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:

--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 fallb