From evan@status.net Sat Dec 1 06:42:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7762A11E8097 for ; Sat, 1 Dec 2012 06:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z86b009DjgEa for ; Sat, 1 Dec 2012 06:42:36 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 52DCB11E809A for ; Sat, 1 Dec 2012 06:42:34 -0800 (PST) Received: from [192.168.0.119] (24-226-215-21.ae.cgocable.ca [24.226.215.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 36DDE8D4597; Sat, 1 Dec 2012 14:54:47 +0000 (UTC) Message-ID: <50BA1756.70808@status.net> Date: Sat, 01 Dec 2012 09:42:30 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "webfinger@googlegroups.com" References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010407060407020908060801" Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 14:42:38 -0000 This is a cryptographically signed message in MIME format. --------------ms010407060407020908060801 Content-Type: multipart/alternative; boundary="------------020700070503010602080409" This is a multi-part message in MIME format. --------------020700070503010602080409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I think I've already given this proposal my -1. It doesn't belong in this spec, which isn't about libraries or their=20 APIs. If someone wants to define an IDL model for Webfinger libraries in = some other document, best wishes. This document should be about the interface between clients and servers, = not the interface between client libraries and their calling applications= =2E -Evan On 12-11-30 06:09 PM, Tim Bray wrote: > On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros > wrote: > > > You're right on target. In fact, I have made both proposals here: > > > > 1. Mandatory TLS > > 2. Mandatory-to-implement configuration for no-HTTP fallback. > > Essentially in this case the inputs to a WF client are an email > > address and a boolean to say whether fallback is allowed. May not be > > pleasant to write in a spec... > > OK, let's make this concrete, I don't think it's that unpleasant to=20 > spec out: > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > In draft-ietf-appsawg-webfinger-06 > > - Remove the second paragraph of Section 5.1, which begins "Clients=20 > MUST first attempt a query... > > Introduce a new section 5.2 and bump up the other sections, as follows > > 5.2 Use of HTTPS > > WebFinger client software MUST accept as input a boolean parameter=20 > which for the purposes of this discussion will be referred as=20 > "allow-fallback". > > WebFinger client software MUST attempt to retrieve=20 > /.well-known/webfinger using the HTTPS protocol. If an HTTPS=20 > connection is made, and the server has an invalid certificate, or=20 > returns an HTTP status code indicating an error, the client software=20 > MUST report an error and cease attempting to retrieve the resource. > > If the WebFinger client software is unable to establish an HTTPS=20 > connection to the server, behavior depends on the value of the=20 > allow-fallback parameter. If the value of allow-fallback is true, the = > client software MAY fall back to unencrypted HTTP in an attempt to=20 > retrieve /.well-known/webfinger. If allow-fallback is false, client=20 > software MUST report an error and cease attempting to retrieve the=20 > resource. > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------020700070503010602080409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think I've already given this proposal my -1.

It doesn't belong in this spec, which isn't about libraries or their APIs. If someone wants to define an IDL model for Webfinger libraries in some other document, best wishes.

This document should be about the interface between clients and servers, not the interface between client libraries and their calling applications.

-Evan

On 12-11-30 06:09 PM, Tim Bray wrote:
On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros <br= eno@google.com> wrote:

> You're right on target. In fact, I have made both proposals here:
>
> 1. Mandatory TLS
> 2. Mandatory-to-implement configuration for no-HTTP fallback.<= br> > Essentially in this case the inputs to a WF client are an email
> address and a boolean to say whether fallback is allowed. May not be
> pleasant to write in a spec...

OK, let's make this concrete, I don’t think it’s that u= npleasant to spec out:
<<<<<<<<<<<<<<<<<<&= lt;<<<<<<<<<<<<<<<<<&l= t;<<<<<<<<<<<<<<<<<
In draft-ietf-appsawg-webfinger-06

- Remove the second paragraph of Section 5.1, which begins “Clients MUST first attempt a query...

Introduce a new section 5.2 and bump up the other sections, as follows

5.2 Use of HTTPS

WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback".

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol.  If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter.  If the value of allow-fallback is t= rue, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger.  If allow-fallback= is false, client software MUST report an error and cease attempting to retrieve the resource.



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

--------------020700070503010602080409-- --------------ms010407060407020908060801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq 4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU 4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2 QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg /axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM +O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31 3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0 cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8 4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEyMDEx NDQyMzBaMCMGCSqGSIb3DQEJBDEWBBThl+mz+5tkjq2mQCa1n+FH/yJC2DBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBABne Krj1NDX6xSWmr63okXp+8lJRD/LugBXeHD4DbPQq4SC7+1gj1xTpX0UiL01n94+PM+ang0M+ ZChZ3PtrhipbKccCyvjRIKCVvyuAPrXlhjRvsUt7229wNp4Kjwhgy6dPKExGFxxLv0tRoy4p jmu4/ehYrwVyVhF3Wz+75GsLj8EDm6Zc8uemsDvDC67vV5kObVYG9hzobS1/B3xtt4P2k+Cq ePMrQ+BLrNv705C1lUgB2S8R8MaflXk+rLAJxgPWTiJuxcqE4cqei7Pbsa7/wCR1MN0Pu+BZ Nf8Kj9roWWfY8cGRuPYvcI7ZncobhqErToiiNulkesAv8Uzz/e0AAAAAAAA= --------------ms010407060407020908060801-- From evan@status.net Sat Dec 1 07:48:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAF01F0C5C for ; Sat, 1 Dec 2012 07:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiv1yV-2wicN for ; Sat, 1 Dec 2012 07:48:18 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id BC0F91F0C49 for ; Sat, 1 Dec 2012 07:48:14 -0800 (PST) Received: from [192.168.0.119] (24-226-215-21.ae.cgocable.ca [24.226.215.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 634C98D44D5; Sat, 1 Dec 2012 16:00:28 +0000 (UTC) Message-ID: <50BA26BB.7090904@status.net> Date: Sat, 01 Dec 2012 10:48:11 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@googlegroups.com References: <27AB907B-7B70-4931-BCEC-6ADCC966601B@josephholsten.com> <50B7C3CA.4010800@status.net> <50B7CB43.3080607@status.net> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050003020507090204000108" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I'm calling this sans-tls bluff X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 15:48:20 -0000 This is a cryptographically signed message in MIME format. --------------ms050003020507090204000108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12-11-29 05:03 PM, Breno de Medeiros wrote: > On Thu, Nov 29, 2012 at 12:53 PM, Evan Prodromou wrot= e: >> I disagree with the premise. I don't think it's impossible to use Webf= inger >> securely if it's possible to use Webfinger insecurely. Just say, "For = this >> application, only use HTTPS." > You are free to disagree, but that doesn't change the facts. If the > client will fallback to HTTP, the server can do nothing to protect > that client. If by client you mean popular implementations in open > source libraries, then the server cannot protect most users. Then don't use those libraries for security-related applications. --Evan --------------ms050003020507090204000108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq 4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU 4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2 QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg /axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM +O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31 3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0 cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8 4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEyMDEx NTQ4MTFaMCMGCSqGSIb3DQEJBDEWBBQhhl+s18r6o10Tq6V2E1QfEg9UYzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBAD4D bKRTkswqA2S3cGtz+H/TdbUqj2c9Sx4kUPQfQ2rZufQqxqtz3xzP7viDJ2p39z3Yh+eAP5qG F4ZipElB/GNz4WggIr5lKn8jLLvx1xHJqWTNjuCrvARIvBjDyVJePQDE4Cv28MZniRieIASV xRBHEIopULEZF7Vn680h5WhsJa0sLYWqJIGuCa7pv/sJmmw6IQiVoXxydoxG7/aRpvTHDEM3 ZByLp8d7AT+rwX50IGCZ3gXb6+DWWcqub+CFHKskLiZBJwkbiTmGxGLhj8m3MGRUGCFyzc4D /4feDMJ6B2tDVtRVzSlm5HvmZr0MhzScTMfYJ47oJeSH7Gu/G04AAAAAAAA= --------------ms050003020507090204000108-- From jasnell@gmail.com Sat Dec 1 07:57:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F0F21E805F for ; Sat, 1 Dec 2012 07:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBm5thONWiVA for ; Sat, 1 Dec 2012 07:57:04 -0800 (PST) Received: from mail-ia0-f177.google.com (mail-ia0-f177.google.com [209.85.210.177]) by ietfa.amsl.com (Postfix) with ESMTP id B8BD511E8097 for ; Sat, 1 Dec 2012 07:57:04 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id u21so1451718ial.22 for ; Sat, 01 Dec 2012 07:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y9Nkz/Xgy7KCxWHkQ0b1dccuWvvueyw1Gc7ThmusuF4=; b=msMCe5CEWjaASM8to2HH/O+8um+qAJrS3IE5XzucgGhV+T0vJP7ikeMe2oTsyrY2H9 vGTb1ypai+2syVI1N9mM0hzHYaCnzUtxZydkgO69KZBVpwHKgQTBaWGY+JRHfFog54Up 28URbogCaNXmCnB62QSQ4/DLAcNQP3tCTrS7FP2CyyXvmaurVEuZ0dslssFLsNMl8LUt JBg0EsMGYIQfCcNbvIGwFabnBs+PXzIOObG/wkluAFqjwos0ZkRKI2263Q7LQC35fJe2 zS7+ONzJuiobEuQhd2s1I7BLT3eZ7a6U+Gb8Z1WkHKJsCffZdSzRxlWCJHvy3zU6YaNo LXCQ== MIME-Version: 1.0 Received: by 10.50.6.136 with SMTP id b8mr1634833iga.54.1354377424148; Sat, 01 Dec 2012 07:57:04 -0800 (PST) Received: by 10.64.41.229 with HTTP; Sat, 1 Dec 2012 07:57:02 -0800 (PST) Received: by 10.64.41.229 with HTTP; Sat, 1 Dec 2012 07:57:02 -0800 (PST) In-Reply-To: <50BA1756.70808@status.net> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> Date: Sat, 1 Dec 2012 07:57:02 -0800 Message-ID: From: James M Snell To: Evan Prodromou Content-Type: multipart/alternative; boundary=e89a8f5032f442174604cfcc9103 Cc: webfinger@googlegroups.com, IETF Apps Discuss Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 15:57:05 -0000 --e89a8f5032f442174604cfcc9103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to Evans objection On Dec 1, 2012 6:42 AM, "Evan Prodromou" wrote: > I think I've already given this proposal my -1. > > It doesn't belong in this spec, which isn't about libraries or their APIs= . > If someone wants to define an IDL model for Webfinger libraries in some > other document, best wishes. > > This document should be about the interface between clients and servers, > not the interface between client libraries and their calling applications= . > > -Evan > > On 12-11-30 06:09 PM, Tim Bray wrote: > > On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros > wrote: > > > You're right on target. In fact, I have made both proposals here: > > > > 1. Mandatory TLS > > 2. Mandatory-to-implement configuration for no-HTTP fallback. > > Essentially in this case the inputs to a WF client are an email > > address and a boolean to say whether fallback is allowed. May not be > > pleasant to write in a spec... > > OK, let's make this concrete, I don=E2=80=99t think it=E2=80=99s that unp= leasant to spec > out: > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > In draft-ietf-appsawg-webfinger-06 > > - Remove the second paragraph of Section 5.1, which begins =E2=80=9CClien= ts MUST > first attempt a query... > > Introduce a new section 5.2 and bump up the other sections, as follows > > 5.2 Use of HTTPS > > WebFinger client software MUST accept as input a boolean parameter which > for the purposes of this discussion will be referred as "allow-fallback". > > WebFinger client software MUST attempt to retrieve /.well-known/webfinger > using the HTTPS protocol. If an HTTPS connection is made, and the server > has an invalid certificate, or returns an HTTP status code indicating an > error, the client software MUST report an error and cease attempting to > retrieve the resource. > > If the WebFinger client software is unable to establish an HTTPS > connection to the server, behavior depends on the value of the > allow-fallback parameter. If the value of allow-fallback is true, the > client software MAY fall back to unencrypted HTTP in an attempt to retrie= ve > /.well-known/webfinger. If allow-fallback is false, client software MUST > report an error and cease attempting to retrieve the resource. > > > > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailma= n/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --e89a8f5032f442174604cfcc9103 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1 to Evans objection

On Dec 1, 2012 6:42 AM, "Evan Prodromou&quo= t; <evan@status.net> wrote:
=20 =20 =20
I think I've already given this proposal my -1.

It doesn't belong in this spec, which isn't about libraries o= r their APIs. If someone wants to define an IDL model for Webfinger libraries in some other document, best wishes.

This document should be about the interface between clients and servers, not the interface between client libraries and their calling applications.

-Evan

On 12-11-30 06:09 PM, Tim Bray wrote:
On Fri, Nov 30, 2012 at 2:28 PM, Breno de Med= eiros <breno@googl= e.com> wrote:

> You're right on target. In fact, I have made both proposals here:
>
> 1. Mandatory TLS
> 2. Mandatory-to-implement configuration for no-HTTP fallback. > Essentially in this case the inputs to a WF client are an email
> address and a boolean to say whether fallback is allowed. May not be
> pleasant to write in a spec...

OK, let's make this concrete, I don=E2=80=99t think it=E2=80=99s = that unpleasant to spec out:
<<<<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<&l= t;<<<<<<<<<<<<<<<<

In draft-ietf-appsawg-webfinger-06

- Remove the second paragraph of Section 5.1, which begins =E2=80=9CClients MUST first attempt a query...

Introduce a new section 5.2 and bump up the other sections, as follows

5.2 Use of HTTPS

WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback".

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol.=C2=A0 If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter.=C2=A0 If the value of allow-fallback is tru= e, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger.=C2=A0 If allow-fallback i= s false, client software MUST report an error and cease attempting to retrieve the resource.



_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8f5032f442174604cfcc9103-- From melvincarvalho@gmail.com Sat Dec 1 08:03:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1D111E809C for ; Sat, 1 Dec 2012 08:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfq00+bYPbLe for ; Sat, 1 Dec 2012 08:03:18 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05FBF11E8097 for ; Sat, 1 Dec 2012 08:03:17 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so1245504iaz.31 for ; Sat, 01 Dec 2012 08:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GLbRuXXh3JxqM9570UXzNgjIMeMywSv5UInY1fHXnwY=; b=gjQ7CMOKwS6lGjJ8+1xUshfzKMukVHyiAf71n1lKjOqEfjzZc9XKqoPj3FaJ4qzxZS gfFh0w821wXvTwc6NOMN0I1rH8nAZFlc26EdHeMHBobcxB6DcX01dTlKxBhQvOCoJY0Y ckjpkFYIUf8HXMFq9fnPBslex7Kq7RonvkHAe/EICO26WT+aAe55CLYCQDZGbxaBgx28 p5NPJBglny2MKqxlmaBCEqtWEvMft/eeRHL2e6FUxCIuS5eo6LxyYAqTAdlf4++wgwz6 CFs6gmdO31G74CPbuznTlwMUXGLBIoKVdUbmVq8PEdKrCk6b1VPpWjEEVdfW9IP0prWU Ba0Q== MIME-Version: 1.0 Received: by 10.50.179.99 with SMTP id df3mr1846653igc.20.1354377797594; Sat, 01 Dec 2012 08:03:17 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sat, 1 Dec 2012 08:03:17 -0800 (PST) In-Reply-To: <27AB907B-7B70-4931-BCEC-6ADCC966601B@josephholsten.com> References: <27AB907B-7B70-4931-BCEC-6ADCC966601B@josephholsten.com> Date: Sat, 1 Dec 2012 17:03:17 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=14dae9340347846e8604cfcca7c2 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I'm calling this sans-tls bluff X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 16:03:18 -0000 --14dae9340347846e8604cfcca7c2 Content-Type: text/plain; charset=ISO-8859-1 On 29 November 2012 20:23, Joseph Holsten wrote: > I don't think this wf-sans-tls issue is an issue to any real, existent > person. > > I'll bet $50 that you can't find a site operator that has >50 users and > would implement webfinger so long as it doesn't require https. > Is having >50 users a requirement for webfinger? > > -- > http://josephholsten.com --14dae9340347846e8604cfcca7c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 29 November 2012 20:23, Joseph Holste= n <joseph@josephholsten.com> wrote:
I don't think this wf-sans-tls issue is an issue to any real, existent = person.

I'll bet $50 that you can't find a site operator that has >50 us= ers and would implement webfinger so long as it doesn't require https.<= br>

Is having >50 users a requirement for webfinger= ?
=A0

--
http://josephholsten= .com

--14dae9340347846e8604cfcca7c2-- From bradfitz@google.com Fri Nov 30 12:20:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCFA21F8430 for ; Fri, 30 Nov 2012 12:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.883 X-Spam-Level: X-Spam-Status: No, score=-102.883 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpJu-b32q+EA for ; Fri, 30 Nov 2012 12:20:04 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9CD721F841E for ; Fri, 30 Nov 2012 12:20:04 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so959869oag.31 for ; Fri, 30 Nov 2012 12:20:00 -0800 (PST) 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=yyVxdWM1ZNDFgUtxMyRPgkb7C4DOtG3jLVcyWJWsYmw=; b=NpCX/Qenb0MJVo8jep/FfL2xQXAgcCuBEjFv8SARNQti9GiEltdmIaitCP1FlMgECW pnS9GxmrvEUnckSIeTKyfEBP9QLeL4RtShovGjT7xYUoo2bjO+1cYSWkD/DLRfEcUrEb gaKYPpVUjzX4D8Us+5EEPq9Hb+L9dm7HBCgi27X9wy+tcecQUkf78PKHA5abUox6BNt3 uWB+t+o5r+HAnmuJDTXGHyBeC9Q8TyP0HtIRmlTgVmuoqsIwTa/440nlZmZ46sv7yL6p OzAcYwgwVQSR+pRpSDiH2ICYOsGsCpp0YFU8MWZLNX/G8sUbTeS4WG+9vwYb42xZZUA1 pglA== X-Google-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:x-gm-message-state; bh=yyVxdWM1ZNDFgUtxMyRPgkb7C4DOtG3jLVcyWJWsYmw=; b=fzU/cIGaaG5LnEP81hfhx7VQWZhlFb1szxAaSJjxn/lGcUlHtEtI3bfqUUheznNTl0 ed5qOD15+tMFqr2E0Yof9i56U2VwVnJS67fe8/XpYkD4dMsV6ZMYZ985+4kyzlew6C7k A81PcNl4TrRGHN2QbO4xFUdK8grmRrO7KXThHcXfgLOvzGW37YUHYC7x0ocAdDWT6tev Fim3/mud8n2qBKoDa6o2c9htJAxEP2XgSHDBJTN5ILgWYaflUxOTRWk3cUhM1Xbx0bqW 84Bbbw2LK8nn8XwUkYegAoag7wKbwYBWEYzN46jZiIUij7DVKWSZezmWslCJM6qrnHYv 3mog== MIME-Version: 1.0 Received: by 10.60.19.105 with SMTP id d9mr2066932oee.83.1354306800391; Fri, 30 Nov 2012 12:20:00 -0800 (PST) Received: by 10.76.22.44 with HTTP; Fri, 30 Nov 2012 12:20:00 -0800 (PST) In-Reply-To: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> Date: Fri, 30 Nov 2012 12:20:00 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8ff1c4bec1171a04cfbc1f89 X-Gm-Message-State: ALoCoQkQGfWgW47SC62KZ05ToMLHD3iyj21ien5Lp/kVjTynim6J0ko3t1p+oCJbGG7EJp1R5fE+o+wItUHzLPdobD9VBY0lS7PWekSF6FSvEdnyPGMnRNIxQfPAqrn25WqYL+KgmeNqhRkwLDtz9+cDGF6cXdMmv4NUiRT8IlctaJPy4JvRx9FsIqRGb9Kgw4wT9xAnTAUV X-Mailman-Approved-At: Sat, 01 Dec 2012 08:04:50 -0800 Cc: Joseph A Holsten , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Webfinger goals doc X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 20:20:06 -0000 --e89a8ff1c4bec1171a04cfbc1f89 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 30, 2012 at 10:48 AM, Bob Wyman wrote: > > > > On Fri, Nov 30, 2012 at 12:20 PM, Brad Fitzpatrick wrote: > >> On Fri, Nov 30, 2012 at 8:43 AM, Bob Wyman wrote: >> >>> >>> >>> >>> On Thu, Nov 29, 2012 at 5:31 PM, John Panzer wrote: >>> >>>> It's Bob's entire public identity. Knowing it wasn't altered in >>>> transit or served from a take origin is kind of... important. >>>> >>> An alternative to requiring a TLS encrypted link to read Bob's >>> information would be to permit Bob to sign the documents he publishes. That >>> would allow some level of integrity and authentication to be provided >>> whether HTTP or HTTPS had been used. WebFinger says nothing about signing. >>> Why not? >>> >> >> WebFinger says nothing about religion or tying shoelaces either. >> >> I intend to use email addresses as the identifier for addressing people >> (crazy!) and sharing in my Camlistore project, which means Camlistore can >> use WebFinger to find other people's Camlistore servers and communicate >> between them. And in Camlistore, everything is signed. >> >> Yet I'm not trying to push Camlistore into WebFinger. >> > Thanks for your very kind comments. But, can you tell me, if I wanted to > publish a signed JRD using WebFinger, how would I do that? The JRD > specification linked to the > latest WebFinger draft doesn't seem to address the issue. > Two options immediately come to mind: 1) Use Accept headers. Have the WebFinger client tell the WebFinger server that it supports a superset of the base types and would understand a version that's signed with the JSON signing method of the week. 2) Have the unsigned version include a URL to the signed version, then it could be understood by both old and new clients. --e89a8ff1c4bec1171a04cfbc1f89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Fri, Nov 30, 2012 at 10:48 AM, Bob Wym= an <= bob@wyman.us> wrote:



On Fri, Nov 30, 2012 at 12:20 = PM, Brad Fitzpatrick <bradfitz@google.com> wrote:
On Fri, Nov 30, 2012 at 8:43 AM, Bob Wyman <bob@w= yman.us> wrote:



On Thu, Nov 29, 2012 at 5:31 PM, John Panzer <= jpanzer@google.com> wrote:

It's Bob's entire pub= lic identity.=C2=A0 Knowing it wasn't altered in transit or served from= a take origin is kind of... important.

=C2=A0An alternative to requiring a TLS encrypted l= ink to read Bob's information would be to permit Bob to sign the docume= nts he publishes. That would allow some level of integrity and authenticati= on to be provided whether HTTP or HTTPS had been used. WebFinger says nothi= ng about signing. Why not?

WebFinger says nothing a= bout religion or tying shoelaces either.

I intend = to use email addresses as the identifier for addressing people (crazy!) and= sharing in my Camlistore project, which means Camlistore can use WebFinger= to find other people's Camlistore servers and communicate between them= . =C2=A0And in Camlistore, everything is signed.

Yet I'm not trying to push Camlistore into WebFinge= r.
Thanks for your very kind= comments. But, can you tell me, if I wanted to publish a signed JRD using = WebFinger, how would I do that? =C2=A0The JRD specification linked to the= latest WebFinger draft doesn't seem to address the issue.

Two options immediately come t= o mind:

1) Use Accept headers. =C2=A0Have the WebFinger c= lient tell the WebFinger server that it supports a superset of the base typ= es and would understand a version that's signed with the JSON signing m= ethod of the week.

2) Have the unsigned version include a URL to the signed version, = then it could be understood by both old and new clients.

--e89a8ff1c4bec1171a04cfbc1f89-- From bradfitz@google.com Fri Nov 30 16:01:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DC521F8714 for ; Fri, 30 Nov 2012 16:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.89 X-Spam-Level: X-Spam-Status: No, score=-102.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irD5ZNs-YmKf for ; Fri, 30 Nov 2012 16:01:08 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD07621F86A8 for ; Fri, 30 Nov 2012 16:01:07 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1130618oag.31 for ; Fri, 30 Nov 2012 16:01:07 -0800 (PST) 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=QplePIKiiFb8OQS+AHFgONf/kyq7kGDRZM9GNr1gHSA=; b=jqBhGK3SkDahY9CTkEk6W2UXs5kAAcs2NaX3iPIw09SzKArHs4qBYtho49TVVLXJG7 va+SUfs7Aud1+LSspeTSi6sNCOBY7jhheB+RwF8RajiKIF2ANFfH+h5c/cxYZVmwbKdM rn7j2B98YJNlfWJhfpU9xaYnkAC3XpN5UWhV1sUry5BY4GajMZI3FkTMyMQwFhbvVTfS ec8IwqYbltsUmina7oI5SP7EAbzNpL5+Qy5u93yeBlKvVCnWlybZmimllg5yeVA+dtC9 0y1F7LMfeqoPsNUACbg4c6E0aAy2ivhDDQdbEhwJJiayZ1sGFg44MSd2lPGhPDYQmuAt DeIQ== X-Google-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:x-gm-message-state; bh=QplePIKiiFb8OQS+AHFgONf/kyq7kGDRZM9GNr1gHSA=; b=WNKOTbIIM2wGfiGlfGYh7Z55li4qm4kwEeD0/Dy4zY64ruPgSzTWYCCy8cTSu3iOHH SyGGCwRmj6UhTGflAbyADFvalTMzyui5NF7Dl4U3jz4rIHT5vjC3JK2rB/Lrh5NZGFrQ x6OYfmIqva3MtTaAS3/UkW65i2KEErlgdQYT/We0SlSCYxiSOZNKpQZHDtwF0e91mvT1 FRW/mOHZxAX84LRccKP5RHcxgwdW3q55r3xabXOb91PhtjyjewJP2/w5GVPe8LvmeBps ePNSulxqqcch7T7ijVumx1IdAbNMUY4i7CU1pBkrEW6d1KgRq69vx1ra9Z/+gthBCxNU Ocgw== MIME-Version: 1.0 Received: by 10.60.7.129 with SMTP id j1mr2441382oea.54.1354320067357; Fri, 30 Nov 2012 16:01:07 -0800 (PST) Received: by 10.76.22.44 with HTTP; Fri, 30 Nov 2012 16:01:07 -0800 (PST) In-Reply-To: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> Date: Fri, 30 Nov 2012 16:01:07 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8fb1fac886ec7a04cfbf364b X-Gm-Message-State: ALoCoQmpzkJPNYNKB7d/VVBJ8eQyvfu8Ep7kKxI8OrAkMEtBihIhn8hbWm6btEQq4b8rImzzzqOYKVXUSh0CKsBrHN/V+1Yz/ezzJucRR2ony+BQyPzYmCuBYlLdQqDBWS+wNENuKYd4s5oktZfpxPGYGMOdKg0dDMf6F2j2Td9j6xRAQb1fcICPBtx7DRNRbcXDk89FsFVP X-Mailman-Approved-At: Sat, 01 Dec 2012 08:05:04 -0800 Cc: "apps-discuss@ietf.org Discuss" , Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 00:01:08 -0000 --e89a8fb1fac886ec7a04cfbf364b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I like Tim Bray's addition. If WebFinger isn't going to be HTTPS-only (which is still my preference, after thinking about it a few days), it definitely needs this sort of addition (or this addition verbatim), otherwise nobody using WebFinger for anything secure will be able to trust likely-insecure permissive clients out there. But I'd still like to keep WebFinger simpler for clients and more secure by making it HTTPS-only. A follow-on spec could define DirtyFinger and its hygienic best practices, but the onus would be on that group to define all this sort of stuff like Tim does below. And DirtyFinger could have its own well-known endpoint. In retrospect, I should've made OpenID HTTPS-only from the beginning, but I was lazy ("HTTPS is annoying"), and I regret it. It resulted in years of debate about OpenID's security, much of it warranted. If WebFinger is going to be a bootstrapping mechanism for other things, it'd be nice to know the base was trustworthy, even if for certain applications it's often unnecessary. I'm mostly interested in the client simplicity: one request. On Fri, Nov 30, 2012 at 3:25 PM, Tim Bray wrote: > Or, a little more smoothly. =E2=80=9CIf the value of allow-fallback is no= t > explicitly specified, WebFinger software MUST assume the value is false.= =E2=80=9D > > > On Fri, Nov 30, 2012 at 3:18 PM, Breno de Medeiros wrot= e: > >> On Fri, Nov 30, 2012 at 3:15 PM, Martin Thomson >> wrote: >> > On 30 November 2012 15:09, Tim Bray wrote: >> >> WebFinger client software MUST accept as input a boolean parameter >> which for >> >> the purposes of this discussion will be referred as "allow-fallback". >> > >> > I suspect that many implementations will choose to disregard this >> > clause in favour of fixing the value to "false". >> > <<< >> > WebFinger client software MAY accept as input a boolean parameter, >> > which for the purposes of this discussion will be referred /to/ as >> > "allow-fallback". Otherwise, WebFinger client software MUST assume >> > that allow-fallback is false. >> >> +1 >> >> -- >> --Breno >> > > --e89a8fb1fac886ec7a04cfbf364b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= like Tim Bray's addition.

If WebFinger isn't go= ing to be HTTPS-only (which is still my preference, after thinking about it= a few days), it definitely needs this sort of addition (or this addition v= erbatim), otherwise nobody using WebFinger for anything secure will be able= to trust likely-insecure permissive clients out there.

But I'd still like to keep WebFinger simpler for cl= ients and more secure by making it HTTPS-only. =C2=A0A follow-on spec could= define DirtyFinger and its hygienic=C2=A0best practices, but the onus woul= d be on that group to define all this sort of stuff like Tim does below. = =C2=A0And DirtyFinger could have its own well-known endpoint.

In retrospect, I should've made OpenID HTTPS-only f= rom the beginning, but I was lazy ("HTTPS is annoying"), and I re= gret it. =C2=A0It resulted in years of debate about OpenID's security, = much of it warranted.

If WebFinger is going to be a bootstrapping mechanism f= or other things, it'd be nice to know the base was trustworthy, even if= for certain applications it's often unnecessary.

I'm mostly interested in the client simplicity: one request.
=


On Fri, Nov 3= 0, 2012 at 3:25 PM, Tim Bray <tbray@textuality.com> wrote= :
Or, a little more smoothly. =E2=80=9CIf the = value of allow-fallback is not explicitly specified, WebFinger software MUS= T assume the value is false.=E2=80=9D


On Fri, Nov 30, 2012 a= t 3:18 PM, Breno de Medeiros <breno@google.com> wrote:
On Fri, Nov 30, 2012 at 3:15 PM, M= artin Thomson
<martin.th= omson@gmail.com> wrote:
> On 30 November 2012 15:09, Tim Bray <tbray@textuality.com> wrote:
>> WebFinger client software MUST accept as input a boolean parameter= which for
>> the purposes of this discussion will be referred as "allow-fa= llback".
>
> I suspect that many implementations will choose to disregard this
> clause in favour of fixing the value to "false".
> <<<
> WebFinger client software MAY accept as input a boolean parameter,
> which for the purposes of this discussion will be referred /to/ as
> "allow-fallback". =C2=A0Otherwise, WebFinger client software= MUST assume
> that allow-fallback is false.

+1

--
--Breno


--e89a8fb1fac886ec7a04cfbf364b-- From Cameron.Byrne@t-mobile.com Fri Nov 30 19:26:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5804021F849E for ; Fri, 30 Nov 2012 19:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSpJxRzb2AFf for ; Fri, 30 Nov 2012 19:26:33 -0800 (PST) Received: from PRDAPBML02.T-MOBILE.COM (mail1.t-mobile.com [206.29.177.244]) by ietfa.amsl.com (Postfix) with ESMTP id F0D3C21F849B for ; Fri, 30 Nov 2012 19:26:32 -0800 (PST) X-AuditID: ce1db1f4-b7fd86d00000050d-b8-50b978e70e1e Received: from PRDMSHUB01.GSM1900.ORG (prdmscdlp013.gsm1900.org [10.154.65.12]) by PRDAPBML02.T-MOBILE.COM () with SMTP id 51.75.01293.7E879B05; Fri, 30 Nov 2012 19:26:31 -0800 (PST) Received: from PMBX03.gsm1900.org ([fe80::15b3:880b:af6c:9359]) by PRDMSHUB01.GSM1900.ORG ([fe80::20e6:27fc:4d81:5ebb%12]) with mapi; Fri, 30 Nov 2012 19:26:30 -0800 From: "Byrne, Cameron" To: Ted Hardie , "apps-discuss@ietf.org" , "draft-ietf-v6ops-464xlat.all@tools.ietf.org" Date: Fri, 30 Nov 2012 19:26:27 -0800 Thread-Topic: Review of draft-ietf-v6ops-464xlat-08 Thread-Index: Ac3PP8RxdXqOpw4/SR+LsfpIAMPfigALSYRwAACObVA= Message-ID: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA11UfUwbZRjn7V2PG+Odt1LahzrIKBgTB4g4DXEGBcWwbLhmGrOYOCzjhGal Jb2Wj8VEtiyCk5EF5rSV4UBEYCRkI3yNRbHTOCYfdVsGDkacfAywLg5QYInM93oUjv1zee75 Pe/v+T2/97ljKdV/m3WsyWLnbRajWc8E0UGu5ODYe4VdhvjTK1zi+ZkGJrHsvJtKPHo26VUq rct1JzCtrm5ZkbZwY54xUO8GvZzFm035vO3ZpPeDcv72/KvI+9VQ+H27hy5GM6+cQJtY4HZC 7/2vFFKsAc9YC3MCBbEqrhPB8r22QOmlEUFveYOviuGehwd3aykRUHNtCNz906SKZWnuKXCV xYg1IVwCVLZOM2KsJvVX+76hpPgl8Da1+XgwtwcWe/4IFGNEOi9ea/blKU4Ltyf8ijiouzxI SXEozIyvKKX6UBgtaUFSfQyc655jpHgH1Nf8SUn8W6HXOUFLZ8Pgh4Zh+hRSu2QtXLLjLtlx l+z4OUQ3Ia1h/+vJhpT0vfEJcW/Hpu9L2b03Ne61fekXEbmTgfALC52oojLWjTgW6YMxN9Vp UCmN+UJRrhuVIFah12EUEBCgCsm0ZhXlGIWcDMGRmWsSBJPVog/F71i7DKota5jNYeYFvRp3 FJA0XktnOsyHCVG3mF0nsvAFgpm3kw3RR+AD+aSxVtZEyDMdMlkdQobDZnYjYClCGz5HinCW segIb7NKzdzoSZbWa/H2SMLNZRvt/GGez+NtfvQMuV19uDSDxsZn84UfmMykpXwMwH2isq1y WJpEi6tyRV454hsmHFfGE2ADo2yeSBzT32ZQ6TY23DiSgt3kRscQG6wPk+SphDxjrmDKlktT 4ys+K/2QJCsEux0kG+zP+iSFYbtYusYikxOOy0V7NesN5FKuoW8RW+UsmUBsl0d8lro/nUAq 2mK18LptkrZQ8WiOw7LROZ1WumlOhvoU6jR4KKrDoHpCBogiCd0tMS+nW9ep245vi2jYhmZy qbOoRkH2lFxYfQW5MPJ7ecyvEHw0X3RmFZHsUmGLqHLzatLnFmAQLfRTyMzahi/pRYlr5HIB CTWIfMELO+H6XxTMe5OhuoeHZm8BjE6WIuicqEDwqOEzBLO/fE5+OzfrEfwz1Y9gdNCDwHl6 lDx6BhWwXOJRQO3X0wr44tZDBVxZqqTg0cdjFJSdvU/B1cUhGpwLtUpYOt6ghPkblxkY9v7M wM3GfgZ+dI8wcKx8nIH5xkkGln6fY2Cs5SED1e2uQOgcbgqcFbdKsb5VduPjLqmxt75D3KpV yL9VaKBN3KrV7OpWBYjJNZYNW8WIkGa9gdwpXTFKuR4/dMZLOaO3vPVlYkBzXfzF0bBLHTsS MjTeA0676Y2EkWYhdnz/SnuxclfEdx/NFSUe1E69SL/5ofrp6NLgCxGor2Wlv6CyaHIgNekn Q3Hc9O6WB78dOln9CfTRe2Zam1q1kSepkaqDNVFRXe8Zot2e40dUL6Tdmbq7q6I7VXkqW08L OcbnnqFsgvF/D+1y95AGAAA= X-Mailman-Approved-At: Sat, 01 Dec 2012 08:05:13 -0800 Subject: Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 03:26:34 -0000 Ted, Thanks for taking the time to review our work. My comments in-line. > -----Original Message----- > From: Ted Hardie [mailto:ted.ietf@gmail.com] > Sent: Friday, November 30, 2012 1:15 PM > To: apps-discuss@ietf.org; draft-ietf-v6ops-464xlat.all@tools.ietf.org > Subject: Review of draft-ietf-v6ops-464xlat-08 >=20 > I have been selected as the Applications Area Directorate reviewer for t= his draft > (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate > ). >=20 > Please resolve these comments along with any other Last Call comments you > may receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. >=20 > Document:draft-ietf-v6ops-464xlat-08 > Title: 464XLAT: Combination of Stateful and Stateless Translation > Reviewer: Ted Hardie > Review Date: November 30, 2012 >=20 > Summary: This draft is not ready for publication as a BCP, and it may not= be an > appropriate candidate for this status. >=20 > Major Issues: >=20 > This document provides a v4/v6 inter-working method using a pair of addre= ss > translators that bracket a network region in which there is no > IPv4 routing. It discusses two different potential deployments. In the = first, the > first address translator is co-resident on the device where the IPv4 addr= ess is > assigned; in the second, the the first address translator is resident in = a nearby > network device. In both, the second address translator is at the border = of the > internal IPv6 routing domain and a global IPv4 routing domain. >=20 > The document has the following applicability statement: >=20 > This BCP only applies when the following two criteria are present: >=20 > 1. There is an IPv6-only network that uses stateful translation > [RFC6146] as the only mechanism for providing IPv4 access. >=20 > 2. There are IPv4-only applications or hosts that must communicate > across the IPv6-only network to reach the IPv4 Internet. >=20 > The first item is problematic. This document describes a method for usin= g > stateful translation, but it does not justify why this is the appropriate= choice; the The choice for using a stateful translator is outside the scope of this doc= ument. =20 But, the IETF has published RFC 6146 which is specifies a stateful protocol= translator on the standards track. RFC6146 is necessary but not sufficien= t to operate an IPv6-only network that is dominated (today) by IPv4 nodes. = The problem of IPv4-referals / IPv4-literals as well as IPv4 sockets APIs = is very real. It would be very unfortunate if the IETF specified stateful = NAT64 in RFC 6146 but was no deployable or could only provide an 85% servic= e (15% of Android apps fail to work on NAT64/DNS64 only networks) Just generally speaking on why stateful is the right choice, many networks = already operate stateful NAT44 and the NAT64 is just another feature that i= s quick to deploy on existing hardware with existing support models. Furth= ermore, this architecture is based on the reality that IPv4 address are no = longer available in APNIC in blocks larger than an emergency /22 (RIPE and = ARIN also have max /22 allocations for the last /8 in the RIR). That said,= stateful multiplex of ports / sessions is absolutely required for any serv= ice that must scale to millions of users. Stateless solutions simply do no= t scale for new entrants that do not have existing IPv4 resources. > encapsulation methods used in something like DS-Lite seem to be an altern= ative > here, and it is not clear either what constraint prevents encapsulation's= use in > these networks or what the advantage is here to using dual translation ov= er an > encapsulation-based method. In other words, this appears circular--it de= fines it Encapsulation can break many things including traffic engineering based on = IP address (no more hop by hop routing), DPI associated with charging (spec= ifically 3GPP defined Policy and Charging Controls (PCC)). DS-lite also has configuration driven exclusively by DHCP, there is no DHCP= in 3GPP networks. > as a best practice for networks using stateful translation, rather than d= efining > when stateful translation is best practice. >=20 The wording of the document was chosen to state the circumstance that you h= ave this type of network: IPv6-only with stateful NAT64 as defined here ht= tp://tools.ietf.org/html/rfc6144#section-2.1 Given that scenario, there is= a practical reality that hosts and software have specific IPv4 dependencie= s and thus this scenario is defunct without something like 464XLAT. And, th= at goes origins of 464XLAT. It is emergent behavior that occurs in my IPv6= -only network at T-Mobile USA. People wanted Skype to work so they put an = NAT46 on the host ....and Skype now worked. We track broken Android apps at this list (15% don't work: Skype, Netflix,= Spotify ...), and 464XLAT fixes 100% of the broken apps http://goo.gl/z3j3= q 464XLAT allows for the real commercial deployment of IPv6-only networks. The current state of the network at T-Mobile USA today is squat space + NAT= 44. This is the same at Rogers and Sprint mobile networks here in North Am= erica. > The document also says this in the introduction, which provides an additi= onal > applicability > limitation: >=20 > The 464XLAT architecture only supports IPv4 in the > client server model, where the server has a global IPv4 address. > This means it is not fit for IPv4 peer-to-peer communication or > inbound IPv4 connections >=20 > If this is true, it is highly problematic, because it provides a constrai= nt on the > semantics of an RFC 1918 address that is not currently present. It is no= t entirely > clear, though, that this is true. >=20 > Systems attempting peer-to-peer communication when using RFC 1918 > addresses typically must use ICE to handle the artifacts of network addre= ss > translation. > I was not able to understand > how ICE would fail here, either in the case where the CLAT was resident o= n the > node or when it is network resident. In my naive reading, this would wor= k for > cases where the ICE server was in the IPv4 global routing domain. Becaus= e > PLATs are provisioned with a single IP address, the mapped address attrib= ute What do you mean 1 IP address? 1 IPv4 address? They will have pools of ad= dress for sure. > would always have the same family and address, but it seems it should be > distinguishable by port. If this is not the case, or there is a differen= t reason why > this mechanism cannot work with ICE, I believe it should be called out in= the > draft explicitly. >=20 We make this restriction because of the case where you and I are on the sam= e ISP. We both have 10.10.10.1 as our local address. Communication fails. If we have unique address space, are right, it would work. But, we do not = want to push an additional level of complexity to try and coordinate unique= LAN side IP addresses. It is simpler to say this simply does not work. A= nd, in case of DNS64, users will generally not use IPv4. IPv4 is only used= for the case of IPv4 referals or IPv4-only host and APIs. > An ICE-based peer-to-peer connection would, certainly, provide a severely= sub- > optimal path for two devices within the same 464xlat region, as it would = hairpin > out and back. But those are not the only potential peer-to-peer connectio= ns and > it would work at least to some degree. >=20 > In the case where the CLAT is resident on a device, but that device provi= des > tethering, the document currently says: >=20 > The CLAT SHOULD perform router function to > facilitate packets forwarding through the stateless > translation even if it is an end-node. >=20 > For proper operation of tethered devices, this would appear to require a = MUST, > rather than a SHOULD. > If it is not MUST, then some description of what will happen is desirable= . > (Perhaps a statement that CLATs which do not provide this functionality c= annot > be used when tethering is in place or whether tethered devices require IP= v4?) > I think you are right. We can do a must here. =20 > Minor Issues: >=20 > This draft is currently targeted for BCP. I do not believe that it > is appropriate to target it for The rational is that 464XLAT is a best practice for RFC 6144 2.1 network th= at has IPv4-only apps in it. > BCP unless it is preferred over encapsulation-based approaches. I also = believe > that the marketing material which is currently embedded in the text (see,= for > example, section 5) should be removed. >=20 I am happy to eliminate section 5, but section 5 has been required during d= raft formation because there are many solutions in this space. > Nits: The description 3GPP applicability relates to 3GPP "Pre-Release 9",= but > there is no citation given. I also note that 3GPP specifications current= ly appear See RFC6459 > to be on release 12, and there is no notice of whether changes between pr= e- The most advanced LTE network is Release 8 at Verizon. Most phones are release 7 or earlier (sold on the market today) New networks like the one T-Mobile will launch next year will be partially = Release 10 > release 9 and the current release have changed the topology in a way to Current release is not relevant to install base. > eliminate the multiple PDP issue raised. If the text means to say that t= his is not a But it does not remove the dependency on IPv4 address that are not availabl= e.... public and private addresses are both exhausted, so we use squat spac= e. > problem for any version 9 or later, and that the problem exists for any v= ersion > prior to 9 which supports multiple address families, it needs to be rewor= ded. I will review the wording. Thanks again for your review. I look forward t= o more feedback from you, thanks again for taking the time to work with us = and sharing your experience Thanks Cameron From ve7jtb@ve7jtb.com Sat Dec 1 09:25:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AD91F0C84 for ; Sat, 1 Dec 2012 09:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkf92VC2V-1f for ; Sat, 1 Dec 2012 09:25:54 -0800 (PST) Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1D01B1F0C6E for ; Sat, 1 Dec 2012 09:25:42 -0800 (PST) Received: by mail-yh0-f42.google.com with SMTP id g71so76315yhg.15 for ; Sat, 01 Dec 2012 09:25:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=dSEzWcgRgZeLWE9wL020e6gaXiZZzO1HiHg+KOQTfdM=; b=Y4yxyTlL1jFMdKdKOGOyNvS8KPuUjarIW0PhO2r5eYl1l8Exc+qHsPKL90mIakA4Tg DbinejAfL2KBQ/Lup7qKf9gw9XjdSy8qg7K1lE6lS8GtjsUt8XEc0a/eDap0P3HTsjSM hdW9dqIwMWrnkmyr97YrCPCn4MKopUraBPN58UI3z+7WClp/YNb98DYw52QyBdu9tGkd 1oO7FJY2nM5wxuwygrJAltq//yfNHrm30CQIvNLlfpNGD5WEzNKzqb1yig2A387Yb8hd 4m3gy+90SoZE/xYLTKCiSC+P5bRcPtYB08tm8XqCLszxcmAlBzVR+u1/3yl797cmTiwV WIhw== Received: by 10.100.245.16 with SMTP id s16mr1477116anh.49.1354382742524; Sat, 01 Dec 2012 09:25:42 -0800 (PST) Received: from [192.168.1.211] (190-20-35-136.baf.movistar.cl. [190.20.35.136]) by mx.google.com with ESMTPS id t2sm7413088anj.3.2012.12.01.09.25.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2012 09:25:41 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_121C55DF-1CB1-4AE6-9F01-1956202BCBEF" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Sat, 1 Dec 2012 14:25:32 -0300 Message-Id: <081143FA-4576-4E80-81EE-A8A1E2C3420C@ve7jtb.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnhjAiuxrM4/kLIJF6BSSlaocW+NpZ7Z+X3S+zFOgmx+orv0yzLy6Ej8PHsx1PANtgiOwWm Cc: Joseph Holsten , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 17:25:55 -0000 --Apple-Mail=_121C55DF-1CB1-4AE6-9F01-1956202BCBEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jeff's RFC on strict transport is good but mostly targeted at the threat = of cookie disclosure if a user clicks through on a TLS warning. We could require WF clients to support it, however if the first = interaction is to the hijacked site the Client never sees the strict = header and would fall back. I don't think this solves the issue. I am uncharacteristically agreeing with Brad on this. I prefer https: = only as it stops lots of interoperability issues, and is simpler for = clients to implement than a fall back sometimes under some circumstances = for some things. Caching will also need to be considered in the client = library you can't cache the http version and later serve it up to a = secure only request it, needs to treat them as separate resources. It = is not simple. If we need to support both the protocol needs to be https: only unless = it receives an explicit request from the app level to allow fallback. =20= In the end that winds up being https: only with extra complexity that is = not required but I could live with it if I have to. John B. On 2012-11-30, at 8:59 PM, Blaine Cook wrote: > http://tools.ietf.org/html/rfc6797 >=20 >=20 > On 30 November 2012 16:36, Nico Williams = wrote: > I think the right thing to do is to leave WF signing for later and > rely on TLS for integrity protection where it's needed. I doubt we're > prepared to start doing JWE signatures here, right now. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 --Apple-Mail=_121C55DF-1CB1-4AE6-9F01-1956202BCBEF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii romeda@gmail.com> = wrote:

http://tools.ietf.org/html/rfc= 6797


On 30 November 2012 16:36, Nico Williams <nico@cryptonector.com> wrote:
I think the right = thing to do is to leave WF signing for later and
rely on TLS for integrity protection where it's needed.  I doubt = we're
prepared to start doing JWE signatures here, right now.
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


= --Apple-Mail=_121C55DF-1CB1-4AE6-9F01-1956202BCBEF-- From ve7jtb@ve7jtb.com Sat Dec 1 09:31:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74A621F8C4E for ; Sat, 1 Dec 2012 09:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.307 X-Spam-Level: X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfS8l9miT7hP for ; Sat, 1 Dec 2012 09:31:17 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBE9E21F8B19 for ; Sat, 1 Dec 2012 09:31:16 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so242066ggn.31 for ; Sat, 01 Dec 2012 09:31:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=rE4Lkozr5smkVYhRg56YD0AUFemIRMeCLnw+cXPcm+w=; b=A3zmZKme/cCasqEztiQKZ82MXGx09ONlbmLZ62yka6YQvsZyeanzNOqc1W4btXiGXU nKR2PoFJ3svyLbbWS6lFru9seH2ycrU3dyvHzsJX7JSyzUlgFTNnrYVDYI+8HLytngeg EM9MRDPpwaakdN9GQusB14rq33OFv/L+94p+ydmjlZUj4Kywr5Tsam9vKexiju1vhAkZ mq6wOjpuKMTwFqmGWsWjSv7hQwjbkvypEG4QcixUMBCZwcZYvlsN22+B9X2rn++tSY3b wy75gqtIbEILbP/PRD5QUoNbg1063zfA0QuH44IOq8iufNdwLvF8e7GUcOR0BjwXODN7 N2Sg== Received: by 10.236.82.178 with SMTP id o38mr5228346yhe.70.1354383076309; Sat, 01 Dec 2012 09:31:16 -0800 (PST) Received: from [192.168.1.211] (190-20-35-136.baf.movistar.cl. [190.20.35.136]) by mx.google.com with ESMTPS id n40sm7407697ani.16.2012.12.01.09.31.13 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2012 09:31:15 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_28751D2A-DF88-4F04-8D72-E5C6AAFC07CB" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Sat, 1 Dec 2012 14:31:07 -0300 Message-Id: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkmxTthCpYwoLuT2yFIq6HlO/BmEUQfFlldoy8pzZ/7uxCxJAomfo47a6UIZ5JlGl4WsInJ Cc: IETF Apps Discuss Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 17:31:17 -0000 --Apple-Mail=_28751D2A-DF88-4F04-8D72-E5C6AAFC07CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Defining library API is not in any way my preference. I think = mandatory TLS is the only correct answer. =20 However if we are to allow both without being clear with developers how = to control fallback it won't be useful. The other thing to do is have two versions of WF clean and dirty and = allow applications to call dirty if clean fails and they want to try = again rather than hiding it all in a single flow and expecting some = magic to happen. John B. On 2012-12-01, at 12:57 PM, James M Snell wrote: > +1 to Evans objection >=20 > On Dec 1, 2012 6:42 AM, "Evan Prodromou" wrote: > I think I've already given this proposal my -1. >=20 > It doesn't belong in this spec, which isn't about libraries or their = APIs. If someone wants to define an IDL model for Webfinger libraries in = some other document, best wishes. >=20 > This document should be about the interface between clients and = servers, not the interface between client libraries and their calling = applications. >=20 > -Evan >=20 > On 12-11-30 06:09 PM, Tim Bray wrote: >> On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros = wrote: >>=20 >> > You're right on target. In fact, I have made both proposals here: >> > >> > 1. Mandatory TLS >> > 2. Mandatory-to-implement configuration for no-HTTP fallback. >> > Essentially in this case the inputs to a WF client are an email >> > address and a boolean to say whether fallback is allowed. May not = be >> > pleasant to write in a spec... >>=20 >> OK, let's make this concrete, I don=92t think it=92s that unpleasant = to spec out: >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >>=20 >> In draft-ietf-appsawg-webfinger-06 >>=20 >> - Remove the second paragraph of Section 5.1, which begins =93Clients = MUST first attempt a query... >>=20 >> Introduce a new section 5.2 and bump up the other sections, as = follows >>=20 >> 5.2 Use of HTTPS >>=20 >> WebFinger client software MUST accept as input a boolean parameter = which for the purposes of this discussion will be referred as = "allow-fallback". >>=20 >> WebFinger client software MUST attempt to retrieve = /.well-known/webfinger using the HTTPS protocol. If an HTTPS connection = is made, and the server has an invalid certificate, or returns an HTTP = status code indicating an error, the client software MUST report an = error and cease attempting to retrieve the resource. >>=20 >> If the WebFinger client software is unable to establish an HTTPS = connection to the server, behavior depends on the value of the = allow-fallback parameter. If the value of allow-fallback is true, the = client software MAY fall back to unencrypted HTTP in an attempt to = retrieve /.well-known/webfinger. If allow-fallback is false, client = software MUST report an error and cease attempting to retrieve the = resource. >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 --Apple-Mail=_28751D2A-DF88-4F04-8D72-E5C6AAFC07CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 jasnell@gmail.com> = wrote:

+1 to Evans objection

On Dec 1, 2012 6:42 AM, "Evan Prodromou" = <evan@status.net> wrote:
=20 =20 =20
I think I've already given this proposal my -1.

It doesn't belong in this spec, which isn't about libraries or their APIs. If someone wants to define an IDL model for Webfinger libraries in some other document, best wishes.

This document should be about the interface between clients and servers, not the interface between client libraries and their calling applications.

-Evan

On 12-11-30 06:09 PM, Tim Bray wrote:
On Fri, Nov 30, 2012 at 2:28 PM, Breno de = Medeiros <breno@google.com> wrote:

> You're right on target. In fact, I have made both proposals here:
>
> 1. Mandatory TLS
> 2. Mandatory-to-implement configuration for no-HTTP = fallback.
> Essentially in this case the inputs to a WF client are an email
> address and a boolean to say whether fallback is allowed. May not be
> pleasant to write in a spec...

OK, let's make this concrete, I don=92t think it=92s that = unpleasant to spec out:
= <<<<<<<<<<<<<<<<<<&l= t;<<<<<<<<<<<<<<<<<<= <<<<<<<<<<<<<<<<<

In draft-ietf-appsawg-webfinger-06

- Remove the second paragraph of Section 5.1, which begins =93Clients MUST first attempt a query...

Introduce a new section 5.2 and bump up the other sections, as follows

5.2 Use of HTTPS

WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback".

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol.  If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter.  If the value of allow-fallback is = true, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger.  If = allow-fallback is false, client software MUST report an error and cease attempting to retrieve the resource.



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

= --Apple-Mail=_28751D2A-DF88-4F04-8D72-E5C6AAFC07CB-- From ve7jtb@ve7jtb.com Sat Dec 1 09:34:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FBB1F0C67 for ; Sat, 1 Dec 2012 09:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRsG-EM8DWsJ for ; Sat, 1 Dec 2012 09:34:37 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA2E1F0C5C for ; Sat, 1 Dec 2012 09:34:36 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id z22so243511ghb.31 for ; Sat, 01 Dec 2012 09:34:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=0vGd7aXHU02DW4tuKil/Ut1yCX6Vtg5bS58c+2FJSf4=; b=d5276UukIMlfpd3zf+eP53Wyrkm4I5jWqfecGIeEmvMmq4s3+W9vHzv0Z6wxIECk0/ H1LGQn2jjpsvgnUWCYDWSm4oDTiy8RKjmB+Zwu7s/ta1hfDKE2UxQzrIwhzDvsL3HFjK nn/L9vQscJDJ9TPJ/F5frXkxNH2sou8+YFOafTohtH9b63wr0IzPtqKluNJm/1qugG4v BnJWC64BB8CHf2ba2s4TptIwI6iQwMJfSwf3DnVItz9dnyxFWW/OWs36mxbl8H64EAIp VgB8ucvCLpXEzFOhj82A0vOC2yX6Lp0sv1fyD7E8HSiUUKRJXzLzRTzQqucO2gdgslO0 hKuw== Received: by 10.236.151.99 with SMTP id a63mr5193972yhk.120.1354383276630; Sat, 01 Dec 2012 09:34:36 -0800 (PST) Received: from [192.168.1.211] (190-20-35-136.baf.movistar.cl. [190.20.35.136]) by mx.google.com with ESMTPS id g2sm8279482yhj.9.2012.12.01.09.34.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2012 09:34:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Sat, 1 Dec 2012 14:34:26 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <31DD8CE6-5C32-45DA-A188-5E2D7FC7974C@ve7jtb.com> References: <27AB907B-7B70-4931-BCEC-6ADCC966601B@josephholsten.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQke6G23ZfOAze/L330ihm+gsqKyT37Qij9k2ZoxnhaBID6zJ+2u5JZt4xM9UdPNm5veG1LU Cc: webfinger@googlegroups.com, "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] I'm calling this sans-tls bluff X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 17:34:37 -0000 Saying we want WF servers to be static resources and serve up two = different versions of the document depending on if it is https: or not = is possible but a likely interoperability nightmare. That leaves it up to each WF publisher to decide where each link = relation can go. =20 I prefer all TLS or no TLS at least that is clear to everyone what to = expect. John B. On 2012-11-30, at 4:12 PM, Paul Hoffman wrote: > On Nov 30, 2012, at 10:49 AM, Nico Williams = wrote: >=20 >> Er, why not: >>=20 >> - if you use TLS you can get the whole resource >> - if you don't use TLS you get a reduced resource (e.g., minus any >> security-relevant content) >>=20 >> Or, alternatively, and better, if the client didn't use TLS, then the >> client MUST NOT trust any security-relevant content, and the client >> really must not trust any of the content. Lack of trust !=3D = useless. >> The old finger protocol was never secure, yet it was useful.... >=20 > +1 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From tbray@textuality.com Sat Dec 1 09:55:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0D021F8CE5 for ; Sat, 1 Dec 2012 09:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hid7mDUolyXG for ; Sat, 1 Dec 2012 09:55:30 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFE9521F8CE4 for ; Sat, 1 Dec 2012 09:55:29 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1674943oag.31 for ; Sat, 01 Dec 2012 09:55:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=JRQ/AacuN3mXuK1knUVavYCgeDyQqSvL7xpG5c8Hu3Q=; b=oKLrg0nIZ0/QvT55u9X7G0M5Hmn+kDlYelSYJ6Hhr1dRvrET5H2GBNJHU51dWhmuAx OJd0nimvLf2xT4s6fGVqfMXhRryzAUK7vj7Moo8refMvyW4Bjj2KX+uOf/8WAX2gm8dn 6p2fGW+tTNS+Te3Jqa/7RjqFgS/JqM2TlIp1lfhKaZtzUwOgsQy1dY/CRVCm/H/kFSGk X/Q8SLNALb6lR1iwnzJ/UVhSyHK0mL+L83BUIPZnbL0IUt2ujSXVFYUnJkS4XSqS+W0V lIy/6/8fH6+aPKvB9QKiITMAszvezTtdUZdgGuPnKI4M8+6+xzTk0YB0uoq2BNsmYzPy /kLw== MIME-Version: 1.0 Received: by 10.60.1.164 with SMTP id 4mr4285964oen.47.1354384529124; Sat, 01 Dec 2012 09:55:29 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sat, 1 Dec 2012 09:55:28 -0800 (PST) X-Originating-IP: [74.198.150.212] Received: by 10.76.12.134 with HTTP; Sat, 1 Dec 2012 09:55:28 -0800 (PST) In-Reply-To: <50BA1756.70808@status.net> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> Date: Sat, 1 Dec 2012 09:55:28 -0800 Message-ID: From: Tim Bray To: Evan Prodromou Content-Type: multipart/alternative; boundary=e89a8fb1ffe2bf6eb604cfce38ec X-Gm-Message-State: ALoCoQkY9LgUN06muGYgVM+J7oiJy/mRx/j0PVUo5wsEQFz5QpXTr8PmaMFUa1BVpUPSKalb/ZyJ Cc: webfinger@googlegroups.com, Apps Discuss Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 17:55:30 -0000 --e89a8fb1ffe2bf6eb604cfce38ec Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I normally agree with Evan on most things, but not here. It is perfectly OK and unsurprising for an Internet protocol to impose behavioral constraints on software. Otherwise you could never specify MustUnderstand. -T On Dec 1, 2012 6:42 AM, "Evan Prodromou" wrote: > I think I've already given this proposal my -1. > > It doesn't belong in this spec, which isn't about libraries or their APIs= . > If someone wants to define an IDL model for Webfinger libraries in some > other document, best wishes. > > This document should be about the interface between clients and servers, > not the interface between client libraries and their calling applications= . > > -Evan > > On 12-11-30 06:09 PM, Tim Bray wrote: > > On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros > wrote: > > > You're right on target. In fact, I have made both proposals here: > > > > 1. Mandatory TLS > > 2. Mandatory-to-implement configuration for no-HTTP fallback. > > Essentially in this case the inputs to a WF client are an email > > address and a boolean to say whether fallback is allowed. May not be > > pleasant to write in a spec... > > OK, let's make this concrete, I don=92t think it=92s that unpleasant to s= pec > out: > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > In draft-ietf-appsawg-webfinger-06 > > - Remove the second paragraph of Section 5.1, which begins =93Clients MUS= T > first attempt a query... > > Introduce a new section 5.2 and bump up the other sections, as follows > > 5.2 Use of HTTPS > > WebFinger client software MUST accept as input a boolean parameter which > for the purposes of this discussion will be referred as "allow-fallback". > > WebFinger client software MUST attempt to retrieve /.well-known/webfinger > using the HTTPS protocol. If an HTTPS connection is made, and the server > has an invalid certificate, or returns an HTTP status code indicating an > error, the client software MUST report an error and cease attempting to > retrieve the resource. > > If the WebFinger client software is unable to establish an HTTPS > connection to the server, behavior depends on the value of the > allow-fallback parameter. If the value of allow-fallback is true, the > client software MAY fall back to unencrypted HTTP in an attempt to retrie= ve > /.well-known/webfinger. If allow-fallback is false, client software MUST > report an error and cease attempting to retrieve the resource. > > > > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailma= n/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --e89a8fb1ffe2bf6eb604cfce38ec Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I normally agree with Evan on most things, but not here. It = is perfectly OK and unsurprising for an Internet protocol to impose behavio= ral constraints on software. Otherwise you could never specify MustUndersta= nd. -T

On Dec 1, 2012 6:42 AM, "Evan Prodromou&quo= t; <evan@status.net> wrote:
=20 =20 =20
I think I've already given this proposal my -1.

It doesn't belong in this spec, which isn't about libraries o= r their APIs. If someone wants to define an IDL model for Webfinger libraries in some other document, best wishes.

This document should be about the interface between clients and servers, not the interface between client libraries and their calling applications.

-Evan

On 12-11-30 06:09 PM, Tim Bray wrote:
On Fri, Nov 30, 2012 at 2:28 PM, Breno de Med= eiros <breno@googl= e.com> wrote:

> You're right on target. In fact, I have made both proposals here:
>
> 1. Mandatory TLS
> 2. Mandatory-to-implement configuration for no-HTTP fallback. > Essentially in this case the inputs to a WF client are an email
> address and a boolean to say whether fallback is allowed. May not be
> pleasant to write in a spec...

OK, let's make this concrete, I don=92t think it=92s that unpleas= ant to spec out:
<<<<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<&l= t;<<<<<<<<<<<<<<<<

In draft-ietf-appsawg-webfinger-06

- Remove the second paragraph of Section 5.1, which begins =93Clients MUST first attempt a query...

Introduce a new section 5.2 and bump up the other sections, as follows

5.2 Use of HTTPS

WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback".

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol.=A0 If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter.=A0 If the value of allow-fallback is true, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger.=A0 If allow-fallback is false, client software MUST report an error and cease attempting to retrieve the resource.



_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8fb1ffe2bf6eb604cfce38ec-- From tbray@textuality.com Sat Dec 1 09:56:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B68821F867F for ; Sat, 1 Dec 2012 09:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 811DYpXISQOZ for ; Sat, 1 Dec 2012 09:56:23 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE59821F84D1 for ; Sat, 1 Dec 2012 09:56:21 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so1446529obc.31 for ; Sat, 01 Dec 2012 09:56:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KNcqyUuXaSHwnYeSU//vf8+RWKrxjoeDuOjcQyQLgJQ=; b=Ah7fdpN3SOFEGeIAlI5Eqt3B6scwdoJ7pi+/xlTpxjPAjeKYjSwCIDGf0/oS6pIupQ sdvzW0F7/qGyFFwXtvONtdY20EHAg32WXGiB1w2Se5vASt2TT1FJgnC/AM2Wg7N2ehUv Y3VBXmxHsFzrJhk7vej0zSvM05+HGZfB/mV6Rfso633coLxy0D3yoYbMooFcXC1pKFsP PWjeagUEk+kBfiBbWTeL+rDtGdvmzGefQyAHgA03fHqWIFQqsqsP3CTaBc/+vNhmMvLQ uioMm+36nabt1oOucbWVqmEGV3B+e0bcSiNAoSazxlTCvhpjrIvjHXvJi6HHxsHr4UNB /t1A== MIME-Version: 1.0 Received: by 10.60.1.164 with SMTP id 4mr4287321oen.47.1354384581444; Sat, 01 Dec 2012 09:56:21 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sat, 1 Dec 2012 09:56:21 -0800 (PST) X-Originating-IP: [74.198.150.212] Received: by 10.76.12.134 with HTTP; Sat, 1 Dec 2012 09:56:21 -0800 (PST) In-Reply-To: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> Date: Sat, 1 Dec 2012 09:56:21 -0800 Message-ID: From: Tim Bray To: Evan Prodromou Content-Type: multipart/alternative; boundary=e89a8fb1ffe2ddc44204cfce3bb2 X-Gm-Message-State: ALoCoQkCiI1NJR6X0GbDcmtJbk6Xt6Cd+8aly0qBWJ+SA8V/kEUWcfRDpHdZBow25n7ENHT1ovmE Cc: webfinger@googlegroups.com, Apps Discuss Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 17:56:24 -0000 --e89a8fb1ffe2ddc44204cfce3bb2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Er once again I mean MustIgnore. On Dec 1, 2012 9:55 AM, "Tim Bray" wrote: > I normally agree with Evan on most things, but not here. It is perfectly > OK and unsurprising for an Internet protocol to impose behavioral > constraints on software. Otherwise you could never specify MustUnderstand= . > -T > On Dec 1, 2012 6:42 AM, "Evan Prodromou" wrote: > >> I think I've already given this proposal my -1. >> >> It doesn't belong in this spec, which isn't about libraries or their >> APIs. If someone wants to define an IDL model for Webfinger libraries in >> some other document, best wishes. >> >> This document should be about the interface between clients and servers, >> not the interface between client libraries and their calling application= s. >> >> -Evan >> >> On 12-11-30 06:09 PM, Tim Bray wrote: >> >> On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros >> wrote: >> >> > You're right on target. In fact, I have made both proposals here: >> > >> > 1. Mandatory TLS >> > 2. Mandatory-to-implement configuration for no-HTTP fallback. >> > Essentially in this case the inputs to a WF client are an email >> > address and a boolean to say whether fallback is allowed. May not be >> > pleasant to write in a spec... >> >> OK, let's make this concrete, I don=92t think it=92s that unpleasant to = spec >> out: >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> >> In draft-ietf-appsawg-webfinger-06 >> >> - Remove the second paragraph of Section 5.1, which begins =93Clients MU= ST >> first attempt a query... >> >> Introduce a new section 5.2 and bump up the other sections, as follows >> >> 5.2 Use of HTTPS >> >> WebFinger client software MUST accept as input a boolean parameter which >> for the purposes of this discussion will be referred as "allow-fallback"= . >> >> WebFinger client software MUST attempt to retrieve /.well-known/webfinge= r >> using the HTTPS protocol. If an HTTPS connection is made, and the serve= r >> has an invalid certificate, or returns an HTTP status code indicating an >> error, the client software MUST report an error and cease attempting to >> retrieve the resource. >> >> If the WebFinger client software is unable to establish an HTTPS >> connection to the server, behavior depends on the value of the >> allow-fallback parameter. If the value of allow-fallback is true, the >> client software MAY fall back to unencrypted HTTP in an attempt to retri= eve >> /.well-known/webfinger. If allow-fallback is false, client software MUS= T >> report an error and cease attempting to retrieve the resource. >> >> >> >> _______________________________________________ >> apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailm= an/listinfo/apps-discuss >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> --e89a8fb1ffe2ddc44204cfce3bb2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Er once again I mean MustIgnore.

On Dec 1, 2012 9:55 AM, "Tim Bray" <= ;tbray@textuality.com> wrote= :

I normally agree with Evan on most things, but not here. It = is perfectly OK and unsurprising for an Internet protocol to impose behavio= ral constraints on software. Otherwise you could never specify MustUndersta= nd. -T

On Dec 1, 2012 6:42 AM, "Evan Prodromou&quo= t; <evan@status.net= > wrote:
=20 =20 =20
I think I've already given this proposal my -1.

It doesn't belong in this spec, which isn't about libraries o= r their APIs. If someone wants to define an IDL model for Webfinger libraries in some other document, best wishes.

This document should be about the interface between clients and servers, not the interface between client libraries and their calling applications.

-Evan

On 12-11-30 06:09 PM, Tim Bray wrote:
On Fri, Nov 30, 2012 at 2:28 PM, Breno de Med= eiros <breno@googl= e.com> wrote:

> You're right on target. In fact, I have made both proposals here:
>
> 1. Mandatory TLS
> 2. Mandatory-to-implement configuration for no-HTTP fallback. > Essentially in this case the inputs to a WF client are an email
> address and a boolean to say whether fallback is allowed. May not be
> pleasant to write in a spec...

OK, let's make this concrete, I don=92t think it=92s that unpleas= ant to spec out:
<<<<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<&l= t;<<<<<<<<<<<<<<<<

In draft-ietf-appsawg-webfinger-06

- Remove the second paragraph of Section 5.1, which begins =93Clients MUST first attempt a query...

Introduce a new section 5.2 and bump up the other sections, as follows

5.2 Use of HTTPS

WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback".

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol.=A0 If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter.=A0 If the value of allow-fallback is true, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger.=A0 If allow-fallback is false, client software MUST report an error and cease attempting to retrieve the resource.



_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8fb1ffe2ddc44204cfce3bb2-- From tbray@textuality.com Sat Dec 1 10:07:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C00D11E80A3 for ; Sat, 1 Dec 2012 10:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZXoYLTsBrpc for ; Sat, 1 Dec 2012 10:07:01 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 460B211E8099 for ; Sat, 1 Dec 2012 10:07:01 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1680645oag.31 for ; Sat, 01 Dec 2012 10:07:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=oJrR3VtVlPpvpqlgbpl0u6BuNfOEGkRdI52kwhTgjyk=; b=LpXpSf+le7TZl0sBF1KXrUksAPKPaIK52AMGPHR4AzyY7XgnJdFegOoBhy3sfLe+5+ 4wL7IEi2R1kJ4C7s/pYiBcsZNL52JiawbI9ThkO/9T/OH9LdPdD3gQ6dG/fggtYsXV5m r5tPdfK7ResAzN49pruNGwjv8rY2avlavc8G6G/wJeBfJxKEtBW2BnP8Wy1ZAqIq4FpR Od9cy/sHUjcam0C56KXO9vWO+nfpoPxy4eoNnyNsyME7/r+SxBfLHBPMq7SGBZxJnJ0o NynlUTMaMmjLo3D/G2b5fqIpykqrtft1/J7789V1GtUNRQW+BuZVla5Om1S++0qZQPAp YUTA== MIME-Version: 1.0 Received: by 10.60.5.231 with SMTP id v7mr4384761oev.62.1354385220800; Sat, 01 Dec 2012 10:07:00 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sat, 1 Dec 2012 10:07:00 -0800 (PST) X-Originating-IP: [74.198.150.212] Received: by 10.76.12.134 with HTTP; Sat, 1 Dec 2012 10:07:00 -0800 (PST) In-Reply-To: <081143FA-4576-4E80-81EE-A8A1E2C3420C@ve7jtb.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <081143FA-4576-4E80-81EE-A8A1E2C3420C@ve7jtb.com> Date: Sat, 1 Dec 2012 10:07:00 -0800 Message-ID: From: Tim Bray To: John Bradley Content-Type: multipart/alternative; boundary=e89a8ff25350f991a504cfce6163 X-Gm-Message-State: ALoCoQk00/S2u+OhdDUDrgl8QOpzBsPcrQ3O5IO6XQSpJWygDIfqeF9suLCBK5Ve5f1lHW+9VdiJ Cc: "apps-discuss@ietf.org Discuss" , webfinger@googlegroups.com, Joseph A Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 18:07:02 -0000 --e89a8ff25350f991a504cfce6163 Content-Type: text/plain; charset=ISO-8859-1 My overriding goal is that we leave open the possibility of using WF in OIDC. Given what the security people have said, that means either https-only or a fallback parameter. I'm with a rough consensus in favor of either. If I were wearing a WG chair hat, I'd be trying some consensus calls PDQ. On Dec 1, 2012 9:25 AM, "John Bradley" wrote: > Jeff's RFC on strict transport is good but mostly targeted at the threat > of cookie disclosure if a user clicks through on a TLS warning. > > We could require WF clients to support it, however if the first > interaction is to the hijacked site the Client never sees the strict header > and would fall back. > > I don't think this solves the issue. > > I am uncharacteristically agreeing with Brad on this. I prefer https: > only as it stops lots of interoperability issues, and is simpler for > clients to implement than a fall back sometimes under some circumstances > for some things. Caching will also need to be considered in the client > library you can't cache the http version and later serve it up to a secure > only request it, needs to treat them as separate resources. It is not > simple. > > If we need to support both the protocol needs to be https: only unless it > receives an explicit request from the app level to allow fallback. > In the end that winds up being https: only with extra complexity that is > not required but I could live with it if I have to. > > John B. > > > On 2012-11-30, at 8:59 PM, Blaine Cook wrote: > > http://tools.ietf.org/html/rfc6797 > > > On 30 November 2012 16:36, Nico Williams wrote: > >> I think the right thing to do is to leave WF signing for later and >> rely on TLS for integrity protection where it's needed. I doubt we're >> prepared to start doing JWE signatures here, right now. >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --e89a8ff25350f991a504cfce6163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

My overriding goal is that we leave open the possibility of = using WF in OIDC. Given what the security people have said, that means eith= er https-only or a fallback parameter.=A0 I'm with a rough consensus in= favor of either.

If I were wearing a WG chair hat, I'd be trying some con= sensus calls PDQ.

On Dec 1, 2012 9:25 AM, "John Bradley"= <ve7jtb@ve7jtb.com> wrote:<= br type=3D"attribution">
Jeff's RFC on strict transport is g= ood but mostly targeted at the threat of cookie disclosure if a user clicks= through on a TLS warning.

We could require WF clients t= o support it, however if the first interaction is to the hijacked site the = Client never sees the strict header and would fall back.

I don't think this solves the issue.

=
I am uncharacteristically agreeing with Brad on this. =A0I prefe= r https: only as it stops lots of interoperability issues, and is simpler f= or clients to implement than a fall back sometimes under some circumstances= for some things. =A0Caching will also need to be considered in the client = library you can't cache the http version and later serve it up to a sec= ure only request it, needs to treat them as separate resources. =A0 It is n= ot simple.

If we need to support both the protocol needs to be htt= ps: only unless it receives an explicit request from the app level to allow= fallback. =A0=A0
In the end that winds up being https: only with= extra complexity that is not required but I could live with it if I have t= o.

John B.


On 2012-= 11-30, at 8:59 PM, Blaine Cook <romeda@gmail.com> wrote:

http://too= ls.ietf.org/html/rfc6797


On 30 November 2012 16:36, Nico Williams <nico@cryp= tonector.com> wrote:
I think the right thing to do is to leave WF= signing for later and
rely on TLS for integrity protection where it's needed. =A0I doubt we&#= 39;re
prepared to start doing JWE signatures here, right now.
_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



____________________________________= ___________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8ff25350f991a504cfce6163-- From nico@cryptonector.com Sat Dec 1 10:53:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AC121E803F for ; Sat, 1 Dec 2012 10:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGtx8YFGly52 for ; Sat, 1 Dec 2012 10:53:49 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9165121E8039 for ; Sat, 1 Dec 2012 10:53:49 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 0A8EF438072 for ; Sat, 1 Dec 2012 10:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8HPJgSDboGywxleXdfiD dUnS5g4=; b=GKjHhR/B7ePB/QMnwi67PVMeAGrDJihjfRG2Bd4IbBS1OZDmWy0f hSv0aG4/nKbMQ/HqtLfQxAMjuVbGajcLrkdjXwpE4HI7hg4UNzUBJ/8jVEPNBdNo TttaVeONNnIeJ81xLFCmuKlIDmLGgE61y++XCKXGiFQs7Cx1Wdp55yU= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id A868243806C for ; Sat, 1 Dec 2012 10:53:48 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so591312wey.31 for ; Sat, 01 Dec 2012 10:53:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.227.197 with SMTP id d47mr447371weq.83.1354388027293; Sat, 01 Dec 2012 10:53:47 -0800 (PST) Received: by 10.216.192.207 with HTTP; Sat, 1 Dec 2012 10:53:46 -0800 (PST) In-Reply-To: <50BA1756.70808@status.net> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> Date: Sat, 1 Dec 2012 12:53:46 -0600 Message-ID: From: Nico Williams To: Evan Prodromou Content-Type: text/plain; charset=UTF-8 Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 18:53:50 -0000 On Sat, Dec 1, 2012 at 8:42 AM, Evan Prodromou wrote: > I think I've already given this proposal my -1. > > It doesn't belong in this spec, which isn't about libraries or their APIs. > If someone wants to define an IDL model for Webfinger libraries in some > other document, best wishes. > > This document should be about the interface between clients and servers, not > the interface between client libraries and their calling applications. We don't just describe bits on the wire. We describe behavior as well. And that means at least a modicum of recommendations and/or requirements for APIs. BTW, another thing we need to require is an output (from the client API) indicating whether TLS was used or not. Nico -- From william_john_mills@yahoo.com Sat Dec 1 16:24:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C9F21E80CE for ; Sat, 1 Dec 2012 16:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HqMkKx7iGWP for ; Sat, 1 Dec 2012 16:24:33 -0800 (PST) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) by ietfa.amsl.com (Postfix) with ESMTP id E026221E80B7 for ; Sat, 1 Dec 2012 16:24:32 -0800 (PST) Received: from [98.139.212.149] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2012 00:24:23 -0000 Received: from [98.139.212.216] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2012 00:24:23 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 02 Dec 2012 00:24:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 97660.99328.bm@omp1025.mail.bf1.yahoo.com Received: (qmail 64739 invoked by uid 60001); 2 Dec 2012 00:24:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354407861; bh=sKgs/saORrGb4CcikUADXgkCr+LGUf2BUOSeRfpeShI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WQNdluNZzB1UwEHKD+csEGaaM6JsIArrzuKabuSR5tgGavjxMXt3tSRtKOU5YxTI+wBKJjad0eP/vBq/L3ODPthhcD5f+4Ea/XYf5rRGvvy+MOablqOQT0yxtLR6NKPXsZBO3nc4mkj4A3oII/aQU+Jqs+9Q9f0N2zaRiJN+i9Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=koFwoWcNLGIomoHuH/GyIC7P7eiCrEddUpX3j/8R8mwUEQhhD9QW4cV9l2ui/ZZ1XOi0Bxg8zGXgrKaxocW/5ih1QMuVc+Fq5WYYwHsZWRxPY+lB+UrVPc10pHXW9GvXhPsIJgIlsNwYOYcNuvyCIZzQlAPZx1bDTD9hyFGhrbw=; X-YMail-OSG: Z0zW074VM1mgyWjH_ZVATLPEje9_B3EyA9wQEsZF83XWlXt RNdVKL2dkXS2tHk8UPwteJ6BSA.oT.W4l_ZTHHtjYHZilqZti6AHOcG6DLmZ Kou5jB.9Yh95TQCkrfSgMoRKVkR.QElbzvGy81Z1xY3PIYBa7r9.VOWCHFzZ kwzmgPSplrYe1qsx9Ow7SYqQ.bYYqFPJbrp_Efu2EBptnbSFkZzEa1UqW8Ci SMO4OKXOzxZGZXGkaFlc0SlGy1dprI7cgH_2E4pAF.FS0u9tBIPtIb_eQ5cK P.Qu7lCVf_b3XC2nmS.ZrZq_lFO0SwmdJaL90cnfekDc9c44QGZ02BHhHtBg zpCNOcfZZo_FLlPCvsWOyWDtxfv7ZeRZ1Qiju_tIUQxHKPC2XrisNhhJCSga 96o0fxvOMeuj80B4EAwuYeP44YduRUuQEhZc_drq9s2ZDlG2sgCVMMP93Qx1 aLfxBkqGgJ1LS5l_q7zxSkhZRHZHjSbE6a8s- Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Sat, 01 Dec 2012 16:24:21 PST X-Rocket-MIMEInfo: 001.001, QW5vdGhlciBwb3NzaWJpbGl0eSBpcyB0byBkZWZpbmUgMiBlbmRwb2ludHM7ICJ3ZWJmaW5nZXIiIGZvciBnZW5lcmFsIHVzZSwgYW5kICJ0bHNmaW5nZXIiIHdoaWNoIE1VU1QgYmUgVExTIChvciBvdGhlciBzZWN1cmVkIG1ldGhvZCkgb25seS4KCgoKCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IE5pY28gV2lsbGlhbXMgPG5pY29AY3J5cHRvbmVjdG9yLmNvbT4KPlRvOiBFdmFuIFByb2Ryb21vdSA8ZXZhbkBzdGF0dXMubmV0PiAKPkNjOiAid2ViZmluZ2VyQGdvb2dsZWdyb3UBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.129.483 References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> Message-ID: <1354407861.71942.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Sat, 1 Dec 2012 16:24:21 -0800 (PST) From: William Mills To: Nico Williams , Evan Prodromou In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-1437967558-1354407861=:71942" Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org Discuss" Subject: [apps-discuss] Options... Re: HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 00:24:34 -0000 ---551393103-1437967558-1354407861=:71942 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Another possibility is to define 2 endpoints; "webfinger" for general use, = and "tlsfinger" which MUST be TLS (or other secured method) only.=0A=0A=0A= =0A=0A>________________________________=0A> From: Nico Williams =0A>To: Evan Prodromou =0A>Cc: "webfinger@goo= glegroups.com" ; "apps-discuss@ietf.org Discuss= " =0A>Sent: Saturday, December 1, 2012 10:53 AM=0A>= Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP=0A> =0A>On Sat, De= c 1, 2012 at 8:42 AM, Evan Prodromou wrote:=0A>> I think = I've already given this proposal my -1.=0A>>=0A>> It doesn't belong in this= spec, which isn't about libraries or their APIs.=0A>> If someone wants to = define an IDL model for Webfinger libraries in some=0A>> other document, be= st wishes.=0A>>=0A>> This document should be about the interface between cl= ients and servers, not=0A>> the interface between client libraries and thei= r calling applications.=0A>=0A>We don't just describe bits on the wire.=A0 = We describe behavior as=0A>well.=A0 And that means at least a modicum of re= commendations and/or=0A>requirements for APIs.=0A>=0A>BTW, another thing we= need to require is an output (from the client=0A>API) indicating whether T= LS was used or not.=0A>=0A>Nico=0A>--=0A>__________________________________= _____________=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=0A>http= s://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A> ---551393103-1437967558-1354407861=:71942 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Another possibility is to define 2 endpoints; "webfinger" for general use= , and "tlsfinger" which MUST be TLS (or other secured method) only.

<= hr size=3D"1"> From: Nico = Williams <nico@cryptonector.com>
To: Evan Prodromou <evan@status.net>
Cc: "webfinger@googlegroups.com" <webfinger@googlegroups.com>; "apps-discuss@ietf.org Discuss" <ap= ps-discuss@ietf.org>
Sent: Saturday, December 1, 2012 10:53 AM
Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-= HTTP

On Sat, Dec 1, 2012 at 8:42 AM, Evan Prodromou = <e= van@status.net> wrote:
> I think I've already given this propo= sal my -1.
>
> It doesn't belong in this spec, which isn't abou= t libraries or their APIs.
> If someone wants to define an IDL model = for Webfinger libraries in some
> other document, best wishes.
>= ;
> This document should be about the interface between clients and s= ervers, not
> the interface between client libraries and their callin= g applications.

We don't just describe bits on the wire.  We describe behavior as
well.  And that means at least a modicum of r= ecommendations and/or
requirements for APIs.

BTW, another thing w= e need to require is an output (from the client
API) indicating whether = TLS was used or not.

Nico
--
_________________________________= ______________
apps-discuss mailing list
apps-discuss@ietf.org=
https://www.ietf.org/mailman/listinfo/apps-discuss

---551393103-1437967558-1354407861=:71942-- From paulej@packetizer.com Sat Dec 1 19:59:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE0A21F8C57 for ; Sat, 1 Dec 2012 19:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qMomzeuWhE2 for ; Sat, 1 Dec 2012 19:59:13 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 266B521F8C54 for ; Sat, 1 Dec 2012 19:59:13 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB23x8pc004073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Dec 2012 22:59:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354420749; bh=NnFwWKhYjE4PiLzrwrHPmdSblK5fCh4iTP+jbjcrOug=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=SCcVs9UhgrCIrxBAAUgkYQtH8N2KwxUj0S/LWJXFBP0uEG03JpY7+thkGwWefCgcZ AsmfPio9arU/nrfTY7UAqID7uAKUxz3/b8RqxZtw3ABX6T/4DmXHr6LeXFvH3Bwsgu 0soZ4vYF1qktLyMtZj6DUBiPVy/xWf87J0CzB9XQ= From: "Paul E. Jones" To: "'Barry Leiba'" , References: In-Reply-To: Date: Sat, 1 Dec 2012 22:59:05 -0500 Message-ID: <073001cdd041$5fe02870$1fa07950$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ4bIbVoOYnjs9LNp6E5RjJeKrO15avqNuw Content-Language: en-us Subject: Re: [apps-discuss] webfinger mailing list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 03:59:14 -0000 No objection, though I also do hope we are nearing the end. As I see it, there are only two talking points: 1. HTTPS only or not 2. Document format Once we settle on those, I hope the list traffic slows. And I do think it's unfortunate how much traffic was generate on this list. On the other hand, it's good to see a lot of traffic generated, as it means there is interest. I hope. :-) Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Friday, November 30, 2012 6:33 PM > To: apps-discuss@ietf.org > Subject: [apps-discuss] webfinger mailing list > > As I see the extensive discussion about webfinger, and note how long > it's been going on (as we discussed in the AppsAWG session in Atlanta), > I regret that we didn't create a separate working group for webfinger. > I'm willing to entertain strong suggestions that we do so, but I think > we're near enough to the end at this point that it isn't worth that. > > But I think it *is* worth it to separate the discussion onto a non-WG > mailing list of its own. I'd like to hear, very soon, any objections to > the creation of for that discussion. Of course, > other comments than objections are also welcome, but lacking serious > reasons not to, I plan to request such a mailing list by the end of next > week. > > Barry, Applications AD > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From paulej@packetizer.com Sat Dec 1 20:02:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D4D21F89CF for ; Sat, 1 Dec 2012 20:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ku0h-O38zhh for ; Sat, 1 Dec 2012 20:02:23 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 59F9B21F8858 for ; Sat, 1 Dec 2012 20:02:23 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB242JHt004470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Dec 2012 23:02:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354420940; bh=lOlIl/qXnk4Y/x7qporNPRmJmtrhzTI6AV6eeIf4Koc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=hyyYZGUrztKr8R0tmgot+HquIXlGTSspujwqbQV99fyVDOoPEIZm/feqOxu9YTH22 e/4/5TVhsNUnaWrYMGvtCGsM0MS28AYAQypH9kDZ2eY/KgR4R1wxzAAGG/joZ7i/XY 8P3ysk4YMIpycMJd0OvHocnOePvTtay8Y7hAQzV0= From: "Paul E. Jones" To: "'Blaine Cook'" , "'Nico Williams'" References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> In-Reply-To: Date: Sat, 1 Dec 2012 23:02:16 -0500 Message-ID: <073201cdd041$d2050b50$760f21f0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0733_01CDD017.E92F9F90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLrZ2Se+xCQ1wKSSFBTHovI4rJ73wIvNloxAedIuXAA9cPVgQKCxNrpAaoig/sCH1k1jwGrYWq2AipsKXMChR/lCwF99wDGAxHsnkIB0G8+1AJOdXLAAQVCTGcCX/geEwII4dHFAn8MzHMB8gSSPgHxhin6AVzZKoYCBaPwPwGVV2QRAmu4yDqUXQBoUA== Content-Language: en-us Cc: apps-discuss@ietf.org, 'WebFinger List' , 'Joseph Holsten' Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 04:02:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0733_01CDD017.E92F9F90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is still a glaring hole in that spec where a client unfamiliar = with a given domain does not know that the domain wants to use HTTPS or = not. A possible solution to that is querying the site=E2=80=99s = webfinger resource to see if it returns the = =E2=80=9CStrict-Transport-Security=E2=80=9D header in the reply :-) =20 Paul =20 =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook Sent: Friday, November 30, 2012 6:59 PM To: Nico Williams Cc: Joseph Holsten; WebFinger List; apps-discuss@ietf.org Discuss Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP =20 http://tools.ietf.org/html/rfc6797 =20 On 30 November 2012 16:36, Nico Williams wrote: I think the right thing to do is to leave WF signing for later and rely on TLS for integrity protection where it's needed. I doubt we're prepared to start doing JWE signatures here, right now. _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 ------=_NextPart_000_0733_01CDD017.E92F9F90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

There is still a glaring hole in that spec where a client unfamiliar = with a given domain does not know that the domain wants to use HTTPS or = not.=C2=A0 A possible solution to that is querying the site=E2=80=99s = webfinger resource to see if it returns the = =E2=80=9CStrict-Transport-Security=E2=80=9D header in the reply = :-)

 

Paul

 

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Blaine Cook
Sent: Friday, November 30, = 2012 6:59 PM
To: Nico Williams
Cc: Joseph Holsten; = WebFinger List; apps-discuss@ietf.org Discuss
Subject: Re: = [apps-discuss] HTTPS-only vs = HTTPS-and-HTTP

 

http://tools.ietf.org/html/rf= c6797

 

On 30 November 2012 16:36, Nico Williams <nico@cryptonector.com> wrote:

I think the right thing to do is to leave WF signing = for later and
rely on TLS for integrity protection where it's needed. =  I doubt we're
prepared to start doing JWE signatures here, = right now.

_______________________________________________
apps= -discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_0733_01CDD017.E92F9F90-- From ve7jtb@ve7jtb.com Sat Dec 1 20:16:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317A31F0C59 for ; Sat, 1 Dec 2012 20:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKJ1U-M8onk3 for ; Sat, 1 Dec 2012 20:16:52 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E108C21F865C for ; Sat, 1 Dec 2012 20:16:28 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so534251qad.10 for ; Sat, 01 Dec 2012 20:16:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=5XAMMPTOVIlJD6qwcxDpYI6Fj+1oGtVA0x1K3xr+xcE=; b=Eoi3eVaQi2rtEuBw2jx77/hM0T/tbPv6uRmg0OKC9FDEuKlNrTOSBBrexgW2kRLzqw QBlz0Q+d2R+sEtUy5HesD5LU95npSWBMG78vmq7jN1+2vtTmP2rhtUVqpFXDfd0OwceB m25Upr1VFpYMIMIY2OfUxCu2Q670f+yRUjkMY6Xmg2YU9XQFZaANFhi/GEEC+0rvSMOH ie/C+zGIZnZ5gYie+CL3mO2R2bnu/uHZ/O30PllTY9BsF/hetLTSO89O/OP2WIk3D55B Pe/jPkdc5ccXqkfD/U8iXH8pkitWCzPYSNI37xLjT5NL88qwc6H4AhLWz0Cpe8DpyQ9l 3yww== Received: by 10.224.186.145 with SMTP id cs17mr10867731qab.91.1354421787903; Sat, 01 Dec 2012 20:16:27 -0800 (PST) Received: from [192.168.1.211] (190-20-35-136.baf.movistar.cl. [190.20.35.136]) by mx.google.com with ESMTPS id z5sm5986530qer.8.2012.12.01.20.16.20 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2012 20:16:27 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9E039576-78E6-479D-950E-14531EC5A1A0" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <073201cdd041$d2050b50$760f21f0$@packetizer.com> Date: Sun, 2 Dec 2012 01:16:11 -0300 Message-Id: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlxc+qo9nTntj8UNsHdAFu6jhV4wPmRT3WeoLKenIPDDxI7mlAhnYCbZpgA5LlOW6q8MPS1 Cc: apps-discuss@ietf.org, 'Joseph Holsten' Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 04:16:53 -0000 --Apple-Mail=_9E039576-78E6-479D-950E-14531EC5A1A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The query about the client wanting to use strict https: would only be = useful if it were over https. =20 It winds up a bit circular.=20 The main thing it is doing is not letting users click OK to certificate = errors in the browser after they have received the header.=20 So it works if you have already connected to the real site before the = DNS is hijacked. The header is still quite new so I wouldn't count on everything being = able to see or inspect it. John B. On 2012-12-02, at 1:02 AM, "Paul E. Jones" = wrote: > There is still a glaring hole in that spec where a client unfamiliar = with a given domain does not know that the domain wants to use HTTPS or = not. A possible solution to that is querying the site=92s webfinger = resource to see if it returns the =93Strict-Transport-Security=94 header = in the reply :-) > =20 > Paul > =20 > =20 > From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook > Sent: Friday, November 30, 2012 6:59 PM > To: Nico Williams > Cc: Joseph Holsten; WebFinger List; apps-discuss@ietf.org Discuss > Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP > =20 > http://tools.ietf.org/html/rfc6797 > =20 >=20 > On 30 November 2012 16:36, Nico Williams = wrote: > I think the right thing to do is to leave WF signing for later and > rely on TLS for integrity protection where it's needed. I doubt we're > prepared to start doing JWE signatures here, right now. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_9E039576-78E6-479D-950E-14531EC5A1A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The query about the client = wanting to use strict https: would only be useful if it were over https. =  

It winds up a bit = circular. 

The main thing it is doing is = not letting users click OK to certificate errors in the browser after = they have received the header. 
So it works if you have = already connected to the real site before the DNS is = hijacked.

The header is still quite new so I = wouldn't count on everything being able to see or inspect = it.

John = B.

On 2012-12-02, at 1:02 AM, "Paul = E. Jones" <paulej@packetizer.com> = wrote:

There is still a glaring = hole in that spec where a client unfamiliar with a given domain does not = know that the domain wants to use HTTPS or not.  A possible = solution to that is querying the site=92s webfinger resource to see if = it returns the =93Strict-Transport-Security=94 header in the reply = :-)
 
Paul
 
 
From: apps-discuss-bounces@ietf.or= g [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine = Cook
Sent: Friday, November 30, 2012 = 6:59 PM
To: Nico = Williams
Cc: Joseph Holsten; WebFinger = List; apps-discuss@ietf.org = Discuss
Subject: Re: [apps-discuss] = HTTPS-only vs HTTPS-and-HTTP
 
 

On 30 November 2012 16:36, Nico Williams <nico@cryptonector.com> = wrote:
I think the = right thing to do is to leave WF signing for later and
rely on TLS = for integrity protection where it's needed.  I doubt = we're
prepared to start doing JWE signatures here, right = now.
apps-discuss@ietf.org
Date: Sun, 02 Dec 2012 00:09:01 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 08:09:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-07.txt Pages : 20 Date : 2012-12-02 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Sun Dec 2 00:21:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190D621F8E0B for ; Sun, 2 Dec 2012 00:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7j1frfOc1Wa for ; Sun, 2 Dec 2012 00:21:56 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 180BF21F84ED for ; Sun, 2 Dec 2012 00:21:23 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB28LLJT027667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Dec 2012 03:21:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354436482; bh=qwvJnz0sv3IZ6iXlvdb2YkkLXPW+YSwXGcS06DRi5o0=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=OxrL9FGDhvuK4d8LlKipmvY3+InL4LSSzlpxUtI1ipoDFzDsB10KKsjS3zGKf6Htb Qtwo9BPgmccdasdTMIxWVicywOisuJglBqx04RAvr7L3ipF9cE5MqGAQ4pjOJ79XRi 05CXi7QCZJ0QNMTxiYSd5Y7dOo8VjUrnWBZ+0o8g= From: "Paul E. Jones" To: , Date: Sun, 2 Dec 2012 03:21:19 -0500 Message-ID: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0767_01CDD03C.18CFA910" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3QZG1exNIw0MR6TLCPTt0Yxn8skQ== Content-Language: en-us Subject: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 08:21:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0767_01CDD03C.18CFA910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul ------=_NextPart_000_0767_01CDD03C.18CFA910 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http:= //tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

<= p class=3DMsoNormal> 

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc.  It’s = a fairly simple format and I believe this text documents it = sufficiently.  Combined with the visual examples, I think this = makes it pretty clear.  Have a look at the JRD documentation in = section 5.2 and provide your comments.

 

With respect = to HTTPS, it seems there is strong preference for “HTTPS = only”, but some a fair bit of insistence for allowing HTTP.  = I changed the wording in 5.2 to try to capture opinions.  = Previously, the text led with a requirement to try HTTPS first.  = That is still there.  I just added some extra conditions that make = it clearer that there are some instances where a client must not utilize = HTTP.  This might need further refinement, but I think there is a = balance we can strike here between the two camps without introducing a = lot of complex language.

 

I made some = editorial changes through the document.

 

Comments are = welcome, as always.  Seems I don’t need to say that to this = group, though :-)

 

Paul

 

------=_NextPart_000_0767_01CDD03C.18CFA910-- From paulej@packetizer.com Sun Dec 2 00:30:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ACB21F8458 for ; Sun, 2 Dec 2012 00:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI2-vtsgeB1k for ; Sun, 2 Dec 2012 00:30:41 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADB321F8455 for ; Sun, 2 Dec 2012 00:30:41 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB28UaRX028142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Dec 2012 03:30:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354437037; bh=2Whf3VpjuHSA7abkjXU3YmvGt7b9qAL018Zjm7BPBW8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=o+o9pHhbTTllUKavHAsovM7YMedZe/Q9HkA9KK7JyiygOSFWT/9G9OQEPAhlhb5g8 KHkr50Ynqs/Z1w9/xc9Kvh2mEVf1ZXxnu/U94HQBlJL92UiUFTM/ET2m7e/edNtJAj 5GUM6f7JQruhsigelfz8rit8kTH22epqTPNP9KUs= From: "Paul E. Jones" To: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> In-Reply-To: Date: Sun, 2 Dec 2012 03:30:34 -0500 Message-ID: <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLrZ2Se+xCQ1wKSSFBTHovI4rJ73wIvNloxAedIuXAA9cPVgQKCxNrpAaoig/sCH1k1jwGrYWq2AipsKXMChR/lCwF99wDGAxHsnkIB0G8+1AJOdXLAAQVCTGcCX/geEwHyBJI+AfGGKfoBXNkqhgIFo/A/AZVXZBECa7jIOgJPc/d9AXtstykB3Uji3ZRUSI6w Content-Language: en-us Cc: apps-discuss@ietf.org, 'Joseph Holsten' Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 08:30:42 -0000 I think it comes down to "what are you going to do with the information?" If you have a web site that has a comments area and you just want to use WF to get a picture of the person posting comments so make it a little more "colorful", then HTTP is likely sufficient. However, if you blog requests users to log in using some mechanism that results in possibly passing user login credentials to a rogue site as a result of having the response message altered in flight, then HTTPS is mandatory. I would also expect HTTPS to be used when collecting server information for auto-provisioning email for the same reason. I would not want to pass my user credentials to a third-party site that uses plain text logins and steals my password. If your email client uses WF to grab a person's picture, vcard, or other information for use in your email program, then I'd say HTTP is probably just fine. In any case, the current document encourage use of HTTPS. But, it still allows for HTTP and I can see some valid cases for it. Paul > -----Original Message----- > From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On > Behalf Of Zellyn Hunter > Sent: Sunday, December 02, 2012 1:17 AM > To: webfinger@googlegroups.com > Cc: Blaine Cook; Nico Williams; Joseph Holsten; apps-discuss@ietf.org > Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP > > Would it be useful to enumerate specific cases where people feel HTTP > would be useful, so we can see whether the concern is justified? > > My first thoughts were: > - static sites like github pages, small sites hosted places like > bluehost, etc. > - locally served pages while debugging: setting up certificates might be > painful. > > However, > - I'm sure that with free certs offered now, it won't stay complicated > or unusual to upload certs for long > - I'm less certain about local debugging, although it seems like a one- > paragraph tutorial could easily cover generating testing certs and > signing for any given framework (eg. django, rails) and tool (eg. > curl, wget). > > Are there more pressing concerns about disallowing HTTP? Several of the > pro-HTTP comments have mentioned that everything in webfinger will point > to HTTP-only resources that are freely and un-encryptedly available. But > I imagine that it is precisely if webfinger is successful that more and > more important things will use it as a jumping-off point. I also have a > hard time discounting (a) the increasing trend towards HTTPS for web > traffic, and (b) the comments of people like Brad about wishing they'd > done HTTPS-only for other > protocols: it would be a shame to ignore that hard-won wisdom. > > Sorry if I'm adding to the noise: I'd just like to see some more > concrete arguments in favor of allowing HTTP. > > Zellyn > > > On Sat, Dec 1, 2012 at 8:16 PM, John Bradley wrote: > > The query about the client wanting to use strict https: would only be > > useful if it were over https. > > > > It winds up a bit circular. > > > > The main thing it is doing is not letting users click OK to > > certificate errors in the browser after they have received the header. > > So it works if you have already connected to the real site before the > > DNS is hijacked. > > > > The header is still quite new so I wouldn't count on everything being > > able to see or inspect it. > > > > John B. > > > > On 2012-12-02, at 1:02 AM, "Paul E. Jones" > wrote: > > > > There is still a glaring hole in that spec where a client unfamiliar > > with a given domain does not know that the domain wants to use HTTPS > > or not. A possible solution to that is querying the site's webfinger > > resource to see if it returns the "Strict-Transport-Security" header > > in the reply :-) > > > > Paul > > > > > > From: apps-discuss-bounces@ietf.org > > [mailto:apps-discuss-bounces@ietf.org] > > On Behalf Of Blaine Cook > > Sent: Friday, November 30, 2012 6:59 PM > > To: Nico Williams > > Cc: Joseph Holsten; WebFinger List; apps-discuss@ietf.org Discuss > > Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP > > > > http://tools.ietf.org/html/rfc6797 > > > > > > > > On 30 November 2012 16:36, Nico Williams wrote: > > I think the right thing to do is to leave WF signing for later and > > rely on TLS for integrity protection where it's needed. I doubt we're > > prepared to start doing JWE signatures here, right now. > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > From Michael.Jones@microsoft.com Sun Dec 2 01:08:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3869B21F87C9 for ; Sun, 2 Dec 2012 01:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PqfJpw-6D+E for ; Sun, 2 Dec 2012 01:08:05 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 657FC21F87C8 for ; Sun, 2 Dec 2012 01:08:05 -0800 (PST) Received: from mail205-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Sun, 2 Dec 2012 09:08:01 +0000 Received: from mail205-va3 (localhost [127.0.0.1]) by mail205-va3-R.bigfish.com (Postfix) with ESMTP id CAD61360271; Sun, 2 Dec 2012 09:08:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zzbb2dI9371Ic85ehzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh18c673hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail205-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail205-va3 (localhost.localdomain [127.0.0.1]) by mail205-va3 (MessageSwitch) id 135443927992961_28773; Sun, 2 Dec 2012 09:07:59 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.240]) by mail205-va3.bigfish.com (Postfix) with ESMTP id 0AD75DC00AE; Sun, 2 Dec 2012 09:07:59 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 2 Dec 2012 09:07:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Sun, 2 Dec 2012 09:07:57 +0000 From: Mike Jones To: "Paul E. Jones" , "apps-discuss@ietf.org" , "webfinger@googlegroups.com" Thread-Topic: [apps-discuss] draft-ietf-appsawg-webfinger-07 Thread-Index: Ac3QZG1exNIw0MR6TLCPTt0Yxn8skQACBetx Date: Sun, 2 Dec 2012 09:07:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436690EB13@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> In-Reply-To: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436690EB13TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 09:08:06 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436690EB13TK5EX14MBXC283r_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You're fast! :-) ________________________________ From: Paul E. Jones Sent: 12/2/2012 12:22 AM To: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: [apps-discuss] draft-ietf-appsawg-webfinger-07 Folks, I published another version of the WebFinger spec trying to bring closure t= o the two open issues I see (resource representation and transport). The n= ew version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document. There are no external references to RFC = 6415 now, no need to go read the XRD spec, etc. It=92s a fairly simple for= mat and I believe this text documents it sufficiently. Combined with the v= isual examples, I think this makes it pretty clear. Have a look at the JRD= documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for =93HTTPS onl= y=94, but some a fair bit of insistence for allowing HTTP. I changed the w= ording in 5.2 to try to capture opinions. Previously, the text led with a = requirement to try HTTPS first. That is still there. I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP. This might need further refinement, but I thi= nk there is a balance we can strike here between the two camps without intr= oducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don=92t need to say that to this = group, though :-) Paul --_000_4E1F6AAD24975D4BA5B16804296739436690EB13TK5EX14MBXC283r_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
You're fast! = :-)

From: Paul E= . Jones
Sent: 12/2/2= 012 12:22 AM
To: apps-d= iscuss@ietf.org; webfinger@googlegroups.com
Subject: [apps-= discuss] draft-ietf-appsawg-webfinger-07

Folks,

 

I published another version of the WebFinger spec tr= ying to bring closure to the two open issues I see (resource representation= and transport).  The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-= 07

 

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.  There are no= external references to RFC 6415 now, no need to go read the XRD spec, etc.=  It=92s a fairly simple format and I believe this text documents it sufficiently.  Combined with the visual exampl= es, I think this makes it pretty clear.  Have a look at the JRD docume= ntation in section 5.2 and provide your comments.

 

With respect to HTTPS, it seems there is strong pref= erence for =93HTTPS only=94, but some a fair bit of insistence for allowing= HTTP.  I changed the wording in 5.2 to try to capture opinions. = Previously, the text led with a requirement to try HTTPS first.  That is still there.  I just added some extra = conditions that make it clearer that there are some instances where a clien= t must not utilize HTTP.  This might need further refinement, but I th= ink there is a balance we can strike here between the two camps without introducing a lot of complex language.

 

I made some editorial changes through the document.<= /p>

 

Comments are welcome, as always.  Seems I don= =92t need to say that to this group, though :-)

 

Paul

 

--_000_4E1F6AAD24975D4BA5B16804296739436690EB13TK5EX14MBXC283r_-- From lhotka@nic.cz Sun Dec 2 01:09:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B941321F8D50 for ; Sun, 2 Dec 2012 01:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMOMHzcTRqXy for ; Sun, 2 Dec 2012 01:09:45 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B700921F87CD for ; Sun, 2 Dec 2012 01:09:44 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0761F13F87E; Sun, 2 Dec 2012 10:09:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354439382; bh=0M3NJ4NU0VQE1ilnJOJi45GS4DSTQcjej7DU5M2JJUQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ErGSDeZHZ3O4Dcv9CUYaDZAylTsivLWMQnqfeuJzadpuduGukBk8LvBjN4p5TxzmA H4LQ2sTiWsUcaQ795eTGl4yZ6gL0W7M+DHvzJMDikyFpI505xzjLeXiWw3QCTTde6/ M6+jYldUg8GXSetdcULrQNfwnV9cuRPI5FmaewO4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 2 Dec 2012 10:09:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <26263E0AC2BA16FFBE9930DE@caldav.corp.apple.com> To: Nico Williams X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Describing JSON document formats X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 09:09:45 -0000 On Nov 30, 2012, at 7:45 PM, Nico Williams = wrote: > On Fri, Nov 30, 2012 at 11:13 AM, Phillip Hallam-Baker = wrote: >> I think it would be very useful to have a mechanism that allowed JSON >> formats to be mapped onto data structures and back. >=20 > Agreed. >=20 >> I think that a mechanism that looked anything like XML Schema with = the >> maximum and minimum values for integers or with regular expressions = and such >> should be left at the door. >=20 > Well, type constraints are a good thing. If you know that some number > will be 0..2^32 - 1 then you can use a uint32_t in a C implementation > -- at least you'll want to distinguish between integer sizes, bignums, > and so on. Yeah, you don't need min/max to convey integer size. >=20 > The key is that the JSON syntax/schema/whatever map easily onto your > implementation language, and given the programming languages we all > typically deal with (from C to Python, JS, Ruby) I think we need > something ASN.1-ish, just not ASN.1 itself, and very light-weight. >=20 > But, really, something ASN.1-ish, minus the awful syntax, minus the > tags, and all that. We might call it JASN, say (heh). All we need is > to be able to specify messages as being arrays or dicts, and if arrays > of what type (including "any"), and if dicts what keys are allowed, > which are required, which are optional, and their value types, and > whether unknown keys are allowed. Even if that's too much info, the > default should be that everything is optional, value types are "any", > and let your implementation impose any actual constraints however you > like. And if you have a protocol that could really use constraints in > the schema, use them. In my opinion, YANG [RFC 6020] should satisfy most of the requirements - = and it can also be extended if necessary. YANG can be used for modelling = JSON text via [draft-lhotka-netmod-yang-json-00]. Paradoxically, YANG is = probably a better fit for JSON than for XML. The example in the cited I-D, sec. 3.4 [*], shows a sample of YANG = features and how they are mapped to JSON. Lada [*] = http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-00#section-3.4 =20 >=20 >> I also think that there is no need to use JSON syntax for the purpose = of >> defining the data structures. >=20 > But since you can parse it you can easily turn it into what you like: >=20 > { 'type' : 'struct', 'name' : 'Account', 'fields' : [ [ 'Username', > 'String' ], [ 'Realm', 'String' ], [ 'Created', 'DateTime' ] ] } >=20 > Done right it can be made real easy to add implementation-specific > directives ("represent this number as uint32_t, that one as uint64_t, > this dict as a struct, that dict as a hash table, ..."). To me this > is important: the lack of a decent way to add implementation > directives to ASN.1 is one of the many problems with ASN.1. >=20 >> Good: >>=20 >> Structure Account >> String Username >> String Realm >> DateTime Created >>=20 >>=20 >> Bad: >>=20 >> Structure Widget >> Integer Height { min=3D1, max=3D142} >> Integer Width {min=3D1, max=3D23} >=20 > If you don't care about the constraints, don't implement them, no? > And if nobody cares, for some protocol, then don't declare them. >=20 >> Schema validation is bunk. >=20 > Oh, well, if you've got complex config file languages then you kinda > want schema validation as it becomes a configuration linter. I'm > bored of writing config file parsers, validators, ... >=20 > Nico > -- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mmn@hethane.se Sun Dec 2 06:47:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E92C21F8794 for ; Sun, 2 Dec 2012 06:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gueUbk3mZd-J for ; Sun, 2 Dec 2012 06:47:43 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id A901C21F8834 for ; Sun, 2 Dec 2012 06:47:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 02 Dec 2012 15:47:31 +0100 From: Mikael Nordfeldth To: In-Reply-To: <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> References: "\" <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com>" <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com>" " <073201cdd041$d2050b50$760f21f0$@packetizer.com>" <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> Message-ID: X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 14:47:49 -0000 02.12.2012 09:30 skrev Paul E. Jones: > In any case, the current document encourage use of HTTPS. But, it > still > allows for HTTP and I can see some valid cases for it. I simply haven't written in this discussion because it took some time to catch up with all the activity. But I think Paul is very right here. The context is that there _are_ cases where HTTP is ok. When I first joined this discussion the main topic was that "XML would be too hard for newbies" and that XRD support would cripple adoption. If one _requires_ a user to get, configure and setup an SSL certificate, regardless of easiness through web hotels, I think it would be a much larger obstacle. Also, to really get my personal point through regarding HTTP/HTTPS, I wish to remind everyone reading this discussion that HTTPS does _not_ mean secure. There remains big security loop-holes due to things like non-secure DNS requests, huge reliance upon on small number of certificate authorities and of course relaxed default configurations in https libraries. So. Having mandatory HTTPS would in practice not secure the majority of Webfinger use. If one's specific application is very sensitive regarding 100% verifiable data, the only option is to gather out-of-band data to compare. Which works just as well for HTTP. I don't mean to pour further gasoline in the fire, so if anyone wishes to comment or correct me on this post they can do it privately. I think most relevant cases for Webfinger are already discussed on this list. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From melvincarvalho@gmail.com Sun Dec 2 06:57:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B3321F8476 for ; Sun, 2 Dec 2012 06:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umAHsSptzxOa for ; Sun, 2 Dec 2012 06:57:39 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 982B921F8546 for ; Sun, 2 Dec 2012 06:57:39 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so3133108ieb.31 for ; Sun, 02 Dec 2012 06:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M6wRYVsvuthKmTRzU5mpTBhisob82rCWf8kjNf8Ccug=; b=Ax9eEiLd6dFsSWEjuD6QPokRZ28xcWKm5kR0LX2sCMAh+gbZHUmVLdmfe0eS0r00hD pwi+zjhJ/jj5jxgMTS18/auWMegluFEFJKMkrN9qci/7t6P172ajCmWUoJwWjEp+b/aV XpWPu+aLaaiABk+y9RlRbn5kM/T2phBWl3sFnm5863xGncvXu5qLjiTOedl8O8FRD9Rv xtX1JMbB7VykrsT21ipNWDjGwY/tURugz0ZlzBgKxM4Ztb14+1QG4hzDM5l0v3mbXbUV gsx8YZKGGnURSPqR5aDDdqBivRXuQdVXE4gLGI+GRBSvrMymrvETgq8JQ7akfMIsIFXG pFaw== MIME-Version: 1.0 Received: by 10.50.16.172 with SMTP id h12mr3854100igd.41.1354460259109; Sun, 02 Dec 2012 06:57:39 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sun, 2 Dec 2012 06:57:38 -0800 (PST) In-Reply-To: <073201cdd041$d2050b50$760f21f0$@packetizer.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> Date: Sun, 2 Dec 2012 15:57:38 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04428c6e9b4c7304cfdfda47 Cc: apps-discuss@ietf.org, Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 14:57:44 -0000 --f46d04428c6e9b4c7304cfdfda47 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2 December 2012 05:02, Paul E. Jones wrote: > There is still a glaring hole in that spec where a client unfamiliar with > a given domain does not know that the domain wants to use HTTPS or not. = A > possible solution to that is querying the site=92s webfinger resource to = see > if it returns the =93Strict-Transport-Security=94 header in the reply :-) > Agree this is a hole and mandating https would seem to fix it. Tho the added constraint may alienate some adopters. At this point it's probably getting more urgent to ship something that is usable, rather than the making webfinger the perfect all-purpose discovery system for the web (which it can never be anyway, as linked data has sewn that up already). So I suggest going with whatever can achieve consensus fastest. > **** > > ** ** > > Paul**** > > ** ** > > ** ** > > *From:* apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] *On Behalf Of *Blaine Cook > *Sent:* Friday, November 30, 2012 6:59 PM > *To:* Nico Williams > *Cc:* Joseph Holsten; WebFinger List; apps-discuss@ietf.org Discuss > > *Subject:* Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP**** > > ** ** > > http://tools.ietf.org/html/rfc6797**** > > ** ** > > On 30 November 2012 16:36, Nico Williams wrote:**= * > * > > I think the right thing to do is to leave WF signing for later and > rely on TLS for integrity protection where it's needed. I doubt we're > prepared to start doing JWE signatures here, right now.**** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > ** ** > --f46d04428c6e9b4c7304cfdfda47 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 2 December 2012 05:02, Paul E. Jones = <paulej@packetizer.com> wrote:

There is still a glaring hole in that spec w= here a client unfamiliar with a given domain does not know that the domain = wants to use HTTPS or not.=A0 A possible solution to that is querying the s= ite=92s webfinger resource to see if it returns the =93Strict-Transport-Sec= urity=94 header in the reply :-)


Agree this is a hole and mandating https = would seem to fix it.=A0 Tho the added constraint may alienate some adopter= s.=A0

At this point it's probably getting more urgent to ship s= omething that is usable, rather than the making webfinger the perfect all-p= urpose discovery system for the web (which it can never be anyway, as linke= d data has sewn that up already).=A0 So I suggest going with whatever can a= chieve consensus fastest.
=A0

<= /u>

=A0<= /p>

Paul

=A0<= /p>

=A0

From:= apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] <= b>On Behalf Of Blaine Cook
Sent: Friday, November 30, 2012 6:59 PM
To: Nico Williams<= br>Cc: Joseph Holsten; WebFinger List; apps-discuss@ietf.org Discuss

<= div class=3D"im">
Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP<= u>

=A0

=

http://tools.ietf.org/html/rfc6797

=A0

On 30 November 2012= 16:36, Nico Williams <nico@cryptonector.com> wrote:

I think the right thing to do is to leave WF signing= for later and
rely on TLS for integrity protection where it's neede= d. =A0I doubt we're
prepared to start doing JWE signatures here, rig= ht now.

__________________________________________= _____
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.o= rg/mailman/listinfo/apps-discuss

=A0

<= /div>

--f46d04428c6e9b4c7304cfdfda47-- From dick.hardt@gmail.com Sun Dec 2 07:00:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B693E21F8488 for ; Sun, 2 Dec 2012 07:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcUFtgkcgmtq for ; Sun, 2 Dec 2012 07:00:12 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E556C21F847F for ; Sun, 2 Dec 2012 07:00:11 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1341777pbc.31 for ; Sun, 02 Dec 2012 07:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=VG6DOa+vFwiQ4dx3f8f9XKEv9YATCbRyKthWiHMQ5js=; b=LRmz0mktZ/53+kbSVhDtE72NbVhS2MoPUxS27helBoFtX7r43P9UbytLYTnyBYJcFG o5if1Dneq6F6Ko3O4Y7vYppTq6lNS6fgUZ5v1L6fWnj3eJG8OSvYqfP1f574z6QDoBht UTI9utyCMxKIdY/mxVu2PQnqGfw0EILSeK0u+CSa2unk3Bw4v0dDnhiSc20qIWc+IBBs 8D8drHp/8U31TbrQIQbfdZk83WkC1vKNFGrJBI5CbW6b0WKxPfkZ03WKlCutR5lEHUvp sMl9zQ+QKl5RuJitFG4lCNsbr5KdsPOIuXY2BzYhyy8XX7N+1E3PkQK0unaOEbeio7Cm P12Q== Received: by 10.66.85.67 with SMTP id f3mr18717884paz.0.1354460411707; Sun, 02 Dec 2012 07:00:11 -0800 (PST) Received: from [192.168.3.101] (airnode1222.air-internet.com. [12.110.33.210]) by mx.google.com with ESMTPS id m4sm6402558pax.16.2012.12.02.07.00.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 07:00:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> Date: Sun, 2 Dec 2012 07:00:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org, 'Joseph Holsten' Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 15:00:17 -0000 On Dec 2, 2012, at 12:30 AM, "Paul E. Jones" = wrote: > In any case, the current document encourage use of HTTPS. But, it = still > allows for HTTP and I can see some valid cases for it. What are the avid use cases?=20 Keep in mind we are adding complexity to clients by allowing both, so = there is a real cost to allowing both. I'm not clear what we are losing = by HTTPS-only -- Dick= From superuser@gmail.com Sun Dec 2 07:55:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2444221F8428 for ; Sun, 2 Dec 2012 07:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCRCFDH2NIt3 for ; Sun, 2 Dec 2012 07:55:27 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 519EF21F8422 for ; Sun, 2 Dec 2012 07:55:27 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1634096lah.31 for ; Sun, 02 Dec 2012 07:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3nZech/TD564cXrvqsKpWaUlg8vGBfHbEJWzbXaT2yE=; b=fyZtryhvvBIt4P6GQzPNCruHhFie0gQ1i6eyWA4eWLjQcSQ3yWdicYryw611GdZc8K dC4Ppkrwk6L0GX5cPhlMFYSXRdaX8+7XCLIY3EEEKPYT3FxIrj3GAzX2E3aiqaj49pDH J6TS11ssjS+L9GFVLmPrGg+18Hb+4zqufLrD+SkqR5HITKnAo1xlrV9EXPwQhW4JL8e6 T4E+i+ny6VwXvy6j+kbzBDqmW8WpL4Zh99KSkI7QYaEQ9nVN/2A4JjwoZgPYKhwQ7Y+Y 2goipU7n/UdNDEIGzUj2jinM2/4/BHBd/dBHhzC7v2ELVlCFgCtxpB/WLYy7Bo2AvJmv Psuw== MIME-Version: 1.0 Received: by 10.112.42.233 with SMTP id r9mr3058538lbl.76.1354463726160; Sun, 02 Dec 2012 07:55:26 -0800 (PST) Received: by 10.112.61.67 with HTTP; Sun, 2 Dec 2012 07:55:26 -0800 (PST) In-Reply-To: References: Date: Sun, 2 Dec 2012 07:55:26 -0800 Message-ID: From: "Murray S. Kucherawy" To: Applications Area Directors Content-Type: multipart/alternative; boundary=90e6ba10a7df424da804cfe0a9d3 Cc: Apps Discuss Subject: Re: [apps-discuss] Notes from Applications Area chairs lunch meeting at IETF 85 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 15:55:28 -0000 --90e6ba10a7df424da804cfe0a9d3 Content-Type: text/plain; charset=ISO-8859-1 Is the proposed new PROTO writeup posted to a wiki or a page someplace? I've got two PROTOs I just did for APPSAWG using the current template, having forgotten we were asked to try the new one. -MSK On Fri, Nov 30, 2012 at 3:40 PM, Applications Area Directors < app-ads@tools.ietf.org> wrote: > At IETF 85 in Atlanta, the Applications Area chairs and ADs had a > lunch meeting. Attached are the ADs' notes from that meeting, which > we will also get into the meeting proceedings. > > Barry and Pete > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --90e6ba10a7df424da804cfe0a9d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is the proposed new PROTO writeup posted to a wiki or a page someplace?=A0 = I've got two PROTOs I just did for APPSAWG using the current template, = having forgotten we were asked to try the new one.

-MSK


On Fri, Nov 30, 2012 at 3:40 PM, Applica= tions Area Directors <app-ads@tools.ietf.org> wrote:
At IETF 85 in Atlanta, the Applications Area chairs and ADs had a
lunch meeting. =A0Attached are the ADs' notes from that meeting, which<= br> we will also get into the meeting proceedings.

Barry and Pete

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--90e6ba10a7df424da804cfe0a9d3-- From bradfitz@google.com Sat Dec 1 10:14:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D293A21E8091 for ; Sat, 1 Dec 2012 10:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.896 X-Spam-Level: X-Spam-Status: No, score=-102.896 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8d0vRYLwflp for ; Sat, 1 Dec 2012 10:14:11 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA83721E803A for ; Sat, 1 Dec 2012 10:14:11 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so1455165obc.31 for ; Sat, 01 Dec 2012 10:14:07 -0800 (PST) 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=u+h4ZLbG0ZBLXV++muG6ppr5VPAC+27YtrpSseVZv/E=; b=TzscPbLcASdcjMzlFWHHKAgXaufmK9/raFj+e/NNNqivhoa3tvGqcEjvg+NDjrYV+k 5iZ403itW/6eabs3El67yT3btMFOVWYtDrID2X+DSaDfd58eDhcsKwIfBQ3Vp4GTA/uQ kkQ0aXhY7wASA55P0erGs1EqO3BJWg0iGW5YdEqXL5g/GFDjOXiId90nJzTchF+9VLMG ODcmYYTkamCHOAx20iVNzLN7TT4sc9iTq4B361OV3pPIURGPEvckV42sva/pglZCOISM vRJpZyfxpTF1JPQbeWw6+kxs7zx+2GlknGropznn8gF6hO8MrJZgXRwrP37uomKoD+UG PBMg== X-Google-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:x-gm-message-state; bh=u+h4ZLbG0ZBLXV++muG6ppr5VPAC+27YtrpSseVZv/E=; b=XZgW3pOmxGgCmuNE69uInK1CoRWdS6vqjJR3lCZFa0IVewsPKQQrlRlFv/mD/rJlYp UJXJyO2YV6EcoPFEVq4CTaxEq1xei9PZz68ZC9Bn9ssKb1BcCPmcsxBCPhRDxlSsLOBj B1ooHf4L6tuT/xgn5S7W3VKgWZ/mNe2SYS2r9SzF6m33nMfvrX2hCiqzgI2M2HwgmP9R ByE1e9069AHe14ye+/2ImKnGXLDwkeSR4tDo8B3+vJww23gUi5d+iVcywvQfi25g+hET AQGL00B317XqRATZTt5fxxUMYnTwMF8cXTzj7x4f4tQL1fRUykV6eqQsixa8m39FeLQw r2Gw== MIME-Version: 1.0 Received: by 10.60.171.175 with SMTP id av15mr4323217oec.75.1354385647771; Sat, 01 Dec 2012 10:14:07 -0800 (PST) Received: by 10.76.22.44 with HTTP; Sat, 1 Dec 2012 10:14:07 -0800 (PST) In-Reply-To: <50BA1756.70808@status.net> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> Date: Sat, 1 Dec 2012 10:14:07 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec54d43ea6ca06604cfce7ba8 X-Gm-Message-State: ALoCoQn+tkkx6un/x1u3KhZI4+XMlE8g3gA7iMdCZ0A4rG30Qbq+cxiNHmg5+NE0Vp49riLCsU3bQpLud4ugEXDB97vhX7lY9haMLeZpCCn3n/e3TLFRDliLhtoPApJx8ZyUliHJ/mCDiGFHLpX1WZSrE/+m1EpTlCwIhTprDrMRqjIHVuuLPM9Wh/5Sb7rFTzvMPs4fV8Wx X-Mailman-Approved-At: Sun, 02 Dec 2012 08:41:00 -0800 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 18:14:12 -0000 --bcaec54d43ea6ca06604cfce7ba8 Content-Type: text/plain; charset=UTF-8 On Sat, Dec 1, 2012 at 6:42 AM, Evan Prodromou wrote: > I think I've already given this proposal my -1. > > It doesn't belong in this spec, which isn't about libraries or their APIs. > If someone wants to define an IDL model for Webfinger libraries in some > other document, best wishes. > > This document should be about the interface between clients and servers, > not the interface between client libraries and their calling applications. > Security is an end-to-end thing, though. You can mandate that seat belts are installed in cars, but you save many more lives by legislating that people actually wear them. You seem to be in the "why should anybody be allowed to tell me I have to wear a motorcycle helmet?" camp, but I think a lot of people on this list are looking for more safety. Is your objection against HTTPS that it would be too difficult for status.net users? (or actually, I'm not sure of your position on this, so I don't mean to put words in your mouth....) --bcaec54d43ea6ca06604cfce7ba8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Sat, Dec 1, 2012 at 6:42 AM, Evan Prod= romou <evan@status.net> wrote:
=20 =20 =20
I think I've already given this proposal my -1.

It doesn't belong in this spec, which isn't about libraries o= r their APIs. If someone wants to define an IDL model for Webfinger libraries in some other document, best wishes.

This document should be about the interface between clients and servers, not the interface between client libraries and their calling applications.

Sec= urity is an end-to-end thing, though.

You can mand= ate that seat belts are installed in cars, but you save many more lives by = legislating that people actually wear them.

You seem to be in the "why should anybody be allow= ed to tell me I have to wear a motorcycle helmet?" camp, but I think a= lot of people on this list are looking for more safety.

Is your objection against HTTPS that it would be too difficult f= or status.net users? =C2=A0(or actually, = I'm not sure of your position on this, so I don't mean to put words= in your mouth....)
--bcaec54d43ea6ca06604cfce7ba8-- From zellyn@gmail.com Sat Dec 1 22:16:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FBD21F8F7C for ; Sat, 1 Dec 2012 22:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBSdHi3F6YNX for ; Sat, 1 Dec 2012 22:16:53 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8876C21F8F74 for ; Sat, 1 Dec 2012 22:16:52 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so476799wib.13 for ; Sat, 01 Dec 2012 22:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PX6Ngxh1zI81ARhCn1z5i6kEqjurGP08dIv2n8KYwOw=; b=aRXMgP1w1C4PA6PMKItFeASfxJALfsLm2rrnaSd/Jra5Fdw9nYo2mrmR3k1Uf7Zbf1 r/lwNdD+qHvNbWDLCCjVzS4Ee62xR07ZBig97jq2nzOnqx3xTCWxwpdMKyaHSdVYLsld ikIbFOwPmqVU2iJtEDhfPF0aVg9rqcYtoexj1vzCWaN8fOfZKYa/4G5JY6SQjkTqzpLl BO5H8j79fXto7BGbjKNGBOwe+aAkubcNyH1JjJHx3f+OHaK0/DEfA+NFdfMg+HBBbu9L Cd3EVrI3x/ZFLBDX4pNw7cHQa8DIkXvCtnd8X0BfjOhwZNmxOq11byzZKK4LEkO99/T7 Qqjw== MIME-Version: 1.0 Received: by 10.180.14.2 with SMTP id l2mr4299226wic.2.1354429011524; Sat, 01 Dec 2012 22:16:51 -0800 (PST) Received: by 10.194.156.227 with HTTP; Sat, 1 Dec 2012 22:16:51 -0800 (PST) In-Reply-To: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> Date: Sat, 1 Dec 2012 22:16:51 -0800 Message-ID: From: Zellyn Hunter To: webfinger@googlegroups.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 02 Dec 2012 08:41:17 -0800 Cc: "apps-discuss@ietf.org" , Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 06:16:54 -0000 Would it be useful to enumerate specific cases where people feel HTTP would be useful, so we can see whether the concern is justified? My first thoughts were: - static sites like github pages, small sites hosted places like bluehost, = etc. - locally served pages while debugging: setting up certificates might be painful. However, - I'm sure that with free certs offered now, it won't stay complicated or unusual to upload certs for long - I'm less certain about local debugging, although it seems like a one-paragraph tutorial could easily cover generating testing certs and signing for any given framework (eg. django, rails) and tool (eg. curl, wget). Are there more pressing concerns about disallowing HTTP? Several of the pro-HTTP comments have mentioned that everything in webfinger will point to HTTP-only resources that are freely and un-encryptedly available. But I imagine that it is precisely if webfinger is successful that more and more important things will use it as a jumping-off point. I also have a hard time discounting (a) the increasing trend towards HTTPS for web traffic, and (b) the comments of people like Brad about wishing they'd done HTTPS-only for other protocols: it would be a shame to ignore that hard-won wisdom. Sorry if I'm adding to the noise: I'd just like to see some more concrete arguments in favor of allowing HTTP. Zellyn On Sat, Dec 1, 2012 at 8:16 PM, John Bradley wrote: > The query about the client wanting to use strict https: would only be use= ful > if it were over https. > > It winds up a bit circular. > > The main thing it is doing is not letting users click OK to certificate > errors in the browser after they have received the header. > So it works if you have already connected to the real site before the DNS= is > hijacked. > > The header is still quite new so I wouldn't count on everything being abl= e > to see or inspect it. > > John B. > > On 2012-12-02, at 1:02 AM, "Paul E. Jones" wrote: > > There is still a glaring hole in that spec where a client unfamiliar with= a > given domain does not know that the domain wants to use HTTPS or not. A > possible solution to that is querying the site=92s webfinger resource to = see > if it returns the =93Strict-Transport-Security=94 header in the reply :-) > > Paul > > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > On Behalf Of Blaine Cook > Sent: Friday, November 30, 2012 6:59 PM > To: Nico Williams > Cc: Joseph Holsten; WebFinger List; apps-discuss@ietf.org Discuss > Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP > > http://tools.ietf.org/html/rfc6797 > > > > On 30 November 2012 16:36, Nico Williams wrote: > I think the right thing to do is to leave WF signing for later and > rely on TLS for integrity protection where it's needed. I doubt we're > prepared to start doing JWE signatures here, right now. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From barryleiba@gmail.com Sun Dec 2 11:20:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1C521F8574 for ; Sun, 2 Dec 2012 11:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzojtOvW0GQU for ; Sun, 2 Dec 2012 11:20:19 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8044421F843F for ; Sun, 2 Dec 2012 11:20:19 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1116573vbb.31 for ; Sun, 02 Dec 2012 11:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8r5qIdQnElIUyiKYE5D9+8wTolS+AaBo31JWXvFLdVs=; b=KG0HFptdvBN56LFqGe5QSeiuygMD/ZfB8DHmxCAWtP23h14Ho4sq+6oqjkzrrt8tmO UqfZdurga56mKjhMqn8uWWshNc9BSdjbmoP78Uv01d6Y6v9s7Q6DymwLhViM0kxY1tJx opKLwc6xscOYgL1B+DGZaIZb7AEmx9CsaoTwXwJS+T56p0fq59yPh7B/c/UkHPVDcNNb ML/YIV1hs29e3CfFiDuA9TDDiiDo9KXKTF67rF/iR2HvD3vP61l4mcKl/xGkC8O2DwB5 Uzp1zPGVF8Y/+Yufm6YX9Chs4tasAr6RHQHdhJaeN2jeqZ5Fu2sQJ0DLvzDY/w0fq80L Rung== MIME-Version: 1.0 Received: by 10.52.69.201 with SMTP id g9mr5785942vdu.98.1354476019096; Sun, 02 Dec 2012 11:20:19 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Sun, 2 Dec 2012 11:20:18 -0800 (PST) In-Reply-To: References: Date: Sun, 2 Dec 2012 14:20:18 -0500 X-Google-Sender-Auth: xXaSluqWLG4nrhgsmizxw6E9nmU Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] Notes from Applications Area chairs lunch meeting at IETF 85 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 19:20:20 -0000 > Is the proposed new PROTO writeup posted to a wiki or a page someplace? > I've got two PROTOs I just did for APPSAWG using the current template, > having forgotten we were asked to try the new one. The link was in the version I sent to the chairs on Friday of IETF week, but I didn't think it needed to be sent to apps-discuss nor posted to the meeting materials. It's here: http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate Barry From tbray@textuality.com Sun Dec 2 11:53:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D9321F87AD for ; Sun, 2 Dec 2012 11:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaU2+xmL9by8 for ; Sun, 2 Dec 2012 11:53:49 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E13021F87AE for ; Sun, 2 Dec 2012 11:53:49 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2257152oag.31 for ; Sun, 02 Dec 2012 11:53:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=NnnHD9f+EbBPS9YMDTN1Ru1qb1WLV5WUDS+y/puzs8Q=; b=UiHh1FYVpvHnRt5hvMc64xbxZ6i5TbBqnVV8gMKI/4fIJSCOQNwigQD7rLTxWAiDth k5C4BiF6jytMgYzSVS6yjfRWhNuPuizmEQhtj3u0Qke6EIW8IGAbNP+JHE2WizCOUYzi 7+PF0fuc1TkJyLrM7YLPJI3l/w6sEyNs6EdYYI1jWBvjT64tAGVZBAn5k88h2IC/98Uu GbHz65jxy2VCMG0UYAPInsui2j8SNBO3Cy8i6gg5jhbOxJNeBGiLpwpNxfr3DDBf45mQ gdrlbzb2dfbj7cBcTZbC+KyB9L/L6qKBfbmIRi9W6266jFQiT5LXLWdhUN9o0qwEZuqw 5wvw== MIME-Version: 1.0 Received: by 10.182.177.72 with SMTP id co8mr2686675obc.53.1354478028973; Sun, 02 Dec 2012 11:53:48 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 11:53:48 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> Date: Sun, 2 Dec 2012 11:53:48 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f643104c5e60604cfe3fd17 X-Gm-Message-State: ALoCoQlzrbx7BhW8glnrTjAZbqdxphSCKr7o2HUuLsTaZiwmrlZbmdMkkzH/ooUXNL0SCARxT+DA Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 19:53:50 -0000 --e89a8f643104c5e60604cfe3fd17 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks to Paul for the extra effort. I=92d like to suggest, in the interes= ts of courtesy and efficiency, that from here on on, contributions to this discussion be =93camera-ready=94, that is to say, specific suggestions in t= he style of a diff, including fully-written-out replacements language. -Tim On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > I published another version of the WebFinger spec trying to bring closure > to the two open issues I see (resource representation and transport). Th= e > new version is here:**** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** > > ** ** > > With respect to resource representation, I fully described the JSON > Resource Descriptor within the document. There are no external reference= s > to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly > simple format and I believe this text documents it sufficiently. Combine= d > with the visual examples, I think this makes it pretty clear. Have a loo= k > at the JRD documentation in section 5.2 and provide your comments. **** > > ** ** > > With respect to HTTPS, it seems there is strong preference for =93HTTPS > only=94, but some a fair bit of insistence for allowing HTTP. I changed = the > wording in 5.2 to try to capture opinions. Previously, the text led with= a > requirement to try HTTPS first. That is still there. I just added some > extra conditions that make it clearer that there are some instances where= a > client must not utilize HTTP. This might need further refinement, but I > think there is a balance we can strike here between the two camps without > introducing a lot of complex language.**** > > ** ** > > I made some editorial changes through the document.**** > > ** ** > > Comments are welcome, as always. Seems I don=92t need to say that to thi= s > group, though :-)**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --e89a8f643104c5e60604cfe3fd17 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks to Paul for the extra effort.=A0 I=92d like to suggest, in the inter= ests of courtesy and efficiency, that from here on on, contributions to thi= s discussion be =93camera-ready=94, that is to say, specific suggestions in= the style of a diff, including fully-written-out replacements language.
=A0-Tim

On Sun, Dec 2, 2012 at 12:21 = AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

I published another version of the WebFinger spec tryin= g to bring closure to the two open issues I see (resource representation an= d transport).=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=A0=

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=A0 There are no ex= ternal references to RFC 6415 now, no need to go read the XRD spec, etc. = =A0It=92s a fairly simple format and I believe this text documents it suffi= ciently.=A0 Combined with the visual examples, I think this makes it pretty= clear.=A0 Have a look at the JRD documentation in section 5.2 and provide = your comments.

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)

=A0

Paul

=A0


_______________= ________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--e89a8f643104c5e60604cfe3fd17-- From paulej@packetizer.com Sun Dec 2 12:59:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3B221F8846 for ; Sun, 2 Dec 2012 12:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0D64OWEBLN4k for ; Sun, 2 Dec 2012 12:59:12 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0597421F8845 for ; Sun, 2 Dec 2012 12:59:11 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB2KxAFS029984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Dec 2012 15:59:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354481950; bh=Jm3LQNRpS4j3vsJv2+X0n7lZP+RomhJ9ODLAjMUK1/Y=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=VvKGNmcV1U8qbmEzvrrf9Yj0mbhHm+GHho+9eNkCe5kam7ypnFMGL2v58E3QAkxnw Vi3+l9bHBRo76yhZ1A8xoJiUJsE4cq0spIz+nso6X9dLtdHROPgN7N3X4Xquhcj8FO RFTYLkT6V/nqZchbSl07Mzx6xv//tCFdMgLazhWg= From: "Paul E. Jones" To: "'Tim Bray'" References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> In-Reply-To: Date: Sun, 2 Dec 2012 15:59:08 -0500 Message-ID: <07e601cdd0cf$dfb4d3f0$9f1e7bd0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07E7_01CDD0A5.F6DFB650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEKh79DPBqdV8xMCCarbG6K9ejXOwIIZLRSmXxLVrA= Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 20:59:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07E7_01CDD0A5.F6DFB650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tim, I didn't mean to be rude by introducing these changes, just trying to move things along. Most changes were fairly trivial, not worth mentioning, and can be seen here: http://tools.ietf.org/rfcdiff?difftype=--hwdiff &url2=draft-ietf-appsawg-webfinger-07.txt The most significant changes were the re-write of section 5.2 and modification to the language related to HTTPS in 5.1. I suspect that is the text to which you refer as preferring it to be "camera-ready". (I would assume the balance of the changes would not need to be presented as "camera-ready", since they're minor editorial things.) In any case, the most important text changes I would like folks to consider is section 5.2 (which aims to fully document the JSON Resource Descriptor object) and paragraphs 2 and 3 in section 5.1. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, December 02, 2012 2:54 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 Thanks to Paul for the extra effort. I'd like to suggest, in the interests of courtesy and efficiency, that from here on on, contributions to this discussion be "camera-ready", that is to say, specific suggestions in the style of a diff, including fully-written-out replacements language. -Tim On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_07E7_01CDD0A5.F6DFB650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim,

 

I didn’t mean to be rude by introducing these changes, just = trying to move things along.  Most changes were fairly trivial, not = worth mentioning, and can be seen here:

http://tools.ietf.org/rfcdiff?difftype=3D= --hwdiff&url2=3Ddraft-ietf-appsawg-webfinger-07.txt

 

The most significant changes were the re-write of section 5.2 and = modification to the language related to HTTPS in 5.1.  I suspect = that is the text to which you refer as preferring it to be = “camera-ready”.  (I would assume the balance of the = changes would not need to be presented as “camera-ready”, = since they’re minor editorial things.)

 

In any case, the most important text changes I would like folks to = consider is section 5.2 (which aims to fully document the JSON Resource = Descriptor object) and paragraphs 2 and 3 in section = 5.1.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December = 02, 2012 2:54 PM
To: Paul E. Jones
Cc: = apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: = [apps-discuss] = draft-ietf-appsawg-webfinger-07

 

Thanks to Paul for the extra = effort.  I’d like to suggest, in the interests of courtesy = and efficiency, that from here on on, contributions to this discussion = be “camera-ready”, that is to say, specific suggestions in = the style of a diff, including fully-written-out replacements = language.

 -Tim

On = Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07

 <= /o:p>

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc.  It’s = a fairly simple format and I believe this text documents it = sufficiently.  Combined with the visual examples, I think this = makes it pretty clear.  Have a look at the JRD documentation in = section 5.2 and provide your comments.

 <= /o:p>

With = respect to HTTPS, it seems there is strong preference for “HTTPS = only”, but some a fair bit of insistence for allowing HTTP.  = I changed the wording in 5.2 to try to capture opinions.  = Previously, the text led with a requirement to try HTTPS first.  = That is still there.  I just added some extra conditions that make = it clearer that there are some instances where a client must not utilize = HTTP.  This might need further refinement, but I think there is a = balance we can strike here between the two camps without introducing a = lot of complex language.

 <= /o:p>

I made some = editorial changes through the document.

 <= /o:p>

Comments = are welcome, as always.  Seems I don’t need to say that to = this group, though :-)

 

Paul

 


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_07E7_01CDD0A5.F6DFB650-- From gsalguei@cisco.com Sun Dec 2 13:48:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046CA21F888C for ; Sun, 2 Dec 2012 13:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQyg4BXRl4w5 for ; Sun, 2 Dec 2012 13:48:58 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 39F3321F888B for ; Sun, 2 Dec 2012 13:48:58 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB2LmuTn023420 for ; Sun, 2 Dec 2012 16:48:56 -0500 (EST) Received: from rtp-gsalguei-89111.cisco.com (rtp-gsalguei-89111.cisco.com [10.116.132.60]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB2LmufL018181; Sun, 2 Dec 2012 16:48:56 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: Gonzalo Salgueiro In-Reply-To: Date: Sun, 2 Dec 2012 16:48:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <62D70F11-9D18-4391-95D9-4515D51B0E00@cisco.com> References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> To: webfinger@googlegroups.com, General discussion of application-layer protocols X-Mailer: Apple Mail (2.1283) Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 21:48:59 -0000 A huge +1 to that. We've been at this a looooong time and I think we = are to the point in this discussion (and the draft that represents it) = where actual text is much more valuable than high level opinions. Cheers, Gonzalo On Dec 2, 2012, at 2:53 PM, Tim Bray wrote: > Thanks to Paul for the extra effort. I=92d like to suggest, in the = interests of courtesy and efficiency, that from here on on, = contributions to this discussion be =93camera-ready=94, that is to say, = specific suggestions in the style of a diff, including fully-written-out = replacements language. >=20 > -Tim >=20 > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: > Folks, >=20 > =20 >=20 > I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: >=20 > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 >=20 > =20 >=20 > With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. It=92s = a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments. >=20 > =20 >=20 > With respect to HTTPS, it seems there is strong preference for =93HTTPS = only=94, but some a fair bit of insistence for allowing HTTP. I changed = the wording in 5.2 to try to capture opinions. Previously, the text led = with a requirement to try HTTPS first. That is still there. I just = added some extra conditions that make it clearer that there are some = instances where a client must not utilize HTTP. This might need further = refinement, but I think there is a balance we can strike here between = the two camps without introducing a lot of complex language. >=20 > =20 >=20 > I made some editorial changes through the document. >=20 > =20 >=20 > Comments are welcome, as always. Seems I don=92t need to say that to = this group, though :-) >=20 > =20 >=20 > Paul >=20 > =20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 From tbray@textuality.com Sun Dec 2 13:57:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF8421F889A for ; Sun, 2 Dec 2012 13:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytmeScKknWyp for ; Sun, 2 Dec 2012 13:57:19 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFD321F8898 for ; Sun, 2 Dec 2012 13:57:19 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2088750obc.31 for ; Sun, 02 Dec 2012 13:57:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9sYzCfGkTVrTgOapLw1LrUTLmrOMbjC/mcuxqS8nNdk=; b=TkBI+CXXJ1uswb8sUw2LTh8nW8cTTd5lx4ehFPzl3/V99cUrPCCgegQ4RDmuyywuq6 9Ki4RQCbiKAj1AJPRN60mo++PcU+PKogadh1bn21nP+xpveNlFhdji0DjQFAGgS7Eyyl At61lWatnYmDJYoFeevd2nfxgxMgcoQRUsJYxYrh1SkUYrh1GOmeKR4BKfSAjaHk0EYR zjmThCbk/HPzNtLs4fxo/QSSOWejHSSQ3hEGqFNKaJ65+WQWn0H1BhTlYfDyQjtBftFl utEJf91OPqXWAAYg/AZI4mkukEla+F6tbCWFq4myvfyGmHqgQv1wYpVk9EzdAU4oBN4X P0Dg== MIME-Version: 1.0 Received: by 10.182.47.66 with SMTP id b2mr2810329obn.34.1354485439137; Sun, 02 Dec 2012 13:57:19 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 13:57:19 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <07e601cdd0cf$dfb4d3f0$9f1e7bd0$@packetizer.com> References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> <07e601cdd0cf$dfb4d3f0$9f1e7bd0$@packetizer.com> Date: Sun, 2 Dec 2012 13:57:19 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae93998cd7408e104cfe5b7ae X-Gm-Message-State: ALoCoQmEWUHL1lRQncWctfItbZlh44UBu7X9QbUAC1bipOf2JtEuBB5asW+WyoWVRXH5v2h7Bgdb Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 21:57:20 -0000 --14dae93998cd7408e104cfe5b7ae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No, we=92re on the same side here. I=92m suggesting taking webfinger-07 as = a baseline, and all *future* changes need to be proposed as a concrete delta against it. -T On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones wrote= : > Tim,**** > > ** ** > > I didn=92t mean to be rude by introducing these changes, just trying to m= ove > things along. Most changes were fairly trivial, not worth mentioning, an= d > can be seen here:**** > > > http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-appsa= wg-webfinger-07.txt > **** > > ** ** > > The most significant changes were the re-write of section 5.2 and > modification to the language related to HTTPS in 5.1. I suspect that is > the text to which you refer as preferring it to be =93camera-ready=94. (= I > would assume the balance of the changes would not need to be presented as > =93camera-ready=94, since they=92re minor editorial things.)**** > > ** ** > > In any case, the most important text changes I would like folks to > consider is section 5.2 (which aims to fully document the JSON Resource > Descriptor object) and paragraphs 2 and 3 in section 5.1.**** > > ** ** > > Paul**** > > ** ** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Sunday, December 02, 2012 2:54 PM > *To:* Paul E. Jones > *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com > *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-07**** > > ** ** > > Thanks to Paul for the extra effort. I=92d like to suggest, in the > interests of courtesy and efficiency, that from here on on, contributions > to this discussion be =93camera-ready=94, that is to say, specific sugges= tions > in the style of a diff, including fully-written-out replacements language= . > > -Tim**** > > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones > wrote:**** > > Folks,**** > > **** > > I published another version of the WebFinger spec trying to bring closure > to the two open issues I see (resource representation and transport). Th= e > new version is here:**** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** > > **** > > With respect to resource representation, I fully described the JSON > Resource Descriptor within the document. There are no external reference= s > to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly > simple format and I believe this text documents it sufficiently. Combine= d > with the visual examples, I think this makes it pretty clear. Have a loo= k > at the JRD documentation in section 5.2 and provide your comments. **** > > **** > > With respect to HTTPS, it seems there is strong preference for =93HTTPS > only=94, but some a fair bit of insistence for allowing HTTP. I changed = the > wording in 5.2 to try to capture opinions. Previously, the text led with= a > requirement to try HTTPS first. That is still there. I just added some > extra conditions that make it clearer that there are some instances where= a > client must not utilize HTTP. This might need further refinement, but I > think there is a balance we can strike here between the two camps without > introducing a lot of complex language.**** > > **** > > I made some editorial changes through the document.**** > > **** > > Comments are welcome, as always. Seems I don=92t need to say that to thi= s > group, though :-)**** > > **** > > Paul**** > > **** > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > ** ** > --14dae93998cd7408e104cfe5b7ae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No, we=92re on the same side here. I=92m suggesting taking webfinger-07 as = a baseline, and all *future* changes need to be proposed as a concrete delt= a against it.=A0 -T

On Sun, Dec 2, 2012 a= t 12:59 PM, Paul E. Jones <paulej@packetizer.com> wrote:=

Tim,

=A0<= /p>

I didn=92t mean to be = rude by introducing these changes, just trying to move things along.=A0 Mos= t changes were fairly trivial, not worth mentioning, and can be seen here:<= u>

http://tools.ietf.org/rfcdiff?difftype=3D--hwdif= f&url2=3Ddraft-ietf-appsawg-webfinger-07.txt

=A0<= /p>

The most significant c= hanges were the re-write of section 5.2 and modification to the language re= lated to HTTPS in 5.1.=A0 I suspect that is the text to which you refer as = preferring it to be =93camera-ready=94.=A0 (I would assume the balance of t= he changes would not need to be presented as =93camera-ready=94, since they= =92re minor editorial things.)

=A0<= /p>

In any case, the most = important text changes I would like folks to consider is section 5.2 (which= aims to fully document the JSON Resource Descriptor object) and paragraphs= 2 and 3 in section 5.1.

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. Jones<= br>Cc: ap= ps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07

<= u>=A0

T= hanks to Paul for the extra effort.=A0 I=92d like to suggest, in the intere= sts of courtesy and efficiency, that from here on on, contributions to this= discussion be =93camera-ready=94, that is to say, specific suggestions in = the style of a diff, including fully-written-out replacements language.

=A0-Tim

On Sun, Dec 2, 201= 2 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

I published another version of the W= ebFinger spec trying to bring closure to the two open issues I see (resourc= e representation and transport).=A0 The new version is here:<= /p>

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=A0=

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=A0 There are no ex= ternal references to RFC 6415 now, no need to go read the XRD spec, etc. = =A0It=92s a fairly simple format and I believe this text documents it suffi= ciently.=A0 Combined with the visual examples, I think this makes it pretty= clear.=A0 Have a look at the JRD documentation in section 5.2 and provide = your comments.

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)=

=A0

Paul

=A0


_____= __________________________________________
apps-discuss mailing list
= apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=A0


--14dae93998cd7408e104cfe5b7ae-- From nico@cryptonector.com Sun Dec 2 15:41:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B19021F8897 for ; Sun, 2 Dec 2012 15:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2OujktjfS4d for ; Sun, 2 Dec 2012 15:41:04 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 36D3E21F8770 for ; Sun, 2 Dec 2012 15:41:04 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id C3312264058 for ; Sun, 2 Dec 2012 15:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=IjXdhYfAWndajEKJzIr2 ueCdqHI=; b=rvxa56qUsg01+ELBISIYi0vbtuBPn2qZdmzlkBvzVuU1JofNtwSz vfLa2H6iUSWs83W+BkOYXimI7+1zp+1TllG/8wD/rMNEJS5XcEYE124wyswUf0vi lpmdwver3v1GA4XzjGFcxIo841zbdNEOPxWt3M/38poOCWLNG3ZGgTQ= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 6D6E9264057 for ; Sun, 2 Dec 2012 15:41:03 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so938876wey.31 for ; Sun, 02 Dec 2012 15:41:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.88.71 with SMTP id be7mr6748261wib.17.1354491662239; Sun, 02 Dec 2012 15:41:02 -0800 (PST) Received: by 10.216.192.207 with HTTP; Sun, 2 Dec 2012 15:41:02 -0800 (PST) In-Reply-To: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> Date: Sun, 2 Dec 2012 17:41:02 -0600 Message-ID: From: Nico Williams To: Zellyn Hunter Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , webfinger@googlegroups.com, Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 23:41:05 -0000 On Sun, Dec 2, 2012 at 12:16 AM, Zellyn Hunter wrote: > Would it be useful to enumerate specific cases where people feel HTTP > would be useful, so we can see whether the concern is justified? As long as WF is a bag of arbitrary stuff, no: we can't enumerate what might get put in in the future. From joseph@josephholsten.com Sun Dec 2 16:01:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FFF21F88EB for ; Sun, 2 Dec 2012 16:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKA5HklHryNX for ; Sun, 2 Dec 2012 16:01:51 -0800 (PST) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9E43A21F8847 for ; Sun, 2 Dec 2012 16:01:49 -0800 (PST) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 30E00A4B8; Sun, 2 Dec 2012 19:01:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=references :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id:cc:from:subject:date:to; s=sasl; bh=z7fDR9f+Tne42T7z NXGVNyXNwqM=; b=QBp7W9Csvss02YX0x5bdRiLODgO/FFoOPjlk73EovETNmj1E qa02nFyHbWJ+TWN45hScYuKOLtkCwKa+P7rV8py4UBQSGeSI7lTDaJ+3VP4iVFLb 1HIm8Rcdwx1pAiMTmbOX6SiJ9GlO8kpoeHG+1huWLS3W0azUd5d4amEGrig= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 1F133A4B7; Sun, 2 Dec 2012 19:01:47 -0500 (EST) Received: from [10.0.1.3] (unknown [76.28.212.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by b-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 6FF72A4B5; Sun, 2 Dec 2012 19:01:45 -0500 (EST) References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-7A34432F-94D8-4A75-9E68-7E13415D4F91 Content-Transfer-Encoding: 7bit Message-Id: <35B2CD9A-A927-4159-B3A2-D330CD129170@josephholsten.com> X-Mailer: iPhone Mail (10A523) From: Joseph Holsten Date: Sun, 2 Dec 2012 16:02:07 -0800 To: "webfinger@googlegroups.com" X-Pobox-Relay-ID: A0E96C5C-3CDC-11E2-8479-C2612E706CDE-15777318!b-pb-sasl-quonix.pobox.com Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 00:01:52 -0000 --Apple-Mail-7A34432F-94D8-4A75-9E68-7E13415D4F91 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Xrd was designed to fail fast under sax parsing conditions. Doesn't apply to= Jrd at all. =20 -- http://josephholsten.com On Dec 2, 2012, at 15:48, Brad Fitzpatrick wrote: > Why does the JRD have a recommended key/value order? >=20 > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wro= te: >> Folks, >>=20 >> =20 >>=20 >> I published another version of the WebFinger spec trying to bring closure= to the two open issues I see (resource representation and transport). The n= ew version is here: >>=20 >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 >>=20 >> =20 >>=20 >> With respect to resource representation, I fully described the JSON Resou= rce Descriptor within the document. There are no external references to RFC= 6415 now, no need to go read the XRD spec, etc. It=A1=AFs a fairly simple f= ormat and I believe this text documents it sufficiently. Combined with the v= isual examples, I think this makes it pretty clear. Have a look at the JRD d= ocumentation in section 5.2 and provide your comments. >>=20 >> =20 >>=20 >> With respect to HTTPS, it seems there is strong preference for =A1=B0HTTP= S only=A1=B1, but some a fair bit of insistence for allowing HTTP. I change= d the wording in 5.2 to try to capture opinions. Previously, the text led w= ith a requirement to try HTTPS first. That is still there. I just added so= me extra conditions that make it clearer that there are some instances where= a client must not utilize HTTP. This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without int= roducing a lot of complex language. >>=20 >> =20 >>=20 >> I made some editorial changes through the document. >>=20 >> =20 >>=20 >> Comments are welcome, as always. Seems I don=A1=AFt need to say that to t= his group, though :-) >>=20 >> =20 >>=20 >> Paul >>=20 >> =20 >>=20 >=20 --Apple-Mail-7A34432F-94D8-4A75-9E68-7E13415D4F91 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Xrd was designed to fail fast under sa= x parsing conditions. Doesn't apply to Jrd at all.  
--

On Dec 2, 2012, at 15:48, Brad Fitzpatrick <bradfitz@google.com> wrote:

=
Why does the JRD have a recommended key/value or= der?

On Sun, Dec 2, 2012 at 12:21 AM, Paul= E. Jones <paulej@packetizer.com> wrote:

Folks,

 

I published another version of the WebFinger spec try= ing to bring closure to the two open issues I see (resource representation a= nd transport).  The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07<= u>

 

With respect to resource representation, I fully described the JSON Resource= Descriptor within the document.  There are no external references to R= FC 6415 now, no need to go read the XRD spec, etc.  It=E2=80=99s a fair= ly simple format and I believe this text documents it sufficiently.  Co= mbined with the visual examples, I think this makes it pretty clear.  H= ave a look at the JRD documentation in section 5.2 and provide your comments= .

 

With r= espect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS only= =E2=80=9D, but some a fair bit of insistence for allowing HTTP.  I chan= ged the wording in 5.2 to try to capture opinions.  Previously, the tex= t led with a requirement to try HTTPS first.  That is still there. = ; I just added some extra conditions that make it clearer that there are som= e instances where a client must not utilize HTTP.  This might need furt= her refinement, but I think there is a balance we can strike here between th= e two camps without introducing a lot of complex language.

=

 

I made= some editorial changes through the document.

 

Comments are welcom= e, as always.  Seems I don=E2=80=99t need to say that to this group, th= ough :-)=

 

Paul

 


= --Apple-Mail-7A34432F-94D8-4A75-9E68-7E13415D4F91-- From mnot@mnot.net Sun Dec 2 16:12:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F6021F892C for ; Sun, 2 Dec 2012 16:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.152 X-Spam-Level: X-Spam-Status: No, score=-104.152 tagged_above=-999 required=5 tests=[AWL=-1.553, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQDXb1ZTQ4+3 for ; Sun, 2 Dec 2012 16:12:45 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 12AF021F8903 for ; Sun, 2 Dec 2012 16:12:45 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1BA90509B7 for ; Sun, 2 Dec 2012 19:12:43 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Dec 2012 11:12:42 +1100 References: <50BB20B3.8010403@skoegl.net> To: Apps Discuss Message-Id: <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 00:12:46 -0000 I've started collecting implementations of JSON Patch here: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch ... and am also discussing both the draft and a test suite with the = implementers. Below is some feedback from Stefan K=F6gl, who's implementing in Python, = forwarded with permission (along with some commentary from me). Begin forwarded message: > * Section 4 "Operations" states >=20 > > Other members of operation objects MUST be ignored, unless they are > > explicitly allowed by the definition of the operation. >=20 > Why has the decision been made to ignore unknown members? I think this = could be problematic if the spec is updated later so that existing = operations include new keywords (say a "type" member for test). You = wouldn't notice that your (outdated) implementation does not support = this addition. >=20 > I don't know how/why the decision has been made to ignore unknown = members, but please consider this an argument against it. I explained why we made this decision (to recap: it was felt that some = implementations would inevitably ignore unknown extensions, causing a = situation similar to HTML).=20 Personally, I think we *could* require unknown extensions to be an = error; given our approach to extensibility, and with willing = implementers, it's a reasonable thing to do. Failing that, we at least need to document the approach to extensibility = that we're talking (i.e., that this format is not extensible, and any = modifications / additions need to be expressed using a new media type). > * The "replace" and "move" operations contain the note >=20 > > The target location MUST exist for the operation to be successful. >=20 > which is clear in the context. The "move" and "copy" operations do not = contain such a statement even though they proably should. Also if they = did, the term "target location" would be ambiguous, because it could = also refer to the "to" value. >=20 > I'd suggest to use a different term for whatever "path" refers to, and = add the statement to all operators to which it applies. (I think he means *re*move, not move in the first line above) I tend to agree on both counts. Is there any objecting to adding this clause to "move" and "copy"?=20 Regarding the term, how about "path location"? Cheers (and thanks to Stefan for the feedback!), -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Sun Dec 2 16:56:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030B921F846B for ; Sun, 2 Dec 2012 16:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5JSdSBIvMrz for ; Sun, 2 Dec 2012 16:56:33 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id DE8BB21F8475 for ; Sun, 2 Dec 2012 16:56:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,359,1352034000"; d="scan'208";a="103962174" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 03 Dec 2012 11:56:30 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="49924440" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcani.tcif.telstra.com.au with ESMTP; 03 Dec 2012 11:56:31 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Mon, 3 Dec 2012 11:56:30 +1100 From: "Manger, James H" To: Mark Nottingham , Apps Discuss Date: Mon, 3 Dec 2012 11:56:29 +1100 Thread-Topic: [apps-discuss] JSON Patch implementation feedback Thread-Index: Ac3Q6vOkBVWwHe6NRletvqv6TtvQHAAAK0gQ Message-ID: <255B9BB34FB7D647A506DC292726F6E115028CD4FD@WSMSG3153V.srv.dir.telstra.com> References: <50BB20B3.8010403@skoegl.net> <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> In-Reply-To: <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 00:56:34 -0000 PiA+ICogU2VjdGlvbiA0ICJPcGVyYXRpb25zIiBzdGF0ZXMNCj4gPg0KPiA+ID4gT3RoZXIgbWVt YmVycyBvZiBvcGVyYXRpb24gb2JqZWN0cyBNVVNUIGJlIGlnbm9yZWQsIHVubGVzcyB0aGV5IGFy ZQ0KPiA+ID4gZXhwbGljaXRseSBhbGxvd2VkIGJ5IHRoZSBkZWZpbml0aW9uIG9mIHRoZSBvcGVy YXRpb24uDQo+ID4NCj4gPiBXaHkgaGFzIHRoZSBkZWNpc2lvbiBiZWVuIG1hZGUgdG8gaWdub3Jl IHVua25vd24gbWVtYmVycz8gSSB0aGluaw0KPiB0aGlzIGNvdWxkIGJlIHByb2JsZW1hdGljIGlm IHRoZSBzcGVjIGlzIHVwZGF0ZWQgbGF0ZXIgc28gdGhhdCBleGlzdGluZw0KPiBvcGVyYXRpb25z IGluY2x1ZGUgbmV3IGtleXdvcmRzIChzYXkgYSAidHlwZSIgbWVtYmVyIGZvciB0ZXN0KS4gWW91 DQo+IHdvdWxkbid0IG5vdGljZSB0aGF0IHlvdXIgKG91dGRhdGVkKSBpbXBsZW1lbnRhdGlvbiBk b2VzIG5vdCBzdXBwb3J0DQo+IHRoaXMgYWRkaXRpb24uDQo+ID4NCj4gPiBJIGRvbid0IGtub3cg aG93L3doeSB0aGUgZGVjaXNpb24gaGFzIGJlZW4gbWFkZSB0byBpZ25vcmUgdW5rbm93bg0KPiBt ZW1iZXJzLCBidXQgcGxlYXNlIGNvbnNpZGVyIHRoaXMgYW4gYXJndW1lbnQgYWdhaW5zdCBpdC4N Cj4gDQo+IEkgZXhwbGFpbmVkIHdoeSB3ZSBtYWRlIHRoaXMgZGVjaXNpb24gKHRvIHJlY2FwOiBp dCB3YXMgZmVsdCB0aGF0IHNvbWUNCj4gaW1wbGVtZW50YXRpb25zIHdvdWxkIGluZXZpdGFibHkg aWdub3JlIHVua25vd24gZXh0ZW5zaW9ucywgY2F1c2luZyBhDQo+IHNpdHVhdGlvbiBzaW1pbGFy IHRvIEhUTUwpLg0KPiANCj4gUGVyc29uYWxseSwgSSB0aGluayB3ZSAqY291bGQqIHJlcXVpcmUg dW5rbm93biBleHRlbnNpb25zIHRvIGJlIGFuDQo+IGVycm9yOyBnaXZlbiBvdXIgYXBwcm9hY2gg dG8gZXh0ZW5zaWJpbGl0eSwgYW5kIHdpdGggd2lsbGluZw0KPiBpbXBsZW1lbnRlcnMsIGl0J3Mg YSByZWFzb25hYmxlIHRoaW5nIHRvIGRvLg0KPiANCj4gRmFpbGluZyB0aGF0LCB3ZSBhdCBsZWFz dCBuZWVkIHRvIGRvY3VtZW50IHRoZSBhcHByb2FjaCB0bw0KPiBleHRlbnNpYmlsaXR5IHRoYXQg d2UncmUgdGFsa2luZyAoaS5lLiwgdGhhdCB0aGlzIGZvcm1hdCBpcyBub3QNCj4gZXh0ZW5zaWJs ZSwgYW5kIGFueSBtb2RpZmljYXRpb25zIC8gYWRkaXRpb25zIG5lZWQgdG8gYmUgZXhwcmVzc2Vk DQo+IHVzaW5nIGEgbmV3IG1lZGlhIHR5cGUpLg0KDQoNCkl0IGlzIGV4dGVuc2libGUuDQpUbyBk ZWZpbmUgbmV3IGZ1bmN0aW9uYWxpdHkgdGhhdCBtdXN0IG5vdCBiZSBpZ25vcmVkIHlvdSBjYW4g ZGVmaW5lIGEgbmV3IG9wZXJhdGlvbi4NClRvIGRlZmluZSBuZXcgZnVuY3Rpb25hbGl0eSB0aGF0 IGNhbiBiZSBzYWZlbHkgaWdub3JlZCBieSBvbGQgaW1wbGVtZW50YXRpb25zIHlvdSBjYW4gZGVm aW5lIG5ldyBtZW1iZXJzIGZvciBleGlzdGluZyBvcGVyYXRpb25zLg0KDQpGb3IgaW5zdGFuY2Us IHRvIGRlZmluZSBhIHRlc3Qgb2YgdGhlIHR5cGUgb2YgYSBKU09OIHZhbHVlIHlvdSBjb3VsZCBk ZWZpbmUgYSBuZXcgb3BlcmF0aW9uczoNCiAgeyAib3AiOiJ0ZXN0MiIsICJwYXRoIjoiL2EvYi9j IiwgInR5cGUiOltdIH0gIC0tIHRydWUgaWZmIHRoZSB2YWx1ZSBhdCB0aGUgZ2l2ZW4gcGF0aCBp cyBhbiBhcnJheQ0KDQpTb21lIGV4dHJhIHRleHQgdG8gZG9jdW1lbnQgdGhpcyB3b3VsZCBiZSBn b29kLiBQZXJoYXBzIGNoYW5nZSB0aGUgMXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDQgIk9wZXJh dGlvbnMiOg0KDQo8LS1mcm9tLS0NCiAgIE9wZXJhdGlvbiBvYmplY3RzIE1VU1QgaGF2ZSBleGFj dGx5IG9uZSAib3AiIG1lbWJlciwgd2hvc2UgdmFsdWUNCiAgIGluZGljYXRlcyB0aGUgb3BlcmF0 aW9uIHRvIHBlcmZvcm0uICBJdHMgdmFsdWUgTVVTVCBiZSBvbmUgb2YgImFkZCIsDQogICAicmVt b3ZlIiwgInJlcGxhY2UiLCAibW92ZSIsICJjb3B5IiBvciAidGVzdCIuICBUaGUgc2VtYW50aWNz IG9mIGVhY2gNCiAgIGlzIGRlZmluZWQgYmVsb3cuDQotLXRvLS0+DQogICBPcGVyYXRpb24gb2Jq ZWN0cyBNVVNUIGhhdmUgZXhhY3RseSBvbmUgIm9wIiBtZW1iZXIsIHdob3NlIHZhbHVlDQogICBp bmRpY2F0ZXMgdGhlIG9wZXJhdGlvbiB0byBwZXJmb3JtLiAgVGhlIHNlbWFudGljcyBhcmUgZGVm aW5lZCBiZWxvdw0KICAgZm9yIHRoZSB2YWx1ZXMgImFkZCIsICJyZW1vdmUiLCAicmVwbGFjZSIs ICJtb3ZlIiwgImNvcHkiIGFuZCAidGVzdCIuDQogICBJdCBpcyBhbiBlcnJvciBpZiB0aGUgdmFs dWUgaXMgbm90IHJlY29nbml6ZWQuIE5ldyBvcGVyYXRpb25zIGNhbg0KICAgYmUgZGVmaW5lZCBi eSBSRkNzIHRoYXQgdXBkYXRlIHRoaXMgZG9jdW1lbnQuDQotLQ0KDQoNCj4gPiAqIFRoZSAicmVw bGFjZSIgYW5kICJtb3ZlIiBvcGVyYXRpb25zIGNvbnRhaW4gdGhlIG5vdGUNCj4gPg0KPiA+ID4g VGhlIHRhcmdldCBsb2NhdGlvbiBNVVNUIGV4aXN0IGZvciB0aGUgb3BlcmF0aW9uIHRvIGJlIHN1 Y2Nlc3NmdWwuDQo+ID4NCj4gPiB3aGljaCBpcyBjbGVhciBpbiB0aGUgY29udGV4dC4gVGhlICJt b3ZlIiBhbmQgImNvcHkiIG9wZXJhdGlvbnMgZG8NCj4gbm90IGNvbnRhaW4gc3VjaCBhIHN0YXRl bWVudCBldmVuIHRob3VnaCB0aGV5IHByb2FibHkgc2hvdWxkLiBBbHNvIGlmDQo+IHRoZXkgZGlk LCB0aGUgdGVybSAidGFyZ2V0IGxvY2F0aW9uIiB3b3VsZCBiZSBhbWJpZ3VvdXMsIGJlY2F1c2Ug aXQNCj4gY291bGQgYWxzbyByZWZlciB0byB0aGUgInRvIiB2YWx1ZS4NCj4gPg0KPiA+IEknZCBz dWdnZXN0IHRvIHVzZSBhIGRpZmZlcmVudCB0ZXJtIGZvciB3aGF0ZXZlciAicGF0aCIgcmVmZXJz IHRvLA0KPiBhbmQgYWRkIHRoZSBzdGF0ZW1lbnQgdG8gYWxsIG9wZXJhdG9ycyB0byB3aGljaCBp dCBhcHBsaWVzLg0KPiANCj4gDQo+IChJIHRoaW5rIGhlIG1lYW5zICpyZSptb3ZlLCBub3QgbW92 ZSBpbiB0aGUgZmlyc3QgbGluZSBhYm92ZSkNCj4gDQo+IEkgdGVuZCB0byBhZ3JlZSBvbiBib3Ro IGNvdW50cy4NCj4gDQo+IElzIHRoZXJlIGFueSBvYmplY3RpbmcgdG8gYWRkaW5nIHRoaXMgY2xh dXNlIHRvICJtb3ZlIiBhbmQgImNvcHkiPw0KPiANCj4gUmVnYXJkaW5nIHRoZSB0ZXJtLCBob3cg YWJvdXQgInBhdGggbG9jYXRpb24iPw0KDQoNCkkgdGhvdWdodCAicGF0aCIgd2FzIGJlaW5nIHJl cGxhY2VkIHdpdGggImZyb20iIGFuZCAidG8iIGFzIGFwcHJvcHJpYXRlIHRvIHRoZSBvcGVyYXRp b24uICJmcm9tIiByZWZlcnMgdG8gYSBsb2NhdGlvbiBpbiB0aGUgZXhpc3RpbmcgdmFsdWU7ICJ0 byIgcmVmZXJzIHRvIGEgbG9jYXRpb24gaW4gdGhlIHBhdGNoZWQgdmFsdWUgKHdoaWNoIHdpbGwg b2Z0ZW4gbm90IGV4aXN0IGluIHRoZSBleGlzdGluZyB2YWx1ZSkuDQoNCiAgWw0KICAgICB7ICJv cCI6ICJ0ZXN0IiwgICAgImZyb20iOiAiL2EvYi9jIiwgInZhbHVlIjogImZvbyIgfSwNCiAgICAg eyAib3AiOiAicmVtb3ZlIiwgICJmcm9tIjogIi9hL2IvYyIgfSwNCiAgICAgeyAib3AiOiAiYWRk IiwgICAgICAgInRvIjogIi9hL2IvYyIsICJ2YWx1ZSI6IFsgImZvbyIsICJiYXIiIF0gfSwNCiAg ICAgeyAib3AiOiAicmVwbGFjZSIsICAgInRvIjogIi9hL2IvYyIsICJ2YWx1ZSI6IDQyIH0sDQog ICAgIHsgIm9wIjogIm1vdmUiLCAgICAiZnJvbSI6ICIvYS9iL2MiLCAidG8iOiAiL2EvYi9kIiB9 LA0KICAgICB7ICJvcCI6ICJjb3B5IiwgICAgImZyb20iOiAiL2EvYi9kIiwgInRvIjogIi9hL2Iv ZSIgfQ0KICBdDQoNCltJIHN0aWxsIHRoaW5rIHdlIHNob3VsZCBkaXRjaCB0aGUgc3RhdGVtZW50 cyB0aGF0ICJUaGUgdGFyZ2V0IGxvY2F0aW9uIE1VU1QgZXhpc3QgZm9yIHRoZSBvcGVyYXRpb24g dG8gYmUgc3VjY2Vzc2Z1bCIuIEJldHRlciB0byBkZWZpbmUgYSBzZW5zaWJsZSAic3VjY2Vzc2Z1 bCIgcmVzdWx0IChlZyAicmVtb3ZlIiBpcyBhIG5vLW9wIGlmICJmcm9tIiBkb2VzIG5vdCBleGlz dDsgIm1vdmUiIGlzIGVxdWl2YWxlbnQgdG8gInJlbW92ZSIgb24gdGhlICJmcm9tIiBhbmQgInRv IiBsb2NhdGlvbnMgdGhlbiwgaWYgdGhlcmUgd2FzIGEgdmFsdWUgYXQgImZyb20iLCBhbiAiYWRk IiBvcGVyYXRpb247ICJyZXBsYWNlIiBpcyBlcXVpdmFsZW50IHRvICJyZW1vdmUiIHRoZW4gImFk ZCIgb3BlcmF0aW9ucykuXQ0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From tbray@textuality.com Sun Dec 2 17:14:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF18921F894F for ; Sun, 2 Dec 2012 17:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2Qq5GLC6cMI for ; Sun, 2 Dec 2012 17:14:37 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFC621F894C for ; Sun, 2 Dec 2012 17:14:36 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2401824oag.31 for ; Sun, 02 Dec 2012 17:14:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=Ha9B6tU4MMVFzeHT8d4TA4eRvFyYEfyurdhtFP93yJQ=; b=pRJOj2S/mUBEbzWMIktWKlVp+AEcwWmJavOijaQW0PiDauq+dBnkKCXPsS2KKZbSfP +syTsdKhmML3IPL/tSHdLX/Nyzyny7bLdXKovRIujfom1bMwnSzbskK2bFWpfGBBbJpJ /w6GXepjCrAM1lmxCk0yrWH8hyc5PDdp17+Ap0KgjEJqJJ+0XDlcg/4sAbidLT6/1jSt QV2FEKyhTgzkcDnFN7XihciVZ9BXWIO8S1AO5hiyNHOPoyjDqBgI3mdYsVtiM7hGk/CH 4om6oBxX/+/MoF2ynWmrsYMa87nBnPztAl5AQiKqIdPI7ZQ+kOIE/qZ2ok0aw3QXwrcU 9/GA== MIME-Version: 1.0 Received: by 10.182.212.35 with SMTP id nh3mr3132351obc.10.1354497274946; Sun, 02 Dec 2012 17:14:34 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 17:14:34 -0800 (PST) X-Originating-IP: [24.84.235.32] Date: Sun, 2 Dec 2012 17:14:34 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f5039dcec22a804cfe878b1 X-Gm-Message-State: ALoCoQmKiijC/EYemZzietMNnaYlqzCwC+Di9LTJg9sUmDEyXHIS1KWtuu9DxYAT/7yVGU8msiEt Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: [apps-discuss] Draft -07 mod proposal: Remove top-level "properties" in JRD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:14:38 -0000 --e89a8f5039dcec22a804cfe878b1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is actively harmful. Link relations are an excellent way to express properties of a resource, and having two competing mechanisms will distract developers and hurt interoperability. Proposal: 1. Introduction: s/link relations, properties, titles/link relations, titles/ 3. Overview: same 4.1 remove "properties:" member of JRD 4.1 last para s/and properties// 4.2 remove "properties:" member of JRD 4.2 s/any aliases and properties/any aliases/ 4.3 remove "properties" top-level member of JRD 5.2 remove "properties" from bullet list after 1st para 5.2 s/"properties" is an object comprised of name/value pairs whose values are strings// 5.2.4 Remove section 5.3 example, remove top-level "properties" member 5.4 s/and properties// On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > I published another version of the WebFinger spec trying to bring closure > to the two open issues I see (resource representation and transport). Th= e > new version is here:**** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** > > ** ** > > With respect to resource representation, I fully described the JSON > Resource Descriptor within the document. There are no external reference= s > to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly > simple format and I believe this text documents it sufficiently. Combine= d > with the visual examples, I think this makes it pretty clear. Have a loo= k > at the JRD documentation in section 5.2 and provide your comments. **** > > ** ** > > With respect to HTTPS, it seems there is strong preference for =93HTTPS > only=94, but some a fair bit of insistence for allowing HTTP. I changed = the > wording in 5.2 to try to capture opinions. Previously, the text led with= a > requirement to try HTTPS first. That is still there. I just added some > extra conditions that make it clearer that there are some instances where= a > client must not utilize HTTP. This might need further refinement, but I > think there is a balance we can strike here between the two camps without > introducing a lot of complex language.**** > > ** ** > > I made some editorial changes through the document.**** > > ** ** > > Comments are welcome, as always. Seems I don=92t need to say that to thi= s > group, though :-)**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --e89a8f5039dcec22a804cfe878b1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is actively harmful.=A0 Link relations are an excellent way to express= properties of a resource, and having two competing mechanisms will distrac= t developers and hurt interoperability.

Proposal:

1. Introduc= tion: s/link relations, properties,=A0 titles/link relations, titles/
3. Overview: same
4.1 remove "properties:" member of JRD
4.= 1 last para s/and properties//
4.2 remove "properties:" member= of JRD
4.2 s/any aliases and properties/any aliases/
4.3 remove &quo= t;properties" top-level member of JRD
5.2 remove "properties" from bullet list after 1st para
5.2 s/= "properties" is an object comprised of name/value pairs whose val= ues are strings//
5.2.4 Remove section
5.3 example, remove top-level = "properties" member
5.4 s/and properties//


On Sun, Dec 2,= 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com>= wrote:

Folks,

=A0

I published another version of the WebFinger spec tr= ying to bring closure to the two open issues I see (resource representation= and transport).=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

=A0

With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=A0 There are no external references to RF= C 6415 now, no need to go read the XRD spec, etc. =A0It=92s a fairly simple= format and I believe this text documents it sufficiently.=A0 Combined with= the visual examples, I think this makes it pretty clear.=A0 Have a look at= the JRD documentation in section 5.2 and provide your comments. =

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)

=A0

<= p class=3D"MsoNormal">Paul

= =A0


_______________________________= ________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--e89a8f5039dcec22a804cfe878b1-- From tbray@textuality.com Sun Dec 2 17:14:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A3C21F8956 for ; Sun, 2 Dec 2012 17:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15VaIJMHhiKt for ; Sun, 2 Dec 2012 17:14:43 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id D952021F8951 for ; Sun, 2 Dec 2012 17:14:42 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2401824oag.31 for ; Sun, 02 Dec 2012 17:14:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=Zezl3d2AxxjgS7JuSygJjPza0wmCaadXDNZxZxck4hU=; b=kbRFl2ab9FzY0km9nsBVbN7Z5hh+Mz0mH0jOl8OSpFlBeN7SfL5s0RjxKfBKGyJe22 TLpiDbAqZOaQVhKAg0CAgF6Up2wBGE3DRVcvgGe+S3pZNpd9gErjWrE461Crxb2KW8nY y3XBfVjmqDhn9urz1pPlGSCN2lfz+xKXP/QRKY7AMaGGDTKtQ9bX5oa5985SthHeWGtR Q+vITVNXl8oVMxW4rVp16mN64qvGhKsFCivmEgBSFnt4cCfdZwL3MSSoR3y++OWqJisU DRsIOZ7OE7lPjNEVt84gzWd6dgoVkxEtRpmcRlqjjbDQ+pUJLUzx8lMqpCtQjKcWfRyY AoRw== MIME-Version: 1.0 Received: by 10.60.23.200 with SMTP id o8mr6786363oef.48.1354497282676; Sun, 02 Dec 2012 17:14:42 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 17:14:42 -0800 (PST) X-Originating-IP: [24.84.235.32] Date: Sun, 2 Dec 2012 17:14:42 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb206e462176904cfe8795d X-Gm-Message-State: ALoCoQmOg25v2X52fHmPXZubGZ4YPd0SAfLGw+etoz8wG0+ROtU5vQygzlLD1tDzypcGwCzCiO+k Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: [apps-discuss] Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:14:43 -0000 --e89a8fb206e462176904cfe8795d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Right now, section 5.2.2 says "The value of the "subject" member is a string that MUST be set to the same value as the "resource" parameter in the client request. " This is a recipe for trouble, for a couple of reasons. First of all, what does =93the same value=94 mean? Go visit RFC3986, section 6, and enjoy sev= eral hundred words walking through all the issues that arise in trying to figure out when two URIs are equivalent, ranging from exact character-by-character identity to all sorts of protocol-specific goo. You are just one level of case-sensitivity-in-%-escaping from a big hairy false negative. I=92m also worried about a lack of flexibility. I might have a single webfinger resource that declares a bunch of link relations for a bunch of different resources. This section, as written, wouldn=92t let me do that. Proposal: Re-write section 5.2.2 as follows: <<<<<<< The value of the "subject" member is a string whose value is advisory, identifying the resource to which the properties given in the "links" member apply. Normally this would be expected to be equivalent to the value of the "resource" parameter in the client request. <<<<<<< On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > I published another version of the WebFinger spec trying to bring closure > to the two open issues I see (resource representation and transport). Th= e > new version is here:**** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** > > ** ** > > With respect to resource representation, I fully described the JSON > Resource Descriptor within the document. There are no external reference= s > to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly > simple format and I believe this text documents it sufficiently. Combine= d > with the visual examples, I think this makes it pretty clear. Have a loo= k > at the JRD documentation in section 5.2 and provide your comments. **** > > ** ** > > With respect to HTTPS, it seems there is strong preference for =93HTTPS > only=94, but some a fair bit of insistence for allowing HTTP. I changed = the > wording in 5.2 to try to capture opinions. Previously, the text led with= a > requirement to try HTTPS first. That is still there. I just added some > extra conditions that make it clearer that there are some instances where= a > client must not utilize HTTP. This might need further refinement, but I > think there is a balance we can strike here between the two camps without > introducing a lot of complex language.**** > > ** ** > > I made some editorial changes through the document.**** > > ** ** > > Comments are welcome, as always. Seems I don=92t need to say that to thi= s > group, though :-)**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --e89a8fb206e462176904cfe8795d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Right now, section 5.2.2 says "The value of the "subject" me= mber is a string that MUST be set to the same value as the "resource&q= uot; parameter in the client request. "

This is a recipe for tr= ouble, for a couple of reasons. First of all, what does =93the same value= =94 mean?=A0 Go visit RFC3986, section 6, and enjoy several hundred words w= alking through all the issues that arise in trying to figure out when two U= RIs are equivalent, ranging from exact character-by-character identity to a= ll sorts of protocol-specific goo. You are just one level of case-sensitivi= ty-in-%-escaping from a big hairy false negative.

I=92m also worried about a lack of flexibility. I might have a single w= ebfinger resource that declares a bunch of link relations for a bunch of di= fferent resources. This section, as written, wouldn=92t let me do that.

Proposal: Re-write section 5.2.2 as follows:

<<<<<= ;<<
The value of the "subject" member is a string whose = value is advisory, identifying the resource to which the properties given i= n the "links" member apply.=A0 Normally this would be expected to= be equivalent to the value of the "resource" parameter in the cl= ient request.
<<<<<<<

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

I published another version of the WebFinger spec tr= ying to bring closure to the two open issues I see (resource representation= and transport).=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

=A0

With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=A0 There are no external references to RF= C 6415 now, no need to go read the XRD spec, etc. =A0It=92s a fairly simple= format and I believe this text documents it sufficiently.=A0 Combined with= the visual examples, I think this makes it pretty clear.=A0 Have a look at= the JRD documentation in section 5.2 and provide your comments. =

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)

=A0

<= p class=3D"MsoNormal">Paul

= =A0


_______________________________= ________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--e89a8fb206e462176904cfe8795d-- From tbray@textuality.com Sun Dec 2 17:14:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0697921F895B for ; Sun, 2 Dec 2012 17:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmhJ4oSUMZug for ; Sun, 2 Dec 2012 17:14:50 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13B5F21F894C for ; Sun, 2 Dec 2012 17:14:49 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2175560obc.31 for ; Sun, 02 Dec 2012 17:14:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=bcerOjMisVXOj8lKu02xH9dBS08wYCNL1qe1y7+aqFg=; b=CeJET/4IbmzyAP0lSaC65kLR47tuNLPK6/CYlSx3HalsrjVoS2a/0nHfeb8gVMcOC9 hYTm1BkcGkLh4+TgljWYlksx7icunjZu/RoHXlA5M8xJGnfri4H9ojYpfK8OxblmHmiY ebn78ymTVI8/F5AMiy0mMSrjCGNd4daOQGFvPsZhr2FkLwz+ENfeAsCgkqdDoha2ZmXQ FuGUp6GUnf4hG5unZ2kY1FnLZBp2rsXUZvK1OtDNV4KyNmbbaSIrYab7/qGonitVN6OQ TBZo3kWSGC1LDzCuxB9rBdfa2kwi3IZBUvkN5he+KXTrizxHoKspEje1p40FF5XAoYfR dlqA== MIME-Version: 1.0 Received: by 10.182.174.39 with SMTP id bp7mr3143460obc.1.1354497288644; Sun, 02 Dec 2012 17:14:48 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 17:14:48 -0800 (PST) X-Originating-IP: [24.84.235.32] Date: Sun, 2 Dec 2012 17:14:48 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f642a2abd2a1204cfe87926 X-Gm-Message-State: ALoCoQlfZXryNBuT3YuuXbI7huzKkj39Ygy6gTRW3HySbtSb6KWWIGRWEyc7YqP0WZBQZV59LwSt Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:14:51 -0000 --e89a8f642a2abd2a1204cfe87926 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I don=92t want to wait for work on this to be completed, and I don=92t thin= k that its presence is necessary for WebFinger to be useful. So let's take it out. Proposal: Section 4.1: Change the URI in the example from acct: to mailto: Section 4.2: Same Section 5.3: Same Section 5.4: s/it could be an "acct" URI [7], // Section 5.4: Remove 2nd para, beginning "For resources associated with a user account at a host...=93 Section 5.4: s/both an "acct" URI and any alias/any alias/ Section 8: Change the URI in the example from acct: to mailto: On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: > No, we=92re on the same side here. I=92m suggesting taking webfinger-07 a= s a > baseline, and all *future* changes need to be proposed as a concrete delt= a > against it. -T > > > On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones wro= te: > >> Tim,**** >> >> ** ** >> >> I didn=92t mean to be rude by introducing these changes, just trying to >> move things along. Most changes were fairly trivial, not worth mentioni= ng, >> and can be seen here:**** >> >> >> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-apps= awg-webfinger-07.txt >> **** >> >> ** ** >> >> The most significant changes were the re-write of section 5.2 and >> modification to the language related to HTTPS in 5.1. I suspect that is >> the text to which you refer as preferring it to be =93camera-ready=94. = (I >> would assume the balance of the changes would not need to be presented a= s >> =93camera-ready=94, since they=92re minor editorial things.)**** >> >> ** ** >> >> In any case, the most important text changes I would like folks to >> consider is section 5.2 (which aims to fully document the JSON Resource >> Descriptor object) and paragraphs 2 and 3 in section 5.1.**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> *From:* Tim Bray [mailto:tbray@textuality.com] >> *Sent:* Sunday, December 02, 2012 2:54 PM >> *To:* Paul E. Jones >> *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com >> *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-07**** >> >> ** ** >> >> Thanks to Paul for the extra effort. I=92d like to suggest, in the >> interests of courtesy and efficiency, that from here on on, contribution= s >> to this discussion be =93camera-ready=94, that is to say, specific sugge= stions >> in the style of a diff, including fully-written-out replacements languag= e. >> >> -Tim**** >> >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones >> wrote:**** >> >> Folks,**** >> >> **** >> >> I published another version of the WebFinger spec trying to bring closur= e >> to the two open issues I see (resource representation and transport). T= he >> new version is here:**** >> >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >> >> **** >> >> With respect to resource representation, I fully described the JSON >> Resource Descriptor within the document. There are no external referenc= es >> to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly >> simple format and I believe this text documents it sufficiently. Combin= ed >> with the visual examples, I think this makes it pretty clear. Have a lo= ok >> at the JRD documentation in section 5.2 and provide your comments. **** >> >> **** >> >> With respect to HTTPS, it seems there is strong preference for =93HTTPS >> only=94, but some a fair bit of insistence for allowing HTTP. I changed= the >> wording in 5.2 to try to capture opinions. Previously, the text led wit= h a >> requirement to try HTTPS first. That is still there. I just added some >> extra conditions that make it clearer that there are some instances wher= e a >> client must not utilize HTTP. This might need further refinement, but I >> think there is a balance we can strike here between the two camps withou= t >> introducing a lot of complex language.**** >> >> **** >> >> I made some editorial changes through the document.**** >> >> **** >> >> Comments are welcome, as always. Seems I don=92t need to say that to th= is >> group, though :-)**** >> >> **** >> >> Paul**** >> >> **** >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss**** >> >> ** ** >> > > --e89a8f642a2abd2a1204cfe87926 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I don=92t want to wait for work on this to be completed, and I don=92t thin= k that its presence is necessary for WebFinger to be useful.=A0 So let'= s take it out.

Proposal:
Section 4.1: Change the URI in the examp= le from acct: to mailto:
Section 4.2: Same
Section 5.3: Same
Section 5.4: s/it could be an &qu= ot;acct" URI [7], //
Section 5.4: Remove 2nd para, beginning "= For resources associated with a user account at a host...=93
Section 5.4= : s/both an "acct" URI and any alias/any alias/
Section 8: Change the URI in the example from acct: to mailto:


<= div class=3D"gmail_quote">On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray <tbr= ay@textuality.com> wrote:
No, we=92re on the same side here. I=92m sug= gesting taking webfinger-07 as a baseline, and all *future* changes need to= be proposed as a concrete delta against it.=A0 -T


On Sun, Dec 2, 2012 at 12:59 PM, Pa= ul E. Jones <paulej@packetizer.com> wrote:

Tim,

=A0<= /p>

I didn=92t mean to be = rude by introducing these changes, just trying to move things along.=A0 Mos= t changes were fairly trivial, not worth mentioning, and can be seen here:<= u>

http://tools.ietf.org/rfcdiff?difftype=3D--hwdif= f&url2=3Ddraft-ietf-appsawg-webfinger-07.txt

=A0<= /p>

The most significant c= hanges were the re-write of section 5.2 and modification to the language re= lated to HTTPS in 5.1.=A0 I suspect that is the text to which you refer as = preferring it to be =93camera-ready=94.=A0 (I would assume the balance of t= he changes would not need to be presented as =93camera-ready=94, since they= =92re minor editorial things.)

=A0<= /p>

In any case, the most = important text changes I would like folks to consider is section 5.2 (which= aims to fully document the JSON Resource Descriptor object) and paragraphs= 2 and 3 in section 5.1.

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. Jones<= br>Cc: ap= ps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07

=A0<= /u>

Thanks to Paul= for the extra effort.=A0 I=92d like to suggest, in the interests of courte= sy and efficiency, that from here on on, contributions to this discussion b= e =93camera-ready=94, that is to say, specific suggestions in the style of = a diff, including fully-written-out replacements language.

=A0-Tim

On Sun, Dec 2, 201= 2 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

I published another version of the W= ebFinger spec trying to bring closure to the two open issues I see (resourc= e representation and transport).=A0 The new version is here:<= /p>

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=A0=

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=A0 There are no ex= ternal references to RFC 6415 now, no need to go read the XRD spec, etc. = =A0It=92s a fairly simple format and I believe this text documents it suffi= ciently.=A0 Combined with the visual examples, I think this makes it pretty= clear.=A0 Have a look at the JRD documentation in section 5.2 and provide = your comments.

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)=

=A0

Paul

=A0


_____= __________________________________________
apps-discuss mailing list
= apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=A0



--e89a8f642a2abd2a1204cfe87926-- From tbray@textuality.com Sun Dec 2 17:15:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBFB21F8960 for ; Sun, 2 Dec 2012 17:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRxUBSutXTk0 for ; Sun, 2 Dec 2012 17:15:08 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF11221F895E for ; Sun, 2 Dec 2012 17:15:08 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2175560obc.31 for ; Sun, 02 Dec 2012 17:15:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=pE4A87D959JmvcDreoltqj+bn70aFMdfzne4sNnaMeM=; b=jPtKfJo61BjCvl/7hQt7Igs5cEeBgRlwk0ddQ0uY8uJnvFRXzsylxLeI0uDLZQuw2s 2AX6WyOXQuxyzAaPKDbFYSd7pMo+RFLeJsKw41LKytVHTwWCGri2jlGimkeMQuhbfb3R VuG/TWw50fhctMxksWGoNe/VHlxFZBpnF2mHmoewmJfiZqyJW3vTWZlBSHCJbvshk1j3 7qvOdlxng3UuAxS24i5NUPM7zb2U9hyQedFFQWNW1gFmLVK2C8NAGDzQGCoS6DKoiydX qXE7OVPrFFbtmOMAPCE/HrueKe8qXO5VV8u8y0Z6Y+98DWAA82lQywoGoUAiZUOXKmDl JWCg== MIME-Version: 1.0 Received: by 10.182.52.105 with SMTP id s9mr3145690obo.25.1354497308674; Sun, 02 Dec 2012 17:15:08 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 17:15:08 -0800 (PST) X-Originating-IP: [24.84.235.32] Date: Sun, 2 Dec 2012 17:15:08 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae9399429eecb9b04cfe87a22 X-Gm-Message-State: ALoCoQk3AQaFlhEnj8MYABL/6SYtOdBiNdUSJYzEbT+0lLclyd8qE4H+tejYC8Kx0Ud5qjnHw25O Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: [apps-discuss] Draft -07 meta-proposal: HTTPS and HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:15:09 -0000 --14dae9399429eecb9b04cfe87a22 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote= : > With respect to HTTPS, it seems there is strong preference for =93HTTPS > only=94, but some a fair bit of insistence for allowing HTTP. I changed = the > wording in 5.2 to try to capture opinions. Previously, the text led with= a > requirement to try HTTPS first. That is still there. I just added some > extra conditions that make it clearer that there are some instances where= a > client must not utilize HTTP. This might need further refinement, but I > think there is a balance we can strike here between the two camps without > introducing a lot of complex language. > Paul, I think you=92re swimming up-hill here. I detect a maybe-better-than-rough consensus that the security folk want determinism, and this language saying =93It=92s OK to use HTTP except when you shouldn= =92t=94 is probably not going to do it for them. I heard two realistic proposals to work around this: HTTP only, and a fallback parameter with deterministic behavior. I=92m going to write up proposals for both of those (since eithe= r would get my support) and let the WG chairs decide if either or both has rough-consensus support. -T > ** ** > > I made some editorial changes through the document.**** > > ** ** > > Comments are welcome, as always. Seems I don=92t need to say that to thi= s > group, though :-)**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --14dae9399429eecb9b04cfe87a22 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:
With respect to HTT= PS, it seems there is strong preference for =93HTTPS only=94, but some a fa= ir bit of insistence for allowing HTTP.=A0 I changed the wording in 5.2 to = try to capture opinions.=A0 Previously, the text led with a requirement to = try HTTPS first.=A0 That is still there.=A0 I just added some extra conditi= ons that make it clearer that there are some instances where a client must = not utilize HTTP.=A0 This might need further refinement, but I think there = is a balance we can strike here between the two camps without introducing a= lot of complex language.

Paul, I think you=92re swimming up-hill here.= =A0 I detect a maybe-better-than-rough consensus that the security folk wan= t determinism, and this language saying =93It=92s OK to use HTTP except whe= n you shouldn=92t=94 is probably not going to do it for them.=A0 I heard tw= o realistic proposals to work around this: HTTP only, and a fallback parame= ter with deterministic behavior.=A0 I=92m going to write up proposals for b= oth of those (since either would get my support) and let the WG chairs deci= de if either or both has rough-consensus support. -T
=A0

=A0

I made some editorial changes through the document.

=A0

Comments= are welcome, as always.=A0 Seems I don=92t need to say that to this group,= though :-)

=A0

<= p class=3D"MsoNormal">Paul

= =A0


_______________________________= ________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--14dae9399429eecb9b04cfe87a22-- From tbray@textuality.com Sun Dec 2 17:15:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4642A21F896A for ; Sun, 2 Dec 2012 17:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJxtI3KsQ30P for ; Sun, 2 Dec 2012 17:15:15 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id AEC4421F8967 for ; Sun, 2 Dec 2012 17:15:15 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2402221oag.31 for ; Sun, 02 Dec 2012 17:15:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=CjHKN0jhYtIIb426kLseVXMF//RtL+rKxpM6Lt36/pw=; b=A8Hm3LiFvIyiSVkg9D4Z9pMpkGxV7hmKNt8umHencnIaXebzoIhyE4oAhroUe6HJ/g xKKxvZMbzX9kK1oJ2Rsc8lsUGS6DzSybwOxU27ZDcvUeheiaxKeZDJNB3xlyd4rpx2PJ f3qccKIm1nZXGWZD8DvD1+JGM/Gebh4WDVveip9EWzVbKH/NT/16dxN+AnIyrzi+i1jK 8VCeES1kKuPy8HhYCepx77QGczlVJt45+5OkgaZ6vXZPQ0rnGIvk2cx8qwyOKrvoS11+ eQzrKDCy0dUvYsSzEengGOsveP05/uWcCSSklTiKoch72FErTiY0cDBwHZi6IzEHtUJ4 m38w== MIME-Version: 1.0 Received: by 10.182.177.72 with SMTP id co8mr3145485obc.53.1354497315345; Sun, 02 Dec 2012 17:15:15 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 17:15:15 -0800 (PST) X-Originating-IP: [24.84.235.32] Date: Sun, 2 Dec 2012 17:15:15 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f64310454954404cfe87bb3 X-Gm-Message-State: ALoCoQl4rdFiO9VCU8J3HHybDj82+j2O/1ejIKl+tP27hf8kUpJ3BXKk/LunRq3MpgSEbTTpo4yN Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: [apps-discuss] Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:15:16 -0000 --e89a8f64310454954404cfe87bb3 Content-Type: text/plain; charset=ISO-8859-1 Proposal: Change para 2 of section 5.2 to read as follows: Clients MUST query the server using HTTPS. If an HTTPS connection cannot be established, or returns an HTTP status code indicating some error, such as 4xx or 5xx, the client MUST report an error and MUST cease attempting to retrieve the resource. --e89a8f64310454954404cfe87bb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Proposal: Change para 2 of section 5.2 to read as follows:

Clients M= UST query the server using HTTPS. If an HTTPS connection cannot be establis= hed, or returns an HTTP status code indicating some error, such as 4xx or 5= xx, the client MUST report an error and MUST cease attempting to retrieve t= he resource.

--e89a8f64310454954404cfe87bb3-- From tbray@textuality.com Sun Dec 2 17:15:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C4121F896E for ; Sun, 2 Dec 2012 17:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlLzCVQDA2Eb for ; Sun, 2 Dec 2012 17:15:21 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9350321F896C for ; Sun, 2 Dec 2012 17:15:19 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2175560obc.31 for ; Sun, 02 Dec 2012 17:15:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=Xj7fQDc6Ix+T/NZAbXRChuF29tHAFRz1ATA264ug++U=; b=aoZOpjI0uNUwzcXf+2fixIhSKUAAtzlZadeULRaoNaVU69XhrUyRbijUBPqM/FkOAZ QKuzTXDrued70d6mYa+DuLqi5AtbOuvDFqfKqj3Ac5V2mPg/dX47OaEyPphWvp1gMwsX mwPwwpXXhNuVPsejMhHliOJ/tWGLt4kl7PbMF8up45AbyORnUIVVYWrLDtds9AKg2lX4 UUfmX0K31V1EWznryWMIHdjRe962NG9fT8hs/yQOc0Za3WR8JJH2v3xBPF/oc7ayrYud Gi1c7FqLLwO7LExbtBXDkyb2kJqd+seczjqs/DrnLwc/+CmDh44bb45Me+BozCBMxHAp Yf5Q== MIME-Version: 1.0 Received: by 10.182.47.66 with SMTP id b2mr3071872obn.34.1354497319404; Sun, 02 Dec 2012 17:15:19 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 17:15:19 -0800 (PST) X-Originating-IP: [24.84.235.32] Date: Sun, 2 Dec 2012 17:15:19 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae93998cd9283f804cfe87bdd X-Gm-Message-State: ALoCoQkYqHbroAYbl6eWhenti3CEr86bOMoQBJmNlRZICenIy6VC6Mqrsn5+F4humMKwS6NVE7fQ Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:15:22 -0000 --14dae93998cd9283f804cfe87bdd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Change paragraph 2 of section 5.1 to read: WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback". If this parameter is not provided, client software MUST behave as if it were present with a value of false. WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol. If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource. If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallbackparameter. If the value of allow- fallback is true, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger. If allow-fallback is false, client software MUST report an error and cease attempting to retrieve the resource. On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > I published another version of the WebFinger spec trying to bring closure > to the two open issues I see (resource representation and transport). Th= e > new version is here:**** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** > > ** ** > > With respect to resource representation, I fully described the JSON > Resource Descriptor within the document. There are no external reference= s > to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly > simple format and I believe this text documents it sufficiently. Combine= d > with the visual examples, I think this makes it pretty clear. Have a loo= k > at the JRD documentation in section 5.2 and provide your comments. **** > > ** ** > > With respect to HTTPS, it seems there is strong preference for =93HTTPS > only=94, but some a fair bit of insistence for allowing HTTP. I changed = the > wording in 5.2 to try to capture opinions. Previously, the text led with= a > requirement to try HTTPS first. That is still there. I just added some > extra conditions that make it clearer that there are some instances where= a > client must not utilize HTTP. This might need further refinement, but I > think there is a balance we can strike here between the two camps without > introducing a lot of complex language.**** > > ** ** > > I made some editorial changes through the document.**** > > ** ** > > Comments are welcome, as always. Seems I don=92t need to say that to thi= s > group, though :-)**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --14dae93998cd9283f804cfe87bdd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Change paragraph 2 of section 5.1 to read:

WebFinger client software= MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-= fallback".=A0 If this parameter is not provided, client softwar= e MUST behave as if it were present with a value of false.

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using=20 the HTTPS protocol.=A0 If an HTTPS connection is made, and the server has= =20 an invalid certificate, or returns an HTTP status code indicating an=20 error, the client software MUST report an error and cease attempting to=20 retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS=20 connection to the server, behavior depends on the value of the allow-= fallback parameter.=A0 If the value of allow-fallback i= s true, the client software MAY fall back to unen= crypted HTTP in an attempt to retrieve /.well-known/webfinger.=A0 If allow-= fallback is false, client software MUST report an error and ce= ase attempting to retrieve the resource.



On Sun, Dec 2, 2012 at 12:21 AM, Pau= l E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

I published another version of the WebFinger spec tryin= g to bring closure to the two open issues I see (resource representation an= d transport).=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=A0=

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=A0 There are no ex= ternal references to RFC 6415 now, no need to go read the XRD spec, etc. = =A0It=92s a fairly simple format and I believe this text documents it suffi= ciently.=A0 Combined with the visual examples, I think this makes it pretty= clear.=A0 Have a look at the JRD documentation in section 5.2 and provide = your comments.

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)

=A0

<= p class=3D"MsoNormal">Paul

= =A0


_______________________________= ________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--14dae93998cd9283f804cfe87bdd-- From bobwyman@gmail.com Sun Dec 2 17:34:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C2521F8948 for ; Sun, 2 Dec 2012 17:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrnUuoqkYpxZ for ; Sun, 2 Dec 2012 17:34:54 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0556421F893A for ; Sun, 2 Dec 2012 17:34:49 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1952291lbk.31 for ; Sun, 02 Dec 2012 17:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JN20l88pUETpM9eI2pBgFE+9AyOOUiuK+Ec/nx7p5xY=; b=sGHqkTPwQ6mcL2d7GFXeVkfeX1H6Gy4xoZt1RYQIgmjimjugo9Ko5PYkeewS8HhUlc 7piR7eugPRIzkmGQDDM9XQz8UMo7Nj3Wlq6KotsFHrxxINtpWzG71VKvfuE9t9SPiRL9 nNNtor0hEf5WSZXAMvZun6glX5kp3ncXryR3qMJyZIIqWFA9z+V6WzkUlufJT3cfQIrO qTF384Mvl07vtXXnBXSGh7v7o1MSkM0KP6tvGkgyza18AnVOXGyw9ZitOA7E5unZMjm9 RgxgfDVagk3LainAFlqI9lxWbI/00VHzUzozTJEJS2CxGjYCbbFvRZz5hBwuo1mYlAiJ rVmw== MIME-Version: 1.0 Received: by 10.152.102.234 with SMTP id fr10mr7944472lab.28.1354498488862; Sun, 02 Dec 2012 17:34:48 -0800 (PST) Sender: bobwyman@gmail.com Received: by 10.114.37.227 with HTTP; Sun, 2 Dec 2012 17:34:48 -0800 (PST) In-Reply-To: References: Date: Sun, 2 Dec 2012 20:34:48 -0500 X-Google-Sender-Auth: rfRplUzrnk984Z4X-npvOWWZmIs Message-ID: From: Bob Wyman To: WebFinger List Content-Type: multipart/alternative; boundary=f46d040712594706de04cfe8c12c Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:34:58 -0000 --f46d040712594706de04cfe8c12c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think this would be unwise. If the spec is filled with mailto: examples, we're going to be dealing for years with people who claim that "WebFinger is for email addresses." No, that will not be a correct reading of the spec, but that is how many will read it. Moving acct:'s definition to a distinct document is no justification for essentially removing acct: from WebFinger. Acct: and WebFinger go together. bob wyman On Sun, Dec 2, 2012 at 8:14 PM, Tim Bray wrote: > I don=92t want to wait for work on this to be completed, and I don=92t th= ink > that its presence is necessary for WebFinger to be useful. So let's take > it out. > > Proposal: > Section 4.1: Change the URI in the example from acct: to mailto: > Section 4.2: Same > Section 5.3: Same > Section 5.4: s/it could be an "acct" URI [7], // > Section 5.4: Remove 2nd para, beginning "For resources associated with a > user account at a host...=93 > Section 5.4: s/both an "acct" URI and any alias/any alias/ > Section 8: Change the URI in the example from acct: to mailto: > > > On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: > >> No, we=92re on the same side here. I=92m suggesting taking webfinger-07 = as a >> baseline, and all *future* changes need to be proposed as a concrete del= ta >> against it. -T >> >> >> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones wr= ote: >> >>> Tim,**** >>> >>> ** ** >>> >>> I didn=92t mean to be rude by introducing these changes, just trying to >>> move things along. Most changes were fairly trivial, not worth mention= ing, >>> and can be seen here:**** >>> >>> >>> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-app= sawg-webfinger-07.txt >>> **** >>> >>> ** ** >>> >>> The most significant changes were the re-write of section 5.2 and >>> modification to the language related to HTTPS in 5.1. I suspect that i= s >>> the text to which you refer as preferring it to be =93camera-ready=94. = (I >>> would assume the balance of the changes would not need to be presented = as >>> =93camera-ready=94, since they=92re minor editorial things.)**** >>> >>> ** ** >>> >>> In any case, the most important text changes I would like folks to >>> consider is section 5.2 (which aims to fully document the JSON Resource >>> Descriptor object) and paragraphs 2 and 3 in section 5.1.**** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> *From:* Tim Bray [mailto:tbray@textuality.com] >>> *Sent:* Sunday, December 02, 2012 2:54 PM >>> *To:* Paul E. Jones >>> *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com >>> *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-07**** >>> >>> ** ** >>> >>> Thanks to Paul for the extra effort. I=92d like to suggest, in the >>> interests of courtesy and efficiency, that from here on on, contributio= ns >>> to this discussion be =93camera-ready=94, that is to say, specific sugg= estions >>> in the style of a diff, including fully-written-out replacements langua= ge. >>> >>> -Tim**** >>> >>> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones >>> wrote:**** >>> >>> Folks,**** >>> >>> **** >>> >>> I published another version of the WebFinger spec trying to bring >>> closure to the two open issues I see (resource representation and >>> transport). The new version is here:**** >>> >>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >>> >>> **** >>> >>> With respect to resource representation, I fully described the JSON >>> Resource Descriptor within the document. There are no external referen= ces >>> to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly >>> simple format and I believe this text documents it sufficiently. Combi= ned >>> with the visual examples, I think this makes it pretty clear. Have a l= ook >>> at the JRD documentation in section 5.2 and provide your comments. **** >>> >>> **** >>> >>> With respect to HTTPS, it seems there is strong preference for =93HTTPS >>> only=94, but some a fair bit of insistence for allowing HTTP. I change= d the >>> wording in 5.2 to try to capture opinions. Previously, the text led wi= th a >>> requirement to try HTTPS first. That is still there. I just added som= e >>> extra conditions that make it clearer that there are some instances whe= re a >>> client must not utilize HTTP. This might need further refinement, but = I >>> think there is a balance we can strike here between the two camps witho= ut >>> introducing a lot of complex language.**** >>> >>> **** >>> >>> I made some editorial changes through the document.**** >>> >>> **** >>> >>> Comments are welcome, as always. Seems I don=92t need to say that to t= his >>> group, though :-)**** >>> >>> **** >>> >>> Paul**** >>> >>> **** >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss**** >>> >>> ** ** >>> >> >> > --f46d040712594706de04cfe8c12c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think this would be unwise. If the spec is filled with mailto: examples, = we're going to be dealing for years with people who claim that "We= bFinger is for email addresses." No, that will not be a correct readin= g of the spec, but that is how many will read it.

Moving acct:'s definition to a distinct document is no j= ustification for essentially removing acct: from WebFinger. Acct: and WebFi= nger go together.

bob wyman


On Sun, Dec 2, 2012 at 8:14 PM, Tim Bray= <tbray@textuality.com> wrote:
I don=92t want to wait for work on this to be completed, and I don=92t thin= k that its presence is necessary for WebFinger to be useful.=A0 So let'= s take it out.

Proposal:
Section 4.1: Change the URI in the examp= le from acct: to mailto:
Section 4.2: Same
Section 5.3: Same
Section 5.4: s/it could be an &qu= ot;acct" URI [7], //
Section 5.4: Remove 2nd para, beginning "= For resources associated with a user account at a host...=93
Section 5.4= : s/both an "acct" URI and any alias/any alias/
Section 8: Change the URI in the example from acct: to mailto:


<= div class=3D"gmail_quote">On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray <tbr= ay@textuality.com> wrote:
No, we=92re on the same side here. I=92m sug= gesting taking webfinger-07 as a baseline, and all *future* changes need to= be proposed as a concrete delta against it.=A0 -T


On Sun, Dec 2, 2012 at 12:59 PM, Pa= ul E. Jones <paulej@packetizer.com> wrote:

Tim,

=A0<= /p>

I didn=92t mean to be = rude by introducing these changes, just trying to move things along.=A0 Mos= t changes were fairly trivial, not worth mentioning, and can be seen here:<= u>

http://tools.ietf.org/rfcdiff?difftype=3D--hwdif= f&url2=3Ddraft-ietf-appsawg-webfinger-07.txt

=A0<= /p>

The most significant c= hanges were the re-write of section 5.2 and modification to the language re= lated to HTTPS in 5.1.=A0 I suspect that is the text to which you refer as = preferring it to be =93camera-ready=94.=A0 (I would assume the balance of t= he changes would not need to be presented as =93camera-ready=94, since they= =92re minor editorial things.)

=A0<= /p>

In any case, the most = important text changes I would like folks to consider is section 5.2 (which= aims to fully document the JSON Resource Descriptor object) and paragraphs= 2 and 3 in section 5.1.

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. Jones<= br>Cc: ap= ps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07

=A0<= /u>

Thanks to Paul= for the extra effort.=A0 I=92d like to suggest, in the interests of courte= sy and efficiency, that from here on on, contributions to this discussion b= e =93camera-ready=94, that is to say, specific suggestions in the style of = a diff, including fully-written-out replacements language.

=A0-Tim

On Sun, Dec 2, 201= 2 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

I published another version of the W= ebFinger spec trying to bring closure to the two open issues I see (resourc= e representation and transport).=A0 The new version is here:<= /p>

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=A0=

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=A0 There are no ex= ternal references to RFC 6415 now, no need to go read the XRD spec, etc. = =A0It=92s a fairly simple format and I believe this text documents it suffi= ciently.=A0 Combined with the visual examples, I think this makes it pretty= clear.=A0 Have a look at the JRD documentation in section 5.2 and provide = your comments.

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)=

=A0

Paul

=A0


_____= __________________________________________
apps-discuss mailing list
= apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=A0




--f46d040712594706de04cfe8c12c-- From ve7jtb@ve7jtb.com Sun Dec 2 17:37:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA7021F893A for ; Sun, 2 Dec 2012 17:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.335 X-Spam-Level: X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwsL4dCjrBIk for ; Sun, 2 Dec 2012 17:37:02 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E46421F890E for ; Sun, 2 Dec 2012 17:37:02 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so355544ggn.31 for ; Sun, 02 Dec 2012 17:37:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=KpSQC9pe9/u1LeXlq/NsyhiLIopkwRo/5zhvNDqCEUE=; b=Fp/ogg+y2Q5RFi5lZoV44RvgmVXceVjdSY5P26a/lwm/RmAhIVbeiCMMyJ9ZE9l8zD r+mWjKuU4eD5U7vopUmRh5YmI7qYnOSbaHmKiI+kAp2DTNG6uMOvWrx1+/sW0D8rhQVz Pp11WX2TREl6E19v+DXt+602xtDXMIgiEpupxHujNqtQCyQModpNUnmfFhyxQDu/Uugd dpzwE6PCp6LIZqClaOh+nrD/Mxe1MQKg5iEJ4vSSNpcJdPznC5qdYtujRVkXsAr8rC7Y Ptqh7uIqi08ELnYjUNtftcC2JL/J+HMiPT6nUvJISz3Q9MtvADnZapF2n2/5L/4XZbWL L26g== Received: by 10.236.9.104 with SMTP id 68mr8847066yhs.89.1354498621774; Sun, 02 Dec 2012 17:37:01 -0800 (PST) Received: from [192.168.1.211] (190-20-29-186.baf.movistar.cl. [190.20.29.186]) by mx.google.com with ESMTPS id k63sm11799885yhj.20.2012.12.02.17.36.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 17:37:00 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Sun, 2 Dec 2012 22:36:50 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkdjuOz58BYsSDqbV0PasFhy1z5ihVyXW43RAL5HQ306UaKiEBOeEZLDli5CnRGW2XI6+tq Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:37:02 -0000 Of the two proposals Tim has submitted on this, this is my clear = preference. I may be able to live with the other. Not news to anyone I expect. =20 This is simpler to code for clients and will have fewer interoperability = issues. John B. On 2012-12-02, at 10:15 PM, Tim Bray wrote: > Proposal: Change para 2 of section 5.2 to read as follows: >=20 > Clients MUST query the server using HTTPS. If an HTTPS connection = cannot be established, or returns an HTTP status code indicating some = error, such as 4xx or 5xx, the client MUST report an error and MUST = cease attempting to retrieve the resource. >=20 From ve7jtb@ve7jtb.com Sun Dec 2 17:52:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119EB21F8919 for ; Sun, 2 Dec 2012 17:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.343 X-Spam-Level: X-Spam-Status: No, score=-3.343 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDE26Yt3keqD for ; Sun, 2 Dec 2012 17:52:11 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABABB21F8918 for ; Sun, 2 Dec 2012 17:52:11 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id r14so359816yen.31 for ; Sun, 02 Dec 2012 17:52:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=+W2O4DdeO/MRaqO2FVGk7p18jQ7xdfcf0WocXkkueUg=; b=e8kQhgKTPOBRoDZB3fr4GqxXDrDZ6mDgYVK8R0MjiVZpoznb/WLPo8wiJVmeb2Am0e LV+XBBcv08XAd3q3TKtA4IuoAMTcOdyNIk/KBf7Po81L81gTeKvTlUfgoK8r/VX4kWsk T3SgF293wNgXPHL6lGir1m+z9vm6cjdfoYKbPcftLOVVoW1rk018MP535dUdQSY4j/Ma 6ZnHCXjn5+VJ9mt+bgxCmXf0UPwVDTn9yopW1LH9rTN3Z3LV2rBw3M/PyEP3Dwh8mFLP EKVsBSrizoTr20h2DAJHadPYFdJ+IkBXp6jcuclsXHueOEUoK0lvaRbm+l4gydI7KD2t ARDA== Received: by 10.236.188.200 with SMTP id a48mr5339844yhn.62.1354499526790; Sun, 02 Dec 2012 17:52:06 -0800 (PST) Received: from [192.168.1.211] (190-20-29-186.baf.movistar.cl. [190.20.29.186]) by mx.google.com with ESMTPS id s30sm11831596yhl.21.2012.12.02.17.52.00 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 17:52:03 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5622C1D5-3E75-4501-9D1C-22CCC06753EF" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Sun, 2 Dec 2012 22:51:53 -0300 Message-Id: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> References: To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlODSsYh/XRjyjXmdGEX/9+BIbhdu+hZdrerJsbhZUY7VhrhXcMjVDl03U5TWcgp8/q/58K Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:52:13 -0000 --Apple-Mail=_5622C1D5-3E75-4501-9D1C-22CCC06753EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree that WF is not just about email. A question ( perhaps channeling Blane) is if it should only be about = acct: for simplicity. As an example should we be expecting it to resolve xmpp: tel: or other = things. =20 For http: and https: scheme URI perhaps link headers pointing to a acct: = relation are the most appropriate. WF is about having a identifier in User Principal name (UPN) form where = the principal is a domain and finding the JRD document or documents for = that account. There is a bunch of hedging that it can work with any URI but that may = just be confusing the issue. My personal preference t this point (others working on openID Connect = may well disagree) is to go all in on acct: and just admit that WF is = the resolution process for those URI. That is what most people think of it as anyway. John B. On 2012-12-02, at 10:35 PM, Brad Fitzpatrick = wrote: > -1. I feel strongly for keeping the acct: scheme. WebFinger isn't = just about email. >=20 > On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > I don=92t want to wait for work on this to be completed, and I don=92t = think that its presence is necessary for WebFinger to be useful. So = let's take it out. >=20 > Proposal: > Section 4.1: Change the URI in the example from acct: to mailto: > Section 4.2: Same > Section 5.3: Same > Section 5.4: s/it could be an "acct" URI [7], // > Section 5.4: Remove 2nd para, beginning "For resources associated with = a user account at a host...=93 > Section 5.4: s/both an "acct" URI and any alias/any alias/ > Section 8: Change the URI in the example from acct: to mailto: >=20 >=20 > On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: > No, we=92re on the same side here. I=92m suggesting taking = webfinger-07 as a baseline, and all *future* changes need to be proposed = as a concrete delta against it. -T >=20 >=20 > On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones = wrote: > Tim, >=20 > =20 >=20 > I didn=92t mean to be rude by introducing these changes, just trying = to move things along. Most changes were fairly trivial, not worth = mentioning, and can be seen here: >=20 > = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-appsaw= g-webfinger-07.txt >=20 > =20 >=20 > The most significant changes were the re-write of section 5.2 and = modification to the language related to HTTPS in 5.1. I suspect that is = the text to which you refer as preferring it to be =93camera-ready=94. = (I would assume the balance of the changes would not need to be = presented as =93camera-ready=94, since they=92re minor editorial = things.) >=20 > =20 >=20 > In any case, the most important text changes I would like folks to = consider is section 5.2 (which aims to fully document the JSON Resource = Descriptor object) and paragraphs 2 and 3 in section 5.1. >=20 > =20 >=20 > Paul >=20 > =20 >=20 > From: Tim Bray [mailto:tbray@textuality.com]=20 > Sent: Sunday, December 02, 2012 2:54 PM > To: Paul E. Jones > Cc: apps-discuss@ietf.org; webfinger@googlegroups.com > Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 >=20 > =20 >=20 > Thanks to Paul for the extra effort. I=92d like to suggest, in the = interests of courtesy and efficiency, that from here on on, = contributions to this discussion be =93camera-ready=94, that is to say, = specific suggestions in the style of a diff, including fully-written-out = replacements language. >=20 > -Tim >=20 > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: >=20 > Folks, >=20 > =20 >=20 > I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: >=20 > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 >=20 > =20 >=20 > With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. It=92s = a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments. >=20 > =20 >=20 > With respect to HTTPS, it seems there is strong preference for =93HTTPS = only=94, but some a fair bit of insistence for allowing HTTP. I changed = the wording in 5.2 to try to capture opinions. Previously, the text led = with a requirement to try HTTPS first. That is still there. I just = added some extra conditions that make it clearer that there are some = instances where a client must not utilize HTTP. This might need further = refinement, but I think there is a balance we can strike here between = the two camps without introducing a lot of complex language. >=20 > =20 >=20 > I made some editorial changes through the document. >=20 > =20 >=20 > Comments are welcome, as always. Seems I don=92t need to say that to = this group, though :-) >=20 > =20 >=20 > Paul >=20 > =20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > =20 >=20 >=20 >=20 >=20 --Apple-Mail=_5622C1D5-3E75-4501-9D1C-22CCC06753EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = agree that WF is not just about email.

A question ( = perhaps channeling Blane) is if it should only be about acct: for = simplicity.

As an example should we be = expecting it to resolve xmpp:  tel:  or other things. =   
For http: and https: scheme URI perhaps link = headers pointing to a acct: relation are the most = appropriate.

WF is about having a identifier in = User Principal name (UPN)  form where the principal is a domain and = finding the JRD document or documents for that = account.

There is a bunch of hedging that it = can work with any URI but that may just be confusing the = issue.

My personal preference t this point = (others working on openID Connect may well disagree) is to go all in on = acct: and just admit that WF is the resolution process for those = URI.

That is what most people think of it as = anyway.

John = B.


On 2012-12-02, at 10:35 PM, = Brad Fitzpatrick <bradfitz@google.com> = wrote:

-1.  I feel strongly for keeping the acct: scheme. =  WebFinger isn't just about email.

On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray <tbray@textuality.com> wrote:
I don=92t want to wait = for work on this to be completed, and I don=92t think that its presence = is necessary for WebFinger to be useful.  So let's take it out.

Proposal:
Section 4.1: Change the URI in the example from acct: = to mailto:
Section 4.2: Same
Section 5.3: Same
Section 5.4: s/it could be an = "acct" URI [7], //
Section 5.4: Remove 2nd para, beginning "For = resources associated with a user account at a host...=93
Section 5.4: = s/both an "acct" URI and any alias/any alias/
Section 8: Change the URI in the example from acct: to = mailto:


On Sun, Dec 2, 2012 at = 1:57 PM, Tim Bray <tbray@textuality.com> wrote:
No, we=92re on the = same side here. I=92m suggesting taking webfinger-07 as a baseline, and = all *future* changes need to be proposed as a concrete delta against = it.  -T


On Sun, Dec 2, 2012 at 12:59 PM, = Paul E. Jones <paulej@packetizer.com> wrote:

Tim,

 

I didn=92t mean to be rude by introducing these = changes, just trying to move things along.  Most changes were = fairly trivial, not worth mentioning, and can be seen = here:

http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&ur= l2=3Ddraft-ietf-appsawg-webfinger-07.txt

 

The most significant changes were the re-write of = section 5.2 and modification to the language related to HTTPS in = 5.1.  I suspect that is the text to which you refer as preferring = it to be =93camera-ready=94.  (I would assume the balance of the = changes would not need to be presented as =93camera-ready=94, since = they=92re minor editorial things.)

 

In any case, the most important text changes I = would like folks to consider is section 5.2 (which aims to fully = document the JSON Resource Descriptor object) and paragraphs 2 and 3 in = section 5.1.

 

Paul

 

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. = Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] = draft-ietf-appsawg-webfinger-07

<= p class=3D"MsoNormal"> 

Thanks to Paul for the extra = effort.  I=92d like to suggest, in the interests of courtesy and = efficiency, that from here on on, contributions to this discussion be = =93camera-ready=94, that is to say, specific suggestions in the style of = a diff, including fully-written-out replacements language.

 -Tim

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,

 

I = published another version of the WebFinger spec trying to bring closure = to the two open issues I see (resource representation and = transport).  The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-= 07

 

With respect to resource representation, I fully = described the JSON Resource Descriptor within the document.  There = are no external references to RFC 6415 now, no need to go read the XRD = spec, etc.  It=92s a fairly simple format and I believe this text = documents it sufficiently.  Combined with the visual examples, I = think this makes it pretty clear.  Have a look at the JRD = documentation in section 5.2 and provide your comments. =

 

With respect to HTTPS, it seems there is strong = preference for =93HTTPS only=94, but some a fair bit of insistence for = allowing HTTP.  I changed the wording in 5.2 to try to capture = opinions.  Previously, the text led with a requirement to try HTTPS = first.  That is still there.  I just added some extra = conditions that make it clearer that there are some instances where a = client must not utilize HTTP.  This might need further refinement, = but I think there is a balance we can strike here between the two camps = without introducing a lot of complex language.

 

I = made some editorial changes through the document.

 

Comments are welcome, as always.  Seems I don=92t= need to say that to this group, though :-)

 

Paul

 


_______________________________________= ________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

 





= --Apple-Mail=_5622C1D5-3E75-4501-9D1C-22CCC06753EF-- From mnot@mnot.net Sun Dec 2 18:39:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2DC21F8942 for ; Sun, 2 Dec 2012 18:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.084 X-Spam-Level: X-Spam-Status: No, score=-104.084 tagged_above=-999 required=5 tests=[AWL=-1.485, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROYw6WGYszba for ; Sun, 2 Dec 2012 18:39:27 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id C175621F8932 for ; Sun, 2 Dec 2012 18:39:27 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2F3DC509B5; Sun, 2 Dec 2012 21:39:22 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115028CD4FD@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 3 Dec 2012 13:39:25 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <05CB04C6-A7CD-4C56-8050-45EF788DD5E0@mnot.net> References: <50BB20B3.8010403@skoegl.net> <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CD4FD@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: Apps Discuss Subject: Re: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 02:39:28 -0000 On 03/12/2012, at 11:56 AM, "Manger, James H" = wrote: >=20 > It is extensible. > To define new functionality that must not be ignored you can define a = new operation. > To define new functionality that can be safely ignored by old = implementations you can define new members for existing operations. >=20 > For instance, to define a test of the type of a JSON value you could = define a new operations: > { "op":"test2", "path":"/a/b/c", "type":[] } -- true iff the value = at the given path is an array That's not a backwards-compatible extension; it fundamentally changes = the semantics of the document, and an implementation that ignores it may = PATCH when it shouldn't. > Some extra text to document this would be good. Perhaps change the 1st = paragraph of section 4 "Operations": >=20 > <--from-- > Operation objects MUST have exactly one "op" member, whose value > indicates the operation to perform. Its value MUST be one of "add", > "remove", "replace", "move", "copy" or "test". The semantics of = each > is defined below. > --to--> > Operation objects MUST have exactly one "op" member, whose value > indicates the operation to perform. The semantics are defined below > for the values "add", "remove", "replace", "move", "copy" and = "test". > It is an error if the value is not recognized. New operations can > be defined by RFCs that update this document. > -- We explicitly agreed to the text before -- i.e., that the set of = operations defined by this format is closed. > * The "replace" and "move" operations contain the note >>>=20 >>>> The target location MUST exist for the operation to be successful. >>>=20 >>> which is clear in the context. The "move" and "copy" operations do >>> not contain such a statement even though they proably should. Also = if >>> they did, the term "target location" would be ambiguous, because it >>> could also refer to the "to" value. >>>=20 >>> I'd suggest to use a different term for whatever "path" refers to, >>> and add the statement to all operators to which it applies. >>=20 >>=20 >> (I think he means *re*move, not move in the first line above) >>=20 >> I tend to agree on both counts. >>=20 >> Is there any objecting to adding this clause to "move" and "copy"? >>=20 >> Regarding the term, how about "path location"? >=20 >=20 > I thought "path" was being replaced with "from" and "to" as = appropriate to the operation. "from" refers to a location in the = existing value; "to" refers to a location in the patched value (which = will often not exist in the existing value). No. In the current draft, *all* operations have "path", and it always = refers to the place that the operation affects (where appropriate, = "to"). In operations where there are two relevant locations, the second = location is now always "from"; it used to be "to", but that didn't align = with the semantics of the other, one-location operations well. > [I still think we should ditch the statements that "The target = location MUST exist for the operation to be successful". Better to = define a sensible "successful" result (eg "remove" is a no-op if "from" = does not exist; "move" is equivalent to "remove" on the "from" and "to" = locations then, if there was a value at "from", an "add" operation; = "replace" is equivalent to "remove" then "add" operations).] The point of this statement in the "remove" and "replace" operations is = that if the target isn't there, the patch is probably not written with = the state of the document in mind, and should fail. Contrast with "add" = (where the intent was to allow authors to add-or-update). For "move" and "copy" it also seems like a good idea, because if you run = a patch and the source of one of these operations isn't existent, you = definitely don't know what state the document is in, and the patch = should fail. -- Mark Nottingham http://www.mnot.net/ From dick.hardt@gmail.com Sun Dec 2 19:08:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BD221F8974 for ; Sun, 2 Dec 2012 19:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfB1SZKwWXmR for ; Sun, 2 Dec 2012 19:08:49 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id E51F021F8973 for ; Sun, 2 Dec 2012 19:08:48 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1462983pad.31 for ; Sun, 02 Dec 2012 19:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=NLFntX7Pq2Y7GUcCKpqKz6/SnLk7uFOm0jz9g96ZoBk=; b=BkT4zv0KrCp9hbUXLEP37WYfvTcZlP4h97PA19ymUE7+MNIr2SqdBa5we0FgGHs6MR /7N2RsSeKq1gN+mUyvJUjJqIIfEQ5l90PeIk6IVtxtL44yQp1vKJQbn7oOcW0QOGa2Co 1XYQ+uaMyy4lEsMoKVeYrRnFs7sQEjnAuQ3QgFLzI6TMBS9473C2AgiyIwuNXf7NhvyH AoJgjRyYFXcDhYAZ1+Jux2/9ICCDpi4qtqxmt9VoopsPeAh55cM44vdydBNjYrP+xjts 0nZiI5F/wNZBYYwWku2WISYiPslbwqwWBSALB4TqZKBfAWge02c5s8u5YVdIq/WL3Pys rOMg== Received: by 10.68.237.6 with SMTP id uy6mr25088693pbc.147.1354504128733; Sun, 02 Dec 2012 19:08:48 -0800 (PST) Received: from [192.168.3.101] (airnode1222.air-internet.com. [12.110.33.210]) by mx.google.com with ESMTPS id ak10sm7226314pbd.24.2012.12.02.19.08.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 19:08:44 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_156BA09A-6779-481A-828C-BF3E5D385D26" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Sun, 2 Dec 2012 19:08:39 -0800 Message-Id: References: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 03:08:50 -0000 --Apple-Mail=_156BA09A-6779-481A-828C-BF3E5D385D26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I share Brad's opinion. On Dec 2, 2012, at 6:03 PM, Brad Fitzpatrick = wrote: > I would be fine with acct:-only, but I also don't really care whether = any URI is accepted. >=20 > Little bit more simplicity vs future generality. I'll let people who = feel more strongly decide this. I only feel strongly that we say = "acct:" and not "mailto:". >=20 >=20 > On Sun, Dec 2, 2012 at 5:51 PM, John Bradley = wrote: > I agree that WF is not just about email. >=20 > A question ( perhaps channeling Blane) is if it should only be about = acct: for simplicity. >=20 > As an example should we be expecting it to resolve xmpp: tel: or = other things. =20 > For http: and https: scheme URI perhaps link headers pointing to a = acct: relation are the most appropriate. >=20 > WF is about having a identifier in User Principal name (UPN) form = where the principal is a domain and finding the JRD document or = documents for that account. >=20 > There is a bunch of hedging that it can work with any URI but that may = just be confusing the issue. >=20 > My personal preference t this point (others working on openID Connect = may well disagree) is to go all in on acct: and just admit that WF is = the resolution process for those URI. >=20 > That is what most people think of it as anyway. >=20 > John B. >=20 >=20 > On 2012-12-02, at 10:35 PM, Brad Fitzpatrick = wrote: >=20 >> -1. I feel strongly for keeping the acct: scheme. WebFinger isn't = just about email. >>=20 >> On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray = wrote: >> I don=92t want to wait for work on this to be completed, and I don=92t = think that its presence is necessary for WebFinger to be useful. So = let's take it out. >>=20 >> Proposal: >> Section 4.1: Change the URI in the example from acct: to mailto: >> Section 4.2: Same >> Section 5.3: Same >> Section 5.4: s/it could be an "acct" URI [7], // >> Section 5.4: Remove 2nd para, beginning "For resources associated = with a user account at a host...=93 >> Section 5.4: s/both an "acct" URI and any alias/any alias/ >> Section 8: Change the URI in the example from acct: to mailto: >>=20 >>=20 >> On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray = wrote: >> No, we=92re on the same side here. I=92m suggesting taking = webfinger-07 as a baseline, and all *future* changes need to be proposed = as a concrete delta against it. -T >>=20 >>=20 >> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones = wrote: >> Tim, >>=20 >> =20 >>=20 >> I didn=92t mean to be rude by introducing these changes, just trying = to move things along. Most changes were fairly trivial, not worth = mentioning, and can be seen here: >>=20 >> = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-appsaw= g-webfinger-07.txt >>=20 >> =20 >>=20 >> The most significant changes were the re-write of section 5.2 and = modification to the language related to HTTPS in 5.1. I suspect that is = the text to which you refer as preferring it to be =93camera-ready=94. = (I would assume the balance of the changes would not need to be = presented as =93camera-ready=94, since they=92re minor editorial = things.) >>=20 >> =20 >>=20 >> In any case, the most important text changes I would like folks to = consider is section 5.2 (which aims to fully document the JSON Resource = Descriptor object) and paragraphs 2 and 3 in section 5.1. >>=20 >> =20 >>=20 >> Paul >>=20 >> =20 >>=20 >> From: Tim Bray [mailto:tbray@textuality.com]=20 >> Sent: Sunday, December 02, 2012 2:54 PM >> To: Paul E. Jones >> Cc: apps-discuss@ietf.org; webfinger@googlegroups.com >> Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 >>=20 >> =20 >>=20 >> Thanks to Paul for the extra effort. I=92d like to suggest, in the = interests of courtesy and efficiency, that from here on on, = contributions to this discussion be =93camera-ready=94, that is to say, = specific suggestions in the style of a diff, including fully-written-out = replacements language. >>=20 >> -Tim >>=20 >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: >>=20 >> Folks, >>=20 >> =20 >>=20 >> I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: >>=20 >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 >>=20 >> =20 >>=20 >> With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. It=92s = a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments. >>=20 >> =20 >>=20 >> With respect to HTTPS, it seems there is strong preference for =93HTTPS= only=94, but some a fair bit of insistence for allowing HTTP. I = changed the wording in 5.2 to try to capture opinions. Previously, the = text led with a requirement to try HTTPS first. That is still there. I = just added some extra conditions that make it clearer that there are = some instances where a client must not utilize HTTP. This might need = further refinement, but I think there is a balance we can strike here = between the two camps without introducing a lot of complex language. >>=20 >> =20 >>=20 >> I made some editorial changes through the document. >>=20 >> =20 >>=20 >> Comments are welcome, as always. Seems I don=92t need to say that to = this group, though :-) >>=20 >> =20 >>=20 >> Paul >>=20 >> =20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> =20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_156BA09A-6779-481A-828C-BF3E5D385D26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = share Brad's opinion.

On Dec 2, 2012, at 6:03 PM, Brad = Fitzpatrick <bradfitz@google.com> = wrote:

I would be fine with acct:-only, but I also don't = really care whether any URI is accepted.

Little bit = more simplicity vs future generality.  I'll let people who feel = more strongly decide this.  I only feel strongly that we say = "acct:" and not "mailto:".


On Sun, = Dec 2, 2012 at 5:51 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I agree that WF is not just about = email.

A question ( perhaps channeling Blane) is if = it should only be about acct: for simplicity.

As an example should we be expecting it to resolve = xmpp:  tel:  or other things.   
For http: = and https: scheme URI perhaps link headers pointing to a acct: relation = are the most appropriate.

WF is about having a identifier in User Principal = name (UPN)  form where the principal is a domain and finding the = JRD document or documents for that = account.

There is a bunch of hedging that it = can work with any URI but that may just be confusing the issue.

My personal preference t this point (others working = on openID Connect may well disagree) is to go all in on acct: and just = admit that WF is the resolution process for those = URI.

That is what most people think of it as = anyway.

John B.


On 2012-12-02, at 10:35 = PM, Brad Fitzpatrick <bradfitz@google.com> wrote:

-1. =  I feel strongly for keeping the acct: scheme.  WebFinger = isn't just about email.

On Sun, Dec 2, = 2012 at 5:14 PM, Tim Bray <tbray@textuality.com> wrote:
I don=92t want to wait = for work on this to be completed, and I don=92t think that its presence = is necessary for WebFinger to be useful.  So let's take it out.

Proposal:
Section 4.1: Change the URI in the example from acct: = to mailto:
Section 4.2: Same
Section 5.3: Same
Section 5.4: s/it could be an = "acct" URI [7], //
Section 5.4: Remove 2nd para, beginning "For = resources associated with a user account at a host...=93
Section 5.4: = s/both an "acct" URI and any alias/any alias/
Section 8: Change the URI in the example from acct: to = mailto:


On Sun, Dec 2, 2012 at = 1:57 PM, Tim Bray <tbray@textuality.com> wrote:
No, we=92re on the = same side here. I=92m suggesting taking webfinger-07 as a baseline, and = all *future* changes need to be proposed as a concrete delta against = it.  -T


On Sun, Dec 2, 2012 at 12:59 PM, = Paul E. Jones <paulej@packetizer.com> wrote:

Tim,

 

I didn=92t mean to be rude by introducing these = changes, just trying to move things along.  Most changes were = fairly trivial, not worth mentioning, and can be seen = here:

http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&ur= l2=3Ddraft-ietf-appsawg-webfinger-07.txt

 

The most significant changes were the re-write of = section 5.2 and modification to the language related to HTTPS in = 5.1.  I suspect that is the text to which you refer as preferring = it to be =93camera-ready=94.  (I would assume the balance of the = changes would not need to be presented as =93camera-ready=94, since = they=92re minor editorial things.)

 

In any case, the most important text changes I = would like folks to consider is section 5.2 (which aims to fully = document the JSON Resource Descriptor object) and paragraphs 2 and 3 in = section 5.1.

 

Paul

 

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. = Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] = draft-ietf-appsawg-webfinger-07

<= p class=3D"MsoNormal"> 

Thanks to Paul for the extra = effort.  I=92d like to suggest, in the interests of courtesy and = efficiency, that from here on on, contributions to this discussion be = =93camera-ready=94, that is to say, specific suggestions in the style of = a diff, including fully-written-out replacements language.

 -Tim

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,

 

I published another version of the WebFinger spec = trying to bring closure to the two open issues I see (resource = representation and transport).  The new version is = here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-= 07

 

With respect to resource representation, I fully = described the JSON Resource Descriptor within the document.  There = are no external references to RFC 6415 now, no need to go read the XRD = spec, etc.  It=92s a fairly simple format and I believe this text = documents it sufficiently.  Combined with the visual examples, I = think this makes it pretty clear.  Have a look at the JRD = documentation in section 5.2 and provide your comments. =

 

With respect to HTTPS, it seems there is strong = preference for =93HTTPS only=94, but some a fair bit of insistence for = allowing HTTP.  I changed the wording in 5.2 to try to capture = opinions.  Previously, the text led with a requirement to try HTTPS = first.  That is still there.  I just added some extra = conditions that make it clearer that there are some instances where a = client must not utilize HTTP.  This might need further refinement, = but I think there is a balance we can strike here between the two camps = without introducing a lot of complex language.

 

I = made some editorial changes through the document.

 

Comments are welcome, as always.  Seems I don=92t= need to say that to this group, though :-)

 

Paul

 


_______________________________________= ________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

 




=



= --Apple-Mail=_156BA09A-6779-481A-828C-BF3E5D385D26-- From paulej@packetizer.com Sun Dec 2 19:11:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E3621F892B for ; Sun, 2 Dec 2012 19:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvPnBfSkk+7c for ; Sun, 2 Dec 2012 19:11:50 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5CA21F8920 for ; Sun, 2 Dec 2012 19:11:50 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB33Bl3X001314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Dec 2012 22:11:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354504308; bh=pEHbAoZ81Du8BEmg6FcgPATEDsEQZTfbH12OtFvvJPg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=aAXdTWiGdIrNUquXPJF/zCRYZgkwnfjgexluY0gDq9k+cVXQ7xC4o+8PfMrSottWf ayH4xQqQNPQsDeKjMhv6CetbBLmZ9N1rkeZDRJ/B3NWk1Tiokm1aV/b6PvsROxy5hv 8oCt1OLaNZug9jaN+ANigW+2x3QazqnMI5U768u0= From: "Paul E. Jones" To: "'Dick Hardt'" , References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> In-Reply-To: <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> Date: Sun, 2 Dec 2012 22:11:46 -0500 Message-ID: <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLrZ2Se+xCQ1wKSSFBTHovI4rJ73wIvNloxAedIuXAA9cPVgQKCxNrpAaoig/sCH1k1jwGrYWq2AipsKXMChR/lCwF99wDGAxHsnkIB0G8+1AJOdXLAAQVCTGcCX/geEwG3Q8YrAYVGlZ8BXNkqhgIFo/A/AZVXZBECa7jIOgJPc/d9AXtstykB3Uji3QIHfXp5Ak3EinGUN/ChwA== Content-Language: en-us Cc: 'Joseph Holsten' , apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 03:11:51 -0000 Dick, I can imagine university networks and even some businesses that would utilize WebFinger for internal purposes where security is not essential. If WF takes off, then there might be millions of domains out there that provide WF services. What percentage of those might use WF in scenarios where security is important? If WF is used to auto-provision an email client or direct a user to log into an IdP, then I can appreciate a need to use TLS. So, in applications where TLS is really needed, I would not bother with attempting a request via HTTP. Example uses where HTTP is probably "good enough": * Clicking on acct:paulej@packetizer.com in my browser and having a "profile" page produced that contains whatever information that is found (e.g., a picture, contact info, blog, web site) * Clicking on the sender's name in an email client to fetch the person's vcard, picture, or other. * Fetching a user's picture when he or she posts something on a web site (I assume that the user has an account at the web site and the site has verified the user's email address) I appreciate that the client code will be made a little more complex, but the effort is not really more than handling a 3xx redirection. I'm not arguing strongly either way, though. I could put the mandate in for TLS, but there are other folks who want to allow plain ol' HTTP. They've spoken on the list. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Dick Hardt > Sent: Sunday, December 02, 2012 10:00 AM > To: webfinger@googlegroups.com > Cc: apps-discuss@ietf.org; 'Joseph Holsten' > Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP > > > On Dec 2, 2012, at 12:30 AM, "Paul E. Jones" > wrote: > > In any case, the current document encourage use of HTTPS. But, it > > still allows for HTTP and I can see some valid cases for it. > > What are the avid use cases? > > Keep in mind we are adding complexity to clients by allowing both, so > there is a real cost to allowing both. I'm not clear what we are losing > by HTTPS-only > > -- Dick > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From gsalguei@cisco.com Sun Dec 2 19:14:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7223F21F8977 for ; Sun, 2 Dec 2012 19:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSU0TMrDPUYX for ; Sun, 2 Dec 2012 19:14:41 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6F34621F892B for ; Sun, 2 Dec 2012 19:14:41 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB33EeeO021329 for ; Sun, 2 Dec 2012 22:14:40 -0500 (EST) Received: from rtp-gsalguei-89111.cisco.com (rtp-gsalguei-89111.cisco.com [10.116.132.60]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB33Edxx000443; Sun, 2 Dec 2012 22:14:39 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Gonzalo Salgueiro In-Reply-To: Date: Sun, 2 Dec 2012 22:14:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9280C999-C0D5-443F-BFAF-4780B2846075@cisco.com> References: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1283) Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 03:14:42 -0000 +1 on going with acct: --G On Dec 2, 2012, at 10:08 PM, Dick Hardt wrote: > I share Brad's opinion. >=20 > On Dec 2, 2012, at 6:03 PM, Brad Fitzpatrick = wrote: >=20 >> I would be fine with acct:-only, but I also don't really care whether = any URI is accepted. >>=20 >> Little bit more simplicity vs future generality. I'll let people who = feel more strongly decide this. I only feel strongly that we say = "acct:" and not "mailto:". >>=20 >>=20 >> On Sun, Dec 2, 2012 at 5:51 PM, John Bradley = wrote: >> I agree that WF is not just about email. >>=20 >> A question ( perhaps channeling Blane) is if it should only be about = acct: for simplicity. >>=20 >> As an example should we be expecting it to resolve xmpp: tel: or = other things. =20 >> For http: and https: scheme URI perhaps link headers pointing to a = acct: relation are the most appropriate. >>=20 >> WF is about having a identifier in User Principal name (UPN) form = where the principal is a domain and finding the JRD document or = documents for that account. >>=20 >> There is a bunch of hedging that it can work with any URI but that = may just be confusing the issue. >>=20 >> My personal preference t this point (others working on openID Connect = may well disagree) is to go all in on acct: and just admit that WF is = the resolution process for those URI. >>=20 >> That is what most people think of it as anyway. >>=20 >> John B. >>=20 >>=20 >> On 2012-12-02, at 10:35 PM, Brad Fitzpatrick = wrote: >>=20 >>> -1. I feel strongly for keeping the acct: scheme. WebFinger isn't = just about email. >>>=20 >>> On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray = wrote: >>> I don=92t want to wait for work on this to be completed, and I don=92t= think that its presence is necessary for WebFinger to be useful. So = let's take it out. >>>=20 >>> Proposal: >>> Section 4.1: Change the URI in the example from acct: to mailto: >>> Section 4.2: Same >>> Section 5.3: Same >>> Section 5.4: s/it could be an "acct" URI [7], // >>> Section 5.4: Remove 2nd para, beginning "For resources associated = with a user account at a host...=93 >>> Section 5.4: s/both an "acct" URI and any alias/any alias/ >>> Section 8: Change the URI in the example from acct: to mailto: >>>=20 >>>=20 >>> On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray = wrote: >>> No, we=92re on the same side here. I=92m suggesting taking = webfinger-07 as a baseline, and all *future* changes need to be proposed = as a concrete delta against it. -T >>>=20 >>>=20 >>> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones = wrote: >>> Tim, >>>=20 >>> =20 >>>=20 >>> I didn=92t mean to be rude by introducing these changes, just trying = to move things along. Most changes were fairly trivial, not worth = mentioning, and can be seen here: >>>=20 >>> = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-appsaw= g-webfinger-07.txt >>>=20 >>> =20 >>>=20 >>> The most significant changes were the re-write of section 5.2 and = modification to the language related to HTTPS in 5.1. I suspect that is = the text to which you refer as preferring it to be =93camera-ready=94. = (I would assume the balance of the changes would not need to be = presented as =93camera-ready=94, since they=92re minor editorial = things.) >>>=20 >>> =20 >>>=20 >>> In any case, the most important text changes I would like folks to = consider is section 5.2 (which aims to fully document the JSON Resource = Descriptor object) and paragraphs 2 and 3 in section 5.1. >>>=20 >>> =20 >>>=20 >>> Paul >>>=20 >>> =20 >>>=20 >>> From: Tim Bray [mailto:tbray@textuality.com]=20 >>> Sent: Sunday, December 02, 2012 2:54 PM >>> To: Paul E. Jones >>> Cc: apps-discuss@ietf.org; webfinger@googlegroups.com >>> Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 >>>=20 >>> =20 >>>=20 >>> Thanks to Paul for the extra effort. I=92d like to suggest, in the = interests of courtesy and efficiency, that from here on on, = contributions to this discussion be =93camera-ready=94, that is to say, = specific suggestions in the style of a diff, including fully-written-out = replacements language. >>>=20 >>> -Tim >>>=20 >>> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: >>>=20 >>> Folks, >>>=20 >>> =20 >>>=20 >>> I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 >>>=20 >>> =20 >>>=20 >>> With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. It=92s = a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments. >>>=20 >>> =20 >>>=20 >>> With respect to HTTPS, it seems there is strong preference for = =93HTTPS only=94, but some a fair bit of insistence for allowing HTTP. = I changed the wording in 5.2 to try to capture opinions. Previously, = the text led with a requirement to try HTTPS first. That is still = there. I just added some extra conditions that make it clearer that = there are some instances where a client must not utilize HTTP. This = might need further refinement, but I think there is a balance we can = strike here between the two camps without introducing a lot of complex = language. >>>=20 >>> =20 >>>=20 >>> I made some editorial changes through the document. >>>=20 >>> =20 >>>=20 >>> Comments are welcome, as always. Seems I don=92t need to say that = to this group, though :-) >>>=20 >>> =20 >>>=20 >>> Paul >>>=20 >>> =20 >>>=20 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>> =20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 From dick.hardt@gmail.com Sun Dec 2 19:25:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355FF21F896A for ; Sun, 2 Dec 2012 19:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqWZrwyTGlwn for ; Sun, 2 Dec 2012 19:25:05 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF1021F8967 for ; Sun, 2 Dec 2012 19:25:05 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1014034dae.31 for ; Sun, 02 Dec 2012 19:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=RUGJw9+My6ciyicYSCyLMPEXIHwGMCdVp2FCXNLZZoI=; b=ObCpJ/9JIDP4msjGv0Faqt+1fSzlCgIKa4uzrFw6AiccD8gweG8f/L41A9pz4/RiIx wyc2AxSG26/0Yr2iqIcLQmpqinQNN2wsyg5UrQq12+6iPAKcrhuUNF5IWJ6bp/UpSFTo JVt/8yYA2QynEeIzA9CtrwHPbKqAkt4u6bTmYNyzTrcSA82dj0bGWLj6GjamX+VuFQhv jRDGL2jTkdWmSFxIsUL/ry9mPnGMoV0z+960N+J97IK1gpzSsaHwWAzPtkeVfGQaD4oi gHvgVOpFdQxA/7WGP4dwQ0GyYSGnN6iFDxuw9ozkF2o5VTLLnqmb+9XSccSmRV5RnJJJ 3u0g== Received: by 10.68.232.195 with SMTP id tq3mr25718073pbc.70.1354505105277; Sun, 02 Dec 2012 19:25:05 -0800 (PST) Received: from [192.168.3.101] (airnode1222.air-internet.com. [12.110.33.210]) by mx.google.com with ESMTPS id d8sm297503pax.23.2012.12.02.19.24.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 19:25:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> Date: Sun, 2 Dec 2012 19:24:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) Cc: 'Joseph Holsten' , webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 03:25:06 -0000 Hi Paul I agree there are many use cases where the security is not essential. My question was what do we lose by requiring TLS?=20 I know we are adding complexity to server implementations, but what else = are we losing? As for dealing with a 3XX redirect, many client libraries will do that = automagically for you.=20 There is a real latency and extra code in dealing with the fallback as = currently specified. For example, we lose being able to use a simple CURL command to get a = JRD. Again, what are we losing by HTTPS only? A pro and con list would be = helpful. -- Dick On Dec 2, 2012, at 7:11 PM, "Paul E. Jones" = wrote: > Dick, >=20 > I can imagine university networks and even some businesses that would > utilize WebFinger for internal purposes where security is not = essential. >=20 > If WF takes off, then there might be millions of domains out there = that > provide WF services. What percentage of those might use WF in = scenarios > where security is important? If WF is used to auto-provision an email > client or direct a user to log into an IdP, then I can appreciate a = need to > use TLS. So, in applications where TLS is really needed, I would not = bother > with attempting a request via HTTP. >=20 > Example uses where HTTP is probably "good enough": > * Clicking on acct:paulej@packetizer.com in my browser and having > a "profile" page produced that contains whatever information > that is found (e.g., a picture, contact info, blog, web site) > * Clicking on the sender's name in an email client to fetch > the person's vcard, picture, or other. > * Fetching a user's picture when he or she posts something on a web > site (I assume that the user has an account at the web site and the > site has verified the user's email address) >=20 > I appreciate that the client code will be made a little more complex, = but > the effort is not really more than handling a 3xx redirection. >=20 > I'm not arguing strongly either way, though. I could put the mandate = in for > TLS, but there are other folks who want to allow plain ol' HTTP. = They've > spoken on the list. >=20 > Paul >=20 >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Dick Hardt >> Sent: Sunday, December 02, 2012 10:00 AM >> To: webfinger@googlegroups.com >> Cc: apps-discuss@ietf.org; 'Joseph Holsten' >> Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP >>=20 >>=20 >> On Dec 2, 2012, at 12:30 AM, "Paul E. Jones" >> wrote: >>> In any case, the current document encourage use of HTTPS. But, it >>> still allows for HTTP and I can see some valid cases for it. >>=20 >> What are the avid use cases? >>=20 >> Keep in mind we are adding complexity to clients by allowing both, so >> there is a real cost to allowing both. I'm not clear what we are = losing >> by HTTPS-only >>=20 >> -- Dick >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From dick.hardt@gmail.com Sun Dec 2 19:26:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF2121F88A2 for ; Sun, 2 Dec 2012 19:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdWG9CjEHMF9 for ; Sun, 2 Dec 2012 19:26:03 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84EE121F8864 for ; Sun, 2 Dec 2012 19:26:03 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1549705pbc.31 for ; Sun, 02 Dec 2012 19:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ns2QQKYRK8EUsxfWQZZm+YVhG1yRpNGMtxHioMckBFI=; b=DakL3PGNOOd3DyeOv/io95L7Aae5EV77g+WKPtDMG9c/EbhK3lg6MSWsrTDOGq/mSY GTUCtyBcdQ+xO2N3QW7ouE3589krWayumX4cbUhQzrrPG6oySIfwrvU0kyd3yd568U46 1/jY5btgiwtVNUHGS6yQe6YZdcNfASYrLangp90phNDsqabdXPcGTrqQ6hueb9KCRTDX K6Yhj67r7Rk3iEjYfbuO+bmomOLbIZB1MAfjhIxmwYo1M+vzGZXAehbCrCIiIFy52RKO Sm32czladHkM9iJ2yIYyRLvq9XXkjZ6JtjecwJ1N2HFCE5ax+MGJdkLEKcKbwfa1woSf 9KvQ== Received: by 10.66.87.167 with SMTP id az7mr22468999pab.69.1354505163270; Sun, 02 Dec 2012 19:26:03 -0800 (PST) Received: from [192.168.3.101] (airnode1222.air-internet.com. [12.110.33.210]) by mx.google.com with ESMTPS id d8sm297503pax.23.2012.12.02.19.25.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 19:25:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Sun, 2 Dec 2012 19:25:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: "\" <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com>" <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com>" " <073201cdd041$d2050b50$760f21f0$@packetizer.com>" <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> To: jonathan@gorard.co.uk X-Mailer: Apple Mail (2.1499) Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 03:26:04 -0000 On Dec 2, 2012, at 12:25 PM, jonathan@gorard.co.uk wrote: > On 2012-12-02 15:00, Dick Hardt wrote: >> On Dec 2, 2012, at 12:30 AM, "Paul E. Jones" = wrote: >>> In any case, the current document encourage use of HTTPS. But, it = still >>> allows for HTTP and I can see some valid cases for it. >>=20 >> What are the avid use cases? >>=20 >> Keep in mind we are adding complexity to clients by allowing both, so >> there is a real cost to allowing both. I'm not clear what we are >> losing by HTTPS-only >>=20 >> -- Dick >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > Surely mandating HTTPS for all connections would not only increase = overhead by forcing SSL key exchange where it isn't necessary, but = wouldn't it remove the ability to cache web content, thereby crippling = the performance of many content-heavy websites? For sites which don't = require secure connections, it just doesn't make sense. The additional = complexity on the client from running both protocols that you mentioned = is the lesser of two evils (unless the two protocols are somehow = integrated). It is implementation complexity that I am talking about. Per the latest = draft, the Client has to first call HTTPS and depending on the result of = that call, can call HTTP. The overhead of SSL is nothing compared to making to calls, and the = first has to be SSL anyway! -- Dick= From cb.list6@gmail.com Sun Dec 2 19:56:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3494D21F875C for ; Sun, 2 Dec 2012 19:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIsRqr5V++SK for ; Sun, 2 Dec 2012 19:56:14 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF4C21F870D for ; Sun, 2 Dec 2012 19:56:14 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1889291lah.31 for ; Sun, 02 Dec 2012 19:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pRgkPrHQNCeKbmnHSp5IUhvTxAbxeO7u62GuBhaGG7I=; b=yZp4JRlW0+wToTjer5uFQXYbIsivZEGbpGrh7ueBJZWzi/GXR8/jyIewsSRUAXzXE2 V/MgJo5v7RuPyNOd9/aJunK6CB/40WkFZS1ICiH7SQ4sULWMd9S5CijecWdPgmnxAIYh B+ldp1dJXMMSsnQ/lal/ue+v8aoNu+GyGoK5m0qjHU2dfURvMzHyHjXaIKtWbIx5Rezx UnAKCxs8qXpYW290Aun5Qw4bdw5Gn3wM8g8NgzvMF4coM9B/GDbrnmyOCF3Is2B/gKKB UF6elfoU/ExlXVv8BUjVdReikvQIggMqJFX0tkvtvon5Vw9YZp5EStlycDWGBNf35/dX i+3Q== MIME-Version: 1.0 Received: by 10.112.29.102 with SMTP id j6mr3520546lbh.21.1354506973202; Sun, 02 Dec 2012 19:56:13 -0800 (PST) Received: by 10.112.44.36 with HTTP; Sun, 2 Dec 2012 19:56:13 -0800 (PST) In-Reply-To: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> References: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> Date: Sun, 2 Dec 2012 19:56:13 -0800 Message-ID: From: Cameron Byrne To: "Byrne, Cameron" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-v6ops-464xlat.all@tools.ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 03:56:16 -0000 Ted, i have revision to my previous statements On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron wrote: > Ted, > > Thanks for taking the time to review our work. My comments in-line. > >> -----Original Message----- >> From: Ted Hardie [mailto:ted.ietf@gmail.com] >> Sent: Friday, November 30, 2012 1:15 PM >> To: apps-discuss@ietf.org; draft-ietf-v6ops-464xlat.all@tools.ietf.org >> Subject: Review of draft-ietf-v6ops-464xlat-08 >> >> I have been selected as the Applications Area Directorate reviewer for = this draft >> (for background on appsdir, please see >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat= e >> ). >> >> Please resolve these comments along with any other Last Call comments yo= u >> may receive. Please wait for direction from your document shepherd or AD >> before posting a new version of the draft. >> >> Document:draft-ietf-v6ops-464xlat-08 >> Title: 464XLAT: Combination of Stateful and Stateless Translation >> Reviewer: Ted Hardie >> Review Date: November 30, 2012 >> >> Summary: This draft is not ready for publication as a BCP, and it may no= t be an >> appropriate candidate for this status. >> >> Major Issues: >> >> This document provides a v4/v6 inter-working method using a pair of addr= ess >> translators that bracket a network region in which there is no >> IPv4 routing. It discusses two different potential deployments. In the= first, the >> first address translator is co-resident on the device where the IPv4 add= ress is >> assigned; in the second, the the first address translator is resident in= a nearby >> network device. In both, the second address translator is at the border= of the >> internal IPv6 routing domain and a global IPv4 routing domain. >> >> The document has the following applicability statement: >> >> This BCP only applies when the following two criteria are present: >> >> 1. There is an IPv6-only network that uses stateful translation >> [RFC6146] as the only mechanism for providing IPv4 access. >> >> 2. There are IPv4-only applications or hosts that must communicate >> across the IPv6-only network to reach the IPv4 Internet. >> >> The first item is problematic. This document describes a method for usi= ng >> stateful translation, but it does not justify why this is the appropriat= e choice; the > > The choice for using a stateful translator is outside the scope of this d= ocument. > > But, the IETF has published RFC 6146 which is specifies a stateful protoc= ol translator on the standards track. RFC6146 is necessary but not suffici= ent to operate an IPv6-only network that is dominated (today) by IPv4 nodes= . The problem of IPv4-referals / IPv4-literals as well as IPv4 sockets API= s is very real. It would be very unfortunate if the IETF specified statefu= l NAT64 in RFC 6146 but was no deployable or could only provide an 85% serv= ice (15% of Android apps fail to work on NAT64/DNS64 only networks) > > Just generally speaking on why stateful is the right choice, many network= s already operate stateful NAT44 and the NAT64 is just another feature that= is quick to deploy on existing hardware with existing support models. Fur= thermore, this architecture is based on the reality that IPv4 address are n= o longer available in APNIC in blocks larger than an emergency /22 (RIPE an= d ARIN also have max /22 allocations for the last /8 in the RIR). That sai= d, stateful multiplex of ports / sessions is absolutely required for any se= rvice that must scale to millions of users. Stateless solutions simply do = not scale for new entrants that do not have existing IPv4 resources. > > >> encapsulation methods used in something like DS-Lite seem to be an alter= native >> here, and it is not clear either what constraint prevents encapsulation'= s use in >> these networks or what the advantage is here to using dual translation o= ver an >> encapsulation-based method. In other words, this appears circular--it d= efines it > > Encapsulation can break many things including traffic engineering based o= n IP address (no more hop by hop routing), DPI associated with charging (sp= ecifically 3GPP defined Policy and Charging Controls (PCC)). > > DS-lite also has configuration driven exclusively by DHCP, there is no DH= CP in 3GPP networks. > >> as a best practice for networks using stateful translation, rather than = defining >> when stateful translation is best practice. >> > > The wording of the document was chosen to state the circumstance that you= have this type of network: IPv6-only with stateful NAT64 as defined here = http://tools.ietf.org/html/rfc6144#section-2.1 Given that scenario, there = is a practical reality that hosts and software have specific IPv4 dependenc= ies and thus this scenario is defunct without something like 464XLAT. And, = that goes origins of 464XLAT. It is emergent behavior that occurs in my IP= v6-only network at T-Mobile USA. People wanted Skype to work so they put a= n NAT46 on the host ....and Skype now worked. > > We track broken Android apps at this list (15% don't work: Skype, Netfli= x, Spotify ...), and 464XLAT fixes 100% of the broken apps http://goo.gl/z3= j3q > > 464XLAT allows for the real commercial deployment of IPv6-only networks. > > The current state of the network at T-Mobile USA today is squat space + N= AT44. This is the same at Rogers and Sprint mobile networks here in North = America. > > >> The document also says this in the introduction, which provides an addit= ional >> applicability >> limitation: >> >> The 464XLAT architecture only supports IPv4 in the >> client server model, where the server has a global IPv4 address. >> This means it is not fit for IPv4 peer-to-peer communication or >> inbound IPv4 connections >> >> If this is true, it is highly problematic, because it provides a constra= int on the >> semantics of an RFC 1918 address that is not currently present. It is n= ot entirely >> clear, though, that this is true. >> >> Systems attempting peer-to-peer communication when using RFC 1918 >> addresses typically must use ICE to handle the artifacts of network addr= ess >> translation. >> I was not able to understand >> how ICE would fail here, either in the case where the CLAT was resident = on the >> node or when it is network resident. In my naive reading, this would wo= rk for >> cases where the ICE server was in the IPv4 global routing domain. Becau= se >> PLATs are provisioned with a single IP address, the mapped address attri= bute > > What do you mean 1 IP address? 1 IPv4 address? They will have pools of = address for sure. > >> would always have the same family and address, but it seems it should be >> distinguishable by port. If this is not the case, or there is a differe= nt reason why >> this mechanism cannot work with ICE, I believe it should be called out i= n the >> draft explicitly. >> > > We make this restriction because of the case where you and I are on the s= ame ISP. We both have 10.10.10.1 as our local address. Communication fail= s. > > If we have unique address space, are right, it would work. But, we do no= t want to push an additional level of complexity to try and coordinate uniq= ue LAN side IP addresses. It is simpler to say this simply does not work. = And, in case of DNS64, users will generally not use IPv4. IPv4 is only us= ed for the case of IPv4 referals or IPv4-only host and APIs. > > >> An ICE-based peer-to-peer connection would, certainly, provide a severel= y sub- >> optimal path for two devices within the same 464xlat region, as it would= hairpin >> out and back. But those are not the only potential peer-to-peer connecti= ons and >> it would work at least to some degree. >> I believe you are right that ICE would work at the app level. Our statement about hub-and-spoke in the I-D was driven by wording set in http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01#section= -8.2 In this way, the NAT64 is a hub for IPv4 communications and IPv4 nodes via the NAT64 can communicate with other IPv4 nodes. That is the basic architecture, if you need IPv4 access, send it via the CLAT and PLAT where CLAT is the spoke and PLAT is the hub Our claim that p2p does not work is based on the topological case that if you are address 2001:DB8:9999::10.1.1.1 and i am address 2001:DB8:8888::10.1.1.1 our ipv4-only nodes behind the CLAT cannot send packets to each other without something like ICE to force them via the NAT64 or TURN. If our addresses were different on the LAN like 2001:DB8:9999::10.1.9.9 and 2001:DB8:8888::10.1.1.1 we could send IPv4 packets to each other without the need for the hub (PLAT) since each CLAT would do RFC 6145 translation and remove the first 96 bits on the LAN side. This is great if there is a high chance that the LAN side IPs are unique, but that is not the case and result would be ipv4 packets with src =3D 10.1.1.1 and dst 10.1.1.1 The current wording in question is "The 464XLAT architecture only supports IPv4 in the client server model, where the server has a global IPv4 address. This means it is not fit for IPv4 peer-to-peer communication or inbound IPv4 connections." The important term is "fit" vs "not fit". Given that path would go via a hub and may require ICE in the apps and infrastructure, it would not really be direct p2p, and therefore the WG settle on this specific language to error on the side of caution to the reader that this is not a "fit" design if p2p is an important use-case in ipv4 supporting ipv4. The current statement is a caution to the reader and that is the reason it appears in the introduction. Alternatively, we can strike this from the introduction all together and give a more in-depth discussion that reference ICE for the p2p case. The WG decided it was best to just punt on p2p and say it does not work here in the introduction. CB >> In the case where the CLAT is resident on a device, but that device prov= ides >> tethering, the document currently says: >> >> The CLAT SHOULD perform router function to >> facilitate packets forwarding through the stateless >> translation even if it is an end-node. >> >> For proper operation of tethered devices, this would appear to require a= MUST, >> rather than a SHOULD. >> If it is not MUST, then some description of what will happen is desirabl= e. >> (Perhaps a statement that CLATs which do not provide this functionality = cannot >> be used when tethering is in place or whether tethered devices require I= Pv4?) >> > > I think you are right. We can do a must here. > >> Minor Issues: >> >> This draft is currently targeted for BCP. I do not believe that it >> is appropriate to target it for > > The rational is that 464XLAT is a best practice for RFC 6144 2.1 network = that has IPv4-only apps in it. > >> BCP unless it is preferred over encapsulation-based approaches. I also= believe >> that the marketing material which is currently embedded in the text (see= , for >> example, section 5) should be removed. >> > > I am happy to eliminate section 5, but section 5 has been required during= draft formation because there are many solutions in this space. > >> Nits: The description 3GPP applicability relates to 3GPP "Pre-Release 9"= , but >> there is no citation given. I also note that 3GPP specifications curren= tly appear > > See RFC6459 > >> to be on release 12, and there is no notice of whether changes between p= re- > > The most advanced LTE network is Release 8 at Verizon. > > Most phones are release 7 or earlier (sold on the market today) > > New networks like the one T-Mobile will launch next year will be partiall= y Release 10 > >> release 9 and the current release have changed the topology in a way to > > Current release is not relevant to install base. > >> eliminate the multiple PDP issue raised. If the text means to say that = this is not a > > But it does not remove the dependency on IPv4 address that are not availa= ble.... public and private addresses are both exhausted, so we use squat sp= ace. > >> problem for any version 9 or later, and that the problem exists for any = version >> prior to 9 which supports multiple address families, it needs to be rewo= rded. > > I will review the wording. Thanks again for your review. I look forward= to more feedback from you, thanks again for taking the time to work with u= s and sharing your experience > > Thanks > Cameron > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nico@cryptonector.com Sun Dec 2 20:56:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB3221F841B for ; Sun, 2 Dec 2012 20:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzLIJitMkiPb for ; Sun, 2 Dec 2012 20:56:24 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id D35DA21F841A for ; Sun, 2 Dec 2012 20:56:24 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 8D8126B0078 for ; Sun, 2 Dec 2012 20:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0CKnr28iEmFi+4jeCqTe z61WZ48=; b=MupveVfwGWOyvjlo0OUUSP67jHQifLwb2XUmm2GFeDdEkXXVbt1u Ejk8tk/oI1jaSZvswBWaav6ML6pIpvoHwqKxS21z73GKGgUWVymiVmDjaHk7WmrW Sz9e7V/jwjDTy4a12TK+/yfg8cy3za7IMNnL0YM2YegOUyJNez7a98I= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 420816B0070 for ; Sun, 2 Dec 2012 20:56:24 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so999784wey.31 for ; Sun, 02 Dec 2012 20:56:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.97.137 with SMTP id ea9mr7382215wib.13.1354510582837; Sun, 02 Dec 2012 20:56:22 -0800 (PST) Received: by 10.216.192.207 with HTTP; Sun, 2 Dec 2012 20:56:22 -0800 (PST) In-Reply-To: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> Date: Sun, 2 Dec 2012 22:56:22 -0600 Message-ID: From: Nico Williams To: Dick Hardt Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org, webfinger@googlegroups.com, Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 04:56:25 -0000 On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt wrote: > I agree there are many use cases where the security is not essential. > > My question was what do we lose by requiring TLS? Some hosting sites can't handle it well at all. Either they require server certs that can serve many domains or they require per-domain IP addresses because SNI is not well supported. Many clients don't do proper server cert validation. "I used TLS" != "I got it securely". > There is a real latency and extra code in dealing with the fallback as currently specified. But is that relevant here? > For example, we lose being able to use a simple CURL command to get a JRD. So you need an if and two invocations of curl. Nico -- From nico@cryptonector.com Sun Dec 2 20:57:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA5821F8475 for ; Sun, 2 Dec 2012 20:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs5Wi6xNsTAC for ; Sun, 2 Dec 2012 20:57:42 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5EACC21F8467 for ; Sun, 2 Dec 2012 20:57:42 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 2330F778057 for ; Sun, 2 Dec 2012 20:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=alxgi45+URIr+Y6zfwgh H5rd8X8=; b=WaoCitPlvB9Z8uYp4tDEjyWiUBcaBVSpSK50uRcNV/5gl/7kW+rB luWYGKixj4G9PeI/NBJ8VdlVFMYqTRi/f3AgAoe3kG9qdBldYETK+hzCBBssUJ9n uHm9zZMVuhDyYQIhOnYGiZBpuf09ZwykVNd8pg3EbG+AA3A4PhuBrhI= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id BFD0877801F for ; Sun, 2 Dec 2012 20:57:41 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1025861wgb.13 for ; Sun, 02 Dec 2012 20:57:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.202.199 with SMTP id d49mr2879058weo.78.1354510660553; Sun, 02 Dec 2012 20:57:40 -0800 (PST) Received: by 10.216.192.207 with HTTP; Sun, 2 Dec 2012 20:57:40 -0800 (PST) In-Reply-To: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> Date: Sun, 2 Dec 2012 22:57:40 -0600 Message-ID: From: Nico Williams To: Dick Hardt Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org, webfinger@googlegroups.com Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 04:57:43 -0000 On Sun, Dec 2, 2012 at 9:25 PM, Dick Hardt wrote: > It is implementation complexity that I am talking about. Per the latest draft, the Client has to first call HTTPS and depending on the result of that call, can call HTTP. That's two lines of code. Compare to the discovery process. From dick.hardt@gmail.com Sun Dec 2 20:58:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EBD21F842F for ; Sun, 2 Dec 2012 20:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqyH0kR6IPcK for ; Sun, 2 Dec 2012 20:58:37 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1955421F841E for ; Sun, 2 Dec 2012 20:58:37 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1043033dae.31 for ; Sun, 02 Dec 2012 20:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=S98bVsYTc9DhmSoVjhSZaiH7UNq7ytzeTxvyWsCMKfM=; b=mB9+vWk/ZMOMvx6CYTc+e/TqBrmcLAa09bP/nE9e9baTB3Qrqvz8vsVhI9t3Aajcow WdKsHAuuenb2sinhH6jDcXd0Po5DeVI8ztW57QJuiqrVF5ICRn0sN7B4XzflH1Z0dW/x XbzMOuLZGHioZ+UauR0gHlrBMXJ+1sXZGFtGiwL1ZsuJe0y0W8JBuZbHzer7BcH4RNxS YCOe0RHK7v/ggkM5Y8Fm+h31GKAAoPX0vy4963Sbd5opQLaTiD/ucqp7PJm2YFag+9I2 iPOOu2ToYzr2nBkMax+MpQ20YQIxd3ZiiTAKexWFHB7Gxl0ARHWlV/VBapXmB/zPCVwo 1riA== Received: by 10.66.77.74 with SMTP id q10mr22849908paw.81.1354510716910; Sun, 02 Dec 2012 20:58:36 -0800 (PST) Received: from [192.168.3.101] (airnode1222.air-internet.com. [12.110.33.210]) by mx.google.com with ESMTPS id k2sm3715431paw.24.2012.12.02.20.58.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 20:58:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Sun, 2 Dec 2012 20:58:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <69A2CBC0-7828-4665-A332-701B03A0B2B1@gmail.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> To: Nico Williams X-Mailer: Apple Mail (2.1499) Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 04:58:37 -0000 On Dec 2, 2012, at 8:57 PM, Nico Williams wrote: > On Sun, Dec 2, 2012 at 9:25 PM, Dick Hardt = wrote: >> It is implementation complexity that I am talking about. Per the = latest draft, the Client has to first call HTTPS and depending on the = result of that call, can call HTTP. >=20 > That's two lines of code. Compare to the discovery process. Compare what?= From James.H.Manger@team.telstra.com Sun Dec 2 21:02:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766F321F899E for ; Sun, 2 Dec 2012 21:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE4g+uXhdZi0 for ; Sun, 2 Dec 2012 21:02:01 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 166E021F86FA for ; Sun, 2 Dec 2012 21:01:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,360,1352034000"; d="scan'208";a="104008799" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 03 Dec 2012 16:01:47 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="101427811" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbni.tcif.telstra.com.au with ESMTP; 03 Dec 2012 16:01:47 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Mon, 3 Dec 2012 16:01:47 +1100 From: "Manger, James H" To: Mark Nottingham Date: Mon, 3 Dec 2012 16:01:46 +1100 Thread-Topic: [apps-discuss] JSON Patch implementation feedback Thread-Index: Ac3Q/2zX6qSAi1q4RdKpsLsRNE/zBAAAFvGg Message-ID: <255B9BB34FB7D647A506DC292726F6E115028CDBC3@WSMSG3153V.srv.dir.telstra.com> References: <50BB20B3.8010403@skoegl.net> <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CD4FD@WSMSG3153V.srv.dir.telstra.com> <05CB04C6-A7CD-4C56-8050-45EF788DD5E0@mnot.net> In-Reply-To: <05CB04C6-A7CD-4C56-8050-45EF788DD5E0@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:02:01 -0000 PiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBJdCBp cyBleHRlbnNpYmxlLg0KPiA+IFRvIGRlZmluZSBuZXcgZnVuY3Rpb25hbGl0eSB0aGF0IG11c3Qg bm90IGJlIGlnbm9yZWQgeW91IGNhbiBkZWZpbmUgYQ0KPiBuZXcgb3BlcmF0aW9uLg0KPiA+IFRv IGRlZmluZSBuZXcgZnVuY3Rpb25hbGl0eSB0aGF0IGNhbiBiZSBzYWZlbHkgaWdub3JlZCBieSBv bGQNCj4gaW1wbGVtZW50YXRpb25zIHlvdSBjYW4gZGVmaW5lIG5ldyBtZW1iZXJzIGZvciBleGlz dGluZyBvcGVyYXRpb25zLg0KPiA+DQo+ID4gRm9yIGluc3RhbmNlLCB0byBkZWZpbmUgYSB0ZXN0 IG9mIHRoZSB0eXBlIG9mIGEgSlNPTiB2YWx1ZSB5b3UgY291bGQNCj4gZGVmaW5lIGEgbmV3IG9w ZXJhdGlvbnM6DQo+ID4gIHsgIm9wIjoidGVzdDIiLCAicGF0aCI6Ii9hL2IvYyIsICJ0eXBlIjpb XSB9ICAtLSB0cnVlIGlmZiB0aGUgdmFsdWUNCj4gPiBhdCB0aGUgZ2l2ZW4gcGF0aCBpcyBhbiBh cnJheQ0KDQo+IFRoYXQncyBub3QgYSBiYWNrd2FyZHMtY29tcGF0aWJsZSBleHRlbnNpb247IGl0 IGZ1bmRhbWVudGFsbHkgY2hhbmdlcw0KPiB0aGUgc2VtYW50aWNzIG9mIHRoZSBkb2N1bWVudCwg YW5kIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgaWdub3JlcyBpdA0KPiBtYXkgUEFUQ0ggd2hlbiBp dCBzaG91bGRuJ3QuDQoNCiJvcCI6InRlc3QyIiBpcyBub3QgbWVhbnQgdG8gYmUgYmFja3dhcmQt Y29tcGF0aWJsZS4gSXQgaXMgbm90IG1lYW50IHRvIGJlIGlnbm9yZWQgYW5kIGl0IHdpbGwgbm90 IGJlIGlnbm9yZWQuIEFsbCBjb2RlIHdpbGwgc3dpdGNoIG9uIHRoZSAib3AiIHZhbHVlLiBbSW4g c2hhcnAgY29udHJhc3QgdG8gdW5leHBlY3RlZCBleHRyYSBuYW1lL3ZhbHVlIHBhaXJzIHdoaWNo IG1vc3QgY29kZSB3aWxsIGlnbm9yZSBzbyB0aGUgc3BlYyBzZW5zaWJseSBjb2RpZmllcyB0aGF0 IG11c3QtaWdub3JlIGJlaGF2aW91ci5dDQoNCg0KPiA+ICAgSXQgaXMgYW4gZXJyb3IgaWYgdGhl IHZhbHVlIGlzIG5vdCByZWNvZ25pemVkLiBOZXcgb3BlcmF0aW9ucyBjYW4NCj4gPiAgIGJlIGRl ZmluZWQgYnkgUkZDcyB0aGF0IHVwZGF0ZSB0aGlzIGRvY3VtZW50Lg0KPiA+IC0tDQo+IA0KPiBX ZSBleHBsaWNpdGx5IGFncmVlZCB0byB0aGUgdGV4dCBiZWZvcmUgLS0gaS5lLiwgdGhhdCB0aGUg c2V0IG9mDQo+IG9wZXJhdGlvbnMgZGVmaW5lZCBieSB0aGlzIGZvcm1hdCBpcyBjbG9zZWQuDQoN Cg0KU28gaWYgYW5vdGhlciBzcGVjIGxpa2UgZHJhZnQtc25lbGwtanNvbi10ZXN0IChzZWN0aW9u IDIuNSAiVXNpbmcgSlNPTiBQcmVkaWNpYXRlIHdpdGhpbiBKU09OIFBhdGNoIERvY3VtZW50cykg ZGVmaW5lcyBzb21lIG9wZXJhdGlvbnMgaXQgY2FuIHJlLXVzZSB0aGUganNvbi1wYXRjaCBzeW50 YXggd2l0aCBzb21lIG5ldyAib3AiIHZhbHVlcyAtLSBidXQgaXQgYWxzbyBuZWVkcyB0byBkZWZp bmUgYSBuZXcgbWVkaWEgdHlwZT8gT2ggd2VsbC4NCg0KDQoNCj4gPiBbSSBzdGlsbCB0aGluayB3 ZSBzaG91bGQgZGl0Y2ggdGhlIHN0YXRlbWVudHMgdGhhdCAiVGhlIHRhcmdldA0KPiA+IGxvY2F0 aW9uIE1VU1QgZXhpc3QgZm9yIHRoZSBvcGVyYXRpb24gdG8gYmUgc3VjY2Vzc2Z1bCIuIEJldHRl ciB0bw0KPiA+IGRlZmluZSBhIHNlbnNpYmxlICJzdWNjZXNzZnVsIiByZXN1bHQgKGVnICJyZW1v dmUiIGlzIGEgbm8tb3AgaWYNCj4gPiAiZnJvbSIgZG9lcyBub3QgZXhpc3Q7ICJtb3ZlIiBpcyBl cXVpdmFsZW50IHRvICJyZW1vdmUiIG9uIHRoZSAiZnJvbSINCj4gPiBhbmQgInRvIiBsb2NhdGlv bnMgdGhlbiwgaWYgdGhlcmUgd2FzIGEgdmFsdWUgYXQgImZyb20iLCBhbiAiYWRkIg0KPiA+IG9w ZXJhdGlvbjsgInJlcGxhY2UiIGlzIGVxdWl2YWxlbnQgdG8gInJlbW92ZSIgdGhlbiAiYWRkIg0K PiA+IG9wZXJhdGlvbnMpLl0NCj4gDQo+IA0KPiBUaGUgcG9pbnQgb2YgdGhpcyBzdGF0ZW1lbnQg aW4gdGhlICJyZW1vdmUiIGFuZCAicmVwbGFjZSIgb3BlcmF0aW9ucyBpcw0KPiB0aGF0IGlmIHRo ZSB0YXJnZXQgaXNuJ3QgdGhlcmUsIHRoZSBwYXRjaCBpcyBwcm9iYWJseSBub3Qgd3JpdHRlbiB3 aXRoDQo+IHRoZSBzdGF0ZSBvZiB0aGUgZG9jdW1lbnQgaW4gbWluZCwgYW5kIHNob3VsZCBmYWls LiBDb250cmFzdCB3aXRoICJhZGQiDQo+ICh3aGVyZSB0aGUgaW50ZW50IHdhcyB0byBhbGxvdyBh dXRob3JzIHRvIGFkZC1vci11cGRhdGUpLg0KDQpTbyB0byB1c2UgImFkZCIgdGhlIGF1dGhvciBk b2Vzbid0IG5lZWQgdG8gaGF2ZSAidGhlIHN0YXRlIG9mIHRoZSBkb2N1bWVudCBpbiBtaW5kIiwg YnV0IHRvIHVzZSAicmVtb3ZlIiBvciAicmVwbGFjZSIgdGhlIGF1dGhvciBkb2VzLiBUaGF0IGlz IHBhaW5mdWxseSBpbmNvbnNpc3RlbnQuIFBsdXMgdGhlIHByb3RlY3Rpb24gZm9yIHRoZSBhdXRo b3IgaXMgc28gd2VhazogdGhlIHZhbHVlIHRoYXQgYSAicmVtb3ZlIiBvcCBkZWxldGVzIGNvdWxk IGhhdmUgYmVlbiB1cGRhdGVkIHRvIHNvbWV0aGluZyBjb21wbGV0ZWx5IGRpZmZlcmVudCBmcm9t IHRoZSB2YWx1ZSB0aGUgcGF0Y2ggYXV0aG9yIHRoaW5rcyBpdCBpcywgYnV0IGl0IHdpbGwgYmUg cmVtb3ZlZCBhbnl3YXkuDQpBbnkgbWlub3IgYmVuZWZpdCBvZiBjYXRjaGluZyBzb21lICJ0eXBv cyIgaW4gcGF0Y2ggZG9jcyBpbiBhbiBhZCBob2MgbWFubmVyIGlzIG91dHdlaWdoZWQgYnkgbG9z aW5nIGZ1bmN0aW9uYWxpdHkgKGVnIGEgcGF0Y2ggdG8gcmVtb3ZlIGEgZmllbGQgdGhhdCB3b3Jr cyByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIGZpZWxkIGlzIHByZXNlbnQpLCBhbmQgdGhlIHRl bXB0YXRpb24gaXQgZ2l2ZXMgdG8gc2tpbXAgb24gcHJvcGVyIGNoZWNrcyAoZWcgd2l0aCBhICJ0 ZXN0IiBvcCwgZS10YWdzLCBvciBsb2NrcykuDQoNCg0KDQo+IEZvciAibW92ZSIgYW5kICJjb3B5 IiBpdCBhbHNvIHNlZW1zIGxpa2UgYSBnb29kIGlkZWEsIGJlY2F1c2UgaWYgeW91DQo+IHJ1biBh IHBhdGNoIGFuZCB0aGUgc291cmNlIG9mIG9uZSBvZiB0aGVzZSBvcGVyYXRpb25zIGlzbid0IGV4 aXN0ZW50LA0KPiB5b3UgZGVmaW5pdGVseSBkb24ndCBrbm93IHdoYXQgc3RhdGUgdGhlIGRvY3Vt ZW50IGlzIGluLCBhbmQgdGhlIHBhdGNoDQo+IHNob3VsZCBmYWlsLg0KDQpBbmQgaWYgdGhlIHBh dGNoIHN1Y2NlZWRzIHlvdSBtaWdodCBoYXZlIGtub3duIHRoZSBkb2Mgc3RhdGUgb3IgeW91IG1p Z2h0IG5vdC4gVGhhdCdzIGJldHRlcj8NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo= From dick.hardt@gmail.com Sun Dec 2 21:02:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F7221F89F6 for ; Sun, 2 Dec 2012 21:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQSVqZ35Rl24 for ; Sun, 2 Dec 2012 21:02:47 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBCD221F899E for ; Sun, 2 Dec 2012 21:02:47 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1517233pad.31 for ; Sun, 02 Dec 2012 21:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=w4rwuB7MVmFGJ9tz85+zf9g8NOPnFlHSkTA1ZuHndHU=; b=jUuU/2tvOWj+TzJI65XuRFpyUjxMIqZ/9sw380Nq/ucyr6zNKHkJzs8D6f9pIDrJXV wnXpZUvSiIWll3NxxtBPGErC6UjcCTH6P0GIpvcnZUP1bMerZ5PIRTT01rhxpeu9xNXF UAj02Giqv/TfetKnXloO3w9u2k1sQ1/bZD0OS5oSxI73F7FYuFy+gBhvcHXHhv/ChpbX VKSqq97luSgINzR2Cp2AoAPDwXMwSDtnUA/c2uGwhLMmk4frNWePsB8jV7FOsbW5QJtv Fibm7fj6zpJXD/feL/b7cQNFfGj7VA2RqowQoMVEkZjBTm2Gs3AfmtBnlcWsRdBDUP/U e87A== Received: by 10.66.74.2 with SMTP id p2mr23135354pav.55.1354510967571; Sun, 02 Dec 2012 21:02:47 -0800 (PST) Received: from [192.168.3.101] (airnode1222.air-internet.com. [12.110.33.210]) by mx.google.com with ESMTPS id om10sm7380653pbc.73.2012.12.02.21.02.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 21:02:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Sun, 2 Dec 2012 21:02:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> To: Nico Williams X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org, webfinger@googlegroups.com, Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:02:48 -0000 On Dec 2, 2012, at 8:56 PM, Nico Williams wrote: > On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt = wrote: >> I agree there are many use cases where the security is not essential. >>=20 >> My question was what do we lose by requiring TLS? >=20 > Some hosting sites can't handle it well at all. Either they require > server certs that can serve many domains or they require per-domain IP > addresses because SNI is not well supported. Which sites? Are they critical to the successful deployment of WF? If WF = is successful, will they make it easier to deploy TLS? Perhaps = HTTPS-only will drive easier TLS support. That would seem to be a good = thing. >=20 > Many clients don't do proper server cert validation. "I used TLS" !=3D > "I got it securely". So we should not force HTTPS because some clients don't implement it = properly? Really? >=20 >> There is a real latency and extra code in dealing with the fallback = as currently specified. >=20 > But is that relevant here? I would think so. If the user is waiting for discovery to be finished, = latency is an issue. Extra code is extra code and complexity and more to understand. >> For example, we lose being able to use a simple CURL command to get a = JRD. >=20 > So you need an if and two invocations of curl. So you agree it is more complicated. The agreed goal is to push = complexity to the server.= From nico@cryptonector.com Sun Dec 2 21:10:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E61F21F8A14 for ; Sun, 2 Dec 2012 21:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6p7kaRjFnvt for ; Sun, 2 Dec 2012 21:10:57 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id BE5A421F891A for ; Sun, 2 Dec 2012 21:10:57 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 3B7E4BC040 for ; Sun, 2 Dec 2012 21:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=I8GP68RWaHYgQrQOPI3I cWiQqe8=; b=Ej4uU6JF0a4A5DNcsmw4dAlCSrOSL77gRIEITpSIdiYuDgANXtI4 QSlVmNMtspy8O+BN2fgG7lZSsK1ZqD+ukkw7LrJkmPsVGyJ59+UsJ2slbfkCCJ4p sQz3go0Eie3BlHV7c6iqv2DUzyQB4FKpSF4EdXXMNKUzG9my2Dy6sC8= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id BEA84BC031 for ; Sun, 2 Dec 2012 21:10:56 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1028953wgb.13 for ; Sun, 02 Dec 2012 21:10:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.102.102 with SMTP id fn6mr7411855wib.13.1354511455543; Sun, 02 Dec 2012 21:10:55 -0800 (PST) Received: by 10.216.192.207 with HTTP; Sun, 2 Dec 2012 21:10:55 -0800 (PST) In-Reply-To: <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> Date: Sun, 2 Dec 2012 23:10:55 -0600 Message-ID: From: Nico Williams To: Dick Hardt Content-Type: multipart/alternative; boundary=f46d0444ef5526e2be04cfebc6ef Cc: "apps-discuss@ietf.org" , "webfinger@googlegroups.com" , Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:10:58 -0000 --f46d0444ef5526e2be04cfebc6ef Content-Type: text/plain; charset=UTF-8 On Sunday, December 2, 2012, Dick Hardt wrote: > > On Dec 2, 2012, at 8:56 PM, Nico Williams > > wrote: > > > On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt > > wrote: > >> I agree there are many use cases where the security is not essential. > >> > >> My question was what do we lose by requiring TLS? > > > > Some hosting sites can't handle it well at all. Either they require > > server certs that can serve many domains or they require per-domain IP > > addresses because SNI is not well supported. > > Which sites? Are they critical to the successful deployment of WF? If WF > is successful, will they make it easier to deploy TLS? Perhaps HTTPS-only > will drive easier TLS support. That would seem to be a good thing. My domain's hosting site, for example. This is not about the hosting site: it's about the incomplete deployment of TLS SNI. > > > > Many clients don't do proper server cert validation. "I used TLS" != > > "I got it securely". > > So we should not force HTTPS because some clients don't implement it > properly? Really? No, we should not mandate TLS if either we know that requirement will often be ignored or if we're doing it because we think that gets use "security". And if we do end up requiring TLS we need to say a lot more about server certificate validation, about TLS cipher suites (e.g., no anon DH ones), and so on, about trust anchors (same as for web browsers?). > > > >> There is a real latency and extra code in dealing with the fallback as > currently specified. > > > > But is that relevant here? > > I would think so. If the user is waiting for discovery to be finished, > latency is an issue. > Extra code is extra code and complexity and more to understand. I wouldn't worry about a line of code given TLS' complexity, which we'd be requiring. The latency involved in one more fallback may well matter, but I'm not ready to conclude that it means we must require TLS because we could still consider the alternative that the WF app/ user be the one to decide whether to use TLS at all or not, without a fallback in either case (actually, I prefer this alternative). > >> For example, we lose being able to use a simple CURL command to get a > JRD. > > > > So you need an if and two invocations of curl. > > So you agree it is more complicated. The agreed goal is to push complexity > to the server. Agreed by whom? --f46d0444ef5526e2be04cfebc6ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, December 2, 2012, Dick Hardt wrote:

On Dec 2, 2012, at 8:56 PM, Nico Williams <nico@cry= ptonector.com> wrote:

> On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt <dic= k.hardt@gmail.com> wrote:
>> I agree there are many use cases where the security is not essenti= al.
>>
>> My question was what do we lose by requiring TLS?
>
> Some hosting sites can't handle it well at all. =C2=A0Either they = require
> server certs that can serve many domains or they require per-domain IP=
> addresses because SNI is not well supported.

Which sites? Are they critical to the successful deployment of WF? If WF is= successful, will they make it easier to deploy TLS? Perhaps HTTPS-only wil= l drive easier TLS support. That would seem to be a good thing.

My domain's hosting site, for example. =C2=A0This i= s not about the hosting site: it's about the incomplete deployment of T= LS SNI.
=C2=A0
>
> Many clients don't do proper server cert validation. =C2=A0"I= used TLS" !=3D
> "I got it securely".

So we should not force HTTPS because some clients don't implement it pr= operly? Really?

No, we should not mandate T= LS if either we know that requirement will often be ignored or if we're= doing it because we think that gets use "security". =C2=A0And if= we do end up requiring TLS we need to say a lot more about server certific= ate validation, about TLS cipher suites (e.g., no anon DH ones), and so on,= about trust anchors (same as for web browsers?).
=C2=A0
>
>> There is a real latency and extra code in dealing with the fallbac= k as currently specified.
>
> But is that relevant here?

I would think so. If the user is waiting for discovery to be finished, late= ncy is an issue.
Extra code is extra code and complexity and more to understand.

I wouldn't worry about a line of code given TLS= 9; complexity, which we'd be requiring. =C2=A0The latency involved in o= ne more fallback may well matter, but I'm not ready to conclude that it= means we must require TLS because we could still consider the alternative = that the WF app/ user be the one to decide whether to use TLS at all or not= , without a fallback in either case (actually, I prefer this alternative).<= /div>
=C2=A0
>> For example, we lose being able to use a simple CURL command to ge= t a JRD.
>
> So you need an if and two invocations of curl.

So you agree it is more complicated. The agreed goal is to push complexity = to the server.

Agreed by whom?=
--f46d0444ef5526e2be04cfebc6ef-- From mnot@mnot.net Sun Dec 2 21:17:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6C521F870E for ; Sun, 2 Dec 2012 21:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.022 X-Spam-Level: X-Spam-Status: No, score=-104.022 tagged_above=-999 required=5 tests=[AWL=-1.423, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D1JahPShS7w for ; Sun, 2 Dec 2012 21:17:27 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 96C2421F8707 for ; Sun, 2 Dec 2012 21:17:27 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0CEAF509B6; Mon, 3 Dec 2012 00:17:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115028CDBC3@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 3 Dec 2012 16:17:25 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50BB20B3.8010403@skoegl.net> <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CD4FD@WSMSG3153V.srv.dir.telstra.com> <05CB04C6-A7CD-4C56-8050-45EF788DD5E0@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CDBC3@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: Apps Discuss Subject: Re: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:17:28 -0000 On 03/12/2012, at 4:01 PM, "Manger, James H" = wrote: >> wrote: >>>=20 >>> It is extensible. >>> To define new functionality that must not be ignored you can define = a >> new operation. >>> To define new functionality that can be safely ignored by old >> implementations you can define new members for existing operations. >>>=20 >>> For instance, to define a test of the type of a JSON value you could >> define a new operations: >>> { "op":"test2", "path":"/a/b/c", "type":[] } -- true iff the value >>> at the given path is an array >=20 >> That's not a backwards-compatible extension; it fundamentally changes >> the semantics of the document, and an implementation that ignores it >> may PATCH when it shouldn't. >=20 > "op":"test2" is not meant to be backward-compatible. It is not meant = to be ignored and it will not be ignored. All code will switch on the = "op" value. [In sharp contrast to unexpected extra name/value pairs = which most code will ignore so the spec sensibly codifies that = must-ignore behaviour.] Introducing a new operation that is safe-to-ignore for processors that = don't understand it is theoretically possible, but practically what will = they do? In the cast of your theoretical test2 -- if the patcher doesn't perform = the test, and it would have failed, now we have two different = behaviours, based upon whether they implement test2; not a good thing in = a patch format. > It is an error if the value is not recognized. New operations can >>> be defined by RFCs that update this document. >>> -- >>=20 >> We explicitly agreed to the text before -- i.e., that the set of >> operations defined by this format is closed. >=20 > So if another spec like draft-snell-json-test (section 2.5 "Using JSON = Prediciate within JSON Patch Documents) defines some operations it can = re-use the json-patch syntax with some new "op" values -- but it also = needs to define a new media type? Oh well Ask discussed, yes -- and James is AFAIK OK with and behind that = approach. >>> [I still think we should ditch the statements that "The target >>> location MUST exist for the operation to be successful". Better to >>> define a sensible "successful" result (eg "remove" is a no-op if >>> "from" does not exist; "move" is equivalent to "remove" on the = "from" >>> and "to" locations then, if there was a value at "from", an "add" >>> operation; "replace" is equivalent to "remove" then "add" >>> operations).] >>=20 >>=20 >> The point of this statement in the "remove" and "replace" operations = is >> that if the target isn't there, the patch is probably not written = with >> the state of the document in mind, and should fail. Contrast with = "add" >> (where the intent was to allow authors to add-or-update). >=20 > So to use "add" the author doesn't need to have "the state of the = document in mind", but to use "remove" or "replace" the author does. = That is painfully inconsistent. Plus the protection for the author is so = weak: the value that a "remove" op deletes could have been updated to = something completely different from the value the patch author thinks it = is, but it will be removed anyway. >=20 > Any minor benefit of catching some "typos" in patch docs in an ad hoc = manner is outweighed by losing functionality (eg a patch to remove a = field that works regardless of whether the field is present), and the = temptation it gives to skimp on proper checks (eg with a "test" op, = e-tags, or locks). *shrug* I'm not too concerned about consistency for its own sake. People = had compelling use cases for 'add', whereas they felt that if you = 'remove' something, and it isn't there, you'd want the patch to fail. I'm not married to any particular approach here, as long as a) it makes = sense for implementers and end users, and b) we can get to a decision = quickly (as opposed to the Dueling Architects Show that the IETF seems = to lean towards these days...*). To be clear -- I think the proposal you're making is a) to make 'remove' = not fail if the target isn't there, and b) to take 'replace' out of the = specification (since the only difference in its semantics from 'add' is = the ability to fail if the thing you want to set isn't there). Additionally, if we go down this road, we'll have to decide what to do = about similar failures in 'copy' and 'move' -- do you REALLY want = failure to find the target to be silently digested? (!?) What do other folks think? >> For "move" and "copy" it also seems like a good idea, because if you >> run a patch and the source of one of these operations isn't existent, >> you definitely don't know what state the document is in, and the = patch >> should fail. >=20 > And if the patch succeeds you might have known the doc state or you = might not. That's better? By the nature of HTTP, you can't know the state of the resource until = you GET it (and even then, it's ephemeral). However, if you write a patch that says "move x to y" and there isn't an = x in the doc, it seems like a pretty sure think that you're patching = something sensibly. YMMV. * N.B. My job title includes the word "Architect." -- Mark Nottingham http://www.mnot.net/ From jasnell@gmail.com Sun Dec 2 21:18:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D348321F8709 for ; Sun, 2 Dec 2012 21:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBlhyIdNMGz7 for ; Sun, 2 Dec 2012 21:18:14 -0800 (PST) Received: from mail-ia0-f177.google.com (mail-ia0-f177.google.com [209.85.210.177]) by ietfa.amsl.com (Postfix) with ESMTP id BC49E21F8707 for ; Sun, 2 Dec 2012 21:18:14 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id u21so2351160ial.22 for ; Sun, 02 Dec 2012 21:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=J1Kan0hDwxuC5/4TwdQym2mekI8UJe/5KCSJiVXwGvw=; b=Kw5ECY7qxNobboV3ys/HKmlIZ+FgX8UyOUa5AnlgZpZ79dQXgznczQRDjagZlYtF1d eL9L6TGtKXpiXxc+6MELFr8F5BikPUcZAfJ0tpeqz0JiZnmwTPoO72dUFnHkYIuBdjbR rq8+HRSa+xGW74uW680bCQDq6vxDUzrjYugi9uMSdDsrQONWTKWRRkIUr8nILmN2bGzj Ppf58PkvM7j/Y4YKVNFN8PH76FclqLxHU87jRo48F8agadQVBPYkMIW5mYMrCltIys8C l2nh0TGkf9l2VyYT9NRc1ohCW1RnIyWYd1C5eMquBREKr626qu4fWAOs7ZyIwbsvDBSr tsbA== Received: by 10.50.203.101 with SMTP id kp5mr5169194igc.61.1354511894324; Sun, 02 Dec 2012 21:18:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.41.229 with HTTP; Sun, 2 Dec 2012 21:17:54 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115028CDBC3@WSMSG3153V.srv.dir.telstra.com> References: <50BB20B3.8010403@skoegl.net> <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CD4FD@WSMSG3153V.srv.dir.telstra.com> <05CB04C6-A7CD-4C56-8050-45EF788DD5E0@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CDBC3@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Sun, 2 Dec 2012 21:17:54 -0800 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae93407714e24ed04cfebe009 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:18:16 -0000 --14dae93407714e24ed04cfebe009 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 2, 2012 at 9:01 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > [snip] > > That's not a backwards-compatible extension; it fundamentally changes > > the semantics of the document, and an implementation that ignores it > > may PATCH when it shouldn't. > > "op":"test2" is not meant to be backward-compatible. It is not meant to be > ignored and it will not be ignored. All code will switch on the "op" value. > [In sharp contrast to unexpected extra name/value pairs which most code > will ignore so the spec sensibly codifies that must-ignore behaviour.] > > Per the json patch spec, the introduction of an unknown operation should cause the operation to fail. > > > > It is an error if the value is not recognized. New operations can > > > be defined by RFCs that update this document. > > > -- > > > > We explicitly agreed to the text before -- i.e., that the set of > > operations defined by this format is closed. > > > So if another spec like draft-snell-json-test (section 2.5 "Using JSON > Prediciate within JSON Patch Documents) defines some operations it can > re-use the json-patch syntax with some new "op" values -- but it also needs > to define a new media type? Oh well. > > Yes, given the current definition of json-patch, a new media type would be necessary. While silly, it's not a deal breaker in reality. If you serve up a json-patch file with predicates to an implementation that does not understand those predicates, the processing will predictably and correctly fail. Serve it up to an implementation that understands predicates, and it'll work... regardless of whatever media type is used. - James > > > > > [I still think we should ditch the statements that "The target > > > location MUST exist for the operation to be successful". Better to > > > define a sensible "successful" result (eg "remove" is a no-op if > > > "from" does not exist; "move" is equivalent to "remove" on the "from" > > > and "to" locations then, if there was a value at "from", an "add" > > > operation; "replace" is equivalent to "remove" then "add" > > > operations).] > > > > > > The point of this statement in the "remove" and "replace" operations is > > that if the target isn't there, the patch is probably not written with > > the state of the document in mind, and should fail. Contrast with "add" > > (where the intent was to allow authors to add-or-update). > > So to use "add" the author doesn't need to have "the state of the document > in mind", but to use "remove" or "replace" the author does. That is > painfully inconsistent. Plus the protection for the author is so weak: the > value that a "remove" op deletes could have been updated to something > completely different from the value the patch author thinks it is, but it > will be removed anyway. > Any minor benefit of catching some "typos" in patch docs in an ad hoc > manner is outweighed by losing functionality (eg a patch to remove a field > that works regardless of whether the field is present), and the temptation > it gives to skimp on proper checks (eg with a "test" op, e-tags, or locks). > > > > > For "move" and "copy" it also seems like a good idea, because if you > > run a patch and the source of one of these operations isn't existent, > > you definitely don't know what state the document is in, and the patch > > should fail. > > And if the patch succeeds you might have known the doc state or you might > not. That's better? > > -- > James Manger > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --14dae93407714e24ed04cfebe009 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Sun, Dec 2, 2012 at 9:01 PM, Manger, = James H <James.H.Manger@team.telstra.com> wrot= e:
[snip]
> That's not a backwards-compatible extension; it fundamentally chan= ges
> the semantics of the document, and an implementation that ignores it > may PATCH when it shouldn't.

"op":"test2" is not meant to be backward-compatib= le. It is not meant to be ignored and it will not be ignored. All code will= switch on the "op" value. [In sharp contrast to unexpected extra= name/value pairs which most code will ignore so the spec sensibly codifies= that must-ignore behaviour.]


Per the json p= atch spec, the introduction of an unknown operation should cause the operat= ion to fail.=C2=A0
=C2=A0

> > =C2=A0 It is an error if the value is not recognized. New operati= ons can
> > =C2=A0 be defined by RFCs that update this document.
> > --
>
> We explicitly agreed to the text before -- i.e., that the set of
> operations defined by this format is closed.


So if another spec like draft-snell-json-test (section 2.5 "Usin= g JSON Prediciate within JSON Patch Documents) defines some operations it c= an re-use the json-patch syntax with some new "op" values -- but = it also needs to define a new media type? Oh well.


Yes, given the= current definition of json-patch, a new media type would be necessary. Whi= le silly, it's not a deal breaker in reality. If you serve up a json-pa= tch file with predicates to an implementation that does not understand thos= e predicates, the processing will predictably and correctly fail. Serve it = up to an implementation that understands predicates, and it'll work... = regardless of whatever media type is used.

- James
=C2=A0


> > [I still think we should ditch the statements that "The targ= et
> > location MUST exist for the operation to be successful". Bet= ter to
> > define a sensible "successful" result (eg "remove&= quot; is a no-op if
> > "from" does not exist; "move" is equivalent t= o "remove" on the "from"
> > and "to" locations then, if there was a value at "= from", an "add"
> > operation; "replace" is equivalent to "remove"= ; then "add"
> > operations).]
>
>
> The point of this statement in the "remove" and "replac= e" operations is
> that if the target isn't there, the patch is probably not written = with
> the state of the document in mind, and should fail. Contrast with &quo= t;add"
> (where the intent was to allow authors to add-or-update).

So to use "add" the author doesn't need to have "t= he state of the document in mind", but to use "remove" or &q= uot;replace" the author does. That is painfully inconsistent. Plus the= protection for the author is so weak: the value that a "remove" = op deletes could have been updated to something completely different from t= he value the patch author thinks it is, but it will be removed anyway.
Any minor benefit of catching some "typos" in patch docs in an ad= hoc manner is outweighed by losing functionality (eg a patch to remove a f= ield that works regardless of whether the field is present), and the tempta= tion it gives to skimp on proper checks (eg with a "test" op, e-t= ags, or locks).



> For "move" and "copy" it also seems like a good id= ea, because if you
> run a patch and the source of one of these operations isn't existe= nt,
> you definitely don't know what state the document is in, and the p= atch
> should fail.

And if the patch succeeds you might have known the doc state or you m= ight not. That's better?

--
James Manger

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--14dae93407714e24ed04cfebe009-- From dick.hardt@gmail.com Sun Dec 2 21:19:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0852521F870E for ; Sun, 2 Dec 2012 21:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZUssYSaqkm0 for ; Sun, 2 Dec 2012 21:19:15 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97FCF21F8709 for ; Sun, 2 Dec 2012 21:19:13 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1525950pad.31 for ; Sun, 02 Dec 2012 21:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=EKyEvTBK7vd+0SQIj8C41brYuIy59NhcffMHM2pELEA=; b=S+6g4XBoa8uY8ckX747lIGdLSJ4iTqNtE7ZvSGBY44F8Z0wcaB2VtRz2Nqxqpf7ynu ArT7S1h29kvxwj3OElnC1iVL5t5jQ/VJYLb3C5HheadtZeW53qo+oKBLHkOpWz9XaLR0 e1ajPk6vHpDuEklg23SZ6JcQx6uWvcba17opTXzF60sJPJhvVTUTLVmaKL8RXZPzgeJX RZ3QjvMlSHfs4UYvbZwPr+FxAUlBrPJprAEyRVuw8t9p9Y0KxI1cRInc6NM5Kyimf8ig EZxNJGhttBkTlo5kwp/Igcgm/MKmem/97HtkVkMT/G1+S0q6XqVjHI6ueREK+MpQuPTW E9FQ== Received: by 10.68.219.164 with SMTP id pp4mr26175881pbc.72.1354511953406; Sun, 02 Dec 2012 21:19:13 -0800 (PST) Received: from [192.168.3.101] (airnode1222.air-internet.com. [12.110.33.210]) by mx.google.com with ESMTPS id om10sm7405187pbc.73.2012.12.02.21.19.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 21:19:12 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3793252D-273F-49D3-BE20-79A2E4086E27" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Sun, 2 Dec 2012 21:19:08 -0800 Message-Id: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> To: Nico Williams X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org" , "webfinger@googlegroups.com" , Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:19:16 -0000 --Apple-Mail=_3793252D-273F-49D3-BE20-79A2E4086E27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 2, 2012, at 9:10 PM, Nico Williams wrote: >=20 > My domain's hosting site, for example. This is not about the hosting = site: it's about the incomplete deployment of TLS SNI. Would motivating hosting sites to do complete deployment of TLS SNI not = be a good thing? > =20 > > > > Many clients don't do proper server cert validation. "I used TLS" = !=3D > > "I got it securely". >=20 > So we should not force HTTPS because some clients don't implement it = properly? Really? >=20 > No, we should not mandate TLS if either we know that requirement will = often be ignored or if we're doing it because we think that gets use = "security". And if we do end up requiring TLS we need to say a lot more = about server certificate validation, about TLS cipher suites (e.g., no = anon DH ones), and so on, about trust anchors (same as for web = browsers?). We mandated TLS in OAuth 2.0 without any of that. Not sure why that is = suddenly an issue now. > =20 > > > >> There is a real latency and extra code in dealing with the fallback = as currently specified. > > > > But is that relevant here? >=20 > I would think so. If the user is waiting for discovery to be finished, = latency is an issue. > Extra code is extra code and complexity and more to understand. >=20 > I wouldn't worry about a line of code given TLS' complexity, which = we'd be requiring. =20 TLS support is in libraries readily available to clients. Yes, some of = them need to be improved to have *better* support of TLS, but that is a = separate issue. > The latency involved in one more fallback may well matter, but I'm not = ready to conclude that it means we must require TLS because we could = still consider the alternative that the WF app/ user be the one to = decide whether to use TLS at all or not, without a fallback in either = case The latest spec requires an HTTPS call to start ALL the time. Choice of what to use adds complexity and incorrect choices by = implementations. > (actually, I prefer this alternative). And how would the WF app decide if to use TLS or not, or how will it = discover what the server supports?=20 > =20 > >> For example, we lose being able to use a simple CURL command to get = a JRD. > > > > So you need an if and two invocations of curl. >=20 > So you agree it is more complicated. The agreed goal is to push = complexity to the server. >=20 > Agreed by whom? There seemed consensus on this, and I think should be a guiding = principal. All other things being equal, move complexity to the side = that has fewer implementations and is likely to be done by less = sophisticated implementors. -- Dick --Apple-Mail=_3793252D-273F-49D3-BE20-79A2E4086E27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii nico@cryptonector.com> = wrote:

My domain's = hosting site, for example.  This is not about the hosting site: = it's about the incomplete deployment of TLS = SNI.

Would motivating hosting = sites to do complete deployment of TLS SNI not be a good = thing?

 
>
> Many clients don't do proper server cert validation.  "I used = TLS" !=3D
> "I got it securely".

So we should not force HTTPS because some clients don't implement it = properly? Really?

No, we should not = mandate TLS if either we know that requirement will often be ignored or = if we're doing it because we think that gets use "security".  And = if we do end up requiring TLS we need to say a lot more about server = certificate validation, about TLS cipher suites (e.g., no anon DH ones), = and so on, about trust anchors (same as for web = browsers?).

We mandated TLS in = OAuth 2.0 without any of that. Not sure why that is suddenly an issue = now.

 
>
>> There is a real latency and extra code in dealing with the = fallback as currently specified.
>
> But is that relevant here?

I would think so. If the user is waiting for discovery to be finished, = latency is an issue.
Extra code is extra code and complexity and more to = understand.

I wouldn't worry about a = line of code given TLS' complexity, which we'd be requiring. =  

TLS support is in libraries = readily available to clients. Yes, some of them need to be improved to = have *better* support of TLS, but that is a separate = issue.

The latency involved in = one more fallback may well matter, but I'm not ready to conclude that it = means we must require TLS because we could still consider the = alternative that the WF app/ user be the one to decide whether to use = TLS at all or not, without a fallback in either = case

The latest spec requires = an HTTPS call to start ALL the time.

Choice of = what to use adds complexity and incorrect choices by = implementations.

= (actually, I prefer this = alternative).

And how would the WF = app decide if to use TLS or not, or how will it discover what the server = supports? 

 
>> For example, we lose being able to use a simple CURL command to = get a JRD.
>
> So you need an if and two invocations of curl.

So you agree it is more complicated. The agreed goal is to push = complexity to the server.

Agreed by = whom?

There seemed consensus on this, and I think = should be a guiding principal. All other things being equal, move = complexity to the side that has fewer implementations and is likely to = be done by less sophisticated implementors.

-- = Dick

= --Apple-Mail=_3793252D-273F-49D3-BE20-79A2E4086E27-- From jasnell@gmail.com Sun Dec 2 21:21:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C5F21F878C for ; Sun, 2 Dec 2012 21:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwSThwoOobe3 for ; Sun, 2 Dec 2012 21:21:23 -0800 (PST) Received: from mail-ia0-f177.google.com (mail-ia0-f177.google.com [209.85.210.177]) by ietfa.amsl.com (Postfix) with ESMTP id E25AE21F870E for ; Sun, 2 Dec 2012 21:21:22 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id u21so2352772ial.22 for ; Sun, 02 Dec 2012 21:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ax+2om8ftOQ6XavEockPHmXwRffskhkpjtJ7hcas/EA=; b=epSlnTfCMtD2rci5KgqbEIHdKUiYuo16Ddld3HsTSdRqHvk7yDTqtRzieMsVDbmLxT 53NsgSXDa4/mHtgPKO6DXLbd8pvdDmxzDfigpGyVHf5a0v1PCmT6Z2afctjVg10kKshF oIbLs7RwmfW43tD4lhYwayZpKR4J61rPHcFTBXtJvB9Z83ar56BvmNYh10ThowrPI3IF QmziFIqB2TR6aAwUvUroUSPiSAwNvs/26zQjd/TekJ6I7Z6DBUxUUXltH7h9CM7XBxDF fP+zXcHLOj8waaiF2G1vAvIZ3tz8loJx/eUYTpK5WbhWVjJKbNe9TIFqqJRFJRS7Pgy2 rtgg== Received: by 10.42.41.144 with SMTP id p16mr6426888ice.39.1354512082577; Sun, 02 Dec 2012 21:21:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.41.229 with HTTP; Sun, 2 Dec 2012 21:21:02 -0800 (PST) In-Reply-To: References: <50BB20B3.8010403@skoegl.net> <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CD4FD@WSMSG3153V.srv.dir.telstra.com> <05CB04C6-A7CD-4C56-8050-45EF788DD5E0@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CDBC3@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Sun, 2 Dec 2012 21:21:02 -0800 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=20cf301d423286aa3804cfebeb72 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:21:23 -0000 --20cf301d423286aa3804cfebeb72 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 2, 2012 at 9:17 PM, Mark Nottingham wrote: > >[snip] > > So if another spec like draft-snell-json-test (section 2.5 "Using JSON > Prediciate within JSON Patch Documents) defines some operations it can > re-use the json-patch syntax with some new "op" values -- but it also needs > to define a new media type? Oh well > > Ask discussed, yes -- and James is AFAIK OK with and behind that approach. > [snip] > To be clear, yes I am. A new media type is just fine -- largely because, when put into practice, the specific media type is not going to matter too much. An implementation will either understand predicates inside a json-patch or it will not. Either way processing the result should lead to a correct result. - James --20cf301d423286aa3804cfebeb72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Sun, Dec 2, 2012 at 9:17 PM, Mark Not= tingham <mnot@mnot.net> wrote:
>[snip]
> So if another spec like draft-snell-json-test (section 2.5 "Using= JSON Prediciate within JSON Patch Documents) defines some operations it ca= n re-use the json-patch syntax with some new "op" values -- but i= t also needs to define a new media type? Oh well

Ask discussed, yes -- and James is AFAIK OK with and behind that appr= oach.
[snip]

To be clear,= yes I am. A new media type is just fine -- largely because, when put into = practice, the specific media type is not going to matter too much. An imple= mentation will either understand predicates inside a json-patch or it will = not. Either way processing the result should lead to a correct result.

- James

--20cf301d423286aa3804cfebeb72-- From jpanzer@google.com Sun Dec 2 21:24:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4521F878C for ; Sun, 2 Dec 2012 21:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN-3LHpH5l24 for ; Sun, 2 Dec 2012 21:24:14 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F43A21F86FA for ; Sun, 2 Dec 2012 21:24:09 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2042945lbk.31 for ; Sun, 02 Dec 2012 21:24:08 -0800 (PST) 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=QcxeSAmoVEQ2tkfhIBCoi8M1AMMqHiN6GjwTZCHpPIA=; b=fnyDGAvZMusozWSctOBAGVxH8JmQUGOZl7kudh9PRybusv0URHE5Vq+MAG1Vvj42Sc rkl7M+dL0WQx1rT8O1VVBSrrvRUwseH69K/U2rrgpb2u3iIn//deDUFGZxvBAKIO+T9A 0dc3SYUZ+YbK2sM+udZhaKN/XRFT/ree6VRyTDB8kJNVrTeJLNZgSY+LAEp+Q8CCBDHJ blMoGNP+KdOwLS9iXyUp19xearh0rIl8NGtar4yOZ+rgI7cdDZ3LkmcYw2cwwQW+pw5f Z5rWw7P3iJbcsGfTxXj8/B+HZe0VOHIL2ut2cx5as7cc3XwPt1so7HUtGOqT6/cOgAaX 3rew== X-Google-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:x-gm-message-state; bh=QcxeSAmoVEQ2tkfhIBCoi8M1AMMqHiN6GjwTZCHpPIA=; b=FZGYNuDMEIh6LZTwIzPAGBYU+lCmG/KOkSrC8nYT0tj6ZC7tP3UbxwuRqVTIzC1ZCi ATMi9D+BKizSpOuh0hZ5N8cbExZFVTSLqs0lPVRJqzQPTOxcpDgY/7GDCSxB4pFBw5yh gghtwfiEL/TmNch3p6pX8E3edbg6pVrQ0Oqpj7NR2sgj0+5EJOmMufihoB4JObSp2Sgu LKKHAJ5WrugfN4xoVMQWNdHgWyyb8pgAeC3zbYJnS3jlH8b4imDs4uqEGJfm1q3gYus1 qeRv79b1+T4AsYvt+ub03znvii3ZRurPexE6mVWBk6wBHRmGcWJ+CkiH/4krmYVKXtF7 Z7VQ== MIME-Version: 1.0 Received: by 10.152.111.131 with SMTP id ii3mr8075894lab.37.1354512248031; Sun, 02 Dec 2012 21:24:08 -0800 (PST) Received: by 10.114.4.197 with HTTP; Sun, 2 Dec 2012 21:24:07 -0800 (PST) Received: by 10.114.4.197 with HTTP; Sun, 2 Dec 2012 21:24:07 -0800 (PST) In-Reply-To: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> Date: Sun, 2 Dec 2012 21:24:07 -0800 Message-ID: From: John Panzer To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d040839f1634afc04cfebf5d6 X-Gm-Message-State: ALoCoQnHIXTE5hrjkyh9QSHC7Gb4E8+I4yFBSSk0YCoc7XtNp105ZSo9M7xHB8adrZdA79M7GtgrJ9IBLQrNwn8hhgrWZef4JW3Lf1UB9uE90RcLcguoWNKnVnukSQycIaX+zxEZkVSGR8Rof+6xIglQO5tiAl+OJc0AHxm1vdQofOjo7fd/dA5SLPFJwaFgFUz+XVrMdtnH Cc: Joseph Holsten , apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:24:14 -0000 --f46d040839f1634afc04cfebf5d6 Content-Type: text/plain; charset=ISO-8859-1 On Dec 2, 2012 9:19 PM, "Dick Hardt" wrote: > > > On Dec 2, 2012, at 9:10 PM, Nico Williams wrote: >> >> >> My domain's hosting site, for example. This is not about the hosting site: it's about the incomplete deployment of TLS SNI. > > > Would motivating hosting sites to do complete deployment of TLS SNI not be a good thing? > >> >>> >>> > >>> > Many clients don't do proper server cert validation. "I used TLS" != >>> > "I got it securely". >>> >>> So we should not force HTTPS because some clients don't implement it properly? Really? >> >> >> No, we should not mandate TLS if either we know that requirement will often be ignored or if we're doing it because we think that gets use "security". And if we do end up requiring TLS we need to say a lot more about server certificate validation, about TLS cipher suites (e.g., no anon DH ones), and so on, about trust anchors (same as for web browsers?). > > > We mandated TLS in OAuth 2.0 without any of that. Not sure why that is suddenly an issue now. > >> >>> >>> > >>> >> There is a real latency and extra code in dealing with the fallback as currently specified. >>> > >>> > But is that relevant here? >>> >>> I would think so. If the user is waiting for discovery to be finished, latency is an issue. >>> Extra code is extra code and complexity and more to understand. >> >> >> I wouldn't worry about a line of code given TLS' complexity, which we'd be requiring. > > > TLS support is in libraries readily available to clients. Yes, some of them need to be improved to have *better* support of TLS, but that is a separate issue. > >> The latency involved in one more fallback may well matter, but I'm not ready to conclude that it means we must require TLS because we could still consider the alternative that the WF app/ user be the one to decide whether to use TLS at all or not, without a fallback in either case > > > The latest spec requires an HTTPS call to start ALL the time. > > Choice of what to use adds complexity and incorrect choices by implementations. > >> (actually, I prefer this alternative). > > > And how would the WF app decide if to use TLS or not, or how will it discover what the server supports? > >> >>> >>> >> For example, we lose being able to use a simple CURL command to get a JRD. >>> > >>> > So you need an if and two invocations of curl. >>> >>> So you agree it is more complicated. The agreed goal is to push complexity to the server. >> >> >> Agreed by whom? > > > There seemed consensus on this, and I think should be a guiding principal. All other things being equal, move complexity to the side that has fewer implementations and is likely to be done by less sophisticated implementors. s/less/more/ I assume. > > -- Dick > --f46d040839f1634afc04cfebf5d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Dec 2, 2012 9:19 PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:
>
>
> On Dec 2, 2012, at 9:10 PM, Nico Williams <nico@cryptonector.com> wrote:
>>
>>
>> My domain's hosting site, for example. =A0This is not about th= e hosting site: it's about the incomplete deployment of TLS SNI.
>
>
> Would motivating hosting sites to do complete deployment of TLS SNI no= t be a good thing?
>
>> =A0
>>>
>>> >
>>> > Many clients don't do proper server cert validation. = =A0"I used TLS" !=3D
>>> > "I got it securely".
>>>
>>> So we should not force HTTPS because some clients don't im= plement it properly? Really?
>>
>>
>> No, we should not mandate TLS if either we know that requirement w= ill often be ignored or if we're doing it because we think that gets us= e "security". =A0And if we do end up requiring TLS we need to say= a lot more about server certificate validation, about TLS cipher suites (e= .g., no anon DH ones), and so on, about trust anchors (same as for web brow= sers?).
>
>
> We mandated TLS in OAuth 2.0 without any of that. Not sure why that is= suddenly an issue now.
>
>> =A0
>>>
>>> >
>>> >> There is a real latency and extra code in dealing wit= h the fallback as currently specified.
>>> >
>>> > But is that relevant here?
>>>
>>> I would think so. If the user is waiting for discovery to be f= inished, latency is an issue.
>>> Extra code is extra code and complexity and more to understand= .
>>
>>
>> I wouldn't worry about a line of code given TLS' complexit= y, which we'd be requiring. =A0
>
>
> TLS support is in libraries readily available to clients. Yes, some of= them need to be improved to have *better* support of TLS, but that is a se= parate issue.
>
>> The latency involved in one more fallback may well matter, but I&#= 39;m not ready to conclude that it means we must require TLS because we cou= ld still consider the alternative that the WF app/ user be the one to decid= e whether to use TLS at all or not, without a fallback in either case
>
>
> The latest spec requires an HTTPS call to start ALL the time.
>
> Choice of what to use adds complexity and incorrect choices by impleme= ntations.
>
>> (actually, I prefer this alternative).
>
>
> And how would the WF app decide if to use TLS or not, or how will it d= iscover what the server supports?=A0
>
>> =A0
>>>
>>> >> For example, we lose being able to use a simple CURL = command to get a JRD.
>>> >
>>> > So you need an if and two invocations of curl.
>>>
>>> So you agree it is more complicated. The agreed goal is to pus= h complexity to the server.
>>
>>
>> Agreed by whom?
>
>
> There seemed consensus on this, and I think should be a guiding princi= pal. All other things being equal, move complexity to the side that has few= er implementations and is likely to be done by less sophisticated implement= ors.

s/less/more/ I assume.

>
> -- Dick
>

--f46d040839f1634afc04cfebf5d6-- From dick.hardt@gmail.com Sun Dec 2 21:26:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1605621F878C for ; Sun, 2 Dec 2012 21:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+Oyw9k-iu66 for ; Sun, 2 Dec 2012 21:26:07 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 471BF21F81FF for ; Sun, 2 Dec 2012 21:26:07 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1051935dae.31 for ; Sun, 02 Dec 2012 21:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=SVfWozLqAokHbRozsddqmlwdxJEOs+5C7n/MBBTL3ko=; b=SCrrKndxvZqpNWGkrVr37DptE6AiuieBo4FVib/9iRZk2lKCdnOjX010aPRsO4qpmz eBivHy3lCCFpIhNdSgceRY0V6NNDf35u69xrqmHmSzVRmr7BVkMpmYiNbzvv+5vRdwsG 0RpeRZmCMEfATvDJu3+uGIAiyReo/tdUPK0rBQyA7M4ReeCPhM69Uy206tJn0x6Zqq5U XdDLi/WIHX1LGAQTLU/CAeq6eZdHSYfa/NyTAqujl+SZ+Sos54vGF0OrxOuiQ/CbG/wN kWPsFb+bttjGs5m6yAkP36B2WnJmY7rLKRpfTFf9r/kq75B/hDMgieUaoe8wPgQ3TFs6 wYiw== Received: by 10.68.247.196 with SMTP id yg4mr26466509pbc.167.1354512367074; Sun, 02 Dec 2012 21:26:07 -0800 (PST) Received: from [192.168.3.101] (airnode1222.air-internet.com. [12.110.33.210]) by mx.google.com with ESMTPS id ug6sm7433611pbc.4.2012.12.02.21.26.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 21:26:06 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_EB550CFA-71C3-409E-B45B-0D72A15A863C" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Sun, 2 Dec 2012 21:26:01 -0800 Message-Id: References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> To: John Panzer X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org, webfinger@googlegroups.com, Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:26:08 -0000 --Apple-Mail=_EB550CFA-71C3-409E-B45B-0D72A15A863C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 2, 2012, at 9:24 PM, John Panzer wrote: > On Dec 2, 2012 9:19 PM, "Dick Hardt" wrote: > > > > > > On Dec 2, 2012, at 9:10 PM, Nico Williams = wrote: > >> > >> > >> My domain's hosting site, for example. This is not about the = hosting site: it's about the incomplete deployment of TLS SNI. > > > > > > Would motivating hosting sites to do complete deployment of TLS SNI = not be a good thing? > > > >> =20 > >>> > >>> > > >>> > Many clients don't do proper server cert validation. "I used = TLS" !=3D > >>> > "I got it securely". > >>> > >>> So we should not force HTTPS because some clients don't implement = it properly? Really? > >> > >> > >> No, we should not mandate TLS if either we know that requirement = will often be ignored or if we're doing it because we think that gets = use "security". And if we do end up requiring TLS we need to say a lot = more about server certificate validation, about TLS cipher suites (e.g., = no anon DH ones), and so on, about trust anchors (same as for web = browsers?). > > > > > > We mandated TLS in OAuth 2.0 without any of that. Not sure why that = is suddenly an issue now. > > > >> =20 > >>> > >>> > > >>> >> There is a real latency and extra code in dealing with the = fallback as currently specified. > >>> > > >>> > But is that relevant here? > >>> > >>> I would think so. If the user is waiting for discovery to be = finished, latency is an issue. > >>> Extra code is extra code and complexity and more to understand. > >> > >> > >> I wouldn't worry about a line of code given TLS' complexity, which = we'd be requiring. =20 > > > > > > TLS support is in libraries readily available to clients. Yes, some = of them need to be improved to have *better* support of TLS, but that is = a separate issue. > > > >> The latency involved in one more fallback may well matter, but I'm = not ready to conclude that it means we must require TLS because we could = still consider the alternative that the WF app/ user be the one to = decide whether to use TLS at all or not, without a fallback in either = case > > > > > > The latest spec requires an HTTPS call to start ALL the time. > > > > Choice of what to use adds complexity and incorrect choices by = implementations. > > > >> (actually, I prefer this alternative). > > > > > > And how would the WF app decide if to use TLS or not, or how will it = discover what the server supports?=20 > > > >> =20 > >>> > >>> >> For example, we lose being able to use a simple CURL command to = get a JRD. > >>> > > >>> > So you need an if and two invocations of curl. > >>> > >>> So you agree it is more complicated. The agreed goal is to push = complexity to the server. > >> > >> > >> Agreed by whom? > > > > > > There seemed consensus on this, and I think should be a guiding = principal. All other things being equal, move complexity to the side = that has fewer implementations and is likely to be done by less = sophisticated implementors. >=20 > s/less/more/ I assume >=20 >=20 Yes, thanks, John. Working with PowerPoint right now. My brain is being = rewired on me. -- Dick --Apple-Mail=_EB550CFA-71C3-409E-B45B-0D72A15A863C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Dec 2, 2012, at 9:24 PM, John Panzer <jpanzer@google.com> wrote:

On Dec 2, 2012 9:19 PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:
>
>
> On Dec 2, 2012, at 9:10 PM, Nico Williams <nico@cryptonector.com> wrote:
>>
>>
>> My domain's hosting site, for example.  This is not about the hosting site: it's about the incomplete deployment of TLS SNI.
>
>
> Would motivating hosting sites to do complete deployment of TLS SNI not be a good thing?
>
>>  
>>>
>>> >
>>> > Many clients don't do proper server cert validation.  "I used TLS" !=
>>> > "I got it securely".
>>>
>>> So we should not force HTTPS because some clients don't implement it properly? Really?
>>
>>
>> No, we should not mandate TLS if either we know that requirement will often be ignored or if we're doing it because we think that gets use "security".  And if we do end up requiring TLS we need to say a lot more about server certificate validation, about TLS cipher suites (e.g., no anon DH ones), and so on, about trust anchors (same as for web browsers?).
>
>
> We mandated TLS in OAuth 2.0 without any of that. Not sure why that is suddenly an issue now.
>
>>  
>>>
>>> >
>>> >> There is a real latency and extra code in dealing with the fallback as currently specified.
>>> >
>>> > But is that relevant here?
>>>
>>> I would think so. If the user is waiting for discovery to be finished, latency is an issue.
>>> Extra code is extra code and complexity and more to understand.
>>
>>
>> I wouldn't worry about a line of code given TLS' complexity, which we'd be requiring.  
>
>
> TLS support is in libraries readily available to clients. Yes, some of them need to be improved to have *better* support of TLS, but that is a separate issue.
>
>> The latency involved in one more fallback may well matter, but I'm not ready to conclude that it means we must require TLS because we could still consider the alternative that the WF app/ user be the one to decide whether to use TLS at all or not, without a fallback in either case
>
>
> The latest spec requires an HTTPS call to start ALL the time.
>
> Choice of what to use adds complexity and incorrect choices by implementations.
>
>> (actually, I prefer this alternative).
>
>
> And how would the WF app decide if to use TLS or not, or how will it discover what the server supports? 
>
>>  
>>>
>>> >> For example, we lose being able to use a simple CURL command to get a JRD.
>>> >
>>> > So you need an if and two invocations of curl.
>>>
>>> So you agree it is more complicated. The agreed goal is to push complexity to the server.
>>
>>
>> Agreed by whom?
>
>
> There seemed consensus on this, and I think should be a guiding principal. All other things being equal, move complexity to the side that has fewer implementations and is likely to be done by less sophisticated implementors.

s/less/more/ I assume



Yes, thanks, John. Working with PowerPoint right now. My brain is being rewired on me.

-- Dick

--Apple-Mail=_EB550CFA-71C3-409E-B45B-0D72A15A863C-- From jpanzer@google.com Sun Dec 2 21:27:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929F421F878E for ; Sun, 2 Dec 2012 21:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt+e13rgHLly for ; Sun, 2 Dec 2012 21:27:47 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 723BA21F81FF for ; Sun, 2 Dec 2012 21:27:47 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2044538lbk.31 for ; Sun, 02 Dec 2012 21:27:46 -0800 (PST) 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=q0DtfEzWOe/ad3hx0PvsL67oMehn9sEi14fEtRWWS4k=; b=pkF4NO1G6DdS3RX3+8nG0qDJ8m9UyqweqKeWiTA7VekcZfee+0IIEjMZiVNVGJSium Jcu5FPSJVrxYCaKiXqNQ/HreAJK2mWZlyBEAFLkwiarKs+V65y8IdIuJyM+8cG2OWYQq 8PwWIB3pkzNXQ51ozUdOiDmx5iBzaro963D3PirmjlCsw4FM3q0BRoshmmj5kjAoW90G VE1MCGJIm4Y/CKoIEyXvAMYqKPVqWh8ZO3HW3otaaSOKOlSfvIVtWW7ghc/P/KLkZamr 9jMAGKNZU/bolcqzN1M9TvXpPBF+TNoqbhPYbK7Ycmatks020xZngjDMyK7zX2xzL/18 nSUg== X-Google-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:x-gm-message-state; bh=q0DtfEzWOe/ad3hx0PvsL67oMehn9sEi14fEtRWWS4k=; b=dA3fs+1aYy+ZYwN6NkU1Z016Qq4ZYcGJkxDIl1mUKwyqULpM1f8Xj674yfGz9YQ6cb Dlx93A9fEyTvC8OPgkPUyrVfXWxKNAYLFTf6h9Pn705GU5tDGU3oY7A9vqX9mt0l0Qea yeJ5Yuhdwvzm/ihv3cV+7TcF6A5QkyjfCyeLWlMLz5DNuivi3YvbZgDdLsH6Ze1P85WW pqodI6D5oKNukQq9+2zDZ7l1acX+pfjxdFaWvLd/rPExqvTc2xnYgaHSXLdsghLjMHay sMqqh5Y+7A+/EnOu9ir7Jv/o+g/VVO+Ha1Q/I5rc4a2tyg9Q+VZJelC/MdezE1yOSfpZ ep+A== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr8219398lab.11.1354512466455; Sun, 02 Dec 2012 21:27:46 -0800 (PST) Received: by 10.114.4.197 with HTTP; Sun, 2 Dec 2012 21:27:46 -0800 (PST) Received: by 10.114.4.197 with HTTP; Sun, 2 Dec 2012 21:27:46 -0800 (PST) In-Reply-To: References: Date: Sun, 2 Dec 2012 21:27:46 -0800 Message-ID: From: John Panzer To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04088ef5682cc704cfec0222 X-Gm-Message-State: ALoCoQnisF2ZI8IfugEofIhMZ4luSyhBp/YO4sijs1wWY0NDU+KP0rF5eGt2/GRa7tpo4/Ub3kbHW0TS1fvaHo9wv8336iBE2GdL8ePr3MG3kEl7ueIMz6PKav/nTKbqIzyKjNjdf8qmaphy9SNOQIq5K6w8y4+RsAkbrNw3bQglHdECvF5sOT27pmq/riTLjLzD89mPa54E Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:27:48 -0000 --f46d04088ef5682cc704cfec0222 Content-Type: text/plain; charset=ISO-8859-1 +1. On Dec 2, 2012 5:15 PM, "Tim Bray" wrote: > Proposal: Change para 2 of section 5.2 to read as follows: > > Clients MUST query the server using HTTPS. If an HTTPS connection cannot > be established, or returns an HTTP status code indicating some error, such > as 4xx or 5xx, the client MUST report an error and MUST cease attempting to > retrieve the resource. > > --f46d04088ef5682cc704cfec0222 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1.

On Dec 2, 2012 5:15 PM, "Tim Bray" <= ;tbray@textuality.com> wrote= :
Proposal: Change para 2 of section 5.2 to read as follows:

Clients M= UST query the server using HTTPS. If an HTTPS connection cannot be establis= hed, or returns an HTTP status code indicating some error, such as 4xx or 5= xx, the client MUST report an error and MUST cease attempting to retrieve t= he resource.

--f46d04088ef5682cc704cfec0222-- From jasnell@gmail.com Sun Dec 2 21:37:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A317E21F89A9 for ; Sun, 2 Dec 2012 21:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pojIFCdWxXwe for ; Sun, 2 Dec 2012 21:37:48 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2571B21F899C for ; Sun, 2 Dec 2012 21:37:48 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so3823187ieb.31 for ; Sun, 02 Dec 2012 21:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=64NmAw/8eqn7lem1tz4LsDNHKAcEE3j3xLcs4yQ79QQ=; b=o01dv5MMVYqgQ7X1Dx1UZ8eby8PS9/cPlPVEn8Ejvi7f/ZLqsZjGOOP39AAUHlbkrH JT2k1g1mfrw80zqXQnzp6EVobsZM1iD1NukJZwVP3Ytt0BnsYPAPCRGQ1g9f9A166oUr pdBue+UTFf0TsAXiQZnqqoyb4U7htbaGkz3cHy01aP8HlyeTGKneL3+YXtur7DYnTG0E A8Zi2CTtHo0eHRnEk++/jCzDLmF66CP5kKpcEpm48Cd0Gb3PxPH7FTDtVmeAI3maUaUo UvA88lKfhLhKJEIFw54u9Aki3RXNaaxUlhDBa6vfZ4eHw/c/p+THaNM0LQd8FM0peYTW 38GA== Received: by 10.50.203.101 with SMTP id kp5mr5197318igc.61.1354513067643; Sun, 02 Dec 2012 21:37:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.41.229 with HTTP; Sun, 2 Dec 2012 21:37:27 -0800 (PST) In-Reply-To: References: From: James M Snell Date: Sun, 2 Dec 2012 21:37:27 -0800 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=14dae93407713d964c04cfec269b Cc: "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Draft -07 mod proposal: Remove top-level "properties" in JRD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:37:50 -0000 --14dae93407713d964c04cfec269b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1. While I personally would not have added "properties" in were I designing the basic format, it must be recognized that there are existing implementations that are making use of "properties" and use cases have been put forward that show where it can be useful to reduce the number of roundtrips necessary for various configurations. Yes, ultimately, it may prove out that "properties" isn't as useful or helpful as the original authors intended but that's something that will only truly come to light once the spec is out in the hands of implementors. For now, I don't believe it's been adequately demonstrated to be "actively harmful" and rather than bike shedding on the format any longer, let's go with this and see what implementors actually do with it in the wild. - James On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > This is actively harmful. Link relations are an excellent way to express > properties of a resource, and having two competing mechanisms will distra= ct > developers and hurt interoperability. > > Proposal: > > 1. Introduction: s/link relations, properties, titles/link relations, > titles/ > 3. Overview: same > 4.1 remove "properties:" member of JRD > 4.1 last para s/and properties// > 4.2 remove "properties:" member of JRD > 4.2 s/any aliases and properties/any aliases/ > 4.3 remove "properties" top-level member of JRD > 5.2 remove "properties" from bullet list after 1st para > 5.2 s/"properties" is an object comprised of name/value pairs whose value= s > are strings// > 5.2.4 Remove section > 5.3 example, remove top-level "properties" member > 5.4 s/and properties// > > > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wro= te: > >> Folks,**** >> >> ** ** >> >> I published another version of the WebFinger spec trying to bring closur= e >> to the two open issues I see (resource representation and transport). T= he >> new version is here:**** >> >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >> >> ** ** >> >> With respect to resource representation, I fully described the JSON >> Resource Descriptor within the document. There are no external referenc= es >> to RFC 6415 now, no need to go read the XRD spec, etc. It=E2=80=99s a f= airly >> simple format and I believe this text documents it sufficiently. Combin= ed >> with the visual examples, I think this makes it pretty clear. Have a lo= ok >> at the JRD documentation in section 5.2 and provide your comments. **** >> >> ** ** >> >> With respect to HTTPS, it seems there is strong preference for =E2=80=9C= HTTPS >> only=E2=80=9D, but some a fair bit of insistence for allowing HTTP. I c= hanged the >> wording in 5.2 to try to capture opinions. Previously, the text led wit= h a >> requirement to try HTTPS first. That is still there. I just added some >> extra conditions that make it clearer that there are some instances wher= e a >> client must not utilize HTTP. This might need further refinement, but I >> think there is a balance we can strike here between the two camps withou= t >> introducing a lot of complex language.**** >> >> ** ** >> >> I made some editorial changes through the document.**** >> >> ** ** >> >> Comments are welcome, as always. Seems I don=E2=80=99t need to say that= to this >> group, though :-)**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --14dae93407713d964c04cfec269b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1. While I personally would not have = added "properties" in were I designing the basic format, it must = be recognized that there are existing implementations that are making use o= f "properties" and use cases have been put forward that show wher= e it can be useful to reduce the number of roundtrips necessary for various= configurations. Yes, ultimately, it may prove out that "properties&qu= ot; isn't as useful or helpful as the original authors intended but tha= t's something that will only truly come to light once the spec is out i= n the hands of implementors. For now, I don't believe it's been ade= quately demonstrated to be "actively harmful" and rather than bik= e shedding on the format any longer, let's go with this and see what im= plementors actually do with it in the wild.

- James


On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray <tbray@textuality.com><= /span> wrote:
This is actively harmful.=C2=A0 Link relatio= ns are an excellent way to express properties of a resource, and having two= competing mechanisms will distract developers and hurt interoperability.
Proposal:

1. Introduction: s/link relations, properties,=C2=A0 t= itles/link relations, titles/
3. Overview: same
4.1 remove "properties:" member of JRD
4.= 1 last para s/and properties//
4.2 remove "properties:" member= of JRD
4.2 s/any aliases and properties/any aliases/
4.3 remove &quo= t;properties" top-level member of JRD
5.2 remove "properties" from bullet list after 1st para
5.2 s/= "properties" is an object comprised of name/value pairs whose val= ues are strings//
5.2.4 Remove section
5.3 example, remove top-level = "properties" member
5.4 s/and properties//


On Sun, Dec 2,= 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com>= wrote:

Folks,

=C2=A0

I published another version of the WebFinger spec tr= ying to bring closure to the two open issues I see (resource representation= and transport).=C2=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

=C2=A0

With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=C2=A0 There are no external references to= RFC 6415 now, no need to go read the XRD spec, etc. =C2=A0It=E2=80=99s a f= airly simple format and I believe this text documents it sufficiently.=C2= =A0 Combined with the visual examples, I think this makes it pretty clear.= =C2=A0 Have a look at the JRD documentation in section 5.2 and provide your= comments.

=C2=A0

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS on= ly=E2=80=9D, but some a fair bit of insistence for allowing HTTP.=C2=A0 I c= hanged the wording in 5.2 to try to capture opinions.=C2=A0 Previously, the= text led with a requirement to try HTTPS first.=C2=A0 That is still there.= =C2=A0 I just added some extra conditions that make it clearer that there a= re some instances where a client must not utilize HTTP.=C2=A0 This might ne= ed further refinement, but I think there is a balance we can strike here be= tween the two camps without introducing a lot of complex language.

=C2=A0

I mad= e some editorial changes through the document.

=C2=A0

Comments are wel= come, as always.=C2=A0 Seems I don=E2=80=99t need to say that to this group= , though :-)

=C2=A0

Paul

=C2=A0


__________________________= _____________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--14dae93407713d964c04cfec269b-- From lear@cisco.com Sun Dec 2 21:39:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2025421F89A9 for ; Sun, 2 Dec 2012 21:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.348 X-Spam-Level: X-Spam-Status: No, score=-110.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw6zI11pdEjM for ; Sun, 2 Dec 2012 21:39:03 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0E34421F89B1 for ; Sun, 2 Dec 2012 21:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3567; q=dns/txt; s=iport; t=1354513143; x=1355722743; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=L/Gr9TsU8wMD6LjKAmk5WfXFtrp8eLfQ0h5FX6NhW7M=; b=lt1gDWq1eAFZF/n4THvay+BWDJieXHmM8g9RvtaJPuKFTE94iQQ//i+y g5UiKzZo7bE0RG5GH5ZDIjB4jR7RFRTqmNTNGchwgvMppaflFKWRZxgcc Bt3TQ10RSF93Obenesqzu4dvQ62Jo9RkBvEnCGCIS1h+jzauqQkAp+eix s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAL85vFCQ/khL/2dsb2JhbABEhiyFX7N0FnOCHgEBAQQBAQEgSwoBEAsECgoJFgsCAgkDAgECARUwBg0BBQIBAYgMDKwrkWkEjEuDI4ETA5YBkEeCc4Fr X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="10094120" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 03 Dec 2012 05:39:01 +0000 Received: from dhcp-10-55-80-36.cisco.com (dhcp-10-55-80-36.cisco.com [10.55.80.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB35d0qP005483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 05:39:01 GMT Message-ID: <50BC3AF5.2080507@cisco.com> Date: Mon, 03 Dec 2012 06:39:01 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------000802020707020503010109" Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:39:04 -0000 This is a multi-part message in MIME format. --------------000802020707020503010109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Department of "here we go again". TLS does not require security on its own. Making mandatory use of it requires a signed certificate. Self-signed certs are common in enterprise (and other environments). One of the examples given in the draft (4.3 email client) is a classic enterprise configuration matter. And so what this would do is force more nags at the user about untrusted certificates. Worse– some email clients (in the given example) may not handle that warning well. So on the whole, I'd oppose any sort of language like the below. It's too strong, and eliminates webfinger from serious consideration within the enterprise. Eliot On 12/3/12 2:15 AM, Tim Bray wrote: > Proposal: Change para 2 of section 5.2 to read as follows: > > Clients MUST query the server using HTTPS. If an HTTPS connection > cannot be established, or returns an HTTP status code indicating some > error, such as 4xx or 5xx, the client MUST report an error and MUST > cease attempting to retrieve the resource. > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------000802020707020503010109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Department of "here we go again".

TLS does not require security on its own.  Making mandatory use of it requires a signed certificate.  Self-signed certs are common in enterprise (and other environments).  One of the examples given in the draft (4.3 email client) is a classic enterprise configuration matter.  And so what this would do is force more nags at the user about untrusted certificates.  Worse– some email clients (in the given example) may not handle that warning well.

So on the whole, I'd oppose any sort of language like the below.  It's too strong, and eliminates webfinger from serious consideration within the enterprise.

Eliot

On 12/3/12 2:15 AM, Tim Bray wrote:
Proposal: Change para 2 of section 5.2 to read as follows:

Clients MUST query the server using HTTPS. If an HTTPS connection cannot be established, or returns an HTTP status code indicating some error, such as 4xx or 5xx, the client MUST report an error and MUST cease attempting to retrieve the resource.



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--------------000802020707020503010109-- From tbray@textuality.com Sun Dec 2 21:42:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA2521F89A9 for ; Sun, 2 Dec 2012 21:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e73YhtFb-dKF for ; Sun, 2 Dec 2012 21:42:33 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 16C0621F8998 for ; Sun, 2 Dec 2012 21:42:28 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2545019oag.31 for ; Sun, 02 Dec 2012 21:42:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=vmi/QvV85AhePbXtsHoCihcC9PsRwAZlOS3l/2ADNY8=; b=pQOHnCVV2dESCRKpoY/sFGFG5pGbOAHs930rFr0eVpIsg3AESwy3U5DrUyXuMff7Fo sL2MxXsdhuESDM6qw6zQvdTZ7nMYB1etcNBajZVeX5pXlkyi86bAW0I2kvNZNVgzNc7Z pQ4RGHvS6V+6Aqxv7o+iab2+kGkAltzoQA2KLEMVISsnol14IfpSkXs5wzDFKpmRBhza 2vTsXxm87Bc7TwixfEuD+PLW5IxNVB2r2Ee6zwQACuV4LqmN1r9IL5jFFCNXi7uaEaxQ e+fXrQMfNUmzZk2BQKcpU2jPq2z+T210/uJz4wq9gqdnEXjXCZ2JLwEB9mhkeyCFE1NE GSfg== MIME-Version: 1.0 Received: by 10.60.3.231 with SMTP id f7mr7545620oef.43.1354513348460; Sun, 02 Dec 2012 21:42:28 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 21:42:28 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Sun, 2 Dec 2012 21:42:28 -0800 Message-ID: From: Tim Bray To: James M Snell Content-Type: multipart/alternative; boundary=e89a8ff1ce48fa808704cfec361a X-Gm-Message-State: ALoCoQlxJf/myt72V9WmQToDU7O3Hq0j9c3sHzySpNCuc/t3IKenCo7PCetekCf08tGLW31hq5sH Cc: "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Draft -07 mod proposal: Remove top-level "properties" in JRD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:42:35 -0000 --e89a8ff1ce48fa808704cfec361a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What=92s it for? -T On Sun, Dec 2, 2012 at 9:37 PM, James M Snell wrote: > -1. While I personally would not have added "properties" in were I > designing the basic format, it must be recognized that there are existing > implementations that are making use of "properties" and use cases have be= en > put forward that show where it can be useful to reduce the number of > roundtrips necessary for various configurations. Yes, ultimately, it may > prove out that "properties" isn't as useful or helpful as the original > authors intended but that's something that will only truly come to light > once the spec is out in the hands of implementors. For now, I don't belie= ve > it's been adequately demonstrated to be "actively harmful" and rather tha= n > bike shedding on the format any longer, let's go with this and see what > implementors actually do with it in the wild. > > - James > > > On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > >> This is actively harmful. Link relations are an excellent way to expres= s >> properties of a resource, and having two competing mechanisms will distr= act >> developers and hurt interoperability. >> >> Proposal: >> >> 1. Introduction: s/link relations, properties, titles/link relations, >> titles/ >> 3. Overview: same >> 4.1 remove "properties:" member of JRD >> 4.1 last para s/and properties// >> 4.2 remove "properties:" member of JRD >> 4.2 s/any aliases and properties/any aliases/ >> 4.3 remove "properties" top-level member of JRD >> 5.2 remove "properties" from bullet list after 1st para >> 5.2 s/"properties" is an object comprised of name/value pairs whose >> values are strings// >> 5.2.4 Remove section >> 5.3 example, remove top-level "properties" member >> 5.4 s/and properties// >> >> >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wr= ote: >> >>> Folks,**** >>> >>> ** ** >>> >>> I published another version of the WebFinger spec trying to bring >>> closure to the two open issues I see (resource representation and >>> transport). The new version is here:**** >>> >>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >>> >>> ** ** >>> >>> With respect to resource representation, I fully described the JSON >>> Resource Descriptor within the document. There are no external referen= ces >>> to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly >>> simple format and I believe this text documents it sufficiently. Combi= ned >>> with the visual examples, I think this makes it pretty clear. Have a l= ook >>> at the JRD documentation in section 5.2 and provide your comments. **** >>> >>> ** ** >>> >>> With respect to HTTPS, it seems there is strong preference for =93HTTPS >>> only=94, but some a fair bit of insistence for allowing HTTP. I change= d the >>> wording in 5.2 to try to capture opinions. Previously, the text led wi= th a >>> requirement to try HTTPS first. That is still there. I just added som= e >>> extra conditions that make it clearer that there are some instances whe= re a >>> client must not utilize HTTP. This might need further refinement, but = I >>> think there is a balance we can strike here between the two camps witho= ut >>> introducing a lot of complex language.**** >>> >>> ** ** >>> >>> I made some editorial changes through the document.**** >>> >>> ** ** >>> >>> Comments are welcome, as always. Seems I don=92t need to say that to t= his >>> group, though :-)**** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > --e89a8ff1ce48fa808704cfec361a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What=92s it for? -T

On Sun, Dec 2, 2012 a= t 9:37 PM, James M Snell <jasnell@gmail.com> wrote:
-1. While I personally would not have = added "properties" in were I designing the basic format, it must = be recognized that there are existing implementations that are making use o= f "properties" and use cases have been put forward that show wher= e it can be useful to reduce the number of roundtrips necessary for various= configurations. Yes, ultimately, it may prove out that "properties&qu= ot; isn't as useful or helpful as the original authors intended but tha= t's something that will only truly come to light once the spec is out i= n the hands of implementors. For now, I don't believe it's been ade= quately demonstrated to be "actively harmful" and rather than bik= e shedding on the format any longer, let's go with this and see what im= plementors actually do with it in the wild.

- James


On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray <tbray@textuality.com><= /span> wrote:
This is actively harmful.=A0 Link relations = are an excellent way to express properties of a resource, and having two co= mpeting mechanisms will distract developers and hurt interoperability.

Proposal:

1. Introduction: s/link relations, properties,=A0 titl= es/link relations, titles/
3. Overview: same
4.1 remove "properties:" member of JRD
4.= 1 last para s/and properties//
4.2 remove "properties:" member= of JRD
4.2 s/any aliases and properties/any aliases/
4.3 remove &quo= t;properties" top-level member of JRD
5.2 remove "properties" from bullet list after 1st para
5.2 s/= "properties" is an object comprised of name/value pairs whose val= ues are strings//
5.2.4 Remove section
5.3 example, remove top-level = "properties" member
5.4 s/and properties//


On Sun, Dec 2,= 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com>= wrote:

Folks,

=A0

I published another version of the WebFinger spec tr= ying to bring closure to the two open issues I see (resource representation= and transport).=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

=A0

With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=A0 There are no external references to RF= C 6415 now, no need to go read the XRD spec, etc. =A0It=92s a fairly simple= format and I believe this text documents it sufficiently.=A0 Combined with= the visual examples, I think this makes it pretty clear.=A0 Have a look at= the JRD documentation in section 5.2 and provide your comments. =

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)

=A0

<= p class=3D"MsoNormal">Paul

= =A0


_______________________________= ________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--e89a8ff1ce48fa808704cfec361a-- From jasnell@gmail.com Sun Dec 2 21:43:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705CC21F89B1 for ; Sun, 2 Dec 2012 21:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbNqx22AdtgH for ; Sun, 2 Dec 2012 21:43:07 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 452CB21F8998 for ; Sun, 2 Dec 2012 21:43:07 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2032308iaz.31 for ; Sun, 02 Dec 2012 21:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=k5cbcWu48b60ju0WuLMgC5LtR7hVRNrKG6p88tjYoMo=; b=YctjNVdROpSUudhDXYmbwIHe+QnyZemSX5QMJzU3kkckatKU1MgEab/VWyvi3X+QTr U3wjwfEBYjmaHUh2JDTozhDwCK22HDoD17JsXaQxlhgGGTTfvjwt3PzIeZ5mKA3oEw3R QtoYw1E0fY3s5SKn5nTlB47PYREob4eGcBKvbqnGLrWss8fpjNwF2g8tjF7b8ZA7hW4B iYqHFMFdwUheli7XxSdX4wJ0QNYe7/CsX1NZBa3iNEtIm+a4hV7a6eh+R1TxD/rUTMWN JH7HJtDs3GrApIe2EF7ZYUIJDWI9q16Ksvmtck6d8d48zuZhd90PE/5vhIspGvXKTzAa f+ew== Received: by 10.42.138.74 with SMTP id b10mr6983767icu.33.1354513386791; Sun, 02 Dec 2012 21:43:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.41.229 with HTTP; Sun, 2 Dec 2012 21:42:46 -0800 (PST) In-Reply-To: References: From: James M Snell Date: Sun, 2 Dec 2012 21:42:46 -0800 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=90e6ba6138a24363be04cfec397f Cc: "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:43:09 -0000 --90e6ba6138a24363be04cfec397f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1 ... fixing this would be good but your proposed text isn't quite enough without either defining or specifically referencing what "equivalence" means. For example, as currently defined, the resource parameter can be a relative URI reference, while the subject could be an absolute URI reference. How does one determine equivalence exactly? - James On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > Right now, section 5.2.2 says "The value of the "subject" member is a > string that MUST be set to the same value as the "resource" parameter in > the client request. " > > This is a recipe for trouble, for a couple of reasons. First of all, what > does =E2=80=9Cthe same value=E2=80=9D mean? Go visit RFC3986, section 6,= and enjoy several > hundred words walking through all the issues that arise in trying to figu= re > out when two URIs are equivalent, ranging from exact character-by-charact= er > identity to all sorts of protocol-specific goo. You are just one level of > case-sensitivity-in-%-escaping from a big hairy false negative. > > I=E2=80=99m also worried about a lack of flexibility. I might have a sing= le > webfinger resource that declares a bunch of link relations for a bunch of > different resources. This section, as written, wouldn=E2=80=99t let me do= that. > > Proposal: Re-write section 5.2.2 as follows: > > <<<<<<< > The value of the "subject" member is a string whose value is advisory, > identifying the resource to which the properties given in the "links" > member apply. Normally this would be expected to be equivalent to the > value of the "resource" parameter in the client request. > <<<<<<< > > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wro= te: > >> Folks,**** >> >> ** ** >> >> I published another version of the WebFinger spec trying to bring closur= e >> to the two open issues I see (resource representation and transport). T= he >> new version is here:**** >> >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >> >> ** ** >> >> With respect to resource representation, I fully described the JSON >> Resource Descriptor within the document. There are no external referenc= es >> to RFC 6415 now, no need to go read the XRD spec, etc. It=E2=80=99s a f= airly >> simple format and I believe this text documents it sufficiently. Combin= ed >> with the visual examples, I think this makes it pretty clear. Have a lo= ok >> at the JRD documentation in section 5.2 and provide your comments. **** >> >> ** ** >> >> With respect to HTTPS, it seems there is strong preference for =E2=80=9C= HTTPS >> only=E2=80=9D, but some a fair bit of insistence for allowing HTTP. I c= hanged the >> wording in 5.2 to try to capture opinions. Previously, the text led wit= h a >> requirement to try HTTPS first. That is still there. I just added some >> extra conditions that make it clearer that there are some instances wher= e a >> client must not utilize HTTP. This might need further refinement, but I >> think there is a balance we can strike here between the two camps withou= t >> introducing a lot of complex language.**** >> >> ** ** >> >> I made some editorial changes through the document.**** >> >> ** ** >> >> Comments are welcome, as always. Seems I don=E2=80=99t need to say that= to this >> group, though :-)**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --90e6ba6138a24363be04cfec397f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1 ... fixing this would be good but y= our proposed text isn't quite enough without either defining or specifi= cally referencing what "equivalence" means. For example, as curre= ntly defined, the resource parameter can be a relative URI reference, while= the subject could be an absolute URI reference. How does one determine equ= ivalence exactly?=C2=A0

 --90e6ba6138a24363be04cfec397f-- From tbray@textuality.com Sun Dec 2 21:49:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0521F89E3 for ; Sun, 2 Dec 2012 21:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5OK3fx9kSxn for ; Sun, 2 Dec 2012 21:49:23 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 507BE21F89B1 for ; Sun, 2 Dec 2012 21:49:23 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2318766obc.31 for ; Sun, 02 Dec 2012 21:49:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=tlOBs9XZSHJ6PhXRIxIrk5AkkgK4O9mo/czaDmoP6FY=; b=fArxckmmZ3sRwNmBx3JHd6UFv17WYW/3VTC8OXAYGGWIPT7eeR4WbWOqZz1aE3kuuV zKWDWEnLgqaPcFheBejbASrjB17j7xWTZ/SlRUj9W22J6HvGAfvn14N3NOPLlJyXYdox 9tN/YwsyR2vzVRHY5FjNsl5zfaJc9qhmSBC5x1te2qV7b80OEPoc92aaaxMVU98/G5sB ZyHhAL40CxP5dwDuoSdS5bI5NWk2ikN9OtUH5Bc8RvzhNh3E0z5dnrS7E/E/NXXv+2SV cDZ23GGFdRvKlTqLcZxsWkyIEqu6Yvr6ZZQzIG57AY0WyG1JQcmoIGnQkpJxxF2Lr6Sp mVDg== MIME-Version: 1.0 Received: by 10.60.4.165 with SMTP id l5mr1494025oel.84.1354513762662; Sun, 02 Dec 2012 21:49:22 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 21:49:22 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Sun, 2 Dec 2012 21:49:22 -0800 Message-ID: From: Tim Bray To: James M Snell Content-Type: multipart/alternative; boundary=e89a8ff1c2e8aab88704cfec4fa5 X-Gm-Message-State: ALoCoQnDUZRfx31R9zsTbiH05PTG/p0a0H/wIkrM7oRyTR2LBwquHIcqyUATNeWp/i+ttWLaMt3z Cc: "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:49:24 -0000 --e89a8ff1c2e8aab88704cfec4fa5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sounds to me like you=92re arguing my side of it. The current language suggests that you should turf the JRD if they=92re not =93the same value=94= that you put in your query. There are lots of reasons why they might not be byte-for-byte or even character-for-character identical, and still be equivalent for all practical purposes. -T On Sun, Dec 2, 2012 at 9:42 PM, James M Snell wrote: > -1 ... fixing this would be good but your proposed text isn't quite enoug= h > without either defining or specifically referencing what "equivalence" > means. For example, as currently defined, the resource parameter can be a > relative URI reference, while the subject could be an absolute URI > reference. How does one determine equivalence exactly? > > - James > > > On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > >> Right now, section 5.2.2 says "The value of the "subject" member is a >> string that MUST be set to the same value as the "resource" parameter in >> the client request. " >> >> This is a recipe for trouble, for a couple of reasons. First of all, wha= t >> does =93the same value=94 mean? Go visit RFC3986, section 6, and enjoy = several >> hundred words walking through all the issues that arise in trying to fig= ure >> out when two URIs are equivalent, ranging from exact character-by-charac= ter >> identity to all sorts of protocol-specific goo. You are just one level o= f >> case-sensitivity-in-%-escaping from a big hairy false negative. >> >> I=92m also worried about a lack of flexibility. I might have a single >> webfinger resource that declares a bunch of link relations for a bunch o= f >> different resources. This section, as written, wouldn=92t let me do that= . >> >> Proposal: Re-write section 5.2.2 as follows: >> >> <<<<<<< >> The value of the "subject" member is a string whose value is advisory, >> identifying the resource to which the properties given in the "links" >> member apply. Normally this would be expected to be equivalent to the >> value of the "resource" parameter in the client request. >> <<<<<<< >> >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wr= ote: >> >>> Folks,**** >>> >>> ** ** >>> >>> I published another version of the WebFinger spec trying to bring >>> closure to the two open issues I see (resource representation and >>> transport). The new version is here:**** >>> >>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >>> >>> ** ** >>> >>> With respect to resource representation, I fully described the JSON >>> Resource Descriptor within the document. There are no external referen= ces >>> to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly >>> simple format and I believe this text documents it sufficiently. Combi= ned >>> with the visual examples, I think this makes it pretty clear. Have a l= ook >>> at the JRD documentation in section 5.2 and provide your comments. **** >>> >>> ** ** >>> >>> With respect to HTTPS, it seems there is strong preference for =93HTTPS >>> only=94, but some a fair bit of insistence for allowing HTTP. I change= d the >>> wording in 5.2 to try to capture opinions. Previously, the text led wi= th a >>> requirement to try HTTPS first. That is still there. I just added som= e >>> extra conditions that make it clearer that there are some instances whe= re a >>> client must not utilize HTTP. This might need further refinement, but = I >>> think there is a balance we can strike here between the two camps witho= ut >>> introducing a lot of complex language.**** >>> >>> ** ** >>> >>> I made some editorial changes through the document.**** >>> >>> ** ** >>> >>> Comments are welcome, as always. Seems I don=92t need to say that to t= his >>> group, though :-)**** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > --e89a8ff1c2e8aab88704cfec4fa5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sounds to me like you=92re arguing my side of it.=A0 The current language s= uggests that you should turf the JRD if they=92re not =93the same value=94 = that you put in your query. There are lots of reasons why they might not be= byte-for-byte or even character-for-character identical, and still be equi= valent for all practical purposes.=A0 -T

On Sun, Dec 2, 2012 at 9:42 PM, James M Snel= l <jasnell@gmail.com> wrote:
-1 ... fixing this would be good but y= our proposed text isn't quite enough without either defining or specifi= cally referencing what "equivalence" means. For example, as curre= ntly defined, the resource parameter can be a relative URI reference, while= the subject could be an absolute URI reference. How does one determine equ= ivalence exactly?=A0<= div>
- James


On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray= <tbray@textuality.com> wrote:
Right now, section 5.2.2 says "The valu= e of the "subject" member is a string that MUST be set to the sam= e value as the "resource" parameter in the client request. "=

This is a recipe for trouble, for a couple of reasons. First of all, wh= at does =93the same value=94 mean?=A0 Go visit RFC3986, section 6, and enjo= y several hundred words walking through all the issues that arise in trying= to figure out when two URIs are equivalent, ranging from exact character-b= y-character identity to all sorts of protocol-specific goo. You are just on= e level of case-sensitivity-in-%-escaping from a big hairy false negative.<= br>
I=92m also worried about a lack of flexibility. I might have a single w= ebfinger resource that declares a bunch of link relations for a bunch of di= fferent resources. This section, as written, wouldn=92t let me do that.

Proposal: Re-write section 5.2.2 as follows:

<<<<<= ;<<
The value of the "subject" member is a string whose = value is advisory, identifying the resource to which the properties given i= n the "links" member apply.=A0 Normally this would be expected to= be equivalent to the value of the "resource" parameter in the cl= ient request.
<<<<<<<

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

I published another version of the WebFinger spec tr= ying to bring closure to the two open issues I see (resource representation= and transport).=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

=A0

With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=A0 There are no external references to RF= C 6415 now, no need to go read the XRD spec, etc. =A0It=92s a fairly simple= format and I believe this text documents it sufficiently.=A0 Combined with= the visual examples, I think this makes it pretty clear.=A0 Have a look at= the JRD documentation in section 5.2 and provide your comments. =

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)

=A0

<= p class=3D"MsoNormal">Paul

= =A0


_______________________________= ________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


- James


<= div class=3D"gmail_quote">On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray <tbr= ay@textuality.com> wrote:
Right now, section 5.2.2 says "The valu= e of the "subject" member is a string that MUST be set to the sam= e value as the "resource" parameter in the client request. "=

This is a recipe for trouble, for a couple of reasons. First of all, wh= at does =E2=80=9Cthe same value=E2=80=9D mean?=C2=A0 Go visit RFC3986, sect= ion 6, and enjoy several hundred words walking through all the issues that = arise in trying to figure out when two URIs are equivalent, ranging from ex= act character-by-character identity to all sorts of protocol-specific goo. = You are just one level of case-sensitivity-in-%-escaping from a big hairy f= alse negative.

I=E2=80=99m also worried about a lack of flexibility. I might have a si= ngle webfinger resource that declares a bunch of link relations for a bunch= of different resources. This section, as written, wouldn=E2=80=99t let me = do that.

Proposal: Re-write section 5.2.2 as follows:

<<<<<= ;<<
The value of the "subject" member is a string whose = value is advisory, identifying the resource to which the properties given i= n the "links" member apply.=C2=A0 Normally this would be expected= to be equivalent to the value of the "resource" parameter in the= client request.
<<<<<<<

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=C2=A0

I published another version of the WebFinger spec tr= ying to bring closure to the two open issues I see (resource representation= and transport).=C2=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

=C2=A0

With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=C2=A0 There are no external references to= RFC 6415 now, no need to go read the XRD spec, etc. =C2=A0It=E2=80=99s a f= airly simple format and I believe this text documents it sufficiently.=C2= =A0 Combined with the visual examples, I think this makes it pretty clear.= =C2=A0 Have a look at the JRD documentation in section 5.2 and provide your= comments.

=C2=A0

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS on= ly=E2=80=9D, but some a fair bit of insistence for allowing HTTP.=C2=A0 I c= hanged the wording in 5.2 to try to capture opinions.=C2=A0 Previously, the= text led with a requirement to try HTTPS first.=C2=A0 That is still there.= =C2=A0 I just added some extra conditions that make it clearer that there a= re some instances where a client must not utilize HTTP.=C2=A0 This might ne= ed further refinement, but I think there is a balance we can strike here be= tween the two camps without introducing a lot of complex language.

=C2=A0

I mad= e some editorial changes through the document.

=C2=A0

Comments are wel= come, as always.=C2=A0 Seems I don=E2=80=99t need to say that to this group= , though :-)

=C2=A0

Paul

=C2=A0


__________________________= _____________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--e89a8ff1c2e8aab88704cfec4fa5-- From jasnell@gmail.com Sun Dec 2 21:52:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD6221F8715 for ; Sun, 2 Dec 2012 21:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMuLuPEniA7U for ; Sun, 2 Dec 2012 21:52:17 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12DBA21F8704 for ; Sun, 2 Dec 2012 21:52:17 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2036041iaz.31 for ; Sun, 02 Dec 2012 21:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GG6wKYMJqnbfFW9BlEWURQGjBLrI4VG3WPQERZ5fUlw=; b=kg4trV1KCZsSch/6DpibntnM4zwCnujqkPWP4G8aKkLbW+eYAhDi1DoYZVcmSsk0R7 DlEf6oiPsDgf8N9LGPk9WAQtdXuZGWQe+exOYry8pvgE4sdY6mGH5fa47AYlJzUzbCAy 98OlzKqiKOi4j4ppaIHh2yf1RrCXdWDJH3aTv7hPO5h3eaC9AR/GExHqwMzivEUK9g4N xVNjqbG0PSfV8ss8jFO3Sdt0xPs1dN2SQ3vzBD80IMr4eSl8KYFKKsi27+6Y0cQlPVi+ 4UVBBK2dGHvaslYng3JTiPX4+uPxw2CFj01+fKxWZFwi2QNaBzOCjzVvMxQ8+XSZhakY GI4Q== Received: by 10.42.138.74 with SMTP id b10mr6996152icu.33.1354513936534; Sun, 02 Dec 2012 21:52:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.41.229 with HTTP; Sun, 2 Dec 2012 21:51:56 -0800 (PST) In-Reply-To: References: From: James M Snell Date: Sun, 2 Dec 2012 21:51:56 -0800 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=90e6ba6138a207cd2804cfec5aa1 Cc: "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:52:18 -0000 --90e6ba6138a207cd2804cfec5aa1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1 ... I believe the utility of the acct scheme when used with WF is readily apparent, and honestly there's no reason to "wait" for acct to be finished. If we complete work on WF before acct is done, the only real impact is that we wait a bit longer for WF to get an RFC#. Implementors can still get started doing their thing. (I do agree that WF is useful with non acct uri's too tho) - James On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > I don=E2=80=99t want to wait for work on this to be completed, and I don= =E2=80=99t think > that its presence is necessary for WebFinger to be useful. So let's take > it out. > > Proposal: > Section 4.1: Change the URI in the example from acct: to mailto: > Section 4.2: Same > Section 5.3: Same > Section 5.4: s/it could be an "acct" URI [7], // > Section 5.4: Remove 2nd para, beginning "For resources associated with a > user account at a host...=E2=80=9C > Section 5.4: s/both an "acct" URI and any alias/any alias/ > Section 8: Change the URI in the example from acct: to mailto: > > > On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: > >> No, we=E2=80=99re on the same side here. I=E2=80=99m suggesting taking w= ebfinger-07 as a >> baseline, and all *future* changes need to be proposed as a concrete del= ta >> against it. -T >> >> >> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones wr= ote: >> >>> Tim,**** >>> >>> ** ** >>> >>> I didn=E2=80=99t mean to be rude by introducing these changes, just try= ing to >>> move things along. Most changes were fairly trivial, not worth mention= ing, >>> and can be seen here:**** >>> >>> >>> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-app= sawg-webfinger-07.txt >>> **** >>> >>> ** ** >>> >>> The most significant changes were the re-write of section 5.2 and >>> modification to the language related to HTTPS in 5.1. I suspect that i= s >>> the text to which you refer as preferring it to be =E2=80=9Ccamera-read= y=E2=80=9D. (I >>> would assume the balance of the changes would not need to be presented = as >>> =E2=80=9Ccamera-ready=E2=80=9D, since they=E2=80=99re minor editorial t= hings.)**** >>> >>> ** ** >>> >>> In any case, the most important text changes I would like folks to >>> consider is section 5.2 (which aims to fully document the JSON Resource >>> Descriptor object) and paragraphs 2 and 3 in section 5.1.**** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> *From:* Tim Bray [mailto:tbray@textuality.com] >>> *Sent:* Sunday, December 02, 2012 2:54 PM >>> *To:* Paul E. Jones >>> *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com >>> *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-07**** >>> >>> ** ** >>> >>> Thanks to Paul for the extra effort. I=E2=80=99d like to suggest, in t= he >>> interests of courtesy and efficiency, that from here on on, contributio= ns >>> to this discussion be =E2=80=9Ccamera-ready=E2=80=9D, that is to say, s= pecific suggestions >>> in the style of a diff, including fully-written-out replacements langua= ge. >>> >>> -Tim**** >>> >>> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones >>> wrote:**** >>> >>> Folks,**** >>> >>> **** >>> >>> I published another version of the WebFinger spec trying to bring >>> closure to the two open issues I see (resource representation and >>> transport). The new version is here:**** >>> >>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >>> >>> **** >>> >>> With respect to resource representation, I fully described the JSON >>> Resource Descriptor within the document. There are no external referen= ces >>> to RFC 6415 now, no need to go read the XRD spec, etc. It=E2=80=99s a = fairly >>> simple format and I believe this text documents it sufficiently. Combi= ned >>> with the visual examples, I think this makes it pretty clear. Have a l= ook >>> at the JRD documentation in section 5.2 and provide your comments. **** >>> >>> **** >>> >>> With respect to HTTPS, it seems there is strong preference for =E2=80= =9CHTTPS >>> only=E2=80=9D, but some a fair bit of insistence for allowing HTTP. I = changed the >>> wording in 5.2 to try to capture opinions. Previously, the text led wi= th a >>> requirement to try HTTPS first. That is still there. I just added som= e >>> extra conditions that make it clearer that there are some instances whe= re a >>> client must not utilize HTTP. This might need further refinement, but = I >>> think there is a balance we can strike here between the two camps witho= ut >>> introducing a lot of complex language.**** >>> >>> **** >>> >>> I made some editorial changes through the document.**** >>> >>> **** >>> >>> Comments are welcome, as always. Seems I don=E2=80=99t need to say tha= t to this >>> group, though :-)**** >>> >>> **** >>> >>> Paul**** >>> >>> **** >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss**** >>> >>> ** ** >>> >> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --90e6ba6138a207cd2804cfec5aa1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1 ... I believe the utility of the ac= ct scheme when used with WF is readily apparent, and honestly there's n= o reason to "wait" for acct to be finished. If we complete work o= n WF before acct is done, the only real impact is that we wait a bit longer= for WF to get an RFC#. Implementors can still get started doing their thin= g.

(I do agree that WF is useful with non acct uri'= s too tho)

- James


On Sun, Dec 2, 2012 at= 5:14 PM, Tim Bray <tbray@textuality.com> wrote:
I don=E2=80=99t want to wait for work on thi= s to be completed, and I don=E2=80=99t think that its presence is necessary= for WebFinger to be useful.=C2=A0 So let's take it out.

Proposal:
Section 4.1: Change the URI in the example from acct: to m= ailto:
Section 4.2: Same
Section 5.3: Same
Section 5.4: s/it could be an &qu= ot;acct" URI [7], //
Section 5.4: Remove 2nd para, beginning "= For resources associated with a user account at a host...=E2=80=9C
Secti= on 5.4: s/both an "acct" URI and any alias/any alias/
Section 8: Change the URI in the example from acct: to mailto:


<= div class=3D"gmail_quote">On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray <tbr= ay@textuality.com> wrote:
No, we=E2=80=99re on the same side here. I= =E2=80=99m suggesting taking webfinger-07 as a baseline, and all *future* c= hanges need to be proposed as a concrete delta against it.=C2=A0 -T


On Sun, Dec 2, 2012 at 12:59 PM, Pa= ul E. Jones <paulej@packetizer.com> wrote:

Tim,

=C2=A0

I didn=E2=80=99t me= an to be rude by introducing these changes, just trying to move things alon= g.=C2=A0 Most changes were fairly trivial, not worth mentioning, and can be= seen here:

http://tools.ietf.org/rfcdiff?difftype=3D--hwdif= f&url2=3Ddraft-ietf-appsawg-webfinger-07.txt

=C2=A0

The most significan= t changes were the re-write of section 5.2 and modification to the language= related to HTTPS in 5.1.=C2=A0 I suspect that is the text to which you ref= er as preferring it to be =E2=80=9Ccamera-ready=E2=80=9D.=C2=A0 (I would as= sume the balance of the changes would not need to be presented as =E2=80=9C= camera-ready=E2=80=9D, since they=E2=80=99re minor editorial things.)

=C2=A0

In any case, the mo= st important text changes I would like folks to consider is section 5.2 (wh= ich aims to fully document the JSON Resource Descriptor object) and paragra= phs 2 and 3 in section 5.1.

=C2=A0

Paul<= /span>

=C2=A0

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. Jones<= br>Cc: ap= ps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07

=C2=A0<= u>

Thanks to P= aul for the extra effort.=C2=A0 I=E2=80=99d like to suggest, in the interes= ts of courtesy and efficiency, that from here on on, contributions to this = discussion be =E2=80=9Ccamera-ready=E2=80=9D, that is to say, specific sugg= estions in the style of a diff, including fully-written-out replacements la= nguage.

=C2=A0-Tim

On Sun, Dec 2, = 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

<= div>

Folks,

=C2= =A0

I published another version of = the WebFinger spec trying to bring closure to the two open issues I see (re= source representation and transport).=C2=A0 The new version is here:=

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=C2=A0<= /u>

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=C2=A0 There are no= external references to RFC 6415 now, no need to go read the XRD spec, etc.= =C2=A0It=E2=80=99s a fairly simple format and I believe this text document= s it sufficiently.=C2=A0 Combined with the visual examples, I think this ma= kes it pretty clear.=C2=A0 Have a look at the JRD documentation in section = 5.2 and provide your comments.

=C2=A0

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS on= ly=E2=80=9D, but some a fair bit of insistence for allowing HTTP.=C2=A0 I c= hanged the wording in 5.2 to try to capture opinions.=C2=A0 Previously, the= text led with a requirement to try HTTPS first.=C2=A0 That is still there.= =C2=A0 I just added some extra conditions that make it clearer that there a= re some instances where a client must not utilize HTTP.=C2=A0 This might ne= ed further refinement, but I think there is a balance we can strike here be= tween the two camps without introducing a lot of complex language.

=C2=A0

I mad= e some editorial changes through the document.

=C2=A0

Comments are wel= come, as always.=C2=A0 Seems I don=E2=80=99t need to say that to this group= , though :-)

=C2=A0

Paul

=C2=A0=


_____= __________________________________________
apps-discuss mailing list
= apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=C2=A0

<= /div>



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--90e6ba6138a207cd2804cfec5aa1-- From jasnell@gmail.com Sun Dec 2 21:55:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AB021F89D7 for ; Sun, 2 Dec 2012 21:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvlCX+Cgt+di for ; Sun, 2 Dec 2012 21:55:39 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E358921F89BE for ; Sun, 2 Dec 2012 21:55:38 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so3837941ieb.31 for ; Sun, 02 Dec 2012 21:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hXrDrjk7SagTvcizud2gQa2fYlgSg9xbaLxsLIFTroo=; b=RPcCJtYsX0aep+ymYRRKBkWP4g4ziuwiBBgd3sWkxZjORAJQEhjkGcFmPCLndSCjCw gxux6CKR1d/ByB7MfhpTXRKQWUkNXUrVmxUg05CWz86GjG4OEDMHGITOb7w+4huvDODk NN6V8qWIzpFITeskEEoel7CgFGuzZlLH0qeyGjeP1utny0eqlqbZ1z+JE/0EX0KVlNqd x5Fm7BOf4yIws7rF8pUKRvNSK6HYxU5OK4zRolh+91eZik3VeWC0XkZKOsWlDg866Ff7 kdAC6iwqkj2fDNvjRTOOusiZCm3Y/H6W4T+tZjN0Wm8QKSQBs+3EqoPRlnhhv6yvoVeP Pn1w== Received: by 10.50.160.165 with SMTP id xl5mr5380289igb.54.1354514138588; Sun, 02 Dec 2012 21:55:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.41.229 with HTTP; Sun, 2 Dec 2012 21:55:18 -0800 (PST) In-Reply-To: References: From: James M Snell Date: Sun, 2 Dec 2012 21:55:18 -0800 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=14dae9340efd12e78d04cfec66c4 Cc: "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:55:40 -0000 --14dae9340efd12e78d04cfec66c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I -1'd the specific change because I don't believe it's good enough. Honestly, I'd be happy to get rid of the subject property entirely, as I do not believe it's going to be all that useful. The subject of the JRD should be the effective request URI. Period. Anything other than that adds unhelpful and unnecessary complexity. If, however, we keep subject in, then clear equivalent rules should be spelled out or referenced. We can't just say "equivalent" and hope for the best. - James On Sun, Dec 2, 2012 at 9:49 PM, Tim Bray wrote: > Sounds to me like you=E2=80=99re arguing my side of it. The current lang= uage > suggests that you should turf the JRD if they=E2=80=99re not =E2=80=9Cthe= same value=E2=80=9D that > you put in your query. There are lots of reasons why they might not be > byte-for-byte or even character-for-character identical, and still be > equivalent for all practical purposes. -T > > > On Sun, Dec 2, 2012 at 9:42 PM, James M Snell wrote: > >> -1 ... fixing this would be good but your proposed text isn't quite >> enough without either defining or specifically referencing what >> "equivalence" means. For example, as currently defined, the resource >> parameter can be a relative URI reference, while the subject could be an >> absolute URI reference. How does one determine equivalence exactly? >> >> - James >> >> >> On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: >> >>> Right now, section 5.2.2 says "The value of the "subject" member is a >>> string that MUST be set to the same value as the "resource" parameter i= n >>> the client request. " >>> >>> This is a recipe for trouble, for a couple of reasons. First of all, >>> what does =E2=80=9Cthe same value=E2=80=9D mean? Go visit RFC3986, sec= tion 6, and enjoy >>> several hundred words walking through all the issues that arise in tryi= ng >>> to figure out when two URIs are equivalent, ranging from exact >>> character-by-character identity to all sorts of protocol-specific goo. = You >>> are just one level of case-sensitivity-in-%-escaping from a big hairy f= alse >>> negative. >>> >>> I=E2=80=99m also worried about a lack of flexibility. I might have a si= ngle >>> webfinger resource that declares a bunch of link relations for a bunch = of >>> different resources. This section, as written, wouldn=E2=80=99t let me = do that. >>> >>> Proposal: Re-write section 5.2.2 as follows: >>> >>> <<<<<<< >>> The value of the "subject" member is a string whose value is advisory, >>> identifying the resource to which the properties given in the "links" >>> member apply. Normally this would be expected to be equivalent to the >>> value of the "resource" parameter in the client request. >>> <<<<<<< >>> >>> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones w= rote: >>> >>>> Folks,**** >>>> >>>> ** ** >>>> >>>> I published another version of the WebFinger spec trying to bring >>>> closure to the two open issues I see (resource representation and >>>> transport). The new version is here:**** >>>> >>>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >>>> >>>> ** ** >>>> >>>> With respect to resource representation, I fully described the JSON >>>> Resource Descriptor within the document. There are no external refere= nces >>>> to RFC 6415 now, no need to go read the XRD spec, etc. It=E2=80=99s a= fairly >>>> simple format and I believe this text documents it sufficiently. Comb= ined >>>> with the visual examples, I think this makes it pretty clear. Have a = look >>>> at the JRD documentation in section 5.2 and provide your comments. ***= * >>>> >>>> ** ** >>>> >>>> With respect to HTTPS, it seems there is strong preference for =E2=80= =9CHTTPS >>>> only=E2=80=9D, but some a fair bit of insistence for allowing HTTP. I= changed the >>>> wording in 5.2 to try to capture opinions. Previously, the text led w= ith a >>>> requirement to try HTTPS first. That is still there. I just added so= me >>>> extra conditions that make it clearer that there are some instances wh= ere a >>>> client must not utilize HTTP. This might need further refinement, but= I >>>> think there is a balance we can strike here between the two camps with= out >>>> introducing a lot of complex language.**** >>>> >>>> ** ** >>>> >>>> I made some editorial changes through the document.**** >>>> >>>> ** ** >>>> >>>> Comments are welcome, as always. Seems I don=E2=80=99t need to say th= at to >>>> this group, though :-)**** >>>> >>>> ** ** >>>> >>>> Paul**** >>>> >>>> ** ** >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> >>>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >> > --14dae9340efd12e78d04cfec66c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I -1'd the specific change be= cause I don't believe it's good enough. Honestly, I'd be happy = to get rid of the subject property entirely, as I do not believe it's g= oing to be all that useful. The subject of the JRD should be the effective = request URI. Period. Anything other than that adds unhelpful and unnecessar= y complexity. If, however, we keep subject in, then clear equivalent rules = should be spelled out or referenced. We can't just say "equivalent= " and hope for the best.

- James

On Sun, Dec 2, 2012 at 9:49 PM, Tim Bray <= tbray@textuality.com> wrote:
Sounds to me like you=E2=80=99re arguing my = side of it.=C2=A0 The current language suggests that you should turf the JR= D if they=E2=80=99re not =E2=80=9Cthe same value=E2=80=9D that you put in y= our query. There are lots of reasons why they might not be byte-for-byte or= even character-for-character identical, and still be equivalent for all pr= actical purposes.=C2=A0 -T


On Sun, Dec 2, 2012 at 9:42 PM, James M Snel= l <jasnell@gmail.com> wrote:
-1 ... fixing this would be good but y= our proposed text isn't quite enough without either defining or specifi= cally referencing what "equivalence" means. For example, as curre= ntly defined, the resource parameter can be a relative URI reference, while= the subject could be an absolute URI reference. How does one determine equ= ivalence exactly?=C2=A0

- James


On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray= <tbray@textuality.com> wrote:
Right now, section 5.2.2 says "The valu= e of the "subject" member is a string that MUST be set to the sam= e value as the "resource" parameter in the client request. "=

This is a recipe for trouble, for a couple of reasons. First of all, wh= at does =E2=80=9Cthe same value=E2=80=9D mean?=C2=A0 Go visit RFC3986, sect= ion 6, and enjoy several hundred words walking through all the issues that = arise in trying to figure out when two URIs are equivalent, ranging from ex= act character-by-character identity to all sorts of protocol-specific goo. = You are just one level of case-sensitivity-in-%-escaping from a big hairy f= alse negative.

I=E2=80=99m also worried about a lack of flexibility. I might have a si= ngle webfinger resource that declares a bunch of link relations for a bunch= of different resources. This section, as written, wouldn=E2=80=99t let me = do that.

Proposal: Re-write section 5.2.2 as follows:

<<<<<= ;<<
The value of the "subject" member is a string whose = value is advisory, identifying the resource to which the properties given i= n the "links" member apply.=C2=A0 Normally this would be expected= to be equivalent to the value of the "resource" parameter in the= client request.
<<<<<<<

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=C2=A0

I published another version of the WebFinger spec tr= ying to bring closure to the two open issues I see (resource representation= and transport).=C2=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

=C2=A0

With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=C2=A0 There are no external references to= RFC 6415 now, no need to go read the XRD spec, etc. =C2=A0It=E2=80=99s a f= airly simple format and I believe this text documents it sufficiently.=C2= =A0 Combined with the visual examples, I think this makes it pretty clear.= =C2=A0 Have a look at the JRD documentation in section 5.2 and provide your= comments.

=C2=A0

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS on= ly=E2=80=9D, but some a fair bit of insistence for allowing HTTP.=C2=A0 I c= hanged the wording in 5.2 to try to capture opinions.=C2=A0 Previously, the= text led with a requirement to try HTTPS first.=C2=A0 That is still there.= =C2=A0 I just added some extra conditions that make it clearer that there a= re some instances where a client must not utilize HTTP.=C2=A0 This might ne= ed further refinement, but I think there is a balance we can strike here be= tween the two camps without introducing a lot of complex language.

=C2=A0

I mad= e some editorial changes through the document.

=C2=A0

Comments are wel= come, as always.=C2=A0 Seems I don=E2=80=99t need to say that to this group= , though :-)

=C2=A0

Paul

=C2=A0


__________________________= _____________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss




--14dae9340efd12e78d04cfec66c4-- From James.H.Manger@team.telstra.com Sun Dec 2 22:08:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BB821F8484 for ; Sun, 2 Dec 2012 22:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTKHr9ebvoxy for ; Sun, 2 Dec 2012 22:07:59 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4A34E21F858B for ; Sun, 2 Dec 2012 22:07:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,361,1352034000"; d="scan'208";a="106348550" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 03 Dec 2012 17:07:45 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="101407409" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccvi.tcif.telstra.com.au with ESMTP; 03 Dec 2012 17:07:46 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Mon, 3 Dec 2012 17:07:44 +1100 From: "Manger, James H" To: Mark Nottingham Date: Mon, 3 Dec 2012 17:07:43 +1100 Thread-Topic: [apps-discuss] JSON Patch implementation feedback Thread-Index: Ac3RFYGleughSS6CS0Cf4Iaq+EytFwAAPDjg Message-ID: <255B9BB34FB7D647A506DC292726F6E115028CDD7E@WSMSG3153V.srv.dir.telstra.com> References: <50BB20B3.8010403@skoegl.net> <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CD4FD@WSMSG3153V.srv.dir.telstra.com> <05CB04C6-A7CD-4C56-8050-45EF788DD5E0@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CDBC3@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 06:08:01 -0000 PiA+IFNvIHRvIHVzZSAiYWRkIiB0aGUgYXV0aG9yIGRvZXNuJ3QgbmVlZCB0byBoYXZlICJ0aGUg c3RhdGUgb2YgdGhlDQo+IGRvY3VtZW50IGluIG1pbmQiLCBidXQgdG8gdXNlICJyZW1vdmUiIG9y ICJyZXBsYWNlIiB0aGUgYXV0aG9yIGRvZXMuDQo+IFRoYXQgaXMgcGFpbmZ1bGx5IGluY29uc2lz dGVudC4gUGx1cyB0aGUgcHJvdGVjdGlvbiBmb3IgdGhlIGF1dGhvciBpcw0KPiBzbyB3ZWFrOiB0 aGUgdmFsdWUgdGhhdCBhICJyZW1vdmUiIG9wIGRlbGV0ZXMgY291bGQgaGF2ZSBiZWVuIHVwZGF0 ZWQNCj4gdG8gc29tZXRoaW5nIGNvbXBsZXRlbHkgZGlmZmVyZW50IGZyb20gdGhlIHZhbHVlIHRo ZSBwYXRjaCBhdXRob3INCj4gdGhpbmtzIGl0IGlzLCBidXQgaXQgd2lsbCBiZSByZW1vdmVkIGFu eXdheS4NCj4gPg0KPiA+IEFueSBtaW5vciBiZW5lZml0IG9mIGNhdGNoaW5nIHNvbWUgInR5cG9z IiBpbiBwYXRjaCBkb2NzIGluIGFuIGFkIGhvYw0KPiBtYW5uZXIgaXMgb3V0d2VpZ2hlZCBieSBs b3NpbmcgZnVuY3Rpb25hbGl0eSAoZWcgYSBwYXRjaCB0byByZW1vdmUgYQ0KPiBmaWVsZCB0aGF0 IHdvcmtzIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgZmllbGQgaXMgcHJlc2VudCksIGFuZCB0 aGUNCj4gdGVtcHRhdGlvbiBpdCBnaXZlcyB0byBza2ltcCBvbiBwcm9wZXIgY2hlY2tzIChlZyB3 aXRoIGEgInRlc3QiIG9wLCBlLQ0KPiB0YWdzLCBvciBsb2NrcykuDQo+IA0KPiAqc2hydWcqIEkn bSBub3QgdG9vIGNvbmNlcm5lZCBhYm91dCBjb25zaXN0ZW5jeSBmb3IgaXRzIG93biBzYWtlLg0K PiBQZW9wbGUgaGFkIGNvbXBlbGxpbmcgdXNlIGNhc2VzIGZvciAnYWRkJywgd2hlcmVhcyB0aGV5 IGZlbHQgdGhhdCBpZg0KPiB5b3UgJ3JlbW92ZScgc29tZXRoaW5nLCBhbmQgaXQgaXNuJ3QgdGhl cmUsIHlvdSdkIHdhbnQgdGhlIHBhdGNoIHRvDQo+IGZhaWwuDQoNCkkgbmVlZCBhIGNvbXBlbGxp bmcgdXNlIGNhc2UgdGhlbjogd2lsbCBjdXRlIGRvPw0KQSBKU09OIG9iamVjdCByZXByZXNlbnRz IHNvbWUgc3lzdGVtIHN0YXRlLiBJZiBpdCBjb250YWlucyAiZGVidWciOjxsZXZlbD4geW91IGdl dCBsb3RzIG9mIGxvZ3MuIFR3byAxLWxpbmUgY3VybCBjb21tYW5kcyBjYW4gdG9nZ2xlIHRoZSBz dGF0ZS4gVGhlIGZpcnN0IHNlbmRzIHRoZSBwYXRjaCB7Im9wIjoiYWRkIiwgInBhdGgiOiIvZGVi dWciLCAidmFsdWUiOjJ9IHRvIHR1cm5zIG9uIGRlYnVnZ2luZzsgaXQgYWx3YXlzIHdvcmtzOyBp dCBpcyBpZGVtcG90ZW50LiBUaGUgc2Vjb25kIHNlbmRzIHRoZSBwYXRjaCB7Im9wIjoicmVtb3Zl IiwgInBhdGgiOiIvZGVidWcifS4gSWRlYWxseSBpdCB3b3VsZCBhbHNvIGFsd2F5cyB3b3JrOyBp dCB3b3VsZCBiZSBpZGVtcG90ZW50LiBIb3dldmVyLCBjdXJyZW50bHkgaXQgY2FuIGZhaWw6IHBl cmhhcHMgYmVjYXVzZSBkZWJ1Z2dpbmcgd2FzIGFscmVhZHkgb2ZmLCBvciBwZXJoYXBzIGJlY2F1 c2UgdGhlcmUgd2FzIHNvbWUgb3RoZXIgcHJvYmxlbS4gQW5ub3lpbmcuDQoNCg0KPiBJJ20gbm90 IG1hcnJpZWQgdG8gYW55IHBhcnRpY3VsYXIgYXBwcm9hY2ggaGVyZSwgYXMgbG9uZyBhcyBhKSBp dCBtYWtlcw0KPiBzZW5zZSBmb3IgaW1wbGVtZW50ZXJzIGFuZCBlbmQgdXNlcnMsIGFuZCBiKSB3 ZSBjYW4gZ2V0IHRvIGEgZGVjaXNpb24NCj4gcXVpY2tseSAoYXMgb3Bwb3NlZCB0byB0aGUgRHVl bGluZyBBcmNoaXRlY3RzIFNob3cgdGhhdCB0aGUgSUVURiBzZWVtcw0KPiB0byBsZWFuIHRvd2Fy ZHMgdGhlc2UgZGF5cy4uLiopLg0KPiANCj4gVG8gYmUgY2xlYXIgLS0gSSB0aGluayB0aGUgcHJv cG9zYWwgeW91J3JlIG1ha2luZyBpcw0KPiBhKSB0byBtYWtlICdyZW1vdmUnIG5vdCBmYWlsIGlm IHRoZSB0YXJnZXQgaXNuJ3QgdGhlcmUsDQoNClllcw0KDQo+IGFuZCBiKSB0byB0YWtlICdyZXBs YWNlJyBvdXQgb2YgdGhlIHNwZWNpZmljYXRpb24NCg0KTm8uIFlvdSBzdGlsbCBuZWVkIHRvIGRp c3Rpbmd1aXNoIHJlcGxhY2luZyB0aGUgdmFsdWUgYXQgYSBnaXZlbiBhcnJheSBpbmRleCwgYW5k IGluc2VydGluZyBhIG5ldyB2YWx1ZSBiZWZvcmUgYSBnaXZlbiBhcnJheSBpbmRleC4gInJlcGxh Y2UiIGNhbiBiZSBkZWZpbmVkIGFzICJyZW1vdmUiIHRoZW4gImFkZCIuDQoNCkkgd291bGQgYWxz byBnbyBhIHN0ZXAgZnVydGhlciBzbyAiYWRkIiBhbHdheXMgd29ya3MgLS0gY3JlYXRpbmcgYW55 IHBhcmVudCBvYmplY3RzIHRoYXQgYXJlIG5lZWRlZCAobGlrZSAibWtkaXIgLS1wYXJlbnRzIiku DQoNCj4gQWRkaXRpb25hbGx5LCBpZiB3ZSBnbyBkb3duIHRoaXMgcm9hZCwgd2UnbGwgaGF2ZSB0 byBkZWNpZGUgd2hhdCB0byBkbw0KPiBhYm91dCBzaW1pbGFyIGZhaWx1cmVzIGluICdjb3B5JyBh bmQgJ21vdmUnIC0tIGRvIHlvdSBSRUFMTFkgd2FudA0KPiBmYWlsdXJlIHRvIGZpbmQgdGhlIHRh cmdldCB0byBiZSBzaWxlbnRseSBkaWdlc3RlZD8gKCE/KQ0KDQpNYXkgYXMgd2VsbC4gVHJpZ2dl cmluZyBlcnJvcnMgaXNuJ3QgdXNlZnVsLiBNb3ZlL2NvcHkgYWN0aW5nIGxpa2UgInJlbW92ZSIg d2hlbiB0aGVyZSBpcyBubyB2YWx1ZSBhdCAiZnJvbSIgY2FuJ3QgYmUgbGVzcyB1c2VmdWwgdGhh biBhbiBlcnJvci4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From pbryan@anode.ca Sun Dec 2 22:13:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E519021F898C for ; Sun, 2 Dec 2012 22:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UA8Gy1UJD6eE for ; Sun, 2 Dec 2012 22:13:38 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id F1DED21F898B for ; Sun, 2 Dec 2012 22:13:31 -0800 (PST) Received: from [192.168.1.4] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id D2D56641E; Mon, 3 Dec 2012 06:13:30 +0000 (UTC) Message-ID: <1354515209.2975.9.camel@polyglot> From: "Paul C. Bryan" To: Mark Nottingham Date: Sun, 02 Dec 2012 22:13:29 -0800 In-Reply-To: References: <50BB20B3.8010403@skoegl.net> <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CD4FD@WSMSG3153V.srv.dir.telstra.com> <05CB04C6-A7CD-4C56-8050-45EF788DD5E0@mnot.net> <255B9BB34FB7D647A506DC292726F6E115028CDBC3@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="=-UZlpaKsz+DyOj/gdI0M2" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 06:13:40 -0000 --=-UZlpaKsz+DyOj/gdI0M2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2012-12-03 at 16:17 +1100, Mark Nottingham wrote: > On 03/12/2012, at 4:01 PM, "Manger, James H" > wrote: > > >> wrote: > >>> > >>> It is extensible. > >>> To define new functionality that must not be ignored you can > define a > >> new operation. > >>> To define new functionality that can be safely ignored by old > >> implementations you can define new members for existing operations. > >>> > >>> For instance, to define a test of the type of a JSON value you > could > >> define a new operations: > >>> { "op":"test2", "path":"/a/b/c", "type":[] } -- true iff the > value > >>> at the given path is an array > > > >> That's not a backwards-compatible extension; it fundamentally > changes > >> the semantics of the document, and an implementation that ignores > it > >> may PATCH when it shouldn't. > > > > "op":"test2" is not meant to be backward-compatible. It is not meant > to be ignored and it will not be ignored. All code will switch on the > "op" value. [In sharp contrast to unexpected extra name/value pairs > which most code will ignore so the spec sensibly codifies that > must-ignore behaviour.] > > Introducing a new operation that is safe-to-ignore for processors that > don't understand it is theoretically possible, but practically what > will they do? > > In the cast of your theoretical test2 -- if the patcher doesn't > perform the test, and it would have failed, now we have two different > behaviours, based upon whether they implement test2; not a good thing > in a patch format. I agree. I can't presently imagine an operation that could be safe to ignore. If a new RFC obseletes ours, it can establish a new media type or some other convention to distinguish itself from the the format we're currently specifying. > > It is an error if the value is not recognized. New operations can > >>> be defined by RFCs that update this document. > >>> -- > >> > >> We explicitly agreed to the text before -- i.e., that the set of > >> operations defined by this format is closed. > > > > So if another spec like draft-snell-json-test (section 2.5 "Using > JSON Prediciate within JSON Patch Documents) defines some operations > it can re-use the json-patch syntax with some new "op" values -- but > it also needs to define a new media type? Oh well > > Ask discussed, yes -- and James is AFAIK OK with and behind that > approach. Agree. > >>> [I still think we should ditch the statements that "The target > >>> location MUST exist for the operation to be successful". Better to > >>> define a sensible "successful" result (eg "remove" is a no-op if > >>> "from" does not exist; "move" is equivalent to "remove" on the > "from" > >>> and "to" locations then, if there was a value at "from", an "add" > >>> operation; "replace" is equivalent to "remove" then "add" > >>> operations).] > >> > >> > >> The point of this statement in the "remove" and "replace" > operations is > >> that if the target isn't there, the patch is probably not written > with > >> the state of the document in mind, and should fail. Contrast with > "add" > >> (where the intent was to allow authors to add-or-update). > > > > So to use "add" the author doesn't need to have "the state of the > document in mind", but to use "remove" or "replace" the author does. > That is painfully inconsistent. Plus the protection for the author is > so weak: the value that a "remove" op deletes could have been updated > to something completely different from the value the patch author > thinks it is, but it will be removed anyway. > > > > Any minor benefit of catching some "typos" in patch docs in an ad > hoc manner is outweighed by losing functionality (eg a patch to remove > a field that works regardless of whether the field is present), and > the temptation it gives to skimp on proper checks (eg with a "test" > op, e-tags, or locks). > > *shrug* I'm not too concerned about consistency for its own sake. > People had compelling use cases for 'add', whereas they felt that if > you 'remove' something, and it isn't there, you'd want the patch to > fail. > > I'm not married to any particular approach here, as long as a) it > makes sense for implementers and end users, and b) we can get to a > decision quickly (as opposed to the Dueling Architects Show that the > IETF seems to lean towards these days...*). > > To be clear -- I think the proposal you're making is a) to make > 'remove' not fail if the target isn't there, and b) to take 'replace' > out of the specification (since the only difference in its semantics > from 'add' is the ability to fail if the thing you want to set isn't > there). > > Additionally, if we go down this road, we'll have to decide what to do > about similar failures in 'copy' and 'move' -- do you REALLY want > failure to find the target to be silently digested? (!?) > > What do other folks think? Unless we want to run the gauntlet and further enhance the test operation as well, I'm not in favour of making failure of these operations silent. > >> For "move" and "copy" it also seems like a good idea, because if > you > >> run a patch and the source of one of these operations isn't > existent, > >> you definitely don't know what state the document is in, and the > patch > >> should fail. > > > > And if the patch succeeds you might have known the doc state or you > might not. That's better? > > > By the nature of HTTP, you can't know the state of the resource until > you GET it (and even then, it's ephemeral). > > However, if you write a patch that says "move x to y" and there isn't > an x in the doc, it seems like a pretty sure think that you're > patching something sensibly. YMMV. > > > > * N.B. My job title includes the word "Architect." > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss Paul --=-UZlpaKsz+DyOj/gdI0M2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 2012-12-03 at 16:17 +1100, Mark Nottingham wrote:
On 03/12/2012, at 4:01 PM, "Manger, James H" <James.H.Manger@team.telstra.com> wrote:

>> <James.H.Manger@team.telstra.com> wrote:
>>>
>>> It is extensible.
>>> To define new functionality that must not be ignored you can define a
>> new operation.
>>> To define new functionality that can be safely ignored by old
>> implementations you can define new members for existing operations.
>>>
>>> For instance, to define a test of the type of a JSON value you could
>> define a new operations:
>>> { "op":"test2", "path":"/a/b/c", "type":[] } -- true iff the value
>>> at the given path is an array
>
>> That's not a backwards-compatible extension; it fundamentally changes
>> the semantics of the document, and an implementation that ignores it
>> may PATCH when it shouldn't.
>
> "op":"test2" is not meant to be backward-compatible. It is not meant to be ignored and it will not be ignored. All code will switch on the "op" value. [In sharp contrast to unexpected extra name/value pairs which most code will ignore so the spec sensibly codifies that must-ignore behaviour.]

Introducing a new operation that is safe-to-ignore for processors that don't understand it is theoretically possible, but practically what will they do?

In the cast of your theoretical test2 -- if the patcher doesn't perform the test, and it would have failed, now we have two different behaviours, based upon whether they implement test2; not a good thing in a patch format.

I agree. I can't presently imagine an operation that could be safe to ignore. If a new RFC obseletes ours, it can establish a new media type or some other convention to distinguish itself from the the format we're currently specifying.   

> It is an error if the value is not recognized. New operations can
>>> be defined by RFCs that update this document.
>>> --
>>
>> We explicitly agreed to the text before -- i.e., that the set of
>> operations defined by this format is closed.
>
> So if another spec like draft-snell-json-test (section 2.5 "Using JSON Prediciate within JSON Patch Documents) defines some operations it can re-use the json-patch syntax with some new "op" values -- but it also needs to define a new media type? Oh well

Ask discussed, yes -- and James is AFAIK OK with and behind that approach.

Agree.

>>> [I still think we should ditch the statements that "The target
>>> location MUST exist for the operation to be successful". Better to
>>> define a sensible "successful" result (eg "remove" is a no-op if
>>> "from" does not exist; "move" is equivalent to "remove" on the "from"
>>> and "to" locations then, if there was a value at "from", an "add"
>>> operation; "replace" is equivalent to "remove" then "add"
>>> operations).]
>>
>>
>> The point of this statement in the "remove" and "replace" operations is
>> that if the target isn't there, the patch is probably not written with
>> the state of the document in mind, and should fail. Contrast with "add"
>> (where the intent was to allow authors to add-or-update).
>
> So to use "add" the author doesn't need to have "the state of the document in mind", but to use "remove" or "replace" the author does. That is painfully inconsistent. Plus the protection for the author is so weak: the value that a "remove" op deletes could have been updated to something completely different from the value the patch author thinks it is, but it will be removed anyway.
>
> Any minor benefit of catching some "typos" in patch docs in an ad hoc manner is outweighed by losing functionality (eg a patch to remove a field that works regardless of whether the field is present), and the temptation it gives to skimp on proper checks (eg with a "test" op, e-tags, or locks).

*shrug* I'm not too concerned about consistency for its own sake. People had compelling use cases for 'add', whereas they felt that if you 'remove' something, and it isn't there, you'd want the patch to fail.

I'm not married to any particular approach here, as long as a) it makes sense for implementers and end users, and b) we can get to a decision quickly (as opposed to the Dueling Architects Show that the IETF seems to lean towards these days...*).

To be clear -- I think the proposal you're making is a) to make 'remove' not fail if the target isn't there, and b) to take 'replace' out of the specification (since the only difference in its semantics from 'add' is the ability to fail if the thing you want to set isn't there).

Additionally, if we go down this road, we'll have to decide what to do about similar failures in 'copy' and 'move' -- do you REALLY want failure to find the target to be silently digested? (!?)

What do other folks think?

Unless we want to run the gauntlet and further enhance the test operation as well, I'm not in favour of making failure of these operations silent.

>> For "move" and "copy" it also seems like a good idea, because if you
>> run a patch and the source of one of these operations isn't existent,
>> you definitely don't know what state the document is in, and the patch
>> should fail.
>
> And if the patch succeeds you might have known the doc state or you might not. That's better?


By the nature of HTTP, you can't know the state of the resource until you GET it (and even then, it's ephemeral).

However, if you write a patch that says "move x to y" and there isn't an x in the doc, it seems like a pretty sure think that you're patching something sensibly. YMMV.



* N.B. My job title includes the word "Architect."

--
Mark Nottingham http://www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Paul --=-UZlpaKsz+DyOj/gdI0M2-- From sm@resistor.net Sun Dec 2 22:30:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BC221F899C for ; Sun, 2 Dec 2012 22:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.643 X-Spam-Level: X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk0A1MPRt538 for ; Sun, 2 Dec 2012 22:30:45 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F87721F8998 for ; Sun, 2 Dec 2012 22:30:44 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qB36UdTA018188; Sun, 2 Dec 2012 22:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1354516243; bh=phHyvY0OtNubUnCg2I2pKDL3lL5A4KsWcOF2PbJSZVs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gBYi44K78Fwx8rE8Z/pORsrbkVNvpyaVOEHyJD2PuvhfH2Nkg/sSgGWkU7JODs+Rz O9ccWqkktBDk5s/oBo7Yancbf0aDMnAkXy1ax+XloHVU/cm2i1Gb1amDNc97W8m36A meg+SpzIsqdLAfjnCOxZDNHtX5FD7Fwern6q+mCg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1354516243; i=@resistor.net; bh=phHyvY0OtNubUnCg2I2pKDL3lL5A4KsWcOF2PbJSZVs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eBkJYOLN9+vu//a7jvkiZCmOIC8PrLVMzvCfi+2HGrE8i8o/61veb4JZ6nOkJ91R0 yo99l37ZaSDHDfmvH2bbg1DTHbY9/OfFOAmGLYey6/qbcuKn0IFhyZdqymqncaFGsc Yu9oDGNwQZEias4SwYm4kMXmYHtxo7+iav2PCDoU= Message-Id: <6.2.5.6.2.20121202222641.0ad33b50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 02 Dec 2012 22:29:07 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> <07e601cdd0cf$dfb4d3f0$9f1e7bd0$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 06:30:46 -0000 At 13:57 02-12-2012, Tim Bray wrote: >No, we're on the same side here. I'm suggesting taking webfinger-07 >as a baseline, and all *future* changes need to be proposed as a >concrete delta against it. -T That's my preference too. Regards, -sm From Michael.Jones@microsoft.com Sun Dec 2 22:54:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D3E21F8A5E for ; Sun, 2 Dec 2012 22:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.182 X-Spam-Level: X-Spam-Status: No, score=-5.182 tagged_above=-999 required=5 tests=[AWL=1.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 473DsbXdw5Rn for ; Sun, 2 Dec 2012 22:54:44 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id C352E21F8200 for ; Sun, 2 Dec 2012 22:54:43 -0800 (PST) Received: from mail133-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Mon, 3 Dec 2012 06:54:43 +0000 Received: from mail133-tx2 (localhost [127.0.0.1]) by mail133-tx2-R.bigfish.com (Postfix) with ESMTP id 344563401CB; Mon, 3 Dec 2012 06:54:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz98dI9371Id6eah936eIc85fhzz1de0h1202h1d1ah1d2ahzz18de19h1033IL17326ah8275bh8275dh18c673hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail133-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail133-tx2 (localhost.localdomain [127.0.0.1]) by mail133-tx2 (MessageSwitch) id 135451768152436_28777; Mon, 3 Dec 2012 06:54:41 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.246]) by mail133-tx2.bigfish.com (Postfix) with ESMTP id 085564E0043; Mon, 3 Dec 2012 06:54:41 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 3 Dec 2012 06:54:40 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Mon, 3 Dec 2012 06:54:39 +0000 From: Mike Jones To: John Bradley , "webfinger@googlegroups.com" Thread-Topic: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme Thread-Index: AQHN0PjEclp0/dlb30mtVQAvbu/iPpgGoh4A Date: Mon, 3 Dec 2012 06:54:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436690FAD2@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> In-Reply-To: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436690FAD2TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 06:54:48 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436690FAD2TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In reply to Tim's suggestion to ditch the dependency upon acct: - this seem= s like a "premature optimization". It looks likely that both WebFinger and= the acct: URI drafts will be ready to go to working group last call at the= same time, and that in fact, they are likely to proceed to RFC status at t= he same time. I don't see any schedule reason to remove the dependency at = this time. (And I think there are technical reasons not to do so, e.g. acc= t:selfissued@twitter.com.) In reply to the opposing suggestion that WebFinger be only useful for acct:= URIs and not others, among other consequences, this would mean that OpenID= Connect would not be able to use WebFinger, as it has to do resolution on = several kinds of URIs, some of which don't use e-mail syntax. (See http://= openid.bitbucket.org/openid-connect-discovery-1_0.html#anchor5, http://ope= nid.bitbucket.org/openid-connect-discovery-1_0.html#anchor8 and http://open= id.bitbucket.org/openid-connect-discovery-1_0.html#host.port.example.) So while on the same thread people are advocating not using acct: and only = using acct:, I believe the most flexible and best path is to allow the use = of acct: - but also other URIs - exactly where we are today. -- Mike From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of John Bradley Sent: Sunday, December 02, 2012 5:52 PM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:= " scheme I agree that WF is not just about email. A question ( perhaps channeling Blane) is if it should only be about acct: = for simplicity. As an example should we be expecting it to resolve xmpp: tel: or other th= ings. For http: and https: scheme URI perhaps link headers pointing to a acct: re= lation are the most appropriate. WF is about having a identifier in User Principal name (UPN) form where th= e principal is a domain and finding the JRD document or documents for that = account. There is a bunch of hedging that it can work with any URI but that may just= be confusing the issue. My personal preference t this point (others working on openID Connect may w= ell disagree) is to go all in on acct: and just admit that WF is the resolu= tion process for those URI. That is what most people think of it as anyway. John B. On 2012-12-02, at 10:35 PM, Brad Fitzpatrick > wrote: -1. I feel strongly for keeping the acct: scheme. WebFinger isn't just ab= out email. On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray > wrote: I don't want to wait for work on this to be completed, and I don't think th= at its presence is necessary for WebFinger to be useful. So let's take it = out. Proposal: Section 4.1: Change the URI in the example from acct: to mailto: Section 4.2: Same Section 5.3: Same Section 5.4: s/it could be an "acct" URI [7], // Section 5.4: Remove 2nd para, beginning "For resources associated with a us= er account at a host..." Section 5.4: s/both an "acct" URI and any alias/any alias/ Section 8: Change the URI in the example from acct: to mailto: On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray > wrote: No, we're on the same side here. I'm suggesting taking webfinger-07 as a ba= seline, and all *future* changes need to be proposed as a concrete delta ag= ainst it. -T On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones > wrote: Tim, I didn't mean to be rude by introducing these changes, just trying to move = things along. Most changes were fairly trivial, not worth mentioning, and = can be seen here: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-appsawg= -webfinger-07.txt The most significant changes were the re-write of section 5.2 and modificat= ion to the language related to HTTPS in 5.1. I suspect that is the text to= which you refer as preferring it to be "camera-ready". (I would assume th= e balance of the changes would not need to be presented as "camera-ready", = since they're minor editorial things.) In any case, the most important text changes I would like folks to consider= is section 5.2 (which aims to fully document the JSON Resource Descriptor = object) and paragraphs 2 and 3 in section 5.1. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, December 02, 2012 2:54 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegr= oups.com Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 Thanks to Paul for the extra effort. I'd like to suggest, in the interests= of courtesy and efficiency, that from here on on, contributions to this di= scussion be "camera-ready", that is to say, specific suggestions in the sty= le of a diff, including fully-written-out replacements language. -Tim On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones > wrote: Folks, I published another version of the WebFinger spec trying to bring closure t= o the two open issues I see (resource representation and transport). The n= ew version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document. There are no external references to RFC = 6415 now, no need to go read the XRD spec, etc. It's a fairly simple forma= t and I believe this text documents it sufficiently. Combined with the vis= ual examples, I think this makes it pretty clear. Have a look at the JRD d= ocumentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only"= , but some a fair bit of insistence for allowing HTTP. I changed the wordi= ng in 5.2 to try to capture opinions. Previously, the text led with a requ= irement to try HTTPS first. That is still there. I just added some extra = conditions that make it clearer that there are some instances where a clien= t must not utilize HTTP. This might need further refinement, but I think t= here is a balance we can strike here between the two camps without introduc= ing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this gr= oup, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_4E1F6AAD24975D4BA5B16804296739436690FAD2TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In reply to Tim’s s= uggestion to ditch the dependency upon acct: - this seems like a “pre= mature optimization”.  It looks likely that both WebFinger and t= he acct: URI drafts will be ready to go to working group last call at the same time= , and that in fact, they are likely to proceed to RFC status at the same ti= me.  I don’t see any schedule reason to remove the dependency at= this time.  (And I think there are technical reasons not to do so, e.g. acct:selfissued@twitter.com.)=

 <= /p>

In reply to the opposing = suggestion that WebFinger be only useful for acct: URIs and not others, amo= ng other consequences, this would mean that OpenID Connect would not be able to use WebFinger, as it has to do resolution on several = kinds of URIs, some of which don’t use e-mail syntax.  (See http://openid.bitbucket.org/openid-connect-discovery-1_0.html#anchor= 5,  http://openid.bitbucket.org/openid-connect-discovery-1_= 0.html#anchor8 and http://openid.bitbucket.org/openid-connect-discovery-1_0.html#host.port.exa= mple.)

 <= /p>

So while on the same thre= ad people are advocating not using acct: and only using acct:, I believe th= e most flexible and best path is to allow the use of acct: - but also other URIs – exactly where we are today.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley
Sent: Sunday, December 02, 2012 5:52 PM
To: webfinger@googlegroups.com
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on= "acct:" scheme

 

I agree that WF is not just about email.<= /p>

 

A question ( perhaps channeling Blane) is if it shou= ld only be about acct: for simplicity.

 

As an example should we be expecting it to resolve x= mpp:  tel:  or other things.   

For http: and https: scheme URI perhaps link headers= pointing to a acct: relation are the most appropriate.

 

WF is about having a identifier in User Principal na= me (UPN)  form where the principal is a domain and finding the JRD doc= ument or documents for that account.

 

There is a bunch of hedging that it can work with an= y URI but that may just be confusing the issue.

 

My personal preference t this point (others working = on openID Connect may well disagree) is to go all in on acct: and just admi= t that WF is the resolution process for those URI.

 

That is what most people think of it as anyway.=

 

John B.

 

 

On 2012-12-02, at 10:35 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:=



-1.  = I feel strongly for keeping the acct: scheme.  WebFinger isn't just ab= out email.

On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray = <tbray@textual= ity.com> wrote:

I don̵= 7;t want to wait for work on this to be completed, and I don’t think = that its presence is necessary for WebFinger to be useful.  So let's t= ake it out.

Proposal:
Section 4.1: Change the URI in the example from acct: to mailto:
Section 4.2: Same
Section 5.3: Same
Section 5.4: s/it could be an "acct" URI [7], //
Section 5.4: Remove 2nd para, beginning "For resources associated with= a user account at a host...“
Section 5.4: s/both an "acct" URI and any alias/any alias/
Section 8: Change the URI in the example from acct: to mailto:

On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray = <tbray@textual= ity.com> wrote:

No, we’re on the same side here. I&= #8217;m suggesting taking webfinger-07 as a baseline, and all *future* chan= ges need to be proposed as a concrete delta against it.  -T=

 = ;

On Sun, Dec 2, 2012 at 12:59 PM, Paul E. = Jones <paulej= @packetizer.com> wrote:

Tim,

 

I didn’t mean to be rude by intro= ducing these changes, just trying to move things along.  Most changes were fairly trivial, not worth mentioning, and can be seen here:

http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Dd= raft-ietf-appsawg-webfinger-07.txt

 

The most significant changes were the r= e-write of section 5.2 and modification to the language related to HTTPS in 5.1.  I suspect that is the text to which you refer as pr= eferring it to be “camera-ready”.  (I would assume the bal= ance of the changes would not need to be presented as “camera-ready&#= 8221;, since they’re minor editorial things.)

 

In any case, the most important text ch= anges I would like folks to consider is section 5.2 (which aims to fully document the JSON Resource Descriptor object) and paragraphs= 2 and 3 in section 5.1.

 

Paul

 

 

Thanks to Paul for the extra effort.  I’d like to suggest, in= the interests of courtesy and efficiency, that from here on on, contributi= ons to this discussion be “camera-ready”, that is to say, specific suggestions in the style of a diff, including fully-wr= itten-out replacements language.

 -Tim

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> w= rote:

Folks,

 

I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and transport= ).  The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfin= ger-07

 

With respect to resource representation, I fully described the JSO= N Resource Descriptor within the document.  There are no external refe= rences to RFC 6415 now, no need to go read the XRD spec, etc.  It’s a fairly simple format and I believe t= his text documents it sufficiently.  Combined with the visual examples= , I think this makes it pretty clear.  Have a look at the JRD document= ation in section 5.2 and provide your comments.

 

With respect to HTTPS, it seems there is strong preference for = 220;HTTPS only”, but some a fair bit of insistence for allowing HTTP.=   I changed the wording in 5.2 to try to capture opinions.  Previously, the text led with a requirement to try HTTPS f= irst.  That is still there.  I just added some extra conditions t= hat make it clearer that there are some instances where a client must not u= tilize HTTP.  This might need further refinement, but I think there is a balance we can strike here between the two camps wi= thout introducing a lot of complex language.

 

I made some editorial changes through the document.

 

Comments are welcome, as always.  Seems I don’t need to= say that to this group, though :-)

 

Paul

 


_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

 

 

 

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436690FAD2TK5EX14MBXC283r_-- From paulej@packetizer.com Sun Dec 2 23:01:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707C521F86EF for ; Sun, 2 Dec 2012 23:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw0vudvfZ-3Q for ; Sun, 2 Dec 2012 23:01:36 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1543221F857D for ; Sun, 2 Dec 2012 23:01:36 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB371Ylc012128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 02:01:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354518095; bh=P5yUhhoKg1yZkKuaSOqToyojP+skxS0WVWfiGlwZ+po=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=YFFGQOyKXku4HCHOlMKy0b1F8j+YK6ogUL6ix19XI5Lv9coceRz82iNxibvJQ0w3g /63YwHGq4MA+OEG7shVcCagM7qiyJTRadF/3BM/X3piL4ICxXGLB+K/ffE07mVHbN3 mYWwBPbVtaclCkgj5pqjlgVsoX+sFYEkoQ40CxIc= From: "Paul E. Jones" To: "'John Bradley'" , References: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> In-Reply-To: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> Date: Mon, 3 Dec 2012 02:01:33 -0500 Message-ID: <08cb01cdd124$07bf0740$173d15c0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08CC_01CDD0FA.1EEAD400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQITt0iW8mEwUphkpzmiosoEPt1RdQIwGr8XASDcrjqXYE9HMA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 07:01:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08CC_01CDD0FA.1EEAD400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A single URI scheme does not make it simpler or more complex. The scheme just defines that entity being queried. If you want to learn something given my twitter id, then the client would query using acct:. Generally, I think that "acct:" is the scheme that should be used for user@domain forms. However, if I want to auto-provision my email client, I would expect my email client to query using "mailto:paulej@packetizer.com". If I want to know how to configure my XMPP client, my client might query xmpp:paulej@packetizer.com. Perhaps if both queries go to the same server, one might get the same reply. Perhaps not. WebFinger is intended to describe any entity on the Internet, not just users. Thus "acct" is not appropriate in all cases. If I want to get metadata information about a URI (e.g., http://www.packetizer.com/), then WebFinger could be used to return that metadata. That might be a copyright date, server information, or whatever one wants to define. A given client does not need to understand every kind of response from a server. Things not understood are ignored. So, given a URI, there may or may not be things a generic client understands. However, as we start to define link relations and property values, and describe how those are used in certain specialized tasks (e.g., email client configuration), then I believe you will appreciate the flexibility offered by the current protocol. Paul From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Sunday, December 02, 2012 8:52 PM To: webfinger@googlegroups.com Cc: Paul E. Jones; apps-discuss@ietf.org Subject: Re: Draft -07 proposal: Remove dependency on "acct:" scheme I agree that WF is not just about email. A question ( perhaps channeling Blane) is if it should only be about acct: for simplicity. As an example should we be expecting it to resolve xmpp: tel: or other things. For http: and https: scheme URI perhaps link headers pointing to a acct: relation are the most appropriate. WF is about having a identifier in User Principal name (UPN) form where the principal is a domain and finding the JRD document or documents for that account. There is a bunch of hedging that it can work with any URI but that may just be confusing the issue. My personal preference t this point (others working on openID Connect may well disagree) is to go all in on acct: and just admit that WF is the resolution process for those URI. That is what most people think of it as anyway. John B. On 2012-12-02, at 10:35 PM, Brad Fitzpatrick wrote: -1. I feel strongly for keeping the acct: scheme. WebFinger isn't just about email. On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: I don't want to wait for work on this to be completed, and I don't think that its presence is necessary for WebFinger to be useful. So let's take it out. Proposal: Section 4.1: Change the URI in the example from acct: to mailto: Section 4.2: Same Section 5.3: Same Section 5.4: s/it could be an "acct" URI [7], // Section 5.4: Remove 2nd para, beginning "For resources associated with a user account at a host..." Section 5.4: s/both an "acct" URI and any alias/any alias/ Section 8: Change the URI in the example from acct: to mailto: On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: No, we're on the same side here. I'm suggesting taking webfinger-07 as a baseline, and all *future* changes need to be proposed as a concrete delta against it. -T On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones wrote: Tim, I didn't mean to be rude by introducing these changes, just trying to move things along. Most changes were fairly trivial, not worth mentioning, and can be seen here: http://tools.ietf.org/rfcdiff?difftype=--hwdiff &url2=draft-ietf-appsawg-webfinger-07.txt The most significant changes were the re-write of section 5.2 and modification to the language related to HTTPS in 5.1. I suspect that is the text to which you refer as preferring it to be "camera-ready". (I would assume the balance of the changes would not need to be presented as "camera-ready", since they're minor editorial things.) In any case, the most important text changes I would like folks to consider is section 5.2 (which aims to fully document the JSON Resource Descriptor object) and paragraphs 2 and 3 in section 5.1. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, December 02, 2012 2:54 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 Thanks to Paul for the extra effort. I'd like to suggest, in the interests of courtesy and efficiency, that from here on on, contributions to this discussion be "camera-ready", that is to say, specific suggestions in the style of a diff, including fully-written-out replacements language. -Tim On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_08CC_01CDD0FA.1EEAD400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A single URI scheme does not make it simpler or more complex.  = The scheme just defines that entity being = queried.

 

If you want to learn something given my twitter id, then the client = would query using acct:.  Generally, I think that = “acct:” is the scheme that should be used for user@domain = forms.

 

However, if I want to auto-provision my email client, I would expect = my email client to query using = “mailto:paulej@packetizer.com”.  If I want to know how = to configure my XMPP client, my client might query = xmpp:paulej@packetizer.com.

 

Perhaps if both queries go to the same server, one might get the same = reply.  Perhaps not.

 

WebFinger is intended to describe any entity on the Internet, not = just users.  Thus “acct” is not appropriate in all = cases.  If I want to get metadata information about a URI (e.g., = http://www.packetizer.com/), then WebFinger could be used to return that = metadata.  That might be a copyright date, server information, or = whatever one wants to define.

 

A given client does not need to understand every kind of response = from a server.  Things not understood are ignored.  So, given = a URI, there may or may not be things a generic client = understands.  However, as we start to define link relations and = property values, and describe how those are used in certain specialized = tasks (e.g., email client configuration), then I believe you will = appreciate the flexibility offered by the current = protocol.

 

Paul

 

From:= = John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Sunday, = December 02, 2012 8:52 PM
To: = webfinger@googlegroups.com
Cc: Paul E. Jones; = apps-discuss@ietf.org
Subject: Re: Draft -07 proposal: Remove = dependency on "acct:" = scheme

 

I agree that = WF is not just about email.

 

A = question ( perhaps channeling Blane) is if it should only be about acct: = for simplicity.

 

As an example should we be expecting it to resolve = xmpp:  tel:  or other things. =   

For http: and = https: scheme URI perhaps link headers pointing to a acct: relation are = the most appropriate.

 

WF is about having a identifier in User Principal name = (UPN)  form where the principal is a domain and finding the JRD = document or documents for that account.

 

There is a bunch of hedging that it can work with any = URI but that may just be confusing the = issue.

 

My personal preference t this point (others working on = openID Connect may well disagree) is to go all in on acct: and just = admit that WF is the resolution process for those = URI.

 

That is what most people think of it as = anyway.

 

John B.

 

 

On = 2012-12-02, at 10:35 PM, Brad Fitzpatrick <bradfitz@google.com> = wrote:



-1.  I = feel strongly for keeping the acct: scheme.  WebFinger isn't just = about email.

On Sun, Dec = 2, 2012 at 5:14 PM, Tim Bray <tbray@textuality.com> = wrote:

I = don’t want to wait for work on this to be completed, and I = don’t think that its presence is necessary for WebFinger to be = useful.  So let's take it out.

Proposal:
Section 4.1: = Change the URI in the example from acct: to mailto:
Section 4.2: = Same
Section 5.3: Same
Section 5.4: s/it could be an = "acct" URI [7], //
Section 5.4: Remove 2nd para, beginning = "For resources associated with a user account at a = host...“
Section 5.4: s/both an "acct" URI and any = alias/any alias/
Section 8: Change the URI in the example from acct: = to mailto:

On Sun, Dec = 2, 2012 at 1:57 PM, Tim Bray <tbray@textuality.com> = wrote:

No, = we’re on the same side here. I’m suggesting taking = webfinger-07 as a baseline, and all *future* changes need to be proposed = as a concrete delta against it.  = -T

 

On Sun, Dec = 2, 2012 at 12:59 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Tim,

 

I didn’t mean to be rude by introducing these changes, just = trying to move things along.  Most changes were fairly trivial, not = worth mentioning, and can be seen here:

http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&u= rl2=3Ddraft-ietf-appsawg-webfinger-07.txt

 

The most significant changes were the re-write of section 5.2 and = modification to the language related to HTTPS in 5.1.  I suspect = that is the text to which you refer as preferring it to be = “camera-ready”.  (I would assume the balance of the = changes would not need to be presented as “camera-ready”, = since they’re minor editorial things.)

 

In any case, the most important text changes I would like folks to = consider is section 5.2 (which aims to fully document the JSON Resource = Descriptor object) and paragraphs 2 and 3 in section = 5.1.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, = December 02, 2012 2:54 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: = [apps-discuss] = draft-ietf-appsawg-webfinger-07

 <= /o:p>

Thanks to Paul = for the extra effort.  I’d like to suggest, in the interests = of courtesy and efficiency, that from here on on, contributions to this = discussion be “camera-ready”, that is to say, specific = suggestions in the style of a diff, including fully-written-out = replacements language.

 -Tim

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07

 <= /o:p>

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc.  It’s = a fairly simple format and I believe this text documents it = sufficiently.  Combined with the visual examples, I think this = makes it pretty clear.  Have a look at the JRD documentation in = section 5.2 and provide your comments.

 <= /o:p>

With = respect to HTTPS, it seems there is strong preference for “HTTPS = only”, but some a fair bit of insistence for allowing HTTP.  = I changed the wording in 5.2 to try to capture opinions.  = Previously, the text led with a requirement to try HTTPS first.  = That is still there.  I just added some extra conditions that make = it clearer that there are some instances where a client must not utilize = HTTP.  This might need further refinement, but I think there is a = balance we can strike here between the two camps without introducing a = lot of complex language.

 <= /o:p>

I made some = editorial changes through the document.

 <= /o:p>

Comments = are welcome, as always.  Seems I don’t need to say that to = this group, though :-)

 

Paul

 


______________= _________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 <= /o:p>

 

 

 

 

------=_NextPart_000_08CC_01CDD0FA.1EEAD400-- From paulej@packetizer.com Sun Dec 2 23:11:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B466F21F878C for ; Sun, 2 Dec 2012 23:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga+LGxaiIiKL for ; Sun, 2 Dec 2012 23:11:06 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4BE21F890F for ; Sun, 2 Dec 2012 23:11:02 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB37B0Hs012516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 02:11:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354518661; bh=28kIRZlY8G6DoD4iA2LaCoK2JyjdhTTnjNQAJDQ/fZU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=uJABmOmEDzHw9J9RjqEF9YITD92Q9zY+KaI7i1f1HR4p3UzKYLeTiRi9dyNRMLiva G1MixVkRFRcpzJ8ozKEEc/fda8OP7AZ+K1IoqS6NWTkfXVH30tiakocn25D169Xo9C g3wz3zOBFh19pPkuqmN4ek6UvvGdAFgusTROJ4nA= From: "Paul E. Jones" To: "'Tim Bray'" References: In-Reply-To: Date: Mon, 3 Dec 2012 02:10:59 -0500 Message-ID: <08d801cdd125$59305fb0$0b911f10$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08D9_01CDD0FB.705B4210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKjOTtxuJPk2ISqfIA9/hDsstMTgpZb1nmg Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: Remove top-level "properties" in JRD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 07:11:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08D9_01CDD0FB.705B4210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tim, I don't think we should get rid of properties that relate to the subject or properties that relate to a link relation. I'd argue we should keep the presently-defined JRD exactly as it is (modulo correcting any errors in my text). Properties that describe the JRD can be used for useful things like conveying a person's name as I showed in the example here: https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-5.2.4 Properties in link relations can provide a client with information so that it does not have to issue subsequent queries to learn information. The entire email client configuration example shows how that could be done: https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3 Yes, those details could be pushed off into a yet-to-be-described, separate document that has to be queried, but why do that if we can succinctly describe what we need right within the JRD? A generic client looking for user information just ignores this stuff, after all. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, December 02, 2012 8:15 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Draft -07 mod proposal: Remove top-level "properties" in JRD This is actively harmful. Link relations are an excellent way to express properties of a resource, and having two competing mechanisms will distract developers and hurt interoperability. Proposal: 1. Introduction: s/link relations, properties, titles/link relations, titles/ 3. Overview: same 4.1 remove "properties:" member of JRD 4.1 last para s/and properties// 4.2 remove "properties:" member of JRD 4.2 s/any aliases and properties/any aliases/ 4.3 remove "properties" top-level member of JRD 5.2 remove "properties" from bullet list after 1st para 5.2 s/"properties" is an object comprised of name/value pairs whose values are strings// 5.2.4 Remove section 5.3 example, remove top-level "properties" member 5.4 s/and properties// On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_08D9_01CDD0FB.705B4210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim,

 

I don’t think we should get rid of properties that relate to = the subject or properties that relate to a link relation.  = I’d argue we should keep the presently-defined JRD exactly as it = is (modulo correcting any errors in my text).

 

Properties that describe the JRD can be used for useful things like = conveying a person’s name as I showed in the example = here:

https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#sec= tion-5.2.4

 

Properties in link relations can provide a client with information so = that it does not have to issue subsequent queries to learn = information.  The entire email client configuration example shows = how that could be done:

https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#secti= on-4.3

 

Yes, those details could be pushed off into a yet-to-be-described, = separate document that has to be queried, but why do that if we can = succinctly describe what we need right within the JRD?  A generic = client looking for user information just ignores this stuff, after = all.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December = 02, 2012 8:15 PM
To: Paul E. Jones
Cc: = apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: = Draft -07 mod proposal: Remove top-level "properties" in = JRD

 

This is actively harmful.  Link = relations are an excellent way to express properties of a resource, and = having two competing mechanisms will distract developers and hurt = interoperability.

Proposal:

1. Introduction: s/link = relations, properties,  titles/link relations, titles/
3. = Overview: same
4.1 remove "properties:" member of = JRD
4.1 last para s/and properties//
4.2 remove = "properties:" member of JRD
4.2 s/any aliases and = properties/any aliases/
4.3 remove "properties" top-level = member of JRD
5.2 remove "properties" from bullet list = after 1st para
5.2 s/"properties" is an object comprised of = name/value pairs whose values are strings//
5.2.4 Remove = section
5.3 example, remove top-level "properties" = member
5.4 s/and properties//

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07

 <= /o:p>

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc.  It’s = a fairly simple format and I believe this text documents it = sufficiently.  Combined with the visual examples, I think this = makes it pretty clear.  Have a look at the JRD documentation in = section 5.2 and provide your comments.

 <= /o:p>

With = respect to HTTPS, it seems there is strong preference for “HTTPS = only”, but some a fair bit of insistence for allowing HTTP.  = I changed the wording in 5.2 to try to capture opinions.  = Previously, the text led with a requirement to try HTTPS first.  = That is still there.  I just added some extra conditions that make = it clearer that there are some instances where a client must not utilize = HTTP.  This might need further refinement, but I think there is a = balance we can strike here between the two camps without introducing a = lot of complex language.

 <= /o:p>

I made some = editorial changes through the document.

 <= /o:p>

Comments = are welcome, as always.  Seems I don’t need to say that to = this group, though :-)

 

Paul

 


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_08D9_01CDD0FB.705B4210-- From paulej@packetizer.com Sun Dec 2 23:16:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8392921F849A for ; Sun, 2 Dec 2012 23:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAAGY17EGMgC for ; Sun, 2 Dec 2012 23:16:27 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F029C21F8475 for ; Sun, 2 Dec 2012 23:16:26 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB37GP7Y012764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 02:16:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354518985; bh=Na3L9EVzIiWhYgArdXk2Yg07oGx5PyU22TwHQwTLRBg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=gRmhrewrzbcNCEvLLxLADhRD65cMth9JPtKpnoVV0LqDpdmE1ZuVIezEd3CQeENvd 42Da55PRMqlMNZMgfxaiJ07s7jU+Evf8eBs6K7ceYkh+3PRyCwRhM9NKGB6J5e8LE3 kDPZHOZBJWhEYFmuGVnud3Mzf4SatmydHktrgveE= From: "Paul E. Jones" To: "'Tim Bray'" References: In-Reply-To: Date: Mon, 3 Dec 2012 02:16:24 -0500 Message-ID: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08E6_01CDD0FC.3201B0C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLG5ikawERVTngmuhW5Swaa7Q+GspYUf61A Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 07:16:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08E6_01CDD0FC.3201B0C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tim, Yeah, I can appreciate that. However, I would like to suggest some slightly different wording. How is this for the first paragraph in 5.2.2? "The value of the "subject" member is a string whose value is advisory and normally would be expected to be equivalent to the value of the "resource" parameter in the client request. The "subject" identifies the entity to which the JRD describes." Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, December 02, 2012 8:15 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Draft -07 mod proposal: Clean up "subject" Right now, section 5.2.2 says "The value of the "subject" member is a string that MUST be set to the same value as the "resource" parameter in the client request. " This is a recipe for trouble, for a couple of reasons. First of all, what does "the same value" mean? Go visit RFC3986, section 6, and enjoy several hundred words walking through all the issues that arise in trying to figure out when two URIs are equivalent, ranging from exact character-by-character identity to all sorts of protocol-specific goo. You are just one level of case-sensitivity-in-%-escaping from a big hairy false negative. I'm also worried about a lack of flexibility. I might have a single webfinger resource that declares a bunch of link relations for a bunch of different resources. This section, as written, wouldn't let me do that. Proposal: Re-write section 5.2.2 as follows: <<<<<<< The value of the "subject" member is a string whose value is advisory, identifying the resource to which the properties given in the "links" member apply. Normally this would be expected to be equivalent to the value of the "resource" parameter in the client request. <<<<<<< On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_08E6_01CDD0FC.3201B0C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim,

 

Yeah, I can appreciate that.  However, I would like to suggest = some slightly different wording.  How is this for the first = paragraph in 5.2.2?

 

“The value of the "subject" member is a string whose = value is advisory and normally would be expected to be equivalent to the = value of the "resource" parameter in the client request.  = The "subject" identifies the entity to which the JRD = describes.”

 

Paul

 

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December = 02, 2012 8:15 PM
To: Paul E. Jones
Cc: = apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: = Draft -07 mod proposal: Clean up = "subject"

 

Right now, section 5.2.2 says "The = value of the "subject" member is a string that MUST be set to = the same value as the "resource" parameter in the client = request. "

This is a recipe for trouble, for a couple of = reasons. First of all, what does “the same value” = mean?  Go visit RFC3986, section 6, and enjoy several hundred words = walking through all the issues that arise in trying to figure out when = two URIs are equivalent, ranging from exact character-by-character = identity to all sorts of protocol-specific goo. You are just one level = of case-sensitivity-in-%-escaping from a big hairy false = negative.

I’m also worried about a lack of flexibility. I = might have a single webfinger resource that declares a bunch of link = relations for a bunch of different resources. This section, as written, = wouldn’t let me do that.

Proposal: Re-write section 5.2.2 = as follows:

<<<<<<<
The value of the = "subject" member is a string whose value is advisory, = identifying the resource to which the properties given in the = "links" member apply.  Normally this would be expected to = be equivalent to the value of the "resource" parameter in the = client request.
<<<<<<<

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07

 <= /o:p>

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc.  It’s = a fairly simple format and I believe this text documents it = sufficiently.  Combined with the visual examples, I think this = makes it pretty clear.  Have a look at the JRD documentation in = section 5.2 and provide your comments.

 <= /o:p>

With = respect to HTTPS, it seems there is strong preference for “HTTPS = only”, but some a fair bit of insistence for allowing HTTP.  = I changed the wording in 5.2 to try to capture opinions.  = Previously, the text led with a requirement to try HTTPS first.  = That is still there.  I just added some extra conditions that make = it clearer that there are some instances where a client must not utilize = HTTP.  This might need further refinement, but I think there is a = balance we can strike here between the two camps without introducing a = lot of complex language.

 <= /o:p>

I made some = editorial changes through the document.

 <= /o:p>

Comments = are welcome, as always.  Seems I don’t need to say that to = this group, though :-)

 

Paul

 


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_08E6_01CDD0FC.3201B0C0-- From paulej@packetizer.com Sun Dec 2 23:19:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368D521F8ABE for ; Sun, 2 Dec 2012 23:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ+EuK-+lYxR for ; Sun, 2 Dec 2012 23:19:22 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B944D21F8ABD for ; Sun, 2 Dec 2012 23:19:22 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB37JLeo012896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 02:19:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354519162; bh=HB3f39hHF90PM5RdofGazVByclREs1Xla+lWRYyk42c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=IU1xFPFJp1PkNP+IXlIr/UwVrnpOcAOfYQB7Dw74sEcq4kmK134yq/YqecXrX9/N5 ckzxFcPKvLaWr9RIfoaF8P58n3ovhEg57r3Npb+QokP1ANT5ILCBUylEj3YbNj4F7a ob0pubYzkwjkc8905yG+8OmGGPU5/WyhmcJoL2HA= From: "Paul E. Jones" To: "'Tim Bray'" References: In-Reply-To: Date: Mon, 3 Dec 2012 02:19:21 -0500 Message-ID: <091901cdd126$83d2b8c0$8b782a40$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_091A_01CDD0FC.9AFD7410" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFle3OGxU84YUE6EJe9JiklLtNrapjXVdgQ Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 07:19:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_091A_01CDD0FC.9AFD7410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Where are you suggesting this be placed exactly? Should we have a separate client or library behavior section? From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, December 02, 2012 8:15 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Draft -07 mod proposal: HTTPS with fallback parameter Change paragraph 2 of section 5.1 to read: WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback". If this parameter is not provided, client software MUST behave as if it were present with a value of false. WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol. If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource. If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter. If the value of allow-fallback is true, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger. If allow-fallback is false, client software MUST report an error and cease attempting to retrieve the resource. On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_091A_01CDD0FC.9AFD7410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Where are you suggesting this be placed exactly?  Should we have = a separate client or library behavior section?

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December = 02, 2012 8:15 PM
To: Paul E. Jones
Cc: = apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: = Draft -07 mod proposal: HTTPS with fallback = parameter

 

Change paragraph 2 of section 5.1 to = read:

WebFinger client software MUST accept as input a boolean = parameter which for the purposes of this discussion will be referred as = "allow-fallback".  If this parameter is not provided, = client software MUST behave as if it were present with a value of = false.

WebFinger client software MUST attempt to retrieve = /.well-known/webfinger using the HTTPS protocol.  If an HTTPS = connection is made, and the server has an invalid certificate, or = returns an HTTP status code indicating an error, the client software = MUST report an error and cease attempting to retrieve the = resource.

If the WebFinger client software is unable to establish = an HTTPS connection to the server, behavior depends on the value of the = allow-fallback parameter.  If the value of allow-fallback is true, = the client software MAY fall back to unencrypted HTTP in an attempt to = retrieve /.well-known/webfinger.  If allow-fallback is false, = client software MUST report an error and cease attempting to retrieve = the resource.


On = Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07

 <= /o:p>

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc.  It’s = a fairly simple format and I believe this text documents it = sufficiently.  Combined with the visual examples, I think this = makes it pretty clear.  Have a look at the JRD documentation in = section 5.2 and provide your comments.

 <= /o:p>

With = respect to HTTPS, it seems there is strong preference for “HTTPS = only”, but some a fair bit of insistence for allowing HTTP.  = I changed the wording in 5.2 to try to capture opinions.  = Previously, the text led with a requirement to try HTTPS first.  = That is still there.  I just added some extra conditions that make = it clearer that there are some instances where a client must not utilize = HTTP.  This might need further refinement, but I think there is a = balance we can strike here between the two camps without introducing a = lot of complex language.

 <= /o:p>

I made some = editorial changes through the document.

 <= /o:p>

Comments = are welcome, as always.  Seems I don’t need to say that to = this group, though :-)

 

Paul

 


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_091A_01CDD0FC.9AFD7410-- From paulej@packetizer.com Sun Dec 2 23:33:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B187721F8AC7 for ; Sun, 2 Dec 2012 23:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVfBqXirJvAh for ; Sun, 2 Dec 2012 23:33:41 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C61E721F898C for ; Sun, 2 Dec 2012 23:33:41 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB37XbOa013467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 02:33:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354520018; bh=GRAah52xgc7o1yeGTgYUHISwaSgURwFvGb093Et45og=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RGaDTqc9xI66irBgV61B3fWClB0k/o37PWvLy3JxHTYTe4gyEoYNOITxPqaZ10MQC tB+RaW+QmJvLdYT0oOXgszjfwxyh+KKD3DDCrBUpXvSli8wr2bbYoew/WubSfEVU5u QAul10P0AMZvWJOWN1V8dHc1aqcd+wRpGNHRpu4k= From: "Paul E. Jones" To: "'Dick Hardt'" References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> In-Reply-To: Date: Mon, 3 Dec 2012 02:33:37 -0500 Message-ID: <092601cdd128$8276c050$876440f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLrZ2Se+xCQ1wKSSFBTHovI4rJ73wIvNloxAedIuXAA9cPVgQKCxNrpAaoig/sCH1k1jwGrYWq2AipsKXMChR/lCwF99wDGAxHsnkIB0G8+1AJOdXLAAQVCTGcCX/geEwJOKcO0AeWzd2oBXNkqhgIFo/A/AZVXZBECa7jIOgJPc/d9AXtstykB3Uji3QIHfXp5Ak3EinEB2xgoWwLCVF31lAuxKMA= Content-Language: en-us Cc: 'Joseph Holsten' , webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 07:33:42 -0000 Dick, I gave a list down below of where HTTP was likely sufficient. What we lose by demanding TLS is the ability to use WF in places where putting a TLS certificate is impossible or impractical or useless. I don't need TLS on the server running in my house, for example. (And I'm just the kind of person that might find a use for WF in such a closed environment.) You can still use curl, though: curl https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer .com || curl http://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer. com Granted, this is a somewhat faulty fallback mechanism. This is more accurate: curl https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer .com if [ $? == 7 ] then curl http://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer. com fi I fully agree that this is not as elegant as a one-liner, but it works. You're entirely right about the latency. That's the one thing I really don't like about the fallback approach. That said, if we go with HTTPS only and there is no server running, the delay still exists and the user gets no information. Turning around immediately and issuing a query via HTTP is pretty quick... unless there is no server running there, either :) I'll say again, though, that I don't need to be persuaded. I'll go along with the group. Paul > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Sunday, December 02, 2012 10:25 PM > To: Paul E. Jones > Cc: 'Dick Hardt'; webfinger@googlegroups.com; apps-discuss@ietf.org; > 'Joseph Holsten' > Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP > > Hi Paul > > I agree there are many use cases where the security is not essential. > > My question was what do we lose by requiring TLS? > > I know we are adding complexity to server implementations, but what else > are we losing? > > As for dealing with a 3XX redirect, many client libraries will do that > automagically for you. > > There is a real latency and extra code in dealing with the fallback as > currently specified. > > For example, we lose being able to use a simple CURL command to get a > JRD. > > Again, what are we losing by HTTPS only? A pro and con list would be > helpful. > > -- Dick > > On Dec 2, 2012, at 7:11 PM, "Paul E. Jones" > wrote: > > > Dick, > > > > I can imagine university networks and even some businesses that would > > utilize WebFinger for internal purposes where security is not > essential. > > > > If WF takes off, then there might be millions of domains out there > > that provide WF services. What percentage of those might use WF in > > scenarios where security is important? If WF is used to > > auto-provision an email client or direct a user to log into an IdP, > > then I can appreciate a need to use TLS. So, in applications where > > TLS is really needed, I would not bother with attempting a request via > HTTP. > > > > Example uses where HTTP is probably "good enough": > > * Clicking on acct:paulej@packetizer.com in my browser and having > > a "profile" page produced that contains whatever information > > that is found (e.g., a picture, contact info, blog, web site) > > * Clicking on the sender's name in an email client to fetch > > the person's vcard, picture, or other. > > * Fetching a user's picture when he or she posts something on a web > > site (I assume that the user has an account at the web site and the > > site has verified the user's email address) > > > > I appreciate that the client code will be made a little more complex, > > but the effort is not really more than handling a 3xx redirection. > > > > I'm not arguing strongly either way, though. I could put the mandate > > in for TLS, but there are other folks who want to allow plain ol' > > HTTP. They've spoken on the list. > > > > Paul > > > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > >> bounces@ietf.org] On Behalf Of Dick Hardt > >> Sent: Sunday, December 02, 2012 10:00 AM > >> To: webfinger@googlegroups.com > >> Cc: apps-discuss@ietf.org; 'Joseph Holsten' > >> Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP > >> > >> > >> On Dec 2, 2012, at 12:30 AM, "Paul E. Jones" > >> wrote: > >>> In any case, the current document encourage use of HTTPS. But, it > >>> still allows for HTTP and I can see some valid cases for it. > >> > >> What are the avid use cases? > >> > >> Keep in mind we are adding complexity to clients by allowing both, so > >> there is a real cost to allowing both. I'm not clear what we are > >> losing by HTTPS-only > >> > >> -- Dick > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > From paulej@packetizer.com Sun Dec 2 23:37:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2828721F871D for ; Sun, 2 Dec 2012 23:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OECKvQWxjj-T for ; Sun, 2 Dec 2012 23:37:51 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0254321F8704 for ; Sun, 2 Dec 2012 23:37:50 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB37bkEM013643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 02:37:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354520267; bh=93Nb+WTkZ49z5V9q6ogdA+0Hjw7oJBhAPgb04vyySA8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=lf5/68N2X1yUELTgjo3/ewrWPRCUUbFQXnrw6nkQrckWlYZgWKvWmHszaSCYI13Ms buWEBQusDqk7f4zy1nuGgjJ5e8GXP5ALRr7KqncG8PyxIPMhnusmIXF/AiehEoBHhJ 9orEwjveq/1R62bbKeynO/bbR6z0+aQwfZ1VBoO0= From: "Paul E. Jones" To: "'Nico Williams'" , "'Dick Hardt'" References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> In-Reply-To: Date: Mon, 3 Dec 2012 02:37:46 -0500 Message-ID: <092801cdd129$16b09cf0$4411d6d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0929_01CDD0FF.2DDB7F50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLrZ2Se+xCQ1wKSSFBTHovI4rJ73wIvNloxAedIuXAA9cPVgQKCxNrpAaoig/sCH1k1jwGrYWq2AipsKXMChR/lCwF99wDGAxHsnkIB0G8+1AJOdXLAAQVCTGcCX/geEwIFo/A/AZVXZBECa7jIOgJPc/d9AXtstykB3Uji3QIHfXp5Ak3EinEB2xgoWwLCVF31Alq0QSACKaqGdwLfmOUzk/0ay8A= Content-Language: en-us Cc: apps-discuss@ietf.org, webfinger@googlegroups.com, 'Joseph Holsten' Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 07:37:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0929_01CDD0FF.2DDB7F50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable SNI is actually a real problem still and with the current WF spec, even = HTTP would not work since the text says that if we get a cert error, = don=E2=80=99t try HTTP. =20 If we want to allow HTTP to work on sites that are running HTTPS for = some service, but not necessarily dedicated to the target domain, we = will have intermittent issues until such time as all client code = properly supports SNI. =20 I mentioned before that there is a heck of a lot of client code out = there still that does not work with SNI. This will just take time. We = either have to just accept the failures or soften the text related to = failures by saying the response should be ignored and allow the client = to use HTTP to get a WF response. (Again, apps that depend on security = may opt to not do that.) =20 Paul =20 =20 From: Nico Williams [mailto:nico@cryptonector.com]=20 Sent: Monday, December 03, 2012 12:11 AM To: Dick Hardt Cc: Nico Williams; Paul E. Jones; Joseph Holsten; = webfinger@googlegroups.com; apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP =20 On Sunday, December 2, 2012, Dick Hardt wrote: On Dec 2, 2012, at 8:56 PM, Nico Williams > wrote: > On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt > wrote: >> I agree there are many use cases where the security is not essential. >> >> My question was what do we lose by requiring TLS? > > Some hosting sites can't handle it well at all. Either they require > server certs that can serve many domains or they require per-domain IP > addresses because SNI is not well supported. Which sites? Are they critical to the successful deployment of WF? If WF = is successful, will they make it easier to deploy TLS? Perhaps = HTTPS-only will drive easier TLS support. That would seem to be a good = thing. =20 My domain's hosting site, for example. This is not about the hosting = site: it's about the incomplete deployment of TLS SNI. =20 > > Many clients don't do proper server cert validation. "I used TLS" = !=3D > "I got it securely". So we should not force HTTPS because some clients don't implement it = properly? Really? =20 No, we should not mandate TLS if either we know that requirement will = often be ignored or if we're doing it because we think that gets use = "security". And if we do end up requiring TLS we need to say a lot more = about server certificate validation, about TLS cipher suites (e.g., no = anon DH ones), and so on, about trust anchors (same as for web = browsers?). =20 > >> There is a real latency and extra code in dealing with the fallback = as currently specified. > > But is that relevant here? I would think so. If the user is waiting for discovery to be finished, = latency is an issue. Extra code is extra code and complexity and more to understand. =20 I wouldn't worry about a line of code given TLS' complexity, which we'd = be requiring. The latency involved in one more fallback may well = matter, but I'm not ready to conclude that it means we must require TLS = because we could still consider the alternative that the WF app/ user be = the one to decide whether to use TLS at all or not, without a fallback = in either case (actually, I prefer this alternative). =20 >> For example, we lose being able to use a simple CURL command to get a = JRD. > > So you need an if and two invocations of curl. So you agree it is more complicated. The agreed goal is to push = complexity to the server. =20 Agreed by whom? ------=_NextPart_000_0929_01CDD0FF.2DDB7F50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

SNI is actually a real problem still and with the current WF spec, = even HTTP would not work since the text says that if we get a cert = error, don=E2=80=99t try HTTP.

 

If we want to allow HTTP to work on sites that are running HTTPS for = some service, but not necessarily dedicated to the target domain, we = will have intermittent issues until such time as all client code = properly supports SNI.

 

I mentioned before that there is a heck of a lot of client code out = there still that does not work with SNI.=C2=A0 This will just take = time.=C2=A0 We either have to just accept the failures or soften the = text related to failures by saying the response should be ignored and = allow the client to use HTTP to get a WF response.=C2=A0 (Again, apps = that depend on security may opt to not do that.)

 

Paul

 

 

From:= = Nico Williams [mailto:nico@cryptonector.com]
Sent: Monday, = December 03, 2012 12:11 AM
To: Dick Hardt
Cc: Nico = Williams; Paul E. Jones; Joseph Holsten; webfinger@googlegroups.com; = apps-discuss@ietf.org
Subject: Re: [apps-discuss] HTTPS-only = vs HTTPS-and-HTTP

 



On = Sunday, December 2, 2012, Dick Hardt wrote:


On Dec 2, 2012, at 8:56 PM, Nico Williams <nico@cryptonector.com> wrote:

> = On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>> I = agree there are many use cases where the security is not = essential.
>>
>> My question was what do we lose by = requiring TLS?
>
> Some hosting sites can't handle it well = at all.  Either they require
> server certs that can serve = many domains or they require per-domain IP
> addresses because SNI = is not well supported.

Which sites? Are they critical to the = successful deployment of WF? If WF is successful, will they make it = easier to deploy TLS? Perhaps HTTPS-only will drive easier TLS support. = That would seem to be a good thing.

 

My domain's hosting site, for example.  This is = not about the hosting site: it's about the incomplete deployment of TLS = SNI.

 

>
> Many clients don't do proper server cert = validation.  "I used TLS" !=3D
> "I got it = securely".

So we should not force HTTPS because some clients = don't implement it properly? Really?

 

No, we should not mandate TLS if either we know that = requirement will often be ignored or if we're doing it because we think = that gets use "security".  And if we do end up requiring = TLS we need to say a lot more about server certificate validation, about = TLS cipher suites (e.g., no anon DH ones), and so on, about trust = anchors (same as for web browsers?).

 

>
>> There is a real latency and extra = code in dealing with the fallback as currently = specified.
>
> But is that relevant here?

I would = think so. If the user is waiting for discovery to be finished, latency = is an issue.
Extra code is extra code and complexity and more to = understand.

 

I = wouldn't worry about a line of code given TLS' complexity, which we'd be = requiring.  The latency involved in one more fallback may well = matter, but I'm not ready to conclude that it means we must require TLS = because we could still consider the alternative that the WF app/ user be = the one to decide whether to use TLS at all or not, without a fallback = in either case (actually, I prefer this = alternative).

 

>> = For example, we lose being able to use a simple CURL command to get a = JRD.
>
> So you need an if and two invocations of = curl.

So you agree it is more complicated. The agreed goal is to = push complexity to the server.

 

Agreed by = whom?

------=_NextPart_000_0929_01CDD0FF.2DDB7F50-- From tbray@textuality.com Sun Dec 2 23:44:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F7021F8ACC for ; Sun, 2 Dec 2012 23:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45LbW4uKFuXr for ; Sun, 2 Dec 2012 23:44:52 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2E6B21F86A4 for ; Sun, 2 Dec 2012 23:44:51 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2621612oag.31 for ; Sun, 02 Dec 2012 23:44:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=N1YePpxaYJ6ckb5X5k2OvZqQOeK+oCX2oyBBeYEz3FU=; b=lr9ZM//x1O5ZgLypZyUYz/3xn398qaEsEuKK2y2IQuZu/TCRuVXKI1taBM+DEgum39 nYp+R8hpOwXGSXJmD3DzE/23JToK8XwbLsOzH1QzH8zFH3WKCPymKy0yrjwkFeYrkpg2 8SAhXrLTDEDd5XbdXB1caOvslnLaiXG15/tzQgRtS3C6st7itAZ+RbBB7p9hulP2nJSL ZC9LHk9CdD187vPHcAHDU5E3RFC2j9m4ooA9EoK/AwTWP5UuebW0uOLRPCyJBFybPU3l HfBwUfomSNA12P6cGBo+IfdwrnmYibniSnUxC5slOagA6wPdUDuPWd5JLZ8hea7VEAXq F0wA== MIME-Version: 1.0 Received: by 10.182.52.105 with SMTP id s9mr3692831obo.25.1354520691242; Sun, 02 Dec 2012 23:44:51 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sun, 2 Dec 2012 23:44:51 -0800 (PST) X-Originating-IP: [172.26.48.5] In-Reply-To: <091901cdd126$83d2b8c0$8b782a40$@packetizer.com> References: <091901cdd126$83d2b8c0$8b782a40$@packetizer.com> Date: Sun, 2 Dec 2012 23:44:51 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae9399429a476b604cfedecbe X-Gm-Message-State: ALoCoQnmZxB4JGVr0sRKeHwCoWhtnt41ezeRQll58s+JIVmJ7TckAHWQV0L++tX7cjpFtsKtLYOu Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 07:44:53 -0000 --14dae9399429a476b604cfedecbe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Discretion of the editor. Assuming people are OK with the language. -T On Sun, Dec 2, 2012 at 11:19 PM, Paul E. Jones wrote= : > Where are you suggesting this be placed exactly? Should we have a > separate client or library behavior section?**** > > ** ** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Sunday, December 02, 2012 8:15 PM > *To:* Paul E. Jones > *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com > *Subject:* Draft -07 mod proposal: HTTPS with fallback parameter**** > > ** ** > > Change paragraph 2 of section 5.1 to read: > > WebFinger client software MUST accept as input a boolean parameter which > for the purposes of this discussion will be referred as "allow-fallback". > If this parameter is not provided, client software MUST behave as if it > were present with a value of false. > > WebFinger client software MUST attempt to retrieve /.well-known/webfinger > using the HTTPS protocol. If an HTTPS connection is made, and the server > has an invalid certificate, or returns an HTTP status code indicating an > error, the client software MUST report an error and cease attempting to > retrieve the resource. > > If the WebFinger client software is unable to establish an HTTPS > connection to the server, behavior depends on the value of the > allow-fallback parameter. If the value of allow-fallback is true, the > client software MAY fall back to unencrypted HTTP in an attempt to retrie= ve > /.well-known/webfinger. If allow-fallback is false, client software MUST > report an error and cease attempting to retrieve the resource. > > > **** > > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones > wrote:**** > > Folks,**** > > **** > > I published another version of the WebFinger spec trying to bring closure > to the two open issues I see (resource representation and transport). Th= e > new version is here:**** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** > > **** > > With respect to resource representation, I fully described the JSON > Resource Descriptor within the document. There are no external reference= s > to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly > simple format and I believe this text documents it sufficiently. Combine= d > with the visual examples, I think this makes it pretty clear. Have a loo= k > at the JRD documentation in section 5.2 and provide your comments. **** > > **** > > With respect to HTTPS, it seems there is strong preference for =93HTTPS > only=94, but some a fair bit of insistence for allowing HTTP. I changed = the > wording in 5.2 to try to capture opinions. Previously, the text led with= a > requirement to try HTTPS first. That is still there. I just added some > extra conditions that make it clearer that there are some instances where= a > client must not utilize HTTP. This might need further refinement, but I > think there is a balance we can strike here between the two camps without > introducing a lot of complex language.**** > > **** > > I made some editorial changes through the document.**** > > **** > > Comments are welcome, as always. Seems I don=92t need to say that to thi= s > group, though :-)**** > > **** > > Paul**** > > **** > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > ** ** > --14dae9399429a476b604cfedecbe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Discretion of the editor. Assuming people are OK with the language. -T
<= br>
On Sun, Dec 2, 2012 at 11:19 PM, Paul E. Jone= s <paulej@packetizer.com> wrote:

Where are you= suggesting this be placed exactly?=A0 Should we have a separate client or = library behavior section?

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 8:15 PM
To: Paul E. Jones<= br>Cc: ap= ps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Draft -07 mod proposal: HTTPS with fallback parameter

=A0

Change paragraph 2 of section 5.1 to read:

WebFinger client software MUST accept as input a boolean parameter whic= h for the purposes of this discussion will be referred as "allow-fallb= ack".=A0 If this parameter is not provided, client software MUST behav= e as if it were present with a value of false.

WebFinger client software MUST attempt to retrieve /.well-known/webfing= er using the HTTPS protocol.=A0 If an HTTPS connection is made, and the ser= ver has an invalid certificate, or returns an HTTP status code indicating a= n error, the client software MUST report an error and cease attempting to r= etrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connec= tion to the server, behavior depends on the value of the allow-fallback par= ameter.=A0 If the value of allow-fallback is true, the client software MAY = fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfin= ger.=A0 If allow-fallback is false, client software MUST report an error an= d cease attempting to retrieve the resource.


On Sun, Dec 2, 2012 a= t 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

I published another version of the W= ebFinger spec trying to bring closure to the two open issues I see (resourc= e representation and transport).=A0 The new version is here:<= /p>

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=A0=

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=A0 There are no ex= ternal references to RFC 6415 now, no need to go read the XRD spec, etc. = =A0It=92s a fairly simple format and I believe this text documents it suffi= ciently.=A0 Combined with the visual examples, I think this makes it pretty= clear.=A0 Have a look at the JRD documentation in section 5.2 and provide = your comments.

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)=

=A0

Paul

=A0


_____= __________________________________________
apps-discuss mailing list
= apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=A0


--14dae9399429a476b604cfedecbe-- From tbray@textuality.com Mon Dec 3 00:09:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FB021F886F for ; Mon, 3 Dec 2012 00:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECQw7LcRusse for ; Mon, 3 Dec 2012 00:09:57 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3F3C21F86B5 for ; Mon, 3 Dec 2012 00:09:56 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2410368obc.31 for ; Mon, 03 Dec 2012 00:09:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TiZHFPglCFCIqs/XQksvOfhL54SqSXFkTbgmQGBxXGw=; b=WWWpQty4xYVzkClTxdLOAkQV+I+Y93JRGuDZp0asLnnUPYq9GSTmgwuphG9/zPmowL i+09QY7Vj9MtBS5fDNWrTWG6bTsEjAKDGpMvGGek2MTHEE2YbzkksgX5bmKFoe7w1VoL VYe3IsADX7LxFPJ13E9Myb+7apE2VnZ9RaJoJzw3jKGwt1Wnv6tjk4pLuVzd5shbOqvo hY9kB2HCb+E8YVN/dHdu5ysEPga/JCMHiH6XPIKOiILGLLZuie7tQVXXhIKhMkqn3FaW 9eswXCTled7SXOsEE/Z+ultMdV1Y3qB6PjsE3WklOEb/aXDbNTI8FZ+rM/ABNK8Z8KCD WLkg== MIME-Version: 1.0 Received: by 10.182.47.66 with SMTP id b2mr3647166obn.34.1354522196265; Mon, 03 Dec 2012 00:09:56 -0800 (PST) Received: by 10.76.12.134 with HTTP; Mon, 3 Dec 2012 00:09:56 -0800 (PST) X-Originating-IP: [172.26.48.5] In-Reply-To: <092801cdd129$16b09cf0$4411d6d0$@packetizer.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> <092801cdd129$16b09cf0$4411d6d0$@packetizer.com> Date: Mon, 3 Dec 2012 00:09:56 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae93998cd5948f704cfee46d3 X-Gm-Message-State: ALoCoQkrukjJjP/m3ScB26QhgEw2AGcuoQkdJsE9snMJUpu47+2kIOu4O0jrTiq6qYz3Bmo+O97o Cc: Joseph Holsten , webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 08:09:58 -0000 --14dae93998cd5948f704cfee46d3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Possibly related and FWIW, I just set up https on my blog this weekend, see http://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS It was easy and cheap. Now I=92m waiting to discover the horrible problems and difficulties people keep talking about here. -T On Sun, Dec 2, 2012 at 11:37 PM, Paul E. Jones wrote= : > SNI is actually a real problem still and with the current WF spec, even > HTTP would not work since the text says that if we get a cert error, don= =92t > try HTTP.**** > > ** ** > > If we want to allow HTTP to work on sites that are running HTTPS for some > service, but not necessarily dedicated to the target domain, we will have > intermittent issues until such time as all client code properly supports > SNI.**** > > ** ** > > I mentioned before that there is a heck of a lot of client code out there > still that does not work with SNI. This will just take time. We either > have to just accept the failures or soften the text related to failures b= y > saying the response should be ignored and allow the client to use HTTP to > get a WF response. (Again, apps that depend on security may opt to not d= o > that.)**** > > ** ** > > Paul**** > > ** ** > > ** ** > > *From:* Nico Williams [mailto:nico@cryptonector.com] > *Sent:* Monday, December 03, 2012 12:11 AM > *To:* Dick Hardt > *Cc:* Nico Williams; Paul E. Jones; Joseph Holsten; > webfinger@googlegroups.com; apps-discuss@ietf.org > > *Subject:* Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP**** > > ** ** > > > > On Sunday, December 2, 2012, Dick Hardt wrote:**** > > > On Dec 2, 2012, at 8:56 PM, Nico Williams wrote: > > > On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt wrote= : > >> I agree there are many use cases where the security is not essential. > >> > >> My question was what do we lose by requiring TLS? > > > > Some hosting sites can't handle it well at all. Either they require > > server certs that can serve many domains or they require per-domain IP > > addresses because SNI is not well supported. > > Which sites? Are they critical to the successful deployment of WF? If WF > is successful, will they make it easier to deploy TLS? Perhaps HTTPS-only > will drive easier TLS support. That would seem to be a good thing.**** > > ** ** > > My domain's hosting site, for example. This is not about the hosting > site: it's about the incomplete deployment of TLS SNI.**** > > **** > > > > > Many clients don't do proper server cert validation. "I used TLS" !=3D > > "I got it securely". > > So we should not force HTTPS because some clients don't implement it > properly? Really?**** > > ** ** > > No, we should not mandate TLS if either we know that requirement will > often be ignored or if we're doing it because we think that gets use > "security". And if we do end up requiring TLS we need to say a lot more > about server certificate validation, about TLS cipher suites (e.g., no an= on > DH ones), and so on, about trust anchors (same as for web browsers?).**** > > **** > > > > >> There is a real latency and extra code in dealing with the fallback as > currently specified. > > > > But is that relevant here? > > I would think so. If the user is waiting for discovery to be finished, > latency is an issue. > Extra code is extra code and complexity and more to understand.**** > > ** ** > > I wouldn't worry about a line of code given TLS' complexity, which we'd b= e > requiring. The latency involved in one more fallback may well matter, bu= t > I'm not ready to conclude that it means we must require TLS because we > could still consider the alternative that the WF app/ user be the one to > decide whether to use TLS at all or not, without a fallback in either cas= e > (actually, I prefer this alternative).**** > > **** > > >> For example, we lose being able to use a simple CURL command to get a > JRD. > > > > So you need an if and two invocations of curl. > > So you agree it is more complicated. The agreed goal is to push complexit= y > to the server.**** > > ** ** > > Agreed by whom?**** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --14dae93998cd5948f704cfee46d3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Possibly related and FWIW, I just set up https on my blog this weekend, see= http:/= /www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS

It was easy an= d cheap. Now I=92m waiting to discover the horrible problems and difficulti= es people keep talking about here.=A0 -T

On Sun, Dec 2, 2012 at 11:37 PM, Paul E. Jon= es <paulej@packetizer.com> wrote:

SNI is actually a real problem still and wit= h the current WF spec, even HTTP would not work since the text says that if= we get a cert error, don=92t try HTTP.

=A0<= /p>

If we want to allow HT= TP to work on sites that are running HTTPS for some service, but not necess= arily dedicated to the target domain, we will have intermittent issues unti= l such time as all client code properly supports SNI.<= /p>

=A0<= /p>

I mentioned before tha= t there is a heck of a lot of client code out there still that does not wor= k with SNI.=A0 This will just take time.=A0 We either have to just accept t= he failures or soften the text related to failures by saying the response s= hould be ignored and allow the client to use HTTP to get a WF response.=A0 = (Again, apps that depend on security may opt to not do that.)=

=A0<= /p>

Paul

=A0<= /p>

=A0

From:= Nico Williams [mailto:nico@cryptonector.com]
Sent: Monday, December 03, 2012 12:11 AM
To: Dick HardtCc: Nico Williams; Paul E. Jones; Joseph Holsten; webfinger@googlegroups.com; apps-discuss= @ietf.org


Subject: Re: [apps-discuss] HTTPS-only vs HTTP= S-and-HTTP

= =A0


On Sunday, December 2, 2012, Dick Hardt wrote:


On Dec 2, 20= 12, at 8:56 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt <dick.hardt@gma= il.com> wrote:
>> I agree there are many use cases where the security is not essenti= al.
>>
>> My question was what do we lose by requiring TL= S?
>
> Some hosting sites can't handle it well at all. =A0E= ither they require
> server certs that can serve many domains or they require per-domain IP=
> addresses because SNI is not well supported.

Which sites? A= re they critical to the successful deployment of WF? If WF is successful, w= ill they make it easier to deploy TLS? Perhaps HTTPS-only will drive easier= TLS support. That would seem to be a good thing.

=A0

My domain's hosting site, for example. =A0This is not about the= hosting site: it's about the incomplete deployment of TLS SNI.<= u>

=A0

>
> M= any clients don't do proper server cert validation. =A0"I used TLS= " !=3D
> "I got it securely".

So we should not force HTTPS bec= ause some clients don't implement it properly? Really?

=A0

<= p class=3D"MsoNormal"> No, we should not mandate TLS if either we know that requirement will often= be ignored or if we're doing it because we think that gets use "s= ecurity". =A0And if we do end up requiring TLS we need to say a lot mo= re about server certificate validation, about TLS cipher suites (e.g., no a= non DH ones), and so on, about trust anchors (same as for web browsers?).

=A0

>
>&g= t; There is a real latency and extra code in dealing with the fallback as c= urrently specified.
>
> But is that relevant here?

I would think so. If the use= r is waiting for discovery to be finished, latency is an issue.
Extra co= de is extra code and complexity and more to understand.

=A0

I wouldn't worry about a line of code given TLS= 9; complexity, which we'd be requiring. =A0The latency involved in one = more fallback may well matter, but I'm not ready to conclude that it me= ans we must require TLS because we could still consider the alternative tha= t the WF app/ user be the one to decide whether to use TLS at all or not, w= ithout a fallback in either case (actually, I prefer this alternative).<= /u>

=A0

>> For e= xample, we lose being able to use a simple CURL command to get a JRD.
>
> So you need an if and two invocations of curl.

So you a= gree it is more complicated. The agreed goal is to push complexity to the s= erver.

=A0=

Agreed by whom?


___________________________________________= ____
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--14dae93998cd5948f704cfee46d3-- From paulej@packetizer.com Mon Dec 3 00:25:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7656D21F895E for ; Mon, 3 Dec 2012 00:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URY-a-nSprIz for ; Mon, 3 Dec 2012 00:25:34 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DEA8221F895D for ; Mon, 3 Dec 2012 00:25:33 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB38PW3U015719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 03:25:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354523132; bh=R4s7bvVv8mZMl+n/cT8/Un44qPImzBJbDiFTIpCL4Ak=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=g436PI7SYytuLF+2ZD9kl2uSa4QcioT9rt9z9jBk2CObbl9rGIoO4haid/WJSUGn6 sizemktPWTwA7WPXN9zwjADw6ekuGhst+7PUb6n3erFbmJkk28nNvYuja6eL/BfoOQ NT8C9eAt90mrd6DCT5QFgozPe91y4iylEonyb9l4= From: "Paul E. Jones" To: "'Tim Bray'" References: <091901cdd126$83d2b8c0$8b782a40$@packetizer.com> In-Reply-To: Date: Mon, 3 Dec 2012 03:25:31 -0500 Message-ID: <099c01cdd12f$c29d01b0$47d70510$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_099D_01CDD105.D9C7E410" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFle3OGxU84YUE6EJe9JiklLtNragI+x3PMAUa31m6YuzxO0A== Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 08:25:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_099D_01CDD105.D9C7E410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think we can write this without introducing the word "fallback". I'll just insert the text and figure out how to work it into that section, etc. But, we still need to settle on the HTTPS vs HTTP issue in general first. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Monday, December 03, 2012 2:45 AM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: Draft -07 mod proposal: HTTPS with fallback parameter Discretion of the editor. Assuming people are OK with the language. -T On Sun, Dec 2, 2012 at 11:19 PM, Paul E. Jones wrote: Where are you suggesting this be placed exactly? Should we have a separate client or library behavior section? From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, December 02, 2012 8:15 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Draft -07 mod proposal: HTTPS with fallback parameter Change paragraph 2 of section 5.1 to read: WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback". If this parameter is not provided, client software MUST behave as if it were present with a value of false. WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol. If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource. If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter. If the value of allow-fallback is true, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger. If allow-fallback is false, client software MUST report an error and cease attempting to retrieve the resource. On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_099D_01CDD105.D9C7E410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think we can write this without introducing the word = “fallback”.  I’ll just insert the text and figure = out how to work it into that section, etc.  But, we still need to = settle on the HTTPS vs HTTP issue in general = first.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Monday, December = 03, 2012 2:45 AM
To: Paul E. Jones
Cc: = apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: = Draft -07 mod proposal: HTTPS with fallback = parameter

 

Discretion of the editor. Assuming people = are OK with the language. -T

On = Sun, Dec 2, 2012 at 11:19 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Where are you suggesting this be placed exactly?  Should we have = a separate client or library behavior section?

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, = December 02, 2012 8:15 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: = Draft -07 mod proposal: HTTPS with fallback = parameter

 <= /o:p>

Change paragraph = 2 of section 5.1 to read:

WebFinger client software MUST accept = as input a boolean parameter which for the purposes of this discussion = will be referred as "allow-fallback".  If this parameter = is not provided, client software MUST behave as if it were present with = a value of false.

WebFinger client software MUST attempt to = retrieve /.well-known/webfinger using the HTTPS protocol.  If an = HTTPS connection is made, and the server has an invalid certificate, or = returns an HTTP status code indicating an error, the client software = MUST report an error and cease attempting to retrieve the = resource.

If the WebFinger client software is unable to establish = an HTTPS connection to the server, behavior depends on the value of the = allow-fallback parameter.  If the value of allow-fallback is true, = the client software MAY fall back to unencrypted HTTP in an attempt to = retrieve /.well-known/webfinger.  If allow-fallback is false, = client software MUST report an error and cease attempting to retrieve = the resource.

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07

 <= /o:p>

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc.  It’s = a fairly simple format and I believe this text documents it = sufficiently.  Combined with the visual examples, I think this = makes it pretty clear.  Have a look at the JRD documentation in = section 5.2 and provide your comments.

 <= /o:p>

With = respect to HTTPS, it seems there is strong preference for “HTTPS = only”, but some a fair bit of insistence for allowing HTTP.  = I changed the wording in 5.2 to try to capture opinions.  = Previously, the text led with a requirement to try HTTPS first.  = That is still there.  I just added some extra conditions that make = it clearer that there are some instances where a client must not utilize = HTTP.  This might need further refinement, but I think there is a = balance we can strike here between the two camps without introducing a = lot of complex language.

 <= /o:p>

I made some = editorial changes through the document.

 <= /o:p>

Comments = are welcome, as always.  Seems I don’t need to say that to = this group, though :-)

 

Paul

 


______________= _________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 <= /o:p>

 

------=_NextPart_000_099D_01CDD105.D9C7E410-- From paulej@packetizer.com Mon Dec 3 01:05:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A5321F865F for ; Mon, 3 Dec 2012 01:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wqBJWtzvb8P for ; Mon, 3 Dec 2012 01:05:27 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A826B21F86D2 for ; Mon, 3 Dec 2012 01:05:27 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB395NCE017375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 04:05:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354525524; bh=SQaEwkHQhsuiqNcAcGaae4x89XW3fZn/RyJ6TNzRCLU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=P2/vuMzdrhmpx7ESVzI+T3B3WEtxaHZMxFpiMLCRDMOnRmpMxmDs5xEoYhP+yaG/p 0gbhJnnLJCNqY/3c7XaFipGpgvPIlx6WZA2vwiiklITjcbKqBHdE4j4aia1rF78ONy UjGKKDqsnLOaBc5KKQAJ6LcyBRrk9Edd6wet/ghc= From: "Paul E. Jones" To: "'Tim Bray'" References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201c dd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> <092801cdd129$16b09cf0$4411d6d0$@packetizer.com> In-Reply-To: Date: Mon, 3 Dec 2012 04:05:23 -0500 Message-ID: <09e101cdd135$544bfb70$fce3f250$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09E2_01CDD10B.6B775300" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLrZ2Se+xCQ1wKSSFBTHovI4rJ73wIvNloxAedIuXAA9cPVgQKCxNrpAaoig/sCH1k1jwGrYWq2AipsKXMChR/lCwF99wDGAxHsnkIB0G8+1AJOdXLAAQVCTGcCX/geEwJruMg6Ak9z930Be2y3KQHdSOLdAgd9enkCTcSKcQHbGChbAsJUXfUCWrRBIAIpqoZ3At+Y5TMB2LTi9wGbBwU1k/5oy5A= Content-Language: en-us Cc: 'Joseph Holsten' , webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 09:05:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09E2_01CDD10B.6B775300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tim, I think Apache just added SNI support in 2.2.12 released in 2009, I think. One would also need OpenSSL 0.9.8f or newer. That was released in 2007, I think. It took a little time for those packages to find their way into Linux distributions, of course. I would assume all new Linux releases have this code. Many servers are still in operation that do not have the right software installed. On the client side, Windows XP still seems to lack support for SNI, I think. Not sure if that affects every browser, but it would affect a lot of software nonetheless. SNI is one issue. The other is cost. It can be cheap. Did you buy a wildcard certificate? Those are expensive. I'd like to have one, but I'm not going to pay for it. And did you get a one-year cert or 5 year? If one-year, then you can add the additional labor of swapping out certificates next year. Personally, I find this to be a pain. It's worth it for applications where I truly need it. But, there are applications where I don't. And while you're technically capable, there are some (many) who are not. I've purchased TLS certificates from three different companies. The process is somewhat painful, in my opinion. I can create my own self-signed certificate more easily. Way more easily. If you understand the language, you're OK. But, there are many who can set up a simple web site but get lost trying to get a certificate or figure out how to install it. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Monday, December 03, 2012 3:10 AM To: Paul E. Jones Cc: Nico Williams; Dick Hardt; apps-discuss@ietf.org; webfinger@googlegroups.com; Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Possibly related and FWIW, I just set up https on my blog this weekend, see http://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS It was easy and cheap. Now I'm waiting to discover the horrible problems and difficulties people keep talking about here. -T On Sun, Dec 2, 2012 at 11:37 PM, Paul E. Jones wrote: SNI is actually a real problem still and with the current WF spec, even HTTP would not work since the text says that if we get a cert error, don't try HTTP. If we want to allow HTTP to work on sites that are running HTTPS for some service, but not necessarily dedicated to the target domain, we will have intermittent issues until such time as all client code properly supports SNI. I mentioned before that there is a heck of a lot of client code out there still that does not work with SNI. This will just take time. We either have to just accept the failures or soften the text related to failures by saying the response should be ignored and allow the client to use HTTP to get a WF response. (Again, apps that depend on security may opt to not do that.) Paul From: Nico Williams [mailto:nico@cryptonector.com] Sent: Monday, December 03, 2012 12:11 AM To: Dick Hardt Cc: Nico Williams; Paul E. Jones; Joseph Holsten; webfinger@googlegroups.com; apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP On Sunday, December 2, 2012, Dick Hardt wrote: On Dec 2, 2012, at 8:56 PM, Nico Williams wrote: > On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt wrote: >> I agree there are many use cases where the security is not essential. >> >> My question was what do we lose by requiring TLS? > > Some hosting sites can't handle it well at all. Either they require > server certs that can serve many domains or they require per-domain IP > addresses because SNI is not well supported. Which sites? Are they critical to the successful deployment of WF? If WF is successful, will they make it easier to deploy TLS? Perhaps HTTPS-only will drive easier TLS support. That would seem to be a good thing. My domain's hosting site, for example. This is not about the hosting site: it's about the incomplete deployment of TLS SNI. > > Many clients don't do proper server cert validation. "I used TLS" != > "I got it securely". So we should not force HTTPS because some clients don't implement it properly? Really? No, we should not mandate TLS if either we know that requirement will often be ignored or if we're doing it because we think that gets use "security". And if we do end up requiring TLS we need to say a lot more about server certificate validation, about TLS cipher suites (e.g., no anon DH ones), and so on, about trust anchors (same as for web browsers?). > >> There is a real latency and extra code in dealing with the fallback as currently specified. > > But is that relevant here? I would think so. If the user is waiting for discovery to be finished, latency is an issue. Extra code is extra code and complexity and more to understand. I wouldn't worry about a line of code given TLS' complexity, which we'd be requiring. The latency involved in one more fallback may well matter, but I'm not ready to conclude that it means we must require TLS because we could still consider the alternative that the WF app/ user be the one to decide whether to use TLS at all or not, without a fallback in either case (actually, I prefer this alternative). >> For example, we lose being able to use a simple CURL command to get a JRD. > > So you need an if and two invocations of curl. So you agree it is more complicated. The agreed goal is to push complexity to the server. Agreed by whom? _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_09E2_01CDD10B.6B775300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim,

 

I think Apache just added SNI support in 2.2.12 released in 2009, I = think.  One would also need OpenSSL 0.9.8f or newer.  That was = released in 2007, I think.  It took a little time for those = packages to find their way into Linux distributions, of course.  I = would assume all new Linux releases have this code.  Many servers = are still in operation that do not have the right software = installed.

 

On the client side, Windows XP still seems to lack support for SNI, I = think.  Not sure if that affects every browser, but it would affect = a lot of software nonetheless.

 

SNI is one issue.  The other is cost.  It can be cheap. Did = you buy a wildcard certificate?  Those are expensive.  = I’d like to have one, but I’m not going to pay for it.  = And did you get a one-year cert or 5 year?  If one-year, then you = can add the additional labor of swapping out certificates next = year.  Personally, I find this to be a pain.  It’s worth = it for applications where I truly need it.  But, there are = applications where I don’t.

 

And while you’re technically capable, there are some (many) who = are not.  I’ve purchased TLS certificates from three = different companies.  The process is somewhat painful, in my = opinion.  I can create my own self-signed certificate more = easily.  Way more easily.  If you understand the language, = you’re OK.  But, there are many who can set up a simple web = site but get lost trying to get a certificate or figure out how to = install it.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Monday, December = 03, 2012 3:10 AM
To: Paul E. Jones
Cc: Nico = Williams; Dick Hardt; apps-discuss@ietf.org; webfinger@googlegroups.com; = Joseph Holsten
Subject: Re: [apps-discuss] HTTPS-only vs = HTTPS-and-HTTP

 

Possibly related and FWIW, I just set up = https on my blog this weekend, see http://w= ww.tbray.org/ongoing/When/201x/2012/12/02/HTTPS

It was easy = and cheap. Now I’m waiting to discover the horrible problems and = difficulties people keep talking about here.  = -T

On Sun, Dec 2, 2012 at 11:37 = PM, Paul E. Jones <paulej@packetizer.com> = wrote:

SNI is actually a real problem still and with the current WF spec, = even HTTP would not work since the text says that if we get a cert = error, don’t try HTTP.

 

If we want to allow HTTP to work on sites that are running HTTPS for = some service, but not necessarily dedicated to the target domain, we = will have intermittent issues until such time as all client code = properly supports SNI.

 

I mentioned before that there is a heck of a lot of client code out = there still that does not work with SNI.  This will just take = time.  We either have to just accept the failures or soften the = text related to failures by saying the response should be ignored and = allow the client to use HTTP to get a WF response.  (Again, apps = that depend on security may opt to not do that.)

 

Paul

 

 

From:= = Nico Williams [mailto:nico@cryptonector.com]
Sent: Monday, = December 03, 2012 12:11 AM
To: Dick Hardt
Cc: Nico = Williams; Paul E. Jones; Joseph Holsten; webfinger@googlegroups.com; apps-discuss@ietf.org


Subject: Re: [apps-discuss] HTTPS-only vs = HTTPS-and-HTTP

 <= /o:p>

 <= /o:p>


On Sunday, December 2, 2012, = Dick Hardt wrote:


On Dec = 2, 2012, at 8:56 PM, Nico Williams <nico@cryptonector.com> = wrote:

> On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:
>> I agree there are many use cases where the security = is not essential.
>>
>> My question was what do we = lose by requiring TLS?
>
> Some hosting sites can't handle = it well at all.  Either they require
> server certs that can = serve many domains or they require per-domain IP
> addresses = because SNI is not well supported.

Which sites? Are they critical = to the successful deployment of WF? If WF is successful, will they make = it easier to deploy TLS? Perhaps HTTPS-only will drive easier TLS = support. That would seem to be a good thing.

 <= /o:p>

My domain's = hosting site, for example.  This is not about the hosting site: = it's about the incomplete deployment of TLS = SNI.

 <= /o:p>

>
>= Many clients don't do proper server cert validation.  "I used = TLS" !=3D
> "I got it securely".

So we = should not force HTTPS because some clients don't implement it properly? = Really?

 <= /o:p>

No, we = should not mandate TLS if either we know that requirement will often be = ignored or if we're doing it because we think that gets use = "security".  And if we do end up requiring TLS we need to = say a lot more about server certificate validation, about TLS cipher = suites (e.g., no anon DH ones), and so on, about trust anchors (same as = for web browsers?).

 <= /o:p>

>
>= > There is a real latency and extra code in dealing with the fallback = as currently specified.
>
> But is that relevant = here?

I would think so. If the user is waiting for discovery to = be finished, latency is an issue.
Extra code is extra code and = complexity and more to understand.

 <= /o:p>

I wouldn't = worry about a line of code given TLS' complexity, which we'd be = requiring.  The latency involved in one more fallback may well = matter, but I'm not ready to conclude that it means we must require TLS = because we could still consider the alternative that the WF app/ user be = the one to decide whether to use TLS at all or not, without a fallback = in either case (actually, I prefer this = alternative).

 <= /o:p>

>> = For example, we lose being able to use a simple CURL command to get a = JRD.
>
> So you need an if and two invocations of = curl.

So you agree it is more complicated. The agreed goal is to = push complexity to the server.

 <= /o:p>

Agreed by = whom?


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_09E2_01CDD10B.6B775300-- From tbray@textuality.com Mon Dec 3 01:12:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614F321F890C for ; Mon, 3 Dec 2012 01:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOjB7W6++MX8 for ; Mon, 3 Dec 2012 01:12:37 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2F721F8809 for ; Mon, 3 Dec 2012 01:12:37 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2688467oag.31 for ; Mon, 03 Dec 2012 01:12:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=dW8YPVCsQpdEVOlOXtpmdpUqPOsQfewE61EX/WbKMzk=; b=Af44rgP/CTNqwNVx8uJgiVZ07L/yRoT2O2nCy64Xs0etNJtcCkDidYa6G3mdHyVNbe ZEVnsd382UTUFj19k7e3BmxS9DtTAcSU0h58RrDEcq3+nDRUauKk31jnH0VEAL00omhF KTpRGRNh3EIGPn+zMBSVNV5i3wKycYdE+jAWfFXt5whr4gBSkqB4Lthf83J2P4xLDHsG HHf9r8fREFsMmnEjuQQePh6ARh2jq9HXRU+aVzmRRJUwe7Y+F/tlbocsjIGdz32OxlT7 OkMpITlPZ6izQjqxA+w8dEfbYqJD2yalmXd8dylUEFiuoVRn2wCv+JjXivEhLBgmqPFN YTNQ== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr7415487oeb.24.1354525956605; Mon, 03 Dec 2012 01:12:36 -0800 (PST) Received: by 10.76.12.134 with HTTP; Mon, 3 Dec 2012 01:12:36 -0800 (PST) X-Originating-IP: [172.26.48.5] In-Reply-To: <09e101cdd135$544bfb70$fce3f250$@packetizer.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> <092801cdd129$16b09cf0$4411d6d0$@packetizer.com> <09e101cdd135$544bfb70$fce3f250$@packetizer.com> Date: Mon, 3 Dec 2012 01:12:36 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f4187b858304cfef26db X-Gm-Message-State: ALoCoQmGh0mA4P418KCbwi7T9JeZE5s24q6ndL7+XjCz969cHXisimsEOG2DtyYzvTXTBImPfgVh Cc: Joseph Holsten , webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 09:12:40 -0000 --e89a8fb1f4187b858304cfef26db Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I bought a wildcard for $90/year from cheapssls.com. Easy, straightforward, affordable, well-documented. Single-domain certs are now down below $10/year. -T On Mon, Dec 3, 2012 at 1:05 AM, Paul E. Jones wrote= : > Tim,**** > > ** ** > > I think Apache just added SNI support in 2.2.12 released in 2009, I > think. One would also need OpenSSL 0.9.8f or newer. That was released i= n > 2007, I think. It took a little time for those packages to find their wa= y > into Linux distributions, of course. I would assume all new Linux releas= es > have this code. Many servers are still in operation that do not have the > right software installed.**** > > ** ** > > On the client side, Windows XP still seems to lack support for SNI, I > think. Not sure if that affects every browser, but it would affect a lot > of software nonetheless.**** > > ** ** > > SNI is one issue. The other is cost. It can be cheap. Did you buy a > wildcard certificate? Those are expensive. I=92d like to have one, but = I=92m > not going to pay for it. And did you get a one-year cert or 5 year? If > one-year, then you can add the additional labor of swapping out > certificates next year. Personally, I find this to be a pain. It=92s wo= rth > it for applications where I truly need it. But, there are applications > where I don=92t.**** > > ** ** > > And while you=92re technically capable, there are some (many) who are not= . > I=92ve purchased TLS certificates from three different companies. The > process is somewhat painful, in my opinion. I can create my own > self-signed certificate more easily. Way more easily. If you understand > the language, you=92re OK. But, there are many who can set up a simple w= eb > site but get lost trying to get a certificate or figure out how to instal= l > it. **** > > ** ** > > Paul**** > > ** ** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Monday, December 03, 2012 3:10 AM > *To:* Paul E. Jones > *Cc:* Nico Williams; Dick Hardt; apps-discuss@ietf.org; > webfinger@googlegroups.com; Joseph Holsten > > *Subject:* Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP**** > > ** ** > > Possibly related and FWIW, I just set up https on my blog this weekend, > see http://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS > > It was easy and cheap. Now I=92m waiting to discover the horrible problem= s > and difficulties people keep talking about here. -T**** > > On Sun, Dec 2, 2012 at 11:37 PM, Paul E. Jones > wrote:**** > > SNI is actually a real problem still and with the current WF spec, even > HTTP would not work since the text says that if we get a cert error, don= =92t > try HTTP.**** > > **** > > If we want to allow HTTP to work on sites that are running HTTPS for some > service, but not necessarily dedicated to the target domain, we will have > intermittent issues until such time as all client code properly supports > SNI.**** > > **** > > I mentioned before that there is a heck of a lot of client code out there > still that does not work with SNI. This will just take time. We either > have to just accept the failures or soften the text related to failures b= y > saying the response should be ignored and allow the client to use HTTP to > get a WF response. (Again, apps that depend on security may opt to not d= o > that.)**** > > **** > > Paul**** > > **** > > **** > > *From:* Nico Williams [mailto:nico@cryptonector.com] > *Sent:* Monday, December 03, 2012 12:11 AM > *To:* Dick Hardt > *Cc:* Nico Williams; Paul E. Jones; Joseph Holsten; > webfinger@googlegroups.com; apps-discuss@ietf.org**** > > > *Subject:* Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP**** > > **** > > ** ** > > > On Sunday, December 2, 2012, Dick Hardt wrote:**** > > > On Dec 2, 2012, at 8:56 PM, Nico Williams wrote: > > > On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt wrote= : > >> I agree there are many use cases where the security is not essential. > >> > >> My question was what do we lose by requiring TLS? > > > > Some hosting sites can't handle it well at all. Either they require > > server certs that can serve many domains or they require per-domain IP > > addresses because SNI is not well supported. > > Which sites? Are they critical to the successful deployment of WF? If WF > is successful, will they make it easier to deploy TLS? Perhaps HTTPS-only > will drive easier TLS support. That would seem to be a good thing.**** > > **** > > My domain's hosting site, for example. This is not about the hosting > site: it's about the incomplete deployment of TLS SNI.**** > > **** > > > > > Many clients don't do proper server cert validation. "I used TLS" !=3D > > "I got it securely". > > So we should not force HTTPS because some clients don't implement it > properly? Really?**** > > **** > > No, we should not mandate TLS if either we know that requirement will > often be ignored or if we're doing it because we think that gets use > "security". And if we do end up requiring TLS we need to say a lot more > about server certificate validation, about TLS cipher suites (e.g., no an= on > DH ones), and so on, about trust anchors (same as for web browsers?).**** > > **** > > > > >> There is a real latency and extra code in dealing with the fallback as > currently specified. > > > > But is that relevant here? > > I would think so. If the user is waiting for discovery to be finished, > latency is an issue. > Extra code is extra code and complexity and more to understand.**** > > **** > > I wouldn't worry about a line of code given TLS' complexity, which we'd b= e > requiring. The latency involved in one more fallback may well matter, bu= t > I'm not ready to conclude that it means we must require TLS because we > could still consider the alternative that the WF app/ user be the one to > decide whether to use TLS at all or not, without a fallback in either cas= e > (actually, I prefer this alternative).**** > > **** > > >> For example, we lose being able to use a simple CURL command to get a > JRD. > > > > So you need an if and two invocations of curl. > > So you agree it is more complicated. The agreed goal is to push complexit= y > to the server.**** > > **** > > Agreed by whom?**** > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > ** ** > --e89a8fb1f4187b858304cfef26db Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I bought a wildcard for $90/year from chea= pssls.com.=A0 Easy, straightforward, affordable, well-documented. Singl= e-domain certs are now down below $10/year.

=A0-T

On Mon, Dec 3, 2012 at 1:05 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Tim,

=A0

I think Apache just added SNI support in 2.2.= 12 released in 2009, I think.=A0 One would also need OpenSSL 0.9.8f or newe= r.=A0 That was released in 2007, I think.=A0 It took a little time for thos= e packages to find their way into Linux distributions, of course.=A0 I woul= d assume all new Linux releases have this code.=A0 Many servers are still i= n operation that do not have the right software installed.

=A0<= /p>

On the client side, Wi= ndows XP still seems to lack support for SNI, I think.=A0 Not sure if that = affects every browser, but it would affect a lot of software nonetheless.

=A0<= /p>

SNI is one issue.=A0 T= he other is cost.=A0 It can be cheap. Did you buy a wildcard certificate?= =A0 Those are expensive.=A0 I=92d like to have one, but I=92m not going to = pay for it.=A0 And did you get a one-year cert or 5 year?=A0 If one-year, t= hen you can add the additional labor of swapping out certificates next year= .=A0 Personally, I find this to be a pain.=A0 It=92s worth it for applicati= ons where I truly need it.=A0 But, there are applications where I don=92t.<= u>

=A0<= /p>

And while you=92re tec= hnically capable, there are some (many) who are not.=A0 I=92ve purchased TL= S certificates from three different companies.=A0 The process is somewhat p= ainful, in my opinion.=A0 I can create my own self-signed certificate more = easily.=A0 Way more easily.=A0 If you understand the language, you=92re OK.= =A0 But, there are many who can set up a simple web site but get lost tryin= g to get a certificate or figure out how to install it.

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Monday, December 03, 2012 3:10 AM
To: Paul E. Jones<= br>Cc: Nico Williams; Dick Hardt; apps-discuss@ietf.org; webfinger@googlegroups.com; Jo= seph Holsten


Subject: Re: [apps-discuss] HTTPS-only vs= HTTPS-and-HTTP

=A0

Possibly related and FWIW, I just set up https on my blog this weekend, see= http://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS

It was easy and cheap. Now I=92m waiting to discover the horrible probl= ems and difficulties people keep talking about here.=A0 -T

On Sun, Dec 2, 2012 at 11:37 PM, Paul E. Jones= <paulej@pack= etizer.com> wrote:

SNI is actually= a real problem still and with the current WF spec, even HTTP would not wor= k since the text says that if we get a cert error, don=92t try HTTP.=

=A0<= /p>

If we want to allow HT= TP to work on sites that are running HTTPS for some service, but not necess= arily dedicated to the target domain, we will have intermittent issues unti= l such time as all client code properly supports SNI.<= /p>

=A0<= /p>

I mentioned before tha= t there is a heck of a lot of client code out there still that does not wor= k with SNI.=A0 This will just take time.=A0 We either have to just accept t= he failures or soften the text related to failures by saying the response s= hould be ignored and allow the client to use HTTP to get a WF response.=A0 = (Again, apps that depend on security may opt to not do that.)=

=A0<= /p>

Paul<= /u>

=A0<= /p>

=A0

From:= Nico Williams [mailto:nico@cryptonector.com]
Sent: Monday, December 03, 2012 12:11 AM
To: Dick HardtCc: Nico Williams; Paul E. Jones; Joseph Holsten; webfinger@googlegroups.com; apps-discuss= @ietf.org


Subject: Re: [apps-discuss] HTTPS-on= ly vs HTTPS-and-HTTP

=A0

=A0

<= div>


On Sunday, December 2, 2012, Dick Hardt wrote:

<= /div>


On Dec 2, 2012, at 8:56 PM, Nico = Williams <nic= o@cryptonector.com> wrote:

> On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:<= br>>> I agree there are many use cases where the security is not esse= ntial.
>>
>> My question was what do we lose by requiring TLS?
&= gt;
> Some hosting sites can't handle it well at all. =A0Either t= hey require
> server certs that can serve many domains or they requir= e per-domain IP
> addresses because SNI is not well supported.

Which sites? Are t= hey critical to the successful deployment of WF? If WF is successful, will = they make it easier to deploy TLS? Perhaps HTTPS-only will drive easier TLS= support. That would seem to be a good thing.

=A0

My domain's hosting site, for example. =A0This is not about the= hosting site: it's about the incomplete deployment of TLS SNI.<= u>

=A0

=

>
> Many clients don't do proper server cert validation. =A0&q= uot;I used TLS" !=3D
> "I got it securely".

So = we should not force HTTPS because some clients don't implement it prope= rly? Really?

=A0

No, we should not mandate TLS if either we know that r= equirement will often be ignored or if we're doing it because we think = that gets use "security". =A0And if we do end up requiring TLS we= need to say a lot more about server certificate validation, about TLS ciph= er suites (e.g., no anon DH ones), and so on, about trust anchors (same as = for web browsers?).

=A0

=

>
>> There is a real latency and extra code in dealing with the= fallback as currently specified.
>
> But is that relevant here= ?

I would think so. If the user is waiting for discovery to be finis= hed, latency is an issue.
Extra code is extra code and complexity and more to understand.

=A0

<= div>

I wouldn't worry about a line of code given = TLS' complexity, which we'd be requiring. =A0The latency involved i= n one more fallback may well matter, but I'm not ready to conclude that= it means we must require TLS because we could still consider the alternati= ve that the WF app/ user be the one to decide whether to use TLS at all or = not, without a fallback in either case (actually, I prefer this alternative= ).

=A0

=

>> For example, we lose being able to use a simple CURL command to ge= t a JRD.
>
> So you need an if and two invocations of curl.
=
So you agree it is more complicated. The agreed goal is to push complex= ity to the server.

=A0

Agreed by whom?


__= _____________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailma= n/listinfo/apps-discuss

=A0

<= /div>

--e89a8fb1f4187b858304cfef26db-- From duerst@it.aoyama.ac.jp Mon Dec 3 01:56:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E5721F841A for ; Mon, 3 Dec 2012 01:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.575 X-Spam-Level: X-Spam-Status: No, score=-101.575 tagged_above=-999 required=5 tests=[AWL=1.215, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_BACKHAIR_55=1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hkf1m6E34w6 for ; Mon, 3 Dec 2012 01:56:14 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3FB21F841B for ; Mon, 3 Dec 2012 01:56:14 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id qB39u4We011894 for ; Mon, 3 Dec 2012 18:56:06 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 3bde_073c_a6a90e74_3d2f_11e2_8511_001d096c5782; Mon, 03 Dec 2012 18:56:03 +0900 Received: from [IPv6:::1] ([133.2.210.1]:42475) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 3 Dec 2012 18:56:04 +0900 Message-ID: <50BC7732.6090703@it.aoyama.ac.jp> Date: Mon, 03 Dec 2012 18:56:02 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> <092801cdd129$16b09cf0$4411d6d0$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org, webfinger@googlegroups.com, Joseph Holsten Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 09:56:18 -0000 On 2012/12/03 17:09, Tim Bray wrote: > Possibly related and FWIW, I just set up https on my blog this weekend, see > http://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS Great! (as the person who suggested it, I'm glad to see it worked out) But shouldn't that be https://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS ? ^ As for the actual issue at hand, my preference would be to allow both HTTPS and HTTP. (Just because Tim Bray says it's easy doesn't mean that everybody will get it right :-). Regards, Martin. > It was easy and cheap. Now I’m waiting to discover the horrible problems > and difficulties people keep talking about here. -T > > On Sun, Dec 2, 2012 at 11:37 PM, Paul E. Joneswrote: > >> SNI is actually a real problem still and with the current WF spec, even >> HTTP would not work since the text says that if we get a cert error, don’t >> try HTTP.**** >> >> ** ** >> >> If we want to allow HTTP to work on sites that are running HTTPS for some >> service, but not necessarily dedicated to the target domain, we will have >> intermittent issues until such time as all client code properly supports >> SNI.**** >> >> ** ** >> >> I mentioned before that there is a heck of a lot of client code out there >> still that does not work with SNI. This will just take time. We either >> have to just accept the failures or soften the text related to failures by >> saying the response should be ignored and allow the client to use HTTP to >> get a WF response. (Again, apps that depend on security may opt to not do >> that.)**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> ** ** >> >> *From:* Nico Williams [mailto:nico@cryptonector.com] >> *Sent:* Monday, December 03, 2012 12:11 AM >> *To:* Dick Hardt >> *Cc:* Nico Williams; Paul E. Jones; Joseph Holsten; >> webfinger@googlegroups.com; apps-discuss@ietf.org >> >> *Subject:* Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP**** >> >> ** ** >> >> >> >> On Sunday, December 2, 2012, Dick Hardt wrote:**** >> >> >> On Dec 2, 2012, at 8:56 PM, Nico Williams wrote: >> >>> On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt wrote: >>>> I agree there are many use cases where the security is not essential. >>>> >>>> My question was what do we lose by requiring TLS? >>> >>> Some hosting sites can't handle it well at all. Either they require >>> server certs that can serve many domains or they require per-domain IP >>> addresses because SNI is not well supported. >> >> Which sites? Are they critical to the successful deployment of WF? If WF >> is successful, will they make it easier to deploy TLS? Perhaps HTTPS-only >> will drive easier TLS support. That would seem to be a good thing.**** >> >> ** ** >> >> My domain's hosting site, for example. This is not about the hosting >> site: it's about the incomplete deployment of TLS SNI.**** >> >> **** >> >>> >>> Many clients don't do proper server cert validation. "I used TLS" != >>> "I got it securely". >> >> So we should not force HTTPS because some clients don't implement it >> properly? Really?**** >> >> ** ** >> >> No, we should not mandate TLS if either we know that requirement will >> often be ignored or if we're doing it because we think that gets use >> "security". And if we do end up requiring TLS we need to say a lot more >> about server certificate validation, about TLS cipher suites (e.g., no anon >> DH ones), and so on, about trust anchors (same as for web browsers?).**** >> >> **** >> >>> >>>> There is a real latency and extra code in dealing with the fallback as >> currently specified. >>> >>> But is that relevant here? >> >> I would think so. If the user is waiting for discovery to be finished, >> latency is an issue. >> Extra code is extra code and complexity and more to understand.**** >> >> ** ** >> >> I wouldn't worry about a line of code given TLS' complexity, which we'd be >> requiring. The latency involved in one more fallback may well matter, but >> I'm not ready to conclude that it means we must require TLS because we >> could still consider the alternative that the WF app/ user be the one to >> decide whether to use TLS at all or not, without a fallback in either case >> (actually, I prefer this alternative).**** >> >> **** >> >>>> For example, we lose being able to use a simple CURL command to get a >> JRD. >>> >>> So you need an if and two invocations of curl. >> >> So you agree it is more complicated. The agreed goal is to push complexity >> to the server.**** >> >> ** ** >> >> Agreed by whom?**** >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From markus.lanthaler@gmx.net Mon Dec 3 02:33:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A19D21F869E for ; Mon, 3 Dec 2012 02:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.075 X-Spam-Level: X-Spam-Status: No, score=-1.075 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-MRYSV2sjYj for ; Mon, 3 Dec 2012 02:33:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8326B21F869C for ; Mon, 3 Dec 2012 02:33:53 -0800 (PST) Received: (qmail invoked by alias); 03 Dec 2012 10:33:44 -0000 Received: from unknown (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp019) with SMTP; 03 Dec 2012 11:33:44 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX184Bl1Xh404rgqwyF+tunlpQVFlXfN2vSfUyAAzaH b4WNvQG8uqQUqQ From: "Markus Lanthaler" To: "'Tim Bray'" , "'Paul E. Jones'" References: In-Reply-To: Date: Mon, 3 Dec 2012 11:33:40 +0100 Message-ID: <01d301cdd141$aaaf7f80$000e7e80$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3Q851mSn9mb4FDQG6y1aLwde5SgwATa/0w Content-Language: de X-Y-GMX-Trusted: 0 Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: Remove top-level "properties" in JRD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 10:33:54 -0000 Tim, I=92m not sure I understand what you are proposing. Is it a) remove = properties completely, i.e., there=92s no way to express properties in a JRD = document or b) move those properties to the =93links=94 object and express them by = using link relations as property names? Cheers, Markus ---- From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Tim Bray Sent: Monday, December 03, 2012 2:15 AM To: Paul E. Jones Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Subject: [apps-discuss] Draft -07 mod proposal: Remove top-level "properties" in JRD This is actively harmful.=A0 Link relations are an excellent way to = express properties of a resource, and having two competing mechanisms will = distract developers and hurt interoperability. Proposal: 1. Introduction: s/link relations, properties,=A0 titles/link relations, titles/ 3. Overview: same 4.1 remove "properties:" member of JRD 4.1 last para s/and properties// 4.2 remove "properties:" member of JRD 4.2 s/any aliases and properties/any aliases/ 4.3 remove "properties" top-level member of JRD 5.2 remove "properties" from bullet list after 1st para 5.2 s/"properties" is an object comprised of name/value pairs whose = values are strings// 5.2.4 Remove section 5.3 example, remove top-level "properties" member 5.4 s/and properties// On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote: Folks, =A0 I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and transport).=A0 = The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 =A0 With respect to resource representation, I fully described the JSON = Resource Descriptor within the document.=A0 There are no external references to = RFC 6415 now, no need to go read the XRD spec, etc. =A0It=92s a fairly = simple format and I believe this text documents it sufficiently.=A0 Combined with the = visual examples, I think this makes it pretty clear.=A0 Have a look at the JRD documentation in section 5.2 and provide your comments.=20 =A0 With respect to HTTPS, it seems there is strong preference for =93HTTPS = only=94, but some a fair bit of insistence for allowing HTTP.=A0 I changed the = wording in 5.2 to try to capture opinions.=A0 Previously, the text led with a requirement to try HTTPS first.=A0 That is still there.=A0 I just added = some extra conditions that make it clearer that there are some instances = where a client must not utilize HTTP.=A0 This might need further refinement, but = I think there is a balance we can strike here between the two camps = without introducing a lot of complex language. =A0 I made some editorial changes through the document. =A0 Comments are welcome, as always.=A0 Seems I don=92t need to say that to = this group, though :-) =A0 Paul =A0 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From john-ietf@jck.com Mon Dec 3 03:48:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0E421F8500 for ; Mon, 3 Dec 2012 03:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJVJru8wILg2 for ; Mon, 3 Dec 2012 03:48:32 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1064D21F8479 for ; Mon, 3 Dec 2012 03:48:32 -0800 (PST) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TfUVj-0000vi-0H for apps-discuss@ietf.org; Mon, 03 Dec 2012 06:48:31 -0500 Date: Mon, 03 Dec 2012 06:48:25 -0500 From: John C Klensin To: apps-discuss@ietf.org Message-ID: <2BD6CE37760538020CEE52FF@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [apps-discuss] Enough from Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 11:48:32 -0000 Hi. Having just received another huge batch of specialized webfinger correspondence over the weekend, most of which couldn't even bother to be identified sufficiently by draft or topic to enable easy filtering, I'm unsubscribing from apps-discuss. Someone might let me (and the others I assume have departed for other reasons) know when this is over and the list is back to being used for other topics. john From jan.algermissen@nordsc.com Mon Dec 3 03:49:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9E521F8704 for ; Mon, 3 Dec 2012 03:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EV8-kUNRYIn for ; Mon, 3 Dec 2012 03:49:33 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1A921F8479 for ; Mon, 3 Dec 2012 03:49:32 -0800 (PST) Received: from [192.168.2.111] (p548FB142.dip.t-dialin.net [84.143.177.66]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MWLRl-1Ti3ko1VjV-00XWrY; Mon, 03 Dec 2012 12:49:31 +0100 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 3 Dec 2012 12:49:30 +0100 To: apps-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:slJ8dA97kHUNoWQ7+j3xzwBf7KrrPDvZNS2Y0vvagHi KALt+7B+SdBuvyXFGX6uSctsQeDj5FekoTqCUCCfc7sO+Ny98V rWNPDbH5SqIYSGsSRhq+DoIlrfO3pRUQTchI4uT6r5dJtHMaHn kHj6MPtoArKZC18G8LkceV/ruGO3B+DuWZ+YuVs8Okswiaxcfz sWOnEpzK48RBO+zt/s4pyVaXuSd+OU74jrdlB5Kow70JT9VarH pvDb9DxZ00V2Bj1k6wPuOGUwV6sTOdigeVZ5hlUpNkZDtIN9Rn O4WuhnCpiyavmHaWiiRRaLqld/tMxssIN63WLQRrJPcul4MWL1 +ihAnjF7G7AcF2/aM9NRK/+zMVedGwZfqQNGeHuW9V8nCIG6n4 EGSPiscaB24cg== Subject: [apps-discuss] Link relation type for home documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 11:49:33 -0000 Hi Mark, I maybe have a use case where a client would need to be informed at = runtime where a service's/server's home document is. Do you have a link rel on your mind for that purpose? What about = re-using 'service'? Or maybe define a new one: 'home'? Jan From ve7jtb@ve7jtb.com Mon Dec 3 05:00:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD8621F873E for ; Mon, 3 Dec 2012 05:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9Twe4Or+huy for ; Mon, 3 Dec 2012 05:00:56 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEA4A21F873B for ; Mon, 3 Dec 2012 05:00:53 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so406360ggn.31 for ; Mon, 03 Dec 2012 05:00:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=HC3pQOBARH7f55SMpC665nSIYSDJKZ0hPwyHRAZweLE=; b=EKMszC2WNMowIdO1YggYLpj6kZhoVnn6EiMPCdY+RIrzmu97pKdWGkFzEcKbHDtmDv bYAZ7N83CNqgVezUcUFNLpmZNc85M9N1/Zs2nl42FbVi9vjLLGBrcGUMTii2w7mH7YOS WWDXCnQOogO5xwU7Oz1t+oqZ4CzULKHr2oNzADswEr6kHh+2+nbqO4S+VCGYJOIdOddQ LRNEPm4keNz6HFaJXHIfjIWBgTWPGOXDhBpfHDSJqzZCo5+NWCUgF4tO0PrAIBeqdJAF hpKU/ViTRpDvkiykhyWwidPsU5JLypKrYnj+FBh/TNPf/ZMGBZXW6Llx/hmnBTBU1H4I 9+BQ== Received: by 10.236.146.239 with SMTP id r75mr10235782yhj.100.1354539652853; Mon, 03 Dec 2012 05:00:52 -0800 (PST) Received: from [192.168.1.211] (190-20-29-186.baf.movistar.cl. [190.20.29.186]) by mx.google.com with ESMTPS id j8sm11462968ank.21.2012.12.03.05.00.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 05:00:51 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AED180A8-59AB-46DF-A719-6B2C0DC0190F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <50BC3AF5.2080507@cisco.com> Date: Mon, 3 Dec 2012 10:00:34 -0300 Message-Id: <25A482B0-90AE-402E-93B7-5F964FB06107@ve7jtb.com> References: <50BC3AF5.2080507@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnQdV/PVyUgKTHMVQNqnGKk3sBTmPZOnlKrBu65BwYF0JzVEF9Yxg+S4JPfwQis98eCwiFz Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:00:56 -0000 --Apple-Mail=_AED180A8-59AB-46DF-A719-6B2C0DC0190F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I added Web Finger to the subject to make filtering easier for those = that want to not see this. Enterprises that are acting as their own CA install there signing = certificates in the clients certificate store to prevent browser = warnings now. I don't see how this makes that situation any better or worse. True if = a enterprise is it's own CA third parties going to that site for WF will = have to install the root cert anyway. A concrete example of that would be MITRE who sign their own = certificates for security reasons rather cost. I expect for security = that they would not be allowed to do non TLS web-finger. They will have a issue that they need to solve independent of whether = TLS is mandatory in the spec. The simplest solution is to not use a certificate from a CA that is not = part of the default certificate store if you want the public to come to = your site and read your WF documents. I think most people know that already. I don't think the enterprise example really holds water, they are the = people most likely to get a commercial vert if they are dealing with the = public. (MITRE has a different audience who's names I can't speak) John B. On 2012-12-03, at 2:39 AM, Eliot Lear wrote: > Department of "here we go again". >=20 > TLS does not require security on its own. Making mandatory use of it = requires a signed certificate. Self-signed certs are common in = enterprise (and other environments). One of the examples given in the = draft (4.3 email client) is a classic enterprise configuration matter. = And so what this would do is force more nags at the user about untrusted = certificates. Worse=96 some email clients (in the given example) may = not handle that warning well. >=20 > So on the whole, I'd oppose any sort of language like the below. It's = too strong, and eliminates webfinger from serious consideration within = the enterprise. >=20 > Eliot >=20 > On 12/3/12 2:15 AM, Tim Bray wrote: >> Proposal: Change para 2 of section 5.2 to read as follows: >>=20 >> Clients MUST query the server using HTTPS. If an HTTPS connection = cannot be established, or returns an HTTP status code indicating some = error, such as 4xx or 5xx, the client MUST report an error and MUST = cease attempting to retrieve the resource. >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_AED180A8-59AB-46DF-A719-6B2C0DC0190F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 lear@cisco.com> = wrote:
=20 =20
Department of "here we go again".

TLS does not require security on its own.  Making mandatory use = of it requires a signed certificate.  Self-signed certs are common = in enterprise (and other environments).  One of the examples given = in the draft (4.3 email client) is a classic enterprise configuration matter.  And so what this would do is force more nags at the = user about untrusted certificates.  Worse=96 some email clients (in = the given example) may not handle that warning well.

So on the whole, I'd oppose any sort of language like the = below.  It's too strong, and eliminates webfinger from serious consideration within the enterprise.

Eliot

On 12/3/12 2:15 AM, Tim Bray = wrote:
Proposal: Change para 2 of section 5.2 to read as follows:

Clients MUST query the server using HTTPS. If an HTTPS connection cannot be established, or returns an HTTP status code indicating some error, such as 4xx or 5xx, the client MUST report an error and MUST cease attempting to retrieve the resource.



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ie=
tf.org/mailman/listinfo/apps-discuss

_______________________________________________
apps-discuss mailing = list
apps-discuss@ietf.org
https:/= /www.ietf.org/mailman/listinfo/apps-discuss

= --Apple-Mail=_AED180A8-59AB-46DF-A719-6B2C0DC0190F-- From ve7jtb@ve7jtb.com Mon Dec 3 05:11:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D545121F846B for ; Mon, 3 Dec 2012 05:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGmEtswBpHAS for ; Mon, 3 Dec 2012 05:11:13 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5E8121F8231 for ; Mon, 3 Dec 2012 05:11:11 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id r14so411924yen.31 for ; Mon, 03 Dec 2012 05:11:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=QkSOcHv2HLeaXfR138J4JrlHpSwy+YnZRlSNINTTJ/I=; b=CwOR7PyHeywITSj/0JbAZ/hY0COpuOxwA6IcUvw11F1uzCC1cMLfmVDIVuBuC8jaXQ X5rAqWegHhN04zdn1bufKNj81gvkcsOFA+/V4+Sw2fQ3NhspeOBQZX40OdNJt8yzZfrW gkO1U8SxIA4w8KiE/mcSzJf73FvGXPh9c8ZrRykngmYrflulbKHuT7oOsCrFBdMgjKhB xRSHo/eX8DYpie2phXoAeSuuQfTArO/t71Om4FUhMPVDXrz4jIFP8ytOo0kbKxtCeCB8 NRAr/qu5mC03HF5iJb/vvY63cqZKafhRVaqAs7mM0gG4QDrqQ0vqdI5Cid3is6ZaPKW+ xSag== Received: by 10.236.130.199 with SMTP id k47mr10016277yhi.126.1354540270983; Mon, 03 Dec 2012 05:11:10 -0800 (PST) Received: from [192.168.1.211] (190-20-29-186.baf.movistar.cl. [190.20.29.186]) by mx.google.com with ESMTPS id t46sm12970941yhi.3.2012.12.03.05.11.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 05:11:09 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_172A2D46-0082-4D62-A9EA-AA175C95781B" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> Date: Mon, 3 Dec 2012 10:11:01 -0300 Message-Id: References: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkM8L787JKLp27p72HFjMLW067TjODtFGarhMtv552UO6G6EqDGk4ACtYvfV4lB6gnE5KoZ Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:11:15 -0000 --Apple-Mail=_172A2D46-0082-4D62-A9EA-AA175C95781B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Added Web Finger to subject for the inocent. I would change that to: > =93The value of the "subject" member is a string whose value is = advisory and normally would be expected to be equivalent to the value of = the "resource" parameter in the client request. The "subject" = identifies the entity to which the JRD claims to describe.=94 The subject is self asserted saying that it is defiantly the ting that = the JRD describes will lead to applications making mistakes. The = subject is the thing that the JRD claims to be about. It is more likely = to be about the thing you did the query on. If they differ the client = should understand that the query parameter is the stronger binding. If we go in on the acct: URI then I would be tempted to say that the = value SHOULD be the normalized acct: uri for the thing you are asking = about. That is likely more useful information to the client. John B. On 2012-12-03, at 4:16 AM, "Paul E. Jones" = wrote: > Tim, > =20 > Yeah, I can appreciate that. However, I would like to suggest some = slightly different wording. How is this for the first paragraph in = 5.2.2? > =20 > =93The value of the "subject" member is a string whose value is = advisory and normally would be expected to be equivalent to the value of = the "resource" parameter in the client request. The "subject" = identifies the entity to which the JRD describes.=94 > =20 > Paul > =20 > =20 > From: Tim Bray [mailto:tbray@textuality.com]=20 > Sent: Sunday, December 02, 2012 8:15 PM > To: Paul E. Jones > Cc: apps-discuss@ietf.org; webfinger@googlegroups.com > Subject: Draft -07 mod proposal: Clean up "subject" > =20 > Right now, section 5.2.2 says "The value of the "subject" member is a = string that MUST be set to the same value as the "resource" parameter in = the client request. " >=20 > This is a recipe for trouble, for a couple of reasons. First of all, = what does =93the same value=94 mean? Go visit RFC3986, section 6, and = enjoy several hundred words walking through all the issues that arise in = trying to figure out when two URIs are equivalent, ranging from exact = character-by-character identity to all sorts of protocol-specific goo. = You are just one level of case-sensitivity-in-%-escaping from a big = hairy false negative. >=20 > I=92m also worried about a lack of flexibility. I might have a single = webfinger resource that declares a bunch of link relations for a bunch = of different resources. This section, as written, wouldn=92t let me do = that. >=20 > Proposal: Re-write section 5.2.2 as follows: >=20 > <<<<<<< > The value of the "subject" member is a string whose value is advisory, = identifying the resource to which the properties given in the "links" = member apply. Normally this would be expected to be equivalent to the = value of the "resource" parameter in the client request.=20 > <<<<<<< >=20 > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: > Folks, > =20 > I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 > =20 > With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. It=92s = a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments. > =20 > With respect to HTTPS, it seems there is strong preference for =93HTTPS = only=94, but some a fair bit of insistence for allowing HTTP. I changed = the wording in 5.2 to try to capture opinions. Previously, the text led = with a requirement to try HTTPS first. That is still there. I just = added some extra conditions that make it clearer that there are some = instances where a client must not utilize HTTP. This might need further = refinement, but I think there is a balance we can strike here between = the two camps without introducing a lot of complex language. > =20 > I made some editorial changes through the document. > =20 > Comments are welcome, as always. Seems I don=92t need to say that to = this group, though :-) > =20 > Paul > =20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 --Apple-Mail=_172A2D46-0082-4D62-A9EA-AA175C95781B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Added Web = Finger to subject for the inocent.

I would change = that to:

=93The value of the "subject" member is a string whose value = is advisory and normally would be expected to be equivalent to the value = of the "resource" parameter in the client request.  The "subject" = identifies the entity to which the JRD claims to = describe.=94

The subject is self asserted saying that it is = defiantly the ting that the JRD describes will lead to applications = making mistakes.   The subject is the thing that the JRD claims to = be about.  It is more likely to be about the thing you did the = query on.   If they differ the client should understand that the = query parameter is the stronger binding.

If we go in on the acct: URI then I = would be tempted to say that the value SHOULD be the normalized acct: = uri for the thing you are asking about.  That is likely more useful = information to the client.

John B.


On 2012-12-03, at 4:16 AM, "Paul E. = Jones" <paulej@packetizer.com> = wrote:

Tim,
 
Yeah, I can appreciate that.  = However, I would like to suggest some slightly different wording.  = How is this for the first paragraph in 5.2.2?
 
=93The value = of the "subject" member is a string whose value is advisory and normally = would be expected to be equivalent to the value of the "resource" = parameter in the client request.  The "subject" identifies the = entity to which the JRD describes.=94
 
Paul
 
 
From: Tim Bray [mailto:tbray@textuality.com] 
Sent: Sunday, December 02, 2012 = 8:15 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com<= br class=3D"">Subject: Draft -07 mod proposal: = Clean up "subject"
 

Right now, section 5.2.2 says "The = value of the "subject" member is a string that MUST be set to the same = value as the "resource" parameter in the client request. "

This is a recipe for trouble, for a couple of = reasons. First of all, what does =93the same value=94 mean?  Go = visit RFC3986, section 6, and enjoy several hundred words walking = through all the issues that arise in trying to figure out when two URIs = are equivalent, ranging from exact character-by-character identity to = all sorts of protocol-specific goo. You are just one level of = case-sensitivity-in-%-escaping from a big hairy false negative.

I=92m also worried about a lack of = flexibility. I might have a single webfinger resource that declares a = bunch of link relations for a bunch of different resources. This = section, as written, wouldn=92t let me do that.

Proposal: Re-write section 5.2.2 as follows:

<<<<<<<
The value of the = "subject" member is a string whose value is advisory, identifying the = resource to which the properties given in the "links" member = apply.  Normally this would be expected to be equivalent to the = value of the "resource" parameter in the client request. 
<<<<<<<

On Sun, Dec 2, 2012 = at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,
 
I published another version of the WebFinger spec trying to = bring closure to the two open issues I see (resource representation and = transport).  The new version is here:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07<= o:p class=3D"">
 
With respect to resource representation, I fully described = the JSON Resource Descriptor within the document.  There are no = external references to RFC 6415 now, no need to go read the XRD spec, = etc.  It=92s a fairly simple format and I believe this text = documents it sufficiently.  Combined with the visual examples, I = think this makes it pretty clear.  Have a look at the JRD = documentation in section 5.2 and provide your comments.
 
With respect to HTTPS, it seems there is strong preference = for =93HTTPS only=94, but some a fair bit of insistence for allowing = HTTP.  I changed the wording in 5.2 to try to capture = opinions.  Previously, the text led with a requirement to try HTTPS = first.  That is still there.  I just added some extra = conditions that make it clearer that there are some instances where a = client must not utilize HTTP.  This might need further refinement, = but I think there is a balance we can strike here between the two camps = without introducing a lot of complex language.
 
I made some editorial changes through the document.
 
Comments are welcome, as always.  Seems I don=92t need = to say that to this group, though :-)
 
Paul
 


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


= --Apple-Mail=_172A2D46-0082-4D62-A9EA-AA175C95781B-- From ve7jtb@ve7jtb.com Mon Dec 3 05:42:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D9A21F8521 for ; Mon, 3 Dec 2012 05:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqVUW2ni+Fbs for ; Mon, 3 Dec 2012 05:42:50 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 27DF721F8589 for ; Mon, 3 Dec 2012 05:42:49 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id r14so419328yen.31 for ; Mon, 03 Dec 2012 05:42:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=lRqI2Czcu+QJlYu964Hc8pzipQ0D9hWEJQNFlwOqAuQ=; b=o+xshFmN5M0ZB/7+htzyFFdaS1wLaU10o4vqh9mJ2yAzThpfBKR21t/0wwt6inGtXP uZuuCKuOB9rxrLn/WliswjfhrOG4OpWyJ65mGwomHJrzG4IV9DPsNkBkmJ7c8m3j57s7 1Tx22a6OvkCxcXGSdAPnHEn1zmyBMHAUf2S24GR7kuAdF/IHWRgRCn4Mnoaf6Np0XUVk dkchZU3YFdNS0uCiA4E5Zjb6ULg1qPZMglZSd9ksmNblbtrCZlLjtk5Kw94PHu+0iITW 0j1m8OTnGRUmTJGl+isB8GtnfN2Z3VdGKEG2C706C+Ju4Gem8TKZApnZ/cQuBLUu7Zxn ilGQ== Received: by 10.236.83.103 with SMTP id p67mr10159728yhe.78.1354542168076; Mon, 03 Dec 2012 05:42:48 -0800 (PST) Received: from [192.168.1.211] (190-20-29-186.baf.movistar.cl. [190.20.29.186]) by mx.google.com with ESMTPS id u15sm11572761anq.14.2012.12.03.05.42.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 05:42:46 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_78554AFE-CAAD-42E2-ABE9-6C6C326D9580" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Mon, 3 Dec 2012 10:42:37 -0300 Message-Id: <591637DA-481A-42D2-BAFE-6FD0DDB17A84@ve7jtb.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <073201cdd041$d2050b50$760f21f0$@packetizer.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnFFqh8OxchW3G9xIPaDnlVgusJGhQpAsJH+f5p3lfU62gAFlDeMEkGlOk8wFM9s44kYQj7 Cc: "apps-discuss@ietf.org" , Joseph Holsten Subject: Re: [apps-discuss] Web Finger HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:42:51 -0000 --Apple-Mail=_78554AFE-CAAD-42E2-ABE9-6C6C326D9580 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In Oauth 2 Security considerations we reference RFC6125 to describe = proper certificate validation.=20 It tells servers what the right thing to do is. For JS clients, = enforcing that is admittedly a challenge. I don't think the correct thing is to say that just because TLS is not = perfect we should just give up. Some clients will get it wrong but if the spec is correct and clear = those can be made to be fixed.=20 If the spec is not clear then people will do what they like as good = enough. John B. On 2012-12-03, at 2:19 AM, Dick Hardt wrote: >=20 > On Dec 2, 2012, at 9:10 PM, Nico Williams = wrote: >>=20 >> My domain's hosting site, for example. This is not about the hosting = site: it's about the incomplete deployment of TLS SNI. >=20 > Would motivating hosting sites to do complete deployment of TLS SNI = not be a good thing? >=20 >> =20 >> > >> > Many clients don't do proper server cert validation. "I used TLS" = !=3D >> > "I got it securely". >>=20 >> So we should not force HTTPS because some clients don't implement it = properly? Really? >>=20 >> No, we should not mandate TLS if either we know that requirement will = often be ignored or if we're doing it because we think that gets use = "security". And if we do end up requiring TLS we need to say a lot more = about server certificate validation, about TLS cipher suites (e.g., no = anon DH ones), and so on, about trust anchors (same as for web = browsers?). >=20 > We mandated TLS in OAuth 2.0 without any of that. Not sure why that is = suddenly an issue now. >=20 >> =20 >> > >> >> There is a real latency and extra code in dealing with the = fallback as currently specified. >> > >> > But is that relevant here? >>=20 >> I would think so. If the user is waiting for discovery to be = finished, latency is an issue. >> Extra code is extra code and complexity and more to understand. >>=20 >> I wouldn't worry about a line of code given TLS' complexity, which = we'd be requiring. =20 >=20 > TLS support is in libraries readily available to clients. Yes, some of = them need to be improved to have *better* support of TLS, but that is a = separate issue. >=20 >> The latency involved in one more fallback may well matter, but I'm = not ready to conclude that it means we must require TLS because we could = still consider the alternative that the WF app/ user be the one to = decide whether to use TLS at all or not, without a fallback in either = case >=20 > The latest spec requires an HTTPS call to start ALL the time. >=20 > Choice of what to use adds complexity and incorrect choices by = implementations. >=20 >> (actually, I prefer this alternative). >=20 > And how would the WF app decide if to use TLS or not, or how will it = discover what the server supports?=20 >=20 >> =20 >> >> For example, we lose being able to use a simple CURL command to = get a JRD. >> > >> > So you need an if and two invocations of curl. >>=20 >> So you agree it is more complicated. The agreed goal is to push = complexity to the server. >>=20 >> Agreed by whom? >=20 > There seemed consensus on this, and I think should be a guiding = principal. All other things being equal, move complexity to the side = that has fewer implementations and is likely to be done by less = sophisticated implementors. >=20 > -- Dick >=20 --Apple-Mail=_78554AFE-CAAD-42E2-ABE9-6C6C326D9580 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In = Oauth 2 Security considerations we reference RFC6125 to describe proper certificate = validation. 
It = tells servers what the right thing to do is. For JS clients, enforcing = that is admittedly a challenge.

I = don't think the correct thing is to say that just because TLS is not = perfect we should just give up.

Some clients = will get it wrong but if the spec is correct and clear those can be made = to be fixed. 
If the spec is not clear then people will = do what they like as good enough.

John = B.

On 2012-12-03, at 2:19 AM, Dick Hardt <dick.hardt@gmail.com> = wrote:

nico@cryptonector.com> = wrote:

My domain's = hosting site, for example.  This is not about the hosting site: = it's about the incomplete deployment of TLS = SNI.

Would motivating hosting = sites to do complete deployment of TLS SNI not be a good = thing?

 
>
> Many clients don't do proper server cert validation.  "I used = TLS" !=3D
> "I got it securely".

So we should not force HTTPS because some clients don't implement it = properly? Really?

No, we should not = mandate TLS if either we know that requirement will often be ignored or = if we're doing it because we think that gets use "security".  And = if we do end up requiring TLS we need to say a lot more about server = certificate validation, about TLS cipher suites (e.g., no anon DH ones), = and so on, about trust anchors (same as for web = browsers?).

We mandated TLS in = OAuth 2.0 without any of that. Not sure why that is suddenly an issue = now.

 
>
>> There is a real latency and extra code in dealing with the = fallback as currently specified.
>
> But is that relevant here?

I would think so. If the user is waiting for discovery to be finished, = latency is an issue.
Extra code is extra code and complexity and more to = understand.

I wouldn't worry about a = line of code given TLS' complexity, which we'd be requiring. =  

TLS support is in libraries = readily available to clients. Yes, some of them need to be improved to = have *better* support of TLS, but that is a separate = issue.

The latency involved in one = more fallback may well matter, but I'm not ready to conclude that it = means we must require TLS because we could still consider the = alternative that the WF app/ user be the one to decide whether to use = TLS at all or not, without a fallback in either = case

The latest spec requires an = HTTPS call to start ALL the time.

Choice of = what to use adds complexity and incorrect choices by = implementations.

(actually, I = prefer this alternative).

And how would = the WF app decide if to use TLS or not, or how will it discover what the = server supports? 

 
>> For example, we lose being able to use a simple CURL command to = get a JRD.
>
> So you need an if and two invocations of curl.

So you agree it is more complicated. The agreed goal is to push = complexity to the server.

Agreed by = whom?

There seemed consensus on this, and I think = should be a guiding principal. All other things being equal, move = complexity to the side that has fewer implementations and is likely to = be done by less sophisticated implementors.

-- = Dick


= --Apple-Mail=_78554AFE-CAAD-42E2-ABE9-6C6C326D9580-- From lear@cisco.com Mon Dec 3 05:58:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A64321F871D for ; Mon, 3 Dec 2012 05:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvDeoDRmO1b9 for ; Mon, 3 Dec 2012 05:58:17 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8A021F872C for ; Mon, 3 Dec 2012 05:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=559; q=dns/txt; s=iport; t=1354543097; x=1355752697; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yIp0DbHKcmjfwafyWa+dLjRNIzaBGhzHilkxQ+W1mjU=; b=Nd1ekr37WmNdS1RLlynzXlUA2odZb01ILpPiBDmPrSKgUYNFjRELZU5b oMgPjtTjXjG8B1FTEbrOYODugOv14UNg+SDHzW1EsiQJ6sgilFqZmiGnj v9aFQIji897Ifjo7xQoAkMUw1Axf3ZGyWMp4KWa+XsL2cZ8+q5/k4trzD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPeuvFCQ/khL/2dsb2JhbABEhiy5VRZzgh8BAQQjVQEQCw4MAgUWCwICCQMCAQIBRQYNAQcBAYgMrA2SJIEiiymDI4ETA5YBkEeCc4Fr X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="78768043" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 03 Dec 2012 13:58:16 +0000 Received: from dhcp-10-55-80-36.cisco.com (dhcp-10-55-80-36.cisco.com [10.55.80.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB3DwFm7016838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 13:58:16 GMT Message-ID: <50BCAFF7.4090002@cisco.com> Date: Mon, 03 Dec 2012 14:58:15 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Bradley References: <50BC3AF5.2080507@cisco.com> <25A482B0-90AE-402E-93B7-5F964FB06107@ve7jtb.com> In-Reply-To: <25A482B0-90AE-402E-93B7-5F964FB06107@ve7jtb.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:58:18 -0000 John, I think the problem we're having here is the applicability of webfinger. One of the examples could be viewed as an internal employee at an enterprise configuring email. Also, Internet (big I) tools often end up in the enterprise. Your MITRE example is a good one. In that case, and there are others like it, administrators have made a choice. That's the way it should be. Other administrators will make other choices. Don't force them to make bad ones. Different story for implementers. There I have no problem with a MUST. Eliot From ve7jtb@ve7jtb.com Mon Dec 3 06:57:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AB621F86C3 for ; Mon, 3 Dec 2012 06:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp8Dx1VukyGo for ; Mon, 3 Dec 2012 06:57:25 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB00E21F8501 for ; Mon, 3 Dec 2012 06:57:25 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so431537ggn.31 for ; Mon, 03 Dec 2012 06:57:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=D09hwTxjwTqpdIXESTPIYJ8lHdKTvLfPisKCDwj6LvA=; b=j0gfZJj1oaSOFQI1C0HRb0WDS585r8GtIOtbExjRt3kcP5aB/SxZ7qCkQ9ALvHA6vY X0MNyvZuBLBBRVacdCD56RDPtsRRM/nE8YcxY3LOepJnRnkTogeH/1WOmo7ZNLjBbTi4 J5klGaFSnKkmQDUDM5apFOpAXJeBGq5Rk9V+hI//v0lOErddWgt98VAfks5KA7517Tb1 Srfr+NrUSY5NRiCBMOzGyYjWCQmEVZQMRGoQCfhENRWvgweo1fX2DFpZFgOioCnngz7o eRdHSY9kberXpIoiOxVMjEkSPN8fSmKkW5EJP2ndS82DMsKXh4+WweYRqSGt9AP/8Cnf El/Q== Received: by 10.236.87.77 with SMTP id x53mr10910891yhe.7.1354546645124; Mon, 03 Dec 2012 06:57:25 -0800 (PST) Received: from [192.168.1.211] (190-20-29-186.baf.movistar.cl. [190.20.29.186]) by mx.google.com with ESMTPS id u11sm11758231ane.11.2012.12.03.06.57.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 06:57:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <50BCAFF7.4090002@cisco.com> Date: Mon, 3 Dec 2012 11:57:14 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3B25ACBB-40C4-465C-9B3F-6D99A1922953@ve7jtb.com> References: <50BC3AF5.2080507@cisco.com> <25A482B0-90AE-402E-93B7-5F964FB06107@ve7jtb.com> <50BCAFF7.4090002@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnWqfppjmJsQ1Qx0F8aXTRqQ3+GZXq694w7BNQ7Xzppw+m5t7WXKzRA0ErdWxkdmvulKA1H Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 14:57:27 -0000 I am not recommending a particular solution for enterprises, just = pointing out that is they probably have a solution for trusting there = own certificates for web browsers. That works for WF as well. If they don't have a solution other than telling users to hit ignore all = the time then we probably can't help them. Remember WF is deployed on the web server for there domain, so whatever = cert is there will work or not work for them as well as it is now. John B. On 2012-12-03, at 10:58 AM, Eliot Lear wrote: > John, >=20 > I think the problem we're having here is the applicability of > webfinger. One of the examples could be viewed as an internal = employee > at an enterprise configuring email. Also, Internet (big I) tools = often > end up in the enterprise. Your MITRE example is a good one. In that > case, and there are others like it, administrators have made a choice.=20= > That's the way it should be. Other administrators will make other > choices. Don't force them to make bad ones. Different story for > implementers. There I have no problem with a MUST. >=20 > Eliot From bradfitz@google.com Sun Dec 2 15:48:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8B321F8905 for ; Sun, 2 Dec 2012 15:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rf1Wp2T8-GM for ; Sun, 2 Dec 2012 15:48:01 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE0521F8904 for ; Sun, 2 Dec 2012 15:48:01 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2361936oag.31 for ; Sun, 02 Dec 2012 15:48:00 -0800 (PST) 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=/bP3vq6TsHZ+gFm035O04FhkWIEm4+MnMuQxz1+ZoIs=; b=ZGRp/E0etVSgz8u1itzhRteR34hnPXoKyqk+Wt4B4VgC/xgC2jRlfP+K2lPZMPzOuj S4L7z1oZjICZJ7GAqFddkJ0Fi6G6xx5lHJd+c/molgyCrT4YmZjcdNe1K4bMODxvoFAP e4/bPS73gDRHEyQEUMdpgdAjQTC5mk8y13XyvfASCizF7pTH5b//uHW0tBNPvVMaMhK4 zboEz5UGzQXld+bxK/X1bBDo6H716CgWzSW/2sWV/kEQA34pRjHsI98EFg5whLJUWSzh 7dXTU2cgMWX4+mijURxe5DFM6YSzHRn110Fma3j4N6YsyUbbBFya8wTEBX/4srBWzufd wLhg== X-Google-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:x-gm-message-state; bh=/bP3vq6TsHZ+gFm035O04FhkWIEm4+MnMuQxz1+ZoIs=; b=fC3dXc2PtHHlrJw6q6Mw+2CxM/w9rM2z1lEUFP5ezORfFNGkPGHmqgYN5+EvlQoxJG dlfvQtW/U09Juq+4S49yjOCl8glQ/bkjj0GlIxAz1gDYrHwhzqV6PZAYT1Yw42kAHU3C 0m99sn749p+74ioA51EnYKltNHGMESExRsP7kigxZdAtueJ1qfjzDSw56FdcSuINe3TG UvoVviWO+rqBaCNIb39EhsIhoPnRJ9L5R0G7X13Rv/ky9CxdY4268P6G65QTCecec2RH Rbr2XirgN0cO/9Pg63IWuTL62ljTZi2VzqW7OqiGRfxlvyVZeYuLJMf9mzfLrc5jArJV l6yQ== MIME-Version: 1.0 Received: by 10.60.11.105 with SMTP id p9mr6932958oeb.128.1354492080548; Sun, 02 Dec 2012 15:48:00 -0800 (PST) Received: by 10.76.105.35 with HTTP; Sun, 2 Dec 2012 15:48:00 -0800 (PST) In-Reply-To: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> Date: Sun, 2 Dec 2012 15:48:00 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8fb1f7544feb5504cfe7435f X-Gm-Message-State: ALoCoQmgV+V5yZxE97GZJUd9mlV4iPyExhhsVWm4fyb5MkGaYx7i3o6WTeQVkP2x16K15hGLB5Y7TqOa6XQ7hasc4mn9hydcqPXMG6EwcPI9KXCeny7PcHvz+WJIuh5ajjRdUny5KbjfAzbOvpLDA4HS41fC7lCU9SVFF2L0rC4205YXWE/uHgT8EV5Sxcc5i2J+uM97jcfm X-Mailman-Approved-At: Mon, 03 Dec 2012 08:38:36 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 23:48:02 -0000 --e89a8fb1f7544feb5504cfe7435f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Why does the JRD have a recommended key/value order? On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > I published another version of the WebFinger spec trying to bring closure > to the two open issues I see (resource representation and transport). Th= e > new version is here:**** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** > > ** ** > > With respect to resource representation, I fully described the JSON > Resource Descriptor within the document. There are no external reference= s > to RFC 6415 now, no need to go read the XRD spec, etc. It=E2=80=99s a fa= irly > simple format and I believe this text documents it sufficiently. Combine= d > with the visual examples, I think this makes it pretty clear. Have a loo= k > at the JRD documentation in section 5.2 and provide your comments. **** > > ** ** > > With respect to HTTPS, it seems there is strong preference for =E2=80=9CH= TTPS > only=E2=80=9D, but some a fair bit of insistence for allowing HTTP. I ch= anged the > wording in 5.2 to try to capture opinions. Previously, the text led with= a > requirement to try HTTPS first. That is still there. I just added some > extra conditions that make it clearer that there are some instances where= a > client must not utilize HTTP. This might need further refinement, but I > think there is a balance we can strike here between the two camps without > introducing a lot of complex language.**** > > ** ** > > I made some editorial changes through the document.**** > > ** ** > > Comments are welcome, as always. Seems I don=E2=80=99t need to say that = to this > group, though :-)**** > > ** ** > > Paul**** > > ** ** > --e89a8fb1f7544feb5504cfe7435f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
W= hy does the JRD have a recommended key/value order?

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <paulej@pack= etizer.com> wrote:

Folks,

=C2=A0

I published another version of the WebFinger spec tr= ying to bring closure to the two open issues I see (resource representation= and transport).=C2=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

=C2=A0

With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=C2=A0 There are no external references to= RFC 6415 now, no need to go read the XRD spec, etc. =C2=A0It=E2=80=99s a f= airly simple format and I believe this text documents it sufficiently.=C2= =A0 Combined with the visual examples, I think this makes it pretty clear.= =C2=A0 Have a look at the JRD documentation in section 5.2 and provide your= comments.

=C2=A0

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS on= ly=E2=80=9D, but some a fair bit of insistence for allowing HTTP.=C2=A0 I c= hanged the wording in 5.2 to try to capture opinions.=C2=A0 Previously, the= text led with a requirement to try HTTPS first.=C2=A0 That is still there.= =C2=A0 I just added some extra conditions that make it clearer that there a= re some instances where a client must not utilize HTTP.=C2=A0 This might ne= ed further refinement, but I think there is a balance we can strike here be= tween the two camps without introducing a lot of complex language.

=C2=A0

I mad= e some editorial changes through the document.

=C2=A0

Comments are wel= come, as always.=C2=A0 Seems I don=E2=80=99t need to say that to this group= , though :-)

=C2=A0

Paul

=C2=A0

=

--e89a8fb1f7544feb5504cfe7435f-- From bradfitz@google.com Sun Dec 2 17:35:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABE521F894E for ; Sun, 2 Dec 2012 17:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.905 X-Spam-Level: X-Spam-Status: No, score=-102.905 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhJgcuft8ayU for ; Sun, 2 Dec 2012 17:35:46 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 913D021F893A for ; Sun, 2 Dec 2012 17:35:46 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2185130obc.31 for ; Sun, 02 Dec 2012 17:35:46 -0800 (PST) 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=0Xo4Brw3PN1Yi+JGvrtjB0ZEetVNf6j/x28kwNHIHPo=; b=KZgSK1HFj8aahG9ZqL7sJ6M2BwEBIsALCaZFY86uYW4pb4NIv4S1UqppHsI8aMseJu 8bT65cA1RfMmYzoEfxnEsRXZGgYNxWbVWmSoVDa+W8+FstheU2UuV5ubb2E5UtKTnBa1 0kwmh6jLZwAsGoX2K4sTisPYc+aNbn2wEnVF53XcYt+xEjZOIMNTTF14YreOiBk2gD1E 4Tj20DuLyT+aB231BGhoZW8b3pBwd+j8hBriGJAeN6B1CvKCPVacBfN9dtpfgo+DGJuo ISk2pL62ozKStGUBYzM8afSLMootu8/riMO5Je+sSOgEyqTXoBxgpGdnDwbwXbB/1rCf 4iAA== X-Google-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:x-gm-message-state; bh=0Xo4Brw3PN1Yi+JGvrtjB0ZEetVNf6j/x28kwNHIHPo=; b=S2b2U0C5Q8nl8MEmrugzob/+3PCHxvSJJ9FFVGcg0ZVAKiZ2+6bG8QnH8Aaxy/8gky uMIJ0YebbUdyYDgs+yaFgEzal56c5wZLyiit1I7mXnUcqAwQAarQXWJKA1HN37sdxqN8 oIIXHEDf7tZz6Av2436WWkBpA/pyCq3ZY8g3k24E6YA9CwTNEvJMcgh7P0067MNDoPeW HJ6R0/sKhiXNCMwKNJ9RF7YywtsbhLC8Izn98SaSUhPaB9QOpEH3XHTL5vKTHzXiUW0B x0ZEC+DcMfxywPQby4GWDAAGXAq/3sCdM9/LaJsiqKl9lHj3FpKdlmiIdNhD5lJMTa0T cdOA== MIME-Version: 1.0 Received: by 10.60.171.244 with SMTP id ax20mr7238362oec.0.1354498546081; Sun, 02 Dec 2012 17:35:46 -0800 (PST) Received: by 10.76.105.35 with HTTP; Sun, 2 Dec 2012 17:35:45 -0800 (PST) In-Reply-To: References: Date: Sun, 2 Dec 2012 17:35:45 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec54a32c6b020ec04cfe8c48f X-Gm-Message-State: ALoCoQlHRf45Xu7byKdZ6GTb9xA4QmFxLrc2dhh08dxlbj+Sv0PzuwUM1cJe7IOGbZIyaB7eAoMh+eLCrqPuouf9N2uyGPFnT3aNs1H01hMC4dRviGhGsUJcpidK1+nIx3/0tuusYxpfYK4239LGC5uS7+itg8PmxZHGF9uVubzxWQAFyHoOH/cbdLdVlPa/Lwt4F80wx3Pb X-Mailman-Approved-At: Mon, 03 Dec 2012 08:38:51 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:35:47 -0000 --bcaec54a32c6b020ec04cfe8c48f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1. I feel strongly for keeping the acct: scheme. WebFinger isn't just about email. On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > I don=E2=80=99t want to wait for work on this to be completed, and I don= =E2=80=99t think > that its presence is necessary for WebFinger to be useful. So let's take > it out. > > Proposal: > Section 4.1: Change the URI in the example from acct: to mailto: > Section 4.2: Same > Section 5.3: Same > Section 5.4: s/it could be an "acct" URI [7], // > Section 5.4: Remove 2nd para, beginning "For resources associated with a > user account at a host...=E2=80=9C > Section 5.4: s/both an "acct" URI and any alias/any alias/ > Section 8: Change the URI in the example from acct: to mailto: > > > On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: > >> No, we=E2=80=99re on the same side here. I=E2=80=99m suggesting taking w= ebfinger-07 as a >> baseline, and all *future* changes need to be proposed as a concrete del= ta >> against it. -T >> >> >> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones wr= ote: >> >>> Tim,**** >>> >>> ** ** >>> >>> I didn=E2=80=99t mean to be rude by introducing these changes, just try= ing to >>> move things along. Most changes were fairly trivial, not worth mention= ing, >>> and can be seen here:**** >>> >>> >>> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-app= sawg-webfinger-07.txt >>> **** >>> >>> ** ** >>> >>> The most significant changes were the re-write of section 5.2 and >>> modification to the language related to HTTPS in 5.1. I suspect that i= s >>> the text to which you refer as preferring it to be =E2=80=9Ccamera-read= y=E2=80=9D. (I >>> would assume the balance of the changes would not need to be presented = as >>> =E2=80=9Ccamera-ready=E2=80=9D, since they=E2=80=99re minor editorial t= hings.)**** >>> >>> ** ** >>> >>> In any case, the most important text changes I would like folks to >>> consider is section 5.2 (which aims to fully document the JSON Resource >>> Descriptor object) and paragraphs 2 and 3 in section 5.1.**** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> *From:* Tim Bray [mailto:tbray@textuality.com] >>> *Sent:* Sunday, December 02, 2012 2:54 PM >>> *To:* Paul E. Jones >>> *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com >>> *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-07**** >>> >>> ** ** >>> >>> Thanks to Paul for the extra effort. I=E2=80=99d like to suggest, in t= he >>> interests of courtesy and efficiency, that from here on on, contributio= ns >>> to this discussion be =E2=80=9Ccamera-ready=E2=80=9D, that is to say, s= pecific suggestions >>> in the style of a diff, including fully-written-out replacements langua= ge. >>> >>> -Tim**** >>> >>> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones >>> wrote:**** >>> >>> Folks,**** >>> >>> **** >>> >>> I published another version of the WebFinger spec trying to bring >>> closure to the two open issues I see (resource representation and >>> transport). The new version is here:**** >>> >>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >>> >>> **** >>> >>> With respect to resource representation, I fully described the JSON >>> Resource Descriptor within the document. There are no external referen= ces >>> to RFC 6415 now, no need to go read the XRD spec, etc. It=E2=80=99s a = fairly >>> simple format and I believe this text documents it sufficiently. Combi= ned >>> with the visual examples, I think this makes it pretty clear. Have a l= ook >>> at the JRD documentation in section 5.2 and provide your comments. **** >>> >>> **** >>> >>> With respect to HTTPS, it seems there is strong preference for =E2=80= =9CHTTPS >>> only=E2=80=9D, but some a fair bit of insistence for allowing HTTP. I = changed the >>> wording in 5.2 to try to capture opinions. Previously, the text led wi= th a >>> requirement to try HTTPS first. That is still there. I just added som= e >>> extra conditions that make it clearer that there are some instances whe= re a >>> client must not utilize HTTP. This might need further refinement, but = I >>> think there is a balance we can strike here between the two camps witho= ut >>> introducing a lot of complex language.**** >>> >>> **** >>> >>> I made some editorial changes through the document.**** >>> >>> **** >>> >>> Comments are welcome, as always. Seems I don=E2=80=99t need to say tha= t to this >>> group, though :-)**** >>> >>> **** >>> >>> Paul**** >>> >>> **** >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss**** >>> >>> ** ** >>> >> >> > --bcaec54a32c6b020ec04cfe8c48f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
-= 1. =C2=A0I feel strongly for keeping the acct: scheme. =C2=A0WebFinger isn&= #39;t just about email.

On Sun, Dec 2, 20= 12 at 5:14 PM, Tim Bray <tbray@textuality.com> wrote:
I don=E2=80=99t want to wait for work on thi= s to be completed, and I don=E2=80=99t think that its presence is necessary= for WebFinger to be useful.=C2=A0 So let's take it out.

Proposal:
Section 4.1: Change the URI in the example from acct: to m= ailto:
Section 4.2: Same
Section 5.3: Same
Section 5.4: s/it could be an &qu= ot;acct" URI [7], //
Section 5.4: Remove 2nd para, beginning "= For resources associated with a user account at a host...=E2=80=9C
Secti= on 5.4: s/both an "acct" URI and any alias/any alias/
Section 8: Change the URI in the example from acct: to mailto:


<= div class=3D"gmail_quote">On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray <tbr= ay@textuality.com> wrote:
No, we=E2=80=99re on the same side here. I= =E2=80=99m suggesting taking webfinger-07 as a baseline, and all *future* c= hanges need to be proposed as a concrete delta against it.=C2=A0 -T


On Sun, Dec 2, 2012 at 12:59 PM, Pa= ul E. Jones <paulej@packetizer.com> wrote:

Tim,

=C2=A0

I didn=E2=80=99t me= an to be rude by introducing these changes, just trying to move things alon= g.=C2=A0 Most changes were fairly trivial, not worth mentioning, and can be= seen here:

http://tools.ietf.org/rfcdiff?difftype=3D--hwdif= f&url2=3Ddraft-ietf-appsawg-webfinger-07.txt

=C2=A0

The most significan= t changes were the re-write of section 5.2 and modification to the language= related to HTTPS in 5.1.=C2=A0 I suspect that is the text to which you ref= er as preferring it to be =E2=80=9Ccamera-ready=E2=80=9D.=C2=A0 (I would as= sume the balance of the changes would not need to be presented as =E2=80=9C= camera-ready=E2=80=9D, since they=E2=80=99re minor editorial things.)

=C2=A0

In any case, the mo= st important text changes I would like folks to consider is section 5.2 (wh= ich aims to fully document the JSON Resource Descriptor object) and paragra= phs 2 and 3 in section 5.1.

=C2=A0

Paul<= /span>

=C2=A0

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. Jones<= br>Cc: ap= ps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07

=C2=A0<= u>

Thanks to P= aul for the extra effort.=C2=A0 I=E2=80=99d like to suggest, in the interes= ts of courtesy and efficiency, that from here on on, contributions to this = discussion be =E2=80=9Ccamera-ready=E2=80=9D, that is to say, specific sugg= estions in the style of a diff, including fully-written-out replacements la= nguage.

=C2=A0-Tim

On Sun, Dec 2, = 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

<= div>

Folks,

=C2= =A0

I published another version of = the WebFinger spec trying to bring closure to the two open issues I see (re= source representation and transport).=C2=A0 The new version is here:=

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=C2=A0<= /u>

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=C2=A0 There are no= external references to RFC 6415 now, no need to go read the XRD spec, etc.= =C2=A0It=E2=80=99s a fairly simple format and I believe this text document= s it sufficiently.=C2=A0 Combined with the visual examples, I think this ma= kes it pretty clear.=C2=A0 Have a look at the JRD documentation in section = 5.2 and provide your comments.

=C2=A0

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS on= ly=E2=80=9D, but some a fair bit of insistence for allowing HTTP.=C2=A0 I c= hanged the wording in 5.2 to try to capture opinions.=C2=A0 Previously, the= text led with a requirement to try HTTPS first.=C2=A0 That is still there.= =C2=A0 I just added some extra conditions that make it clearer that there a= re some instances where a client must not utilize HTTP.=C2=A0 This might ne= ed further refinement, but I think there is a balance we can strike here be= tween the two camps without introducing a lot of complex language.

=C2=A0

I mad= e some editorial changes through the document.

=C2=A0

Comments are wel= come, as always.=C2=A0 Seems I don=E2=80=99t need to say that to this group= , though :-)

=C2=A0

Paul

=C2=A0=


_____= __________________________________________
apps-discuss mailing list
= apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=C2=A0

<= /div>



--bcaec54a32c6b020ec04cfe8c48f-- From bradfitz@google.com Sun Dec 2 18:03:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8A21F894C for ; Sun, 2 Dec 2012 18:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcfFRG4vWpjs for ; Sun, 2 Dec 2012 18:03:09 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8AD21F8949 for ; Sun, 2 Dec 2012 18:03:09 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2199286obc.31 for ; Sun, 02 Dec 2012 18:03:08 -0800 (PST) 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=8i7sjT8T8d3U0CwNurnCfD5KocMnvIfvtZvktU9DfuM=; b=KUnFzloKKmkNJEry1ziTfyyoN/hi3RnT69WRRN3MjV1WNqCFMyC/jrV3LvKqvxZjyT 2fWZQ+Lwr67TqbQ9Q/kjkFfs3tDXhuz3ex0ByxvvGnTboweFcJXtzD8g5wUE08QGP/53 mRt1WTuaUqIXwCci8rGh3UcqtBJuFxY2wkjkApBt3l91EiiUTsNUfNYsOTkn7ZKFP9ym 13F+rgX+dN2aL2Qi/8oic4rglIVsDGTSjsEBlOeCpDIrgxqc1B1Rrq718Ulv3y7OdIZx t9pGLnA9XfsF2IbaWylas8WFrZYWumz0RpdgSntwn61HvqbmblPPpBy7FHscgkIB2X9s qIpw== X-Google-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:x-gm-message-state; bh=8i7sjT8T8d3U0CwNurnCfD5KocMnvIfvtZvktU9DfuM=; b=afuZqAD2WoyYUf0cTGkAb5p61RN5dtShk2SP36A7fLSK2buU7mYSFz2TZLjhnNin4v n+56RTFfTFEa0LYwdYW7In/DeZoaYMuQTu8WvJEi/v/vIkpEStxaixkX4evy7p3+Ua0N jHF5ZDtmVQwNlJJw1uMI6z8Rv3a1yp/h7laVW9n3eizeIUrtmIbOVagxK2RkkWPqmTsP 8uSzbpGK9ATkP6TiqWNtGg0e38r2SyT9JjLLMs8A+YJjiKheaTE5otHFxTD/a/QQuTwR 7vJqNQJBG1rGgZeHaWtn1iC+JvfhIrlNGz7uRQF/16oS5kD0EBEwcdMufimUU0zAB4SR SC3g== MIME-Version: 1.0 Received: by 10.182.172.74 with SMTP id ba10mr3207243obc.83.1354500188662; Sun, 02 Dec 2012 18:03:08 -0800 (PST) Received: by 10.76.105.35 with HTTP; Sun, 2 Dec 2012 18:03:08 -0800 (PST) In-Reply-To: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> References: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> Date: Sun, 2 Dec 2012 18:03:08 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8f839f6f97e9b804cfe926b5 X-Gm-Message-State: ALoCoQnN2WES8iBagy793RA1ug26FqDWqNlmiu4Mesda/JF5beuKPQDW7kUWFdDvR7psWpSKiLcGqt3NSnHhclckQbhVnI2IvpT2nVVoExsnAnyn534sq+WHSc09FgsDEueFFAlFdiOrqDS9auqKxw6Hf7HPBew8jI/qqysav1IFHhbX7K7oeaME6nFUBn93s7yMoVPur9NV X-Mailman-Approved-At: Mon, 03 Dec 2012 08:39:05 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 02:03:11 -0000 --e89a8f839f6f97e9b804cfe926b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would be fine with acct:-only, but I also don't really care whether any URI is accepted. Little bit more simplicity vs future generality. I'll let people who feel more strongly decide this. I only feel strongly that we say "acct:" and not "mailto:". On Sun, Dec 2, 2012 at 5:51 PM, John Bradley wrote: > I agree that WF is not just about email. > > A question ( perhaps channeling Blane) is if it should only be about acct= : > for simplicity. > > As an example should we be expecting it to resolve xmpp: tel: or other > things. > For http: and https: scheme URI perhaps link headers pointing to a acct: > relation are the most appropriate. > > WF is about having a identifier in User Principal name (UPN) form where > the principal is a domain and finding the JRD document or documents for > that account. > > There is a bunch of hedging that it can work with any URI but that may > just be confusing the issue. > > My personal preference t this point (others working on openID Connect may > well disagree) is to go all in on acct: and just admit that WF is the > resolution process for those URI. > > That is what most people think of it as anyway. > > John B. > > > On 2012-12-02, at 10:35 PM, Brad Fitzpatrick wrote: > > -1. I feel strongly for keeping the acct: scheme. WebFinger isn't just > about email. > > On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > >> I don=E2=80=99t want to wait for work on this to be completed, and I don= =E2=80=99t think >> that its presence is necessary for WebFinger to be useful. So let's tak= e >> it out. >> >> Proposal: >> Section 4.1: Change the URI in the example from acct: to mailto: >> Section 4.2: Same >> Section 5.3: Same >> Section 5.4: s/it could be an "acct" URI [7], // >> Section 5.4: Remove 2nd para, beginning "For resources associated with a >> user account at a host...=E2=80=9C >> Section 5.4: s/both an "acct" URI and any alias/any alias/ >> Section 8: Change the URI in the example from acct: to mailto: >> >> >> On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: >> >>> No, we=E2=80=99re on the same side here. I=E2=80=99m suggesting taking = webfinger-07 as a >>> baseline, and all *future* changes need to be proposed as a concrete de= lta >>> against it. -T >>> >>> >>> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones w= rote: >>> >>>> Tim,**** >>>> >>>> ** ** >>>> >>>> I didn=E2=80=99t mean to be rude by introducing these changes, just tr= ying to >>>> move things along. Most changes were fairly trivial, not worth mentio= ning, >>>> and can be seen here:**** >>>> >>>> >>>> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-ap= psawg-webfinger-07.txt >>>> **** >>>> >>>> ** ** >>>> >>>> The most significant changes were the re-write of section 5.2 and >>>> modification to the language related to HTTPS in 5.1. I suspect that = is >>>> the text to which you refer as preferring it to be =E2=80=9Ccamera-rea= dy=E2=80=9D. (I >>>> would assume the balance of the changes would not need to be presented= as >>>> =E2=80=9Ccamera-ready=E2=80=9D, since they=E2=80=99re minor editorial = things.)**** >>>> >>>> ** ** >>>> >>>> In any case, the most important text changes I would like folks to >>>> consider is section 5.2 (which aims to fully document the JSON Resourc= e >>>> Descriptor object) and paragraphs 2 and 3 in section 5.1.**** >>>> >>>> ** ** >>>> >>>> Paul**** >>>> >>>> ** ** >>>> >>>> *From:* Tim Bray [mailto:tbray@textuality.com] >>>> *Sent:* Sunday, December 02, 2012 2:54 PM >>>> *To:* Paul E. Jones >>>> *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com >>>> *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-07**** >>>> >>>> ** ** >>>> >>>> Thanks to Paul for the extra effort. I=E2=80=99d like to suggest, in = the >>>> interests of courtesy and efficiency, that from here on on, contributi= ons >>>> to this discussion be =E2=80=9Ccamera-ready=E2=80=9D, that is to say, = specific suggestions >>>> in the style of a diff, including fully-written-out replacements langu= age. >>>> >>>> -Tim**** >>>> >>>> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones >>>> wrote:**** >>>> >>>> Folks,**** >>>> >>>> **** >>>> >>>> I published another version of the WebFinger spec trying to bring >>>> closure to the two open issues I see (resource representation and >>>> transport). The new version is here:**** >>>> >>>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >>>> >>>> **** >>>> >>>> With respect to resource representation, I fully described the JSON >>>> Resource Descriptor within the document. There are no external refere= nces >>>> to RFC 6415 now, no need to go read the XRD spec, etc. It=E2=80=99s a= fairly >>>> simple format and I believe this text documents it sufficiently. Comb= ined >>>> with the visual examples, I think this makes it pretty clear. Have a = look >>>> at the JRD documentation in section 5.2 and provide your comments. ***= * >>>> >>>> **** >>>> >>>> With respect to HTTPS, it seems there is strong preference for =E2=80= =9CHTTPS >>>> only=E2=80=9D, but some a fair bit of insistence for allowing HTTP. I= changed the >>>> wording in 5.2 to try to capture opinions. Previously, the text led w= ith a >>>> requirement to try HTTPS first. That is still there. I just added so= me >>>> extra conditions that make it clearer that there are some instances wh= ere a >>>> client must not utilize HTTP. This might need further refinement, but= I >>>> think there is a balance we can strike here between the two camps with= out >>>> introducing a lot of complex language.**** >>>> >>>> **** >>>> >>>> I made some editorial changes through the document.**** >>>> >>>> **** >>>> >>>> Comments are welcome, as always. Seems I don=E2=80=99t need to say th= at to >>>> this group, though :-)**** >>>> >>>> **** >>>> >>>> Paul**** >>>> >>>> **** >>>> >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss**** >>>> >>>> ** ** >>>> >>> >>> >> > > --e89a8f839f6f97e9b804cfe926b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= would be fine with acct:-only, but I also don't really care whether an= y URI is accepted.

Little bit more simplicity vs future = generality. =C2=A0I'll let people who feel more strongly decide this. = =C2=A0I only feel strongly that we say "acct:" and not "mail= to:".


On Sun, = Dec 2, 2012 at 5:51 PM, John Bradley <ve7jtb@ve7jtb.com> wro= te:
I agree = that WF is not just about email.

A question ( perhaps ch= anneling Blane) is if it should only be about acct: for simplicity.

As an example should we be expecting it to resolve xmpp= : =C2=A0tel: =C2=A0or other things. =C2=A0=C2=A0
For http: and ht= tps: scheme URI perhaps link headers pointing to a acct: relation are the m= ost appropriate.

WF is about having a identifier in User Principal name = (UPN) =C2=A0form where the principal is a domain and finding the JRD docume= nt or documents for that account.

There is a bunch= of hedging that it can work with any URI but that may just be confusing th= e issue.

My personal preference t this point (others working on = openID Connect may well disagree) is to go all in on acct: and just admit t= hat WF is the resolution process for those URI.

That is what most people think of it as anyway.

Jo= hn B.


On 2012= -12-02, at 10:35 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:

-1. =C2=A0I feel strongly for keeping the acct: sch= eme. =C2=A0WebFinger isn't just about email.

On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray <tbray@textuality.com<= /a>> wrote:
I don=E2=80=99t want to wait for work on thi= s to be completed, and I don=E2=80=99t think that its presence is necessary= for WebFinger to be useful.=C2=A0 So let's take it out.

Proposal:
Section 4.1: Change the URI in the example from acct: to m= ailto:
Section 4.2: Same
Section 5.3: Same
Section 5.4: s/it could be an &qu= ot;acct" URI [7], //
Section 5.4: Remove 2nd para, beginning "= For resources associated with a user account at a host...=E2=80=9C
Secti= on 5.4: s/both an "acct" URI and any alias/any alias/
Section 8: Change the URI in the example from acct: to mailto:


<= div class=3D"gmail_quote">On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray <tbr= ay@textuality.com> wrote:
No, we=E2=80=99re on the same side here. I= =E2=80=99m suggesting taking webfinger-07 as a baseline, and all *future* c= hanges need to be proposed as a concrete delta against it.=C2=A0 -T


On Sun, Dec 2, 2012 at 12:59 PM, Pa= ul E. Jones <paulej@packetizer.com> wrote:

Tim,=

=C2=A0

I didn=E2=80=99t me= an to be rude by introducing these changes, just trying to move things alon= g.=C2=A0 Most changes were fairly trivial, not worth mentioning, and can be= seen here:

http://tools.ietf.org/rfcdiff?difftype=3D--hwdif= f&url2=3Ddraft-ietf-appsawg-webfinger-07.txt

=C2=A0

The most significan= t changes were the re-write of section 5.2 and modification to the language= related to HTTPS in 5.1.=C2=A0 I suspect that is the text to which you ref= er as preferring it to be =E2=80=9Ccamera-ready=E2=80=9D.=C2=A0 (I would as= sume the balance of the changes would not need to be presented as =E2=80=9C= camera-ready=E2=80=9D, since they=E2=80=99re minor editorial things.)

=C2=A0

In any case, the mo= st important text changes I would like folks to consider is section 5.2 (wh= ich aims to fully document the JSON Resource Descriptor object) and paragra= phs 2 and 3 in section 5.1.

=C2=A0

Paul<= /span>

=C2=A0

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. Jones<= br>Cc: ap= ps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07

=C2=A0

Thanks to Paul f= or the extra effort.=C2=A0 I=E2=80=99d like to suggest, in the interests of= courtesy and efficiency, that from here on on, contributions to this discu= ssion be =E2=80=9Ccamera-ready=E2=80=9D, that is to say, specific suggestio= ns in the style of a diff, including fully-written-out replacements languag= e.

=C2=A0-Tim

On Sun, Dec 2, = 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

<= div>

Folks,

=C2=A0

I published another version of the WebFinger spec trying= to bring closure to the two open issues I see (resource representation and= transport).=C2=A0 The new version is here:

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=C2=A0<= /u>

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=C2=A0 There are no= external references to RFC 6415 now, no need to go read the XRD spec, etc.= =C2=A0It=E2=80=99s a fairly simple format and I believe this text document= s it sufficiently.=C2=A0 Combined with the visual examples, I think this ma= kes it pretty clear.=C2=A0 Have a look at the JRD documentation in section = 5.2 and provide your comments.

=C2=A0

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS on= ly=E2=80=9D, but some a fair bit of insistence for allowing HTTP.=C2=A0 I c= hanged the wording in 5.2 to try to capture opinions.=C2=A0 Previously, the= text led with a requirement to try HTTPS first.=C2=A0 That is still there.= =C2=A0 I just added some extra conditions that make it clearer that there a= re some instances where a client must not utilize HTTP.=C2=A0 This might ne= ed further refinement, but I think there is a balance we can strike here be= tween the two camps without introducing a lot of complex language.

=C2=A0

I mad= e some editorial changes through the document.

=C2=A0

Comments are wel= come, as always.=C2=A0 Seems I don=E2=80=99t need to say that to this group= , though :-)

=C2=A0

Paul

=C2=A0=


___________= ____________________________________
apps-discuss mailing list
apps-discuss@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=C2=A0






--e89a8f839f6f97e9b804cfe926b5-- From matthias@pfefferle.org Mon Dec 3 00:32:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C26321F888E for ; Mon, 3 Dec 2012 00:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHJ9g1NyEyqJ for ; Mon, 3 Dec 2012 00:32:40 -0800 (PST) Received: from mail-oa0-f64.google.com (mail-oa0-f64.google.com [209.85.219.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCB421F88C2 for ; Mon, 3 Dec 2012 00:32:40 -0800 (PST) Received: by mail-oa0-f64.google.com with SMTP id n16so2194852oag.19 for ; Mon, 03 Dec 2012 00:32:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-google-doc-id:x-google-web-client:date:from:to:cc:message-id :in-reply-to:references:subject:mime-version:content-type :x-google-token:x-google-ip:x-gm-message-state; bh=eT78GWwco1bGDcJnA3dyWXPcy9YTIr9bGUajpBb15IM=; b=SHkEziSiAjqI4bvt+QeoQ4gkm2MvJhKzv2kdCOj6bUzTEvW658nAxx+YseO+lom/KP cfhOexiQjlY355cY/E5wS5UHsOl4LSHiSLe3a4X+lIZL+ie5B0A9oFNZPbtv//FfJ9Dg 2hJ2zmFHDTEj4LueviUcCbnkW4PkUgxD3oRKQnbIiob/Ul5KXoj48/mC4xt+44i7eCqA 1inWL74nI8Ej787vo0GCxvVb5Xy9LtQM6yjeCHY6Sek6+joZ631ImXT0j8VrqnhxlQN/ 9dTGxHqDjVxEsLRW960+1BRGoPmtRfXTv8Rg8Jda6wefCl0oib93enyeEJjyv0va3HX6 nKjQ== Received: by 10.49.35.77 with SMTP id f13mr2068618qej.4.1354523559830; Mon, 03 Dec 2012 00:32:39 -0800 (PST) X-Google-Doc-Id: 572a1168526e3ca9 X-Google-Web-Client: true Date: Mon, 3 Dec 2012 00:32:39 -0800 (PST) From: Matthias Pfefferle To: webfinger@googlegroups.com Message-Id: <928b5960-107a-4052-977f-e8513ac32e5e@googlegroups.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10_23038742.1354523559532" X-Google-Token: EKfH8YUFr5ucvWNjooQ0 X-Google-IP: 93.204.66.189 X-Gm-Message-State: ALoCoQkMSJdtxbCAO1ps7yFiAsxcGIQt3equVgcitDRfayU36P0+QSpeMSS4JAXmLT6gzO2eWZnL X-Mailman-Approved-At: Mon, 03 Dec 2012 08:39:19 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 08:33:46 -0000 ------=_Part_10_23038742.1354523559532 Content-Type: multipart/alternative; boundary="----=_Part_11_29844817.1354523559533" ------=_Part_11_29844817.1354523559533 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is it important to talk about "fallbacks"? Wouldn't it be enough to define= =20 "MUST USE" HTTP for "harmless" queries like OExchange, E-Mail to Profile=20 mapping or OStatus, and "MUST USE" HTTPS for OpenID Connect or OAuth? Am Montag, 3. Dezember 2012 02:15:19 UTC+1 schrieb Tim Bray: > > Change paragraph 2 of section 5.1 to read: > > WebFinger client software MUST accept as input a boolean parameter which= =20 > for the purposes of this discussion will be referred as "allow-fallback".= =20 > If this parameter is not provided, client software MUST behave as if it= =20 > were present with a value of false. > > WebFinger client software MUST attempt to retrieve /.well-known/webfinger= =20 > using the HTTPS protocol. If an HTTPS connection is made, and the server= =20 > has an invalid certificate, or returns an HTTP status code indicating an= =20 > error, the client software MUST report an error and cease attempting to= =20 > retrieve the resource. > > If the WebFinger client software is unable to establish an HTTPS=20 > connection to the server, behavior depends on the value of the allow- > fallback parameter. If the value of allow-fallback is true, the client= =20 > software MAY fall back to unencrypted HTTP in an attempt to retrieve=20 > /.well-known/webfinger. If allow-fallback is false, client software MUST= =20 > report an error and cease attempting to retrieve the resource. > > > > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones > > wrote: > >> Folks,**** >> >> ** ** >> >> I published another version of the WebFinger spec trying to bring closur= e=20 >> to the two open issues I see (resource representation and transport). T= he=20 >> new version is here:**** >> >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >> >> ** ** >> >> With respect to resource representation, I fully described the JSON=20 >> Resource Descriptor within the document. There are no external referenc= es=20 >> to RFC 6415 now, no need to go read the XRD spec, etc. It=E2=80=99s a f= airly=20 >> simple format and I believe this text documents it sufficiently. Combin= ed=20 >> with the visual examples, I think this makes it pretty clear. Have a lo= ok=20 >> at the JRD documentation in section 5.2 and provide your comments. **** >> >> ** ** >> >> With respect to HTTPS, it seems there is strong preference for =E2=80=9C= HTTPS=20 >> only=E2=80=9D, but some a fair bit of insistence for allowing HTTP. I c= hanged the=20 >> wording in 5.2 to try to capture opinions. Previously, the text led wit= h a=20 >> requirement to try HTTPS first. That is still there. I just added some= =20 >> extra conditions that make it clearer that there are some instances wher= e a=20 >> client must not utilize HTTP. This might need further refinement, but I= =20 >> think there is a balance we can strike here between the two camps withou= t=20 >> introducing a lot of complex language.**** >> >> ** ** >> >> I made some editorial changes through the document.**** >> >> ** ** >> >> Comments are welcome, as always. Seems I don=E2=80=99t need to say that= to this=20 >> group, though :-)**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> _______________________________________________ >> apps-discuss mailing list >> apps-d...@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > ------=_Part_11_29844817.1354523559533 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is it important to talk about "fallbacks"? Wouldn't it be enough to define = "MUST USE" HTTP for "harmless" queries like OExchange, E-Mail to Profile ma= pping or OStatus, and "MUST USE" HTTPS for OpenID Connect or OAuth?

= Am Montag, 3. Dezember 2012 02:15:19 UTC+1 schrieb Tim Bray:
Change paragraph 2 of section 5.1 to read:
WebFinger client software MUST accept as input a boolean parameter whi= ch for the purposes of this discussion will be referred as "allow-fallb= ack".  If this parameter is not provided, client software MUST = behave as if it were present with a value of false.

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using=20 the HTTPS protocol.  If an HTTPS connection is made, and the server ha= s=20 an invalid certificate, or returns an HTTP status code indicating an=20 error, the client software MUST report an error and cease attempting to=20 retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS=20 connection to the server, behavior depends on the value of the allow-= fallback parameter.  If the value of allow-fallback is true, the client software MAY fall back to u= nencrypted HTTP in an attempt to retrieve /.well-known/webfinger.  If = allow-fallback is false, client software MUST report an error = and cease attempting to retrieve the resource.



On Sun, Dec 2, 2012 at 12:21 AM, Pau= l E. Jones <pau...@packetizer.com>= wrote:

Folks,

 

=

I published another version of the WebFinger spec tr= ying to bring closure to the two open issues I see (resource representation= and transport).  The new version is here:

http://tools.ietf.org/html/draft-= ietf-appsawg-webfinger-07

=  

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.  There are no= external references to RFC 6415 now, no need to go read the XRD spec, etc.=  It=E2=80=99s a fairly simple format and I believe this text document= s it sufficiently.  Combined with the visual examples, I think this ma= kes it pretty clear.  Have a look at the JRD documentation in section = 5.2 and provide your comments.

 

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS on= ly=E2=80=9D, but some a fair bit of insistence for allowing HTTP.  I c= hanged the wording in 5.2 to try to capture opinions.  Previously, the= text led with a requirement to try HTTPS first.  That is still there.=   I just added some extra conditions that make it clearer that there a= re some instances where a client must not utilize HTTP.  This might ne= ed further refinement, but I think there is a balance we can strike here be= tween the two camps without introducing a lot of complex language.

 

I mad= e some editorial changes through the document.

 

Comments are wel= come, as always.  Seems I don=E2=80=99t need to say that to this group= , though :-)

 

Paul

 


__________________________= _____________________
apps-discuss mailing list
apps-d...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


------=_Part_11_29844817.1354523559533-- ------=_Part_10_23038742.1354523559532-- From nick@silverbucket.net Mon Dec 3 05:19:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA45221F8788 for ; Mon, 3 Dec 2012 05:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY0kSowtFvqz for ; Mon, 3 Dec 2012 05:19:24 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0BDC21F8773 for ; Mon, 3 Dec 2012 05:19:23 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2397670lbk.31 for ; Mon, 03 Dec 2012 05:19:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=QL365rpeUbOvDnbwMoftPDBRs3tSQ6pIS737teLnNQ0=; b=AKZzvHTNkxQkUC5vOpUOwjQVA4mj9JuE57C1zuR83gf/iX4AJ+RmnQ1uny+dUnGCSd ppxTZ6C/gh6/ImKTd9brZwHFiHb2AzZRRb8CLDKybTJg7APL4D1K3ETFxWp1ul2JlUMf +8yBNVKEtD8bR8ACPORd84YiAlO7efjdhe/crgIk6GMwE06uVR9mEIsVF0uJwN0jGHc/ zZle7gA++2okVAnhXipXlRB84DSH+ljPybpkseNhqXvsiK5JF8bbFgV0vRys79g0x5G7 /8S1BKKKUKeBFAzEXiB4FC/yWbPCaeRyV+7JKjEw+Djt9OSX+EpNk4MmOwxyQHhPz2Jd Xfww== Received: by 10.152.45.229 with SMTP id q5mr9346418lam.34.1354540762579; Mon, 03 Dec 2012 05:19:22 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id t5sm5395187lbf.6.2012.12.03.05.19.21 (version=SSLv3 cipher=OTHER); Mon, 03 Dec 2012 05:19:21 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2397643lbk.31 for ; Mon, 03 Dec 2012 05:19:21 -0800 (PST) Received: by 10.112.24.161 with SMTP id v1mr4298650lbf.28.1354540761190; Mon, 03 Dec 2012 05:19:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Mon, 3 Dec 2012 05:18:50 -0800 (PST) In-Reply-To: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> References: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> From: Nick Jennings Date: Mon, 3 Dec 2012 14:18:50 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmCo0gI88Sfulfoy3QiH3OQIZFpbQslUlX5UQTRT+cZCRIGDGIYsGZxvV2spqJrUrKjhCNH X-Mailman-Approved-At: Mon, 03 Dec 2012 08:39:30 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:19:24 -0000 On Mon, Dec 3, 2012 at 8:16 AM, Paul E. Jones wrote= : > Tim, > > Yeah, I can appreciate that. However, I would like to suggest some sligh= tly > different wording. How is this for the first paragraph in 5.2.2? > > =E2=80=9CThe value of the "subject" member is a string whose value is adv= isory and > normally would be expected to be equivalent to the value of the "resource= " > parameter in the client request. The "subject" identifies the entity to > which the JRD describes.=E2=80=9D > For someone writing a client library, I would take this to mean that the subject "should" match, but since it doesn't have to, there's no point in checking it and it can be safely ignored. Also, I was discussing WF with a friend the other day and they asked about the possibility of specifying a forwarding address, in the case you switched email addresses, or have several and don't want to manage WF data for all of them. Is there any in-built mechanism for specifying a forwarding account, or something which has a similar effect? -Nick From andy@hxr.us Mon Dec 3 08:49:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F5421F88DF for ; Mon, 3 Dec 2012 08:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCDpLRUE18Od for ; Mon, 3 Dec 2012 08:49:03 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C32121F88DE for ; Mon, 3 Dec 2012 08:49:02 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2615022lbk.31 for ; Mon, 03 Dec 2012 08:49:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=3E0y0dH8EfG6NVGHCeuSH+nwro3ETo3MXYPu+5fjS2M=; b=KEfcyCkiD1nqz3tvI5OmM1Sw/BlOto5iKYDPLe2sUJiCCoxNXlKxYa+gaazPCYMhuJ MsX2QBoRWnlWF1vq0u8/8hryvsZGsFgQf1YwqGLOaPGcNI2ei3jXgkg6OhkobiiDS6+a 5WiXstDSYvNdSucMtsBxV/c2AOmbyMnMkCkI443+AP5e9H8twgtMDYbnd2gesA1oafr+ 8CUN13AcAIxI5+hMS3cWp1nLJqo5Ok0gNzzc0rxh/LyY0AfdgoUNd9KbBiwp+DICoj7w 8KaXnAKLpbZjq4Ote93HFesv5Y1/jd2t1AJsySR2r3KUJuhR9nqyTKypNs4cKDVIDFFg 0uQw== MIME-Version: 1.0 Received: by 10.152.110.42 with SMTP id hx10mr10136477lab.0.1354553342608; Mon, 03 Dec 2012 08:49:02 -0800 (PST) Received: by 10.112.12.52 with HTTP; Mon, 3 Dec 2012 08:49:02 -0800 (PST) X-Originating-IP: [2001:500:4:15:c99:ee00:e32b:ba6b] In-Reply-To: <26263E0AC2BA16FFBE9930DE@caldav.corp.apple.com> References: <26263E0AC2BA16FFBE9930DE@caldav.corp.apple.com> Date: Mon, 3 Dec 2012 11:49:02 -0500 Message-ID: From: Andrew Newton To: Cyrus Daboo Content-Type: multipart/alternative; boundary=bcaec54ee8a4d0c46c04cff586f4 X-Gm-Message-State: ALoCoQkg8ZYBVDDip9IszmX2xFJXw4ih6n2E2cFfwi+4UgIGUfGjL2oiGo9AbJsIHCxB7y5pVfvA Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Describing JSON document formats X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 16:49:04 -0000 --bcaec54ee8a4d0c46c04cff586f4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 30, 2012 at 11:34 AM, Cyrus Daboo wrote: > My question is, is there any right way to describe a JSON document format? > I know there are various JSON schema proposals out there, of which > draft-newton-json-content-**rules was the one I liked the most, and > obviously I would be interested in seeing that document proceed. Any > thoughts? > Hi Cyrus, I'll be updating the content rules draft soon. But regarding your question about there being a right way, my opinion is that there need not be only one way to do describe JSON. Like programming languages, schema languages/formats should be used as appropriate. Thanks for taking a look at the JSON content rules draft. -andy --bcaec54ee8a4d0c46c04cff586f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 3= 0, 2012 at 11:34 AM, Cyrus Daboo <cyrus@daboo.name> wrote:
My question is, is there any right way to describe a JSON = document format? I know there are various JSON schema proposals out there, = of which draft-newton-json-content-rules was the one I liked the mos= t, and obviously I would be interested in seeing that document proceed. Any= thoughts?

Hi Cyrus,

I'll be upd= ating the content rules draft soon. But regarding your question about there= being a right way, my opinion is that there need not be only one way to do= describe JSON. Like programming languages, schema languages/formats should= be used as appropriate.

Thanks for = taking a look at the JSON content rules draft.

-andy
--bcaec54ee8a4d0c46c04cff586f4-- From jan.algermissen@nordsc.com Mon Dec 3 08:52:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE7A21F87F1 for ; Mon, 3 Dec 2012 08:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVfpKbAyLzRk for ; Mon, 3 Dec 2012 08:52:14 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 86EBC21F85AA for ; Mon, 3 Dec 2012 08:52:14 -0800 (PST) Received: from [192.168.2.111] (p548FB142.dip.t-dialin.net [84.143.177.66]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MJZeR-1TeBfj3Wm3-003I2z; Mon, 03 Dec 2012 17:52:13 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jan Algermissen In-Reply-To: Date: Mon, 3 Dec 2012 17:52:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> To: Brad Fitzpatrick X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:mH4vMzR1cDv9IGFeiVhmmBxWWVn2SJ+C2vpqey35tqi c9nPIHZR3NQVGKRsnCZ4+nbWKqWIoKwWPF69310LM+xiQQCjAh wxoJYCdtMn5yYwXJetlYgZwTKtRQWsACb5JPWnq6c3+Aa1N7Yn A3ZNLsEZyR2XJXSkA8ABoM2EjuGyeGzIeonFefluORN5Lwbl1O 5VP0Ol3CwrDZ/vJbFDvicxMAgjouWBrUG1NtPnLKdz6yxBybNO oNqlRoOHEiypPnUqWwvNd/PibnsCBx1qdlddTQ3WW5Rc76RFQz RWA78b7Mly9geYhpvMHmm8kkk2ymrqPrmlRSOUE/50/yd2eG0p Onj9VMp3zroPGfqHMpPCEoZN7sRLHkTRYI6wQgzxx0/iWOK4Yr LVJtLGOcJiMRQ== Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 16:52:24 -0000 On Dec 3, 2012, at 3:03 AM, Brad Fitzpatrick = wrote: > I would be fine with acct:-only, but I also don't really care whether = any URI is accepted. >=20 > Little bit more simplicity vs future generality. I'll let people who = feel more strongly decide this. FWIW I just looked at WebFinger the first time and I am kinda shocked = how much it is coupled with / mentions other specs. Have you guys heard about http://www.w3.org/TR/webarch/#orthogonal-specs = ? Suggestion: drop the idea of it being a protocol, define a decent media = type and a well-known URI so clients can do their initial GET: GET /.well-known/webfinger Accept: application/webfinger The rest of what you try to accomplish IMO will fall into place = naturally. Jan > I only feel strongly that we say "acct:" and not "mailto:". >=20 >=20 > On Sun, Dec 2, 2012 at 5:51 PM, John Bradley = wrote: > I agree that WF is not just about email. >=20 > A question ( perhaps channeling Blane) is if it should only be about = acct: for simplicity. >=20 > As an example should we be expecting it to resolve xmpp: tel: or = other things. =20 > For http: and https: scheme URI perhaps link headers pointing to a = acct: relation are the most appropriate. >=20 > WF is about having a identifier in User Principal name (UPN) form = where the principal is a domain and finding the JRD document or = documents for that account. >=20 > There is a bunch of hedging that it can work with any URI but that may = just be confusing the issue. >=20 > My personal preference t this point (others working on openID Connect = may well disagree) is to go all in on acct: and just admit that WF is = the resolution process for those URI. >=20 > That is what most people think of it as anyway. >=20 > John B. >=20 >=20 > On 2012-12-02, at 10:35 PM, Brad Fitzpatrick = wrote: >=20 >> -1. I feel strongly for keeping the acct: scheme. WebFinger isn't = just about email. >>=20 >> On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray = wrote: >> I don=92t want to wait for work on this to be completed, and I don=92t = think that its presence is necessary for WebFinger to be useful. So = let's take it out. >>=20 >> Proposal: >> Section 4.1: Change the URI in the example from acct: to mailto: >> Section 4.2: Same >> Section 5.3: Same >> Section 5.4: s/it could be an "acct" URI [7], // >> Section 5.4: Remove 2nd para, beginning "For resources associated = with a user account at a host...=93 >> Section 5.4: s/both an "acct" URI and any alias/any alias/ >> Section 8: Change the URI in the example from acct: to mailto: >>=20 >>=20 >> On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray = wrote: >> No, we=92re on the same side here. I=92m suggesting taking = webfinger-07 as a baseline, and all *future* changes need to be proposed = as a concrete delta against it. -T >>=20 >>=20 >> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones = wrote: >> Tim, >>=20 >> =20 >>=20 >> I didn=92t mean to be rude by introducing these changes, just trying = to move things along. Most changes were fairly trivial, not worth = mentioning, and can be seen here: >>=20 >> = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-appsaw= g-webfinger-07.txt >>=20 >> =20 >>=20 >> The most significant changes were the re-write of section 5.2 and = modification to the language related to HTTPS in 5.1. I suspect that is = the text to which you refer as preferring it to be =93camera-ready=94. = (I would assume the balance of the changes would not need to be = presented as =93camera-ready=94, since they=92re minor editorial = things.) >>=20 >> =20 >>=20 >> In any case, the most important text changes I would like folks to = consider is section 5.2 (which aims to fully document the JSON Resource = Descriptor object) and paragraphs 2 and 3 in section 5.1. >>=20 >> =20 >>=20 >> Paul >>=20 >> =20 >>=20 >> From: Tim Bray [mailto:tbray@textuality.com]=20 >> Sent: Sunday, December 02, 2012 2:54 PM >> To: Paul E. Jones >> Cc: apps-discuss@ietf.org; webfinger@googlegroups.com >> Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 >>=20 >> =20 >>=20 >> Thanks to Paul for the extra effort. I=92d like to suggest, in the = interests of courtesy and efficiency, that from here on on, = contributions to this discussion be =93camera-ready=94, that is to say, = specific suggestions in the style of a diff, including fully-written-out = replacements language. >>=20 >> -Tim >>=20 >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: >>=20 >> Folks, >>=20 >> =20 >>=20 >> I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: >>=20 >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 >>=20 >> =20 >>=20 >> With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. It=92s = a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments. >>=20 >> =20 >>=20 >> With respect to HTTPS, it seems there is strong preference for =93HTTPS= only=94, but some a fair bit of insistence for allowing HTTP. I = changed the wording in 5.2 to try to capture opinions. Previously, the = text led with a requirement to try HTTPS first. That is still there. I = just added some extra conditions that make it clearer that there are = some instances where a client must not utilize HTTP. This might need = further refinement, but I think there is a balance we can strike here = between the two camps without introducing a lot of complex language. >>=20 >> =20 >>=20 >> I made some editorial changes through the document. >>=20 >> =20 >>=20 >> Comments are welcome, as always. Seems I don=92t need to say that to = this group, though :-) >>=20 >> =20 >>=20 >> Paul >>=20 >> =20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> =20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jan.algermissen@nordsc.com Mon Dec 3 08:52:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073D121F85AA for ; Mon, 3 Dec 2012 08:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD9Ew0NzbQyg for ; Mon, 3 Dec 2012 08:52:40 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id DB4FA21F84F5 for ; Mon, 3 Dec 2012 08:52:39 -0800 (PST) Received: from [192.168.2.111] (p548FB142.dip.t-dialin.net [84.143.177.66]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0M2kBW-1TNDak12Ry-00sVYS; Mon, 03 Dec 2012 17:52:36 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jan Algermissen In-Reply-To: Date: Mon, 3 Dec 2012 17:52:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46D4B28C-7C4C-4A21-AEC5-8AC9B828A7DD@nordsc.com> References: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> To: Brad Fitzpatrick X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:tpFRsZNJhD1NZGsb0y0CypCLJBrVGz6W7G9sYTdTnXJ Lkg0Ax2x+smE3qdpAkarKaCZPwUstUYcKmREZPDaB4Q+cPvH2y hL0GtXrUeunVAYId13JIx5nSmhbd9/Us+YBOxAFJJsZk2sqI6v 1oPbDXMQKMC/7KpenADaGO+TlmEVopAc9zAfry8lZFICi8kq+M yjs1FpCAgm+c11rBct9BD6vjQOs3gyP5+YOmVPuj+763Oz0Z4H itx8S/vO/brLCNeroWXvFt8sOD1sVv7gfRQ0sFNv7kb6OowU9f e8zQqziz+kNGqWf+dRMoR81eH3p8WBZvLhhMMQKmTdG8R6ENgg ISYJGaFCXWFhzSzk+HWSUIoEVbP0At5lhXr45iM6Bru/xggO3e gTAgGOqyV1foQ== Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 16:52:42 -0000 On Dec 3, 2012, at 3:03 AM, Brad Fitzpatrick = wrote: > I would be fine with acct:-only, but I also don't really care whether = any URI is accepted. >=20 > Little bit more simplicity vs future generality. I'll let people who = feel more strongly decide this. FWIW I just looked at WebFinger the first time and I am kinda shocked = how much it is coupled with / mentions other specs. Have you guys heard about http://www.w3.org/TR/webarch/#orthogonal-specs = ? Suggestion: drop the idea of it being a protocol, define a decent media = type and a well-known URI so clients can do their initial GET: GET /.well-known/webfinger Accept: application/webfinger The rest of what you try to accomplish IMO will fall into place = naturally. Jan > I only feel strongly that we say "acct:" and not "mailto:". >=20 >=20 > On Sun, Dec 2, 2012 at 5:51 PM, John Bradley = wrote: > I agree that WF is not just about email. >=20 > A question ( perhaps channeling Blane) is if it should only be about = acct: for simplicity. >=20 > As an example should we be expecting it to resolve xmpp: tel: or = other things. =20 > For http: and https: scheme URI perhaps link headers pointing to a = acct: relation are the most appropriate. >=20 > WF is about having a identifier in User Principal name (UPN) form = where the principal is a domain and finding the JRD document or = documents for that account. >=20 > There is a bunch of hedging that it can work with any URI but that may = just be confusing the issue. >=20 > My personal preference t this point (others working on openID Connect = may well disagree) is to go all in on acct: and just admit that WF is = the resolution process for those URI. >=20 > That is what most people think of it as anyway. >=20 > John B. >=20 >=20 > On 2012-12-02, at 10:35 PM, Brad Fitzpatrick = wrote: >=20 >> -1. I feel strongly for keeping the acct: scheme. WebFinger isn't = just about email. >>=20 >> On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray = wrote: >> I don=92t want to wait for work on this to be completed, and I don=92t = think that its presence is necessary for WebFinger to be useful. So = let's take it out. >>=20 >> Proposal: >> Section 4.1: Change the URI in the example from acct: to mailto: >> Section 4.2: Same >> Section 5.3: Same >> Section 5.4: s/it could be an "acct" URI [7], // >> Section 5.4: Remove 2nd para, beginning "For resources associated = with a user account at a host...=93 >> Section 5.4: s/both an "acct" URI and any alias/any alias/ >> Section 8: Change the URI in the example from acct: to mailto: >>=20 >>=20 >> On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray = wrote: >> No, we=92re on the same side here. I=92m suggesting taking = webfinger-07 as a baseline, and all *future* changes need to be proposed = as a concrete delta against it. -T >>=20 >>=20 >> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones = wrote: >> Tim, >>=20 >>=20 >>=20 >> I didn=92t mean to be rude by introducing these changes, just trying = to move things along. Most changes were fairly trivial, not worth = mentioning, and can be seen here: >>=20 >> = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-appsaw= g-webfinger-07.txt >>=20 >>=20 >>=20 >> The most significant changes were the re-write of section 5.2 and = modification to the language related to HTTPS in 5.1. I suspect that is = the text to which you refer as preferring it to be =93camera-ready=94. = (I would assume the balance of the changes would not need to be = presented as =93camera-ready=94, since they=92re minor editorial = things.) >>=20 >>=20 >>=20 >> In any case, the most important text changes I would like folks to = consider is section 5.2 (which aims to fully document the JSON Resource = Descriptor object) and paragraphs 2 and 3 in section 5.1. >>=20 >>=20 >>=20 >> Paul >>=20 >>=20 >>=20 >> From: Tim Bray [mailto:tbray@textuality.com]=20 >> Sent: Sunday, December 02, 2012 2:54 PM >> To: Paul E. Jones >> Cc: apps-discuss@ietf.org; webfinger@googlegroups.com >> Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 >>=20 >>=20 >>=20 >> Thanks to Paul for the extra effort. I=92d like to suggest, in the = interests of courtesy and efficiency, that from here on on, = contributions to this discussion be =93camera-ready=94, that is to say, = specific suggestions in the style of a diff, including fully-written-out = replacements language. >>=20 >> -Tim >>=20 >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: >>=20 >> Folks, >>=20 >>=20 >>=20 >> I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: >>=20 >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 >>=20 >>=20 >>=20 >> With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. It=92s = a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments. >>=20 >>=20 >>=20 >> With respect to HTTPS, it seems there is strong preference for =93HTTPS= only=94, but some a fair bit of insistence for allowing HTTP. I = changed the wording in 5.2 to try to capture opinions. Previously, the = text led with a requirement to try HTTPS first. That is still there. I = just added some extra conditions that make it clearer that there are = some instances where a client must not utilize HTTP. This might need = further refinement, but I think there is a balance we can strike here = between the two camps without introducing a lot of complex language. >>=20 >>=20 >>=20 >> I made some editorial changes through the document. >>=20 >>=20 >>=20 >> Comments are welcome, as always. Seems I don=92t need to say that to = this group, though :-) >>=20 >>=20 >>=20 >> Paul >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From laurentwalter.goix@telecomitalia.it Mon Dec 3 08:59:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBBF21F84F5 for ; Mon, 3 Dec 2012 08:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.674 X-Spam-Level: X-Spam-Status: No, score=-0.674 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX6oZnoSbURJ for ; Mon, 3 Dec 2012 08:59:56 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3C621F886C for ; Mon, 3 Dec 2012 08:59:55 -0800 (PST) Content-Type: multipart/mixed; boundary="_5f0cf300-325a-45c6-913e-eda67fce1dbf_" Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 3 Dec 2012 17:59:50 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Mon, 3 Dec 2012 17:59:50 +0100 From: Goix Laurent Walter To: Matthias Pfefferle , "webfinger@googlegroups.com" Date: Mon, 3 Dec 2012 17:59:49 +0100 Thread-Topic: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter Thread-Index: Ac3RdNLsAcYJYsIERcKtlEPI31JE3wAAhNEA Message-ID: References: <928b5960-107a-4052-977f-e8513ac32e5e@googlegroups.com> In-Reply-To: <928b5960-107a-4052-977f-e8513ac32e5e@googlegroups.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] R: Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 16:59:57 -0000 --_5f0cf300-325a-45c6-913e-eda67fce1dbf_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5A21D5BGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5A21D5BGRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGVyZSBhcmUgY2xlYXIgdXNlIGNhc2VzIGZvciBib3RoLiBIb3dldmVyIGl0IG1h eSBiZSBkaWZmaWN1bHQgdG8gc3RhdGUgZXhoYXVzdGl2ZWx5IHdoaWNoIGNhc2Ugd291bGQgZml0 IHdpdGggaHR0cCwgYW5kIHdoaWNoIG5vdCwgc28gSeKAmWQgcmVjb21tZW5kIHN0YXlpbmcgZ2Vu ZXJpYyBhbmQgbm90IG1lbnRpb24gc3BlY2lmaWMgZXhhbXBsZXMuDQpodHRwcyBzaG91bGQgYmUg Y29uc2lkZXJlZCBhcyBhIHNob3VsZCwgYnV0IHRoZXJlIGFyZSB2ZXJ5IHZhbGlkIHVzZSBjYXNl cyBmb3Igd2hpY2ggaXQgaXMgbm90IG5lZWRlZC4NCllldCBpbiBvdGhlciBjYXNlcyBhcyBJIHN0 YXRlZCBlYXJsaWVyLCBodHRwcyBjYW5ub3Qgd29yayBhdCBmaXJzdDogaW4gbW9zdCBtb2JpbGUg bmV0d29yayBpZGVudGlmaWNhdGlvbiBzeXN0ZW1zLCB0aGUgdXNlciBpZGVudGl0eSAocGhvbmUg bnVtYmVyKSBjYW4gb25seSBiZSByZWNvZ25pemVkIG92ZXIgcGxhaW4gaHR0cC4gVGhpcyBvZnRl biByZXF1aXJlcyB0byBpc3N1ZSBhIGZpcnN0IGh0dHAgcmVxdWVzdCAoc29ydCBvZiBwcm9iZSkg dG8gZ2V0IHRoZSBzZXJ2ZXIgc2V0IGEgY29va2llLCBhIG9ubHkgdGhlbiBzZW5kIHRoZSBodHRw cyByZXF1ZXN0IHRvIHRoZSBzYW1lIGVuZHBvaW50IHdpdGggdGhlIHByZXZpb3VzIGNvb2tpZSBm b3IgYXNzb2NpYXRpbmcgdGhlbS4NCg0KRGE6IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBNYXR0 aGlhcyBQZmVmZmVybGUNCkludmlhdG86IGx1bmVkw6wgMyBkaWNlbWJyZSAyMDEyIDkuMzMNCkE6 IHdlYmZpbmdlckBnb29nbGVncm91cHMuY29tDQpDYzogYXBwcy1kaXNjdXNzQGlldGYub3JnDQpP Z2dldHRvOiBSZTogW2FwcHMtZGlzY3Vzc10gRHJhZnQgLTA3IG1vZCBwcm9wb3NhbDogSFRUUFMg d2l0aCBmYWxsYmFjayBwYXJhbWV0ZXINCg0KSXMgaXQgaW1wb3J0YW50IHRvIHRhbGsgYWJvdXQg ImZhbGxiYWNrcyI/IFdvdWxkbid0IGl0IGJlIGVub3VnaCB0byBkZWZpbmUgIk1VU1QgVVNFIiBI VFRQIGZvciAiaGFybWxlc3MiIHF1ZXJpZXMgbGlrZSBPRXhjaGFuZ2UsIEUtTWFpbCB0byBQcm9m aWxlIG1hcHBpbmcgb3IgT1N0YXR1cywgYW5kICJNVVNUIFVTRSIgSFRUUFMgZm9yIE9wZW5JRCBD b25uZWN0IG9yIE9BdXRoPw0KDQpBbSBNb250YWcsIDMuIERlemVtYmVyIDIwMTIgMDI6MTU6MTkg VVRDKzEgc2NocmllYiBUaW0gQnJheToNCkNoYW5nZSBwYXJhZ3JhcGggMiBvZiBzZWN0aW9uIDUu MSB0byByZWFkOg0KDQpXZWJGaW5nZXIgY2xpZW50IHNvZnR3YXJlIE1VU1QgYWNjZXB0IGFzIGlu cHV0IGEgYm9vbGVhbiBwYXJhbWV0ZXIgd2hpY2ggZm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIGRp c2N1c3Npb24gd2lsbCBiZSByZWZlcnJlZCBhcyAiYWxsb3ctZmFsbGJhY2siLiAgSWYgdGhpcyBw YXJhbWV0ZXIgaXMgbm90IHByb3ZpZGVkLCBjbGllbnQgc29mdHdhcmUgTVVTVCBiZWhhdmUgYXMg aWYgaXQgd2VyZSBwcmVzZW50IHdpdGggYSB2YWx1ZSBvZiBmYWxzZS4NCg0KV2ViRmluZ2VyIGNs aWVudCBzb2Z0d2FyZSBNVVNUIGF0dGVtcHQgdG8gcmV0cmlldmUgLy53ZWxsLWtub3duL3dlYmZp bmdlciB1c2luZyB0aGUgSFRUUFMgcHJvdG9jb2wuICBJZiBhbiBIVFRQUyBjb25uZWN0aW9uIGlz IG1hZGUsIGFuZCB0aGUgc2VydmVyIGhhcyBhbiBpbnZhbGlkIGNlcnRpZmljYXRlLCBvciByZXR1 cm5zIGFuIEhUVFAgc3RhdHVzIGNvZGUgaW5kaWNhdGluZyBhbiBlcnJvciwgdGhlIGNsaWVudCBz b2Z0d2FyZSBNVVNUIHJlcG9ydCBhbiBlcnJvciBhbmQgY2Vhc2UgYXR0ZW1wdGluZyB0byByZXRy aWV2ZSB0aGUgcmVzb3VyY2UuDQoNCklmIHRoZSBXZWJGaW5nZXIgY2xpZW50IHNvZnR3YXJlIGlz IHVuYWJsZSB0byBlc3RhYmxpc2ggYW4gSFRUUFMgY29ubmVjdGlvbiB0byB0aGUgc2VydmVyLCBi ZWhhdmlvciBkZXBlbmRzIG9uIHRoZSB2YWx1ZSBvZiB0aGUgYWxsb3ctZmFsbGJhY2sgcGFyYW1l dGVyLiAgSWYgdGhlIHZhbHVlIG9mIGFsbG93LWZhbGxiYWNrIGlzIHRydWUsIHRoZSBjbGllbnQg c29mdHdhcmUgTUFZIGZhbGwgYmFjayB0byB1bmVuY3J5cHRlZCBIVFRQIGluIGFuIGF0dGVtcHQg dG8gcmV0cmlldmUgLy53ZWxsLWtub3duL3dlYmZpbmdlci4gIElmIGFsbG93LWZhbGxiYWNrIGlz IGZhbHNlLCBjbGllbnQgc29mdHdhcmUgTVVTVCByZXBvcnQgYW4gZXJyb3IgYW5kIGNlYXNlIGF0 dGVtcHRpbmcgdG8gcmV0cmlldmUgdGhlIHJlc291cmNlLg0KDQoNCk9uIFN1biwgRGVjIDIsIDIw MTIgYXQgMTI6MjEgQU0sIFBhdWwgRS4gSm9uZXMgPHBhdS4uLkBwYWNrZXRpemVyLmNvbTxqYXZh c2NyaXB0Oj4+IHdyb3RlOg0KRm9sa3MsDQoNCkkgcHVibGlzaGVkIGFub3RoZXIgdmVyc2lvbiBv ZiB0aGUgV2ViRmluZ2VyIHNwZWMgdHJ5aW5nIHRvIGJyaW5nIGNsb3N1cmUgdG8gdGhlIHR3byBv cGVuIGlzc3VlcyBJIHNlZSAocmVzb3VyY2UgcmVwcmVzZW50YXRpb24gYW5kIHRyYW5zcG9ydCku ICBUaGUgbmV3IHZlcnNpb24gaXMgaGVyZToNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDcNCg0KV2l0aCByZXNwZWN0IHRvIHJlc291cmNl IHJlcHJlc2VudGF0aW9uLCBJIGZ1bGx5IGRlc2NyaWJlZCB0aGUgSlNPTiBSZXNvdXJjZSBEZXNj cmlwdG9yIHdpdGhpbiB0aGUgZG9jdW1lbnQuICBUaGVyZSBhcmUgbm8gZXh0ZXJuYWwgcmVmZXJl bmNlcyB0byBSRkMgNjQxNSBub3csIG5vIG5lZWQgdG8gZ28gcmVhZCB0aGUgWFJEIHNwZWMsIGV0 Yy4gIEl04oCZcyBhIGZhaXJseSBzaW1wbGUgZm9ybWF0IGFuZCBJIGJlbGlldmUgdGhpcyB0ZXh0 IGRvY3VtZW50cyBpdCBzdWZmaWNpZW50bHkuICBDb21iaW5lZCB3aXRoIHRoZSB2aXN1YWwgZXhh bXBsZXMsIEkgdGhpbmsgdGhpcyBtYWtlcyBpdCBwcmV0dHkgY2xlYXIuICBIYXZlIGEgbG9vayBh dCB0aGUgSlJEIGRvY3VtZW50YXRpb24gaW4gc2VjdGlvbiA1LjIgYW5kIHByb3ZpZGUgeW91ciBj b21tZW50cy4NCg0KV2l0aCByZXNwZWN0IHRvIEhUVFBTLCBpdCBzZWVtcyB0aGVyZSBpcyBzdHJv bmcgcHJlZmVyZW5jZSBmb3Ig4oCcSFRUUFMgb25seeKAnSwgYnV0IHNvbWUgYSBmYWlyIGJpdCBv ZiBpbnNpc3RlbmNlIGZvciBhbGxvd2luZyBIVFRQLiAgSSBjaGFuZ2VkIHRoZSB3b3JkaW5nIGlu IDUuMiB0byB0cnkgdG8gY2FwdHVyZSBvcGluaW9ucy4gIFByZXZpb3VzbHksIHRoZSB0ZXh0IGxl ZCB3aXRoIGEgcmVxdWlyZW1lbnQgdG8gdHJ5IEhUVFBTIGZpcnN0LiAgVGhhdCBpcyBzdGlsbCB0 aGVyZS4gIEkganVzdCBhZGRlZCBzb21lIGV4dHJhIGNvbmRpdGlvbnMgdGhhdCBtYWtlIGl0IGNs ZWFyZXIgdGhhdCB0aGVyZSBhcmUgc29tZSBpbnN0YW5jZXMgd2hlcmUgYSBjbGllbnQgbXVzdCBu b3QgdXRpbGl6ZSBIVFRQLiAgVGhpcyBtaWdodCBuZWVkIGZ1cnRoZXIgcmVmaW5lbWVudCwgYnV0 IEkgdGhpbmsgdGhlcmUgaXMgYSBiYWxhbmNlIHdlIGNhbiBzdHJpa2UgaGVyZSBiZXR3ZWVuIHRo ZSB0d28gY2FtcHMgd2l0aG91dCBpbnRyb2R1Y2luZyBhIGxvdCBvZiBjb21wbGV4IGxhbmd1YWdl Lg0KDQpJIG1hZGUgc29tZSBlZGl0b3JpYWwgY2hhbmdlcyB0aHJvdWdoIHRoZSBkb2N1bWVudC4N Cg0KQ29tbWVudHMgYXJlIHdlbGNvbWUsIGFzIGFsd2F5cy4gIFNlZW1zIEkgZG9u4oCZdCBuZWVk IHRvIHNheSB0aGF0IHRvIHRoaXMgZ3JvdXAsIHRob3VnaCA6LSkNCg0KUGF1bA0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQphcHBzLWRpc2N1c3Mg bWFpbGluZyBsaXN0DQphcHBzLWQuLi5AaWV0Zi5vcmc8amF2YXNjcmlwdDo+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0KDQpRdWVzdG8gbWVzc2Fn Z2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxs ZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRy YSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9u aSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1 ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBk YXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUg YWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwg Y29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJl dHVybiBlLW1haWwsIFRoYW5rcy4NCg0KW2NpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwM0BUSS5EaXNjbGFpbWVyXVJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVz dGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg0K --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5A21D5BGRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglwYW5vc2Ut MToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDIuMGNtIDIuMGNtIDIuMGNtO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNl Y3Rpb24xO30NCi0tPg0KPC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFG NDk3RCI+SSBhZ3JlZSB0aGVyZSBhcmUgY2xlYXIgdXNlIGNhc2VzIGZvciBib3RoLiBIb3dldmVy IGl0IG1heSBiZSBkaWZmaWN1bHQgdG8gc3RhdGUgZXhoYXVzdGl2ZWx5IHdoaWNoIGNhc2Ugd291 bGQgZml0IHdpdGggaHR0cCwgYW5kIHdoaWNoIG5vdCwNCiBzbyBJ4oCZZCByZWNvbW1lbmQgc3Rh eWluZyBnZW5lcmljIGFuZCBub3QgbWVudGlvbiBzcGVjaWZpYyBleGFtcGxlcy4gPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPmh0dHBzIHNob3VsZCBiZSBjb25z aWRlcmVkIGFzIGEgc2hvdWxkLCBidXQgdGhlcmUgYXJlIHZlcnkgdmFsaWQgdXNlIGNhc2VzIGZv ciB3aGljaCBpdCBpcyBub3QgbmVlZGVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPllldCBpbiBvdGhlciBjYXNlcyBhcyBJIHN0YXRlZCBlYXJsaWVyLCBo dHRwcyBjYW5ub3Qgd29yayBhdCBmaXJzdDogaW4gbW9zdCBtb2JpbGUgbmV0d29yayBpZGVudGlm aWNhdGlvbiBzeXN0ZW1zLCB0aGUgdXNlciBpZGVudGl0eSAocGhvbmUgbnVtYmVyKQ0KIGNhbiBv bmx5IGJlIHJlY29nbml6ZWQgb3ZlciBwbGFpbiBodHRwLiBUaGlzIG9mdGVuIHJlcXVpcmVzIHRv IGlzc3VlIGEgZmlyc3QgaHR0cCByZXF1ZXN0IChzb3J0IG9mIHByb2JlKSB0byBnZXQgdGhlIHNl cnZlciBzZXQgYSBjb29raWUsIGEgb25seSB0aGVuIHNlbmQgdGhlIGh0dHBzIHJlcXVlc3QgdG8g dGhlIHNhbWUgZW5kcG9pbnQgd2l0aCB0aGUgcHJldmlvdXMgY29va2llIGZvciBhc3NvY2lhdGlu ZyB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EYTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gYXBwcy1k aXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPlBlciBjb250byBkaSA8L2I+TWF0dGhpYXMgUGZlZmZlcmxlPGJyPg0KPGI+SW52 aWF0bzo8L2I+IGx1bmVkw6wgMyBkaWNlbWJyZSAyMDEyIDkuMzM8YnI+DQo8Yj5BOjwvYj4gd2Vi ZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb208YnI+DQo8Yj5DYzo8L2I+IGFwcHMtZGlzY3Vzc0BpZXRm Lm9yZzxicj4NCjxiPk9nZ2V0dG86PC9iPiBSZTogW2FwcHMtZGlzY3Vzc10gRHJhZnQgLTA3IG1v ZCBwcm9wb3NhbDogSFRUUFMgd2l0aCBmYWxsYmFjayBwYXJhbWV0ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyBpdCBpbXBvcnRhbnQgdG8gdGFsayBh Ym91dCAmcXVvdDtmYWxsYmFja3MmcXVvdDs/IFdvdWxkbid0IGl0IGJlIGVub3VnaCB0byBkZWZp bmUgJnF1b3Q7TVVTVCBVU0UmcXVvdDsgSFRUUCBmb3IgJnF1b3Q7aGFybWxlc3MmcXVvdDsgcXVl cmllcyBsaWtlIE9FeGNoYW5nZSwgRS1NYWlsIHRvIFByb2ZpbGUgbWFwcGluZyBvciBPU3RhdHVz LCBhbmQgJnF1b3Q7TVVTVCBVU0UmcXVvdDsgSFRUUFMgZm9yIE9wZW5JRCBDb25uZWN0IG9yIE9B dXRoPzxicj4NCjxicj4NCkFtIE1vbnRhZywgMy4gRGV6ZW1iZXIgMjAxMiAwMjoxNToxOSBVVEMm IzQzOzEgc2NocmllYiBUaW0gQnJheTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Q2hhbmdlIHBhcmFncmFwaCAyIG9mIHNl Y3Rpb24gNS4xIHRvIHJlYWQ6PGJyPg0KPGJyPg0KV2ViRmluZ2VyIGNsaWVudCBzb2Z0d2FyZSBN VVNUIGFjY2VwdCBhcyBpbnB1dCBhIGJvb2xlYW4gcGFyYW1ldGVyIHdoaWNoIGZvciB0aGUgcHVy cG9zZXMgb2YgdGhpcyBkaXNjdXNzaW9uIHdpbGwgYmUgcmVmZXJyZWQgYXMgJnF1b3Q7YWxsb3ct ZmFsbGJhY2smcXVvdDsuJm5ic3A7IElmIHRoaXMgcGFyYW1ldGVyIGlzIG5vdCBwcm92aWRlZCwg Y2xpZW50IHNvZnR3YXJlIE1VU1QgYmVoYXZlIGFzIGlmIGl0IHdlcmUgcHJlc2VudCB3aXRoIGEg dmFsdWUgb2YgZmFsc2UuPGJyPg0KPGJyPg0KV2ViRmluZ2VyIGNsaWVudCBzb2Z0d2FyZSBNVVNU IGF0dGVtcHQgdG8gcmV0cmlldmUgLy53ZWxsLWtub3duL3dlYmZpbmdlciB1c2luZyB0aGUgSFRU UFMgcHJvdG9jb2wuJm5ic3A7IElmIGFuIEhUVFBTIGNvbm5lY3Rpb24gaXMgbWFkZSwgYW5kIHRo ZSBzZXJ2ZXIgaGFzIGFuIGludmFsaWQgY2VydGlmaWNhdGUsIG9yIHJldHVybnMgYW4gSFRUUCBz dGF0dXMgY29kZSBpbmRpY2F0aW5nIGFuIGVycm9yLCB0aGUgY2xpZW50IHNvZnR3YXJlIE1VU1Qg cmVwb3J0DQogYW4gZXJyb3IgYW5kIGNlYXNlIGF0dGVtcHRpbmcgdG8gcmV0cmlldmUgdGhlIHJl c291cmNlLjxicj4NCjxicj4NCklmIHRoZSBXZWJGaW5nZXIgY2xpZW50IHNvZnR3YXJlIGlzIHVu YWJsZSB0byBlc3RhYmxpc2ggYW4gSFRUUFMgY29ubmVjdGlvbiB0byB0aGUgc2VydmVyLCBiZWhh dmlvciBkZXBlbmRzIG9uIHRoZSB2YWx1ZSBvZiB0aGUgYWxsb3ctZmFsbGJhY2sgcGFyYW1ldGVy LiZuYnNwOyBJZiB0aGUgdmFsdWUgb2YgYWxsb3ctZmFsbGJhY2sgaXMgdHJ1ZSwgdGhlIGNsaWVu dCBzb2Z0d2FyZSBNQVkgZmFsbCBiYWNrIHRvIHVuZW5jcnlwdGVkIEhUVFAgaW4gYW4gYXR0ZW1w dA0KIHRvIHJldHJpZXZlIC8ud2VsbC1rbm93bi93ZWJmaW5nZXIuJm5ic3A7IElmIGFsbG93LWZh bGxiYWNrIGlzIGZhbHNlLCBjbGllbnQgc29mdHdhcmUgTVVTVCByZXBvcnQgYW4gZXJyb3IgYW5k IGNlYXNlIGF0dGVtcHRpbmcgdG8gcmV0cmlldmUgdGhlIHJlc291cmNlLjxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwg RGVjIDIsIDIwMTIgYXQgMTI6MjEgQU0sIFBhdWwgRS4gSm9uZXMgJmx0OzxhIGhyZWY9ImphdmFz Y3JpcHQ6IiB0YXJnZXQ9Il9ibGFuayI+cGF1Li4uQHBhY2tldGl6ZXIuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPkZvbGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgcHVibGlz aGVkIGFub3RoZXIgdmVyc2lvbiBvZiB0aGUgV2ViRmluZ2VyIHNwZWMgdHJ5aW5nIHRvIGJyaW5n IGNsb3N1cmUgdG8gdGhlIHR3byBvcGVuIGlzc3VlcyBJIHNlZSAocmVzb3VyY2UgcmVwcmVzZW50 YXRpb24gYW5kIHRyYW5zcG9ydCkuJm5ic3A7IFRoZSBuZXcgdmVyc2lvbg0KIGlzIGhlcmU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBz YXdnLXdlYmZpbmdlci0wNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDc8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+V2l0aCByZXNwZWN0IHRvIHJlc291cmNlIHJlcHJlc2VudGF0aW9uLCBJIGZ1bGx5IGRl c2NyaWJlZCB0aGUgSlNPTiBSZXNvdXJjZSBEZXNjcmlwdG9yIHdpdGhpbiB0aGUgZG9jdW1lbnQu Jm5ic3A7IFRoZXJlIGFyZSBubyBleHRlcm5hbCByZWZlcmVuY2VzIHRvIFJGQyA2NDE1IG5vdywN CiBubyBuZWVkIHRvIGdvIHJlYWQgdGhlIFhSRCBzcGVjLCBldGMuICZuYnNwO0l04oCZcyBhIGZh aXJseSBzaW1wbGUgZm9ybWF0IGFuZCBJIGJlbGlldmUgdGhpcyB0ZXh0IGRvY3VtZW50cyBpdCBz dWZmaWNpZW50bHkuJm5ic3A7IENvbWJpbmVkIHdpdGggdGhlIHZpc3VhbCBleGFtcGxlcywgSSB0 aGluayB0aGlzIG1ha2VzIGl0IHByZXR0eSBjbGVhci4mbmJzcDsgSGF2ZSBhIGxvb2sgYXQgdGhl IEpSRCBkb2N1bWVudGF0aW9uIGluIHNlY3Rpb24gNS4yIGFuZCBwcm92aWRlIHlvdXINCiBjb21t ZW50cy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+V2l0aCByZXNwZWN0IHRvIEhUVFBTLCBpdCBz ZWVtcyB0aGVyZSBpcyBzdHJvbmcgcHJlZmVyZW5jZSBmb3Ig4oCcSFRUUFMgb25seeKAnSwgYnV0 IHNvbWUgYSBmYWlyIGJpdCBvZiBpbnNpc3RlbmNlIGZvciBhbGxvd2luZyBIVFRQLiZuYnNwOyBJ IGNoYW5nZWQgdGhlIHdvcmRpbmcgaW4gNS4yDQogdG8gdHJ5IHRvIGNhcHR1cmUgb3BpbmlvbnMu Jm5ic3A7IFByZXZpb3VzbHksIHRoZSB0ZXh0IGxlZCB3aXRoIGEgcmVxdWlyZW1lbnQgdG8gdHJ5 IEhUVFBTIGZpcnN0LiZuYnNwOyBUaGF0IGlzIHN0aWxsIHRoZXJlLiZuYnNwOyBJIGp1c3QgYWRk ZWQgc29tZSBleHRyYSBjb25kaXRpb25zIHRoYXQgbWFrZSBpdCBjbGVhcmVyIHRoYXQgdGhlcmUg YXJlIHNvbWUgaW5zdGFuY2VzIHdoZXJlIGEgY2xpZW50IG11c3Qgbm90IHV0aWxpemUgSFRUUC4m bmJzcDsgVGhpcyBtaWdodCBuZWVkDQogZnVydGhlciByZWZpbmVtZW50LCBidXQgSSB0aGluayB0 aGVyZSBpcyBhIGJhbGFuY2Ugd2UgY2FuIHN0cmlrZSBoZXJlIGJldHdlZW4gdGhlIHR3byBjYW1w cyB3aXRob3V0IGludHJvZHVjaW5nIGEgbG90IG9mIGNvbXBsZXggbGFuZ3VhZ2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+SSBtYWRlIHNvbWUgZWRpdG9yaWFsIGNoYW5nZXMgdGhyb3VnaCB0aGUg ZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q29tbWVudHMgYXJlIHdlbGNvbWUsIGFz IGFsd2F5cy4mbmJzcDsgU2VlbXMgSSBkb27igJl0IG5lZWQgdG8gc2F5IHRoYXQgdG8gdGhpcyBn cm91cCwgdGhvdWdoIDotKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+UGF1bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4 ODg4Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmFwcHMtZGlzY3Vz cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJqYXZhc2NyaXB0OiIgdGFyZ2V0PSJfYmxhbmsi PmFwcHMtZC4uLkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3VzcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPg0KPCEtLQ0Kc3Bhbi5HcmFt RSB7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5ZXM7fQ0KLS0+DQo8L3N0eWxlPg0K PHRhYmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJ3 aWR0aDo1ODVweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFsOyBmb250LXNpemU6MTJweDsg Y29sb3I6IzAwMDsgdGV4dC1hbGlnbjoganVzdGlmeSIgd2lkdGg9IjM5NSI+DQo8ZGl2IGFsaWdu PSJqdXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5OyBsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6VmVyZGFuYSI+UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25v IGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlm ZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxh IGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmll dGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9y ZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6 aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdy YXppZS4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8cCBhbGlnbj0ianVzdGlmeSI+PHNwYW4gY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTsgbGluZS1oZWlnaHQ6bm9y bWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5UaGlzIGUtbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToNCiAgNy41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpWZXJk YW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4mbmJzcDs8c3BhbiBjbGFzcz0iR3JhbUUiPmlz PC9zcGFuPiZuYnNwOzwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6DQogIDcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t R0IiPmNvbmZpZGVudGlhbA0KIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlp bmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlcg0KIGJ5IHJldHVy biBlLW1haWwsIFRoYW5rcy48L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNv LWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPg0KPC9zcGFuPjwvc3Bhbj48L3A+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0Ow0KICBmb250LWZhbWlseTpWZXJkYW5hIj48aW1nIHNyYz0iY2lk OjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRpc2NsYWltZXIiIGFsdD0icmlz cGV0dGEgbCdhbWJpZW50ZSIgd2lkdGg9IjI2IiBoZWlnaHQ9IjQwIj5SaXNwZXR0YSBsJ2FtYmll bnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uPC9zcGFu PjwvYj4NCjxwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5A21D5BGRFMBX704BA02_-- --_5f0cf300-325a-45c6-913e-eda67fce1dbf_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_5f0cf300-325a-45c6-913e-eda67fce1dbf_-- From nico@cryptonector.com Mon Dec 3 09:03:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB3B21F888E for ; Mon, 3 Dec 2012 09:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4fa0u9IGGKl for ; Mon, 3 Dec 2012 09:03:40 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id C89D321F86FA for ; Mon, 3 Dec 2012 09:03:40 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id E84561E069 for ; Mon, 3 Dec 2012 09:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=h9ybj4JZdEqObueu0Gfk 2RB6tIM=; b=Ylo+VHuf4Et0AjCpfSnJwiTxF0r/qFeVePyeviNyTJye5qCSwBQD WiHwRjfs/73VFvWGM69V19cgaK1Xnnm+DGpQ1MV4PBfewdEx70OSoL62o2SzfF3I XGmncfnbr2b3sBgdFwFZejkOAR4Zutp6Eqr1cKZfoq9AfRkJ3yBvxFo= Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id C4E661E05C for ; Mon, 3 Dec 2012 09:03:38 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4869471ieb.31 for ; Mon, 03 Dec 2012 09:03:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.7.135 with SMTP id j7mr6977453iga.34.1354554218413; Mon, 03 Dec 2012 09:03:38 -0800 (PST) Received: by 10.64.12.69 with HTTP; Mon, 3 Dec 2012 09:03:38 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 11:03:38 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:03:41 -0000 I'd rather say that the user of WF (an app, or a user through a user-agent) MUST decide whether it needs TLS. Having a fallback creates problems: we must then say that the user of WF must find out whether TLS was used and decide whether to continue or change how it handles the result. It seems easier to say that the user/app must know a priori whether it needs TLS. Nico -- From nico@cryptonector.com Mon Dec 3 09:04:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7640E21F88EC for ; Mon, 3 Dec 2012 09:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-S-sVJ-Gm0i for ; Mon, 3 Dec 2012 09:04:53 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 115D621F889D for ; Mon, 3 Dec 2012 09:04:53 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id CC66F20219B for ; Mon, 3 Dec 2012 09:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=4OnXpHxT0cPdrfLO85Ub uoZX/pw=; b=CxBSi2xGTg1iFe9s/lMWx//wgzs1kKpn5BNrbb/V/q2qSUR78QjR FTzObDXFRIyztuqwMRTGx7V+yiGHQcR0RsmckX4kh+m18L/eR0PdWJ0ScYAKtar6 fHquxTXX5GvoUHaK6hpQwrcP98osq6oweIdskpC5kgZD8vHwml0K7jM= Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id E8E452021A2 for ; Mon, 3 Dec 2012 09:00:26 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so4268297iea.38 for ; Mon, 03 Dec 2012 09:00:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.207.70 with SMTP id lu6mr6626578igc.50.1354554025535; Mon, 03 Dec 2012 09:00:25 -0800 (PST) Received: by 10.64.12.69 with HTTP; Mon, 3 Dec 2012 09:00:25 -0800 (PST) In-Reply-To: <09e101cdd135$544bfb70$fce3f250$@packetizer.com> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <078801cdd067$4cdfb2b0$e69f1810$@packetizer.com> <0BB05AB9-6D89-4CBC-8724-B1744BE95A94@gmail.com> <085801cdd103$ee1f2ce0$ca5d86a0$@packetizer.com> <2D7426FD-9A32-421E-AB6E-5FC5CD7D123C@gmail.com> <092801cdd129$16b09cf0$4411d6d0$@packetizer.com> <09e101cdd135$544bfb70$fce3f250$@packetizer.com> Date: Mon, 3 Dec 2012 11:00:25 -0600 Message-ID: From: Nico Williams To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Cc: Joseph Holsten , webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:04:53 -0000 Right, SNI is critical to being able to mandate TLS, and there's been enough lack of coverage on the installed client and server base that a number of hosting providers have refused to support TLS w/o per-domain IP addresses (which cost more). This is changing, slowly but surely. I will re-check with my hosting provider later today. Nico -- From cyrus@daboo.name Mon Dec 3 09:06:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D7421F88FE for ; Mon, 3 Dec 2012 09:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpoRC7K7aDVn for ; Mon, 3 Dec 2012 09:06:02 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 975F821F88EC for ; Mon, 3 Dec 2012 09:06:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0545E36D4731; Mon, 3 Dec 2012 12:06:02 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMc_dM8VW-SN; Mon, 3 Dec 2012 12:06:01 -0500 (EST) Received: from [17.45.162.221] (unknown [17.45.162.221]) by daboo.name (Postfix) with ESMTPSA id 8D4DA36D4723; Mon, 3 Dec 2012 12:05:59 -0500 (EST) Date: Mon, 03 Dec 2012 12:06:11 -0500 From: Cyrus Daboo To: Andrew Newton Message-ID: <44B101594E89AB885900B76D@cyrus.local> In-Reply-To: References: <26263E0AC2BA16FFBE9930DE@caldav.corp.apple.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=856 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Describing JSON document formats X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:06:03 -0000 Hi Andrew, --On December 3, 2012 11:49:02 AM -0500 Andrew Newton wrote: > I'll be updating the content rules draft soon. But regarding your > question about there being a right way, my opinion is that there need not > be only one way to do describe JSON. Like programming languages, schema > languages/formats should be used as appropriate. > > > Thanks for taking a look at the JSON content rules draft. Thanks for putting that draft together. I do prefer it amongst all the other JSON "schema" type proposals I have seen. If you have a chance I would appreciate you reviewing the usage in to make sure that looks right. Have you put together any sort of validation tool for the content rules syntax? It would be good to have something like that. -- Cyrus Daboo From jpanzer@google.com Mon Dec 3 09:29:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E8E21F8877 for ; Mon, 3 Dec 2012 09:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POikgx+hqKCG for ; Mon, 3 Dec 2012 09:29:21 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A896F21F8863 for ; Mon, 3 Dec 2012 09:29:17 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2541173lah.31 for ; Mon, 03 Dec 2012 09:29:16 -0800 (PST) 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=qSGwCzNJez6LJ8zUtzBQAZo++LgRZKi+a9Zcy/fNNOA=; b=lAR6qFZsEg1o0WcwGl1C1EikCt93E7kMyUV7o05dAlN3Bmtjn9d3o5ZEeaqUA17nr2 mFHzptu/1gEZ05WmUtd7XhekcxdCiJPCTSvOdbWBx9t0CUQqUH05AO6Dl0XR4DBxZri+ wLc1y0TwAq42s8gmbsGLC/fJdGK444x9ySdXfPepQKR8IsBXaXDSMJUS/wbopsfvUFYI ZrFkhyFK50PtZo3TgSYdGEtAw+U8yzXYqrInHY/r3Qiap9wRh6PtXwhcHjUBEVaO5tu7 8CzUGnvjkMPy23lZ9UIGWHJiethTiJ6R04nWCiuHVYkWafilrgetNp5/jEPFRoRa/KbB tqwg== X-Google-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:x-gm-message-state; bh=qSGwCzNJez6LJ8zUtzBQAZo++LgRZKi+a9Zcy/fNNOA=; b=G+YvE4J7roNEJK18PLkpUlD6NM6yp/FgCrP5MuWgqh71+bOGE+Shn8geAsRr3hldpw qTWaxK3sPZyqLeOxNUkIbZ3yGePvOIsUf3GWl6Q5VxHTs9RLf0dzCHHhLV45Twr8pEYu 6uLllhWNdI6OkO3cwXOYzhL9ArLFEEm8BdWe4AoBKKRdbRbpA9OEy/iBcrHITen6Yygt NvfMRqS6e9whbYDVVoIDe4wBYM8UyVxxcPpOMgW90eKFNlSVNUEaPRmG8iFgWasGP6wy 0QWUdAWeUQtFtvNci4iAbbTjZ1XZIHQJCsd2HwFBX+rzzwtSrx4CFlAIgcPPnnR2jUZf 29WA== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr10117608lab.11.1354555756546; Mon, 03 Dec 2012 09:29:16 -0800 (PST) Received: by 10.114.4.197 with HTTP; Mon, 3 Dec 2012 09:29:16 -0800 (PST) Received: by 10.114.4.197 with HTTP; Mon, 3 Dec 2012 09:29:16 -0800 (PST) In-Reply-To: <928b5960-107a-4052-977f-e8513ac32e5e@googlegroups.com> References: <928b5960-107a-4052-977f-e8513ac32e5e@googlegroups.com> Date: Mon, 3 Dec 2012 09:29:16 -0800 Message-ID: From: John Panzer To: Matthias Pfefferle Content-Type: multipart/alternative; boundary=f46d04088ef5b28b8704cff6160f X-Gm-Message-State: ALoCoQkR90239peHrf+fzjFSdDMWR5qxeSb9w+6T9b4/7qJW5oSDfYsrzQCTKSal5K4C4GlSVpXzkOZ1ZcmhHWknvY8hG4D8BhnVsbrFUG6blOYRJshQUJ5cynkeG9tj64qCxKwOxqaw1DmwNUXh3wVReKEvw6B5drHrhgO8p8n0tyQM+4oMkmG2784FOjC+jDkT6oIJi8IY Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:29:22 -0000 --f46d04088ef5b28b8704cff6160f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I dislike the assumption that contact information is "harmless if hacked". One attack scenario: Imagine I can poison the DNS of a small company. I ask for a password reset for Tim Bray, but tell them my email is down. I return my own telephone number and IM contact info instead of Tim's via Webfinger. Support personnel call me on "Tim's" number and I verify I'm him. I gain control of his account, use that to bootstrap to gain information about other accounts... etc. It's less likely than an interception attack at an internet cafe. I don't feel competent to say how much less likely. On Dec 3, 2012 8:39 AM, "Matthias Pfefferle" wrote: > Is it important to talk about "fallbacks"? Wouldn't it be enough to defin= e > "MUST USE" HTTP for "harmless" queries like OExchange, E-Mail to Profile > mapping or OStatus, and "MUST USE" HTTPS for OpenID Connect or OAuth? > > Am Montag, 3. Dezember 2012 02:15:19 UTC+1 schrieb Tim Bray: >> >> Change paragraph 2 of section 5.1 to read: >> >> WebFinger client software MUST accept as input a boolean parameter which >> for the purposes of this discussion will be referred as "allow-fallback"= . >> If this parameter is not provided, client software MUST behave as if it >> were present with a value of false. >> >> WebFinger client software MUST attempt to retrieve /.well-known/webfinge= r >> using the HTTPS protocol. If an HTTPS connection is made, and the serve= r >> has an invalid certificate, or returns an HTTP status code indicating an >> error, the client software MUST report an error and cease attempting to >> retrieve the resource. >> >> If the WebFinger client software is unable to establish an HTTPS >> connection to the server, behavior depends on the value of the allow- >> fallback parameter. If the value of allow-fallback is true, the client >> software MAY fall back to unencrypted HTTP in an attempt to retrieve >> /.well-known/webfinger. If allow-fallback is false, client software >> MUST report an error and cease attempting to retrieve the resource. >> >> >> >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wr= ote: >> >>> Folks,**** >>> >>> ** ** >>> >>> I published another version of the WebFinger spec trying to bring >>> closure to the two open issues I see (resource representation and >>> transport). The new version is here:**** >>> >>> http://tools.ietf.org/html/**draft-ietf-appsawg-webfinger-**07 >>> **** >>> >>> ** ** >>> >>> With respect to resource representation, I fully described the JSON >>> Resource Descriptor within the document. There are no external referen= ces >>> to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly >>> simple format and I believe this text documents it sufficiently. Combi= ned >>> with the visual examples, I think this makes it pretty clear. Have a l= ook >>> at the JRD documentation in section 5.2 and provide your comments. **** >>> >>> ** ** >>> >>> With respect to HTTPS, it seems there is strong preference for =93HTTPS >>> only=94, but some a fair bit of insistence for allowing HTTP. I change= d the >>> wording in 5.2 to try to capture opinions. Previously, the text led wi= th a >>> requirement to try HTTPS first. That is still there. I just added som= e >>> extra conditions that make it clearer that there are some instances whe= re a >>> client must not utilize HTTP. This might need further refinement, but = I >>> think there is a balance we can strike here between the two camps witho= ut >>> introducing a lot of complex language.**** >>> >>> ** ** >>> >>> I made some editorial changes through the document.**** >>> >>> ** ** >>> >>> Comments are welcome, as always. Seems I don=92t need to say that to t= his >>> group, though :-)**** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> ______________________________**_________________ >>> apps-discuss mailing list >>> apps-d...@ietf.org >>> https://www.ietf.org/mailman/**listinfo/apps-discuss >>> >>> >> > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d04088ef5b28b8704cff6160f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I dislike the assumption that contact information is "h= armless if hacked".

One attack scenario:=A0 Imagine I can poison the DNS of a sm= all company.=A0 I ask for a password reset for Tim Bray, but tell them my e= mail is down.=A0 I return my own telephone number and IM contact info inste= ad of Tim's via Webfinger.=A0 Support personnel call me on "Tim= 9;s" number and I verify I'm him.=A0 I gain control of his account= , use that to bootstrap to gain information about other accounts... etc.

It's less likely than an interception attack at an inter= net cafe.=A0 I don't feel competent to say how much less likely.

On Dec 3, 2012 8:39 AM, "Matthias Pfefferle= " <matthias@pfefferle.org= > wrote:
Is it important to talk about "fallbacks"? Wouldn't it be eno= ugh to define "MUST USE" HTTP for "harmless" queries li= ke OExchange, E-Mail to Profile mapping or OStatus, and "MUST USE"= ; HTTPS for OpenID Connect or OAuth?

Am Montag, 3. Dezember 2012 02:15:19 UTC+1 schrieb Tim Bray:Change paragraph 2 of section 5.1 to read:

WebFinger client software MUST accept as input a boolean parameter whic= h for the purposes of this discussion will be referred as "allow-= fallback".=A0 If this parameter is not provided, client softwar= e MUST behave as if it were present with a value of false.

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using=20 the HTTPS protocol.=A0 If an HTTPS connection is made, and the server has= =20 an invalid certificate, or returns an HTTP status code indicating an=20 error, the client software MUST report an error and cease attempting to=20 retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS=20 connection to the server, behavior depends on the value of the allow-= fallback parameter.=A0 If the value of allow-fallback i= s true, the client software MAY fall back to unen= crypted HTTP in an attempt to retrieve /.well-known/webfinger.=A0 If allow-= fallback is false, client software MUST report an error and ce= ase attempting to retrieve the resource.



On Sun, Dec 2, 2012 at 12:21 AM, Pau= l E. Jones <pau...@packetizer.com> wr= ote:

Folks,

=A0

I published another version of the WebFinger spec tryin= g to bring closure to the two open issues I see (resource representation an= d transport).=A0 The new version is here:

http://tools.ietf.org/html/draf= t-ietf-appsawg-webfinger-07

=A0

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=A0 There are no ex= ternal references to RFC 6415 now, no need to go read the XRD spec, etc. = =A0It=92s a fairly simple format and I believe this text documents it suffi= ciently.=A0 Combined with the visual examples, I think this makes it pretty= clear.=A0 Have a look at the JRD documentation in section 5.2 and provide = your comments.

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)

=A0

<= p class=3D"MsoNormal">Paul

= =A0


______________________________<= u>_________________
apps-discuss mailing list
apps-d...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d04088ef5b28b8704cff6160f-- From andy@hxr.us Mon Dec 3 09:33:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF1A21F8715 for ; Mon, 3 Dec 2012 09:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94wu2cuWwMhB for ; Mon, 3 Dec 2012 09:33:50 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6F1F21F86CE for ; Mon, 3 Dec 2012 09:33:49 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2659718lbk.31 for ; Mon, 03 Dec 2012 09:33:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Xf1pw2u1jx7WBwvfvZK+j6hPq3iHhO9hDvFsL9On3O0=; b=GP3AJQ5OJ0jYL9Fh7a1LU4dL1IUuJyGBx+0x0uJNqGhpJ84Gs0LWwf1gRslgtieNHX yWETPmW5ZONgZE7x6l8wMCbxs+utopSgAki9B2NfferwS+arcjqZHxxFlfUUglLr28zb z6inRDJfeb0dwuIoqRgDyJp90Ai+a04dNWy5sQr32wlf7FxcitnYSWnJevcDhuOIwBnj z6xLmR5uwqa0x9NwbBIDBvOV19Rv4d918DJmSHYcMVt6rx3dWB/lsbMrHEwRD7HOkrLC pOEYQnWn+Z6eDpySPHxvBKuDJqa5e1CyWn7jZgWxU32uQurukPvRViJG2DnPQLOuUX/y gj0g== MIME-Version: 1.0 Received: by 10.152.106.237 with SMTP id gx13mr9992860lab.46.1354556028729; Mon, 03 Dec 2012 09:33:48 -0800 (PST) Received: by 10.112.12.52 with HTTP; Mon, 3 Dec 2012 09:33:48 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: <44B101594E89AB885900B76D@cyrus.local> References: <26263E0AC2BA16FFBE9930DE@caldav.corp.apple.com> <44B101594E89AB885900B76D@cyrus.local> Date: Mon, 3 Dec 2012 12:33:48 -0500 Message-ID: From: Andrew Newton To: Cyrus Daboo Content-Type: multipart/alternative; boundary=f46d04071613ebbb2904cff62631 X-Gm-Message-State: ALoCoQmxNMauEF7LVtxb/tu0uC/B64UszOUHV6upPG11aOs0BZAVxKxSMJSrZiLwJnvB3vWkyQhA Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Describing JSON document formats X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:33:51 -0000 --f46d04071613ebbb2904cff62631 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 3, 2012 at 12:06 PM, Cyrus Daboo wrote: > Thanks for putting that draft together. I do prefer it amongst all the > other JSON "schema" type proposals I have seen. If you have a chance I > would appreciate you reviewing the usage in **doc/draft-douglass-timezone-**service/> > to make sure that looks right. > > Yes, I'll do that shortly. > Have you put together any sort of validation tool for the content rules > syntax? It would be good to have something like that. > Not yet, but I'm looking into it. -andy --f46d04071613ebbb2904cff62631 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 3= , 2012 at 12:06 PM, Cyrus Daboo <cyrus@daboo.name> wrote:
=
Thanks for putting that draft together. I do prefer it amo= ngst all the other JSON "schema" type proposals I have seen. If y= ou have a chance I would appreciate you reviewing the usage in <https://datatracker.ietf.org/doc/draft-douglass-timezo= ne-service/> to make sure that looks right.


Yes, I'll do that shortly.
=A0
Have you put together any sort of validation tool for the content rules syn= tax? It would be good to have something like that.
=
Not yet, but I'm looking into it.<= /div>

-andy
--f46d04071613ebbb2904cff62631-- From stpeter@stpeter.im Mon Dec 3 09:35:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4E521F8862 for ; Mon, 3 Dec 2012 09:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id carc1GcvfPZ3 for ; Mon, 3 Dec 2012 09:35:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 921E521F8715 for ; Mon, 3 Dec 2012 09:35:11 -0800 (PST) Received: from [10.154.128.144] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6A80540410; Mon, 3 Dec 2012 10:40:24 -0700 (MST) Message-ID: <50BCE2CE.6000202@stpeter.im> Date: Mon, 03 Dec 2012 09:35:10 -0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@googlegroups.com References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:35:12 -0000 I agree there's no need to wait on the 'acct' scheme -- in fact it might be done before the WebFinger draft. There was some contention about whether 'acct' is tied to WebFinger. My sense is still that 'acct' is an independent thing, used by WebFinger but usable by other technologies. Feedback on that issue is still welcome. In any case I'll review the 'acct' spec again in the next few days and request further input on the uri-review list ASAP, in accordance with RFC 4395. Peter On 12/2/12 9:51 PM, James M Snell wrote: > -1 ... I believe the utility of the acct scheme when used with WF is > readily apparent, and honestly there's no reason to "wait" for acct to > be finished. If we complete work on WF before acct is done, the only > real impact is that we wait a bit longer for WF to get an RFC#. > Implementors can still get started doing their thing. > > (I do agree that WF is useful with non acct uri's too tho) > > - James > > > On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray > wrote: > > I don’t want to wait for work on this to be completed, and I don’t > think that its presence is necessary for WebFinger to be useful. So > let's take it out. > > Proposal: > Section 4.1: Change the URI in the example from acct: to mailto: > Section 4.2: Same > Section 5.3: Same > Section 5.4: s/it could be an "acct" URI [7], // > Section 5.4: Remove 2nd para, beginning "For resources associated > with a user account at a host...“ > Section 5.4: s/both an "acct" URI and any alias/any alias/ > Section 8: Change the URI in the example from acct: to mailto: > > > On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray > wrote: > > No, we’re on the same side here. I’m suggesting taking > webfinger-07 as a baseline, and all *future* changes need to be > proposed as a concrete delta against it. -T > > > On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones > > wrote: > > Tim,____ > > __ __ > > I didn’t mean to be rude by introducing these changes, just > trying to move things along. Most changes were fairly > trivial, not worth mentioning, and can be seen here:____ > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-appsawg-webfinger-07.txt____ > > __ __ > > The most significant changes were the re-write of section > 5.2 and modification to the language related to HTTPS in > 5.1. I suspect that is the text to which you refer as > preferring it to be “camera-readyâ€. (I would assume the > balance of the changes would not need to be presented as > “camera-readyâ€, since they’re minor editorial things.)____ > > __ __ > > In any case, the most important text changes I would like > folks to consider is section 5.2 (which aims to fully > document the JSON Resource Descriptor object) and paragraphs > 2 and 3 in section 5.1.____ > > __ __ > > Paul____ > > __ __ > > *From:*Tim Bray [mailto:tbray@textuality.com > ] > *Sent:* Sunday, December 02, 2012 2:54 PM > *To:* Paul E. Jones > *Cc:* apps-discuss@ietf.org ; > webfinger@googlegroups.com > *Subject:* Re: [apps-discuss] > draft-ietf-appsawg-webfinger-07____ > > __ __ > > Thanks to Paul for the extra effort. I’d like to suggest, > in the interests of courtesy and efficiency, that from here > on on, contributions to this discussion be “camera-readyâ€, > that is to say, specific suggestions in the style of a diff, > including fully-written-out replacements language. > > -Tim____ > > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones > > > wrote:____ > > Folks,____ > > ____ > > I published another version of the WebFinger spec trying to > bring closure to the two open issues I see (resource > representation and transport). The new version is here:____ > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07____ > > ____ > > With respect to resource representation, I fully described > the JSON Resource Descriptor within the document. There are > no external references to RFC 6415 now, no need to go read > the XRD spec, etc. It’s a fairly simple format and I > believe this text documents it sufficiently. Combined with > the visual examples, I think this makes it pretty clear. > Have a look at the JRD documentation in section 5.2 and > provide your comments. ____ > > ____ > > With respect to HTTPS, it seems there is strong preference > for “HTTPS onlyâ€, but some a fair bit of insistence for > allowing HTTP. I changed the wording in 5.2 to try to > capture opinions. Previously, the text led with a > requirement to try HTTPS first. That is still there. I > just added some extra conditions that make it clearer that > there are some instances where a client must not utilize > HTTP. This might need further refinement, but I think there > is a balance we can strike here between the two camps > without introducing a lot of complex language.____ > > ____ > > I made some editorial changes through the document.____ > > ____ > > Comments are welcome, as always. Seems I don’t need to say > that to this group, though :-)____ > > ____ > > Paul____ From nico@cryptonector.com Mon Dec 3 09:37:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2B121F885B for ; Mon, 3 Dec 2012 09:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPDZoyRX0M9M for ; Mon, 3 Dec 2012 09:37:35 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC9421F880A for ; Mon, 3 Dec 2012 09:37:34 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 5CAFA508072 for ; Mon, 3 Dec 2012 09:37:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=PRUxP7S9DjCpaShBIiRa jjWbSr0=; b=X/2tudXajYTJ8XDQ24u6961suHSSh4n4Ed0pYQcadszdF9o/PRED +dTK2ORL2+iZeXQouV0o4miJ62vA8LrdM3h0NWykW8yYN8Tkfse257e+Vee2Kb1Y nUqBZ8AASnD+OXqdzrVWRQnz7aorOrIfuINwOPAxqY3jNdhOj4Vq22g= Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 3DDEA508064 for ; Mon, 3 Dec 2012 09:37:31 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2530441iaz.31 for ; Mon, 03 Dec 2012 09:37:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.201.201 with SMTP id fb9mr8555326icb.19.1354556250838; Mon, 03 Dec 2012 09:37:30 -0800 (PST) Received: by 10.64.12.69 with HTTP; Mon, 3 Dec 2012 09:37:30 -0800 (PST) In-Reply-To: References: <928b5960-107a-4052-977f-e8513ac32e5e@googlegroups.com> Date: Mon, 3 Dec 2012 11:37:30 -0600 Message-ID: From: Nico Williams To: John Panzer Content-Type: text/plain; charset=UTF-8 Cc: Matthias Pfefferle , webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:37:36 -0000 On Mon, Dec 3, 2012 at 11:29 AM, John Panzer wrote: > I dislike the assumption that contact information is "harmless if hacked". Indeed. That doesn't mean that WF is useless w/o TLS. > One attack scenario: Imagine I can poison the DNS of a small company. I > ask for a password reset for Tim Bray, but tell them my email is down. I > return my own telephone number and IM contact info instead of Tim's via > Webfinger. Support personnel call me on "Tim's" number and I verify I'm > him. I gain control of his account, use that to bootstrap to gain > information about other accounts... etc. Support personnel are a type of user/app that must use TLS for fetching any resources involved in authenticating a customer. > It's less likely than an interception attack at an internet cafe. I don't > feel competent to say how much less likely. I'd say it's more likely, not less. Nico -- From nico@cryptonector.com Mon Dec 3 09:38:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A31021F8862 for ; Mon, 3 Dec 2012 09:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGiXdt1UDXBH for ; Mon, 3 Dec 2012 09:38:20 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 96D3421F885B for ; Mon, 3 Dec 2012 09:38:20 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 5C278594061 for ; Mon, 3 Dec 2012 09:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=VM0Vtu0Oc5QqT1gjpIGg 2j9D1pA=; b=jStYSEJQIOlkbK2S/Y4YrQ/VhUL98pdG6XRUXzg9u7e3CJX2/oXe Qx9F13JMy02TZ+rXdDJFeUFT/z/sTiNhZ+rP13zCLDZYhoLuht6yFCWHwFDyN0JD 4WFDABWVgv6jY5E+8oXowsoFgH1ZUJn0RWarzYQn4vew2cT5tjy2ZJQ= Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 3926359405E for ; Mon, 3 Dec 2012 09:38:20 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4944661ieb.31 for ; Mon, 03 Dec 2012 09:38:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.53.193 with SMTP id d1mr7129256igp.69.1354556299824; Mon, 03 Dec 2012 09:38:19 -0800 (PST) Received: by 10.64.12.69 with HTTP; Mon, 3 Dec 2012 09:38:19 -0800 (PST) In-Reply-To: <50BCE2CE.6000202@stpeter.im> References: <50BCE2CE.6000202@stpeter.im> Date: Mon, 3 Dec 2012 11:38:19 -0600 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: webfinger@googlegroups.com, IETF Apps Discuss Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:38:21 -0000 On Mon, Dec 3, 2012 at 11:35 AM, Peter Saint-Andre wrote: > I agree there's no need to wait on the 'acct' scheme -- in fact it might > be done before the WebFinger draft. There was some contention about > whether 'acct' is tied to WebFinger. My sense is still that 'acct' is an > independent thing, used by WebFinger but usable by other technologies. > Feedback on that issue is still welcome. +1 From melvincarvalho@gmail.com Mon Dec 3 09:46:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D17E21F88DE for ; Mon, 3 Dec 2012 09:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VW4CAKbnK2o for ; Mon, 3 Dec 2012 09:46:58 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2C221F889D for ; Mon, 3 Dec 2012 09:46:58 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so4203507ieb.25 for ; Mon, 03 Dec 2012 09:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iZsAcQClDeI3lXsaX198Hs7PEPKjoI7Hm56SEd/QHUQ=; b=KvCChugW+kqJGCuEDkoE23NsF3lkJ3Qrc5+j49B/1RVwFh0ugIy2xasbXoGzqHeXQi cRg3rr/lK3AMp+cHKwJStY/roVps32cFyRZTMJbFn02Etma+p1PC8QKYuNenyF/FpWQ3 3bxgab/9vz0ozg6W2Dd+D4w7/aF0ju+d4dcxOhWX/GbCH/eXP/r1H7sKBWpl61SzuMDp F9Q/KpMi82R9fJy83VjF+qizxlGAf5EVDMiodX8WsF/eal1YsvYnFg6kssLCzFcBlz24 he2kh0kyoP6ih53FAPG7oaN6HL2NMFWfLa5dv98A2F0RIf2asYu2P6R+JS7agtatWQj/ J+hw== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr7008170igk.41.1354556817965; Mon, 03 Dec 2012 09:46:57 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 3 Dec 2012 09:46:57 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 18:46:57 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=14dae9340901f6826604cff655e5 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:46:59 -0000 --14dae9340901f6826604cff655e5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3 December 2012 02:14, Tim Bray wrote: > I don=92t want to wait for work on this to be completed, and I don=92t th= ink > that its presence is necessary for WebFinger to be useful. So let's take > it out. > > Proposal: > Section 4.1: Change the URI in the example from acct: to mailto: > Section 4.2: Same > Section 5.3: Same > Section 5.4: s/it could be an "acct" URI [7], // > Section 5.4: Remove 2nd para, beginning "For resources associated with a > user account at a host...=93 > Section 5.4: s/both an "acct" URI and any alias/any alias/ > Section 8: Change the URI in the example from acct: to mailto: > +1 mailto (as either a direct or indirect identifier as per awww) should be used in all cases, acct: is not only extraneous, it conflates the user@hostpattern that 99% of clients will interpret as mailto:as of today, it opens the door to one uri scheme per concept e.g. user: and others which dilute the name space, triggering a potential land grab and it's simply confusing to developers SWD had a formulation that contained only mailto: which was cleaner imho > > > On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: > >> No, we=92re on the same side here. I=92m suggesting taking webfinger-07 = as a >> baseline, and all *future* changes need to be proposed as a concrete del= ta >> against it. -T >> >> >> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones wr= ote: >> >>> Tim,**** >>> >>> ** ** >>> >>> I didn=92t mean to be rude by introducing these changes, just trying to >>> move things along. Most changes were fairly trivial, not worth mention= ing, >>> and can be seen here:**** >>> >>> >>> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-app= sawg-webfinger-07.txt >>> **** >>> >>> ** ** >>> >>> The most significant changes were the re-write of section 5.2 and >>> modification to the language related to HTTPS in 5.1. I suspect that i= s >>> the text to which you refer as preferring it to be =93camera-ready=94. = (I >>> would assume the balance of the changes would not need to be presented = as >>> =93camera-ready=94, since they=92re minor editorial things.)**** >>> >>> ** ** >>> >>> In any case, the most important text changes I would like folks to >>> consider is section 5.2 (which aims to fully document the JSON Resource >>> Descriptor object) and paragraphs 2 and 3 in section 5.1.**** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> *From:* Tim Bray [mailto:tbray@textuality.com] >>> *Sent:* Sunday, December 02, 2012 2:54 PM >>> *To:* Paul E. Jones >>> *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com >>> *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-07**** >>> >>> ** ** >>> >>> Thanks to Paul for the extra effort. I=92d like to suggest, in the >>> interests of courtesy and efficiency, that from here on on, contributio= ns >>> to this discussion be =93camera-ready=94, that is to say, specific sugg= estions >>> in the style of a diff, including fully-written-out replacements langua= ge. >>> >>> -Tim**** >>> >>> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones >>> wrote:**** >>> >>> Folks,**** >>> >>> **** >>> >>> I published another version of the WebFinger spec trying to bring >>> closure to the two open issues I see (resource representation and >>> transport). The new version is here:**** >>> >>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >>> >>> **** >>> >>> With respect to resource representation, I fully described the JSON >>> Resource Descriptor within the document. There are no external referen= ces >>> to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly >>> simple format and I believe this text documents it sufficiently. Combi= ned >>> with the visual examples, I think this makes it pretty clear. Have a l= ook >>> at the JRD documentation in section 5.2 and provide your comments. **** >>> >>> **** >>> >>> With respect to HTTPS, it seems there is strong preference for =93HTTPS >>> only=94, but some a fair bit of insistence for allowing HTTP. I change= d the >>> wording in 5.2 to try to capture opinions. Previously, the text led wi= th a >>> requirement to try HTTPS first. That is still there. I just added som= e >>> extra conditions that make it clearer that there are some instances whe= re a >>> client must not utilize HTTP. This might need further refinement, but = I >>> think there is a balance we can strike here between the two camps witho= ut >>> introducing a lot of complex language.**** >>> >>> **** >>> >>> I made some editorial changes through the document.**** >>> >>> **** >>> >>> Comments are welcome, as always. Seems I don=92t need to say that to t= his >>> group, though :-)**** >>> >>> **** >>> >>> Paul**** >>> >>> **** >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss**** >>> >>> ** ** >>> >> >> > --14dae9340901f6826604cff655e5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 3 December 2012 02:14, Tim Bray <= tbray@textuality.com> wrote:


On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray <tbray@textuality.com><= /span> wrote:
No, we=92re on the same side here. I=92m sug= gesting taking webfinger-07 as a baseline, and all *future* changes need to= be proposed as a concrete delta against it.=A0 -T


On Sun, Dec 2, 2012 at 12:59 PM, Pa= ul E. Jones <paulej@packetizer.com> wrote:

Tim,

=A0<= /p>

I didn=92t mean to be = rude by introducing these changes, just trying to move things along.=A0 Mos= t changes were fairly trivial, not worth mentioning, and can be seen here:<= u>

http://tools.ietf.org/rfcdiff?difftype=3D--hwdif= f&url2=3Ddraft-ietf-appsawg-webfinger-07.txt

=A0<= /p>

The most significant c= hanges were the re-write of section 5.2 and modification to the language re= lated to HTTPS in 5.1.=A0 I suspect that is the text to which you refer as = preferring it to be =93camera-ready=94.=A0 (I would assume the balance of t= he changes would not need to be presented as =93camera-ready=94, since they= =92re minor editorial things.)

=A0<= /p>

In any case, the most = important text changes I would like folks to consider is section 5.2 (which= aims to fully document the JSON Resource Descriptor object) and paragraphs= 2 and 3 in section 5.1.

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. Jones<= br>Cc: ap= ps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07

=A0<= /u>

Thanks to Paul= for the extra effort.=A0 I=92d like to suggest, in the interests of courte= sy and efficiency, that from here on on, contributions to this discussion b= e =93camera-ready=94, that is to say, specific suggestions in the style of = a diff, including fully-written-out replacements language.

=A0-Tim

On Sun, Dec 2, 201= 2 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

I published another version of the W= ebFinger spec trying to bring closure to the two open issues I see (resourc= e representation and transport).=A0 The new version is here:<= /p>

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=A0=

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=A0 There are no ex= ternal references to RFC 6415 now, no need to go read the XRD spec, etc. = =A0It=92s a fairly simple format and I believe this text documents it suffi= ciently.=A0 Combined with the visual examples, I think this makes it pretty= clear.=A0 Have a look at the JRD documentation in section 5.2 and provide = your comments.

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)=

=A0

Paul

=A0


_____= __________________________________________
apps-discuss mailing list
= apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=A0




--14dae9340901f6826604cff655e5-- From melvincarvalho@gmail.com Mon Dec 3 09:48:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0229421F8905 for ; Mon, 3 Dec 2012 09:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0GjdPPsl86f for ; Mon, 3 Dec 2012 09:48:55 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7E3A21F88DF for ; Mon, 3 Dec 2012 09:48:54 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4963618ieb.31 for ; Mon, 03 Dec 2012 09:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VDHbj2Xxv1RQCN7NpiAXDfEQcsTdQa0+c5zkIH1a48I=; b=h8zvTQa6penhOwVSBmnKnI9Hf2xdjRwIiEiR1wdSXhhR2n0k0EsZPgtjiOCLxPnBgR BGibwPrUs/oSQ801qTFYlsygCv4UctUqRvuxs0St8hYh7qm84PvpPHA95gTV7zWp9Ekr ZR0dIMKlNgF9ckt8Wp5ACK84L1uMYWXCKbQj/JBB4vD/iyXPhqLghv1+yYkStJ9K75IY 6eCHWDyoD9O8ZuTsmesBR7G4HiHNAL2gU8YhuO7cLymJ2YjkycoovZeCHguVrm/Nzu0s gChI6Mh++mD9yvfTzJI1yc+vRRw8VZb5zBmBlaHYusPid6357mG9KsjOvvyQDtCgzAS3 ++nQ== MIME-Version: 1.0 Received: by 10.50.108.145 with SMTP id hk17mr7180304igb.51.1354556934288; Mon, 03 Dec 2012 09:48:54 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 3 Dec 2012 09:48:54 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 18:48:54 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d0402a9f3e5752e04cff65cec Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:48:56 -0000 --f46d0402a9f3e5752e04cff65cec Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3 December 2012 02:35, Brad Fitzpatrick wrote: > -1. I feel strongly for keeping the acct: scheme. WebFinger isn't just > about email. > If Webfinger isnt just about email. What else is it about? > > > On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > >> I don=92t want to wait for work on this to be completed, and I don=92t t= hink >> that its presence is necessary for WebFinger to be useful. So let's tak= e >> it out. >> >> Proposal: >> Section 4.1: Change the URI in the example from acct: to mailto: >> Section 4.2: Same >> Section 5.3: Same >> Section 5.4: s/it could be an "acct" URI [7], // >> Section 5.4: Remove 2nd para, beginning "For resources associated with a >> user account at a host...=93 >> Section 5.4: s/both an "acct" URI and any alias/any alias/ >> Section 8: Change the URI in the example from acct: to mailto: >> >> >> On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: >> >>> No, we=92re on the same side here. I=92m suggesting taking webfinger-07= as a >>> baseline, and all *future* changes need to be proposed as a concrete de= lta >>> against it. -T >>> >>> >>> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones w= rote: >>> >>>> Tim,**** >>>> >>>> ** ** >>>> >>>> I didn=92t mean to be rude by introducing these changes, just trying t= o >>>> move things along. Most changes were fairly trivial, not worth mentio= ning, >>>> and can be seen here:**** >>>> >>>> >>>> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-ap= psawg-webfinger-07.txt >>>> **** >>>> >>>> ** ** >>>> >>>> The most significant changes were the re-write of section 5.2 and >>>> modification to the language related to HTTPS in 5.1. I suspect that = is >>>> the text to which you refer as preferring it to be =93camera-ready=94.= (I >>>> would assume the balance of the changes would not need to be presented= as >>>> =93camera-ready=94, since they=92re minor editorial things.)**** >>>> >>>> ** ** >>>> >>>> In any case, the most important text changes I would like folks to >>>> consider is section 5.2 (which aims to fully document the JSON Resourc= e >>>> Descriptor object) and paragraphs 2 and 3 in section 5.1.**** >>>> >>>> ** ** >>>> >>>> Paul**** >>>> >>>> ** ** >>>> >>>> *From:* Tim Bray [mailto:tbray@textuality.com] >>>> *Sent:* Sunday, December 02, 2012 2:54 PM >>>> *To:* Paul E. Jones >>>> *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com >>>> *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-07**** >>>> >>>> ** ** >>>> >>>> Thanks to Paul for the extra effort. I=92d like to suggest, in the >>>> interests of courtesy and efficiency, that from here on on, contributi= ons >>>> to this discussion be =93camera-ready=94, that is to say, specific sug= gestions >>>> in the style of a diff, including fully-written-out replacements langu= age. >>>> >>>> -Tim**** >>>> >>>> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones >>>> wrote:**** >>>> >>>> Folks,**** >>>> >>>> **** >>>> >>>> I published another version of the WebFinger spec trying to bring >>>> closure to the two open issues I see (resource representation and >>>> transport). The new version is here:**** >>>> >>>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >>>> >>>> **** >>>> >>>> With respect to resource representation, I fully described the JSON >>>> Resource Descriptor within the document. There are no external refere= nces >>>> to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairl= y >>>> simple format and I believe this text documents it sufficiently. Comb= ined >>>> with the visual examples, I think this makes it pretty clear. Have a = look >>>> at the JRD documentation in section 5.2 and provide your comments. ***= * >>>> >>>> **** >>>> >>>> With respect to HTTPS, it seems there is strong preference for =93HTTP= S >>>> only=94, but some a fair bit of insistence for allowing HTTP. I chang= ed the >>>> wording in 5.2 to try to capture opinions. Previously, the text led w= ith a >>>> requirement to try HTTPS first. That is still there. I just added so= me >>>> extra conditions that make it clearer that there are some instances wh= ere a >>>> client must not utilize HTTP. This might need further refinement, but= I >>>> think there is a balance we can strike here between the two camps with= out >>>> introducing a lot of complex language.**** >>>> >>>> **** >>>> >>>> I made some editorial changes through the document.**** >>>> >>>> **** >>>> >>>> Comments are welcome, as always. Seems I don=92t need to say that to >>>> this group, though :-)**** >>>> >>>> **** >>>> >>>> Paul**** >>>> >>>> **** >>>> >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss**** >>>> >>>> ** ** >>>> >>> >>> >> > --f46d0402a9f3e5752e04cff65cec Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 3 December 2012 02:35, Brad Fitzpatri= ck <bradfitz@google.com> wrote:
-1. = =A0I feel strongly for keeping the acct: scheme. =A0WebFinger isn't jus= t about email.

If Webfinger isnt just about emai= l.=A0 What else is it about?
=A0


On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray <tbray@textuality.com><= /span> wrote:
I don=92t want to wait for work on this to b= e completed, and I don=92t think that its presence is necessary for WebFing= er to be useful.=A0 So let's take it out.

Proposal:
Section 4.1: Change the URI in the example from acct: to m= ailto:
Section 4.2: Same
Section 5.3: Same
Section 5.4: s/it could be an &qu= ot;acct" URI [7], //
Section 5.4: Remove 2nd para, beginning "= For resources associated with a user account at a host...=93
Section 5.4= : s/both an "acct" URI and any alias/any alias/
Section 8: Change the URI in the example from acct: to mailto:


<= div class=3D"gmail_quote">On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray <tbr= ay@textuality.com> wrote:
No, we=92re on the same side here. I=92m sug= gesting taking webfinger-07 as a baseline, and all *future* changes need to= be proposed as a concrete delta against it.=A0 -T


On Sun, Dec 2, 2012 at 12:59 PM, Pa= ul E. Jones <paulej@packetizer.com> wrote:

Tim,

=A0<= /p>

I didn=92t mean to be = rude by introducing these changes, just trying to move things along.=A0 Mos= t changes were fairly trivial, not worth mentioning, and can be seen here:<= u>

http://tools.ietf.org/rfcdiff?difftype=3D--hwdif= f&url2=3Ddraft-ietf-appsawg-webfinger-07.txt

=A0<= /p>

The most significant c= hanges were the re-write of section 5.2 and modification to the language re= lated to HTTPS in 5.1.=A0 I suspect that is the text to which you refer as = preferring it to be =93camera-ready=94.=A0 (I would assume the balance of t= he changes would not need to be presented as =93camera-ready=94, since they= =92re minor editorial things.)

=A0<= /p>

In any case, the most = important text changes I would like folks to consider is section 5.2 (which= aims to fully document the JSON Resource Descriptor object) and paragraphs= 2 and 3 in section 5.1.

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. Jones<= br>Cc: ap= ps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07

=A0<= /u>

Thanks to Paul= for the extra effort.=A0 I=92d like to suggest, in the interests of courte= sy and efficiency, that from here on on, contributions to this discussion b= e =93camera-ready=94, that is to say, specific suggestions in the style of = a diff, including fully-written-out replacements language.

=A0-Tim

On Sun, Dec 2, 201= 2 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

I published another version of the W= ebFinger spec trying to bring closure to the two open issues I see (resourc= e representation and transport).=A0 The new version is here:<= /p>

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=A0=

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=A0 There are no ex= ternal references to RFC 6415 now, no need to go read the XRD spec, etc. = =A0It=92s a fairly simple format and I believe this text documents it suffi= ciently.=A0 Combined with the visual examples, I think this makes it pretty= clear.=A0 Have a look at the JRD documentation in section 5.2 and provide = your comments.

=A0

With res= pect to HTTPS, it seems there is strong preference for =93HTTPS only=94, bu= t some a fair bit of insistence for allowing HTTP.=A0 I changed the wording= in 5.2 to try to capture opinions.=A0 Previously, the text led with a requ= irement to try HTTPS first.=A0 That is still there.=A0 I just added some ex= tra conditions that make it clearer that there are some instances where a c= lient must not utilize HTTP.=A0 This might need further refinement, but I t= hink there is a balance we can strike here between the two camps without in= troducing a lot of complex language.

=A0

I made s= ome editorial changes through the document.

=A0

Comments are welcome, = as always.=A0 Seems I don=92t need to say that to this group, though :-)=

=A0

Paul

=A0


_____= __________________________________________
apps-discuss mailing list
= apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=A0





--f46d0402a9f3e5752e04cff65cec-- From ted.ietf@gmail.com Mon Dec 3 10:01:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5416D21F88F1 for ; Mon, 3 Dec 2012 10:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3GFJNsH7Ipr for ; Mon, 3 Dec 2012 10:01:40 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9376321F88EC for ; Mon, 3 Dec 2012 10:01:40 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2150487vbb.31 for ; Mon, 03 Dec 2012 10:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wd/W67Ke1kQ3WV+ngTkLXMH4mNIC0n29+fRnCSF7wqA=; b=bKY8TYIFvuxclrUm2Q30u8gKQIHOre4AC0tSeUf8/wOoBGjaEYMqVrOTWRrL1xh0Hh pQGxwc/4n1nSPFBfr8iO36D65XNJ2z6cvMde+yl64P29w9RTXJOsNDubsx5YC2VAX/ey hHtZuFLQ5LDRafNR4LDoJGn/q1qCQxV4SIS+CAeKTUhXfsap7ChjAwno3yhslB7RRLIb XXHD18wMs66Z1lnP2oFXgAH7f0CEirsf6DBmbHz9qMSHWIqxGqb8zEm//3JO1Xey/tAG q22YPF0K5RGGoPqnOKhQAoauPaE/lGUCwTRIb3/4a5/90+WvIld0AmPol1pU1GGmYLyh 70Aw== MIME-Version: 1.0 Received: by 10.52.37.103 with SMTP id x7mr8043556vdj.61.1354557699919; Mon, 03 Dec 2012 10:01:39 -0800 (PST) Received: by 10.58.164.35 with HTTP; Mon, 3 Dec 2012 10:01:39 -0800 (PST) In-Reply-To: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> References: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> Date: Mon, 3 Dec 2012 10:01:39 -0800 Message-ID: From: Ted Hardie To: "Byrne, Cameron" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-v6ops-464xlat.all@tools.ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:01:42 -0000 On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron wrote: > Ted, > > Thanks for taking the time to review our work. My comments in-line. > Hi Cameron, Thanks for the quick reply; some additional questions/comments in-line with yours. regards, Ted >> -----Original Message----- >> From: Ted Hardie [mailto:ted.ietf@gmail.com] >> Sent: Friday, November 30, 2012 1:15 PM >> To: apps-discuss@ietf.org; draft-ietf-v6ops-464xlat.all@tools.ietf.org >> Subject: Review of draft-ietf-v6ops-464xlat-08 >> >> I have been selected as the Applications Area Directorate reviewer for = this draft >> (for background on appsdir, please see >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat= e >> ). >> >> Please resolve these comments along with any other Last Call comments yo= u >> may receive. Please wait for direction from your document shepherd or AD >> before posting a new version of the draft. >> >> Document:draft-ietf-v6ops-464xlat-08 >> Title: 464XLAT: Combination of Stateful and Stateless Translation >> Reviewer: Ted Hardie >> Review Date: November 30, 2012 >> >> Summary: This draft is not ready for publication as a BCP, and it may no= t be an >> appropriate candidate for this status. >> >> Major Issues: >> >> This document provides a v4/v6 inter-working method using a pair of addr= ess >> translators that bracket a network region in which there is no >> IPv4 routing. It discusses two different potential deployments. In the= first, the >> first address translator is co-resident on the device where the IPv4 add= ress is >> assigned; in the second, the the first address translator is resident in= a nearby >> network device. In both, the second address translator is at the border= of the >> internal IPv6 routing domain and a global IPv4 routing domain. >> >> The document has the following applicability statement: >> >> This BCP only applies when the following two criteria are present: >> >> 1. There is an IPv6-only network that uses stateful translation >> [RFC6146] as the only mechanism for providing IPv4 access. >> >> 2. There are IPv4-only applications or hosts that must communicate >> across the IPv6-only network to reach the IPv4 Internet. >> >> The first item is problematic. This document describes a method for usi= ng >> stateful translation, but it does not justify why this is the appropriat= e choice; the > > The choice for using a stateful translator is outside the scope of this d= ocument. > > But, the IETF has published RFC 6146 which is specifies a stateful protoc= ol translator on the standards track. RFC6146 is necessary but not suffici= ent to operate an IPv6-only network that is dominated (today) by IPv4 nodes= . The problem of IPv4-referals / IPv4-literals as well as IPv4 sockets API= s is very real. It would be very unfortunate if the IETF specified statefu= l NAT64 in RFC 6146 but was no deployable or could only provide an 85% serv= ice (15% of Android apps fail to work on NAT64/DNS64 only networks) I apologize, it appears I did not express this well. I was trying to get at the question of why using stateful translation in cases where there is no IPv4 routing domain is the right idea. My understanding of RFC 6146 is that is specifies a method for allowing IPv6 only clients to reach a v4 Internet host; it does not seem to require the creation of separate technique to allow nodes to retain an IPv4 address in networks that do not have IPv4 routing. That may well be justified by something else, but I don't personally see how RFC 6146 justifies or requires it. You mention that the use of IPv4 referrals or literals are a part of this problem. I understand that, but I'm not honestly note sure that I understand how creating a method that makes nodes believe that they are part of a local IPv4 routing domain when they are actually only part of a v6 local routing domain (and via that a global v4 routing domain) actually helps. It seems particularly worrisome if they have to understand some set of limitations (even if you got a 464xlat socket option, it's not stated how a node would know over what networks it would have to use it). > > Just generally speaking on why stateful is the right choice, many network= s already operate stateful NAT44 and the NAT64 is just another feature that= is quick to deploy on existing hardware with existing support models. Fur= thermore, this architecture is based on the reality that IPv4 address are n= o longer available in APNIC in blocks larger than an emergency /22 (RIPE an= d ARIN also have max /22 allocations for the last /8 in the RIR). That sai= d, stateful multiplex of ports / sessions is absolutely required for any se= rvice that must scale to millions of users. Stateless solutions simply do = not scale for new entrants that do not have existing IPv4 resources. > > >> encapsulation methods used in something like DS-Lite seem to be an alter= native >> here, and it is not clear either what constraint prevents encapsulation'= s use in >> these networks or what the advantage is here to using dual translation o= ver an >> encapsulation-based method. In other words, this appears circular--it d= efines it > > Encapsulation can break many things including traffic engineering based o= n IP address (no more hop by hop routing), DPI associated with charging (sp= ecifically 3GPP defined Policy and Charging Controls (PCC)). > > DS-lite also has configuration driven exclusively by DHCP, there is no DH= CP in 3GPP networks. > Not to be dense here, but in the case where the CLAT is not node resident, how does the the node get the RFC 1918 address it uses? >> as a best practice for networks using stateful translation, rather than = defining >> when stateful translation is best practice. >> > > The wording of the document was chosen to state the circumstance that you= have this type of network: IPv6-only with stateful NAT64 as defined here = http://tools.ietf.org/html/rfc6144#section-2.1 Given that scenario, there = is a practical reality that hosts and software have specific IPv4 dependenc= ies and thus this scenario is defunct without something like 464XLAT. And, = that goes origins of 464XLAT. It is emergent behavior that occurs in my IP= v6-only network at T-Mobile USA. People wanted Skype to work so they put a= n NAT46 on the host ....and Skype now worked. > > We track broken Android apps at this list (15% don't work: Skype, Netfli= x, Spotify ...), and 464XLAT fixes 100% of the broken apps http://goo.gl/z3= j3q > Thanks for the citation. A quick look at the list shows a number of the cited applications are no longer the current version. Is this being maintained as a living document, so there are ongoing tests? If so, has the introduction of Skype 3, Google plus 3 et al resolved any of these? > 464XLAT allows for the real commercial deployment of IPv6-only networks. > > The current state of the network at T-Mobile USA today is squat space + N= AT44. This is the same at Rogers and Sprint mobile networks here in North = America. > > >> The document also says this in the introduction, which provides an addit= ional >> applicability >> limitation: >> >> The 464XLAT architecture only supports IPv4 in the >> client server model, where the server has a global IPv4 address. >> This means it is not fit for IPv4 peer-to-peer communication or >> inbound IPv4 connections >> >> If this is true, it is highly problematic, because it provides a constra= int on the >> semantics of an RFC 1918 address that is not currently present. It is n= ot entirely >> clear, though, that this is true. >> >> Systems attempting peer-to-peer communication when using RFC 1918 >> addresses typically must use ICE to handle the artifacts of network addr= ess >> translation. >> I was not able to understand >> how ICE would fail here, either in the case where the CLAT was resident = on the >> node or when it is network resident. In my naive reading, this would wo= rk for >> cases where the ICE server was in the IPv4 global routing domain. Becau= se >> PLATs are provisioned with a single IP address, the mapped address attri= bute > > What do you mean 1 IP address? 1 IPv4 address? They will have pools of = address for sure. > The figure/chart between section 8.2 and 8.3 says " Global IPv4 address assigned to IPv4 server"; I took that to mean that PLATs were generally provisioned with a single address. With a pool, the ICE considerations below still apply; it will simply be more likely that two hosts within a PLAT-served domain are distinguishable by address as well as address/port. >> would always have the same family and address, but it seems it should be >> distinguishable by port. If this is not the case, or there is a differe= nt reason why >> this mechanism cannot work with ICE, I believe it should be called out i= n the >> draft explicitly. >> > > We make this restriction because of the case where you and I are on the s= ame ISP. We both have 10.10.10.1 as our local address. Communication fail= s. > As long as we are assigned different ports by the PLAT, it does not fail. It is suboptimal, but works. > If we have unique address space, are right, it would work. But, we do no= t want to push an additional level of complexity to try and coordinate uniq= ue LAN side IP addresses. It is simpler to say this simply does not work. = And, in case of DNS64, users will generally not use IPv4. IPv4 is only us= ed for the case of IPv4 referals or IPv4-only host and APIs. > > >> An ICE-based peer-to-peer connection would, certainly, provide a severel= y sub- >> optimal path for two devices within the same 464xlat region, as it would= hairpin >> out and back. But those are not the only potential peer-to-peer connecti= ons and >> it would work at least to some degree. >> >> In the case where the CLAT is resident on a device, but that device prov= ides >> tethering, the document currently says: >> >> The CLAT SHOULD perform router function to >> facilitate packets forwarding through the stateless >> translation even if it is an end-node. >> >> For proper operation of tethered devices, this would appear to require a= MUST, >> rather than a SHOULD. >> If it is not MUST, then some description of what will happen is desirabl= e. >> (Perhaps a statement that CLATs which do not provide this functionality = cannot >> be used when tethering is in place or whether tethered devices require I= Pv4?) >> > > I think you are right. We can do a must here. > >> Minor Issues: >> >> This draft is currently targeted for BCP. I do not believe that it >> is appropriate to target it for > > The rational is that 464XLAT is a best practice for RFC 6144 2.1 network = that has IPv4-only apps in it. > If I understand you correctly, it is not simply IPv4-only apps, but IPv4-only apps which use IPv4-only referrals. Is that right? >> BCP unless it is preferred over encapsulation-based approaches. I also= believe >> that the marketing material which is currently embedded in the text (see= , for >> example, section 5) should be removed. >> > > I am happy to eliminate section 5, but section 5 has been required during= draft formation because there are many solutions in this space. > >> Nits: The description 3GPP applicability relates to 3GPP "Pre-Release 9"= , but >> there is no citation given. I also note that 3GPP specifications curren= tly appear > > See RFC6459 > Just to be clear, you are proposing adding a citation to RFC 6459? >> to be on release 12, and there is no notice of whether changes between p= re- > > The most advanced LTE network is Release 8 at Verizon. > > Most phones are release 7 or earlier (sold on the market today) > > New networks like the one T-Mobile will launch next year will be partiall= y Release 10 > >> release 9 and the current release have changed the topology in a way to > > Current release is not relevant to install base. > The current installed base is not the question I was raising. If the problem you are proposing to solve is limited such that it goes away in 3GPP Release 10, 11, or 12, then the text should say that in the 3GPP applicability section. If an operator/handset manufacturer/app person targeting a release for a network can determine whether or not this set of issues will arise by knowing the relevant 3GPP release, it would be useful to include that. >> eliminate the multiple PDP issue raised. If the text means to say that = this is not a > > But it does not remove the dependency on IPv4 address that are not availa= ble.... public and private addresses are both exhausted, so we use squat sp= ace. > You've twice mentioned the squat space used in your network, but the draft doesn't seem to have any specific text bearing on this problem. The most I see is in 7.1, where an access network simplifies its operations by running v6 only and trusting an upstream to run the PLAT. If you think the squat space use case is important for understanding the applicability, you may need more text in the draft. >> problem for any version 9 or later, and that the problem exists for any = version >> prior to 9 which supports multiple address families, it needs to be rewo= rded. > > I will review the wording. Thanks again for your review. I look forward= to more feedback from you, thanks again for taking the time to work with u= s and sharing your experience > Thanks again for your quick response. regards, Ted Hardie > Thanks > Cameron From ted.ietf@gmail.com Mon Dec 3 10:13:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4246821F85C8 for ; Mon, 3 Dec 2012 10:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jPuKWiAlr9l for ; Mon, 3 Dec 2012 10:13:57 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6AC221F84C1 for ; Mon, 3 Dec 2012 10:13:56 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2163265vbb.31 for ; Mon, 03 Dec 2012 10:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vYureD8koALshCWWM8kZaGeHP0YlEIpNKbehoRkzYLU=; b=Fa5KkB2hEr3qVoOWTlSjlqPqcXeBTp6A2nGBiFndYXvY4OUbhBQmUQVqbh0E/41lTf blXfheKbyRJMQw0/OoAooAFFY0aCML90yowdibM4Gb5P0ex4G5zo85aaarWnVnydzrSl 0m+VfSHohbWERMzSJ/yJ+F9IyVBmNSU2JU4i5FORH1FTD0mqV6g4QpZ8myTDZfjF1mTW x6h5H+DyVaiiJZRsdStI9CSBFHh886x4PBZdHPVwJ/JhFH+/aRLfdde+BjOjljUNu7dn dv9Q9dx9xxzMw0KI9xivm9WPyn7HZo+4c30PCDsXSncmvPowE0ddIzYcBAnEw566XYC9 yFhA== MIME-Version: 1.0 Received: by 10.59.13.135 with SMTP id ey7mr9559601ved.37.1354558436303; Mon, 03 Dec 2012 10:13:56 -0800 (PST) Received: by 10.58.164.35 with HTTP; Mon, 3 Dec 2012 10:13:56 -0800 (PST) In-Reply-To: References: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> Date: Mon, 3 Dec 2012 10:13:56 -0800 Message-ID: From: Ted Hardie To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-ietf-v6ops-464xlat.all@tools.ietf.org" , "apps-discuss@ietf.org" , "Byrne, Cameron" Subject: Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:13:58 -0000 On Sun, Dec 2, 2012 at 7:56 PM, Cameron Byrne wrote: > Ted, > > i have revision to my previous statements > In-line. > On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron > > I believe you are right that ICE would work at the app level. > > Our statement about hub-and-spoke in the I-D was driven by wording set > in http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01#section-8.2 > > In this way, the NAT64 is a hub for IPv4 communications and IPv4 nodes > via the NAT64 can communicate with other IPv4 nodes. That is the > basic architecture, if you need IPv4 access, send it via the CLAT and > PLAT where CLAT is the spoke and PLAT is the hub > > Our claim that p2p does not work is based on the topological case that > if you are address 2001:DB8:9999::10.1.1.1 and i am address > 2001:DB8:8888::10.1.1.1 our ipv4-only nodes behind the CLAT cannot > send packets to each other without something like ICE to force them > via the NAT64 or TURN. > There are two cases. In the first case, the CLAT is node resident. There, the CLAT-internal RFC 1918 addresses used by different nodes are functionally in different RFC 1918 instances. That's the same case we get now when different networks use RFC 1918, just much smaller. In the case where two home networks both use RFC 1918, in other words, you get the same situation--they must go out to an ICE server to have p2p communications even if they are, say, behind the same cable head end. In the second case, the CLAT is not node resident, but it is not running an IPv4 routing domain in the traditional sense; in other words, itt does not offer local routing among the IPv4 nodes, just translation to v6. Here the situations is mildly different from the two-home-networks-each-using-RFC1918, but the result from the point of the application is the same--they must use an ICE server to communicate. > If our addresses were different on the LAN like > 2001:DB8:9999::10.1.9.9 and 2001:DB8:8888::10.1.1.1 we could send > IPv4 packets to each other without the need for the hub (PLAT) since > each CLAT would do RFC 6145 translation and remove the first 96 bits > on the LAN side. This is great if there is a high chance that the > LAN side IPs are unique, but that is not the case and result would be > ipv4 packets with src = 10.1.1.1 and dst 10.1.1.1 > > The current wording in question is "The 464XLAT architecture only > supports IPv4 in the > client server model, where the server has a global IPv4 address. > This means it is not fit for IPv4 peer-to-peer communication or > inbound IPv4 connections." > > The important term is "fit" vs "not fit". Given that path would go > via a hub and may require ICE in the apps and infrastructure, it would > not really be direct p2p, and therefore the WG settle on this specific > language to error on the side of caution to the reader that this is > not a "fit" design if p2p is an important use-case in ipv4 supporting > ipv4. The current statement is a caution to the reader and that is > the reason it appears in the introduction. > > Alternatively, we can strike this from the introduction all together > and give a more in-depth discussion that reference ICE for the p2p > case. The WG decided it was best to just punt on p2p and say it does > not work here in the introduction. > Speaking personally, I don't think this is the right choice, because it makes it appear you are creating a new semantic for RFC 1918 addresses (a limited case where the usual tools for providing peer to peer connectivity for them do not work). If you can't signal that new semantic, the app has no way of knowing whether the RFC1918 address it has is "full service" (for whatever that means in the modern NAT and double NAT world) or "client/server only". That's making a bad situation worse. ICE is a complicated bear that no one loves much, but it is currently the best toolkit we have. A reference to it and a description of how this works with it seems like a better choice to me than creating a new, limited RFC 1918 addressing semantic. regards, Ted Hardie From barryleiba.mailing.lists@gmail.com Mon Dec 3 10:48:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C7C21F8826 for ; Mon, 3 Dec 2012 10:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lu1b4Exe5st for ; Mon, 3 Dec 2012 10:48:02 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF42421F881F for ; Mon, 3 Dec 2012 10:48:01 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2607242lah.31 for ; Mon, 03 Dec 2012 10:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wTD3GJ4hkQ4UPujRytv1zdcsn9LLKfFV41PdHaCjzn0=; b=mgGi46EBe+DYSwibAzStg/V5wkH9Frw/DYDh+a86Q+7TXg0IAev3p8eWEGwdz+iLu9 WC1HYD8FZNsbPsYHPt7vAG8X7reuxBx2HekhupxSwM0CKJVkjt+AXh2lrfg2N79FOMj+ 5BiHTk5n2G7PtuSkSKIQUgfzf8f3r48AQQzXpyPKn8idzEqmTwzbX7lfkp2C5dP1z0EP 2WlQGw+gij1WlliYlf1mKnQ8Yfi/kUC6BRTq5iQXxyPl9PSJ7DmCB63sVfFKv6Eo5qmi j+GSeT+YUxyvpZ6C0MrmkhbhEA/uEWr7LXWFiee7qw2vVcApitGKhe2xhKtbORbMcKac mm2A== MIME-Version: 1.0 Received: by 10.112.82.166 with SMTP id j6mr4755052lby.25.1354560480371; Mon, 03 Dec 2012 10:48:00 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Mon, 3 Dec 2012 10:48:00 -0800 (PST) In-Reply-To: <2BD6CE37760538020CEE52FF@JcK-HP8200.jck.com> References: <2BD6CE37760538020CEE52FF@JcK-HP8200.jck.com> Date: Mon, 3 Dec 2012 13:48:00 -0500 X-Google-Sender-Auth: XZGrXnkdjNRKyoiWdE-ep3cHv1I Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Enough from Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:48:02 -0000 > Having just received another huge batch of specialized webfinger > correspondence over the weekend, most of which couldn't even > bother to be identified sufficiently by draft or topic to enable > easy filtering, I'm unsubscribing from apps-discuss. Someone > might let me (and the others I assume have departed for other > reasons) know when this is over and the list is back to being > used for other topics. Indeed, and I've had some off-list complaints as well. Because of these, and because I've received only support and no complaints about creating a "webfinger" non-WG mailing list, I've put in the request and asked that it be handled ASAP. The creation of , which you'll be able to subscribe to here when it's created: https://www.ietf.org/mailman/listinfo/webfinger (that link won't work yet) will be announced on ietf-announce and on this list as well. *** When that list is created, please move all webfinger-related discussions to that list. *** *** In the meantime, please try to hold off on further discussion of webfinger on the apps-discuss list. *** Hang on for a day or two until the new list is created, and carry on over there. And realize that once discussion is taken up on that list, participants will have to read the archives to see what they missed before they subscribed -- it's not practical to try to pre-subscribe people in this case. Thanks, everyone (on both sides of this fence) for your understanding. We made a mistake, underestimating the traffic and the length of the discussion, and we have to do what we can to correct for it now. Barry, App AD From evan@status.net Mon Dec 3 10:49:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A2321F8826 for ; Mon, 3 Dec 2012 10:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrTmOqldTXbn for ; Mon, 3 Dec 2012 10:49:14 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 79AC321F881F for ; Mon, 3 Dec 2012 10:49:14 -0800 (PST) Received: from [10.0.1.34] (unknown [24.53.26.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 9E9D38D4456; Mon, 3 Dec 2012 19:01:31 +0000 (UTC) Message-ID: <50BCF429.4020001@status.net> Date: Mon, 03 Dec 2012 13:49:13 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Apps Discuss References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030808050806060600040403" Cc: webfinger@googlegroups.com Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:49:15 -0000 This is a multi-part message in MIME format. --------------030808050806060600040403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I think the problem with modeling interactions around libraries, function calls, and parameters is that it's presupposing a particular kind of operating environment. Webfinger as defined is simple enough that you can use HTTP libraries directly without an intermediate chunk of software. I think those implementations should still be compliant, even though they don't implement a boolean parameter to anything. I'd suggest if we're going to include this, it be made a SHOULD rather than a MUST. And if we start to go down the path of "What's a parameter?" and "What are possible 'false' values?" the whole thing should be struck out as a distraction. -Evan On 2012-12-01 12:55, Tim Bray wrote: > > I normally agree with Evan on most things, but not here. It is > perfectly OK and unsurprising for an Internet protocol to impose > behavioral constraints on software. Otherwise you could never specify > MustUnderstand. -T > > On Dec 1, 2012 6:42 AM, "Evan Prodromou" > wrote: > > I think I've already given this proposal my -1. > > It doesn't belong in this spec, which isn't about libraries or > their APIs. If someone wants to define an IDL model for Webfinger > libraries in some other document, best wishes. > > This document should be about the interface between clients and > servers, not the interface between client libraries and their > calling applications. > > -Evan > > On 12-11-30 06:09 PM, Tim Bray wrote: >> On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros >> > wrote: >> >> > You're right on target. In fact, I have made both proposals here: >> > >> > 1. Mandatory TLS >> > 2. Mandatory-to-implement configuration for no-HTTP fallback. >> > Essentially in this case the inputs to a WF client are an email >> > address and a boolean to say whether fallback is allowed. May >> not be >> > pleasant to write in a spec... >> >> OK, let's make this concrete, I don’t think it’s that unpleasant >> to spec out: >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> >> In draft-ietf-appsawg-webfinger-06 >> >> - Remove the second paragraph of Section 5.1, which begins >> “Clients MUST first attempt a query... >> >> Introduce a new section 5.2 and bump up the other sections, as >> follows >> >> 5.2 Use of HTTPS >> >> WebFinger client software MUST accept as input a boolean >> parameter which for the purposes of this discussion will be >> referred as "allow-fallback". >> >> WebFinger client software MUST attempt to retrieve >> /.well-known/webfinger using the HTTPS protocol. If an HTTPS >> connection is made, and the server has an invalid certificate, or >> returns an HTTP status code indicating an error, the client >> software MUST report an error and cease attempting to retrieve >> the resource. >> >> If the WebFinger client software is unable to establish an HTTPS >> connection to the server, behavior depends on the value of the >> allow-fallback parameter. If the value of allow-fallback is >> true, the client software MAY fall back to unencrypted HTTP in an >> attempt to retrieve /.well-known/webfinger. If allow-fallback is >> false, client software MUST report an error and cease attempting >> to retrieve the resource. >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 --------------030808050806060600040403 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I think the problem with modeling interactions around libraries, function calls, and parameters is that it's presupposing a particular kind of operating environment.

Webfinger as defined is simple enough that you can use HTTP libraries directly without an intermediate chunk of software. I think those implementations should still be compliant, even though they don't implement a boolean parameter to anything.

I'd suggest if we're going to include this, it be made a SHOULD rather than a MUST. And if we start to go down the path of "What's a parameter?" and "What are possible 'false' values?" the whole thing should be struck out as a distraction.

-Evan

On 2012-12-01 12:55, Tim Bray wrote:

I normally agree with Evan on most things, but not here. It is perfectly OK and unsurprising for an Internet protocol to impose behavioral constraints on software. Otherwise you could never specify MustUnderstand. -T

On Dec 1, 2012 6:42 AM, "Evan Prodromou" <evan@status.net> wrote:
I think I've already given this proposal my -1.

It doesn't belong in this spec, which isn't about libraries or their APIs. If someone wants to define an IDL model for Webfinger libraries in some other document, best wishes.

This document should be about the interface between clients and servers, not the interface between client libraries and their calling applications.

-Evan

On 12-11-30 06:09 PM, Tim Bray wrote:
On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros <breno@google.com> wrote:

> You're right on target. In fact, I have made both proposals here:
>
> 1. Mandatory TLS
> 2. Mandatory-to-implement configuration for no-HTTP fallback.
> Essentially in this case the inputs to a WF client are an email
> address and a boolean to say whether fallback is allowed. May not be
> pleasant to write in a spec...

OK, let's make this concrete, I don’t think it’s that unpleasant to spec out:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

In draft-ietf-appsawg-webfinger-06

- Remove the second paragraph of Section 5.1, which begins “Clients MUST first attempt a query...

Introduce a new section 5.2 and bump up the other sections, as follows

5.2 Use of HTTPS

WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback".

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol.  If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter.  If the value of allow-fallback is true, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger.  If allow-fallback is false, client software MUST report an error and cease attempting to retrieve the resource.



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net P: +1-514-554-3826
--------------030808050806060600040403-- From perpetual-tripper@wwelves.org Mon Dec 3 11:07:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C6B21F884A for ; Mon, 3 Dec 2012 11:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVxdXsRYFckU for ; Mon, 3 Dec 2012 11:07:27 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id E371321F8848 for ; Mon, 3 Dec 2012 11:07:26 -0800 (PST) X-Originating-IP: 217.70.178.146 Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id C3097172086; Mon, 3 Dec 2012 20:07:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id K-lSANHt3lUc; Mon, 3 Dec 2012 20:07:14 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 580CB172074; Mon, 3 Dec 2012 20:07:14 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Melvin Carvalho In-reply-to: References: Date: Mon, 03 Dec 2012 19:07:13 +0000 Message-Id: <1354561255-sup-4941@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: webfinger , apps-discuss Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:07:27 -0000 Excerpts from Melvin Carvalho's message of 2012-12-03 17:46:57 +0000: > On 3 December 2012 02:14, Tim Bray wrote: >=20 > > I don=E2=80=99t want to wait for work on this to be completed, and I = don=E2=80=99t think > > that its presence is necessary for WebFinger to be useful. So let's = take > > it out. > > > > Proposal: > > Section 4.1: Change the URI in the example from acct: to mailto: > > Section 4.2: Same > > Section 5.3: Same > > Section 5.4: s/it could be an "acct" URI [7], // > > Section 5.4: Remove 2nd para, beginning "For resources associated wit= h a > > user account at a host...=E2=80=9C > > Section 5.4: s/both an "acct" URI and any alias/any alias/ > > Section 8: Change the URI in the example from acct: to mailto: > > >=20 > +1 >=20 > mailto (as either a direct or indirect identifier as per awww) should b= e > used in all cases, acct: is not only extraneous, it conflates the > user@hostpattern that 99% of clients will interpret as mailto:as of > today, it opens the door to one uri scheme per concept e.g. user: and > others which dilute the name space, triggering a potential land grab an= d > it's simply confusing to developers for 'one uri scheme per concept e.g. user'... i consider us - PEOPLE, as = quite unique concept who may deserve little special pampering ;) From nico@cryptonector.com Mon Dec 3 11:15:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B739021F88CB for ; Mon, 3 Dec 2012 11:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExF3LXRMbBOD for ; Mon, 3 Dec 2012 11:15:26 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4D55821F88BD for ; Mon, 3 Dec 2012 11:15:26 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 0BA7F26C05E for ; Mon, 3 Dec 2012 11:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ERD0BUaq1IE3SeH/vUmK BDd3BxA=; b=o3iSl4l0uNScmZNXK5eZba8RVXArxMMu1t5MQFdxmnPTxWve4W7d 259YNjLS9WZFH930goXZAXK5P79X3hTaayrJ4HLHOD50DQq4h08F+hrLosUhD4N+ G8HrgCIlkxLO0TAK/xCuA+sYUZUS77jolz1DKzMrdKilicwehWG/MGI= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id B2CCC26C057 for ; Mon, 3 Dec 2012 11:15:25 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1364895wey.31 for ; Mon, 03 Dec 2012 11:15:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.88.71 with SMTP id be7mr207579wib.17.1354562124298; Mon, 03 Dec 2012 11:15:24 -0800 (PST) Received: by 10.216.192.207 with HTTP; Mon, 3 Dec 2012 11:15:23 -0800 (PST) In-Reply-To: <50BCF429.4020001@status.net> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> <50BCF429.4020001@status.net> Date: Mon, 3 Dec 2012 13:15:23 -0600 Message-ID: From: Nico Williams To: Evan Prodromou Content-Type: text/plain; charset=UTF-8 Cc: webfinger@googlegroups.com, Apps Discuss Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:15:26 -0000 On Mon, Dec 3, 2012 at 12:49 PM, Evan Prodromou wrote: > I think the problem with modeling interactions around libraries, function > calls, and parameters is that it's presupposing a particular kind of > operating environment. > > Webfinger as defined is simple enough that you can use HTTP libraries > directly without an intermediate chunk of software. I think those > implementations should still be compliant, even though they don't implement > a boolean parameter to anything. My knee-jerk reaction is that this is irrelevant in a WF app that internally implements a WF client. Thinking a bit more about this I think that fallback is the wrong compromise. I would prefer that we state that the WF client app/user must decide whether TLS is required for its purpose -- no fallback. FYI: http://wiki.dreamhost.com/Secure_Hosting#Considerations_and_Caveats That wiki page doesn't mention SNI, but ISTR them claiming that SNI is not sufficiently supported by clients. Nico -- From jpanzer@google.com Mon Dec 3 11:22:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1768D21F84FD for ; Mon, 3 Dec 2012 11:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP6pLb4MgfZY for ; Mon, 3 Dec 2012 11:21:59 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B59D921F84DA for ; Mon, 3 Dec 2012 11:21:58 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2636174lah.31 for ; Mon, 03 Dec 2012 11:21:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z1q+xOfCgnjH0a6KAj5FsZi0pT7wSBw/G7v3sj0qUqM=; b=Dc5sv2kVDS25VEAwohZXssuP3+kz0Lh0G+aujQqkQv1+uHSD6a77rYdh23lVucLevV sVhFM/oMz00BYTw0MBhcYHye7XGfuolDIjDGNa7FgpKqsyDSQ3vf1BeVtGH8Lq4agrGD hjpmxLNrsOjr4WibpzNvIaYCP61DOm1VH5AiGAduTWMgIH4O5iaHOejmhnzNV2CvoK09 bwh6JKXhjSYY6rHwTYXdBk9JfAFUIkWK7dpU4wJyoIB56NKqXqlK0VfQYY1o0MW6h9RJ kyo2Ua+aolgjWtzsX/sx0Dp9jCE8qb/iNmSgfgUEG+eOjP4T6gCcvO7zGAj/KRcsBxWc KikA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=z1q+xOfCgnjH0a6KAj5FsZi0pT7wSBw/G7v3sj0qUqM=; b=oavw8tkdY/fTe0MckpbY7xjfe6kVVRyh1ksEXT9IcUB9uZKCN3BSiWjC3JuUC++ssa emUJ7dA1yJGu+7X1ZDtNokTXyi8jJn/+lBWvY2wcu2twLrU88uNhfp8uoz1g1szHu7ct 3WFZXE1S8fUBtuvnQyy8JZ1LiI0xLkzGIJdMK+LYJDxTa0nSd6Fmd/O9RukOIVOaTHs4 4jXf6jgWb+zb3FLHmF0RnWmz8DqCDbsn5F+B+cQ1I7XaWT2V0R5UE0dLoe1QsEbAnaBZ V6qjER8oASWUMe6HtJeCs31COh+tNqnYC68pAoXqHXFJaR4nNC86swFtVsZrYwVTYMPm ETvQ== Received: by 10.112.87.194 with SMTP id ba2mr4848056lbb.84.1354562517393; Mon, 03 Dec 2012 11:21:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.4.197 with HTTP; Mon, 3 Dec 2012 11:21:37 -0800 (PST) In-Reply-To: <50BCF429.4020001@status.net> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> <50BCF429.4020001@status.net> From: John Panzer Date: Mon, 3 Dec 2012 11:21:37 -0800 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d0401fdfface12404cff7a963 X-Gm-Message-State: ALoCoQn0Hd1+HGamo3q/KzruaavbM+pQ7KREu7pnNDbBcI20Q3a0vmkayQbxzYg76ITEVtvtsZTuUKzAt2Te0DcEH1+D2hHTl0oDbIblz69JEyhl2Pqm3PYQwiQR/VZX4jHfm0ma0uHettuTP3nOYboHLmNStF605IQ74v3/LmNGTCiaT9i4lq3YPk0+sjacFFlu1mYpjM8v Cc: Apps Discuss Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:22:00 -0000 --f46d0401fdfface12404cff7a963 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If we do allow http-only servers, then for interop I'd suggest this language: "Clients MUST be able to be configured so that they can successfully query a TLS-only server." On Mon, Dec 3, 2012 at 10:49 AM, Evan Prodromou wrote: > I think the problem with modeling interactions around libraries, > function calls, and parameters is that it's presupposing a particular kin= d > of operating environment. > > Webfinger as defined is simple enough that you can use HTTP libraries > directly without an intermediate chunk of software. I think those > implementations should still be compliant, even though they don't impleme= nt > a boolean parameter to anything. > > I'd suggest if we're going to include this, it be made a SHOULD rather > than a MUST. And if we start to go down the path of "What's a parameter?" > and "What are possible 'false' values?" the whole thing should be struck > out as a distraction. > > -Evan > > > On 2012-12-01 12:55, Tim Bray wrote: > > I normally agree with Evan on most things, but not here. It is perfectly > OK and unsurprising for an Internet protocol to impose behavioral > constraints on software. Otherwise you could never specify MustUnderstand= . > -T > On Dec 1, 2012 6:42 AM, "Evan Prodromou" wrote: > >> I think I've already given this proposal my -1. >> >> It doesn't belong in this spec, which isn't about libraries or their >> APIs. If someone wants to define an IDL model for Webfinger libraries in >> some other document, best wishes. >> >> This document should be about the interface between clients and servers, >> not the interface between client libraries and their calling application= s. >> >> -Evan >> >> On 12-11-30 06:09 PM, Tim Bray wrote: >> >> On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros >> wrote: >> >> > You're right on target. In fact, I have made both proposals here: >> > >> > 1. Mandatory TLS >> > 2. Mandatory-to-implement configuration for no-HTTP fallback. >> > Essentially in this case the inputs to a WF client are an email >> > address and a boolean to say whether fallback is allowed. May not be >> > pleasant to write in a spec... >> >> OK, let's make this concrete, I don=92t think it=92s that unpleasant to = spec >> out: >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> >> In draft-ietf-appsawg-webfinger-06 >> >> - Remove the second paragraph of Section 5.1, which begins =93Clients MU= ST >> first attempt a query... >> >> Introduce a new section 5.2 and bump up the other sections, as follows >> >> 5.2 Use of HTTPS >> >> WebFinger client software MUST accept as input a boolean parameter which >> for the purposes of this discussion will be referred as "allow-fallback"= . >> >> WebFinger client software MUST attempt to retrieve /.well-known/webfinge= r >> using the HTTPS protocol. If an HTTPS connection is made, and the serve= r >> has an invalid certificate, or returns an HTTP status code indicating an >> error, the client software MUST report an error and cease attempting to >> retrieve the resource. >> >> If the WebFinger client software is unable to establish an HTTPS >> connection to the server, behavior depends on the value of the >> allow-fallback parameter. If the value of allow-fallback is true, the >> client software MAY fall back to unencrypted HTTP in an attempt to retri= eve >> /.well-known/webfinger. If allow-fallback is false, client software MUS= T >> report an error and cease attempting to retrieve the resource. >> >> >> >> _______________________________________________ >> apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailm= an/listinfo/apps-discuss >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > -- > Evan Prodromou, CEO and Founder, StatusNet Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E: evan@status.net P: +1-514-554-3826 > > --f46d0401fdfface12404cff7a963 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
If we = do allow http-only servers, then for interop I'd suggest this language:=

"Clients MUST be able to be configured so that the= y can successfully query a TLS-only server."

On Mon, Dec 3, 2012 at 10:49 AM, Evan Prodro= mou <evan@status.net> wrote:
=20 =20 =20
I think the problem with modeling interactions around libraries, function calls, and parameters is that it's presupposing a particular kind of operating environment= .

Webfinger as defined is simple enough that you can use HTTP libraries directly without an intermediate chunk of software. I think those implementations should still be compliant, even though they don't implement a boolean parameter to anything.

I'd suggest if we're going to include this, it be made a SHOU= LD rather than a MUST. And if we start to go down the path of "What= 's a parameter?" and "What are possible 'false' values= ?" the whole thing should be struck out as a distraction.

-Evan


On 2012-12-01 12:55, Tim Bray wrote:

I normally agree with Evan on most things, but not here. It is perfectly OK and unsurprising for an Internet protocol to impose behavioral constraints on software. Otherwise you could never specify MustUnderstand. -T

On Dec 1, 2012 6:42 AM, "Evan Prodrom= ou" <evan@statu= s.net> wrote:
I think I've already given this proposal my -1.

It doesn't belong in this spec, which isn't about libraries or their APIs. If someone wants to define an IDL model for Webfinger libraries in some other document, best wishes.

This document should be about the interface between clients and servers, not the interface between client libraries and their calling applications.

-Evan

On 12-11-30 06:09 PM, Tim Bray wrote:
On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros <breno@google.com> wrote:

> You're right on target. In fact, I have made both proposals here:
>
> 1. Mandatory TLS
> 2. Mandatory-to-implement configuration for no-HTTP fallback.
> Essentially in this case the inputs to a WF client are an email
> address and a boolean to say whether fallback is allowed. May not be
> pleasant to write in a spec...

OK, let's make this concrete, I don=92t think it=92s that unpleasant to spec out:
<<<<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<&l= t;<<<<<<<<<<<<<<<<

In draft-ietf-appsawg-webfinger-06

- Remove the second paragraph of Section 5.1, which begins =93Clients MUST first attempt a query...

Introduce a new section 5.2 and bump up the other sections, as follows

5.2 Use of HTTPS

WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback".

WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol.=A0 If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter.=A0 If the value of allow-fallback is true, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger.=A0 If allow-fallback is false, client software MUST report an error and cease attempting to retrieve the resource.



_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
apps-discuss mailing list
apps-d= iscuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--=20
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net=
 P: +1-514-554-3826

--f46d0401fdfface12404cff7a963-- From cb.list6@gmail.com Mon Dec 3 11:36:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DD121F867D for ; Mon, 3 Dec 2012 11:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c24FAX8dCq5Y for ; Mon, 3 Dec 2012 11:36:48 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B23EF21F8583 for ; Mon, 3 Dec 2012 11:36:47 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2768135lbk.31 for ; Mon, 03 Dec 2012 11:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e0hnqcN8pH2VQUoMC/as+RlhcqwtEzQp7Zhz5uLL7Pg=; b=cnM5CBBZii8fNr5/zAs6N7TpAFOTDolFMZCuwVTVnWnvf/KWifxyO0tfaBqGXhvWV9 VtQcsTPhbiGygJYDwFvBzRN9GEZT0bLgYrP92z0SR7KS2gDmPUa/9VL8dmmraJg8jO5l UuShoHZdRYyjhudPksGw4mvgtQR9j4A5VSFhmE04corgkuVkfRF00AokIQ6WnKzLJhTb oh9kzzZvLSDm9/abydkV1Ks+ZGadk/KfZhH9IIiY4KmpXcAlqtUWMwvpKVrMTohdAJS1 jFpaJsZJHMhlBWyKp5hDo11czdiVju66VaNlTFZtBAnq0FhQuIccDrRbpfgYnQUATlp6 0UqA== MIME-Version: 1.0 Received: by 10.152.108.48 with SMTP id hh16mr10414089lab.25.1354563406063; Mon, 03 Dec 2012 11:36:46 -0800 (PST) Received: by 10.112.44.36 with HTTP; Mon, 3 Dec 2012 11:36:45 -0800 (PST) In-Reply-To: References: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> Date: Mon, 3 Dec 2012 11:36:45 -0800 Message-ID: From: Cameron Byrne To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-v6ops-464xlat.all@tools.ietf.org" , "apps-discuss@ietf.org" , "Byrne, Cameron" Subject: Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:36:50 -0000 Hi Ted, Once again, your feedback is very much appreciated. Comments inline On Mon, Dec 3, 2012 at 10:01 AM, Ted Hardie wrote: > On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron > wrote: >> Ted, >> >> Thanks for taking the time to review our work. My comments in-line. >> > > > Hi Cameron, > > Thanks for the quick reply; some additional questions/comments in-line > with yours. > > regards, > > Ted > >>> -----Original Message----- >>> From: Ted Hardie [mailto:ted.ietf@gmail.com] >>> Sent: Friday, November 30, 2012 1:15 PM >>> To: apps-discuss@ietf.org; draft-ietf-v6ops-464xlat.all@tools.ietf.org >>> Subject: Review of draft-ietf-v6ops-464xlat-08 >>> >>> I have been selected as the Applications Area Directorate reviewer for= this draft >>> (for background on appsdir, please see >>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora= te >>> ). >>> >>> Please resolve these comments along with any other Last Call comments y= ou >>> may receive. Please wait for direction from your document shepherd or A= D >>> before posting a new version of the draft. >>> >>> Document:draft-ietf-v6ops-464xlat-08 >>> Title: 464XLAT: Combination of Stateful and Stateless Translation >>> Reviewer: Ted Hardie >>> Review Date: November 30, 2012 >>> >>> Summary: This draft is not ready for publication as a BCP, and it may n= ot be an >>> appropriate candidate for this status. >>> >>> Major Issues: >>> >>> This document provides a v4/v6 inter-working method using a pair of add= ress >>> translators that bracket a network region in which there is no >>> IPv4 routing. It discusses two different potential deployments. In th= e first, the >>> first address translator is co-resident on the device where the IPv4 ad= dress is >>> assigned; in the second, the the first address translator is resident i= n a nearby >>> network device. In both, the second address translator is at the borde= r of the >>> internal IPv6 routing domain and a global IPv4 routing domain. >>> >>> The document has the following applicability statement: >>> >>> This BCP only applies when the following two criteria are present: >>> >>> 1. There is an IPv6-only network that uses stateful translation >>> [RFC6146] as the only mechanism for providing IPv4 access. >>> >>> 2. There are IPv4-only applications or hosts that must communicate >>> across the IPv6-only network to reach the IPv4 Internet. >>> >>> The first item is problematic. This document describes a method for us= ing >>> stateful translation, but it does not justify why this is the appropria= te choice; the >> >> The choice for using a stateful translator is outside the scope of this = document. >> >> But, the IETF has published RFC 6146 which is specifies a stateful proto= col translator on the standards track. RFC6146 is necessary but not suffic= ient to operate an IPv6-only network that is dominated (today) by IPv4 node= s. The problem of IPv4-referals / IPv4-literals as well as IPv4 sockets AP= Is is very real. It would be very unfortunate if the IETF specified statef= ul NAT64 in RFC 6146 but was no deployable or could only provide an 85% ser= vice (15% of Android apps fail to work on NAT64/DNS64 only networks) > > I apologize, it appears I did not express this well. I was trying to I am still a bit unclear on what exactly your concern is, but i will try to address it below. Sorry for not being able to parse your meaning, i am bit close to the subject so it hard for me to understand the gaps you (or any reader) may have in understanding the draft > get at the question of why using stateful translation in cases where > there is no IPv4 routing domain is the right idea. My understanding of > RFC 6146 is > that is specifies a method for allowing IPv6 only clients to reach a > v4 Internet host; it does not seem to require the creation of separate > technique to allow nodes to retain an IPv4 address in networks that do > not have IPv4 routing. That may well be justified by something else, > but I don't personally see how RFC 6146 justifies or requires it. > The fact that there must be an IPv6-only routing domain is a function of IPv4 exhaustion (APNIC is already out). Many large access networks have more customers than address available in the private / shared allocations. Just to cite 2 examples, AT&T and Verizon Wireless in the USA each have over 100 million wireless subscribers. The fact that a host within an IPv6-only routing domain requires an IPv4 address to form sockets is attributed to IPv4-only network APIs, single stack IPv4 hosts, and the use of IPv4 referals within otherwise IPv6 capable systems [Skype on Android] > You mention that the use of IPv4 referrals or literals are a part of > this problem. I understand that, but I'm not > honestly note sure that I understand how creating a method that makes > nodes believe that they are part of a > local IPv4 routing domain when they are actually only part of a v6 > local routing domain (and via that a global > v4 routing domain) actually helps. It seems particularly worrisome if > they have to understand some set of > limitations (even if you got a 464xlat socket option, it's not stated > how a node would know over what networks it would have to use it). > To make a Skype call, Skype must open an socket from an IPv4 address to an IPv4 address. 464XLAT on the host provides a TUN interface, for example, that the local host can bind IPv4 sockets to. That TUN interface then performs RFC 6145. So, the host can form the IPv4 socket that it previously could not form. Packets generated from that interface are immediately translated from IPv4 to IPv6 and put on the wire with the destination set for the NAT64 in the first 96 bits and the last 32 for the IPv4 address. This is all running code. Here you will find pointers to the Android implementation for Nexus S, Galaxy Nexus, as well the open source code that has been accepted by Android Open Source Project: http://dan.drown.org/android/clat/ This software "just works" on an IPv6-only network such as T-mobile's. Before and after tests are readily reproducible that without this 464XLAT software Skype and Netflix do not work (latest version of both tested within the last 2 weeks) yet with 464XLAT they do work. >> >> Just generally speaking on why stateful is the right choice, many networ= ks already operate stateful NAT44 and the NAT64 is just another feature tha= t is quick to deploy on existing hardware with existing support models. Fu= rthermore, this architecture is based on the reality that IPv4 address are = no longer available in APNIC in blocks larger than an emergency /22 (RIPE a= nd ARIN also have max /22 allocations for the last /8 in the RIR). That sa= id, stateful multiplex of ports / sessions is absolutely required for any s= ervice that must scale to millions of users. Stateless solutions simply do= not scale for new entrants that do not have existing IPv4 resources. > >> >> >>> encapsulation methods used in something like DS-Lite seem to be an alte= rnative >>> here, and it is not clear either what constraint prevents encapsulation= 's use in >>> these networks or what the advantage is here to using dual translation = over an >>> encapsulation-based method. In other words, this appears circular--it = defines it >> >> Encapsulation can break many things including traffic engineering based = on IP address (no more hop by hop routing), DPI associated with charging (s= pecifically 3GPP defined Policy and Charging Controls (PCC)). >> >> DS-lite also has configuration driven exclusively by DHCP, there is no D= HCP in 3GPP networks. >> > > Not to be dense here, but in the case where the CLAT is not node > resident, how does the > the node get the RFC 1918 address it uses? > Section 8.5 describes the CLAT as a gateway that operates a DHCP server > >>> as a best practice for networks using stateful translation, rather than= defining >>> when stateful translation is best practice. >>> >> >> The wording of the document was chosen to state the circumstance that yo= u have this type of network: IPv6-only with stateful NAT64 as defined here= http://tools.ietf.org/html/rfc6144#section-2.1 Given that scenario, there= is a practical reality that hosts and software have specific IPv4 dependen= cies and thus this scenario is defunct without something like 464XLAT. And,= that goes origins of 464XLAT. It is emergent behavior that occurs in my I= Pv6-only network at T-Mobile USA. People wanted Skype to work so they put = an NAT46 on the host ....and Skype now worked. >> >> We track broken Android apps at this list (15% don't work: Skype, Netfl= ix, Spotify ...), and 464XLAT fixes 100% of the broken apps http://goo.gl/z= 3j3q >> > > Thanks for the citation. A quick look at the list shows a number of > the cited applications are no longer > the current version. Is this being maintained as a living document, > so there are ongoing tests? If so, > has the introduction of Skype 3, Google plus 3 et al resolved any of thes= e? > It is a living document, i have been meaning to do a complete update of it. I can likely have that done in a few weeks. In any event, within the last 2 weeks i have verified that Skype and Netflix on the latest version from the Android market do not yet work on IPv6-only + NAT64/DNS64. These are both on the top 20 list of most popular apps, so there is no responsible case for moving forward with IPv6 and letting them break. Much to my personal disappoint, a Skype engineer (who i assume you recognize) went on the record yesterday explaining that there is no demand and therefore no plan to support IPv6 in Skype http://mailman.nanog.org/pipermail/nanog/2012-December/053918.html :( I would rather not need 464XLAT, but these statements from Skype reflects a reality that it is easier to change the host than it is the app. > >> 464XLAT allows for the real commercial deployment of IPv6-only networks. >> >> The current state of the network at T-Mobile USA today is squat space + = NAT44. This is the same at Rogers and Sprint mobile networks here in North= America. >> >> >>> The document also says this in the introduction, which provides an addi= tional >>> applicability >>> limitation: >>> >>> The 464XLAT architecture only supports IPv4 in the >>> client server model, where the server has a global IPv4 address. >>> This means it is not fit for IPv4 peer-to-peer communication or >>> inbound IPv4 connections >>> >>> If this is true, it is highly problematic, because it provides a constr= aint on the >>> semantics of an RFC 1918 address that is not currently present. It is = not entirely >>> clear, though, that this is true. >>> >>> Systems attempting peer-to-peer communication when using RFC 1918 >>> addresses typically must use ICE to handle the artifacts of network add= ress >>> translation. >>> I was not able to understand >>> how ICE would fail here, either in the case where the CLAT was resident= on the >>> node or when it is network resident. In my naive reading, this would w= ork for >>> cases where the ICE server was in the IPv4 global routing domain. Beca= use >>> PLATs are provisioned with a single IP address, the mapped address attr= ibute >> >> What do you mean 1 IP address? 1 IPv4 address? They will have pools of= address for sure. >> > > The figure/chart between section 8.2 and 8.3 says " Global IPv4 > address assigned to IPv4 server"; > I took that to mean that PLATs were generally provisioned with a > single address. With a pool, > the ICE considerations below still apply; it will simply be more > likely that two hosts within a PLAT-served > domain are distinguishable by address as well as address/port. > Yes, you are right. I can make it more clear that the NAT64 will use 1 or more addresses. >>> would always have the same family and address, but it seems it should b= e >>> distinguishable by port. If this is not the case, or there is a differ= ent reason why >>> this mechanism cannot work with ICE, I believe it should be called out = in the >>> draft explicitly. >>> >> >> We make this restriction because of the case where you and I are on the = same ISP. We both have 10.10.10.1 as our local address. Communication fai= ls. >> > > As long as we are assigned different ports by the PLAT, it does not > fail. It is suboptimal, but works. > > Yep, assuming the apps are ICE capable. >> If we have unique address space, are right, it would work. But, we do n= ot want to push an additional level of complexity to try and coordinate uni= que LAN side IP addresses. It is simpler to say this simply does not work.= And, in case of DNS64, users will generally not use IPv4. IPv4 is only u= sed for the case of IPv4 referals or IPv4-only host and APIs. >> >> >>> An ICE-based peer-to-peer connection would, certainly, provide a severe= ly sub- >>> optimal path for two devices within the same 464xlat region, as it woul= d hairpin >>> out and back. But those are not the only potential peer-to-peer connect= ions and >>> it would work at least to some degree. >>> >>> In the case where the CLAT is resident on a device, but that device pro= vides >>> tethering, the document currently says: >>> >>> The CLAT SHOULD perform router function to >>> facilitate packets forwarding through the stateless >>> translation even if it is an end-node. >>> >>> For proper operation of tethered devices, this would appear to require = a MUST, >>> rather than a SHOULD. >>> If it is not MUST, then some description of what will happen is desirab= le. >>> (Perhaps a statement that CLATs which do not provide this functionality= cannot >>> be used when tethering is in place or whether tethered devices require = IPv4?) >>> >> >> I think you are right. We can do a must here. >> >>> Minor Issues: >>> >>> This draft is currently targeted for BCP. I do not believe that it >>> is appropriate to target it for >> >> The rational is that 464XLAT is a best practice for RFC 6144 2.1 network= that has IPv4-only apps in it. >> > > If I understand you correctly, it is not simply IPv4-only apps, but > IPv4-only apps which use IPv4-only > referrals. Is that right? > Too be clear, the known broken cases that we are trying to fix are IPv4-only host (ie Windows XP which is at 40% market share IIRC), IPv4 referals (Amazon prime streaming is a well known case), and IPv4-only network APIs > >>> BCP unless it is preferred over encapsulation-based approaches. I als= o believe >>> that the marketing material which is currently embedded in the text (se= e, for >>> example, section 5) should be removed. >>> >> >> I am happy to eliminate section 5, but section 5 has been required durin= g draft formation because there are many solutions in this space. >> >>> Nits: The description 3GPP applicability relates to 3GPP "Pre-Release 9= ", but >>> there is no citation given. I also note that 3GPP specifications curre= ntly appear >> >> See RFC6459 >> > > Just to be clear, you are proposing adding a citation to RFC 6459? > I can add another citation to RFC 6459 to make this clear >>> to be on release 12, and there is no notice of whether changes between = pre- >> >> The most advanced LTE network is Release 8 at Verizon. >> >> Most phones are release 7 or earlier (sold on the market today) >> >> New networks like the one T-Mobile will launch next year will be partial= ly Release 10 >> >>> release 9 and the current release have changed the topology in a way to >> >> Current release is not relevant to install base. >> > > The current installed base is not the question I was raising. If the > problem you are proposing to solve > is limited such that it goes away in 3GPP Release 10, 11, or 12, then > the text should say that in the 3GPP > applicability section. If an operator/handset manufacturer/app person > targeting a release for > a network can determine whether or not this set of issues will arise > by knowing the relevant 3GPP > release, it would be useful to include that. > That is not the case. The 2 PDP in a 3GPP network issue does go away in Release 9 and onward, but the problem of demand for IPv4 addresses exceeding supply does not go away in the case of dual-stack network connections. In fact, dual-stack does not improve the problem on insufficient IPv4 addresses at all. NAT64 works around the problem of insufficient IPv4 addresses by translating IPv6 to IPv4... thus the edge of the network does not require an IPv4 as dearly as it does today. The 2 PDP issue is a barrier to offering a dual-stack service in most of the world today, but in the long run it is private the public ipv4 scarcity that is the problem to solve. 464XLAT (incuding NAT64) provides IPv4 independence for network operators at the edge network. A few IPv4 addresses can be shared using statistical multiplexing and all known apps will work. We cannot move away from IPv4 unless there is service parity with ipv6, and that is the goal of 464XLAT. This goal is demonstrated in running code. >>> eliminate the multiple PDP issue raised. If the text means to say that= this is not a >> >> But it does not remove the dependency on IPv4 address that are not avail= able.... public and private addresses are both exhausted, so we use squat s= pace. >> > > You've twice mentioned the squat space used in your network, but the > draft doesn't seem to have any specific > text bearing on this problem. The most I see is in 7.1, where an > access network simplifies its operations by running v6 only and > trusting an upstream to run the PLAT. If you think the squat space > use case is important > for understanding the applicability, you may need more text in the draft. > I'd rather not air my ephemeral dirty laundry in an long lived RFC :) The -00 had this text, which was weeded out as too verbose "Now that both global and private IPv4 addresses are scarce to the extent that it is a substantial business risk and limiting growth in many areas, the mobile network providers must support IPv6 to solve the IP address scarcity issue. It is not feasible to simply turn on additional IPv6 PDP network attachments since that does not solve the near-term IPv4 scarcity issues and it increases cost in most cases. The most logical path forward is to replace IPv4 with IPv6 and replace the common NAT44 with stateful translation [RFC6146] and DNS64 [RFC6147]. " CB >>> problem for any version 9 or later, and that the problem exists for any= version >>> prior to 9 which supports multiple address families, it needs to be rew= orded. >> >> I will review the wording. Thanks again for your review. I look forwar= d to more feedback from you, thanks again for taking the time to work with = us and sharing your experience >> > > Thanks again for your quick response. > > regards, > > Ted Hardie > >> Thanks >> Cameron > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From cb.list6@gmail.com Mon Dec 3 11:49:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28BF21F8811 for ; Mon, 3 Dec 2012 11:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4xxC+y9356E for ; Mon, 3 Dec 2012 11:49:45 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A31A821F880B for ; Mon, 3 Dec 2012 11:49:44 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2779115lbk.31 for ; Mon, 03 Dec 2012 11:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qBuFGDkaip6ARUMsovLE+ZYEEBLOjQO3PT6E+0XjgDw=; b=fkgzdHFEvr3IER7grtmhfyIP1XjiPUG+uZTOaeL3l4e7Y1RdRXryhTyPgQEhrJRfX/ DH7KspueuHwvZLycR17NCdkOvzKQ262x+386MdzHQSV3vMp0JmFPEcWyw6VPFrGAqwD6 zg/9jKpQ+d3ESMBwQaUdth7KYzyndDkgrqJ8gwIUKU64NbRVh8VhPytPkL19hInJu9Rm FVduPEzk8qjGxfANdUKvhCj05c+IXH70SrlsGfrtWueBEnmAuLKQRyWazVnmmctYEhyU 2xpSNflfT7z9s3EjS6M6afr1gZdtER1x/6JAmHBPsZqH9jS/8NbpDQFbeMkmivn9G1Qw 02Zw== MIME-Version: 1.0 Received: by 10.152.106.237 with SMTP id gx13mr10373462lab.46.1354564183487; Mon, 03 Dec 2012 11:49:43 -0800 (PST) Received: by 10.112.44.36 with HTTP; Mon, 3 Dec 2012 11:49:43 -0800 (PST) In-Reply-To: References: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> Date: Mon, 3 Dec 2012 11:49:43 -0800 Message-ID: From: Cameron Byrne To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-ietf-v6ops-464xlat.all@tools.ietf.org" , "apps-discuss@ietf.org" , "Byrne, Cameron" Subject: Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:49:46 -0000 Ted, On Mon, Dec 3, 2012 at 10:13 AM, Ted Hardie wrote: > On Sun, Dec 2, 2012 at 7:56 PM, Cameron Byrne wrote: >> Ted, >> >> i have revision to my previous statements >> > > In-line. > >> On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron > >> >> I believe you are right that ICE would work at the app level. >> >> Our statement about hub-and-spoke in the I-D was driven by wording set >> in http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01#section-8.2 >> >> In this way, the NAT64 is a hub for IPv4 communications and IPv4 nodes >> via the NAT64 can communicate with other IPv4 nodes. That is the >> basic architecture, if you need IPv4 access, send it via the CLAT and >> PLAT where CLAT is the spoke and PLAT is the hub >> >> Our claim that p2p does not work is based on the topological case that >> if you are address 2001:DB8:9999::10.1.1.1 and i am address >> 2001:DB8:8888::10.1.1.1 our ipv4-only nodes behind the CLAT cannot >> send packets to each other without something like ICE to force them >> via the NAT64 or TURN. >> > > There are two cases. In the first case, the CLAT is node resident. There, the > CLAT-internal RFC 1918 addresses used by different nodes are > functionally in different > RFC 1918 instances. That's the same case we get now when different > networks use RFC 1918, just > much smaller. In the case where two home networks both use RFC 1918, > in other words, > you get the same situation--they must go out to an ICE server to have > p2p communications even > if they are, say, behind the same cable head end. > > In the second case, the CLAT is not node resident, but it is not > running an IPv4 routing domain > in the traditional sense; in other words, itt does not offer local > routing among the IPv4 nodes, just > translation to v6. Here the situations is mildly different from the > two-home-networks-each-using-RFC1918, > but the result from the point of the application is the same--they > must use an ICE server to communicate. > This is case the where CLAT is just a function of an otherwise normal home gateway. I believe normal IP routing and ethernet switching will occur for the LAN. The CLAT function only occurs WAN <-> LAN > >> If our addresses were different on the LAN like >> 2001:DB8:9999::10.1.9.9 and 2001:DB8:8888::10.1.1.1 we could send >> IPv4 packets to each other without the need for the hub (PLAT) since >> each CLAT would do RFC 6145 translation and remove the first 96 bits >> on the LAN side. This is great if there is a high chance that the >> LAN side IPs are unique, but that is not the case and result would be >> ipv4 packets with src = 10.1.1.1 and dst 10.1.1.1 >> >> The current wording in question is "The 464XLAT architecture only >> supports IPv4 in the >> client server model, where the server has a global IPv4 address. >> This means it is not fit for IPv4 peer-to-peer communication or >> inbound IPv4 connections." >> >> The important term is "fit" vs "not fit". Given that path would go >> via a hub and may require ICE in the apps and infrastructure, it would >> not really be direct p2p, and therefore the WG settle on this specific >> language to error on the side of caution to the reader that this is >> not a "fit" design if p2p is an important use-case in ipv4 supporting >> ipv4. The current statement is a caution to the reader and that is >> the reason it appears in the introduction. >> >> Alternatively, we can strike this from the introduction all together >> and give a more in-depth discussion that reference ICE for the p2p >> case. The WG decided it was best to just punt on p2p and say it does >> not work here in the introduction. >> > > Speaking personally, I don't think this is the right choice, because it > makes it appear you are creating a new semantic for RFC 1918 addresses > (a limited case where the usual tools for providing peer to peer connectivity > for them do not work). If you can't signal that new semantic, the app > has no way of knowing whether the RFC1918 address it has is "full service" > (for whatever that means in the modern NAT and double NAT world) or > "client/server only". That's making a bad situation worse. > > ICE is a complicated bear that no one loves much, but it is currently the > best toolkit we have. A reference to it and a description of how this > works with > it seems like a better choice to me than creating a new, limited RFC > 1918 addressing > semantic. > I agree. That is why we declared the topology to be hub and spoke in the draft. We can add a reference to ICE providing an application level hub and spoke architecture above the network layer hub and spoke topology. does that make sense? CB > regards, > > Ted Hardie From paulej@packetizer.com Mon Dec 3 12:17:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4421F87EB for ; Mon, 3 Dec 2012 12:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SUaJ42LioUm for ; Mon, 3 Dec 2012 12:17:15 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8279521F884B for ; Mon, 3 Dec 2012 12:17:15 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB3KHDiZ015546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 15:17:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354565834; bh=9l9hfrC9tHNnfyyusdvZ7UgQ/Jb7DWA7jSOHSQ049hY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=jdKxWUTCpQN/E3PsjYJj69KHtogTVLFDxBCQM7o7/Kt6pfEqE1VJRVmQjiQc7JA8j +0osHlwXEBXxokJNEuqnDO9EJuZWWzolGjzzgLR5M88OayCk9ZqS2yECzPMOH4xrlQ 4T9ULLyYGIgqISJF4QW0W0gZGekgVlW4IQw1UQyc= From: "Paul E. Jones" To: "'Melvin Carvalho'" , References: In-Reply-To: Date: Mon, 3 Dec 2012 15:17:13 -0500 Message-ID: <0b5801cdd193$2f17d0a0$8d4771e0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B59_01CDD169.46432830" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQITt0iW8mEwUphkpzmiosoEPt1RdQFWSCjvl3EFT9A= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 20:17:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B59_01CDD169.46432830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Just because one has an account on a blog or Twitter or CNN or elsewhere does not mean they have email there. It is important to differentiate an account at a domain from email services at a domain. Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Monday, December 03, 2012 12:47 PM To: webfinger@googlegroups.com Cc: Paul E. Jones; apps-discuss@ietf.org Subject: Re: Draft -07 proposal: Remove dependency on "acct:" scheme On 3 December 2012 02:14, Tim Bray wrote: I don't want to wait for work on this to be completed, and I don't think that its presence is necessary for WebFinger to be useful. So let's take it out. Proposal: Section 4.1: Change the URI in the example from acct: to mailto: Section 4.2: Same Section 5.3: Same Section 5.4: s/it could be an "acct" URI [7], // Section 5.4: Remove 2nd para, beginning "For resources associated with a user account at a host..." Section 5.4: s/both an "acct" URI and any alias/any alias/ Section 8: Change the URI in the example from acct: to mailto: +1 mailto (as either a direct or indirect identifier as per awww) should be used in all cases, acct: is not only extraneous, it conflates the user@host pattern that 99% of clients will interpret as mailto: as of today, it opens the door to one uri scheme per concept e.g. user: and others which dilute the name space, triggering a potential land grab and it's simply confusing to developers SWD had a formulation that contained only mailto: which was cleaner imho On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: No, we're on the same side here. I'm suggesting taking webfinger-07 as a baseline, and all *future* changes need to be proposed as a concrete delta against it. -T On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones wrote: Tim, I didn't mean to be rude by introducing these changes, just trying to move things along. Most changes were fairly trivial, not worth mentioning, and can be seen here: http://tools.ietf.org/rfcdiff?difftype=--hwdiff &url2=draft-ietf-appsawg-webfinger-07.txt The most significant changes were the re-write of section 5.2 and modification to the language related to HTTPS in 5.1. I suspect that is the text to which you refer as preferring it to be "camera-ready". (I would assume the balance of the changes would not need to be presented as "camera-ready", since they're minor editorial things.) In any case, the most important text changes I would like folks to consider is section 5.2 (which aims to fully document the JSON Resource Descriptor object) and paragraphs 2 and 3 in section 5.1. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, December 02, 2012 2:54 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 Thanks to Paul for the extra effort. I'd like to suggest, in the interests of courtesy and efficiency, that from here on on, contributions to this discussion be "camera-ready", that is to say, specific suggestions in the style of a diff, including fully-written-out replacements language. -Tim On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0B59_01CDD169.46432830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Just because one has an account on a blog or Twitter or CNN or = elsewhere does not mean they have email there.  It is important to = differentiate an account at a domain from email services at a = domain.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Monday, December 03, 2012 12:47 PM
To: = webfinger@googlegroups.com
Cc: Paul E. Jones; = apps-discuss@ietf.org
Subject: Re: Draft -07 proposal: Remove = dependency on "acct:" = scheme

 

 

On 3 December 2012 02:14, Tim Bray <tbray@textuality.com> wrote:

I don’t want to wait for work on this to be = completed, and I don’t think that its presence is necessary for = WebFinger to be useful.  So let's take it = out.

Proposal:
Section 4.1: Change the URI in the example from = acct: to mailto:
Section 4.2: Same
Section 5.3: Same
Section = 5.4: s/it could be an "acct" URI [7], //
Section 5.4: = Remove 2nd para, beginning "For resources associated with a user = account at a host...“
Section 5.4: s/both an "acct" = URI and any alias/any alias/
Section 8: Change the URI in the example = from acct: to mailto:


+1

mailto (as either a direct or indirect = identifier as per awww) should be used in all cases, acct: is not only = extraneous, it conflates the user@host pattern that 99% of clients will = interpret as mailto: as of today, it opens the door to one uri scheme = per concept e.g. user: and others which dilute the name space, = triggering a potential land grab and it's simply confusing to = developers

SWD had a formulation that contained only mailto: = which was cleaner imho
 

 

On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray <tbray@textuality.com> wrote:

No, we’re on the same side here. I’m = suggesting taking webfinger-07 as a baseline, and all *future* changes = need to be proposed as a concrete delta against it.  = -T

 

On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Tim,

 

I didn’t mean to be rude by introducing these changes, just = trying to move things along.  Most changes were fairly trivial, not = worth mentioning, and can be seen here:

http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&u= rl2=3Ddraft-ietf-appsawg-webfinger-07.txt

 

The most significant changes were the re-write of section 5.2 and = modification to the language related to HTTPS in 5.1.  I suspect = that is the text to which you refer as preferring it to be = “camera-ready”.  (I would assume the balance of the = changes would not need to be presented as “camera-ready”, = since they’re minor editorial things.)

 

In any case, the most important text changes I would like folks to = consider is section 5.2 (which aims to fully document the JSON Resource = Descriptor object) and paragraphs 2 and 3 in section = 5.1.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, = December 02, 2012 2:54 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: = [apps-discuss] = draft-ietf-appsawg-webfinger-07

 <= /o:p>

Thanks to Paul = for the extra effort.  I’d like to suggest, in the interests = of courtesy and efficiency, that from here on on, contributions to this = discussion be “camera-ready”, that is to say, specific = suggestions in the style of a diff, including fully-written-out = replacements language.

 -Tim

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07

 <= /o:p>

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc.  It’s = a fairly simple format and I believe this text documents it = sufficiently.  Combined with the visual examples, I think this = makes it pretty clear.  Have a look at the JRD documentation in = section 5.2 and provide your comments.

 <= /o:p>

With = respect to HTTPS, it seems there is strong preference for “HTTPS = only”, but some a fair bit of insistence for allowing HTTP.  = I changed the wording in 5.2 to try to capture opinions.  = Previously, the text led with a requirement to try HTTPS first.  = That is still there.  I just added some extra conditions that make = it clearer that there are some instances where a client must not utilize = HTTP.  This might need further refinement, but I think there is a = balance we can strike here between the two camps without introducing a = lot of complex language.

 <= /o:p>

I made some = editorial changes through the document.

 <= /o:p>

Comments = are welcome, as always.  Seems I don’t need to say that to = this group, though :-)

 

Paul

 


______________= _________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 <= /o:p>

 

 

 

------=_NextPart_000_0B59_01CDD169.46432830-- From paulej@packetizer.com Mon Dec 3 12:24:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6ADE21F88BD for ; Mon, 3 Dec 2012 12:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnTOeusGn9oF for ; Mon, 3 Dec 2012 12:24:25 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2934C21F8892 for ; Mon, 3 Dec 2012 12:24:25 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB3KONbY015874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 15:24:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354566263; bh=T06Ext8JsKuRaI33TpZqga+iVFb3UfpuP3PewJHqEFo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=abr9PnKk02K6QnymVf6YT1+zQqiwlrnzXz/07BbYt2E3mVrOl1BWXY/GzK45ub7WU gq2j/sdAdspk84ymhuxAyVlQH5Y8L6vjcn2veYERStwsKBvARfdweEOzvuWWyFS+6E tiA4ecTq+u9MRSzSmImB4x/J7hNHY08Xwuye5yHM= From: "Paul E. Jones" To: "'Melvin Carvalho'" , References: In-Reply-To: Date: Mon, 3 Dec 2012 15:24:23 -0500 Message-ID: <0b6e01cdd194$2f324100$8d96c300$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B6F_01CDD16A.465DBFA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQITt0iW8mEwUphkpzmiosoEPt1RdQIwGr8XAoX4WHaXVgdHsA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 20:24:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B6F_01CDD16A.465DBFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It's definitely not about email. I create an account on Twitter, say "paulej" (which is not mine, BTW). Let's say Twitter opens its network up to other microblogging sites (perhaps it already has). Let's say you create an account at a different microblogging site at example.com. I might post something on Twitter and want to refer to you. Today, that would be done via @melvin, but you're not on twitter. I might refer to @melvin@example.com (+melvin@example.com looks better here, but whatever). Likewise, you might respond back to me with +paulej@twitter.com. There is no email relationship here. But, using the account at the other domain, the respective services can grab pictures and other useful information to make the serves feel more integrated. I have many accounts at various places. But, if I want to refer to an account other than my packetizer.com account, it's not going to be an email ID. Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Monday, December 03, 2012 12:49 PM To: webfinger@googlegroups.com Cc: Paul E. Jones; apps-discuss@ietf.org Subject: Re: Draft -07 proposal: Remove dependency on "acct:" scheme On 3 December 2012 02:35, Brad Fitzpatrick wrote: -1. I feel strongly for keeping the acct: scheme. WebFinger isn't just about email. If Webfinger isnt just about email. What else is it about? On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: I don't want to wait for work on this to be completed, and I don't think that its presence is necessary for WebFinger to be useful. So let's take it out. Proposal: Section 4.1: Change the URI in the example from acct: to mailto: Section 4.2: Same Section 5.3: Same Section 5.4: s/it could be an "acct" URI [7], // Section 5.4: Remove 2nd para, beginning "For resources associated with a user account at a host..." Section 5.4: s/both an "acct" URI and any alias/any alias/ Section 8: Change the URI in the example from acct: to mailto: On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: No, we're on the same side here. I'm suggesting taking webfinger-07 as a baseline, and all *future* changes need to be proposed as a concrete delta against it. -T On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones wrote: Tim, I didn't mean to be rude by introducing these changes, just trying to move things along. Most changes were fairly trivial, not worth mentioning, and can be seen here: http://tools.ietf.org/rfcdiff?difftype=--hwdiff &url2=draft-ietf-appsawg-webfinger-07.txt The most significant changes were the re-write of section 5.2 and modification to the language related to HTTPS in 5.1. I suspect that is the text to which you refer as preferring it to be "camera-ready". (I would assume the balance of the changes would not need to be presented as "camera-ready", since they're minor editorial things.) In any case, the most important text changes I would like folks to consider is section 5.2 (which aims to fully document the JSON Resource Descriptor object) and paragraphs 2 and 3 in section 5.1. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, December 02, 2012 2:54 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 Thanks to Paul for the extra effort. I'd like to suggest, in the interests of courtesy and efficiency, that from here on on, contributions to this discussion be "camera-ready", that is to say, specific suggestions in the style of a diff, including fully-written-out replacements language. -Tim On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0B6F_01CDD16A.465DBFA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s definitely not about email.

 

I create an account on Twitter, say “paulej” (which is = not mine, BTW).  Let’s say Twitter opens its network up to = other microblogging sites (perhaps it already has).  Let’s = say you create an account at a different microblogging site at = example.com.  I might post something on Twitter and want to refer = to you.  Today, that would be done via @melvin, but you’re = not on twitter.  I might refer to @melvin@example.com (+melvin@example.com looks better = here, but whatever).  Likewise, you might respond back to me with = +paulej@twitter.com.  = There is no email relationship here.  But, using the account at the = other domain, the respective services can grab pictures and other useful = information to make the serves feel more = integrated.

 

I have many accounts at various places.  But, if I want to refer = to an account other than my packetizer.com account, it’s not going = to be an email ID.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Monday, December 03, 2012 12:49 PM
To: = webfinger@googlegroups.com
Cc: Paul E. Jones; = apps-discuss@ietf.org
Subject: Re: Draft -07 proposal: Remove = dependency on "acct:" = scheme

 

 

On 3 December 2012 02:35, Brad Fitzpatrick <bradfitz@google.com> = wrote:

-1.  I = feel strongly for keeping the acct: scheme.  WebFinger isn't just = about email.


If = Webfinger isnt just about email.  What else is it = about?
 

 

On Sun, Dec = 2, 2012 at 5:14 PM, Tim Bray <tbray@textuality.com> = wrote:

I = don’t want to wait for work on this to be completed, and I = don’t think that its presence is necessary for WebFinger to be = useful.  So let's take it out.

Proposal:
Section 4.1: = Change the URI in the example from acct: to mailto:
Section 4.2: = Same
Section 5.3: Same
Section 5.4: s/it could be an = "acct" URI [7], //
Section 5.4: Remove 2nd para, beginning = "For resources associated with a user account at a = host...“
Section 5.4: s/both an "acct" URI and any = alias/any alias/
Section 8: Change the URI in the example from acct: = to mailto:

On Sun, Dec = 2, 2012 at 1:57 PM, Tim Bray <tbray@textuality.com> = wrote:

No, = we’re on the same side here. I’m suggesting taking = webfinger-07 as a baseline, and all *future* changes need to be proposed = as a concrete delta against it.  = -T

 

On Sun, Dec = 2, 2012 at 12:59 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Tim,

 

I didn’t mean to be rude by introducing these changes, just = trying to move things along.  Most changes were fairly trivial, not = worth mentioning, and can be seen here:

http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&u= rl2=3Ddraft-ietf-appsawg-webfinger-07.txt

 

The most significant changes were the re-write of section 5.2 and = modification to the language related to HTTPS in 5.1.  I suspect = that is the text to which you refer as preferring it to be = “camera-ready”.  (I would assume the balance of the = changes would not need to be presented as “camera-ready”, = since they’re minor editorial things.)

 

In any case, the most important text changes I would like folks to = consider is section 5.2 (which aims to fully document the JSON Resource = Descriptor object) and paragraphs 2 and 3 in section = 5.1.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Sunday, = December 02, 2012 2:54 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: = [apps-discuss] = draft-ietf-appsawg-webfinger-07

 <= /o:p>

Thanks to Paul = for the extra effort.  I’d like to suggest, in the interests = of courtesy and efficiency, that from here on on, contributions to this = discussion be “camera-ready”, that is to say, specific = suggestions in the style of a diff, including fully-written-out = replacements language.

 -Tim

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07

 <= /o:p>

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc.  It’s = a fairly simple format and I believe this text documents it = sufficiently.  Combined with the visual examples, I think this = makes it pretty clear.  Have a look at the JRD documentation in = section 5.2 and provide your comments.

 <= /o:p>

With = respect to HTTPS, it seems there is strong preference for “HTTPS = only”, but some a fair bit of insistence for allowing HTTP.  = I changed the wording in 5.2 to try to capture opinions.  = Previously, the text led with a requirement to try HTTPS first.  = That is still there.  I just added some extra conditions that make = it clearer that there are some instances where a client must not utilize = HTTP.  This might need further refinement, but I think there is a = balance we can strike here between the two camps without introducing a = lot of complex language.

 <= /o:p>

I made some = editorial changes through the document.

 <= /o:p>

Comments = are welcome, as always.  Seems I don’t need to say that to = this group, though :-)

 

Paul

 


______________= _________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 <= /o:p>

 

 

 

 

------=_NextPart_000_0B6F_01CDD16A.465DBFA0-- From paulej@packetizer.com Mon Dec 3 12:59:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDE421F88F1 for ; Mon, 3 Dec 2012 12:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZUkLqM222rb for ; Mon, 3 Dec 2012 12:58:57 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8170A21F87DB for ; Mon, 3 Dec 2012 12:58:57 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB3Kwtu7017400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 15:58:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354568336; bh=UJmgQ1hvDtmz3/L2aJL4wv5AkB3/RRt7546pu8VUlvU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=UgcKOyKx2GFqdvyInPCspc5/4ipIQ2lQXFMZjGvRPM9ZrQOGS/xbUCj6fenoZZp/n U5n7CIyuHKPIannfdBnFFVf1yqThWxo6ufI18AIaTbBo0QBtXSWCCi4LdcDWQCsz50 0jQK6oKP240IogDOYS6X56uXqO6cszNBFThJFGJc= From: "Paul E. Jones" To: "'John Bradley'" , References: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> In-Reply-To: Date: Mon, 3 Dec 2012 15:58:56 -0500 Message-ID: <0bae01cdd199$02da39f0$088eadd0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BAF_01CDD16F.1A059180" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLG5ikawERVTngmuhW5Swaa7Q+GsgI3/5g1Ap/fbOKV7qYpIA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 20:59:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0BAF_01CDD16F.1A059180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John, But, the subject is the subject of what the JRD describes. Who is the authority here? It's the WF server. If my server tells you "the following JRD describes acct:paulej@packetizer.com", this is not subject to second guessing. The value might not be equal to the "resource" parameter (for good cause), but normally would be. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley Sent: Monday, December 03, 2012 8:11 AM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up "subject" Added Web Finger to subject for the inocent. I would change that to: "The value of the "subject" member is a string whose value is advisory and normally would be expected to be equivalent to the value of the "resource" parameter in the client request. The "subject" identifies the entity to which the JRD claims to describe." The subject is self asserted saying that it is defiantly the ting that the JRD describes will lead to applications making mistakes. The subject is the thing that the JRD claims to be about. It is more likely to be about the thing you did the query on. If they differ the client should understand that the query parameter is the stronger binding. If we go in on the acct: URI then I would be tempted to say that the value SHOULD be the normalized acct: uri for the thing you are asking about. That is likely more useful information to the client. John B. On 2012-12-03, at 4:16 AM, "Paul E. Jones" wrote: Tim, Yeah, I can appreciate that. However, I would like to suggest some slightly different wording. How is this for the first paragraph in 5.2.2? "The value of the "subject" member is a string whose value is advisory and normally would be expected to be equivalent to the value of the "resource" parameter in the client request. The "subject" identifies the entity to which the JRD describes." Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, December 02, 2012 8:15 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Draft -07 mod proposal: Clean up "subject" Right now, section 5.2.2 says "The value of the "subject" member is a string that MUST be set to the same value as the "resource" parameter in the client request. " This is a recipe for trouble, for a couple of reasons. First of all, what does "the same value" mean? Go visit RFC3986, section 6, and enjoy several hundred words walking through all the issues that arise in trying to figure out when two URIs are equivalent, ranging from exact character-by-character identity to all sorts of protocol-specific goo. You are just one level of case-sensitivity-in-%-escaping from a big hairy false negative. I'm also worried about a lack of flexibility. I might have a single webfinger resource that declares a bunch of link relations for a bunch of different resources. This section, as written, wouldn't let me do that. Proposal: Re-write section 5.2.2 as follows: <<<<<<< The value of the "subject" member is a string whose value is advisory, identifying the resource to which the properties given in the "links" member apply. Normally this would be expected to be equivalent to the value of the "resource" parameter in the client request. <<<<<<< On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones < paulej@packetizer.com> wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0BAF_01CDD16F.1A059180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

 

But, the subject is the subject of what the JRD describes.  Who = is the authority here?  It’s the WF server.  If my = server tells you “the following JRD describes = acct:paulej@packetizer.com”, this is not subject to second = guessing.  The value might not be equal to the = “resource” parameter (for good cause), but normally would = be.

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of John Bradley
Sent: Monday, December 03, = 2012 8:11 AM
To: webfinger@googlegroups.com
Cc: = apps-discuss@ietf.org
Subject: Re: [apps-discuss] Web Finger = Draft -07 mod proposal: Clean up = "subject"

 

Added = Web Finger to subject for the inocent.

 

I = would change that to:

 

“The value of the "subject" member is a string whose = value is advisory and normally would be expected to be equivalent to the = value of the "resource" parameter in the client request.  = The "subject" identifies the entity to which the JRD claims to = describe.”

 

The = subject is self asserted saying that it is defiantly the ting that the = JRD describes will lead to applications making mistakes.   The = subject is the thing that the JRD claims to be about.  It is more = likely to be about the thing you did the query on.   If they differ = the client should understand that the query parameter is the stronger = binding.

 

If we go in on the acct: URI then I would be tempted = to say that the value SHOULD be the normalized acct: uri for the thing = you are asking about.  That is likely more useful information to = the client.

 

John B.

 

 

On = 2012-12-03, at 4:16 AM, "Paul E. Jones" <paulej@packetizer.com> = wrote:



Tim,

 

Yeah, I can appreciate that.  However, I would like to suggest = some slightly different wording.  How is this for the first = paragraph in 5.2.2?

 

“The value of the "subject" member is a string whose = value is advisory and normally would be expected to be equivalent to the = value of the "resource" parameter in the client request.  = The "subject" identifies the entity to which the JRD = describes.”

 

Paul

 

 

From:=  Tim Bray = [mailto:tbray@textuality.com] 
Sent: Sunday, December 02, 2012 = 8:15 PM
To: Paul E. = Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com=
Subject: Draft -07 mod proposal: Clean = up "subject"

 

Right now, section 5.2.2 says "The = value of the "subject" member is a string that MUST be set to = the same value as the "resource" parameter in the client = request. "

This is a recipe for trouble, for a couple of = reasons. First of all, what does “the same value” = mean?  Go visit RFC3986, section 6, and enjoy several hundred words = walking through all the issues that arise in trying to figure out when = two URIs are equivalent, ranging from exact character-by-character = identity to all sorts of protocol-specific goo. You are just one level = of case-sensitivity-in-%-escaping from a big hairy false = negative.

I’m also worried about a lack of flexibility. I = might have a single webfinger resource that declares a bunch of link = relations for a bunch of different resources. This section, as written, = wouldn’t let me do that.

Proposal: Re-write section 5.2.2 = as follows:

<<<<<<<
The value of the = "subject" member is a string whose value is advisory, = identifying the resource to which the properties given in the = "links" member apply.  Normally this would be expected to = be equivalent to the value of the "resource" parameter in the = client request. 
<<<<<<&l= t;

On Sun, Dec 2, 2012 at = 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,

 

I = published another version of the WebFinger spec trying to bring closure = to the two open issues I see (resource representation and = transport).  The new version is here:

 

With respect to resource representation, I fully = described the JSON Resource Descriptor within the document.  There = are no external references to RFC 6415 now, no need to go read the XRD = spec, etc.  It’s a fairly simple format and I believe this = text documents it sufficiently.  Combined with the visual examples, = I think this makes it pretty clear.  Have a look at the JRD = documentation in section 5.2 and provide your = comments.

 

With respect to HTTPS, it seems there is strong = preference for “HTTPS only”, but some a fair bit of = insistence for allowing HTTP.  I changed the wording in 5.2 to try = to capture opinions.  Previously, the text led with a requirement = to try HTTPS first.  That is still there.  I just added some = extra conditions that make it clearer that there are some instances = where a client must not utilize HTTP.  This might need further = refinement, but I think there is a balance we can strike here between = the two camps without introducing a lot of complex = language.

 

I = made some editorial changes through the = document.

 

Comments are welcome, as always.  Seems I = don’t need to say that to this group, though = :-)

 

Paul

 


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss=

 

------=_NextPart_000_0BAF_01CDD16F.1A059180-- From paulej@packetizer.com Mon Dec 3 13:03:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8716E21F881F for ; Mon, 3 Dec 2012 13:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoVN5zrSCAvl for ; Mon, 3 Dec 2012 13:03:05 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9788221F8817 for ; Mon, 3 Dec 2012 13:03:05 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB3L3374017641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 16:03:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354568584; bh=ULGnCJSMySlPzAWT/Nmga16DcxNmbKFKIHDmVtDiyW4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=SBBLxsKT2B58RSfasQKNnZPJf6CWBpB33qIkSoRPa1QTfqa9uYsnMw+sJXIxQ1oPH XVKjT3PfZHmZca3RAxAEFknJ54gL4fAH31I0t1zaCf3ZL8p/n2rYY0ff8T2oJqVxvD RLDb/Oh+IAX1rvSarOihWUXZiCihtnScvcdK9l/4= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> In-Reply-To: Date: Mon, 3 Dec 2012 16:03:04 -0500 Message-ID: <0bbe01cdd199$967a6ea0$c36f4be0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BBF_01CDD16F.ADA529F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEKh79DPBqdV8xMCCarbG6K9ejXOwGBQhyVmYIYsLA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 21:03:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0BBF_01CDD16F.ADA529F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brad, =20 Things can be ordered in any way one wants since it=E2=80=99s a JSON = object. That said, placing things in a given order makes it easier for = a human who might manually inspect the document. I put that word in = just to encourage a consistent format. =20 Paul =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Brad Fitzpatrick Sent: Sunday, December 02, 2012 6:48 PM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 =20 Why does the JRD have a recommended key/value order? On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: Folks, =20 I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 =20 With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. = It=E2=80=99s a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments.=20 =20 With respect to HTTPS, it seems there is strong preference for = =E2=80=9CHTTPS only=E2=80=9D, but some a fair bit of insistence for = allowing HTTP. I changed the wording in 5.2 to try to capture opinions. = Previously, the text led with a requirement to try HTTPS first. That = is still there. I just added some extra conditions that make it clearer = that there are some instances where a client must not utilize HTTP. = This might need further refinement, but I think there is a balance we = can strike here between the two camps without introducing a lot of = complex language. =20 I made some editorial changes through the document. =20 Comments are welcome, as always. Seems I don=E2=80=99t need to say that = to this group, though :-) =20 Paul =20 =20 ------=_NextPart_000_0BBF_01CDD16F.ADA529F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Brad,

 

Things can be ordered in any way one wants since it=E2=80=99s a JSON = object.=C2=A0 That said, placing things in a given order makes it easier = for a human who might manually inspect the document.=C2=A0 I put that = word in just to encourage a consistent format.

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Brad Fitzpatrick
Sent: Sunday, December = 02, 2012 6:48 PM
To: webfinger@googlegroups.com
Cc: = apps-discuss@ietf.org
Subject: Re: [apps-discuss] = draft-ietf-appsawg-webfinger-07

 

Why does the = JRD have a recommended key/value order?

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07

 <= /o:p>

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc. =  It=E2=80=99s a fairly simple format and I believe this text = documents it sufficiently.  Combined with the visual examples, I = think this makes it pretty clear.  Have a look at the JRD = documentation in section 5.2 and provide your comments. =

 <= /o:p>

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS = only=E2=80=9D, but some a fair bit of insistence for allowing = HTTP.  I changed the wording in 5.2 to try to capture = opinions.  Previously, the text led with a requirement to try HTTPS = first.  That is still there.  I just added some extra = conditions that make it clearer that there are some instances where a = client must not utilize HTTP.  This might need further refinement, = but I think there is a balance we can strike here between the two camps = without introducing a lot of complex language.

 <= /o:p>

I made some = editorial changes through the document.

 <= /o:p>

Comments = are welcome, as always.  Seems I don=E2=80=99t need to say that to = this group, though :-)

 

Paul

 

 

------=_NextPart_000_0BBF_01CDD16F.ADA529F0-- From paulej@packetizer.com Mon Dec 3 13:12:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD4021F87F1 for ; Mon, 3 Dec 2012 13:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j45j0F10VH2I for ; Mon, 3 Dec 2012 13:11:59 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D7D4E21F85D7 for ; Mon, 3 Dec 2012 13:11:58 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB3LBuqA018080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 16:11:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354569116; bh=hDGTws8Ytz6It2AF6x0Y+IImbyKTofuZCp14SdmeGjU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hh2ZI2fQlvB+gQEqUsD7qKvhi9yxx7ggoZ+5qInHY3BiwV1rLIlkvhWll9zOYg5u1 flZEo8KILlwtCL+oCCYjgxj1IuvMueVdln9PuHx8VFcRw1F97g7mwcGf2lEwB5mDpy OsIIZsJk+rvvBirpaiuadFITkF0K9JDuFfxUx4O0= From: "Paul E. Jones" To: References: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> In-Reply-To: Date: Mon, 3 Dec 2012 16:11:56 -0500 Message-ID: <0bd101cdd19a$d3f59bf0$7be0d3d0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLG5ikawERVTngmuhW5Swaa7Q+GsgI3/5g1Ag8WQqSV8y6xcA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 21:12:02 -0000 Nick, Does the words "would be expected to be equivalent" cause the concern? = Should I make that "normally be equivalent"? The "best" means for "forwarding" would be to have the WF server respond = with a 3xx pointing to the new location. So, if you query acct:paulej@packetizer.com It might return a 301 (though Blaine would suggest 307) that refers the = client to https://example.org/.well-known/webfinger?acct:paulej@example.org An alternative that is not documented is to utilize the "acct" link = relation for this purpose. That was text that used to be in the draft = but was removed and is planned for a separate draft. One could query acct:paulej@packetizer.com and the reply that comes back = might be: { "subject" : "acct:paulej@packetizer.com", "links" : [ { "rel" : "acct", "href" : "acct:paulej@example.com", } ] } This is not a "forwarding", per se, but could inform the client that = additional or other information is available elsewhere. This was never = intended to a be a "forwarding" mechanism, though. The 3xx should do = that. Paul > -----Original Message----- > From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] = On > Behalf Of Nick Jennings > Sent: Monday, December 03, 2012 8:19 AM > To: webfinger@googlegroups.com > Cc: Tim Bray; apps-discuss@ietf.org > Subject: Re: Draft -07 mod proposal: Clean up "subject" >=20 > On Mon, Dec 3, 2012 at 8:16 AM, Paul E. Jones > wrote: > > Tim, > > > > Yeah, I can appreciate that. However, I would like to suggest some > > slightly different wording. How is this for the first paragraph in > 5.2.2? > > > > =E2=80=9CThe value of the "subject" member is a string whose value = is advisory > > and normally would be expected to be equivalent to the value of the > "resource" > > parameter in the client request. The "subject" identifies the = entity > > to which the JRD describes.=E2=80=9D > > >=20 > For someone writing a client library, I would take this to mean that = the > subject "should" match, but since it doesn't have to, there's no point > in checking it and it can be safely ignored. >=20 > Also, I was discussing WF with a friend the other day and they asked > about the possibility of specifying a forwarding address, in the case > you switched email addresses, or have several and don't want to manage > WF data for all of them. >=20 > Is there any in-built mechanism for specifying a forwarding account, = or > something which has a similar effect? >=20 > -Nick From paulej@packetizer.com Mon Dec 3 13:26:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0ED121F84DA for ; Mon, 3 Dec 2012 13:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f38Qv6peiIWH for ; Mon, 3 Dec 2012 13:26:04 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D1A9921F8914 for ; Mon, 3 Dec 2012 13:26:03 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB3LQ1Ke018726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 16:26:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354569962; bh=im7GNft7b3cnVj5S5DsEVHAjHP9OFHdLKJGVllNyUbA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VXYUVgbc0i7gWEgdKjv09QBbKw42qbX8SRtv85IWYZTloYDxzzzKWrs7gbt88g3NF wi+hImJnBNxEHuYo4gUM8sSJ2JFD4ta5IkR/W6MU0brLNLp8yAQhD5R0G8lidOL/ox hJMdEvvBGntHrMeIpzLctoews7vlBGnP0IkYBPO8= From: "Paul E. Jones" To: "'Jan Algermissen'" , "'Brad Fitzpatrick'" References: <8C9F5A6F-5C20-43D3-8681-2E3F6E98E00F@ve7jtb.com> In-Reply-To: Date: Mon, 3 Dec 2012 16:26:01 -0500 Message-ID: <0bf901cdd19c$cbe75050$63b5f0f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQITt0iW8mEwUphkpzmiosoEPt1RdQIwGr8XASDcrjoBw1ThkQFj10vUl0gIuCA= Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 21:26:05 -0000 Jan, There are not a lot external specs that are unusual. There are a few specs that are in the normative section that need to be moved to informative. I've not always been consistent there, I see. But, most of the normative references are to things that should be referenced, like RFC 2119, the HTTP spec, CORS, URI specs, etc. References exist so users unfamiliar with a concept can find information and should be there somewhere. There may even be a few I should mention and didn't. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Jan Algermissen > Sent: Monday, December 03, 2012 11:52 AM > To: Brad Fitzpatrick > Cc: webfinger@googlegroups.com; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on > "acct:" scheme > > > On Dec 3, 2012, at 3:03 AM, Brad Fitzpatrick wrote: > > > I would be fine with acct:-only, but I also don't really care whether > any URI is accepted. > > > > Little bit more simplicity vs future generality. I'll let people who > feel more strongly decide this. > > FWIW I just looked at WebFinger the first time and I am kinda shocked > how much it is coupled with / mentions other specs. > > Have you guys heard about http://www.w3.org/TR/webarch/#orthogonal- > specs ? > > Suggestion: drop the idea of it being a protocol, define a decent media > type and a well-known URI so clients can do their initial GET: > > GET /.well-known/webfinger > Accept: application/webfinger > > The rest of what you try to accomplish IMO will fall into place > naturally. > > > Jan > > > > > > I only feel strongly that we say "acct:" and not "mailto:". > > > > > > On Sun, Dec 2, 2012 at 5:51 PM, John Bradley wrote: > > I agree that WF is not just about email. > > > > A question ( perhaps channeling Blane) is if it should only be about > acct: for simplicity. > > > > As an example should we be expecting it to resolve xmpp: tel: or > other things. > > For http: and https: scheme URI perhaps link headers pointing to a > acct: relation are the most appropriate. > > > > WF is about having a identifier in User Principal name (UPN) form > where the principal is a domain and finding the JRD document or > documents for that account. > > > > There is a bunch of hedging that it can work with any URI but that may > just be confusing the issue. > > > > My personal preference t this point (others working on openID Connect > may well disagree) is to go all in on acct: and just admit that WF is > the resolution process for those URI. > > > > That is what most people think of it as anyway. > > > > John B. > > > > > > On 2012-12-02, at 10:35 PM, Brad Fitzpatrick > wrote: > > > >> -1. I feel strongly for keeping the acct: scheme. WebFinger isn't > just about email. > >> > >> On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > >> I don't want to wait for work on this to be completed, and I don't > think that its presence is necessary for WebFinger to be useful. So > let's take it out. > >> > >> Proposal: > >> Section 4.1: Change the URI in the example from acct: to mailto: > >> Section 4.2: Same > >> Section 5.3: Same > >> Section 5.4: s/it could be an "acct" URI [7], // Section 5.4: Remove > >> 2nd para, beginning "For resources associated with a user account at > >> a host..." Section 5.4: s/both an "acct" URI and any alias/any alias/ > >> Section 8: Change the URI in the example from acct: to mailto: > >> > >> > >> On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray wrote: > >> No, we're on the same side here. I'm suggesting taking webfinger-07 > >> as a baseline, and all *future* changes need to be proposed as a > >> concrete delta against it. -T > >> > >> > >> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones > wrote: > >> Tim, > >> > >> > >> > >> I didn't mean to be rude by introducing these changes, just trying to > move things along. Most changes were fairly trivial, not worth > mentioning, and can be seen here: > >> > >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-appsa > >> wg-webfinger-07.txt > >> > >> > >> > >> The most significant changes were the re-write of section 5.2 and > >> modification to the language related to HTTPS in 5.1. I suspect that > >> is the text to which you refer as preferring it to be "camera-ready". > >> (I would assume the balance of the changes would not need to be > >> presented as "camera-ready", since they're minor editorial things.) > >> > >> > >> > >> In any case, the most important text changes I would like folks to > consider is section 5.2 (which aims to fully document the JSON Resource > Descriptor object) and paragraphs 2 and 3 in section 5.1. > >> > >> > >> > >> Paul > >> > >> > >> > >> From: Tim Bray [mailto:tbray@textuality.com] > >> Sent: Sunday, December 02, 2012 2:54 PM > >> To: Paul E. Jones > >> Cc: apps-discuss@ietf.org; webfinger@googlegroups.com > >> Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 > >> > >> > >> > >> Thanks to Paul for the extra effort. I'd like to suggest, in the > interests of courtesy and efficiency, that from here on on, > contributions to this discussion be "camera-ready", that is to say, > specific suggestions in the style of a diff, including fully-written-out > replacements language. > >> > >> -Tim > >> > >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones > wrote: > >> > >> Folks, > >> > >> > >> > >> I published another version of the WebFinger spec trying to bring > closure to the two open issues I see (resource representation and > transport). The new version is here: > >> > >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 > >> > >> > >> > >> With respect to resource representation, I fully described the JSON > Resource Descriptor within the document. There are no external > references to RFC 6415 now, no need to go read the XRD spec, etc. It's > a fairly simple format and I believe this text documents it sufficiently. > Combined with the visual examples, I think this makes it pretty clear. > Have a look at the JRD documentation in section 5.2 and provide your > comments. > >> > >> > >> > >> With respect to HTTPS, it seems there is strong preference for "HTTPS > only", but some a fair bit of insistence for allowing HTTP. I changed > the wording in 5.2 to try to capture opinions. Previously, the text led > with a requirement to try HTTPS first. That is still there. I just > added some extra conditions that make it clearer that there are some > instances where a client must not utilize HTTP. This might need further > refinement, but I think there is a balance we can strike here between > the two camps without introducing a lot of complex language. > >> > >> > >> > >> I made some editorial changes through the document. > >> > >> > >> > >> Comments are welcome, as always. Seems I don't need to say that to > >> this group, though :-) > >> > >> > >> > >> Paul > >> > >> > >> > >> > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > >> > >> > >> > >> > >> > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From paulej@packetizer.com Mon Dec 3 13:31:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF12721F87F1 for ; Mon, 3 Dec 2012 13:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6gj7sJ8x9bc for ; Mon, 3 Dec 2012 13:31:32 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A48B721F8793 for ; Mon, 3 Dec 2012 13:31:32 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB3LVUJI019021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 16:31:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354570291; bh=k3xC2zEYMWcw3P1XuceDiE1yPW+6nL5RwkvfOydST0s=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=PSaU1TZaecQCJgq4MIJZ7vw1APX0+ai9jCOZMkCx9sbRWs/LPOYaZ1SX/eva7VTQJ HyGKAr2vR2AUDU7IJYVqy3tuzTOsegXeRnjNEjXdiNdsSM1teJdOHEPRBR7DYujkKD RTKjJjUkwHtNOzt9ND4enat693aTlALD6sfQLT3U= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> <0bbe01cdd199$967a6ea0$c36f4be0$@packetizer.com> In-Reply-To: Date: Mon, 3 Dec 2012 16:31:30 -0500 Message-ID: <0c0101cdd19d$8fc7f790$af57e6b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C02_01CDD173.A6F30100" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEKh79DPBqdV8xMCCarbG6K9ejXOwGBQhyVAlA9ArwBjwvLopljJz2A Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 21:31:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0C02_01CDD173.A6F30100 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good argument. I=E2=80=99ll strike the wording. =20 From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 Sent: Monday, December 03, 2012 4:09 PM To: Paul E. Jones Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 =20 You want to make it easier for humans, but it will make it harder for = humans. =20 Humans will waste time being distracted by that, trying to fight their = JSON encoder to get the "recommended" ordering. It also brings up = confusion: "how can an unordered thing be ordered? Why did they write = that? Surely they must mean something else and I'm just not getting it." =20 Most people will write their JSON with a library anyway, so almost = nobody will implement that part. =20 It's a pointless burden IMO. =20 =20 On Mon, Dec 3, 2012 at 1:03 PM, Paul E. Jones = wrote: Brad, =20 Things can be ordered in any way one wants since it=E2=80=99s a JSON = object. That said, placing things in a given order makes it easier for = a human who might manually inspect the document. I put that word in = just to encourage a consistent format. =20 Paul =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Brad Fitzpatrick Sent: Sunday, December 02, 2012 6:48 PM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 =20 Why does the JRD have a recommended key/value order? On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: Folks, =20 I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 =20 With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. = It=E2=80=99s a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments.=20 =20 With respect to HTTPS, it seems there is strong preference for = =E2=80=9CHTTPS only=E2=80=9D, but some a fair bit of insistence for = allowing HTTP. I changed the wording in 5.2 to try to capture opinions. = Previously, the text led with a requirement to try HTTPS first. That = is still there. I just added some extra conditions that make it clearer = that there are some instances where a client must not utilize HTTP. = This might need further refinement, but I think there is a balance we = can strike here between the two camps without introducing a lot of = complex language. =20 I made some editorial changes through the document. =20 Comments are welcome, as always. Seems I don=E2=80=99t need to say that = to this group, though :-) =20 Paul =20 =20 =20 ------=_NextPart_000_0C02_01CDD173.A6F30100 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Good argument.=C2=A0 I=E2=80=99ll strike the = wording.

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Monday, = December 03, 2012 4:09 PM
To: Paul E. Jones
Cc: = webfinger@googlegroups.com; apps-discuss@ietf.org
Subject: Re: = [apps-discuss] = draft-ietf-appsawg-webfinger-07

 

You want to = make it easier for humans, but it will make it harder for = humans.

 

Humans will = waste time being distracted by that, trying to fight their JSON encoder = to get the "recommended" ordering.  It also brings up = confusion: "how can an unordered thing be ordered? Why did they = write that? Surely they must mean something else and I'm just not = getting it."

 

Most people = will write their JSON with a library anyway, so almost nobody will = implement that part.

 

It's a = pointless burden IMO.

 

 

On Mon, Dec = 3, 2012 at 1:03 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Brad,

 

Things can be ordered in any way one wants since it=E2=80=99s a JSON = object.  That said, placing things in a given order makes it easier = for a human who might manually inspect the document.  I put that = word in just to encourage a consistent format.

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of = Brad Fitzpatrick
Sent: Sunday, December 02, 2012 6:48 = PM
To: webfinger@googlegroups.com
Cc: apps-discuss@ietf.org
Subject: Re: = [apps-discuss] = draft-ietf-appsawg-webfinger-07

 <= /o:p>

Why does the = JRD have a recommended key/value order?

On Sun, Dec = 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07

 <= /o:p>

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc. =  It=E2=80=99s a fairly simple format and I believe this text = documents it sufficiently.  Combined with the visual examples, I = think this makes it pretty clear.  Have a look at the JRD = documentation in section 5.2 and provide your comments. =

 <= /o:p>

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS = only=E2=80=9D, but some a fair bit of insistence for allowing = HTTP.  I changed the wording in 5.2 to try to capture = opinions.  Previously, the text led with a requirement to try HTTPS = first.  That is still there.  I just added some extra = conditions that make it clearer that there are some instances where a = client must not utilize HTTP.  This might need further refinement, = but I think there is a balance we can strike here between the two camps = without introducing a lot of complex language.

 <= /o:p>

I made some = editorial changes through the document.

 <= /o:p>

Comments = are welcome, as always.  Seems I don=E2=80=99t need to say that to = this group, though :-)

 

Paul

 

 =

 

------=_NextPart_000_0C02_01CDD173.A6F30100-- From melvincarvalho@gmail.com Mon Dec 3 14:02:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E7021F8890 for ; Mon, 3 Dec 2012 14:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfrA4sba2Cnt for ; Mon, 3 Dec 2012 14:02:06 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id F073621F895D for ; Mon, 3 Dec 2012 14:02:05 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so6427968ieb.39 for ; Mon, 03 Dec 2012 14:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P867k4+87EzfboNHONqa51Z4NKWOFXPIePf5sptuvrM=; b=AqnxXsYBa9qbbhKvZ3+baqTOX2rZCXuArd/ivS7ZCakkmncEpBfBJqmZzULaF4PVlh pTiAqfa1fklayOGUv8+VtIYt22GBZ3vNrEO33UkvyEn/k5XuatbmY8G8l5Ssllmxf+7M SB4iFQvtpY4OcYatKewGROR6QZKAoBCx4vlr3ZXh63n/Nas7V6nGs2kjF8OTrS3BFxpN nLopjqtk+YrJMBFE1nbDYdWux9nI7QN4L5SwYKrlQeWw4Orj+5JPiqXdOC1sMeslIHCP 6cGZHSeemr/qpnV6wIxat8lmeQ2cvzUUOusHaY0ti54epr0H7Yo3g2tXlQk09cLAenMu fNhw== MIME-Version: 1.0 Received: by 10.50.202.73 with SMTP id kg9mr527448igc.51.1354572125507; Mon, 03 Dec 2012 14:02:05 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 3 Dec 2012 14:02:05 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 23:02:05 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d0447a2515d0f0a04cff9e6e1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:02:06 -0000 --f46d0447a2515d0f0a04cff9e6e1 Content-Type: text/plain; charset=ISO-8859-1 On 3 December 2012 19:00, Brad Fitzpatrick wrote: > On Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho wrote: > >> >> >> On 3 December 2012 02:35, Brad Fitzpatrick wrote: >> >>> -1. I feel strongly for keeping the acct: scheme. WebFinger isn't just >>> about email. >>> >> >> If Webfinger isnt just about email. What else is it about? >> > > Accounts on services. > > Limited to social services, or including, say, bank accounts? --f46d0447a2515d0f0a04cff9e6e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 3 December 2012 19:00, Brad Fitzpatri= ck <bradfitz@google.com> wrote:
On Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho <melvin= carvalho@gmail.com> wrote:


On 3 December 2012 02:35, Br= ad Fitzpatrick <bradfitz@google.com> wrote:
-1. = =A0I feel strongly for keeping the acct: scheme. =A0WebFinger isn't jus= t about email.

If Webfinger isnt just abou= t email.=A0 What else is it about?

Accounts on services.


Limited to social services, or including, say, bank = accounts?
--f46d0447a2515d0f0a04cff9e6e1-- From melvincarvalho@gmail.com Mon Dec 3 14:06:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F92F21F8862 for ; Mon, 3 Dec 2012 14:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlfuDOr-LEms for ; Mon, 3 Dec 2012 14:06:25 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7E321F883B for ; Mon, 3 Dec 2012 14:06:25 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id k13so5634009iea.8 for ; Mon, 03 Dec 2012 14:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b03IH6JI0V65aQNbxzAWWuJQriZ8gzXC9SMdEV6ph1o=; b=ajfGjCflYbVLgGr588N6GXYlUVnf6LLkZdDCONAWuRoDx2TLnYo6y8d91MWFxtkoLk 3D34AKym/j9PSYWjTnjH9bunCtzc+2iR7CJ9VV/yTr1j36FAzavuSojgn0ouGh7DfpVe bha0qDfAYKUn2FUUDbzrV5FVqq5P3P9ZusC3EAB1cVlGpIzO/nLiM7gU5SR4MklqBmnz VyBqjyAgE/DAp2WuOBI6UCB3OvZCF+LPGudP6un+NPIFWPuCpEaDWhjQ8IT/eqVeNAGV QZAdC3r8xUM/eZeNI5bSwMGVcXOT4bCAGoie/u7ecSoayyzz8is2lysjoAWh8MYGbusi pu/w== MIME-Version: 1.0 Received: by 10.50.91.168 with SMTP id cf8mr613086igb.20.1354572385022; Mon, 03 Dec 2012 14:06:25 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 3 Dec 2012 14:06:24 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 23:06:24 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8f3b9d3dd4f21304cff9f56e Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:06:26 -0000 --e89a8f3b9d3dd4f21304cff9f56e Content-Type: text/plain; charset=ISO-8859-1 On 3 December 2012 23:02, Brad Fitzpatrick wrote: > > > On Mon, Dec 3, 2012 at 2:02 PM, Melvin Carvalho wrote: > >> >> >> On 3 December 2012 19:00, Brad Fitzpatrick wrote: >> >>> On Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho < >>> melvincarvalho@gmail.com> wrote: >>> >>>> >>>> >>>> On 3 December 2012 02:35, Brad Fitzpatrick wrote: >>>> >>>>> -1. I feel strongly for keeping the acct: scheme. WebFinger isn't >>>>> just about email. >>>>> >>>> >>>> If Webfinger isnt just about email. What else is it about? >>>> >>> >>> Accounts on services. >>> >>> >> Limited to social services, or including, say, bank accounts? >> > > Why would we limit it to social services? > It's relatively easy to understand brad@gmail.com as an email account. Maybe it could be argued brad@twitter.com is a microblogging account. But accountno@citibank.com could be more problematic because you have a further granularity such as sort code etc. If the scope is wide, then there may be more cases to consider... --e89a8f3b9d3dd4f21304cff9f56e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 3 December 2012 23:02, Brad Fitzpatri= ck <bradfitz@google.com> wrote:

On Mon, Dec 3, 2012 at = 2:02 PM, Melvin Carvalho <melvincarvalho@gmail.com> w= rote:


On 3 December 2012 19:00, Brad Fitzpatrick <bradfitz@google.com&g= t; wrote:
O= n Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho <melvincarvalho@gmai= l.com> wrote:

On 3 December 2012 02:35, Brad Fitzpatric= k <bradfitz@google.com> wrote:
-1. = =A0I feel strongly for keeping the acct: scheme. =A0WebFinger isn't jus= t about email.

If Webfinger isnt just abou= t email.=A0 What else is it about?

Accounts on services.


Limited to social services, or including= , say, bank accounts?

=A0Wh= y would we limit it to social services?

It's relatively easy to understand brad@gmail.com as an email account.=A0 Maybe it could be argued brad@twitter.com is a microblogging acco= unt.=A0 But accountno@citibank.co= m could be more problematic because you have a further granularity such= as sort code etc.=A0 If the scope is wide, then there may be more cases to= consider...



--e89a8f3b9d3dd4f21304cff9f56e-- From melvincarvalho@gmail.com Mon Dec 3 14:13:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B4721F8908 for ; Mon, 3 Dec 2012 14:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caaweS3CRZ2C for ; Mon, 3 Dec 2012 14:13:27 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5659D21F8593 for ; Mon, 3 Dec 2012 14:13:27 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id k10so4776462iea.15 for ; Mon, 03 Dec 2012 14:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VCCqUGnWy/DVbTUKmJ3bvJ6Ibgq2mfWy3B0kp8ASVnw=; b=fV/sdS595h2EAn7PUSOJVuTsPBB+kyVOMVDVYum1ADUsxLeZTnJJsPdGudHWbPMvYG CVXjVdFkp3/mNesuw+QRBkmYiPGgF2NJgXEHq7d0yTWxzpRiuWlf2R6XehGjBgqPp4i4 hXuQ/xHK7DN6hXRGACNyuQ0d/RG2RfRQX0a/W30xTKS0EiumGtTdKP5PxH7Lsj/PXZ8/ zpVVGJqVDNe1hWQ+Wn9xFd4WMItWDs+fO+TvjRD2C05T3723gYlKkMCNINsjMM1eSEhn Xw/XCP14irxY/JLdYfqzEnkPoAa440CoaK9Prdr3QmfKB1+FSFQoDNrWQzwzt57phd9U Zq+Q== MIME-Version: 1.0 Received: by 10.50.202.73 with SMTP id kg9mr555254igc.51.1354572806718; Mon, 03 Dec 2012 14:13:26 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 3 Dec 2012 14:13:26 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 23:13:26 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d0447a251f785d504cffa0e92 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:13:28 -0000 --f46d0447a251f785d504cffa0e92 Content-Type: text/plain; charset=ISO-8859-1 On 3 December 2012 23:09, Brad Fitzpatrick wrote: > On Mon, Dec 3, 2012 at 2:06 PM, Melvin Carvalho wrote: > >> >>>>>> If Webfinger isnt just about email. What else is it about? >>>>>> >>>>> >>>>> Accounts on services. >>>>> >>>>> >>>> Limited to social services, or including, say, bank accounts? >>>> >>> >>> Why would we limit it to social services? >>> >> >> It's relatively easy to understand brad@gmail.com as an email account. >> Maybe it could be argued brad@twitter.com is a microblogging account. >> But accountno@citibank.com could be more problematic because you have a >> further granularity such as sort code etc. If the scope is wide, then >> there may be more cases to consider... >> > > sort? scope? cases? I don't understand what you're asking about, but in > any case: The rules are all the same regardless of what service(s) the > hostname provides. > > 1) hit /.well-known/webfinger, 2) receive document. > > If Citibank pivots and becomes a Pinterest clone, their WebFinger still > works. > sorry perhaps its a UK thing ... banks have both an account identifier and a "sort code" to identify a branch just wondering if accountid@bank.com would be considered part of webfinger scope hope that makes more sense, tho perhaps you've answered already in that, if the file is missing it's not part of the system --f46d0447a251f785d504cffa0e92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 3 December 2012 23:09, Brad Fitzpatri= ck <bradfitz@google.com> wrote:
On Mon, Dec 3, 2012 at 2:06 PM, Melvin Carvalho <melvin= carvalho@gmail.com> wrote:

If Webfinger isnt just about email.=A0 = What else is it about?

Accounts on services.


Limited to social services, or including, say,= bank accounts?

=A0Why would we l= imit it to social services?

It's relatively easy to understand brad@gmail.com as an email account.=A0 Maybe it cou= ld be argued brad@twi= tter.com is a microblogging account.=A0 But accountno@citibank.com could be more p= roblematic because you have a further granularity such as sort code etc.=A0= If the scope is wide, then there may be more cases to consider...

sort? scope? cases? =A0I don&#= 39;t understand what you're asking about, but in any case: =A0The rules= are all the same regardless of what service(s) the hostname provides.

1) hit /.well-known/webfinger, =A02) receive document.
=

If Citibank pivots and becomes a Pinterest clone, their= WebFinger still works.

sorry perhap= s its a UK thing ... banks have both an account identifier and a "sort= code" to identify a branch

just wondering if accountid@bank.= com would be considered part of webfinger scope

hope that makes = more sense, tho perhaps you've answered already in that, if the file is= missing it's not part of the system

--f46d0447a251f785d504cffa0e92-- From joseph@josephholsten.com Mon Dec 3 14:14:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620B521F8929 for ; Mon, 3 Dec 2012 14:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lAYMn1FopNu for ; Mon, 3 Dec 2012 14:14:07 -0800 (PST) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE2321F8908 for ; Mon, 3 Dec 2012 14:14:06 -0800 (PST) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id B1A8D9090; Mon, 3 Dec 2012 17:14:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; s=sasl; bh= E4cSCdKC8CM/kkeOgjFeoOOrVJc=; b=cZkSUkm1e1w8vHXv2BiAo8ZvH37MtvFA +4dNOOR/irJQsBAhXxhQ+xCisnOsRNiRWE3C2HPGdH53nHZwjbL+cbLlD/DJIdF5 3+H8QuTu6PXcSXNXT1wrnV2p3KdNDKoj1vkeKOcTk1Oz8+KExjIrFeh77ORK/1l2 GF9kP5CiXE0= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 9F77C908F; Mon, 3 Dec 2012 17:14:04 -0500 (EST) Received: from [192.168.9.49] (unknown [75.147.189.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by b-sasl-quonix.pobox.com (Postfix) with ESMTPSA id E061A908E; Mon, 3 Dec 2012 17:14:03 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joseph Anthony Pasquale Holsten In-Reply-To: Date: Mon, 3 Dec 2012 22:14:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7B156D8E-78F4-481E-AA0F-8F726F433C97@josephholsten.com> References: To: webfinger@googlegroups.com, "apps-discuss@ietf.org" X-Mailer: Apple Mail (2.1499) X-Pobox-Relay-ID: BF74722E-3D96-11E2-B2EE-995F2E706CDE-15777318!b-pb-sasl-quonix.pobox.com Subject: Re: [apps-discuss] Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:14:08 -0000 URI equivalence/normalization/canonicalization is a well defined rat = hole. It's URI scheme specific, so we'll never be able to define all of = these. If you think we need to explicitly say that "We defer the = definition of URI equivalence to the mechanism defined by its schema," = we can. On 2012-12-03, at 05:42 , James M Snell wrote: > -1 ... fixing this would be good but your proposed text isn't quite = enough without either defining or specifically referencing what = "equivalence" means. For example, as currently defined, the resource = parameter can be a relative URI reference, while the subject could be an = absolute URI reference. How does one determine equivalence exactly?=20 >=20 > - James >=20 >=20 > On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray wrote: > Right now, section 5.2.2 says "The value of the "subject" member is a = string that MUST be set to the same value as the "resource" parameter in = the client request. " >=20 > This is a recipe for trouble, for a couple of reasons. First of all, = what does =93the same value=94 mean? Go visit RFC3986, section 6, and = enjoy several hundred words walking through all the issues that arise in = trying to figure out when two URIs are equivalent, ranging from exact = character-by-character identity to all sorts of protocol-specific goo. = You are just one level of case-sensitivity-in-%-escaping from a big = hairy false negative. >=20 > I=92m also worried about a lack of flexibility. I might have a single = webfinger resource that declares a bunch of link relations for a bunch = of different resources. This section, as written, wouldn=92t let me do = that. >=20 > Proposal: Re-write section 5.2.2 as follows: >=20 > <<<<<<< > The value of the "subject" member is a string whose value is advisory, = identifying the resource to which the properties given in the "links" = member apply. Normally this would be expected to be equivalent to the = value of the "resource" parameter in the client request.=20 > <<<<<<< >=20 > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: > Folks, >=20 > =20 >=20 > I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: >=20 > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 >=20 > =20 >=20 > With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. It=92s = a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments. >=20 > =20 >=20 > With respect to HTTPS, it seems there is strong preference for =93HTTPS = only=94, but some a fair bit of insistence for allowing HTTP. I changed = the wording in 5.2 to try to capture opinions. Previously, the text led = with a requirement to try HTTPS first. That is still there. I just = added some extra conditions that make it clearer that there are some = instances where a client must not utilize HTTP. This might need further = refinement, but I think there is a balance we can strike here between = the two camps without introducing a lot of complex language. >=20 > =20 >=20 > I made some editorial changes through the document. >=20 > =20 >=20 > Comments are welcome, as always. Seems I don=92t need to say that to = this group, though :-) >=20 > =20 >=20 > Paul >=20 > =20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 From paul.hoffman@vpnc.org Mon Dec 3 14:17:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA2E21F892B for ; Mon, 3 Dec 2012 14:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUv0eXeWjgmM for ; Mon, 3 Dec 2012 14:17:15 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1622B21F8929 for ; Mon, 3 Dec 2012 14:17:15 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qB3MHC4I006623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 3 Dec 2012 15:17:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Mon, 3 Dec 2012 14:17:12 -0800 Content-Transfer-Encoding: 7bit Message-Id: <83DE50D7-1095-415A-BA9C-36D2BEFA80E7@vpnc.org> References: <2BD6CE37760538020CEE52FF@JcK-HP8200.jck.com> To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1499) Subject: [apps-discuss] ALL WEBFINGER POSTERS: PLEASE READ: (was: Re: Enough from Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:17:15 -0000 On Dec 3, 2012, at 10:48 AM, Barry Leiba wrote: >> Having just received another huge batch of specialized webfinger >> correspondence over the weekend, most of which couldn't even >> bother to be identified sufficiently by draft or topic to enable >> easy filtering, I'm unsubscribing from apps-discuss. Someone >> might let me (and the others I assume have departed for other >> reasons) know when this is over and the list is back to being >> used for other topics. > > Indeed, and I've had some off-list complaints as well. Because of > these, and because I've received only support and no complaints about > creating a "webfinger" non-WG mailing list, I've put in the request > and asked that it be handled ASAP. > > The creation of , which you'll be able to > subscribe to here when it's created: > https://www.ietf.org/mailman/listinfo/webfinger > (that link won't work yet) will be announced on ietf-announce and on > this list as well. > > *** When that list is created, please move all webfinger-related > discussions to that list. *** > > *** In the meantime, please try to hold off on further discussion of > webfinger on the apps-discuss list. *** > > Hang on for a day or two until the new list is created, and carry on > over there. And realize that once discussion is taken up on that > list, participants will have to read the archives to see what they > missed before they subscribed -- it's not practical to try to > pre-subscribe people in this case. > > Thanks, everyone (on both sides of this fence) for your understanding. > We made a mistake, underestimating the traffic and the length of the > discussion, and we have to do what we can to correct for it now. > > Barry, App AD > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From william_john_mills@yahoo.com Mon Dec 3 14:20:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BDC21F8972 for ; Mon, 3 Dec 2012 14:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.109 X-Spam-Level: X-Spam-Status: No, score=-16.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8qOAKkpeFdw for ; Mon, 3 Dec 2012 14:20:11 -0800 (PST) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by ietfa.amsl.com (Postfix) with ESMTP id 141B921F8934 for ; Mon, 3 Dec 2012 14:20:10 -0800 (PST) Received: from [98.139.212.145] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 03 Dec 2012 22:20:10 -0000 Received: from [98.139.212.192] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 03 Dec 2012 22:20:10 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 03 Dec 2012 22:20:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 354582.440.bm@omp1001.mail.bf1.yahoo.com Received: (qmail 10191 invoked by uid 60001); 3 Dec 2012 22:20:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354573209; bh=i/2HKDf/r1idF+DxKKv9d14EAzP/iTNlOEP0x2u84Y4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SwyEG0Zowk7h5gF2XaHnRom7cX854qgpMCot5rF36oVxbJRvirf0yg5w8Ex4wqTQD4PfDxap6QOIHZA2a80ca2yotphVZs0UJ90L+r083f5JFABhuCZfyPp4jcLUqte2nR+MrcPwfiR2Rq24AD2fhkR1iisoat2YZXtW8IEMMEs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Jv/RFYOyeLSrjhk79bDMBnbUz3QV2cFQ6J3b39wJ/jXU+XoCc0oSPAzHBziDRpn/OXC6Z5ZQEZrE7G2klz4chmTWsNCfKzZuxpurHXOZGVmCrDesGrw2zWv8o+TybBLbie9mEtLbhYgvMoDlLO9NOXZygRV2RqUITLfwXdsMKaM=; X-YMail-OSG: T7m_ZosVM1l4iZe7h_FOIMMSQ9titXxiP8cOhU4PeXkneCj t3By9sZpZ1MjpgEnPxA4lzw6t9NhDGeXe0rmy.4WkjzUyBP_WLNgP_EG31j. WV9kjxPq3weERbxJQVlsBIQMiud18ksWkDOUtvIH9sbr.lGJpC0u2uiQpJtf FEtiWkAfd5kr8IzbYGscsYxgdh3hLhdF9q6U7iozhcaysRquGvJhQ6tqksNn hDWIx3oOB.bfKM9sMoKyUl5Oi7DdZrQOdqcnv4R7n7cNTARQ1QFW78DmTUit aOcoz6kCMv.nrsGBPutFPicA4DSUFYcPBnHC4dFs8IGsVZmQkC1RczgpcMO3 bQnMK0olJm_Wfr1ruzG1QDpljk2Jpq9pjHaPD8aitJxDc2vwIbYD2De6_JRG 2i.LSfKFweS4Ja8UTS_sS7E45jIAUCQD6mdZO2JE.eA7D.p7DxM_w1rojUkv Pzpk4VvxPmbIp6MlL1ooSTQmQDQ-- Received: from [98.139.248.67] by web31802.mail.mud.yahoo.com via HTTP; Mon, 03 Dec 2012 14:20:09 PST X-Rocket-MIMEInfo: 001.001, VGhlIHNhbWUgcGVyc29uIG1pZ2h0IGhhdmUgbXVsdGlwbGUgd2F5cyB0byBjb250YWN0IGFuZCBleHRhbnQgc2NoZW1lcyBoYXZlIGEgc3BlY2lmaWMgcHJvdG9jb2wgY29udGV4dCwgc28gcXVlcnlpbmcgYWNjdDp3bWlsbHNfOTIxMDUgYWdhaW5zdCBhIEphYmJlciBvciBTa3lwZSBvciBJUkMgb3Igb3RoZXIgc2VydmljZSB0byBiZSBuYW1lZCBsYXRlciB3aWxsIHdvcmsgd2l0aG91dCBjb25mdXNpb24sIHdoZXJlIG1haWx0bzp3bWlsbHNfOTIxMDUgaW1wbGllcyBhbiBTTVRQIGRlc3RpbmF0aW9uIChhbmQBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.129.483 References: Message-ID: <1354573209.1167.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Mon, 3 Dec 2012 14:20:09 -0800 (PST) From: William Mills To: Melvin Carvalho , "webfinger@googlegroups.com" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-713075550-1354573209=:1167" Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Webfinger and acct: Re: Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:20:14 -0000 ---1036955950-713075550-1354573209=:1167 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The same person might have multiple ways to contact and extant schemes have= a specific protocol context, so querying acct:wmills_92105 against a Jabbe= r or Skype or IRC or other service to be named later will work without conf= usion, where mailto:wmills_92105 implies an SMTP destination (and lacking d= omain also presumes a local context.=0A=0A=0A=0A=0A>_______________________= _________=0A> From: Melvin Carvalho =0A>To: webfi= nger@googlegroups.com =0A>Cc: apps-discuss@ietf.org =0A>Sent: Monday, Decem= ber 3, 2012 2:02 PM=0A>Subject: Re: [apps-discuss] Draft -07 proposal: Remo= ve dependency on "acct:" scheme=0A> =0A>=0A>=0A>=0A>=0A>On 3 December 2012 = 19:00, Brad Fitzpatrick wrote:=0A>=0A>On Mon, Dec 3, = 2012 at 9:48 AM, Melvin Carvalho wrote:=0A>>=0A>= >=0A>>>=0A>>>=0A>>>On 3 December 2012 02:35, Brad Fitzpatrick wrote:=0A>>>=0A>>>-1. =A0I feel strongly for keeping the acct: sch= eme. =A0WebFinger isn't just about email.=0A>>>=0A>>>If Webfinger isnt just= about email.=A0 What else is it about?=0A>>>=0A>>=0A>>=0A>>Accounts on ser= vices.=0A>>=0A>>=0A>Limited to social services, or including, say, bank acc= ounts?=0A>=0A>_______________________________________________=0A>apps-discu= ss mailing list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/apps-discuss=0A>=0A>=0A> ---1036955950-713075550-1354573209=:1167 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The same person might have multiple ways to contact and extant schemes ha= ve a specific protocol context, so querying acct:wmills_92105 against a Jab= ber or Skype or IRC or other service to be named later will work without co= nfusion, where mailto:wmills_92105 implies an SMTP destination (and lacking= domain also presumes a local context.

From: Melvin Carvalho <melvincarvalho@gmail.com>
To: webfinger@googlegroups.com
Cc: apps-discuss@ietf.org
Sent: Monday, December 3, 2012 2:02 PM
Subject: Re: [apps-discuss] Draf= t -07 proposal: Remove dependency on "acct:" scheme

=


O= n 3 December 2012 19:00, Brad Fitzpatrick <bradfitz@google.com> wrote:
=0A
On= Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho <melvincarvalho@gmail.com><= /span> wrote:
=0A=0A

<= br>
On 3 December 2012 02:35, B= rad Fitzpatrick <bradfitz@google.com> wrote:
=0A=0A
=0A
-1.  I feel strongly for keeping the acct: schem= e.  WebFinger isn't just about email.
If Webfinger isnt just about email.  What else is it about?
=0A=0A=

Accounts on services.

=0A

Limited to social s= ervices, or including, say, bank accounts?
=0A

________________= _______________________________
apps-discuss mailing list
app= s-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-= discuss


---1036955950-713075550-1354573209=:1167-- From dhc@dcrocker.net Mon Dec 3 14:44:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DC221F88C2 for ; Mon, 3 Dec 2012 14:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMCnffM6KvBH for ; Mon, 3 Dec 2012 14:44:40 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BBEDE21F883B for ; Mon, 3 Dec 2012 14:44:40 -0800 (PST) Received: from [192.168.1.9] (adsl-67-127-190-125.dsl.pltn13.pacbell.net [67.127.190.125]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id qB3MiZt9007331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Dec 2012 14:44:36 -0800 Message-ID: <50BD2B49.6090507@dcrocker.net> Date: Mon, 03 Dec 2012 14:44:25 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Barry Leiba References: <2BD6CE37760538020CEE52FF@JcK-HP8200.jck.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 03 Dec 2012 14:44:36 -0800 (PST) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Enough from Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:44:41 -0000 On 12/3/2012 10:48 AM, Barry Leiba wrote: > Indeed, and I've had some off-list complaints as well. Because of > these, and because I've received only support and no complaints about > creating a "webfinger" non-WG mailing list, I've put in the request > and asked that it be handled ASAP. ... > *** When that list is created, please move all webfinger-related > discussions to that list. *** This sequence would seem, to me, a rather strong prima facie case for turning webfinger into a formal wg, with the discipline of a charter, schedule, and clear deliverables. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hallam@gmail.com Mon Dec 3 15:01:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59C721F89A0 for ; Mon, 3 Dec 2012 15:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM3rFjFTy4jQ for ; Mon, 3 Dec 2012 15:01:00 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B71E121F8998 for ; Mon, 3 Dec 2012 15:01:00 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so3665392oag.31 for ; Mon, 03 Dec 2012 15:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ryVBUHUhEph1mOCnbaP42rIW/t+G/QFbL/F4ZzXz1hI=; b=KfUenv+nnZHEHsfFoxSxcDUVFg046EyG97QJinJOSQiDT3GkVivsxcvQ1Aj6Z2vQz+ cfSI8O08M3oASg8F+f2dWrXcTume9YQ+oW7hqRitxvfXSsMujsCFohFSOn6ha2qi8+wQ /HSca0l9mPkulre6Tx4aOsKar5FxJTvGvwCCHUKc0Z4COOMqepkw0kuSCLQSJ/DzGo6W A2hceMh1Zt03oqGeucgFa8rmNIJ/RpzEQGzfAC/jhkSpNNIb5uHekjhZMP2JQiCOOsCi ELN7wKvYvm8SXALneHBQySQV9MiCbA91tQIGOmS5AGYBAodwHMq0HyWrqrxovBEGDgUB LWrA== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr9425929oeb.24.1354575660208; Mon, 03 Dec 2012 15:01:00 -0800 (PST) Received: by 10.76.19.43 with HTTP; Mon, 3 Dec 2012 15:01:00 -0800 (PST) In-Reply-To: <50BD2B49.6090507@dcrocker.net> References: <2BD6CE37760538020CEE52FF@JcK-HP8200.jck.com> <50BD2B49.6090507@dcrocker.net> Date: Mon, 3 Dec 2012 18:01:00 -0500 Message-ID: From: Phillip Hallam-Baker To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=e89a8fb1f4180c531804cffab983 Cc: Barry Leiba , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Enough from Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 23:01:02 -0000 --e89a8fb1f4180c531804cffab983 Content-Type: text/plain; charset=ISO-8859-1 And maybe explaining what the point of it is? On Mon, Dec 3, 2012 at 5:44 PM, Dave Crocker wrote: > > > On 12/3/2012 10:48 AM, Barry Leiba wrote: > >> Indeed, and I've had some off-list complaints as well. Because of >> these, and because I've received only support and no complaints about >> creating a "webfinger" non-WG mailing list, I've put in the request >> and asked that it be handled ASAP. >> > ... > > *** When that list is created, please move all webfinger-related >> discussions to that list. *** >> > > > This sequence would seem, to me, a rather strong prima facie case for > turning webfinger into a formal wg, with the discipline of a charter, > schedule, and clear deliverables. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > -- Website: http://hallambaker.com/ --e89a8fb1f4180c531804cffab983 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And maybe explaining what the point of it is?



On Mon, Dec 3, 2012 at 5:44 PM, Dave Crocker <dhc@= dcrocker.net> wrote:


On 12/3/2012 10:48 AM, Barry Leiba wrote:
Indeed, and I've had some off-list complaints as well. =A0Because of these, and because I've received only support and no complaints about creating a "webfinger" non-WG mailing list, I've put in the r= equest
and asked that it be handled ASAP.
...

*** When that list is created, please move all webfinger-related
discussions to that list. ***


This sequence would seem, to me, a rather strong prima facie case for turni= ng webfinger into a formal wg, with the discipline of a charter, schedule, = and clear deliverables.

d/

--
=A0Dave Crocker
=A0Brandenburg InternetWorking
=A0bbiw.net=

_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--
= Website: http://hallambaker.com/
--e89a8fb1f4180c531804cffab983-- From ve7jtb@ve7jtb.com Mon Dec 3 15:04:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2296A21F8987 for ; Mon, 3 Dec 2012 15:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.335 X-Spam-Level: X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r0GHsTd1HRf for ; Mon, 3 Dec 2012 15:04:46 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 954E121F8981 for ; Mon, 3 Dec 2012 15:04:46 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so3449506obc.31 for ; Mon, 03 Dec 2012 15:04:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version:x-mailer :x-gm-message-state; bh=gIW56y+lUrY/hSI2be+GsbOxf7NEzn1gdxgEHRD7bQc=; b=Zk51WUMy5dTl8KLwnB4pJjUL39TlLRtV60E5UcFgNN+ZtNGuo9jtSSOcMK9hsnq2Yh +eVdC6+2ahfK1Hq4to8kIN/XW40VK4VcOOTJOY+57I/MZE6tB8qFDTwV+K26W+Ob3V1H kByTs8hnHx0DwygulcnVNnIVSWpQrubI0VMae4Q3mW/dI3yNkaQtcN5DWXNI6Q/xKiND fYc1xExx6qc27jeOq1KIjlzIKjYYouHYt6upp2FSKKyU0fwIeUCLr/8oaOC0vxyZN69j TjlboqWaJdo8J4LV4RWn1fN4YL4PAvyNmw4mWb5Fg/mNxtT5zcUMzbw+ZnNtiKSkaND7 w98Q== Received: by 10.60.2.2 with SMTP id 2mr9928588oeq.89.1354575886061; Mon, 03 Dec 2012 15:04:46 -0800 (PST) Received: from [192.168.1.211] (190-20-2-238.baf.movistar.cl. [190.20.2.238]) by mx.google.com with ESMTPS id s5sm15066143obo.10.2012.12.03.15.04.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 15:04:45 -0800 (PST) From: John Bradley Content-Type: multipart/alternative; boundary="Apple-Mail=_9945DC2C-6E09-4916-B296-267510301635" Message-Id: <19F00756-769E-4774-852B-EE403876610D@ve7jtb.com> Date: Mon, 3 Dec 2012 20:04:37 -0300 To: "apps-discuss@ietf.org Discuss" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQklpgtc4J7rTr0ng33QhEYm702WN2WumtI+T3R/EoIDWP8IfcFBNgGSu9VCGyY7E30iFRME Subject: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 23:04:47 -0000 --Apple-Mail=_9945DC2C-6E09-4916-B296-267510301635 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I am guessing this is wrong or the text needs to be clarified. HTTP/1.1 307 Temporary Redirect Location: http://wf.example.net/example.com/webfinger? resource=3Dacct%3Aalice%40example.com HTTP/1.1 The client MUST follow the redirection, re-issuing the request to the URL provided in the Location header. If the primary method of delegation is redirect, one expects the client = to take the redirect URI and append the appropriate query parameters to = it and reissue the request. The r=E9ponse the input query parameters parameters, indicating the = redirect URI is opaque to the client. =20 On the face of it that would be OK but if a sever can do a dynamic = redirect based on query parameters can probably also run a WF server. I thought the redirect was supposed to be to the new base URL. If the server is repressible for completely formatting the redirect URI = including query parameters that needs to be made clearer to the server = developers. John B. --Apple-Mail=_9945DC2C-6E09-4916-B296-267510301635 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I am = guessing this is wrong or the text needs to be = clarified.

http://wf.example.ne=
t/example.com/webfinger?
                       resource=3Dacct%3Aalice%40example.com HTTP/1.1

   The client MUST follow the redirection, re-issuing the request to the
   URL provided in the Location header.


If the primary method of = delegation is redirect, one expects the client to take the redirect URI = and append the appropriate query parameters to it and reissue the = request.

The r=E9ponse  the input query = parameters parameters, indicating the redirect URI is opaque to the = client.  
On the face of it that would be OK but if a = sever can do a dynamic redirect based on query parameters can probably = also run a WF server.

I thought the redirect = was supposed to be to the new base URL.

If the = server is repressible for completely formatting the redirect URI = including query parameters that needs to be made clearer to the server = developers.

John = B.


= --Apple-Mail=_9945DC2C-6E09-4916-B296-267510301635-- From paulej@packetizer.com Mon Dec 3 17:32:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B44F21F87BA for ; Mon, 3 Dec 2012 17:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ac9lVYUQw2V for ; Mon, 3 Dec 2012 17:32:21 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1E21F87AF for ; Mon, 3 Dec 2012 17:32:20 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB41WJVV029827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 20:32:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354584740; bh=00tWa4JfO1miVvMqUcBV1oxYwKWvD6ImWtFeO7KtH/s=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=jgTdAy2V0UkfFTSCGH/fV72FgVPMSYrZ0GpoLbzQ4S4Wv/texX0mYQV/SUnB/nEkG +hDSRYx/16LkYiJwPlyEO/AelOJXGGcPfPBNJ3OvBN4fLXHYSerHvna7cK/DfgpASL a4sM9p2lwKmZGUCitzEc9avVVi0RaD4B9c0vMsBk= From: "Paul E. Jones" To: "'John Bradley'" , References: <19F00756-769E-4774-852B-EE403876610D@ve7jtb.com> In-Reply-To: <19F00756-769E-4774-852B-EE403876610D@ve7jtb.com> Date: Mon, 3 Dec 2012 20:32:19 -0500 Message-ID: <0c9b01cdd1bf$3455f660$9d01e320$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C9C_01CDD195.4B80B1B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtewO6JN4h2NwrXNVKSoydbbs6zpfIhowg Content-Language: en-us Subject: Re: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 01:32:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0C9C_01CDD195.4B80B1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, =20 Servers always return URL parameters as a part of the 3xx. Try this: $ curl -v http://www.twitter.com/?test=3D123 =20 It should return a 3xx referring you to twitter.com and it will include = the URI parameter in the Location header. The client would not append yet another parameter onto it. And we would not want it to. The server = might redirect the client to an entirely different user account or other URI = as the new resource. =20 Paul =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley Sent: Monday, December 03, 2012 6:05 PM To: apps-discuss@ietf.org Discuss Subject: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong =20 I am guessing this is wrong or the text needs to be clarified. =20 HTTP/1.1 307 Temporary Redirect Location: http://wf.example.net/example.com/webfinger? resource=3Dacct%3Aalice%40example.com HTTP/1.1 =20 The client MUST follow the redirection, re-issuing the request to the URL provided in the Location header. =20 =20 If the primary method of delegation is redirect, one expects the client = to take the redirect URI and append the appropriate query parameters to it = and reissue the request. =20 The r=E9ponse the input query parameters parameters, indicating the = redirect URI is opaque to the client. =20 On the face of it that would be OK but if a sever can do a dynamic = redirect based on query parameters can probably also run a WF server. =20 I thought the redirect was supposed to be to the new base URL. =20 If the server is repressible for completely formatting the redirect URI including query parameters that needs to be made clearer to the server developers. =20 John B. =20 =20 ------=_NextPart_000_0C9C_01CDD195.4B80B1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

John,

 

Servers always return URL parameters as a part of the 3xx.=A0 Try = this:

$ curl -v http://www.twitter.com/?test=3D123

 

It should return a 3xx referring you to twitter.com and it will = include the URI parameter in the Location header.=A0 The client would = not append yet another parameter onto it.=A0 And we would not want it = to.=A0 The server might redirect the client to an entirely different = user account or other URI as the new resource.

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of John Bradley
Sent: Monday, December 03, = 2012 6:05 PM
To: apps-discuss@ietf.org = Discuss
Subject: [apps-discuss] Web Finger Draft 07 Sec 8 = Example response wrong

 

I am = guessing this is wrong or the text needs to be = clarified.

 

HTTP/1.1 307 Temporary =
Redirect
=A0=A0=A0=A0 Location: http://wf.example.n=
et/example.com/webfinger?
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 resource=3Dacct%3Aalice%40example.com =
HTTP/1.1
 
=A0=A0 The client MUST follow the =
redirection, re-issuing the request to the
=A0=A0 URL provided in the Location =
header.

 

 

If the primary method of delegation is redirect, one = expects the client to take the redirect URI and append the appropriate = query parameters to it and reissue the = request.

 

The r=E9ponse  the input query parameters = parameters, indicating the redirect URI is opaque to the client. =  

On the face of it = that would be OK but if a sever can do a dynamic redirect based on query = parameters can probably also run a WF = server.

 

I = thought the redirect was supposed to be to the new base = URL.

 

If the server is repressible for completely formatting = the redirect URI including query parameters that needs to be made = clearer to the server developers.

 

John B.

 

 

------=_NextPart_000_0C9C_01CDD195.4B80B1B0-- From Michael.Jones@microsoft.com Mon Dec 3 17:53:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06DB1F0C4A for ; Mon, 3 Dec 2012 17:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3vdS7vXvXQ8 for ; Mon, 3 Dec 2012 17:53:38 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 954B121F88E8 for ; Mon, 3 Dec 2012 17:53:38 -0800 (PST) Received: from mail20-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Dec 2012 01:53:36 +0000 Received: from mail20-co1 (localhost [127.0.0.1]) by mail20-co1-R.bigfish.com (Postfix) with ESMTP id 78CAAC402B7; Tue, 4 Dec 2012 01:53:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zz9371Ic89bhc85dhzz1de0h1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh18c673hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail20-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail20-co1 (localhost.localdomain [127.0.0.1]) by mail20-co1 (MessageSwitch) id 1354586014677474_22674; Tue, 4 Dec 2012 01:53:34 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.235]) by mail20-co1.bigfish.com (Postfix) with ESMTP id A32F780004C; Tue, 4 Dec 2012 01:53:34 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Dec 2012 01:53:34 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Tue, 4 Dec 2012 01:53:33 +0000 From: Mike Jones To: "Paul E. Jones" , 'John Bradley' , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong Thread-Index: AQHN0aqfb14cLyjaFEu15qxvWcWFq5gH2xCAgAAF3FA= Date: Tue, 4 Dec 2012 01:53:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366917D8C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <19F00756-769E-4774-852B-EE403876610D@ve7jtb.com> <0c9b01cdd1bf$3455f660$9d01e320$@packetizer.com> In-Reply-To: <0c9b01cdd1bf$3455f660$9d01e320$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366917D8CTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 01:53:39 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366917D8CTK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe Paul is correct here From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Paul E. Jones Sent: Monday, December 03, 2012 5:32 PM To: 'John Bradley'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wron= g John, Servers always return URL parameters as a part of the 3xx. Try this: $ curl -v http://www.twitter.com/?test=3D123 It should return a 3xx referring you to twitter.com and it will include the= URI parameter in the Location header. The client would not append yet ano= ther parameter onto it. And we would not want it to. The server might red= irect the client to an entirely different user account or other URI as the = new resource. Paul From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley Sent: Monday, December 03, 2012 6:05 PM To: apps-discuss@ietf.org Discuss Subject: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong I am guessing this is wrong or the text needs to be clarified. HTTP/1.1 307 Temporary Redirect Location: http://wf.example.net/example.com/webfinger? resource=3Dacct%3Aalice%40example.com HTTP/1.1 The client MUST follow the redirection, re-issuing the request to the URL provided in the Location header. If the primary method of delegation is redirect, one expects the client to = take the redirect URI and append the appropriate query parameters to it and= reissue the request. The r=E9ponse the input query parameters parameters, indicating the redire= ct URI is opaque to the client. On the face of it that would be OK but if a sever can do a dynamic redirect= based on query parameters can probably also run a WF server. I thought the redirect was supposed to be to the new base URL. If the server is repressible for completely formatting the redirect URI inc= luding query parameters that needs to be made clearer to the server develop= ers. John B. --_000_4E1F6AAD24975D4BA5B168042967394366917D8CTK5EX14MBXC283r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I believe Paul is correct= here

 <= /p>

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday, December 03, 2012 5:32 PM
To: 'John Bradley'; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Web Finger Draft 07 Sec 8 Example respon= se wrong

 

John,

 <= /p>

Servers always return URL= parameters as a part of the 3xx.  Try this:

$ curl -v http://www.twitter.com/?test= =3D123

 <= /p>

It should return a 3xx re= ferring you to twitter.com and it will include the URI parameter in the Loc= ation header.  The client would not append yet another parameter onto it.  And we would not want it to.  The server might redirec= t the client to an entirely different user account or other URI as the new = resource.

 <= /p>

Paul

 <= /p>

 

I am guessing this is wrong or the text needs to be = clarified.

 

HT=
TP/1.1 307 Temporary Redirect
&n=
bsp;    Location: http://wf.example.net/example.com/webfinger?<=
/span>
&n=
bsp;            =
;          resource=3Dacct%3Aa=
lice%40example.com HTTP/1.1=

 
&n=
bsp;  The client MUST follow the redirection, re-issuing the request t=
o the
&n=
bsp;  URL provided in the Location header.

 

 

If the primary method of delegation is redirect, one= expects the client to take the redirect URI and append the appropriate que= ry parameters to it and reissue the request.

 

The r=E9ponse  the input query parameters param= eters, indicating the redirect URI is opaque to the client.  

On the face of it that would be OK but if a sever ca= n do a dynamic redirect based on query parameters can probably also run a W= F server.

 

I thought the redirect was supposed to be to the new= base URL.

 

If the server is repressible for completely formatti= ng the redirect URI including query parameters that needs to be made cleare= r to the server developers.

 

John B.

 

 

--_000_4E1F6AAD24975D4BA5B168042967394366917D8CTK5EX14MBXC283r_-- From internet-drafts@ietf.org Mon Dec 3 18:01:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103C821F8511; Mon, 3 Dec 2012 18:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqZGGT0+JR-D; Mon, 3 Dec 2012 18:01:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A490721F8521; Mon, 3 Dec 2012 18:01:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121204020126.26355.82813.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 18:01:26 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 02:01:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : The 'acct' URI Scheme Author(s) : Peter Saint-Andre Filename : draft-ietf-appsawg-acct-uri-02.txt Pages : 8 Date : 2012-12-03 Abstract: This document defines the 'acct' URI scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-acct-uri-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ve7jtb@ve7jtb.com Mon Dec 3 18:38:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEBE1F0C59 for ; Mon, 3 Dec 2012 18:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.342 X-Spam-Level: X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymMb1fO3Idc1 for ; Mon, 3 Dec 2012 18:38:11 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE6B11F0C4A for ; Mon, 3 Dec 2012 18:38:11 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so556895ggn.31 for ; Mon, 03 Dec 2012 18:38:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=1kqG1xI30Fx9Ug5JOdnP91Te90yYmF80cpH06fy1PqY=; b=FspDaZphGIfsDtFliZsjZyR9t5axtMt2XAx8lqeNHtmEOIR/RoC3ESx4qaAbDHIj+E SK6DOe0MszViEBJorngHwt08AUbzM/o7NxNZQrGsOKcs4mTvwEONf25mRhGjYrDRSzZW H096u4Q/547ACHgANHQ+41m/sH0m8nMYZFNE3orMMLoDmnqfO0lbivVdhjMtPgeS2crj HBbkncVSyUb2CGpwq/5FETztAOD5Q190ImJ2YRE++H+8seP9REL6+RYiFIwkzzQW2fHu Wa3oT4u+eh2vbgv5sDXCT1b2suV4r/YTKqAOcSaDxsXR1RKOr4Zpn6wgbYtjuMhhCrT/ IWAw== Received: by 10.236.86.73 with SMTP id v49mr13495861yhe.31.1354588690995; Mon, 03 Dec 2012 18:38:10 -0800 (PST) Received: from [192.168.1.211] (190-20-2-238.baf.movistar.cl. [190.20.2.238]) by mx.google.com with ESMTPS id q22sm13436876anh.18.2012.12.03.18.38.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 18:38:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_ECF43D45-77DA-4D2F-B862-AC6AC1AB2155" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <0c9b01cdd1bf$3455f660$9d01e320$@packetizer.com> Date: Mon, 3 Dec 2012 23:38:01 -0300 Message-Id: <5BC32BE0-763C-4B8B-9A4E-1B81B5B55A1F@ve7jtb.com> References: <19F00756-769E-4774-852B-EE403876610D@ve7jtb.com> <0c9b01cdd1bf$3455f660$9d01e320$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmC07dOPgpWKUvCn+37UwohEpZg1Zenbbw3cLTlMPt41E/TLykOpSTV58y+qwbE7dmII4Dx Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 02:38:14 -0000 --Apple-Mail=_ECF43D45-77DA-4D2F-B862-AC6AC1AB2155 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I didn't say the redirect can't contain a query parameter. =20 I was questioning if the server doing the redirect is always expected to = rewrite the parameters in the request URI into the URI in the location = header. If that is the case the spec is not clear on that. The example shows it = but there is no normative text saying the redirect is a fully qualified = URI to the JRD and not to a new WF endpoint. I agree that is probably the correct thing to do as long as people are = clear on what we are asking the server to do and not going to push back = on the complexity to do that sort of redirect. It also seems likely that any server capable of that redirect writing is = probably also capable of being a WF server itself. John B. On 2012-12-03, at 10:32 PM, "Paul E. Jones" = wrote: > John, > =20 > Servers always return URL parameters as a part of the 3xx. Try this: > $ curl -v http://www.twitter.com/?test=3D123 > =20 > It should return a 3xx referring you to twitter.com and it will = include the URI parameter in the Location header. The client would not = append yet another parameter onto it. And we would not want it to. The = server might redirect the client to an entirely different user account = or other URI as the new resource. > =20 > Paul > =20 > From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley > Sent: Monday, December 03, 2012 6:05 PM > To: apps-discuss@ietf.org Discuss > Subject: [apps-discuss] Web Finger Draft 07 Sec 8 Example response = wrong > =20 > I am guessing this is wrong or the text needs to be clarified. > =20 > HTTP/1.1 307 Temporary Redirect > Location: http://wf.example.net/example.com/webfinger? > resource=3Dacct%3Aalice%40example.com HTTP/1.1 > =20 > The client MUST follow the redirection, re-issuing the request to = the > URL provided in the Location header. > =20 > =20 > If the primary method of delegation is redirect, one expects the = client to take the redirect URI and append the appropriate query = parameters to it and reissue the request. > =20 > The r=E9ponse the input query parameters parameters, indicating the = redirect URI is opaque to the client. =20 > On the face of it that would be OK but if a sever can do a dynamic = redirect based on query parameters can probably also run a WF server. > =20 > I thought the redirect was supposed to be to the new base URL. > =20 > If the server is repressible for completely formatting the redirect = URI including query parameters that needs to be made clearer to the = server developers. > =20 > John B. > =20 --Apple-Mail=_ECF43D45-77DA-4D2F-B862-AC6AC1AB2155 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I didn't say the redirect can't = contain a query parameter.   

I was = questioning if the server doing the redirect is always expected to = rewrite the parameters in the request URI into the URI in the location = header.

If that is the case the spec is not = clear on that.  The example shows it but there is no normative text = saying the redirect is a fully qualified URI to the JRD and not to a new = WF endpoint.

I agree that is probably the = correct thing to do as long as people are clear on what we are asking = the server to do and not going to push back on the complexity to do that = sort of redirect.

It also seems likely that any = server capable of that redirect writing is probably also capable of = being a WF server itself.

John = B.

On 2012-12-03, at 10:32 PM, "Paul E. Jones" = <paulej@packetizer.com>= wrote:

 
Servers always return URL parameters as a = part of the 3xx.  Try this:
$ curl -v  
It should return a 3xx = referring you to twitter.com and it will include the URI = parameter in the Location header.  The client would not append yet = another parameter onto it.  And we would not want it to.  The = server might redirect the client to an entirely different user account = or other URI as the new resource.
 
 
 apps-discuss-bounces@ietf.or= g [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Monday, December 03, 2012 = 6:05 PM
To: apps-discuss@ietf.org = Discuss
Subject: [apps-discuss] Web Finger = Draft 07 Sec 8 Example response = wrong
I am guessing = this is wrong or the text needs to be = clarified.
HTTP/1.1 = 307 Temporary Redirect
40example.com =
HTTP/1.1
 
   The client MUST follow the redirection, re-issuing =
the request to the
If =
the primary method of delegation is redirect, one expects the client to =
take the redirect URI and append the appropriate query parameters to it =
and reissue the request.
 
The = r=E9ponse  the input query parameters parameters, indicating the = redirect URI is opaque to the client. =  
On = the face of it that would be OK but if a sever can do a dynamic redirect = based on query parameters can probably also run a WF = server.
I = thought the redirect was supposed to be to the new base = URL.
If = the server is repressible for completely formatting the redirect URI = including query parameters that needs to be made clearer to the server = developers.
John = B.
To: "'John Bradley'" References: <19F00756-769E-4774-852B-EE403876610D@ve7jtb.com> <0c9b01cdd1bf$3455f660$9d01e320$@packetizer.com> <5BC32BE0-763C-4B8B-9A4E-1B81B5B55A1F@ve7jtb.com> In-Reply-To: <5BC32BE0-763C-4B8B-9A4E-1B81B5B55A1F@ve7jtb.com> Date: Mon, 3 Dec 2012 21:47:22 -0500 Message-ID: <0cfb01cdd1c9$af9e9610$0edbc230$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CFC_01CDD19F.C6C9C690" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtewO6JN4h2NwrXNVKSoydbbs6zgHd6b37ASnRkq2XsF8SYA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 02:47:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0CFC_01CDD19F.C6C9C690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, =20 No, they would not be required to do that. For example, if you query = about me, my server might return a 301 pointing to a specific file somewhere = that contains the JRD. The query parameters would not be required. =20 Nothing magical here that needs much explanation, IMO. This is how HTTP redirection works. We=92re adding or removing nothing from it. =20 Paul =20 From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Monday, December 03, 2012 9:38 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft 07 Sec 8 Example response = wrong =20 I didn't say the redirect can't contain a query parameter. =20 =20 I was questioning if the server doing the redirect is always expected to rewrite the parameters in the request URI into the URI in the location header. =20 If that is the case the spec is not clear on that. The example shows it = but there is no normative text saying the redirect is a fully qualified URI = to the JRD and not to a new WF endpoint. =20 I agree that is probably the correct thing to do as long as people are = clear on what we are asking the server to do and not going to push back on the complexity to do that sort of redirect. =20 It also seems likely that any server capable of that redirect writing is probably also capable of being a WF server itself. =20 John B. =20 On 2012-12-03, at 10:32 PM, "Paul E. Jones" = wrote: John, =20 Servers always return URL parameters as a part of the 3xx. Try this: $ curl -v http://www.twitter.com/?test=3D123 =20 It should return a 3xx referring you to = twitter.com and it will include the URI parameter in the Location header. The = client would not append yet another parameter onto it. And we would not want = it to. The server might redirect the client to an entirely different user account or other URI as the new resource. =20 Paul =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley Sent: Monday, December 03, 2012 6:05 PM To: apps-discuss@ietf.org Discuss Subject: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong =20 I am guessing this is wrong or the text needs to be clarified. =20 HTTP/1.1 307 Temporary Redirect Location: http://wf.example.net/example.com/webfinger? resource=3Dacct%3Aalice% 40example.com HTTP/1.1 =20 The client MUST follow the redirection, re-issuing the request to the URL provided in the Location header. =20 =20 If the primary method of delegation is redirect, one expects the client = to take the redirect URI and append the appropriate query parameters to it = and reissue the request. =20 The r=E9ponse the input query parameters parameters, indicating the = redirect URI is opaque to the client. =20 On the face of it that would be OK but if a sever can do a dynamic = redirect based on query parameters can probably also run a WF server. =20 I thought the redirect was supposed to be to the new base URL. =20 If the server is repressible for completely formatting the redirect URI including query parameters that needs to be made clearer to the server developers. =20 John B. =20 =20 ------=_NextPart_000_0CFC_01CDD19F.C6C9C690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

John,

 

No, they would not be required to do that. =A0For example, if you = query about me, my server might return a 301 pointing to a specific file = somewhere that contains the JRD.=A0 The query parameters would not be = required.

 

Nothing magical here that needs much explanation, IMO.=A0 This is how = HTTP redirection works.=A0 We’re adding or removing nothing from = it.

 

Paul

 

From:= = John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Monday, = December 03, 2012 9:38 PM
To: Paul E. Jones
Cc: = apps-discuss@ietf.org
Subject: Re: [apps-discuss] Web Finger = Draft 07 Sec 8 Example response = wrong

 

I didn't say = the redirect can't contain a query parameter. =   

 

I = was questioning if the server doing the redirect is always expected to = rewrite the parameters in the request URI into the URI in the location = header.

 

If that is the case the spec is not clear on that. =  The example shows it but there is no normative text saying the = redirect is a fully qualified URI to the JRD and not to a new WF = endpoint.

 

I = agree that is probably the correct thing to do as long as people are = clear on what we are asking the server to do and not going to push back = on the complexity to do that sort of = redirect.

 

It also seems likely that any server capable of that = redirect writing is probably also capable of being a WF server = itself.

 

John B.

 

On = 2012-12-03, at 10:32 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:



John,

 

Servers always return URL parameters as a part of the 3xx.  Try = this:

 

It should return a 3xx referring you to twitter.com and it will include the URI = parameter in the Location header.  The client would not append yet = another parameter onto it.  And we would not want it to.  The = server might redirect the client to an entirely different user account = or other URI as the new resource.

 

Paul

 

From:=  apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Monday, December 03, 2012 = 6:05 PM
To: apps-discuss@ietf.org = Discuss
Subject: [apps-discuss] Web Finger = Draft 07 Sec 8 Example response = wrong

 

I = am guessing this is wrong or the text needs to be = clarified.

 

HTTP/1.1 307 Temporary =
Redirect
     Location: http://wf.example.net/example.com/webfinger?
       &nbs=
p;            =
;   resource=3Dacct%3Aalice%40example.com =
HTTP/1.1
 
   The client MUST follow the =
redirection, re-issuing the request to the
   URL provided in the Location =
header.

 

 

If the primary method of delegation is redirect, one = expects the client to take the redirect URI and append the appropriate = query parameters to it and reissue the = request.

 

The r=E9ponse  the input query parameters = parameters, indicating the redirect URI is opaque to the client. =  

On the = face of it that would be OK but if a sever can do a dynamic redirect = based on query parameters can probably also run a WF = server.

 

I thought the redirect was supposed to be to the new = base URL.

 

If the server is repressible for completely formatting = the redirect URI including query parameters that needs to be made = clearer to the server developers.

 

John B.

 

 

------=_NextPart_000_0CFC_01CDD19F.C6C9C690-- From evan@status.net Mon Dec 3 18:52:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D5621F88FA for ; Mon, 3 Dec 2012 18:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A43l110OhGsN for ; Mon, 3 Dec 2012 18:52:23 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 395F321F88C8 for ; Mon, 3 Dec 2012 18:52:22 -0800 (PST) Received: from [192.168.0.109] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id C80948D4187; Tue, 4 Dec 2012 03:04:37 +0000 (UTC) Message-ID: <50BD655F.8040901@status.net> Date: Mon, 03 Dec 2012 21:52:15 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> In-Reply-To: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080707000506020603040607" Cc: webfinger@googlegroups.com Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 02:52:25 -0000 This is a cryptographically signed message in MIME format. --------------ms080707000506020603040607 Content-Type: multipart/alternative; boundary="------------090402080803090007040801" This is a multi-part message in MIME format. --------------090402080803090007040801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Paul, I hate to say this, but: removing /all/ reference to RFC 6415 and XRD=20 seems to strip JRD of its context. Especially when we have a long gloss=20 about the finger protocol still, I think some credit is due to the work=20 that went before. Maybe adding quick informative references to the two original documents=20 in 5.2, like: /The JSON Resource Descriptor (JRD), originally introduced in RFC 641= 5 [#] and based on the XRD format [#],//is a JSON object.../ -Evan On 12-12-02 03:21 AM, Paul E. Jones wrote: > > Folks, > > I published another version of the WebFinger spec trying to bring=20 > closure to the two open issues I see (resource representation and=20 > transport). The new version is here: > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 > > With respect to resource representation, I fully described the JSON=20 > Resource Descriptor within the document. There are no external=20 > references to RFC 6415 now, no need to go read the XRD spec, etc.=20 > It's a fairly simple format and I believe this text documents it=20 > sufficiently. Combined with the visual examples, I think this makes it = > pretty clear. Have a look at the JRD documentation in section 5.2 and = > provide your comments. > > With respect to HTTPS, it seems there is strong preference for "HTTPS=20 > only", but some a fair bit of insistence for allowing HTTP. I changed = > the wording in 5.2 to try to capture opinions. Previously, the text=20 > led with a requirement to try HTTPS first. That is still there. I=20 > just added some extra conditions that make it clearer that there are=20 > some instances where a client must not utilize HTTP. This might need=20 > further refinement, but I think there is a balance we can strike here=20 > between the two camps without introducing a lot of complex language. > > I made some editorial changes through the document. > > Comments are welcome, as always. Seems I don't need to say that to=20 > this group, though :-) > > Paul > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------090402080803090007040801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Paul,

I hate to say this, but: removing all reference to RFC 6415 and XRD seems to strip JRD of its context. Especially when we have a long gloss about the finger protocol still, I think some credit is due to the work that went before.

Maybe adding quick informative references to the two original documents in 5.2, like:
The JSON Resource Descriptor (JRD), ori=
ginally introduced in RFC 6415 [#] and based on the XRD format [#], <=
i>is a JSON object...
-Evan

On 12-12-02 03:21 AM, Paul E. Jones wrote:

Folks,

 

I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport).  The new version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

 

With respect to resource representation, I= fully described the JSON Resource Descriptor within the document.  There are no external references to RFC 6415 no= w, no need to go read the XRD spec, etc.  It’s a fairly= simple format and I believe this text documents it sufficiently. = Combined with the visual examples, I think this makes it pretty clear.  Have a look at the JRD documentation in sec= tion 5.2 and provide your comments.

 

With respect to HTTPS, it seems there is strong preference for “HTTPS only”, but some a fair= bit of insistence for allowing HTTP.  I changed the wording in 5.= 2 to try to capture opinions.  Previously, the text led with a requirement to try HTTPS first.  That is still there. = ; I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP.  = This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language.

 

I made some editorial changes through the document.

 

Comments are welcome, as always.  See= ms I don’t need to say that to this group, though :-)

 

Paul

 



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

--------------090402080803090007040801-- --------------ms080707000506020603040607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq 4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU 4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2 QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg /axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM +O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31 3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0 cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8 4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEyMDQw MjUyMTVaMCMGCSqGSIb3DQEJBDEWBBQWncah2pkqsiGcAngqNlAivQ12hzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBAIBF Qizr3pccbnxbPT/ZiomuOukHBTLDZ1TIfMPeBB+O9mx6vUgX2isVTlS0HdwrjSdunu96IGyQ 0jFC2OX2id7UYPB3xhQQpUt9GF9Wbgk4aCaqIsc78WqB7v4saczTRo9Rb8lXsq+bnwq1EAN+ bboAzupN+zra+7zmq/O0ob3/b5CqdgcPhhCfEWbPgDXUVnxU+Z7r+iYYly5ESnra8dfXiAdi /SLdvg7V24Fhg0DQmHrdF27dqoQ8nRkpuxkO8TbLzjRP6irHcYSW5HeqemFGIl45eEkfjPhS 362wuzdyoWousGnZGE7glrDnNDPGrDO1eeV1BhkeEfS9tFa42rsAAAAAAAA= --------------ms080707000506020603040607-- From paulej@packetizer.com Mon Dec 3 19:43:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B4221F8625 for ; Mon, 3 Dec 2012 19:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajZS9XQ852u9 for ; Mon, 3 Dec 2012 19:43:35 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAF321F8616 for ; Mon, 3 Dec 2012 19:43:35 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB43hXqP003203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 22:43:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354592614; bh=/Yv7TUmxkdcpZ7BhNOrPKUp70vOFNkVggVXq5d/tYuc=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=DCBkVpt+LxXEIGuloE/THekciVlNOD3awPF+j8+9SM9YBh7C+2h4sBOiGR+AePW/n lti7y36TYaSygBWEgTlASGYHFzTdhYRaqFNugbnQpNQfY17Ybcqt7p1fSYVDJNP/iL l0cPWlf4h0VZrdzihgqopRJKSxTVNuH07Id0EdlE= From: "Paul E. Jones" To: , References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> <50BD655F.8040901@status.net> In-Reply-To: <50BD655F.8040901@status.net> Date: Mon, 3 Dec 2012 22:43:35 -0500 Message-ID: <0d4701cdd1d1$89efb310$9dcf1930$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D48_01CDD1A7.A11A6E60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEKh79DPBqdV8xMCCarbG6K9ejXOwKrAdp8mXk3ZSA= Content-Language: en-us Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 03:43:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0D48_01CDD1A7.A11A6E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yeah, it has been suggested by a couple of people to at least have an informative reference to RFC 6415. Your suggestion is reasonable, I think. I'll insert them only as informative references since all normative material in within the WF spec itself. Paul From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Evan Prodromou Sent: Monday, December 03, 2012 9:52 PM To: apps-discuss@ietf.org Cc: webfinger@googlegroups.com Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 Paul, I hate to say this, but: removing all reference to RFC 6415 and XRD seems to strip JRD of its context. Especially when we have a long gloss about the finger protocol still, I think some credit is due to the work that went before. Maybe adding quick informative references to the two original documents in 5.2, like: The JSON Resource Descriptor (JRD), originally introduced in RFC 6415 [#] and based on the XRD format [#], is a JSON object... -Evan On 12-12-02 03:21 AM, Paul E. Jones wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0D48_01CDD1A7.A11A6E60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yeah, it has been = suggested by a couple of people to at least have an informative = reference to RFC 6415.  Your suggestion is reasonable, I = think.  I’ll insert them only as informative references since = all normative material in within the WF spec = itself.

 

Paul

 

From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] = On Behalf Of Evan Prodromou
Sent: Monday, December 03, = 2012 9:52 PM
To: apps-discuss@ietf.org
Cc: = webfinger@googlegroups.com
Subject: Re: [apps-discuss] = draft-ietf-appsawg-webfinger-07

 

Paul,

I hate to say this, but: removing = all reference to RFC 6415 and XRD seems to strip JRD of its = context. Especially when we have a long gloss about the finger protocol = still, I think some credit is due to the work that went = before.

Maybe adding quick informative references to the two = original documents in 5.2, like:

The JSON Resource =
Descriptor (JRD), originally introduced in RFC 6415 [#] and based on the =
XRD format [#], is a JSON object...

-Evan

On 12-12-02 03:21 AM, Paul E. Jones = wrote:

Folks,

 

I published = another version of the WebFinger spec trying to bring closure to the two = open issues I see (resource representation and transport).  The new = version is here:

http:= //tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

<= p class=3DMsoNormal> 

With = respect to resource representation, I fully described the JSON Resource = Descriptor within the document.  There are no external references = to RFC 6415 now, no need to go read the XRD spec, etc.  It’s = a fairly simple format and I believe this text documents it = sufficiently.  Combined with the visual examples, I think this = makes it pretty clear.  Have a look at the JRD documentation in = section 5.2 and provide your comments.

 

With respect = to HTTPS, it seems there is strong preference for “HTTPS = only”, but some a fair bit of insistence for allowing HTTP.  = I changed the wording in 5.2 to try to capture opinions.  = Previously, the text led with a requirement to try HTTPS first.  = That is still there.  I just added some extra conditions that make = it clearer that there are some instances where a client must not utilize = HTTP.  This might need further refinement, but I think there is a = balance we can strike here between the two camps without introducing a = lot of complex language.

 

I made some = editorial changes through the document.

 

Comments are = welcome, as always.  Seems I don’t need to say that to this = group, though :-)

 

Paul

 




__________________=
_____________________________
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.i=
etf.org/mailman/listinfo/apps-discuss
 

------=_NextPart_000_0D48_01CDD1A7.A11A6E60-- From duerst@it.aoyama.ac.jp Mon Dec 3 20:40:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84D21E803D for ; Mon, 3 Dec 2012 20:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDhj1mhS31sA for ; Mon, 3 Dec 2012 20:40:08 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 34C9A21E8039 for ; Mon, 3 Dec 2012 20:40:08 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id qB44e0hB015728 for ; Tue, 4 Dec 2012 13:40:00 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 1eee_5b31_a9766dac_3dcc_11e2_86ca_001d096c566a; Tue, 04 Dec 2012 13:39:59 +0900 Received: from [IPv6:::1] ([133.2.210.1]:56941) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 4 Dec 2012 13:40:00 +0900 Message-ID: <50BD7E9C.6060202@it.aoyama.ac.jp> Date: Tue, 04 Dec 2012 13:39:56 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Jan Algermissen References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Link relation type for home documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 04:40:09 -0000 What about 'service-home'? To me, both 'service' and 'home' look way too generic. Regards, Martin. On 2012/12/03 20:49, Jan Algermissen wrote: > Hi Mark, > > I maybe have a use case where a client would need to be informed at runtime where a service's/server's home document is. > > Do you have a link rel on your mind for that purpose? What about re-using 'service'? > > Or maybe define a new one: 'home'? > > Jan > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From duerst@it.aoyama.ac.jp Mon Dec 3 21:07:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D28121E8042 for ; Mon, 3 Dec 2012 21:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.152 X-Spam-Level: X-Spam-Status: No, score=-102.152 tagged_above=-999 required=5 tests=[AWL=1.638, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20HfzArSOpPW for ; Mon, 3 Dec 2012 21:07:06 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9A05821E803A for ; Mon, 3 Dec 2012 21:07:05 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id qB456vZ1028798 for ; Tue, 4 Dec 2012 14:07:00 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7864_b371_6d928d80_3dd0_11e2_9799_001d096c5782; Tue, 04 Dec 2012 14:06:57 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41826) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 4 Dec 2012 14:06:57 +0900 Message-ID: <50BD84EE.7080207@it.aoyama.ac.jp> Date: Tue, 04 Dec 2012 14:06:54 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <50BCE2CE.6000202@stpeter.im> In-Reply-To: <50BCE2CE.6000202@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: webfinger@googlegroups.com, IETF Apps Discuss Subject: [apps-discuss] Definition of acct: (was: Re: Draft -07 proposal: Remove dependency on "acct:" scheme) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 05:07:07 -0000 Hello Peter, On 2012/12/04 2:35, Peter Saint-Andre wrote: > I agree there's no need to wait on the 'acct' scheme -- in fact it might > be done before the WebFinger draft. There was some contention about > whether 'acct' is tied to WebFinger. My sense is still that 'acct' is an > independent thing, used by WebFinger but usable by other technologies. > Feedback on that issue is still welcome. I agree that we should define 'acct:' this way. However, I have previously said so, but maybe it helps to repeat it here: There is no need to strictly distinguish between protocol-tied URI schemes and protocol-independent URIs. So while in general, 'acct:' is not only for WebFinger, it may well happen that sooner or later, browsers implement dereferencing of 'acct:', e.g. in an a@href, using WebFinger. Thus I think section 3 of your document could benefit from some tweaking. Here are some proposals: 3. Definition The syntax of the 'acct' URI scheme is defined under Section 4 of this document. Aside/editorial: Starting a section entitled 'definition' with a sentence saying that the definition is in a different section is confusing. Proposal: Change section title to "Semantics" (or at least to something like "Definition of Semantics". Although 'acct' URIs take the form "user@host", the "user@host" -> "acct:user@host" scheme is designed for the purpose of identification instead of interaction (regarding this distinction, see Section 1.2.2 of [RFC3986]). Please change any text that says "for the purpose of identification instead of interaction" to something like "mainly for the purpose of identification". Then add some text along the lines of "Resolving an 'acct' URI scheme may result in some information related to or about the account. At the time of publication of this specification, no preferred or dedicated resolution protocol exists." (an informative reference to WebFinger and Simple Web Discovery may also be a good idea) While we are at it, please remove the subsections in Section 4. I think they only will create work for IANA. In Section 4.4, please remove "There is no media type associated with the 'acct' URI scheme." Media Types and URI schemes are orthogonal concepts, and thus such a sentence is unnecessary (and potentially confusing). Also, in what is currently Section 4.6, please change "Note that domain labels need to be encoded as A-labels (see [RFC5890]) in order to support internationalized domain names (IDNs)." to something like "This also applies to domain labels. Alternatively, domain labels MAY be encoded as A-labels (see [RFC5890])." Using %-encoding for domain name parts is part of [RFC3986] (see the last two paragraphs of http://tools.ietf.org/html/rfc3986#section-3.2.2). Regards, Martin. > In any case I'll review the 'acct' spec again in the next few days and > request further input on the uri-review list ASAP, in accordance with > RFC 4395. > > Peter > > On 12/2/12 9:51 PM, James M Snell wrote: >> -1 ... I believe the utility of the acct scheme when used with WF is >> readily apparent, and honestly there's no reason to "wait" for acct to >> be finished. If we complete work on WF before acct is done, the only >> real impact is that we wait a bit longer for WF to get an RFC#. >> Implementors can still get started doing their thing. >> >> (I do agree that WF is useful with non acct uri's too tho) >> >> - James >> >> >> On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray> > wrote: >> >> I don’t want to wait for work on this to be completed, and I don’t >> think that its presence is necessary for WebFinger to be useful. So >> let's take it out. >> >> Proposal: >> Section 4.1: Change the URI in the example from acct: to mailto: >> Section 4.2: Same >> Section 5.3: Same >> Section 5.4: s/it could be an "acct" URI [7], // >> Section 5.4: Remove 2nd para, beginning "For resources associated >> with a user account at a host...“ >> Section 5.4: s/both an "acct" URI and any alias/any alias/ >> Section 8: Change the URI in the example from acct: to mailto: >> >> >> On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray> > wrote: >> >> No, we’re on the same side here. I’m suggesting taking >> webfinger-07 as a baseline, and all *future* changes need to be >> proposed as a concrete delta against it. -T >> >> >> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones >> > wrote: >> >> Tim,____ >> >> __ __ >> >> I didn’t mean to be rude by introducing these changes, just >> trying to move things along. Most changes were fairly >> trivial, not worth mentioning, and can be seen here:____ >> >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-appsawg-webfinger-07.txt____ >> >> __ __ >> >> The most significant changes were the re-write of section >> 5.2 and modification to the language related to HTTPS in >> 5.1. I suspect that is the text to which you refer as >> preferring it to be “camera-readyâ€. (I would assume the >> balance of the changes would not need to be presented as >> “camera-readyâ€, since they’re minor editorial things.)____ >> >> __ __ >> >> In any case, the most important text changes I would like >> folks to consider is section 5.2 (which aims to fully >> document the JSON Resource Descriptor object) and paragraphs >> 2 and 3 in section 5.1.____ >> >> __ __ >> >> Paul____ >> >> __ __ >> >> *From:*Tim Bray [mailto:tbray@textuality.com >> ] >> *Sent:* Sunday, December 02, 2012 2:54 PM >> *To:* Paul E. Jones >> *Cc:* apps-discuss@ietf.org; >> webfinger@googlegroups.com >> *Subject:* Re: [apps-discuss] >> draft-ietf-appsawg-webfinger-07____ >> >> __ __ >> >> Thanks to Paul for the extra effort. I’d like to suggest, >> in the interests of courtesy and efficiency, that from here >> on on, contributions to this discussion be “camera-readyâ€, >> that is to say, specific suggestions in the style of a diff, >> including fully-written-out replacements language. >> >> -Tim____ >> >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones >> > >> wrote:____ >> >> Folks,____ >> >> ____ >> >> I published another version of the WebFinger spec trying to >> bring closure to the two open issues I see (resource >> representation and transport). The new version is here:____ >> >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07____ >> >> ____ >> >> With respect to resource representation, I fully described >> the JSON Resource Descriptor within the document. There are >> no external references to RFC 6415 now, no need to go read >> the XRD spec, etc. It’s a fairly simple format and I >> believe this text documents it sufficiently. Combined with >> the visual examples, I think this makes it pretty clear. >> Have a look at the JRD documentation in section 5.2 and >> provide your comments. ____ >> >> ____ >> >> With respect to HTTPS, it seems there is strong preference >> for “HTTPS onlyâ€, but some a fair bit of insistence for >> allowing HTTP. I changed the wording in 5.2 to try to >> capture opinions. Previously, the text led with a >> requirement to try HTTPS first. That is still there. I >> just added some extra conditions that make it clearer that >> there are some instances where a client must not utilize >> HTTP. This might need further refinement, but I think there >> is a balance we can strike here between the two camps >> without introducing a lot of complex language.____ >> >> ____ >> >> I made some editorial changes through the document.____ >> >> ____ >> >> Comments are welcome, as always. Seems I don’t need to say >> that to this group, though :-)____ >> >> ____ >> >> Paul____ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From bradfitz@google.com Mon Dec 3 10:00:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E8C21F8934 for ; Mon, 3 Dec 2012 10:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSs9An+rCOy2 for ; Mon, 3 Dec 2012 10:00:26 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 73DEC21F891F for ; Mon, 3 Dec 2012 10:00:25 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so1475279wib.13 for ; Mon, 03 Dec 2012 10:00:24 -0800 (PST) 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=3SZSd1qsiDnp63isCpmCLpb//Y4Jw2VrTakSQNuy7UQ=; b=IojJabzWOZpsDyP2SPr6rbe12OA5v8h+jJUvKTPBk54npQ1/9LfY9iG1JCwQGLZ6x7 iCqft5vIZzdbOzhwM/M/6h0R7AjPbHbAFwS4IGHUjg2dpxD9Ib87atGMO31jUUYmWgdC y5ZQ8bww6RcRB9cPRU5gh5PW6Sx5JdOBzkoSfViUxfEbBx/lUyYFBFjWVV5B0E9dxLA2 cGbAMRa+p4KzqsKi3mKMS7mZrEX/POdD3OU2DEtVfHTMVg3iiioKDzWwZBR6Q0hslH3O tFuNK6kfX2zSRPoJ4Is5HSvDujuXKxVE+T8HnLgVCeLNbl1kz0SLf5F/a9WY8RDVRieX iBlw== X-Google-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:x-gm-message-state; bh=3SZSd1qsiDnp63isCpmCLpb//Y4Jw2VrTakSQNuy7UQ=; b=OVqj6sea3IptF/UI8xio1QSDBrGpG8opvxnVV3gDfInCi0SZzbY/Cz7cZN+gqxYFRz N9zHIAhVZTuGM0BKpi8TqG+n2FuFwL6xoNLhrrKsKPJnx3whXk3SCDEOog5HGiO6dh3N ikYmJ2DUIdJfJ56EPe4sQQgVzSiA3hGl7eJVFCN/Bc1piRuca0Eyf82DYuaFfiJWw22o W4Inojy8moY9csaVqKVsXKUsH6/NUyZglQDqCO9S/upqYfauQLL5WpFxml9c4kvIgVmx I/RqH5uUIGYzxNfbmcAg4hYOTzX0F3W2MnV+JiLLgl0pFKhtJXLA50K4BOXvfVa7/YTd G1zA== MIME-Version: 1.0 Received: by 10.216.140.19 with SMTP id d19mr4059099wej.34.1354557624533; Mon, 03 Dec 2012 10:00:24 -0800 (PST) Received: by 10.194.166.100 with HTTP; Mon, 3 Dec 2012 10:00:24 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 10:00:24 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=0016e6dee6e809c2ed04cff68695 X-Gm-Message-State: ALoCoQne5adc3pUvWtdggI7N10SCmTDP7x97Mv5HO72QduLfNerezk2TX02tLiAuBvZPhOb7+PpV20mcte0c0G8/lwBwqXjepE8HrYj0gPL+bdiF28DjJrjeX4XpiN+ZzLncPVsywEr53sNc1mhWPywDBZahpnqE+4ACS75/pvRvt0B+MjAkh51x7eUWLNgTRxh6IGQ11Sy1 X-Mailman-Approved-At: Tue, 04 Dec 2012 08:04:08 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:00:27 -0000 --0016e6dee6e809c2ed04cff68695 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho wrote: > > > On 3 December 2012 02:35, Brad Fitzpatrick wrote: > >> -1. I feel strongly for keeping the acct: scheme. WebFinger isn't just >> about email. >> > > If Webfinger isnt just about email. What else is it about? > Accounts on services. --0016e6dee6e809c2ed04cff68695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho <melvincarvalho@gmai= l.com> wrote:


On 3 December 2012 02:35, Brad Fitzpatr= ick <bradfitz@google.com> wrote:
-1. = =C2=A0I feel strongly for keeping the acct: scheme. =C2=A0WebFinger isn'= ;t just about email.

If Webfinger isnt jus= t about email.=C2=A0 What else is it about?

Accounts on services.

--0016e6dee6e809c2ed04cff68695-- From bradfitz@google.com Mon Dec 3 11:32:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9C721F884A for ; Mon, 3 Dec 2012 11:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id queR31KeimUz for ; Mon, 3 Dec 2012 11:32:19 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F41CA21F884B for ; Mon, 3 Dec 2012 11:32:18 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1371907wey.31 for ; Mon, 03 Dec 2012 11:32:18 -0800 (PST) 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=+zDFeb1czXsR/DSYWZMa/E01XvGzrWJJQ8ILUegkWmw=; b=FE1Vx1w40uZ/R/OmCc1yvWphsnQX+nBaQlIXIMOimGkQ+Pp2IDfvCEQe0Jm9VcFml7 70aHmtT5xgcBtrlDwoftdLgMV53tWJN+BncDR2yB4+XREva3WMnZc//+zboSehRyABie plbqa1bvHs1IZx2WmYeuk2k0lC+B5Eq385cxgtnsy3ivjxMJi9/gyjggR50uoiBMDFlT 6iElQ2467jaGNSI8YHdIUSnZsLtPWSmb88e5oJ2pyQTf7AOM5fCLdILharqltDZBlTff UQwZ6bdYIK+JpX6bru02NQyMoUfQ2/yv8Rm2oxSGPFxdQKv5Wvrie7zG6ttks7MZqLtz 8IuQ== X-Google-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:x-gm-message-state; bh=+zDFeb1czXsR/DSYWZMa/E01XvGzrWJJQ8ILUegkWmw=; b=DZ5cYjuTu2YdZRGRPHCwmk9NvAOi4olMS/nN8KM77/M2if4CMg0wKJXzgPsgLZQO7x J1iQlC/z77pCYLUKgjRRPx/KBvs4hgYb5gW1ahQtYgElctoHSuS0Jgm6zpw/zXIgfCyZ NvYrJtD9uPw+yLzP/qjLA7emzk5dcHYIkiOcdTazsYFFaGq/Z+3aHppBlsr+C4OjvsjZ 5Z9IJWARwnhgROTvhyx5MIXIMLSq0kGF7j/DfvG+WnHZVAFW16IVs8l78lhQX9J6YS+U CSN2Gepp40YtdXVskWgp5wpURpnFXGd61Ael2Qj1i8s14WM8Pf8iUoUCcapVPPnNF3n+ Lpyg== MIME-Version: 1.0 Received: by 10.180.107.197 with SMTP id he5mr343335wib.1.1354563137926; Mon, 03 Dec 2012 11:32:17 -0800 (PST) Received: by 10.194.166.100 with HTTP; Mon, 3 Dec 2012 11:32:17 -0800 (PST) In-Reply-To: <50BCF429.4020001@status.net> References: <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com> <016f01cdce6e$8a168af0$9e43a0d0$@packetizer.com> <025701cdce84$a8a1bfb0$f9e53f10$@packetizer.com> <036301cdceb1$3ae93e30$b0bbba90$@packetizer.com> <039001cdceb4$b65c7480$23155d80$@packetizer.com> <9AE8993E-92CB-499B-AC47-C7477FF765CC@gmail.com> <50BA1756.70808@status.net> <50BCF429.4020001@status.net> Date: Mon, 3 Dec 2012 11:32:17 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8f13eaf8a974ee04cff7ce04 X-Gm-Message-State: ALoCoQl6iA6IFFz8dZ5RiVhNlL2+uoJ5hDguyTrMTd2azrjgknRGAZW+dn1bU5C+4bsiaI4lGkL8Ptfm8xRHrgcs/+4u8e00StHC/p4kCp65IMJlg9pAEa3XzGYs7xq4c3aLJ7z1DuaLDtqIdv9QnPbUk8f8PqF6qBhMu/0FDfVFp9zoI64sOLq6CtMRjlsa3jv+LxiaB6E2 X-Mailman-Approved-At: Tue, 04 Dec 2012 08:04:19 -0800 Cc: Apps Discuss Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:32:19 -0000 --e89a8f13eaf8a974ee04cff7ce04 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 3, 2012 at 10:49 AM, Evan Prodromou wrote: > I think the problem with modeling interactions around libraries, > function calls, and parameters is that it's presupposing a particular kind > of operating environment. > > Webfinger as defined is simple enough that you can use HTTP libraries > directly without an intermediate chunk of software. I think those > implementations should still be compliant, even though they don't implement > a boolean parameter to anything. > No existing HTTP library does fallback from HTTPS to HTTP, though, so there's still a bit of intermediate software required if we allow HTTP. If we say HTTPS-only, though, then every HTTP library is a WebFinger library. --e89a8f13eaf8a974ee04cff7ce04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Mon, Dec 3, 2012 at 10:49 AM, Evan Pro= dromou <evan@status.net> wrote:
=20 =20 =20
I think the problem with modeling interactions around libraries, function calls, and parameters is that it's presupposing a particular kind of operating environment= .

Webfinger as defined is simple enough that you can use HTTP libraries directly without an intermediate chunk of software. I think those implementations should still be compliant, even though they don't implement a boolean parameter to anything.

No existing HTTP library does fallback= from HTTPS to HTTP, though, so there's still a bit of intermediate sof= tware required if we allow HTTP. =C2=A0If we say HTTPS-only, though, then e= very HTTP library is a WebFinger library.

--e89a8f13eaf8a974ee04cff7ce04-- From bradfitz@google.com Mon Dec 3 13:08:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034DD21F8929 for ; Mon, 3 Dec 2012 13:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GykYkRIZvGGM for ; Mon, 3 Dec 2012 13:08:33 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4D05C21F891F for ; Mon, 3 Dec 2012 13:08:33 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id dr1so74182wgb.1 for ; Mon, 03 Dec 2012 13:08:32 -0800 (PST) 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=vyDawSJLcyxzELOMCiiU3wdks41V+mgwwXzdRa3chK8=; b=MFpfC5YuvoYjtDkVvaLWutytLzv+IjrdWlnYT7fEdUmgIe4p29GSTD4yfGZxqZLxPp mG36vaAwNCniSZf94fAvkZyBjWnPqhix2wC2Q4kFBWubOBTZvfMplUN0aUWfxj9jYpP6 mb+JD8fO2dfZd4hscoQWMwsfSGFN0+sgL/bZFmmOsRXBp9qrPIpPPPpTJAxNT78vZwr4 +ZoLTvFsYH8v512kDcgUjfEkZ4iBsLpMof8KuOX+u4swv0d4HRkoio2wBNzZv46AcFTC P9VYBhNS57WU/R9o9ktZqYVM+jEDRvWuZzoayBb6hfEUdEkgnzuFFQMNqHbum7JdHhrS QxSg== X-Google-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:x-gm-message-state; bh=vyDawSJLcyxzELOMCiiU3wdks41V+mgwwXzdRa3chK8=; b=Wu0GrgSiwuBPj97WwVRtpGtArI6r9M4g9RZNnJHZBGorp4tXlJ4D78TrhbB8LoU2i5 D7jHIqAhFCVyUQahZygpEmptv0aBQ5/ZKtHlEoXwTv9SilALz7fC6Qn7fpbVLVlqEPRe 7FbX9amlPTfkOcMhVwOcmot/Z35jm2slbQn7rMCLQkSVJWyMDDfhLBP70vqEZmu8/WDi /ewcyyOlixB0ymPvExsNHrTTEN9AYWlnpVeaIju/pzhAphkBU8rywjzDCQ89/ELdYvuJ ZxB9J0KLLHGcUU9Js8p5gQW4X/cryEHMWNDhJHDfzbUwZwPT4mz/Jlc1IDNRlRrLRlfh H3Qw== MIME-Version: 1.0 Received: by 10.180.76.203 with SMTP id m11mr685290wiw.6.1354568912253; Mon, 03 Dec 2012 13:08:32 -0800 (PST) Received: by 10.194.166.100 with HTTP; Mon, 3 Dec 2012 13:08:32 -0800 (PST) In-Reply-To: <0bbe01cdd199$967a6ea0$c36f4be0$@packetizer.com> References: <076601cdd066$01a53be0$04efb3a0$@packetizer.com> <0bbe01cdd199$967a6ea0$c36f4be0$@packetizer.com> Date: Mon, 3 Dec 2012 13:08:32 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d043c7b14d6b4c804cff9268f X-Gm-Message-State: ALoCoQkuWvSp+fhCsErJLEVrtkYVKypi1/vh6QwmbuFjCtuf8wCdlgitKrLqx6Jc3WO7MojpcvwFagC+jEElpMEtCQPRLngeg0rkSJZfIYhVH25E1u0EckAxiFSmYW1Hw9ecm3sARFOa3Pkv5OOCoFB6uPEog27kVpU0cwxUdJiupoTgv8xuYi47Mmug5T0tQPmXWZteqQfp X-Mailman-Approved-At: Tue, 04 Dec 2012 08:04:19 -0800 Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 21:08:35 -0000 --f46d043c7b14d6b4c804cff9268f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You want to make it easier for humans, but it will make it harder for humans. Humans will waste time being distracted by that, trying to fight their JSON encoder to get the "recommended" ordering. It also brings up confusion: "how can an unordered thing be ordered? Why did they write that? Surely they must mean something else and I'm just not getting it." Most people will write their JSON with a library anyway, so almost nobody will implement that part. It's a pointless burden IMO. On Mon, Dec 3, 2012 at 1:03 PM, Paul E. Jones wrote= : > Brad,**** > > ** ** > > Things can be ordered in any way one wants since it=E2=80=99s a JSON obje= ct. That > said, placing things in a given order makes it easier for a human who mig= ht > manually inspect the document. I put that word in just to encourage a > consistent format.**** > > ** ** > > Paul**** > > ** ** > > *From:* apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] *On Behalf Of *Brad Fitzpatrick > *Sent:* Sunday, December 02, 2012 6:48 PM > *To:* webfinger@googlegroups.com > *Cc:* apps-discuss@ietf.org > *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-07**** > > ** ** > > Why does the JRD have a recommended key/value order?**** > > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones > wrote:**** > > Folks,**** > > **** > > I published another version of the WebFinger spec trying to bring closure > to the two open issues I see (resource representation and transport). Th= e > new version is here:**** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** > > **** > > With respect to resource representation, I fully described the JSON > Resource Descriptor within the document. There are no external reference= s > to RFC 6415 now, no need to go read the XRD spec, etc. It=E2=80=99s a fa= irly > simple format and I believe this text documents it sufficiently. Combine= d > with the visual examples, I think this makes it pretty clear. Have a loo= k > at the JRD documentation in section 5.2 and provide your comments. **** > > **** > > With respect to HTTPS, it seems there is strong preference for =E2=80=9CH= TTPS > only=E2=80=9D, but some a fair bit of insistence for allowing HTTP. I ch= anged the > wording in 5.2 to try to capture opinions. Previously, the text led with= a > requirement to try HTTPS first. That is still there. I just added some > extra conditions that make it clearer that there are some instances where= a > client must not utilize HTTP. This might need further refinement, but I > think there is a balance we can strike here between the two camps without > introducing a lot of complex language.**** > > **** > > I made some editorial changes through the document.**** > > **** > > Comments are welcome, as always. Seems I don=E2=80=99t need to say that = to this > group, though :-)**** > > **** > > Paul**** > > **** > > ** ** > --f46d043c7b14d6b4c804cff9268f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Y= ou want to make it easier for humans, but it will make it harder for humans= .

Humans will waste time being distracted by that, tryin= g to fight their JSON encoder to get the "recommended" ordering. = =C2=A0It also brings up confusion: "how can an unordered thing be orde= red? Why did they write that? Surely they must mean something else and I= 9;m just not getting it."

Most people will write their JSON with a library a= nyway, so almost nobody will implement that part.

It's a pointless burden IMO.


On Mon, Dec 3, 2012 at 1:03 PM, Paul E. Jon= es <paulej@packetizer.com> wrote:

Brad,

=C2=A0

Things can be ordered in any way one wants= since it=E2=80=99s a JSON object.=C2=A0 That said, placing things in a giv= en order makes it easier for a human who might manually inspect the documen= t.=C2=A0 I put that word in just to encourage a consistent format.

=C2=A0

Paul<= /span>

=C2=A0

From: ap= ps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Be= half Of Brad Fitzpatrick
Sent: Sunday, December 02, 2012 6:48 PM
To: webfinger@googlegroups.co= m
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07

<= u>=C2=A0

Why does the JRD have a recommended key/value order?

On Sun, Dec 2, 2012 at 12:21 AM, Pau= l E. Jones <p= aulej@packetizer.com> wrote:

Folks,

=C2=A0

I published another ver= sion of the WebFinger spec trying to bring closure to the two open issues I= see (resource representation and transport).=C2=A0 The new version is here= :

http://tools.ietf.org/html/draft-ietf-= appsawg-webfinger-07

=C2=A0<= /u>

With respect to resource representation, I fully des= cribed the JSON Resource Descriptor within the document.=C2=A0 There are no= external references to RFC 6415 now, no need to go read the XRD spec, etc.= =C2=A0It=E2=80=99s a fairly simple format and I believe this text document= s it sufficiently.=C2=A0 Combined with the visual examples, I think this ma= kes it pretty clear.=C2=A0 Have a look at the JRD documentation in section = 5.2 and provide your comments.

=C2=A0

With = respect to HTTPS, it seems there is strong preference for =E2=80=9CHTTPS on= ly=E2=80=9D, but some a fair bit of insistence for allowing HTTP.=C2=A0 I c= hanged the wording in 5.2 to try to capture opinions.=C2=A0 Previously, the= text led with a requirement to try HTTPS first.=C2=A0 That is still there.= =C2=A0 I just added some extra conditions that make it clearer that there a= re some instances where a client must not utilize HTTP.=C2=A0 This might ne= ed further refinement, but I think there is a balance we can strike here be= tween the two camps without introducing a lot of complex language.

=C2=A0

I mad= e some editorial changes through the document.

=C2=A0

Comments are wel= come, as always.=C2=A0 Seems I don=E2=80=99t need to say that to this group= , though :-)

=C2=A0

Paul

=C2=A0=

=C2=A0


--f46d043c7b14d6b4c804cff9268f-- From bradfitz@google.com Mon Dec 3 14:02:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7EF21F8891 for ; Mon, 3 Dec 2012 14:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJqJjw98eXC8 for ; Mon, 3 Dec 2012 14:02:53 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 3313621F88DE for ; Mon, 3 Dec 2012 14:02:53 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1423693wgb.13 for ; Mon, 03 Dec 2012 14:02:52 -0800 (PST) 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=aZp7NhFskXbvC/7NpaAZvUuQ4WNxImNR6R62OBKUn8E=; b=nsyLJwlbcDIj+lS6HVPel9h0SB37ciGOCQg2z1YgljrIVIoNgSRaSogHkU+0CSpO30 vXkk1IqYeqE/iL1kwau1Yg0BnQrOMJE4XhJzhURJzNMOyFcNxFm3ccHd/oL6vY4+/Kac YECaT/o47LB8s6wcuc2JvVxnsRQbS4CbAgrDDI3Dt5Ccesx+xWVhbXEKBsYqrNWO8A2n pgYtEe4JOTr9+oh8ubeRCFmh4vnJVz+q0+u/DtRK9Gvwi/D0Zb7vxIOuFzFrxvMqPgJN MVk74mTo15ydhJGcdERAL3hcLAPx/1mceHnPb04hje+pTImVuxcpHrwCpuXG9X3OVd7v NwiQ== X-Google-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:x-gm-message-state; bh=aZp7NhFskXbvC/7NpaAZvUuQ4WNxImNR6R62OBKUn8E=; b=WIyeIajQmxHGUrZYkhyBi4u+ptZ12CSUsl3kb6mTpTk7Z2lphI/mrkRCy7z741c/4B nAQ02r+Kof9KfW98Wr5BBfIOsS8y/fKv3Fty2zdq272zuT1fmgmtgwMLbitlzROteLJk VbW6hEYGYGm9SCnXaQJMqdCgn4QAcwgb3Y/5RQ8JNKVhEND0KJHGQF9/Kj2qEMRGpvgo 9fMgC45LGSDJoNrgcNR6e0HhvXBiwvelWLKaG6HxlTZ93ULLSV/nSDxp6p+hOMG9+MqQ J4C9iqRY9iHUJiPDg6alVCuS8G1X5ETr3tVcZSeRI+zqNsgazAymiBr0jHyGJApV37N6 SqRQ== MIME-Version: 1.0 Received: by 10.180.85.194 with SMTP id j2mr866955wiz.12.1354572172346; Mon, 03 Dec 2012 14:02:52 -0800 (PST) Received: by 10.194.166.100 with HTTP; Mon, 3 Dec 2012 14:02:52 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 14:02:52 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d0444ef3127c3f104cff9e971 X-Gm-Message-State: ALoCoQnW7Ik5VVQu/61t3kmFhbNnGhDGlsXRBnnWqnVwUgNSqtkBqTeCm/tpnx72jCb7z+FA0QZg+9coH9mz3QRp6V32dnvbVxxAwr2KsEviw1INXDmRTTntbcwdLxvdBGnZmeS9KBF9NZ6QPp65xgD7LLBW+tYJaeGwA12c/a3pKewNFcvFzeaXTJvHKyTdp5Kf0z2EX7ow X-Mailman-Approved-At: Tue, 04 Dec 2012 08:04:19 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:02:54 -0000 --f46d0444ef3127c3f104cff9e971 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 3, 2012 at 2:02 PM, Melvin Carvalho wrote: > > > On 3 December 2012 19:00, Brad Fitzpatrick wrote: > >> On Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho > > wrote: >> >>> >>> >>> On 3 December 2012 02:35, Brad Fitzpatrick wrote: >>> >>>> -1. I feel strongly for keeping the acct: scheme. WebFinger isn't >>>> just about email. >>>> >>> >>> If Webfinger isnt just about email. What else is it about? >>> >> >> Accounts on services. >> >> > Limited to social services, or including, say, bank accounts? > Why would we limit it to social services? --f46d0444ef3127c3f104cff9e971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Mon, Dec 3, 2012 at 2:02 PM, Melvin Ca= rvalho <melvincarvalho@gmail.com> wrote:

=
On 3 December 2012 19:00, Brad Fitzpatrick <= span dir=3D"ltr"><bradfitz@google.com> wrote:
O= n Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho <melvincarvalho@gmai= l.com> wrote:

On 3 December 2012 02:35, Brad Fitzpatric= k <bradfitz@google.com> wrote:
-1. = =C2=A0I feel strongly for keeping the acct: scheme. =C2=A0WebFinger isn'= ;t just about email.

If Webfinger isnt jus= t about email.=C2=A0 What else is it about?

Accounts on services.


Limited to social services, or including= , say, bank accounts?

=C2=A0Why would w= e limit it to social services?
--f46d0444ef3127c3f104cff9e971-- From bradfitz@google.com Mon Dec 3 14:09:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3140121F88C8 for ; Mon, 3 Dec 2012 14:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y43lInkOzcxM for ; Mon, 3 Dec 2012 14:09:35 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4605921F8862 for ; Mon, 3 Dec 2012 14:09:35 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1426400wgb.13 for ; Mon, 03 Dec 2012 14:09:34 -0800 (PST) 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=MsDvInpCq8kT2fycXurq14aa4iSj0sRdK6TC0UTYEGc=; b=ZsNqW5fCtCHl2LkziIkoM9ok9/yFCoxNCb6RIUcw+uEmEzg8T8qXSRuk86dldT+Qp/ 57X2yD23mEOEMG0tpSCGYlww0Bl/I/o+OQbRKXh9MS4rwpnU9PsxG+5PB3dU+k54auQQ CmE5UMX4dtpksMtHTtk5vE9FP6HmdveanvwWe0InNPcdGOn0VcCYjNn3TqvcAg4jGj1S EFY3fNJkv+m22kMlQa8eZrzprhi74BJ3+5Ub3jbhEn2UpuYqm/pYuBFhYerqGUl2CKC9 e80RL7HuqcvJl/yEqOvdpo6RF4lfQeJUiG8SP1OP2YTACgITQLWEs7v3xP6LeiM5IDbF Nj9Q== X-Google-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:x-gm-message-state; bh=MsDvInpCq8kT2fycXurq14aa4iSj0sRdK6TC0UTYEGc=; b=F1tVeJyHZMF2Ljp6mBIU51E+Z/5cH0H80uNbf6QwX0MTrpv02vB3Dm5IQLsH9Uh63l wteV3nesMBsnfQ7X09sCtY9NIdJIHndtvwS9sUgmKTn9DtFsrfCEknum29a+xeaXzdMx noY+b4fxvYOD0przZDBujKC1Cfons3qGWAIp2zufeTzmAPzfh5PwuVWtKk3meWcTPZ/s blSXGNMA7CB0u1yFJqUSvVFnLvs0yFl8nI1HkYAANyaCuQBLyXe6EBQ/GDBp0If6Jum9 KuBXS42X2YUbZ6FedLWgFFCoZBCrdmNwcbB7DGCVXVscVC0bume5QVNrzQUFvVAo0CAG nhTg== MIME-Version: 1.0 Received: by 10.216.220.35 with SMTP id n35mr2826481wep.128.1354572573947; Mon, 03 Dec 2012 14:09:33 -0800 (PST) Received: by 10.194.166.100 with HTTP; Mon, 3 Dec 2012 14:09:33 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 14:09:33 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=0016e6dd8a1e17b87104cffa01f4 X-Gm-Message-State: ALoCoQmHjl6Ydl5ie4aOwT80BLuoQtyPeQz3gB6GkL8PFfbj3v1dG6999IYJLp+hTlSFgVi0Z54qDfFFNdLROI+kB+HQCtfwHgI6nMCyv1OVFm1PsWU0Yf5xqZ1XcG5S2VukXKSMVNDSgYp7bvqCCemYNfJfaZUkf2ig91/Xh2M7f+6Ov7L/i9h682CLlghW7ncpDaWS95zK X-Mailman-Approved-At: Tue, 04 Dec 2012 08:04:19 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:09:36 -0000 --0016e6dd8a1e17b87104cffa01f4 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 3, 2012 at 2:06 PM, Melvin Carvalho wrote: > >>>>> If Webfinger isnt just about email. What else is it about? >>>>> >>>> >>>> Accounts on services. >>>> >>>> >>> Limited to social services, or including, say, bank accounts? >>> >> >> Why would we limit it to social services? >> > > It's relatively easy to understand brad@gmail.com as an email account. > Maybe it could be argued brad@twitter.com is a microblogging account. > But accountno@citibank.com could be more problematic because you have a > further granularity such as sort code etc. If the scope is wide, then > there may be more cases to consider... > sort? scope? cases? I don't understand what you're asking about, but in any case: The rules are all the same regardless of what service(s) the hostname provides. 1) hit /.well-known/webfinger, 2) receive document. If Citibank pivots and becomes a Pinterest clone, their WebFinger still works. --0016e6dd8a1e17b87104cffa01f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Mon, Dec 3, 2012 at 2:06 PM, Melvin Carvalho <melvincarvalho@gmai= l.com> wrote:

If Webfinger isnt just about email.=C2= =A0 What else is it about?

Accounts on services.


Limited to social services, or including, say,= bank accounts?

=C2=A0Why would w= e limit it to social services?

It's relatively easy to understand brad@gmail.com as an email account.=C2=A0 Maybe it = could be argued brad@= twitter.com is a microblogging account.=C2=A0 But accountno@citibank.com could be = more problematic because you have a further granularity such as sort code e= tc.=C2=A0 If the scope is wide, then there may be more cases to consider...=

sort? scope? cases? =C2=A0I don'= t understand what you're asking about, but in any case: =C2=A0The rules= are all the same regardless of what service(s) the hostname provides.

1) hit /.well-known/webfinger, =C2=A02) receive document.

If Citibank pivots and becomes a Pinterest clone, th= eir WebFinger still works.
--0016e6dd8a1e17b87104cffa01f4-- From bradfitz@google.com Mon Dec 3 14:18:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F6F21F893F for ; Mon, 3 Dec 2012 14:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ68GKe7efkn for ; Mon, 3 Dec 2012 14:18:26 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA14921F8943 for ; Mon, 3 Dec 2012 14:18:25 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1440946wey.31 for ; Mon, 03 Dec 2012 14:18:24 -0800 (PST) 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=flWtuzU/qR5Tu9hfIpmQcFP9VYZ3TnRv47Qauli/Vvo=; b=J6FHH4fYrYK/cCWF+So2kyyCu+dZPtUZAPTvYQwvR1d7OPQ9XH4G+Buko7pTdyeA+2 2jn1bN3PX2jRK8xhIt/9i9Lv5JcZuUsbJyF+A2u2l73JUAfOdG7hts02g5ci//r69ocH M1XlNFXzz2IQVmQGLB7ErRdQowZycgBiLx35qjnE/+cK+rJ1Eg9Oeatk8HtApnhx2Cmc Fmg0FPIUN6ANrmhcB9mZJv34AvdtFEsLjea6EpR5uw0C7/SNu0ZoKWD5aFn0RvMD7sqJ 9HJiw5Zrs5ZeYjkxKgClwhY1HFyLJE3Xy1eJqpQM44EOfxyRp8J3tTO8r5iMhhd5v6Y5 i9cg== X-Google-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:x-gm-message-state; bh=flWtuzU/qR5Tu9hfIpmQcFP9VYZ3TnRv47Qauli/Vvo=; b=aBHD2ZasgoHA5WczZBwFH/CO1CF8n4hYX1r3Dc3ac71xMeu7qxRpuTHgKH6pbPwGnq SPNrao7poYh4AkcxNSX1/grFBTkADdFnHrBIWWQ3uVNTE3NKH/PP30e/zPmHE7yvs+Bx rLkDlmERFE9qAYob0MOwHjFuwU+DCqQw7NBwN3jh63kwuLneuYIvikmSDs42GEy/prYj TEatLaBqAIyAeOzRbqqhK+wcF6l26x3lw6cuCm9W7E4yhaKAoMx9L8LNeGOxJx8nN9S9 SbXVZC8it+tIXyKkoJ7tsaZXRQI2emZ8GnHXZ/t5AXKz4yseuz2BeFH5diWB+NmtS3yF IZzw== MIME-Version: 1.0 Received: by 10.180.85.194 with SMTP id j2mr932012wiz.12.1354573104736; Mon, 03 Dec 2012 14:18:24 -0800 (PST) Received: by 10.194.166.100 with HTTP; Mon, 3 Dec 2012 14:18:24 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 14:18:24 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d0444ef31baea2904cffa2034 X-Gm-Message-State: ALoCoQma625t+P1P0TUL1XGOGHeHI3iT3VFuEvIDMghUMgKUWGKbveXRYJUQVW7TSghVozIvwOfrWo3tgC3NiV4AkGydpXk50Q0EJDPn1xyPUeXiwpClFi0RAQI5qLIFcmCy7PvkOADnr/4CpR3t3eskiUTfTzW2xNKH0ZqdUzdzFTggAPUKjXzr70l5j6/SC8NxKrw7YNlU X-Mailman-Approved-At: Tue, 04 Dec 2012 08:04:19 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:18:26 -0000 --f46d0444ef31baea2904cffa2034 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 3, 2012 at 2:13 PM, Melvin Carvalho wrote: > > > On 3 December 2012 23:09, Brad Fitzpatrick wrote: > >> On Mon, Dec 3, 2012 at 2:06 PM, Melvin Carvalho > > wrote: >> >>> >>>>>>> If Webfinger isnt just about email. What else is it about? >>>>>>> >>>>>> >>>>>> Accounts on services. >>>>>> >>>>>> >>>>> Limited to social services, or including, say, bank accounts? >>>>> >>>> >>>> Why would we limit it to social services? >>>> >>> >>> It's relatively easy to understand brad@gmail.com as an email account. >>> Maybe it could be argued brad@twitter.com is a microblogging account. >>> But accountno@citibank.com could be more problematic because you have a >>> further granularity such as sort code etc. If the scope is wide, then >>> there may be more cases to consider... >>> >> >> sort? scope? cases? I don't understand what you're asking about, but in >> any case: The rules are all the same regardless of what service(s) the >> hostname provides. >> >> 1) hit /.well-known/webfinger, 2) receive document. >> >> If Citibank pivots and becomes a Pinterest clone, their WebFinger still >> works. >> > > sorry perhaps its a UK thing ... banks have both an account identifier and > a "sort code" to identify a branch > > just wondering if accountid@bank.com would be considered part of > webfinger scope > > hope that makes more sense, tho perhaps you've answered already in that, > if the file is missing it's not part of the system > WebFinger isn't going to specify rules for every possible application's user account naming policy. Banks get no special distinction, just as CAPS@example.net and caps@example.net get no special distinction. How the WebFinger server interprets the username is up to them. Gmail, for instance, is not case sensitive and pe.r...m.i..t.s periods anywhere in the username. That is also not being specified in WebFinger. --f46d0444ef31baea2904cffa2034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Mon, Dec 3, 2012 at 2:13 PM, Melvin Carvalho <melvincarvalho@gmai= l.com> wrote:


On 3 December 2012 23:09, Brad Fit= zpatrick <bradfitz@google.com> wrote:
O= n Mon, Dec 3, 2012 at 2:06 PM, Melvin Carvalho <melvincarvalho@gmai= l.com> wrote:

If Webfinger isnt just about email.=C2= =A0 What else is it about?

Accounts on services.


Limited to social services, or including, say,= bank accounts?

=C2=A0Why would w= e limit it to social services?

It's relatively easy to understand brad@gmail.com as an email account.=C2=A0 Maybe it = could be argued brad@= twitter.com is a microblogging account.=C2=A0 But accountno@citibank.com could be = more problematic because you have a further granularity such as sort code e= tc.=C2=A0 If the scope is wide, then there may be more cases to consider...=

sort? scope? cases? =C2=A0I do= n't understand what you're asking about, but in any case: =C2=A0The= rules are all the same regardless of what service(s) the hostname provides= .

1) hit /.well-known/webfinger, =C2=A02) receive document.

If Citibank pivots and becomes a Pinterest clone, th= eir WebFinger still works.
<= br> sorry perhaps its a UK thing ... banks have both an account identifier and = a "sort code" to identify a branch

just wondering if accountid@bank.com would be considered part of webfinger scope
hope that makes more sense, tho perhaps you've answered already in th= at, if the file is missing it's not part of the system

WebFinger isn't going to specif= y rules for every possible application's user account naming policy. = =C2=A0Banks get no special distinction, just as CAPS@example.net and caps@= example.net get no special distinction. =C2=A0How the WebFinger server = interprets the username is up to them. =C2=A0Gmail, for instance, is not ca= se sensitive and pe.r...m.i..t.s periods anywhere in the username. =C2=A0Th= at is also not being specified in WebFinger.
--f46d0444ef31baea2904cffa2034-- From nick@silverbucket.net Mon Dec 3 14:04:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6C321F8969 for ; Mon, 3 Dec 2012 14:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAGCgM8LHHRP for ; Mon, 3 Dec 2012 14:04:03 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF621F8968 for ; Mon, 3 Dec 2012 14:04:02 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2882090lbk.31 for ; Mon, 03 Dec 2012 14:04:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=lbeq3csLzrrZTOSyIxFBA447JxmnzYNlXM1Vnttlsqg=; b=ZxbdaiRvdxms1W7oWdVarwWBVXS5vYXYcGF3OgTmp/61mk7RnvyxID16BPRWNNotNo ExXe8LC5iATfTN4n22K1NlMkXOsiFdPFHqW2UAkPltiBsmwqdnnnmDLXJ0UL7BoWo8Kb BvmFN3huPGupGlNaUPC8fjG/766Vjx3lNnXTmOlkt0/5P7At6NC6qeR2OSYD39f0avbC uKPsUQhd33HsK21Ix/MAoO5RBucMZ06syxD2bqDASAiYFJyxfcsGsG6Blb3cm/tU09bY oxOpNY5ik2TKn2uM/eyAy3AdD4j95LIVPGxg4QmPqT9Aiv6z4ugPrQdCthLEZO0Px5Ck LETg== Received: by 10.112.29.129 with SMTP id k1mr5027814lbh.102.1354572241718; Mon, 03 Dec 2012 14:04:01 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id e4sm5975537lby.12.2012.12.03.14.04.00 (version=SSLv3 cipher=OTHER); Mon, 03 Dec 2012 14:04:01 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2760105lah.31 for ; Mon, 03 Dec 2012 14:04:00 -0800 (PST) Received: by 10.152.110.234 with SMTP id id10mr10978705lab.15.1354572240499; Mon, 03 Dec 2012 14:04:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Mon, 3 Dec 2012 14:03:30 -0800 (PST) In-Reply-To: <0bd101cdd19a$d3f59bf0$7be0d3d0$@packetizer.com> References: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> <0bd101cdd19a$d3f59bf0$7be0d3d0$@packetizer.com> From: Nick Jennings Date: Mon, 3 Dec 2012 23:03:30 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkUJtTywA5P2IY0DUWZV5Y8jD+B1WaB4PZZlDw/BUevtKpqX0QZN3pOouSSb6iD8hDfbYTg X-Mailman-Approved-At: Tue, 04 Dec 2012 08:04:29 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:04:04 -0000 On Mon, Dec 3, 2012 at 10:11 PM, Paul E. Jones wrote: > Nick, > > Does the words "would be expected to be equivalent" cause the concern? Should I make that "normally be equivalent"? Well I guess it would help to have some clarification on the implications (if any) of differences in the subject. Are there reasons the client library would want to check this and do something different if there is a difference? > The "best" means for "forwarding" would be to have the WF server respond with a 3xx pointing to the new location. > > So, if you query > acct:paulej@packetizer.com > > It might return a 301 (though Blaine would suggest 307) that refers the client to > https://example.org/.well-known/webfinger?acct:paulej@example.org > > An alternative that is not documented is to utilize the "acct" link relation for this purpose. That was text that used to be in the draft but was removed and is planned for a separate draft. > > One could query acct:paulej@packetizer.com and the reply that comes back might be: > > { > "subject" : "acct:paulej@packetizer.com", > "links" : > [ > { > "rel" : "acct", > "href" : "acct:paulej@example.com", > } > ] > } > > This is not a "forwarding", per se, but could inform the client that additional or other information is available elsewhere. This was never intended to a be a "forwarding" mechanism, though. The 3xx should do that. If you were using an email provider like gmail, or yahoo, but changed your email address and wanted to forward to your new address, do you think it's likely one of these big email providers would implement a way for you to set up a 301 (or 307) redirect for all queries on your account? I would guess no, so it seems more practical to have some method of specifying this 'inline'. In the JRD example you gave above, a WF client probably wouldn't automatically issue a new request to the address based on that 'acct' relation entry. So you'd loose quick-lookup functionality for all your old interactions with your old email address. I know there's probably no chance of this being introduced to the spec (having a standard way of specifying a forwarding account within the JRD response) but thought I'd bring it up anyway as I think there's plenty of use cases for it (ie. switching jobs, switching email providers, switching from an @gmail.com account to an @[mydomainname] account, or just having a few variations on the spelling of your name). -Nick From ve7jtb@ve7jtb.com Tue Dec 4 08:21:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7180A21F8720 for ; Tue, 4 Dec 2012 08:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGzZaCplw51Z for ; Tue, 4 Dec 2012 08:21:24 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA8F121F86D8 for ; Tue, 4 Dec 2012 08:21:23 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id z22so660465ghb.31 for ; Tue, 04 Dec 2012 08:21:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=X1IpY8cQ32fJCqLuouw9NJBzpUUw/MzN1cEucp9xgfE=; b=GmDAR4EIFO83Z3+owNHAnZIdwmInRmDJczsWVyXPTYe/fww+Tf6Ajhmf5+xfVkL6l7 AJC2wWckfMdsXFizS3evR6pntFSS3gscqU8pFI/pQzgTtqner6S/cc2XGeoYPdC7GiSf OB1BgKD3DaSIVzGk3iSlBYiQtT17S2Hlkv6vHil8A3SWm/rmAcf0Y48wTyCZFxLyG8hh pfD/GBhi0AtuNlI7zz1wJEanHEf/2QhtDnQC3Lby0iCHX8bXotQqh7ZBTWtLPGDDJti1 zZOyqf/lzGHDXdYk4kR7k+yaTYxNVy3MSXel5I+OskOov5SonwBwUjkKhayiuBZd3kuo 8E3A== Received: by 10.100.241.3 with SMTP id o3mr4468963anh.38.1354638083300; Tue, 04 Dec 2012 08:21:23 -0800 (PST) Received: from [192.168.1.211] (190-20-2-238.baf.movistar.cl. [190.20.2.238]) by mx.google.com with ESMTPS id h16sm1245355ani.0.2012.12.04.08.21.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Dec 2012 08:21:21 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B64839F5-F9BD-4F71-BA22-4BD2273AE4F5" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <0bae01cdd199$02da39f0$088eadd0$@packetizer.com> Date: Tue, 4 Dec 2012 13:20:37 -0300 Message-Id: References: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> <0bae01cdd199$02da39f0$088eadd0$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlZFCkoZVykwpy586bvVB7IGgcb6zpv4Tk17USu2GtLzNtG0cXrmK6LYNXdLgjsAwibCOh1 Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 16:21:25 -0000 --Apple-Mail=_B64839F5-F9BD-4F71-BA22-4BD2273AE4F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes but if I query ve7jtb@ve7jtb.com and it comes back with a subject of = acct:paulej@packetizer.com I may be claiming the JRD is about you but = that doesn't make it true. Clients need to be mindful that the subject of the JRD is self asserted = and care needs to be taken if any security related decisions are being = made.=20 On 2012-12-03, at 5:58 PM, "Paul E. Jones" = wrote: > John, > =20 > But, the subject is the subject of what the JRD describes. Who is the = authority here? It=92s the WF server. If my server tells you =93the = following JRD describes acct:paulej@packetizer.com=94, this is not = subject to second guessing. The value might not be equal to the = =93resource=94 parameter (for good cause), but normally would be. > =20 > Paul > =20 > From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley > Sent: Monday, December 03, 2012 8:11 AM > To: webfinger@googlegroups.com > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean = up "subject" > =20 > Added Web Finger to subject for the inocent. > =20 > I would change that to: > =20 > =93The value of the "subject" member is a string whose value is = advisory and normally would be expected to be equivalent to the value of = the "resource" parameter in the client request. The "subject" = identifies the entity to which the JRD claims to describe.=94 > =20 > The subject is self asserted saying that it is defiantly the ting that = the JRD describes will lead to applications making mistakes. The = subject is the thing that the JRD claims to be about. It is more likely = to be about the thing you did the query on. If they differ the client = should understand that the query parameter is the stronger binding. > =20 > If we go in on the acct: URI then I would be tempted to say that the = value SHOULD be the normalized acct: uri for the thing you are asking = about. That is likely more useful information to the client. > =20 > John B. > =20 > =20 > On 2012-12-03, at 4:16 AM, "Paul E. Jones" = wrote: >=20 >=20 > Tim, > =20 > Yeah, I can appreciate that. However, I would like to suggest some = slightly different wording. How is this for the first paragraph in = 5.2.2? > =20 > =93The value of the "subject" member is a string whose value is = advisory and normally would be expected to be equivalent to the value of = the "resource" parameter in the client request. The "subject" = identifies the entity to which the JRD describes.=94 > =20 > Paul > =20 > =20 > From: Tim Bray [mailto:tbray@textuality.com]=20 > Sent: Sunday, December 02, 2012 8:15 PM > To: Paul E. Jones > Cc: apps-discuss@ietf.org; webfinger@googlegroups.com > Subject: Draft -07 mod proposal: Clean up "subject" > =20 > Right now, section 5.2.2 says "The value of the "subject" member is a = string that MUST be set to the same value as the "resource" parameter in = the client request. " >=20 > This is a recipe for trouble, for a couple of reasons. First of all, = what does =93the same value=94 mean? Go visit RFC3986, section 6, and = enjoy several hundred words walking through all the issues that arise in = trying to figure out when two URIs are equivalent, ranging from exact = character-by-character identity to all sorts of protocol-specific goo. = You are just one level of case-sensitivity-in-%-escaping from a big = hairy false negative. >=20 > I=92m also worried about a lack of flexibility. I might have a single = webfinger resource that declares a bunch of link relations for a bunch = of different resources. This section, as written, wouldn=92t let me do = that. >=20 > Proposal: Re-write section 5.2.2 as follows: >=20 > <<<<<<< > The value of the "subject" member is a string whose value is advisory, = identifying the resource to which the properties given in the "links" = member apply. Normally this would be expected to be equivalent to the = value of the "resource" parameter in the client request.=20 > <<<<<<< >=20 > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones = wrote: > Folks, > =20 > I published another version of the WebFinger spec trying to bring = closure to the two open issues I see (resource representation and = transport). The new version is here: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 > =20 > With respect to resource representation, I fully described the JSON = Resource Descriptor within the document. There are no external = references to RFC 6415 now, no need to go read the XRD spec, etc. It=92s = a fairly simple format and I believe this text documents it = sufficiently. Combined with the visual examples, I think this makes it = pretty clear. Have a look at the JRD documentation in section 5.2 and = provide your comments. > =20 > With respect to HTTPS, it seems there is strong preference for =93HTTPS = only=94, but some a fair bit of insistence for allowing HTTP. I changed = the wording in 5.2 to try to capture opinions. Previously, the text led = with a requirement to try HTTPS first. That is still there. I just = added some extra conditions that make it clearer that there are some = instances where a client must not utilize HTTP. This might need further = refinement, but I think there is a balance we can strike here between = the two camps without introducing a lot of complex language. > =20 > I made some editorial changes through the document. > =20 > Comments are welcome, as always. Seems I don=92t need to say that to = this group, though :-) > =20 > Paul > =20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 --Apple-Mail=_B64839F5-F9BD-4F71-BA22-4BD2273AE4F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes but if I query ve7jtb@ve7jtb.com and it comes = back with a subject of packetizer.com I may be claiming the JRD is about you = but that doesn't make it true.

Clients need to be = mindful that the subject of the JRD is self asserted and care needs to = be taken if any security related decisions are being = made. 


On 2012-12-03, at = 5:58 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

 
But, the subject is the subject of what the = JRD describes.  Who is the authority here?  It=92s the WF = server.  If my server tells you =93the following JRD describes = acct:paulej@packetizer.com=94, this is not subject = to second guessing.  The value might not be equal to the =93resource=94= parameter (for good cause), but normally would = be.
 
Paul
 
From: apps-discuss-bounces@ietf.or= g [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Monday, December 03, 2012 = 8:11 AM
To: webfinger@googlegroups.com<= br>Cc: apps-discuss@ietf.org
S= ubject: Re: = [apps-discuss] Web Finger Draft -07 mod proposal: Clean up = "subject"
Added Web = Finger to subject for the inocent.
 
I would change that to:
 
=93The value of the "subject" = member is a string whose value is advisory and normally would be = expected to be equivalent to the value of the "resource" parameter in = the client request.  The "subject" identifies the entity to which = the JRD claims to = describe.=94
 
The subject is self asserted saying that it is defiantly the = ting that the JRD describes will lead to applications making mistakes. =   The subject is the thing that the JRD claims to be about. =  It is more likely to be about the thing you did the query on. =   If they differ the client should understand that the query = parameter is the stronger binding.
 
If we go in on the acct: URI then I would be = tempted to say that the value SHOULD be the normalized acct: uri for the = thing you are asking about.  That is likely more useful information = to the client.
John = B.
On = 2012-12-03, at 4:16 AM, "Paul E. Jones" <paulej@packetizer.com> = wrote:
Tim,
Yeah, I can appreciate that.  However, I = would like to suggest some slightly different wording.  How is this = for the first paragraph in 5.2.2?
=93The value of the "subject" member is a = string whose value is advisory and normally would be expected to be = equivalent to the value of the "resource" parameter in the client = request.  The "subject" identifies the entity to which the JRD = describes.=94
Paul
 
From: Tim Bray = [mailto:tbray@textuality.com] 
Sent: Sunday, December 02, 2012 = 8:15 PM
To: Paul E. = Jones
Cc: apps-discuss@ietf.org;  Draft -07 mod proposal: = Clean up "subject"

Right now, section 5.2.2 says "The value of the = "subject" member is a string that MUST be set to the same value as the = "resource" parameter in the client request. "

This is a recipe = for trouble, for a couple of reasons. First of all, what does =93the = same value=94 mean?  Go visit RFC3986, section 6, and enjoy several = hundred words walking through all the issues that arise in trying to = figure out when two URIs are equivalent, ranging from exact = character-by-character identity to all sorts of protocol-specific goo. = You are just one level of case-sensitivity-in-%-escaping from a big = hairy false negative.

I=92m also worried about a lack of = flexibility. I might have a single webfinger resource that declares a = bunch of link relations for a bunch of different resources. This = section, as written, wouldn=92t let me do that.

Proposal: = Re-write section 5.2.2 as = follows:

<<<<<<<
The value of the = "subject" member is a string whose value is advisory, identifying the = resource to which the properties given in the "links" member = apply.  Normally this would be expected to be equivalent to the = value of the "resource" parameter in the client request. 
<<<<<<&= lt;

apps-discuss@ietf.org
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 16:56:23 -0000 --14dae93998cdc72f5104d009be66 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The longer this discussion goes on, the more convinced I am that we should just remove =93subject=94. It=92s really hard to specify properly and it=92= s not obvious that it=92s actually useful. -T On Tue, Dec 4, 2012 at 8:20 AM, John Bradley wrote: > Yes but if I query ve7jtb@ve7jtb.com and it comes back with a subject of > acct:paulej@packetizer.com I may be claiming the JRD is about you but > that doesn't make it true. > > Clients need to be mindful that the subject of the JRD is self asserted > and care needs to be taken if any security related decisions are being > made. > > > On 2012-12-03, at 5:58 PM, "Paul E. Jones" wrote: > > John,**** > > But, the subject is the subject of what the JRD describes. Who is the > authority here? It=92s the WF server. If my server tells you =93the fol= lowing > JRD describes acct:paulej@packetizer.com=94, this is not subject to secon= d > guessing. The value might not be equal to the =93resource=94 parameter (= for > good cause), but normally would be.**** > > Paul**** > > *From:* apps-discuss-bounces@ietf.org [mailto:apps- > discuss-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Monday, December 03, 2012 8:11 AM > *To:* webfinger@googlegroups.com > *Cc:* apps-discuss@ietf.org > *Subject:* Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up > "subject"**** > ** ** > Added Web Finger to subject for the inocent.**** > ** ** > I would change that to:**** > ** ** > > =93The value of the "subject" member is a string whose value is advisory = and > normally would be expected to be equivalent to the value of the "resource= " > parameter in the client request. The "subject" identifies the entity to > which the JRD claims to describe.=94**** > > ** ** > The subject is self asserted saying that it is defiantly the ting that th= e > JRD describes will lead to applications making mistakes. The subject is > the thing that the JRD claims to be about. It is more likely to be about > the thing you did the query on. If they differ the client should > understand that the query parameter is the stronger binding.**** > ** ** > If we go in on the acct: URI then I would be tempted to say that the valu= e > SHOULD be the normalized acct: uri for the thing you are asking about. > That is likely more useful information to the client.**** > ** ** > John B.**** > ** ** > ** ** > On 2012-12-03, at 4:16 AM, "Paul E. Jones" wrote:= * > *** > > > **** > Tim,**** > **** > Yeah, I can appreciate that. However, I would like to suggest some > slightly different wording. How is this for the first paragraph in 5.2.2= ? > **** > **** > =93The value of the "subject" member is a string whose value is advisory = and > normally would be expected to be equivalent to the value of the "resource= " > parameter in the client request. The "subject" identifies the entity to > which the JRD describes.=94**** > **** > Paul**** > **** > **** > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Sunday, December 02, 2012 8:15 PM > *To:* Paul E. Jones > *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com > *Subject:* Draft -07 mod proposal: Clean up "subject"**** > **** > > Right now, section 5.2.2 says "The value of the "subject" member is a > string that MUST be set to the same value as the "resource" parameter in > the client request. " > > This is a recipe for trouble, for a couple of reasons. First of all, what > does =93the same value=94 mean? Go visit RFC3986, section 6, and enjoy s= everal > hundred words walking through all the issues that arise in trying to figu= re > out when two URIs are equivalent, ranging from exact character-by-charact= er > identity to all sorts of protocol-specific goo. You are just one level of > case-sensitivity-in-%-escaping from a big hairy false negative. > > I=92m also worried about a lack of flexibility. I might have a single > webfinger resource that declares a bunch of link relations for a bunch of > different resources. This section, as written, wouldn=92t let me do that. > > Proposal: Re-write section 5.2.2 as follows: > > <<<<<<< > The value of the "subject" member is a string whose value is advisory, > identifying the resource to which the properties given in the "links" > member apply. Normally this would be expected to be equivalent to the > value of the "resource" parameter in the client request. > <<<<<<<**** > On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones > wrote:**** > Folks,**** > **** > I published another version of the WebFinger spec trying to bring closure > to the two open issues I see (resource representation and transport). Th= e > new version is here:**** > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** > **** > With respect to resource representation, I fully described the JSON > Resource Descriptor within the document. There are no external reference= s > to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly > simple format and I believe this text documents it sufficiently. Combine= d > with the visual examples, I think this makes it pretty clear. Have a loo= k > at the JRD documentation in section 5.2 and provide your comments.**** > **** > With respect to HTTPS, it seems there is strong preference for =93HTTPS > only=94, but some a fair bit of insistence for allowing HTTP. I changed = the > wording in 5.2 to try to capture opinions. Previously, the text led with= a > requirement to try HTTPS first. That is still there. I just added some > extra conditions that make it clearer that there are some instances where= a > client must not utilize HTTP. This might need further refinement, but I > think there is a balance we can strike here between the two camps without > introducing a lot of complex language.**** > **** > I made some editorial changes through the document.**** > **** > Comments are welcome, as always. Seems I don=92t need to say that to thi= s > group, though :-)**** > **** > Paul**** > **** > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --14dae93998cdc72f5104d009be66 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The longer this discussion goes on, the more convinced I am that we should = just remove =93subject=94. It=92s really hard to specify properly and it=92= s not obvious that it=92s actually useful. -T

On Tue, Dec 4, 2012 at 8:20 AM, John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:
Yes but = if I query ve7jtb@ve= 7jtb.com and it comes back with a subject of=A0acct:paulej@packetizer.com=A0I ma= y be claiming the JRD is about you but that doesn't make it true.

Clients need to be mindful that the subject of the JRD is se= lf asserted and care needs to be taken if any security related decisions ar= e being made.=A0


<= div> On 2012-12-03, at 5:58 PM, "Paul E. Jones" <paulej@packetizer.com> wrot= e:

John,
=A0
But, the subject is = the subject of what the JRD describes.=A0 Who is the authority here?=A0 It= =92s the WF server.=A0 If my server tells you =93the following JRD describe= s acct:paulej@packetizer.com=94, this is not = subject to second guessing.=A0 The value might not be equal to the =93resou= rce=94 parameter (for good cause), but normally would be.
=A0
Paul
=A0=
From:=A0apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]=A0On Behalf Of=A0John Bradley
Sent:=A0Monday, December 03, 2012 8:11 AM
To:= =A0webfinger@googlegroups.com
Cc:=A0apps-discuss@ietf.org<= br> Subject:=A0Re: [apps-discuss] Web Finger Draft -07 mod = proposal: Clean up "subject"
=A0
Added Web Finger to subj= ect for the inocent.
=A0
I would change that to:=
=A0
=93The value of the "subj= ect" member is a string whose value is advisory and normally would be = expected to be equivalent to the value of the "resource" paramete= r in the client request.=A0 The "subject" identifies the entity t= o which the JRD claims to describe.=94
=A0
The subject is self asserted saying that it is defiantly the ting that the = JRD describes will lead to applications making mistakes. =A0 The subject is= the thing that the JRD claims to be about. =A0It is more likely to be abou= t the thing you did the query on. =A0 If they differ the client should unde= rstand that the query parameter is the stronger binding.
=A0
If we go in on the acct: URI then I would be tempted to say that the value = SHOULD be the normalized acct: uri for the thing you are asking about. =A0T= hat is likely more useful information to the client.
=A0
John B.
=A0<= /u>
=A0
On 2012-12-03, at 4= :16 AM, "Paul E. Jones" <paul= ej@packetizer.com> wrote:


Tim,
=A0
Yeah, I can appreciate that.=A0 H= owever, I would like to suggest some slightly different wording.=A0 How is = this for the first paragraph in 5.2.2?
=A0
=93The value of the "subject"= member is a string whose value is advisory and normally would be expected = to be equivalent to the value of the "resource" parameter in the = client request.=A0 The "subject" identifies the entity to which t= he JRD describes.=94
=A0
Paul
=A0
=A0
= From:=A0Tim= Bray [mailto:tbray@textuality.com]=A0
Sent:=A0Sunday, December 02, 2012 8:15 PM
To:= =A0Paul E. Jones
Cc:=A0apps-discuss@ietf.org;=A0webfinger@googlegroups.com
Subject:=A0Draft -07 mod proposal: Clean up "subje= ct"
=A0

Right now= , section 5.2.2 says "The value of the "subject" member is a= string that MUST be set to the same value as the "resource" para= meter in the client request. "

This is a recipe for trouble, for a couple of reasons. First of all, wh= at does =93the same value=94 mean?=A0 Go visit RFC3986, section 6, and enjo= y several hundred words walking through all the issues that arise in trying= to figure out when two URIs are equivalent, ranging from exact character-b= y-character identity to all sorts of protocol-specific goo. You are just on= e level of case-sensitivity-in-%-escaping from a big hairy false negative.<= br>
I=92m also worried about a lack of flexibility. I might have a single w= ebfinger resource that declares a bunch of link relations for a bunch of di= fferent resources. This section, as written, wouldn=92t let me do that.

Proposal: Re-write section 5.2.2 as follows:

<<<<<= ;<<
The value of the "subject" member is a string whose = value is advisory, identifying the resource to which the properties given i= n the "links" member apply.=A0 Normally this would be expected to= be equivalent to the value of the "resource" parameter in the cl= ient request.=A0
<<<<<<<

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com&= gt; wrote:
Folks,
=A0
I published anothe= r version of the WebFinger spec trying to bring closure to the two open iss= ues I see (resource representation and transport).=A0 The new version is he= re:
=A0
With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=A0 There are no external references to RF= C 6415 now, no need to go read the XRD spec, etc. =A0It=92s a fairly simple= format and I believe this text documents it sufficiently.=A0 Combined with= the visual examples, I think this makes it pretty clear.=A0 Have a look at= the JRD documentation in section 5.2 and provide your comments.<= /u>
=A0
With respect to HTTPS, it seems there is strong preference for =93HTTPS onl= y=94, but some a fair bit of insistence for allowing HTTP.=A0 I changed the= wording in 5.2 to try to capture opinions.=A0 Previously, the text led wit= h a requirement to try HTTPS first.=A0 That is still there.=A0 I just added= some extra conditions that make it clearer that there are some instances w= here a client must not utilize HTTP.=A0 This might need further refinement,= but I think there is a balance we can strike here between the two camps wi= thout introducing a lot of complex language.
=A0
I made some editorial changes through the document.
=A0
Comments are welcome, as always.=A0 Seems I don=92t need to say that to thi= s group, though :-)
=A0
Pa= ul
=A0
=


____________________________= ___________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.= ietf.org/mailman/listinfo/apps-discuss

=


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--14dae93998cdc72f5104d009be66-- From jpanzer@google.com Tue Dec 4 09:22:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5051021F8C76 for ; Tue, 4 Dec 2012 09:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzxSiIOhPA+e for ; Tue, 4 Dec 2012 09:22:43 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A04921F8C77 for ; Tue, 4 Dec 2012 09:22:42 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3703414lbk.31 for ; Tue, 04 Dec 2012 09:22:38 -0800 (PST) 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=as/gRsQ0qW7MU2I4odzQkAby22Hm4ECLz8EQbZszdEQ=; b=fTGofD/rzy1WluIX2uvN1yYkO4Zcmh0Akuh2yzlyfxBsJXzmIQ4UUI27ZcL53zaC98 ATLHVC+72EfCKTBi/IbpJt40a6Hre+4fDegF2am9xoZ3JzhHI488b6VvCkVD5J6Sn4lG 2afEnwOEDMJeCbA7OojClDhCCg3Cr2JHZ7mxE7XI1FFrMhvHkyba4MnZWI/4krQPzMu5 +eQBMUxoU6hV9w1K6M+GAhCyDMzdpLU4w6OfoJstpikzV9K50oa1pjiEkNCHMLFOUebO qfobE87dXwosgs54C69lSAiQsutConBoosenWVIzdijCWGpHVs/kPoiKTnB/0ro4qMi5 XkPA== X-Google-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:x-gm-message-state; bh=as/gRsQ0qW7MU2I4odzQkAby22Hm4ECLz8EQbZszdEQ=; b=nXjuexQPyaWCeua81q0BzQwdfsazIwjK+M9B0LxD9Qh+wP7MSQ2r2Ve8wMZhXjXNjy GpZbLkEuJWddUS9uxLpkNa8yj2jjx98PtgFB4Sk0D4nMNVFSMtWiZRrPzvSVaiTsK+/W 5pBS0S71g0BkynbnvD5o0JEMEtN9EecmiKgqUMI9jzfqhD7f82xXc71dfjoI+9aEsgCZ O5iLRdAp/rcKOwDS54B2JMrY9Q3kMBbTJOz02JMIyyT9+TabvV4xZnPl8ZbV3npc95F5 hux98IVPikP9aBiSJ+cczUQC65Q3wG94ROis1NyJl6Iav2KSGApGSROHeD4AaxSSojte LEig== MIME-Version: 1.0 Received: by 10.112.9.74 with SMTP id x10mr6093442lba.59.1354641757948; Tue, 04 Dec 2012 09:22:37 -0800 (PST) Received: by 10.114.4.197 with HTTP; Tue, 4 Dec 2012 09:22:37 -0800 (PST) Received: by 10.114.4.197 with HTTP; Tue, 4 Dec 2012 09:22:37 -0800 (PST) In-Reply-To: References: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> <0bae01cdd199$02da39f0$088eadd0$@packetizer.com> Date: Tue, 4 Dec 2012 09:22:37 -0800 Message-ID: From: John Panzer To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e0cb4efe307ac7cb5704d00a1c8c X-Gm-Message-State: ALoCoQm8inCiNybz+ews3qoMh5C3qic2J8b9Hd4VWpcJbDK7WJLdNJtFjo+0CO78xJAP7bUM8J/TMnAdbHMMcKUDAH01zMwXQBjs6z6O3vwAzL00Q1HhCX2a7nDXt9eszeIUkkYd4vHlAzoVRxtHmhIjJw8oyWWeWulibexH41IGJl8cpMy9VFRh8jlsJY92/P/TwD9QB7m7 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 17:22:45 -0000 --e0cb4efe307ac7cb5704d00a1c8c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If subject is not spec'd, my guess is that people who want it would use something like rel=3Dcanonical. Which would have all the same issues but would be not a Webfinger problem per se. On Dec 4, 2012 8:56 AM, "Tim Bray" wrote: > The longer this discussion goes on, the more convinced I am that we shoul= d > just remove =93subject=94. It=92s really hard to specify properly and it= =92s not > obvious that it=92s actually useful. -T > > On Tue, Dec 4, 2012 at 8:20 AM, John Bradley wrote: > >> Yes but if I query ve7jtb@ve7jtb.com and it comes back with a subject of >> acct:paulej@packetizer.com I may be claiming the JRD is about you but >> that doesn't make it true. >> >> Clients need to be mindful that the subject of the JRD is self asserted >> and care needs to be taken if any security related decisions are being >> made. >> >> >> On 2012-12-03, at 5:58 PM, "Paul E. Jones" wrote= : >> >> John,**** >> >> But, the subject is the subject of what the JRD describes. Who is the >> authority here? It=92s the WF server. If my server tells you =93the fo= llowing >> JRD describes acct:paulej@packetizer.com=94, this is not subject to seco= nd >> guessing. The value might not be equal to the =93resource=94 parameter = (for >> good cause), but normally would be.**** >> >> Paul**** >> >> *From:* apps-discuss-bounces@ietf.org [mailto:apps- >> discuss-bounces@ietf.org] *On Behalf Of *John Bradley >> *Sent:* Monday, December 03, 2012 8:11 AM >> *To:* webfinger@googlegroups.com >> *Cc:* apps-discuss@ietf.org >> *Subject:* Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean >> up "subject"**** >> ** ** >> Added Web Finger to subject for the inocent.**** >> ** ** >> I would change that to:**** >> ** ** >> >> =93The value of the "subject" member is a string whose value is advisory >> and normally would be expected to be equivalent to the value of the >> "resource" parameter in the client request. The "subject" identifies th= e >> entity to which the JRD claims to describe.=94**** >> >> ** ** >> The subject is self asserted saying that it is defiantly the ting that >> the JRD describes will lead to applications making mistakes. The subje= ct >> is the thing that the JRD claims to be about. It is more likely to be >> about the thing you did the query on. If they differ the client should >> understand that the query parameter is the stronger binding.**** >> ** ** >> If we go in on the acct: URI then I would be tempted to say that the >> value SHOULD be the normalized acct: uri for the thing you are asking >> about. That is likely more useful information to the client.**** >> ** ** >> John B.**** >> ** ** >> ** ** >> On 2012-12-03, at 4:16 AM, "Paul E. Jones" wrote= : >> **** >> >> >> **** >> Tim,**** >> **** >> Yeah, I can appreciate that. However, I would like to suggest some >> slightly different wording. How is this for the first paragraph in 5.2.= 2? >> **** >> **** >> =93The value of the "subject" member is a string whose value is advisory >> and normally would be expected to be equivalent to the value of the >> "resource" parameter in the client request. The "subject" identifies th= e >> entity to which the JRD describes.=94**** >> **** >> Paul**** >> **** >> **** >> *From:* Tim Bray [mailto:tbray@textuality.com] >> *Sent:* Sunday, December 02, 2012 8:15 PM >> *To:* Paul E. Jones >> *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com >> *Subject:* Draft -07 mod proposal: Clean up "subject"**** >> **** >> >> Right now, section 5.2.2 says "The value of the "subject" member is a >> string that MUST be set to the same value as the "resource" parameter in >> the client request. " >> >> This is a recipe for trouble, for a couple of reasons. First of all, wha= t >> does =93the same value=94 mean? Go visit RFC3986, section 6, and enjoy = several >> hundred words walking through all the issues that arise in trying to fig= ure >> out when two URIs are equivalent, ranging from exact character-by-charac= ter >> identity to all sorts of protocol-specific goo. You are just one level o= f >> case-sensitivity-in-%-escaping from a big hairy false negative. >> >> I=92m also worried about a lack of flexibility. I might have a single >> webfinger resource that declares a bunch of link relations for a bunch o= f >> different resources. This section, as written, wouldn=92t let me do that= . >> >> Proposal: Re-write section 5.2.2 as follows: >> >> <<<<<<< >> The value of the "subject" member is a string whose value is advisory, >> identifying the resource to which the properties given in the "links" >> member apply. Normally this would be expected to be equivalent to the >> value of the "resource" parameter in the client request. >> <<<<<<<**** >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones >> wrote:**** >> Folks,**** >> **** >> I published another version of the WebFinger spec trying to bring closur= e >> to the two open issues I see (resource representation and transport). T= he >> new version is here:**** >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >> **** >> With respect to resource representation, I fully described the JSON >> Resource Descriptor within the document. There are no external referenc= es >> to RFC 6415 now, no need to go read the XRD spec, etc. It=92s a fairly >> simple format and I believe this text documents it sufficiently. Combin= ed >> with the visual examples, I think this makes it pretty clear. Have a lo= ok >> at the JRD documentation in section 5.2 and provide your comments.**** >> **** >> With respect to HTTPS, it seems there is strong preference for =93HTTPS >> only=94, but some a fair bit of insistence for allowing HTTP. I changed= the >> wording in 5.2 to try to capture opinions. Previously, the text led wit= h a >> requirement to try HTTPS first. That is still there. I just added some >> extra conditions that make it clearer that there are some instances wher= e a >> client must not utilize HTTP. This might need further refinement, but I >> think there is a balance we can strike here between the two camps withou= t >> introducing a lot of complex language.**** >> **** >> I made some editorial changes through the document.**** >> **** >> Comments are welcome, as always. Seems I don=92t need to say that to th= is >> group, though :-)**** >> **** >> Paul**** >> **** >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss**** >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > --e0cb4efe307ac7cb5704d00a1c8c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

If subject is not spec'd, my guess is that people who wa= nt it would use something like rel=3Dcanonical.=A0 Which would have all the= same issues but would be not a Webfinger problem per se.

 --e0cb4efe307ac7cb5704d00a1c8c-- From jasnell@gmail.com Tue Dec 4 09:28:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E37821F8C75 for ; Tue, 4 Dec 2012 09:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF688nEKCDul for ; Tue, 4 Dec 2012 09:28:27 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A862A21F875E for ; Tue, 4 Dec 2012 09:28:27 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so3476851iaz.31 for ; Tue, 04 Dec 2012 09:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=f2ytxBlzhXCLCKR4plIt83GtiJsy826ZLIjPByV0lAo=; b=zI3g8DbBZuLPU5GbVVgdfSyQk0GrpG4QIBi8mYXSWWKnMzHaOyzb7ejLKMyztC8CtA g//vpc7QA8PuVrN7mgBnMmtE8iYcHhzFiDPSHk18dqPqDYtqpTo1tyEYfWocsgE5Ow8q SPPlxLL970COsqnGdg3t/otGeBRxU6WyFk6vjPcLq3z/UeGOlElD59JB2skiHeCNWWdi SiFRYrCKKVKKEfMHg9n5HRQq4pnV2WAMeCYupI+0uTLGtvaMSr/vyia5R58nptb1q16S SqHMNS/WEmm8CRK/OogrFyLfKPtq0U43iPjcYVUgdgUMLzsv0T/uvLF4S0NBCsKGL/ls 6KFA== Received: by 10.50.159.229 with SMTP id xf5mr3670217igb.0.1354642107266; Tue, 04 Dec 2012 09:28:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Tue, 4 Dec 2012 09:28:06 -0800 (PST) In-Reply-To: References: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> <0bae01cdd199$02da39f0$088eadd0$@packetizer.com> From: James M Snell Date: Tue, 4 Dec 2012 09:28:06 -0800 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=14dae934071f99f79004d00a3115 Cc: "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 17:28:29 -0000 --14dae934071f99f79004d00a3115 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm quite the opposite on this actually... at first I didn't think it would be useful but then I really sat down and started going through various use cases.. in particular, how things could be implemented in environments like IBM's hosted cloud social services. In our environment, there are two critical identifiers for a user... their email address (which is usually their company specific address.. e.g. joe@corp.example.com) and the account id used within our application. If we were to implement WebFinger in our infrastructure on behalf of our clients, it should be possible to pass in either the email address or the account id as the value of the resource parameter. Regardless of which is passed in, the JRD returned should be identical. The subject (and aliases) properties would provide the necessary correlation we need to match them up.. e.g. https://apps.example.com/.well-known/webfinger?resource=3Dacct:joe@corp.exa= mple.com https://apps.example.com/.well-known/webfinger?resource=3Dacct:1234abcd@app= s.example.com both would return... { "subject": "acct:1234abcd@apps.example.com", "aliases": [ "acct:joe@corp.example.com", "acct:1234abcd@apps.example.com" ], ... } It's ok if the value of the resource parameter does not match, character-for-character, the subject value.. and determining the equivalence of the two values is not critical so long as the resource parameter value shows up as one of the listed aliases. - James On Tue, Dec 4, 2012 at 8:56 AM, Tim Bray wrote: > The longer this discussion goes on, the more convinced I am that we shoul= d > just remove =E2=80=9Csubject=E2=80=9D. It=E2=80=99s really hard to specif= y properly and it=E2=80=99s not > obvious that it=E2=80=99s actually useful. -T > > > On Tue, Dec 4, 2012 at 8:20 AM, John Bradley wrote: > >> Yes but if I query ve7jtb@ve7jtb.com and it comes back with a subject of >> acct:paulej@packetizer.com I may be claiming the JRD is about you but >> that doesn't make it true. >> >> Clients need to be mindful that the subject of the JRD is self asserted >> and care needs to be taken if any security related decisions are being >> made. >> >> >> On 2012-12-03, at 5:58 PM, "Paul E. Jones" wrote= : >> >> John,**** >> >> But, the subject is the subject of what the JRD describes. Who is the >> authority here? It=E2=80=99s the WF server. If my server tells you =E2= =80=9Cthe following >> JRD describes acct:paulej@packetizer.com=E2=80=9D, this is not subject t= o second >> guessing. The value might not be equal to the =E2=80=9Cresource=E2=80= =9D parameter (for >> good cause), but normally would be.**** >> >> Paul**** >> >> *From:* apps-discuss-bounces@ietf.org [mailto:apps- >> discuss-bounces@ietf.org] *On Behalf Of *John Bradley >> *Sent:* Monday, December 03, 2012 8:11 AM >> *To:* webfinger@googlegroups.com >> *Cc:* apps-discuss@ietf.org >> *Subject:* Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean >> up "subject"**** >> ** ** >> Added Web Finger to subject for the inocent.**** >> ** ** >> I would change that to:**** >> ** ** >> >> =E2=80=9CThe value of the "subject" member is a string whose value is ad= visory >> and normally would be expected to be equivalent to the value of the >> "resource" parameter in the client request. The "subject" identifies th= e >> entity to which the JRD claims to describe.=E2=80=9D**** >> >> ** ** >> The subject is self asserted saying that it is defiantly the ting that >> the JRD describes will lead to applications making mistakes. The subje= ct >> is the thing that the JRD claims to be about. It is more likely to be >> about the thing you did the query on. If they differ the client should >> understand that the query parameter is the stronger binding.**** >> ** ** >> If we go in on the acct: URI then I would be tempted to say that the >> value SHOULD be the normalized acct: uri for the thing you are asking >> about. That is likely more useful information to the client.**** >> ** ** >> John B.**** >> ** ** >> ** ** >> On 2012-12-03, at 4:16 AM, "Paul E. Jones" wrote= : >> **** >> >> >> **** >> Tim,**** >> **** >> Yeah, I can appreciate that. However, I would like to suggest some >> slightly different wording. How is this for the first paragraph in 5.2.= 2? >> **** >> **** >> =E2=80=9CThe value of the "subject" member is a string whose value is ad= visory >> and normally would be expected to be equivalent to the value of the >> "resource" parameter in the client request. The "subject" identifies th= e >> entity to which the JRD describes.=E2=80=9D**** >> **** >> Paul**** >> **** >> **** >> *From:* Tim Bray [mailto:tbray@textuality.com] >> *Sent:* Sunday, December 02, 2012 8:15 PM >> *To:* Paul E. Jones >> *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com >> *Subject:* Draft -07 mod proposal: Clean up "subject"**** >> **** >> >> Right now, section 5.2.2 says "The value of the "subject" member is a >> string that MUST be set to the same value as the "resource" parameter in >> the client request. " >> >> This is a recipe for trouble, for a couple of reasons. First of all, wha= t >> does =E2=80=9Cthe same value=E2=80=9D mean? Go visit RFC3986, section 6= , and enjoy several >> hundred words walking through all the issues that arise in trying to fig= ure >> out when two URIs are equivalent, ranging from exact character-by-charac= ter >> identity to all sorts of protocol-specific goo. You are just one level o= f >> case-sensitivity-in-%-escaping from a big hairy false negative. >> >> I=E2=80=99m also worried about a lack of flexibility. I might have a sin= gle >> webfinger resource that declares a bunch of link relations for a bunch o= f >> different resources. This section, as written, wouldn=E2=80=99t let me d= o that. >> >> Proposal: Re-write section 5.2.2 as follows: >> >> <<<<<<< >> The value of the "subject" member is a string whose value is advisory, >> identifying the resource to which the properties given in the "links" >> member apply. Normally this would be expected to be equivalent to the >> value of the "resource" parameter in the client request. >> <<<<<<<**** >> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones >> wrote:**** >> Folks,**** >> **** >> I published another version of the WebFinger spec trying to bring closur= e >> to the two open issues I see (resource representation and transport). T= he >> new version is here:**** >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07**** >> **** >> With respect to resource representation, I fully described the JSON >> Resource Descriptor within the document. There are no external referenc= es >> to RFC 6415 now, no need to go read the XRD spec, etc. It=E2=80=99s a f= airly >> simple format and I believe this text documents it sufficiently. Combin= ed >> with the visual examples, I think this makes it pretty clear. Have a lo= ok >> at the JRD documentation in section 5.2 and provide your comments.**** >> **** >> With respect to HTTPS, it seems there is strong preference for =E2=80=9C= HTTPS >> only=E2=80=9D, but some a fair bit of insistence for allowing HTTP. I c= hanged the >> wording in 5.2 to try to capture opinions. Previously, the text led wit= h a >> requirement to try HTTPS first. That is still there. I just added some >> extra conditions that make it clearer that there are some instances wher= e a >> client must not utilize HTTP. This might need further refinement, but I >> think there is a balance we can strike here between the two camps withou= t >> introducing a lot of complex language.**** >> **** >> I made some editorial changes through the document.**** >> **** >> Comments are welcome, as always. Seems I don=E2=80=99t need to say that= to this >> group, though :-)**** >> **** >> Paul**** >> **** >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss**** >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --14dae934071f99f79004d00a3115 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm qu= ite the opposite on this actually... at first I didn't think it would b= e useful but then I really sat down and started going through various use c= ases.. in particular, how things could be implemented in environments like = IBM's hosted cloud social services.=C2=A0

In = our environment, there are two critical identifiers for a user... their ema= il address (which is usually their company specific address.. e.g. joe@corp.example.com) and the account = id used within our application. If we were to implement WebFinger in our in= frastructure on behalf of our clients, it should be possible to pass in eit= her the email address or the account id as the value of the resource parame= ter. Regardless of which is passed in, the JRD returned should be identical= . The subject (and aliases) properties would provide the necessary correlat= ion we need to match them up.. e.g.

https://apps.example.com/.well-known/webfinger?resource= =3Dacct:joe@corp.example.com

https://apps.example.com/.well-known/webfinger?resou= rce=3Dacct:1234abcd@apps.example.com

bot= h would return...

=C2=A0 {
=C2=A0 =C2=A0 "subject": "acct:1234abcd@apps.example.com",
=C2=A0 =C2= =A0 "aliases": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0"acct:joe@corp.example.com",
=C2=A0 =C2= =A0 =C2=A0 =C2=A0"= acct:1234abcd@apps.example.com"
=C2=A0 =C2=A0 ],
=C2=A0 =C2= =A0 ...
=C2=A0 }

It's ok if the value of the resource parameter does not match, chara= cter-for-character, the subject value.. and determining the equivalence of = the two values is not critical so long as the resource parameter value show= s up as one of the listed aliases.=C2=A0

- J= ames

On Tue, Dec 4, 2012 at 8:56 A= M, Tim Bray <tbray@textuality.com> wrote:
The longer this discussion goes on, the more= convinced I am that we should just remove =E2=80=9Csubject=E2=80=9D. It=E2= =80=99s really hard to specify properly and it=E2=80=99s not obvious that i= t=E2=80=99s actually useful. -T


On Tue, Dec 4, 2012 at= 8:20 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but = if I query ve7jtb@ve= 7jtb.com and it comes back with a subject of=C2=A0acct:paulej@<= /span>packetizer.com=C2= =A0I may be claiming the JRD is about you but that doesn't make it true= .

Clients need to be mindful that the subject of the JRD is se= lf asserted and care needs to be taken if any security related decisions ar= e being made.=C2=A0


On 2012-12-03, at 5:58 PM, "Paul E. Jones" <paulej@packetizer.com> wrot= e:

John,
=C2=A0
But, the subject = is the subject of what the JRD describes.=C2=A0 Who is the authority here?= =C2=A0 It=E2=80=99s the WF server.=C2=A0 If my server tells you =E2=80=9Cth= e following JRD describes acct:paulej@packetizer.= com=E2=80=9D, this is not subject to second guessing.=C2=A0 The value m= ight not be equal to the =E2=80=9Cresource=E2=80=9D parameter (for good cau= se), but normally would be.
=C2=A0
Paul
=C2= =A0
From:=C2=A0apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0John Bradley
Sent:=C2=A0Monday, December 03, 2012 8:11 AM
To:<= /b>=C2=A0webfinger@googlegroups.com
Cc:=C2=A0= apps-discuss@iet= f.org
Subject:=C2=A0Re: [apps-discuss] Web Finger Draft -07 m= od proposal: Clean up "subject"
<= /div>
=C2=A0
Added Web Finger to s= ubject for the inocent.
I would change that = to:
=C2=A0
=E2=80=9CThe value of the &= quot;subject" member is a string whose value is advisory and normally = would be expected to be equivalent to the value of the "resource"= parameter in the client request.=C2=A0 The "subject" identifies = the entity to which the JRD claims to describe.=E2=80=9D
=C2=A0
The subject is self asserted saying that it is defiantly the ting that the = JRD describes will lead to applications making mistakes. =C2=A0 The subject= is the thing that the JRD claims to be about. =C2=A0It is more likely to b= e about the thing you did the query on. =C2=A0 If they differ the client sh= ould understand that the query parameter is the stronger binding.=
=C2=A0
If we go in on the acct: URI then I would be tempted to say that the value = SHOULD be the normalized acct: uri for the thing you are asking about. =C2= =A0That is likely more useful information to the client.
=C2=A0
John B.
=C2=A0<= u>
=C2=A0
On 2012-12-03, a= t 4:16 AM, "Paul E. Jones" <p= aulej@packetizer.com> wrote:


Tim,
=C2=A0
Yeah, I can appreciate that.=C2= =A0 However, I would like to suggest some slightly different wording.=C2=A0= How is this for the first paragraph in 5.2.2?
=C2=A0
=
=E2=80=9CThe value of the "subject= " member is a string whose value is advisory and normally would be exp= ected to be equivalent to the value of the "resource" parameter i= n the client request.=C2=A0 The "subject" identifies the entity t= o which the JRD describes.=E2=80=9D
=C2=A0
=
Paul
=C2=A0
=
=C2=A0
= From:=C2=A0= = Tim Bray [mailto:tbray@textuality.com]=C2=A0
Sent:=C2=A0Sunday, December 02, 2012 8:15 PM
To:<= /b>=C2=A0Paul E. Jones
Cc:=C2=A0apps-discuss@ietf.org;=C2=A0webfinger@googlegroups.com
Subject:=C2=A0Draft -07 mod proposal: Clean up "su= bject"
=C2=A0

Right = now, section 5.2.2 says "The value of the "subject" member i= s a string that MUST be set to the same value as the "resource" p= arameter in the client request. "

This is a recipe for trouble, for a couple of reasons. First of all, wh= at does =E2=80=9Cthe same value=E2=80=9D mean?=C2=A0 Go visit RFC3986, sect= ion 6, and enjoy several hundred words walking through all the issues that = arise in trying to figure out when two URIs are equivalent, ranging from ex= act character-by-character identity to all sorts of protocol-specific goo. = You are just one level of case-sensitivity-in-%-escaping from a big hairy f= alse negative.

I=E2=80=99m also worried about a lack of flexibility. I might have a si= ngle webfinger resource that declares a bunch of link relations for a bunch= of different resources. This section, as written, wouldn=E2=80=99t let me = do that.

Proposal: Re-write section 5.2.2 as follows:

<<<<<= ;<<
The value of the "subject" member is a string whose = value is advisory, identifying the resource to which the properties given i= n the "links" member apply.=C2=A0 Normally this would be expected= to be equivalent to the value of the "resource" parameter in the= client request.=C2=A0
<<<<<<<

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com&= gt; wrote:
Folks,
=C2=A0
I published ano= ther version of the WebFinger spec trying to bring closure to the two open = issues I see (resource representation and transport).=C2=A0 The new version= is here:
=C2=A0
With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=C2=A0 There are no external references to= RFC 6415 now, no need to go read the XRD spec, etc. =C2=A0It=E2=80=99s a f= airly simple format and I believe this text documents it sufficiently.=C2= =A0 Combined with the visual examples, I think this makes it pretty clear.= =C2=A0 Have a look at the JRD documentation in section 5.2 and provide your= comments.
=C2=A0
With respect to HTTPS, it seems there is strong preference for =E2=80=9CHTT= PS only=E2=80=9D, but some a fair bit of insistence for allowing HTTP.=C2= =A0 I changed the wording in 5.2 to try to capture opinions.=C2=A0 Previous= ly, the text led with a requirement to try HTTPS first.=C2=A0 That is still= there.=C2=A0 I just added some extra conditions that make it clearer that = there are some instances where a client must not utilize HTTP.=C2=A0 This m= ight need further refinement, but I think there is a balance we can strike = here between the two camps without introducing a lot of complex language.
=C2=A0
I made some editorial changes through the document.
=C2=A0
Comments are welcome, as always.=C2=A0 Seems I don=E2=80=99t need to say th= at to this group, though :-)
=C2=A0
Pa= ul
=C2=A0


_________________________= ______________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.= ietf.org/mailman/listinfo/apps-discuss

=


_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

On Dec 4, 2012 8:56 AM, "Tim Bray" <= ;tbray@textuality.com> wrote= :
The longer this discussion goes on, the more convinced I am that we should = just remove =93subject=94. It=92s really hard to specify properly and it=92= s not obvious that it=92s actually useful. -T

On Tue, Dec 4, 2012 at 8:20 AM, John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:
Yes but = if I query ve7jtb@ve= 7jtb.com and it comes back with a subject of=A0acct:paulej@packetizer.com=A0I ma= y be claiming the JRD is about you but that doesn't make it true.

Clients need to be mindful that the subject of the JRD is se= lf asserted and care needs to be taken if any security related decisions ar= e being made.=A0


On 2012-12-03, at 5:58 PM, "Paul E. Jones" <paulej@packetizer.com> wrot= e:

John,
=A0
But, the subject is = the subject of what the JRD describes.=A0 Who is the authority here?=A0 It= =92s the WF server.=A0 If my server tells you =93the following JRD describe= s acct:paulej@packetizer.com=94, this is not = subject to second guessing.=A0 The value might not be equal to the =93resou= rce=94 parameter (for good cause), but normally would be.
=A0
Paul
=A0=
From:=A0apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]=A0On Behalf Of=A0John Bradley
Sent:=A0Monday, December 03, 2012 8:11 AM
To:= =A0webfinger@googlegroups.com
Cc:=A0apps-discuss@ietf.org<= br> Subject:=A0Re: [apps-discuss] Web Finger Draft -07 mod = proposal: Clean up "subject"
=A0
Added Web Finger to subj= ect for the inocent.
=A0
I would change that to:=
=A0
=93The value of the "subj= ect" member is a string whose value is advisory and normally would be = expected to be equivalent to the value of the "resource" paramete= r in the client request.=A0 The "subject" identifies the entity t= o which the JRD claims to describe.=94
=A0
The subject is self asserted saying that it is defiantly the ting that the = JRD describes will lead to applications making mistakes. =A0 The subject is= the thing that the JRD claims to be about. =A0It is more likely to be abou= t the thing you did the query on. =A0 If they differ the client should unde= rstand that the query parameter is the stronger binding.
=A0
If we go in on the acct: URI then I would be tempted to say that the value = SHOULD be the normalized acct: uri for the thing you are asking about. =A0T= hat is likely more useful information to the client.
=A0
John B.
=A0<= /u>
=A0
On 2012-12-03, at 4= :16 AM, "Paul E. Jones" <paul= ej@packetizer.com> wrote:


Tim,
=A0
Yeah, I can appreciate that.=A0 H= owever, I would like to suggest some slightly different wording.=A0 How is = this for the first paragraph in 5.2.2?
=A0
=93The value of the "subject"= member is a string whose value is advisory and normally would be expected = to be equivalent to the value of the "resource" parameter in the = client request.=A0 The "subject" identifies the entity to which t= he JRD describes.=94
=A0
Paul
=A0
=A0
= From:=A0Tim= Bray [mailto:tbray@textuality.com]=A0
Sent:=A0Sunday, December 02, 2012 8:15 PM
To:= =A0Paul E. Jones
Cc:=A0apps-discuss@ietf.org;=A0webfinger@googlegroups.com
Subject:=A0Draft -07 mod proposal: Clean up "subje= ct"
=A0

Right now= , section 5.2.2 says "The value of the "subject" member is a= string that MUST be set to the same value as the "resource" para= meter in the client request. "

This is a recipe for trouble, for a couple of reasons. First of all, wh= at does =93the same value=94 mean?=A0 Go visit RFC3986, section 6, and enjo= y several hundred words walking through all the issues that arise in trying= to figure out when two URIs are equivalent, ranging from exact character-b= y-character identity to all sorts of protocol-specific goo. You are just on= e level of case-sensitivity-in-%-escaping from a big hairy false negative.<= br>
I=92m also worried about a lack of flexibility. I might have a single w= ebfinger resource that declares a bunch of link relations for a bunch of di= fferent resources. This section, as written, wouldn=92t let me do that.

Proposal: Re-write section 5.2.2 as follows:

<<<<<= ;<<
The value of the "subject" member is a string whose = value is advisory, identifying the resource to which the properties given i= n the "links" member apply.=A0 Normally this would be expected to= be equivalent to the value of the "resource" parameter in the cl= ient request.=A0
<<<<<<<

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <paulej@packetizer.com&= gt; wrote:
Folks,
=A0
I published anothe= r version of the WebFinger spec trying to bring closure to the two open iss= ues I see (resource representation and transport).=A0 The new version is he= re:
=A0
With respect to resource representation, I fully described the JSON Resourc= e Descriptor within the document.=A0 There are no external references to RF= C 6415 now, no need to go read the XRD spec, etc. =A0It=92s a fairly simple= format and I believe this text documents it sufficiently.=A0 Combined with= the visual examples, I think this makes it pretty clear.=A0 Have a look at= the JRD documentation in section 5.2 and provide your comments.<= /u>
=A0
With respect to HTTPS, it seems there is strong preference for =93HTTPS onl= y=94, but some a fair bit of insistence for allowing HTTP.=A0 I changed the= wording in 5.2 to try to capture opinions.=A0 Previously, the text led wit= h a requirement to try HTTPS first.=A0 That is still there.=A0 I just added= some extra conditions that make it clearer that there are some instances w= here a client must not utilize HTTP.=A0 This might need further refinement,= but I think there is a balance we can strike here between the two camps wi= thout introducing a lot of complex language.
=A0
I made some editorial changes through the document.
=A0
Comments are welcome, as always.=A0 Seems I don=92t need to say that to thi= s group, though :-)
=A0
Pa= ul
=A0
=


____________________________= ___________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.= ietf.org/mailman/listinfo/apps-discuss

=


_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss




_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--14dae934071f99f79004d00a3115-- From romeda@gmail.com Tue Dec 4 10:55:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2FB21F8CCD for ; Tue, 4 Dec 2012 10:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNCOl2d3CIQ7 for ; Tue, 4 Dec 2012 10:55:16 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35F5921F8CCA for ; Tue, 4 Dec 2012 10:55:16 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2890513pbc.31 for ; Tue, 04 Dec 2012 10:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/bLNZseS+CD8VtnnFOX3pMtUYP89hibnNPoDjZCzSVU=; b=FEpj3Gl49+Rcp25znMNAz4hKlYyMwUmfiZCxwteYFxB4GDvDLOo7Eu0FiU1RCoiA7o uBhN0jvXvT22wE+1sjokTGGUqpQOkCHwrSukrxZf354quz1/P9DdVoW18jOnh3Jm/6PJ A96QCvWvlXBJxg1WLfHS7sLK2Buekv493t/4A7nRtFAy2MucAxu4dwHuMHx5y6yQWSqj 1rrhxyf8MFEV2yyAtz86/T87PiZePqVaHjUkTMc9yJKQBUpErOU5lyedn95yWZyzs+Ta vL7bjnXRF/bLkhJoHBraRcT/T6a/vuoxmvoFHMO6hPnHuVg8+j2gfa2Mnu9RNNDQDjJ7 gRWw== Received: by 10.68.197.68 with SMTP id is4mr40882759pbc.30.1354647315902; Tue, 04 Dec 2012 10:55:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.59.229 with HTTP; Tue, 4 Dec 2012 10:54:55 -0800 (PST) In-Reply-To: References: From: Blaine Cook Date: Tue, 4 Dec 2012 18:54:55 +0000 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8ff1c8620f6f8f04d00b6852 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:55:17 -0000 --e89a8ff1c8620f6f8f04d00b6852 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can I offer a compromise? I know the voice of small providers isn't very welcome here, but I think it's (still) important. Examples like Github Pages are relevant, whether those at organisations with large engineering resources think so or not. n.b. If someone on this list can convince Github to do the necessary work (or even a clear commitment with a stated time-frame for delivery) to have this ticket closed: http://www.mail-archive.com/tor-bugs@lists.torproject.org/msg30067.htmlI'll totally rescind my concerns over this. How about: Clients MUST query the server using HTTPS, obeying HSTS semantics. If an HTTPS connection has never been established, or returns an HTTP status code indicating some error, such as 4xx or 5xx, absent HSTS headers, the client MAY attempt the same query using HTTP. ... and then add something (e.g. after =C2=A77) to the effect of: --- Transport Security It is advised that webfinger resources that are to be used for authentication or verification purposes SHOULD use HTTPS, and HTTPS-enabled servers SHOULD use HSTS to ensure that clients are not vulnerable to downgrade attacks. --- It's worth noting that DNS is still a huge security hole in all of this. I don't see Webfinger mandating the use of DNSSEC, nor the methods by which to verify certificates, so no-one should be under the illusion that mandating HTTPS is going to lead to "secure" implementations. b. On 4 December 2012 16:04, Brad Fitzpatrick wrote: > +1 > > But I would also tolerate the alternative, requiring that clients provide > an HTTPS-only mode. > > > On Sun, Dec 2, 2012 at 5:15 PM, Tim Bray wrote: > >> Proposal: Change para 2 of section 5.2 to read as follows: >> >> Clients MUST query the server using HTTPS. If an HTTPS connection cannot >> be established, or returns an HTTP status code indicating some error, su= ch >> as 4xx or 5xx, the client MUST report an error and MUST cease attempting= to >> retrieve the resource. >> >> > --e89a8ff1c8620f6f8f04d00b6852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can I offer a compromise? I know the voice of small providers isn't ver= y welcome here, but I think it's (still) important. Examples like Githu= b Pages are relevant, whether those at organisations with large engineering= resources think so or not.

n.b. If someone on this list can convince Github to do the n= ecessary work=C2=A0(or even a clear commitment with a stated time-frame for= delivery)=C2=A0to have this ticket closed: http://www.mail-archiv= e.com/tor-bugs@lists.torproject.org/msg30067.html I'll totally resc= ind my concerns over this.

How about:

Clients MUST query the server= using HTTPS, obeying HSTS semantics.=C2=A0If an HTTPS connection has never been es= tablished, or returns an HTTP status code indicating some error, such as 4x= x or 5xx, absent HSTS headers, the client MAY attempt the same query using = HTTP.

... and then add something (e.= g. after =C2=A77) to the effect of:

---
Transport Security

It is advised that webfinger resources that are to be used for authenti= cation or verification purposes SHOULD use HTTPS, and HTTPS-enabled servers= SHOULD use HSTS to ensure that clients are not vulnerable to downgrade att= acks.
---

<= font face=3D"arial, sans-serif">It's worth noting that DNS is still a h= uge security hole in all of this. I don't see Webfinger mandating the u= se of DNSSEC, nor the methods by which to verify certificates, so no-one sh= ould be under the illusion that mandating HTTPS is going to lead to "s= ecure" implementations.

b.


<= div class=3D"gmail_quote">On 4 December 2012 16:04, Brad Fitzpatrick <br= adfitz@google.com> wrote:
+1

But I would also tolerate th= e alternative, requiring that clients provide an HTTPS-only mode.


On Sun, Dec 2, 2012 at 5:15 PM, Tim Bray= <tbray@textuality.com> wrote:
Proposal: Change para 2 of section 5.2 to re= ad as follows:

Clients MUST query the server using HTTPS. If an HTTP= S connection cannot be established, or returns an HTTP status code indicati= ng some error, such as 4xx or 5xx, the client MUST report an error and MUST= cease attempting to retrieve the resource.



--e89a8ff1c8620f6f8f04d00b6852-- From ve7jtb@ve7jtb.com Tue Dec 4 11:43:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E3921F8CA2 for ; Tue, 4 Dec 2012 11:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UaKi-k+8KpJ for ; Tue, 4 Dec 2012 11:43:26 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C86021F8C82 for ; Tue, 4 Dec 2012 11:43:26 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so4821438oag.31 for ; Tue, 04 Dec 2012 11:43:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=IuMiugISUD/kIVXSO8eqH8843kTVn3E0OaVesuIqKfE=; b=gvrjLKcAW2HB3tJnAwVqkie810CU5Tg4oo2ZV0ECjy4MMmL2AnBezNHrb7bl3e4LGU XYGG5w6WPaop5tCnYaDsIgu6QhpX/F/0yshw5mNVWmg/Eie/gnBWjt4RVWJUvfgqbReO KY0xvPXCkqmlpnASFLco6salGvLfGOAXqkS+fclDZPvlbLp19ir5C0BybEVN8VSWRG39 HrSxy6qACx3Iaa4scdU10RwSIYIiokiX7SItglZkVDpxM+la0V/EBngfpC6FYiVrA79q bUYmMGuR8FIthDxWtGpTN0UJWDlYroqUSJA2sOGxYyxvmQcqmwUYry2H+mBdeYAarsR7 PzSQ== Received: by 10.60.30.201 with SMTP id u9mr12868887oeh.28.1354650205505; Tue, 04 Dec 2012 11:43:25 -0800 (PST) Received: from [192.168.1.211] (190-20-2-238.baf.movistar.cl. [190.20.2.238]) by mx.google.com with ESMTPS id h2sm1641786obn.11.2012.12.04.11.43.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Dec 2012 11:43:24 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_700CAF26-BFC6-4BD9-9C4C-4E73D4D1A78B" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Tue, 4 Dec 2012 16:43:15 -0300 Message-Id: <8ADA643B-3CC7-43A8-9E51-A49BA30063F5@ve7jtb.com> References: To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkiKGHzT2fD2de9byGMhY78+45Tx9DfD3ns+SHpcWQJ8an8tXR69kd9jIJKjkXYhEjP4izt Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 19:43:27 -0000 --Apple-Mail=_700CAF26-BFC6-4BD9-9C4C-4E73D4D1A78B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii HSTS doesn't protect against a DNS attack before the client makes first = contact. It is intended to prevent leaking https: bound cookies after = the first contact. I don't think it helps us in any way. An attacker would redirect the = client to the fake site without HSTS before it makes the WF request. The certificate verification re RFC6125 per OAuth and other specs still = needs to be added, rather than just implied. =20 John B. On 2012-12-04, at 4:03 PM, Brad Fitzpatrick wrote: > On Tue, Dec 4, 2012 at 10:54 AM, Blaine Cook wrote: > and HTTPS-enabled servers SHOULD use HSTS to ensure that clients are = not vulnerable to downgrade attacks. >=20 > HSTS is a huge hammer and very few sites are prepared to enable it. I = don't think it should be a SHOULD, especially because webfinger shares = the same domain as other things on that host, and WebFinger's use of = HSTS would influence other paths on that host. (yes, I already hear the = arguments for a webfinger subdomain coming back) >=20 > It's worth noting that DNS is still a huge security hole in all of = this. I don't see Webfinger mandating the use of DNSSEC, nor the methods = by which to verify certificates, so no-one should be under the illusion = that mandating HTTPS is going to lead to "secure" implementations. >=20 > I believe verification of certs with root CAs was implicit. At least = that's what (almost?) all HTTP clients do by default anyway. --Apple-Mail=_700CAF26-BFC6-4BD9-9C4C-4E73D4D1A78B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii HSTS = doesn't protect against a DNS attack before the client makes first = contact.   It is intended to prevent leaking https: bound cookies = after the first contact.
I don't think it helps us in any way. =  An attacker would redirect the client to the fake site without = HSTS before it makes the WF request.

 
John = B.

On 2012-12-04, at 4:03 PM, Brad = Fitzpatrick <bradfitz@google.com> = wrote:

On Tue, Dec 4, 2012 at 10:54 AM, Blaine Cook <romeda@gmail.com> wrote:
and HTTPS-enabled servers SHOULD = use HSTS to ensure that clients are not vulnerable to downgrade = attacks.

HSTS is a huge hammer and very few = sites are prepared to enable it.  I don't think it should be a = SHOULD, especially because webfinger shares the same domain as other = things on that host, and WebFinger's use of HSTS would influence other = paths on that host.  (yes, I already hear the arguments for a = webfinger subdomain coming back)

It's worth noting that DNS is = still a huge security hole in all of this. I don't see Webfinger = mandating the use of DNSSEC, nor the methods by which to verify = certificates, so no-one should be under the illusion that mandating = HTTPS is going to lead to "secure" implementations.

I believe verification of certs with = root CAs was implicit.  At least that's what (almost?) all HTTP = clients do by default anyway.

= --Apple-Mail=_700CAF26-BFC6-4BD9-9C4C-4E73D4D1A78B-- From barryleiba.mailing.lists@gmail.com Tue Dec 4 11:54:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF34721F8C81 for ; Tue, 4 Dec 2012 11:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.046 X-Spam-Level: X-Spam-Status: No, score=-103.046 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qx-plvJT8b2 for ; Tue, 4 Dec 2012 11:54:16 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E90621F8C53 for ; Tue, 4 Dec 2012 11:54:15 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3830071lbk.31 for ; Tue, 04 Dec 2012 11:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=0wWcfgl0wlLuxzUmRmM/LWJ+D3dqA6SvRLyRijThggw=; b=o7nQRpCshtCCR2OJp3YtEr0ze2UxkXbMKpRaUtz4adb+Fb5LVse6j/UOGJ3Ch5tJ1T LGJu8wnRt+LWT8tJtbSwD0zzpyHkFmonfCnjplow3XW2XKvHaHLip7uuE4rpGfAIyBIW ZJX4ZQG8IPMQdTWzXWItC6mv8W1guCuBCM/Ta5XiLkzOxKPP+ZFOq8wxLfmjyZ7vEjRR y1/H4Cr+KkWVzN/t+xJS9IkkrmTl9BQw1P4hJ9YNXfAI0gPXKXcjopXlH2Sc443XuBj9 jPFVByOv6ZPNrrHpNXNHWTNev5Y1XfvLG6twg7KC6JuDG61/e9RyuUK0Tf/yvdmFzqu8 1LQg== MIME-Version: 1.0 Received: by 10.152.114.100 with SMTP id jf4mr14280188lab.47.1354650854581; Tue, 04 Dec 2012 11:54:14 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Tue, 4 Dec 2012 11:54:14 -0800 (PST) Date: Tue, 4 Dec 2012 14:54:14 -0500 X-Google-Sender-Auth: _VGratEmbVeaXQYP3a6utPNujjo Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] IMPORTANT: webfinger@ietf.org mailing list has been created X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 19:54:17 -0000 The subject mailing list has been created, and anyone interested in continuing the webfinger discussion should subscribe to that list tout de suite, here: https://www.ietf.org/mailman/listinfo/webfinger *** Please immediately start replacing with when you reply to existing webfinger discussions. *** I know that I'm asking you to take an extra step when you reply, but please do your best to remember to do it -- it's the only way we'll get the discussion moved over there. Barry, App AD From randall.leeds@gmail.com Tue Dec 4 12:07:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D948821F8CBF for ; Tue, 4 Dec 2012 12:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD3NG8AUJOx9 for ; Tue, 4 Dec 2012 12:07:10 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B23C021F8C27 for ; Tue, 4 Dec 2012 12:07:01 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so4849485oag.31 for ; Tue, 04 Dec 2012 12:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lXA0vC0JXCoDxmthv9vjV1eI7fgJsHJ8iVCaNrkd720=; b=yEoO7KtrQP/ENvtB98ZnOOgbEjKxfZxajw99CTZgEm1yYeTE14d94OOJfPBUlCLICH HLSAcw5emHwzkGMO6YdZG/w6Bk52tEYBbdaqgKKf/ZX/fJ8gM/pr+6V+lv/RAEAhxUgj rn3dH37gEPmiiIkSjPx86crUirIf2saoHHtl8XL7PKPoIwdLZIhxDqBfbFc/OlkoDQGT V4FJuHH8mtaNuhR0+kF2jHWonsJ0dgdJcbghQam9NGkBaX6Tnm62h57nmQiH6H1Qrstf o6c24gML0Nip95CkX9tzkqo0fWPkjgNpBssJCtw1qL8/30dil/OMDlfB6FqbIYdpfKgG ODdQ== MIME-Version: 1.0 Received: by 10.182.53.3 with SMTP id x3mr8856452obo.87.1354651621319; Tue, 04 Dec 2012 12:07:01 -0800 (PST) Received: by 10.76.21.6 with HTTP; Tue, 4 Dec 2012 12:07:01 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Dec 2012 12:07:01 -0800 Message-ID: From: Randall Leeds To: Blaine Cook Content-Type: multipart/alternative; boundary=f46d044630a0aee4a004d00c68e0 Cc: webfinger@googlegroups.com, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 20:07:15 -0000 --f46d044630a0aee4a004d00c68e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 4, 2012 at 10:54 AM, Blaine Cook wrote: > How about: > > Clients MUST query the server using HTTPS, obeying HSTS semantics. If an > HTTPS connection has never been established, or returns an HTTP status co= de > indicating some error, such as 4xx or 5xx, absent HSTS headers, the clien= t > MAY attempt the same query using HTTP. > > ... and then add something (e.g. after =C2=A77) to the effect of: > > --- > Transport Security > > It is advised that webfinger resources that are to be used for > authentication or verification purposes SHOULD use HTTPS, and HTTPS-enabl= ed > servers SHOULD use HSTS to ensure that clients are not vulnerable to > downgrade attacks. > +1. I've been lurking this discussion for a while, trying to ascertain where I might contribute and I'd like to chime in to say that this language makes sense to me. As has been repeated many times, an implementor can *always* break spec. Providing recommendations around fallbacks and client API requirements just doesn't seem worth the words. In the end, the communities of practice will decide what becomes common use.* > --- > > It's worth noting that DNS is still a huge security hole in all of this. = I > don't see Webfinger mandating the use of DNSSEC, nor the methods by which > to verify certificates, so no-one should be under the illusion that > mandating HTTPS is going to lead to "secure" implementations. > If it's worth noting, then I'd say note it in the spec. Again, I think it's good to cover the issues, but not mandate what anyone should do with that information. It seems clear to me that there are a range of security concerns around, from zero concerns, trusted links and hosts, all the way to DNSSEC. If WebFinger will serve all of these uses then I feel that it shouldn't try to over-specify these issues. Please, correct me if I'm missing something; many in this discussion seem to have much more spec-writing experience and security knowledge than I. -- * For example, I might expect some kind of OpenID Connect consumer library to enforce a strict HTTPS-only policy when looking up the IdP (or decide to offer a fallback parameter in its API), but that's completely up to those implementors. Similarly, a provider of WebFinger resources might redirect HTTP to HTTPS+HSTS if it feels strongly that this would protect its users from phishing or some such threat. Market pressure should dictate that identity providers make a best effort at ensuring their WebFinger resources are difficult to impersonate successfully. --f46d044630a0aee4a004d00c68e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 4, 2012 a= t 10:54 AM, Blaine Cook <romeda@gmail.com> wrote:
How about:

Clients MUST query the server using HTTPS, o= beying HSTS semantics.=C2=A0If an HTTPS connection has never been established, or r= eturns an HTTP status code indicating some error, such as 4xx or 5xx, absen= t HSTS headers, the client MAY attempt the same query using HTTP.

... and then add something (e.= g. after =C2=A77) to the effect of:

---
Transport Security

It is advised that webfinger resources that are to be used for authenti= cation or verification purposes SHOULD use HTTPS, and HTTPS-enabled servers= SHOULD use HSTS to ensure that clients are not vulnerable to downgrade att= acks.

+1.

I've been lurking this discussio= n for a while, trying to ascertain where I might contribute and I'd lik= e to chime in to say that this language makes sense to me.

As has be= en repeated many times, an implementor can *always* break spec. Providing r= ecommendations around fallbacks and client API requirements just doesn'= t seem worth the words. In the end, the communities of practice will decide= what becomes common use.*
=C2=A0
---

<= font face=3D"arial, sans-serif">It's worth noting that DNS is still a h= uge security hole in all of this. I don't see Webfinger mandating the u= se of DNSSEC, nor the methods by which to verify certificates, so no-one sh= ould be under the illusion that mandating HTTPS is going to lead to "s= ecure" implementations.

If it's worth noting, then I'd say note= it in the spec. Again, I think it's good to cover the issues, but not = mandate what anyone should do with that information. It seems clear to me t= hat there are a range of security concerns around, from zero concerns, trus= ted links and hosts, all the way to DNSSEC. If WebFinger will serve all of = these uses then I feel that it shouldn't try to over-specify these issu= es.

Please, correct me if I'm missing something; many in this discussio= n seem to have much more spec-writing experience and security knowledge tha= n I.

--

* For example, I might expect some kind of OpenID Con= nect consumer library to enforce a strict HTTPS-only policy when looking up the IdP (or=20 decide to offer a fallback parameter in its API), but that's completely= =20 up to those implementors. Similarly, a provider of WebFinger resources=20 might redirect HTTP to HTTPS+HSTS if it feels strongly that this would=20 protect its users from phishing or some such threat. Market pressure=20 should dictate that identity providers make a best effort at ensuring=20 their WebFinger resources are difficult to impersonate successfully.
<= /div>
--f46d044630a0aee4a004d00c68e0-- From internet-drafts@ietf.org Tue Dec 4 16:42:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79F921F8BE9; Tue, 4 Dec 2012 16:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfvffTV68s16; Tue, 4 Dec 2012 16:42:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD2721F8BDC; Tue, 4 Dec 2012 16:42:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121205004222.5427.95750.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2012 16:42:22 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 00:42:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Pointer Author(s) : Paul C. Bryan Kris Zyp Mark Nottingham Filename : draft-ietf-appsawg-json-pointer-06.txt Pages : 8 Date : 2012-12-04 Abstract: JSON Pointer defines a string syntax for identifying a specific value within a JSON document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-pointer-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Dec 4 16:42:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460D221F8BF6; Tue, 4 Dec 2012 16:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPSagHb5JIBc; Tue, 4 Dec 2012 16:42:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4325721F8BF4; Tue, 4 Dec 2012 16:42:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121205004238.21724.66135.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2012 16:42:38 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 00:42:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Patch Author(s) : Paul C. Bryan Mark Nottingham Filename : draft-ietf-appsawg-json-patch-07.txt Pages : 16 Date : 2012-12-04 Abstract: JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mnot@mnot.net Tue Dec 4 16:52:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EE021F8BB4 for ; Tue, 4 Dec 2012 16:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.067 X-Spam-Level: X-Spam-Status: No, score=-104.067 tagged_above=-999 required=5 tests=[AWL=-1.468, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTOrWTgDJ-jp for ; Tue, 4 Dec 2012 16:52:27 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id AE97D21F8BB2 for ; Tue, 4 Dec 2012 16:52:27 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AB773509B5 for ; Tue, 4 Dec 2012 19:52:26 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <20121205004222.5427.95750.idtracker@ietfa.amsl.com> Date: Wed, 5 Dec 2012 11:52:31 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <931DFB08-6300-41CA-9269-2B5E0AFEB9D7@mnot.net> References: <20121205004222.5427.95750.idtracker@ietfa.amsl.com> To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1499) Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 00:52:28 -0000 Very small changes here based upon LC feedback; nothing to see, move = along. On 05/12/2012, at 11:42 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Applications Area Working Group = Working Group of the IETF. >=20 > Title : JSON Pointer > Author(s) : Paul C. Bryan > Kris Zyp > Mark Nottingham > Filename : draft-ietf-appsawg-json-pointer-06.txt > Pages : 8 > Date : 2012-12-04 >=20 > Abstract: > JSON Pointer defines a string syntax for identifying a specific = value > within a JSON document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-pointer-06 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Dec 4 16:53:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1676321F8BB4 for ; Tue, 4 Dec 2012 16:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.012 X-Spam-Level: X-Spam-Status: No, score=-104.012 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdJ5Pz5UAs+H for ; Tue, 4 Dec 2012 16:53:20 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 62C6F21F8BB2 for ; Tue, 4 Dec 2012 16:53:20 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8AB7E509B5 for ; Tue, 4 Dec 2012 19:53:19 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <20121205004238.21724.66135.idtracker@ietfa.amsl.com> Date: Wed, 5 Dec 2012 11:53:24 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E049FE5-FCD8-4DDE-B0B2-AB7D7720303F@mnot.net> References: <20121205004238.21724.66135.idtracker@ietfa.amsl.com> To: Apps Discuss X-Mailer: Apple Mail (2.1499) Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 00:53:21 -0000 Fairly substantial changes based upon LC feedback; in particular, on = "move" and "copy", "to" is now "from", and much of the text has been = simplified. I've also put all of the examples into the test suite: https://github.com/json-patch/json-patch-tests Cheers, On 05/12/2012, at 11:42 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Applications Area Working Group = Working Group of the IETF. >=20 > Title : JSON Patch > Author(s) : Paul C. Bryan > Mark Nottingham > Filename : draft-ietf-appsawg-json-patch-07.txt > Pages : 16 > Date : 2012-12-04 >=20 > Abstract: > JSON Patch defines the media type "application/json-patch", a JSON > document structure for expressing a sequence of operations to apply > to a JSON document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Tue Dec 4 18:37:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371DB21F8BF4 for ; Tue, 4 Dec 2012 18:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_54=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZISkz-NsAH7 for ; Tue, 4 Dec 2012 18:37:02 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 241DD21F860F for ; Tue, 4 Dec 2012 18:37:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,375,1352034000"; d="scan'208";a="106728153" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 05 Dec 2012 13:36:59 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6916"; a="100677405" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcbvi.tcif.telstra.com.au with ESMTP; 05 Dec 2012 13:36:59 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Wed, 5 Dec 2012 13:36:58 +1100 From: "Manger, James H" To: Mark Nottingham , Apps Discuss Date: Wed, 5 Dec 2012 13:36:56 +1100 Thread-Topic: json-patch-tests errors Thread-Index: Ac3Sgu8Hn4uSmIThSO+QfVJzybac2AACdjxQ Message-ID: <255B9BB34FB7D647A506DC292726F6E11502A39E1D@WSMSG3153V.srv.dir.telstra.com> References: <20121205004238.21724.66135.idtracker@ietfa.amsl.com> <5E049FE5-FCD8-4DDE-B0B2-AB7D7720303F@mnot.net> In-Reply-To: <5E049FE5-FCD8-4DDE-B0B2-AB7D7720303F@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] json-patch-tests errors X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 02:37:04 -0000 PiBJJ3ZlIGFsc28gcHV0IGFsbCBvZiB0aGUgZXhhbXBsZXMgaW50byB0aGUgdGVzdCBzdWl0ZToN Cj4gICBodHRwczovL2dpdGh1Yi5jb20vanNvbi1wYXRjaC9qc29uLXBhdGNoLXRlc3RzDQoNCjxo dHRwczovL2dpdGh1Yi5jb20vanNvbi1wYXRjaC9qc29uLXBhdGNoLXRlc3RzL2Jsb2IvbWFzdGVy L3NwZWNfdGVzdHMuanNvbj4NCnNwZWNfdGVzdHMuanNvbiBsb29rcyByaWdodC4NCg0KPGh0dHBz Oi8vZ2l0aHViLmNvbS9qc29uLXBhdGNoL2pzb24tcGF0Y2gtdGVzdHMvYmxvYi9tYXN0ZXIvc2lt cGxleG1sX3Rlc3RzLmpzb24+DQo0IG9mIHRoZSA1IHRlc3RzIGluIHNpbXBsZXhtbF90ZXN0cy5q c29uIGxvb2sgd3JvbmcuDQpUaGUgdGVzdHMgc2VlbSB0byByZWx5IG9uIHNvbWUgc29ydCBvZiBh dXRvbWFnaWMgZXF1aXZhbGVuY2UgYmV0d2VlbiBhIHZhbHVlIGFuZCBhIDEtaXRlbSBhcnJheSB3 aXRoIGp1c3QgdGhhdCB2YWx1ZSAoZWcgYmV0d2VlbiB7ImZvbyI6MX0gYW5kIHsiZm9vIjpbMV19 KS4NClBlcmhhcHMgdGhlc2UgdGVzdHMgYXJlIHJlbGF0ZWQgdG8gc29tZXRoaW5nIG90aGVyIHRo YW4gZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcGF0Y2guDQoNCjxodHRwczovL2dpdGh1Yi5jb20v anNvbi1wYXRjaC9qc29uLXBhdGNoLXRlc3RzL2Jsb2IvbWFzdGVyL3Rlc3RzLmpzb24+DQp0ZXN0 cy5qc29uIGhhcyBzb21lIGVycm9ycy4NCg0KV1JPTkcNCiAgIHsgImNvbW1lbnQiOiAiYWRkIHRv IGV4aXN0aW5nIG51bGwtdmFsdWVkIGZpZWxkIHNob3VsZCBlcnIiLA0KICAgICAgImRvYyI6IHsi Zm9vIjogbnVsbH0sDQogICAgICAicGF0Y2giOiBbeyJvcCI6ICJhZGQiLCAicGF0aCI6ICIvZm9v IiwgInZhbHVlIjoxfV0sDQogICAgICAiZXJyb3IiOiAiJ2FkZCcgdGFyZ2V0IGFscmVhZHkgc2V0 IiB9LA0KUklHSFQNCiAgIHsgImNvbW1lbnQiOiAiYWRkIHJlcGxhY2VzIGFueSBleGlzdGluZyBm aWVsZCIsDQogICAgICAiZG9jIjogeyJmb28iOiBudWxsfSwNCiAgICAgICJwYXRjaCI6IFt7Im9w IjogImFkZCIsICJwYXRoIjogIi9mb28iLCAidmFsdWUiOjF9XSwNCiAgICAgICJleHBlY3RlZCI6 IHsiZm9vIjogMX0gfSwNCg0KV1JPTkcNCiAgIHsgImRvYyI6IHsiZm9vIjogMX0sDQogICAgICAi cGF0Y2giOiBbeyJvcCI6ICJhZGQiLCAicGF0aCI6ICIvMCIsICJ2YWx1ZSI6ICJiYXIifV0sDQog ICAgICAiZXJyb3IiOiAiQXJyYXkgb3BlcmF0aW9uIG9uIG9iamVjdCB0YXJnZXQiIH0sDQpSSUdI VA0KICAgeyAiY29tbWVudCI6ICIwIGNhbiBiZSBhbiBhcnJheSBpbmRleCBvciBvYmplY3QgZWxl bWVudCBuYW1lIiwNCiAgICAgICJkb2MiOiB7ImZvbyI6IDF9LA0KICAgICAgInBhdGNoIjogW3si b3AiOiAiYWRkIiwgInBhdGgiOiAiLzAiLCAidmFsdWUiOiAiYmFyIn1dLA0KICAgICAgImV4cGVj dGVkIjogeyJmb28iOiAxLCAiMCI6ICJiYXIiIH0sDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From mnot@mnot.net Tue Dec 4 19:06:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5530821F8BFA for ; Tue, 4 Dec 2012 19:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.662 X-Spam-Level: X-Spam-Status: No, score=-103.662 tagged_above=-999 required=5 tests=[AWL=-1.663, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cykycaS9N3Lm for ; Tue, 4 Dec 2012 19:06:46 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B806021F8BB4 for ; Tue, 4 Dec 2012 19:06:46 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 796E7509B9; Tue, 4 Dec 2012 22:06:44 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11502A39E1D@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 5 Dec 2012 14:06:52 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <290B023C-E3C9-427D-A23F-D85ABE8206EB@mnot.net> References: <20121205004238.21724.66135.idtracker@ietfa.amsl.com> <5E049FE5-FCD8-4DDE-B0B2-AB7D7720303F@mnot.net> <255B9BB34FB7D647A506DC292726F6E11502A39E1D@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: Apps Discuss Subject: Re: [apps-discuss] json-patch-tests errors X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 03:06:47 -0000 Hi James, Thanks for that. Those tests were sourced from some earlier = implementations.=20 I think the best way to move them forward would be to raise issues in = github -- do you mind doing that? Cheers, On 05/12/2012, at 1:36 PM, "Manger, James H" = wrote: >> I've also put all of the examples into the test suite: >> https://github.com/json-patch/json-patch-tests >=20 > = > spec_tests.json looks right. >=20 > = > 4 of the 5 tests in simplexml_tests.json look wrong. > The tests seem to rely on some sort of automagic equivalence between a = value and a 1-item array with just that value (eg between {"foo":1} and = {"foo":[1]}). > Perhaps these tests are related to something other than = draft-ietf-appsawg-json-patch. >=20 > = > tests.json has some errors. >=20 > WRONG > { "comment": "add to existing null-valued field should err", > "doc": {"foo": null}, > "patch": [{"op": "add", "path": "/foo", "value":1}], > "error": "'add' target already set" }, > RIGHT > { "comment": "add replaces any existing field", > "doc": {"foo": null}, > "patch": [{"op": "add", "path": "/foo", "value":1}], > "expected": {"foo": 1} }, >=20 > WRONG > { "doc": {"foo": 1}, > "patch": [{"op": "add", "path": "/0", "value": "bar"}], > "error": "Array operation on object target" }, > RIGHT > { "comment": "0 can be an array index or object element name", > "doc": {"foo": 1}, > "patch": [{"op": "add", "path": "/0", "value": "bar"}], > "expected": {"foo": 1, "0": "bar" }, >=20 > -- > James Manger -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Tue Dec 4 19:20:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCEA21F8AA2 for ; Tue, 4 Dec 2012 19:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.764 X-Spam-Level: X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RpNroLKOlV6 for ; Tue, 4 Dec 2012 19:20:20 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9780F21F8A84 for ; Tue, 4 Dec 2012 19:20:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,375,1352034000"; d="scan'208";a="112334513" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 05 Dec 2012 14:20:17 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6916"; a="50376925" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcani.tcif.telstra.com.au with ESMTP; 05 Dec 2012 14:20:17 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 5 Dec 2012 14:20:17 +1100 From: "Manger, James H" To: Mark Nottingham , "apps-discuss@ietf.org Discuss" Date: Wed, 5 Dec 2012 14:20:16 +1100 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt Thread-Index: Ac3Sgs/wZKUGH5VsR1ywXV/KKNuRggADpsgA Message-ID: <255B9BB34FB7D647A506DC292726F6E11502A39F2F@WSMSG3153V.srv.dir.telstra.com> References: <20121205004222.5427.95750.idtracker@ietfa.amsl.com> <931DFB08-6300-41CA-9269-2B5E0AFEB9D7@mnot.net> In-Reply-To: <931DFB08-6300-41CA-9269-2B5E0AFEB9D7@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 03:20:20 -0000 PiBWZXJ5IHNtYWxsIGNoYW5nZXMgaGVyZSBiYXNlZCB1cG9uIExDIGZlZWRiYWNrOyBub3RoaW5n IHRvIHNlZSwgbW92ZQ0KPiBhbG9uZy4NCg0KSSBub3RpY2VkIGEgYnVnIGluIGFuIGltcGxlbWVu dGF0aW9uIGxpc3RlZCBhdCBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9hcHBzYXdnL3Ry YWMvd2lraS9Kc29uUGF0Y2g6IHVuZXNjYXBpbmcgfjAgdG8gfiwgYmVmb3JlIHVuZXNjYXBpbmcg fjEgdG8gLyAoc28gYSB+IGZyb20gdGhlIGZpcnN0IHVuZXNjYXBpbmcgaXMgbWlzdGFrZW5seSB0 cmVhdGVkIGFzIGFuIGVzY2FwZSBjaGFyYWN0ZXIgaW4gdGhlIHNlY29uZCB1bmVzY2FwaW5nKS4N Ckl0IGlzIGEgYnVnIHRoYXQgY291bGQgZWFzaWx5IGJlIHJlcGVhdGVkIHNvIG9uZSBtb3JlIGV4 YW1wbGUgaW4gZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcG9pbnRlciB0byBjb3ZlciB0aGlzIGNh c2Ugd291bGQgYmUgd29ydGh3aGlsZS4NCg0KSW4gc2VjdGlvbiA1ICJKU09OIFN0cmluZyBSZXBy ZXNlbnRhdGlvbiIgYWRkOg0KDQpHaXZlbiB0aGUgSlNPTiBkb2M6DQogIHsgIi8iOiA5LA0KICAg In4xIjogMTAgfQ0KQSBwb2ludGVyIChhcyBhIEpTT04gc3RyaW5nKSBhbmQgdmFsdWUgaXM6DQog ICIvfjAxIiAgMTANCg0KDQpJbiB0aGUgZm9ybWF0IG9mIGh0dHBzOi8vZ2l0aHViLmNvbS9qc29u LXBhdGNoL2pzb24tcGF0Y2gtdGVzdHMNCiAgIHsgImNvbW1lbnQiOiAiZG9uJ3QgdW5lc2NhcGUg fjAgc2VwYXJhdGVseSBiZWZvcmUgdW5lc2NhcGluZyB+MSIsDQogICAgICAiZG9jIjogew0KICAg ICAgICAgICIvIjogOSwNCiAgICAgICAgICAifjEiOiAxMCB9LA0KICAgICAgInBhdGNoIjogW3si b3AiOiAidGVzdCIsICJwYXRoIjogIi9+MDEiLCAidmFsdWUiOjEwfV0gfSwNCg0KPiBJIHRoaW5r IHRoZSBiZXN0IHdheSB0byBtb3ZlIHRoZW0gZm9yd2FyZCB3b3VsZCBiZSB0byByYWlzZSBpc3N1 ZXMgaW4gZ2l0aHViIC0tIGRvIHlvdSBtaW5kIGRvaW5nIHRoYXQ/DQoNCkRPTkUNCg0KDQpJIGFs c28gbm90aWNlZCBhIGZldyBpbXBsZW1lbnRhdGlvbnMganVzdCB1c2UgSmF2YVNjcmlwdOKAmXMg cGFyc2VJbnQoKSBmdW5jdGlvbiB0byBjb252ZXJ0IGEgc2VnbWVudCBpbiBhIEpTT04gcG9pbnRl ciAoYSA8cmVmZXJlbmNlLXRva2VuPikgdG8gYW4gaW50ZWdlciBhcnJheSBpbmRleC4gSGVuY2Us IHRoZXkgYWNjZXB0ICIvMDA3IiBhbmQgIi8gICswMDA3enp6IiBhcyBlcXVpdmFsZW50IHRvICIv NyIuIFl1Y2suIFBlcmhhcHMgYWRkIGV4YW1wbGVzIHRvIHRoZSBzcGVjIHRvIGV4cGxpY2l0bHkg c2hvdyB0aGVzZSBhcmUgZXJyb3JzIChzbyB0aGV5IG1ha2UgaXQgaW50byB0ZXN0cyk/DQoNCi0t DQpKYW1lcyBNYW5nZXINCg== From mccabe@archive.org Tue Dec 4 21:27:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5700321F8C1A for ; Tue, 4 Dec 2012 21:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6sOThC9OkMI for ; Tue, 4 Dec 2012 21:27:31 -0800 (PST) Received: from mail.archive.org (mail.us.archive.org [207.241.224.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE5121F85A5 for ; Tue, 4 Dec 2012 21:27:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.archive.org (Postfix) with ESMTP id 6155968401CD; Tue, 4 Dec 2012 21:27:30 -0800 (PST) Received: from mail.archive.org ([127.0.0.1]) by localhost (mail.archive.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WkwZdjwC9Pak; Tue, 4 Dec 2012 21:27:23 -0800 (PST) Received: from Mikes-MacBook-Air.local (208-90-212-115.PUBLIC.monkeybrains.net [208.90.212.115]) by mail.archive.org (Postfix) with ESMTPSA id 0E6F768401D5; Tue, 4 Dec 2012 21:27:22 -0800 (PST) Message-ID: <50BEDB31.4030507@archive.org> Date: Tue, 04 Dec 2012 21:27:13 -0800 From: Mike McCabe User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20121205004238.21724.66135.idtracker@ietfa.amsl.com> <5E049FE5-FCD8-4DDE-B0B2-AB7D7720303F@mnot.net> <255B9BB34FB7D647A506DC292726F6E11502A39E1D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11502A39E1D@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] json-patch-tests errors X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 05:27:32 -0000 James - Thanks for your comments. Currently, json-patch-tests is out of date and will need review - thanks for creating the github issues. You're right - simplexml_tests.json is for implementation-specific sematics that are different than json-patch. I'll remove it. Regards, Mike On 12/4/12 6:36 PM, Manger, James H wrote: > > 4 of the 5 tests in simplexml_tests.json look wrong. > The tests seem to rely on some sort of automagic equivalence between a value and a 1-item array with just that value (eg between {"foo":1} and {"foo":[1]}). > Perhaps these tests are related to something other than draft-ietf-appsawg-json-patch. From markus.lanthaler@gmx.net Wed Dec 5 01:41:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D0621F8C17 for ; Wed, 5 Dec 2012 01:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0NlpRy9tONG for ; Wed, 5 Dec 2012 01:41:03 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 544B021F8C9E for ; Wed, 5 Dec 2012 01:41:03 -0800 (PST) Received: (qmail invoked by alias); 05 Dec 2012 09:41:01 -0000 Received: from unknown (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp041) with SMTP; 05 Dec 2012 10:41:01 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18/aTURMDw/pRSVnSRMEcOQRpPLfSy1885kInXNhX ZZM69DqsQwv94o From: "Markus Lanthaler" To: References: <20121205004222.5427.95750.idtracker@ietfa.amsl.com> In-Reply-To: <20121205004222.5427.95750.idtracker@ietfa.amsl.com> Date: Wed, 5 Dec 2012 10:40:58 +0100 Message-ID: <00b201cdd2cc$a20bdc20$e6239460$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3SgWYm7VZmpvPTT2qNygOewNIpeQASmqmw Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 09:41:04 -0000 Hi, this probably something that has been asked before but I couldn't find anything relevant. How does JSON Pointer distinguish between objects and arrays? E.g. consider the following JSON document: { "foo": "bar", "1": "baz" } As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even though that's probably not what the author intended. Is there are way to avoid that? Thanks, Markus -- Markus Lanthaler @markuslanthaler > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, December 05, 2012 1:42 AM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer- > 06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group > Working Group of the IETF. > > Title : JSON Pointer > Author(s) : Paul C. Bryan > Kris Zyp > Mark Nottingham > Filename : draft-ietf-appsawg-json-pointer-06.txt > Pages : 8 > Date : 2012-12-04 > > Abstract: > JSON Pointer defines a string syntax for identifying a specific > value > within a JSON document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-pointer-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From bradfitz@google.com Tue Dec 4 08:04:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67321F8C3F for ; Tue, 4 Dec 2012 08:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC+firCD5MIQ for ; Tue, 4 Dec 2012 08:04:45 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5478021F8C33 for ; Tue, 4 Dec 2012 08:04:45 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so816162wib.13 for ; Tue, 04 Dec 2012 08:04:44 -0800 (PST) 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=IgDJaKKzFNmZpl1UFuRt71Cm2pW3hpWyQ3IZ/RGJ9OM=; b=hY0/uEpsODtrs+2+NBDVe8QwDkv8lXCaoPFqIEDSZ/txLm8jWk0WK2S8+mqkIWmVSy cUufEL7HYnNv0WjrmGStWTXYZPMchFQNVOb0I2FDx4cXs6MaIZ3RpaD9mddqYst0rhNf pDWGLAP0vZSRoYkJyZn4fOr+VMDG6PkqXI1S0gztEBdEbqoiNGpGAuwaizrve9qqshuJ WMjDEm33RrFTe01MdwNnTf1e8LqtGMJke++GitlJwDcR6uEdWHTobN71zPu7sZu9A3fY u/qZQWMZWGBx21XVJNmEkuYSLCBBnVyVZEK09l8uW19wqRoQhdaVxJazzf+uQCONe457 beug== X-Google-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:x-gm-message-state; bh=IgDJaKKzFNmZpl1UFuRt71Cm2pW3hpWyQ3IZ/RGJ9OM=; b=I+HQj2bnm1jkWYmKAKsnjo04xgbUx6YC8anILlw3TWyeXsIq3KUOZ8u5KW1HQ7mN4P JPIL6X9kyXF+nDpXXptvD+JRSiVcgUlm4X+UuNkqQbZXxWNFDEQGp9/hTtXx61QQfs9s +xGDjbjsYpFfkziwg/odnbfIcTdk/uOesMipnTaPqTwsPEQEKjKbAfkYyx8V7JqGEroi XnHrwKE8Jgrr+462b65TzbjAp64yKBdYko9YUN9oda0wigOzZnoqwlWjdx8Ac3vOcRHj h0n3LzCd9udo3hTEvhPdN5DuHsps++ohyDE1xwpvr9fhBUaRAOEISb2vQm3CbKGEV8MH VDug== MIME-Version: 1.0 Received: by 10.180.87.39 with SMTP id u7mr5370905wiz.6.1354637084394; Tue, 04 Dec 2012 08:04:44 -0800 (PST) Received: by 10.194.166.100 with HTTP; Tue, 4 Dec 2012 08:04:44 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Dec 2012 08:04:44 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d044280f83703b304d00906ae X-Gm-Message-State: ALoCoQkdcRVAusiuzJ3WuqMCw2ktULMfwst1rax8RmZc9aVkrDhpARW4N9jFTsqVPAu2RNTQpoprTIZkrW5IVhlC4Y3fLV4HZ8FwuKzpvKfy9fWyGP4rSgF1UZlEl1DwBintTwvp/v3d4jw06P2F43n7r1uuhHM4qP9szqpbM1q6HFbXMwzX4urQtZKp0MLFczDka5ZJK5v5 X-Mailman-Approved-At: Wed, 05 Dec 2012 08:08:12 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 16:04:46 -0000 --f46d044280f83703b304d00906ae Content-Type: text/plain; charset=UTF-8 +1 But I would also tolerate the alternative, requiring that clients provide an HTTPS-only mode. On Sun, Dec 2, 2012 at 5:15 PM, Tim Bray wrote: > Proposal: Change para 2 of section 5.2 to read as follows: > > Clients MUST query the server using HTTPS. If an HTTPS connection cannot > be established, or returns an HTTP status code indicating some error, such > as 4xx or 5xx, the client MUST report an error and MUST cease attempting to > retrieve the resource. > > --f46d044280f83703b304d00906ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+= 1

But I would also tolerate the alternative, requiring t= hat clients provide an HTTPS-only mode.

O= n Sun, Dec 2, 2012 at 5:15 PM, Tim Bray <tbray@textuality.com> wrote:
Proposal: Change para 2 of section 5.2 to re= ad as follows:

Clients MUST query the server using HTTPS. If an HTTP= S connection cannot be established, or returns an HTTP status code indicati= ng some error, such as 4xx or 5xx, the client MUST report an error and MUST= cease attempting to retrieve the resource.


--f46d044280f83703b304d00906ae-- From bradfitz@google.com Tue Dec 4 11:03:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B21221F8CAE for ; Tue, 4 Dec 2012 11:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb5xH2Ng32Nj for ; Tue, 4 Dec 2012 11:03:48 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD1521F8AD9 for ; Tue, 4 Dec 2012 11:03:48 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1907697wey.31 for ; Tue, 04 Dec 2012 11:03:47 -0800 (PST) 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=ypq+Fei6TDyI0suga5UJ75r0gKKMbHwpH9knWtI6h3g=; b=BV/P6z76qr07e3bdJ/B+Wzl3TRbXzE6WwtzoUby11vlWm55hVoqLn9slV6AQiZJDAK 9f1n5kC9g2mjdqI2cunvK4ZsQn0TjSE7NUcFTpYHwbN0ZEqs1pxZnMAcV/fqL1sPLaIW GfsNMd2bq9/gId/tmL4y/EHlZsRpqWwVXGoNvoiy1XLKB5XB2/EEXKqY3YwAyEuAVwnI uvi8Vhn1w2IbK/1SRkCDUibHb4a00c03KVbrMnX4aRwFx0eo+8RraELqXH8vMtXIiq5T /hIzgB9Pv4aXy/P2rxcZVnssBg2jUH38A/je+Mj4USS9aUKlbJ+5C9ukm3zPbricijn+ PFyA== X-Google-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:x-gm-message-state; bh=ypq+Fei6TDyI0suga5UJ75r0gKKMbHwpH9knWtI6h3g=; b=kQ0YtOcxFdf6xOqVSGh+/4m4ve+wH+3gq6Dp1n4GNblt2yQ1XaEpZF0RzIACRnrooY 9cix9sc4jvoDERQOhuK6cVq0GkIyOcU+fXVBl+V5iKQfCDp1PcpwR88EYckF1oXzVwAd BpkAXrUExxhT236l+OZzzM4iYV5nhC993dxuCVDcIfBO2LbpZ4n3haBknu4YN0K/qTCr QKu3CSoLI+FP/WgC2f8oVoyIBjQjtcK+Z1Gyw50KfSKrWdfcc8v9ME6lv4f5eX/QycnR 02a5+XF0VJiOwjTA7wmnhPptp4rojRkCVpLAGZyYUVoIF1aqfeH0zND5eZle0EHFrv/Z wtIQ== MIME-Version: 1.0 Received: by 10.216.140.19 with SMTP id d19mr5767558wej.34.1354647827104; Tue, 04 Dec 2012 11:03:47 -0800 (PST) Received: by 10.194.166.100 with HTTP; Tue, 4 Dec 2012 11:03:47 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Dec 2012 11:03:47 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=0016e6dee6e887c51d04d00b860a X-Gm-Message-State: ALoCoQn1n4hCYg5qvJ/EEPy1XHjROVqK7hvw8mFyFiT7UOKm+uDejd1qtfrfUJWEyTZ6R5HTSYItVdtj7geNiRyRrTvYmlaWYxAWA82AJNXcF3Bn/Al3mKrWXMO1b9SEd5Gq+vOdrSBdnNeHSnI8lddsnR217gkoXdkre3UI4o9fXlZT1zf4tqhqkCkAbEbAzmYXoBTTweyx X-Mailman-Approved-At: Wed, 05 Dec 2012 08:08:29 -0800 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 19:03:49 -0000 --0016e6dee6e887c51d04d00b860a Content-Type: text/plain; charset=UTF-8 On Tue, Dec 4, 2012 at 10:54 AM, Blaine Cook wrote: > and HTTPS-enabled servers SHOULD use HSTS to ensure that clients are not > vulnerable to downgrade attacks. > HSTS is a huge hammer and very few sites are prepared to enable it. I don't think it should be a SHOULD, especially because webfinger shares the same domain as other things on that host, and WebFinger's use of HSTS would influence other paths on that host. (yes, I already hear the arguments for a webfinger subdomain coming back) It's worth noting that DNS is still a huge security hole in all of this. I > don't see Webfinger mandating the use of DNSSEC, nor the methods by which > to verify certificates, so no-one should be under the illusion that > mandating HTTPS is going to lead to "secure" implementations. > I believe verification of certs with root CAs was implicit. At least that's what (almost?) all HTTP clients do by default anyway. --0016e6dee6e887c51d04d00b860a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Tue, Dec 4, 2012 at 10:54 AM, Blaine Cook <romeda@gmail.com> wrote:
and HTTPS-enabled servers SHOULD use = HSTS to ensure that clients are not vulnerable to downgrade attacks.=

HSTS is a huge hammer and very few s= ites are prepared to enable it. =C2=A0I don't think it should be a SHOU= LD, especially because webfinger shares the same domain as other things on = that host, and WebFinger's use of HSTS would influence other paths on t= hat host. =C2=A0(yes, I already hear the arguments for a webfinger subdomai= n coming back)

It's worth noting that DNS is still a huge se= curity hole in all of this. I don't see Webfinger mandating the use of = DNSSEC, nor the methods by which to verify certificates, so no-one should b= e under the illusion that mandating HTTPS is going to lead to "secure&= quot; implementations.

I believe verification of certs with= root CAs was implicit. =C2=A0At least that's what (almost?) all HTTP c= lients do by default anyway.
--0016e6dee6e887c51d04d00b860a-- From ietf-secretariat@ietf.org Tue Dec 4 13:15:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDB521F8BB0; Tue, 4 Dec 2012 13:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouM50SuuMFx0; Tue, 4 Dec 2012 13:15:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7A621F8892; Tue, 4 Dec 2012 13:15:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121204211546.17101.19087.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2012 13:15:46 -0800 X-Mailman-Approved-At: Wed, 05 Dec 2012 08:09:12 -0800 Cc: webfinger@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] New Non-WG Mailing List: webfinger -- Discussion of the Webfinger protocol proposal in the Applications Area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 21:15:47 -0000 A new IETF non-working group email list has been created. List address: webfinger@ietf.org Archive: http://www.ietf.org/mail-archive/web/webfinger/ To subscribe: https://www.ietf.org/mailman/listinfo/webfinger Purpose: Discussion of the Webfinger protocol proposal in the Applications = Area. For additional information, please contact the list administrators. From jasnell@gmail.com Wed Dec 5 11:44:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCA721F8CA1 for ; Wed, 5 Dec 2012 11:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.69 X-Spam-Level: X-Spam-Status: No, score=-3.69 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeQRHzh3wouQ for ; Wed, 5 Dec 2012 11:44:31 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4C221F8BE2 for ; Wed, 5 Dec 2012 11:44:31 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4569833iaz.31 for ; Wed, 05 Dec 2012 11:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Dg2eE9YGuQJXTWcu/oRAuZQGfmZaLkrUbVP6lj0AvqE=; b=nbQ9iQ2cauRWkkDtHdmjwTNZ/mAQBWt2s2x/Ecbt63ko5sEkcMTaISceIuFK4fGbIz QTZ8aCaszUgfQtsdp5Cv+4o7V3vNvaBuQYBbirgDAymtiQN4bvn+GgDULEB+FbYogNAP D8qdqj4htWf6OKD46YDeQF8mT8TcYEK9iVKsZN/+YnO98WTn/v29ZbWLusyrPX0EgiZ2 LvpyZqwaUhPPTCR9mhnk6MkIiw6CPheQRmLJ+6NSrUgYW6RxMVEU5fJR2rX1Wk5yLeVS 6hGAp9B/8D0SZJD74cntUUCelRDZ4WkTwfUnAclPGpTlEfkHWI4FTQHArLKq1SccSTM+ Py6Q== Received: by 10.50.45.166 with SMTP id o6mr3208012igm.0.1354736670974; Wed, 05 Dec 2012 11:44:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Wed, 5 Dec 2012 11:44:10 -0800 (PST) From: James M Snell Date: Wed, 5 Dec 2012 11:44:10 -0800 Message-ID: To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=14dae934035709a11204d02036e2 Subject: [apps-discuss] [JSON-TEST] Updated draft... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:44:32 -0000 --14dae934035709a11204d02036e2 Content-Type: text/plain; charset=UTF-8 Minor updates to the JSON Predicates draft following the updates to JSON Patch from yesterday. http://www.ietf.org/id/draft-snell-json-test-03.txt As always, feedback is welcome. - James --14dae934035709a11204d02036e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Minor updates to the JSON Predicates = draft following the updates to JSON Patch from yesterday.


As always, feedback is welcome.

- James
--14dae934035709a11204d02036e2-- From jpanzer@google.com Wed Dec 5 13:43:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AA621F8797 for ; Wed, 5 Dec 2012 13:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ94ATZHYIjN for ; Wed, 5 Dec 2012 13:43:52 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E359121F8773 for ; Wed, 5 Dec 2012 13:43:51 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4871624lah.31 for ; Wed, 05 Dec 2012 13:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z6XSwCuCvNGMQRo35bWqkxpm0qQzjHRUFa58OTJg35I=; b=OaeEGQWuLWxH5RkyQbZw9jkki2QjbOpyitXwuNUGOHQ6/THCj+VeO6wllhXJRIxjFx qkUu2ZnpBtYVcnLYOABeLgBJsPICvlh8rNHn9BKbWKpJvZeClgOh5wrK/UOQ3MhvVEXN TMLBwaoQhU4WuhS3rhJsdHeRtSRt1pvfLVyhT/QazhlXD+ZAryaofid+KzZuOAtJnn47 FC6VDM7YHtsh1ZSM3vU/LFOKRF4oH8Ne1+TCnGa4ndAECuwcQ1OlhoCoZBYH72TXWb1p Huu9uc67nSnmEIv4suaQnFyV0VVMJTNbb1Jvb4ANZlPUsLf+QH5lXRMMyZ4pR9CmLQDL zRCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=z6XSwCuCvNGMQRo35bWqkxpm0qQzjHRUFa58OTJg35I=; b=SanQ6bj3dGKHwyMsPCFQMhfiF/S28FPnBYZ0tabs6CBcOFxtjjImZ4x37tnsibKovH Fv7BwqGnvdXvQ1HgvzS6McAZgamdgQ5Z9Hd9Yjxm4O66EY8luBPxbUMUAcTY9OQ4NeAb 6WUpO4rz654K1jBJBeRGA3OPvo+dq9JllQZ1hgfPNhBo/yrGvXsOFcLutXIsvoQef488 c1i7rGwO3WSKeg0/QBQy+Rj3hSYTaDaBwcNk8BxoOoh20576/bT4nGNZlQjmKsThpe8W fDZl02FyPtnuP3f0Bd4Eyk9U285mvvQWS9N/vKpQcaH2w33VPsTYc1oD6MqwQbZFluVZ aA7A== Received: by 10.152.128.9 with SMTP id nk9mr18201721lab.17.1354743830445; Wed, 05 Dec 2012 13:43:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.29.161 with HTTP; Wed, 5 Dec 2012 13:43:27 -0800 (PST) In-Reply-To: References: <928b5960-107a-4052-977f-e8513ac32e5e@googlegroups.com> From: John Panzer Date: Wed, 5 Dec 2012 13:43:27 -0800 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04343e8ac67e2804d021e09c X-Gm-Message-State: ALoCoQlKUlrd011cPhnsNvJsLW4V6PBvpNvkXsc3j7LixwVMmZ1/URCDW+H9cksjct+VfeXqxnKBEpeCOfYBBH7MJDvyvlXw40fcpewNFWcDvseUZYdJeUC2k3BQ3RM/CJlgFWRJdtpCN8oHbOy06OCx4qBfGXe77gYGOXw+um1eRVWlBG7SC22TfASTkjHQdQxSlZZRO+4y Cc: Matthias Pfefferle , apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:43:53 -0000 --f46d04343e8ac67e2804d021e09c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 5, 2012 at 1:35 PM, Nick Jennings wrote: > On Mon, Dec 3, 2012 at 6:29 PM, John Panzer wrote: > > I dislike the assumption that contact information is "harmless if > hacked". > > > > One attack scenario: Imagine I can poison the DNS of a small company. I > > ask for a password reset for Tim Bray, but tell them my email is down. I > > return my own telephone number and IM contact info instead of Tim's via > > Webfinger. Support personnel call me on "Tim's" number and I verify I'm > > him. I gain control of his account, use that to bootstrap to gain > > information about other accounts... etc. > > > > It's less likely than an interception attack at an internet cafe. I > don't > > feel competent to say how much less likely. > > > I think that, in this case, the security hole is the fact that the the > "company" uses public WF records as their customer contact database, > and use it as part of their security procedure... However if they were > to decide this is how they wanted to run their infrastructure, they > could simply make the calls to Tim's WF using HTTPS. > As long as their Webfinger client gives them that option, and that they are aware of the option. If it does HTTPS with HTTP fallback they would not have that choice, and if they aren't aware of the option they wouldn't know they had the choice. (The most secure option is to mandate HTTPS only by default on clients but they may be configured to explicitly use HTTP. I don't know how a protocol would spec that.) > > -Nick > --f46d04343e8ac67e2804d021e09c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed= , Dec 5, 2012 at 1:35 PM, Nick Jennings <nick@silverbucket.net>= wrote:
On Mon, Dec 3, 2012 at 6:29 PM, John Panzer <jpanzer@google.com> wrote:
> I dislike the assumption that contact information is "harmless if= hacked".
>
> One attack scenario: =A0Imagine I can poison the DNS of a small compan= y. =A0I
> ask for a password reset for Tim Bray, but tell them my email is down.= =A0I
> return my own telephone number and IM contact info instead of Tim'= s via
> Webfinger. =A0Support personnel call me on "Tim's" numbe= r and I verify I'm
> him. =A0I gain control of his account, use that to bootstrap to gain > information about other accounts... etc.
>
> It's less likely than an interception attack at an internet cafe. = =A0I don't
> feel competent to say how much less likely.


I think that, in this case, the security hole is the fact that the th= e
"company" uses public WF records as their customer contact databa= se,
and use it as part of their security procedure... However if they were
to decide this is how they wanted to run their infrastructure, they
could simply make the calls to Tim's WF using HTTPS.

As long as their Webfinger client gives them that option,= and that they are aware of the option. =A0If it does HTTPS with HTTP fallb= ack they would not have that choice, and if they aren't aware of the op= tion they wouldn't know they had the choice.

(The most secure option is to mandate HTTPS only by def= ault on clients but they may be configured to explicitly use HTTP. =A0I don= 't know how a protocol would spec that.)
=A0

-Nick

--f46d04343e8ac67e2804d021e09c-- From paulej@packetizer.com Wed Dec 5 15:16:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07FB21F8B2A for ; Wed, 5 Dec 2012 15:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wt2OUwLC9KWa for ; Wed, 5 Dec 2012 15:15:58 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 141EB21F8C11 for ; Wed, 5 Dec 2012 15:15:58 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB5NFuci026174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Dec 2012 18:15:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354749357; bh=pP40KSmqyT50R6HphfdKAHm81VBwq7czc6uZLxLf0Gc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=q7YZxSzO4aWEH+fHmtq0KeO0jQ5dAdLzN2zj370E7QUGMnMQDsK40l90Bl5WEQAct d9uRh68e/hNKOWgawBjfKlCY2Mv7lSGmtRVDLdeRA8VZYSb1taH6dgTQCg6VOKf7Hb PTxLCWxkRJmlrcBRW2730/NurHVvb9fTqERLiQ+g= From: "Paul E. Jones" To: "'John Bradley'" References: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> <0bae01cdd199$02da39f0$088eadd0$@packetizer.com> In-Reply-To: Date: Wed, 5 Dec 2012 18:16:01 -0500 Message-ID: <10d401cdd33e$7dfabd70$79f03850$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_10D5_01CDD314.9526D850" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLG5ikawERVTngmuhW5Swaa7Q+GsgI3/5g1Ap/fbOIBr9MxOgGZ/3xrldehTMA= Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up "subject" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 23:16:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_10D5_01CDD314.9526D850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It's true, because that's what your server said. It does not mean that this document represents me, though. It only means that, at your server, this is the document that particular URI will return when queried. Consider other examples like the "tel" URI. They don't even have domain information with them, but folks want to be able to query some defined server any query using that tel URI. Assume the server returns a reply. Another server that also accepts tel URIs might reply with something different. There may be some language we need to add so that the client does not assume the "subject" returned does represent a "subject" at another domain, especially one where the "subject" is like this one you present. By itself, it's harmless. But, if a client assumes the response really is me. yes, that's bad. Words? Paul From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Tuesday, December 04, 2012 11:21 AM To: Paul E. Jones Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up "subject" Yes but if I query ve7jtb@ve7jtb.com and it comes back with a subject of acct:paulej@ packetizer.com I may be claiming the JRD is about you but that doesn't make it true. Clients need to be mindful that the subject of the JRD is self asserted and care needs to be taken if any security related decisions are being made. On 2012-12-03, at 5:58 PM, "Paul E. Jones" wrote: John, But, the subject is the subject of what the JRD describes. Who is the authority here? It's the WF server. If my server tells you "the following JRD describes acct:paulej@ packetizer.com", this is not subject to second guessing. The value might not be equal to the "resource" parameter (for good cause), but normally would be. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley Sent: Monday, December 03, 2012 8:11 AM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up "subject" Added Web Finger to subject for the inocent. I would change that to: "The value of the "subject" member is a string whose value is advisory and normally would be expected to be equivalent to the value of the "resource" parameter in the client request. The "subject" identifies the entity to which the JRD claims to describe." The subject is self asserted saying that it is defiantly the ting that the JRD describes will lead to applications making mistakes. The subject is the thing that the JRD claims to be about. It is more likely to be about the thing you did the query on. If they differ the client should understand that the query parameter is the stronger binding. If we go in on the acct: URI then I would be tempted to say that the value SHOULD be the normalized acct: uri for the thing you are asking about. That is likely more useful information to the client. John B. On 2012-12-03, at 4:16 AM, "Paul E. Jones" < paulej@packetizer.com> wrote: Tim, Yeah, I can appreciate that. However, I would like to suggest some slightly different wording. How is this for the first paragraph in 5.2.2? "The value of the "subject" member is a string whose value is advisory and normally would be expected to be equivalent to the value of the "resource" parameter in the client request. The "subject" identifies the entity to which the JRD describes." Paul From: Tim Bray [mailto:tbray@ textuality.com] Sent: Sunday, December 02, 2012 8:15 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Draft -07 mod proposal: Clean up "subject" Right now, section 5.2.2 says "The value of the "subject" member is a string that MUST be set to the same value as the "resource" parameter in the client request. " This is a recipe for trouble, for a couple of reasons. First of all, what does "the same value" mean? Go visit RFC3986, section 6, and enjoy several hundred words walking through all the issues that arise in trying to figure out when two URIs are equivalent, ranging from exact character-by-character identity to all sorts of protocol-specific goo. You are just one level of case-sensitivity-in-%-escaping from a big hairy false negative. I'm also worried about a lack of flexibility. I might have a single webfinger resource that declares a bunch of link relations for a bunch of different resources. This section, as written, wouldn't let me do that. Proposal: Re-write section 5.2.2 as follows: <<<<<<< The value of the "subject" member is a string whose value is advisory, identifying the resource to which the properties given in the "links" member apply. Normally this would be expected to be equivalent to the value of the "resource" parameter in the client request. <<<<<<< On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones < paulej@packetizer.com> wrote: Folks, I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport). The new version is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07 With respect to resource representation, I fully described the JSON Resource Descriptor within the document. There are no external references to RFC 6415 now, no need to go read the XRD spec, etc. It's a fairly simple format and I believe this text documents it sufficiently. Combined with the visual examples, I think this makes it pretty clear. Have a look at the JRD documentation in section 5.2 and provide your comments. With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP. I changed the wording in 5.2 to try to capture opinions. Previously, the text led with a requirement to try HTTPS first. That is still there. I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP. This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language. I made some editorial changes through the document. Comments are welcome, as always. Seems I don't need to say that to this group, though :-) Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_10D5_01CDD314.9526D850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s true, because that’s what your server said.  It = does not mean that this document represents me, though.  It only = means that, at your server, this is the document that particular URI = will return when queried.

 

Consider other examples like the “tel” URI.  They = don’t even have domain information with them, but folks want to be = able to query some defined server any query using that tel URI.  = Assume the server returns a reply.  Another server that also = accepts tel URIs might reply with something = different.

 

There may be some language we need to add so that the client does not = assume the “subject” returned does represent a = “subject” at another domain, especially one where the = “subject” is like this one you present.  By itself, = it’s harmless.  But, if a client assumes the response really = is me… yes, that’s bad.

 

Words?

 

Paul

 

From:= = John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Tuesday, = December 04, 2012 11:21 AM
To: Paul E. Jones
Cc: = webfinger@googlegroups.com; apps-discuss@ietf.org
Subject: Re: = [apps-discuss] Web Finger Draft -07 mod proposal: Clean up = "subject"

 

Yes but if I = query ve7jtb@ve7jtb.com and it = comes back with a subject of acct:paulej@packetizer.com I may be claiming the JRD is about you = but that doesn't make it true.

 

Clients need to be mindful that the subject of the JRD = is self asserted and care needs to be taken if any security related = decisions are being made. 

 

 

On = 2012-12-03, at 5:58 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:



John,

 

But, the subject is the subject of what the JRD describes.  Who = is the authority here?  It’s the WF server.  If my = server tells you “the following JRD describes acct:paulej@packetizer.com”, this is not = subject to second guessing.  The value might not be equal to the = “resource” parameter (for good cause), but normally would = be.

 

Paul

 

From:=  apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Monday, December 03, 2012 = 8:11 AM
To: webfinger@googlegroups.com=
Cc: apps-discuss@ietf.org
Sub= ject: Re: = [apps-discuss] Web Finger Draft -07 mod proposal: Clean up = "subject"

 

Added Web Finger to subject for the = inocent.

 

I would change that = to:

 

“The value of the "subject" member is a string whose = value is advisory and normally would be expected to be equivalent to the = value of the "resource" parameter in the client request.  = The "subject" identifies the entity to which the JRD claims to = describe.”

 

The subject is self asserted saying that it is = defiantly the ting that the JRD describes will lead to applications = making mistakes.   The subject is the thing that the JRD claims to = be about.  It is more likely to be about the thing you did the = query on.   If they differ the client should understand that the = query parameter is the stronger = binding.

 

If we go in on the acct: URI then I would be tempted = to say that the value SHOULD be the normalized acct: uri for the thing = you are asking about.  That is likely more useful information to = the client.

 

John B.

 

 

On 2012-12-03, at 4:16 AM, "Paul E. Jones" = <paulej@packetizer.com> = wrote:




Tim,

 

Yeah, I can appreciate that.  However, I would like to suggest = some slightly different wording.  How is this for the first = paragraph in 5.2.2?

 

“The value of the "subject" member is a string whose = value is advisory and normally would be expected to be equivalent to the = value of the "resource" parameter in the client request.  = The "subject" identifies the entity to which the JRD = describes.”

 

Paul

 

 

From:=  Tim Bray = [mailto:tbray@textuality.com] 
Sent: Sunday, December 02, 2012 = 8:15 PM
To: Paul E. = Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subjec= t: Draft -07 mod = proposal: Clean up = "subject"

 

Right now, section 5.2.2 says "The = value of the "subject" member is a string that MUST be set to = the same value as the "resource" parameter in the client = request. "

This is a recipe for trouble, for a couple of = reasons. First of all, what does “the same value” = mean?  Go visit RFC3986, section 6, and enjoy several hundred words = walking through all the issues that arise in trying to figure out when = two URIs are equivalent, ranging from exact character-by-character = identity to all sorts of protocol-specific goo. You are just one level = of case-sensitivity-in-%-escaping from a big hairy false = negative.

I’m also worried about a lack of flexibility. I = might have a single webfinger resource that declares a bunch of link = relations for a bunch of different resources. This section, as written, = wouldn’t let me do that.

Proposal: Re-write section 5.2.2 = as follows:

<<<<<<<
The value of the = "subject" member is a string whose value is advisory, = identifying the resource to which the properties given in the = "links" member apply.  Normally this would be expected to = be equivalent to the value of the "resource" parameter in the = client request. 
<<<<<<&l= t;

On Sun, Dec 2, 2012 = at 12:21 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,

 

I published another version of the WebFinger spec = trying to bring closure to the two open issues I see (resource = representation and transport).  The new version is = here:

 

With respect to resource representation, I fully = described the JSON Resource Descriptor within the document.  There = are no external references to RFC 6415 now, no need to go read the XRD = spec, etc.  It’s a fairly simple format and I believe this = text documents it sufficiently.  Combined with the visual examples, = I think this makes it pretty clear.  Have a look at the JRD = documentation in section 5.2 and provide your = comments.

 

With respect to HTTPS, it seems there is strong = preference for “HTTPS only”, but some a fair bit of = insistence for allowing HTTP.  I changed the wording in 5.2 to try = to capture opinions.  Previously, the text led with a requirement = to try HTTPS first.  That is still there.  I just added some = extra conditions that make it clearer that there are some instances = where a client must not utilize HTTP.  This might need further = refinement, but I think there is a balance we can strike here between = the two camps without introducing a lot of complex = language.

 

I made some editorial changes through the = document.

 

Comments are welcome, as always.  Seems I = don’t need to say that to this group, though = :-)

 

Paul

<= p class=3DMsoNormal> 


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss=

 

------=_NextPart_000_10D5_01CDD314.9526D850-- From jasnell@gmail.com Wed Dec 5 15:58:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AAA21F8CDE for ; Wed, 5 Dec 2012 15:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.823 X-Spam-Level: X-Spam-Status: No, score=-3.823 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mmDvoZtGm4F for ; Wed, 5 Dec 2012 15:58:21 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3C58A21F892F for ; Wed, 5 Dec 2012 15:58:21 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id k13so11435567iea.22 for ; Wed, 05 Dec 2012 15:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4x3gt9t8Q+3te8RyFJ9myYy3lNRe4RiBb50hN3FWgkY=; b=B9itLMEAFYJqSMvqsv1bAED5PjlLepnvk4dreUnVaIhlB6aea4vrW+6xfI4GGKToGI jSRZz6uJy/kHseXvlZxFwwr5kUt9Jw6MgO+vOnlY9qE0S0W2insaAOiWaZzW1YHIvhgA 07NyA1RaU7W611Pv5/IU4CWr+/t/Kv/Ak0HEtAGgj8PW1+Uoy5zjX+RBMJCScCUphuxl 0pIycGsfv5SQ9rkOznypxIzMqu+oSve7TirA/ML+mDtguhLunr88f+oKgrP/14hYy6jy TkpLOi5e3iQqKL5+US5295CTe0J60N5n6yuIAupx+7UxgO+RblusLy2c0jbkBHfHYtdq lt8Q== Received: by 10.50.34.226 with SMTP id c2mr4007736igj.24.1354751900651; Wed, 05 Dec 2012 15:58:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Wed, 5 Dec 2012 15:58:00 -0800 (PST) In-Reply-To: <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> References: <50BB20B3.8010403@skoegl.net> <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> From: James M Snell Date: Wed, 5 Dec 2012 15:58:00 -0800 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=14dae9340595cc0edd04d023c189 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 23:58:22 -0000 --14dae9340595cc0edd04d023c189 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Experimental ruby impl here: https://rubygems.org/gems/json-tools. Has not yet been thoroughly tested. Includes basic Pointer, Patch and Predicates support. Updated today to match the patch-07 update. - James On Sun, Dec 2, 2012 at 4:12 PM, Mark Nottingham wrote: > I've started collecting implementations of JSON Patch here: > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch > > ... and am also discussing both the draft and a test suite with the > implementers. > > Below is some feedback from Stefan K=C3=B6gl, who's implementing in Pytho= n, > forwarded with permission (along with some commentary from me). > > Begin forwarded message: > > > * Section 4 "Operations" states > > > > > Other members of operation objects MUST be ignored, unless they are > > > explicitly allowed by the definition of the operation. > > > > Why has the decision been made to ignore unknown members? I think this > could be problematic if the spec is updated later so that existing > operations include new keywords (say a "type" member for test). You > wouldn't notice that your (outdated) implementation does not support this > addition. > > > > I don't know how/why the decision has been made to ignore unknown > members, but please consider this an argument against it. > > I explained why we made this decision (to recap: it was felt that some > implementations would inevitably ignore unknown extensions, causing a > situation similar to HTML). > > Personally, I think we *could* require unknown extensions to be an error; > given our approach to extensibility, and with willing implementers, it's = a > reasonable thing to do. > > Failing that, we at least need to document the approach to extensibility > that we're talking (i.e., that this format is not extensible, and any > modifications / additions need to be expressed using a new media type). > > > > * The "replace" and "move" operations contain the note > > > > > The target location MUST exist for the operation to be successful. > > > > which is clear in the context. The "move" and "copy" operations do not > contain such a statement even though they proably should. Also if they di= d, > the term "target location" would be ambiguous, because it could also refe= r > to the "to" value. > > > > I'd suggest to use a different term for whatever "path" refers to, and > add the statement to all operators to which it applies. > > > (I think he means *re*move, not move in the first line above) > > I tend to agree on both counts. > > Is there any objecting to adding this clause to "move" and "copy"? > > Regarding the term, how about "path location"? > > Cheers (and thanks to Stefan for the feedback!), > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --14dae9340595cc0edd04d023c189 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Experimental ruby impl here:=C2=A0https://rubygems.org/gems/json= -tools. Has not yet been thoroughly tested.

Includes basic Point= er, Patch and Predicates support. Updated today to match the patch-07 updat= e.

- James


On Sun, Dec 2, 2012 at 4:12 PM, M= ark Nottingham <mnot@mnot.net> wrote:
I've started collecting implementations of JSON Patch = here:
=C2=A0 http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPat= ch

... and am also discussing both the draft and a test suite with the impleme= nters.

Below is some feedback from Stefan K=C3=B6gl, who's implementing in Pyt= hon, forwarded with permission (along with some commentary from me).

Begin forwarded message:

> * Section 4 "Operations" states
>
> > Other members of operation objects MUST be ignored, unless they a= re
> > explicitly allowed by the definition of the operation.
>
> Why has the decision been made to ignore unknown members? I think this= could be problematic if the spec is updated later so that existing operati= ons include new keywords (say a "type" member for test). You woul= dn't notice that your (outdated) implementation does not support this a= ddition.
>
> I don't know how/why the decision has been made to ignore unknown = members, but please consider this an argument against it.

I explained why we made this decision (to recap: it was felt that some impl= ementations would inevitably ignore unknown extensions, causing a situation= similar to HTML).

Personally, I think we *could* require unknown extensions to be an error; g= iven our approach to extensibility, and with willing implementers, it's= a reasonable thing to do.

Failing that, we at least need to document the approach to extensibility th= at we're talking (i.e., that this format is not extensible, and any mod= ifications / additions need to be expressed using a new media type).


> * The "replace" and "move" operations contain the = note
>
> > The target location MUST exist for the operation to be successful= .
>
> which is clear in the context. The "move" and "copy&quo= t; operations do not contain such a statement even though they proably shou= ld. Also if they did, the term "target location" would be ambiguo= us, because it could also refer to the "to" value.
>
> I'd suggest to use a different term for whatever "path" = refers to, and add the statement to all operators to which it applies.


(I think he means *re*move, not move in the first line above)

I tend to agree on both counts.

Is there any objecting to adding this clause to "move" and "= copy"?

Regarding the term, how about "path location"?

Cheers (and thanks to Stefan for the feedback!),


--
Mark Nottingham =C2=A0 h= ttp://www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--14dae9340595cc0edd04d023c189-- From mnot@mnot.net Wed Dec 5 20:44:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD5821F8CA3 for ; Wed, 5 Dec 2012 20:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.904 X-Spam-Level: X-Spam-Status: No, score=-103.904 tagged_above=-999 required=5 tests=[AWL=-1.305, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhkdIg15EEVB for ; Wed, 5 Dec 2012 20:44:52 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 639D421F8CA0 for ; Wed, 5 Dec 2012 20:44:52 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B01B3509B9; Wed, 5 Dec 2012 23:44:50 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Thu, 6 Dec 2012 15:44:49 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F13D809-9401-48D1-9245-C00499CFD3BF@mnot.net> References: <50BB20B3.8010403@skoegl.net> <03A0F58D-A16C-4AD1-AE65-945AF2D3A193@mnot.net> To: James M Snell X-Mailer: Apple Mail (2.1499) Cc: Apps Discuss Subject: Re: [apps-discuss] JSON Patch implementation feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 04:44:53 -0000 Updated, thanks! On 06/12/2012, at 10:58 AM, James M Snell wrote: > Experimental ruby impl here: https://rubygems.org/gems/json-tools. Has = not yet been thoroughly tested. >=20 > Includes basic Pointer, Patch and Predicates support. Updated today to = match the patch-07 update. >=20 > - James >=20 >=20 > On Sun, Dec 2, 2012 at 4:12 PM, Mark Nottingham wrote: > I've started collecting implementations of JSON Patch here: > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch >=20 > ... and am also discussing both the draft and a test suite with the = implementers. >=20 > Below is some feedback from Stefan K=F6gl, who's implementing in = Python, forwarded with permission (along with some commentary from me). >=20 > Begin forwarded message: >=20 > > * Section 4 "Operations" states > > > > > Other members of operation objects MUST be ignored, unless they = are > > > explicitly allowed by the definition of the operation. > > > > Why has the decision been made to ignore unknown members? I think = this could be problematic if the spec is updated later so that existing = operations include new keywords (say a "type" member for test). You = wouldn't notice that your (outdated) implementation does not support = this addition. > > > > I don't know how/why the decision has been made to ignore unknown = members, but please consider this an argument against it. >=20 > I explained why we made this decision (to recap: it was felt that some = implementations would inevitably ignore unknown extensions, causing a = situation similar to HTML). >=20 > Personally, I think we *could* require unknown extensions to be an = error; given our approach to extensibility, and with willing = implementers, it's a reasonable thing to do. >=20 > Failing that, we at least need to document the approach to = extensibility that we're talking (i.e., that this format is not = extensible, and any modifications / additions need to be expressed using = a new media type). >=20 >=20 > > * The "replace" and "move" operations contain the note > > > > > The target location MUST exist for the operation to be successful. > > > > which is clear in the context. The "move" and "copy" operations do = not contain such a statement even though they proably should. Also if = they did, the term "target location" would be ambiguous, because it = could also refer to the "to" value. > > > > I'd suggest to use a different term for whatever "path" refers to, = and add the statement to all operators to which it applies. >=20 >=20 > (I think he means *re*move, not move in the first line above) >=20 > I tend to agree on both counts. >=20 > Is there any objecting to adding this clause to "move" and "copy"? >=20 > Regarding the term, how about "path location"? >=20 > Cheers (and thanks to Stefan for the feedback!), >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Dec 5 21:07:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8F621F8D02 for ; Wed, 5 Dec 2012 21:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.861 X-Spam-Level: X-Spam-Status: No, score=-103.861 tagged_above=-999 required=5 tests=[AWL=-1.262, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMYvgKrb5YpE for ; Wed, 5 Dec 2012 21:07:40 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D1F5121F8BED for ; Wed, 5 Dec 2012 21:07:40 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 87653509B6; Thu, 6 Dec 2012 00:07:38 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11502A39F2F@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 6 Dec 2012 16:07:38 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <4CA64572-A910-4FC9-B096-10D8D5B1EC8E@mnot.net> References: <20121205004222.5427.95750.idtracker@ietfa.amsl.com> <931DFB08-6300-41CA-9269-2B5E0AFEB9D7@mnot.net> <255B9BB34FB7D647A506DC292726F6E11502A39F2F@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 05:07:41 -0000 On 05/12/2012, at 2:20 PM, "Manger, James H" = wrote: >> Very small changes here based upon LC feedback; nothing to see, move >> along. >=20 > I noticed a bug in an implementation listed at = http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch: unescaping ~0 = to ~, before unescaping ~1 to / (so a ~ from the first unescaping is = mistakenly treated as an escape character in the second unescaping). Please log a bug with them, if possible (and if you haven't already done = so). > It is a bug that could easily be repeated so one more example in = draft-ietf-appsawg-json-pointer to cover this case would be worthwhile. >=20 > In section 5 "JSON String Representation" add: >=20 > Given the JSON doc: > { "/": 9, > "~1": 10 } > A pointer (as a JSON string) and value is: > "/~01" 10 >=20 >=20 > In the format of https://github.com/json-patch/json-patch-tests > { "comment": "don't unescape ~0 separately before unescaping ~1", > "doc": { > "/": 9, > "~1": 10 }, > "patch": [{"op": "test", "path": "/~01", "value":10}] }, OK, thanks. Will add to the next rev. > I also noticed a few implementations just use JavaScript=92s = parseInt() function to convert a segment in a JSON pointer (a = ) to an integer array index. Hence, they accept "/007" = and "/ +0007zzz" as equivalent to "/7". Yuck. Perhaps add examples to = the spec to explicitly show these are errors (so they make it into = tests)? How about just adding to the non-spec tests? This is = implementation-specific, so I'd rather keep it out of the spec, I think. Cheers, -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Wed Dec 5 22:27:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895AC21F875E for ; Wed, 5 Dec 2012 22:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=1.123, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCDEkRA4H8aH for ; Wed, 5 Dec 2012 22:27:02 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id EB9AB21F8707 for ; Wed, 5 Dec 2012 22:27:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,228,1355058000"; d="scan'208";a="104567235" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 06 Dec 2012 17:27:00 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="102074586" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcbni.tcif.telstra.com.au with ESMTP; 06 Dec 2012 17:27:00 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Thu, 6 Dec 2012 17:26:59 +1100 From: "Manger, James H" To: Mark Nottingham Date: Thu, 6 Dec 2012 17:26:58 +1100 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt Thread-Index: Ac3Tb6FoeiZ7Ml36QKWtV792K2ibswABzuzg Message-ID: <255B9BB34FB7D647A506DC292726F6E11502AF50BD@WSMSG3153V.srv.dir.telstra.com> References: <20121205004222.5427.95750.idtracker@ietfa.amsl.com> <931DFB08-6300-41CA-9269-2B5E0AFEB9D7@mnot.net> <255B9BB34FB7D647A506DC292726F6E11502A39F2F@WSMSG3153V.srv.dir.telstra.com> <4CA64572-A910-4FC9-B096-10D8D5B1EC8E@mnot.net> In-Reply-To: <4CA64572-A910-4FC9-B096-10D8D5B1EC8E@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 06:27:03 -0000 PiA+IEkgYWxzbyBub3RpY2VkIGEgZmV3IGltcGxlbWVudGF0aW9ucyBqdXN0IHVzZSBKYXZhU2Ny aXB04oCZcyBwYXJzZUludCgpDQo+IGZ1bmN0aW9uIHRvIGNvbnZlcnQgYSBzZWdtZW50IGluIGEg SlNPTiBwb2ludGVyIChhIDxyZWZlcmVuY2UtdG9rZW4+KQ0KPiB0byBhbiBpbnRlZ2VyIGFycmF5 IGluZGV4LiBIZW5jZSwgdGhleSBhY2NlcHQgIi8wMDciIGFuZCAiLyAgKzAwMDd6enoiDQo+IGFz IGVxdWl2YWxlbnQgdG8gIi83Ii4gWXVjay4gUGVyaGFwcyBhZGQgZXhhbXBsZXMgdG8gdGhlIHNw ZWMgdG8NCj4gZXhwbGljaXRseSBzaG93IHRoZXNlIGFyZSBlcnJvcnMgKHNvIHRoZXkgbWFrZSBp dCBpbnRvIHRlc3RzKT8NCg0KPiBIb3cgYWJvdXQganVzdCBhZGRpbmcgdG8gdGhlIG5vbi1zcGVj IHRlc3RzPyBUaGlzIGlzIGltcGxlbWVudGF0aW9uLQ0KPiBzcGVjaWZpYywgc28gSSdkIHJhdGhl ciBrZWVwIGl0IG91dCBvZiB0aGUgc3BlYywgSSB0aGluay4NCg0KSXQgc2VlbXMgbm8gb25lIGRv ZXMgaW5wdXQgdmFsaWRhdGlvbi4gQXJnaCENCkkgZ2xhbmNlZCBhdCBvdmVyIGhhbGYgb2YgdGhl IDggaW1wbGVtZW50YXRpb25zIGxpc3RlZCBhdCBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93 Zy9hcHBzYXdnL3RyYWMvd2lraS9Kc29uUGF0Y2ggYW5kIGRpZG4ndCBmaW5kIGEgc2luZ2xlIG9u ZSB0aGF0IGNoZWNrZWQgdGhhdCBhIEpTT04gcG9pbnRlciBzZWdtZW50IHdhcyBhIHZhbGlkIGFy cmF5IGluZGV4IGJlZm9yZSBjb252ZXJ0aW5nIGl0IHRvIGFuIGludGVnZXIuDQoNCkdpdmVuIHRo YXQgbm90IG9uZSBpbXBsZW1lbnRhdGlvbiB2YWxpZGF0ZWQgdGhlIGlucHV0IHNlZW1zIGxpa2Ug YSBzdHJvbmcgcmVhc29uIHRvIGNhbGwgbW9yZSBhdHRlbnRpb24gdG8gaXQgaW4gdGhlIHNwZWMu IEZvciBpbnN0YW5jZSwgc3RhdGluZyAiLys3IiwgIi8wMDciLCAiLyA3IiwgYW5kICIvNy4wIiBh cmUgZXhhbXBsZSBvZiBwb2ludGVycyB0aGF0IE1VU1QgTk9UIGJlIGFjY2VwdGVkIGFzIGFycmF5 IGluZGljZXMuIE9yIHBlcmhhcHMgcHJvdmlkZSBhIHJlZ2V4IHRoYXQgYSBzZWdtZW50IE1VU1Qg bWF0Y2ggdG8gYmUgYW4gYXJyYXkgaW5kZXg6IDB8WzEtOV1bMC05XSouDQoNCg0KQWxsIHRoZSBp bXBsZW1lbnRhdGlvbnMgSSBnbGFuY2VkIGF0IGp1c3QgY2FsbCBhIG5hdGl2ZSBmdW5jdGlvbiB0 byBjb252ZXJ0IGEgc3RyaW5nIHRvIGFuIGludGVnZXIuDQoNClRoZSBKYXZhU2NyaXB0IGNvZGUg Y2FsbCBwYXJzZUludC4NClRoZSBQeXRob24gY29kZSBjYWxscyBpbnQoKSwgYW5kIGlzZGlnaXQo KS4NClRoZSBSdWJ5IGNvZGUgY2FsbHMgdG9faSBvciBJbnRlZ2VyIGtleS4NClRoZSBQSFAgY29k ZSBjYWxscyBpc19udW1lcmljLg0KVGhlIEphdmEgY29kZSBjYWxscyBJbnRlZ2VyLnBhcnNlSW50 KCkuDQoNCkFsbCBvZiB0aGVzZSBhY2NlcHQgSlNPTiBzZWdtZW50cyB0aGF0IGFyZSBub3QgdmFs aWQgYXJyYXkgaW5kaWNlczogaW5jbHVkaW5nIGxlYWRpbmcgd2hpdGVzcGFjZSwgIisiIHNpZ25z LCAweCBoZXggdmFsdWVzLCBkZWNpbWFsIHBvaW50cywgZXhwb25lbnRzLCAiXyIgZGlnaXQgc2Vw YXJhdG9ycywgdW5uZWNlc3NhcnkgbGVhZGluZyAwJ3MsIHRyYWlsaW5nIGxldHRlcnMsIGFuZCBt b3JlLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From nick@silverbucket.net Wed Dec 5 13:36:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DDB21F8CB8 for ; Wed, 5 Dec 2012 13:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q-sqNwIT2c5 for ; Wed, 5 Dec 2012 13:36:09 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8AA21F871A for ; Wed, 5 Dec 2012 13:36:08 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4866388lah.31 for ; Wed, 05 Dec 2012 13:36:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=D2rO1caLDJmSJ1tLWnIA4S+hxPBj5QXPz9pYD/mFtGA=; b=oDC7X6MwfkVs1c/Z/lyRSF7bwTJzH9yA8874CuW2yeZ1Czn5b2cr0glX4U16+PMKoL Ss+yGxPfKYKBHTHyC/z/ZSLqWSTb3MrdEpsCug8jNET+aDI72/bfhyrqYqIOqD+LdWGj wTiwJA8O1wQJ69NypaoHPEAulef8euM4/UpxymXYIdm0SG4HowmyMHlJzUnI908bfhQL gbyc+dh4KyxH00jsDc2dU44QXDMj4YIVCg4SC3+cYhMMPrqNJmiOYd+Yr6CTv1HOtJFK JLSxnJLkBlrr17AzO0qQINLKxzO6q+hant6rcmmtHVM6y9VuCKcEgX4L3O/E5tcq4QjE fuNg== Received: by 10.112.9.135 with SMTP id z7mr7859160lba.66.1354743367565; Wed, 05 Dec 2012 13:36:07 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id jk8sm2619257lab.7.2012.12.05.13.36.06 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 13:36:06 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so5002850lbk.31 for ; Wed, 05 Dec 2012 13:36:06 -0800 (PST) Received: by 10.152.110.234 with SMTP id id10mr18180326lab.15.1354743366157; Wed, 05 Dec 2012 13:36:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Wed, 5 Dec 2012 13:35:35 -0800 (PST) In-Reply-To: References: <928b5960-107a-4052-977f-e8513ac32e5e@googlegroups.com> From: Nick Jennings Date: Wed, 5 Dec 2012 22:35:35 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnzO4c/xioLqNjee+HdyY8PQMV9kkDYk3IhmkJFEJ2sla5T9bABeOKuU8TJx9TyqDnY48HU X-Mailman-Approved-At: Thu, 06 Dec 2012 08:02:05 -0800 Cc: Matthias Pfefferle , apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft -07 mod proposal: HTTPS with fallback parameter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:36:09 -0000 On Mon, Dec 3, 2012 at 6:29 PM, John Panzer wrote: > I dislike the assumption that contact information is "harmless if hacked". > > One attack scenario: Imagine I can poison the DNS of a small company. I > ask for a password reset for Tim Bray, but tell them my email is down. I > return my own telephone number and IM contact info instead of Tim's via > Webfinger. Support personnel call me on "Tim's" number and I verify I'm > him. I gain control of his account, use that to bootstrap to gain > information about other accounts... etc. > > It's less likely than an interception attack at an internet cafe. I don't > feel competent to say how much less likely. I think that, in this case, the security hole is the fact that the the "company" uses public WF records as their customer contact database, and use it as part of their security procedure... However if they were to decide this is how they wanted to run their infrastructure, they could simply make the calls to Tim's WF using HTTPS. -Nick From Jeff.Hodges@KingsMountain.com Thu Dec 6 08:06:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4354721F859A for ; Thu, 6 Dec 2012 08:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4qVFLXoBR9u for ; Thu, 6 Dec 2012 08:06:40 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 54E8821F85C6 for ; Thu, 6 Dec 2012 08:06:40 -0800 (PST) Received: (qmail 20974 invoked by uid 0); 6 Dec 2012 16:06:18 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 6 Dec 2012 16:06:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=J32l3+TGlhjK9n5rYIrEnbsEi9H/sIAOPZhsYmAvlx4=; b=AZq3X7tnvUFGqnZedTktQhEjPQ00j02sumngQk8kZfsyr+7lYBSdE/Figa5AjqGlZWkvWe01HtyTfXpUHh/lh+ZefIt9Mf7Q6DuBym/ceVTWng3IsOzuvLdPqAQ62WJ2; Received: from [216.113.168.128] (port=26266 helo=[10.244.137.210]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Tgdxp-0005qY-MJ; Thu, 06 Dec 2012 09:06:17 -0700 Message-ID: <50C0C278.7050302@KingsMountain.com> Date: Thu, 06 Dec 2012 08:06:16 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: HTTP State , IETF WebSec WG , HTTP Working Group , Apps Discuss , IETF oauth WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [apps-discuss] fyi: IETF conflict review results for draft-secure-cookie-session-protocol X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 16:06:41 -0000 [ I was nosing around and noticed this relatively recent decision, it didn't appear to have been fwd'd to these lists. fyi/fwiw... ] Subject: Results of IETF-conflict review for draft-secure-cookie-session-protocol-08 From: The IESG Date: Mon, 19 Nov 2012 14:46:52 -0800 To: "Nevil Brownlee" , draft-secure-cookie-session-protocol@tools.ietf.org Cc: iana@iana.org, The IESG , ietf-announce@ietf.org The IESG has completed a review of draft-secure-cookie-session-protocol-08 consistent with RFC5742. The IESG has no problem with the publication of 'SCS: Secure Cookie Sessions for HTTP' as an Informational RFC. The IESG has concluded that this work is related to IETF work done in the websec and httpbis working groups, but this relationship does not prevent publishing. The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-secure-cookie-session-protocol/ A URL of the reviewed Internet Draft is: http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary ### IETF conflict review for draft-secure-cookie-session-protocol [conflict-review-secure-cookie-session-protocol-00] https://datatracker.ietf.org/doc/conflict-review-secure-cookie-session-protocol/ Conflict Review State: Approved No Problem - announcement sent Shepherding AD: Barry Leiba Last updated: 2012-11-19 Conflict Review for draft-secure-cookie-session-protocol-09 The IESG has concluded that this work is related to IETF work done in the websec and httpbis working groups, but this relationship does not prevent publishing. ### From jasnell@gmail.com Thu Dec 6 10:58:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419B821F868D for ; Thu, 6 Dec 2012 10:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.814 X-Spam-Level: X-Spam-Status: No, score=-4.814 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKNyY+QXv-mB for ; Thu, 6 Dec 2012 10:58:06 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 578C321F862C for ; Thu, 6 Dec 2012 10:58:06 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id 17so12691704iea.30 for ; Thu, 06 Dec 2012 10:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5CojOqPv11m5GeLnq5DV8W+uJMviHpai/fq0tDDMW1Q=; b=bWUFVNwNQrCQTlpUeYdgRKE3raO8ABpTSZAlrHaFGeSNuLynrCU34i7RnxvYtm8IP/ gRttWDwc/F6sw3dmuXkcwhVn+jizP8eiTmHGEJmJdR5tQvhnF7qpOzw5QqpfkGzARr97 i4pZdSkdkRflbrie0BgGW4sxrTvAdb3zPqN3j9JtS/BMXqUuxK+Z9NdkQf5PhZ4KkgTM RAD76p/8F7KY+ZNbVhynfY+HweauH+2T+fG3TLmAeSdC8z10FUHrCB1nR/PfUeDgAdUa v5wjDvzRHzIq+DHG7g2e/0DIMlJgxKrg8FA3W8+w6edkhwila9fJMJ0AyE3a1wBO69P2 LmMw== Received: by 10.50.6.169 with SMTP id c9mr2608118iga.24.1354820285762; Thu, 06 Dec 2012 10:58:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 6 Dec 2012 10:57:45 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11502AF50BD@WSMSG3153V.srv.dir.telstra.com> References: <20121205004222.5427.95750.idtracker@ietfa.amsl.com> <931DFB08-6300-41CA-9269-2B5E0AFEB9D7@mnot.net> <255B9BB34FB7D647A506DC292726F6E11502A39F2F@WSMSG3153V.srv.dir.telstra.com> <4CA64572-A910-4FC9-B096-10D8D5B1EC8E@mnot.net> <255B9BB34FB7D647A506DC292726F6E11502AF50BD@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Thu, 6 Dec 2012 10:57:45 -0800 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=e89a8f646717de0ddf04d033adcb Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:58:07 -0000 --e89a8f646717de0ddf04d033adcb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 5, 2012 at 10:26 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > > I also noticed a few implementations just use JavaScript=E2=80=99s pa= rseInt() > > function to convert a segment in a JSON pointer (a ) > > to an integer array index. Hence, they accept "/007" and "/ +0007zzz" > > as equivalent to "/7". Yuck. Perhaps add examples to the spec to > > explicitly show these are errors (so they make it into tests)? > > > How about just adding to the non-spec tests? This is implementation- > > specific, so I'd rather keep it out of the spec, I think. > > It seems no one does input validation. Argh! > I glanced at over half of the 8 implementations listed at > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch and didn't find > a single one that checked that a JSON pointer segment was a valid array > index before converting it to an integer. > > Given that not one implementation validated the input seems like a strong > reason to call more attention to it in the spec. For instance, stating > "/+7", "/007", "/ 7", and "/7.0" are example of pointers that MUST NOT be > accepted as array indices. Or perhaps provide a regex that a segment MUST > match to be an array index: 0|[1-9][0-9]*. > > > I'll eventually get proper validation added to the json-tools ruby impl. I just haven't had much time to work on it. I'm not sure there's anything to be gained in making the spec more explicit and strict on this point. - James > All the implementations I glanced at just call a native function to > convert a string to an integer. > > The JavaScript code call parseInt. > The Python code calls int(), and isdigit(). > The Ruby code calls to_i or Integer key. > The PHP code calls is_numeric. > The Java code calls Integer.parseInt(). > > All of these accept JSON segments that are not valid array indices: > including leading whitespace, "+" signs, 0x hex values, decimal points, > exponents, "_" digit separators, unnecessary leading 0's, trailing letter= s, > and more. > > -- > James Manger > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8f646717de0ddf04d033adcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Wed, Dec 5, 2012 at 10:26 PM, Manger,= James H <James.H.Manger@team.telstra.com> wro= te:
> > I also noticed a= few implementations just use JavaScript=E2=80=99s parseInt()
> function to convert a segment in a JSON pointer (a <reference-token= >)
> to an integer array index. Hence, they accept "/007" and &qu= ot;/ =C2=A0+0007zzz"
> as equivalent to "/7". Yuck. Perhaps add examples to the spe= c to
> explicitly show these are errors (so they make it into tests)?

> How about just adding to the non-spec tests? This is implementation- > specific, so I'd rather keep it out of the spec, I think.

It seems no one does input validation. Argh!
I glanced at over half of the 8 implementations listed at http= ://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch and didn't fi= nd a single one that checked that a JSON pointer segment was a valid array = index before converting it to an integer.

Given that not one implementation validated the input seems like a strong r= eason to call more attention to it in the spec. For instance, stating "= ;/+7", "/007", "/ 7", and "/7.0" are exa= mple of pointers that MUST NOT be accepted as array indices. Or perhaps pro= vide a regex that a segment MUST match to be an array index: 0|[1-9][0-9]*.=



I'll eventually get proper validat= ion added to the json-tools ruby impl. I just haven't had much time to = work on it. I'm not sure there's anything to be gained in making th= e spec more explicit and strict on this point.=C2=A0

- James
=C2=A0
All the implementations I glanced at just call a native function to convert= a string to an integer.

The JavaScript code call parseInt.
The Python code calls int(), and isdigit().
The Ruby code calls to_i or Integer key.
The PHP code calls is_numeric.
The Java code calls Integer.parseInt().

All of these accept JSON segments that are not valid array indices: includi= ng leading whitespace, "+" signs, 0x hex values, decimal points, = exponents, "_" digit separators, unnecessary leading 0's, tra= iling letters, and more.

--
James Manger
___________________________________= ____________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8f646717de0ddf04d033adcb-- From barryleiba.mailing.lists@gmail.com Thu Dec 6 11:34:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3C921F88C1; Thu, 6 Dec 2012 11:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.093 X-Spam-Level: X-Spam-Status: No, score=-103.093 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf1yeV96Vi7G; Thu, 6 Dec 2012 11:34:55 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47D3E21F867A; Thu, 6 Dec 2012 11:34:49 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so5909765lbk.31 for ; Thu, 06 Dec 2012 11:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6hgqy6AxD2R9SZxoPfFAKdFGbY/9J4+Dx5UZdm8Mfqo=; b=w9guA4XFOKSC774g7SX+soD1m+Y6+QRF6mkNXKlBVdISLQvhx9Hihwr00e+plLeDPP yHZR2tTQo0G+zV3FyM7tZu/jQu9cdx1jzjKKCLCoPU4OqwQM3PqqDd0n2rL7zJ36MugA ccWGI3qYiDQoC/bOh+YVlm2u1VmQvsTaJUdbO54KGju5CkNy9mYKgaUF0Ui0519+H4u6 IInq3oMD3sep0OCh+sxvkgSyXmusixHxB0tIu1UzxDyW6GakQEeVI0jl4ZCkAO2KaKi9 o017MtkfpQ72bYWg5x8FqEaQhtDNa6Ak0iYQ8D+GS3/CyLk2EDeLfSIudBKZaEuHGDWL 9P8A== MIME-Version: 1.0 Received: by 10.112.25.34 with SMTP id z2mr1449204lbf.125.1354822488183; Thu, 06 Dec 2012 11:34:48 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Thu, 6 Dec 2012 11:34:48 -0800 (PST) In-Reply-To: <50C0C278.7050302@KingsMountain.com> References: <50C0C278.7050302@KingsMountain.com> Date: Thu, 6 Dec 2012 14:34:48 -0500 X-Google-Sender-Auth: OX0NyyE18yghle8XQywQyo6h5PI Message-ID: From: Barry Leiba To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF oauth WG , IETF WebSec WG , HTTP Working Group , Apps Discuss , HTTP State Subject: Re: [apps-discuss] [OAUTH-WG] fyi: IETF conflict review results for draft-secure-cookie-session-protocol X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 19:34:55 -0000 > [ I was nosing around and noticed this relatively recent decision, it didn't > appear to have been fwd'd to these lists. fyi/fwiw... ] ... > The IESG has no problem with the publication of 'SCS: Secure Cookie > Sessions for HTTP' as an > Informational RFC. > > The IESG has concluded that this work is related to IETF work done in the > websec and httpbis working groups, but this relationship does not prevent > publishing. Yes, Jeff, and thanks for forwarding this. To make sure people have the background... I announced on 17 Oct to this set of mailing lists that we were looking for input to the conflict review to be posted to the SAAG mailing list. The discussion thread starts here: http://www.ietf.org/mail-archive/web/saag/current/msg04049.html On 9 November, I closed the discussion with this message on the SAAG list: http://www.ietf.org/mail-archive/web/saag/current/msg04164.html If anyone has any questions about the document, I suggest they contact the authors directly. You can do that with the following tools alias: Barry, App AD From mnot@mnot.net Thu Dec 6 17:06:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A088021F84F2 for ; Thu, 6 Dec 2012 17:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.065 X-Spam-Level: X-Spam-Status: No, score=-105.065 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUzYjo194O6d for ; Thu, 6 Dec 2012 17:06:47 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1378B21F8504 for ; Thu, 6 Dec 2012 17:06:46 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6F461509BB; Thu, 6 Dec 2012 20:06:44 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11502AF50BD@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 7 Dec 2012 12:06:48 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <883455A4-D3EC-416B-9CF2-563E5973D353@mnot.net> References: <20121205004222.5427.95750.idtracker@ietfa.amsl.com> <931DFB08-6300-41CA-9269-2B5E0AFEB9D7@mnot.net> <255B9BB34FB7D647A506DC292726F6E11502A39F2F@WSMSG3153V.srv.dir.telstra.com> <4CA64572-A910-4FC9-B096-10D8D5B1EC8E@mnot.net> <255B9BB34FB7D647A506DC292726F6E11502AF50BD@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 01:06:47 -0000 FWIW, I created: https://github.com/json-patch/json-patch-tests/issues/5 On 06/12/2012, at 5:26 PM, "Manger, James H" = wrote: >>> I also noticed a few implementations just use JavaScript=92s = parseInt() >> function to convert a segment in a JSON pointer (a ) >> to an integer array index. Hence, they accept "/007" and "/ = +0007zzz" >> as equivalent to "/7". Yuck. Perhaps add examples to the spec to >> explicitly show these are errors (so they make it into tests)? >=20 >> How about just adding to the non-spec tests? This is implementation- >> specific, so I'd rather keep it out of the spec, I think. >=20 > It seems no one does input validation. Argh! > I glanced at over half of the 8 implementations listed at = http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch and didn't = find a single one that checked that a JSON pointer segment was a valid = array index before converting it to an integer. >=20 > Given that not one implementation validated the input seems like a = strong reason to call more attention to it in the spec. For instance, = stating "/+7", "/007", "/ 7", and "/7.0" are example of pointers that = MUST NOT be accepted as array indices. Or perhaps provide a regex that a = segment MUST match to be an array index: 0|[1-9][0-9]*. >=20 >=20 > All the implementations I glanced at just call a native function to = convert a string to an integer. >=20 > The JavaScript code call parseInt. > The Python code calls int(), and isdigit(). > The Ruby code calls to_i or Integer key. > The PHP code calls is_numeric. > The Java code calls Integer.parseInt(). >=20 > All of these accept JSON segments that are not valid array indices: = including leading whitespace, "+" signs, 0x hex values, decimal points, = exponents, "_" digit separators, unnecessary leading 0's, trailing = letters, and more. >=20 > -- > James Manger -- Mark Nottingham http://www.mnot.net/ From ietfc@btconnect.com Fri Dec 7 10:17:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B2421F85CB; Fri, 7 Dec 2012 10:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSJtc-mzLftz; Fri, 7 Dec 2012 10:17:15 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 59E5621F85F4; Fri, 7 Dec 2012 10:17:14 -0800 (PST) Received: from mail72-co1-R.bigfish.com (10.243.78.254) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Dec 2012 18:17:14 +0000 Received: from mail72-co1 (localhost [127.0.0.1]) by mail72-co1-R.bigfish.com (Postfix) with ESMTP id 0026B9A02D1; Fri, 7 Dec 2012 18:17:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zzbb2dI98dI9371I936eI542I1432Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h304l1155h) Received: from mail72-co1 (localhost.localdomain [127.0.0.1]) by mail72-co1 (MessageSwitch) id 1354904231864607_22475; Fri, 7 Dec 2012 18:17:11 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.233]) by mail72-co1.bigfish.com (Postfix) with ESMTP id D03911C007B; Fri, 7 Dec 2012 18:17:11 +0000 (UTC) Received: from AMSPRD0710HT004.eurprd07.prod.outlook.com (157.56.249.85) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Dec 2012 18:17:11 +0000 Received: from DB3PRD0610HT005.eurprd06.prod.outlook.com (157.56.252.53) by pod51017.outlook.com (10.255.160.167) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 7 Dec 2012 18:17:05 +0000 Message-ID: <042c01cdd4a6$da9b8fa0$4001a8c0@gateway.2wire.net> From: t.petch To: Brian E Carpenter References: <50B3967F.7040205@gmail.com> Date: Fri, 7 Dec 2012 18:15:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.53] X-OriginatorOrg: btconnect.com Cc: draft-ietf-6man-uri-zoneid@tools.ietf.org, appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 18:17:16 -0000 ----- Original Message ----- From: "Brian E Carpenter" To: "Yves Lafon" Cc: ; ; ; Sent: Monday, November 26, 2012 4:19 PM > Yves, > > On 26/11/2012 14:56, Yves Lafon wrote: > > I have been selected as the Applications Area Directorate reviewer for > > this draft (for background on appsdir, please see > > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat e). > > > > Please resolve these comments along with any other Last Call comments > > you may receive. Please wait for direction from your document shepherd > > or AD before posting a new version of the draft. > > > > Document: draft-ietf-6man-uri-zoneid-05 > > Title: IPv6 Zone Identifiers in Address Literals and Uniform Resource > > Identifiers > > Reviewer: Yves Lafon > > Review Date: 26 November 2012 > > IETF Last Call Date: 2012-11-23 > > > > Summary: The document is almost ready to progress, but some > > clarifications are needed on two points explicited below. > > > > In section 3: > > << > > This document implies that all browsers should recognise a ZoneID > > preceded by an escaped "%". In the spirit of "be liberal with what > > you accept", we also recommend that URI parsers accept bare "%" signs > > (i.e., a "%" not followed by two valid hexadecimal characters). This > > makes it easy for a user to copy and paste a string such as > > "fe80::a%en1" from the output of a "ping" command and have it work. > > Does it mean that such URIs can be present in an HTML document or that > > they MAY allow bare "%" signs when the URI is pasted in the address bar? > > (Those are two different use cases, and browsers may have different code > > paths for both). > > This is exactly why I suggested in the "New URL Standard..." thread > on the IETF list that we need a formal distinction between URI syntax > and the permitted "syntax" for user input strings. Without that > distinction, we are obliged to specify them both as if they were > the same thing. I really don't know how to capture this in the current > draft. Brian My take on that thread is somewhat different, namely that there is a distinction, that the IETF defines the valid output of the process and has never specified the input or processing thereof, leaving every web browser to exercise its skill and judgment thereon. (Roy Fielding did say "I have absolutely no problem with writing a proposed standard for parsing references, particularly if browser developers are willing to adhere to one." and "It is not non-interoperable behavior to parse input data differently depending on the context in which it is entered.") In which case, you can spell that out in this I-D. Tom Petch > Since we do say that URIs with ZoneIDs are meaningless outside the > originating host, that would mean they shouldn't be included in HTML > documents IMHO. But I think somebody needs to rewrite RFC 3986. > > > In section 4: > > It says > > << > > An HTTP server or proxy MUST ignore any ZoneID attached to an > > incoming URI, as it only has local significance at the sending host. > >>> > > > > A proxy can be considered as a sending host, so does it mean that a the > > receiving end MUST strip all ZoneID before processing the request? (and > > it would be a significant change to implementations), or could this be > > resolved by mandating Web browser to strip ZoneID prior to sending the > > request as it is only significant for the sending host and as it is the > > implementation that needs to be updated to recognize the new syntax? > > IMHO it would be safest if the sending host strips it. We could certainly > suggest that. > > However, as the draft is on the IESG agenda this week, we won't update > it until we get all the IESG comments. > > Thanks > > Brian > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From ted.ietf@gmail.com Fri Dec 7 10:57:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E16F21F8518 for ; Fri, 7 Dec 2012 10:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZvWCGOLGACR for ; Fri, 7 Dec 2012 10:57:04 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4FB21F84FC for ; Fri, 7 Dec 2012 10:57:04 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so787919vbb.31 for ; Fri, 07 Dec 2012 10:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/qHXAOkQO8uTT7wNx9jqLgFCyArP4QSRUKxBd06GfCQ=; b=F7S2ntuhXAUuoEQ17owLkdAX+CtmMpeqj8oOjKrFvxbywudLSmfj3WUDbPuLjBbSel s3MgMuE5YUlOlZxGHTlppcuPFto6KdUWBJ1JhuUtBbeYzHSomF3K6NPdCp/ZW9+/bIG/ WrqnhK0X4cGOOQMoC3SVDMLxdDctknxqifP/qTy7yeufEXxD2y0quHXOaAfe2TUiQCHL Et0hcADKAT2WuElxeIkVUUrZkPI1pvS6cV1Ja9nXMotXBaR4biCu87vzUp3CKlWKrmTo +VGQwUJLy8ADiuNv86aDZxrXE6RR51Md4ISO+Sly9nMImsUdy2C+8jP5GKg1Dymhj5+l vh4w== MIME-Version: 1.0 Received: by 10.220.220.7 with SMTP id hw7mr4335205vcb.17.1354906622557; Fri, 07 Dec 2012 10:57:02 -0800 (PST) Received: by 10.58.164.35 with HTTP; Fri, 7 Dec 2012 10:57:02 -0800 (PST) In-Reply-To: References: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> Date: Fri, 7 Dec 2012 10:57:02 -0800 Message-ID: From: Ted Hardie To: Cameron Byrne Content-Type: multipart/alternative; boundary=14dae9d24d54f0ffc804d047c792 Cc: "draft-ietf-v6ops-464xlat.all@tools.ietf.org" , "apps-discuss@ietf.org" , "Byrne, Cameron" Subject: Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 18:57:06 -0000 --14dae9d24d54f0ffc804d047c792 Content-Type: text/plain; charset=ISO-8859-1 Hi Cameron, My apologies for the delay in replying. Some further discussion in-line. On Mon, Dec 3, 2012 at 11:49 AM, Cameron Byrne wrote: > Ted, > > On Mon, Dec 3, 2012 at 10:13 AM, Ted Hardie wrote: > > On Sun, Dec 2, 2012 at 7:56 PM, Cameron Byrne > wrote: > >> Ted, > >> > >> i have revision to my previous statements > >> > > > > In-line. > > > >> On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron > > > >> > >> I believe you are right that ICE would work at the app level. > >> > >> Our statement about hub-and-spoke in the I-D was driven by wording set > >> in > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01#section-8.2 > >> > >> In this way, the NAT64 is a hub for IPv4 communications and IPv4 nodes > >> via the NAT64 can communicate with other IPv4 nodes. That is the > >> basic architecture, if you need IPv4 access, send it via the CLAT and > >> PLAT where CLAT is the spoke and PLAT is the hub > >> > >> Our claim that p2p does not work is based on the topological case that > >> if you are address 2001:DB8:9999::10.1.1.1 and i am address > >> 2001:DB8:8888::10.1.1.1 our ipv4-only nodes behind the CLAT cannot > >> send packets to each other without something like ICE to force them > >> via the NAT64 or TURN. > >> > > > > There are two cases. In the first case, the CLAT is node resident. > There, the > > CLAT-internal RFC 1918 addresses used by different nodes are > > functionally in different > > RFC 1918 instances. That's the same case we get now when different > > networks use RFC 1918, just > > much smaller. In the case where two home networks both use RFC 1918, > > in other words, > > you get the same situation--they must go out to an ICE server to have > > p2p communications even > > if they are, say, behind the same cable head end. > > > > In the second case, the CLAT is not node resident, but it is not > > running an IPv4 routing domain > > in the traditional sense; in other words, itt does not offer local > > routing among the IPv4 nodes, just > > translation to v6. Here the situations is mildly different from the > > two-home-networks-each-using-RFC1918, > > but the result from the point of the application is the same--they > > must use an ICE server to communicate. > > > > This is case the where CLAT is just a function of an otherwise normal > home gateway. I believe normal IP routing and ethernet switching will > occur for the LAN. The CLAT function only occurs WAN <-> LAN > > If this is the case, then the peer-to-peer functionality is preserved within the LAN as well. So you get it in the LAN; you lose it in the WAN (and must use ICE) and you get the standard behavior in the presence of NAT for the Internet. Is that your understanding? > > > >> If our addresses were different on the LAN like > >> 2001:DB8:9999::10.1.9.9 and 2001:DB8:8888::10.1.1.1 we could send > >> IPv4 packets to each other without the need for the hub (PLAT) since > >> each CLAT would do RFC 6145 translation and remove the first 96 bits > >> on the LAN side. This is great if there is a high chance that the > >> LAN side IPs are unique, but that is not the case and result would be > >> ipv4 packets with src = 10.1.1.1 and dst 10.1.1.1 > >> > >> The current wording in question is "The 464XLAT architecture only > >> supports IPv4 in the > >> client server model, where the server has a global IPv4 address. > >> This means it is not fit for IPv4 peer-to-peer communication or > >> inbound IPv4 connections." > >> > >> The important term is "fit" vs "not fit". Given that path would go > >> via a hub and may require ICE in the apps and infrastructure, it would > >> not really be direct p2p, and therefore the WG settle on this specific > >> language to error on the side of caution to the reader that this is > >> not a "fit" design if p2p is an important use-case in ipv4 supporting > >> ipv4. The current statement is a caution to the reader and that is > >> the reason it appears in the introduction. > >> > >> Alternatively, we can strike this from the introduction all together > >> and give a more in-depth discussion that reference ICE for the p2p > >> case. The WG decided it was best to just punt on p2p and say it does > >> not work here in the introduction. > >> > > > > Speaking personally, I don't think this is the right choice, because it > > makes it appear you are creating a new semantic for RFC 1918 addresses > > (a limited case where the usual tools for providing peer to peer > connectivity > > for them do not work). If you can't signal that new semantic, the app > > has no way of knowing whether the RFC1918 address it has is "full > service" > > (for whatever that means in the modern NAT and double NAT world) or > > "client/server only". That's making a bad situation worse. > > > > ICE is a complicated bear that no one loves much, but it is currently the > > best toolkit we have. A reference to it and a description of how this > > works with > > it seems like a better choice to me than creating a new, limited RFC > > 1918 addressing > > semantic. > > > > I agree. That is why we declared the topology to be hub and spoke in > the draft. We can add a reference to ICE providing an application > level hub and spoke architecture above the network layer hub and spoke > topology. > > does that make sense? > > Yes, I think adding the ICE reference and a more nuanced view of where peer-to-peer will work is a better way forward. In another message, you made the following comment on why you would prefer not to include discussion of squat space: "I'd rather not air my ephemeral dirty laundry in an long lived RFC :)" Understood, but the case you're dealing with--a network larger than the IPv4 address space available in the private address range--is not exactly dirty laundry, and the lack of new IPv4 allocations is well known. Those do help justify this work and might be included. That said, I am afraid I still don't see this as a BCP, in part because there is more than one way to accomplish this. DPI as a driver for this choice may be a 3GPP network-specific thumb on the scales, but I don't think this would be preferred over encapsulation-based methods in all cases. As for dirty laundry, I would personally welcome a presentation from you or your colleagues at the upcoming IETF apps area meeting on what's breaking here, as we've been recommending other referral methods and IPv6-native clients for quite some time. If we can get people to see exactly how much hoop jumping is going on in other parts of the stack to get Skype to work on a perfectly valid v6 network, it would be good. regards, Ted > CB > > regards, > > > > Ted Hardie > --14dae9d24d54f0ffc804d047c792 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cameron,

My apologies for the delay in replying.=A0 Some further = discussion in-line.

On Mon, Dec 3, 2012 a= t 11:49 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
Ted,

On Mon, Dec 3, 2012 at 10:13 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> On Sun, Dec 2, 2012 at 7:56 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
>> Ted,
>>
>> i have revision to my previous statements
>>
>
> In-line.
>
>> On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron
> <snip>
>>
>> I believe you are right that ICE would work at the app level.
>>
>> Our statement about hub-and-spoke in the I-D was driven by wording= set
>> in http://tools.ietf.org/html/draf= t-mdt-softwire-map-translation-01#section-8.2
>>
>> In this way, the NAT64 is a hub for IPv4 communications and IPv4 n= odes
>> via the NAT64 can communicate with other IPv4 nodes. =A0That is th= e
>> basic architecture, if you need IPv4 access, send it via the CLAT = and
>> PLAT where CLAT is the spoke and PLAT is the hub
>>
>> Our claim that p2p does not work is based on the topological case = that
>> if you are address 2001:DB8:9999::10.1.1.1 and i am address
>> 2001:DB8:8888::10.1.1.1 =A0our ipv4-only nodes behind the CLAT can= not
>> send packets to each other without something like ICE to force the= m
>> via the NAT64 or TURN.
>>
>
> There are two cases. =A0In the first case, the CLAT is node resident. = =A0There, the
> CLAT-internal RFC 1918 addresses used by different nodes are
> functionally in different
> RFC 1918 instances. =A0That's the same case we get now when differ= ent
> networks use RFC 1918, just
> much smaller. =A0In the case where two home networks both use RFC 1918= ,
> in other words,
> you get the same situation--they must go out to an ICE server to have<= br> > p2p communications even
> if they are, say, behind the same cable head end.
>
> In the second case, the CLAT is not node resident, but it is not
> running an IPv4 routing domain
> in the traditional sense; in other words, itt does not offer local
> routing among the IPv4 nodes, just
> translation to v6. =A0Here the situations is mildly different from the=
> two-home-networks-each-using-RFC1918,
> but the result from the point of the application is the same--they
> must use an ICE server to communicate.
>

This is case the where CLAT is just a function of an otherwise = normal
home gateway. =A0I believe normal IP routing and ethernet switching will occur for the LAN. =A0The CLAT function only occurs =A0WAN <-> LAN


If this is the= case, then the peer-to-peer functionality is preserved within
the LAN a= s well.=A0 So you get it in the LAN; you lose it in the WAN (and must
us= e ICE) and you get the standard behavior in the presence of NAT for
the Internet.=A0 Is that your understanding?
=A0
>
>> If our addresses were different on the LAN like
>> 2001:DB8:9999::10.1.9.9 and =A0 2001:DB8:8888::10.1.1.1 we could s= end
>> IPv4 packets to each other without the need for the hub (PLAT) sin= ce
>> each CLAT would do RFC 6145 translation and remove the first 96 bi= ts
>> on the =A0LAN side. =A0This is great if there is a high chance tha= t the
>> LAN side IPs are unique, but that is not the case and result would= be
>> ipv4 packets with src =3D 10.1.1.1 and dst 10.1.1.1
>>
>> The current wording in question is "The 464XLAT architecture = only
>> supports IPv4 in the
>> =A0 =A0client server model, where the server has a global IPv4 add= ress.
>> =A0 =A0This means it is not fit for IPv4 peer-to-peer communicatio= n or
>> =A0 =A0inbound IPv4 connections."
>>
>> The important term is "fit" vs "not fit". =A0G= iven that path would go
>> via a hub and may require ICE in the apps and infrastructure, it w= ould
>> not really be direct p2p, and therefore the WG settle on this spec= ific
>> language to error on the side of caution to the reader that this i= s
>> not a "fit" design if p2p is an important use-case in ip= v4 supporting
>> ipv4. =A0The current statement is a caution to the reader and that= is
>> the reason it appears in the introduction.
>>
>> Alternatively, we can strike this from the introduction all togeth= er
>> and give a more in-depth discussion that reference ICE for the p2p=
>> case. =A0The WG decided it was best to just punt on p2p and say it= does
>> not work here in the introduction.
>>
>
> Speaking personally, I don't think this is the right choice, becau= se it
> makes it appear you are creating a new semantic for RFC 1918 addresses=
> (a limited case where the usual tools for providing peer to peer conne= ctivity
> for them do not work). =A0If you can't signal that new semantic, t= he app
> has no way of knowing whether the RFC1918 address it has is "full= service"
> (for whatever that means in the modern NAT and double NAT world) or > "client/server only". =A0That's making a bad situation w= orse.
>
> ICE is a complicated bear that no one loves much, but it is currently = the
> best toolkit we have. =A0A reference to it and a description of how th= is
> works with
> it seems like a better choice to me than creating a new, limited RFC > 1918 addressing
> semantic.
>

I agree. =A0That is why we declared the topology to be hub and = spoke in
the draft. =A0We can add a reference to ICE providing an application
level hub and spoke architecture above the network layer hub and spoke
topology.

does that make sense?


Yes,=A0 I think adding the ICE reference and a mo= re nuanced view of where
peer-to-peer will work is a better way forward.=

In another message, you made the following comment on why you would=
prefer not to include discussion of squat space:

"I'd rathe= r not air my ephemeral dirty laundry in an long lived RFC =A0:)"
Understood, but the case you're dealing with--a network larger than t= he
IPv4 address space available in the private address range--is not exactlydirty laundry, and the lack of new IPv4 allocations is well known.=A0 Tho= se
do help justify this work and might be included.

That said, I = am afraid I still don't see this as a BCP, in part because there is
more than one way to accomplish this.=A0 DPI as a driver for this choice ma= y be
a 3GPP network-specific thumb on the scales, but I don't think = this would
be preferred over encapsulation-based methods in all cases.
As for dirty laundry, I would personally welcome a presentation from yo= u
or your colleagues at the upcoming IETF apps area meeting on what'= s breaking here,
as we've been recommending other referral methods a= nd IPv6-native
clients for quite some time.=A0 If we can get people to see exactly how
= much hoop jumping is going on in other parts of the stack to get Skype
t= o work on a perfectly valid v6 network, it would be good.

regards,
Ted
=A0
CB
> regards,
>
> Ted Hardie

--14dae9d24d54f0ffc804d047c792-- From cb.list6@gmail.com Fri Dec 7 11:33:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10F921F8829 for ; Fri, 7 Dec 2012 11:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpGmgjZJ6Z-l for ; Fri, 7 Dec 2012 11:33:37 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B41A521F881E for ; Fri, 7 Dec 2012 11:33:25 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so680736lah.31 for ; Fri, 07 Dec 2012 11:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2FxZY+ivJ76h/fn97yfk7n3iuYbh8Wmar0VDIKZgAeU=; b=N5VA5fmuvnBtUEdVDfPolLIWKIXbL8aMl1GBBd4tk9pT7D6cknX7z8l93VzjKcWlgX 4RFFeFeosSJO9CC7U+UpnLRaLbemf2d6i1qPhPL+angLcjF5Oz+r4ScL7nFWACTuCdpi REkI0T6NQj0hZsLJm5EvU+CWpCPVoH2O/HmSWY76cZgPFFUZL/wSsk2ZSbZM7YsrNo9U aQjrOU7ZyPyMPoEQ3v9YMZK2PGgnt2Jn79zTUNeOVarIZRk0p64fwVw+eNceKM//58F3 qTPhzBY9MzAyz4fsHGpanYKTG9PR6+DNlKQPxqSZc8/2EC948o4UCGelfqKQ9kENb2bM lpwA== MIME-Version: 1.0 Received: by 10.152.124.226 with SMTP id ml2mr6309537lab.46.1354908804714; Fri, 07 Dec 2012 11:33:24 -0800 (PST) Received: by 10.112.44.36 with HTTP; Fri, 7 Dec 2012 11:33:24 -0800 (PST) In-Reply-To: References: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> Date: Fri, 7 Dec 2012 11:33:24 -0800 Message-ID: From: Cameron Byrne To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-ietf-v6ops-464xlat.all@tools.ietf.org" , "apps-discuss@ietf.org" , "Byrne, Cameron" Subject: Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:33:41 -0000 Ted, On Fri, Dec 7, 2012 at 10:57 AM, Ted Hardie wrote: > Hi Cameron, > > My apologies for the delay in replying. Some further discussion in-line. > > On Mon, Dec 3, 2012 at 11:49 AM, Cameron Byrne wrote: >> >> Ted, >> >> On Mon, Dec 3, 2012 at 10:13 AM, Ted Hardie wrote: >> > On Sun, Dec 2, 2012 at 7:56 PM, Cameron Byrne >> > wrote: >> >> Ted, >> >> >> >> i have revision to my previous statements >> >> >> > >> > In-line. >> > >> >> On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron >> > >> >> >> >> I believe you are right that ICE would work at the app level. >> >> >> >> Our statement about hub-and-spoke in the I-D was driven by wording set >> >> in >> >> http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01#section-8.2 >> >> >> >> In this way, the NAT64 is a hub for IPv4 communications and IPv4 nodes >> >> via the NAT64 can communicate with other IPv4 nodes. That is the >> >> basic architecture, if you need IPv4 access, send it via the CLAT and >> >> PLAT where CLAT is the spoke and PLAT is the hub >> >> >> >> Our claim that p2p does not work is based on the topological case that >> >> if you are address 2001:DB8:9999::10.1.1.1 and i am address >> >> 2001:DB8:8888::10.1.1.1 our ipv4-only nodes behind the CLAT cannot >> >> send packets to each other without something like ICE to force them >> >> via the NAT64 or TURN. >> >> >> > >> > There are two cases. In the first case, the CLAT is node resident. >> > There, the >> > CLAT-internal RFC 1918 addresses used by different nodes are >> > functionally in different >> > RFC 1918 instances. That's the same case we get now when different >> > networks use RFC 1918, just >> > much smaller. In the case where two home networks both use RFC 1918, >> > in other words, >> > you get the same situation--they must go out to an ICE server to have >> > p2p communications even >> > if they are, say, behind the same cable head end. >> > >> > In the second case, the CLAT is not node resident, but it is not >> > running an IPv4 routing domain >> > in the traditional sense; in other words, itt does not offer local >> > routing among the IPv4 nodes, just >> > translation to v6. Here the situations is mildly different from the >> > two-home-networks-each-using-RFC1918, >> > but the result from the point of the application is the same--they >> > must use an ICE server to communicate. >> > >> >> This is case the where CLAT is just a function of an otherwise normal >> home gateway. I believe normal IP routing and ethernet switching will >> occur for the LAN. The CLAT function only occurs WAN <-> LAN >> > > If this is the case, then the peer-to-peer functionality is preserved within > the LAN as well. So you get it in the LAN; you lose it in the WAN (and must > use ICE) and you get the standard behavior in the presence of NAT for > the Internet. Is that your understanding? > Yes, that is my understanding. >> >> > >> >> If our addresses were different on the LAN like >> >> 2001:DB8:9999::10.1.9.9 and 2001:DB8:8888::10.1.1.1 we could send >> >> IPv4 packets to each other without the need for the hub (PLAT) since >> >> each CLAT would do RFC 6145 translation and remove the first 96 bits >> >> on the LAN side. This is great if there is a high chance that the >> >> LAN side IPs are unique, but that is not the case and result would be >> >> ipv4 packets with src = 10.1.1.1 and dst 10.1.1.1 >> >> >> >> The current wording in question is "The 464XLAT architecture only >> >> supports IPv4 in the >> >> client server model, where the server has a global IPv4 address. >> >> This means it is not fit for IPv4 peer-to-peer communication or >> >> inbound IPv4 connections." >> >> >> >> The important term is "fit" vs "not fit". Given that path would go >> >> via a hub and may require ICE in the apps and infrastructure, it would >> >> not really be direct p2p, and therefore the WG settle on this specific >> >> language to error on the side of caution to the reader that this is >> >> not a "fit" design if p2p is an important use-case in ipv4 supporting >> >> ipv4. The current statement is a caution to the reader and that is >> >> the reason it appears in the introduction. >> >> >> >> Alternatively, we can strike this from the introduction all together >> >> and give a more in-depth discussion that reference ICE for the p2p >> >> case. The WG decided it was best to just punt on p2p and say it does >> >> not work here in the introduction. >> >> >> > >> > Speaking personally, I don't think this is the right choice, because it >> > makes it appear you are creating a new semantic for RFC 1918 addresses >> > (a limited case where the usual tools for providing peer to peer >> > connectivity >> > for them do not work). If you can't signal that new semantic, the app >> > has no way of knowing whether the RFC1918 address it has is "full >> > service" >> > (for whatever that means in the modern NAT and double NAT world) or >> > "client/server only". That's making a bad situation worse. >> > >> > ICE is a complicated bear that no one loves much, but it is currently >> > the >> > best toolkit we have. A reference to it and a description of how this >> > works with >> > it seems like a better choice to me than creating a new, limited RFC >> > 1918 addressing >> > semantic. >> > >> >> I agree. That is why we declared the topology to be hub and spoke in >> the draft. We can add a reference to ICE providing an application >> level hub and spoke architecture above the network layer hub and spoke >> topology. >> >> does that make sense? >> > > Yes, I think adding the ICE reference and a more nuanced view of where > peer-to-peer will work is a better way forward. > Will do. > In another message, you made the following comment on why you would > prefer not to include discussion of squat space: > > > "I'd rather not air my ephemeral dirty laundry in an long lived RFC :)" > > Understood, but the case you're dealing with--a network larger than the > IPv4 address space available in the private address range--is not exactly > dirty laundry, and the lack of new IPv4 allocations is well known. Those > do help justify this work and might be included. > Yes, stating it as: Many large and fast growing edge networks exceed the size of the available private IPv4 address space, and thus must choose between a variety technical comprises within IPv4 or an immediate transition to IPv6 with an enabling technology such as 464XLAT. > That said, I am afraid I still don't see this as a BCP, in part because > there is > more than one way to accomplish this. DPI as a driver for this choice may > be > a 3GPP network-specific thumb on the scales, but I don't think this would > be preferred over encapsulation-based methods in all cases. > Anything tunnels or DHCP based (including DS-lite and MAP) will not work in 3GPP, that barriers are too high. 464XLAT navigates the barriers and is running code with interests from many operators. But from a 10,000 foot view, 464XLAT is not a glorious, obvious, or elegant creation, it is just the tool to get the job done. It helps us move IPv6 forward. That said, the authors of 464XLAT accept whatever the IESG approves. CB > As for dirty laundry, I would personally welcome a presentation from you > or your colleagues at the upcoming IETF apps area meeting on what's breaking > here, > as we've been recommending other referral methods and IPv6-native > clients for quite some time. If we can get people to see exactly how > much hoop jumping is going on in other parts of the stack to get Skype > to work on a perfectly valid v6 network, it would be good. > > regards, > > Ted > >> >> CB >> > regards, >> > >> > Ted Hardie > > From sm@elandsys.com Fri Dec 7 15:02:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3180721F871F for ; Fri, 7 Dec 2012 15:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+zLda+hal9c for ; Fri, 7 Dec 2012 15:02:43 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 992CB21F866C for ; Fri, 7 Dec 2012 15:02:43 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.129.85]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qB7N2UTa023606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Dec 2012 15:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1354921361; bh=RMS+zAk/hDz1+aCP34Vdbjv2lDCgihT0Y6fjbvsBOow=; h=Date:To:From:Subject:Cc; b=HsCqoX5IcJKG+DlyHVOZu4XmXsO7xrp1fBzPnYTvsoFyVuyWU3Hl9J2Cx2hpO3YwL qN3GF3cJIOnrjSK6Dj8irH5Mb6x39xywK41t/xBccL/yhVfgB/A5vY425oNkVS+zvd 2zJckAROExauby1sHvVWfwWRroex209UYTFtW/Dw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1354921361; i=@elandsys.com; bh=RMS+zAk/hDz1+aCP34Vdbjv2lDCgihT0Y6fjbvsBOow=; h=Date:To:From:Subject:Cc; b=leeLC6va4pLrb8ySIM3cX9qgBiodFGv3kaUlMiTH8hAjTefxljbJTqVx4EP4Mx/rV LEC5HTJCSowYaUBjw0exDebyznIQltrYJFwMV6AaGepQNc9hL0H4rQYnqzeNPTWJ1T a1vdvnUm+jNavBfqxzPrb7S8L1i7EQbsKY8dew9Y= Message-Id: <6.2.5.6.2.20121207145600.0b4fa678@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Dec 2012 15:01:37 -0800 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Directorate report for November 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:02:44 -0000 The Applications Area Directorate provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The directorate consists of the Working Group Chairs of the Applications Area and recognized experts in the Applications Area. The following review were performed in November 2012: Reviewer I-D Mark Nottingham draft-ietf-pkix-est-03 Henry S. Thompson draft-ietf-appsawg-json-patch-06 Eliot Lear draft-ietf-tcpm-experimental-options-02 Claudio Allocchio draft-ietf-mptcp-api-06 Murray Kucherawy draft-ietf-imapmove-command Jiankang Yao draft-ietf-v6ops-icp-guidance-04 Larry Masinter draft-salgueiro-vcarddav-kind-device-03 Alexey Melnikov draft-ietf-sipcore-sip-websocket-06 Yves Lafon draft-ietf-6man-uri-zoneid-05 Salvatore Loreto draft-ietf-ppsp-problem-statement-11 Ted Hardie draft-ietf-v6ops-464xlat-08 Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From brian.e.carpenter@gmail.com Sat Dec 8 00:19:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D9B21F85E8; Sat, 8 Dec 2012 00:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.359 X-Spam-Level: X-Spam-Status: No, score=-101.359 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM73qN-lA-sZ; Sat, 8 Dec 2012 00:19:01 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 041E021F85DB; Sat, 8 Dec 2012 00:19:00 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so115803wib.13 for ; Sat, 08 Dec 2012 00:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rSpSAC4TX7UZT8D5jt0OT4DajhQrZOJSofZjqZxfCU0=; b=pkR00wDdF77+hgkI62VO5C8hU3MjdsIXZlcZO143DGC1tror5GUxjB3+1gRHJ946tU VoZ1bPsXO+KOHOUdtBk6PSVmFEUQALBfffEg8zq48B3H5ULbvy1xOxvMJm5y0HmMlzwN ZwFRPSbJey+oWqWVHuNp86L2VaBFzsWiy+foddSYrztLbkpwA5uzGJUurl4oaddhCSWX tEFvTqlltV0dZt7JcAOd1n7lAGq1x2a8hyj1p4zdZZz6rvVw0hMgWO7PFQBZ0VnBvLtR CHdxU4XdCwQW8k7C005WqOsb3KsIvjPHw5A0O15ybWAhB8kbsfM797CHomFmy1Bb8u+D Zeag== Received: by 10.180.102.101 with SMTP id fn5mr2173573wib.19.1354954740109; Sat, 08 Dec 2012 00:19:00 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-203.as13285.net. [2.102.217.203]) by mx.google.com with ESMTPS id u6sm1523738wif.2.2012.12.08.00.18.57 (version=SSLv3 cipher=OTHER); Sat, 08 Dec 2012 00:18:58 -0800 (PST) Message-ID: <50C2F802.1040209@gmail.com> Date: Sat, 08 Dec 2012 08:19:14 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "t.petch" References: <50B3967F.7040205@gmail.com> <042c01cdd4a6$da9b8fa0$4001a8c0@gateway.2wire.net> In-Reply-To: <042c01cdd4a6$da9b8fa0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-uri-zoneid@tools.ietf.org, appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 08:19:02 -0000 Tom, On 07/12/2012 18:15, t.petch wrote: > ----- Original Message ----- > From: "Brian E Carpenter" > To: "Yves Lafon" > Cc: ; ; > ; > Sent: Monday, November 26, 2012 4:19 PM > ... >>> Does it mean that such URIs can be present in an HTML document or that >>> they MAY allow bare "%" signs when the URI is pasted in the address bar? >>> (Those are two different use cases, and browsers may have different code >>> paths for both). >> This is exactly why I suggested in the "New URL Standard..." thread >> on the IETF list that we need a formal distinction between URI syntax >> and the permitted "syntax" for user input strings. Without that >> distinction, we are obliged to specify them both as if they were >> the same thing. I really don't know how to capture this in the current >> draft. > > Brian > > My take on that thread is somewhat different, namely that there is a > distinction, that the IETF defines the valid output of the process and > has never specified the input or processing thereof, leaving every web > browser to exercise its skill and judgment thereon. > (Roy Fielding did say > "I have absolutely no problem with writing a proposed standard > for parsing references, particularly if browser developers are > willing to adhere to one." > and > "It is not non-interoperable behavior to parse input data > differently depending on the context in which it is entered.") > > In which case, you can spell that out in this I-D. We've changed the text in that area in draft-ietf-6man-uri-zoneid-06, which has just come out. However, I think we'll leave the general problem for the Apps Area and the W3C to resolve. Regards Brian From sm@resistor.net Sun Dec 9 12:13:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C5621F8CE9 for ; Sun, 9 Dec 2012 12:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRm0ME3-9mkS for ; Sun, 9 Dec 2012 12:13:13 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8348421F8CDF for ; Sun, 9 Dec 2012 12:13:13 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qB9KD3Gs023946; Sun, 9 Dec 2012 12:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1355083987; bh=60PGLaR6nTY0l6IHv4C68w6lPzbe09lcnBDu1/Uchx4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=F9c0kSoqW4/3ZXAJXclTFbGFwW01EF124NzY7ya1eU02M62RKYqM7dvMoBxGOBtMn THL7I3w+tTZdjEk+Ji9LBkjKoO+GrhM+hI9JQLEv2Hs74Zrmoe0Xva/XUz1koNb9Yd niKyYnZbZb5GIk9U3mZOs+5TYzLNPf0dujMZsalE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1355083987; i=@resistor.net; bh=60PGLaR6nTY0l6IHv4C68w6lPzbe09lcnBDu1/Uchx4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hhFoB0HAgl9csMP6y1b1qlXaYIDLdmhXE5bjpCU+b0u9rASht8zPU6BfMZb4pzdf4 x50U9HaFb+CsToyp7C35j00IAQVtye0TqMxAwnKzpChcEAuMOCqQPTTcYbLkWlcPyG /rPob6diXT+6gYw2mKlXnfz5mNks5TkHUGRwMCis= Message-Id: <6.2.5.6.2.20121209120249.094c9af0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 09 Dec 2012 12:12:32 -0800 To: Cameron Byrne From: SM In-Reply-To: References: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] Other parts of the stack (was: Review of draft-ietf-v6ops-464xlat-08) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 20:13:14 -0000 Hi Cameron, At 10:57 07-12-2012, Ted Hardie wrote: >As for dirty laundry, I would personally welcome a presentation from you >or your colleagues at the upcoming IETF apps area meeting on what's >breaking here, >as we've been recommending other referral methods and IPv6-native >clients for quite some time. If we can get people to see exactly how >much hoop jumping is going on in other parts of the stack to get Skype >to work on a perfectly valid v6 network, it would be good. Having such a presentation is a good idea in my humble opinion. Skype would be an interesting case study. Regards, -sm From Claudio.Allocchio@garr.it Sun Dec 9 13:23:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED1621F8D26 for ; Sun, 9 Dec 2012 13:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPxky3NgErHl for ; Sun, 9 Dec 2012 13:23:41 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0796421F8D23 for ; Sun, 9 Dec 2012 13:23:40 -0800 (PST) Received: internal info suppressed Date: Sun, 9 Dec 2012 22:23:35 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: SM In-Reply-To: <6.2.5.6.2.20121209120249.094c9af0@resistor.net> Message-ID: References: <1F4ED938D73A4242BBBB1E7DD492EA0C168EAB5BD9@PMBX03.gsm1900.org> <6.2.5.6.2.20121209120249.094c9af0@resistor.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1355088218; bh=I6L3qK2tAgilgKNaGJ2kLmAigRFSC++5UcJenL/QpgE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KZB9o7JjQra+3PbritU3zhbFA06hYecMVOBuFmISScTgnf2wsaWx2fcXnklz/l8rn riBCYa3hy5Z95zGdboUXa8ugGMZerrGuzvlNKyuyu8ajJ6eeUcbYE8olPQ/Cj6tlef RFG5k2qIvcFP9W2gY34MXgMgSondit41O7mBgdfo= Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Other parts of the stack (was: Review of draft-ietf-v6ops-464xlat-08) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 21:23:42 -0000 On Sun, 9 Dec 2012, SM wrote: > Hi Cameron, > At 10:57 07-12-2012, Ted Hardie wrote: >> As for dirty laundry, I would personally welcome a presentation from you >> or your colleagues at the upcoming IETF apps area meeting on what's >> breaking here, >> as we've been recommending other referral methods and IPv6-native >> clients for quite some time. If we can get people to see exactly how >> much hoop jumping is going on in other parts of the stack to get Skype >> to work on a perfectly valid v6 network, it would be good. > > Having such a presentation is a good idea in my humble opinion. Skype would > be an interesting case study. ... and a big push for reluctant ISPs to enable IPv6 :-) hopfully... > > Regards, > -sm > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From mnot@mnot.net Sun Dec 9 21:18:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9032A21F8DFD for ; Sun, 9 Dec 2012 21:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.052 X-Spam-Level: X-Spam-Status: No, score=-104.052 tagged_above=-999 required=5 tests=[AWL=-1.453, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFv26sno0vZf for ; Sun, 9 Dec 2012 21:18:57 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE9521F8DFE for ; Sun, 9 Dec 2012 21:18:57 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.242.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C893D22E1FA for ; Mon, 10 Dec 2012 00:18:50 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Dec 2012 16:18:47 +1100 References: <20121210051806.4232.34297.idtracker@ietfa.amsl.com> To: Apps Discuss Message-Id: <87ECF944-7221-4FC3-966F-EA8381808CD7@mnot.net> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-problem-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 05:18:58 -0000 FYI, lots of changes in this one. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-http-problem-02.txt > Date: 10 December 2012 4:18:06 PM AEDT > To: mnot@mnot.net >=20 >=20 > A new version of I-D, draft-nottingham-http-problem-02.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-http-problem > Revision: 02 > Title: Problem Details for HTTP APIs > Creation date: 2012-12-10 > WG ID: Individual Submission > Number of pages: 11 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-http-problem-02.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-http-problem > Htmlized: = http://tools.ietf.org/html/draft-nottingham-http-problem-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-problem-02 >=20 > Abstract: > This document defines a "problem detail" as an extensible way to > carry machine-readable details of errors in a HTTP response, to = avoid > the need to invent new response formats for HTTP APIs. >=20 > Note to Readers >=20 > This draft should be discussed on the apps-discuss mailing list [1]. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- Mark Nottingham http://www.mnot.net/ From sm@elandsys.com Mon Dec 10 11:13:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D3421F85AF; Mon, 10 Dec 2012 11:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOG6Rzgn5CPZ; Mon, 10 Dec 2012 11:13:26 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CFE21F84EE; Mon, 10 Dec 2012 11:13:26 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.130.164]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qBAJDA9F004711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2012 11:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1355166804; bh=KlDKiEtb3vfgpVbOjf4CxL+ShFUQ8M1Ea8KqO07edMo=; h=Date:To:From:Subject:Cc; b=rgxpMVrLNAzLGlt2zF8u/t8Hf2N3uoSBEmbnAHyhB+0hOFrZ9sDpJMkphfEkSrrhr q4OcmOWMjb5ui1TVnamXcj0J6I0ORnvkHHRbB/YKPzMsQ7dYeHAREjiSJUeWWfAVpX S3PTyJyFZLuIsxEuha3rpyN/4gxXXAMkSFaKBYQY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1355166804; i=@elandsys.com; bh=KlDKiEtb3vfgpVbOjf4CxL+ShFUQ8M1Ea8KqO07edMo=; h=Date:To:From:Subject:Cc; b=d9LLtor8pZLeiDPa/oCB4bR6y3u6NGv223N8kl7oUpdq2l45j3BfqeWpvY5zBCTW5 yq4o2hgYBRMyZ3Xba9RqU4GpFQgEDlysx6zLm4/SfiyXKmNScIQPmA/6eKIMkWjNK9 29AvBoSWMiDdRUopszKT+mmdjeEuyBshjCHlgL4w= Message-Id: <6.2.5.6.2.20121210081849.09d63058@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 10 Dec 2012 11:08:20 -0800 To: apps-discuss@ietf.org, iesg@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: 6renum@ietf.org, draft-ietf-6renum-enterprise.all@tools.ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-6renum-enterprise-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 19:13:27 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6renum-enterprise-04 Title: IPv6 Enterprise Network Renumbering Scenarios and Guidelines Reviewer: S. Moonesamy Review Date: December 10, 2012 IETF Last Call Date: November 28, 2012 IESG Telechat Date: December 13, 2012 Summary: This document is almost ready for publication as an Informational RFC. The document focuses on enterprise network renumbering. Most of the analysis is also applicable to ISP network renumbering. The impact on applications is the reconfiguration of application services when a network is renumbered. There isn't any discussion of the application services angle in the document. Major Issues: After reading the document several times I was left with a sense that there is an unclear picture. The preparations for renumbering seem to be mainly about DNS and identifying long-lived sessions. I rate this review as poor as I found it difficult to grasp how Section 4 fits in with the rest of the document. Figure 1 in Section 2 has an "APP server". Section 4.1 mentions that: "Manual-configured addresses are not scalable in medium to large sites, hence are out of scope. Manually-configured addresses/hosts should be avoided as much as possible." I understand that manual configuration of addresses is not scalable. There is a discussion which may be relevant for application servers in draft-ietf-6renum-static-problem. I suggest adding some text to clarify the APP server angle. Minor Issues: In Section 4.1: "In general, Fully-Qualified Domain Names (FQDNs) are recommended to be used to configure network connectivity, such as tunnels, servers etc. The capability to use FQDNs as endpoint names has been standardized in several RFCs, such as [RFC5996], although many system/network administrators do not realize that it is there and works well as a way to avoid manual modification during renumbering." The usage of FQDNs is only useful to identify endpoint names. Application servers are generally assigned static IP addresses. Manual configuration of application services is sometimes needed during renumbering. There are possible issues when an application service relies on DNS (e.g. http://httpd.apache.org/docs/2.2/dns-caveats.html ). Nits: In Section 3.1: "The enterprise network switches to a new ISP. When this occurs, the enterprise stop numbering its resources form the prefix" There is a typo for "from". Regards, S. Moonesamy From internet-drafts@ietf.org Mon Dec 10 20:23:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488DB21F86CD; Mon, 10 Dec 2012 20:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPI6rTZGR68Q; Mon, 10 Dec 2012 20:23:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22D221F86D8; Mon, 10 Dec 2012 20:23:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121211042312.18410.4921.idtracker@ietfa.amsl.com> Date: Mon, 10 Dec 2012 20:23:12 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 04:23:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Pointer Author(s) : Paul C. Bryan Kris Zyp Mark Nottingham Filename : draft-ietf-appsawg-json-pointer-07.txt Pages : 8 Date : 2012-12-10 Abstract: JSON Pointer defines a string syntax for identifying a specific value within a JSON document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-pointer-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Dec 10 20:23:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7BC21F8734; Mon, 10 Dec 2012 20:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnld8zJ3Hh0S; Mon, 10 Dec 2012 20:23:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCC321F86DD; Mon, 10 Dec 2012 20:23:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121211042315.18410.76565.idtracker@ietfa.amsl.com> Date: Mon, 10 Dec 2012 20:23:15 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 04:23:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Patch Author(s) : Paul C. Bryan Mark Nottingham Filename : draft-ietf-appsawg-json-patch-08.txt Pages : 17 Date : 2012-12-10 Abstract: JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document, suitable for use with the HTTP PATCH method. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Tue Dec 11 07:00:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318ED21F8841; Tue, 11 Dec 2012 07:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to+0VwLGf2V9; Tue, 11 Dec 2012 07:00:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A08821F8784; Tue, 11 Dec 2012 07:00:05 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> Date: Tue, 11 Dec 2012 07:00:05 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 15:00:06 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'JSON Patch' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document, suitable for use with the HTTP PATCH method. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Dec 11 07:00:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF4121F8863; Tue, 11 Dec 2012 07:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXdD7TfwSyLy; Tue, 11 Dec 2012 07:00:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBAD21F883F; Tue, 11 Dec 2012 07:00:58 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> Date: Tue, 11 Dec 2012 07:00:57 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 15:00:58 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'JSON Pointer' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract JSON Pointer defines a string syntax for identifying a specific value within a JSON document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ No IPR declarations have been submitted directly on this I-D. From barryleiba.mailing.lists@gmail.com Tue Dec 11 07:25:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B4021F881A; Tue, 11 Dec 2012 07:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.094 X-Spam-Level: X-Spam-Status: No, score=-103.094 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC9xQD2jWMhQ; Tue, 11 Dec 2012 07:25:59 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84E0C21F8815; Tue, 11 Dec 2012 07:25:58 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3319883lbk.31 for ; Tue, 11 Dec 2012 07:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=fTJ65mUqmvsYLh3gEWkY6L7PMonGsKL1RCQ1ayttsjo=; b=fltTwEZmb0i14mbPls9Timwe1Kq70cqhJx8A2Se3zI3hl/f/Rf+SfRFAr2f3f53lQ7 P0gF2uMlRu9Dw0fReTJ2luYq6xHJPg9HKlE9j2YyFL1CtZGt/ClcjpNL0pBXWRTPIokY RbD12kNcGSIpTGe7wGEngKFZ30JMq8697xLrKFz39FpzUlAbmSqwORiQqqE5eHtw+efo QHb/pS0H8f9ged19mCM/lkZjT32Pors2URlMWq59qvRimuP+gXownnlwgijfsqEZVbTl rvXZMASpB/caKSGvxJ9w/V+Gc0l7MvAqdK2Stxhtp3OLJzNJoS9wqFADZpbrxel9vApz l4aQ== MIME-Version: 1.0 Received: by 10.112.25.34 with SMTP id z2mr7677167lbf.125.1355239557492; Tue, 11 Dec 2012 07:25:57 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Tue, 11 Dec 2012 07:25:57 -0800 (PST) In-Reply-To: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> Date: Tue, 11 Dec 2012 10:25:57 -0500 X-Google-Sender-Auth: N71ui7HSiSdpSu_2bo6qGeIvU_4 Message-ID: From: Barry Leiba To: IETF discussion list , "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 15:25:59 -0000 > Abstract > JSON Patch defines the media type "application/json-patch", a JSON > document structure for expressing a sequence of operations to apply > to a JSON document, suitable for use with the HTTP PATCH method. ... > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch/ I've reviewed JSON Patch and JSON Pointer as responsible AD, and am very happy with the documents -- this is good work, well written. I came up with one issue that I want to discuss as part of last call: 4.1. add The "add" operation adds a new value at the target location. The operation object MUST contain a "value" member that specifies the value to be added. For example: { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] } When the operation is applied, the target location MUST reference one of: o The root of the target document - whereupon the specified value becomes the entire content of the target document. Now, what this means is that if we start with this: { "a": { "num": 1 } } and we apply this: { "op": "add", "path": "", "value": [ "foo", "bar" ] } we end up with this: [ "foo", "bar" ] This doesn't strike me as having any sense of an "add" operation -- it appears to be a special case that doesn't fit. In any other situation, using any other path, the operation either adds something to what's already there, or it fails. But when the path is "", it's anomalous. So, three questions: 1. Do I have this right, or am I mistaken about the result of that operation? 2. Assuming I have it right, can someone explain why it's this way? 3. Can someone explain why this is the right way to specify it, rather than using "replace" for this? Barry From jasnell@gmail.com Tue Dec 11 09:22:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B5A21F84CD; Tue, 11 Dec 2012 09:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.834 X-Spam-Level: X-Spam-Status: No, score=-3.834 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP35wJcQMseR; Tue, 11 Dec 2012 09:22:43 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42B21F84CA; Tue, 11 Dec 2012 09:22:38 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id qd14so12938194ieb.6 for ; Tue, 11 Dec 2012 09:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=55steGPZ4XVOvlwQHjlGVsQWc408AgC8tnGDfyBdyf0=; b=Lc8bBBS8eV/p/FKdzm5MzLpTmwz41P+v6RQhufw0Am0cO/c/7y5l/8zM4tYojP/9wZ SVMajKW14I2TX7jvmZ2cRA2EDBJMXkiZRlIDqqbkkDdGgxt1eNxUEhwecCPGUt0H/5Gn rKvoohb1mJz0/Kj5eCf5NueVZlkz3fXsY4RDA/wYpy1d3E8Y/Te2+Uk7zlnfDhgQ9Lmt 0sEEN3ZajFRdxPb7ekucQltYBSEIxPBmxarwHzcx4EG2IFQQY9IgydDyOSV0fe5xKt+d pLNL0ZGAQAHLcQRunCb87mpDceQr/SR055qGMscG0ahyc07h9KPeJEHwUh6orgdNhpdg PKIQ== Received: by 10.50.151.165 with SMTP id ur5mr3032978igb.24.1355246554595; Tue, 11 Dec 2012 09:22:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Tue, 11 Dec 2012 09:22:14 -0800 (PST) In-Reply-To: References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> From: James M Snell Date: Tue, 11 Dec 2012 09:22:14 -0800 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=e89a8f23541d78414c04d096ed35 Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 17:22:45 -0000 --e89a8f23541d78414c04d096ed35 Content-Type: text/plain; charset=UTF-8 You are reading it correctly. Note also that the very next bullet point says: A member to add to an existing object - whereupon the supplied value is added to that object at the indicated location. If the member already exists, it is replaced by the specified value. So an "add" is really a "replace" that does not have the "target location MUST exist" restriction. Personally, I'm not too fond of that decision. For anything other than an array, "add" should fail if the target already exists. For arrays, "add" should insert but never replace an existing value. - James On Tue, Dec 11, 2012 at 7:25 AM, Barry Leiba wrote: > > Abstract > > JSON Patch defines the media type "application/json-patch", a JSON > > document structure for expressing a sequence of operations to apply > > to a JSON document, suitable for use with the HTTP PATCH method. > ... > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch/ > > I've reviewed JSON Patch and JSON Pointer as responsible AD, and am > very happy with the documents -- this is good work, well written. I > came up with one issue that I want to discuss as part of last call: > > 4.1. add > > The "add" operation adds a new value at the target location. The > operation object MUST contain a "value" member that specifies the > value to be added. > > For example: > > { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] } > > When the operation is applied, the target location MUST reference one > of: > > o The root of the target document - whereupon the specified value > becomes the entire content of the target document. > > Now, what this means is that if we start with this: > > { "a": { "num": 1 } } > > and we apply this: > > { "op": "add", "path": "", "value": [ "foo", "bar" ] } > > we end up with this: > > [ "foo", "bar" ] > > This doesn't strike me as having any sense of an "add" operation -- it > appears to be a special case that doesn't fit. In any other > situation, using any other path, the operation either adds something > to what's already there, or it fails. But when the path is "", it's > anomalous. > > So, three questions: > > 1. Do I have this right, or am I mistaken about the result of that > operation? > > 2. Assuming I have it right, can someone explain why it's this way? > > 3. Can someone explain why this is the right way to specify it, rather > than using "replace" for this? > > Barry > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8f23541d78414c04d096ed35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You are reading it correctly. Note als= o that the very next bullet point says:=C2=A0

=C2=A0 A member to add to an existing object - whereupon the supplied
=
=C2=A0 value is added to that object at the indicated location. =C2=A0= If the
=C2=A0 member already exists, it is replaced by the specif= ied value.

So an "add" is really a "replace" t= hat does not have the "target location MUST exist" restriction. P= ersonally, I'm not too fond of that decision. For anything other than a= n array, "add" should fail if the target already exists. For arra= ys, "add" should insert but never replace an existing value.=C2= =A0

- James

On Tue, Dec 11, 2012 at 7:25 AM, Barry Lei= ba <barryleiba@computer.org> wrote:
> Abstract
> =C2=A0 =C2=A0JSON Patch defines the media type "application/json-= patch", a JSON
> =C2=A0 =C2=A0document structure for expressing a sequence of operation= s to apply
> =C2=A0 =C2=A0to a JSON document, suitable for use with the HTTP PATCH = method.
...
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-j= son-patch/

I've reviewed JSON Patch and JSON Pointer as responsible AD, and am
very happy with the documents -- this is good work, well written. =C2=A0I came up with one issue that I want to discuss as part of last call:

=C2=A0 =C2=A04.1. =C2=A0add

=C2=A0 =C2=A0The "add" operation adds a new value at the target l= ocation. =C2=A0The
=C2=A0 =C2=A0operation object MUST contain a "value" member that = specifies the
=C2=A0 =C2=A0value to be added.

=C2=A0 =C2=A0For example:

=C2=A0 =C2=A0{ "op": "add", "path": "/a/= b/c", "value": [ "foo", "bar" ] }

=C2=A0 =C2=A0When the operation is applied, the target location MUST refere= nce one
=C2=A0 =C2=A0of:

=C2=A0 =C2=A0o =C2=A0The root of the target document - whereupon the specif= ied value
=C2=A0 =C2=A0 =C2=A0 becomes the entire content of the target document.

Now, what this means is that if we start with this:

{ "a": { "num": 1 } }

and we apply this:

{ "op": "add", "path": "", "va= lue": [ "foo", "bar" ] }

we end up with this:

[ "foo", "bar" ]

This doesn't strike me as having any sense of an "add" operat= ion -- it
appears to be a special case that doesn't fit. =C2=A0In any other
situation, using any other path, the operation either adds something
to what's already there, or it fails. =C2=A0But when the path is "= ", it's
anomalous.

So, three questions:

1. Do I have this right, or am I mistaken about the result of that operatio= n?

2. Assuming I have it right, can someone explain why it's this way?

3. Can someone explain why this is the right way to specify it, rather
than using "replace" for this?

Barry
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8f23541d78414c04d096ed35-- From pbryan@anode.ca Tue Dec 11 09:41:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169DF21F885D; Tue, 11 Dec 2012 09:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjUylC-gNjwW; Tue, 11 Dec 2012 09:41:42 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4F49B21F8816; Tue, 11 Dec 2012 09:41:42 -0800 (PST) Received: from [10.126.22.61] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 7D1C46450; Tue, 11 Dec 2012 17:41:41 +0000 (UTC) From: "Paul C. Bryan" To: James M Snell In-Reply-To: References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="=-Qp5FcYlekSffU306EFPn" Date: Tue, 11 Dec 2012 09:41:40 -0800 Message-ID: <1355247700.17722.59.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Barry Leiba , IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 17:41:43 -0000 --=-Qp5FcYlekSffU306EFPn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I'm not fond of that decision either. Paul On Tue, 2012-12-11 at 09:22 -0800, James M Snell wrote: > You are reading it correctly. Note also that the very next bullet > point says: > > > > A member to add to an existing object - whereupon the supplied > value is added to that object at the indicated location. If the > member already exists, it is replaced by the specified value. > > > So an "add" is really a "replace" that does not have the "target > location MUST exist" restriction. Personally, I'm not too fond of that > decision. For anything other than an array, "add" should fail if the > target already exists. For arrays, "add" should insert but never > replace an existing value. > > > - James > > > > On Tue, Dec 11, 2012 at 7:25 AM, Barry Leiba > wrote: > > > Abstract > > JSON Patch defines the media type > "application/json-patch", a JSON > > document structure for expressing a sequence of > operations to apply > > to a JSON document, suitable for use with the HTTP PATCH > method. > > > ... > > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch/ > > I've reviewed JSON Patch and JSON Pointer as responsible AD, > and am > very happy with the documents -- this is good work, well > written. I > came up with one issue that I want to discuss as part of last > call: > > 4.1. add > > The "add" operation adds a new value at the target > location. The > operation object MUST contain a "value" member that > specifies the > value to be added. > > For example: > > { "op": "add", "path": "/a/b/c", "value": [ "foo", > "bar" ] } > > When the operation is applied, the target location MUST > reference one > of: > > o The root of the target document - whereupon the > specified value > becomes the entire content of the target document. > > Now, what this means is that if we start with this: > > { "a": { "num": 1 } } > > and we apply this: > > { "op": "add", "path": "", "value": [ "foo", "bar" ] } > > we end up with this: > > [ "foo", "bar" ] > > This doesn't strike me as having any sense of an "add" > operation -- it > appears to be a special case that doesn't fit. In any other > situation, using any other path, the operation either adds > something > to what's already there, or it fails. But when the path is > "", it's > anomalous. > > So, three questions: > > 1. Do I have this right, or am I mistaken about the result of > that operation? > > 2. Assuming I have it right, can someone explain why it's this > way? > > 3. Can someone explain why this is the right way to specify > it, rather > than using "replace" for this? > > Barry > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-Qp5FcYlekSffU306EFPn Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I'm not fond of that decision either.

Paul

On Tue, 2012-12-11 at 09:22 -0800, James M Snell wrote:
You are reading it correctly. Note also that the very next bullet point says: 


  A member to add to an existing object - whereupon the supplied
  value is added to that object at the indicated location.  If the
  member already exists, it is replaced by the specified value.


So an "add" is really a "replace" that does not have the "target location MUST exist" restriction. Personally, I'm not too fond of that decision. For anything other than an array, "add" should fail if the target already exists. For arrays, "add" should insert but never replace an existing value. 


- James


On Tue, Dec 11, 2012 at 7:25 AM, Barry Leiba <barryleiba@computer.org> wrote:
> Abstract
>    JSON Patch defines the media type "application/json-patch", a JSON
>    document structure for expressing a sequence of operations to apply
>    to a JSON document, suitable for use with the HTTP PATCH method.

...
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch/

I've reviewed JSON Patch and JSON Pointer as responsible AD, and am
very happy with the documents -- this is good work, well written.  I
came up with one issue that I want to discuss as part of last call:

   4.1.  add

   The "add" operation adds a new value at the target location.  The
   operation object MUST contain a "value" member that specifies the
   value to be added.

   For example:

   { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }

   When the operation is applied, the target location MUST reference one
   of:

   o  The root of the target document - whereupon the specified value
      becomes the entire content of the target document.

Now, what this means is that if we start with this:

{ "a": { "num": 1 } }

and we apply this:

{ "op": "add", "path": "", "value": [ "foo", "bar" ] }

we end up with this:

[ "foo", "bar" ]

This doesn't strike me as having any sense of an "add" operation -- it
appears to be a special case that doesn't fit.  In any other
situation, using any other path, the operation either adds something
to what's already there, or it fails.  But when the path is "", it's
anomalous.

So, three questions:

1. Do I have this right, or am I mistaken about the result of that operation?

2. Assuming I have it right, can someone explain why it's this way?

3. Can someone explain why this is the right way to specify it, rather
than using "replace" for this?

Barry
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-Qp5FcYlekSffU306EFPn-- From mnot@mnot.net Tue Dec 11 15:43:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B30221E8096; Tue, 11 Dec 2012 15:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.073 X-Spam-Level: X-Spam-Status: No, score=-104.073 tagged_above=-999 required=5 tests=[AWL=-1.474, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ7G1iGcmi80; Tue, 11 Dec 2012 15:43:25 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7ED21E808E; Tue, 11 Dec 2012 15:43:25 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.242.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9BCAA22E253; Tue, 11 Dec 2012 18:43:23 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Wed, 12 Dec 2012 10:43:25 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 23:43:25 -0000 On 12/12/2012, at 2:25 AM, Barry Leiba wrote: > 1. Do I have this right, or am I mistaken about the result of that = operation? The former. > 2. Assuming I have it right, can someone explain why it's this way? "add" has the semantics of "make the value *this*". "replace" has the semantics of "make the existing value *this*"; if = there isn't an existing value, it's an error. > 3. Can someone explain why this is the right way to specify it, rather > than using "replace" for this? As has already been mentioned, there are multiple tools in the box. Cheers, -- Mark Nottingham http://www.mnot.net/ From barryleiba@gmail.com Tue Dec 11 16:24:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEEA1F0CB0; Tue, 11 Dec 2012 16:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.079 X-Spam-Level: X-Spam-Status: No, score=-103.079 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2ScwGrbMjrM; Tue, 11 Dec 2012 16:24:29 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB2E521F8696; Tue, 11 Dec 2012 16:24:28 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so74385vbb.31 for ; Tue, 11 Dec 2012 16:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CgbVZrq+Ps7iZDZTFuRGomU80q7gsfP+CFICGJI+7PI=; b=b+d2OVmKq+hvJN0Vp+FYoKYr3oKG1DPOcSS2HDYTtsTG2ySuW8lbpk6akkteMIlI57 OEuf4GDmwLaYCyhNDsjYMcOpBVHZlgYIWMJKMCmZ+9vrSFLsfuTslFaOIqJScvYa2Qgq mi8EbCTx83237wlticnlSN8xbbk6/4Kjr1QazP+cLcjeg7FLtpLLZN2reOQoTpCoI3iB PIRiNrS9V5Th+Qh0IRyQA3LcA6iLTgqV7EVj4V0oBvqLxha9qh/cifojaiBDkI7anIej XmZQHDxrqVl/HBtGs0r8ivIZ2iLMsZ6CSsysctj2mAZnIHR/u4DUafS2l9+lznOvXSTj nGNA== MIME-Version: 1.0 Received: by 10.220.157.71 with SMTP id a7mr6711146vcx.19.1355271868191; Tue, 11 Dec 2012 16:24:28 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Tue, 11 Dec 2012 16:24:27 -0800 (PST) In-Reply-To: <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> Date: Tue, 11 Dec 2012 19:24:27 -0500 X-Google-Sender-Auth: VLCsbCAtuoXLafFeQtdZKpgMUMU Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 00:24:29 -0000 > "add" has the semantics of "make the value *this*". Yeh, I guess the problem I have with that is that that's not the semantics most of us attach to the concept of "add a thing to a set". And it bothers me that "add to an object" and "add to an array" have different semantics. That difference is unsettling. It's OK to have "add" on an array have the semantics of "insert", especially because there's no "insert" action. But having "add" on an object have the semantics of "replace" seems bad, partly because it's inconsistent with the semantics it has on an array and because there's already a "replace" action. If I have { "baz": "qux", "foo": "bar" }, these two do exactly the same thing: case 1a: [{ "op": "add", "path": "/baz", "value": "blarg" }] case 1b: [{ "op": "replace", "path": "/baz", "value": "blarg" }] Both result in { "baz": "blarg", "foo": "bar" } While these are different: case 2a: [{ "op": "add", "path": "/hah", "value": "blarg" }] case 2b: [{ "op": "replace", "path": "/hah", "value": "blarg" }] Case 2a results in { "baz": "blarg", "foo": "bar", "hah": "blarg" }, and 2b is an error. Case 1 just seems wrong. The "add" in 1a should be an error, and then life would make sense. > As has already been mentioned, there are multiple tools in the box. Stretching the analogy, having the wrench act as a hammer in some cases does not make for a particularly well defined, robust tool box. Barry From mnot@mnot.net Tue Dec 11 16:31:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02C321F8898; Tue, 11 Dec 2012 16:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.036 X-Spam-Level: X-Spam-Status: No, score=-104.036 tagged_above=-999 required=5 tests=[AWL=-1.437, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWOB-cxYOSpe; Tue, 11 Dec 2012 16:31:44 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 269D211E80A3; Tue, 11 Dec 2012 16:31:43 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.242.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 30D0022E1F4; Tue, 11 Dec 2012 19:31:36 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Wed, 12 Dec 2012 11:31:39 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 00:31:45 -0000 So, do you have a suggestion? On 12/12/2012, at 11:24 AM, Barry Leiba wrote: >> "add" has the semantics of "make the value *this*". >=20 > Yeh, I guess the problem I have with that is that that's not the > semantics most of us attach to the concept of "add a thing to a set". > And it bothers me that "add to an object" and "add to an array" have > different semantics. >=20 > That difference is unsettling. It's OK to have "add" on an array have > the semantics of "insert", especially because there's no "insert" > action. But having "add" on an object have the semantics of "replace" > seems bad, partly because it's inconsistent with the semantics it has > on an array and because there's already a "replace" action. >=20 > If I have { "baz": "qux", "foo": "bar" }, these two do exactly the = same thing: >=20 > case 1a: [{ "op": "add", "path": "/baz", "value": "blarg" }] >=20 > case 1b: [{ "op": "replace", "path": "/baz", "value": "blarg" }] >=20 > Both result in { "baz": "blarg", "foo": "bar" } >=20 > While these are different: >=20 > case 2a: [{ "op": "add", "path": "/hah", "value": "blarg" }] >=20 > case 2b: [{ "op": "replace", "path": "/hah", "value": "blarg" }] >=20 > Case 2a results in { "baz": "blarg", "foo": "bar", "hah": "blarg" }, > and 2b is an error. >=20 > Case 1 just seems wrong. The "add" in 1a should be an error, and then > life would make sense. >=20 >=20 >> As has already been mentioned, there are multiple tools in the box. >=20 > Stretching the analogy, having the wrench act as a hammer in some > cases does not make for a particularly well defined, robust tool box. >=20 > Barry -- Mark Nottingham http://www.mnot.net/ From McQuilWP@pobox.com Tue Dec 11 16:35:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B72421E808F for ; Tue, 11 Dec 2012 16:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moY4tQ2Ydrwf for ; Tue, 11 Dec 2012 16:35:55 -0800 (PST) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC0611E80AE for ; Tue, 11 Dec 2012 16:35:53 -0800 (PST) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 7FA5D9877; Tue, 11 Dec 2012 19:35:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=qMpCRnoe+VVE jEqjczPxP85YvDE=; b=fWeNDeGQKDXI5WMMYni8PijMtqV8mWpg0HQPZ48XKJUV mbm+ZE0Cls9iNUcUwAnV94C+bJEtqnUgn8rzfUo+F2T+DGKSwSG3rowSJ3wKbGRh rZaSfkRA1b0tvBQkm5TBXEiJyDAVwRfvfGDcDUOHW0ryj3Zb9zpjOe3Nb/zMIEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=WbTbu6 0+Ckq+CRDiswRjtsmWlh4QTLX2escrC3qBi3KX88ouZIdbREV9bMxpLWkyW0DALU Uldhn0f+4Udsi1pb02Ck4EaWIP24/p6kVCHjLRgYuaTTpCpU9QDpl890GUbP2NcL Bb1dc14R2MuS3U2yVQzZ3aicEhcbKM3FWo6PE= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 6DA809876; Tue, 11 Dec 2012 19:35:51 -0500 (EST) Received: from BQ07NB (unknown [68.107.15.47]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id CCBA19874; Tue, 11 Dec 2012 19:35:50 -0500 (EST) Date: Tue, 11 Dec 2012 16:35:49 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <596974167.20121211163549@pobox.com> To: Apps-Discusssion In-Reply-To: References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E1513FF4-43F3-11E2-AFCD-995F2E706CDE-02871704!b-pb-sasl-quonix.pobox.com Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 00:35:56 -0000 On Tue, 2012-12-11, Barry Leiba wrote: >> "add" has the semantics of "make the value *this*". > Yeh, I guess the problem I have with that is that that's not the > semantics most of us attach to the concept of "add a thing to a set". > And it bothers me that "add to an object" and "add to an array" have > different semantics. > That difference is unsettling. It's OK to have "add" on an array have > the semantics of "insert", especially because there's no "insert" > action. But having "add" on an object have the semantics of "replace" > seems bad, partly because it's inconsistent with the semantics it has > on an array and because there's already a "replace" action. > If I have { "baz": "qux", "foo": "bar" }, these two do exactly the same thing: > case 1a: [{ "op": "add", "path": "/baz", "value": "blarg" }] > case 1b: [{ "op": "replace", "path": "/baz", "value": "blarg" }] > Both result in { "baz": "blarg", "foo": "bar" } > While these are different: > case 2a: [{ "op": "add", "path": "/hah", "value": "blarg" }] > case 2b: [{ "op": "replace", "path": "/hah", "value": "blarg" }] > Case 2a results in { "baz": "blarg", "foo": "bar", "hah": "blarg" }, > and 2b is an error. > Case 1 just seems wrong. The "add" in 1a should be an error, and then > life would make sense. >> As has already been mentioned, there are multiple tools in the box. > Stretching the analogy, having the wrench act as a hammer in some > cases does not make for a particularly well defined, robust tool box. It sound to me like "add" should be spelled "set" or "put". > https://www.ietf.org/mailman/listinfo/apps-discuss -- Bill McQuillan From barryleiba@gmail.com Tue Dec 11 17:01:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B560621E8096; Tue, 11 Dec 2012 17:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.078 X-Spam-Level: X-Spam-Status: No, score=-103.078 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVn+ZYcNjl1g; Tue, 11 Dec 2012 17:01:20 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07D7111E80A3; Tue, 11 Dec 2012 17:01:19 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so109444vcb.31 for ; Tue, 11 Dec 2012 17:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=k4wXQ6CxOlbWIm4oeubuVGaYhzbDAMzedR2sckPxsCc=; b=Am8uPWc/xqa0DKKfthjE1wQf9RKsulrDlqzaLDbZWlIrjYOzyhe5BLPpryIRZbQKts 8qbiEoi2Qp72OYl1qqE9laGiSRgswieivoQht2OMlR23ObAB0Ln0YX8eVuwDTV01n64v bBS81UG1cyKLnU8b3WdmsDZ/PUvprUlUqDDBtqLBOAJcn/QgEHMjYp3gF1KDSUAbLSZg IG+ls98GIlgeNJVzx+4ozfOp8cKAoBAP+/MMh0x1GoJkcYtxKTJYFDOsNql4Qzgtbc9T Fz47pzUIepAmhVF2yj8mJOKqigPyVs0IPIXN+PSUqt3W8NcXO0Tg4wUkgaseyHUfmzV5 5piA== MIME-Version: 1.0 Received: by 10.58.221.130 with SMTP id qe2mr20064vec.14.1355274079499; Tue, 11 Dec 2012 17:01:19 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Tue, 11 Dec 2012 17:01:19 -0800 (PST) In-Reply-To: <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> Date: Tue, 11 Dec 2012 20:01:19 -0500 X-Google-Sender-Auth: Q6Kuj75c1hGr8oVPhvVkbv8YXb4 Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 01:01:20 -0000 > So, do you have a suggestion? I do, and it's buried in there: >> Case 1 just seems wrong. The "add" in 1a should be an error, and then >> life would make sense. Turning that into a text suggestion, it would be this (which represents a change to the protocol, so the working group would have to accept it): OLD When the operation is applied, the target location MUST reference one of: o The root of the target document - whereupon the specified value becomes the entire content of the target document. o A member to add to an existing object - whereupon the supplied value is added to that object at the indicated location. If the member already exists, it is replaced by the specified value. NEW When the operation is applied, the target location MUST reference one of: o A member to add to an existing object - whereupon the supplied value is added to that object at the indicated location. It is an error for the specified member to already exist. END OLD For example, "add"ing to the path "/a/b" to this document: { "a": { "foo": 1 } } is not an error, because "a" exists, and "b" will be added to its value. It is an error in this document: { "q": { "bar": 2 } } because "a" does not exist. NEW For example, given the following starting document: { "a": { "foo": 1 } } o "add"ing to the path "/a/b" is not an error, because "/a" exists, and "b" will be added to its value. o "add"ing to the path "/q/b" is an error, because "/q" does not exist. But "/q" can be added first, followed by "add"ing "/q/b". o "add"ing to the path "/a" or "/a/foo" is an error, because "/a" and "/a/foo" both exist already, and cannot be added. END I understand that this will change implementations -- patches that used to use "add" will now have to use "replace", and there's now no way to do "add this if it's not already there, and replace it if it is already there". Perhaps there's a need to add something with those semantics. On the other hand, as the text stands now, there's no way to do "add this only if it's not already there", because "test" can't test for existence. Barry From mnot@mnot.net Tue Dec 11 17:14:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EE821E8094; Tue, 11 Dec 2012 17:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.001 X-Spam-Level: X-Spam-Status: No, score=-104.001 tagged_above=-999 required=5 tests=[AWL=-1.402, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YH6Qz16-oA9; Tue, 11 Dec 2012 17:14:53 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 18E2521E8030; Tue, 11 Dec 2012 17:14:53 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.242.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1A4DA22E1F4; Tue, 11 Dec 2012 20:14:45 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Wed, 12 Dec 2012 12:14:49 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 01:14:53 -0000 On 12/12/2012, at 12:01 PM, Barry Leiba wrote: >=20 > I understand that this will change implementations -- patches that > used to use "add" will now have to use "replace", and there's now no > way to do "add this if it's not already there, and replace it if it is > already there". That was a very desirable feature for many people in the WG. Personally -- to me, it seems like you're getting hung up on the word = "add." We've had a few bits of feedback, where people try to map a = particular meaning of one of the operation names to a programming = language or other system. In this format, "add" means what the format = definition says it means, because otherwise we have to rationalise all = of the different systems people might use it with to make sense. That said, if changing the operation name would make things easier, I'd = be OK with that; e.g., "set." However, I suspect doing so would just = raise issues from other people who are used to having "set" mean = something slightly different. > Perhaps there's a need to add something with those > semantics. On the other hand, as the text stands now, there's no way > to do "add this only if it's not already there", because "test" can't > test for existence. We discussed having a test for existence in the WG, but there was = agreement that it wasn't important enough to justify the added = complexity. YMMV, of course. Cheers, -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Tue Dec 11 17:54:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF9F21E80B7 for ; Tue, 11 Dec 2012 17:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQNsyLb8jHA9 for ; Tue, 11 Dec 2012 17:54:30 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id B6DE921E8096 for ; Tue, 11 Dec 2012 17:54:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,263,1355058000"; d="scan'208";a="107942492" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 12 Dec 2012 12:54:28 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="153353998" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcavi.tcif.telstra.com.au with ESMTP; 12 Dec 2012 12:54:28 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Wed, 12 Dec 2012 12:54:27 +1100 From: "Manger, James H" To: Barry Leiba Date: Wed, 12 Dec 2012 12:54:26 +1100 Thread-Topic: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard Thread-Index: Ac3YBExjy7E46n9rSn+u8Amk50ccPgAADZSA Message-ID: <255B9BB34FB7D647A506DC292726F6E11502E33447@WSMSG3153V.srv.dir.telstra.com> References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 01:54:31 -0000 PiA+PiBDYXNlIDEganVzdCBzZWVtcyB3cm9uZy4gIFRoZSAiYWRkIiBpbiAxYSBzaG91bGQgYmUg YW4gZXJyb3IsIGFuZA0KPiA+PiB0aGVuIGxpZmUgd291bGQgbWFrZSBzZW5zZS4NCj4gLi4uDQo+ IEkgdW5kZXJzdGFuZCB0aGF0IHRoaXMgd2lsbCBjaGFuZ2UgaW1wbGVtZW50YXRpb25zIC0tIHBh dGNoZXMgdGhhdCB1c2VkDQo+IHRvIHVzZSAiYWRkIiB3aWxsIG5vdyBoYXZlIHRvIHVzZSAicmVw bGFjZSIsIGFuZCB0aGVyZSdzIG5vdyBubyB3YXkgdG8NCj4gZG8gImFkZCB0aGlzIGlmIGl0J3Mg bm90IGFscmVhZHkgdGhlcmUsIGFuZCByZXBsYWNlIGl0IGlmIGl0IGlzIGFscmVhZHkNCj4gdGhl cmUiLiAgUGVyaGFwcyB0aGVyZSdzIGEgbmVlZCB0byBhZGQgc29tZXRoaW5nIHdpdGggdGhvc2Ug c2VtYW50aWNzLg0KPiBPbiB0aGUgb3RoZXIgaGFuZCwgYXMgdGhlIHRleHQgc3RhbmRzIG5vdywg dGhlcmUncyBubyB3YXkgdG8gZG8gImFkZA0KPiB0aGlzIG9ubHkgaWYgaXQncyBub3QgYWxyZWFk eSB0aGVyZSIsIGJlY2F1c2UgInRlc3QiIGNhbid0IHRlc3QgZm9yDQo+IGV4aXN0ZW5jZS4NCg0K DQpJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBiZSBhYmxlIHRvIGRvOiAic2V0IHRoaXMgb2Jq ZWN0IGVsZW1lbnQgKHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgaXQgYWxyZWFkeSBleGlz dHMgb3Igd2hhdCBpdHMgZXhpc3RpbmcgdmFsdWUgaXMpIi4NClRoaXMgbWVhbnMgeW91IGNhbiBt YWtlIHNvbWUgcGF0Y2hlcyB3aXRob3V0IGhhdmluZyB0byBmaXJzdCByZWFkIHRoZSB0YXJnZXQs IHRoZW4gbG9ja2luZyB0aGUgdGFyZ2V0IGFnYWluc3Qgb3RoZXIgY2hhbmdlcyBiZWZvcmUgeW91 ciBwYXRjaCBpcyBhcHBsaWVkLg0KDQpUaGlzIGlzIG1vcmUgaW1wb3J0YW50IHRoYW4gYmVpbmcg YWJsZSB0byBkbzogInNldCB0aGlzIG9iamVjdCBlbGVtZW50IG9ubHkgaWYgaXQncyBub3QgYWxy ZWFkeSB0aGVyZSIuDQoNCkZvciB0aGUgc2FtZSByZWFzb25zLCBJIGFsc28gdGhpbmsgaXQgaXMg aW1wb3J0YW50IHRvIGJlIGFibGUgdG8gZG86ICJyZW1vdmUgdGhpcyBvYmplY3QgZWxlbWVudCAo cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCBpdCBleGlzdHMpIi4gV2l0aCBkcmFmdC0wOCAi cmVtb3ZlIiBjYXVzZXMgYW4gZXJyb3IgaWYgdGhlIGVsZW1lbnQgZG9lcyBub3QgZXhpc3QuDQoN Ck1pbmQgeW91LCBwZXJoYXBzICJhZGQiIGJlaW5nIGxlbmllbnQgKGFib3V0IHRoZSBwcmVzZW5j ZSBvciBhYnNlbmNlIG9mIGEgdmFsdWUpIHdoaWxlICJyZW1vdmUiIGlzIHN0cmljdCBpcyBub3Qg c3VjaCBhIHVzZWZ1bCBjb21iaW5hdGlvbi4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From barryleiba.mailing.lists@gmail.com Tue Dec 11 20:25:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C11521F8675; Tue, 11 Dec 2012 20:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.077 X-Spam-Level: X-Spam-Status: No, score=-103.077 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izz8ihkdCaVS; Tue, 11 Dec 2012 20:25:18 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3A021F869E; Tue, 11 Dec 2012 20:25:17 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id c1so216116lbg.18 for ; Tue, 11 Dec 2012 20:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CzI6CZAfnJ2XoKhPW+I4ip0b3qNUNO0jGQTf/Kpz7KM=; b=hK3UOfGUN29LXoGMfJDGj3BfmLNCeXKC9aJrnCmOrakd/RbH8DtHqq7Qe211+rEwjd 9y8bJa7iBSPmjRCyHD4DrK/3aq5YYALLH40Cx0F89nNHNNxPP/9xIikImn9u34MGq0TG Z+R7IbtFSeO7kYvia5Ga97V4VzZX6+8IjM8YypMsEgAfAR4F0E0aOPzk5ElJCd4vb6kA t0jatRaG6LyRMrYoVGsFnaqctK3Z3oaXr4AtsUGqbtx1o44TWKL0yNYhdpqMSI5N3uPw 0PcG9eWdbwM1Mnh2tnAiaQ3f2jkAfxTwn0FeEJHZn53yx1h7tcnR+09pNyB0Ea7oHr06 hh+w== MIME-Version: 1.0 Received: by 10.152.112.36 with SMTP id in4mr5880lab.35.1355286316205; Tue, 11 Dec 2012 20:25:16 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Tue, 11 Dec 2012 20:25:15 -0800 (PST) In-Reply-To: References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> Date: Tue, 11 Dec 2012 23:25:15 -0500 X-Google-Sender-Auth: D4A9R_iy92eFRV18Ki8Z_C9WKik Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 04:25:19 -0000 > Personally -- to me, it seems like you're getting hung up on the word "add." ... > "add" means what the format definition says it means, because otherwise > we have to rationalise all of the different systems people might use it with > to make sense. OK, I'll buy that. Then let's take a different approach, and make it clearer that it's Humpty Dumpty's version of "add", so maybe neither I nor Alice will get hung up on it: OLD The "add" operation adds a new value at the target location. The operation object MUST contain a "value" member that specifies the value to be added. NEW The "add" operation performs the following function, depending upon what the target location references (see details below): o If the target location specifies an array index, a new value is inserted into the array at the specified index. o If the target location specifies an object member that does not already exist, a new member is added to the object. o If the target location specifies an object member that does exist, that member's value is replaced. END That may be wordier than we need, but I think it makes the point... feel free to wordsmith. With something like that, I think we can say that we had to pick a name, "add" was picked, and it means exactly what we choose it to mean - neither more nor less. And that's glory for you. Barry From rwfranks@gmail.com Tue Dec 11 17:54:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951FD21E80C0; Tue, 11 Dec 2012 17:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka2IlbTa7a0b; Tue, 11 Dec 2012 17:54:07 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4202E21E8096; Tue, 11 Dec 2012 17:54:07 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so48299wey.3 for ; Tue, 11 Dec 2012 17:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=K0gabIB8Tz+PptTlys9WmbJN+/emkz5j1ihif1L8zYI=; b=E+px4Iu7WOApHgbg4ekhZi1XUf3LMpTfiLtNL/o/G8a3+1g7t+mX2qjZ5fET9jOCuy +4LQH9j+1vDi+EmTrxNgKOSLQFfjXhEwesUL7el6EVBqeAjqkQJ2hvW6N3E9fqnzRWhD WmNV/VCZaVYxzU3mGFZU1VgJnHDZHtI4Am6Sp8KHhVXN8XUPu5pKwpjcOtGbQEuhHgJ2 yE82DotT4zpFnoRfs0RqAGe7ENapOoCmo5rL8wnwClf3FymZI3o2Ch5qg1cQcmm4Sv65 HHNzJDVzrxPBLkd1v3OXWt+XygztGw7edu23bHopK9vmp79mmNtRK57qnQ6YdSuLp6pK BSXQ== Received: by 10.180.73.80 with SMTP id j16mr243283wiv.5.1355277246289; Tue, 11 Dec 2012 17:54:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.18.65 with HTTP; Tue, 11 Dec 2012 17:53:45 -0800 (PST) In-Reply-To: References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> From: Dick Franks Date: Wed, 12 Dec 2012 01:53:45 +0000 Message-ID: To: IETF discussion list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 12 Dec 2012 08:15:42 -0800 Cc: Mark Nottingham , Barry Leiba , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 01:54:13 -0000 On 12 December 2012 01:14, Mark Nottingham wrote: [snip] > > Personally -- to me, it seems like you're getting hung up on the word "ad= d." We've had a few bits of feedback, where people try to map a particular = meaning of one of the operation names to a programming language or other sy= stem. In this format, "add" means what the format definition says it means,= because otherwise we have to rationalise all of the different systems peop= le might use it with to make sense. > "When I use a word", Humpty Dumpty said, in rather a scornful tone, "it means what I choose it to mean - neither more nor less." Lewis Carroll. Through the Looking Glass. 1872. From sayrer@gmail.com Thu Dec 13 02:38:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853E021F87C8 for ; Thu, 13 Dec 2012 02:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIsIpD24Uzom for ; Thu, 13 Dec 2012 02:38:37 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7319B21F87B3 for ; Thu, 13 Dec 2012 02:38:37 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so3883553wib.13 for ; Thu, 13 Dec 2012 02:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zvwrf23j4lEJbK7DTFk/Dyr1Wm+GqBYk9JqzqFPJNPc=; b=tbbkagb/yAKtQ+PJsZR8PffIGUaAwkl3AsCioUA4+n//IALgMIQtGsX2w+165/oRcC g8/Nm4cWMQ0zSQGwrh6HVJx2gOkE85XDkIM0+SUHCuX5gys9pa55ntzQTVCU7ct3N/xZ zmBCwa4EjZtx6LAZYKTWYpx0MNeEGG9GPiEIUWsU2Y174cVrb9YfGVV160s8rReFgXcc PHUNt6TsiSn5oX8rfl4OIW/N6Jg2f0iQW/6BSEcHgtZze24T7MPi8RE63yhu8k/CqN1t yy7hMSZGV5o0gZ37iHWZauJNrkCk9kU5jwyCrcqa7hxU25D0rTY4kv1gp0wX8VxSGHY5 bCJQ== MIME-Version: 1.0 Received: by 10.194.23.37 with SMTP id j5mr7281480wjf.28.1355395116538; Thu, 13 Dec 2012 02:38:36 -0800 (PST) Received: by 10.194.1.101 with HTTP; Thu, 13 Dec 2012 02:38:36 -0800 (PST) Date: Thu, 13 Dec 2012 02:38:36 -0800 Message-ID: From: Robert Sayre To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=047d7b414e8c739c1e04d0b9845c Subject: [apps-discuss] (no subject) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 10:38:38 -0000 --047d7b414e8c739c1e04d0b9845c Content-Type: text/plain; charset=ISO-8859-1 James Manger wrote: > For the same reasons, I also think it is important to be able to do: "remove this object element > (regardless of whether or not it exists)". With draft-08 "remove" causes an error if the element > does not exist. Oh, I think that text is buggy. Specifically, the text "the target location MUST exist" is unsuitably ambiguous for a MUST requirement, and needlessly ties client state to server state. If a server receives two PATCH requests that remove the same element, against ETags that are either the same or non-conflicting, there's no problem. - Rob --047d7b414e8c739c1e04d0b9845c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable James Manger wrote:
>=A0For the same reasons, I also think it is important to be able to = do: "remove this object element=A0
> (regardless of whether or not it e= xists)". With draft-08 "remove" causes an error if the eleme= nt=A0
> does not ex= ist.

Oh, I think that text is buggy. Specifically, the text "the target l= ocation MUST exist" is unsuitably ambiguous for a MUST requirement, an= d needlessly ties client state to server state.

If a server rec= eives two PATCH requests that remove the same element, against ETags that a= re either the same or non-conflicting, there's no problem.

- Rob --047d7b414e8c739c1e04d0b9845c-- From sm@resistor.net Thu Dec 13 14:30:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6170721F8BC0; Thu, 13 Dec 2012 14:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuXb7kDugERN; Thu, 13 Dec 2012 14:30:47 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D20821F8B82; Thu, 13 Dec 2012 14:30:47 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qBDMUgEl002553; Thu, 13 Dec 2012 14:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1355437846; bh=WSEKHIqebEQnQgLCc6ZL0pFCt6KUn7xac63ccRMubsw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VYBhfej1I/cuVVYqYKyHL3e9GQP4w9o13U0QqWMGT04NGgKOPDByK2iuIBaUtO+lW VBPZpCG9qfZ36Jd1dLQoiQoaYaoB7Ul4Y772W5emnuj2DPSynIRhlxnU+NGnuhQeK9 CX2GqqfhFK40P6zr8/CjH1GQWnn0nxudp4SCTXyI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1355437846; i=@resistor.net; bh=WSEKHIqebEQnQgLCc6ZL0pFCt6KUn7xac63ccRMubsw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OM+fWxWywv7Vxs3KW9meYKFMklyNTmyC7S0Tfvt0goATwV0Q/QSZiCHBPGLtAuZ4E h07ZEQoR6cNMWqqU47SPbRXvF9eI36nkRgG37okVjg5IQvxVHmVBxnCgSVMaBVFVVN FdS7P4Tp7uV0BkTHqOgNfuMtnIJCklUMf9XPSZco= Message-Id: <6.2.5.6.2.20121213131533.0b7a65b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Dec 2012 14:22:45 -0800 To: renum@ietf.org From: SM In-Reply-To: <20121128152543.31789.28197.idtracker@ietfa.amsl.com> References: <20121128152543.31789.28197.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Problem Statement for Renumbering IPv6 Hosts with Static Addresses) to Informational RFC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:30:48 -0000 At 07:25 28-11-2012, The IESG wrote: >The IESG has received a request from the IPv6 Site Renumbering WG >(6renum) to consider the following document: >- 'Problem Statement for Renumbering IPv6 Hosts with Static Addresses' > as Informational RFC These comments are after the Last Call. As such I am ok if they are ignored. There is a Cc to apps-discuss in case anyone is interested to comment about the application perspective. I am aware that renumbering is difficult. I have read about the claim that "addresses are stable over long periods of time" in RFC 6250. The Introduction Section of the draft mentions that: "Static addresses may be configured automatically, for example by stateful DHCPv6." It's fine to assign IP addresses to printers through DHCPv6. The printer is a one-function device and it usually isn't critical. I wouldn't use DHCPv6 for servers to be on the safe side. If I had to choose between walking to the server to be able to access it when things go wrong and pushing an IP configuration manually, I would choose the former as it would have a lower impact on service availability. Note that the server may be running multiple services which could interact with each other. In Section 2.3: "However, it is very widespread operational practice that servers have static IP addresses." "Such server addresses can be managed centrally even if they are static, by using DHCPv6 in stateful mode, and by generating both DHCPv6 data and DNS data from a common configuration database using a suitable configuration tool." This draft argues for DHCPv6 as the solution to make renumbering easier. The draft seems to focus more on the client perspective where DHCPv6 (or SLAAC) is a worthwhile alternative for address assignment. There's more to a server than assigning an IP address to the host. If I configure a "Listen" address for an application and there is a DNS failure, the application does not start. The problem statement (Section 4) mentions among other things printers and desktops. The server part relies on DHCPv6 and DNS for configuration management. In my humble opinion, that's a recipe for service outage. Regards, -sm From brian.e.carpenter@gmail.com Fri Dec 14 00:01:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367C021F88DC; Fri, 14 Dec 2012 00:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.023 X-Spam-Level: X-Spam-Status: No, score=-101.023 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, TO_MALFORMED=1.17, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxftuqW0qWnF; Fri, 14 Dec 2012 00:01:42 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 46B1A21F88DA; Fri, 14 Dec 2012 00:01:42 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1252419wgb.13 for ; Fri, 14 Dec 2012 00:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TIgKsKTIqUFJomWM3TKaxPaS9SIhRqDonM5c74HUc98=; b=UZDlSSE/SjE86dqc+tyZ5EYd5cn7tg5+yKEeOXGKaLu0tSe9zZgRDSAJnf4RaPpqGv e4m+p4D8YsqbX+6BgXC4YbiW3C1H4fnNeGEog3vGOZkd7Kz1hZr0WWMrwzQR+ZboULIw rQ0A2P8KrtCl1Z7DjiiPjIjMANcnkpigFsxzGV02I0mHZzSLUyuDGCR+eG4rxkwnLvcF GUN7jiXzvwU4owDzmLBOZDHjf/2TMlCwdWOuttBFcpQmMiCFBA7RzfAXj0fnA1M1qu/p 0V33mR3P7thy+vBhomhtXh1SxATZqvKdRZCAwUaltgs7hm//FwCvxvLyksHtpn/wWGLj 2g1Q== Received: by 10.180.99.227 with SMTP id et3mr1179231wib.6.1355472101107; Fri, 14 Dec 2012 00:01:41 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-46.as13285.net. [2.102.217.46]) by mx.google.com with ESMTPS id b1sm6396326wix.11.2012.12.14.00.01.38 (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 00:01:40 -0800 (PST) Message-ID: <50CADD05.1010207@gmail.com> Date: Fri, 14 Dec 2012 08:02:13 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sm@2001:470:f329:1::1.amsl.com References: <20121128152543.31789.28197.idtracker@ietfa.amsl.com> <6.2.5.6.2.20121213131533.0b7a65b0@resistor.net> In-Reply-To: <6.2.5.6.2.20121213131533.0b7a65b0@resistor.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: renum@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Problem Statement for Renumbering IPv6 Hosts with Static Addresses) to Informational RFC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 08:01:43 -0000 > The server part relies on DHCPv6 and DNS for configuration management. In my humble opinion, that's a recipe for service outage. In my world, DHCP and DNS have been mission critical for twenty years. Regards Brian Carpenter On 13/12/2012 22:22, SM wrote: > At 07:25 28-11-2012, The IESG wrote: >> The IESG has received a request from the IPv6 Site Renumbering WG >> (6renum) to consider the following document: >> - 'Problem Statement for Renumbering IPv6 Hosts with Static Addresses' >> as Informational RFC > > These comments are after the Last Call. As such I am ok if they are > ignored. There is a Cc to apps-discuss in case anyone is interested to > comment about the application perspective. > > I am aware that renumbering is difficult. I have read about the claim > that "addresses are stable over long periods of time" in RFC 6250. The > Introduction Section of the draft mentions that: > > "Static addresses may be configured automatically, for example by > stateful DHCPv6." > > It's fine to assign IP addresses to printers through DHCPv6. The > printer is a one-function device and it usually isn't critical. I > wouldn't use DHCPv6 for servers to be on the safe side. If I had to > choose between walking to the server to be able to access it when things > go wrong and pushing an IP configuration manually, I would choose the > former as it would have a lower impact on service availability. Note > that the server may be running multiple services which could interact > with each other. > > In Section 2.3: > > "However, it is very widespread operational practice that servers have > static IP addresses." > > "Such server addresses can be managed centrally even if they are > static, by using DHCPv6 in stateful mode, and by generating both > DHCPv6 data and DNS data from a common configuration database using a > suitable configuration tool." > > This draft argues for DHCPv6 as the solution to make renumbering > easier. The draft seems to focus more on the client perspective where > DHCPv6 (or SLAAC) is a worthwhile alternative for address assignment. > There's more to a server than assigning an IP address to the host. If I > configure a "Listen" address for an application and there is a DNS > failure, the application does not start. The problem statement (Section > 4) mentions among other things printers and desktops. The server part > relies on DHCPv6 and DNS for configuration management. In my humble > opinion, that's a recipe for service outage. > > Regards, > -sm > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From markus.lanthaler@gmx.net Fri Dec 14 02:51:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA8B21F8711 for ; Fri, 14 Dec 2012 02:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV7ILPAcAKww for ; Fri, 14 Dec 2012 02:51:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id EC7AF21F86AB for ; Fri, 14 Dec 2012 02:51:16 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LnVZY-1TDB3F2H5q-00hdzh for ; Fri, 14 Dec 2012 11:51:15 +0100 Received: (qmail invoked by alias); 14 Dec 2012 10:51:15 -0000 Received: from unknown (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp010) with SMTP; 14 Dec 2012 11:51:15 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+NRcQuHiONodTOjbH3DuggkEEE/NUV20NB7ZE8Ga lv0NwjBhcZIbgs From: "Markus Lanthaler" To: , References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> In-Reply-To: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> Date: Fri, 14 Dec 2012 11:51:10 +0100 Message-ID: <012301cdd9e8$ee97ac90$cbc705b0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3XsGOrMo1y6p+OQxaQgS0VOp8txQCOE5dw Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 10:51:31 -0000 I've asked that before but didn't get an answer. So let me ask again (even though I'm quite sure it has already been asked by somebody else). How does JSON Pointer distinguish between objects and arrays? E.g. consider the following JSON document: { "foo": "bar", "1": "baz" } As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even though that's probably not what the author intended. Is there a way to avoid that? Thanks, Markus -- Markus Lanthaler @markuslanthaler > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of The IESG > Sent: Tuesday, December 11, 2012 4:01 PM > To: IETF-Announce > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] Last Call: 07.txt> (JSON Pointer) to Proposed Standard > > > The IESG has received a request from the Applications Area Working > Group > WG (appsawg) to consider the following document: > - 'JSON Pointer' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > JSON Pointer defines a string syntax for identifying a specific > value > within a JSON document. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jasnell@gmail.com Fri Dec 14 08:41:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D684121F89E9; Fri, 14 Dec 2012 08:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.707 X-Spam-Level: X-Spam-Status: No, score=-3.707 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUm6sSIM2Ni5; Fri, 14 Dec 2012 08:41:02 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF5A321F894D; Fri, 14 Dec 2012 08:41:01 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6252261ieb.31 for ; Fri, 14 Dec 2012 08:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z4cmBJ7oAY29bR3/a8ACPI4H06Lrrmh4SGAYfcHCLrI=; b=NecIG+gej7MZatR1XcBVIlmAmywKjNBqYE/2JbXCXkdX+vWNLX8W3RbBAs5gTJSZ80 TvU7H0xNd5P0ZakWZkdDVSKalvMzG2M9Nw+xD3KIITqyMaJg8nNPR/dipmGqV/WhY5kB /BWKqC3/3+EXT3eThhZdBYehv/10LHLbgmfqWgToYFIaj8GSxyYmeOi4SJguzQNdn4yD iRFzGAQ0jrxyxo3bLtYPI+5+/bz41PbQt6ubN8ZWm5CSgIVs6bFlVQuQSYmUcaM5bZyt O+NmHCwou/lCkqBjP80eG9gSfSAfCue5PWQqMN9kKhSc+gi0zOGxLB7wdf1wcdxpBBvb ax/A== Received: by 10.50.6.169 with SMTP id c9mr2179709iga.24.1355503256744; Fri, 14 Dec 2012 08:40:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Fri, 14 Dec 2012 08:40:36 -0800 (PST) In-Reply-To: <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> From: James M Snell Date: Fri, 14 Dec 2012 08:40:36 -0800 Message-ID: To: Markus Lanthaler Content-Type: multipart/alternative; boundary=e89a8f6467171c338604d0d2b2c4 Cc: IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 16:41:03 -0000 --e89a8f6467171c338604d0d2b2c4 Content-Type: text/plain; charset=UTF-8 JSON Pointer does not distinguish between objects and arrays. That is not determined until the pointer is applied to an actual object instance... the pointer "/1" is valid against {"1":"a"} or ["a","b"] On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler wrote: > I've asked that before but didn't get an answer. So let me ask again (even > though I'm quite sure it has already been asked by somebody else). > > How does JSON Pointer distinguish between objects and arrays? E.g. consider > the following JSON document: > > { > "foo": "bar", > "1": "baz" > } > > As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even > though that's probably not what the author intended. Is there a way to > avoid > that? > > > Thanks, > Markus > > > > -- > Markus Lanthaler > @markuslanthaler > > > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of The IESG > > Sent: Tuesday, December 11, 2012 4:01 PM > > To: IETF-Announce > > Cc: apps-discuss@ietf.org > > Subject: [apps-discuss] Last Call: > 07.txt> (JSON Pointer) to Proposed Standard > > > > > > The IESG has received a request from the Applications Area Working > > Group > > WG (appsawg) to consider the following document: > > - 'JSON Pointer' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may > > be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > JSON Pointer defines a string syntax for identifying a specific > > value > > within a JSON document. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8f6467171c338604d0d2b2c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable JSON Pointer does not distinguish betw= een objects and arrays. That is not determined until the pointer is applied= to an actual object instance... the pointer "/1" is valid agains= t {"1":"a"} or ["a","b"]

On Fri, Dec 14, 2012 at 2:51 AM, Markus = Lanthaler <markus.lanthaler@gmx.net> wrote:
I've asked that before but didn't get an answer. So let me ask agai= n (even
though I'm quite sure it has already been asked by somebody else).

How does JSON Pointer distinguish between objects and arrays? E.g. consider=
the following JSON document:

{
=C2=A0 "foo": "bar",
=C2=A0 "1": "baz"
}

As I read the draft, the JSON Pointer "/1" would evaluate to &quo= t;baz" even
though that's probably not what the author intended. Is there a way to = avoid
that?


Thanks,
Markus



--
Markus Lanthaler
@markuslanthaler




> -----Original Message-----
> From: apps-discuss-bo= unces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of= The IESG
> Sent: Tuesday, December 11, 2012 4:01 PM
> To: IETF-Announce
> Cc: apps-discuss@ietf.org=
> Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer= -
> 07.txt> (JSON Pointer) to Proposed Standard
>
>
> The IESG has received a request from the Applications Area Working
> Group
> WG (appsawg) to consider the following document:
> - 'JSON Pointer'
> =C2=A0 <draft-ietf-appsawg-json-pointer-07.txt> as Proposed Stan= dard
>
> The IESG plans to make a decision in the next few weeks, and solicits<= br> > final comments on this action. Please send substantive comments to the=
> ietf@ietf.org mailing lists by 20= 12-12-25. Exceptionally, comments may
> be
> sent to iesg@ietf.org instead. In= either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> =C2=A0 =C2=A0JSON Pointer defines a string syntax for identifying a sp= ecific
> value
> =C2=A0 =C2=A0within a JSON document.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg= -json-pointer/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-= appsawg-json-pointer/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8f6467171c338604d0d2b2c4-- From markus.lanthaler@gmx.net Fri Dec 14 09:17:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584FD21F8A28 for ; Fri, 14 Dec 2012 09:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp0cTU3jjhBf for ; Fri, 14 Dec 2012 09:17:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 40CCF21F8A08 for ; Fri, 14 Dec 2012 09:17:40 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M7nFW-1SxDWd1AuW-00vPVR for ; Fri, 14 Dec 2012 18:17:39 +0100 Received: (qmail invoked by alias); 14 Dec 2012 17:17:38 -0000 Received: from unknown (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp029) with SMTP; 14 Dec 2012 18:17:38 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18huEAEOS4hnEAFoDwA6TEOXZ6xFoeaWHs/Aeszkt ZVVNyMy3vXuRwr From: "Markus Lanthaler" To: "'James M Snell'" References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Fri, 14 Dec 2012 18:17:33 +0100 Message-ID: <01f901cdda1e$e9287830$bb796890$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FA_01CDDA27.4AECE030" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3aGcp/PEXrnxKCQ+em/G5vi3KWIgABPGqA Content-Language: de X-Y-GMX-Trusted: 0 Cc: 'IETF Discussion' , 'IETF Apps Discuss' Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:17:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01FA_01CDDA27.4AECE030 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hmm.. I think that=E2=80=99s quite problematic. Especially considering = how JSON Pointer is used in JSON Patch. =20 =20 -- Markus Lanthaler @markuslanthaler =20 =20 =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Friday, December 14, 2012 5:41 PM To: Markus Lanthaler Cc: IETF Discussion; IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: = (JSON Pointer) to Proposed = Standard =20 JSON Pointer does not distinguish between objects and arrays. That is = not determined until the pointer is applied to an actual object = instance... the pointer "/1" is valid against {"1":"a"} or ["a","b"] =20 On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler = wrote: I've asked that before but didn't get an answer. So let me ask again = (even though I'm quite sure it has already been asked by somebody else). How does JSON Pointer distinguish between objects and arrays? E.g. = consider the following JSON document: { "foo": "bar", "1": "baz" } As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even though that's probably not what the author intended. Is there a way to = avoid that? Thanks, Markus -- Markus Lanthaler @markuslanthaler > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of The IESG > Sent: Tuesday, December 11, 2012 4:01 PM > To: IETF-Announce > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] Last Call: 07.txt> (JSON Pointer) to Proposed Standard > > > The IESG has received a request from the Applications Area Working > Group > WG (appsawg) to consider the following document: > - 'JSON Pointer' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > JSON Pointer defines a string syntax for identifying a specific > value > within a JSON document. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ > > IESG discussion can be tracked via > = http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 ------=_NextPart_000_01FA_01CDDA27.4AECE030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hmm.. I = think that=E2=80=99s quite problematic. Especially considering how JSON = Pointer is used in JSON Patch.

 =

 =

--

Markus Lanthaler

@markuslanthaler

 =

 =

 =

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Friday, = December 14, 2012 5:41 PM
To: Markus Lanthaler
Cc: = IETF Discussion; IETF Apps Discuss
Subject: Re: [apps-discuss] = Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) = to Proposed Standard

 

JSON Pointer does not distinguish = between objects and arrays. That is not determined until the pointer is = applied to an actual object instance... the pointer "/1" is = valid against {"1":"a"} or = ["a","b"]

 

On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler = <markus.lanthaler@gmx.net> = wrote:

I've asked that before but = didn't get an answer. So let me ask again (even
though I'm quite sure = it has already been asked by somebody else).

How does JSON = Pointer distinguish between objects and arrays? E.g. consider
the = following JSON document:

{
  "foo": = "bar",
  "1": "baz"
}

As = I read the draft, the JSON Pointer "/1" would evaluate to = "baz" even
though that's probably not what the author = intended. Is there a way to = avoid
that?


Thanks,
Markus



--
Markus = Lanthaler
@markuslanthaler





> -----Original = Message-----
> From: apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of The = IESG
> Sent: Tuesday, December 11, 2012 4:01 PM
> To: = IETF-Announce
> Cc: apps-discuss@ietf.org
> = Subject: [apps-discuss] Last Call: = <draft-ietf-appsawg-json-pointer-
> 07.txt> (JSON Pointer) = to Proposed Standard
>
>
> The IESG has received a = request from the Applications Area Working
> Group
> WG = (appsawg) to consider the following document:
> - 'JSON = Pointer'
>   <draft-ietf-appsawg-json-pointer-07.txt> = as Proposed Standard
>
> The IESG plans to make a decision = in the next few weeks, and solicits
> final comments on this = action. Please send substantive comments to the
> ietf@ietf.org mailing lists by = 2012-12-25. Exceptionally, comments may
> be
> sent to iesg@ietf.org instead. In either case, = please retain the
> beginning of the Subject line to allow = automated sorting.
>
> Abstract
>
>
> =    JSON Pointer defines a string syntax for identifying a = specific
> value
>    within a JSON = document.
>
>
>
>
> The file can be = obtained via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json= -pointer/
>
> IESG discussion can be tracked via
> = http://datatracker.ietf.org/doc/draft-ietf-appsawg-json= -pointer/ballot/
>
>
> No IPR declarations have = been submitted directly on this I-D.
>
>
> = _______________________________________________
> apps-discuss = mailing list
> apps-discuss@ietf.org
> = https://www.ietf.org/mailman/listinfo/apps-discuss<= br>
_______________________________________________
apps-discuss = mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_01FA_01CDDA27.4AECE030-- From jasnell@gmail.com Fri Dec 14 09:18:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0068E21F8A55; Fri, 14 Dec 2012 09:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh9-VcgxC+q7; Fri, 14 Dec 2012 09:18:57 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9587C21F8A51; Fri, 14 Dec 2012 09:18:55 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6324513ieb.31 for ; Fri, 14 Dec 2012 09:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tbCgJNfktKcobFaaT/Y5VhPBqKb0oJ0vYEJoqqX/zTg=; b=ZpJ2kHiz79ra6OAa7OplaG4IsHH+nrInu0Urkw9aygdC1IOXB8ZARUPwxsSAQwxIR0 UWBMYVGjjHQ68I6krp8ogJQ7f76FKVAE/eXVl8RtIGRwJHXbdRIHT4HoICIIHKMT/LcP r/iYWWU1fHekgMMVG6Ucf6sTps6VLIiIUAPvHjgPr77543LOtETdQDwXdybkfrB9kTr7 kXrNSjkQllVINnrvCDLcjjqTMF9El5VsFYhksCwTxw1nqNO/YFRPKnyugZk9ZB751JTl DfutthAoS3or5D7cEaS77JH5gshVj6npN7xpHwuBN1Xb2ZNhV9IAPs8iGcW42+m3bXVW hN0Q== Received: by 10.42.41.144 with SMTP id p16mr5048672ice.39.1355505535258; Fri, 14 Dec 2012 09:18:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Fri, 14 Dec 2012 09:18:34 -0800 (PST) In-Reply-To: <50cb5f33.295eb40a.7e3d.ffff919fSMTPIN_ADDED_BROKEN@mx.google.com> References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f33.295eb40a.7e3d.ffff919fSMTPIN_ADDED_BROKEN@mx.google.com> From: James M Snell Date: Fri, 14 Dec 2012 09:18:34 -0800 Message-ID: To: Markus Lanthaler Content-Type: multipart/alternative; boundary=20cf301d4232eb903c04d0d339b3 Cc: IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:18:58 -0000 --20cf301d4232eb903c04d0d339b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How so? Doesn't appear to be a problem in practice. On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler wrote: > Hmm.. I think that=E2=80=99s quite problematic. Especially considering ho= w JSON > Pointer is used in JSON Patch.**** > > ** ** > > ** ** > > --**** > > Markus Lanthaler**** > > @markuslanthaler**** > > ** ** > > ** ** > > ** ** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Friday, December 14, 2012 5:41 PM > *To:* Markus Lanthaler > *Cc:* IETF Discussion; IETF Apps Discuss > *Subject:* Re: [apps-discuss] Last Call: > (JSON Pointer) to Proposed Stand= ard > **** > > ** ** > > JSON Pointer does not distinguish between objects and arrays. That is not > determined until the pointer is applied to an actual object instance... t= he > pointer "/1" is valid against {"1":"a"} or ["a","b"]**** > > ** ** > > On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler < > markus.lanthaler@gmx.net> wrote:**** > > I've asked that before but didn't get an answer. So let me ask again (eve= n > though I'm quite sure it has already been asked by somebody else). > > How does JSON Pointer distinguish between objects and arrays? E.g. consid= er > the following JSON document: > > { > "foo": "bar", > "1": "baz" > } > > As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even > though that's probably not what the author intended. Is there a way to > avoid > that? > > > Thanks, > Markus > > > > -- > Markus Lanthaler > @markuslanthaler**** > > > > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of The IESG > > Sent: Tuesday, December 11, 2012 4:01 PM > > To: IETF-Announce > > Cc: apps-discuss@ietf.org > > Subject: [apps-discuss] Last Call: > 07.txt> (JSON Pointer) to Proposed Standard > > > > > > The IESG has received a request from the Applications Area Working > > Group > > WG (appsawg) to consider the following document: > > - 'JSON Pointer' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may > > be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > JSON Pointer defines a string syntax for identifying a specific > > value > > within a JSON document. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > ** ** > --20cf301d4232eb903c04d0d339b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How so? Doesn't appear to be a pr= oblem in practice.=C2=A0


On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

Hmm.. I think t= hat=E2=80=99s quite problematic. Especially considering how JSON Pointer is= used in JSON Patch.

=C2=A0

=C2=A0

--

Markus Lanthaler=

@markuslanthaler<= span style=3D"font-size:10.5pt;font-family:Consolas"><= /p>

=C2=A0

=C2=A0<= /u>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Friday, December 14, 2012 5:41 PM
To: Markus Lanthal= er
Cc: IETF Discussion; IETF Apps Discuss
Subject: Re: = [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (J= SON Pointer) to Proposed Standard

=C2=A0<= /u>

JSON Pointer does not distinguish between objects and arrays. That i= s not determined until the pointer is applied to an actual object instance.= .. the pointer "/1" is valid against {"1":"a"= } or ["a","b"]

=C2=A0=

On Fri, Dec 14, 2012 at 2:51 AM, Markus= Lanthaler <markus.lanthaler@gmx.net> wrote:

I've asked that before but didn't get an ans= wer. So let me ask again (even
though I'm quite sure it has already = been asked by somebody else).

How does JSON Pointer distinguish betw= een objects and arrays? E.g. consider
the following JSON document:

{
=C2=A0 "foo": "bar&= quot;,
=C2=A0 "1": "baz"
}

As I read the d= raft, the JSON Pointer "/1" would evaluate to "baz" eve= n
though that's probably not what the author intended. Is there a way to = avoid
that?


Thanks,
Markus



--
Markus Lanthaler@markuslanthaler




> -----Original Message-----
> From: apps-discuss-bounces@ietf.or= g [mailto:apps-discu= ss-
> bounces@ietf.org= ] On Behalf Of The IESG
> Sent: Tuesday, December 11, 2012 4:01 P= M
> To: IETF-Announce
> Cc: apps-discuss@ietf.org
> Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer= -
> 07.txt> (JSON Pointer) to Proposed Standard
>
>> The IESG has received a request from the Applications Area Working > Group
> WG (appsawg) to consider the following document:
>= - 'JSON Pointer'
> =C2=A0 <draft-ietf-appsawg-json-pointe= r-07.txt> as Proposed Standard
>
> The IESG plans to make a = decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the=
> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may
> be
> sent to iesg@ietf.o= rg instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
&= gt; Abstract
>
>
> =C2=A0 =C2=A0JSON Pointer defines a st= ring syntax for identifying a specific
> value
> =C2=A0 =C2=A0w= ithin a JSON document.
>
>
>
>
> The file can be obtained via
> <= a href=3D"http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/"= target=3D"_blank">http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-= pointer/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/bal= lot/
>
>
> No IPR declarations have been submitted directly on th= is I-D.
>
>
> ___________________________________________= ____
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

_= ______________________________________________
apps-discuss mailing list=
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

=C2=A0


--20cf301d4232eb903c04d0d339b3-- From markus.lanthaler@gmx.net Fri Dec 14 09:38:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EE221F89A9 for ; Fri, 14 Dec 2012 09:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.982 X-Spam-Level: X-Spam-Status: No, score=-0.982 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Socbpa1lOBcq for ; Fri, 14 Dec 2012 09:38:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id BEB0821F85B3 for ; Fri, 14 Dec 2012 09:38:37 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lg2yr-1TKfzj3FIx-00pbLZ for ; Fri, 14 Dec 2012 18:38:36 +0100 Received: (qmail invoked by alias); 14 Dec 2012 17:38:36 -0000 Received: from unknown (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp020) with SMTP; 14 Dec 2012 18:38:36 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18C4iwMq38CBurbmemGiWEHepaAVUcbDgPR6usqMP AGdG5jL/CrT7lR From: "Markus Lanthaler" To: "'James M Snell'" References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f33.295eb40a.7e3d.ffff919fSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Fri, 14 Dec 2012 18:38:31 +0100 Message-ID: <021601cdda21$d6c541c0$844fc540$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3aHxjjg7lMd90fTjSw+Fg4sHvJ/wAAVshQ Content-Language: de X-Y-GMX-Trusted: 0 Cc: 'IETF Discussion' , 'IETF Apps Discuss' Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:38:38 -0000 On Friday, December 14, 2012 6:19 PM, James M Snell wrote: > > On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler wrote: > > > > Hmm.. I think that=E2=80=99s quite problematic. Especially = considering > > how JSON Pointer is used in JSON Patch. > > How so? Doesn't appear to be a problem in practice.=20 Since it doesn't express the authors intent. For example, assume you = have a JSON Patch document like the following: [ { "op": "test", "path": "/1", "value": 68 }, { "op": "add", "path": "/2", "value": 105 } ] What would you expect it to do? I think almost everyone would say that = it set the third element of an array to 105 iff the second value is 68. = So you might expect to get back an array on success but what you really = get back might be something like this:=20 { "some": "value", "1": 68, "some other": "value", "and": "finally", "2": 105 } Maybe having something like ~2 to express that a number is to be treated = as an array index would solve it!? -- Markus Lanthaler @markuslanthaler From jasnell@gmail.com Fri Dec 14 09:43:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CFB21F852D; Fri, 14 Dec 2012 09:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.695 X-Spam-Level: X-Spam-Status: No, score=-3.695 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD95+H-+2lU8; Fri, 14 Dec 2012 09:43:21 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 035CE21F8501; Fri, 14 Dec 2012 09:43:18 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so3404145iaz.31 for ; Fri, 14 Dec 2012 09:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0w8DafvQpeVofSm3ieh73xHdc/q4au1yO8kZ4sI8kaU=; b=RAsUK7u9o6MJARv91zS/V9BYhAKPCVlt+p0ROBmZX/BffbXkYafNPs7GK90HdMHE9e aGxsAyNwfUbqFxLQH3LUwUKAzNJPzWh67bYZe3MhqAnrWC6YacUfjHofOGFzwfVqG6RE qgHyaTbd/txGuoTGOBEzxcm29bhJXxxJC5nz1IfW7GycYEPFnKAhhd6swa+05zO+PLZq /YtZxIjGdEMPqoilByDbZBQ0UGRS3DeBTLGYvQuJn1TH9yOsAKG3rO6BVCNtpCwd2Bne SHuxms8CdUr8WXuhAUOzElBboOZqHvhyMozzuBLwgHzZATSURvDoIG20Q7f5DuuChp8W Jkgg== Received: by 10.50.151.238 with SMTP id ut14mr2350608igb.72.1355506998679; Fri, 14 Dec 2012 09:43:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Fri, 14 Dec 2012 09:42:58 -0800 (PST) In-Reply-To: <50cb641d.87cd0e0a.7f49.7549SMTPIN_ADDED_BROKEN@mx.google.com> References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f33.295eb40a.7e3d.ffff919fSMTPIN_ADDED_BROKEN@mx.google.com> <50cb641d.87cd0e0a.7f49.7549SMTPIN_ADDED_BROKEN@mx.google.com> From: James M Snell Date: Fri, 14 Dec 2012 09:42:58 -0800 Message-ID: To: Markus Lanthaler Content-Type: multipart/alternative; boundary=e89a8f3b9f7d25978304d0d39110 Cc: IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:43:22 -0000 --e89a8f3b9f7d25978304d0d39110 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The author just needs to be aware of the current state of the object being patched. Using conditional requests mechanisms can make it more reliable. On Fri, Dec 14, 2012 at 9:38 AM, Markus Lanthaler wrote: > On Friday, December 14, 2012 6:19 PM, James M Snell wrote: > > > > On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler wrote: > > > > > > Hmm.. I think that=E2=80=99s quite problematic. Especially considerin= g > > > how JSON Pointer is used in JSON Patch. > > > > How so? Doesn't appear to be a problem in practice. > > Since it doesn't express the authors intent. For example, assume you have > a JSON Patch document like the following: > > [ > { "op": "test", "path": "/1", "value": 68 }, > { "op": "add", "path": "/2", "value": 105 } > ] > > What would you expect it to do? I think almost everyone would say that it > set the third element of an array to 105 iff the second value is 68. So y= ou > might expect to get back an array on success but what you really get back > might be something like this: > > { > "some": "value", > "1": 68, > "some other": "value", > "and": "finally", > "2": 105 > } > > Maybe having something like ~2 to express that a number is to be treated > as an array index would solve it!? > > > -- > Markus Lanthaler > @markuslanthaler > > --e89a8f3b9f7d25978304d0d39110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The author just needs to be aware of t= he current state of the object being patched. Using conditional requests me= chanisms can make it more reliable.=C2=A0
=

On Fri, Dec 14, 2012 at 9:38 AM, Markus Lanthale= r <markus.lanthaler@gmx.net> wrote:
On Friday, December 14, 2012 6:19 PM, James M Snell wrote:

> > On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler wrote:
> >
> > Hmm.. I think that=E2=80=99s quite problematic. Especially consid= ering
> > how JSON Pointer is used in JSON Patch.
>
> How so? Doesn't appear to be a problem in = practice.

Since it doesn't express the authors intent. For example, assume = you have a JSON Patch document like the following:

=C2=A0 =C2=A0[
=C2=A0 =C2=A0 =C2=A0{ "op": "test", "path": &= quot;/1", "value": 68 },
=C2=A0 =C2=A0 =C2=A0{ "op": "add", "path": &q= uot;/2", "value": 105 }
=C2=A0 =C2=A0]

What would you expect it to do? I think almost everyone would say that it s= et the third element of an array to 105 iff the second value is 68. So you = might expect to get back an array on success but what you really get back m= ight be something like this:

{
=C2=A0 "some": "value",
=C2=A0 "1": 68,
=C2=A0 "some other": "value",
=C2=A0 "and": "finally",
=C2=A0 "2": 105
}

Maybe having something like ~2 to express that a number is to be treated as= an array index would solve it!?


--
Markus Lanthaler
@markuslanthaler


--e89a8f3b9f7d25978304d0d39110-- From sayrer@gmail.com Sat Dec 15 20:36:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620A521F8566; Sat, 15 Dec 2012 20:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+8+NmIFK6ak; Sat, 15 Dec 2012 20:36:08 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F39321F845A; Sat, 15 Dec 2012 20:36:08 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2276856wey.31 for ; Sat, 15 Dec 2012 20:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1UpRj7ApAA8YI+lkyR1A8ofFuuzUDbqp+QVzkAfqgo0=; b=KOK7Wne6kLpWvaLv/3u3k9nswRvD4600bul0L5//jRJQ/5cG/EwDqrKoVwPzc7SHcQ 6SoQrydvKHHnfgK+rVnL7SOxPHswYhbX3x2V8JKnBEWsGtk0lNOPKHKJsZaiQVFz0R4r XAyBHrPHjjUNDZFH8vgqwK4xrwmlMS5Vh2W11fRkc3q86uo5f1iWJmWYacB4kDVmE3hj TCOU3glKrTjuVYfa6xAdYDf5n1xJj4T+LnyOAUWZZNRg8hdBrJfRjA65GlhCojwGhsgX dQM4Fw1xZVzZkzjUZMJWHa/RJ2fWl4P8P5ZxwJRyCCis1i8bIJl08IFHv7vvn10Tdy8P PQew== MIME-Version: 1.0 Received: by 10.194.23.37 with SMTP id j5mr10657051wjf.28.1355632567498; Sat, 15 Dec 2012 20:36:07 -0800 (PST) Received: by 10.194.1.101 with HTTP; Sat, 15 Dec 2012 20:36:07 -0800 (PST) In-Reply-To: <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> Date: Sat, 15 Dec 2012 20:36:07 -0800 Message-ID: From: Robert Sayre To: Markus Lanthaler Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 04:36:09 -0000 On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler wrote: > > Hmm.. I think that=92s quite problematic. Especially considering how JSON= Pointer is used in JSON Patch. I agree--I provided the same feedback privately. It seems straightforwardly unsound. - Rob > > -- > > Markus Lanthaler > > @markuslanthaler > > > > > > > > From: James M Snell [mailto:jasnell@gmail.com] > Sent: Friday, December 14, 2012 5:41 PM > To: Markus Lanthaler > Cc: IETF Discussion; IETF Apps Discuss > Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard > > > > JSON Pointer does not distinguish between objects and arrays. That is not= determined until the pointer is applied to an actual object instance... th= e pointer "/1" is valid against {"1":"a"} or ["a","b"] > > > > On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler wrote: > > I've asked that before but didn't get an answer. So let me ask again (eve= n > though I'm quite sure it has already been asked by somebody else). > > How does JSON Pointer distinguish between objects and arrays? E.g. consid= er > the following JSON document: > > { > "foo": "bar", > "1": "baz" > } > > As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even > though that's probably not what the author intended. Is there a way to av= oid > that? > > > Thanks, > Markus > > > > -- > Markus Lanthaler > @markuslanthaler > > > > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of The IESG > > Sent: Tuesday, December 11, 2012 4:01 PM > > To: IETF-Announce > > Cc: apps-discuss@ietf.org > > Subject: [apps-discuss] Last Call: > 07.txt> (JSON Pointer) to Proposed Standard > > > > > > The IESG has received a request from the Applications Area Working > > Group > > WG (appsawg) to consider the following document: > > - 'JSON Pointer' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may > > be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > JSON Pointer defines a string syntax for identifying a specific > > value > > within a JSON document. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From jasnell@gmail.com Sat Dec 15 21:23:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADCD21F846D; Sat, 15 Dec 2012 21:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.69 X-Spam-Level: X-Spam-Status: No, score=-3.69 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZW2sM4kza-o; Sat, 15 Dec 2012 21:23:18 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 10FA221F8434; Sat, 15 Dec 2012 21:23:18 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4454604iaz.31 for ; Sat, 15 Dec 2012 21:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QPPDjy2CZR1Uur+AmrisQ0fpquvcD29fH82JYzAdvbo=; b=IzhaRCeXnRffXbiBYJbeZOnxQsrZGQpRyVVAepMoL9O/GzF9Oo2fucmAdHf+ie6xmY 2n6tWCSV0hCHNyi3zZbZx0++odREoCV51wO+EL7iEUac6FEzFKVJe0jZx7DPuji1Whaj RUP/7qKPCNWLC3tnqyAuPvbC8n8k6zS+ojVsvgClJiUFrocylzgy/jix6UXh6GK01+CP NmsvaaOv9L+/YEwPwJrs4PT2S/kbi0tLv7wVEiknUkU7P+9LaK9bnW9cRKh1Wz7uFo3n AtT/BlOJcMbbZa+NYC3EPiTKRSe7XB/f5G7XUSXcnEaxiD+Wr4dSeCj1pGLxS3hb+0+z A0lQ== Received: by 10.50.0.193 with SMTP id 1mr6069724igg.0.1355635397593; Sat, 15 Dec 2012 21:23:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Sat, 15 Dec 2012 21:22:57 -0800 (PST) In-Reply-To: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> From: James M Snell Date: Sat, 15 Dec 2012 21:22:57 -0800 Message-ID: To: Robert Sayre Content-Type: multipart/alternative; boundary=e89a8f502f8e51897304d0f17665 Cc: IETF Apps Discuss , IETF Discussion Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 05:23:19 -0000 --e89a8f502f8e51897304d0f17665 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre wrote: > On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler > wrote: > > > > Hmm.. I think that=E2=80=99s quite problematic. Especially considering = how JSON > Pointer is used in JSON Patch. > > I agree--I provided the same feedback privately. It seems > straightforwardly unsound. > > In practice it doesn't seem to be much of an issue. Specifically, if I GET an existing document and get an etag with the JSON, then make some changes and send a PATCH with If-Match, the fact that any given pointer could point to an array or object member doesn't really matter much. For example: > GET /the/doc HTTP/1.1 < HTTP/1.1 200 OK ETag: "my-document-tag" Content-Type: application/json {"1":"foo"} > PATCH /the/doc HTTP/1.1 If-Match: "my-document-etag" Content-Type: application/json-patch [{"op":"add","path":"/2","value":"bar"}] Generally speaking, someone should not be using PATCH to perform a partial modification if they don't already have some knowledge in advance what they are modifying. The only time the apparent ambiguity becomes an issue is when a client is blindly sending a patch to an unknown endpoint... in which case, you get whatever you end up with. - James > - Rob > > > > > > -- > > > > Markus Lanthaler > > > > @markuslanthaler > > > > > > > > > > > > > > > > From: James M Snell [mailto:jasnell@gmail.com] > > Sent: Friday, December 14, 2012 5:41 PM > > To: Markus Lanthaler > > Cc: IETF Discussion; IETF Apps Discuss > > Subject: Re: [apps-discuss] Last Call: > (JSON Pointer) to Proposed Stand= ard > > > > > > > > JSON Pointer does not distinguish between objects and arrays. That is > not determined until the pointer is applied to an actual object instance.= .. > the pointer "/1" is valid against {"1":"a"} or ["a","b"] > > > > > > > > On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler < > markus.lanthaler@gmx.net> wrote: > > > > I've asked that before but didn't get an answer. So let me ask again > (even > > though I'm quite sure it has already been asked by somebody else). > > > > How does JSON Pointer distinguish between objects and arrays? E.g. > consider > > the following JSON document: > > > > { > > "foo": "bar", > > "1": "baz" > > } > > > > As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even > > though that's probably not what the author intended. Is there a way to > avoid > > that? > > > > > > Thanks, > > Markus > > > > > > > > -- > > Markus Lanthaler > > @markuslanthaler > > > > > > > > > > > > > -----Original Message----- > > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > > bounces@ietf.org] On Behalf Of The IESG > > > Sent: Tuesday, December 11, 2012 4:01 PM > > > To: IETF-Announce > > > Cc: apps-discuss@ietf.org > > > Subject: [apps-discuss] Last Call: > > 07.txt> (JSON Pointer) to Proposed Standard > > > > > > > > > The IESG has received a request from the Applications Area Working > > > Group > > > WG (appsawg) to consider the following document: > > > - 'JSON Pointer' > > > as Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and solicits > > > final comments on this action. Please send substantive comments to th= e > > > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments ma= y > > > be > > > sent to iesg@ietf.org instead. In either case, please retain the > > > beginning of the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > JSON Pointer defines a string syntax for identifying a specific > > > value > > > within a JSON document. > > > > > > > > > > > > > > > The file can be obtained via > > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ > > > > > > IESG discussion can be tracked via > > > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > _______________________________________________ > > > apps-discuss mailing list > > > apps-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > --e89a8f502f8e51897304d0f17665 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



--
Matthew = P. C. Morley
=

On Sat, Dec 15, 2012 at 8:36 PM, Robert = Sayre <sayrer@gmail.com> wrote:
On Fri, Dec 14, 2012 at 9:= 17 AM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
>
> Hmm.. I think that=E2=80=99s quite problematic. Especially considering= how JSON Pointer is used in JSON Patch.

I agree--I provided the same feedback privately. It seems
straightforwardly unsound.




For example:

=C2=A0 > =C2=A0GET /the/doc HTTP/1.1

=C2=A0 < =C2=A0HTTP/1.1 200 OK
<= div>=C2=A0 =C2=A0 =C2=A0ETag: "m= y-document-tag"
=C2=A0 =C2=A0 =C2=A0Content-Type= : application/json
<= br>
=C2=A0 =C2=A0 = =C2=A0{"1":"foo"}

=C2=A0 > =C2= =A0PATCH /the/doc HTTP/1.1
=C2=A0 =C2=A0 =C2=A0If-Match: "my-document-etag"
=C2=A0 =C2=A0 =C2=A0Content-T= ype: application/json-patch

=C2=A0 =C2=A0 =C2=A0[{"op":"add&= quot;,"path":"/2","value":"bar"}]

Generally speaking, so= meone should not be using PATCH to perform a partial modification if they d= on't already have some knowledge in advance what they are modifying. Th= e only time the apparent ambiguity becomes an issue is when a client is bli= ndly sending a patch to an unknown endpoint... in which case, you get whate= ver you end up with.=C2=A0

- James

=C2=A0<= /div>
- Rob


>
> --
>
> Markus Lanthaler
>
> @markuslanthaler
>
>
>
>
>
>
>
> From: James M Snell [mailto:jasne= ll@gmail.com]
> Sent: Friday, December 14, 2012 5:41 PM
> To: Markus Lanthaler
> Cc: IETF Discussion; IETF Apps Discuss
> Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-js= on-pointer-07.txt> (JSON Pointer) to Proposed Standard
>
>
>
> JSON Pointer does not distinguish between objects and arrays. That is = not determined until the pointer is applied to an actual object instance...= the pointer "/1" is valid against {"1":"a"} = or ["a","b"]
>
>
>
> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
>
> I've asked that before but didn't get an answer. So let me ask= again (even
> though I'm quite sure it has already been asked by somebody else).=
>
> How does JSON Pointer distinguish between objects and arrays? E.g. con= sider
> the following JSON document:
>
> {
> =C2=A0 "foo": "bar",
> =C2=A0 "1": "baz"
> }
>
> As I read the draft, the JSON Pointer "/1" would evaluate to= "baz" even
> though that's probably not what the author intended. Is there a wa= y to avoid
> that?
>
>
> Thanks,
> Markus
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
>
> > -----Original Message-----
> > From: apps-discu= ss-bounces@ietf.org [mailto:apps-discu= ss-
> > bounces@ietf.org] On Beha= lf Of The IESG
> > Sent: Tuesday, December 11, 2012 4:01 PM
> > To: IETF-Announce
> > Cc: apps-discuss@ietf.or= g
> > Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-json-po= inter-
> > 07.txt> (JSON Pointer) to Proposed Standard
> >
> >
> > The IESG has received a request from the Applications Area Workin= g
> > Group
> > WG (appsawg) to consider the following document:
> > - 'JSON Pointer'
> > =C2=A0 <draft-ietf-appsawg-json-pointer-07.txt> as Proposed= Standard
> >
> > The IESG plans to make a decision in the next few weeks, and soli= cits
> > final comments on this action. Please send substantive comments t= o the
> > ietf@ietf.org mailing lists = by 2012-12-25. Exceptionally, comments may
> > be
> > sent to iesg@ietf.org instea= d. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> > =C2=A0 =C2=A0JSON Pointer defines a string syntax for identifying= a specific
> > value
> > =C2=A0 =C2=A0within a JSON document.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-ap= psawg-json-pointer/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-= ietf-appsawg-json-pointer/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--e89a8f502f8e51897304d0f17665-- From nishida@sfc.wide.ad.jp Sat Dec 15 17:54:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB8321F854D; Sat, 15 Dec 2012 17:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzMCCiv8eKTo; Sat, 15 Dec 2012 17:54:18 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id D06C021F8543; Sat, 15 Dec 2012 17:54:17 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A409927818D; Sun, 16 Dec 2012 10:54:13 +0900 (JST) Received: by mail-la0-f44.google.com with SMTP id d3so3756652lah.31 for ; Sat, 15 Dec 2012 17:54:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.11.98 with SMTP id p2mr4129921lbb.34.1355622850831; Sat, 15 Dec 2012 17:54:10 -0800 (PST) Received: by 10.112.142.196 with HTTP; Sat, 15 Dec 2012 17:54:10 -0800 (PST) In-Reply-To: References: <6.2.5.6.2.20121115153136.0a4db440@elandnews.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B2@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Sat, 15 Dec 2012 17:54:10 -0800 Message-ID: From: Yoshifumi Nishida To: Barry Leiba Content-Type: multipart/alternative; boundary=20cf302669f279280704d0ee8a85 X-Mailman-Approved-At: Sun, 16 Dec 2012 08:09:31 -0800 Cc: "iesg@ietf.org" , "Scharf, Michael \(Michael\)" , "apps-discuss@ietf.org" , "draft-ietf-mptcp-api.all@tools.ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mptcp-api-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 01:54:19 -0000 --20cf302669f279280704d0ee8a85 Content-Type: text/plain; charset=ISO-8859-1 Hello Barry, As stated in our charter, we're thinking about working on the following documents. Apr 2013 - Implementation advice (Informational) to IESG Aug 2013 - Use-cases and operational experiences (Informational) to IESG I think these docs might be able to address your points. In my feeling, it might be better to work on application considerations with some more implementation experiences. Thanks, -- Yoshifumi Nishida On Mon, Nov 26, 2012 at 8:33 AM, Barry Leiba wrote: > > >> 3.1.2. Delay > >> > >> Since burstiness is commonplace on the Internet > >> today, it is unlikely that applications will suffer from such an > >> impact on the traffic profile, but application authors may wish to > >> consider this in future development. > >> > >> well, even it is true the burstiness is common on most of the > >> Internet, this is not the case in many other circumstances, and there > >> are, maybe a few, applications which do expect the jitter to be low > >> and the packet delivery rate to be stable to work correctly (being > >> the developer of one of them... "LOLA - Low latency A/V system" I did > >> expericend already a number of cases where MPTCP did a disaster work > >> just because of its presence on multiple parallel 10G links). Thus I > >> would at least be not to optimistic in the above sentence. It is just > >> not for future work. I just suggest changing it reportig that "this > >> might be a problem" instead of "it is unlikely". > > > > [MSC] I don't know the details of the measurement you refer to, but it is > > certainly important to distinguish between the protocol in general and the > > behavior of an implementation, which is possibly work-in-progress. I do > > agree that if a specific application does not need the additional bandwidth > > by multipath and if it is very latency sensitive, the use of MPTCP could be > > worse than use of standard TCP, in particular if the sender's scheduler is > > not optimal. At least in theory, in such an application-limited scenario it > > would make sense if the MPTCP scheduler mainly used the subflow with > > smallest delay, i. e., jitter should be similar to a single-path TCP connection. > > With a reasonable scheduler in the sender, I think that the scenario you > > mention is indeed "unlikely". Anyway, I think that the scenario you describe > > refers to a mostly controlled environment without congestion etc. In the > > general Internet, an application does have to deal with jitter etc. > > ...etc... > > This and the related discussions seem to highlight that this document > really has two pieces: > > 1. Considerations for using MPTCP with various applications and types > of applications, independent of the API. > > 2. Definition of a basic API, and considerations specific to the API. > > It's possible (likely, maybe) that these should have been separate > documents. I'm not sure whether it's too late to tease them apart, > but I see some significant value in a document that just lays out (1) > by itself. The discussion above fits into that: there's nothing about > this that has anything to do with the API; it's considerations of > whether MPTCP is, in general, advantageous, detrimental, or neutral > for any particular application use case... and that's important. > > It becomes something of a problem when this document has some, but > insufficient, discussion about this, as in this case. It's easy to > say that applications in general have to deal with burstiness on the > Internet, so adding a bit more probably won't hurt... but, as Claudio > points out, that might not be true for all application types, and > further discussion of this is warranted. The oversimplified statement > might be OK for this document, or it might be problematic if it's > taken as a valid statement to apply to all Internet applications. And > there are other points in this document that fall into this category. > > What should we do about that? I've looked at the other MPTCP > documents, and we have a very cursory section in RFC 6182 (MPTCP > Architecture), "6.1 Interactions with Applications". Should there be > another document that goes into more detail about application > considerations for MPTCP? And what do we do with those issues in this > document in the meantime? Leave them as they are? Pull them out > altogether? Change them to indicate that more work needs to be done > on application considerations? > > Barry, Applications AD --20cf302669f279280704d0ee8a85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Barry,

As stated in our charter, we're thinking about work= ing on the following documents.

=A0 =A0Apr 2013 - Implementation adv= ice (Informational) to IESG
=A0 =A0Aug 2013 - Use-cases and operational = experiences (Informational) to IESG

I think these docs might be able to address your points.=A0
In my f= eeling, it might be better to work on application considerations with some = more implementation experiences.
Thanks,
--
Yoshifumi Nishida

On Mon, Nov 26, 2012 at 8:33 AM,= Barry Leiba <barryleiba@computer.org> wrote:
>
> >> 3.1.2. =A0Delay
> >>
> >> =A0= =A0 Since burstiness is commonplace on the Internet
> >> =A0 = =A0 today, it is unlikely that applications will suffer from such an
>= ; >> =A0 =A0 impact on the traffic profile, but application authors m= ay wish to
> >> =A0 =A0 consider this in future development.
> >>=
> >> well, even it is true the burstiness is common on most of= the
> >> Internet, this is not the case in many other circumst= ances, and there
> >> are, maybe a few, applications which do expect the jitter to = be low
> >> and the packet delivery rate to be stable to work c= orrectly (being
> >> the developer of one of them... "LOLA= - Low latency A/V system" I did
> >> expericend already a number of cases where MPTCP did a disast= er work
> >> just because of its presence on multiple parallel = 10G links). Thus I
> >> would at least be not to optimistic in = the above sentence. It is just
> >> not for future work. I just suggest changing it reportig that= "this
> >> might be a problem" instead of "it i= s unlikely".
> >
> > [MSC] I don't know the deta= ils of the measurement you refer to, but it is
> > certainly important to distinguish between the protocol in genera= l and the
> > behavior of an implementation, which is possibly wor= k-in-progress. I do
> > agree that if a specific application does = not need the additional bandwidth
> > by multipath and if it is very latency sensitive, the use of MPTC= P could be
> > worse than use of standard TCP, in particular if th= e sender's scheduler is
> > not optimal. At least in theory, i= n such an application-limited scenario it
> > would make sense if the MPTCP scheduler mainly used the subflow w= ith
> > smallest delay, i. e., jitter should be similar to a singl= e-path TCP connection.
> > With a reasonable scheduler in the send= er, I think that the scenario you
> > mention is indeed "unlikely". Anyway, I think that the = scenario you describe
> > refers to a mostly controlled environmen= t without congestion etc. In the
> > general Internet, an applicat= ion does have to deal with jitter etc.
>
> ...etc...
>
> This and the related discussions see= m to highlight that this document
> really has two pieces:
>> 1. Considerations for using MPTCP with various applications and types=
> of applications, independent of the API.
>
> 2. Definition= of a basic API, and considerations specific to the API.
>
> It= 's possible (likely, maybe) that these should have been separate
> documents. =A0I'm not sure whether it's too late to tease them= apart,
> but I see some significant value in a document that just la= ys out (1)
> by itself. =A0The discussion above fits into that: there= 's nothing about
> this that has anything to do with the API; it's considerations of<= br>> whether MPTCP is, in general, advantageous, detrimental, or neutral=
> for any particular application use case... and that's importan= t.
>
> It becomes something of a problem when this document has some,= but
> insufficient, discussion about this, as in this case. =A0It= 9;s easy to
> say that applications in general have to deal with burs= tiness on the
> Internet, so adding a bit more probably won't hurt... but, as Clau= dio
> points out, that might not be true for all application types, a= nd
> further discussion of this is warranted. =A0The oversimplified s= tatement
> might be OK for this document, or it might be problematic if it's<= br>> taken as a valid statement to apply to all Internet applications. = =A0And
> there are other points in this document that fall into this = category.
>
> What should we do about that? =A0I've looked at the other = MPTCP
> documents, and we have a very cursory section in RFC 6182 (MP= TCP
> Architecture), "6.1 =A0Interactions with Applications"= ;. =A0Should there be
> another document that goes into more detail about application
> = considerations for MPTCP? =A0And what do we do with those issues in this> document in the meantime? =A0Leave them as they are? =A0Pull them out=
> altogether? =A0Change them to indicate that more work needs to be done=
> on application considerations?
>
> Barry, Applications= AD

--20cf302669f279280704d0ee8a85-- From barryleiba.mailing.lists@gmail.com Sun Dec 16 15:13:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9CF21F8738; Sun, 16 Dec 2012 15:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.044 X-Spam-Level: X-Spam-Status: No, score=-103.044 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jtdSH3Xzr9b; Sun, 16 Dec 2012 15:13:02 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3957021F86D9; Sun, 16 Dec 2012 15:13:01 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so4157158lbk.31 for ; Sun, 16 Dec 2012 15:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XdPW6Em3ERt9x+ZG9pqrK7feXlcbz5aFYfBkS0Qxq4c=; b=jAaX9cKoJhomGJr/GqOcqHjDt1Hnbw/TU95k9rJyBqUypyFqULQpRbg+W7u1g3fJ2t MAaJXVhmxAm1aTS01A40tLcX5pdgVFcako5z/RtEXJakkEK5T5KSECM3sAigdQ3CAfRc mFl014JnPHESPKPmXdx5eluNupA98dRevldNhUSzFyvHzlWJ0VCbnE/nIzkTSxhP8Pb0 eXaFVxXmxkOJOzqHedKJqbiLcOecNVqUQUxSAJjB2NoQOPWttLtqTqnLGgW+NKYK2J9O XrKV0wuMGGCjijAOTtX6TdWSLhJAlqU+EVMVGyXDaQvTSwm4DE43vhWFH6E2WlHJIYjv tKyQ== MIME-Version: 1.0 Received: by 10.112.101.135 with SMTP id fg7mr5087581lbb.87.1355699575857; Sun, 16 Dec 2012 15:12:55 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Sun, 16 Dec 2012 15:12:55 -0800 (PST) In-Reply-To: References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> Date: Sun, 16 Dec 2012 18:12:55 -0500 X-Google-Sender-Auth: 2OE11SKONsT-ucV1TskA7vwKvlw Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 23:13:05 -0000 Anyone have any comments on what I suggested below? Barry On Tue, Dec 11, 2012 at 11:25 PM, Barry Leiba wrote: >> Personally -- to me, it seems like you're getting hung up on the word "add." > ... >> "add" means what the format definition says it means, because otherwise >> we have to rationalise all of the different systems people might use it with >> to make sense. > > OK, I'll buy that. Then let's take a different approach, and make it > clearer that it's Humpty Dumpty's version of "add", so maybe neither I > nor Alice will get hung up on it: > > OLD > The "add" operation adds a new value at the target location. The > operation object MUST contain a "value" member that specifies the > value to be added. > NEW > The "add" operation performs the following function, depending upon > what the target location references (see details below): > > o If the target location specifies an array index, a new value is > inserted into the array at the specified index. > > o If the target location specifies an object member that does not > already exist, a new member is added to the object. > > o If the target location specifies an object member that does > exist, that member's value is replaced. > END > > That may be wordier than we need, but I think it makes the point... > feel free to wordsmith. With something like that, I think we can say > that we had to pick a name, "add" was picked, and it means exactly > what we choose it to mean - neither more nor less. And that's glory > for you. > > Barry From john@jck.com Sun Dec 16 15:53:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D938021F843A; Sun, 16 Dec 2012 15:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ESgJaY8cmme; Sun, 16 Dec 2012 15:53:31 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5980121F8430; Sun, 16 Dec 2012 15:53:31 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TkO1O-0005ra-Iz; Sun, 16 Dec 2012 18:53:26 -0500 X-Vipre-Scanned: 034D352B002C31034D3678-TDI Date: Sun, 16 Dec 2012 18:53:25 -0500 From: John C Klensin To: Barry Leiba , Mark Nottingham Message-ID: <5C6A104276F197129659DF24@[192.168.1.128]> In-Reply-To: References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IETF discussion list , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 23:53:32 -0000 --On Sunday, December 16, 2012 18:12 -0500 Barry Leiba wrote: > Anyone have any comments on what I suggested below? How about "+1" --complete agreement. The terminology, if interpreted in a "normal English" context, lies somewhere between confusing and misleading and a precise local definition is the more efficient fix. john >... > On Tue, Dec 11, 2012 at 11:25 PM, Barry Leiba > wrote: >>> Personally -- to me, it seems like you're getting hung up on >>> the word "add." >> ... >>> "add" means what the format definition says it means, >>> because otherwise we have to rationalise all of the >>> different systems people might use it with to make sense. >> >> OK, I'll buy that. Then let's take a different approach, and >> make it clearer that it's Humpty Dumpty's version of "add", >> so maybe neither I nor Alice will get hung up on it: >... From mnot@mnot.net Sun Dec 16 16:31:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D9A21F8514; Sun, 16 Dec 2012 16:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.029 X-Spam-Level: X-Spam-Status: No, score=-104.029 tagged_above=-999 required=5 tests=[AWL=-1.430, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHeA2I-e7VRQ; Sun, 16 Dec 2012 16:31:38 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id F3D0221F84F8; Sun, 16 Dec 2012 16:31:37 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.33.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0B3A6509B7; Sun, 16 Dec 2012 19:31:33 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Mon, 17 Dec 2012 11:31:29 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <45747DE2-66C7-4198-9BA2-06B3D27E6F2C@mnot.net> References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 00:31:38 -0000 Works for me. On 17/12/2012, at 10:12 AM, Barry Leiba wrote: > Anyone have any comments on what I suggested below? >=20 > Barry >=20 > On Tue, Dec 11, 2012 at 11:25 PM, Barry Leiba = wrote: >>> Personally -- to me, it seems like you're getting hung up on the = word "add." >> ... >>> "add" means what the format definition says it means, because = otherwise >>> we have to rationalise all of the different systems people might use = it with >>> to make sense. >>=20 >> OK, I'll buy that. Then let's take a different approach, and make it >> clearer that it's Humpty Dumpty's version of "add", so maybe neither = I >> nor Alice will get hung up on it: >>=20 >> OLD >> The "add" operation adds a new value at the target location. The >> operation object MUST contain a "value" member that specifies the >> value to be added. >> NEW >> The "add" operation performs the following function, depending upon >> what the target location references (see details below): >>=20 >> o If the target location specifies an array index, a new value is >> inserted into the array at the specified index. >>=20 >> o If the target location specifies an object member that does not >> already exist, a new member is added to the object. >>=20 >> o If the target location specifies an object member that does >> exist, that member's value is replaced. >> END >>=20 >> That may be wordier than we need, but I think it makes the point... >> feel free to wordsmith. With something like that, I think we can say >> that we had to pick a name, "add" was picked, and it means exactly >> what we choose it to mean - neither more nor less. And that's glory >> for you. >>=20 >> Barry -- Mark Nottingham http://www.mnot.net/ From mmorley@mpcm.com Sun Dec 16 16:33:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3AB21F8514 for ; Sun, 16 Dec 2012 16:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhWlu-keoGAl for ; Sun, 16 Dec 2012 16:33:38 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8563F21F84F8 for ; Sun, 16 Dec 2012 16:33:38 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so6501641vcb.31 for ; Sun, 16 Dec 2012 16:33:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=YWNL5PMJIo9RTkUe18XEXF22Cu5izble7vJ/5tBhSoU=; b=Ww+G6WjUFa5vdebCIRnLWv+ZrjIN9Ww761iXADBOlKmvm5DCbiYjCjdSjBWYqz5kKz GGIUQ+hPVwmF4+VuxJbqAivrWWYMQzx1gKgkqlPaoHnRJ9pXMaNsmYKZKGd1lbXEbMuq WitgDZy4oazrXyA60ovh4aVxsPm6mCdtKtljbCIzKdL99FrWpdhkWTRzL8FEkrU8iHNx JzSeWRkL/Rl+LaJ8DkamzsGRv0hnHdfWayPC6DlrACditDLq5YD0+h1pcMYfqSJuYrq8 DjmmB2o3KFp3nR8zljRZqpR//DDFnOlqZPGfgx+3XmgoZtcJMByWzxmtnMCzsRWRR2Vi AO3Q== MIME-Version: 1.0 Received: by 10.220.219.204 with SMTP id hv12mr20181599vcb.71.1355704417586; Sun, 16 Dec 2012 16:33:37 -0800 (PST) Sender: mmorley@mpcm.com Received: by 10.220.227.197 with HTTP; Sun, 16 Dec 2012 16:33:37 -0800 (PST) In-Reply-To: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> Date: Sun, 16 Dec 2012 19:33:37 -0500 X-Google-Sender-Auth: t1EVySSBC5Z8_bAkNvpNHwqwiK4 Message-ID: From: Matthew Morley To: James M Snell Content-Type: multipart/alternative; boundary=14dae9cfcea43b0e9d04d101883e X-Gm-Message-State: ALoCoQmGeVZyTPykd6v6RbtcJMrqaxqVg/nAS1JeZWlv39POD8PUem2XSVYc9LtV5EVN8o6F2qWD Cc: IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 00:33:39 -0000 --14dae9cfcea43b0e9d04d101883e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am usually lurking and struggling to keep up with these posts. But, I concur with James, this really is a non-issue in practice. The JSON Pointer expresses a path down a JSON object to a specific context. The Patch expresses a change within or to that context. Everything about the both standards is about that end context. If you want to confirm the type of the context before applying a patch, this should probably be part of a test operation. I'm not sure if this is possible at this point (?), but that is where the logic should exist. On Sun, Dec 16, 2012 at 12:22 AM, James M Snell wrote: > > > > On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre wrote: > >> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler >> wrote: >> > >> > Hmm.. I think that=92s quite problematic. Especially considering how J= SON >> Pointer is used in JSON Patch. >> >> I agree--I provided the same feedback privately. It seems >> straightforwardly unsound. >> >> > In practice it doesn't seem to be much of an issue. > > Specifically, if I GET an existing document and get an etag with the JSON= , > then make some changes and send a PATCH with If-Match, the fact that any > given pointer could point to an array or object member doesn't really > matter much. > > For example: > > > GET /the/doc HTTP/1.1 > > < HTTP/1.1 200 OK > ETag: "my-document-tag" > Content-Type: application/json > > {"1":"foo"} > > > PATCH /the/doc HTTP/1.1 > If-Match: "my-document-etag" > Content-Type: application/json-patch > > [{"op":"add","path":"/2","value":"bar"}] > > Generally speaking, someone should not be using PATCH to perform a partia= l > modification if they don't already have some knowledge in advance what th= ey > are modifying. The only time the apparent ambiguity becomes an issue is > when a client is blindly sending a patch to an unknown endpoint... in whi= ch > case, you get whatever you end up with. > > - James > > > >> - Rob >> >> >> > >> > -- >> > >> > Markus Lanthaler >> > >> > @markuslanthaler >> > >> > >> > >> > >> > >> > >> > >> > From: James M Snell [mailto:jasnell@gmail.com] >> > Sent: Friday, December 14, 2012 5:41 PM >> > To: Markus Lanthaler >> > Cc: IETF Discussion; IETF Apps Discuss >> > Subject: Re: [apps-discuss] Last Call: >> (JSON Pointer) to Proposed Stan= dard >> > >> > >> > >> > JSON Pointer does not distinguish between objects and arrays. That is >> not determined until the pointer is applied to an actual object instance= ... >> the pointer "/1" is valid against {"1":"a"} or ["a","b"] >> > >> > >> > >> > On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler < >> markus.lanthaler@gmx.net> wrote: >> > >> > I've asked that before but didn't get an answer. So let me ask again >> (even >> > though I'm quite sure it has already been asked by somebody else). >> > >> > How does JSON Pointer distinguish between objects and arrays? E.g. >> consider >> > the following JSON document: >> > >> > { >> > "foo": "bar", >> > "1": "baz" >> > } >> > >> > As I read the draft, the JSON Pointer "/1" would evaluate to "baz" eve= n >> > though that's probably not what the author intended. Is there a way to >> avoid >> > that? >> > >> > >> > Thanks, >> > Markus >> > >> > >> > >> > -- >> > Markus Lanthaler >> > @markuslanthaler >> > >> > >> > >> > >> > >> > > -----Original Message----- >> > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> > > bounces@ietf.org] On Behalf Of The IESG >> > > Sent: Tuesday, December 11, 2012 4:01 PM >> > > To: IETF-Announce >> > > Cc: apps-discuss@ietf.org >> > > Subject: [apps-discuss] Last Call: > > > 07.txt> (JSON Pointer) to Proposed Standard >> > > >> > > >> > > The IESG has received a request from the Applications Area Working >> > > Group >> > > WG (appsawg) to consider the following document: >> > > - 'JSON Pointer' >> > > as Proposed Standard >> > > >> > > The IESG plans to make a decision in the next few weeks, and solicit= s >> > > final comments on this action. Please send substantive comments to t= he >> > > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments >> may >> > > be >> > > sent to iesg@ietf.org instead. In either case, please retain the >> > > beginning of the Subject line to allow automated sorting. >> > > >> > > Abstract >> > > >> > > >> > > JSON Pointer defines a string syntax for identifying a specific >> > > value >> > > within a JSON document. >> > > >> > > >> > > >> > > >> > > The file can be obtained via >> > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ >> > > >> > > IESG discussion can be tracked via >> > > >> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ >> > > >> > > >> > > No IPR declarations have been submitted directly on this I-D. >> > > >> > > >> > > _______________________________________________ >> > > apps-discuss mailing list >> > > apps-discuss@ietf.org >> > > https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > >> > >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --=20 Matthew P. C. Morley --14dae9cfcea43b0e9d04d101883e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am usually lurking and struggling to keep up with these posts. But, I con= cur with James, this really is a non-issue in practice.

The JSON Poi= nter expresses=A0a path down a JSON object to a specific context.
The Pa= tch expresses a change within or to that context.
Everything about the both standards is about that end context.

If yo= u want to confirm the type of the context before applying a patch, this sho= uld probably be part of a test operation.=A0I'm not sure if this is pos= sible at this point (?), but that is where the logic should exist.


On Sun, Dec 16, 2012 at 12:22 AM, James = M Snell <jasnell@gmail.com> wrote:

=

On Sat, Dec 15, 2012 a= t 8:36 PM, Robert Sayre <sayrer@gmail.com> wrote:
On Fri, Dec 14, 2012 at 9:17 AM, Markus= Lanthaler
<markus.la= nthaler@gmx.net> wrote:
>
> Hmm.. I think that=92s quite problematic. Especially considering how J= SON Pointer is used in JSON Patch.

I agree--I provided the same feedback privately. It seems
straightforwardly unsound.


In practice it doesn't seem to be much of an issue.
<= div>
Specifically, if I GET an existing document and= get an etag with the JSON, then make some changes and send a PATCH with If= -Match, the fact that any given pointer could point to an array or object m= ember doesn't really matter much.

For example:

=A0 > =A0GET /the/doc HTTP/1.1

=A0 < =A0HTTP/1.1 200 OK
=A0 =A0 =A0ETag: "my-document-tag&= quot;
=A0 =A0 =A0Content-Type: applica= tion/json

=A0 =A0 =A0{"1"= :"foo"}

=A0 > =A0PATCH= /the/doc HTTP/1.1
= =A0 =A0 =A0If-Match: "my-document-etag"
=A0 =A0 =A0Content-Type: application/json-pat= ch

=A0 =A0 =A0[{"op":"add",&qu= ot;path":"/2","value":"bar"}]

Generally speaking, so= meone should not be using PATCH to perform a partial modification if they d= on't already have some knowledge in advance what they are modifying. Th= e only time the apparent ambiguity becomes an issue is when a client is bli= ndly sending a patch to an unknown endpoint... in which case, you get whate= ver you end up with.=A0

- James

=A0
- Rob


>
> --
>
> Markus Lanthaler
>
> @markuslanthaler
>
>
>
>
>
>
>
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Friday, December 14, 2012 5:41 PM
> To: Markus Lanthaler
> Cc: IETF Discussion; IETF Apps Discuss
> Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-js= on-pointer-07.txt> (JSON Pointer) to Proposed Standard
>
>
>
> JSON Pointer does not distinguish between objects and arrays. That is = not determined until the pointer is applied to an actual object instance...= the pointer "/1" is valid against {"1":"a"} = or ["a","b"]
>
>
>
> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler <markus.lanthaler@gmx.net&= gt; wrote:
>
> I've asked that before but didn't get an answer. So let me ask= again (even
> though I'm quite sure it has already been asked by somebody else).=
>
> How does JSON Pointer distinguish between objects and arrays? E.g. con= sider
> the following JSON document:
>
> {
> =A0 "foo": "bar",
> =A0 "1": "baz"
> }
>
> As I read the draft, the JSON Pointer "/1" would evaluate to= "baz" even
> though that's probably not what the author intended. Is there a wa= y to avoid
> that?
>
>
> Thanks,
> Markus
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
>
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> > bounces@iet= f.org] On Behalf Of The IESG
> > Sent: Tuesday, December 11, 2012 4:01 PM
> > To: IETF-Announce
> > Cc: ap= ps-discuss@ietf.org
> > Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-json-po= inter-
> > 07.txt> (JSON Pointer) to Proposed Standard
> >
> >
> > The IESG has received a request from the Applications Area Workin= g
> > Group
> > WG (appsawg) to consider the following document:
> > - 'JSON Pointer'
> > =A0 <draft-ietf-appsawg-json-pointer-07.txt> as Proposed St= andard
> >
> > The IESG plans to make a decision in the next few weeks, and soli= cits
> > final comments on this action. Please send substantive comments t= o the
> > ietf@ietf.org<= /a> mailing lists by 2012-12-25. Exceptionally, comments may
> > be
> > sent to iesg@i= etf.org instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> > =A0 =A0JSON Pointer defines a string syntax for identifying a spe= cific
> > value
> > =A0 =A0within a JSON document.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-ap= psawg-json-pointer/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-= ietf-appsawg-json-pointer/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-d= iscuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss




--
Matthew = P. C. Morley
--14dae9cfcea43b0e9d04d101883e-- From jasnell@gmail.com Sun Dec 16 18:35:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6399F21F8860; Sun, 16 Dec 2012 18:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.687 X-Spam-Level: X-Spam-Status: No, score=-3.687 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiXuVS202seV; Sun, 16 Dec 2012 18:35:43 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0446421F8825; Sun, 16 Dec 2012 18:35:42 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so8520174ieb.31 for ; Sun, 16 Dec 2012 18:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q8FyqoDZvfe5BBRIx/TCBDqQc0TuUN2a4xXnEYIFs5k=; b=NudX4eixKcjNA7nw6jd9AQ64zsrjeqOCWrCYEG/T75JbUlN/nI4tTheP1Qr7iN2v8i eo96ahbRlno5hbOhYnf/RzWXrzaV4e5TbggPQPPOquTpuXw21jiY4wZ9PrNu8BdkAFhy FiXcLmBankT/CjtEcuZirdxWMqqL3+LharHnrYquLlfRqp5W2RU4A6er8Co1YdBWg1z5 DoBVrMQ423eZhuDeT6K2HI0bGn0uL5ZRc+OVgzh/of/QDyEbZU6tma7uJ+ts1Ucp1vSz wjAROzx7VNT0I5hiVmWM13Jr/utTVT9WRiXZyfkCCMrMLWJKVSxGZLvBrJ4AhygOs5Ke weCQ== MIME-Version: 1.0 Received: by 10.50.151.165 with SMTP id ur5mr7887996igb.24.1355711742549; Sun, 16 Dec 2012 18:35:42 -0800 (PST) Received: by 10.64.7.19 with HTTP; Sun, 16 Dec 2012 18:35:42 -0800 (PST) Received: by 10.64.7.19 with HTTP; Sun, 16 Dec 2012 18:35:42 -0800 (PST) In-Reply-To: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> Date: Sun, 16 Dec 2012 18:35:42 -0800 Message-ID: From: James M Snell To: Matthew Morley Content-Type: multipart/alternative; boundary=e89a8f23541dd51e2704d1033cdd Cc: IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 02:35:44 -0000 --e89a8f23541dd51e2704d1033cdd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Using json-patch with my json-predicates draft allows testing for existing value type before applying a patch operation. On Dec 16, 2012 4:33 PM, "Matthew Morley" wrote: > I am usually lurking and struggling to keep up with these posts. But, I > concur with James, this really is a non-issue in practice. > > The JSON Pointer expresses a path down a JSON object to a specific contex= t. > The Patch expresses a change within or to that context. > Everything about the both standards is about that end context. > > If you want to confirm the type of the context before applying a patch, > this should probably be part of a test operation. I'm not sure if this is > possible at this point (?), but that is where the logic should exist. > > > On Sun, Dec 16, 2012 at 12:22 AM, James M Snell wrote= : > >> >> >> >> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre wrote: >> >>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler >>> wrote: >>> > >>> > Hmm.. I think that=E2=80=99s quite problematic. Especially considerin= g how >>> JSON Pointer is used in JSON Patch. >>> >>> I agree--I provided the same feedback privately. It seems >>> straightforwardly unsound. >>> >>> >> In practice it doesn't seem to be much of an issue. >> >> Specifically, if I GET an existing document and get an etag with the >> JSON, then make some changes and send a PATCH with If-Match, the fact th= at >> any given pointer could point to an array or object member doesn't reall= y >> matter much. >> >> For example: >> >> > GET /the/doc HTTP/1.1 >> >> < HTTP/1.1 200 OK >> ETag: "my-document-tag" >> Content-Type: application/json >> >> {"1":"foo"} >> >> > PATCH /the/doc HTTP/1.1 >> If-Match: "my-document-etag" >> Content-Type: application/json-patch >> >> [{"op":"add","path":"/2","value":"bar"}] >> >> Generally speaking, someone should not be using PATCH to perform a >> partial modification if they don't already have some knowledge in advanc= e >> what they are modifying. The only time the apparent ambiguity becomes an >> issue is when a client is blindly sending a patch to an unknown endpoint= ... >> in which case, you get whatever you end up with. >> >> - James >> >> >> >>> - Rob >>> >>> >>> > >>> > -- >>> > >>> > Markus Lanthaler >>> > >>> > @markuslanthaler >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > From: James M Snell [mailto:jasnell@gmail.com] >>> > Sent: Friday, December 14, 2012 5:41 PM >>> > To: Markus Lanthaler >>> > Cc: IETF Discussion; IETF Apps Discuss >>> > Subject: Re: [apps-discuss] Last Call: >>> (JSON Pointer) to Proposed Sta= ndard >>> > >>> > >>> > >>> > JSON Pointer does not distinguish between objects and arrays. That is >>> not determined until the pointer is applied to an actual object instanc= e... >>> the pointer "/1" is valid against {"1":"a"} or ["a","b"] >>> > >>> > >>> > >>> > On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler < >>> markus.lanthaler@gmx.net> wrote: >>> > >>> > I've asked that before but didn't get an answer. So let me ask again >>> (even >>> > though I'm quite sure it has already been asked by somebody else). >>> > >>> > How does JSON Pointer distinguish between objects and arrays? E.g. >>> consider >>> > the following JSON document: >>> > >>> > { >>> > "foo": "bar", >>> > "1": "baz" >>> > } >>> > >>> > As I read the draft, the JSON Pointer "/1" would evaluate to "baz" ev= en >>> > though that's probably not what the author intended. Is there a way t= o >>> avoid >>> > that? >>> > >>> > >>> > Thanks, >>> > Markus >>> > >>> > >>> > >>> > -- >>> > Markus Lanthaler >>> > @markuslanthaler >>> > >>> > >>> > >>> > >>> > >>> > > -----Original Message----- >>> > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >>> > > bounces@ietf.org] On Behalf Of The IESG >>> > > Sent: Tuesday, December 11, 2012 4:01 PM >>> > > To: IETF-Announce >>> > > Cc: apps-discuss@ietf.org >>> > > Subject: [apps-discuss] Last Call: >> > > 07.txt> (JSON Pointer) to Proposed Standard >>> > > >>> > > >>> > > The IESG has received a request from the Applications Area Working >>> > > Group >>> > > WG (appsawg) to consider the following document: >>> > > - 'JSON Pointer' >>> > > as Proposed Standard >>> > > >>> > > The IESG plans to make a decision in the next few weeks, and solici= ts >>> > > final comments on this action. Please send substantive comments to >>> the >>> > > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments >>> may >>> > > be >>> > > sent to iesg@ietf.org instead. In either case, please retain the >>> > > beginning of the Subject line to allow automated sorting. >>> > > >>> > > Abstract >>> > > >>> > > >>> > > JSON Pointer defines a string syntax for identifying a specific >>> > > value >>> > > within a JSON document. >>> > > >>> > > >>> > > >>> > > >>> > > The file can be obtained via >>> > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ >>> > > >>> > > IESG discussion can be tracked via >>> > > >>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ >>> > > >>> > > >>> > > No IPR declarations have been submitted directly on this I-D. >>> > > >>> > > >>> > > _______________________________________________ >>> > > apps-discuss mailing list >>> > > apps-discuss@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/apps-discuss >>> > >>> > _______________________________________________ >>> > apps-discuss mailing list >>> > apps-discuss@ietf.org >>> > https://www.ietf.org/mailman/listinfo/apps-discuss >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > apps-discuss mailing list >>> > apps-discuss@ietf.org >>> > https://www.ietf.org/mailman/listinfo/apps-discuss >>> > >>> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > > -- > Matthew P. C. Morley > --e89a8f23541dd51e2704d1033cdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Using json-patch with my json-predicates draft allows testin= g for existing value type before applying a patch operation.

On Dec 16, 2012 4:33 PM, "Matthew Morley&qu= ot; <matt@mpcm.com> wrote:
I am usually lurking and struggling to keep up with these posts. But, I con= cur with James, this really is a non-issue in practice.

The JSON Poi= nter expresses=C2=A0a path down a JSON object to a specific context.
The= Patch expresses a change within or to that context.
Everything about the both standards is about that end context.

If yo= u want to confirm the type of the context before applying a patch, this sho= uld probably be part of a test operation.=C2=A0I'm not sure if this is = possible at this point (?), but that is where the logic should exist.


On Sun, Dec 16, 2012 at 12:22 AM, James = M Snell <jasnell@gmail.com> wrote:

=

On Sat, Dec 15, 2012 at 8:36 PM, Ro= bert Sayre <sayrer@gmail.com> wrote:
On Fri, Dec 14, 2012 at 9:17 AM, Markus= Lanthaler
<markus.la= nthaler@gmx.net> wrote:
>
> Hmm.. I think that=E2=80=99s quite problematic. Especially considering= how JSON Pointer is used in JSON Patch.

I agree--I provided the same feedback privately. It seems
straightforwardly unsound.


In practice it doesn't seem to be much of an issue.
<= div>
Specifically, if I GET an existing document and= get an etag with the JSON, then make some changes and send a PATCH with If= -Match, the fact that any given pointer could point to an array or object m= ember doesn't really matter much.

For example:

=C2=A0 > =C2=A0GET /the/doc HTTP/1.1

=C2=A0 < =C2=A0HTTP/1.1 200 OK
<= div>=C2=A0 =C2=A0 =C2=A0ETag: "m= y-document-tag"
=C2=A0 =C2=A0 =C2=A0Content-Type= : application/json
<= br>
=C2=A0 =C2=A0 = =C2=A0{"1":"foo"}

=C2=A0 > =C2= =A0PATCH /the/doc HTTP/1.1
=C2=A0 =C2=A0 =C2=A0If-Match: "my-document-etag"
=C2=A0 =C2=A0 =C2=A0Content-T= ype: application/json-patch

=C2=A0 =C2=A0 =C2=A0[{"op":"add&= quot;,"path":"/2","value":"bar"}]

Generally speaking, so= meone should not be using PATCH to perform a partial modification if they d= on't already have some knowledge in advance what they are modifying. Th= e only time the apparent ambiguity becomes an issue is when a client is bli= ndly sending a patch to an unknown endpoint... in which case, you get whate= ver you end up with.=C2=A0

- James

=C2=A0
- Rob


>
> --
>
> Markus Lanthaler
>
> @markuslanthaler
>
>
>
>
>
>
>
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Friday, December 14, 2012 5:41 PM
> To: Markus Lanthaler
> Cc: IETF Discussion; IETF Apps Discuss
> Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-js= on-pointer-07.txt> (JSON Pointer) to Proposed Standard
>
>
>
> JSON Pointer does not distinguish between objects and arrays. That is = not determined until the pointer is applied to an actual object instance...= the pointer "/1" is valid against {"1":"a"} = or ["a","b"]
>
>
>
> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler <markus.lanthaler@gmx.net&= gt; wrote:
>
> I've asked that before but didn't get an answer. So let me ask= again (even
> though I'm quite sure it has already been asked by somebody else).=
>
> How does JSON Pointer distinguish between objects and arrays? E.g. con= sider
> the following JSON document:
>
> {
> =C2=A0 "foo": "bar",
> =C2=A0 "1": "baz"
> }
>
> As I read the draft, the JSON Pointer "/1" would evaluate to= "baz" even
> though that's probably not what the author intended. Is there a wa= y to avoid
> that?
>
>
> Thanks,
> Markus
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
>
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> > bounces@iet= f.org] On Behalf Of The IESG
> > Sent: Tuesday, December 11, 2012 4:01 PM
> > To: IETF-Announce
> > Cc: ap= ps-discuss@ietf.org
> > Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-json-po= inter-
> > 07.txt> (JSON Pointer) to Proposed Standard
> >
> >
> > The IESG has received a request from the Applications Area Workin= g
> > Group
> > WG (appsawg) to consider the following document:
> > - 'JSON Pointer'
> > =C2=A0 <draft-ietf-appsawg-json-pointer-07.txt> as Proposed= Standard
> >
> > The IESG plans to make a decision in the next few weeks, and soli= cits
> > final comments on this action. Please send substantive comments t= o the
> > ietf@ietf.org<= /a> mailing lists by 2012-12-25. Exceptionally, comments may
> > be
> > sent to iesg@i= etf.org instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> > =C2=A0 =C2=A0JSON Pointer defines a string syntax for identifying= a specific
> > value
> > =C2=A0 =C2=A0within a JSON document.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-ap= psawg-json-pointer/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-= ietf-appsawg-json-pointer/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-d= iscuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8f23541dd51e2704d1033cdd-- From mnot@mnot.net Sun Dec 16 19:30:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E54F21F85C4; Sun, 16 Dec 2012 19:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.935 X-Spam-Level: X-Spam-Status: No, score=-103.935 tagged_above=-999 required=5 tests=[AWL=-1.336, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3FnpCkCz3tq; Sun, 16 Dec 2012 19:30:26 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 51F1921F85BA; Sun, 16 Dec 2012 19:30:26 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.33.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 714C0509B8; Sun, 16 Dec 2012 22:30:23 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Mon, 17 Dec 2012 14:30:21 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E0F71D3-DC1C-4342-AFB1-D2CAAA71AA2E@mnot.net> References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 03:30:27 -0000 Now in SVN. On 12/12/2012, at 3:25 PM, Barry Leiba wrote: >> Personally -- to me, it seems like you're getting hung up on the word = "add." > ... >> "add" means what the format definition says it means, because = otherwise >> we have to rationalise all of the different systems people might use = it with >> to make sense. >=20 > OK, I'll buy that. Then let's take a different approach, and make it > clearer that it's Humpty Dumpty's version of "add", so maybe neither I > nor Alice will get hung up on it: >=20 > OLD > The "add" operation adds a new value at the target location. The > operation object MUST contain a "value" member that specifies the > value to be added. > NEW > The "add" operation performs the following function, depending upon > what the target location references (see details below): >=20 > o If the target location specifies an array index, a new value is > inserted into the array at the specified index. >=20 > o If the target location specifies an object member that does not > already exist, a new member is added to the object. >=20 > o If the target location specifies an object member that does > exist, that member's value is replaced. > END >=20 > That may be wordier than we need, but I think it makes the point... > feel free to wordsmith. With something like that, I think we can say > that we had to pick a name, "add" was picked, and it means exactly > what we choose it to mean - neither more nor less. And that's glory > for you. >=20 > Barry -- Mark Nottingham http://www.mnot.net/ From conal.tuohy@gmail.com Sun Dec 16 20:14:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D8221F88D1 for ; Sun, 16 Dec 2012 20:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giVCNjm7YbnU for ; Sun, 16 Dec 2012 20:14:24 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEBF21F88C4 for ; Sun, 16 Dec 2012 20:14:24 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so3372771pad.31 for ; Sun, 16 Dec 2012 20:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=8tuqDzrC1jIhNPDcYdJhKCJiX83xI86hGv2iRaOknCw=; b=iz5HbXAyTTQCRM7ug7niCE1gwRkHMgMc2goB4EC2A1fN7hPb2UEQwJkABhaPKPf87w VE33HqoAL+7Gq4rk/uGfr6Hr/ATZUHimDRcDkDygBbcq091cYXqKxpdA4k+k4hChnnFu LtQoa/jwHs6KRDB34JqsXkiLEY+/RYEXQhVlSgRsNVH8rwJ5t92eZb7P0bSETCd9CBGX srkb1R9naNTdqozGr7D81sm08Sgwl1zAwm1xnNM84xuD85P3sciTP8oDL/kE7WUlBG6x nGQ/UUEDCok/FQ00yir1qqBFs9C7yyqM3tAgobTZGbk8Xnv6nX1lTxS4EY0RM+q7FrBh 7XkQ== Received: by 10.68.143.162 with SMTP id sf2mr39356307pbb.137.1355717663808; Sun, 16 Dec 2012 20:14:23 -0800 (PST) Received: from [10.1.1.4] (d58-106-35-12.rdl801.qld.optusnet.com.au. [58.106.35.12]) by mx.google.com with ESMTPS id ue7sm7415126pbc.53.2012.12.16.20.14.20 (version=SSLv3 cipher=OTHER); Sun, 16 Dec 2012 20:14:22 -0800 (PST) Sender: Conal Tuohy Message-ID: <50CE9C18.9080004@versi.edu.au> Date: Mon, 17 Dec 2012 14:14:16 +1000 From: Conal Tuohy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net> <1E0F71D3-DC1C-4342-AFB1-D2CAAA71AA2E@mnot.net> In-Reply-To: <1E0F71D3-DC1C-4342-AFB1-D2CAAA71AA2E@mnot.net> Content-Type: multipart/alternative; boundary="------------000307070500070209070702" Subject: Re: [apps-discuss] Last Call: (JSON Patch) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 04:14:25 -0000 This is a multi-part message in MIME format. --------------000307070500070209070702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 17/12/12 13:30, Mark Nottingham wrote: > Now in SVN. > > > On 12/12/2012, at 3:25 PM, Barry Leiba wrote: > >>> Personally -- to me, it seems like you're getting hung up on the word "add." >> ... >>> "add" means what the format definition says it means, because otherwise >>> we have to rationalise all of the different systems people might use it with >>> to make sense. Yes, you can (try to) define the word "add" to mean whatever you like, but if several people have already quibbled about the word, then it must not be a clear label for the operation in question. To my mind, if you "add" to an object it should end up larger than before. I think an operation which can actually remove the contents of an object can't be called "add" without conflicting with that intuition. I also think the operation is too complex (in that it behaves differently in different circumstances). Is there any loss in splitting it into two operations with simpler semantics? > o If the target location specifies an array index, a new value is > inserted into the array at the specified index. I would call that "insert" (rather than "add", because "insert" implies a point of insertion) > o If the target location specifies an object member that does not > already exist, a new member is added to the object. > > o If the target location specifies an object member that does > exist, that member's value is replaced. I would call that "put" (as in HTTP), or perhaps "set". -- Conal Tuohy HuNI Technical Coordinator Victorian eResearch Strategic Initiative Skype: conal.tuohy Twitter: @conal_tuohy Mobile: +61-466324297 --------------000307070500070209070702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 17/12/12 13:30, Mark Nottingham wrote:
Now in SVN.


On 12/12/2012, at 3:25 PM, Barry Leiba <barryleiba@computer.org> wrote:


Personally -- to me, it seems like you're getting hung up on the word "add."

...

"add" means what the format definition says it means, because otherwise
we have to rationalise all of the different systems people might use it with
to make sense.
Yes, you can (try to) define the word "add" to mean whatever you like, but if several people have already quibbled about the word, then it must not be a clear label for the operation in question.

To my mind, if you "add" to an object it should end up larger than before. I think an operation which can actually remove the contents of an object can't be called "add" without conflicting with that intuition.

I also think the operation is too complex (in that it behaves differently in different circumstances). Is there any loss in splitting it into two operations with simpler semantics? 
  o  If the target location specifies an array index, a new value is
     inserted into the array at the specified index.
I would call that "insert" (rather than "add", because "insert" implies a point of insertion)
  o  If the target location specifies an object member that does not
     already exist, a new member is added to the object.

  o  If the target location specifies an object member that does
     exist, that member's value is replaced.
I would call that "put" (as in HTTP), or perhaps "set".



--
Conal Tuohy
HuNI Technical Coordinator
Victorian eResearch Strategic Initiative
Skype: conal.tuohy
Twitter: @conal_tuohy
Mobile: +61-466324297
--------------000307070500070209070702-- From conal.tuohy@gmail.com Sun Dec 16 20:27:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDB721F850E for ; Sun, 16 Dec 2012 20:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzRdYJLH3QQR for ; Sun, 16 Dec 2012 20:27:43 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68B2F21F854D for ; Sun, 16 Dec 2012 20:27:43 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2307552dae.31 for ; Sun, 16 Dec 2012 20:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=5Ia7uK0SaaVo5h3IJFZxSfrHLDSfQH+AG3IBBpldqPA=; b=NuNq/ZKVr6kFaw8Pc04mtEFUuQRKYXVy8i/BLwF7lcyagtPn3HiARnoLvCjxSrHqf0 uOBQ7ofbK2vUHxzvoZHPp25rSORp24+vJ0eWhYWAw7sRwBI1uAitkeV+d1ptmgSfYnZU zbxYlfdj9q6PmE8w0SbVI7WnoySQVgMHV4EMdQYfdUpqffYuWriAD48IkXJZ//9VT15N glo4LvXZfreZLuScc6OcvlES9FrlI/HFvtttcQ1/svTJl/lnoo3FFL4gYZppFtkGUeeB yvLfPdg05euviG81KAaLp3nCTd5PM4i98bDLSuDEmcNIDpGtFeZh1SGrTjzcS8C+PQwN Mxrw== Received: by 10.66.73.105 with SMTP id k9mr38958250pav.37.1355718463079; Sun, 16 Dec 2012 20:27:43 -0800 (PST) Received: from [10.1.1.4] (d58-106-35-12.rdl801.qld.optusnet.com.au. [58.106.35.12]) by mx.google.com with ESMTPS id sk1sm7450284pbc.0.2012.12.16.20.27.40 (version=SSLv3 cipher=OTHER); Sun, 16 Dec 2012 20:27:42 -0800 (PST) Sender: Conal Tuohy Message-ID: <50CE9F39.4020601@versi.edu.au> Date: Mon, 17 Dec 2012 14:27:37 +1000 From: Conal Tuohy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> In-Reply-To: <50CA92A2.5060301@versi.edu.au> Content-Type: multipart/alternative; boundary="------------090404010900060103030705" Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 04:27:44 -0000 This is a multi-part message in MIME format. --------------090404010900060103030705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Can I suggest that the XML format known as the media type "application/api-problem+xml" should use an XML namespace? Using namespaces to disambiguate XML vocabularies is considered best practice. It allows for an XML document to be correctly interpreted even outside the HTTP context in which it might appear (i.e. without knowing the specific internet media type). See http://www.w3.org/TR/webarch/#xml-namespaces for details, and also see http://www.w3.org/TR/webarch/#namespace-document for the reasons why namespace URIs should resolve to useful documentation (such as an RFC document). It seems to me that the relationship between the names of JSON objects and corresponding XML elements also needs clarification. For instance, the XML schema allows those objects to be in "##any" namespace, but how would those namespaces relate to JSON expressions of the same error report? If a JSON problem report were to be transformed into XML, what XML namespaces would actually be used for any extension members? Conversely, if an XML-formatted problem report were converted to JSON, how would any XML namespaces be rendered in the JSON? Conal -- Conal Tuohy eResearch Business Analyst Victorian eResearch Strategic Initiative +61-466324297 -- Conal Tuohy HuNI Technical Coordinator Victorian eResearch Strategic Initiative Skype: conal.tuohy Twitter: @conal_tuohy Mobile: +61-466324297 --------------090404010900060103030705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Can I suggest that the XML format known as the media type "application/api-problem+xml" should use an XML namespace?

Using namespaces to disambiguate XML vocabularies is considered best practice. It allows for an XML document to be correctly interpreted even outside the HTTP context in which it might appear (i.e. without knowing the specific internet media type). See http://www.w3.org/TR/webarch/#xml-namespaces for details, and also see http://www.w3.org/TR/webarch/#namespace-document for the reasons why namespace URIs should resolve to useful documentation (such as an RFC document).

It seems to me that the relationship between the names of JSON objects and corresponding XML elements also needs clarification.

For instance, the XML schema allows those objects to be in "##any" namespace, but how would those namespaces relate to JSON expressions of the same error report? If a JSON problem report were to be transformed into XML, what XML namespaces would actually be used for any extension members? Conversely, if an XML-formatted problem report were converted to JSON, how would any XML namespaces be rendered in the JSON?

Conal

--
Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297


--
Conal Tuohy
HuNI Technical Coordinator
Victorian eResearch Strategic Initiative
Skype: conal.tuohy
Twitter: @conal_tuohy
Mobile: +61-466324297
--------------090404010900060103030705-- From sayrer@gmail.com Sun Dec 16 20:36:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE8121F8942; Sun, 16 Dec 2012 20:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfZihLLkO+VK; Sun, 16 Dec 2012 20:36:20 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48B5321F8938; Sun, 16 Dec 2012 20:36:20 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2616998wey.31 for ; Sun, 16 Dec 2012 20:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GnRoInqjd7m2nYXc/NT6NIXevyMJ2gW4lBkFEtgK0RU=; b=iRw4LU4XLoCD+H3W/i6Q1lzVMcVx36bNwqW8hZamohMO4NCnDi4Z2dzGCjko+Owv9Z 7TFVfEeDpn3jKpk4xVbIwaOBmawFnKNMmS6651yMaGR+F2zQT9YT8/jZW8kszvrQAJau 5oq8e5cW1GEZbO6bJFzvznOUfRGuGyVIgex8/sCwzT2tt3jEW3GR0AKIF2/5nwlhT3yA X+Q6G3m2hodu6jbDVgA36bBxpPOA6nh2XUK9lhD1nkW2SaorZA60Bt7nZzRF5dCIL/1B wQzjiF2fhLoarDDcSDdejDyjivQA2roR8RUVUcGXnpCjvuB84OOr9+Q4y6pM7fMlOE5N OL2w== MIME-Version: 1.0 Received: by 10.194.78.162 with SMTP id c2mr14467013wjx.46.1355718979294; Sun, 16 Dec 2012 20:36:19 -0800 (PST) Received: by 10.194.1.101 with HTTP; Sun, 16 Dec 2012 20:36:19 -0800 (PST) In-Reply-To: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> Date: Sun, 16 Dec 2012 20:36:19 -0800 Message-ID: From: Robert Sayre To: Matthew Morley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 04:36:21 -0000 The cost of fixing it seems low, either by changing the path syntax of JSON pointer or changing the names of operations applied to arrays. Array-like objects are common enough in JavaScript to make this a worry. The other suggestions either assume a particular policy for concurrent edits or require more machinery (test operation etc). Wouldn't it be simpler to make the patch format more precise? - Rob On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley wrote: > I am usually lurking and struggling to keep up with these posts. But, I > concur with James, this really is a non-issue in practice. > > The JSON Pointer expresses a path down a JSON object to a specific contex= t. > The Patch expresses a change within or to that context. > Everything about the both standards is about that end context. > > If you want to confirm the type of the context before applying a patch, t= his > should probably be part of a test operation. I'm not sure if this is > possible at this point (?), but that is where the logic should exist. > > > > On Sun, Dec 16, 2012 at 12:22 AM, James M Snell wrote= : >> >> >> >> >> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre wrote: >>> >>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler >>> wrote: >>> > >>> > Hmm.. I think that=92s quite problematic. Especially considering how = JSON >>> > Pointer is used in JSON Patch. >>> >>> I agree--I provided the same feedback privately. It seems >>> straightforwardly unsound. >>> >> >> In practice it doesn't seem to be much of an issue. >> >> Specifically, if I GET an existing document and get an etag with the JSO= N, >> then make some changes and send a PATCH with If-Match, the fact that any >> given pointer could point to an array or object member doesn't really ma= tter >> much. >> >> For example: >> >> > GET /the/doc HTTP/1.1 >> >> < HTTP/1.1 200 OK >> ETag: "my-document-tag" >> Content-Type: application/json >> >> {"1":"foo"} >> >> > PATCH /the/doc HTTP/1.1 >> If-Match: "my-document-etag" >> Content-Type: application/json-patch >> >> [{"op":"add","path":"/2","value":"bar"}] >> >> Generally speaking, someone should not be using PATCH to perform a parti= al >> modification if they don't already have some knowledge in advance what t= hey >> are modifying. The only time the apparent ambiguity becomes an issue is = when >> a client is blindly sending a patch to an unknown endpoint... in which c= ase, >> you get whatever you end up with. >> >> - James >> >> >>> >>> - Rob >>> >>> >>> > >>> > -- >>> > >>> > Markus Lanthaler >>> > >>> > @markuslanthaler >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > From: James M Snell [mailto:jasnell@gmail.com] >>> > Sent: Friday, December 14, 2012 5:41 PM >>> > To: Markus Lanthaler >>> > Cc: IETF Discussion; IETF Apps Discuss >>> > Subject: Re: [apps-discuss] Last Call: >>> > (JSON Pointer) to Proposed S= tandard >>> > >>> > >>> > >>> > JSON Pointer does not distinguish between objects and arrays. That is >>> > not determined until the pointer is applied to an actual object insta= nce... >>> > the pointer "/1" is valid against {"1":"a"} or ["a","b"] >>> > >>> > >>> > >>> > On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler >>> > wrote: >>> > >>> > I've asked that before but didn't get an answer. So let me ask again >>> > (even >>> > though I'm quite sure it has already been asked by somebody else). >>> > >>> > How does JSON Pointer distinguish between objects and arrays? E.g. >>> > consider >>> > the following JSON document: >>> > >>> > { >>> > "foo": "bar", >>> > "1": "baz" >>> > } >>> > >>> > As I read the draft, the JSON Pointer "/1" would evaluate to "baz" ev= en >>> > though that's probably not what the author intended. Is there a way t= o >>> > avoid >>> > that? >>> > >>> > >>> > Thanks, >>> > Markus >>> > >>> > >>> > >>> > -- >>> > Markus Lanthaler >>> > @markuslanthaler >>> > >>> > >>> > >>> > >>> > >>> > > -----Original Message----- >>> > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >>> > > bounces@ietf.org] On Behalf Of The IESG >>> > > Sent: Tuesday, December 11, 2012 4:01 PM >>> > > To: IETF-Announce >>> > > Cc: apps-discuss@ietf.org >>> > > Subject: [apps-discuss] Last Call: >> > > 07.txt> (JSON Pointer) to Proposed Standard >>> > > >>> > > >>> > > The IESG has received a request from the Applications Area Working >>> > > Group >>> > > WG (appsawg) to consider the following document: >>> > > - 'JSON Pointer' >>> > > as Proposed Standard >>> > > >>> > > The IESG plans to make a decision in the next few weeks, and solici= ts >>> > > final comments on this action. Please send substantive comments to >>> > > the >>> > > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments >>> > > may >>> > > be >>> > > sent to iesg@ietf.org instead. In either case, please retain the >>> > > beginning of the Subject line to allow automated sorting. >>> > > >>> > > Abstract >>> > > >>> > > >>> > > JSON Pointer defines a string syntax for identifying a specific >>> > > value >>> > > within a JSON document. >>> > > >>> > > >>> > > >>> > > >>> > > The file can be obtained via >>> > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ >>> > > >>> > > IESG discussion can be tracked via >>> > > >>> > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/bal= lot/ >>> > > >>> > > >>> > > No IPR declarations have been submitted directly on this I-D. >>> > > >>> > > >>> > > _______________________________________________ >>> > > apps-discuss mailing list >>> > > apps-discuss@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/apps-discuss >>> > >>> > _______________________________________________ >>> > apps-discuss mailing list >>> > apps-discuss@ietf.org >>> > https://www.ietf.org/mailman/listinfo/apps-discuss >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > apps-discuss mailing list >>> > apps-discuss@ietf.org >>> > https://www.ietf.org/mailman/listinfo/apps-discuss >>> > >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > > -- > Matthew P. C. Morley From conal.tuohy@gmail.com Sun Dec 16 20:48:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061B821F842B for ; Sun, 16 Dec 2012 20:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyRhFOOwSDsZ for ; Sun, 16 Dec 2012 20:48:01 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27E8F21F896E for ; Sun, 16 Dec 2012 20:48:01 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so3339502pbc.31 for ; Sun, 16 Dec 2012 20:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=DIRKpBdOH9zKGAtZD7CPqcnz3V2aCfdgvPenpIm3mdo=; b=Ayu1foF2kDg/PoROlEU0qc/YxjcTkLu1HctKB8T2vJ0S9bStQgsGYMsXb9+uuZEUEd OJE5kQ8JX0CO42NneeA9eSrS0hq/Fu3OoihdhcgRUKiDZEzWbNlS6iLe0hTKEsRt8n0W OEPdTV2LCKwyHHvObQoW98BVl+Y8o2pkrO0C14kmQJ1YnxAWN5WpLAbYA7gu5QcFGzZ8 RPNybRzbtIgtZpguLIpRFEO6tqwrwTFhxQoaaWN+wYzjRl1o+GfD+o3CxyOqt2xLRquv Nm/xSuT+D78EPo4Gavw9NkAbe8WoQJE+TgnPY3cyGw+C5dFgykYTjBfl8LlJN6/j2yxT 4+eg== Received: by 10.68.239.99 with SMTP id vr3mr39623571pbc.154.1355719680464; Sun, 16 Dec 2012 20:48:00 -0800 (PST) Received: from [10.1.1.4] (d58-106-35-12.rdl801.qld.optusnet.com.au. [58.106.35.12]) by mx.google.com with ESMTPS id k4sm7838525paz.26.2012.12.16.20.47.56 (version=SSLv3 cipher=OTHER); Sun, 16 Dec 2012 20:47:59 -0800 (PST) Sender: Conal Tuohy Message-ID: <50CEA3F9.8000709@versi.edu.au> Date: Mon, 17 Dec 2012 14:47:53 +1000 From: Conal Tuohy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060608010108030506070307" Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 04:48:22 -0000 This is a multi-part message in MIME format. --------------060608010108030506070307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 17/12/12 10:33, Matthew Morley wrote: > I am usually lurking and struggling to keep up with these posts. But, > I concur with James, this really is a non-issue in practice. > > The JSON Pointer expresses a path down a JSON object to a specific > context. > The Patch expresses a change within or to that context. > Everything about the both standards is about that end context. > > If you want to confirm the type of the context before applying a > patch, this should probably be part of a test operation. I'm not sure > if this is possible at this point (?), but that is where the logic > should exist. On the other hand, it's certainly true that this syntax has the potential to confuse programmers, and surely that should be avoided if possible? There's nothing to be gained by confusing coders. Having a distinct syntax for array indices and object names (as JSON itself does) would not be too difficult, and it would eliminate this particular confusion. Does JSON Pointer have any role outside of JSON Patch? I would guess so, given that it's specified separately. In which case, aren't there use cases where one might want to refer to a value in a JSON object other than for purposes of patching it, without explicit knowledge of a previous state of the object? In the XML world, the equivalent language XPath is used within a large number of other languages; XPointer, XSLT, XQuery, XForms, etc, etc. It would be a shame if the narrow requirements of JSON Patch were used to justify taking a shortcut with JSON Pointer, in a way that makes it less useful for other (non-patching) purposes. -- Conal Tuohy HuNI Technical Coordinator Victorian eResearch Strategic Initiative Skype: conal.tuohy Twitter: @conal_tuohy Mobile: +61-466324297 --------------060608010108030506070307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 17/12/12 10:33, Matthew Morley wrote:
I am usually lurking and struggling to keep up with these posts. But, I concur with James, this really is a non-issue in practice.

The JSON Pointer expresses a path down a JSON object to a specific context.
The Patch expresses a change within or to that context.
Everything about the both standards is about that end context.

If you want to confirm the type of the context before applying a patch, this should probably be part of a test operation. I'm not sure if this is possible at this point (?), but that is where the logic should exist.

On the other hand, it's certainly true that this syntax has the potential to confuse programmers, and surely that should be avoided if possible? There's nothing to be gained by confusing coders. Having a distinct syntax for array indices and object names (as JSON itself does) would not be too difficult, and it would eliminate this particular confusion.

Does JSON Pointer have any role outside of JSON Patch? I would guess so, given that it's specified separately. In which case, aren't there use cases where one might want to refer to a value in a JSON object other than for purposes of patching it, without explicit knowledge of a previous state of the object?

In the XML world, the equivalent language XPath is used within a large number of other languages; XPointer, XSLT, XQuery, XForms, etc, etc. It would be a shame if the narrow requirements of JSON Patch were used to justify taking a shortcut with JSON Pointer, in a way that makes it less useful for other (non-patching) purposes.



--
Conal Tuohy
HuNI Technical Coordinator
Victorian eResearch Strategic Initiative
Skype: conal.tuohy
Twitter: @conal_tuohy
Mobile: +61-466324297
--------------060608010108030506070307-- From mnot@mnot.net Sun Dec 16 21:34:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A78F21F884E for ; Sun, 16 Dec 2012 21:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=-1.505, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln+fJIswIH9a for ; Sun, 16 Dec 2012 21:34:36 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 598EB21F883D for ; Sun, 16 Dec 2012 21:34:34 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.33.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 93D45509B5; Mon, 17 Dec 2012 00:34:30 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <50CE9F39.4020601@versi.edu.au> Date: Mon, 17 Dec 2012 16:34:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> To: Conal Tuohy X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 05:34:37 -0000 Hi Conal, On 17/12/2012, at 3:27 PM, Conal Tuohy wrote: >=20 > Can I suggest that the XML format known as the media type = "application/api-problem+xml" should use an XML namespace? You can certainly suggest it :) > Using namespaces to disambiguate XML vocabularies is considered best = practice. It allows for an XML document to be correctly interpreted even = outside the HTTP context in which it might appear (i.e. without knowing = the specific internet media type). See = http://www.w3.org/TR/webarch/#xml-namespaces for details, and also see = http://www.w3.org/TR/webarch/#namespace-document for the reasons why = namespace URIs should resolve to useful documentation (such as an RFC = document). Yes, I'm familiar with the WebArch document. In practice, XML Namespaces = can cause a lot of developer confusion, and I'd put forth that they = should only be used where distributed extensibility is necessary, and = there are no other ways to achieve it.=20 Here, because the definition of the problem type (and thereby, its = extensions) is controlled by the person that mints it (using a = describedBy link), there isn't a need for distributed extensibility, as = far as I can see. Furthermore, using XML namespaces would force the use = of a similar mechanism with JSON, which would make me (and many others, = I think) unhappy. > It seems to me that the relationship between the names of JSON objects = and corresponding XML elements also needs clarification.=20 >=20 > For instance, the XML schema allows those objects to be in "##any" = namespace, but how would those namespaces relate to JSON expressions of = the same error report? If a JSON problem report were to be transformed = into XML, what XML namespaces would actually be used for any extension = members? Conversely, if an XML-formatted problem report were converted = to JSON, how would any XML namespaces be rendered in the JSON? I'm CC:ing Erik because he helped me add the XML format (which I was = somewhat reluctant to do).=20 No namespaces would be used, as I understand it. Erik, does the schema = need revision? Cheers, P.S. Conal, if you're in Melbourne, It'd be great to chat over a coffee = sometime; I'd love to hear more about your use cases. -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Sun Dec 16 21:41:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9544721F8B30; Sun, 16 Dec 2012 21:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.776 X-Spam-Level: X-Spam-Status: No, score=-103.776 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkMtbHboJWM7; Sun, 16 Dec 2012 21:41:31 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A73CA21F89E9; Sun, 16 Dec 2012 21:41:30 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.33.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4BA40509B7; Mon, 17 Dec 2012 00:41:27 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Mon, 17 Dec 2012 16:41:24 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> To: Robert Sayre X-Mailer: Apple Mail (2.1499) Cc: IETF Apps Discuss , IETF Discussion Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 05:41:33 -0000 Robert,=20 This was discussed extensively in the Working Group.=20 The root of the issue was that some people reflexively felt that this = was necessary, but upon reflection, we decided it wasn't; although it = seems "natural" to some, especially those coming from a static language = background, it didn't provide any utility. You might argue that someone who (for example) adds to "/foo/1" in the = mistaken belief that it's an array, when in fact it's an object, will = get surprising results. That's true, but if we were to solve this = problem, that person would still need to understand the underlying = semantics of "foo" to do anything useful to it -- and I'm not hearing = anyone complain about that (I hope). Put another way -- do you really think that people PATCHing something as = if it's an array (when in fact it's an object) is a significant, = real-world problem, given that the patch author already has to = understand the semantics of the document they're patching? I don't, and = the WG didn't either. Regards, On 17/12/2012, at 3:36 PM, Robert Sayre wrote: > The cost of fixing it seems low, either by changing the path syntax of > JSON pointer or changing the names of operations applied to arrays. > Array-like objects are common enough in JavaScript to make this a > worry. The other suggestions either assume a particular policy for > concurrent edits or require more machinery (test operation etc). > Wouldn't it be simpler to make the patch format more precise? >=20 > - Rob >=20 > On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley wrote: >> I am usually lurking and struggling to keep up with these posts. But, = I >> concur with James, this really is a non-issue in practice. >>=20 >> The JSON Pointer expresses a path down a JSON object to a specific = context. >> The Patch expresses a change within or to that context. >> Everything about the both standards is about that end context. >>=20 >> If you want to confirm the type of the context before applying a = patch, this >> should probably be part of a test operation. I'm not sure if this is >> possible at this point (?), but that is where the logic should exist. >>=20 >>=20 >>=20 >> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell = wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre = wrote: >>>>=20 >>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler >>>> wrote: >>>>>=20 >>>>> Hmm.. I think that=92s quite problematic. Especially considering = how JSON >>>>> Pointer is used in JSON Patch. >>>>=20 >>>> I agree--I provided the same feedback privately. It seems >>>> straightforwardly unsound. >>>>=20 >>>=20 >>> In practice it doesn't seem to be much of an issue. >>>=20 >>> Specifically, if I GET an existing document and get an etag with the = JSON, >>> then make some changes and send a PATCH with If-Match, the fact that = any >>> given pointer could point to an array or object member doesn't = really matter >>> much. >>>=20 >>> For example: >>>=20 >>>> GET /the/doc HTTP/1.1 >>>=20 >>> < HTTP/1.1 200 OK >>> ETag: "my-document-tag" >>> Content-Type: application/json >>>=20 >>> {"1":"foo"} >>>=20 >>>> PATCH /the/doc HTTP/1.1 >>> If-Match: "my-document-etag" >>> Content-Type: application/json-patch >>>=20 >>> [{"op":"add","path":"/2","value":"bar"}] >>>=20 >>> Generally speaking, someone should not be using PATCH to perform a = partial >>> modification if they don't already have some knowledge in advance = what they >>> are modifying. The only time the apparent ambiguity becomes an issue = is when >>> a client is blindly sending a patch to an unknown endpoint... in = which case, >>> you get whatever you end up with. >>>=20 >>> - James >>>=20 >>>=20 >>>>=20 >>>> - Rob >>>>=20 >>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Markus Lanthaler >>>>>=20 >>>>> @markuslanthaler >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: James M Snell [mailto:jasnell@gmail.com] >>>>> Sent: Friday, December 14, 2012 5:41 PM >>>>> To: Markus Lanthaler >>>>> Cc: IETF Discussion; IETF Apps Discuss >>>>> Subject: Re: [apps-discuss] Last Call: >>>>> (JSON Pointer) to = Proposed Standard >>>>>=20 >>>>>=20 >>>>>=20 >>>>> JSON Pointer does not distinguish between objects and arrays. That = is >>>>> not determined until the pointer is applied to an actual object = instance... >>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"] >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler >>>>> wrote: >>>>>=20 >>>>> I've asked that before but didn't get an answer. So let me ask = again >>>>> (even >>>>> though I'm quite sure it has already been asked by somebody else). >>>>>=20 >>>>> How does JSON Pointer distinguish between objects and arrays? E.g. >>>>> consider >>>>> the following JSON document: >>>>>=20 >>>>> { >>>>> "foo": "bar", >>>>> "1": "baz" >>>>> } >>>>>=20 >>>>> As I read the draft, the JSON Pointer "/1" would evaluate to "baz" = even >>>>> though that's probably not what the author intended. Is there a = way to >>>>> avoid >>>>> that? >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Markus >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Markus Lanthaler >>>>> @markuslanthaler >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >>>>>> bounces@ietf.org] On Behalf Of The IESG >>>>>> Sent: Tuesday, December 11, 2012 4:01 PM >>>>>> To: IETF-Announce >>>>>> Cc: apps-discuss@ietf.org >>>>>> Subject: [apps-discuss] Last Call: = >>>>> 07.txt> (JSON Pointer) to Proposed Standard >>>>>>=20 >>>>>>=20 >>>>>> The IESG has received a request from the Applications Area = Working >>>>>> Group >>>>>> WG (appsawg) to consider the following document: >>>>>> - 'JSON Pointer' >>>>>> as Proposed Standard >>>>>>=20 >>>>>> The IESG plans to make a decision in the next few weeks, and = solicits >>>>>> final comments on this action. Please send substantive comments = to >>>>>> the >>>>>> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, = comments >>>>>> may >>>>>> be >>>>>> sent to iesg@ietf.org instead. In either case, please retain the >>>>>> beginning of the Subject line to allow automated sorting. >>>>>>=20 >>>>>> Abstract >>>>>>=20 >>>>>>=20 >>>>>> JSON Pointer defines a string syntax for identifying a specific >>>>>> value >>>>>> within a JSON document. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The file can be obtained via >>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ >>>>>>=20 >>>>>> IESG discussion can be tracked via >>>>>>=20 >>>>>> = http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ >>>>>>=20 >>>>>>=20 >>>>>> No IPR declarations have been submitted directly on this I-D. >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> apps-discuss mailing list >>>>>> apps-discuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>=20 >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> apps-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> apps-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>=20 >>=20 >>=20 >> -- >> Matthew P. C. Morley > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From sayrer@gmail.com Mon Dec 17 02:01:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D254421F8A6B; Mon, 17 Dec 2012 02:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkR4QSNJZlE7; Mon, 17 Dec 2012 02:01:28 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 086DC21F842B; Mon, 17 Dec 2012 02:01:27 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so1794096wib.13 for ; Mon, 17 Dec 2012 02:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6oM4a7Ql/IhvEkMqKzq6CR/2utGalGeLqJHkLpoQrHY=; b=frcxaD1uQ1FSCm9pleQ2/EzcFmEyJmNBIlKhDrrbcGlxnSTPatWj0WwYufj7z5QTWo bnAZJHiGf+8EBEGrPKEI2dCLFVXoPVNd1LgIVnJhwt8l9Q6M68BFW+PNCrOp8oOWg/IO fSKG8n/gyr6qw/fuBYLFJIpyNkVdRF4FMkkh3jSNXnaT88jjqaRkMhLTyLn/c3yOKSpK cJNZ6lPQT8NpR8Q/4wuqdzl4T0WSIoowkr42IwX1lpTnjOVqU7QKrK7estC7BPmR+oGc CYGPBmjPGbbLj4W/sdDFKZow/+nVOGKEED36FlmF/l8rny5426kkeNtTdJb2Dpvr7zvA Hofg== MIME-Version: 1.0 Received: by 10.180.72.232 with SMTP id g8mr14601997wiv.0.1355738487127; Mon, 17 Dec 2012 02:01:27 -0800 (PST) Received: by 10.194.1.101 with HTTP; Mon, 17 Dec 2012 02:01:27 -0800 (PST) In-Reply-To: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 17 Dec 2012 02:01:27 -0800 Message-ID: From: Robert Sayre To: Mark Nottingham Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss , IETF Discussion Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 10:01:32 -0000 On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham wrote: > Robert, > > This was discussed extensively in the Working Group. Presumably every line of the document was discussed by the WG at some point. This phase of review is wider, and this point has been raised separately three times, so perhaps the WG should take another look. One thing that strikes me about the arguments in favor of the status quo is that they seem non-technical. Is there a technical case for leaving this ambiguity in the patch format? > The root of the issue was that some people reflexively felt that this was= necessary, but upon reflection, we decided it wasn't; although it seems "n= atural" to some, especially those coming from a static language background,= it didn't provide any utility. I'm approaching it as an implementor in JavaScript that happens to have spent some on the ECMAScript committee and implemented the native JSON.parse and JSON.stringify methods for Mozilla Firefox. I think this issue leaves open a chance for data corruption with no real upside. I could understand leaving it be if making arrays explicit in the patch format were complex or onerous, but I don't think anyone is arguing that. > > You might argue that someone who (for example) adds to "/foo/1" in the mi= staken belief that it's an array, when in fact it's an object, will get sur= prising results. That's true, but if we were to solve this problem, that pe= rson would still need to understand the underlying semantics of "foo" to do= anything useful to it -- and I'm not hearing anyone complain about that (I= hope). The first case that can come up is editing documents that have been refactored. It's quite common to refactor JSON documents as below when a little extra metadata is needed for a collection: { "foo":[1,2,3] } then becomes { "foo": "bar": "baz", "members": [1,2,3] } now, an operation on /foo/1 is quite a different thing in the second document. It's not too hard to see how a client that's been out of contact with the server for a while could send an addition to /foo intended for the array that's been moved down to "members". Now, there are ways to catch this if you're willing to bloat the patch document with other checks, or by insisting on a matching ETag. But one of the nice things about patch formats is that you can try for more optimistic concurrent editing. This ambiguity in the patch format makes it needlessly more costly to detect unsound edits. Another source of bugs from JavaScript side of things will be "array-like" objects. These are really quite common (jQuery lists, arguments object, etc), and authors very often don't realize they won't be serialized as an array. To be sure, this is a bug on the author's side, but some checks in the patch format would really help. They'll probably become even more common as ES6 is standardizing iterators http://wiki.ecmascript.org/doku.php?id=3Dharmony:iterators. Here's an example in a JS REPL using the arguments object (but keep in mind there are many other objects out there that behave this way). > function foo(list) { console.log(JSON.stringify(list)) } > function bar(a,b,c) { foo(arguments) } > bar("a", "b", "c"); {"0":"a","1":"b","2":"c"} > > Put another way -- do you really think Yes, really. > that people PATCHing something as if it's an array (when in fact it's an = object) is a significant, real-world problem, given that the patch author a= lready has to understand the semantics of the document they're patching? I don't see that requirement in the draft, and I certainly wouldn't bet on it being true in all cases. Wasn't one of the motivating use-cases for this patch format CouchDB? That software operates on arbitrary, user-defined JSON documents. - Rob > I don't, and the WG didn't either. > > Regards, > > > On 17/12/2012, at 3:36 PM, Robert Sayre wrote: > >> The cost of fixing it seems low, either by changing the path syntax of >> JSON pointer or changing the names of operations applied to arrays. >> Array-like objects are common enough in JavaScript to make this a >> worry. The other suggestions either assume a particular policy for >> concurrent edits or require more machinery (test operation etc). >> Wouldn't it be simpler to make the patch format more precise? >> >> - Rob >> >> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley wrote: >>> I am usually lurking and struggling to keep up with these posts. But, I >>> concur with James, this really is a non-issue in practice. >>> >>> The JSON Pointer expresses a path down a JSON object to a specific cont= ext. >>> The Patch expresses a change within or to that context. >>> Everything about the both standards is about that end context. >>> >>> If you want to confirm the type of the context before applying a patch,= this >>> should probably be part of a test operation. I'm not sure if this is >>> possible at this point (?), but that is where the logic should exist. >>> >>> >>> >>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell wro= te: >>>> >>>> >>>> >>>> >>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre wrote= : >>>>> >>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler >>>>> wrote: >>>>>> >>>>>> Hmm.. I think that=92s quite problematic. Especially considering how= JSON >>>>>> Pointer is used in JSON Patch. >>>>> >>>>> I agree--I provided the same feedback privately. It seems >>>>> straightforwardly unsound. >>>>> >>>> >>>> In practice it doesn't seem to be much of an issue. >>>> >>>> Specifically, if I GET an existing document and get an etag with the J= SON, >>>> then make some changes and send a PATCH with If-Match, the fact that a= ny >>>> given pointer could point to an array or object member doesn't really = matter >>>> much. >>>> >>>> For example: >>>> >>>>> GET /the/doc HTTP/1.1 >>>> >>>> < HTTP/1.1 200 OK >>>> ETag: "my-document-tag" >>>> Content-Type: application/json >>>> >>>> {"1":"foo"} >>>> >>>>> PATCH /the/doc HTTP/1.1 >>>> If-Match: "my-document-etag" >>>> Content-Type: application/json-patch >>>> >>>> [{"op":"add","path":"/2","value":"bar"}] >>>> >>>> Generally speaking, someone should not be using PATCH to perform a par= tial >>>> modification if they don't already have some knowledge in advance what= they >>>> are modifying. The only time the apparent ambiguity becomes an issue i= s when >>>> a client is blindly sending a patch to an unknown endpoint... in which= case, >>>> you get whatever you end up with. >>>> >>>> - James >>>> >>>> >>>>> >>>>> - Rob >>>>> >>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Markus Lanthaler >>>>>> >>>>>> @markuslanthaler >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: James M Snell [mailto:jasnell@gmail.com] >>>>>> Sent: Friday, December 14, 2012 5:41 PM >>>>>> To: Markus Lanthaler >>>>>> Cc: IETF Discussion; IETF Apps Discuss >>>>>> Subject: Re: [apps-discuss] Last Call: >>>>>> (JSON Pointer) to Proposed = Standard >>>>>> >>>>>> >>>>>> >>>>>> JSON Pointer does not distinguish between objects and arrays. That i= s >>>>>> not determined until the pointer is applied to an actual object inst= ance... >>>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"] >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler >>>>>> wrote: >>>>>> >>>>>> I've asked that before but didn't get an answer. So let me ask again >>>>>> (even >>>>>> though I'm quite sure it has already been asked by somebody else). >>>>>> >>>>>> How does JSON Pointer distinguish between objects and arrays? E.g. >>>>>> consider >>>>>> the following JSON document: >>>>>> >>>>>> { >>>>>> "foo": "bar", >>>>>> "1": "baz" >>>>>> } >>>>>> >>>>>> As I read the draft, the JSON Pointer "/1" would evaluate to "baz" e= ven >>>>>> though that's probably not what the author intended. Is there a way = to >>>>>> avoid >>>>>> that? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Markus >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Markus Lanthaler >>>>>> @markuslanthaler >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >>>>>>> bounces@ietf.org] On Behalf Of The IESG >>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM >>>>>>> To: IETF-Announce >>>>>>> Cc: apps-discuss@ietf.org >>>>>>> Subject: [apps-discuss] Last Call: >>>>>> 07.txt> (JSON Pointer) to Proposed Standard >>>>>>> >>>>>>> >>>>>>> The IESG has received a request from the Applications Area Working >>>>>>> Group >>>>>>> WG (appsawg) to consider the following document: >>>>>>> - 'JSON Pointer' >>>>>>> as Proposed Standard >>>>>>> >>>>>>> The IESG plans to make a decision in the next few weeks, and solici= ts >>>>>>> final comments on this action. Please send substantive comments to >>>>>>> the >>>>>>> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments >>>>>>> may >>>>>>> be >>>>>>> sent to iesg@ietf.org instead. In either case, please retain the >>>>>>> beginning of the Subject line to allow automated sorting. >>>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> >>>>>>> JSON Pointer defines a string syntax for identifying a specific >>>>>>> value >>>>>>> within a JSON document. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The file can be obtained via >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ >>>>>>> >>>>>>> IESG discussion can be tracked via >>>>>>> >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/bal= lot/ >>>>>>> >>>>>>> >>>>>>> No IPR declarations have been submitted directly on this I-D. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> apps-discuss mailing list >>>>>>> apps-discuss@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>> >>>>>> _______________________________________________ >>>>>> apps-discuss mailing list >>>>>> apps-discuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> apps-discuss mailing list >>>>>> apps-discuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> >>> >>> >>> >>> -- >>> Matthew P. C. Morley >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > > From sayrer@gmail.com Mon Dec 17 06:19:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A09421F8AD9; Mon, 17 Dec 2012 06:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbVaHuy9jzbL; Mon, 17 Dec 2012 06:19:17 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61BEB21F8AD8; Mon, 17 Dec 2012 06:19:16 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2884052wey.31 for ; Mon, 17 Dec 2012 06:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bPRDAATgmUCEaJnH3bM6yXTOygKUIfD7uVvCVSvbUYY=; b=ulE0J5UDZOTZqqyJzvyLoKUBOEEBNw5qQVm1Ghb8mWbIJ+2bz/Hwwd/8Ji/Ibu5C2t y/gmcNuNq3trlb8OY+ezm7M4488MWRaqN16TdhWxF+z2nIGsCin/vEk1Fmqs2CWg/Ll+ 9rW2V+7yQca4BWYezyF6F/4N1ert66VnddtbqdQ4E11U1KqeZpWD6dpcYKvasMVSPZzD G9u4h+8/kPC6DB45OMXPa2ZMpxm+6safI7FdOzAR7ggCvCPQxXOpixCZgAdIXDta/Uz0 nAnT7BPLzWio6lmIiQ4TeLWTt+dBSD5G5YbJh4yNtLXXubq8LCPbpCAA0CPGNZOJGI5a QGUA== MIME-Version: 1.0 Received: by 10.194.78.162 with SMTP id c2mr17262915wjx.46.1355753955529; Mon, 17 Dec 2012 06:19:15 -0800 (PST) Received: by 10.194.1.101 with HTTP; Mon, 17 Dec 2012 06:19:15 -0800 (PST) In-Reply-To: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 17 Dec 2012 06:19:15 -0800 Message-ID: From: Robert Sayre To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Apps Discuss , IETF Discussion Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 14:19:17 -0000 On Mon, Dec 17, 2012 at 2:01 AM, Robert Sayre wrote: > > The first case that can come up is editing documents that have been > refactored. It's quite common to refactor JSON documents as below when > a little extra metadata is needed for a collection: > > { "foo":[1,2,3] } > > then becomes > > { > "foo": > "bar": "baz", > "members": [1,2,3] > } > Oh drat, I missed a pair of brackets here. I meant: { "foo": { "bar": "baz", "members": [1,2,3] } } - Rob From jasnell@gmail.com Mon Dec 17 07:09:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C26521F8B23; Mon, 17 Dec 2012 07:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djGYjwA-xpRU; Mon, 17 Dec 2012 07:09:04 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3964A21F8B04; Mon, 17 Dec 2012 07:09:04 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so9346596ieb.31 for ; Mon, 17 Dec 2012 07:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Vkfa6t16crRL0rBWNJEKgovvg1T+ozp7m9l07NFSjIU=; b=JWE9TCUqEUqt+FOJlMd7mdV7BS5j03Ed4gtfLTfcVGmeI53VZvcIRnYxskQo5CBK4x hd28HGV+ssUwtUn4S3/9ZEIyixUk8kozVPe9o6iM3q3J7a+6SS54xRumk6RdSyR/nU1a mqFzri88+HFxOnIsgCIclk+I0IC51CMjrmMpli6sssAaj5ZlFuDrreQEhx/H7MaS7hRl e8wN5o7b/dsfJqEIovqVEwEPFKzd+Pz3z+UDP/KykogMgvko6PTLRXJ+pW/YDZMntVSS Wy3ivZYlRFxGo/c7TshFXxV/11U9gKXN0rQ+4oGEZnEJU5YJZGoqw9i17mYZ3U3aZT0u VAPA== Received: by 10.50.45.166 with SMTP id o6mr9492703igm.0.1355756928025; Mon, 17 Dec 2012 07:08:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Mon, 17 Dec 2012 07:08:27 -0800 (PST) In-Reply-To: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> From: James M Snell Date: Mon, 17 Dec 2012 07:08:27 -0800 Message-ID: To: Robert Sayre Content-Type: multipart/alternative; boundary=14dae934035718c53f04d10dc217 Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 15:09:07 -0000 --14dae934035718c53f04d10dc217 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 17, 2012 at 2:01 AM, Robert Sayre wrote: > [snip] > > > > You might argue that someone who (for example) adds to "/foo/1" in the > mistaken belief that it's an array, when in fact it's an object, will get > surprising results. That's true, but if we were to solve this problem, th= at > person would still need to understand the underlying semantics of "foo" t= o > do anything useful to it -- and I'm not hearing anyone complain about tha= t > (I hope). > > The first case that can come up is editing documents that have been > refactored. It's quite common to refactor JSON documents as below when > a little extra metadata is needed for a collection: > > { "foo":[1,2,3] } > > then becomes > > { > "foo": > "bar": "baz", > "members": [1,2,3] > } > > now, an operation on /foo/1 is quite a different thing in the second > document. It's not too hard to see how a client that's been out of > contact with the server for a while could send an addition to /foo > intended for the array that's been moved down to "members". Now, there > are ways to catch this if you're willing to bloat the patch document > with other checks, or by insisting on a matching ETag. But one of the > nice things about patch formats is that you can try for more > optimistic concurrent editing. This ambiguity in the patch format > makes it needlessly more costly to detect unsound edits. > > Appreciate the concrete use case... while it has come up a few times, this is the first actual case that's been presented. If I understand the issue correctly, you're basically talking about a client making a blind partial update to an arbitrarily structured JSON document whose structure may have changed since the last time the client edited it... In such cases, I would argue that you get whatever you end up with. Everyone's idea of "bloat" is different. Adding etag checking is a simple, effective best practice for detecting concurrent document changes and is likely a really good idea in a scenario where we're making partial modifications to arbitrary documents. Adding in support for json-predicates adds a bit more (not a lot really but opinions vary.. in the ruby implementation it's only approximately 140 more lines of code, mostly formatting) but can make it rather more reliable... For instance, [ {"op": "type", "path": "/foo/1", "value": "array"}, {"op": "add", "path": "/foo/1", "value": 1} ] Again, the point is, I don't see this as a problem in practice. Implementers that make blind edits to arbitrary docs can expect surprising results sometimes. That's just the way it is. There are mechanisms defined (test, json-predicates and conditional requests) that can make the edit more reliable. > Another source of bugs from JavaScript side of things will be > "array-like" objects. These are really quite common (jQuery lists, > arguments object, etc), and authors very often don't realize they > won't be serialized as an array. To be sure, this is a bug on the > author's side, but some checks in the patch format would really help. > They'll probably become even more common as ES6 is standardizing > iterators http://wiki.ecmascript.org/doku.php?id=3Dharmony:iterators. > Here's an example in a JS REPL using the arguments object (but keep in > mind there are many other objects out there that behave this way). > > > function foo(list) { console.log(JSON.stringify(list)) } > > function bar(a,b,c) { foo(arguments) } > > bar("a", "b", "c"); > {"0":"a","1":"b","2":"c"} > > Definitely understand this case, but json-patch is defined in terms of the basic json model and not javascript. In other words... again.. the developer using the patch needs to be aware of the structure of the target resource. Json-predicate provides a good approach to dealing with that by allowing a developer to test the structure before attempting to edit. - James > > > Put another way -- do you really think > > Yes, really. > > > that people PATCHing something as if it's an array (when in fact it's a= n > object) is a significant, real-world problem, given that the patch author > already has to understand the semantics of the document they're patching? > > I don't see that requirement in the draft, and I certainly wouldn't > bet on it being true in all cases. Wasn't one of the motivating > use-cases for this patch format CouchDB? That software operates on > arbitrary, user-defined JSON documents. > > - Rob > > > I don't, and the WG didn't either. > > > > Regards, > > > > > > On 17/12/2012, at 3:36 PM, Robert Sayre wrote: > > > >> The cost of fixing it seems low, either by changing the path syntax of > >> JSON pointer or changing the names of operations applied to arrays. > >> Array-like objects are common enough in JavaScript to make this a > >> worry. The other suggestions either assume a particular policy for > >> concurrent edits or require more machinery (test operation etc). > >> Wouldn't it be simpler to make the patch format more precise? > >> > >> - Rob > >> > >> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley wrote: > >>> I am usually lurking and struggling to keep up with these posts. But,= I > >>> concur with James, this really is a non-issue in practice. > >>> > >>> The JSON Pointer expresses a path down a JSON object to a specific > context. > >>> The Patch expresses a change within or to that context. > >>> Everything about the both standards is about that end context. > >>> > >>> If you want to confirm the type of the context before applying a > patch, this > >>> should probably be part of a test operation. I'm not sure if this is > >>> possible at this point (?), but that is where the logic should exist. > >>> > >>> > >>> > >>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell > wrote: > >>>> > >>>> > >>>> > >>>> > >>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre > wrote: > >>>>> > >>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler > >>>>> wrote: > >>>>>> > >>>>>> Hmm.. I think that=E2=80=99s quite problematic. Especially conside= ring how > JSON > >>>>>> Pointer is used in JSON Patch. > >>>>> > >>>>> I agree--I provided the same feedback privately. It seems > >>>>> straightforwardly unsound. > >>>>> > >>>> > >>>> In practice it doesn't seem to be much of an issue. > >>>> > >>>> Specifically, if I GET an existing document and get an etag with the > JSON, > >>>> then make some changes and send a PATCH with If-Match, the fact that > any > >>>> given pointer could point to an array or object member doesn't reall= y > matter > >>>> much. > >>>> > >>>> For example: > >>>> > >>>>> GET /the/doc HTTP/1.1 > >>>> > >>>> < HTTP/1.1 200 OK > >>>> ETag: "my-document-tag" > >>>> Content-Type: application/json > >>>> > >>>> {"1":"foo"} > >>>> > >>>>> PATCH /the/doc HTTP/1.1 > >>>> If-Match: "my-document-etag" > >>>> Content-Type: application/json-patch > >>>> > >>>> [{"op":"add","path":"/2","value":"bar"}] > >>>> > >>>> Generally speaking, someone should not be using PATCH to perform a > partial > >>>> modification if they don't already have some knowledge in advance > what they > >>>> are modifying. The only time the apparent ambiguity becomes an issue > is when > >>>> a client is blindly sending a patch to an unknown endpoint... in > which case, > >>>> you get whatever you end up with. > >>>> > >>>> - James > >>>> > >>>> > >>>>> > >>>>> - Rob > >>>>> > >>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> Markus Lanthaler > >>>>>> > >>>>>> @markuslanthaler > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> From: James M Snell [mailto:jasnell@gmail.com] > >>>>>> Sent: Friday, December 14, 2012 5:41 PM > >>>>>> To: Markus Lanthaler > >>>>>> Cc: IETF Discussion; IETF Apps Discuss > >>>>>> Subject: Re: [apps-discuss] Last Call: > >>>>>> (JSON Pointer) to Propose= d > Standard > >>>>>> > >>>>>> > >>>>>> > >>>>>> JSON Pointer does not distinguish between objects and arrays. That > is > >>>>>> not determined until the pointer is applied to an actual object > instance... > >>>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"] > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler > >>>>>> wrote: > >>>>>> > >>>>>> I've asked that before but didn't get an answer. So let me ask aga= in > >>>>>> (even > >>>>>> though I'm quite sure it has already been asked by somebody else). > >>>>>> > >>>>>> How does JSON Pointer distinguish between objects and arrays? E.g. > >>>>>> consider > >>>>>> the following JSON document: > >>>>>> > >>>>>> { > >>>>>> "foo": "bar", > >>>>>> "1": "baz" > >>>>>> } > >>>>>> > >>>>>> As I read the draft, the JSON Pointer "/1" would evaluate to "baz" > even > >>>>>> though that's probably not what the author intended. Is there a wa= y > to > >>>>>> avoid > >>>>>> that? > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Markus > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Markus Lanthaler > >>>>>> @markuslanthaler > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > >>>>>>> bounces@ietf.org] On Behalf Of The IESG > >>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM > >>>>>>> To: IETF-Announce > >>>>>>> Cc: apps-discuss@ietf.org > >>>>>>> Subject: [apps-discuss] Last Call: > >>>>>>> 07.txt> (JSON Pointer) to Proposed Standard > >>>>>>> > >>>>>>> > >>>>>>> The IESG has received a request from the Applications Area Workin= g > >>>>>>> Group > >>>>>>> WG (appsawg) to consider the following document: > >>>>>>> - 'JSON Pointer' > >>>>>>> as Proposed Standard > >>>>>>> > >>>>>>> The IESG plans to make a decision in the next few weeks, and > solicits > >>>>>>> final comments on this action. Please send substantive comments t= o > >>>>>>> the > >>>>>>> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comment= s > >>>>>>> may > >>>>>>> be > >>>>>>> sent to iesg@ietf.org instead. In either case, please retain the > >>>>>>> beginning of the Subject line to allow automated sorting. > >>>>>>> > >>>>>>> Abstract > >>>>>>> > >>>>>>> > >>>>>>> JSON Pointer defines a string syntax for identifying a specific > >>>>>>> value > >>>>>>> within a JSON document. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The file can be obtained via > >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ > >>>>>>> > >>>>>>> IESG discussion can be tracked via > >>>>>>> > >>>>>>> > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ > >>>>>>> > >>>>>>> > >>>>>>> No IPR declarations have been submitted directly on this I-D. > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> apps-discuss mailing list > >>>>>>> apps-discuss@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>>>>> > >>>>>> _______________________________________________ > >>>>>> apps-discuss mailing list > >>>>>> apps-discuss@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> apps-discuss mailing list > >>>>>> apps-discuss@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>>>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> apps-discuss mailing list > >>>> apps-discuss@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>>> > >>> > >>> > >>> > >>> -- > >>> Matthew P. C. Morley > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --14dae934035718c53f04d10dc217 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Mon, Dec 17, 2012 at 2:01 AM, Robert = Sayre <sayrer@gmail.com> wrote:
[snip]
>
> You might argue that someone who (for example) adds to "/foo/1&qu= ot; in the mistaken belief that it's an array, when in fact it's an= object, will get surprising results. That's true, but if we were to so= lve this problem, that person would still need to understand the underlying= semantics of "foo" to do anything useful to it -- and I'm no= t hearing anyone complain about that (I hope).

The first case that can come up is editing documents that have been refactored. It's quite common to refactor JSON documents as below when<= br> a little extra metadata is needed for a collection:

{ "foo":[1,2,3] }

then becomes

{
=C2=A0 "foo":
=C2=A0 "bar": "baz",
=C2=A0 "members": [1,2,3]
}

now, an operation on /foo/1 is quite a different thing in the second
document. It's not too hard to see how a client that's been out of<= br> contact with the server for a while could send an addition to /foo
intended for the array that's been moved down to "members". N= ow, there
are ways to catch this if you're willing to bloat the patch document with other checks, or by insisting on a matching ETag. But one of the
nice things about patch formats is that you can try for more
optimistic concurrent editing. This ambiguity in the patch format
makes it needlessly more costly to detect unsound edits.


Appreciate the concrete use case... wh= ile it has come up a few times, this is the first actual case that's be= en presented. If I understand the issue correctly, you're basically tal= king about a client making a blind partial update to an arbitrarily structu= red JSON document whose structure may have changed since the last time the = client edited it... =C2=A0In such cases, I would argue that you get whateve= r you end up with.=C2=A0

Everyone's idea of "bloat" is different. = Adding etag checking is a simple, effective best practice for detecting con= current document changes and is likely a really good idea in a scenario whe= re we're making partial modifications to arbitrary documents. Adding in= support for json-predicates adds a bit more (not a lot really but opinions= vary.. in the ruby implementation it's only approximately 140 more lin= es of code, mostly formatting) but can make it rather more reliable... For = instance,

=C2=A0 [
=C2=A0 =C2=A0 {"op": "= ;type", "path": "/foo/1", "value": "= ;array"},
=C2=A0 =C2=A0 {"op": "add", &q= uot;path": "/foo/1", "value": 1}
=C2=A0 ]

Again, the point is, I don't see= this as a problem in practice. Implementers that make blind edits to arbit= rary docs can expect surprising results sometimes. That's just the way = it is. There are mechanisms defined (test, json-predicates and conditional = requests) that can make the edit more reliable.
=C2=A0
Another source of bugs from JavaScript side of things will be
"array-like" objects. These are really quite common (jQuery lists= ,
arguments object, etc), and authors very often don't realize they
won't be serialized as an array. To be sure, this is a bug on the
author's side, but some checks in the patch format would really help. They'll probably become even more common as ES6 is standardizing
iterators http://wiki.ecmascript.org/doku.php?id=3Dharmony:it= erators.
Here's an example in a JS REPL using the arguments object (but keep in<= br> mind there are many other objects out there that behave this way).

> function foo(list) { console.log(JSON.stringify(list)) }
> function bar(a,b,c) { foo(arguments) }
> bar("a", "b", "c");
{"0":"a","1":"b","2":&quo= t;c"}


Definitely und= erstand this case, but json-patch is defined in terms of the basic json mod= el and not javascript. In other words... again.. the developer using the pa= tch needs to be aware of the structure of the target resource. Json-predica= te provides a good approach to dealing with that by allowing a developer to= test the structure before attempting to edit.=C2=A0
=C2=A0
- James

>
> Put another way -- do you really think

Yes, really.

> that people PATCHing something as if it's an array (when in fact i= t's an object) is a significant, real-world problem, given that the pat= ch author already has to understand the semantics of the document they'= re patching?

I don't see that requirement in the draft, and I certainly wouldn= 't
bet on it being true in all cases. Wasn't one of the motivating
use-cases for this patch format CouchDB? That software operates on
arbitrary, user-defined JSON documents.

- Rob

> I don't, and the WG didn't either.
>
> Regards,
>
>
> On 17/12/2012, at 3:36 PM, Robert Sayre <sayrer@gmail.com> wrote:
>
>> The cost of fixing it seems low, either by changing the path synta= x of
>> JSON pointer or changing the names of operations applied to arrays= .
>> Array-like objects are common enough in JavaScript to make this a<= br> >> worry. The other suggestions either assume a particular policy for=
>> concurrent edits or require more machinery (test operation etc). >> Wouldn't it be simpler to make the patch format more precise?<= br> >>
>> - Rob
>>
>> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley <matt@mpcm.com> wrote:
>>> I am usually lurking and struggling to keep up with these post= s. But, I
>>> concur with James, this really is a non-issue in practice.
>>>
>>> The JSON Pointer expresses a path down a JSON object to a spec= ific context.
>>> The Patch expresses a change within or to that context.
>>> Everything about the both standards is about that end context.=
>>>
>>> If you want to confirm the type of the context before applying= a patch, this
>>> should probably be part of a test operation. I'm not sure = if this is
>>> possible at this point (?), but that is where the logic should= exist.
>>>
>>>
>>>
>>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell <jasnell@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre <sayrer@gmail.com> wrote:
>>>>>
>>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
>>>>> <markus= .lanthaler@gmx.net> wrote:
>>>>>>
>>>>>> Hmm.. I think that=E2=80=99s quite problematic. Es= pecially considering how JSON
>>>>>> Pointer is used in JSON Patch.
>>>>>
>>>>> I agree--I provided the same feedback privately. It se= ems
>>>>> straightforwardly unsound.
>>>>>
>>>>
>>>> In practice it doesn't seem to be much of an issue. >>>>
>>>> Specifically, if I GET an existing document and get an eta= g with the JSON,
>>>> then make some changes and send a PATCH with If-Match, the= fact that any
>>>> given pointer could point to an array or object member doe= sn't really matter
>>>> much.
>>>>
>>>> For example:
>>>>
>>>>> GET /the/doc HTTP/1.1
>>>>
>>>> =C2=A0< =C2=A0HTTP/1.1 200 OK
>>>> =C2=A0 =C2=A0 ETag: "my-document-tag"
>>>> =C2=A0 =C2=A0 Content-Type: application/json
>>>>
>>>> =C2=A0 =C2=A0 {"1":"foo"}
>>>>
>>>>> PATCH /the/doc HTTP/1.1
>>>> =C2=A0 =C2=A0 If-Match: "my-document-etag"
>>>> =C2=A0 =C2=A0 Content-Type: application/json-patch
>>>>
>>>> =C2=A0 =C2=A0 [{"op":"add","path&= quot;:"/2","value":"bar"}]
>>>>
>>>> Generally speaking, someone should not be using PATCH to p= erform a partial
>>>> modification if they don't already have some knowledge= in advance what they
>>>> are modifying. The only time the apparent ambiguity become= s an issue is when
>>>> a client is blindly sending a patch to an unknown endpoint= ... in which case,
>>>> you get whatever you end up with.
>>>>
>>>> - James
>>>>
>>>>
>>>>>
>>>>> - Rob
>>>>>
>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Markus Lanthaler
>>>>>>
>>>>>> @markuslanthaler
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: James M Snell [mailto:jasnell@gmail.com]
>>>>>> Sent: Friday, December 14, 2012 5:41 PM
>>>>>> To: Markus Lanthaler
>>>>>> Cc: IETF Discussion; IETF Apps Discuss
>>>>>> Subject: Re: [apps-discuss] Last Call:
>>>>>> <draft-ietf-appsawg-json-pointer-07.txt> (JS= ON Pointer) to Proposed Standard
>>>>>>
>>>>>>
>>>>>>
>>>>>> JSON Pointer does not distinguish between objects = and arrays. That is
>>>>>> not determined until the pointer is applied to an = actual object instance...
>>>>>> the pointer "/1" is valid against {"= ;1":"a"} or ["a","b"]
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler<= br> >>>>>> <ma= rkus.lanthaler@gmx.net> wrote:
>>>>>>
>>>>>> I've asked that before but didn't get an a= nswer. So let me ask again
>>>>>> (even
>>>>>> though I'm quite sure it has already been aske= d by somebody else).
>>>>>>
>>>>>> How does JSON Pointer distinguish between objects = and arrays? E.g.
>>>>>> consider
>>>>>> the following JSON document:
>>>>>>
>>>>>> {
>>>>>> =C2=A0"foo": "bar",
>>>>>> =C2=A0"1": "baz"
>>>>>> }
>>>>>>
>>>>>> As I read the draft, the JSON Pointer "/1&quo= t; would evaluate to "baz" even
>>>>>> though that's probably not what the author int= ended. Is there a way to
>>>>>> avoid
>>>>>> that?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Markus
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Markus Lanthaler
>>>>>> @markuslanthaler
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>>>>>> bounces@ie= tf.org] On Behalf Of The IESG
>>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM
>>>>>>> To: IETF-Announce
>>>>>>> Cc: a= pps-discuss@ietf.org
>>>>>>> Subject: [apps-discuss] Last Call: <draft-i= etf-appsawg-json-pointer-
>>>>>>> 07.txt> (JSON Pointer) to Proposed Standard=
>>>>>>>
>>>>>>>
>>>>>>> The IESG has received a request from the Appli= cations Area Working
>>>>>>> Group
>>>>>>> WG (appsawg) to consider the following documen= t:
>>>>>>> - 'JSON Pointer'
>>>>>>> =C2=A0<draft-ietf-appsawg-json-pointer-07.t= xt> as Proposed Standard
>>>>>>>
>>>>>>> The IESG plans to make a decision in the next = few weeks, and solicits
>>>>>>> final comments on this action. Please send sub= stantive comments to
>>>>>>> the
>>>>>>> ietf@ietf.org= mailing lists by 2012-12-25. Exceptionally, comments
>>>>>>> may
>>>>>>> be
>>>>>>> sent to iesg@= ietf.org instead. In either case, please retain the
>>>>>>> beginning of the Subject line to allow automat= ed sorting.
>>>>>>>
>>>>>>> Abstract
>>>>>>>
>>>>>>>
>>>>>>> =C2=A0 JSON Pointer defines a string syntax fo= r identifying a specific
>>>>>>> value
>>>>>>> =C2=A0 within a JSON document.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The file can be obtained via
>>>>>>> http://datatracker.ietf.or= g/doc/draft-ietf-appsawg-json-pointer/
>>>>>>>
>>>>>>> IESG discussion can be tracked via
>>>>>>>
>>>>>>> http://datatracker.= ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/
>>>>>>>
>>>>>>>
>>>>>>> No IPR declarations have been submitted direct= ly on this I-D.
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> apps-discuss mailing list
>>>>>>> apps-= discuss@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ap= ps-discuss
>>>>>>
>>>>>> _______________________________________________ >>>>>> apps-discuss mailing list
>>>>>> apps-disc= uss@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/apps-d= iscuss
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ >>>>>> apps-discuss mailing list
>>>>>> apps-disc= uss@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/apps-d= iscuss
>>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>>> apps-discuss@ietf= .org
>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>
>>>
>>>
>>>
>>> --
>>> Matthew P. C. Morley
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org=
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> --
> Mark Nottingham =C2=A0 http://www.mnot.net/
>
>
>
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--14dae934035718c53f04d10dc217-- From dret@berkeley.edu Mon Dec 17 15:23:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709A811E8099 for ; Mon, 17 Dec 2012 15:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMwYOj075NOt for ; Mon, 17 Dec 2012 15:23:02 -0800 (PST) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 699671F0CB2 for ; Mon, 17 Dec 2012 15:22:30 -0800 (PST) Received: from mobile-166-137-219-208.mycingular.net ([166.137.219.208] helo=dretpro.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Tkk0x-0003ab-L3; Mon, 17 Dec 2012 15:22:28 -0800 Message-ID: <50CFA92F.7080306@berkeley.edu> Date: Mon, 17 Dec 2012 15:22:23 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Conal Tuohy References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> In-Reply-To: <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 23:23:07 -0000 hello conal. On 2012-12-16 21:34 , Mark Nottingham wrote: > On 17/12/2012, at 3:27 PM, Conal Tuohy wrote: >> Can I suggest that the XML format known as the media type "application/api-problem+xml" should use an XML namespace? > You can certainly suggest it :) and that's what i came up with as my first proposed design ;-) but then we moved away from that, and so far it's the first cut at defining an XML format, and things are open for discussion. so thanks for your comments! > Yes, I'm familiar with the WebArch document. In practice, XML Namespaces can cause a lot of developer confusion, and I'd put forth that they should only be used where distributed extensibility is necessary, and there are no other ways to achieve it. i tend to believe that developers are not quite as bad as grappling with them as sometimes is assumed, but they certainly still are something that many people not very familiar with XML are confused about. i like them because they make XML documents truly self-describing, and the extensibility is a nice side-effect. > Here, because the definition of the problem type (and thereby, its extensions) is controlled by the person that mints it (using a describedBy link), there isn't a need for distributed extensibility, as far as I can see. Furthermore, using XML namespaces would force the use of a similar mechanism with JSON, which would make me (and many others, I think) unhappy. and that was the main poin in mark's argument for me. in XML, you get namespaces for free, and while some people dislike them, they are just part of the established tech landscape. if you want to represent things across XML and JSON, then mapping XML-enabled XML to JSON just becomes fairly painful, because of JSON's simplicity. since the intention is to keep XML and JSON aligned, and use JSON as the canonical format, adding namespaces to the XML variant makes things surprisingly complicated. >> It seems to me that the relationship between the names of JSON objects and corresponding XML elements also needs clarification. >> For instance, the XML schema allows those objects to be in "##any" namespace, but how would those namespaces relate to JSON expressions of the same error report? If a JSON problem report were to be transformed into XML, what XML namespaces would actually be used for any extension members? Conversely, if an XML-formatted problem report were converted to JSON, how would any XML namespaces be rendered in the JSON? > I'm CC:ing Erik because he helped me add the XML format (which I was somewhat reluctant to do). > No namespaces would be used, as I understand it. Erik, does the schema need revision? good catch, that was probably something from earlier namespace-aware exercises. https://github.com/dret/I-D-1/blob/master/http-problem/http-problem-03.xsd is the updated "##targetNamespace" version, allowing only non-namespace XML (and thus easy mapping to and from JSON, as long as the JSON labels do not validate XML's naming rules, of course...). is still has issues because of XSD's UPA constraint, but for now i'll leave that as an exercise for further refinement... @mark, should we add a constraint to the JSON definition that for the only XML NCNames SHOULD be used (it currently says "names SHOULD conform to token [RFC2616]"), or something along these lines? cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From mnot@mnot.net Mon Dec 17 16:39:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A0121E8040 for ; Mon, 17 Dec 2012 16:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.711 X-Spam-Level: X-Spam-Status: No, score=-103.711 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuDy07tCGj-9 for ; Mon, 17 Dec 2012 16:39:50 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 04EDB21E802E for ; Mon, 17 Dec 2012 16:39:50 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.33.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4008D509B5; Mon, 17 Dec 2012 19:39:47 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <50CFA92F.7080306@berkeley.edu> Date: Tue, 18 Dec 2012 11:39:45 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50CFA92F.7080306@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 00:39:54 -0000 On 18/12/2012, at 10:22 AM, Erik Wilde wrote: >=20 > @mark, should we add a constraint to the JSON definition that for the = only XML NCNames SHOULD be used (it currently says "names SHOULD conform = to token [RFC2616]"), or something along these lines? I chose token to make it compatible with other serialisations as well = (e.g., in a HTTP Header); XML isn't the only (other) game in town. Cheers, -- Mark Nottingham http://www.mnot.net/ From dret@berkeley.edu Mon Dec 17 16:45:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED0E21F869A for ; Mon, 17 Dec 2012 16:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYgpj0xOb352 for ; Mon, 17 Dec 2012 16:45:02 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCBE21F8653 for ; Mon, 17 Dec 2012 16:44:50 -0800 (PST) Received: from mobile-166-137-219-208.mycingular.net ([166.137.219.208] helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TklIa-0003Zh-AB; Mon, 17 Dec 2012 16:44:44 -0800 Message-ID: <50CFBC75.7090909@berkeley.edu> Date: Mon, 17 Dec 2012 16:44:37 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mark Nottingham References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50CFA92F.7080306@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 00:45:03 -0000 On 2012-12-17 16:39 , Mark Nottingham wrote: > On 18/12/2012, at 10:22 AM, Erik Wilde wrote: >> @mark, should we add a constraint to the JSON definition that for the only XML NCNames SHOULD be used (it currently says "names SHOULD conform to token [RFC2616]"), or something along these lines? > I chose token to make it compatible with other serialisations as well (e.g., in a HTTP Header); XML isn't the only (other) game in town. sure. but for those serializations we know of, maybe being friendly to them is a good idea. token is more permissible than NCName and thus allows things that don't work too well in XML-land. maybe choose the intersection of all of the ones we know of? cheers, dret. From sayrer@gmail.com Mon Dec 17 19:41:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E15721E8041; Mon, 17 Dec 2012 19:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnL9vw0-n0JY; Mon, 17 Dec 2012 19:41:04 -0800 (PST) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id EE31821E8039; Mon, 17 Dec 2012 19:41:03 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id z2so52964wey.18 for ; Mon, 17 Dec 2012 19:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EGBKZGwymRgwmz1g5mmLkfZC6sPY+Bv7gBwz0ttxzis=; b=a4QThT785SUeJgyQq8yCu3l87w7yos6AajJojo2rSJaCVqUsDjBIPFRZPUmqtxHtee ozKTxZgPT3YuZQ61CDU9WGk1kLNFvzx5BH0s8RNvhBsHyp8/riuJLQFP+xjyPOT1GyD7 0sQ3QLc4Dud+DiXsRxCHinCUicsJGOv/wNkoKfKnPd8G4vKAyZp3reLRSwoZHbp6Hj/i FyzO5fwQAD6s5M6jkdbuu6W82Z8f5m2isVWD9ymcocr/LiDzUrrBlPk4Z61Z5JJqABSz Tj+NMmwQDDq9SA+BL0AaCybdm8leEv8k0xTEEz/gY5PmitJONpTRMFQA2XEExuPwbf4P r3lA== MIME-Version: 1.0 Received: by 10.194.76.99 with SMTP id j3mr971835wjw.47.1355802062898; Mon, 17 Dec 2012 19:41:02 -0800 (PST) Received: by 10.194.1.101 with HTTP; Mon, 17 Dec 2012 19:41:02 -0800 (PST) In-Reply-To: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 17 Dec 2012 19:41:02 -0800 Message-ID: From: Robert Sayre To: James M Snell Content-Type: text/plain; charset=ISO-8859-1 Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 03:41:05 -0000 On Mon, Dec 17, 2012 at 7:08 AM, James M Snell wrote: > > Everyone's idea of "bloat" is different. What I meant was that the predicate additions increase the size of the protocol messages. Your example is twice as large. The check could be more efficiently represented in the path notation or the operation names. > Again, the point is, I don't see this as a problem in practice. Implementers > that make blind edits to arbitrary docs can expect surprising results > sometimes. That's just the way it is. There are mechanisms defined (test, > json-predicates and conditional requests) that can make the edit more > reliable. Well, one way of putting it would be that the patch format makes it difficult to ensure convergence at quiescence in OT software when there's a change in type from array to object or vice-versa: There's no good reason for it to be that way, is there? - Rob From jasnell@gmail.com Mon Dec 17 19:54:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355BE21E804D; Mon, 17 Dec 2012 19:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB2A18v+QnkY; Mon, 17 Dec 2012 19:54:09 -0800 (PST) Received: from mail-ia0-f173.google.com (mail-ia0-f173.google.com [209.85.210.173]) by ietfa.amsl.com (Postfix) with ESMTP id 50CA421E804C; Mon, 17 Dec 2012 19:54:09 -0800 (PST) Received: by mail-ia0-f173.google.com with SMTP id w21so135259iac.32 for ; Mon, 17 Dec 2012 19:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xMnwV/UIS1JmPTGMpOCMLF7XzACv6147MLk94/lgUJA=; b=gNIWuRmxbqtkkrQqVSWgRFZgLGDvBLI5JjsfMP6gd7oBDrhZlZV4WmxLiYj29N3Xnt zWJbs/gJm9szzBkN4IXBYcENpRVLieziGbNqQcg0oy/vjW3s/eKBkP1PY8g1lBHkiZI9 x09WMF0WkPYoIrBKmRn8ojlQjCvDk5JBjNPlnxDEyjlEkHCUtmcooxi8ATY3nu/ae+41 QPI30wZvTQVwdd+kEoaRkHKgaGHKxP3Zl+g/77wUAJyyyNIhNWpJYgPuOhDQs7MC+4A8 Av0U7E5uMFPEjHwH4exm5RbqX7/pw3/MzO3/lK9QHSi2uUUacHJLRPGn61JmSzImbCpC QdVg== Received: by 10.50.6.169 with SMTP id c9mr731126iga.24.1355802848780; Mon, 17 Dec 2012 19:54:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Mon, 17 Dec 2012 19:53:48 -0800 (PST) In-Reply-To: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> From: James M Snell Date: Mon, 17 Dec 2012 19:53:48 -0800 Message-ID: To: Robert Sayre Content-Type: multipart/alternative; boundary=e89a8f6467172fe21404d1187383 Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 03:54:10 -0000 --e89a8f6467172fe21404d1187383 Content-Type: text/plain; charset=UTF-8 The key advantage to the current syntax is that it's just absolutely drop dead simple. I get what you're saying but I'd rather avoid increasing the complexity of the syntax any more than we absolutely have to. And, to be absolutely honest, I haven't yet seen an actual application case where it's been an issue (that's not to say they don't exist, just haven't seen it in practice yet). What's your suggestion for making the syntax better? On Mon, Dec 17, 2012 at 7:41 PM, Robert Sayre wrote: > On Mon, Dec 17, 2012 at 7:08 AM, James M Snell wrote: > > > > Everyone's idea of "bloat" is different. > > What I meant was that the predicate additions increase the size of the > protocol messages. Your example is twice as large. The check could be > more efficiently represented in the path notation or the operation > names. > > > Again, the point is, I don't see this as a problem in practice. > Implementers > > that make blind edits to arbitrary docs can expect surprising results > > sometimes. That's just the way it is. There are mechanisms defined (test, > > json-predicates and conditional requests) that can make the edit more > > reliable. > > Well, one way of putting it would be that the patch format makes it > difficult to ensure convergence at quiescence in OT software when > there's a change in type from array to object or vice-versa: > > > > There's no good reason for it to be that way, is there? > > - Rob > --e89a8f6467172fe21404d1187383 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The key advantage to the current syntax is that it's j= ust absolutely drop dead simple. I get what you're saying but I'd r= ather avoid increasing the complexity of the syntax any more than we absolu= tely have to. And, to be absolutely honest, I haven't yet seen an actua= l application case where it's been an issue (that's not to say they= don't exist, just haven't seen it in practice yet). What's you= r suggestion for making the syntax better?

On Mon, Dec 17, 2012 at 7:41 PM, Robert Sayr= e <sayrer@gmail.com> wrote:
On Mon, Dec 17, 2012 at 7:08 AM, James M Snell <jasnell@gmail.com> wrote:
>
> Everyone's idea of "bloat" is different.

What I meant was that the predicate additions increase the size of th= e
protocol messages. Your example is twice as large. The check could be
more efficiently represented in the path notation or the operation
names.

> Again, the point is, I don't see this as a problem in practice. Im= plementers
> that make blind edits to arbitrary docs can expect surprising results<= br> > sometimes. That's just the way it is. There are mechanisms defined= (test,
> json-predicates and conditional requests) that can make the edit more<= br> > reliable.

Well, one way of putting it would be that the patch format makes it difficult to ensure convergence at quiescence in OT software when
there's a change in type from array to object or vice-versa:

<http://en.wikipedia.org/wiki/Operational_transf= ormation#The_CC_model>

There's no good reason for it to be that way, is there?

- Rob

--e89a8f6467172fe21404d1187383-- From James.H.Manger@team.telstra.com Mon Dec 17 21:12:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6E1F0CE4; Mon, 17 Dec 2012 21:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD0GaIU49X0C; Mon, 17 Dec 2012 21:12:55 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id A8D2A1F0CE3; Mon, 17 Dec 2012 21:12:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,307,1355058000"; d="scan'208";a="106798582" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 18 Dec 2012 16:12:50 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6929"; a="52493278" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcani.tcif.telstra.com.au with ESMTP; 18 Dec 2012 16:12:51 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Tue, 18 Dec 2012 16:12:51 +1100 From: "Manger, James H" To: Robert Sayre , James M Snell Date: Tue, 18 Dec 2012 16:12:49 +1100 Thread-Topic: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard Thread-Index: Ac3c0aLlBYpU3oEaTmCM88zjVoe+NwAAM0Nw Message-ID: <255B9BB34FB7D647A506DC292726F6E1150408948F@WSMSG3153V.srv.dir.telstra.com> References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 05:12:55 -0000 SWYgd2Ugd2VyZSBzdGFydGluZyBmcm9tIHNjcmF0Y2ggYW5kIGRlZmluaW5nIEpTT04gUG9pbnRl ciBhZ2FpbiBJIHdvdWxkIGFyZ3VlIGZvciBkaXN0aW5ndWlzaGluZyBhcnJheSBpbmRpY2VzIGFu ZCBvYmplY3QgbmFtZXMgaW4gdGhlIHN5bnRheC4gRm9yIGluc3RhbmNlLCBwcmVmaXggYW4gb2Jq ZWN0IG5hbWUgd2l0aCAiLyIgYW5kIGFuIGFycmF5IGluZGV4IHdpdGggIjoiLg0KDQogICBqc29u LXBvaW50ZXIgPSAqc2VnbWVudA0KICAgc2VnbWVudCA9ICIvIiBuYW1lICAvICAiOiIgaW5kZXgN CiAgIG5hbWUgPSAqKCB1bmVzY2FwZWQgLyBlc2NhcGVkICkNCiAgIHVuZXNjYXBlZCA9ICV4MDAt MkUgLyAleDMwLTM5IC8gJXgzQi03RCAvICV4N0YtMTBGRkZGDQogICBlc2NhcGVkID0gIn4iICgg IjAiIC8gIjEiIC8gIjIiICkNCiAgIGluZGV4ID0gIjAiIC8gJXgzMS0zOSAqKCV4MzAtMzkpIC8g Ii0iDQoNCjEuIEl0IG1ha2VzIHBhcnNpbmcgbWFyZ2luYWxseSBoYXJkZXI6IHlvdSBjYW5ub3Qg anVzdCBzcGxpdCBvbiAiLyIgYW5kIHVuZXNjYXBlIGVhY2ggc2VnbWVudC4NCjIuIEl0IGRvZXNu J3QgbWFrZSBtdWNoIGRpZmZlcmVuY2UgZm9yIHNlbGVjdGluZyBhIHZhbHVlIGZyb20gc29tZSBK U09OLCBvciBmb3IgZmluZGluZyBhIHNwb3QgdG8gaW5zZXJ0IGEgbmV3IHZhbHVlLg0KMy4gSXQg d291bGQgYWxsb3cgeW91IHRvIGF1dG9tYXRpY2FsbHkgY3JlYXRlIG9iamVjdCAqb3IgYXJyYXkq IGFuY2VzdG9ycyB3aGVuIHNldHRpbmcgYSBuZXcgdmFsdWUgKGVnIGFkZGluZyAyMyBhdCAvYTow L2I6MCB0byB7fSBjb3VsZCBnaXZlIHsiYSI6W3siYiI6WzIzXX1dfSkuDQo0LiBJdCBtaWdodCBl bmNvdXJhZ2UgYmV0dGVyIHZhbGlkYXRpb24gb2YgcG9pbnRlcnMsIGJ1dCB0aGF0IGlzIHByb2Jh Ymx5IHdpc2hmdWwgdGhpbmtpbmcuDQoNCkJ1dCBKU09OIFBvaW50ZXIgZHJhZnRzIGhhdmUgdXNl ZCB0aGUgL3tuYW1lfGluZGV4fSBmb3JtYXQgZm9yIGEgeWVhci4gVGhlcmUgYXJlIGEgYnVuY2gg b2YgaW1wbGVtZW50YXRpb25zLiBUaGUgZGlmZmVyZW5jZSBpcyBtaW5vciBpbiBtb3N0IGNpcmN1 bXN0YW5jZXMuIFNvIHdoaWxlIEkgd291bGQgYmUgaGFwcHkgdG8gY2hhbmdlLCBJIGFtIGFsc28g Y29tZm9ydGFibGUgc3RheWluZyB3aXRoIHRoZSBjdXJyZW50IHBvaW50ZXIgc3ludGF4Lg0KDQoN Cj4gVGhlcmUncyBubyBnb29kIHJlYXNvbiBmb3IgaXQgdG8gYmUgdGhhdCB3YXksIGlzIHRoZXJl Pw0KDQpJIGRvbid0IHRoaW5rIHNvLg0KIA0KLS0NCkphbWVzIE1hbmdlcg0K From jasnell@gmail.com Mon Dec 17 21:25:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1339321F8573; Mon, 17 Dec 2012 21:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4su-CWVsEASZ; Mon, 17 Dec 2012 21:25:10 -0800 (PST) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3094121F8563; Mon, 17 Dec 2012 21:25:09 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id s32so186365iak.12 for ; Mon, 17 Dec 2012 21:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KuWfD+hl74ZdxJEk5LpuYCQ7BwOSl2EI+wuDq5WKqaI=; b=QeaiDSd+pNo65tao6tByZ5QEMDm5QIq5aRYQyF43d8nolclR106ysCzi3lFsLjNXG3 sHIOtNihujKltZMZ+57hXP+7mY3x48G7a2HHp9gPPBjEriEoNcsOINEkr019jR1m2/gp I1G1E+2QmCjn3J52cDkZ4hXcR9xlGws4rKDtxQ1NRYUd8vig30Uvl9I8w0fqRBwVRsBF YYcV813S6+O0xHBEJDrNyx7PI3P/un8sqdB9gB6Ow2a41XiifcnxE7tC+oFJhXg4DluZ oAjOtwaz+IJ+DkHud+VehePrBbOjGvgPfG1/oM0YIqGl3gDaFGls8MExrU3Hq0fcoeH0 Cpdw== Received: by 10.50.178.106 with SMTP id cx10mr1306380igc.24.1355808308974; Mon, 17 Dec 2012 21:25:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Mon, 17 Dec 2012 21:24:48 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150408948F@WSMSG3153V.srv.dir.telstra.com> References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> <255B9BB34FB7D647A506DC292726F6E1150408948F@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Mon, 17 Dec 2012 21:24:48 -0800 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=e89a8f5036c8a3d5f404d119b87a Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 05:25:11 -0000 --e89a8f5036c8a3d5f404d119b87a Content-Type: text/plain; charset=UTF-8 What I'm not clear on, however, is what significant benefit making this kind of change would provide. Yes, the syntax can be more verbose and exact but it's not clear that the change is worth the cost. Robert mentioned that the addition of the json-predicates test doubled the size of the json-patch file, and yes, I get that.. but if we're talking about sending a two-object json-patch document to modify a JSON document many times larger than that, it's still worth the extra handful of bytes it takes. Sure, if we had a complex patch document consisting of large amounts of json-patch and json-predicate objects being applied to an arbitrarily structured document, I could understand the concern, but in that case one would have to question the wisdom of doing a partial update in the first place. JSON-Patch documents are best served small and simple, and the inclusion of a json-predicate or two per instance is not going to blow the budget on bits on the wire. So the key question becomes: what added benefit does a more verbose pointer syntax provide us? And is there a concrete need for that benefit that can be demonstrated? - James On Mon, Dec 17, 2012 at 9:12 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > If we were starting from scratch and defining JSON Pointer again I would > argue for distinguishing array indices and object names in the syntax. For > instance, prefix an object name with "/" and an array index with ":". > > json-pointer = *segment > segment = "/" name / ":" index > name = *( unescaped / escaped ) > unescaped = %x00-2E / %x30-39 / %x3B-7D / %x7F-10FFFF > escaped = "~" ( "0" / "1" / "2" ) > index = "0" / %x31-39 *(%x30-39) / "-" > > 1. It makes parsing marginally harder: you cannot just split on "/" and > unescape each segment. > 2. It doesn't make much difference for selecting a value from some JSON, > or for finding a spot to insert a new value. > 3. It would allow you to automatically create object *or array* ancestors > when setting a new value (eg adding 23 at /a:0/b:0 to {} could give > {"a":[{"b":[23]}]}). > 4. It might encourage better validation of pointers, but that is probably > wishful thinking. > > But JSON Pointer drafts have used the /{name|index} format for a year. > There are a bunch of implementations. The difference is minor in most > circumstances. So while I would be happy to change, I am also comfortable > staying with the current pointer syntax. > > > > There's no good reason for it to be that way, is there? > > I don't think so. > > -- > James Manger > --e89a8f5036c8a3d5f404d119b87a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What I'm not clea= r on, however, is what significant benefit making this kind of change would= provide. Yes, the syntax can be more verbose and exact but it's not cl= ear that the change is worth the cost.=C2=A0

Robert mentioned that the addition of the json-predica= tes test doubled the size of the json-patch file, and yes, I get that.. but= if we're talking about sending a two-object json-patch document to mod= ify a JSON document many times larger than that, it's still worth the e= xtra handful of bytes it takes. Sure, if we had a complex patch document co= nsisting of large amounts of json-patch and json-predicate objects being ap= plied to an=C2=A0arbitrarily structured document, I could understand the co= ncern, but in that case one would have to question the wisdom of doing a pa= rtial update in the first place. JSON-Patch documents are best served small= and simple, and the inclusion of a json-predicate or two per instance is n= ot going to blow the budget on bits on the wire.=C2=A0

So the key question becomes: what added ben= efit does a more verbose pointer syntax provide us? And is there a concrete= need for that benefit that can be demonstrated?

- James


On Mon, Dec 17, 2012 at= 9:12 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
If we were starting from scratch and definin= g JSON Pointer again I would argue for distinguishing array indices and obj= ect names in the syntax. For instance, prefix an object name with "/&q= uot; and an array index with ":".

=C2=A0 =C2=A0json-pointer =3D *segment
=C2=A0 =C2=A0segment =3D "/" name =C2=A0/ =C2=A0":" ind= ex
=C2=A0 =C2=A0name =3D *( unescaped / escaped )
=C2=A0 =C2=A0unescaped =3D %x00-2E / %x30-39 / %x3B-7D / %x7F-10FFFF
=C2=A0 =C2=A0escaped =3D "~" ( "0" / "1" / &q= uot;2" )
=C2=A0 =C2=A0index =3D "0" / %x31-39 *(%x30-39) / "-"
1. It makes parsing marginally harder: you cannot just split on "/&quo= t; and unescape each segment.
2. It doesn't make much difference for selecting a value from some JSON= , or for finding a spot to insert a new value.
3. It would allow you to automatically create object *or array* ancestors w= hen setting a new value (eg adding 23 at /a:0/b:0 to {} could give {"a= ":[{"b":[23]}]}).
4. It might encourage better validation of pointers, but that is probably w= ishful thinking.

But JSON Pointer drafts have used the /{name|index} format for a year. Ther= e are a bunch of implementations. The difference is minor in most circumsta= nces. So while I would be happy to change, I am also comfortable staying wi= th the current pointer syntax.


> There's no good reason for it to be that way, is there?

I don't think so.

--
James Manger

--e89a8f5036c8a3d5f404d119b87a-- From mnot@mnot.net Tue Dec 18 16:34:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C847E21E8047 for ; Tue, 18 Dec 2012 16:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.691 X-Spam-Level: X-Spam-Status: No, score=-103.691 tagged_above=-999 required=5 tests=[AWL=-1.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taLmGdwAyDLC for ; Tue, 18 Dec 2012 16:34:02 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2597121E8045 for ; Tue, 18 Dec 2012 16:34:02 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.33.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7C244509B6; Tue, 18 Dec 2012 19:33:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <50CFBC75.7090909@berkeley.edu> Date: Wed, 19 Dec 2012 11:33:53 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D6155E8-14FC-4A52-B19F-C4079A344820@mnot.net> References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50CFA92F.7080306@berkeley.edu> <50CFBC75.7090909@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 00:34:02 -0000 On 18/12/2012, at 11:44 AM, Erik Wilde wrote: > On 2012-12-17 16:39 , Mark Nottingham wrote: >> On 18/12/2012, at 10:22 AM, Erik Wilde wrote: >>> @mark, should we add a constraint to the JSON definition that for = the only XML NCNames SHOULD be used (it currently says "names SHOULD = conform to token [RFC2616]"), or something along these lines? >> I chose token to make it compatible with other serialisations as well = (e.g., in a HTTP Header); XML isn't the only (other) game in town. >=20 > sure. but for those serializations we know of, maybe being friendly to = them is a good idea. token is more permissible than NCName and thus = allows things that don't work too well in XML-land. maybe choose the = intersection of all of the ones we know of? Makes sense, although I don't want to do it by reference to NCName... -- Mark Nottingham http://www.mnot.net/ From mmorley@mpcm.com Tue Dec 18 17:00:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ED521F8828 for ; Tue, 18 Dec 2012 17:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff-j5RiYlq2n for ; Tue, 18 Dec 2012 17:00:42 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE64621F882D for ; Tue, 18 Dec 2012 17:00:41 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so4075144qan.3 for ; Tue, 18 Dec 2012 17:00:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=9M1apTBEubjLeegQH0OaUH+Wd2s4r6m/WT1J/J/FK+c=; b=QsQ2oWOs2gZ0rz4HyPyL6lKcQzEjvd2gZtLQf4/DeNZY4tAu31eabWsZ8aQFd79K3d +A7pleQyHH0qyeUpXupI7TdN0houn/HWxYFP22nhRp3/3SZ447FvUBSHM6aUmjxC2FbV T9A8PUZQYKqtjur0XGCGZQb//hy6EFduz8XVhP3zEoIEIpyWjdGzK3M2r/Q6Y1IPXfD/ 7bXFolB9Fd1XYnyr31sJLi5lAEd8ZQn0Rol4C9dgskO2O+k3+f28ZJyXUk6sA4oxsy6X e6H+eWla/ZDXoCWGP06qArcd4zsHskun+94LkSXd/31DqQ56eQDP7JeFM14HCW6+dDKN 8Uyg== MIME-Version: 1.0 Received: by 10.224.17.68 with SMTP id r4mr1719933qaa.21.1355878840835; Tue, 18 Dec 2012 17:00:40 -0800 (PST) Sender: mmorley@mpcm.com Received: by 10.49.16.170 with HTTP; Tue, 18 Dec 2012 17:00:40 -0800 (PST) In-Reply-To: References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> <255B9BB34FB7D647A506DC292726F6E1150408948F@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 18 Dec 2012 20:00:40 -0500 X-Google-Sender-Auth: o_OH8K1GwtwGxS518AQm2VuXJ0U Message-ID: From: Matthew Morley To: James M Snell Content-Type: multipart/alternative; boundary=14dae9399b01aa9f7204d12a249b X-Gm-Message-State: ALoCoQnPxekGNr3aKT+8l4k1XHe+vv9XrYG2O5Yfrpm6Q10kfmtjYSKvz01hYaCyJ7QwFDOAT+V1 Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 01:00:42 -0000 --14dae9399b01aa9f7204d12a249b Content-Type: text/plain; charset=ISO-8859-1 I do not feel there is a gain from adjusting the syntax, in the role of JSON Pointer as a stand alone specification. The addition of such a change adds an implied checking of a list vs a collection, as part of pointer resolution. If you are using the pointer as a means to get a value, it makes little difference in the fact that the value either exists at the end of that path or it doesn't. (Get me the value at /a/b/c/2) If you are using the pointer as a method of identity, again it makes little difference as only one point can presented by that pointer. (You are at /a/b/c/2) For me, these are the primary uses of the JSON Pointer specification. Rarely is the underlying structure, in practice, of consequence. Something like JSON-Schema is much better for testing the shapes of JSON data. However, I can see the point in such a change when paired with JSON-Patch. But I still feel that even this is more of an attempt to overload the role of the pointer, to make it carry additional meaning that should be expressed in either the test or the operation keywords of that particular specification. My vote is to leave the specification syntax as is, and keep it simple to produce and consume, even at the cost of not being able to infer the structure of any given step in the pointer without the actual json object being traversed. -- Matthew P. C. Morley On Tue, Dec 18, 2012 at 12:24 AM, James M Snell wrote: > What I'm not clear on, however, is what significant benefit making this > kind of change would provide. Yes, the syntax can be more verbose and exact > but it's not clear that the change is worth the cost. > > Robert mentioned that the addition of the json-predicates test doubled the > size of the json-patch file, and yes, I get that.. but if we're talking > about sending a two-object json-patch document to modify a JSON document > many times larger than that, it's still worth the extra handful of bytes it > takes. Sure, if we had a complex patch document consisting of large amounts > of json-patch and json-predicate objects being applied to an arbitrarily > structured document, I could understand the concern, but in that case one > would have to question the wisdom of doing a partial update in the first > place. JSON-Patch documents are best served small and simple, and the > inclusion of a json-predicate or two per instance is not going to blow the > budget on bits on the wire. > > So the key question becomes: what added benefit does a more verbose > pointer syntax provide us? And is there a concrete need for that benefit > that can be demonstrated? > > - James > > > On Mon, Dec 17, 2012 at 9:12 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > >> If we were starting from scratch and defining JSON Pointer again I would >> argue for distinguishing array indices and object names in the syntax. For >> instance, prefix an object name with "/" and an array index with ":". >> >> json-pointer = *segment >> segment = "/" name / ":" index >> name = *( unescaped / escaped ) >> unescaped = %x00-2E / %x30-39 / %x3B-7D / %x7F-10FFFF >> escaped = "~" ( "0" / "1" / "2" ) >> index = "0" / %x31-39 *(%x30-39) / "-" >> >> 1. It makes parsing marginally harder: you cannot just split on "/" and >> unescape each segment. >> 2. It doesn't make much difference for selecting a value from some JSON, >> or for finding a spot to insert a new value. >> 3. It would allow you to automatically create object *or array* ancestors >> when setting a new value (eg adding 23 at /a:0/b:0 to {} could give >> {"a":[{"b":[23]}]}). >> 4. It might encourage better validation of pointers, but that is probably >> wishful thinking. >> >> But JSON Pointer drafts have used the /{name|index} format for a year. >> There are a bunch of implementations. The difference is minor in most >> circumstances. So while I would be happy to change, I am also comfortable >> staying with the current pointer syntax. >> >> >> > There's no good reason for it to be that way, is there? >> >> I don't think so. >> >> -- >> James Manger >> > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --14dae9399b01aa9f7204d12a249b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I do not feel there is a gain from adjusting the syntax, in the role of JSO= N Pointer as a stand alone specification.=A0The addition of such a change a= dds an implied=A0checking of a list vs a collection, as part of pointer res= olution.

If you are using the pointer as a means to get a value, it makes little= difference in the fact that the value either exists at the end of that pat= h or it=A0doesn't. =A0(Get me the value at /a/b/c/2)

If you are = using the pointer as a method of identity, again it makes little difference= as only one point can presented by that pointer. (You are at /a/b/c/2)

For me, these are the primary uses of the JSON Pointer specification. R= arely is the underlying structure, in practice, of=A0consequence.

So= mething like JSON-Schema is much better for testing the shapes of JSON data= .

However, I can see the point in such a change when pair= ed with JSON-Patch. But I still feel that even this is more of an attempt t= o overload the role of the pointer, to make it carry additional meaning tha= t should be expressed in either the test or the operation keywords of that = particular specification.

My vote is to leave the specification syntax as is, and keep it simple = to produce and consume, even at the cost of not being able to infer the str= ucture of any given step in the pointer without the actual json object bein= g traversed.

--=A0
Matthew P. C. Morley
On Tue, Dec 18, 2012 at 12:24 AM, James M Snel= l <jasnell@gmail.com> wrote:
What I'm not clear on, however, is what significant benefit m= aking this kind of change would provide. Yes, the syntax can be more verbos= e and exact but it's not clear that the change is worth the cost.=A0

Robert mentioned that the addition of the json-predica= tes test doubled the size of the json-patch file, and yes, I get that.. but= if we're talking about sending a two-object json-patch document to mod= ify a JSON document many times larger than that, it's still worth the e= xtra handful of bytes it takes. Sure, if we had a complex patch document co= nsisting of large amounts of json-patch and json-predicate objects being ap= plied to an=A0arbitrarily structured document, I could understand the conce= rn, but in that case one would have to question the wisdom of doing a parti= al update in the first place. JSON-Patch documents are best served small an= d simple, and the inclusion of a json-predicate or two per instance is not = going to blow the budget on bits on the wire.=A0

So the key question becomes: what added benefit = does a more verbose pointer syntax provide us? And is there a concrete need= for that benefit that can be demonstrated?

- James


On Mon, Dec 17, 2012 at 9:12 PM, Manger, James H <James.H.Ma= nger@team.telstra.com> wrote:
If we were starting from scratch and definin= g JSON Pointer again I would argue for distinguishing array indices and obj= ect names in the syntax. For instance, prefix an object name with "/&q= uot; and an array index with ":".

=A0 =A0json-pointer =3D *segment
=A0 =A0segment =3D "/" name =A0/ =A0":" index
=A0 =A0name =3D *( unescaped / escaped )
=A0 =A0unescaped =3D %x00-2E / %x30-39 / %x3B-7D / %x7F-10FFFF
=A0 =A0escaped =3D "~" ( "0" / "1" / "2&= quot; )
=A0 =A0index =3D "0" / %x31-39 *(%x30-39) / "-"

1. It makes parsing marginally harder: you cannot just split on "/&quo= t; and unescape each segment.
2. It doesn't make much difference for selecting a value from some JSON= , or for finding a spot to insert a new value.
3. It would allow you to automatically create object *or array* ancestors w= hen setting a new value (eg adding 23 at /a:0/b:0 to {} could give {"a= ":[{"b":[23]}]}).
4. It might encourage better validation of pointers, but that is probably w= ishful thinking.

But JSON Pointer drafts have used the /{name|index} format for a year. Ther= e are a bunch of implementations. The difference is minor in most circumsta= nces. So while I would be happy to change, I am also comfortable staying wi= th the current pointer syntax.


> There's no good reason for it to be that way, is there?

I don't think so.

--
James Manger


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--14dae9399b01aa9f7204d12a249b-- From Claudio.Allocchio@garr.it Wed Dec 19 06:57:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3376921F8615 for ; Wed, 19 Dec 2012 06:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Iu2zjszvhNZ for ; Wed, 19 Dec 2012 06:57:05 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 75FE221F85E6 for ; Wed, 19 Dec 2012 06:57:05 -0800 (PST) Received: internal info suppressed Date: Wed, 19 Dec 2012 15:56:59 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: apps-discuss@ietf.org, draft-ietf-avt-rtp-evrc-nw.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-734205198-1355926362=:587" Content-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1355929021; bh=iLrXU9h4f06vpUXpZk+uaBHE7+hprgC5prJFJNyDUtQ=; h=Date:From:To:cc:Subject; b=JjX2r+GdStlWttEEkfEmFcwJVea9K60GKxpzrE0Xn049Rl26Trn5pe0++qUGLazZi G547hmCLKcllS+3Su7d80TBu/5PzrjzuLT4vNOc7aRCsGoGRQbzDI6xDXPNiJa70tx H9lFH0O4ewItw5QLk33GVhF9tpL8GfZcHKgeKYJc= Cc: iesg.ietf.org@cyrus.dir.garr.it Subject: [apps-discuss] APPSDIR review of draft-ietf-avt-rtp-evrc-nw-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:57:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-734205198-1355926362=:587 Content-Type: TEXT/PLAIN; FORMAT=flowed; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). I considered version 09. Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-avt-rtp-evrc-nw-09 Title: RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec Reviewer: Claudio Allocchio Review Date: Dec 19th 2012 IETF Last Call Date: IESG Telechat Date: 2012-12-20 Summary: the draft seems ready for publication and requires IANA registrations. I do not see any major problem in the specification. Major Issues: none. Minor Issues: As just an editorial suggstion, I'd just add an example in the text of what we intend when we talk of "narrowband" and "wideband" situations. An example with "numbers" in it. E.G. we consider "narrowband" when the Mbps rate is below XXX, "wideband" otherwise. Nits: none. ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca --0-734205198-1355926362=:587-- From jasnell@gmail.com Wed Dec 19 15:37:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDEF21F88A2 for ; Wed, 19 Dec 2012 15:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.675 X-Spam-Level: X-Spam-Status: No, score=-3.675 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8cX9TDWyFKj for ; Wed, 19 Dec 2012 15:37:43 -0800 (PST) Received: from mail-ia0-f171.google.com (mail-ia0-f171.google.com [209.85.210.171]) by ietfa.amsl.com (Postfix) with ESMTP id 72D2821F885C for ; Wed, 19 Dec 2012 15:37:43 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id k27so2303197iad.16 for ; Wed, 19 Dec 2012 15:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=EBXtbqRwOpsL7LVgLOAIaim/9ed13T9kxitAatzuNKU=; b=l6Rs+RWQ1SCM0JFB1MawgLHuhkyzRk6VMq0xuIiLTc3cTLXQnMn0aWoTJxq6meHRU8 8UiHEAelLAbWmEpAk8uVRn+I/5M4R6xvkbltU40bfiLfzhbe99X7Q0C1d1NeMdCpv82c F0iATrFW3xWKIgKT7dSPvJcG4kFoPA02tok1lgAzITwBZbfC7Vania1JEuqrnwHLJxiE ZW0eDbXOnq9bSnOEqtRcFDxgr+jeTJxoAr5l6S9Zlc3hxBL3/botaTHFJY6G80ooOqNN uHr+3QfDr9qxwu/c3rWXk2iuKJepWWlhkt7aWvq2QEDizF8rdOFG0DsNrzSa0IU6Gasy foQw== Received: by 10.50.196.227 with SMTP id ip3mr3844879igc.97.1355960262892; Wed, 19 Dec 2012 15:37:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Wed, 19 Dec 2012 15:37:22 -0800 (PST) In-Reply-To: <20121219233538.16685.47765.idtracker@ietfa.amsl.com> References: <20121219233538.16685.47765.idtracker@ietfa.amsl.com> From: James M Snell Date: Wed, 19 Dec 2012 15:37:22 -0800 Message-ID: To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=14dae934117bcc9c8804d13d1985 Subject: [apps-discuss] Fwd: New Version Notification for draft-snell-json-test-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:37:44 -0000 --14dae934117bcc9c8804d13d1985 Content-Type: text/plain; charset=UTF-8 Minor update for the json-predicates spec. Feedback/Comments welcome. ---------- Forwarded message ---------- From: Date: Wed, Dec 19, 2012 at 3:35 PM Subject: New Version Notification for draft-snell-json-test-04.txt To: jasnell@gmail.com A new version of I-D, draft-snell-json-test-04.txt has been successfully submitted by James M Snell and posted to the IETF repository. Filename: draft-snell-json-test Revision: 04 Title: JSON Predicate Creation date: 2012-12-20 WG ID: Individual Submission Number of pages: 24 URL: http://www.ietf.org/internet-drafts/draft-snell-json-test-04.txt Status: http://datatracker.ietf.org/doc/draft-snell-json-test Htmlized: http://tools.ietf.org/html/draft-snell-json-test-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-snell-json-test-04 Abstract: JSON Predicates defines a syntax for serializing various predicate expressions as JSON Objects. The IETF Secretariat --14dae934117bcc9c8804d13d1985 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Minor update for the = json-predicates spec. Feedback/Comments welcome.=C2=A0

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Dec 19, 2012 at 3:35 PM
Subject: New Version Notification for= draft-snell-json-test-04.txt
To: j= asnell@gmail.com



A new version of I-D, draft-snell-json-test-04.txt
has been successfully submitted by James M Snell and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-snell-json-test
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A004
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 JSON Predicate
Creation date: =C2=A0 2012-12-20
WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 24
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://w= ww.ietf.org/internet-drafts/draft-snell-json-test-04.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatracker.ietf.= org/doc/draft-snell-json-test
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/draf= t-snell-json-test-04
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ie= tf.org/rfcdiff?url2=3Ddraft-snell-json-test-04

Abstract:
=C2=A0 =C2=A0JSON Predicates defines a syntax for serializing various predi= cate
=C2=A0 =C2=A0expressions as JSON Objects.




The IETF Secretariat


--14dae934117bcc9c8804d13d1985-- From mnot@mnot.net Thu Dec 20 16:51:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2587821E8034 for ; Thu, 20 Dec 2012 16:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.799 X-Spam-Level: X-Spam-Status: No, score=-104.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdZ9DMML6Hsk for ; Thu, 20 Dec 2012 16:51:49 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 799B221E802E for ; Thu, 20 Dec 2012 16:51:49 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.220.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 115D8509B7; Thu, 20 Dec 2012 19:51:47 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <50CFBC75.7090909@berkeley.edu> Date: Fri, 21 Dec 2012 11:51:42 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50CFA92F.7080306@berkeley.edu> <50CFBC75.7090909@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 00:51:50 -0000 This is what I have now: > If such additional members are defined, their names SHOULD = start with > a letter (ALPHA, as per and SHOULD = consist of > characters from ALPHA, DIGIT and "_", so that it can be = serialised in > formats other than JSON, and SHOULD be three characters or = longer. On 18/12/2012, at 11:44 AM, Erik Wilde wrote: > On 2012-12-17 16:39 , Mark Nottingham wrote: >> On 18/12/2012, at 10:22 AM, Erik Wilde wrote: >>> @mark, should we add a constraint to the JSON definition that for = the only XML NCNames SHOULD be used (it currently says "names SHOULD = conform to token [RFC2616]"), or something along these lines? >> I chose token to make it compatible with other serialisations as well = (e.g., in a HTTP Header); XML isn't the only (other) game in town. >=20 > sure. but for those serializations we know of, maybe being friendly to = them is a good idea. token is more permissible than NCName and thus = allows things that don't work too well in XML-land. maybe choose the = intersection of all of the ones we know of? >=20 > cheers, >=20 > dret. -- Mark Nottingham http://www.mnot.net/ From jyee@afilias.info Thu Dec 20 21:12:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1897021F8953 for ; Thu, 20 Dec 2012 21:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnlFHKdAWbOG for ; Thu, 20 Dec 2012 21:12:35 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 82B8B21F88E1 for ; Thu, 20 Dec 2012 21:12:35 -0800 (PST) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1TluuP-0004aE-5u for apps-discuss@ietf.org; Fri, 21 Dec 2012 05:12:33 +0000 Received: from mail-ia0-f200.google.com ([209.85.210.200]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1TluuP-0007yo-5f for apps-discuss@ietf.org; Fri, 21 Dec 2012 05:12:33 +0000 Received: by mail-ia0-f200.google.com with SMTP id f6so11675117iag.3 for ; Thu, 20 Dec 2012 21:12:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=b4c4R7PHjZxx08naLZboBKO3UiBBNfjWIKY+v5cq8Jc=; b=VrF1Xp22diht2bhfIH58BCuHPFN+KKqx1JCDB3XBARybNyFb8cqqD4JhNbfUavN55L F1xulmxxMwcp9V6ntnOh41oorXPbbuNSBpo1z2b4JKfhBjm9ImxFjwV7hsnpJHskesZT GKimsv9+fklJ8Ku1AVwNXxbbaOXx5vmmBq2bQOb5Vl8Wui+CaRX8jIoLmoAM+Uu4BM++ dN2JIXmmZqQmg1HzxbT9thd09ipTyJZSee/Qk2T9UyYO4MazTthVHSyHerG9blKkRMsT OUkntI8DbW4YncpdtFSEgHynutgR3kbjZEdkIAsRf/rqq1AonxuxJLl7OTc7j9OK+JY2 60+A== X-Received: by 10.182.250.17 with SMTP id yy17mr9985306obc.33.1356066748285; Thu, 20 Dec 2012 21:12:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.250.17 with SMTP id yy17mr9985301obc.33.1356066748174; Thu, 20 Dec 2012 21:12:28 -0800 (PST) Received: by 10.76.93.106 with HTTP; Thu, 20 Dec 2012 21:12:28 -0800 (PST) Date: Fri, 21 Dec 2012 00:12:28 -0500 Message-ID: From: Joseph Yee To: apps-discuss@ietf.org, draft-bonica-special-purpose.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlYw8KhWEb9dKl7XwYffKG05dxPWgSlQreSi0CtBo2ji/+FDpCqHFeeIVR77hPASkcU03Ol08Zcky9TRQ/t/WsFPfhPXP8VQl1ZmDES0y91l5T7aaVk/dLzMj1UFHK/r0kTOmDpajUFAM1w2MgjSIkaqwDFLA== Cc: The IESG Subject: [apps-discuss] APPSDIR review of draft-bonica-special-purpose-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 05:12:36 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-bonica-special-purpose-04 Title: Special-Purpose Address Registries Reviewer: Joseph Yee Review Date: Dec 20th 2012 Summary: This draft is ready for publication as Best Current Practice RFC. Major Issues: none. Minor Issues: (1) Table 20 - Reserved status for Discard-Only Prefix This seems like redirecting specific packets to some equivalent of /dev/null rather than drop, a very special behaviour IMHO. Shouldn't the reserved status more like True than False? (2) Update or Obsoletes RFC4773 & RFC5736? If the old output were obsoleted by this draft, isn't it better to obsolete old the rules as well. This is more of asking than raising it as issue. Nits: (1) No text references RFC4007. (2) In Table 1, the date format in Allocation Date (September, 1981) is different than the rest of the draft (no comma between month and year). If there is another level below nits, I will put this one under there. Note: I was reviewing version 03 and spotted 04 before publishing my review. I read the diff between the two and made adjustment of my review. Best Regards, Joseph From internet-drafts@ietf.org Fri Dec 21 09:20:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE71921F8A6B; Fri, 21 Dec 2012 09:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgsSpc1m7qX5; Fri, 21 Dec 2012 09:20:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A0D21F8A7D; Fri, 21 Dec 2012 09:20:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> Date: Fri, 21 Dec 2012 09:20:32 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 17:20:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-08.txt Pages : 20 Date : 2012-12-21 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From salvatore.loreto@ericsson.com Wed Dec 26 09:18:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B328321F8CCA; Wed, 26 Dec 2012 09:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.194 X-Spam-Level: X-Spam-Status: No, score=-106.194 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZd8at8uEuKx; Wed, 26 Dec 2012 09:18:47 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 290BA21F8C78; Wed, 26 Dec 2012 09:18:46 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-a1-50db317532cb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D1.D4.10459.5713BD05; Wed, 26 Dec 2012 18:18:45 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 26 Dec 2012 18:18:45 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D8A9F24ED; Wed, 26 Dec 2012 19:18:44 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4D8C553F6D; Wed, 26 Dec 2012 19:18:43 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 82CF853539; Wed, 26 Dec 2012 19:18:42 +0200 (EET) Message-ID: <50DB3173.7040206@ericsson.com> Date: Wed, 26 Dec 2012 18:18:43 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , draft-ietf-bliss-call-completion@tools.ietf.org, The IESG Content-Type: multipart/alternative; boundary="------------080200050209050707040406" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+JvjW6p4e0Ag0e3dC1Wv1zBZnF0+gQm ixl/JjI7MHssWfKTyePL5c9sAUxRXDYpqTmZZalF+nYJXBlrnixjL3gtX7F9yRT2BsYvkl2M nBwSAiYS+6/tYYOwxSQu3FsPZgsJnGSUWPFftouRC8jewCjxff0RdghnF6PE1un/oJy1jBL/ +y4wQzjbGCXaPxxnAennFdCWeL7uJCuIzSKgKtGy/wPYXDYBM4nnD7cwg9iiArESWy9dZoOo F5Q4OfMJC8ggEYEWRontf3cydTFycAgL2ElM7ioGqWEWCJN4+3wzM8StahJXz21ihrhVS6L3 bCfTBEbBWUhGzULSAmHbSlyYcx0qLi+x/e0cqLiuxIX/U1DEFzCyrWJkz03MzEkvN9zECAz1 g1t+6+5gPHVO5BCjNAeLkjhvmOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M+e1FG5aJ ly56Z1dSXZPlXnx/xZwZHhfm5Gyof7jxQuUiqxvNOfr/3I5rif3evlTC1vdiH8/+upkxnIt6 nR7kqsgyzJY4+P+v4tYX+54+3ih5zur/6Ypf37MlFTfL/mS35Hx5I/ZCW9q8vvtqUgqSO86E vhPt93ucU8c16dwqbsVcncC5Rls3KbEUZyQaajEXFScCAJvCGd5DAgAA Subject: [apps-discuss] APPSDIR review of draft-ietf-bliss-call-completion-18 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 17:18:48 -0000 --------------080200050209050707040406 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-bonica-special-purpose-04 Title: Call Completion for Session Initiation Protocol (SIP) Reviewer: Salvatore Loreto Review Date: Dec 26th 2012 Summary: This draft is ready for publication. Major Issues: none. Minor Issues: (1) Section 4.1, in the second to last paragraph In a more restricted system, this determination can depend on the mode of the CC call in question, which is provided by the 'm' parameter. It would be better specify what 'm' parameter you are referring, I guess it is the URI 'm' parameter so s/which is provided by the 'm' parameter/which is provided by the URI 'm' parameter (2) Section 11. Security considerations. The information is confined to a busy/not-busy indication, and in legitimate use, will be subscribed to stereotyped ways that limit the disclosure of status information: that is not completely true, as it can also convey indications about 'No Reply' or 'Not Logged-in'. The sections does not say anything if there are different security implications related to those two different indications. Nits: none Best Regards, -- Salvatore Loreto, PhD www.sloreto.com --------------080200050209050707040406 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit 
I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:   draft-bonica-special-purpose-04
Title: Call Completion for Session Initiation Protocol (SIP)
Reviewer:  Salvatore Loreto
Review Date:  Dec 26th 2012


Summary:

This draft is ready for publication.

Major Issues:

none.

Minor Issues:

(1)
Section 4.1, in the second to last paragraph

   In a more restricted system, this determination can depend
   on the mode of the CC call in question, which is provided by the 'm'
   parameter.

It would be better specify what 'm' parameter you are referring,
I guess it is the URI 'm' parameter so
 
s/which is provided by the 'm' parameter/which is provided by the URI 'm' parameter


(2)
Section 11. Security considerations.

   The information is
   confined to a busy/not-busy indication, and in legitimate use, will
   be subscribed to stereotyped ways that limit the disclosure of status
   information:

that is not completely true, as it can also convey indications about 'No Reply'
or 'Not Logged-in'.
The sections does not say anything if there are different security implications
related to those two different indications.


 Nits:

none

Best Regards,


    
-- 
Salvatore Loreto, PhD
www.sloreto.com

  


--------------080200050209050707040406--

From tobias.gondrom@gondrom.org  Wed Dec 26 23:00:09 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2447021F8D3D for ; Wed, 26 Dec 2012 23:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.362
X-Spam-Level: 
X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLWRWelyc9ig for ; Wed, 26 Dec 2012 23:00:08 -0800 (PST)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id E210821F8D3E for ; Wed, 26 Dec 2012 23:00:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1;  q=dns; c=nofws; s=default; d=gondrom.org; b=JiaGqYPw+JhPpJtiZm2B9UhlRWZX7CXQkKTIBIbH5PJlrmju/udVHqvsHNorGqQrsX4jX2Ut5yrI8XSXS/SbUmxdZbiw2GuXsJM6Sji7eQXOo7+e6Ev6GzBMhYGDazaj; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding;
Received: (qmail 29856 invoked from network); 27 Dec 2012 08:00:01 +0100
Received: from ip-43-113-static.velo.net.id (HELO ?10.128.191.242?) (203.153.113.43) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 27 Dec 2012 08:00:00 +0100
Message-ID: <50DBF1E9.3010805@gondrom.org>
Date: Thu, 27 Dec 2012 14:59:53 +0800
From: Tobias Gondrom 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: draft-ietf-core-coap.all@tools.ietf.org, cabo@tzi.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: presnick@qti.qualcomm.com, barryleiba@computer.org, apps-discuss@ietf.org
Subject: [apps-discuss] Early AppsDir review of draft-ietf-core-coap-13
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 07:00:09 -0000

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see ​ 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Please note, that as this is an early AppsDir review, I only cc'ed the 
two Apps ADs, but not the IESG to this email.

Document: draft-ietf-core-coap-13
Title: Constrained Application Protocol (CoAP)
Reviewer: Tobias Gondrom
Review Date: 27.12.2012
State: in WGLC

Summary:
This draft will have major impact on the underlying infrastructure of 
lossy networks using coap. The draft is nearly ready for IETF LC, there 
are a few suggestions I would make.


Some thoughts:
section 1.2

non-confirmable message:
Some other messages do not require an acknowledgement. This is
particularly true for messages that are repeated regularly for
application requirements, such as repeated readings from a sensor
where eventual success is sufficient.

The assumption that eventual success will happen is not necessarily 
correct.
It is rather: success is not critical for the sender node (nor could it 
change it's behaviour) based on that information. In the end even 
eventual success can not be guaranteed.


Comments/Questions:
- section 3.0 and section 4.3: "The payload data extends from after the 
marker to the end of the UDP datagram"
Is there a need for CoAP payloads across multiple UDP packets?
(see also rfc540 section 3.2 Message Size Guidelines and for IPv4 UDP 
max packet size of 65,507 bytes)
I fully understand the fact we want to avoid fragmentation.
The question would be, is there an application need for asynchronous 
larger message sizes assembled over time across different UDP packets in 
the form of CON packets.
Especially considering that maybe one packet is limited to <576bytes as 
outlined in section 4.3?


- considering that we assume a lossy network and repeated sending and 
don't really have a "session", is an 8byte token enough?
Even though I appreciate that it is not for security purposes as you 
MUST use a secure channel binding for that instead, I wonder, whether 
the fact that we don't have a a session ID and potentially infinite 
lifetimes of the CON message (as being resend), is it important that we 
increase the space beyond 8bytes?
(to avoid (or make it harder) spoofing and flooding attacks to spoof a 
confirm or a reset/? E.g. an attacker sending an 8-byte burst to cover 
every token over time.)

section 5.5:
"In the absence of this option, no default value is assumed and the 
format will need to be inferred by the application (e.g., from the 
application context or by "sniffing" the payload)."
As we have seen quite a bit of trouble with "sniffing" in http content 
types, you may want to be more strict and make it clear that sniffing 
SHOULD (or MUST) only apply if no content type is given. Also consider 
that unlike most web scenarios this is M2M and there is no human 
interaction that could make any deviating judgement calls.

section 5.9 Response Code Definitions:
I notice the absence of code 30x responses.
Why is that? Especially a redirect (e.g. to allow to switch to DTLS) 
seems important in this case?

section 9 Securing CoAP:
does Coap need to be able to determine which type of DTLS is in use?
(in which case mapping all three secure cases to coaps may not be 
sufficient for that distinction on the coap application layer?

Considering the weak security properties and large number of attack 
vectors (ncluding section 11.3, etc.) of non-secure coap,
the I-D should consider to write a "SHOULD use coaps whenever possible" 
in that section.

Why do you "hard-code" MUST support of 
"TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8"?
If it (the algs or AES128 or...) is ever not sufficiently secure anymore 
that would constitute a security weakness in the protocol.


section 11.3
"A CoAP server can reduce the amount of amplification it provides to
an attacker by using slicing/blocking modes of CoAP
[I-D.ietf-core-block] and offering large resource representations
only in relatively small slices. E.g., for a 1000 byte resource, a
10-byte request might result in an 80-byte response (with a 64-byte
block) instead of a 1016-byte response, considerably reducing the
amplification provided."

Although the following paragraph already put a "SHOULD" on 
authentication, it might be worth mentioning here as well, that any 
large amplification factors should only be done in the reponse if the 
the request is authenticated (i.e. using coaps).

Section 11.4.
this section is in fact very important (as we don't have some of the 
stabilising factors of a TCP/HTTP session here), and you may want to 
consider to also the "SHOULD use authentication" here?


Nits:
 From a naming perspective:
Safe/Unsafe Option might be better called "safe-forward option" or 
"unsafe-forward option"?

References:
you may want to add a reference to UDP (and DTLS)?

section 6.3
in case you wish, you could use informative reference to the Web Origin 
Concept rfc6454

Best regards, Tobias




From fgaliegue@gmail.com  Thu Dec 27 10:36:47 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3D921F8835 for ; Thu, 27 Dec 2012 10:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.74
X-Spam-Level: 
X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9R6gg4th8Nr for ; Thu, 27 Dec 2012 10:36:46 -0800 (PST)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id E6C2621F83EF for ; Thu, 27 Dec 2012 10:36:36 -0800 (PST)
Received: by mail-ob0-f179.google.com with SMTP id x4so9099621obh.10 for ; Thu, 27 Dec 2012 10:36:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=+jPrfEd1KDYS4s/mnjF/fWBleIDPGcRL8RsZjaV1C0I=; b=nS6sg9Qfghio8n0OQ7/PGpMwxA95vmqcA/4ZFGyM25prd+B0Uo/lfh0270mG+JebDc JU5DQy4Qd7YZmu3zQfVlxfjr8w2pGM2NWpPlSo2wvslwWxQKw/7MVmOUQ0h0LEzdqlJy 9sG8ETacZlm+vdSEhezY9wbFmVMCdAclAy3xzAqC2G/xxPsT9eFTyE5oBnGJyAON8fWF L0/nMBoCaQeR2DblxG0iOj8V67Kz5ffIT1LyurdGFGzYiVdR2JRkHJ7GIAcrbvAWpM51 2RWmq3zsKjq24xia2o5nzWxNC8SY9qJAJ9iTq3uY6vxs9m0+bHBL6hVRzEszyUXHbjOQ Pr1w==
MIME-Version: 1.0
Received: by 10.60.1.132 with SMTP id 4mr13935295oem.140.1356633396064; Thu, 27 Dec 2012 10:36:36 -0800 (PST)
Received: by 10.60.13.231 with HTTP; Thu, 27 Dec 2012 10:36:35 -0800 (PST)
Date: Thu, 27 Dec 2012 19:36:35 +0100
Message-ID: 
From: Francis Galiegue 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [apps-discuss] One question about RFC 6570
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 18:36:47 -0000

Section 2.4.1: it is said that "Prefix modifiers are not applicable to
variables that have composite values".

So, if variable x is defined as:

    x :=3D [ "a", "b" ]

and we encounter "x:3" in a template, this is not applicable, fine.
But what does this mean to implementations? Should this be regarded as
an error?

--
Francis Galiegue, fgaliegue@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

From tbray@textuality.com  Fri Dec 28 08:51:18 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC4F21F8D32 for ; Fri, 28 Dec 2012 08:51:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWD8zJZ7lJqY for ; Fri, 28 Dec 2012 08:51:17 -0800 (PST)
Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 92CFE21F8C54 for ; Fri, 28 Dec 2012 08:50:59 -0800 (PST)
Received: by mail-oa0-f48.google.com with SMTP id h2so9994848oag.35 for ; Fri, 28 Dec 2012 08:50:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=MMsc92Aw5QL2GWQdtY/pfAYmK4zoTxf1O2rPLR8ZJEg=; b=oDsK1NCjhl3Td2JHdSInlhP6PnsQSN4pZksg8+EqG27O1Qa2C1TgCQM/OHGnp3dwqM tHcuVG2SdstWGVdYjLu3ZQ2k4W9jQ3DYIA6DWb6vDwl84S/2W2SrhxtCMK0xWemF79g5 TVSniDKvvKYVyyozkF13lLC9Hy1waU2yWZfMX06pTMQxnmSD3QODGTszn06cYo035JUa fNyupkvvcU7nhSZhwBccKnvV8mXO3WENB4bVVCjBceqxjmP0NZknGY+Z4/VC7r4gOYg7 BalSeiTDpZDeLEDHw1bEYk1/CcgfwU9nUmtVCbm3J1rInOpP8FzHVN/3fhPIb7y93EI9 q32w==
MIME-Version: 1.0
Received: by 10.182.228.69 with SMTP id sg5mr28291950obc.2.1356713459011; Fri, 28 Dec 2012 08:50:59 -0800 (PST)
Received: by 10.76.152.198 with HTTP; Fri, 28 Dec 2012 08:50:58 -0800 (PST)
X-Originating-IP: [204.83.73.92]
Date: Fri, 28 Dec 2012 08:50:58 -0800
Message-ID: 
From: Tim Bray 
To: draft-daboo-ical-vcard-parameter-encoding.all@tools.ietf.org,  "apps-discuss@ietf.org" , The IESG 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQl4thKdnu444LHTDc95sFBs07TFXefDab3hFGS4r2RYLXC+q/F+on0knFHOf/IcIugOY1OQ
Subject: [apps-discuss] APPSDIR review of draft-daboo-ical-vcard-parameter-encoding-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 16:51:18 -0000

I have been selected as the Apps Area Directorate reviewer for this
draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:   draft-daboo-ical-vcard-parameter-encoding-02
Title: Parameter Value Encoding in iCalendar and vCard
Reviewer:  Tim Bray
Review Date:  Dec 28th 2012

Summary: This draft is ready for publication, after fixing one error

Major issues:  None

Minor issues:  Section 3, second para. Text reads =93If a ^ (U+005E)
character is followed by any other character than the ones above,
parsers SHOULD leave the ^ character in place.=94

- This should read =93SHOULD leave both the ^ and the following
character in place=94.
- Shouldn=92t this be a MUST?  The whole escaping scheme is going to
blow up if software starts doing this wrong, or am I missing
something?
- You might want to consider putting this rule in the table, =93^
followed by any other character|left unchanged=94. Might be simpler.

Nits: Appendix A.  Did the discussion also consider the very
successful and generalized character escaping system, as used in HTML
& XML, of " or " for U+0022?  If you did that, you=92d never
have to revisit this again, when (as seems likely) the need for other
character-escaping functions arises in the future?

From mnot@mnot.net  Fri Dec 28 16:29:57 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0CE21F8E00 for ; Fri, 28 Dec 2012 16:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=-2.403, BAYES_40=-0.185, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxUPgT24Udbw for ; Fri, 28 Dec 2012 16:29:56 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D2AA321F8DFD for ; Fri, 28 Dec 2012 16:29:56 -0800 (PST)
Received: from mnot-mini.mnot.net (unknown [118.209.220.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 75F86509B7 for ; Fri, 28 Dec 2012 19:29:55 -0500 (EST)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net>
Date: Sat, 29 Dec 2012 11:29:51 +1100
To: Apps Discuss 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 00:29:57 -0000

=46rom .

We currently use this language to describe the array index in a pointer:

>          characters that represent an unsigned base-10 integer value
>          (possibly with leading zeros), making the new referenced =
value
>          the array element with the zero-based index identified by the
>          token, or

But, as discussed, this is too loose.

I propose:

characters comprised of digits ("\d+", as per [RFC5234]) that represent =
...

Thoughts?

--
Mark Nottingham   http://www.mnot.net/




From derhoermi@gmx.net  Fri Dec 28 18:15:32 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F4621F8E30 for ; Fri, 28 Dec 2012 18:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnKzgibVxGQA for ; Fri, 28 Dec 2012 18:15:31 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 726BF21F8E2D for ; Fri, 28 Dec 2012 18:15:31 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MQbrP-1TcvaG3UOz-00U38v for ; Sat, 29 Dec 2012 03:15:29 +0100
Received: (qmail invoked by alias); 29 Dec 2012 02:15:29 -0000
Received: from pD9538B09.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [217.83.139.9] by mail.gmx.net (mp019) with SMTP; 29 Dec 2012 03:15:29 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19Zov4v1AtZwv/61TpDv44oW8oqN5dBnTAqO/TKZu tH0lXpYWTjCvSx
From: Bjoern Hoehrmann 
To: Mark Nottingham 
Date: Sat, 29 Dec 2012 03:15:32 +0100
Message-ID: <3bksd81m0ake6cd0n3jrjb3v0hcgfonpl8@hive.bjoern.hoehrmann.de>
References: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net>
In-Reply-To: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Apps Discuss 
Subject: Re: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 02:15:32 -0000

* Mark Nottingham wrote:
>From .

>I propose:
>
>characters comprised of digits ("\d+", as per [RFC5234]) that represent ...
>
>Thoughts?

That does not look like RFC 5234 syntax to me, it would be more like
`1*DIGIT`. That aside, 'stating "/+7", "/007", "/ 7", and "/7.0" are
example of pointers that MUST NOT be accepted as array indices' is
much more likely to have the desired effect than offering some formal
syntax.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From dret@berkeley.edu  Sat Dec 29 16:06:26 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049D321F8838 for ; Sat, 29 Dec 2012 16:06:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWAU6XfOOerG for ; Sat, 29 Dec 2012 16:06:25 -0800 (PST)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6041621F8831 for ; Sat, 29 Dec 2012 16:06:25 -0800 (PST)
Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.64]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Tp6Q3-0006kI-9c; Sat, 29 Dec 2012 16:06:24 -0800
Message-ID: <50DF857D.3050208@berkeley.edu>
Date: Sat, 29 Dec 2012 16:06:21 -0800
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: "apps-discuss@ietf.org application-layer protocols" , REST-Discuss ,  hypermedia-web@googlegroups.com
References: <20121230000248.6308.87225.idtracker@ietfa.amsl.com>
In-Reply-To: <20121230000248.6308.87225.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20121230000248.6308.87225.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Fwd: New Version Notification for draft-hausenblas-csv-fragment-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 00:06:26 -0000

A new version of I-D, draft-hausenblas-csv-fragment-01.txt
has been successfully submitted by Erik Wilde and posted to the
IETF repository.

Filename:	 draft-hausenblas-csv-fragment
Revision:	 01
Title:		 URI Fragment Identifiers for the text/csv Media Type
Creation date:	 2012-12-29
WG ID:		 Individual Submission
Number of pages: 10
URL: 
http://www.ietf.org/internet-drafts/draft-hausenblas-csv-fragment-01.txt
Status: 
http://datatracker.ietf.org/doc/draft-hausenblas-csv-fragment
Htmlized:        http://tools.ietf.org/html/draft-hausenblas-csv-fragment-01
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-hausenblas-csv-fragment-01

Abstract:
    This memo defines URI fragment identifiers for text/csv MIME
    entities.  These fragment identifiers make it possible to refer to
    parts of a text/csv MIME entity, identified by cell, row, column, or
    slice.

Note to Readers

    This draft should be discussed on the apps-discuss mailing list [12].

 



The IETF Secretariat


-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |



From mmorley@mpcm.com  Sat Dec 29 20:45:59 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E06B21F88B2 for ; Sat, 29 Dec 2012 20:45:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f1cqvIXouv5 for ; Sat, 29 Dec 2012 20:45:58 -0800 (PST)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id A0F4421F88A8 for ; Sat, 29 Dec 2012 20:45:57 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id v28so5972819qcm.25 for ; Sat, 29 Dec 2012 20:45:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=A6Ou1gGTluAuykN6r5ABMq36HTA36CrR9G9RFseBtXs=; b=WspxCxvbetLbtMlBNSeVTEpKxcoTqI8JOPASUjAfvsafh6xUiYq2aXr+4jfMqKBEAj xl1dV65Q3FxmePTHuRE+yNMiLLMysV4pOhG6miZ4RPOh/QbiSVcLiW/B0wSwxOFXFdq0 0Xybd5/sfGQmBHv63fl720truIfplODDkXGUoNQ5zs1311EndIAIUeiOLmB9d1utVrn/ 50MCupXPuWEXT4rb/vnWZmHh7oYReDx41v9fqo4wNEC6eLgiquw5lWr0AbmNjkbGZgr8 ZfbVSbfom2hCg6BJ1WNC26yvAa6dFGGqnBD486df5mhAaDUqcYkUyOHMittzR8/AYgJb 4Oyg==
MIME-Version: 1.0
Received: by 10.49.104.108 with SMTP id gd12mr19956182qeb.37.1356842757355; Sat, 29 Dec 2012 20:45:57 -0800 (PST)
Sender: mmorley@mpcm.com
Received: by 10.49.16.170 with HTTP; Sat, 29 Dec 2012 20:45:57 -0800 (PST)
In-Reply-To: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net>
References: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net>
Date: Sat, 29 Dec 2012 23:45:57 -0500
X-Google-Sender-Auth: CyElSYXRt4ZiQlfcsfaH9M92OYg
Message-ID: 
From: Matthew Morley 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=047d7b6d9b1e91782804d20a92ec
X-Gm-Message-State: ALoCoQnmtUh8ajYE7XYvQkASil7BVfmPMycviLl62P8HWaLkpqzOzils+aWGIWvJbYd+JsVnGZAU
Cc: Apps Discuss 
Subject: Re: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 04:45:59 -0000

--047d7b6d9b1e91782804d20a92ec
Content-Type: text/plain; charset=ISO-8859-1

I replied on the github link, but I think it bears repeating if this
audience is different enough....

My thoughts:

The syntax for a json-pointer should not require sub-expression parsing.

/a/b/c/1 should not resolve to the same path as /a/b/c/1.000, or /a/b/c/1e0
for that matter.  The later 2 should not be resolvable at all when c is an
array, even though they are a valid json-pointer path syntax.

For an object this is clear.... for any array, if these were considered
equal in resolving, you could not confirm identity based solely on json
pointer path comparisons at the string level.


On Fri, Dec 28, 2012 at 7:29 PM, Mark Nottingham  wrote:

> From .
>
> We currently use this language to describe the array index in a pointer:
>
> >          characters that represent an unsigned base-10 integer value
> >          (possibly with leading zeros), making the new referenced value
> >          the array element with the zero-based index identified by the
> >          token, or
>
> But, as discussed, this is too loose.
>
> I propose:
>
> characters comprised of digits ("\d+", as per [RFC5234]) that represent ...
>
> Thoughts?
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



-- 
Matthew P. C. Morley

--047d7b6d9b1e91782804d20a92ec
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I replied on the github link, but I think it bears repeating if this audien=
ce is different enough....

My thoughts:

The syntax for a json=
-pointer should not require sub-expression parsing.

/a/b/c/1 should =
not resolve to the same path as /a/b/c/1.000, or /a/b/c/1e0 for that matter=
. =A0The later 2 should not be resolvable at all when c is an array, even t=
hough they are a valid json-pointer path syntax.


For an object this is clear.... for any array, if these were considered=
 equal in resolving, you could not confirm identity based solely on json po=
inter path comparisons at the string level.



On Fri, Dec 28, 2012 at 7:29 PM, Mark Nottingham <mnot@mnot.net>=
 wrote:

>From <https://github.com/json-patch/json-patch-tests/issues/5=
>.



We currently use this language to describe the array index in a pointer:


> =A0 =A0 =A0 =A0 =A0characters that represent an unsigned base-10 integ=
er value

> =A0 =A0 =A0 =A0 =A0(possibly with leading zeros), making the new refer=
enced value

> =A0 =A0 =A0 =A0 =A0the array element with the zero-based index identif=
ied by the

> =A0 =A0 =A0 =A0 =A0token, or



But, as discussed, this is too loose.



I propose:



characters comprised of digits ("\d+", as per [RFC5234]) that rep=
resent ...



Thoughts?



--

Mark Nottingham =A0 http=
://www.mnot.net/







_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





-- 
Matthew P. C=
. Morley

--047d7b6d9b1e91782804d20a92ec--

From ddooss@wp.pl  Sun Dec 30 04:59:56 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09F121F85B3 for ; Sun, 30 Dec 2012 04:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.486
X-Spam-Level: 
X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SF7wv1Z4cmmt for ; Sun, 30 Dec 2012 04:59:56 -0800 (PST)
Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9872F21F847B for ; Sun, 30 Dec 2012 04:59:54 -0800 (PST)
Received: (wp-smtpd smtp.wp.pl 6905 invoked from network); 30 Dec 2012 13:59:51 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1356872392; bh=6mrZouuqx/Y91pZi/p6s/OLuIax1U2vhW5ZEQ/QFsHQ=; h=From:To:CC:Subject; b=t6UXYhSUW3DVw6fVyAxsyQaj5+o7vSiKTPrTbh5PjlaHNUTVACMhQRMz2V7zuQkrf y80wkLTn0Z5Jbxr19BPP55LjdfmO7VYfikADGIPb7rONfhllH0NoXfObMXNMz0w/Ui AtyFpbtIfwwSVG3h0jYBU/onWS+6q/+RWpb4Aavo=
Received: from 77-253-109-27.adsl.inetia.pl (HELO [192.168.1.1]) (ddooss@[77.253.109.27]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 30 Dec 2012 13:59:51 +0100
Message-ID: <50E03AC7.1000808@wp.pl>
Date: Sun, 30 Dec 2012 13:59:51 +0100
From: Dominik Tomaszuk 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Erik Wilde 
References: <20121230000248.6308.87225.idtracker@ietfa.amsl.com> <50DF857D.3050208@berkeley.edu>
In-Reply-To: <50DF857D.3050208@berkeley.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO 0000006 [0Sdz]                               
Cc: hypermedia-web@googlegroups.com, REST-Discuss , "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-hausenblas-csv-fragment-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 12:59:56 -0000

On 30.12.2012 01:06, Erik Wilde wrote:
> A new version of I-D, draft-hausenblas-csv-fragment-01.txt
> has been successfully submitted by Erik Wilde and posted to the
> IETF repository.
>
> Filename:     draft-hausenblas-csv-fragment
> Revision:     01
> Title:         URI Fragment Identifiers for the text/csv Media Type
> Creation date:     2012-12-29
> WG ID:         Individual Submission
> Number of pages: 10
> URL:
> http://www.ietf.org/internet-drafts/draft-hausenblas-csv-fragment-01.txt
> Status: http://datatracker.ietf.org/doc/draft-hausenblas-csv-fragment
> Htmlized:
> http://tools.ietf.org/html/draft-hausenblas-csv-fragment-01
> Diff: http://www.ietf.org/rfcdiff?url2=draft-hausenblas-csv-fragment-01
>
> Abstract:
>     This memo defines URI fragment identifiers for text/csv MIME
>     entities.  These fragment identifiers make it possible to refer to
>     parts of a text/csv MIME entity, identified by cell, row, column, or
>     slice.
>
> Note to Readers
>
>     This draft should be discussed on the apps-discuss mailing list [12].

I propose to add "regexp" scheme. For example:
http://example.com/data.csv#regexp:place=/^G/

Following the listing in § 2, the above CSV fragment selects a slice, 
yielding another CSV table as follows:
date,temperature,place
2011-01-01,1,Galway
2011-01-02,-1,Galway
2011-01-03,0,Galway

Cheers,
Dominik Tomaszuk

>
>
>
>
>
> The IETF Secretariat
>
>


From sm@elandsys.com  Sun Dec 30 13:56:30 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D3D21F8B03 for ; Sun, 30 Dec 2012 13:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScyinOPS9F3T for ; Sun, 30 Dec 2012 13:56:28 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C511B21F8AFD for ; Sun, 30 Dec 2012 13:56:28 -0800 (PST)
Received: from SUBMAN.elandsys.com ([197.224.130.246]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qBULuF7i010853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 30 Dec 2012 13:56:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1356904587; bh=S8nhk3C/KDeoXfJtdbM2ek0Mok2JmXjmoCBlom5tk8Y=; h=Date:To:From:Subject; b=uk+uNoaB4XmsjdeRQk9HujOieEItOiFdypX5PrXvD5Ei5O4FNHNGgrCQI2SXWJPa+ IpCtBdkTjg/FTfVnnw+6ndNRAnp0NVWaBy/DwoT7AGbfsg0uX57gmJKvYtfzsEsFc3 fQAf2F/xgyAqTMCsDAkk6Xly7kpfDcoivd/G3d1Y=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1356904587; i=@elandsys.com; bh=S8nhk3C/KDeoXfJtdbM2ek0Mok2JmXjmoCBlom5tk8Y=; h=Date:To:From:Subject; b=SwmartPHRjbzMYLH+FXWhORrFGPR5uL0/8YVvXpWqcdRDRwDJolXJXXfswJBg1yZL f2FW+v7WnAF93RaXqb9qBYlIoh3P5ey2G+Coh4THWAQmDXfpxD2LhtnxI09FlJ9uMs 3D77vLj6rRJ0RmtmcizF6fYj5OQgMVW5sH3khzD4=
Message-Id: <6.2.5.6.2.20121230123316.0a344b68@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 30 Dec 2012 13:14:03 -0800
To: apps-discuss@ietf.org
From: S Moonesamy 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [apps-discuss] Apps Area Directorate report for December 2012
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 21:56:30 -0000

The Applications Area Directorate provides semi-formal reviews of 
Internet-Drafts as a way to improve the quality of IETF 
specifications.  The directorate consists of the Working Group Chairs 
of the Applications Area and recognized experts in the Applications Area.

The following reviews were performed in December 2012:

    Reviewer             I-D

  S. Moonesamy        draft-ietf-6renum-enterprise-04
  Claudio Allocchio   draft-ietf-avt-rtp-evrc-nw-09
  Joseph Yee          draft-bonica-special-purpose-04
  Salvatore Loreto    draft-ietf-bliss-call-completion-18
  Tobias Gondrom      draft-ietf-core-coap-13
  Tim Bray            draft-daboo-ical-vcard-parameter-encoding-02

The Applications Area Directorate currently comprises 30 members, 
including the two members currently on leave.  The directorate 
performed 116 reviews in 2012.  The top six reviewers for this year are:

                    Reviews

  Claudio Allocchio    8
  S. Moonesamy         8
  Alexey Melnikov      7
  Murray S. Kucherawy  7
  Jiankang Yao         6
  Joseph Yee           6

Regards,
S. Moonesamy
On behalf of the Applications Area Directorate
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate


From mnot@mnot.net  Sun Dec 30 18:14:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF9C21F8C0F for ; Sun, 30 Dec 2012 18:14:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.757
X-Spam-Level: 
X-Spam-Status: No, score=-103.757 tagged_above=-999 required=5 tests=[AWL=-1.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShZCfRW3d4fW for ; Sun, 30 Dec 2012 18:14:28 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7332C21F8C09 for ; Sun, 30 Dec 2012 18:14:28 -0800 (PST)
Received: from [192.168.1.80] (unknown [118.209.136.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A8023509B5; Sun, 30 Dec 2012 21:14:26 -0500 (EST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: <3bksd81m0ake6cd0n3jrjb3v0hcgfonpl8@hive.bjoern.hoehrmann.de>
Date: Mon, 31 Dec 2012 13:14:22 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net> <3bksd81m0ake6cd0n3jrjb3v0hcgfonpl8@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann 
X-Mailer: Apple Mail (2.1499)
Cc: Apps Discuss 
Subject: Re: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Dec 2012 02:14:29 -0000

And, that's what I get for doing spec work on holiday. 1*DIGIT is indeed =
what I meant.

MUST NOT be accepted seems strong to me; many languages will just use =
parseInt() or similar, and I don't think that's really that horrific. =
What must be clear is that people producing pointers can't rely upon =
that, and making the syntax clear does that.=20

So, I'd be OK with prose, but think that a MUST NOT goes too far.

Cheers,


On 29/12/2012, at 1:15 PM, Bjoern Hoehrmann  wrote:

> * Mark Nottingham wrote:
>> =46rom .
>=20
>> I propose:
>>=20
>> characters comprised of digits ("\d+", as per [RFC5234]) that =
represent ...
>>=20
>> Thoughts?
>=20
> That does not look like RFC 5234 syntax to me, it would be more like
> `1*DIGIT`. That aside, 'stating "/+7", "/007", "/ 7", and "/7.0" are
> example of pointers that MUST NOT be accepted as array indices' is
> much more likely to have the desired effect than offering some formal
> syntax.
> --=20
> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 =
http://bjoern.hoehrmann.de
> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 =
http://www.bjoernsworld.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 =
http://www.websitedev.de/=20

--
Mark Nottingham   http://www.mnot.net/




From sayrer@gmail.com  Sun Dec 30 19:10:52 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99CE21F8BE9 for ; Sun, 30 Dec 2012 19:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JIkAzGzD0Gb for ; Sun, 30 Dec 2012 19:10:51 -0800 (PST)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCC721F8BC2 for ; Sun, 30 Dec 2012 19:10:51 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id 12so5730883wgh.7 for ; Sun, 30 Dec 2012 19:10:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/9N8IUxbQ8Ngz5+mZI2TRAfbvCjxgcXwqywieqDBQjE=; b=KXX9fLJ0OsuLP/2Oybv8yJGcJNH34YRAg+/XsM6ah/ip7d7fkx4/QrCk2EDh21lsdA UtF0sQy6H5HNdr/fUPrr1wBkEfBbO3IGuwJIh3N7HRHq2Ha02KbNXx3rFNj6p5ACNmFG Z/DJxt5xs85fVsht5scEb7OFAHxR8ZrA6sQCgI700Z6IBpacvoGS4WLoKdIl33uTt2Il 7fXP/QpY449J/3AqRevd5fATrsEk/TquY7ThxPwNtOsjoA9LpGp+LIPoqSay7T/EbUz4 +N05edkfV8g91mkiPbfhztq7l069h3gcT/9PBZ23EotPzhng24ABUHRZqvK+P+lND1P4 p9BQ==
MIME-Version: 1.0
Received: by 10.180.24.198 with SMTP id w6mr52931058wif.27.1356923449165; Sun, 30 Dec 2012 19:10:49 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Sun, 30 Dec 2012 19:10:49 -0800 (PST)
In-Reply-To: 
References: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net> <3bksd81m0ake6cd0n3jrjb3v0hcgfonpl8@hive.bjoern.hoehrmann.de> 
Date: Sun, 30 Dec 2012 19:10:49 -0800
Message-ID: 
From: Robert Sayre 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=f46d044403462cc89a04d21d5cb9
Cc: Apps Discuss , Bjoern Hoehrmann 
Subject: Re: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Dec 2012 03:10:52 -0000

--f46d044403462cc89a04d21d5cb9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There would be a clear deliniation in the grammar if arrays were made
distinct from objects.

- Rob


On Sunday, December 30, 2012, Mark Nottingham wrote:

> And, that's what I get for doing spec work on holiday. 1*DIGIT is indeed
> what I meant.
>
> MUST NOT be accepted seems strong to me; many languages will just use
> parseInt() or similar, and I don't think that's really that horrific. Wha=
t
> must be clear is that people producing pointers can't rely upon that, and
> making the syntax clear does that.
>
> So, I'd be OK with prose, but think that a MUST NOT goes too far.
>
> Cheers,
>
>
> On 29/12/2012, at 1:15 PM, Bjoern Hoehrmann >
> wrote:
>
> > * Mark Nottingham wrote:
> >> From .
> >
> >> I propose:
> >>
> >> characters comprised of digits ("\d+", as per [RFC5234]) that represen=
t
> ...
> >>
> >> Thoughts?
> >
> > That does not look like RFC 5234 syntax to me, it would be more like
> > `1*DIGIT`. That aside, 'stating "/+7", "/007", "/ 7", and "/7.0" are
> > example of pointers that MUST NOT be accepted as array indices' is
> > much more likely to have the desired effect than offering some formal
> > syntax.
> > --
> > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de  =B7
> http://bjoern.hoehrmann.de
> > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernswor=
ld.de
> > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websited=
ev.de/
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org 
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--f46d044403462cc89a04d21d5cb9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There would be a clear deliniation in the grammar if arrays were made disti=
nct from objects.

- Rob


On Sunday, December 30, 2012, Mark Nottingham  wrote:

And, that's what I get for doing spec work on holiday. 1*DIGIT is indee=
d what I meant.



MUST NOT be accepted seems strong to me; many languages will just use parse=
Int() or similar, and I don't think that's really that horrific. Wh=
at must be clear is that people producing pointers can't rely upon that=
, and making the syntax clear does that.




So, I'd be OK with prose, but think that a MUST NOT goes too far.



Cheers,





On 29/12/2012, at 1:15 PM, Bjoern Hoehrmann <derhoermi@=
gmx.net> wrote:



> * Mark Nottingham wrote:

>> From <https://github.com/json-patch/json-patch-tests=
/issues/5>.

>

>> I propose:

>>

>> characters comprised of digits ("\d+", as per [RFC5234])=
 that represent ...

>>

>> Thoughts?

>

> That does not look like RFC 5234 syntax to me, it would be more like
> `1*DIGIT`. That aside, 'stating "/+7", "/007",=
 "/ 7", and "/7.0" are

> example of pointers that MUST NOT be accepted as array indices' is=


> much more likely to have the desired effect than offering some formal<=
br>
> syntax.

> --

> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoe=
rn.hoehrmann.de


> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.de

> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/



--

Mark Nottingham =A0 http=
://www.mnot.net/







_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss




--f46d044403462cc89a04d21d5cb9--

From jasnell@gmail.com  Mon Dec 31 07:36:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BB421F884D for ; Mon, 31 Dec 2012 07:36:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.64
X-Spam-Level: 
X-Spam-Status: No, score=-3.64 tagged_above=-999 required=5 tests=[AWL=-0.042,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgYKaxOpbjYo for ; Mon, 31 Dec 2012 07:36:12 -0800 (PST)
Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) by ietfa.amsl.com (Postfix) with ESMTP id 16E6D21F884A for ; Mon, 31 Dec 2012 07:36:12 -0800 (PST)
Received: by mail-ia0-f180.google.com with SMTP id t4so10453926iag.39 for ; Mon, 31 Dec 2012 07:36:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hfDmigI5uWZD/Tr9HIVDzr96wpYugVzkMp/HIHJCOvE=; b=HjC/rx90I1AV/hK/Vt1c0M3txvlqRskhjxDUFbItf988En7lLNxru7gSHaZedJW8t3 83qUpKwwiblmovnTHrzPTQXCxCn+FPXMft3iY4mfGMBhx2R+hEg5/o3wIgtNuBNWXffa ikhLDWbunvCAIWSZt5tsDt/PdBa2S+G6qkm2Rqo6Rj1Sllr5Bc5csIAv7rBBlS/VBz+N tlM+8xPiXs1YMJ4jdx4084SK5nXQQ+Z1L2KP2J9VMLoI+3lD86KiTJMSTYo/i2Rqszsi oLjBUC6i0RwP3ruaf3PZvAFfzRGa0yRrRdjYOO9ZEHNAG/Pgx2i8WfNEuZPNgHNrRpDF upvg==
Received: by 10.42.32.71 with SMTP id c7mr31946745icd.35.1356968171212; Mon, 31 Dec 2012 07:36:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.19 with HTTP; Mon, 31 Dec 2012 07:35:51 -0800 (PST)
In-Reply-To: 
References: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net> <3bksd81m0ake6cd0n3jrjb3v0hcgfonpl8@hive.bjoern.hoehrmann.de> 
From: James M Snell 
Date: Mon, 31 Dec 2012 07:35:51 -0800
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=bcaec517cda8d10dee04d227c5bd
Cc: Apps Discuss , Bjoern Hoehrmann 
Subject: Re: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Dec 2012 15:36:13 -0000

--bcaec517cda8d10dee04d227c5bd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 for 1+DIGIT with a statement that leading zeros SHOULD not be used and
MUST be ignored if they are present when evaluating an array. Nothing more
than that is required.


On Sun, Dec 30, 2012 at 6:14 PM, Mark Nottingham  wrote:

> And, that's what I get for doing spec work on holiday. 1*DIGIT is indeed
> what I meant.
>
> MUST NOT be accepted seems strong to me; many languages will just use
> parseInt() or similar, and I don't think that's really that horrific. Wha=
t
> must be clear is that people producing pointers can't rely upon that, and
> making the syntax clear does that.
>
> So, I'd be OK with prose, but think that a MUST NOT goes too far.
>
> Cheers,
>
>
> On 29/12/2012, at 1:15 PM, Bjoern Hoehrmann  wrote:
>
> > * Mark Nottingham wrote:
> >> From .
> >
> >> I propose:
> >>
> >> characters comprised of digits ("\d+", as per [RFC5234]) that represen=
t
> ...
> >>
> >> Thoughts?
> >
> > That does not look like RFC 5234 syntax to me, it would be more like
> > `1*DIGIT`. That aside, 'stating "/+7", "/007", "/ 7", and "/7.0" are
> > example of pointers that MUST NOT be accepted as array indices' is
> > much more likely to have the desired effect than offering some formal
> > syntax.
> > --
> > Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http:=
//bjoern.hoehrmann.de
> > Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoe=
rnsworld.de
> > 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www=
.websitedev.de/
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--bcaec517cda8d10dee04d227c5bd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1 for 1+DIGIT with a=
 statement that leading zeros SHOULD not be used and MUST be ignored if the=
y are present when evaluating an array. Nothing more than that is required.=
=C2=A0





On Sun, Dec 3=
0, 2012 at 6:14 PM, Mark Nottingham <mnot@mnot.net> wrote:


And, that's what I get for doing spec work on holiday. 1*DIGIT is indee=
d what I meant.



MUST NOT be accepted seems strong to me; many languages will just use parse=
Int() or similar, and I don't think that's really that horrific. Wh=
at must be clear is that people producing pointers can't rely upon that=
, and making the syntax clear does that.





So, I'd be OK with prose, but think that a MUST NOT goes too far.



Cheers,





On 29/12/2012, at 1:15 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:




> * Mark Nottingham wrote:

>> From <https://github.com/json-patch/json-patch-tests=
/issues/5>.

>


>> I propose:

>>

>> characters comprised of digits ("\d+", as per [RFC5234])=
 that represent ...

>>

>> Thoughts?

>


> That does not look like RFC 5234 syntax to me, it would be more =
like

> `1*DIGIT`. That aside, 'stating "/+7", "/007",=
 "/ 7", and "/7.0" are

> example of pointers that MUST NOT be accepted as array indices' is=


> much more likely to have the desired effect than offering some formal<=
br>
> syntax.

> --

> Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://bjoern.hoehrmann.de

> Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoernsworld.de
> 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.websitedev.de/<=
/a>




--

Mark Nottingham =C2=A0 h=
ttp://www.mnot.net/







_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





--bcaec517cda8d10dee04d227c5bd--

From cabo@tzi.org  Mon Dec 31 07:44:20 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D3821F88A6 for ; Mon, 31 Dec 2012 07:44:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.292
X-Spam-Level: 
X-Spam-Status: No, score=-106.292 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu0BegQ-tr6C for ; Mon, 31 Dec 2012 07:44:20 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AED4E21F8877 for ; Mon, 31 Dec 2012 07:44:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBVFiBBf007191; Mon, 31 Dec 2012 16:44:12 +0100 (CET)
Received: from [192.168.217.117] (p54894753.dip.t-dialin.net [84.137.71.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D2250958; Mon, 31 Dec 2012 16:44:10 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Mon, 31 Dec 2012 16:44:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <950C0B01-E28E-4604-BFE2-05AB48CCDAC8@tzi.org>
References: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net> <3bksd81m0ake6cd0n3jrjb3v0hcgfonpl8@hive.bjoern.hoehrmann.de>  
To: James M Snell 
X-Mailer: Apple Mail (2.1499)
Cc: Apps Discuss , Mark Nottingham , Bjoern Hoehrmann 
Subject: Re: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Dec 2012 15:44:20 -0000

On Dec 31, 2012, at 16:35, James M Snell  wrote:

>  1+DIGIT with a statement that leading zeros SHOULD not be used and =
MUST be ignored if they are present when evaluating an array

No, make that "MUST NOT be sent", "MUST be handled as an error" *).
The other way is the recipe for soup.

Gr=FC=DFe, Carsten

*) (If you do this in Javascript, that already happens automatically.)


From barryleiba@gmail.com  Mon Dec 31 15:44:07 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BE521F86C2; Mon, 31 Dec 2012 15:44:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.718
X-Spam-Level: 
X-Spam-Status: No, score=-101.718 tagged_above=-999 required=5 tests=[AWL=-1.341, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjyLZXZbokNI; Mon, 31 Dec 2012 15:44:05 -0800 (PST)
Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id E1EC221F86C0; Mon, 31 Dec 2012 15:44:04 -0800 (PST)
Received: by mail-vb0-f50.google.com with SMTP id ft2so1547135vbb.37 for ; Mon, 31 Dec 2012 15:44:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=oZnyB9U8vBN86R/VWbdpC+cFigNYBR73+mHzD4ZKHIQ=; b=X8c4tGX+NIMAhXtgoHTX4mY88D8vfcYNOsVTTIWpjvdqWGL51tr9LqNDVrUTguRrXl sfsjARQciEyvoPQoVU/JfuuwF/ikBsMgTNRQm+eM96PYhqUUeLs9l3l7VI9MBhQGV0Sw UUmeN21NotBAfP3e3iAoQ6mKJ2ZNT+vionBrEOQlIFC/9zfBWgbEqRkWZR19TToaG92B t0gq03zEolUPCi9auhHdXJufi6dbFnAn6ty3pvwFahxvciZXbeiuid6LKfTbqyK6pJkP XBIm8q7iWguNYCg3WKpTojsCgmXFFqTZc0JJyRgeKUjkGRVe/0GsFTmBov+xQfQlTpb2 TFRA==
MIME-Version: 1.0
Received: by 10.220.238.148 with SMTP id ks20mr66390981vcb.5.1356997443865; Mon, 31 Dec 2012 15:44:03 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.58.28.231 with HTTP; Mon, 31 Dec 2012 15:44:03 -0800 (PST)
Date: Mon, 31 Dec 2012 18:44:03 -0500
X-Google-Sender-Auth: GWxTfeXmTb1QtqC_0ptMeONikYw
Message-ID: 
From: Barry Leiba 
To: "saag@ietf.org" , ietf-privacy@ietf.org,  Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] CfP for Second International Workshop on Privacy and Security in Online Social Media (PSOSM)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Dec 2012 23:44:07 -0000

Readers of these lists may be interested in this workshop, which is
co-located with the next WWW Conference in Rio de Janeiro this May.  I
know both of the workshop chairs, and can recommend participation.

Please don't respond here, but contact the workshop committee directly.

Barry

---------------------------------------------------------------------------------
CALL FOR PAPERS

Second International Workshop on Privacy and Security in Online Social
Media (PSOSM)
http://precog.iiitd.edu.in/events/psosm2013
Co-located with 22nd International World Wide Web Conference
Rio, Brazil
May 13 - 17, 2013

With increase in the usage of the Internet, there has been an
exponential increase in the use of online social media on the
Internet. Websites like Facebook, YouTube, Orkut, Twitter, Flickr,
Google+, FourSquare, Pinterest, and the likes have changed the way the
Internet is being used. However, widely used, there is a lack of
understanding of privacy and security issues on online social media.
Privacy and security of online social media need to be investigated,
studied and characterized from various perspectives (computational,
cultural, psychological, etc.).  It is critical to detect security
treats and defend privacy through real-time and scalable systems.
Since there are no logical boundaries for the social media, it is
important to study the problem from an international perspective too.
The main goals of the workshop are: To create a platform to discuss
latest and upcoming issues, trends, and cutting-edge research
approaches in security and privacy in online social media / complex
networked systems; (2) To bring researchers who are working separately
on security and privacy, and online social media, to discuss the
problems that overlap and bring these two areas together.

Topics / themes include, but not limited to the following:
- Information privacy disclosure, revelation and its effects in OSM
and online social networks
- Collateral damage due to information leakage (e.g. through photo
tagging) on OSM
- Privacy issues related to location based services on OSM
- Effective and usable privacy setting and policies on OSM
- Anonymization of social network dataset
- Identifying and preventing social spam (including phishing and
frauds) campaigns
- Tracking social footprint / identities across different social network
- Detection and characterization of spam, phishing, frauds, hate
crime, abuse, extremism via online social media
- Cyber-bullying, abuse and harassment detection, and prevention strategies
- Identifying and curbing malware, phishing, and botnets on OSM
- Filtering of pornography, viruses, and human trafficking on OSM
- Studying the social and economic impact of security and privacy issues on OSM
- User behavior towards change in privacy features in OSM
- Usability (including design flaws) of secure systems on online social media
- Data modeling of human behavior in context of security and privacy threats
- Privacy and security in social gaming applications
- Trust systems based on social networks
- Legal and ethical issues for researchers studying security and privacy on OSM
- Information credibility on OSM
- Security and Privacy issues in new entrants in OSM (e.g. Google Plus)
- Effect of OSM on conventional crime (robberies and theft)
- Means to maintain different legitimate identities on the same OSM service
- Access control, rights management, and security of social content
- Privacy-enhancing technologies, including anonymity, pseudonymity
and identity management, specifically for the web
- Identifying fraudulent entities in online social networks
- Problems due to unification of different identities of the same
persona on different social media services
- Using social media (e.g. Twitter) as sensors for decision making at
the organization level (i.e. detecting outbreaks)

Important dates
Abstract submission: February 22nd, 2013
Manuscripts due: February 25th, 2013
Notification of acceptance: March 13th, 2013
Final revised manuscript: April 1st, 2013
Workshop: May 14, 2013 (Full day)

** Best paper award will be given to the most outstanding paper
submitted to the workshop.**

Workshop chairs
- Prof. Ponnurangam Kumaraguru ("PK"), IIIT-Delhi, pk [at] iiitd [dot]
ac [dot] in
- Prof. Virgilo Almeida, UFMG

For more information: http://precog.iiitd.edu.in/events/psosm2013
Follow us at @precog_iiitd and tweet about the workshop using #psosm2013

--
Regards,
PSOSM 2013 Team
http://precog.iiitd.edu.in/events/psosm2013/
---------------------------------------------------------------------------------

From mmorley@mpcm.com  Mon Dec 31 19:15:46 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403E621F8A41 for ; Mon, 31 Dec 2012 19:15:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2de+Tminvsd for ; Mon, 31 Dec 2012 19:15:45 -0800 (PST)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 108F621F8A40 for ; Mon, 31 Dec 2012 19:15:44 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id fe20so4571990lab.15 for ; Mon, 31 Dec 2012 19:15:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=nVNaeKKHXYYmh/M7QnhD6dkF8Xyq8bDgFZBD7GlW4RE=; b=XIYlhJq1/79w68p398ztf8+2d/yjGRHagc8R5TbeuFkYkx3CE2zk2Fr3k0h5mQEBcv Vw6nXqWX7TAEvKq82Sponybpf+QhKjb0oAyT+b5uMHwYkqrrvlPF59sj1McJeUduWkct peTrhS2ammcYBa2zFK1D53ING/X/2+b5L7dZhjvtrBBlSJcnvugjFEQ3LlBe58eqvEHN +eWytm+MCa3mDzoeQw1OdeEgUqF2UmzPu9tHL2z5nUmSYIxry3I9zXqhH6r8i974HY/k PXcPtUnkziVNSXkKd+htLVQDo3+MmiYw+CZ9J6DUkSiF9lgw8EGTKcCbNbtuBDEOlfuw hubA==
MIME-Version: 1.0
Received: by 10.112.100.195 with SMTP id fa3mr17556801lbb.38.1357010143672; Mon, 31 Dec 2012 19:15:43 -0800 (PST)
Sender: mmorley@mpcm.com
Received: by 10.114.37.131 with HTTP; Mon, 31 Dec 2012 19:15:43 -0800 (PST)
In-Reply-To: <950C0B01-E28E-4604-BFE2-05AB48CCDAC8@tzi.org>
References: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net> <3bksd81m0ake6cd0n3jrjb3v0hcgfonpl8@hive.bjoern.hoehrmann.de>   <950C0B01-E28E-4604-BFE2-05AB48CCDAC8@tzi.org>
Date: Mon, 31 Dec 2012 22:15:43 -0500
X-Google-Sender-Auth: ARv8LFe_jt7UT2fZ9C4coVR9YWg
Message-ID: 
From: Matthew Morley 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=14dae9d7121691fae204d2318b3d
X-Gm-Message-State: ALoCoQkymnJGGv483Fw1sy1RDT6LdZzpibo5SljPnuG4srmAYf4yKH9mm+CMNTcsO1dTq0vYp4Ei
Cc: Apps Discuss , Mark Nottingham , Bjoern Hoehrmann 
Subject: Re: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Jan 2013 03:15:46 -0000

--14dae9d7121691fae204d2318b3d
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 31, 2012 at 10:44 AM, Carsten Bormann  wrote:

> On Dec 31, 2012, at 16:35, James M Snell  wrote:
>
> >  1+DIGIT with a statement that leading zeros SHOULD not be used and MUST
> be ignored if they are present when evaluating an array
>
> No, make that "MUST NOT be sent", "MUST be handled as an error" *).
> The other way is the recipe for soup.
>
>
Stricter wording makes the most sense to me. The behavior should be one of
non-resolution in the context of an array, which should translate into
either errors or failure.

The english to describe the correct value set seems to be `zero and
positive whole numbers`. I would have said 'whole numbers' off hand, but
perhaps `non-negative integers` is the most concise.
http://en.wikipedia.org/wiki/Natural_number

Leading zeros should not be allowed in that definition, as such numbers are
not really natural numbers.


An an aside, JSON doesn't use indexes.... it implies them via the base
languages as a means of access access. Depending on character set support,
and the systems in play, I could see this needing to be expand down the
road. Again, only if wider language support is expected as part of pointer
resolution... (ie. http://en.wikipedia.org/wiki/Japanese_numerals)

-- 
Matt (MPCM)

--14dae9d7121691fae204d2318b3d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 31, 2012 at 10:44 AM, Carsten Bormann <cabo@tzi.org> =
wrote:


On Dec 31, 2012, at 16:35, James M Snell <jasnell@gmail.com> wrote:



> =A01+DIGIT with a statement that leading zeros SHOULD not be used and =
MUST be ignored if they are present when evaluating an array




No, make that "MUST NOT be sent", "MUST be handled as =
an error" *).

The other way is the recipe for soup.



Stricter wording makes the most sense =
to me. The behavior should be one of non-resolution in the context of an ar=
ray, which should translate into either errors or failure.

The engli=
sh to describe the correct value set seems to be `zero and positive whole n=
umbers`. I would have said 'whole numbers' off hand, but perhaps `n=
on-negative integers` is the most concise. http://en.wikipedia.org/wiki/Natural_number


Leading zeros should not be allowed in that definition, as such numbers=
 are not really natural numbers.


An an aside, JSON do=
esn't use indexes.... it implies them via the base languages as a means=
 of access access. Depending on character set support, and the systems in p=
lay, I could see this needing to be expand down the road. Again, only if wi=
der language support is expected as part of pointer resolution... (ie. http://en.wikipedia.=
org/wiki/Japanese_numerals)


-- 
Matt (MPCM)


--14dae9d7121691fae204d2318b3d--