From ve7jtb@ve7jtb.com Sat Mar 2 09:13:27 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6137A21F856E for ; Sat, 2 Mar 2013 09:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.111, 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 kUoprZRGtbdw for ; Sat, 2 Mar 2013 09:13:26 -0800 (PST) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4D521F8563 for ; Sat, 2 Mar 2013 09:13:25 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id ro8so2321145pbb.32 for ; Sat, 02 Mar 2013 09:13:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:subject:message-id:date:to :mime-version:x-mailer:x-gm-message-state; bh=ZJYDDnqQFusDxFPkRKgelqWBV5a2i9IXF78wLiyLmLM=; b=cPKyYuXLqSYDJiqMAKdNucg3B9NyzazezSqO4Br7//MC3hjjojuEO5fPZ5xNDhU/zg B8hTCP0IP6MFF7qmIZbtQWUmLqUT4n8/zDdYlkohkTchFczRvS3AMfyFTJhN/6ImP9iw JmkdKmEYh7XMkmCqaHHACB8N4BW+D86O5XB7shmJnrG/BKuRY+pJiEg0uxzXs4wkz7dJ gCdkEi5t1+iEq196LFMv9jOB//y4zhdu+0cgoWecA0sUNpeGzX7CxSfMtdsxxXpojxdJ rHNcQVwBsOwWeZ955KrCYnnj1uTt9Cq4UhLTgc3TWHZ9HkP4/t56mJFN+N4La+d74wgy oP6Q== X-Received: by 10.68.197.106 with SMTP id it10mr7411950pbc.22.1362244404926; Sat, 02 Mar 2013 09:13:24 -0800 (PST) Received: from [192.168.10.62] (ip-64-134-234-74.public.wayport.net. [64.134.234.74]) by mx.google.com with ESMTPS id ax3sm16067265pbd.42.2013.03.02.09.13.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 09:13:22 -0800 (PST) From: John Bradley Content-Type: multipart/signed; boundary="Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> Date: Sat, 2 Mar 2013 09:13:20 -0800 To: Group Group , "openid-connect-interop@googlegroups.com" , "oauth@ietf.org WG" , "" , "webfinger@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkl9HzHE70YiSQ3MK2KLfellIDOEd41s49XgulmS4KAnQ2TIssaV4RAN18B1cnejM9JDgPG Subject: [webfinger] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 17:13:27 -0000 --Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4 Content-Type: multipart/alternative; boundary="Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E" --Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The eventbrite page for people wanting to attend the openID Connect = session prior to IETF86 is now available at: http://openid-ietf-86.eventbrite.com/ Please register if you are planning on coming. We will add the room = once we know it. Regards John Bradley= --Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The eventbrite page for people wanting to attend the openID Connect session prior to IETF86 is now available at:

Please register if you are planning on coming.  We will add the room once we know it.

Regards
John Bradley
--Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E-- --Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzAyMTcxMzIxWjAjBgkqhkiG9w0BCQQxFgQUNoGZ2ZF5 43lTgpmapQmFYpwMg2EwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAIW2CiOGThcHh69152zdqtxx1RKIZBrWHR86vbKhN xXpJREwnOvnCatyLPsX/HR/4TqWhkzYcPe7Hx42+FhSh1PHpXFUU4oO4dwIYum2p5CgEH4xXellC atLaKwzMuoDwS6AN15dZuUljT6Tmg+0vZdHZJ6vvxjSBkdWqlJeLWXZ/PWiyUBjFQW+xw/SunlYR QwqsDSLgdNIaAx06hwVQ8StZj9zWjQdR0HV7AESKnM/KNcaEPOcdEiA1GYvhPVMvwwz2Chp6Cemd CkBs4AtDi3WG6vSqV/1K3+yEe2w6nSzBd+dyvkDawafNG3nNUvGIKYuLu5qa4guKioLalZCzuwAA AAAAAA== --Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4-- From barryleiba.mailing.lists@gmail.com Sat Mar 2 11:57:41 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A3121F85A2; Sat, 2 Mar 2013 11:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.992 X-Spam-Level: X-Spam-Status: No, score=-102.992 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 464b7KErV3PC; Sat, 2 Mar 2013 11:57:40 -0800 (PST) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7535821F849A; Sat, 2 Mar 2013 11:57:40 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id m1so3764575ves.8 for ; Sat, 02 Mar 2013 11:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Lr0I1q4lLE88WKKSdKsegfB0+tVEdC0TJlVnrmC/d9c=; b=014WEoi13u7+0jvm0BE4CUhUM8jBidcDWCIl6d+SL3bqTneJb/BRp5Ba/+Y9Qbbga/ x6180K5SjH9TLsV8X9sXzVjNkht2L5/WteHE/S5RM2JlSBcPhaHYpDPs5FfxgpyC5XlF PvOrnT/iCX32i8pWHChE5kcECdbJwQpz7ERJpc1sUrLsfMZ7z4x/792QX5RERmH/yZWY SI9r1B1nw7pqCU38fWDWPTOYVP2okJyWLOC/VryVUaMdYW+zYoFuA5iRJRe7yBQmJg7F Y5XvhDmLINllqxNSTCSCw4L0HcOmpNgpdtJ92uezXSwevUC5+cjqKisPNiWTRtBuAu4c RWCQ== MIME-Version: 1.0 X-Received: by 10.220.151.5 with SMTP id a5mr5713630vcw.22.1362254259904; Sat, 02 Mar 2013 11:57:39 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Sat, 2 Mar 2013 11:57:39 -0800 (PST) In-Reply-To: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> Date: Sat, 2 Mar 2013 14:57:39 -0500 X-Google-Sender-Auth: pIhd1ejxGyjlivjoBjTUS8778as Message-ID: From: Barry Leiba To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Cc: "openid-connect-interop@googlegroups.com" , Group Group , "oauth@ietf.org WG" , "" , "webfinger@ietf.org" Subject: Re: [webfinger] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 19:57:41 -0000 > The eventbrite page for people wanting to attend the openID Connect session > prior to IETF86 is now available at: > http://openid-ietf-86.eventbrite.com/ That page says this: OpenID Meeting at IETF 86 The OpenID Foundation Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) Orlando, FL I do hope it means Thursday, 7 March. 11 April is about a month *after* the IETF meeting. Barry From ve7jtb@ve7jtb.com Sun Mar 3 14:58:57 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D5B21F88EA for ; Sun, 3 Mar 2013 14:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXPj9Kmzg+zr for ; Sun, 3 Mar 2013 14:58:57 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF8521F88E6 for ; Sun, 3 Mar 2013 14:58:54 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id fa11so2786138pad.37 for ; Sun, 03 Mar 2013 14:58:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=T8Kr+HzmtrVVdvBY4TuFNjgiCxYAhUg3qffVr0bw1yk=; b=PomDlLuK4uOsCDw0iFUClafrumcLXpGfGWmnyqJE6Bk/8N9SgXFwP2h0kzBoxYhbVY RwtnfHtzzDTaSM3AVuw9jYqCiCmpbOJ+NtnDBp8F2MW/M+nZhZQX8n+rB072PJePVywW zrpdfD4dKN/3qJMrSJjtLUaKHIHjf8//vDFRRQzQt7VIK2Znirjq6cl2sOripliQzr26 N2nHJg6hhH7rorQQc7jXYF5uwmUH8i0Ip6T6DbSHHmVzl35ch54+cophfQKqXNp3f1d7 cYx0UTzJ7z/as8LRnpB2uN3i+m7G+5//wYyHeyARvfgMJgAZsZZto/Mn6c96uoJZ8yYu T/Kw== X-Received: by 10.66.87.8 with SMTP id t8mr29074421paz.28.1362351533904; Sun, 03 Mar 2013 14:58:53 -0800 (PST) Received: from [10.186.239.43] ([61.213.4.2]) by mx.google.com with ESMTPS id hu2sm19966287pbc.38.2013.03.03.14.58.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 14:58:52 -0800 (PST) References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <8FCA9E2B-78C5-4C60-BEC2-0DF10600A7BE@ve7jtb.com> X-Mailer: iPhone Mail (10B146) From: John Bradley Date: Mon, 4 Mar 2013 07:58:50 +0900 To: Anthony Nadalin X-Gm-Message-State: ALoCoQmMgjXS4un2Ec74/UYX1wcid6rjEJ8b4IsG0HbOSIeTt3FD7H94yM/zQ6A9NLQ1CUwczkpg Cc: Barry Leiba , "openid-connect-interop@googlegroups.com" , "" , "webfinger@ietf.org" , Group Group , "oauth@ietf.org WG" Subject: Re: [webfinger] [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 22:58:57 -0000 --Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The title Sunday Mar 10 is the correct date. I will update the event.=20 Sorry don't know why the date is wrong.=20 Sent from my iPhone On 2013-03-03, at 9:12 AM, Anthony Nadalin wrote: > I thought it was Sunday >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ba= rry Leiba > Sent: Saturday, March 2, 2013 11:58 AM > To: John Bradley > Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.org W= G; ; webfinger@ietf.org > Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Con= nect at IETF#86 in Sun Mar 10 >=20 >> The eventbrite page for people wanting to attend the openID Connect=20 >> session prior to IETF86 is now available at: >> http://openid-ietf-86.eventbrite.com/ >=20 > That page says this: > OpenID Meeting at IETF 86 > The OpenID Foundation > Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) > Orlando, FL >=20 > I do hope it means Thursday, 7 March. 11 April is about a month > *after* the IETF meeting. >=20 > Barry > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMwMzIyNTg1MlowIwYJKoZIhvcNAQkEMRYEFHoU Un2mvlAgj6PGvrOK7kAGVdeUMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBACPvAuSNf7VayrPjy8fhaGuQMESoT/GIvHsu 9XyHXwNcfPPxdWWIABHujKei0X/i6dG+VHkKs+P2nZPYB6f9m3QqdxUzUd180SWMXLvxzLMoFPQO X9lh50LmyVNeVOlrBZEQiAiN/c7c9ew5NNJRyk/pGEj53secKFMsW/vMvg10GBhuVuKuS3xlsyE1 Wu0MYrb7RkqqhRvrXxTxP3nwH0KKreUrh0v0LmyEOd8Y7ZTNqP/mtnGGLo6o0Jkm+y+p/UZaqIRs RtJYp3ukn24bPyxFXodrZR+MWoqrKL0L79SCtsPB4o17OK3vr6D3FFUv6zxQdXxklL35aTRHXvc2 ZyYAAAAAAAA= --Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553-- From tonynad@microsoft.com Sat Mar 2 16:13:00 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AD521F85BF; Sat, 2 Mar 2013 16:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnaaFHd1K8gw; Sat, 2 Mar 2013 16:12:59 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 368F521F84B9; Sat, 2 Mar 2013 16:12:59 -0800 (PST) Received: from BL2FFO11FD008.protection.gbl (10.173.161.203) by BL2FFO11HUB010.protection.gbl (10.173.161.112) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sun, 3 Mar 2013 00:12:57 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sun, 3 Mar 2013 00:12:57 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 3 Mar 2013 00:12:55 +0000 Received: from mail16-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE022.bigfish.com (10.3.207.144) with Microsoft SMTP Server id 14.1.225.23; Sun, 3 Mar 2013 00:12:50 +0000 Received: from mail16-am1 (localhost [127.0.0.1]) by mail16-am1-R.bigfish.com (Postfix) with ESMTP id 055AF4402C4; Sun, 3 Mar 2013 00:12:50 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -17 X-BigFish: PS-17(zz9371I542Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h9a9j1155h) Received-SPF: softfail (mail16-am1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail16-am1 (localhost.localdomain [127.0.0.1]) by mail16-am1 (MessageSwitch) id 1362269563418841_14662; Sun, 3 Mar 2013 00:12:43 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.238]) by mail16-am1.bigfish.com (Postfix) with ESMTP id 625233600E5; Sun, 3 Mar 2013 00:12:43 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 3 Mar 2013 00:12:43 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.275.5; Sun, 3 Mar 2013 00:12:42 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.620.20; Sun, 3 Mar 2013 00:12:40 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.143]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.231]) with mapi id 15.00.0620.020; Sun, 3 Mar 2013 00:12:40 +0000 From: Anthony Nadalin To: Barry Leiba , John Bradley Thread-Topic: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 Thread-Index: AQHOF4A8v0OPDTa670Gnsm2UmNnS0piTGJXA Date: Sun, 3 Mar 2013 00:12:39 +0000 Message-ID: <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB042.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LISTS.OPENID.NET$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLEGROUPS.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(199002)(13464002)(23726001)(16676001)(46406002)(5343635001)(6806001)(76482001)(5343655001)(53806001)(63696002)(74662001)(44976002)(77982001)(50986001)(47976001)(56776001)(66066001)(20776003)(59766001)(15202345001)(46102001)(74502001)(47446002)(47776003)(54316002)(31966008)(51856001)(4396001)(47736001)(56816002)(80022001)(79102001)(65816001)(49866001)(50466001)(33646001)(54356001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB010; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07749F8C42 X-Mailman-Approved-At: Mon, 04 Mar 2013 04:53:18 -0800 Cc: "openid-connect-interop@googlegroups.com" , Group Group , "oauth@ietf.org WG" , "" , "webfinger@ietf.org" Subject: Re: [webfinger] [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 00:13:00 -0000 I thought it was Sunday -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bar= ry Leiba Sent: Saturday, March 2, 2013 11:58 AM To: John Bradley Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.org WG= ; ; webfinger@ietf.org Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Conn= ect at IETF#86 in Sun Mar 10 > The eventbrite page for people wanting to attend the openID Connect=20 > session prior to IETF86 is now available at: > http://openid-ietf-86.eventbrite.com/ That page says this: OpenID Meeting at IETF 86 The OpenID Foundation Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) Orlando, FL I do hope it means Thursday, 7 March. 11 April is about a month *after* the IETF meeting. Barry _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From phil.hunt@oracle.com Sat Mar 2 16:20:05 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF1721F84D6; Sat, 2 Mar 2013 16:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 eGQS7N-7Fl+9; Sat, 2 Mar 2013 16:20:04 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3C821F84D1; Sat, 2 Mar 2013 16:20:03 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r230JwkD021597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Mar 2013 00:19:59 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r230Jwxt010425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Mar 2013 00:19:58 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r230JvdO030315; Sat, 2 Mar 2013 18:19:57 -0600 Received: from [25.73.5.188] (/74.198.150.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 02 Mar 2013 16:19:57 -0800 References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3AE8D8EF-714C-4F6A-9B50-433AA2500C06@oracle.com> X-Mailer: iPhone Mail (10B146) From: Phil Hunt Date: Sat, 2 Mar 2013 16:19:51 -0800 To: Anthony Nadalin X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Mailman-Approved-At: Mon, 04 Mar 2013 04:53:19 -0800 Cc: Barry Leiba , "openid-connect-interop@googlegroups.com" , "" , John Bradley , "webfinger@ietf.org" , Group Group , "oauth@ietf.org WG" Subject: Re: [webfinger] [OAUTH-WG] [jose] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 00:20:05 -0000 I should be in orlando at 7:30ish if anything is happening in the evening.=20= Phil Sent from my phone. On 2013-03-02, at 16:12, Anthony Nadalin wrote: > I thought it was Sunday >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ba= rry Leiba > Sent: Saturday, March 2, 2013 11:58 AM > To: John Bradley > Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.org W= G; ; webfinger@ietf.org > Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Con= nect at IETF#86 in Sun Mar 10 >=20 >> The eventbrite page for people wanting to attend the openID Connect=20 >> session prior to IETF86 is now available at: >> http://openid-ietf-86.eventbrite.com/ >=20 > That page says this: > OpenID Meeting at IETF 86 > The OpenID Foundation > Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) > Orlando, FL >=20 > I do hope it means Thursday, 7 March. 11 April is about a month > *after* the IETF meeting. >=20 > Barry > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From paulej@packetizer.com Mon Mar 4 08:56:19 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C7621F8CB1 for ; Mon, 4 Mar 2013 08:56:19 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCZVjmClRynM for ; Mon, 4 Mar 2013 08:56:15 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AD31721F8CAC for ; Mon, 4 Mar 2013 08:56:12 -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 r24GuBbx008215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Mar 2013 11:56:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1362416171; bh=5/cNZPrfMqOKQGo9zZRw6GhNUbJr3qNOuBECs5qePvU=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=dPXSp5PyXfOrYm1z8RkvTd5d3CzESsE7twCLdnHc5cOQvs6qF0UOqLgIRRVap8EUH Syv5ZonR921aY/ucEe4x5kuqg7Bq+he0stm8xwN2rwy5LWAnN4cIoFO0lsn3kLkg8/ PMMZHQ36aYcRgpsllJxiPlY3WqIoqon6D2VeIko4= From: "Paul E. Jones" To: , Date: Mon, 4 Mar 2013 11:56:23 -0500 Message-ID: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DC_01CE18CF.4B5A9E90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4Y9rUsx5tHUVqkRUOozflBsxYVaQ== Content-Language: en-us Subject: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:56:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01DC_01CE18CF.4B5A9E90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Folks, =20 One of the features in WebFinger is the ability to define = =E2=80=9Cproperties=E2=80=9D related to either a subject or a link. =20 I would expect properties defined for a link to be defined as a part of = the link relation definition. =20 Properties that relate to the subject would be defined in separate RFCs = or could be defined by other SDOs or anyone else, as properties are = always fully-qualified URIs. =20 As an example, consider the following example: =20 "properties" : { "http://packetizer.com/ns/name" : "Paul E. Jones", "http://packetizer.com/ns/name#zh-CN" : = "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF" } =20 The =E2=80=9Cname=E2=80=9D property is intended to convey the = subject=E2=80=99s name with an optional language tag as a URI fragment. = This is not defined anywhere, except here: http://packetizer.com/ns/name =20 A question to the group is this: do we need to define a registry for = property values defined for a subject? The current WF spec does not = define a registry. Would we want to define one? If so, should that go = into the current draft? (I appreciate that this has gone to Last Call, = so I=E2=80=99ll apologize for not raising this before.) If we did, what = would the URIs look like? Does the IETF or IANA have a URI defined for = this sort of thing? =20 Paul =20 ------=_NextPart_000_01DC_01CE18CF.4B5A9E90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Folks,

 

One of the = features in WebFinger is the ability to define = =E2=80=9Cproperties=E2=80=9D related to either a subject or a = link.

 

I would expect properties defined for a link to be = defined as a part of the link relation definition.

 

Properties = that relate to the subject would be defined in separate RFCs or could be = defined by other SDOs or anyone else, as properties are always = fully-qualified URIs.

 

As an = example, consider the following example:

 

=C2=A0 = "properties" :

=C2=A0 = {

=C2=A0=C2=A0=C2=A0 = "http://packetizer.com/ns/name" : "Paul E. = Jones",

=C2=A0=C2=A0=C2=A0 = "http://packetizer.com/ns/name#zh-CN" : "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF"

=C2=A0 = }

 

The =E2=80=9Cname=E2=80=9D property is intended to = convey the subject=E2=80=99s name with an optional language tag as a URI = fragment.=C2=A0 This is not defined anywhere, except here: http://packetizer.com/ns/name<= /span>

 

A question to the group is this: do we need to define = a registry for property values defined for a subject?=C2=A0 The current = WF spec does not define a registry.=C2=A0 Would we want to define = one?=C2=A0 If so, should that go into the current draft?=C2=A0 (I = appreciate that this has gone to Last Call, so I=E2=80=99ll apologize = for not raising this before.)=C2=A0 If we did, what would the URIs look = like?=C2=A0 Does the IETF or IANA have a URI defined for this sort of = thing?

 

Paul

 

------=_NextPart_000_01DC_01CE18CF.4B5A9E90-- From barryleiba.mailing.lists@gmail.com Mon Mar 4 09:03:05 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9B921F8C20 for ; Mon, 4 Mar 2013 09:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=0.990, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRLurfV6HJJl for ; Mon, 4 Mar 2013 09:03:01 -0800 (PST) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1643021F8CD4 for ; Mon, 4 Mar 2013 09:03:01 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id d10so4835181vea.40 for ; Mon, 04 Mar 2013 09:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=BO4XCXVEj71utzae5CDJO3dk7mukzvKRQjFZSNv42Gw=; b=ejAEYJLQomBZVKd8U4VUbSN3I3niiaa4ffOkDcflD5P+xxKJ5G85XMqgxPA8Nzn5it NIZeodzmFzcMHCh+FPAv9gH4ttzrfXe9MrS875j9ySyFHqIUN63dbelSX6V931kTeR0G inHkCZPQ4cB7M3GdrNEZcuaChIH3KKUOwaSNKcV4vwjDM1sg4X5cLQYaOmw8p3FJI6nw rTwOJMAh2DJlb4bAtlMueIwwrme78hV9ZD8AiLW5D6BeAqenpCT+1/xBB+A5OgfBc9BJ vGZE8afV+W6n0EyTLJH0ypjtxH2bmaDPzoHfgVDTmrrwSSWkKU+2BK+N1pEq77V76q4D pKNg== MIME-Version: 1.0 X-Received: by 10.221.9.136 with SMTP id ow8mr7885084vcb.58.1362416580408; Mon, 04 Mar 2013 09:03:00 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Mon, 4 Mar 2013 09:03:00 -0800 (PST) In-Reply-To: References: <20130209033118.8995.1805.idtracker@ietfa.amsl.com> <028d01ce067d$32872780$97957680$@packetizer.com> Date: Mon, 4 Mar 2013 12:03:00 -0500 X-Google-Sender-Auth: 8CPdNtzb_IhxVMpvmBoUxNT1omM Message-ID: From: Barry Leiba To: "webfinger@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:03:05 -0000 Because I haven't seen anything posted here: Salvatore has requested publication of version -10: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ I am reviewing it now; the next step will be a two-week Last Call, followed by evaluation by the IESG. It will likely be scheduled on the 28 March IESG telechat. Barry, Applications AD From jasnell@gmail.com Mon Mar 4 09:06:27 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A88721F865D for ; Mon, 4 Mar 2013 09:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-2.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG16kmW9qxSt for ; Mon, 4 Mar 2013 09:06:23 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id CB59021F85DF for ; Mon, 4 Mar 2013 09:06:22 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id j6so9552004oag.36 for ; Mon, 04 Mar 2013 09:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=f4aADmOr+wPegSFI3rIGRAdE1EmREbNfjXu6JOdn0CU=; b=hRJg9SaZ2KANnpRBfyHbmd1r55TrWxbMXt7oftrsgSnWbxI7TCoeZbytsuWPoRICy/ 6ZdH+fP4b55o1Bvenq2mDGZ7PjOC62z51pbuRUNGnq6WjFKUowrzslWtKdtoBnjJe3oB urBb8FhUfONlidheZGWSMk7fTxiIw/CRlGr2Ni7KHdcdI5BPV8ZlJavC6ZpFLyQuJD18 WFfvt27VyPIoNLW0d8B97iZEB+ZPHtj+4eKvPMnmApy2PO5hycrSYfppR3guiIrs24G/ N0GCaew9xlXUoyDaTX46fiKxZa0H+ZDawWlPUoyGRTAQe4Ql4XRx50gkVHbvNM2Be110 FdbA== MIME-Version: 1.0 X-Received: by 10.182.107.66 with SMTP id ha2mr16594194obb.43.1362416782473; Mon, 04 Mar 2013 09:06:22 -0800 (PST) Received: by 10.60.23.193 with HTTP; Mon, 4 Mar 2013 09:06:22 -0800 (PST) Received: by 10.60.23.193 with HTTP; Mon, 4 Mar 2013 09:06:22 -0800 (PST) In-Reply-To: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> Date: Mon, 4 Mar 2013 09:06:22 -0800 Message-ID: From: James M Snell To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae93b56925b026404d71c606c Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:06:27 -0000 --14dae93b56925b026404d71c606c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would suggest holding off and waiting to see if a registry is necessary... maybe just see how adoption goes over the next few months then decide. On Mar 4, 2013 8:56 AM, "Paul E. Jones" wrote: > Folks,**** > > ** ** > > One of the features in WebFinger is the ability to define =E2=80=9Cproper= ties=E2=80=9D > related to either a subject or a link.**** > > ** ** > > I would expect properties defined for a link to be defined as a part of > the link relation definition.**** > > ** ** > > Properties that relate to the subject would be defined in separate RFCs o= r > could be defined by other SDOs or anyone else, as properties are always > fully-qualified URIs.**** > > ** ** > > As an example, consider the following example:**** > > ** ** > > "properties" :**** > > {**** > > "http://packetizer.com/ns/name" : "Paul E. Jones",**** > > "http://packetizer.com/ns/name#zh-CN" : "=E4=BF=9D=E7=BD=97=E2=80=A7= =E7=90=BC=E6=96=AF"**** > > }**** > > ** ** > > The =E2=80=9Cname=E2=80=9D property is intended to convey the subject=E2= =80=99s name with an > optional language tag as a URI fragment. This is not defined anywhere, > except here: http://packetizer.com/ns/name**** > > ** ** > > A question to the group is this: do we need to define a registry for > property values defined for a subject? The current WF spec does not defi= ne > a registry. Would we want to define one? If so, should that go into the > current draft? (I appreciate that this has gone to Last Call, so I=E2=80= =99ll > apologize for not raising this before.) If we did, what would the URIs > look like? Does the IETF or IANA have a URI defined for this sort of thi= ng? > **** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --14dae93b56925b026404d71c606c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would suggest holding off and waiting to see if a registry= is necessary... maybe just see how adoption goes over the next few months = then decide.

On Mar 4, 2013 8:56 AM, "Paul E. Jones"= ; <paulej@packetizer.com>= ; wrote:

Folks,

=C2=A0

=

One of the features in WebFinger is the ability to d= efine =E2=80=9Cproperties=E2=80=9D related to either a subject or a link.

=C2=A0

I wou= ld expect properties defined for a link to be defined as a part of the link= relation definition.

=C2=A0=

Properties that relate to the subject would be defined in separate RFCs or = could be defined by other SDOs or anyone else, as properties are always ful= ly-qualified URIs.

=C2=A0=

As an example, consider the following example:

=C2=A0

=C2=A0 "properties" :

=C2=A0 {

=C2=A0= =C2=A0=C2=A0 "http://packetizer.com/ns/name" : "Paul E. Jones",=

=C2=A0=C2=A0=C2=A0 "http://packetizer.com/ns/name#zh-CN&qu= ot; : "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF"= ;

=C2=A0 }

=C2=A0

The =E2=80=9Cname=E2=80=9D pro= perty is intended to convey the subject=E2=80=99s name with an optional lan= guage tag as a URI fragment.=C2=A0 This is not defined anywhere, except her= e: http://packetizer.= com/ns/name

=C2=A0

A que= stion to the group is this: do we need to define a registry for property va= lues defined for a subject?=C2=A0 The current WF spec does not define a reg= istry.=C2=A0 Would we want to define one?=C2=A0 If so, should that go into = the current draft?=C2=A0 (I appreciate that this has gone to Last Call, so = I=E2=80=99ll apologize for not raising this before.)=C2=A0 If we did, what = would the URIs look like?=C2=A0 Does the IETF or IANA have a URI defined fo= r this sort of thing?

=C2=A0

Paul<= u>

=C2=A0


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

--14dae93b56925b026404d71c606c-- From melvincarvalho@gmail.com Mon Mar 4 09:10:19 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4AB21F892D for ; Mon, 4 Mar 2013 09:10:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uytgAV5BTdX for ; Mon, 4 Mar 2013 09:10:15 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBFD21F8915 for ; Mon, 4 Mar 2013 09:10:14 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id n1so4124403lba.37 for ; Mon, 04 Mar 2013 09:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qd0rUrOvdpOnMFstDO3+5z6+hQSURqp+5s+WEkdc7ek=; b=VLpJk7clt0ew1fmI47nOOHLSPWYRdFM8sBIdGWBMVYjXJw21h8LXiFZXtMhEeTBfhp Ucosdt+XUGG/abbSBRUYF1S15xDG4wPi0ElQodm0tUgKYoNr55a4TYO1SWbhs/yuSUDF Yb6DRtOoqsUIEoUoCSOkxIWbp7APdpMFwqyAHqspbDu3JLuxNWEW3uU0kkSumyibvbo+ EPHVJQDFbgqDQDtYDlldIffmm88zoHTDxTXNQhDmbcG4d2mmwonz9dSLyHojaVYGF/sz i+ysyUxT1lSEDWvBUdCyhRPgSThxexO4HWj/QAHaRgwbVyLnKtH+sGd3HsDEJVkDc4KC /urA== MIME-Version: 1.0 X-Received: by 10.112.54.1 with SMTP id f1mr4805137lbp.85.1362417013343; Mon, 04 Mar 2013 09:10:13 -0800 (PST) Received: by 10.112.143.38 with HTTP; Mon, 4 Mar 2013 09:10:13 -0800 (PST) In-Reply-To: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> Date: Mon, 4 Mar 2013 18:10:13 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec55402ae1dd03404d71c6e12 Cc: webfinger@ietf.org Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:10:19 -0000 --bcaec55402ae1dd03404d71c6e12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4 March 2013 17:56, Paul E. Jones wrote: > Folks,**** > > ** ** > > One of the features in WebFinger is the ability to define =E2=80=9Cproper= ties=E2=80=9D > related to either a subject or a link.**** > > ** ** > > I would expect properties defined for a link to be defined as a part of > the link relation definition.**** > > ** ** > > Properties that relate to the subject would be defined in separate RFCs o= r > could be defined by other SDOs or anyone else, as properties are always > fully-qualified URIs.**** > > ** ** > > As an example, consider the following example:**** > > ** ** > > "properties" :**** > > {**** > > "http://packetizer.com/ns/name" : "Paul E. Jones",**** > > "http://packetizer.com/ns/name#zh-CN" : "=E4=BF=9D=E7=BD=97=E2=80=A7= =E7=90=BC=E6=96=AF"**** > > }**** > > ** ** > > The =E2=80=9Cname=E2=80=9D property is intended to convey the subject=E2= =80=99s name with an > optional language tag as a URI fragment. This is not defined anywhere, > except here: http://packetizer.com/ns/name**** > > ** ** > > A question to the group is this: do we need to define a registry for > property values defined for a subject? The current WF spec does not defi= ne > a registry. Would we want to define one? If so, should that go into the > current draft? (I appreciate that this has gone to Last Call, so I=E2=80= =99ll > apologize for not raising this before.) If we did, what would the URIs > look like? Does the IETF or IANA have a URI defined for this sort of thi= ng? > This is very similar to the @property element in HTML5 Generally what you would do is 'follow your nose' from the property URL to the description (via HTTP GET). You could start a registry if you wanted, but it's been done a few times already, e.g. schema.org, foaf, vcard, open graph protocol ... do we want another one to maintain, and where would it be specified, who would look after it etc. Is the XRD group still active, maybe they have something to say about JRD standardization? > **** > > ** ** > > Paul**** > > ** ** > > -- > > --- > You received this message because you are subscribed to the Google Groups > "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > --bcaec55402ae1dd03404d71c6e12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 4 March 2013 17:56, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=C2=A0

=

One of the features in WebFinger is the ability to d= efine =E2=80=9Cproperties=E2=80=9D related to either a subject or a link.

=C2=A0

I wou= ld expect properties defined for a link to be defined as a part of the link= relation definition.

=C2=A0=

Properties that relate to the subject would be defined in separate RFCs or = could be defined by other SDOs or anyone else, as properties are always ful= ly-qualified URIs.

=C2=A0=

As an example, consider the following example:

=C2=A0

=C2=A0 "properties" :

=C2=A0 {

=C2=A0= =C2=A0=C2=A0 "http://packetizer.com/ns/name" : "Paul E. Jones",=

=C2=A0=C2=A0=C2=A0 "http://packetizer.com/ns/name#zh-CN&qu= ot; : "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF"= ;

=C2=A0 }

=C2=A0

The =E2=80=9Cname=E2=80=9D pro= perty is intended to convey the subject=E2=80=99s name with an optional lan= guage tag as a URI fragment.=C2=A0 This is not defined anywhere, except her= e: http://packetizer.= com/ns/name

=C2=A0

A que= stion to the group is this: do we need to define a registry for property va= lues defined for a subject?=C2=A0 The current WF spec does not define a reg= istry.=C2=A0 Would we want to define one?=C2=A0 If so, should that go into = the current draft?=C2=A0 (I appreciate that this has gone to Last Call, so = I=E2=80=99ll apologize for not raising this before.)=C2=A0 If we did, what = would the URIs look like?=C2=A0 Does the IETF or IANA have a URI defined fo= r this sort of thing?


This is very similar to the @property ele= ment in HTML5

Generally what you would do is 'follow your nose&#= 39; from the property URL to the description (via HTTP GET).=C2=A0

= You could start a registry if you wanted, but it's been done a few time= s already, e.g. schema.org, foaf, vcard, = open graph protocol ... do we want another one to maintain, and where would= it be specified, who would look after it etc.=C2=A0

Is the XRD group still active, maybe they have something to say about J= RD standardization?
=C2=A0

=

=C2=A0

P= aul

=C2=A0

--
=C2=A0
---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
=C2=A0
=C2=A0

--bcaec55402ae1dd03404d71c6e12-- From melvincarvalho@gmail.com Mon Mar 4 09:12:44 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3B221F8CA1 for ; Mon, 4 Mar 2013 09:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgV8fa5Jd8wY for ; Mon, 4 Mar 2013 09:12:38 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 48DC021F8C98 for ; Mon, 4 Mar 2013 09:12:38 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id fs13so5249398lab.36 for ; Mon, 04 Mar 2013 09:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jVKFeBwXVUUEtmvzZy/gauwbcAM4IU5d2YGpYFVcI3I=; b=aqp8MEqmusmnzu/QxGv9tt+7o5XVBCKE5IL+jqXuNbBAMNhuh8uKHg/BV+9H2vgBXg 3PEJEYaob1APpDlH6a7eRFwlcOd/umU/u8gcz1ePOQl5xkphydwuR6JOBWguZgV4ULYu QQsfdcjiWtJb1D8s6MjsSnRMXjyqO+nNJkihYqCkhdaNMUu+D9DsGphHoVTh02P+udtv Q/yzzeu8hgaMS7q/79K0hye4c2QZuhX8i75Y557dZAPGdvWErvwSCzuHZJQFKEmM0tP5 IfG0bi5U4BItOmTVmXzRa8F6t8GcJ/BO6M1hBWdu/JApGisOuMP1R7/SPWm+1fpqTzmT Zpgg== MIME-Version: 1.0 X-Received: by 10.112.25.71 with SMTP id a7mr303946lbg.102.1362417157051; Mon, 04 Mar 2013 09:12:37 -0800 (PST) Received: by 10.112.143.38 with HTTP; Mon, 4 Mar 2013 09:12:36 -0800 (PST) In-Reply-To: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> Date: Mon, 4 Mar 2013 18:12:36 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec554de06aea6b804d71c769d Cc: webfinger@ietf.org Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:12:44 -0000 --bcaec554de06aea6b804d71c769d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4 March 2013 17:56, Paul E. Jones wrote: > Folks,**** > > ** ** > > One of the features in WebFinger is the ability to define =E2=80=9Cproper= ties=E2=80=9D > related to either a subject or a link.**** > > ** ** > > I would expect properties defined for a link to be defined as a part of > the link relation definition.**** > > ** ** > > Properties that relate to the subject would be defined in separate RFCs o= r > could be defined by other SDOs or anyone else, as properties are always > fully-qualified URIs.**** > > ** ** > > As an example, consider the following example:**** > > ** ** > > "properties" :**** > > {**** > > "http://packetizer.com/ns/name" : "Paul E. Jones",**** > > "http://packetizer.com/ns/name#zh-CN" : "=E4=BF=9D=E7=BD=97=E2=80=A7= =E7=90=BC=E6=96=AF"**** > > } > Very minor comment, would it not be better to put the properties under HTTPS? > **** > > ** ** > > The =E2=80=9Cname=E2=80=9D property is intended to convey the subject=E2= =80=99s name with an > optional language tag as a URI fragment. This is not defined anywhere, > except here: http://packetizer.com/ns/name**** > > ** ** > > A question to the group is this: do we need to define a registry for > property values defined for a subject? The current WF spec does not defi= ne > a registry. Would we want to define one? If so, should that go into the > current draft? (I appreciate that this has gone to Last Call, so I=E2=80= =99ll > apologize for not raising this before.) If we did, what would the URIs > look like? Does the IETF or IANA have a URI defined for this sort of thi= ng? > **** > > ** ** > > Paul**** > > ** ** > > -- > > --- > You received this message because you are subscribed to the Google Groups > "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > --bcaec554de06aea6b804d71c769d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 4 March 2013 17:56, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=C2=A0

=

One of the features in WebFinger is the ability to d= efine =E2=80=9Cproperties=E2=80=9D related to either a subject or a link.

=C2=A0

I wou= ld expect properties defined for a link to be defined as a part of the link= relation definition.

=C2=A0=

Properties that relate to the subject would be defined in separate RFCs or = could be defined by other SDOs or anyone else, as properties are always ful= ly-qualified URIs.

=C2=A0=

As an example, consider the following example:

=C2=A0

=C2=A0 "properties" :

=C2=A0 {

=C2=A0= =C2=A0=C2=A0 "http://packetizer.com/ns/name" : "Paul E. Jones",=

=C2=A0=C2=A0=C2=A0 "http://packetizer.com/ns/name#zh-CN&qu= ot; : "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF"= ;

=C2=A0 }


Very = minor comment, would it not be better to put the properties under HTTPS?=C2=A0

=C2=A0

The = =E2=80=9Cname=E2=80=9D property is intended to convey the subject=E2=80=99s= name with an optional language tag as a URI fragment.=C2=A0 This is not de= fined anywhere, except here: http://packetizer.com/ns/name

=C2=A0

A que= stion to the group is this: do we need to define a registry for property va= lues defined for a subject?=C2=A0 The current WF spec does not define a reg= istry.=C2=A0 Would we want to define one?=C2=A0 If so, should that go into = the current draft?=C2=A0 (I appreciate that this has gone to Last Call, so = I=E2=80=99ll apologize for not raising this before.)=C2=A0 If we did, what = would the URIs look like?=C2=A0 Does the IETF or IANA have a URI defined fo= r this sort of thing?=

=C2=A0

Paul

=C2=A0

--
=C2=A0
---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
=C2=A0
=C2=A0

--bcaec554de06aea6b804d71c769d-- From barryleiba.mailing.lists@gmail.com Mon Mar 4 11:42:23 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F0D21F8CF5 for ; Mon, 4 Mar 2013 11:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-u75xmuzcXQ for ; Mon, 4 Mar 2013 11:42:23 -0800 (PST) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 64EAF21F8CB4 for ; Mon, 4 Mar 2013 11:42:22 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so1020724vbb.9 for ; Mon, 04 Mar 2013 11:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=yCXV4PYibCjMQO0QTnlRv6tWc1AeppF/PLzTOP2caCQ=; b=1HkqJyHm37b1YjZ7Qj3NxrmSdOUJIJ4aTuKUGbWg53OrTNbxedTAfCbcJFT/1+/hXE uOS2ptESLXHVAwgZiJbE6+/hg/2CoTik2SVtjdLZKQxGTCNB8+uunp0Y/w/bNlYxpRAC Bh/850wrQ+3CTc/MNUKF44hSo8GMqf62BDzcdnvke2pRrp1LYBdjSR3v64+/jcSErjIH zyfVEis3wE79k85uiHuQnJD/PXMA271BWrbFZ2dZLMuVUplIgufQR3IQkf3E4W8HEwLv gfolHefXU5PG1yUxDfBzvhbAp0fliARfg8hcEKhSUDYPChwhyu3PbSBy1/OchDPoITrs 3VlA== MIME-Version: 1.0 X-Received: by 10.52.72.40 with SMTP id a8mr7406736vdv.20.1362426141727; Mon, 04 Mar 2013 11:42:21 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Mon, 4 Mar 2013 11:42:21 -0800 (PST) Date: Mon, 4 Mar 2013 14:42:21 -0500 X-Google-Sender-Auth: Tz-s34abPMhCe0qiksFZz_bhD40 Message-ID: From: Barry Leiba To: "webfinger@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [webfinger] AD review of draft-ietf-appsawg-webfinger-10 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 19:42:24 -0000 This document's in good shape, and is really good work. Thanks, everyone. I have a bunch of comments, but only one of them is significant... the rest are quite minor. None of them will block last call, so after I send this I'm going to request the last call. Document editors: please respond as appropriate to my comments, and then on next Monday, when I-D submissions are open again, post an -11 version with whatever updates you have at that point. --------------------------------------------- One significant issue: In Section 4.3: In the event that a client requests link relation types that are not defined for the specified "resource", a resource descriptor MUST be returned. In the returned JRD, the "links" array MAY be absent, empty, or contain only links that did match a provided "rel" value. I don't understand what this is trying to tell me to do, if I'm implementing a WebFinger resource and I get inappropriate "rel" values. I'm guessing that this is what you want, but this text doesn't make that clear at all: 1. Ignore all "rel" values that contain link relation types that are not defined for the specified resource. 2. If there are other "rel" values left, filter on them as though they were the only ones present. 3. If there are *no* other "rel" values left, do *not* return an unfiltered JRD. Instead, either: 3a. ...return a JRD with an empty "links" array ("links" : [ ]), or 3b. ...return a JRD with no "links" array present at all. Is there a reason to allow both 3a and 3b, rather than specifying one or the other? In any case, please re-word this paragraph so it says clearly what you want it to say. --------------------------------------------- Other minor comments: In the last paragraph of Section 3.2, you have "OPTIONAL". The 2119 keyword is out of place in this non-normative example. Besides: it's not optional; it's a "SHOULD support". So, really, change "is OPTIONAL" to "is not guaranteed". In the first paragraph of Section 4, to be consistent with how you render things later, you should probably make these changes (and then make sure your use of this is consistent throughout the document): using the HTTPS scheme => using the "https" scheme other URI scheme (such as HTTP) ==> other URI scheme (such as "http") In Section 4: GET requests to a WebFinger resource convey the URI to perform the query upon in the URI's query string; see Section 4.1 for details. First, I find this to be an awkward, with two different URIs not clearly differentiated. Second, Section 4.1 doesn't actually give details of the "URI to perform the query upon". Maybe this?: NEW A WebFinger resource is always given a query target, which is another URI that identifies the entity whose information is sought. GET requests to a WebFinger resource convey the query target in the "resource" parameter in the WebFinger URI's query string; see Section 4.1 for details. END In Section 4.1: First, each parameter value is percent-encoded, as per Section 2.1 of RFC 3986, so that it conforms to the query production in Section 3.4 of that specification, and additionally any instances of the "=" and "&" characters are also percent-encoded. I think this would be a bit clearer this way: NEW First, each parameter value is percent-encoded, as per Section 2.1 of RFC 3986. The encoding is done to conform to the query production in Section 3.4 of that specification, with the addition that any instances of the "=" and "&" characters within the parameter value are also percent-encoded. END I think that will avoid anyone's trying to encode the "=" in "resource=", and the like. The order in which the client places each attribute-and-value pair within the query component is unspecified. Is that really trying to say that the order has to be treated as insignificant when the query component is interpreted? If so, it should say it that way: NEW The order in which the client places each attribute-and-value pair within the query component does not matter in the interpretation of the query component. END In Section 4.2: The client MAY include the "Accept" header to indicate a desired representation, though no other representation than JRD is defined in this specification. I think I might prefer this: NEW The client MAY include the "Accept" header to indicate a desired representation; representations other than JRD might be defined in future specifications. The WebFinger resource MUST silently ignore any requested representations that it does not understand and support. END A WebFinger resource MAY redirect the client, but MUST only redirect the client to an HTTPS URI. I don't think this will actually be misinterpreted, but just to be clear about the MAY/MUST thing: NEW A WebFinger resource MAY redirect the client; if it does, the redirection MUST only be to an "https" URI. END In Section 4.3: When the "rel" parameter is used, only the link relations that match the link relations provided via the "rel" parameter are included in the array of links returned in the JRD. Not when it's *used* -- it can be used, but the resource might not support it, right? So: NEW When the "rel" parameter is used and accepted, only the link relations that match the link relations provided via the "rel" parameter are included in the array of links returned in the JRD. END The "rel" parameter MAY be transmitted to the WebFinger resource multiple times in order to request multiple types of link relations. Does this really mean this?: NEW The "rel" parameter MAY be included in the query component of the WebFinger URI multiple times in order to request multiple types of link relations. END Actually, I think "in the query component of the WebFinger URI" can be removed, to just say, "MAY be included multiple times". In Section 4.4, you've hit a pedantic pet peeve of mine that's a lost cause that I still fight: a JSON object that is comprised of the following Correctly, the whole "comprises" the parts (or "is composed of", but not "is comprised of"). NEW a JSON object that comprises the following END And similarly in the following paragraph and in Sections 4.4.3, 4.4.4.4, and 4.4.4.5. In Section 4.5: WebFinger requests can include a "resource" parameter (see Section 4.1) specifying the URI of an account, device, or other entity. Not "can include"; they do include it: Section 4.2 says that the 'query component MUST include the "resource" parameter exactly once'. To perform a WebFinger lookup on an account specific to the host being queried, use of the "acct" URI scheme is RECOMMENDED, since it explicitly identifies an account accessible via WebFinger. I'm racking my brain, trying to decide whether this is an appropriate 2119 "RECOMMENDED", which means "SHOULD", which means that there's an interoperability reason why you must do this unless you fully understand the consequences of not doing it. If what you're saying is that "acct" is always guaranteed to work, while others, such as "mailto" are crap shoots, then I think "RECOMMENDED" is OK. But if they all might or might not work, and we're just saying that "acct" was made for this and we're encouraging its use and it's the best of the bunch, then that's not a 2119 "RECOMMENDED". So can you clarify this for me (in email; don't change the text yet)? In Section 6: As with all web resources, access to the WebFinger resource MAY require authentication. Further, failure to provide required credentials MAY result in the server forbidding access or providing a different response than had the client authenticated with the server. Neither of these "MAY"s is an appropriate 2119 key word. "MAY" means "this is a completely optional choice". The WebFinger resource will either require authentication or it won't, but that's not a MAY sort of choice for anyone. Make both of them "may", or perhaps "might" or "could". Just as a contrast, the MAY in the second paragraph is fine, because it really is describing a choice that the resource can make, at its option. In the third paragraph, it's less clear. Given the example you use, I'd remove the "MAY". But I'm not going to beat you with truncheons about that one. In Section 8: On the two paragraphs about private/personal information, I suggest explicitly passing that by Alissa Cooper for review and comment, if you haven't already. Section 9.1: It would be good to explicitly request review on the mailing list now. That could save time for the formality later. --------------------------------------------- From paulej@packetizer.com Mon Mar 4 12:00:55 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1698F21F8F15 for ; Mon, 4 Mar 2013 12:00:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgWo8qWHamUy for ; Mon, 4 Mar 2013 12:00:53 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E8FAA21F902E for ; Mon, 4 Mar 2013 12:00: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 r24K0VVx018749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Mar 2013 15:00:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1362427232; bh=iLX1d7ENCWIJnINt8okN5mtQFzF4jFeMX5I8C7Ep+Jc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=aI7VXEOnunToIByfY+n0Bhpp6/PaaVWkZzWeX/llB9m5cNCx5tVSjnbN9p0LAXXew 9ydyHcojS6BQAp2OIgLDONC+mjSr0hYlru8ijlSW49XjNPomG4xdHLkooeEOfo0Hm1 pxyhoEPfS+UN0X7Ps2v6BdzWpcvk57l5FBV7nBSw= From: "Paul E. Jones" To: "'Melvin Carvalho'" , References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> In-Reply-To: Date: Mon, 4 Mar 2013 15:00:44 -0500 Message-ID: <027d01ce1912$f4f166d0$ded43470$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027E_01CE18E9.0C1C4930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKLwL0A+sqSEHWydlpfat7K30q9TwJhGAQWlwebgaA= Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:00:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_027E_01CE18E9.0C1C4930 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Melvin, =20 A Property UI is just a =E2=80=9Cname=E2=80=9D, so it names no = difference if it were a URN an HTTP URI or HTTPS URI. =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Melvin Carvalho Sent: Monday, March 04, 2013 12:13 PM To: webfinger@googlegroups.com Cc: webfinger@ietf.org Subject: Re: [webfinger] Properties in WebFinger =20 =20 On 4 March 2013 17:56, Paul E. Jones wrote: Folks, =20 One of the features in WebFinger is the ability to define = =E2=80=9Cproperties=E2=80=9D related to either a subject or a link. =20 I would expect properties defined for a link to be defined as a part of = the link relation definition. =20 Properties that relate to the subject would be defined in separate RFCs = or could be defined by other SDOs or anyone else, as properties are = always fully-qualified URIs. =20 As an example, consider the following example: =20 "properties" : { "http://packetizer.com/ns/name" : "Paul E. Jones", "http://packetizer.com/ns/name#zh-CN" : = "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF" } Very minor comment, would it not be better to put the properties under = HTTPS? =20 =20 The =E2=80=9Cname=E2=80=9D property is intended to convey the = subject=E2=80=99s name with an optional language tag as a URI fragment. = This is not defined anywhere, except here: http://packetizer.com/ns/name =20 A question to the group is this: do we need to define a registry for = property values defined for a subject? The current WF spec does not = define a registry. Would we want to define one? If so, should that go = into the current draft? (I appreciate that this has gone to Last Call, = so I=E2=80=99ll apologize for not raising this before.) If we did, what = would the URIs look like? Does the IETF or IANA have a URI defined for = this sort of thing? =20 Paul =20 --=20 =20 ---=20 You received this message because you are subscribed to the Google = Groups "WebFinger" group. To unsubscribe from this group and stop receiving emails from it, send = an email to webfinger+unsubscribe@googlegroups.com = . For more options, visit https://groups.google.com/groups/opt_out. =20 =20 =20 ------=_NextPart_000_027E_01CE18E9.0C1C4930 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Melvin,

 

A Property UI is just a =E2=80=9Cname=E2=80=9D, so it names no = difference if it were a URN an HTTP URI or HTTPS = URI.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Melvin Carvalho
Sent: Monday, March 04, 2013 = 12:13 PM
To: webfinger@googlegroups.com
Cc: = webfinger@ietf.org
Subject: Re: [webfinger] Properties in = WebFinger

 

 

On 4 March 2013 17:56, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

One of the = features in WebFinger is the ability to define = =E2=80=9Cproperties=E2=80=9D related to either a subject or a = link.

 <= /o:p>

I would = expect properties defined for a link to be defined as a part of the link = relation definition.

 <= /o:p>

Properties = that relate to the subject would be defined in separate RFCs or could be = defined by other SDOs or anyone else, as properties are always = fully-qualified URIs.

 <= /o:p>

As an = example, consider the following example:

 <= /o:p>

  = "properties" :

  = {

    = "http://packetizer.com/ns/name" : "Paul = E. Jones",

    = "http://packetizer.com/ns/name#zh-CN" : = "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF"

  = }


Very = minor comment, would it not be better to put the properties under = HTTPS?
 

 <= /o:p>

The = =E2=80=9Cname=E2=80=9D property is intended to convey the = subject=E2=80=99s name with an optional language tag as a URI = fragment.  This is not defined anywhere, except here: http://packetizer.com/ns/name

=

 <= /o:p>

A question = to the group is this: do we need to define a registry for property = values defined for a subject?  The current WF spec does not define = a registry.  Would we want to define one?  If so, should that = go into the current draft?  (I appreciate that this has gone to = Last Call, so I=E2=80=99ll apologize for not raising this before.)  = If we did, what would the URIs look like?  Does the IETF or IANA = have a URI defined for this sort of thing?

 

Paul

 

-- =
 
--- =
You received this message because you = are subscribed to the Google Groups "WebFinger" = group.
To unsubscribe from this group and = stop receiving emails from it, send an email to webfinger+unsubscribe@googlegroups.com.
<= span class=3Dhoenzb>For more options, visit https://groups.google.com/groups/opt_out. 
 

 

------=_NextPart_000_027E_01CE18E9.0C1C4930-- From melvincarvalho@gmail.com Mon Mar 4 12:05:11 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456DE21F8CB8 for ; Mon, 4 Mar 2013 12:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btfYg7bY9cm8 for ; Mon, 4 Mar 2013 12:05:10 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 501A921F8CAB for ; Mon, 4 Mar 2013 12:05:06 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so5423716lab.37 for ; Mon, 04 Mar 2013 12:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=f+vhwztkRL7V5kYq858G3ML4HHO/8C+UEtAiGABARpU=; b=dw/y6IRbK5g2sswvELpvfSDhBGkFjwn2Qn7O86bzw9MEZaiAXD1iUET4oww0c+B5U5 w9GIQCpkiCsl4UKgODpneLpojeG54lLnn99RfjP3xuPYNOrlCrr6mmuZCIxrqQQxTT36 P4+xgY8uj/n2yn7XtMti5GHlaw2Mrg8YnXZ94uLlsiEzPieJLWB39C+I7IIfa7QklBF/ QDW22wDHP+jllI0kHI1HxxO7jgP+pbbQH6+gqdMQOOf4HpkNaEuXaq3RV4buQpQ5Oh/W Y6fKhRV0TaCtyS4RTjFn0MGv8QVhn7CfjnOdJQNFadBYv7gq5o8WeE8BgnnXO9cJEQoy wdBQ== MIME-Version: 1.0 X-Received: by 10.112.38.202 with SMTP id i10mr4984382lbk.127.1362427505019; Mon, 04 Mar 2013 12:05:05 -0800 (PST) Received: by 10.112.143.38 with HTTP; Mon, 4 Mar 2013 12:05:04 -0800 (PST) In-Reply-To: <027d01ce1912$f4f166d0$ded43470$@packetizer.com> References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> <027d01ce1912$f4f166d0$ded43470$@packetizer.com> Date: Mon, 4 Mar 2013 21:05:04 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=90e6ba25e8c1781cbc04d71edf38 Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:05:11 -0000 --90e6ba25e8c1781cbc04d71edf38 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4 March 2013 21:00, Paul E. Jones wrote: > Melvin,**** > > ** ** > > A Property UI is just a =E2=80=9Cname=E2=80=9D, so it names no difference= if it were a URN > an HTTP URI or HTTPS URI. > Sure, I just meant that since WF is https oriented, it might be an idea to use https for these fields too. In the linked data world most schemas/vocabs/descriptions are http, but we are finding for some projects (particularly security oriented ones such as payments) putting things under https gives a bit more piece of mind and future proofing... :) > **** > > ** ** > > Paul**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Melvin Carvalho > *Sent:* Monday, March 04, 2013 12:13 PM > *To:* webfinger@googlegroups.com > *Cc:* webfinger@ietf.org > *Subject:* Re: [webfinger] Properties in WebFinger**** > > ** ** > > ** ** > > On 4 March 2013 17:56, Paul E. Jones wrote:**** > > Folks,**** > > **** > > One of the features in WebFinger is the ability to define =E2=80=9Cproper= ties=E2=80=9D > related to either a subject or a link.**** > > **** > > I would expect properties defined for a link to be defined as a part of > the link relation definition.**** > > **** > > Properties that relate to the subject would be defined in separate RFCs o= r > could be defined by other SDOs or anyone else, as properties are always > fully-qualified URIs.**** > > **** > > As an example, consider the following example:**** > > **** > > "properties" :**** > > {**** > > "http://packetizer.com/ns/name" : "Paul E. Jones",**** > > "http://packetizer.com/ns/name#zh-CN" : "=E4=BF=9D=E7=BD=97=E2=80=A7= =E7=90=BC=E6=96=AF"**** > > }**** > > > Very minor comment, would it not be better to put the properties under > HTTPS? > **** > > **** > > The =E2=80=9Cname=E2=80=9D property is intended to convey the subject=E2= =80=99s name with an > optional language tag as a URI fragment. This is not defined anywhere, > except here: http://packetizer.com/ns/name**** > > **** > > A question to the group is this: do we need to define a registry for > property values defined for a subject? The current WF spec does not defi= ne > a registry. Would we want to define one? If so, should that go into the > current draft? (I appreciate that this has gone to Last Call, so I=E2=80= =99ll > apologize for not raising this before.) If we did, what would the URIs > look like? Does the IETF or IANA have a URI defined for this sort of thi= ng? > **** > > **** > > Paul**** > > **** > > -- > > --- > You received this message because you are subscribed to the Google Groups > "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > **** > > ** ** > --90e6ba25e8c1781cbc04d71edf38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 4 March 2013 21:00, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

=C2=A0

A Property UI is just a =E2=80=9Cname=E2= =80=9D, so it names no difference if it were a URN an HTTP URI or HTTPS URI= .


Sure, I just meant that since WF is https= oriented, it might be an idea to use https for these fields too.=C2=A0 In = the linked data world most schemas/vocabs/descriptions are http, but we are= finding for some projects (particularly security oriented ones such as pay= ments) putting things under https gives a bit more piece of mind and future= proofing... :)
=C2=A0

<= u>

=C2=A0

Paul<= /span>

=C2=A0

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Melvin Carvalho
Sent: Monday, March 04, 2013 12:13 PM
To: webfinger@googlegroups.com<= /a>
Cc: w= ebfinger@ietf.org
Subject: Re: [webfinger] Properties in WebFinger

=C2= =A0

= =C2=A0

On 4 March 2013 17:56, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:


Very minor comment, would it not be better to put the pr= operties under HTTPS?
=C2=A0

=C2=A0

The =E2=80=9Cname=E2=80=9D property is intended to convey the subject=E2=80= =99s name with an optional language tag as a URI fragment.=C2=A0 This is no= t defined anywhere, except here: http://packetizer.com/ns/name

=C2=A0

A que= stion to the group is this: do we need to define a registry for property va= lues defined for a subject?=C2=A0 The current WF spec does not define a reg= istry.=C2=A0 Would we want to define one?=C2=A0 If so, should that go into = the current draft?=C2=A0 (I appreciate that this has gone to Last Call, so = I=E2=80=99ll apologize for not raising this before.)=C2=A0 If we did, what = would the URIs look like?=C2=A0 Does the IETF or IANA have a URI defined fo= r this sort of thing?

=C2=A0

Paul

=C2=A0=

-- <= /span>
=C2=A0
---
You received this message because you are subscribed = to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, sen= d an email to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.<= br> =C2=A0
=C2=A0

=C2=A0


--90e6ba25e8c1781cbc04d71edf38-- From kidehen@openlinksw.com Mon Mar 4 12:38:46 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA3321F90D3 for ; Mon, 4 Mar 2013 12:38:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWEow8iXk5G1 for ; Mon, 4 Mar 2013 12:38:44 -0800 (PST) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id B75F621F90D2 for ; Mon, 4 Mar 2013 12:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=EAMwwqm7wH9ZDZb33DDj9Yrol+2qT6QmdJWXk0v6Uag=; b=N0adhgi/9bjQ8T/HEoz/HyP8KEAvhJgjreX5ZbPO5LwixID/OEW3IMslCiNXLtGLEEFgWDq3tHdHzGBlXlYLl8RrUrhWgc5qx+/GI5U02sjgUhMgdLZ6+hDpF46/WFmK; Received: from kidehen.vpn ([10.100.2.3] helo=Macintosh-96.local) by mail.openlinksw.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1UCc9g-0000iT-9H for webfinger@ietf.org; Mon, 04 Mar 2013 15:38:40 -0500 Message-ID: <5135064F.3070302@openlinksw.com> Date: Mon, 04 Mar 2013 15:38:39 -0500 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: webfinger@ietf.org References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> <027d01ce1912$f4f166d0$ded43470$@packetizer.com> In-Reply-To: <027d01ce1912$f4f166d0$ded43470$@packetizer.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010000030908050408010809" Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:38:46 -0000 This is a cryptographically signed message in MIME format. --------------ms010000030908050408010809 Content-Type: multipart/alternative; boundary="------------050705000900020902070805" This is a multi-part message in MIME format. --------------050705000900020902070805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 3/4/13 3:00 PM, Paul E. Jones wrote: > > Melvin, > > A Property UI is just a "name", so it names no difference if it were a = > URN an HTTP URI or HTTPS URI. > You mean a property name is just a URI? And that a URI just names the=20 property? If the above is true, then there's a subtlety that's being overlooked if = the URI in question resolves to content the describes its referent i.e., = the content can take the form of an entity relationship graph=20 representing human- and machine-comprehensible entity relationship=20 semantics. Simple example: a URI denoting a property that's inversefunctional in=20 nature e.g., the semantics of an property that associates one of more=20 Agent URIs with an Email Address (mailto: scheme URI). Links: 1. http://bit.ly/Y6TIfs -- how entity relationship semantics enable=20 identity reconciliation . Kingsley > > Paul > > *From:*webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org]=20 > *On Behalf Of *Melvin Carvalho > *Sent:* Monday, March 04, 2013 12:13 PM > *To:* webfinger@googlegroups.com > *Cc:* webfinger@ietf.org > *Subject:* Re: [webfinger] Properties in WebFinger > > On 4 March 2013 17:56, Paul E. Jones > wrote: > > Folks, > > One of the features in WebFinger is the ability to define "properties" = > related to either a subject or a link. > > I would expect properties defined for a link to be defined as a part=20 > of the link relation definition. > > Properties that relate to the subject would be defined in separate=20 > RFCs or could be defined by other SDOs or anyone else, as properties=20 > are always fully-qualified URIs. > > As an example, consider the following example: > > "properties" : > > { > > "http://packetizer.com/ns/name" : "Paul E. Jones", > > "http://packetizer.com/ns/name#zh-CN" : "?????" > > } > > > Very minor comment, would it not be better to put the properties under = > HTTPS? > > The "name" property is intended to convey the subject's name with > an optional language tag as a URI fragment. This is not defined > anywhere, except here: http://packetizer.com/ns/name > > A question to the group is this: do we need to define a registry > for property values defined for a subject? The current WF spec > does not define a registry. Would we want to define one? If so, > should that go into the current draft? (I appreciate that this > has gone to Last Call, so I'll apologize for not raising this > before.) If we did, what would the URIs look like? Does the IETF > or IANA have a URI defined for this sort of thing? > > Paul > > --=20 > > --- > You received this message because you are subscribed to the Google > Groups "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to webfinger+unsubscribe@googlegroups.com > . > For more options, visit https://groups.google.com/groups/opt_out. > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------050705000900020902070805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 3/4/13 3:00 PM, Paul E. Jones wrote= :

Melvin,

 

A Property UI is just a “name”, so it names no diff= erence if it were a URN an HTTP URI or HTTPS URI.


You mean a property name is just a URI? And that a URI just names the property?

If the above is true, then there's a subtlety that's being overlooked if the URI in question resolves to content the describes its referent i.e., the content can take the form of an entity relationship graph representing human- and machine-comprehensible entity relationship semantics.

Simple example: a URI denoting a property that's inversefunctional in nature e.g., the semantics of an property that associates one of more Agent URIs with an Email Address (mailto: scheme URI).

Links:

1. h= ttp://bit.ly/Y6TIfs -- how entity relationship semantics enable identity reconciliation .

Kingsley

 

Paul

 

From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beha= lf Of Melvin Carvalho
Sent: Monday, March 04, 2013 12:13 PM
To: webfinger@googlegroups.com
Cc: webfinger@ietf.org
Subject: Re: [webfinger] Properties in WebFinger

 

&nbs= p;

On 4 March 2013 17:56, Paul E. Jones <p= aulej@packetizer.com> wrote:

Folks,

 

One of the features in WebFinger is the ability to define “properties” related to either a subject or= a link.

 

I would expect properties defined for a link to be defined as a part of the link relation definition.=

 

Properties that relate to the subject would be defined in separate RFCs or could be defined by other SDOs or anyone else, as properties are always fully-qualified URIs.

 

As an example, consider the following example:<= /p>

 

  "properties" :

  {

    "http://packetizer.com/ns/name= " : "Paul E. Jones",

    "http://packetizer.com/ns/name#zh-= CN" : "保罗‧琼斯"

  }


Very minor comment, would it not be better to put the properties under HTTPS?
 

--
 
---
You received this message becaus= e you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+unsubscribe@googlegroup= s.com.
For more options, visit https://groups.google.com/groups/= opt_out.
 
 <= /p>

 



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



--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767=
740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
--------------050705000900020902070805-- --------------ms010000030908050408010809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIID8zCC A+8wggLXoAMCAQICAgSPMA0GCSqGSIb3DQEBBQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMzAyMjMy MTUwNThaFw0xNDAyMjMyMTUwNThaMGExHDAaBgNVBAMTE0tpbmdzbGV5IFV5aSBJZGVoZW4x GjAYBgNVBAoTEU9wZW5MaW5rIFNvZnR3YXJlMSUwIwYJKoZIhvcNAQkBFhZraWRlaGVuQG9w ZW5saW5rc3cuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAun8PsZGCJvxI +x+Prt508na+aURR0ICKjsjwwhcPAhB7LSUMpPz/t3pHBxwBBDc/pCqqo5dSZxncZvZ+bC3Z sZHYg04LOLMaVje8AUDB74A723qC8EWn2UNxUwhB6PK1zX4bteKYQaViwNXYRYO+2G57KaAT 7YE9k27n40CGxz58jpCCgmMcFF53TPn76qGmwrgIlHcbQoKUxNr2Dr4Aga4K6SH4Kke3ZL+N FalfDXHFWncvq0Z0Yhdb99fgM4qtSkfSgwo0E305qSYtNvglyrSaaUj2ZQrX0WAaqMu63U+c WjwWAOM1aR/xTVxHEUlKQt++hvI0yPOxyvdymvAO/QIDAQABo4HQMIHNMB0GA1UdDgQWBBR1 zbKhTzGVLkkicoo5UU3IOuIZWDBLBgNVHREERDBChkBodHRwOi8vaWQubXlvcGVubGluay5u ZXQvZGF0YXNwYWNlL3BlcnNvbi9LaW5nc2xleVV5aUlkZWhlbiN0aGlzMC0GCWCGSAGG+EIB DQQgFh5WaXJ0dW9zbyBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwDgYDVR0PAQH/BAQDAgWgMCAG A1UdJQEB/wQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAprvJ MPqaBszcJp0XN7FooVQDbaUjWIQIBynHY8ezwJdsh+r5tHXvxdWOnf4c4MhtPVtxNHESy2pG r9Y3uv/JKL+wQZ6rP25x70pJzrHYFZbsMbkUzLQ4bkzd7QRyKlhyty87f2r5LRqQ0fLtsA2v dejaEUT0OSuRr2KfKXu/l6c/+FmxSWtvGMPKLkjok44kS4w+B2eyQWthaemj1g8vLPM3Lvsg kWzWVAMdP+vmOaa6bqOYuIkfqTHLh0uhGuoWYCMOcBUI1MnwMN6WCysn0y4J2yUsfs375v8w do1AgQHg5QEVEwLrYDRh/1EZzjrDWhWURE+etB8rm8TBYSx6NzGCAu8wggLrAgEBMEcwQTEj MCEGA1UEAwwaT3BlbkxpbmsgU29mdHdhcmUgTG9jYWwgQ0ExGjAYBgNVBAoMEU9wZW5MaW5r IFNvZnR3YXJlAgIEjzAJBgUrDgMCGgUAoIIBfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xMzAzMDQyMDM4MzlaMCMGCSqGSIb3DQEJBDEWBBSgL19momE4 iSm/B0qH8YbJM+etezBWBgkrBgEEAYI3EAQxSTBHMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZQICBI8wWAYLKoZI hvcNAQkQAgsxSaBHMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNvZnR3YXJlIExvY2FsIENBMRow GAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZQICBI8wbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQArgUCm 62Nq0gg/q0LczuPzE21zr1JGSjW5ttURpwYXQeYpDLffiLc2gWgpWXIz55Xhf/uGHmKYDltm NvDd6Q52bYr8zDXxzo2I27joUZF51Y3tjGe9wGotVkRwqIyR3rSzAbD0vdV1RKdwYyyK/jbK fwcTt9j2Rr7jAlFHmZmwxQt4B2/pgiMt5C75wz+XNZYjgeDNluwWe85M3RYt45C++HsixIti RO8YVRPJ7m528j+vLxBrbLo7ag8lqf/bb8FZ+LID4iyK/RMiihFAQvxG6QaycKmtjYXGhu/u bQG7Xr6P0iHKeXavUflvpObA/gN1vICScB4KRLFpbW5TgNEoAAAAAAAA --------------ms010000030908050408010809-- From barryleiba.mailing.lists@gmail.com Mon Mar 4 12:41:30 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6937721F8FD1 for ; Mon, 4 Mar 2013 12:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNklA8iBd0Hf for ; Mon, 4 Mar 2013 12:41:30 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id D635A21F8FDF for ; Mon, 4 Mar 2013 12:41:27 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id b10so5182307vea.30 for ; Mon, 04 Mar 2013 12:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=m1gILr0TnadwWMe+OoXXp57wAIMQiNgulMGGEKqYghQ=; b=Hz5PMEptM7vgBjICjI6EXsnknp2QIEOAlPL8EkgdO9G+a4ZWVgeCwN/ZbEHJPtLpJT PXdXtsiGDgUcjSK/KmoS45OiMGvlbV1d3tNpPWatcBMgmkRJ0uO1STnctMhJbHGEf2rT krJIo/BFsghMq4AFKsOzlVFPVOKETygHh6s8Q3+cr9XjWU8gP8a3WGoHFqPG46qXcJWN XWrTI9TWaEBKcgwNLve8xEkPBchuQOeXpXbmLcgfU85bUWblgoTZXVj7wKtIJum618Iu a9RyU7ZJ1h7VXFxTLcNAWgeIOyeYo1WODZxN4lAqyQ3eP0w66nTDRBv+YQwLvh3qtt5A ukqQ== MIME-Version: 1.0 X-Received: by 10.52.72.40 with SMTP id a8mr7483271vdv.20.1362429687344; Mon, 04 Mar 2013 12:41:27 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Mon, 4 Mar 2013 12:41:27 -0800 (PST) In-Reply-To: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> References: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> Date: Mon, 4 Mar 2013 15:41:27 -0500 X-Google-Sender-Auth: qCVTuM2makYvk6Aswx7e3XOd38k Message-ID: From: Barry Leiba To: "webfinger@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [webfinger] Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:41:30 -0000 Reflecting this here, for the record. On Mon, Mar 4, 2013 at 3:24 PM, The IESG wrote: > > The IESG has received a request from the Applications Area Working Group > WG (appsawg) to consider the following document: > - 'WebFinger' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-03-18. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > 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. WebFinger discovers > information for a URI that might not be usable as a locator > otherwise, such as account or email URIs. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From paulej@packetizer.com Mon Mar 4 15:06:57 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9A411E80A4 for ; Mon, 4 Mar 2013 15:06:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-YMDAOmKqSa for ; Mon, 4 Mar 2013 15:06:56 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 79A2B21F87FF for ; Mon, 4 Mar 2013 15:06:56 -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 r24N6sIp027976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Mar 2013 18:06:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1362438415; bh=uBHQYF1JJXxr0QR2g5LyQgFMqlA2K/0Cnj1amBGrSTw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=oulCOYS4VfvA5gcvPr8y8d70EC7EKmIVEOj+3TqDVEsA1SOXLxc+f0c7femNwyObD i0tXg+3nGLBjMiVI86Vr1hdpLSmFdjAJ54hdf0VF0TrVybIKBYWh9WA3oLWh4ywK3/ 0OreAe+S9LCAHkDaedteRxHmKOxp7BHE8GtYa0+0= From: "Paul E. Jones" To: "'Kingsley Idehen'" , References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> <027d01ce1912$f4f166d0$ded43470$@packetizer.com> <5135064F.3070302@openlinksw.com> In-Reply-To: <5135064F.3070302@openlinksw.com> Date: Mon, 4 Mar 2013 18:07:07 -0500 Message-ID: <032101ce192c$fec48330$fc4d8990$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0322_01CE1903.15F028E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKLwL0A+sqSEHWydlpfat7K30q9TwJhGAQWAj0fvb8C7TvUApbecKkA Content-Language: en-us Cc: webfinger@googlegroups.com Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 23:06:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0322_01CE1903.15F028E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Kingsley, =20 A property consists of a name and value. The name of the property is a = URI. The value is defined by whatever defines the property name. = Presently, there are no properties defined in the WF spec. Only the = syntax is defined. An example of a property is: =20 "http://packetizer.com/ns/name" : "Paul E. Jones", ----------------------------- ------------- | | Property Name Property Value =20 What I was asking is whether we want to define a registry for property = names. For example, perhaps urn:ietf:params:webfinger: = or something. =20 Paul =20 =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Kingsley Idehen Sent: Monday, March 04, 2013 3:39 PM To: webfinger@ietf.org Subject: Re: [webfinger] Properties in WebFinger =20 On 3/4/13 3:00 PM, Paul E. Jones wrote: Melvin, =20 A Property UI is just a =E2=80=9Cname=E2=80=9D, so it names no = difference if it were a URN an HTTP URI or HTTPS URI. You mean a property name is just a URI? And that a URI just names the = property?=20 If the above is true, then there's a subtlety that's being overlooked if = the URI in question resolves to content the describes its referent i.e., = the content can take the form of an entity relationship graph = representing human- and machine-comprehensible entity relationship = semantics.=20 Simple example: a URI denoting a property that's inversefunctional in = nature e.g., the semantics of an property that associates one of more = Agent URIs with an Email Address (mailto: scheme URI).=20 Links: 1. http://bit.ly/Y6TIfs -- how entity relationship semantics enable = identity reconciliation . Kingsley=20 =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Melvin Carvalho Sent: Monday, March 04, 2013 12:13 PM To: webfinger@googlegroups.com Cc: webfinger@ietf.org Subject: Re: [webfinger] Properties in WebFinger =20 =20 On 4 March 2013 17:56, Paul E. Jones wrote: Folks, =20 One of the features in WebFinger is the ability to define = =E2=80=9Cproperties=E2=80=9D related to either a subject or a link. =20 I would expect properties defined for a link to be defined as a part of = the link relation definition. =20 Properties that relate to the subject would be defined in separate RFCs = or could be defined by other SDOs or anyone else, as properties are = always fully-qualified URIs. =20 As an example, consider the following example: =20 "properties" : { "http://packetizer.com/ns/name" : "Paul E. Jones", "http://packetizer.com/ns/name#zh-CN" : = "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF" } Very minor comment, would it not be better to put the properties under = HTTPS? =20 =20 The =E2=80=9Cname=E2=80=9D property is intended to convey the = subject=E2=80=99s name with an optional language tag as a URI fragment. = This is not defined anywhere, except here: http://packetizer.com/ns/name =20 A question to the group is this: do we need to define a registry for = property values defined for a subject? The current WF spec does not = define a registry. Would we want to define one? If so, should that go = into the current draft? (I appreciate that this has gone to Last Call, = so I=E2=80=99ll apologize for not raising this before.) If we did, what = would the URIs look like? Does the IETF or IANA have a URI defined for = this sort of thing? =20 Paul =20 --=20 =20 ---=20 You received this message because you are subscribed to the Google = Groups "WebFinger" group. To unsubscribe from this group and stop receiving emails from it, send = an email to webfinger+unsubscribe@googlegroups.com = . For more options, visit https://groups.google.com/groups/opt_out. =20 =20 =20 _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger --=20 =20 Regards, =20 Kingsley Idehen =20 Founder & CEO=20 OpenLink Software =20 Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen =20 =20 =20 =20 ------=_NextPart_000_0322_01CE1903.15F028E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Kingsley,

 

A property consists of a name and value.=C2=A0 The name of the = property is a URI.=C2=A0 The value is defined by whatever defines the = property name. =C2=A0Presently, there are no properties defined in the = WF spec.=C2=A0 Only the syntax is defined.=C2=A0 An example of a = property is:

 

=C2=A0 = "http://packetizer.com/ns/name" : "Paul E. = Jones",

=C2=A0 = =C2=A0-----------------------------=C2=A0=C2=A0 = =C2=A0=C2=A0-------------

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Property = Name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0Property Value

 

What I was asking is whether we want to define a registry for = property names.=C2=A0 For example, perhaps = urn:ietf:params:webfinger:<property_name> or = something.

 

Paul

 

 

From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of Kingsley Idehen
Sent: Monday, March 04, = 2013 3:39 PM
To: webfinger@ietf.org
Subject: Re: = [webfinger] Properties in WebFinger

 

On = 3/4/13 3:00 PM, Paul E. Jones wrote:

Melvin,

 

A Property UI is just a =E2=80=9Cname=E2=80=9D, so it names no = difference if it were a URN an HTTP URI or HTTPS = URI.


You mean = a property name is just a URI? And that a URI just names the property? =

If the above is true, then there's a subtlety that's being = overlooked if the URI in question resolves to content the describes its = referent i.e., the content can take the form of an entity relationship = graph representing human- and machine-comprehensible entity relationship = semantics.

Simple example: a URI denoting a property that's = inversefunctional in nature e.g., the semantics of an property that = associates one of more Agent URIs with an Email Address (mailto: scheme = URI).

Links:

1. http://bit.ly/Y6TIfs -- how entity = relationship semantics enable identity reconciliation .

Kingsley =

 

Paul

 

From:= = webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.= org] On Behalf Of Melvin Carvalho
Sent: Monday, = March 04, 2013 12:13 PM
To: webfinger@googlegroups.com=
Cc: webfinger@ietf.org
Subject:<= /b> Re: [webfinger] Properties in = WebFinger

 

 

On 4 March 2013 17:56, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

One of the = features in WebFinger is the ability to define = =E2=80=9Cproperties=E2=80=9D related to either a subject or a = link.

 <= /o:p>

I would = expect properties defined for a link to be defined as a part of the link = relation definition.

 <= /o:p>

Properties = that relate to the subject would be defined in separate RFCs or could be = defined by other SDOs or anyone else, as properties are always = fully-qualified URIs.

 <= /o:p>

As an = example, consider the following example:

 <= /o:p>

  = "properties" :

  = {

    "http://packetizer.com/ns/name" : "Paul = E. Jones",

    "http://packetizer.com/ns/name#zh-CN" : = "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF"

  = }


Very = minor comment, would it not be better to put the properties under = HTTPS?
 

 <= /o:p>

The = =E2=80=9Cname=E2=80=9D property is intended to convey the = subject=E2=80=99s name with an optional language tag as a URI = fragment.  This is not defined anywhere, except here: http://packetizer.com/ns/name

=

 <= /o:p>

A question = to the group is this: do we need to define a registry for property = values defined for a subject?  The current WF spec does not define = a registry.  Would we want to define one?  If so, should that = go into the current draft?  (I appreciate that this has gone to = Last Call, so I=E2=80=99ll apologize for not raising this before.)  = If we did, what would the URIs look like?  Does the IETF or IANA = have a URI defined for this sort of thing?

 

Paul

 

-- =
 
--- =
You received this message because you = are subscribed to the Google Groups "WebFinger" = group.
To unsubscribe from this group and = stop receiving emails from it, send an email to webfinger+unsubscribe@googlegroups.com.
<= span class=3Dhoenzb>For more options, visit https://groups.google.com/groups/opt_out. 
 

 




_______________________=
________________________
webfinger mailing =
list
webfinger@ietf.org
https://www.ietf=
.org/mailman/listinfo/webfinger



-- =

 
Regards,
 
Kingsley =
Idehen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
Founder & CEO =

OpenLink Software=C2=A0=C2=A0=C2=A0=C2=A0 =

Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.co=
m/blog/~kidehen
Twitter/Identi.ca handle: =
@kidehen
Google+ Profile: https://plus=
.google.com/112399767740508618350/about
LinkedIn=
 Profile: http://www.linkedin.com/in/ki=
dehen
 
 
 
 
------=_NextPart_000_0322_01CE1903.15F028E0-- From paulej@packetizer.com Mon Mar 4 20:17:10 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D0021F88A0 for ; Mon, 4 Mar 2013 20:17:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cl5UXgswHlx for ; Mon, 4 Mar 2013 20:17:08 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 96F4F21F88A9 for ; Mon, 4 Mar 2013 20:17:08 -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 r254Gska009706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Mar 2013 23:16:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1362457015; bh=JdPqGWrgKVWJ4z5aHB3GxEyIHfdc3baiP4jfXNsGNx4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=kaw1i4JwZ/rHJ44qW2bxvxUkYlHHw/sX/h516WbBU5GYPYDoIey8B8HygFyOwCZSJ GwcAlWH5hY7d7cR0NbY4m6kEQ/dVpY9rWf1I0CdLvigWUnTUTomvKh8B2tpETkQula xYsw1+I08i75iDr9GRILfEaFkFAKRujKkplHXHR8= From: "Paul E. Jones" To: "'Barry Leiba'" , References: In-Reply-To: Date: Mon, 4 Mar 2013 23:17:07 -0500 Message-ID: <042301ce1958$4d645300$e82cf900$@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: AQExkTgDUTpY/I7mKftWoDOFy68nMZnPcZlw Content-Language: en-us Subject: Re: [webfinger] AD review of draft-ietf-appsawg-webfinger-10 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 04:17:10 -0000 Barry, > Document editors: please respond as appropriate to my comments, and then > on next Monday, when I-D submissions are open again, post an -11 version > with whatever updates you have at that point. OK. I'll reply below and make edits as requested. > --------------------------------------------- > One significant issue: > > In Section 4.3: > In the event that a client requests link relation types that are not > defined for the specified "resource", a resource descriptor MUST be > returned. In the returned JRD, the "links" array MAY be absent, > empty, or contain only links that did match a provided "rel" value. > > I don't understand what this is trying to tell me to do, if I'm > implementing a WebFinger resource and I get inappropriate "rel" > values. I'm guessing that this is what you want, but this text doesn't > make that clear at all: > > 1. Ignore all "rel" values that contain link relation types that are not > defined for the specified resource. > 2. If there are other "rel" values left, filter on them as though they > were the only ones present. > 3. If there are *no* other "rel" values left, do *not* return an > unfiltered JRD. Instead, either: > 3a. ...return a JRD with an empty "links" array ("links" : [ ]), or > 3b. ...return a JRD with no "links" array present at all. > > Is there a reason to allow both 3a and 3b, rather than specifying one or > the other? > > In any case, please re-word this paragraph so it says clearly what you > want it to say. Your interpretation is correct. The reason for allowing either an empty array or a JRD with the links array absent is that there is no semantic difference. If we say that the array must be absent, someone may still return an empty array. Likewise, if we say the array must be empty, someone might still leave it out entirely. I can appreciate how this might happen based on how the serialization routines are written. I have no strong preference one way or the other, but I'd prefer to treat absent/empty as equal and expect either. Considering the specific paragraph in question, the previous text explains how the server filters the request with respect to the "rel" parameter. So, what I would propose to modify the first paragraph of 4.3 as shown (taking the above and below comments into account): When issuing a request to a WebFinger resource, the client MAY utilize the "rel" parameter to request only a subset of the information that would otherwise be returned without the "rel" parameter. When the "rel" parameter is used and accepted, only the link relation types that match the link relation types provided via the "rel" parameter are included in the array of links returned in the JRD. If there are no matching link relation types defined for the resource, the "links" array in the JRD will either be absent or empty. All other information present in a resource descriptor remains present, even when "rel" is employed. Then I propose to delete the last paragraph of 4.3 entirely. > --------------------------------------------- > Other minor comments: > > In the last paragraph of Section 3.2, you have "OPTIONAL". The 2119 > keyword is out of place in this non-normative example. Besides: it's > not optional; it's a "SHOULD support". So, really, change "is OPTIONAL" > to "is not guaranteed". Done. > In the first paragraph of Section 4, to be consistent with how you > render things later, you should probably make these changes (and then > make sure your use of this is consistent throughout the document): > > using the HTTPS scheme => using the "https" scheme > > other URI scheme (such as HTTP) ==> other URI scheme (such as "http") > > In Section 4: > GET requests to a WebFinger resource convey the URI to perform the > query upon in the URI's query string; see Section 4.1 for details. > > First, I find this to be an awkward, with two different URIs not clearly > differentiated. Second, Section 4.1 doesn't actually give details of > the "URI to perform the query upon". Maybe this?: > > NEW > A WebFinger resource is always given a query target, which is > another URI that identifies the entity whose information is > sought. GET requests to a WebFinger resource convey the query > target in the "resource" parameter in the WebFinger URI's query > string; see Section 4.1 for details. > END That works for me. > In Section 4.1: > First, each parameter value is percent-encoded, as > per Section 2.1 of RFC 3986, so that it conforms to the query > production in Section 3.4 of that specification, and additionally any > instances of the "=" and "&" characters are also percent-encoded. > > I think this would be a bit clearer this way: > > NEW > First, each parameter value is percent-encoded, as > per Section 2.1 of RFC 3986. The encoding is done to conform to > the query production in Section 3.4 of that specification, with the > addition that any instances of the "=" and "&" characters within the > parameter value are also percent-encoded. > END OK > I think that will avoid anyone's trying to encode the "=" in "resource=", > and the like. > > The order in which the client places each > attribute-and-value pair within the query component is unspecified. > > Is that really trying to say that the order has to be treated as > insignificant when the query component is interpreted? If so, it should > say it that way: > > NEW > The order in which the client places each > attribute-and-value pair within the query component does not matter > in the interpretation of the query component. > END Correct interpretation. Changed. > In Section 4.2: > The client MAY include the "Accept" > header to indicate a desired representation, though no other > representation than JRD is defined in this specification. > > I think I might prefer this: > > NEW > The client MAY include the "Accept" > header to indicate a desired representation; representations > other than JRD might be defined in future specifications. The > WebFinger resource MUST silently ignore any requested > representations that it does not understand and support. > END Done. > A WebFinger resource MAY redirect the client, but MUST only redirect > the client to an HTTPS URI. > > I don't think this will actually be misinterpreted, but just to be clear > about the MAY/MUST thing: > > NEW > A WebFinger resource MAY redirect the client; if it does, the > redirection MUST only be to an "https" URI. > END Done. > In Section 4.3: > When the "rel" parameter is used, only the link relations > that match the link relations provided via the "rel" parameter are > included in the array of links returned in the JRD. > > Not when it's *used* -- it can be used, but the resource might not > support it, right? So: > > NEW > When the "rel" parameter is used and accepted, only the link > relations that match the link relations provided via the "rel" > parameter are included in the array of links returned in the JRD. > END Done, and also modified as discussed above. > The "rel" parameter MAY be transmitted to the WebFinger resource > multiple times in order to request multiple types of link relations. > > Does this really mean this?: > > NEW > The "rel" parameter MAY be included in the query component of the > WebFinger URI multiple times in order to request multiple types of > link relations. > END > > Actually, I think "in the query component of the WebFinger URI" can be > removed, to just say, "MAY be included multiple times". Done. To be clearer, I suggest switching moving types to the end as: The "rel" parameter MAY be included multiple times in order to request multiple link relation types. > In Section 4.4, you've hit a pedantic pet peeve of mine that's a lost > cause that I still fight: > > a JSON object that is comprised of the following > > Correctly, the whole "comprises" the parts (or "is composed of", but not > "is comprised of"). > > NEW > a JSON object that comprises the following END Done. > And similarly in the following paragraph and in Sections 4.4.3, 4.4.4.4, > and 4.4.4.5. Done. > In Section 4.5: > WebFinger requests can include a "resource" parameter (see Section > 4.1) specifying the URI of an account, device, or other entity. > > Not "can include"; they do include it: Section 4.2 says that the 'query > component MUST include the "resource" parameter exactly once'. Indeed. Removed "can". > To perform a WebFinger lookup on an account specific to the host > being queried, use of the "acct" URI scheme is RECOMMENDED, since it > explicitly identifies an account accessible via WebFinger. > > I'm racking my brain, trying to decide whether this is an appropriate > 2119 "RECOMMENDED", which means "SHOULD", which means that there's an > interoperability reason why you must do this unless you fully understand > the consequences of not doing it. > > If what you're saying is that "acct" is always guaranteed to work, while > others, such as "mailto" are crap shoots, then I think "RECOMMENDED" is > OK. But if they all might or might not work, and we're just saying that > "acct" was made for this and we're encouraging its use and it's the best > of the bunch, then that's not a 2119 "RECOMMENDED". > > So can you clarify this for me (in email; don't change the text yet)? The use of the word RECOMMENDED was to encourage, but not mandate, use of the acct URI scheme when querying for information about a user's account. Personally, I would be OK with mandating use of "acct" when querying for information about a user's account, but I think we all agree that using "mailto" or any other scheme is acceptable depending on the nature of the information sought. For example, if I want to find out information about one's email service, then "mailto" might be the appropriate URI to use. I'll revise according to your next instructions. > In Section 6: > As with all web resources, access to the WebFinger resource MAY > require authentication. Further, failure to provide required > credentials MAY result in the server forbidding access or providing a > different response than had the client authenticated with the server. > > Neither of these "MAY"s is an appropriate 2119 key word. "MAY" means > "this is a completely optional choice". The WebFinger resource will > either require authentication or it won't, but that's not a MAY sort of > choice for anyone. Make both of them "may", or perhaps "might" or > "could". Done. > Just as a contrast, the MAY in the second paragraph is fine, because it > really is describing a choice that the resource can make, at its option. > > In the third paragraph, it's less clear. Given the example you use, I'd > remove the "MAY". But I'm not going to beat you with truncheons about > that one. Changed to "might". > In Section 8: > On the two paragraphs about private/personal information, I suggest > explicitly passing that by Alissa Cooper for review and comment, if you > haven't already. OK, I will do that. > Section 9.1: > It would be good to explicitly request review on the review@ietf.org> mailing list now. That could save time for the > formality later. I'll send an email to request a review. Thanks, Paul From barryleiba@gmail.com Tue Mar 5 05:31:10 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C015821F8750 for ; Tue, 5 Mar 2013 05:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VC9PQlCR+9Q for ; Tue, 5 Mar 2013 05:31:10 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0A71621F8739 for ; Tue, 5 Mar 2013 05:31:09 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id fs12so6183047lab.11 for ; Tue, 05 Mar 2013 05:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ekwN1zyRO/AuNU78UiDZKdd6u6fRFgb0Ary6M8Z3+EM=; b=BC3S7FVpj7jEKxVLATyL2UmF7NQTZhVerJfTmp+Jnj7XPTiC0MeIKScAguRFTr8POU IO3RHYRrrM3hsmUlAKIXf/pM+uLxxo8Lz5QlklKhd+iYKeEGcGKWqe678uhR+XtuZaoM KYstPm6YCbGwgyttTBya0KgYdilQ6+1r6Bwo/x5SyL7s+KiW07ByE67tumMbpU1LacrS 2E3A6SRYjHWy+57ioiiTX9/vcfs5yilyBd2mSIvgOMvN0F8rTO+xVz2Xv52nFIkFGd3X MHaSD/gUMj/V7uY42FiW5R5h9RV+qH+fIfYhpUde/0XP2BKAOGpmhl1EZGx7TMSdqvvU iqsA== MIME-Version: 1.0 X-Received: by 10.112.83.133 with SMTP id q5mr5998770lby.25.1362490268800; Tue, 05 Mar 2013 05:31:08 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.76.98 with HTTP; Tue, 5 Mar 2013 05:31:07 -0800 (PST) In-Reply-To: <042301ce1958$4d645300$e82cf900$@packetizer.com> References: <042301ce1958$4d645300$e82cf900$@packetizer.com> Date: Tue, 5 Mar 2013 08:31:07 -0500 X-Google-Sender-Auth: ucat9BLopy7ZCGpg71MvW0nYFds Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: "webfinger@ietf.org" Subject: Re: [webfinger] AD review of draft-ietf-appsawg-webfinger-10 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 13:31:10 -0000 Thanks for the quick response, Paul. Summary: everything looks good here. > Your interpretation is correct. The reason for allowing either an empty > array or a JRD with the links array absent is that there is no semantic > difference. If we say that the array must be absent, someone may still > return an empty array. Likewise, if we say the array must be empty, someone > might still leave it out entirely. I can appreciate how this might happen > based on how the serialization routines are written. I have no strong > preference one way or the other, but I'd prefer to treat absent/empty as > equal and expect either. Ack; that's fine, and thanks for the explanation. >> To perform a WebFinger lookup on an account specific to the host >> being queried, use of the "acct" URI scheme is RECOMMENDED, since it >> explicitly identifies an account accessible via WebFinger. ... >> I'm racking my brain, trying to decide whether this is an appropriate >> If what you're saying is that "acct" is always guaranteed to work, while >> others, such as "mailto" are crap shoots, then I think "RECOMMENDED" is >> OK. But if they all might or might not work, and we're just saying that >> "acct" was made for this and we're encouraging its use and it's the best >> of the bunch, then that's not a 2119 "RECOMMENDED". ... > The use of the word RECOMMENDED was to encourage, but not mandate, use of > the acct URI scheme when querying for information about a user's account. > Personally, I would be OK with mandating use of "acct" when querying for > information about a user's account, but I think we all agree that using > "mailto" or any other scheme is acceptable depending on the nature of the > information sought. For example, if I want to find out information about > one's email service, then "mailto" might be the appropriate URI to use. Why not change "RECOMMENDED" to "strongly encouraged", then? (Or I gather you mean to make it "recommended", which will be fine as well.) Barry From paulej@packetizer.com Tue Mar 5 23:34:14 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FA721F856D for ; Tue, 5 Mar 2013 23:34:14 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX12O3VkWQUT for ; Tue, 5 Mar 2013 23:34:13 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD8121F854E for ; Tue, 5 Mar 2013 23:34: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 r267Y9cc002830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Mar 2013 02:34:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1362555249; bh=tQfP4wRDSY2NeTHO6eV1+yoJiRTggPp3vso0yU3pDX8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=EOg1OqP1AYwhhZqaqdsSvbOXAaeG8Hra8Pz88flGhSuBt5ALI/8i+dajCU2RGarrb tde7o0J50FymNYfXfE16IDSZHLDm960ZWu51W/Ys56kJGo2PeULHY/t2FvZtNqC8x6 QCs/VCOC7c7QY7a8hYdSuqiDAW3D1usJ/z3DzoqM= From: "Paul E. Jones" To: "'Barry Leiba'" References: <042301ce1958$4d645300$e82cf900$@packetizer.com> In-Reply-To: Date: Wed, 6 Mar 2013 02:34:19 -0500 Message-ID: <008001ce1a3d$03c74000$0b55c000$@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: AQExkTgDUTpY/I7mKftWoDOFy68nMQI08qslAhsCQmmZrtfC0A== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] AD review of draft-ietf-appsawg-webfinger-10 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 07:34:14 -0000 Barry, > Thanks for the quick response, Paul. Summary: everything looks good > here. Great! > >> To perform a WebFinger lookup on an account specific to the host > >> being queried, use of the "acct" URI scheme is RECOMMENDED, since > it > >> explicitly identifies an account accessible via WebFinger. > ... > >> I'm racking my brain, trying to decide whether this is an appropriate > >> If what you're saying is that "acct" is always guaranteed to work, > >> while others, such as "mailto" are crap shoots, then I think > >> "RECOMMENDED" is OK. But if they all might or might not work, and > >> we're just saying that "acct" was made for this and we're encouraging > >> its use and it's the best of the bunch, then that's not a 2119 > "RECOMMENDED". > ... > > The use of the word RECOMMENDED was to encourage, but not mandate, use > > of the acct URI scheme when querying for information about a user's > account. > > Personally, I would be OK with mandating use of "acct" when querying > > for information about a user's account, but I think we all agree that > > using "mailto" or any other scheme is acceptable depending on the > > nature of the information sought. For example, if I want to find out > > information about one's email service, then "mailto" might be the > appropriate URI to use. > > Why not change "RECOMMENDED" to "strongly encouraged", then? (Or I > gather you mean to make it "recommended", which will be fine as well.) I'll got with lowercase. Paul From bcampbell@pingidentity.com Tue Mar 5 09:02:29 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A793E1F0D10 for ; Tue, 5 Mar 2013 09:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmXfOSmAfTYN for ; Tue, 5 Mar 2013 09:02:28 -0800 (PST) Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) by ietfa.amsl.com (Postfix) with ESMTP id A57601F0D08 for ; Tue, 5 Mar 2013 09:02:28 -0800 (PST) Received: from mail-ia0-f198.google.com ([209.85.210.198]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKUTYlJOTWcx3t6+VRdpDs1qZ8uxc9c9lY@postini.com; Tue, 05 Mar 2013 09:02:28 PST Received: by mail-ia0-f198.google.com with SMTP id k38so3787367iah.5 for ; Tue, 05 Mar 2013 09:02:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Gn2hM53Y85+VGdUd7Rb7RHuSy1F7fbAdmdQ3V4bx4IA=; b=CCYU6DYlJ1UX5myKP3XJoE/5mO2WAB7WgpSnwCXV64daWeRbEzoBofbeLOSkG+taGh X3hmQ67UhiTX4WI7Wg8hfQjuVKZD59PgAgM13aOXwWS6H/X+aCjiLMwOY+wqFzheD0Ix jCFJO0LP/tpbIskMLqXNaL4kAi/M7PsI8//c53YAekqGVsBJ6RaK+QhxviM5doxzaxtb H7h6vsarP2YGKcJXFFVDV8MEV/Ww6aQm1Joxw9zMEEcYDF1R1a4DlEuJeAG+p6tkDscF vY2Cl2lVlGU/1YxBWe1UqmNIoVVCok6TV27bA9ME+2mJXJQFZS5UpqfQlmSh4CJsW0r7 6iYQ== X-Received: by 10.50.37.236 with SMTP id b12mr6840787igk.42.1362502948003; Tue, 05 Mar 2013 09:02:28 -0800 (PST) X-Received: by 10.50.37.236 with SMTP id b12mr6840776igk.42.1362502947880; Tue, 05 Mar 2013 09:02:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Tue, 5 Mar 2013 09:01:57 -0800 (PST) In-Reply-To: <3AE8D8EF-714C-4F6A-9B50-433AA2500C06@oracle.com> References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> <3AE8D8EF-714C-4F6A-9B50-433AA2500C06@oracle.com> From: Brian Campbell Date: Tue, 5 Mar 2013 10:01:57 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=f46d044788d936dc7804d7307037 X-Gm-Message-State: ALoCoQljEkm8GxR89b5+O9smC8i0n3sDN09csu+KC36xnpEnTZuOcNEJXX7ENPln8uDCkfDyI0XnteZJ5QG7/ReSUOCpwiw5pM5zxsr4g/TunAQWx1zp2JKD3SYv9c7Tgj5YHq5x2jhNz/GX35EGVpbVJn5AgF9LkA== X-Mailman-Approved-At: Wed, 06 Mar 2013 08:46:20 -0800 Cc: Anthony Nadalin , Group Group , "openid-connect-interop@googlegroups.com" , "" , John Bradley , "webfinger@ietf.org" , Barry Leiba , "oauth@ietf.org WG" Subject: Re: [webfinger] [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 17:02:29 -0000 --f46d044788d936dc7804d7307037 Content-Type: text/plain; charset=ISO-8859-1 Likewise, I'll be arriving in Orlando ~3:30pm, if there's anything happening later in the afternoon/evening? On Sat, Mar 2, 2013 at 5:19 PM, Phil Hunt wrote: > I should be in orlando at 7:30ish if anything is happening in the evening. > > Phil > > Sent from my phone. > > On 2013-03-02, at 16:12, Anthony Nadalin wrote: > > > I thought it was Sunday > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Barry Leiba > > Sent: Saturday, March 2, 2013 11:58 AM > > To: John Bradley > > Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.orgWG; < > jose@ietf.org>; webfinger@ietf.org > > Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID > Connect at IETF#86 in Sun Mar 10 > > > >> The eventbrite page for people wanting to attend the openID Connect > >> session prior to IETF86 is now available at: > >> http://openid-ietf-86.eventbrite.com/ > > > > That page says this: > > OpenID Meeting at IETF 86 > > The OpenID Foundation > > Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) > > Orlando, FL > > > > I do hope it means Thursday, 7 March. 11 April is about a month > > *after* the IETF meeting. > > > > Barry > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --f46d044788d936dc7804d7307037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Likewise, I'll be arriving in Orlando ~3:30pm, if ther= e's anything happening later in the afternoon/evening?


On Sat, Mar 2, 2013 = at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
I should be in orlando at 7:30ish if anythin= g is happening in the evening.

Phil

Sent from my phone.

On 2013-03-02, at 16:12, Anthony Nadalin <tonynad@microsoft.com> wrote:

> I thought it was Sunday
>
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Barry Leiba
> Sent: Saturday, March 2, 2013 11:58 AM
> To: John Bradley
> Cc: openid-= connect-interop@googlegroups.com; Group Group; oauth@ietf.org WG; <jose@= ietf.org>; webfinger@ietf.org<= /a>
> Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID= Connect at IETF#86 in Sun Mar 10
>
>> The eventbrite page for people wanting to attend the openID Connec= t
>> session prior to IETF86 is now available at:
>> http://openid-ietf-86.eventbrite.com/
>
> That page says this:
> =A0 OpenID Meeting at IETF 86
> =A0 The OpenID Foundation
> =A0 Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT)
> =A0 Orlando, FL
>
> I do hope it means Thursday, 7 March. =A011 April is about a month
> *after* the IETF meeting.
>
> Barry
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_____________________________= __________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--f46d044788d936dc7804d7307037-- From paulej@packetizer.com Sun Mar 10 20:21:45 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDF821F8952 for ; Sun, 10 Mar 2013 20:21:45 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkTy02hFgkhk for ; Sun, 10 Mar 2013 20:21:44 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C578C21F892B for ; Sun, 10 Mar 2013 20:21:43 -0700 (PDT) Received: from [192.168.254.248] ([216.189.219.66]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r2B3LYt4003050 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 10 Mar 2013 23:21:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1362972102; bh=ySPK6o/vm9RJGN4YxVxeXpJ4WHl69xQGTLFcjgKlEHc=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=gJ3XhzI8hNOC0Hxes7DvW/TZ0b786+jSmdQS3patAm1k5pBQBKLcxY62v/p08ANGQ tdMesoCT6RSYmMnk9OB5/V9Yt8P7WL7d5SXKs4C4HJjzUOaZwCvYb2dbuGxWx37YAo ZNkBy+fGM9xt5rvxVQWq/wbiMHQukEn5TiOR+9f0= Message-ID: <513D4DCA.3070308@packetizer.com> Date: Sun, 10 Mar 2013 23:21:46 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: webfinger@ietf.org, "webfinger@googlegroups.com" References: <20130311031809.1719.63660.idtracker@ietfa.amsl.com> In-Reply-To: <20130311031809.1719.63660.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130311031809.1719.63660.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020204000709050400080707" Subject: [webfinger] Fwd: I-D Action: draft-ietf-appsawg-webfinger-11.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 03:21:45 -0000 This is a multi-part message in MIME format. --------------020204000709050400080707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. New draft is posted that should include all of the changes Barry recommended. Paul -------- Original Message -------- Subject: I-D Action: draft-ietf-appsawg-webfinger-11.txt Date: Sun, 10 Mar 2013 20:18:09 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: apps-discuss@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-11.txt Pages : 22 Date : 2013-03-10 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. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------020204000709050400080707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.  New draft is posted that should include all of the changes Barry recommended.

Paul

-------- Original Message --------
Subject: I-D Action: draft-ietf-appsawg-webfinger-11.txt
Date: Sun, 10 Mar 2013 20:18:09 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: apps-discuss@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : WebFinger
	Author(s)       : Paul E. Jones
                          Gonzalo Salgueiro
                          Joseph Smarr
	Filename        : draft-ietf-appsawg-webfinger-11.txt
	Pages           : 22
	Date            : 2013-03-10

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.  WebFinger discovers
   information for a URI that might not be usable as a locator
   otherwise, such as account or email URIs.


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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-11


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--------------020204000709050400080707-- From Michael.Jones@microsoft.com Mon Mar 11 03:36:22 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F2021F86D4 for ; Mon, 11 Mar 2013 03:36:22 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDOBATyyz7qF for ; Mon, 11 Mar 2013 03:36:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC2F21F86FB for ; Mon, 11 Mar 2013 03:36:21 -0700 (PDT) Received: from BY2FFO11FD005.protection.gbl (10.1.15.200) by BY2FFO11HUB023.protection.gbl (10.1.14.110) with Microsoft SMTP Server (TLS) id 15.0.620.12; Mon, 11 Mar 2013 10:36:18 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Mon, 11 Mar 2013 10:36:18 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Mon, 11 Mar 2013 10:35:54 +0000 From: Mike Jones To: "Paul E. Jones" , "webfinger@ietf.org" , "webfinger@googlegroups.com" Thread-Topic: [webfinger] Fwd: I-D Action: draft-ietf-appsawg-webfinger-11.txt Thread-Index: AQHOHgeSZPAfQBVjyEq3uvyBRHeM1JigTCxg Date: Mon, 11 Mar 2013 10:35:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674ECEEE@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130311031809.1719.63660.idtracker@ietfa.amsl.com> <513D4DCA.3070308@packetizer.com> In-Reply-To: <513D4DCA.3070308@packetizer.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_4E1F6AAD24975D4BA5B1680429673943674ECEEETK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(43784002)(2473001)(13464002)(69234002)(377454001)(189002)(199002)(377424002)(4396001)(5343655001)(15202345001)(65816001)(512954001)(63696002)(59766001)(54316002)(47736001)(47976001)(49866001)(33656001)(66066001)(69226001)(44976002)(79102001)(74502001)(74662001)(56816002)(46102001)(31966008)(55846006)(54356001)(47446002)(53806001)(5343635001)(16236675001)(50986001)(76482001)(51856001)(16406001)(80022001)(77982001)(20776003)(56776001)(24704001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB023; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0782EC617F Subject: Re: [webfinger] Fwd: I-D Action: draft-ietf-appsawg-webfinger-11.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 10:36:22 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674ECEEETK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've read the diffs and agree with all these changes. Thanks again, -- Mike From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Paul E. Jones Sent: Sunday, March 10, 2013 8:22 PM To: webfinger@ietf.org; webfinger@googlegroups.com Subject: [webfinger] Fwd: I-D Action: draft-ietf-appsawg-webfinger-11.txt FYI. New draft is posted that should include all of the changes Barry reco= mmended. Paul -------- Original Message -------- Subject: I-D Action: draft-ietf-appsawg-webfinger-11.txt Date: Sun, 10 Mar 2013 20:18:09 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: apps-discuss@ietf.org 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-11.txt Pages : 22 Date : 2013-03-10 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. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_4E1F6AAD24975D4BA5B1680429673943674ECEEETK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve read the diffs= and agree with all these changes.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks again,

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

 <= /p>

From: webfinger-bounces@ietf.org [mailto:webfinger-boun= ces@ietf.org] On Behalf Of Paul E. Jones
Sent: Sunday, March 10, 2013 8:22 PM
To: webfinger@ietf.org; webfinger@googlegroups.com
Subject: [webfinger] Fwd: I-D Action: draft-ietf-appsawg-webfinger-1= 1.txt

 

FYI.  New draft is posted that should include a= ll of the changes Barry recommended.

Paul


-------- Original Message --------

Subjec= t:

I-D Action: draft-ietf-appsawg-webfinger-11.txt=

Date: =

Sun, 10 Mar 2013 20:18:09 -0700

From: =

internet= -drafts@ietf.org

Reply-= To:

internet= -drafts@ietf.org

To:

i-d-announc= e@ietf.org

CC:

apps-discus= s@ietf.org

 

A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
 This draft is a work item of the Applications Area Working Group Work=
ing Group of the IETF.
 
        Title   &nbs=
p;       : WebFinger
        Author(s)   =
    : Paul E. Jones
           &nbs=
p;            &=
nbsp; Gonzalo Salgueiro
           &nbs=
p;            &=
nbsp; Joseph Smarr
        Filename   &=
nbsp;    : draft-ietf-appsawg-webfinger-11.txt

        Pages   &nbs=
p;       : 22


        Date    =
;        : 2013-03-10


 


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.  WebFinger dis=
covers


   information for a URI that might not be usable as a locat=
or


   otherwise, such as account or email URIs.

 


 


The IETF datatracker status page for this draft is:


https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger<=
/o:p>


 


There's also a htmlized version available at:


http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11<=
/pre>

 


A diff from the previous version is available at:


http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-11=



 


 


Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/int=
ernet-drafts/


 


_______________________________________________


I-D-Announce mailing list


I-D-Announce@ietf.org


https:/=
/www.ietf.org/mailman/listinfo/i-d-announce


Internet-Draft directories: http://www.ietf.org/shadow.html


or ftp://ftp.iet=
f.org/ietf/1shadow-sites.txt


 

 

--_000_4E1F6AAD24975D4BA5B1680429673943674ECEEETK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Mon Mar 11 07:03:12 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69C121F871D for ; Mon, 11 Mar 2013 07:03:12 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKhZCNzjKnVr for ; Mon, 11 Mar 2013 07:03:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4C121F86C4 for ; Mon, 11 Mar 2013 07:03:11 -0700 (PDT) Received: from BY2FFO11FD017.protection.gbl (10.1.15.200) by BY2FFO11HUB035.protection.gbl (10.1.14.119) with Microsoft SMTP Server (TLS) id 15.0.620.12; Mon, 11 Mar 2013 14:03:08 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD017.mail.protection.outlook.com (10.1.14.105) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Mon, 11 Mar 2013 14:03:08 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Mon, 11 Mar 2013 14:02:36 +0000 From: Mike Jones To: Dick Hardt , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: WebFinger link relation types doc Thread-Index: Ac4eYRIyBaDtCOvwRP+irx63WOsw/g== Date: Mon, 11 Mar 2013 14:02:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674F5DCB@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674F5DCBTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(4396001)(16236675001)(59766001)(56776001)(31966008)(47736001)(66066001)(55846006)(46102001)(74502001)(5343635001)(47446002)(51856001)(16406001)(79102001)(44976002)(76482001)(77982001)(20776003)(74662001)(15202345001)(33656001)(5343655001)(65816001)(80022001)(54356001)(63696002)(53806001)(47976001)(49866001)(69226001)(512954001)(56816002)(50986001)(54316002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB035; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0782EC617F Cc: "webfinger@ietf.org" Subject: [webfinger] WebFinger link relation types doc X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 14:03:12 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674F5DCBTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dick, In a previous message you'd said that you and Gonzalo were working on a dra= ft specifying some common link relation types. This came up during the App= lications Area Working Group meeting at the IETF just now. Is the draft re= ady to share with the webfinger mailing list? -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943674F5DCBTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dick,

 

In a previous message you’d said that you and = Gonzalo were working on a draft specifying some common link relation types.=   This came up during the Applications Area Working Group meeting at t= he IETF just now.  Is the draft ready to share with the webfinger mailing list?

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943674F5DCBTK5EX14MBXC283r_-- From sakimura@gmail.com Mon Mar 11 09:09:40 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADB211E811A for ; Mon, 11 Mar 2013 09:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71pNgPVBsxOK for ; Mon, 11 Mar 2013 09:09:39 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 82A6111E80EF for ; Mon, 11 Mar 2013 09:09:38 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ec20so4122587lab.37 for ; Mon, 11 Mar 2013 09:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=p1x/TKz7Va9m/LVtEggBXqWaBLk7cCvDFxeVJKa3PDk=; b=Mx3IdiiyNhHa7a95hG+cn2dtRy3ZzZD3zzkSX0E+nfw10tx8TjiYg7nZF8wgXLQBUz 3S2qXLND75viZuSnYHO5RJhb8+CdUvozPhxMZr1+hqY2gh+9OLTwuUHtW+DKuRPpcam8 cmO8v2Y2G71ESqqF+5A2vq3XvUvXvJWKBXs+uoEUi2pmzEhp4YF1dtwYUWUeHO1Rrc8/ /yXNEaOSkTcX3S7AKSrQOHffmojAze6rKe8Q+rdxj2S4AxKplOgF9cksIOTRGmldofrZ HtxneKV3kZ9uJVd1IFZcpgPyXMc/mfjDQeABW8wWn/jvJn7ZYZN6MWFo1nGgfHzaZlsD dp8Q== MIME-Version: 1.0 X-Received: by 10.152.48.45 with SMTP id i13mr10747439lan.11.1363018177399; Mon, 11 Mar 2013 09:09:37 -0700 (PDT) Received: by 10.112.14.44 with HTTP; Mon, 11 Mar 2013 09:09:37 -0700 (PDT) In-Reply-To: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> Date: Tue, 12 Mar 2013 01:09:37 +0900 Message-ID: From: Nat Sakimura To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec5523b264954f604d7a86634 Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 16:09:40 -0000 --bcaec5523b264954f604d7a86634 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI, this looks very similar to Claims in OpenID Connect. We use language-script tag to express it the same way you do. http://openid.bitbucket.org/openid-connect-messages-1_0.html#StandardClaims JWT defines a registry for public claim names. http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-9.1 Nat 2013/3/5 Paul E. Jones > Folks,**** > > ** ** > > One of the features in WebFinger is the ability to define =E2=80=9Cproper= ties=E2=80=9D > related to either a subject or a link.**** > > ** ** > > I would expect properties defined for a link to be defined as a part of > the link relation definition.**** > > ** ** > > Properties that relate to the subject would be defined in separate RFCs o= r > could be defined by other SDOs or anyone else, as properties are always > fully-qualified URIs.**** > > ** ** > > As an example, consider the following example:**** > > ** ** > > "properties" :**** > > {**** > > "http://packetizer.com/ns/name" : "Paul E. Jones",**** > > "http://packetizer.com/ns/name#zh-CN" : "=E4=BF=9D=E7=BD=97=E2=80=A7= =E7=90=BC=E6=96=AF"**** > > }**** > > ** ** > > The =E2=80=9Cname=E2=80=9D property is intended to convey the subject=E2= =80=99s name with an > optional language tag as a URI fragment. This is not defined anywhere, > except here: http://packetizer.com/ns/name**** > > ** ** > > A question to the group is this: do we need to define a registry for > property values defined for a subject? The current WF spec does not defi= ne > a registry. Would we want to define one? If so, should that go into the > current draft? (I appreciate that this has gone to Last Call, so I=E2=80= =99ll > apologize for not raising this before.) If we did, what would the URIs > look like? Does the IETF or IANA have a URI defined for this sort of thi= ng? > **** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --bcaec5523b264954f604d7a86634 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI, this looks very similar to Claims in OpenID Connect.=C2=A0
We use = language-script tag to express it the same way you do.=C2=A0


Yes, that is very similar. A significant difference = is that what is advertised via WebFinger is not necessarily something = that one obtains through identity verification. For example, if I visit = a blog and see a posting by you or if I get an email from you, I might = want to know some of this information about you and I'm clearly not in a = position to do an identity verification.

Use of attributes in Connect might be preferred by users who don't mind = sharing this information with certain RPs, but does not want to share = this with the world.

I agree = these are different use cases.


Is there value in defining a URL for each of these attributes for use in = WebFinger?


There is if people are going = to use the attributes! :)

Gonzala and I are = going to pick up the link relation types doc and work on it. Would it = make sense for these URIs for properties to be defined there as = well?


Paul

From: Nat Sakimura <sakimura@gmail.com>
Sent: Mon Mar 11 12:09:37 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger@ietf.org, = webfinger@googlegroups.com<= br> Subject: Re: [webfinger] Properties in WebFinger

FYI, this looks very similar to Claims in OpenID Connect. 
We = use language-script tag to express it the same way you = do. 

JWT defines a registry for public claim = names. 

Nat


2013/3/5 Paul E. Jones <paulej@packetizer.com>

Folks,

 

One = of the features in WebFinger is the ability to define =E2=80=9Cproperties=E2= =80=9D related to either a subject or a link.

 

I = would expect properties defined for a link to be defined as a part of = the link relation definition.

 

Properties that relate to the subject would be defined in separate RFCs = or could be defined by other SDOs or anyone else, as properties are = always fully-qualified URIs.

 

As an = example, consider the following example:

 

  = "properties" :

  = {

    "http://packetizer.com/ns/name" : "Paul E. = Jones",

    "http://packetizer.com/ns/name#zh-CN" : = "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF"

  = }

 

The = =E2=80=9Cname=E2=80=9D property is intended to convey the subject=E2=80=99= s name with an optional language tag as a URI fragment.  This is = not defined anywhere, except here: http://packetizer.com/ns/name

 

A = question to the group is this: do we need to define a registry for = property values defined for a subject?  The current WF spec does = not define a registry.  Would we want to define one?  If so, = should that go into the current draft?  (I appreciate that this has = gone to Last Call, so I=E2=80=99ll apologize for not raising this = before.)  If we did, what would the URIs look like?  Does the = IETF or IANA have a URI defined for this sort of thing?

 

Paul

 


_____________= __________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger




--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--
 
---
You received this message because you are subscribed to the Google = Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send = an email to webfinger+unsubscri= be@googlegroups.com.
For more options, visit https://groups.google.co= m/groups/opt_out.
 
 
JWT defines a registry for public claim names.=C2=A0

Nat


2013/3= /5 Paul E. Jones <paulej@packetizer.com>

Folks,

=C2=A0

=

One of the features in WebFinger is the ability to d= efine =E2=80=9Cproperties=E2=80=9D related to either a subject or a link.

=C2=A0

I wou= ld expect properties defined for a link to be defined as a part of the link= relation definition.

=C2=A0=

Properties that relate to the subject would be defined in separate RFCs or = could be defined by other SDOs or anyone else, as properties are always ful= ly-qualified URIs.

=C2=A0=

As an example, consider the following example:

=C2=A0

=C2=A0 "properties" :

=C2=A0 {

=C2=A0= =C2=A0=C2=A0 "http://packetizer.com/ns/name" : "Paul E. Jones",=

=C2=A0=C2=A0=C2=A0 "http://packetizer.com/ns/name#zh-CN&qu= ot; : "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF"= ;

=C2=A0 }

=C2=A0

The =E2=80=9Cname=E2=80=9D pro= perty is intended to convey the subject=E2=80=99s name with an optional lan= guage tag as a URI fragment.=C2=A0 This is not defined anywhere, except her= e: http://packetizer.= com/ns/name

=C2=A0

A que= stion to the group is this: do we need to define a registry for property va= lues defined for a subject?=C2=A0 The current WF spec does not define a reg= istry.=C2=A0 Would we want to define one?=C2=A0 If so, should that go into = the current draft?=C2=A0 (I appreciate that this has gone to Last Call, so = I=E2=80=99ll apologize for not raising this before.)=C2=A0 If we did, what = would the URIs look like?=C2=A0 Does the IETF or IANA have a URI defined fo= r this sort of thing?=

=C2=A0

Paul

=C2=A0


_________= ______________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--bcaec5523b264954f604d7a86634-- From dick.hardt@gmail.com Mon Mar 11 09:39:07 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D98F11E8169 for ; Mon, 11 Mar 2013 09:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFYPGqMv1WCR for ; Mon, 11 Mar 2013 09:39:07 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEC511E8168 for ; Mon, 11 Mar 2013 09:39:07 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so5072957iea.12 for ; Mon, 11 Mar 2013 09:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jRImH7wpDhsnfM0UCDKmDtCctOk2Lw6WIjh9ZTpM1fw=; b=ewT8CEhrv3iTUL9RUGe40cPZ/UpaQ2iOZVOYQo87Zy1w54ay6OnTiFWfndwdlX3xVl Xp7VFbFl79ewhFZ+gWCBUSS/9KEirEHVeR6IhLHkzHZFp/tCyBoyN43d7VnYUfZIQ0/y if8UGmJX4LWoxbX0AruSVQSGHiqacTfnTFsM+XKcXETcDPlDpNWZKKlcZ/a9Uq7glvJf TDlS09UQdz73bxYM7XcsjG6Xi7P+E8eCSUP6XXJtLCsuNhr2Cj6FZpFUV45JMgUn0jNJ LEvB0IdXpSJ604UbVzlcPwQXZe88clo/RJdFUVBWEagfdrKdMaD7/DKl5d4Cr3OvlBZp dohA== MIME-Version: 1.0 X-Received: by 10.50.5.180 with SMTP id t20mr7846325igt.80.1363019946699; Mon, 11 Mar 2013 09:39:06 -0700 (PDT) Received: by 10.64.22.100 with HTTP; Mon, 11 Mar 2013 09:39:06 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674F5DCB@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943674F5DCB@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 11 Mar 2013 09:39:06 -0700 Message-ID: From: Dick Hardt To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8f502548beb61704d7a8cf96 Cc: "webfinger@ietf.org" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [webfinger] WebFinger link relation types doc X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 16:39:07 -0000 --e89a8f502548beb61704d7a8cf96 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Slipped off my plate. Now that WF has settled, I can pick it up again. On Mon, Mar 11, 2013 at 7:02 AM, Mike Jones wr= ote: > Hi Dick,**** > > ** ** > > In a previous message you=92d said that you and Gonzalo were working on a > draft specifying some common link relation types. This came up during th= e > Applications Area Working Group meeting at the IETF just now. Is the dra= ft > ready to share with the webfinger mailing list?**** > > ** ** > > -- Mike**** > > ** ** > --=20 -- Dick --e89a8f502548beb61704d7a8cf96 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Slipped off my plate. Now that WF has settled, I can pick = it up again.



On Mon, Mar 11, 2013 at 7:02 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Hi Dick,

=A0

In a previous message you=92d said that you and Gonz= alo were working on a draft specifying some common link relation types.=A0 = This came up during the Applications Area Working Group meeting at the IETF= just now.=A0 Is the draft ready to share with the webfinger mailing list?

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0




--
-- Dick
--e89a8f502548beb61704d7a8cf96-- From paulej@packetizer.com Mon Mar 11 10:15:35 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC5B11E8166 for ; Mon, 11 Mar 2013 10:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+29cc80xXQm for ; Mon, 11 Mar 2013 10:15:34 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 15F8F11E8162 for ; Mon, 11 Mar 2013 10:15:27 -0700 (PDT) Received: from dhcp-15f5.meeting.ietf.org (dhcp-15f5.meeting.ietf.org [130.129.21.245]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r2BHFOIX012217 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 11 Mar 2013 13:15:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363022125; bh=8jY33BqKCuELHhoTU3sSQEIJaic5EWt7O1YJgVPNQDk=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=IXJRSbF00oDBSUQrWOFQFPq7CGmtfXEiVjLu+tN66JrID8cVbbiVbkqrgkViG+zmp WW+CPb2jNBPRUqJaXOZxofERxVETvHGJvgAiO1xaDswvcOqhYzazSEgGR6x3K1WMVu qS3p5tyDcVG7y/Tyj14LWLDgGhoLflRC1Ildr/YA= User-Agent: K-9 Mail for Android In-Reply-To: References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----SSA04Z8L717GE43T0O1Q2GM1X49DLB" From: "Paul E. Jones" Date: Mon, 11 Mar 2013 13:15:21 -0400 To: Nat Sakimura Message-ID: <153b93e8-c319-45aa-aae7-878504a7551e@email.android.com> Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:15:35 -0000 ------SSA04Z8L717GE43T0O1Q2GM1X49DLB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Yes, that is very similar. A significant difference is that what is advertised via WebFinger is not necessarily something that one obtains through identity verification. For example, if I visit a blog and see a posting by you or if I get an email from you, I might want to know some of this information about you and I'm clearly not in a position to do an identity verification. Use of attributes in Connect might be preferred by users who don't mind sharing this information with certain RPs, but does not want to share this with the world. Is there value in defining a URL for each of these attributes for use in WebFinger? Paul -------- Original Message -------- From: Nat Sakimura Sent: Mon Mar 11 12:09:37 EDT 2013 To: "Paul E. Jones" Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Properties in WebFinger FYI, this looks very similar to Claims in OpenID Connect. We use language-script tag to express it the same way you do. http://openid.bitbucket.org/openid-connect-messages-1_0.html#StandardClaims JWT defines a registry for public claim names. http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-9.1 Nat 2013/3/5 Paul E. Jones > Folks,**** > > ** ** > > One of the features in WebFinger is the ability to define “properties” > related to either a subject or a link.**** > > ** ** > > I would expect properties defined for a link to be defined as a part of > the link relation definition.**** > > ** ** > > Properties that relate to the subject would be defined in separate RFCs or > could be defined by other SDOs or anyone else, as properties are always > fully-qualified URIs.**** > > ** ** > > As an example, consider the following example:**** > > ** ** > > "properties" :**** > > {**** > > "http://packetizer.com/ns/name" : "Paul E. Jones",**** > > "http://packetizer.com/ns/name#zh-CN" : "保罗‧琼斯"**** > > }**** > > ** ** > > The “name” property is intended to convey the subject’s name with an > optional language tag as a URI fragment. This is not defined anywhere, > except here: http://packetizer.com/ns/name**** > > ** ** > > A question to the group is this: do we need to define a registry for > property values defined for a subject? The current WF spec does not define > a registry. Would we want to define one? If so, should that go into the > current draft? (I appreciate that this has gone to Last Call, so I’ll > apologize for not raising this before.) If we did, what would the URIs > look like? Does the IETF or IANA have a URI defined for this sort of thing? > **** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ------SSA04Z8L717GE43T0O1Q2GM1X49DLB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Yes, that is very similar. A significant difference is that what is advertised via WebFinger is not necessarily something that one obtains through identity verification. For example, if I visit a blog and see a posting by you or if I get an email from you, I might want to know some of this information about you and I'm clearly not in a position to do an identity verification.

Use of attributes in Connect might be preferred by users who don't mind sharing this information with certain RPs, but does not want to share this with the world.

Is there value in defining a URL for each of these attributes for use in WebFinger?

Paul

From: Nat Sakimura <sakimura@gmail.com>
Sent: Mon Mar 11 12:09:37 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger@ietf.org, webfinger@googlegroups.com
Subject: Re: [webfinger] Properties in WebFinger

FYI, this looks very similar to Claims in OpenID Connect. 
We use language-script tag to express it the same way you do. 

JWT defines a registry for public claim names. 

Nat


2013/3/5 Paul E. Jones <paulej@packetizer.com>

Folks,

 

One of the features in WebFinger is the ability to define “properties” related to either a subject or a link.

 

I would expect properties defined for a link to be defined as a part of the link relation definition.

 

Properties that relate to the subject would be defined in separate RFCs or could be defined by other SDOs or anyone else, as properties are always fully-qualified URIs.

 

As an example, consider the following example:

 

  "properties" :

  {

    "http://packetizer.com/ns/name" : "Paul E. Jones",

    "http://packetizer.com/ns/name#zh-CN" : "保罗‧琼斯"

  }

 

The “name” property is intended to convey the subject’s name with an optional language tag as a URI fragment.  This is not defined anywhere, except here: http://packetizer.com/ns/name

 

A question to the group is this: do we need to define a registry for property values defined for a subject?  The current WF spec does not define a registry.  Would we want to define one?  If so, should that go into the current draft?  (I appreciate that this has gone to Last Call, so I’ll apologize for not raising this before.)  If we did, what would the URIs look like?  Does the IETF or IANA have a URI defined for this sort of thing?

 

Paul

 


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




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
------SSA04Z8L717GE43T0O1Q2GM1X49DLB-- From dick.hardt@gmail.com Mon Mar 11 10:25:40 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B9411E813F for ; Mon, 11 Mar 2013 10:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw4jLRJby7nG for ; Mon, 11 Mar 2013 10:25:38 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13FA321F895F for ; Mon, 11 Mar 2013 10:25:38 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wz12so3985097pbc.31 for ; Mon, 11 Mar 2013 10:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=xlNpipPZ9SM2gZKPw6SuIWoJAK8DMcvR0uNWm2+xW4A=; b=PkGXY5FnelJ0EotnK8XBGc4p351/9H0beT361dJMWo80ceUTU8WRIWoxKCgRSQ1DLE HTk14OUASPKxjSx29RQcZX4oTAOp4/Wh8dbLRVSdrLZVncK26bO8Qbx5de9Q9KOJI7Xh r48BzVFD/f/pObd1rfol6eFGx5KXvAR9FWflnW/SDCLySX7ojsJSE564TjSOgAm/Dd7P ZaqUMG4Idq1dgrNQc5Pa3r7ODm3NSEwAfT57/6MBleo2JyU4q8GCOR8ehsN6dRHajK0g 4zznpYfVpK0CAld8JWEfankeI8Ys81Jgt0UXCPhnzg0EFGU/grm89ccjQ2Vr5jD3km4F cjZg== X-Received: by 10.68.117.3 with SMTP id ka3mr29578940pbb.81.1363022737693; Mon, 11 Mar 2013 10:25:37 -0700 (PDT) Received: from [10.0.0.80] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id b9sm21234426pba.6.2013.03.11.10.25.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 10:25:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2D6589C1-C0B6-428B-B6EA-0122F25FD54E" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <153b93e8-c319-45aa-aae7-878504a7551e@email.android.com> Date: Mon, 11 Mar 2013 10:25:33 -0700 Message-Id: References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> <153b93e8-c319-45aa-aae7-878504a7551e@email.android.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org, Nat Sakimura Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:25:40 -0000 --Apple-Mail=_2D6589C1-C0B6-428B-B6EA-0122F25FD54E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 11, 2013, at 10:15 AM, "Paul E. Jones" = wrote: > Yes, that is very similar. A significant difference is that what is = advertised via WebFinger is not necessarily something that one obtains = through identity verification. For example, if I visit a blog and see a = posting by you or if I get an email from you, I might want to know some = of this information about you and I'm clearly not in a position to do an = identity verification. >=20 > Use of attributes in Connect might be preferred by users who don't = mind sharing this information with certain RPs, but does not want to = share this with the world. I agree these are different use cases. >=20 > Is there value in defining a URL for each of these attributes for use = in WebFinger? >=20 There is if people are going to use the attributes! :) Gonzala and I are going to pick up the link relation types doc and work = on it. Would it make sense for these URIs for properties to be defined = there as well? > Paul >=20 > From: Nat Sakimura > Sent: Mon Mar 11 12:09:37 EDT 2013 > To: "Paul E. Jones" > Cc: webfinger@ietf.org, webfinger@googlegroups.com > Subject: Re: [webfinger] Properties in WebFinger >=20 > FYI, this looks very similar to Claims in OpenID Connect.=20 > We use language-script tag to express it the same way you do.=20 > = http://openid.bitbucket.org/openid-connect-messages-1_0.html#StandardClaim= s >=20 > JWT defines a registry for public claim names.=20 > = http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-9.1 >=20 > Nat >=20 >=20 > 2013/3/5 Paul E. Jones > Folks, >=20 > =20 >=20 > One of the features in WebFinger is the ability to define = =E2=80=9Cproperties=E2=80=9D related to either a subject or a link. >=20 > =20 >=20 > I would expect properties defined for a link to be defined as a part = of the link relation definition. >=20 > =20 >=20 > Properties that relate to the subject would be defined in separate = RFCs or could be defined by other SDOs or anyone else, as properties are = always fully-qualified URIs. >=20 > =20 >=20 > As an example, consider the following example: >=20 > =20 >=20 > "properties" : >=20 > { >=20 > "http://packetizer.com/ns/name" : "Paul E. Jones", >=20 > "http://packetizer.com/ns/name#zh-CN" : "=E4=BF=9D=E7=BD=97=E2=80=A7= =E7=90=BC=E6=96=AF" >=20 > } >=20 > =20 >=20 > The =E2=80=9Cname=E2=80=9D property is intended to convey the = subject=E2=80=99s name with an optional language tag as a URI fragment. = This is not defined anywhere, except here: http://packetizer.com/ns/name >=20 > =20 >=20 > A question to the group is this: do we need to define a registry for = property values defined for a subject? The current WF spec does not = define a registry. Would we want to define one? If so, should that go = into the current draft? (I appreciate that this has gone to Last Call, = so I=E2=80=99ll apologize for not raising this before.) If we did, what = would the URIs look like? Does the IETF or IANA have a URI defined for = this sort of thing? >=20 > =20 >=20 > Paul >=20 > =20 >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > --=20 > =20 > ---=20 > You received this message because you are subscribed to the Google = Groups "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send = an email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > =20 > =20 --Apple-Mail=_2D6589C1-C0B6-428B-B6EA-0122F25FD54E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 paulej@packetizer.com> = wrote:

= --Apple-Mail=_2D6589C1-C0B6-428B-B6EA-0122F25FD54E-- From sakimura@gmail.com Mon Mar 11 11:27:37 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C2B21F8D66 for ; Mon, 11 Mar 2013 11:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D59YznLgoFWw for ; Mon, 11 Mar 2013 11:27:33 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 12FF221F8D64 for ; Mon, 11 Mar 2013 11:27:32 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id l12so3391796lbo.33 for ; Mon, 11 Mar 2013 11:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=a70nDux7jg+G4WlmnXQ9ZmYgi+GsJIZCKQr9vS0MQfA=; b=ujtiG79MuLNP7ThupEIxuYbA9bXdbvpncT0jq9XD3v6lmM4wNOw5AY1rDNWvlGvrcg lT8lyBdIXznoqXdZPY/Z0jDjBgouYlDMCU+w+3QmmB33tqguF0FN7GPoIEnQux5cSGqI MD8M+OnYOfjfHEnl1mkltiOPAqD/efV6azl9r99wJxGqqR4anL+4Tt0NxnwxGQfLARlL aHBrQyYPFsDy05pgkLpzLlevoJ3yas39LIOW2cToxcSVnMIZP/lb7yCp+7gnDL80Yuct 0Irf1jYJ4DXxIlpZlhKrmH0OFX85IgGzjhfOtAym3ouBhM+/75rK063ZN257k5wRu9+z XnfQ== MIME-Version: 1.0 X-Received: by 10.152.109.112 with SMTP id hr16mr11211249lab.38.1363026451712; Mon, 11 Mar 2013 11:27:31 -0700 (PDT) Received: by 10.112.14.44 with HTTP; Mon, 11 Mar 2013 11:27:31 -0700 (PDT) In-Reply-To: References: <01db01ce18f9$342fe340$9c8fa9c0$@packetizer.com> <153b93e8-c319-45aa-aae7-878504a7551e@email.android.com> Date: Tue, 12 Mar 2013 03:27:31 +0900 Message-ID: From: Nat Sakimura To: Dick Hardt Content-Type: multipart/alternative; boundary=bcaec54eea707953d104d7aa53d9 Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Properties in WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:27:37 -0000 --bcaec54eea707953d104d7aa53d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable They are different use cases but what is being expressed amounts to be the same. The difference is whether the subject has been authenticated in certain way or not. The data schema should be more or less the same. I think registering them in IANA Link Relation Type Registry would be good. Nat 2013/3/12 Dick Hardt > > On Mar 11, 2013, at 10:15 AM, "Paul E. Jones" > wrote: > > Yes, that is very similar. A significant difference is that what is > advertised via WebFinger is not necessarily something that one obtains > through identity verification. For example, if I visit a blog and see a > posting by you or if I get an email from you, I might want to know some o= f > this information about you and I'm clearly not in a position to do an > identity verification. > > Use of attributes in Connect might be preferred by users who don't mind > sharing this information with certain RPs, but does not want to share thi= s > with the world. > > > I agree these are different use cases. > > > Is there value in defining a URL for each of these attributes for use in > WebFinger? > > > There is if people are going to use the attributes! :) > > Gonzala and I are going to pick up the link relation types doc and work o= n > it. Would it make sense for these URIs for properties to be defined there > as well? > > > Paul > > ------------------------------ > *From:* Nat Sakimura > *Sent:* Mon Mar 11 12:09:37 EDT 2013 > *To:* "Paul E. Jones" > *Cc:* webfinger@ietf.org, webfinger@googlegroups.com > *Subject:* Re: [webfinger] Properties in WebFinger > > FYI, this looks very similar to Claims in OpenID Connect. > We use language-script tag to express it the same way you do. > http://openid.bitbucket.org/openid-connect-messages-1_0.html#StandardClai= ms > > JWT defines a registry for public claim names. > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-9.1 > > Nat > > > 2013/3/5 Paul E. Jones > >> Folks,**** >> >> ** ** >> >> One of the features in WebFinger is the ability to define =E2=80=9Cprope= rties=E2=80=9D >> related to either a subject or a link.**** >> >> ** ** >> >> I would expect properties defined for a link to be defined as a part of >> the link relation definition.**** >> >> ** ** >> >> Properties that relate to the subject would be defined in separate RFCs >> or could be defined by other SDOs or anyone else, as properties are alwa= ys >> fully-qualified URIs.**** >> >> ** ** >> >> As an example, consider the following example:**** >> >> ** ** >> >> "properties" :**** >> >> {**** >> >> "http://packetizer.com/ns/name" : "Paul E. Jones",**** >> >> "http://packetizer.com/ns/name#zh-CN" : "=E4=BF=9D=E7=BD=97=E2=80=A7= =E7=90=BC=E6=96=AF"**** >> >> }**** >> >> ** ** >> >> The =E2=80=9Cname=E2=80=9D property is intended to convey the subject=E2= =80=99s name with an >> optional language tag as a URI fragment. This is not defined anywhere, >> except here: http://packetizer.com/ns/name**** >> >> ** ** >> >> A question to the group is this: do we need to define a registry for >> property values defined for a subject? The current WF spec does not def= ine >> a registry. Would we want to define one? If so, should that go into th= e >> current draft? (I appreciate that this has gone to Last Call, so I=E2= =80=99ll >> apologize for not raising this before.) If we did, what would the URIs >> look like? Does the IETF or IANA have a URI defined for this sort of th= ing? >> **** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > -- > > --- > You received this message because you are subscribed to the Google Groups > "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --bcaec54eea707953d104d7aa53d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable They are different use cases but what is being expressed amounts to be the = same.=C2=A0
The difference is whether the subject has been authenticate= d in certain way or not.=C2=A0
The data schema should be more or = less the same.=C2=A0

I think registering them in IANA=C2=A0Link Relation Typ= e Registry would be good.=C2=A0

Nat

2013/3/12 Dick Hardt <dick.hardt@gmail.com><= /span>

On Mar 11, 2013, at 10:15 AM, "Paul E. Jones&q= uot; <paulej@= packetizer.com> wrote:

Yes, that is very similar. A significant= difference is that what is advertised via WebFinger is not necessarily som= ething that one obtains through identity verification. For example, if I v= isit a blog and see a posting by you or if I get an email from you, I might= want to know some of this information about you and I'm clearly not in= a position to do an identity verification.

Use of attributes in Connect might be preferred by users who don't mind= sharing this information with certain RPs, but does not want to share this= with the world.

I agree th= ese are different use cases.


Is there value in defining a URL for each of these attributes for use in We= bFinger?


There is if people are goi= ng to use the attributes! :)

Gonzala and I are goi= ng to pick up the link relation types doc and work on it. Would it make sen= se for these URIs for properties to be defined there as well?


Paul

From: Nat Sakimura <sakimura@gmail.com>
Sent: Mon Mar 11 12:09:37 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinge= r@ietf.org, webfinger@googlegroups.com
Subject: Re: [webfinger] Properties in WebFinger

FYI, this looks very similar to Claims in OpenID Connect.=C2=A0
We use = language-script tag to express it the same way you do.=C2=A0

JWT defines a registry for public claim names.=C2=A0

Nat


2013/3= /5 Paul E. Jones <paulej@packetizer.com>

F= olks,

=C2=A0

One of the features in WebFinger is the ability to define= =E2=80=9Cproperties=E2=80=9D related to either a subject or a link.=

=C2=A0

I wou= ld expect properties defined for a link to be defined as a part of the link= relation definition.

=C2=A0=

Properties that relate to the subject would be defined in separate RFCs or = could be defined by other SDOs or anyone else, as properties are always ful= ly-qualified URIs.

=C2=A0=

As an example, consider the following example:

=C2=A0

=C2=A0 "properties" :

=C2=A0 {

=C2=A0= =C2=A0=C2=A0 "http://packetizer.com/ns/name" : "Paul E. Jones",=

=C2=A0=C2=A0=C2=A0 "http://packetizer.com/ns/name#zh-CN&qu= ot; : "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF"= ;

=C2=A0 }

=C2=A0

The =E2=80=9Cname=E2=80=9D pro= perty is intended to convey the subject=E2=80=99s name with an optional lan= guage tag as a URI fragment.=C2=A0 This is not defined anywhere, except her= e: http://packetizer.= com/ns/name

=C2=A0

A que= stion to the group is this: do we need to define a registry for property va= lues defined for a subject?=C2=A0 The current WF spec does not define a reg= istry.=C2=A0 Would we want to define one?=C2=A0 If so, should that go into = the current draft?=C2=A0 (I appreciate that this has gone to Last Call, so = I=E2=80=99ll apologize for not raising this before.)=C2=A0 If we did, what = would the URIs look like?=C2=A0 Does the IETF or IANA have a URI defined fo= r this sort of thing?

=C2=A0

Paul<= u>

=C2=A0


_= ______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--
=C2=A0
---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
=C2=A0
=C2=A0




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--bcaec54eea707953d104d7aa53d9-- From bortzmeyer@nic.fr Fri Mar 15 08:02:10 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC42A21F8840 for ; Fri, 15 Mar 2013 08:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6cx8BzXikjI for ; Fri, 15 Mar 2013 08:02:09 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 0420521F8887 for ; Fri, 15 Mar 2013 08:02:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id B650F3BDE4; Fri, 15 Mar 2013 15:02:07 +0000 (UTC) Received: by tyrion (Postfix, from userid 1000) id CA25AF004E5; Fri, 15 Mar 2013 16:00:58 +0100 (CET) Date: Fri, 15 Mar 2013 11:00:58 -0400 From: Stephane Bortzmeyer To: webfinger@ietf.org Message-ID: <20130315150058.GA28881@laperouse.bortzmeyer.org> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 12.04 (precise) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ietf-languages@alvestrand.no Subject: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 15:02:10 -0000 On Mon, Mar 04, 2013 at 12:24:30PM -0800, The IESG wrote a message of 38 lines which said: > The IESG has received a request from the Applications Area Working Group > WG (appsawg) to consider the following document: > - 'WebFinger' > as Proposed Standard draft-ietf-appsawg-webfinger-11.txt says: > The "titles" object comprises zero or more name/value pairs whose > name is a language tag or the string "default". [...] If the > language is unknown or unspecified, then the name is "default". Why inventing a special value when the language tag registry already has a specific value, "und"? To quote RFC 5646: > The 'und' (Undetermined) primary language subtag identifies > linguistic content whose language is not determined. This subtag > SHOULD NOT be used unless a language tag is required and language > information is not available or cannot be determined. Editorial comment: the reference is wrong: [13] Phillips, A., Davis, M., "Tags for Identifying Languages", RFC 5646, January 2001. [It is 2009] From bortzmeyer@nic.fr Fri Mar 15 08:10:36 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD11A21F8831 for ; Fri, 15 Mar 2013 08:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id talj0G-qhi69 for ; Fri, 15 Mar 2013 08:10:36 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECA221F871E for ; Fri, 15 Mar 2013 08:10:36 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A6B003BDEA; Fri, 15 Mar 2013 15:10:35 +0000 (UTC) Received: by tyrion (Postfix, from userid 1000) id 0A6CCF004E5; Fri, 15 Mar 2013 16:10:27 +0100 (CET) Date: Fri, 15 Mar 2013 11:10:27 -0400 From: Stephane Bortzmeyer To: Dave Cridland Message-ID: <20130315151027.GB28881@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 12.04 (precise) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: webfinger@ietf.org Subject: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 15:10:36 -0000 On Mon, Mar 11, 2013 at 03:23:20PM +0000, Dave Cridland wrote a message of 150 lines which said: > 1) There's some suggestions that webfinger could be used for email > autoconfig; I suspect this is at best going to cause confusion Indeed, the example with IMAP in 3.3 confuses me. Why is is better than the standard RFC 6186? From bortzmeyer@nic.fr Fri Mar 15 08:19:35 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B07A21F87AC for ; Fri, 15 Mar 2013 08:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F858I+YH-WyR for ; Fri, 15 Mar 2013 08:19:34 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF3121F87AA for ; Fri, 15 Mar 2013 08:19:34 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id BFCAE3BC7B; Fri, 15 Mar 2013 15:19:28 +0000 (UTC) Received: by tyrion (Postfix, from userid 1000) id 5EE25F004E5; Fri, 15 Mar 2013 16:18:47 +0100 (CET) Date: Fri, 15 Mar 2013 11:18:47 -0400 From: Stephane Bortzmeyer To: webfinger@ietf.org Message-ID: <20130315151847.GA29361@laperouse.bortzmeyer.org> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130315150058.GA28881@laperouse.bortzmeyer.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 12.04 (precise) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ietf-languages@alvestrand.no Subject: [webfinger] Language tag too specific (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 15:19:35 -0000 Another issue with language tags in draft-ietf-appsawg-webfinger-11.txt: > "titles" : > { > "en-us" : "The Magical World of Bob", > "fr" : "Le Monde Magique de Bob" > } I understand that the purpose of the example is to show that you are not limited to the primary langauge subtag, you can add other subtags (here, the region "us"). But the example is not well chosen. RFC 5646 says: > Use as precise a tag as possible, but no more specific than is > justified. Avoid using subtags that are not important for > distinguishing content in an application. > > * For example, 'de' might suffice for tagging an email written > in German, while "de-CH-1996" is probably unnecessarily > precise for such a task. Which seems to apply exactly here (there is nothing US-specific in the sentence). May be, instead: "titles" : { "en-us" : "The Magical Theater of Bob", "en-gb" : "The Magical Theatre of Bob", "fr" : "Le Théâtre Magique de Bob" } From Michael.Jones@microsoft.com Fri Mar 15 09:03:18 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9D621F87D6 for ; Fri, 15 Mar 2013 09:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4scU0QVkFma for ; Fri, 15 Mar 2013 09:03:17 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id AD93421F87B3 for ; Fri, 15 Mar 2013 09:03:17 -0700 (PDT) Received: from BN1BFFO11FD004.protection.gbl (10.58.52.202) by BN1AFFO11HUB026.protection.gbl (10.58.52.136) with Microsoft SMTP Server (TLS) id 15.0.641.9; Fri, 15 Mar 2013 16:03:16 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD004.mail.protection.outlook.com (10.58.53.64) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Fri, 15 Mar 2013 16:03:15 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Fri, 15 Mar 2013 16:02:38 +0000 From: Mike Jones To: Stephane Bortzmeyer , "webfinger@ietf.org" Thread-Topic: [webfinger] Language tag too specific (Was: Last Call: (WebFinger) to Proposed Standard Thread-Index: AQHOIZCMAQ2Xa1cIO06BNTGYLUfpsJim6Q3g Date: Fri, 15 Mar 2013 16:02:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675264CE@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <20130315151847.GA29361@laperouse.bortzmeyer.org> In-Reply-To: <20130315151847.GA29361@laperouse.bortzmeyer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(4396001)(77982001)(59766001)(79102001)(50466001)(69226001)(46102001)(80022001)(65816001)(49866001)(20776003)(33656001)(76482001)(50986001)(47446002)(16406001)(74662001)(63696002)(621065001)(54316002)(74502001)(47736001)(56776001)(66066001)(31966008)(47976001)(73894001)(55846006)(51856001)(53806001)(56816002)(47776003)(23676001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB026; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Cc: "ietf-languages@alvestrand.no" Subject: Re: [webfinger] Language tag too specific (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:03:18 -0000 SSdsbCByYWlzZSBhIHJlbGF0ZWQgaXNzdWUgLSB0aGUgY2FzZSBvZiBjaGFyYWN0ZXJzIHVzZWQg aW4gbGFuZ3VhZ2UgdGFnIHZhbHVlcy4gIEdpdmVuIHRoYXQgImVuLXVzIiBhbmQgImVuLVVTIiBh cmUgZGlmZmVyZW50IEpTT04gdmFsdWVzLCBpdCdzIGltcG9ydGFudCBmb3IgcGVvcGxlIHRvIHNw ZWxsIGxhbmd1YWdlIHRhZyB2YWx1ZXMgaW4gYSBjb25zaXN0ZW50IHdheS4NCg0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTY0NiNzZWN0aW9uLTIuMS4xIG1ha2VzIHNwZWNpZmljIHJl Y29tbWVuZGF0aW9ucy4gV2Ugc2hvdWxkIHByb2JhYmx5IGNhbGwgdGhlbSBvdXQgLSBpbiBwYXJ0 aWN1bGFyLCB0aGF0IHRhZyBlbGVtZW50cyBTSE9VTEQgYmUgc3BlbGxlZCBhcyBpbiB0aGUgSUFO QSByZWdpc3RyeSBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2xhbmd1YWdlLXN1 YnRhZy1yZWdpc3RyeS4NCg0KSW4gdGhlIGNhc2Ugb2YgVVMgRW5nbGlzaCB1c2VkIGluIHRoZSBl eGFtcGxlLCB0aGUgcmVjb21tZW5kZWQgc3BlbGxpbmcgYXBwZWFycyB0byBiZSAiZW4tVVMiLg0K DQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogd2ViZmlu Z2VyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp3ZWJmaW5nZXItYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFN0ZXBoYW5lIEJvcnR6bWV5ZXINClNlbnQ6IEZyaWRheSwgTWFyY2ggMTUs IDIwMTMgODoxOSBBTQ0KVG86IHdlYmZpbmdlckBpZXRmLm9yZw0KQ2M6IGlldGYtbGFuZ3VhZ2Vz QGFsdmVzdHJhbmQubm8NClN1YmplY3Q6IFt3ZWJmaW5nZXJdIExhbmd1YWdlIHRhZyB0b28gc3Bl Y2lmaWMgKFdhczogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMC50 eHQ+IChXZWJGaW5nZXIpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCkFub3RoZXIgaXNzdWUgd2l0 aCBsYW5ndWFnZSB0YWdzIGluIGRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMTEudHh0Og0K DQo+ICJ0aXRsZXMiIDoNCj4gICAgICAgICAgIHsNCj4gICAgICAgICAgICAgICAiZW4tdXMiIDog IlRoZSBNYWdpY2FsIFdvcmxkIG9mIEJvYiIsDQo+ICAgICAgICAgICAgICAgImZyIiA6ICJMZSBN b25kZSBNYWdpcXVlIGRlIEJvYiINCj4gICAgICAgICAgIH0NCg0KSSB1bmRlcnN0YW5kIHRoYXQg dGhlIHB1cnBvc2Ugb2YgdGhlIGV4YW1wbGUgaXMgdG8gc2hvdyB0aGF0IHlvdSBhcmUgbm90IGxp bWl0ZWQgdG8gdGhlIHByaW1hcnkgbGFuZ2F1Z2Ugc3VidGFnLCB5b3UgY2FuIGFkZCBvdGhlciBz dWJ0YWdzIChoZXJlLCB0aGUgcmVnaW9uICJ1cyIpLiBCdXQgdGhlIGV4YW1wbGUgaXMgbm90IHdl bGwgY2hvc2VuLiBSRkMgNTY0NiBzYXlzOg0KDQo+ICAgICAgVXNlIGFzIHByZWNpc2UgYSB0YWcg YXMgcG9zc2libGUsIGJ1dCBubyBtb3JlIHNwZWNpZmljIHRoYW4gaXMNCj4gICAgICBqdXN0aWZp ZWQuICBBdm9pZCB1c2luZyBzdWJ0YWdzIHRoYXQgYXJlIG5vdCBpbXBvcnRhbnQgZm9yDQo+ICAg ICAgZGlzdGluZ3Vpc2hpbmcgY29udGVudCBpbiBhbiBhcHBsaWNhdGlvbi4NCj4NCj4gICAgICAg KiBGb3IgZXhhbXBsZSwgJ2RlJyBtaWdodCBzdWZmaWNlIGZvciB0YWdnaW5nIGFuIGVtYWlsIHdy aXR0ZW4NCj4gICAgICAgICAgaW4gR2VybWFuLCB3aGlsZSAiZGUtQ0gtMTk5NiIgaXMgcHJvYmFi bHkgdW5uZWNlc3NhcmlseQ0KPiAgICAgICAgICBwcmVjaXNlIGZvciBzdWNoIGEgdGFzay4NCg0K V2hpY2ggc2VlbXMgdG8gYXBwbHkgZXhhY3RseSBoZXJlICh0aGVyZSBpcyBub3RoaW5nIFVTLXNw ZWNpZmljIGluIHRoZSBzZW50ZW5jZSkuIE1heSBiZSwgaW5zdGVhZDoNCg0KInRpdGxlcyIgOg0K ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAiZW4tdXMiIDogIlRoZSBNYWdpY2FsIFRoZWF0 ZXIgb2YgQm9iIiwNCiAgICAgICAgICAgICAgICJlbi1nYiIgOiAiVGhlIE1hZ2ljYWwgVGhlYXRy ZSBvZiBCb2IiLA0KICAgICAgICAgICAgICAgImZyIiA6ICJMZSBUaMOpw6J0cmUgTWFnaXF1ZSBk ZSBCb2IiDQogICAgICAgICAgIH0NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQp3ZWJmaW5nZXIgbWFpbGluZyBsaXN0DQp3ZWJmaW5nZXJAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2ViZmluZ2VyDQo= From bortzmeyer@nic.fr Fri Mar 15 09:11:53 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E9621F8523 for ; Fri, 15 Mar 2013 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcxPVn1yQaOm for ; Fri, 15 Mar 2013 09:11:52 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id A059521F8512 for ; Fri, 15 Mar 2013 09:11:52 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id CA7873BE08; Fri, 15 Mar 2013 16:11:51 +0000 (UTC) Received: by tyrion (Postfix, from userid 1000) id 2BF5AF004E5; Fri, 15 Mar 2013 17:04:54 +0100 (CET) Date: Fri, 15 Mar 2013 12:04:54 -0400 From: Stephane Bortzmeyer To: webfinger@ietf.org Message-ID: <20130315160454.GA31767@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 12.04 (precise) User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [webfinger] Comparison of URI-based link relation types? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:11:53 -0000 draft-ietf-appsawg-webfinger-11.txt says: > When the "rel" parameter is used and accepted, only the link > relation types that match the link relation types provided via the > "rel" parameter are included in the array of links returned in the > JRD. Link relation types can be simple strings (registered relation types) but they can also be URIs. URI comparison is not simple (RFC 3986, section 6.2), so is it on purpose if there is no detail in the draft about the matching algorithm to use? From Michael.Jones@microsoft.com Fri Mar 15 09:28:59 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD3021F8523 for ; Fri, 15 Mar 2013 09:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVcEhlE9vEB1 for ; Fri, 15 Mar 2013 09:28:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id D534B21F84E6 for ; Fri, 15 Mar 2013 09:28:53 -0700 (PDT) Received: from BY2FFO11FD013.protection.gbl (10.1.15.203) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 15 Mar 2013 16:28:51 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Fri, 15 Mar 2013 16:28:50 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Fri, 15 Mar 2013 16:28:14 +0000 From: Mike Jones To: Stephane Bortzmeyer , "webfinger@ietf.org" Thread-Topic: [webfinger] Comparison of URI-based link relation types? Thread-Index: AQHOIZfgjPOvJw0IrUy3StolOlvSwJim79ng Date: Fri, 15 Mar 2013 16:28:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436752662F@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20130315160454.GA31767@laperouse.bortzmeyer.org> In-Reply-To: <20130315160454.GA31767@laperouse.bortzmeyer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(189002)(377454001)(199002)(66066001)(54356001)(53806001)(16406001)(54316002)(80022001)(46102001)(47736001)(46406002)(47776003)(51856001)(77982001)(65816001)(69226001)(44976002)(55846006)(23726001)(56816002)(76482001)(4396001)(74502001)(50466001)(47976001)(50986001)(56776001)(63696002)(59766001)(31966008)(5343655001)(20776003)(79102001)(74662001)(47446002)(49866001)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB027; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Subject: Re: [webfinger] Comparison of URI-based link relation types? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:28:59 -0000 I sure hope that what we do is use string equality with no transformations,= case folding, etc. And that we recommend that URNs use the spelling regis= tered in the applicable IANA registry or other registry. -- Mike -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Stephane Bortzmeyer Sent: Friday, March 15, 2013 9:05 AM To: webfinger@ietf.org Subject: [webfinger] Comparison of URI-based link relation types? draft-ietf-appsawg-webfinger-11.txt says: > When the "rel" parameter is used and accepted, only the link relation=20 > types that match the link relation types provided via the "rel"=20 > parameter are included in the array of links returned in the JRD. Link relation types can be simple strings (registered relation types) but t= hey can also be URIs. URI comparison is not simple (RFC 3986, section 6.2),= so is it on purpose if there is no detail in the draft about the matching = algorithm to use? _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger From bortzmeyer@nic.fr Fri Mar 15 09:43:23 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAA521F88A3 for ; Fri, 15 Mar 2013 09:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl+eKDTKRwdY for ; Fri, 15 Mar 2013 09:43:22 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 6864A21F86DE for ; Fri, 15 Mar 2013 09:43:22 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id EEB4D3BE10; Fri, 15 Mar 2013 16:43:20 +0000 (UTC) Received: by tyrion (Postfix, from userid 1000) id A01D3F004E5; Fri, 15 Mar 2013 17:43:12 +0100 (CET) Date: Fri, 15 Mar 2013 12:43:12 -0400 From: Stephane Bortzmeyer To: Mike Jones Message-ID: <20130315164312.GA699@laperouse.bortzmeyer.org> References: <20130315160454.GA31767@laperouse.bortzmeyer.org> <4E1F6AAD24975D4BA5B16804296739436752662F@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436752662F@TK5EX14MBXC284.redmond.corp.microsoft.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 12.04 (precise) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: webfinger@ietf.org Subject: Re: [webfinger] Comparison of URI-based link relation types? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:43:23 -0000 On Fri, Mar 15, 2013 at 04:28:14PM +0000, Mike Jones wrote a message of 25 lines which said: > I sure hope that what we do is use string equality with no > transformations, case folding, etc. If this is the case, I suggest to add a sentence: URI comparison uses the "Simple String Comparison" algorithm of section 6.2.1 of RFC 3986. And be aware that it means that rel="http://webfinger.example/rel/large%2Davatar" won't match "http://webfinger.example/rel/large-avatar" From Michael.Jones@microsoft.com Fri Mar 15 09:53:27 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226EA21F85A2 for ; Fri, 15 Mar 2013 09:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSOZwEpoIUpi for ; Fri, 15 Mar 2013 09:53:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id E1C8921F871C for ; Fri, 15 Mar 2013 09:53:24 -0700 (PDT) Received: from BL2FFO11FD006.protection.gbl (10.173.161.203) by BL2FFO11HUB022.protection.gbl (10.173.161.46) with Microsoft SMTP Server (TLS) id 15.0.641.9; Fri, 15 Mar 2013 16:51:55 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Fri, 15 Mar 2013 16:51:55 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 15 Mar 2013 16:51:21 +0000 From: Mike Jones To: Stephane Bortzmeyer Thread-Topic: [webfinger] Comparison of URI-based link relation types? Thread-Index: AQHOIZfgjPOvJw0IrUy3StolOlvSwJim79nggAAFVACAAAI5sA== Date: Fri, 15 Mar 2013 16:51:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367526801@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20130315160454.GA31767@laperouse.bortzmeyer.org> <4E1F6AAD24975D4BA5B16804296739436752662F@TK5EX14MBXC284.redmond.corp.microsoft.com> <20130315164312.GA699@laperouse.bortzmeyer.org> In-Reply-To: <20130315164312.GA699@laperouse.bortzmeyer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(13464002)(377454001)(47976001)(47776003)(56816002)(15202345001)(5343655001)(66066001)(51856001)(44976002)(5343635001)(31966008)(55846006)(53806001)(49866001)(80022001)(74502001)(54316002)(20776003)(47736001)(69226001)(54356001)(46102001)(50466001)(77982001)(4396001)(33656001)(23726001)(59766001)(79102001)(56776001)(47446002)(65816001)(46406002)(76482001)(50986001)(63696002)(74662001)(16406001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB022; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Comparison of URI-based link relation types? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:53:27 -0000 Sounds like the right choice to me... -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr]=20 Sent: Friday, March 15, 2013 9:43 AM To: Mike Jones Cc: webfinger@ietf.org Subject: Re: [webfinger] Comparison of URI-based link relation types? On Fri, Mar 15, 2013 at 04:28:14PM +0000, Mike Jones wrote a message of 25 lines which said: > I sure hope that what we do is use string equality with no=20 > transformations, case folding, etc. If this is the case, I suggest to add a sentence: URI comparison uses the "Simple String Comparison" algorithm of section 6.2= .1 of RFC 3986. And be aware that it means that rel=3D"http://webfinger.example/rel/large%2Davatar" won't match "http://web= finger.example/rel/large-avatar" From sakimura@gmail.com Fri Mar 15 10:00:38 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4002621F858B for ; Fri, 15 Mar 2013 10:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjjoxsm+lWWt for ; Fri, 15 Mar 2013 10:00:37 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 420E521F8896 for ; Fri, 15 Mar 2013 10:00:32 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id fr10so3959895lab.40 for ; Fri, 15 Mar 2013 10:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=O8u+iH/ZQ9n1ki7b1NatfhixaSHD8OKWrzcn6Z/knrw=; b=esvZv1UaFH0J2G5ldO3I6gLv1hwSCFtddHfmIcoYjCyw05zc52skEt36e3a3qW+BrM DHMvWWJXPeiRQ2OoFhcH3bQ7WnCvBhjTGl3vUxBLW3YfhHOF+FGdaxAioH984UEXa/yf 7eckJf3KsnwMIFeHkFL++cFTx50DXaLUA+fJYKZo1DgSmEMfRRImJSAq+LEpLxTFBDrT DhLVgvZhaJbiT3zRSdffQz6AM267mKFnkomQmvawdD7lACzCd5XdD2YHKLwdgO5REuXg wAo6r5A2EL12VjleD3DpqunJrbgfZmPyZxdZXWRHMHP+uUHiPX2p7U1iNL3vtrGgdGRv 4zMA== MIME-Version: 1.0 X-Received: by 10.152.133.52 with SMTP id oz20mr6387411lab.30.1363366823255; Fri, 15 Mar 2013 10:00:23 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Fri, 15 Mar 2013 10:00:22 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367526801@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20130315160454.GA31767@laperouse.bortzmeyer.org> <4E1F6AAD24975D4BA5B16804296739436752662F@TK5EX14MBXC284.redmond.corp.microsoft.com> <20130315164312.GA699@laperouse.bortzmeyer.org> <4E1F6AAD24975D4BA5B168042967394367526801@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sat, 16 Mar 2013 02:00:22 +0900 Message-ID: From: Nat Sakimura To: Mike Jones Content-Type: multipart/alternative; boundary=f46d0435c24c32e55704d7f993e0 Cc: "webfinger@ietf.org" , Stephane Bortzmeyer Subject: Re: [webfinger] Comparison of URI-based link relation types? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:00:38 -0000 --f46d0435c24c32e55704d7f993e0 Content-Type: text/plain; charset=ISO-8859-1 +1 2013/3/16 Mike Jones > Sounds like the right choice to me... > > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > Sent: Friday, March 15, 2013 9:43 AM > To: Mike Jones > Cc: webfinger@ietf.org > Subject: Re: [webfinger] Comparison of URI-based link relation types? > > On Fri, Mar 15, 2013 at 04:28:14PM +0000, Mike Jones < > Michael.Jones@microsoft.com> wrote a message of 25 lines which said: > > > I sure hope that what we do is use string equality with no > > transformations, case folding, etc. > > If this is the case, I suggest to add a sentence: > > URI comparison uses the "Simple String Comparison" algorithm of section > 6.2.1 of RFC 3986. > > And be aware that it means that > rel="http://webfinger.example/rel/large%2Davatar" won't match " > http://webfinger.example/rel/large-avatar" > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --f46d0435c24c32e55704d7f993e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

2013/3/16 Mike Jones <Micha= el.Jones@microsoft.com>
Sounds like the right choice to me...

-----Original Message-----
From: Stephane Bortzmeyer [mailto:bort= zmeyer@nic.fr]
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: webfinger@ietf.org
Subject: Re: [webfinger] Comparison of URI-based link relation types?

On Fri, Mar 15, 2013 at 04:28:14PM +0000, =A0Mike Jones <Michael.Jones@microsoft.com> wrote = =A0a message of 25 lines which said:

> I sure hope that what we do is use string equality with no
> transformations, case folding, etc.

If this is the case, I suggest to add a sentence:

URI comparison uses the "Simple String Comparison" algorithm of s= ection 6.2.1 of RFC 3986.

And be aware that it means that
rel=3D"http://webfinger.example/rel/large%2Davatar" won't= match "http://webfinger.example/rel/large-avatar"
_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--f46d0435c24c32e55704d7f993e0-- From ve7jtb@ve7jtb.com Sun Mar 17 14:21:17 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A86521F8A6E for ; Sun, 17 Mar 2013 14:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv62+rgaJriI for ; Sun, 17 Mar 2013 14:21:16 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 926E721F8A4A for ; Sun, 17 Mar 2013 14:21:15 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id z24so2418693qcq.5 for ; Sun, 17 Mar 2013 14:21:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=EilpWQB0goE9Qf+qncYIFRbjk16uFcHSHZTrfP+lMQE=; b=m62pkF1LNZYnHsjgdjBZsyjsQkHsSFt8p6K1b1/b7O1Zs0+YGCx1ZW48XVC3x/a9V0 /y7CTTesfIgQ+pugpWibXaBGmgHcdbmTt40xXeGUe6E7S9tSxBKe7ziiDvD8nhVJmFh5 sGQy8jPLJUytzsckpJa8T8WDRz+0SQ4lOrOWLyDI5my8/UWqHQuFXsTu1UX3qE5Qqx2q odCbytpLIM8XY/rO/L1+tD46sFMRgeAzjK3wdgud6JQRwt3s+AIOFE14V0GKRsBABMZN xNDoprWcXlMZTpvyFdZfoHhTnLjfQUm6oI/KClupU+KhiGVv31YL5d7jF+I9OmwQgKwY TRPg== X-Received: by 10.224.33.140 with SMTP id h12mr16809755qad.73.1363555275080; Sun, 17 Mar 2013 14:21:15 -0700 (PDT) Received: from [192.168.1.37] (190-20-39-218.baf.movistar.cl. [190.20.39.218]) by mx.google.com with ESMTPS id q6sm25777266qeu.1.2013.03.17.14.21.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 14:21:13 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_729F49DB-0130-4AA8-A966-44BAD9BA8F0A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Sun, 17 Mar 2013 17:20:58 -0400 Message-Id: References: <20130315160454.GA31767@laperouse.bortzmeyer.org> <4E1F6AAD24975D4BA5B16804296739436752662F@TK5EX14MBXC284.redmond.corp.microsoft.com> <20130315164312.GA699@laperouse.bortzmeyer.org> <4E1F6AAD24975D4BA5B168042967394367526801@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnNgEiEO9PfEmBtny3kMBcM+M/ANgAEmKEj0cMJL7uCAnZmZVBaaPA0+D99bdippCWtWqPd Cc: "webfinger@ietf.org" , Mike Jones , Stephane Bortzmeyer Subject: Re: [webfinger] Comparison of URI-based link relation types? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 21:21:17 -0000 --Apple-Mail=_729F49DB-0130-4AA8-A966-44BAD9BA8F0A Content-Type: multipart/alternative; boundary="Apple-Mail=_7E9BA1E6-53DC-403D-91B6-F4EDD9DADCBA" --Apple-Mail=_7E9BA1E6-53DC-403D-91B6-F4EDD9DADCBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 On 2013-03-15, at 1:00 PM, Nat Sakimura wrote: > +1 >=20 > 2013/3/16 Mike Jones > Sounds like the right choice to me... >=20 > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > Sent: Friday, March 15, 2013 9:43 AM > To: Mike Jones > Cc: webfinger@ietf.org > Subject: Re: [webfinger] Comparison of URI-based link relation types? >=20 > On Fri, Mar 15, 2013 at 04:28:14PM +0000, Mike Jones = wrote a message of 25 lines which said: >=20 > > I sure hope that what we do is use string equality with no > > transformations, case folding, etc. >=20 > If this is the case, I suggest to add a sentence: >=20 > URI comparison uses the "Simple String Comparison" algorithm of = section 6.2.1 of RFC 3986. >=20 > And be aware that it means that > rel=3D"http://webfinger.example/rel/large%2Davatar" won't match = "http://webfinger.example/rel/large-avatar" > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_7E9BA1E6-53DC-403D-91B6-F4EDD9DADCBA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 +1

On 2013-03-15, at 1:00 PM, Nat Sakimura <sakimura@gmail.com> wrote:

+1

2013/3/16 Mike Jones <Michael.Jones@microsoft.com>
Sounds like the right choice to me...

-----Original Message-----
From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr]
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: webfinger@ietf.org
Subject: Re: [webfinger] Comparison of URI-based link relation types?

On Fri, Mar 15, 2013 at 04:28:14PM +0000,  Mike Jones <Michael.Jones@microsoft.com> wrote  a message of 25 lines which said:

> I sure hope that what we do is use string equality with no
> transformations, case folding, etc.

If this is the case, I suggest to add a sentence:

URI comparison uses the "Simple String Comparison" algorithm of section 6.2.1 of RFC 3986.

And be aware that it means that
rel="http://webfinger.example/rel/large%2Davatar" won't match "http://webfinger.example/rel/large-avatar"
_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--Apple-Mail=_7E9BA1E6-53DC-403D-91B6-F4EDD9DADCBA-- --Apple-Mail=_729F49DB-0130-4AA8-A966-44BAD9BA8F0A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE3MjEyMDU5WjAjBgkqhkiG9w0BCQQxFgQUme118dBS oKhZWeUdtlgl8l+CQG0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAsQBv8GsTb0KsYhJ9rgzV7f0dL+Id7XY/kktIhfc+ wRDl8kW1YWsstuhFhdxCi6HLR7xxvw5P/l3/vsnBWoe44jahMhxCd8VdCZAH2OIl2Ro28kLg6jVP jcVs5nwB5DSg1u11KbQoFcusfSVdQWeXr/Mg6iBF7nfOJlSQi/vHo4oexdCedzMtKRhwsA2M3czm bDeh4fQtKJXNlICosCHp8SS4WPaFp8MfaZlIxJ0wlrIPJE2+B/5CJmyYW5T4y0UXcKqwycowRyBv nNJqQ7imp+zX+pzWP3LunBknaPEzfiOOeDHH9f68qu6XDCKpVmUts+Obiz6nomWOylgH7/MeLQAA AAAAAA== --Apple-Mail=_729F49DB-0130-4AA8-A966-44BAD9BA8F0A-- From duerst@it.aoyama.ac.jp Sun Mar 17 19:28:17 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6567B21F8C7D for ; Sun, 17 Mar 2013 19:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.79 X-Spam-Level: X-Spam-Status: No, score=-103.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TberzOg97wcv for ; Sun, 17 Mar 2013 19:28:16 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD7521F8C84 for ; Sun, 17 Mar 2013 19:28:15 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r2I2SCDA016563 for ; Mon, 18 Mar 2013 11:28:12 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 67ec_c84c_7b13892e_8f73_11e2_997e_001d096c5782; Mon, 18 Mar 2013 11:28:11 +0900 Received: from [IPv6:::1] ([133.2.210.1]:58792) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 18 Mar 2013 11:28:13 +0900 Message-ID: <51467BB9.8040408@it.aoyama.ac.jp> Date: Mon, 18 Mar 2013 11:28:09 +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: Mike Jones References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <20130315151847.GA29361@laperouse.bortzmeyer.org> <4E1F6AAD24975D4BA5B1680429673943675264CE@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675264CE@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "webfinger@ietf.org" , Stephane Bortzmeyer , "ietf-languages@alvestrand.no" Subject: Re: [webfinger] Language tag too specific (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 02:28:17 -0000 On 2013/03/16 1:02, Mike Jones wrote: > I'll raise a related issue - the case of characters used in language tag values. Given that "en-us" and "en-US" are different JSON values, it's important for people to spell language tag values in a consistent way. Hello Mike, Language tags are case-insensitive, so whether it says "en-US" or "en-us" (or any other combination of caps and lower case), the final result (that those people who prefer English as used in the US get to see the title version that's labeled "en-US" or "en-us") should be the same. Of course, it might be that there are two separate titles with match case-insensitively. Here's an example: "titles" : { "en-us" : "The Magical Theater of Bob", "en-gb" : "The magical theatre of Bob", "en-GB" : "The Magical Theatre of Bob", "fr" : "Le Théâtre Magique de Bob" } While the author might have intended for the user to select the lower case or the titlecase version of the title, that just won't work. So I guess we should call out this case and prohibit it for producers. But I don't see the reason to specify that everybody has to use "en-GB"; using "en-gb" only should just do as well. Regards, Martin. > http://tools.ietf.org/html/rfc5646#section-2.1.1 makes specific recommendations. We should probably call them out - in particular, that tag elements SHOULD be spelled as in the IANA registry at http://www.iana.org/assignments/language-subtag-registry. > > In the case of US English used in the example, the recommended spelling appears to be "en-US". > > -- Mike > > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Stephane Bortzmeyer > Sent: Friday, March 15, 2013 8:19 AM > To: webfinger@ietf.org > Cc: ietf-languages@alvestrand.no > Subject: [webfinger] Language tag too specific (Was: Last Call: (WebFinger) to Proposed Standard > > Another issue with language tags in draft-ietf-appsawg-webfinger-11.txt: > >> "titles" : >> { >> "en-us" : "The Magical World of Bob", >> "fr" : "Le Monde Magique de Bob" >> } > > I understand that the purpose of the example is to show that you are not limited to the primary langauge subtag, you can add other subtags (here, the region "us"). But the example is not well chosen. RFC 5646 says: > >> Use as precise a tag as possible, but no more specific than is >> justified. Avoid using subtags that are not important for >> distinguishing content in an application. >> >> * For example, 'de' might suffice for tagging an email written >> in German, while "de-CH-1996" is probably unnecessarily >> precise for such a task. > > Which seems to apply exactly here (there is nothing US-specific in the sentence). May be, instead: > > "titles" : > { > "en-us" : "The Magical Theater of Bob", > "en-gb" : "The Magical Theatre of Bob", > "fr" : "Le Théâtre Magique de Bob" > } > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From mark.edward.davis@gmail.com Fri Mar 15 09:06:26 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7058221F87B3 for ; Fri, 15 Mar 2013 09:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0PdJhxgxE+L for ; Fri, 15 Mar 2013 09:06:25 -0700 (PDT) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9706D21F8461 for ; Fri, 15 Mar 2013 09:06:25 -0700 (PDT) Received: by mail-ia0-f176.google.com with SMTP id i18so3292125iac.7 for ; Fri, 15 Mar 2013 09:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ntpaAYvQqPIoSS3bEANVENmX1/d7Wnb6CjXxT6qwmQ4=; b=xG4qOwIHqscUtzbMcFbJVzYc27rdrINIaa60RYUUwhJ4+LuBaOjme5KVjPA+IAlQvc s6OjvJiWIagw6fWKQLv/b3JgONyGDDGolX2yKjx0DMGcFNka2viAnEGIdilwG26Ih25a zbFVfhuMmeMyVmf0/BV6xJRMRf2D0J4lf6UHKg+bjG43H3y430yOOLKxioDCbd0vvqRq Wl5E3Ee2YflgPgJ1tYHV5IC4xmRPBi4SMxTh+XHPmQYSaEZNkTHP77neHiDZCwip5gdU wQ138+ZKUbkZBEkLivyhMWfLLUu/eTuftCZvc8dRflqDyGVyqhB7/lHQNyzwfwQFzfuw tqfg== MIME-Version: 1.0 X-Received: by 10.42.67.10 with SMTP id r10mr5097670ici.7.1363363585228; Fri, 15 Mar 2013 09:06:25 -0700 (PDT) Sender: mark.edward.davis@gmail.com Received: by 10.231.46.129 with HTTP; Fri, 15 Mar 2013 09:06:25 -0700 (PDT) In-Reply-To: <20130315151847.GA29361@laperouse.bortzmeyer.org> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <20130315151847.GA29361@laperouse.bortzmeyer.org> Date: Fri, 15 Mar 2013 17:06:25 +0100 X-Google-Sender-Auth: 3Ps5osFYgDERlUAr3X3Cj8CqhFA Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=20cf3030bd2932906604d7f8d2d8 X-Mailman-Approved-At: Mon, 18 Mar 2013 12:12:19 -0700 Cc: webfinger@ietf.org, ietf-languages@alvestrand.no Subject: Re: [webfinger] Language tag too specific (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:06:26 -0000 --20cf3030bd2932906604d7f8d2d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't think that's an improvement. If I speak en-AU, which do I get? Better would be just: "titles" : { "en" : "The Magical Theater of Bob", "fr" : "Le Th=C3=A9=C3=A2tre Magique de Bob" } Mark * * *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* ** On Fri, Mar 15, 2013 at 4:18 PM, Stephane Bortzmeyer wro= te: > Another issue with language tags in draft-ietf-appsawg-webfinger-11.txt: > > > "titles" : > > { > > "en-us" : "The Magical World of Bob", > > "fr" : "Le Monde Magique de Bob" > > } > > I understand that the purpose of the example is to show that you are > not limited to the primary langauge subtag, you can add other subtags > (here, the region "us"). But the example is not well chosen. RFC 5646 say= s: > > > Use as precise a tag as possible, but no more specific than is > > justified. Avoid using subtags that are not important for > > distinguishing content in an application. > > > > * For example, 'de' might suffice for tagging an email written > > in German, while "de-CH-1996" is probably unnecessarily > > precise for such a task. > > Which seems to apply exactly here (there is nothing US-specific in the > sentence). May be, instead: > > "titles" : > { > "en-us" : "The Magical Theater of Bob", > "en-gb" : "The Magical Theatre of Bob", > "fr" : "Le Th=C3=A9=C3=A2tre Magique de Bob" > } > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > --20cf3030bd2932906604d7f8d2d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think that's an improvement. If I = speak en-AU, which do I get? Better would be just:

"titles" :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"en" : "The Magical Theate= r of Bob",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"fr" : &= quot;Le Th=C3=A9=C3=A2tre Magique de Bob"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}



=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94


On Fri, Mar 15, 2013 at 4:18 PM, Stephan= e Bortzmeyer <bortzmeyer@nic.fr> wrote:
Another issue with language tags in draft-ietf-appsawg-webfinger-11.txt:
> "titles" :
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "en-us" : &= quot;The Magical World of Bob",
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "fr" : &quo= t;Le Monde Magique de Bob"
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

I understand that the purpose of the example is to show that you are
not limited to the primary langauge subtag, you can add other subtags
(here, the region "us"). But the example is not well chosen. RFC = 5646 says:

> =C2=A0 =C2=A0 =C2=A0Use as precise a tag as possible, but no more spec= ific than is
> =C2=A0 =C2=A0 =C2=A0justified. =C2=A0Avoid using subtags that are not = important for
> =C2=A0 =C2=A0 =C2=A0distinguishing content in an application.
>
> =C2=A0 =C2=A0 =C2=A0 * For example, 'de' might suffice for tag= ging an email written
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in German, while "de-CH-1996&qu= ot; is probably unnecessarily
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0precise for such a task.

Which seems to apply exactly here (there is nothing US-specific in the
sentence). May be, instead:

"titles" :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"en-us" : = "The Magical Theater of Bob",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"en-gb" : = "The Magical Theatre of Bob",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"fr" : &qu= ot;Le Th=C3=A9=C3=A2tre Magique de Bob"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
_______________________________________________
Ietf-languages mailing list
Ietf-languages@alvestrand.n= o
http://www.alvestrand.no/mailman/listinfo/ietf-languages

--20cf3030bd2932906604d7f8d2d8-- From mark.edward.davis@gmail.com Fri Mar 15 12:38:44 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA94B21F852A for ; Fri, 15 Mar 2013 12:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZ7+iP4Gg51a for ; Fri, 15 Mar 2013 12:38:42 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 653FF21F8514 for ; Fri, 15 Mar 2013 12:38:42 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id 10so4872411ied.16 for ; Fri, 15 Mar 2013 12:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rIXPm8+CvmSTEXA12Fo+V9lAc8XJaPLwsOG6KrKzcLk=; b=OGdTT+trhNm+wz3N4BdvygPGtNGexBV/j+U2i2sAg6KhXwxQ0v7Y21qkI5Z/6F/akZ BNNi9j7phsLmjnUSTzHIzqB08fw3fGxosPJMKXmixqffrhFRAutdKTSqG/RdMTC/6/oz EPJ+D3h9q6npJfMy0K+TOlAeS8N+KE9HcO38LzYOVrLYga0JKfnTGTioOiYpTCTi2QaB 6t953aGP7u14GlOEsBtik5MWSap93AY51BPdKP3Hxt4/LAVJm0Yne47spmR9vn0ofoYq Avar7gqjnYA7u1qbOwFgrvUkdrV9p0AjCAmAPS2mNo9EoqppZiCGSvv/zUglUm4/kqNc 9WCA== MIME-Version: 1.0 X-Received: by 10.50.150.228 with SMTP id ul4mr2242532igb.9.1363376322072; Fri, 15 Mar 2013 12:38:42 -0700 (PDT) Sender: mark.edward.davis@gmail.com Received: by 10.231.46.129 with HTTP; Fri, 15 Mar 2013 12:38:41 -0700 (PDT) Received: by 10.231.46.129 with HTTP; Fri, 15 Mar 2013 12:38:41 -0700 (PDT) In-Reply-To: <20130315172630.GG21594@mercury.ccil.org> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <20130315151847.GA29361@laperouse.bortzmeyer.org> <20130315172630.GG21594@mercury.ccil.org> Date: Fri, 15 Mar 2013 20:38:41 +0100 X-Google-Sender-Auth: RmDrdLU-W28HbV50gS2bk3_Or-M Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: John Cowan Content-Type: multipart/alternative; boundary=f46d043c7b605f62d404d7fbc9fc X-Mailman-Approved-At: Mon, 18 Mar 2013 12:12:32 -0700 Cc: webfinger@ietf.org, Stephane Bortzmeyer , ietf-languages@alvestrand.no Subject: Re: [webfinger] Language tag too specific X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 19:38:44 -0000 --f46d043c7b605f62d404d7fbc9fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Your formulation points out that the results depend heavily on the matching algorithm. Without context I don't know what that is. We, for example, identify en with the most populous country, eg the US. {phone} On Mar 15, 2013 6:26 PM, "John Cowan" wrote: > Mark Davis =E2=98=95 scripsit: > > > "titles" : > > { > > "en" : "The Magical Theater of Bob", > > "fr" : "Le Th=C3=A9=C3=A2tre Magique de Bob" > > } > > Less than half of all anglophones will like that less than half as well > as it might deserve, abstractly considered. How about this? > > "titles" : > { > "en-us" : "The Magical Theater of Bob", > "en" : "The magical theatre of Bob", > "fr" : "Le th=C3=A9=C3=A2tre magique de Bob" > } > > In that way, all non-Yank anglophones get the right answers for them. > Of course, you can't always count on such a piece of luck. > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > The native charset of SMS messages supports English, French, mainland > Scandinavian languages, German, Italian, Spanish with no accents, and > GREEK SHOUTING. Everything else has to be Unicode, which means you get > only 70 16-bit characters in a text instead of 160 7-bit characters. > --f46d043c7b605f62d404d7fbc9fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Your formulation points out that the results depend heavily = on the matching algorithm.
Without context I don't know what that is.

We, for example, identify en with the most populous country,= eg the US.

{phone}

On Mar 15, 2013 6:26 PM, "John Cowan" = <cowan@mercury.ccil.org>= ; wrote:
Mark Davis =E2=98=95 scripsit:

> "titles" :
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"en" = : "The Magical Theater of Bob",
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"fr" = : "Le Th=C3=A9=C3=A2tre Magique de Bob"
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

Less than half of all anglophones will like that less than half as well
as it might deserve, abstractly considered. =C2=A0How about this?

"titles" :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "en-us" := "The Magical Theater of Bob",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "en" : &q= uot;The magical theatre of Bob",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "fr" : &q= uot;Le th=C3=A9=C3=A2tre magique de Bob"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

In that way, all non-Yank anglophones get the right answers for them.
Of course, you can't always count on such a piece of luck.

--
John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ccil.org/~cowan =C2=A0 =C2=A0 =C2= =A0 =C2=A0 cowan@ccil.org
The native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING. =C2=A0Everything else has to be Unicode, which means you ge= t
only 70 16-bit characters in a text instead of 160 7-bit characters.
--f46d043c7b605f62d404d7fbc9fc-- From dave@cridland.net Mon Mar 18 03:16:48 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D66521F8C93 for ; Mon, 18 Mar 2013 03:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQuIcdSBjM+H for ; Mon, 18 Mar 2013 03:16:47 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1B48D21F871C for ; Mon, 18 Mar 2013 03:16:47 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id ef5so5007525obb.39 for ; Mon, 18 Mar 2013 03:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tywQsARn8aQJEBfwGP9zrRVYT4SI7ZLJkBx0zpFTiNg=; b=G4FBsVamqtJpfmwfrYJQnKSzCG/Y6IL+C7RD6r623CRdDfMfCE5dutkqHIYttSMD10 SFD0uNfkoHWAmZnY2YfrmQN3vtUy0faXaqboetRm+Qix3SkIREmb3tphExQ6ALs1tf25 nX/zkNk33AyU58FN0+W4hqH0zCXS4RCNGi6S8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=tywQsARn8aQJEBfwGP9zrRVYT4SI7ZLJkBx0zpFTiNg=; b=ZsCCr0LC8OOyhIdJvM9wy9ZDCOaqxqTIEjLFDGgMxDL6xKqqmGf8IWwg9XZP4hsy28 vfkXS+jOS4dKI4vf0QlRQdTp/RCIsa267baFT4bX80bL5O7ojIcZLn3dgqVL/dUpeekw SHxMzaZwNwyoF6T4NSB99yjfU5bv+tMXzwScXBX1WIXuTIpYvW2i92SaBDGmhnODxPdr biqLZoQOdazvWDVcjIcm8/UWmwooC2Mt92x0mqZXoa803q51ppgoWeCh+XfZ3XUp2d2z pi/4dJR/UOa904NKsWhpPwuWQokBgMtDzJjP+aqADKCfu5foQpzbY5OzisK8Rh9tThe5 KgQA== MIME-Version: 1.0 X-Received: by 10.182.72.5 with SMTP id z5mr6566154obu.24.1363601806677; Mon, 18 Mar 2013 03:16:46 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Mon, 18 Mar 2013 03:16:46 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Mon, 18 Mar 2013 03:16:46 -0700 (PDT) In-Reply-To: <20130315151027.GB28881@laperouse.bortzmeyer.org> References: <20130315151027.GB28881@laperouse.bortzmeyer.org> Date: Mon, 18 Mar 2013 10:16:46 +0000 Message-ID: From: Dave Cridland To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=f46d044785334d6eee04d830496f X-Gm-Message-State: ALoCoQluVYLU2Ak36+tYhDmU17I1QfA8Oy4xA0xX9ggE0/BzBK31p1AuJC6cc6FKbrmmzU0ExiXp X-Mailman-Approved-At: Mon, 18 Mar 2013 12:12:32 -0700 Cc: webfinger@ietf.org Subject: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:16:48 -0000 --f46d044785334d6eee04d830496f Content-Type: text/plain; charset=ISO-8859-1 On 15 Mar 2013 15:10, "Stephane Bortzmeyer" wrote: > > On Mon, Mar 11, 2013 at 03:23:20PM +0000, > Dave Cridland wrote > a message of 150 lines which said: > > > 1) There's some suggestions that webfinger could be used for email > > autoconfig; I suspect this is at best going to cause confusion > > Indeed, the example with IMAP in 3.3 confuses me. Why is is better > than the standard RFC 6186? There's also aggsrv, and of course ACAP. It's aggsrv I'm concerned about here, since it's likely to be close to, but current from, the design outlined here. The likelihood for confusion will be very high. > > --f46d044785334d6eee04d830496f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 15 Mar 2013 15:10, "Stephane Bortzmeyer" <bortzmeyer@nic.fr> wrote:
>
> On Mon, Mar 11, 2013 at 03:23:20PM +0000,
> =A0Dave Cridland <dave@cridlan= d.net> wrote
> =A0a message of 150 lines which said:
>
> > 1) There's some suggestions that webfinger could be used for = email
> > autoconfig; I suspect this is at best going to cause confusion >
> Indeed, the example with IMAP in 3.3 confuses me. Why is is better
> than the standard RFC 6186?

There's also aggsrv, and of course ACAP. It's aggsrv= I'm concerned about here, since it's likely to be close to, but cu= rrent from, the design outlined here. The likelihood for confusion will be = very high.

>
>

--f46d044785334d6eee04d830496f-- From mark.edward.davis@gmail.com Mon Mar 18 07:51:44 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6973F21F8F25 for ; Mon, 18 Mar 2013 07:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.014 X-Spam-Level: X-Spam-Status: No, score=-1.014 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJQLFD89-+L5 for ; Mon, 18 Mar 2013 07:51:43 -0700 (PDT) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC6321F8F1C for ; Mon, 18 Mar 2013 07:51:43 -0700 (PDT) Received: by mail-ia0-f173.google.com with SMTP id h37so5361573iak.4 for ; Mon, 18 Mar 2013 07:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lW7PpkO25uQEtwuDsv9v7XoWj1m4ZNEed9Wg42Sh8Kw=; b=Q6slIUvZPkkHNLYyuO5xnIXTVeiCQ7RnpPqbgoXHRIDYAEgDmp382zxJ0m3RMxMZvq 8Yfa7ewRK4F4TMjKa+5088M9o/sHrllW7hlbaQFMVRv1HZUVsq7RJgAMKMIH426gkmz2 rOIxu6TtfqetCiuUrfxsOA7WCaRu+AYEtCvI/Zae42FG3kvcKQ6AyV8IthiYEtFGuITe bVqXu/FqfMfV5/9cB+DKAi0dMGKx15aywWhSVtlaiJF5EGUREmJzRSTcCd3m5FClzp7B L//aDKgIeFJFlesuUkvUkinqfv4j5a6aqu4749xzjPuMXWFfT2QOnI2mtGe+BzGRiIjr 2hJw== MIME-Version: 1.0 X-Received: by 10.42.133.133 with SMTP id h5mr8999426ict.45.1363618302878; Mon, 18 Mar 2013 07:51:42 -0700 (PDT) Sender: mark.edward.davis@gmail.com Received: by 10.231.46.129 with HTTP; Mon, 18 Mar 2013 07:51:42 -0700 (PDT) In-Reply-To: <20130318143945.GK300@mercury.ccil.org> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <20130315151847.GA29361@laperouse.bortzmeyer.org> <20130315172630.GG21594@mercury.ccil.org> <20130318143945.GK300@mercury.ccil.org> Date: Mon, 18 Mar 2013 15:51:42 +0100 X-Google-Sender-Auth: vTC9GUxw1NbeoPEMfLv7ZyFQxCk Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: John Cowan Content-Type: multipart/alternative; boundary=90e6ba5bc09d8d6b5b04d83420bf X-Mailman-Approved-At: Mon, 18 Mar 2013 12:12:32 -0700 Cc: webfinger@ietf.org, Stephane Bortzmeyer , ietf-languages@alvestrand.no, "Phillips, Addison" Subject: Re: [webfinger] Language tag too specific X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:51:44 -0000 --90e6ba5bc09d8d6b5b04d83420bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you are referring to RFC 4647, =E2=80=8BI'm reasonably familiar with it,= being one of the editors. I=E2=80=8B=E2=80=8B=E2=80=8Bt=E2=80=8B is well recogniz= ed that it often doesn't produce the best results. It is more a =E2=80=8Bminimum bar than the be-all-and-end= -all. As for "ad hoc proprietary algorithm". Not so much; we use the algorithms =E2=80=8Bfrom Unicode LDML. Mark * * *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* ** On Mon, Mar 18, 2013 at 3:39 PM, John Cowan wrote: > Mark Davis =E2=98=95 scripsit: > > > We, for example, identify en with the most populous country, eg the US. > > Well, that's because you use an ad-hoc proprietary algorithm rather than > any of the three standard ones. > > -- > Kill Gorgun! Kill orc-folk! John Cowan > No other words please Wild Men. cowan@ccil.org > Drive away bad air and darkness http://www.ccil.org/~cowan > with bright iron! --Ghan-buri-Ghan http://www.ccil.org/~cowan > --90e6ba5bc09d8d6b5b04d83420bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you are referring to RFC 4647, =E2=80=8BI'= ;m reasonably familiar with it, being one of the editors. I=E2=80=8B=E2=80= =8B=E2=80=8Bt=E2=80=8B is well recognized that it often doesn't produce= the best results. It is more a =E2=80=8Bminimum bar than the be-all-and-en= d-all.

As for "ad hoc proprietary algorithm". Not so= much; we use the algorithms
=E2=80=8Bfrom
=C2= =A0Unicode LDML.=C2=A0




=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94


On Mon, Mar 18, 2013 at 3:39 PM, John Co= wan <cowan@mercury.ccil.org> wrote:
Mark Davis =E2=98=95 scripsit:

> We, for example, identify en with the most populous country, eg the US= .

Well, that's because you use an ad-hoc proprietary algorithm rath= er than
any of the three standard ones.

--
Kill Gorgun! =C2=A0Kill orc-folk! =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= John Cowan
No other words please Wild Men. =C2=A0 =C2=A0 =C2=A0 =C2=A0 cowan@ccil.org
Drive away bad air and darkness =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ccil.org/~cowan with bright iron! =C2=A0 --Ghan-buri-Ghan =C2=A0 =C2=A0http://www.ccil.org/~cowan

--90e6ba5bc09d8d6b5b04d83420bf-- From cowan@ccil.org Fri Mar 15 10:26:35 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A96621F8749 for ; Fri, 15 Mar 2013 10:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BJB-qESkKCf for ; Fri, 15 Mar 2013 10:26:35 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id F0C1021F84A9 for ; Fri, 15 Mar 2013 10:26:34 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UGYOk-0002hM-DS; Fri, 15 Mar 2013 13:26:30 -0400 Date: Fri, 15 Mar 2013 13:26:30 -0400 From: John Cowan To: Mark Davis =?utf-8?B?4piV?= Message-ID: <20130315172630.GG21594@mercury.ccil.org> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <20130315151847.GA29361@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan X-Mailman-Approved-At: Mon, 18 Mar 2013 12:13:21 -0700 Cc: webfinger@ietf.org, Stephane Bortzmeyer , ietf-languages@alvestrand.no Subject: Re: [webfinger] Language tag too specific X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:26:35 -0000 Mark Davis ☕ scripsit: > "titles" : > { > "en" : "The Magical Theater of Bob", > "fr" : "Le Théâtre Magique de Bob" > } Less than half of all anglophones will like that less than half as well as it might deserve, abstractly considered. How about this? "titles" : { "en-us" : "The Magical Theater of Bob", "en" : "The magical theatre of Bob", "fr" : "Le théâtre magique de Bob" } In that way, all non-Yank anglophones get the right answers for them. Of course, you can't always count on such a piece of luck. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org The native charset of SMS messages supports English, French, mainland Scandinavian languages, German, Italian, Spanish with no accents, and GREEK SHOUTING. Everything else has to be Unicode, which means you get only 70 16-bit characters in a text instead of 160 7-bit characters. From cowan@ccil.org Mon Mar 18 07:39:47 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A7A21F8F0E for ; Mon, 18 Mar 2013 07:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHSNjaMuKfDi for ; Mon, 18 Mar 2013 07:39:46 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id A896B21F8F0A for ; Mon, 18 Mar 2013 07:39:46 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UHbE1-0004SZ-L2; Mon, 18 Mar 2013 10:39:45 -0400 Date: Mon, 18 Mar 2013 10:39:45 -0400 From: John Cowan To: Mark Davis =?utf-8?B?4piV?= Message-ID: <20130318143945.GK300@mercury.ccil.org> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <20130315151847.GA29361@laperouse.bortzmeyer.org> <20130315172630.GG21594@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan X-Mailman-Approved-At: Mon, 18 Mar 2013 12:13:22 -0700 Cc: webfinger@ietf.org, Stephane Bortzmeyer , ietf-languages@alvestrand.no Subject: Re: [webfinger] Language tag too specific X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:39:47 -0000 Mark Davis ☕ scripsit: > We, for example, identify en with the most populous country, eg the US. Well, that's because you use an ad-hoc proprietary algorithm rather than any of the three standard ones. -- Kill Gorgun! Kill orc-folk! John Cowan No other words please Wild Men. cowan@ccil.org Drive away bad air and darkness http://www.ccil.org/~cowan with bright iron! --Ghan-buri-Ghan http://www.ccil.org/~cowan From mark.edward.davis@gmail.com Mon Mar 18 23:10:14 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E4121F893B for ; Mon, 18 Mar 2013 23:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CleOkdwkGEGJ for ; Mon, 18 Mar 2013 23:10:13 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id C12F621F8936 for ; Mon, 18 Mar 2013 23:10:12 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so76749wib.4 for ; Mon, 18 Mar 2013 23:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U5+yr2cSGWtilNRwR3kLn0bJX4bqFQ3xmi5icG7rdXg=; b=PU95vw+3LbvFHBN1Zh9bhB6SZx1LnY7tBZqeCDt3O7U2qUXW2pOZvk0qEFVern8nJh kQ62zjRC5Xl9pNAdaHqJs2K0XBDJXmWKsr1uz1sEVrJiSXU6UaD/fdbf7t039ZmsW0Pq 6Ur5a3Af1Ir6wVtzAgf54NagbzYYdsPxWbQAekQCGiGBLRX0dNFADEMz+BzV+il2OqRO rXiwGzaH0pu5YKLEMRJrmIvS3OpHv8rChLCjXA6g6YhJIOKaDJysAnkTPJKxOVJpyvDl seEMp+DetIQ0eB5UVQuPDkV8GAqDIMxCsMEw8OIKQLDXQq9BaXkdUg5Ykx+YLoqg9y/0 hw1Q== MIME-Version: 1.0 X-Received: by 10.194.237.129 with SMTP id vc1mr920143wjc.20.1363673411884; Mon, 18 Mar 2013 23:10:11 -0700 (PDT) Sender: mark.edward.davis@gmail.com Received: by 10.180.146.129 with HTTP; Mon, 18 Mar 2013 23:10:11 -0700 (PDT) In-Reply-To: <45230706.36494.1363630572888.JavaMail.www@wwinf1k12> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <20130315151847.GA29361@laperouse.bortzmeyer.org> <20130315172630.GG21594@mercury.ccil.org> <45230706.36494.1363630572888.JavaMail.www@wwinf1k12> Date: Tue, 19 Mar 2013 07:10:11 +0100 X-Google-Sender-Auth: mEQHzgyh0loJ8n_WkZAf3T8WIAw Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: Richard BUDELBERGER Content-Type: multipart/alternative; boundary=089e013d14ae4e1eaa04d840f577 Cc: webfinger@ietf.org, John Cowan , ietf-languages@alvestrand.no Subject: Re: [webfinger] Language tag too specific X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 06:10:14 -0000 --089e013d14ae4e1eaa04d840f577 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Normally you would not mark different names according to their source language. Markup as follows would be pedantic, and more likely screw up any software reading it than have a positive effect. I gave a book to my friend Pierre Schmidt. Note also that often titles of movies, plays, etc are either untranslated, partially translated, or untranslated, such as where I live: http://www.google.ch/movies?hl=3Dde&near=3DZurich&dq=3Dmovies&sort=3D1&q=3D= movies&sa=3DX&ei=3D6QBIUfD3Hs29Pcm1gfgN&ved=3D0CCoQxQMoAA Mark * * *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* ** On Mon, Mar 18, 2013 at 7:16 PM, Richard BUDELBERGER < budelberger.richard@wanadoo.fr> wrote: > > Message du 15/03/13 18:27 > > De : "John Cowan" > > A : "Mark Davis" > > Copie =C3=A0 : webfinger@ietf.org, ietf-languages@alvestrand.no > > Objet : Re: Language tag too specific > > > >> Mark Davis scripsit: > >> "titles" : > >> { > >> "en" : "The Magical Theater of Bob", > >> "fr" : "Le Th=C3=A9=C3=A2tre Magique de Bob" > >> } > > >Less than half of all anglophones will like that less than half as well > as it might deserve, > >abstractly considered. How about this? > > > >"titles" : > >{ > >"en-us" : "The Magical Theater of Bob", > >"en" : "The magical theatre of Bob", > >"fr" : "Le th=C3=A9=C3=A2tre magique de Bob" > >} > > > >In that way, all non-Yank anglophones get the right answers for them. > >Of course, you can't always count on such a piece of luck. > > =C2=ABBob=C2=BB being an unFrench name: > > "titles" : > { > "en-us" : "The Magical Theater of Bob", > "en" : "The magical theatre of Bob", > "fr" : "Le th=C3=A9=C3=A2tre magique de" "en-us" : "Bob" > } > --089e013d14ae4e1eaa04d840f577 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Normally you would not mark different names accord= ing to their source language. Markup as follows would be pedantic, and more= likely screw up any software reading it than have a positive effect.

<span lang=3D"en">I gave a = book to my friend </span><span lang=3D"fr">Pierre<= /span> <span lang=3D"de">Schmidt</span>.

Note also that often= titles of movies, plays, etc are either untranslated, partially translated= , or untranslated, such as where I live:

http://www.google.ch/movies?hl=3Dde&ne= ar=3DZurich&dq=3Dmovies&sort=3D1&q=3Dmovies&sa=3DX&ei= =3D6QBIUfD3Hs29Pcm1gfgN&ved=3D0CCoQxQMoAA



=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94


On Mon, Mar 18, 2013 at 7:16 PM, Richard= BUDELBERGER <budelberger.richard@wanadoo.fr> w= rote:
> Message du 15/03/13 18:27
> De : "John Cowan"
> A : "Mark Davis"
> Copie =C3=A0 : webfinger@ietf.or= g, ietf-languages@alves= trand.no
> Objet : Re: Language tag too specific
>
>> Mark Davis scripsit:
>> "titles" :
>> {
>> "en" : "The Magical Theater of Bob",
>> "fr" : "Le Th=C3=A9=C3=A2tre Magique de Bob" >> }

>Less than half of all anglophones will like that less than half as well= as it might deserve,
>abstractly considered. How about this?
>
>"titles" :
>{
>"en-us" : "The Magical Theater of Bob",
>"en" : "The magical theatre of Bob",
>"fr" : "Le th=C3=A9=C3=A2tre magique de Bob"
>}
>
>In that way, all non-Yank anglophones get the right answers for them. >Of course, you can't always count on such a piece of luck.

=C2=ABBob=C2=BB being an unFrench name:

"titles" :
{
"en-us" : "The Magical Theater of Bob",
"en" : "The magical theatre of Bob",
"fr" : "Le th=C3=A9=C3=A2tre magique de" "en= -us" : "Bob"
}

--089e013d14ae4e1eaa04d840f577-- From mark.edward.davis@gmail.com Tue Mar 19 09:38:42 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8B221F8498 for ; Tue, 19 Mar 2013 09:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, DC_IMAGE_SPAM_HTML=0.001, DC_IMAGE_SPAM_TEXT=0.001, DC_PNG_UNO_LARGO=0.558, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id makQPgNvzExC for ; Tue, 19 Mar 2013 09:38:41 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2635521F8D8E for ; Tue, 19 Mar 2013 09:38:41 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id j5so598455iaf.0 for ; Tue, 19 Mar 2013 09:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CR6zRNWMH5+W+4ZseVagyx2ep8T0CqRp0Xbt+CZBCNs=; b=xRyGoUYPjzC6iAhJtNOGfXhwtjAbMeZP3IR/1qFDIXoK3AQcYjo/EyDQ2AZteD/lKx mW24+eRWWUVo9mdUNBmjJcyLt9tCheeBhOewpW+3w525bmfFz/QCQ/qZl31q4QM3TiL3 SYcCR8T76DtIf+GiKeRtUIE4TRE0VZsgokCAoQzGtFAT/ruzr7gtUGCOlS4k8VKC1bjd q5nknGMM/So4V37fSzOt4HCoBRXIZrqb9/NoE2AQYgO1E8QKskMnWp0XnNb8MAihRxRO 29NwXrE/9h3yX/UeFFcfgmS1g7ChYvjT10TX629dIIloVyVEP9rVTkb+MECuQvp7cZgR /HdQ== MIME-Version: 1.0 X-Received: by 10.50.186.134 with SMTP id fk6mr2456633igc.9.1363711117453; Tue, 19 Mar 2013 09:38:37 -0700 (PDT) Sender: mark.edward.davis@gmail.com Received: by 10.231.163.133 with HTTP; Tue, 19 Mar 2013 09:38:37 -0700 (PDT) In-Reply-To: <2063793541.14098.1363709953572.JavaMail.www@wwinf1p25> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <20130315151847.GA29361@laperouse.bortzmeyer.org> <20130315172630.GG21594@mercury.ccil.org> <45230706.36494.1363630572888.JavaMail.www@wwinf1k12> <2063793541.14098.1363709953572.JavaMail.www@wwinf1p25> Date: Tue, 19 Mar 2013 17:38:37 +0100 X-Google-Sender-Auth: ckxHUW1y0n-98xuOyRLDJQpLlo4 Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: Richard BUDELBERGER Content-Type: multipart/related; boundary=14dae9340f2dbb734704d849bc46 Cc: webfinger@ietf.org, John Cowan , ietf-languages@alvestrand.no Subject: Re: [webfinger] Language tag too specific X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:38:42 -0000 --14dae9340f2dbb734704d849bc46 Content-Type: multipart/alternative; boundary=14dae9340f2dbb734504d849bc45 --14dae9340f2dbb734504d849bc45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is what I sent. Looks like the mailer munged it. [image: Inline image 1] Mark * * *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* ** On Tue, Mar 19, 2013 at 5:19 PM, Richard BUDELBERGER < budelberger.richard@wanadoo.fr> wrote: > > Message du 19/03/13 07:10 > > De : "Mark Davis =E2=98=95" > > A : "Richard BUDELBERGER" > > Copie =C3=A0 : "John Cowan" , webfinger@ietf.org, > ietf-languages@alvestrand.no > > Objet : Re: Language tag too specific > > > >Normally you would not mark different names according to their source > language. > >Markup as follows would be pedantic, and more likely screw up any softwa= re > >reading it than have a positive effect. > > > >I gave a book to my friend Pierre Schmidt. > > I gave a book to my friend Pierre Schmidt. > !!!=E2=80=A6 > --14dae9340f2dbb734504d849bc45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is what I sent. Looks like the mailer munged = it.

3D"Inline



=E2=80=94 Il meglio = =C3=A8 l=E2=80=99inimico del bene =E2=80=94


On Tue, Mar 19, 2013 at 5:19 PM, Richard= BUDELBERGER <budelberger.richard@wanadoo.fr> w= rote:
> Message du 19/03/13 07:10
> De : "Mark Davis =E2=98=95"
> A : "Richard BUDELBERGER"
> Copie =C3=A0 : "John Cowan" , webfinger@ietf.org, ietf-languages@alvestrand.no
> Objet : Re: Language tag too specific
>
>Normally you would not mark different names acc= ording to their source language.
>Markup as follows would be pedantic, and more likely screw up any softw= are
>reading it than have a positive effect.
>
>I gave a book to my friend Pierre Schmidt.

I gave a book to my friend Pierre Schmidt.
!!!=E2=80=A6

--14dae9340f2dbb734504d849bc45-- --14dae9340f2dbb734704d849bc46 Content-Type: image/png; name="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_13d838419644edd4 iVBORw0KGgoAAAANSUhEUgAABbwAAADMCAIAAAA3XvJ/AAAME2lDQ1BJQ0MgUHJvZmlsZQAASA2t V2dYU8kanlOSQEhogQhICb0jvUrvRUGqYCMkgYQSQyCIiA1ZVHDtIgI2ZEHEthZAFhWxIMoi2Pui iIKyLhZsqNw5FHXv3v13z/PMnPe8837ffPPNnHlmAJDtZItEqag8AGnCTHG4vxdrZmwci/IAoIAO 5IAScGRzMkSeYWEh4F+fdzcBQjReMyd8/avsfzcocHkZHACQMNicwM3gpEF8DACsgSMSZwJAIvzp LcgUEXg9xEpiGCDElQROGsMNBE4Yw+2jmshwb6jpBkCKxmaLkwCgD0CelcVJgn5kaRBbCrkCIcRT IXbj8NlciHMhNktLm0/gvRAbJfzgJ+kHzGYnfPPJZid9w2NjgZawYx9BhiiVvXD04/9ZpaVKYL5G H01Y0zJSIoLhmwnzls1h+0ZArALxWj4vMGScrxJleoWP802CzMBIiJWg5jpfEhA1jvskKVGeEKtD /nPK/GBCD/OEqggTpodCrAixHifDG+ae6Au1z+FHxoxrQrg8H1+I4SpCZ4rnh0/o+RlZERN8Tg7f e/qEPpkdRMy3LNQXssUQjcaDlvBS/Yl+dSC/X5QZRsRJ9NUhTJ0+Phb0SaLYj9AQ/Cdexuh4idj4 mfzIAMjDmDH5THEkoYFjxNQTBX6BEMPYMEu+OGCC9xCljq5paItFiiXhRB70IE7kCaOIHBJ8IZft Q+QW5gQrB36ADcSABxKAEPQDFggB3sBnvGZBXgg5DpgPUmERs+QmWkhPSV2kx6QbpG7SnQkOWo7r gABwIR7z9YM95CNADvgTeuWBjInecDXcDXfBQ2DtAYs17og7TbR1DNQPTODxWJOgrfm4b6/x6LOg xy8TunmCPPEEHrdJ+Gbxz5j8wBOYgaQJhWWtZb/l5wn77yMm+5J9yAFkP7Ixtgo7irViZ7A2rAmr ByzsNNaAtWMnCTwe10QvbMgQWSEynAGCYRZ5QDL6JZzo729ZknxTjHuQNZG1A+HQSghSYJvgWw/R o1EL/uFFAhUJsMdkqA3+Nh/jceEGMLt2uBfuCvMMc4wzcTVgjtvCjHvi7nAO7CD7fRb/PhpzkDia 7azRsaSAp3AcaZm87Ey4loD3fNFCsSCJn8nyhLslz4wVKORYmLGsLa1sALH3EhoA3jBH91SEeek7 l94MgFMh/D+JbY9FqABg6wJw4ikAjHffOd3X8DeAe+XJTo5EnDWmw4kXCVBH93RVoAl0gRHMiDWw By7AA/iCIBAKIkEsmAvXMB+kwYgXgFywHBSAIrAebAGlYCfYA/aCA+AIqAdN4Ay4AC6DTnAD3APd oBe8AIPgHRhGEISC0BEGoopoIfqIKWKNOCJuiC8SgoQjsUg8koQIEQmSi6xAipCNSCmyG6lBfkVO IGeQNqQLuYM8QvqR18gnFENpqBKqgRqgU1BH1BMNRiPROWgSmo7moPnoWrQErUD3o3XoGfQyegPt Rl+gQxjAZDAmpo2ZY46YNxaKxWGJmBhbghVixVgFdhBrhGvxGtaNDWAfcTLOwFm4OZzJADwK5+Dp +BJ8DV6K78Xr8HP4NfwRPoh/JdFJ6iRTkjMpkDSTlERaQCogFZOqSMdJ5+H/3Et6RyaTmWRDsgNc 7bHkZPIi8hrydvIhcjO5i9xDHqJQKKoUU4orJZTCpmRSCijbKPsppylXKb2UD1IyUlpS1lJ+UnFS Qqk8qWKpfVKnpK5KPZMalpaX1pd2lg6V5kovlF4nXSndKH1Fuld6mKpANaS6UiOpydTl1BLqQep5 6n3qGxkZGR0ZJ5kZMgKZZTIlModlLso8kvlIU6SZ0Lxps2kS2lpaNa2Zdof2hk6nG9A96HH0TPpa eg39LP0h/YMsQ9ZCNlCWK7tUtky2Tvaq7Es5aTl9OU+5uXI5csVyR+WuyA3IS8sbyHvLs+WXyJfJ n5C/JT+kwFCwUghVSFNYo7BPoU2hT5GiaKDoq8hVzFfco3hWsYeBMXQZ3gwOYwWjknGe0atEVjJU ClRKVipSOqDUoTSorKhsqxytnK1cpnxSuZuJMQ2YgcxU5jrmEeZN5qdJGpM8J/EmrZ50cNLVSe9V Jqt4qPBUClUOqdxQ+aTKUvVVTVHdoFqv+kANVzNRm6G2QG2H2nm1gclKk10mcyYXTj4y+a46qm6i Hq6+SH2Perv6kIamhr+GSGObxlmNAU2mpodmsuZmzVOa/VoMLTctgdZmrdNaz1nKLE9WKquEdY41 qK2uHaAt0d6t3aE9rGOoE6WTp3NI54EuVddRN1F3s26L7qCelt40vVy9Wr27+tL6jvp8/a36rfrv DQwNYgxWGtQb9BmqGAYa5hjWGt43ohu5G6UbVRhdNyYbOxqnGG837jRBTexM+CZlJldMUVN7U4Hp dtMuM5KZk5nQrMLsljnN3NM8y7zW/JEF0yLEIs+i3uLlFL0pcVM2TGmd8tXSzjLVstLynpWiVZBV nlWj1WtrE2uOdZn1dRu6jZ/NUpsGm1e2prY82x22t+0YdtPsVtq12H2xd7AX2x+073fQc4h3KHe4 5ajkGOa4xvGiE8nJy2mpU5PTR2d750znI85/uZi7pLjsc+mbajiVN7Vyao+rjivbdbdrtxvLLd5t l1u3u7Y7273C/bGHrgfXo8rjmaexZ7Lnfs+XXpZeYq/jXu+9nb0Xezf7YD7+PoU+Hb6KvlG+pb4P /XT8kvxq/Qb97fwX+TcHkAKCAzYE3ArUCOQE1gQOBjkELQ46F0wLjgguDX4cYhIiDmmchk4LmrZp 2v3p+tOF0+tDQWhg6KbQB2GGYelhv80gzwibUTbjabhVeG54awQjYl7Evoh3kV6R6yLvRRlFSaJa ouWiZ0fXRL+P8YnZGNM9c8rMxTMvx6rFCmIb4ihx0XFVcUOzfGdtmdU72252weybcwznZM9pm6s2 N3XuyXly89jzjsaT4mPi98V/ZoeyK9hDCYEJ5QmDHG/OVs4Lrgd3M7ef58rbyHuW6Jq4MbEvyTVp U1I/351fzB8QeAtKBa+SA5J3Jr9PCU2pThlJjUk9lCaVFp92QqgoTBGem685P3t+l8hUVCDqTndO 35I+KA4WV2UgGXMyGjKV4CG3XWIk+UnyKMstqyzrw4LoBUezFbKF2e0LTRauXvgsxy/nl0X4Is6i llzt3OW5jxZ7Lt69BFmSsKRlqe7S/KW9y/yX7V1OXZ6y/Pc8y7yNeW9XxKxozNfIX5bf85P/T7UF sgXiglsrXVbuXIWvEqzqWG2zetvqr4XcwktFlkXFRZ/XcNZc+tnq55KfR9Ymru1YZ79ux3ryeuH6 mxvcN+zdqLAxZ2PPpmmb6jazNhdufrtl3pa2YtvinVupWyVbu0tCShq26W1bv+1zKb/0RplX2aFy 9fLV5e+3c7df3eGx4+BOjZ1FOz/tEuy6vdt/d12FQUXxHvKerD1PK6MrW39x/KWmSq2qqOpLtbC6 e2/43nM1DjU1+9T3ratFayW1/ftn7+884HOg4aD5wd2HmIeKDoPDksPPf43/9eaR4CMtRx2PHjym f6z8OON4YR1St7BusJ5f390Q29B1IuhES6NL4/HfLH6rbtJuKjupfHLdKeqp/FMjp3NODzWLmgfO JJ3paZnXcu/szLPXz80413E++PzFC34XzrZ6tp6+6Hqxqc257cQlx0v1l+0v17XbtR//3e734x32 HXVXHK40dDp1NnZN7Tp11f3qmWs+1y5cD7x++cb0G103o27evjX7Vvdt7u2+O6l3Xt3Nujt8b9l9 0v3CB/IPih+qP6z4w/iPQ9323Scf+Txqfxzx+F4Pp+fFk4wnn3vzn9KfFj/TelbTZ93X1O/X3/l8 1vPeF6IXwwMFfyr8Wf7S6OWxvzz+ah+cOdj7Svxq5PWaN6pvqt/avm0ZCht6+C7t3fD7wg+qH/Z+ dPzY+inm07PhBZ8pn0u+GH9p/Br89f5I2siIiC1mj54FMFijiYkAvK6G96JYeHboBIAqO3Y3GlUg Y/c5iJHxQtD/hcfuT0QDPEOAag8AopYBENIMwA5Y9CGmwTdxzI/0AKiNzbcCGeLJSLSxHgUITQyP Jh9GRt5oAEBpBOCLeGRkePvIyJdKeO6+A0Bz+tidjFCT4Tl+F7w3ANDWsWYZ8f7x+Q97yGBxDsgM oAAAAAlwSFlzAAAWJQAAFiUBSVIk8AAAAZ5pVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4Onht cG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3JlIDUuMS4yIj4K ICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1z eW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAg ICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNvbS9leGlmLzEuMC8iPgogICAgICAgICA8 ZXhpZjpQaXhlbFhEaW1lbnNpb24+MTQ2ODwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAg IDxleGlmOlBpeGVsWURpbWVuc2lvbj4yMDQ8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAgICA8 L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KrxQHpAAAQABJREFU eAHsnQt4HMWVqEcP2yMH4zGEWGyysUyyWCZraZQHlpPFGhNAgmSxSC6WzGtkArGyBCTjYPHMspvF ssniByT4AUYjg5GMYyTDBckkeCSy2HKyWCPyxRrn++IZb1hrfBOkMVnUY+615p7q6u7pR1V3z2j0 Pv19trqrq06d89epR9d0V2XE43EHHkgACSABJIAEkAASQAJIAAkgASSABJAAEkACWgKZ2ku8QgJI AAkgASSABJAAEkACSAAJIAEkgASQABIgBHDSBP0ACSABJIAEkAASQAJIAAkgASSABJAAEkACDAI4 acKAgkFIAAkgASSABJAAEkACSAAJIAEkgASQABLASRP0ASSABJAAEkACSAAJIAEkgASQABJAAkgA CTAI4KQJAwoGIQEkgASQABJAAkgACSABJIAEkAASQAJIACdN0AeQABJAAkgACSABJIAEkAASQAJI AAkgASTAIICTJgwoGIQEkAASQAJIAAkgASSABJAAEkACSAAJIAGcNEEfQAJIAAkgASSABJAAEkAC SAAJIAEkgASQAIMATpowoGAQEkACSAAJIAEkgASQABJAAkgACSABJIAEcNIEfQAJIAEkgASQABJA AkgACSABJIAEkAASQAIMApNw0iQWOdHVE1LbagxR352a55ZMouGerp6+yQgnFgx0Bc8IKZumJRML BwOBEwMMabEoZNTVFUjkZQxhJMOgcUrAbrmPU/VBrViwqysYjSWpIN/DkxQ0PqNbtoTjU+3xrdVw 29ixsc52+2z0GWPI2Jgw8rlaWqptJw0KxaLQK4ZjccONsQmw0DZFpcZjmzkylqYIyDyZwceMPFNs YQySzRXBu+OVgO22erwakIRe2pprrAtJiLIRNV3yUxtt2lBwzKPE7R19h54umFZQUeH1wr+Nbwja VKE3n3QULoWbcLcwZ2lbeFB7f5SuBo4f9C6dDkizv76LamgMGSVVxnE2lkx6DzVWFGSrMY5ja5JR bSjqf3YNrXHuHe8lk1KKayQjHN9LBE6/qlsYUgvsO7yDZkT/9za+ZwxRx8fz8UzAfrmPUyuGom2y 528LfJyUkjwPT0rI+Ixs2RKOT7WHp5XQVvfNQs8K0lcvW9HQ1c+TdmTbmpKKO7x3VJQUFtZ3nORF 04cPu43VCxyta5vts9FnjCGjpfJo52NpqbGd1Kg4GGyoW0k7xGRbIY2cNF1YaDuMXMZbmzlylg4D Ejsp08c0PFNtYZiS2Upg6PgmYLOtHt9G2NLOWHM1dcGWjOQipUH+MEabyek6RrHtvmmSu+TuzlOv lDlfb9y7t7HuW1W7j6mfCfOuv1doezp3356Xsq9r7T9YNi9HfXf0zjNmlFXeQ7K7cIaUqTFk9LQZ rzlZMXHmzCuvup1of5lzpGyInkr+F+806OKcv7i+4ssgKN+ZimlGMs7cvJJMR9ZnylwzMhL69b9T +o3VHh+Zl+l9+S4I3/2j3dd9XROy55+7kv3FPyHfztkYEbaj2oSLY7fc02vY8EtQJcF56ZX1Ky4E BZ1OlaPaUJjt4TYSToAoVi3hBDAhaRWdZY//7+Yff6OxsXGv/5W71jRFmRL631n9T5s79+5ufG36 hvYjD5bMZ8ZiBg6zjWXKHPFAQ4vNbZ+NPmMMGXF1xygDK0uN7aRO0Vz3jd7CaRCYbCukk5OWS0tt k8hF1dIS65ijgiTEpTlqOi1Ns2oGcSwf0/FMsYVhSTZkjwHjnoChrX7x4Td6kn5/dtybKSporLm6 upB2M9jyte0bO1NVnJRHm2zJ4y00ucmaoejmL8+kJtR3/Lc2rdB09WxP8++1gaN+df6Ed0Zm9m17 Eu/CGENGXalxl6Elk5OvQClnl72UwJhWG/xVl9Qn+Yt3uvIPibMYlY2pOiqDjKCj1LvnNqDXFKTv Wwndbc3PPL5cF9LSZfvH25QsH0PCKek77hPZKPf02jD8EtRJoJ7fILllUsrqPTypxOM6smVLOK61 T1W582HoJWk/zvzNv/vZ6+jdaXe/kUIew21jU8hyeEmMLbZZ+2z0GWPI8PQZv6ktLWW0kxprmiov AtdKqRXSyEnPhZW2NnPRtbRiqnHWZqbJUptAhhWN7WManim2MGzJw1IWE48yAWNb/ZMbPjVWTxOj YTuj5mrqwgjooJfPat/02eriDGO0qZc83q7tvmlCh1COjBm5LvJDARwPeT7bfsqwMMQ5enPs/j9n +FbWGDJ22o2XnMeUSaz7lWW+P+cl+Yt3utCNwPsd+rdWnBnq11ic7rKKb19+iUp/ElK+OIkfb1Vp bZ2OLWFbKk6GSPpyT6NNwy9Bo4RheP4IWppGaKmIGtOWMBWF05LmXMIX7v331sQFFT74/pY1v6Kn 3/1mXgoZ6gWmIGJ0kxhbbLP22egzxpDR1X/0chuupRPONazRGltaMc3kbTOtkQwvBtvHNDxTdCO2 5OFpi6lHl4Curc6fm/HYmx+P1dPE6Jqu5KapC0po+k408jntmyY3Y5wUa6hG6ji9IEtXJHvUvfxy uOq2vZ8MXe9e3dvXmM97+o2d6Whpbn3rpOPCs84rlld7yxXPjgaP+nY0uWvr807ue3zHIfctdVWL Pmreut25alPV5R81NzZ3dfXmLvNWe5e54mc7mn2tB7sdly6uqqly5yof/sQC7Qd8vpaAY4bbXVx+ U6VnwRxrQ0DaAX9MdIlYLOoqWu6BL4mEU+2vdTtmO2PnZniWL3OppdiMz7QU0u5ti7pcjpgj31Oa 78oIdxzois6Aa+fCEoa26rzOzfaULgy2t0ecLnj+JqouLIUk4Y6DgSjMCsXyiksJirTkq9gLCjRv 376jzTF/sXtIXJLj09w3+aUSrKsvjv/B5/N1/WGouLyqanlRYraAqZvDEfbvnH/1asizva3V1Zvj KiotZn3MFQ0dTYs/GD2tTLEXOA6caO/sdTqdQDg2p7CyZKHqpurUhIxopu9Pf7d93Q3EdlFg+GA3 nLa2troW5Dj/5m9ip09rQmjpC6eat29pPdrnzJnrqayqLCXojNrW3rgQ/JMbk8XfLmFaB1kSRMvZ 9Sv5cnEw9QfXbW/Y6tt72LlkeVlBZvTiG6uv480isTUhSoKQJp/vxWOOz+d6rq+srFgiVV5+uP0W iZC3X+5K2XF5Eg6tjc3NzU2OvBLPTZXlJUWkbpM31cU/5FQ6uCXIqVNyusRfrgTIDr5cjPRs39LQ dSZeXFldXaryeZan0UYm4eGKparWm7DSHSbly7QCUFu1luzawStrpi06JdmXbH+zbvGY5Rs/23XA b9ULsHMk2jFlKj6Tuo0OWIiz5omarY9s/X8v3dr66E2VC5SO1RE88Exjzq0N67NXrW1waH4FYetp LJcyFVhNG+uanxsJmdOIBI+27jzk/nFtXuitLb6WyEezy6qquS0zyYitld0Wxthi0/aZ6aUqu6xP mRLAz5URiJ1e3vWRdTuZrMwxHTlQbs54LNzx2hYfDJDmlq2srlT/hGDPq639hCfHpFXn+JJJ3We3 tGLRq9tMYjWvpbLhScyxrolWkkgzS/W5ptKzMz1cFGxsE3gjGb0ezGsmTzmmpoVRRnG80pdTkc5d qYl2ngVoQtN+zTgascXhusugj5CeSuy0CYmHIAexwqrftK4pChPphN2icv1tBEiyx2mGtjp6NrSy 6n7QWnqacBfHAl3JkMwwq1m6EY6lR4n0bJW4ONrn9lwgx6TmGuoCt1yk0rQaRSjR6IlWPrt90yYx icMfbSbpY9ocx/gqyVdfhIavXNAQGhSO7aR6Z5fuGpBEiJ/nKF899B+FtR4cs25uaGlpWn8LiTz9 Kj8sEDsYrpkpzdQULC00N76wdlNdSWIwlzn3gZC02qZAX/KsaTp05M3tVEhLSPwaYjCo/zxHHQJL 1Ky/hsbPvPap3gHxu4rBcNMTJND90H7ZFpmKnfg8S+NC7yFx6sHhoK9Ah461U3PYq5CSvERQDodn y9vCkHDk5Y1U1YyVTxwR19YNHW4mVF23dw8MxYeTr5oJtXUwWHfBNEfWogb/Yf8L0mqpmq+cZCTq Eiy510s1pP9v7vpQisXTbSjSUFdbsoi831Sw4o4ar7eh87QiWDo5n/AQtXA4T84feoMMT5t18xu+ 74Eo6fOcj0UvdTi8m1/2d3O+l+GTCe2/i2qofMcknDzorfDSZXQdRStqvBVP+ny6kM3tJ4WTByBh xqqn2l71kQJ1ODK92344M4tKS9SLWTcHjreaxGTwt0NYVQcZEkgxsOrXyQRPqqfyP79c4kZLs+/a D74Nn/JBdfZ3d1Nn8yjtht4bWJqINV042QnoMi65t8Xv37xiNihD2yJeOLe+qGioyfd+yK0R+nJX SeDwjEu5u273H+/1P3ungi477+e6b7vivBLk1Sk9sThPAl1ep+K+GiV3ONkckJYCZZZUUOfhKks1 rLSrIBP/4ZUv1wrT1pKTb6C3g+MD+vpFvM4ICkL0LSHL31QtSbLlmzVvc8CiF2DlSPsyyorjM8zy YttoNHwwCNyajvc2LCPL3GSvVa3sLja/lc2/792/Fm6pPmNk6akio/YHfhsbNOsTT5MaLR0FBfIZ +VvRyFu3m6UVocf3QC0NY4sN7TO3raBp9T5j9CK5vhvHP8n18vasSE7m2I0cCD2pvNSFC+de+bNu W15tw0+4cvi9uaKbZlSp8nBG3We11freQfQZbq9EPcrsf5aHm2tFpZlZqs0vlREX38N5bbVhJGOz TWbypH0ZbxRnUvqJpwM7Y3stJ5NWxVi+mVdvrM6xNaLL+t7uA0mN/DVamfabNmqKRhi5SN7f0krS pO3Vt9V3LF95c5XmaaKjN5lnKAtL1T2acRzO8N6kPB/GwOKHiprWRn6G5T2L6euCKkdG60SL1nQU oSt9vXxW+6ZLktJok2W7nTZNn/fYXDuSzJZMmmwTv4qnzRZ0eO6Nb4tCSAcvPfwMRcloDGZJ4Nle PLqfvRViZn3uib4hQRjogwX8Sa+Ztch/vLtp/ap7njt48KlrSQisBNFLBvGhVx+ml+4Nb5CZjUHp gU36FPbjnorpmfCMRMeIvS+QJSRqDvyRZGVjQOOvuxLiu598V1SN/Ne7q5Tx9CLfNotvZilJTw1P fMErfp+mGonKech/22o+Q2xpF22B5KJpHmWrl497YFhJpoeGma+ektDivRjylZfhgHzJzIIyFyBr R/8KwmBEKkFI0g2zHgKNL+lppRv92k3JSyucXIGL+DcN2x9ajxs9rcb3bmAPMQ2eCiCflnVfAyds MVvlwYyMIAh9x/YWZDh0s0tGAzUhQ5F614xpD9NaE49/2AkS4GjsOamrFzUNr/9k9nRGzF45JpM/ VB9x3RY+YasS5NSvpMuFY2lTdweYXN8pTbF1bypmTyOCK3A0gZYaGMKMSS99XBcnocgeRh/3scMH B5JqkWp8/r38GmEodyue4GmiNLkdEOjDataWtwei7OdcfQla1SljJdJLkNckBk9rIW2scERsk6W2 iFNSjcF+rYczWm+oU3ob+o+yy9fKCn5rycpXrB08HzDWmiY6ItGR0rWETH+DlsS8xbMqX75dfA83 l8kpL7aNOpPhkk6awI8fh39Kmh6Ho61P6qn73n4EmkTYC4z6T6Kr4pEx9OaWbSyfhiD0Bzd7LqAq NR05PhAK1BeJv5pMv+qIPJbQWMPUCkYCPA/UJE5caCqLlZdajzGsJNjt5ZOxwq5MK934pSPi0tUX 2UuVvsZ05AASpOEy/Jzm7z09cDpQ7/kUKW5avna92spPuHL6zcY5TF+yrvv63tbQO5BZbHavpJ9r Tjhk4ixFrczGLQnh8lnyPXtyI3zeSIbdXml9jMFT7svYozhu6cNPtvqfVM3G9jKcxF9efWSX7ze6 TuufdEw42K2/CW0SZ/w6a1VTEjLksxT9LZ4mkiZ+JWmoaatZY127JHmWGns0zjjc4L3cUQpjNHK8 i/MMa1ZzDXUhzSNPg3zCXAdcdhTNX2McZX6AMdrkkbcYZWlyHMOL1CdNoP9rq/kaHd+IExaJSRPh j+IyourVWMWnfYhMO1cKtE6eGgD7pZlj+QcHaN3ULqX0tdJTx2AYpuIkRxQiLeJ7ItLwztAsGhtK 6TEVpmzoOExMUqNf11ZVKPSxlhXfpqXyw1Kc7ueUGImqMqGnwrHdQClryc/pOy8D7z5JCLtupw+H MBFId1Mebr46SqcPQibKPs2giSSfvxAsLS9lEUF1/GR1MzAgAenyB56nVWx5teG+T5Ohm/n22JZk dCRFY2imSqEr5tAQaU8vmBpbV+O9r6bmZnHUKM7j6LS1jMnkr8tO1IjxH82LLYFfv2gqcbAiyjSt pzz9K571kXmirEXb/MfJ83b/0c17YQ6LdXA0oZLp/kQk2VC0pb7W+9Ce0O/3giczwv9IwjVzW+Yt UvLlbsZTflRQHi30GA2m0wiKC1nWKYMAqQYpEiACW0PxFQxeSZGCNng4laNuvfW5nxbnAQ3la2mF 3mpxP2+ltdTla+4DUNzG+qXXE6511nH8jUtPaiGlR0Fe+ZrZxc3RTKZZeTGMNASJkybEN86TnhRY Sb98wELvFzmzxV9BqM4KfHjBkNfn6spFYcVrY81oyDVFmVGFzpq+frJNfiVKYwxPK44HatKqLtQq WXqp3mdAjtaLLCXY7OXjyVhhU6albmoUYBn1NJUbaB87LdtJFWTxVPJqpd8BdDDSAw+EkGS8WpLD 9BOenIpnyZu/3HEOz5d4Lac8OtIRI2bq/EFsx4y9kjxRqWekuU5Nq6TLJbkRl00vUvoIXokkBhJq m7X0yB1DCGXObGHM8jLISe5ZgFMfaY7M8qV62uFgs/6qOSnnOg+k+sh11qymKBISJ6n5G6TnPyUl hCtnPJJWT44gQGes7hIi2CVpZamdUlMMUk5slnhF4y/Z/allzTX4MM1RaVGlumlvZKKonTjhyFeP JBOR5TNjKbC1oi/8WpHn2CJnNtZ/lddhoTdJ9nCWbX6dbqazdfkXWoN9zr/NpvsXxk6Fiay/qNZk nXl59Qqyanp7IERuiYc771L5VP57Tj6Bz7bhseoS5Wt/p/vG7yTu5czb8NdPPvrRZ5vrrsnIyb3p EWnVukQE87OLlm5dd6Xj/O/WPHcEIka7Xmyc/t3qxQZlFCH8+DYtVSRZnjgLl0JdOn/knvYwLLIb 63rl30mS6Iu+owPwnVvr3S/ds74MoKQ330iwBzL5B69bwe2wt2JWYuNAGl9cAyWduqXJH4yetrf2 O6ue/ovnZ4+TRW34R8pk+CKlO/XNh6pWVtWuqqp6+D+64ejqrl++kN7TaWsSk8nfMmt1BLYEy/pl s1zEnIz6b6gqXTl7BlTAHyy7IufCFc3vX1K74gq1VolzjiaR4G8gTq6yGkjG7PIHN/vgHdcT7HDX qVNEpu0WKeVyZ/OErP/PefgvEtWunK3CSNTjH2msU3oNP0ioZCwpxSeNqum8VBMhdwGzfNNihZIv zwdyxfe2krIloTzH35QIenrKqk8pl69JjlYyU7RRMQZOMudV77wX/gYeezwQi8cCr6zpj71+xzJ1 FOncRE8xhlIuSlqbbawSX32SN1duli+6ko4cOnv61BGkc55WHA9kSDAEDd9LLSXY7OUdyVhhU6al bgYeZgFpaCdzFjy4hXwc3dkTpjkl5dUmfmKUs3Y+GZ9yxzk8X6JqkYWExJYFLlWjHfmm2V/zlsos JdxLSauUy0W9hpHJCNymF+naBGOJmPQvFljE2yYtjN28+GN7hgKc+mhZvnY42Ky/DK3sBZnUFI2A lPyNSEgHSZt+pVHYcGGXpJWldkrNkLkUYJl2w4pvMp9hU6653NbJahTBMyEt4Xqt6GjTirw+lTLK SotOwxYynEkTWJVhbu2vj9AfCm5aeNlNjR/mwyqD8GwQfp/8sTJ1OOvrBprW5lyUf+sHN8C6JHRO i+Ro+/Cs/gnEDTz6YECItv/bz7L/rTZf6RFZQnjxbVrKEskJy5xX9XQF3Nvxy5Cj/zfXb1uw7dkH 4fKp59uj4aNr/udrdHInvflGxfJ69xSd8uIoZidYfChNr252soU45v7A87QO75eaTyQeGo15pY2M QXTENc+tPha7lWWSddqaxNRLVU8K6O/Zu5YlmPO0J0uKxdA/J/fB/lMN932VxPjrvpWey4oeeVNn tZIFU5NY9AxEiJzVJzrLCT+VZIuUtnKXeDqLf/RDUHhtzfYgrMApnPA9+SK8aLP6OmmaTDGWdzI6 dYpRUvxWUY9erXrGXGb5psUKJV+eD9AISdmi1p3pb+oImvN0lC8nR2ufSdlGtQl55d8nPfgnv97S 3N669SH4VNtDp53UkcRzjp5SPKVcdOks21hdfHqpkib/XiIOLYyR2VpxPNCY3BgyfC+1lmCvl4fx FbMeGXUmIfZkWuvGls4OTUs76XR9HqTPpctiQ6vO7xmNSpj4iVHOrL7fgQSTcQ7bl4y50hC5r+Td V8LNWyolGu8kBa3SUi48fSDcphepSocIM5aIMuYxycvyFrOFsZ8Xb2zPyJdTHy3L1xYHe/WXoZW9 IJUOKbWovFxUtWD4JG36FU8XKdw2SfOapSJGBNv3KIhsJy0z97TV3HSMTCSeI/CHaTs3H5WPceOM 4o3hTZqAojMLfIEmncK5+WTRkPMHuyKqd01oHI97vhI58V6DEmTvJHZyX9Etm7K+t+fjPffny32t vaRyrPlLydetn/y6aOaclYfOvr68SL7B+cuJn7SlM8QfKzjjP5p3ftndcNKx9vHa6humP7ChenU1 LF4FexzMuazU/ZPH6eROevN1OslCKkO7u4Y9a0IsSFo3kmhYh6U/GD2tpvlw2xPES1cWr4afWHnZ p5eMOpdnvNvDqmyj/keX7T5OI+i0NYmpFmg818kxRuCFWPLkJWSGG/X3PPfLjt8OVW39rQBrFojf tAfWf4vRWEDfw6npuYVLIa/OR31qhsGG2191fpkdnkHeZLHfIqW93POufxTeIBs6+sjCnMyMmflP Zn3f//tO3tOpglEpQZt1SkmonCgSTEKUW8aSUnxSiaOcGCUrt2DPF2b52rQiIZnVWip3eT7wzPG/ giZJ2aJozvM3JQLvxE75Kpo7VHaZ5GgpMzUb9SbAT/3byQLkjatuWNn44Ys/uj6hJ4TKXZWJnlSg JpUYZN7GJuKraFBRuv9j4vtZpaqRgxKBqxXHA5WEJic2vXSYEuz08rx6xMvajkyb1tksnbS0k7Ho f4FF7gXSq74pe7XOT4xyvF1kuMsb53B9iYdbG54gpg2HK15LtSUwYIirD0hNq7SUi14V1XXSXiSm NZaISf+iyo17atLCJJEXZ2zPyJXTqliWr843eLrZqb8MreSgRC4j0aLKuZj9HT5Je0+ORh0Stov3 7JC0rFk6mbxSMyoDIZZpl/70KeYzbNprruUogqm/MVBnkTGC0WpmCARakmcKHz+BSU+aODMyYtqH TOfCFSFYPY4e4gvnrvzFsGZB/M/PNL9zWgqPnw3DT/qzbnbPS8APRwx9hjxEYwCKkck7mjh89C04 X1SQRy8jPeTFlhkzyNa8uhk+hhwpyFn24230FJY7Nf9GQ4zGjm/T0oBkaSzQeRCkGX8hl5Sify69 kqyr/Nd9W/d9fODuIvgFqbZe2vGnbsUSGiW9+eYuLgax5z94ZMPBk5ImsbPkxOpdISmy8keMb1O3 rjCUfixs/nrLsP3hXJzMTBg97UzG3LKHXoPl2eDTp68u38abLUqNTCRMftFKODr5ZSYR4nTlwt2h Mz/94u0vhMWqFAu9U37NE6uXSvOJiraWMRXw0om2vGwR1okQJZjUL8pTeZTSpSaXqnrK07/6Hy6s Xb4ZmDvzCh/0/6VFXBopeIbxyg9PE6frYsgKWpibHnmVVvlo9ysL7+653k0mRxjhJVcn1SKlVu7E fN0hl0jE/8xGIV/c4QsW24oP/efTjE3HdWkdDqUEbdYpg4CEBOVWWMdZ1JBXUopPKsmVE8VLlZDE Sfwss3xtWmHeWir5ui6dBzkay/raL30Rwk3qV0JPwxnP36BnkTxflySZ8mXaZZJjmO8zZuUVPRUI BMJWPWFudqLrd5ffS9cNgbXVy+W9h2nztf+3EWqxiZ6ptbFMGgm6yhgjfrb94V/AQqH5c9UNqhSR q5XwQY29FoYKUrfPNr00oarhzJYEG708fJDLrEeGDOUAGzJt6QZvbtobsaTcTibKUjixZc2vYNW2 4nlOM6+WTdT/ZfkJT849t5LV5XnjHK4vWdV9qpLSVus1hCXpOC2VJ88F24W2trYH+bU1Na1SLheb PbtNL1Laal6JmPQvRozGEOYoLvm82GN7Y3a8+mhSvlSIXQ426i9DKznIos6yaoqcNPE3NX+T0w+b pI0nR3VbLedrGOfYIGlpqd1SU5RQnVimXT6dPLQan2Fd7kUQzmujVDlYnSYzMrGSRe6btG9KcmMc 5mjTkrwiUDqRbdGHj9V1couq9AfgrQdYNE6/XUI8fkTc7kRefEja9gXGOm1kaxJpdxVpg5u44F9P ei/3w8pOh1KIR97RBjaXgocc2BkBlvEnGg5Fty2bBUno2jzC73dTXDXbXqi/YzY9L4BNCqdf1XW8 nawxCZvy0oSQtyhKHSKbLDSJW1ok1hKTb3D+suPTDW44lkorD8PdbU1N9SvI/o7kyFpUsuopaeMP VmYDh56EWMqmVnQHtazip9Q7Ig8nXwMTabEoyLTGd6j7cKu09WPWogrvfaylUuXy2irtQDRw+Gli VvFTdG0zc93obkcOzx11Ky6YtlbeREbDQZY/XH/4xnP/QvZpYnga1Vzeki1rzR41W5UuFmQkkrNu JptA02MwTHd8qGmVFzc1hPjXLwat6EE3NiNbQQ0Z60XcPKaHwz8JwiwJ/Pol8bRZT4EHW39x8b+K rbQZEZruuwQqiFJhVfDjZprcQ+ZNyDH9qoqSQvgrrgwt+GvmiqG68KRbJLohHIhi1ghDucsey+IJ jRDsLEa1KihcWgKHZ4W36r7NzYeNDSk131iC5nVKDY0jATQkXidvdhbX1Vl2SSntZ8LDGV6qz51f vuZW0DXY2a3loDFfblnzbNHrqVgn9xdm/ia2JJwaZ1G+JnYFjjVSxzD0Zd+oXzrTxGfYNsobGXI2 PpMAgPeC5PqOkwoQKk3ZfxrA0KnMzMVPhMSe1JKM/TbWhEbvoNTeZt26i+bb/fL9oCpvy2GuVtlf Kc3KsNPCEAKG9tncSw29J2OMYS6BYrfu5fn1SCk43Ym1THlLPqhlrLGZxYjFYLtF/6hTD/wKtl+E Ai28cxd8WB0XInQMtrlL2kmN7dUGKSCHts88P2HLkWsHKGBs1Q++9RyEk1v6UaXc67Hb9rixrWb0 DsxeaZDs/A1H5twHQvLwQWcr18Onm2uVdLnQMbn9nt3Uw41tNWckoLNWvDT4mFy/DH2Q1BobRnHs 0je09qrM2WN7VQTxlFsfeT1R0hzs1F+9VvL+Jrx+07ym6KSl6m+KmGGSNB+nMdpqY+2jqliStLRU 1aPZ9167JT7AfYb9Rv13yaMuHMY2Cp7FGG2L+DSd2shEKTblxCCf0b4pkZUTQykAB+5o05I8xxYl tzE+SWL3nCObyLbB0gHbCeu3HSEDR/dO+UERJkrE4Y6cwFHfeozYej5Mft6XD9JbCNIeSzQs6/79 3W9ulO+T+YWWY93SvoNiqJds6BDeVuGicUo2vtF7WBx3Zi1qfH1XIqG4Uw9dSVgJVHY3oNT73lwL kym87spYMpz4HEtpenlABjrAk3nve6Kqy+5t6hD3DTHmIaUivWlivWKYM7o4x7NX2odYTpRivgPi CtV6JoPhBu9XlEBp0qTo9ob2YzC20R6a8ip8aE/brjuVhPIOoKa69R+l6+AoI3IT+an7Q+aCSnFZ fqob8bT+EHwioaiavfaNAfHhQQkRXwTQ6gJXfDI9rSpHhZ1cYQtPuvetIjFr0d7OV5QrcgL+TLY+ Ffyq2pR5y89DHxvrBR1GGWJq6wubfzKEGRL6Q6z69aX7vy09xRE77NRTwtKo/5CyY4JEJmtRE3Nr DBE+SxMxPuyYs47MiNGjYsN+adqLF55EiySST6LcpZ0sqSYMnsLQwCH5XTxZYfqXvX0AGM4oQdM6 RVBrD40EaSgjabiGXWf1PikMhd4ks7fK0XIyaGi9WYN9cXCppAKfV5WvqRW81vLQr2DvbUWg2GuI +fLL2miLlg65YvQO7J5F4/mplC/PLugF2DkSYlY+w6pZME25jrzIltjjUG+20Ab7rMuH3FzH46cP Zn3uCTrlPXB4p3xf+kt+q2DqmVoba0JD9Vir6MDY01oxiqkV+NsRqYuRhGg8UElMTowtNm2f2aMX ls8wvEgUzJOQyF58Zjbr5c3qUUKM5sxSpqVu/NIZ9shBzDvUVV/xZaVw4e3jFk3jz/ZqjY2iGGVS WxGl9ROOHH6rPtDPHFVa131dW61vM+lO58yWSilfmA4QpyYNZpLhB6sHtKGViaWmIzr7PTvbwxkj fN5IhtF3GGuTnmdv0MYojlH6Rslq2pyxvToKlIW00xOjVTGWb2ocbNVfrVZwxa+z8FOcVU3RSkvZ 32QxwyXJG6fx2mrNOEflUZYkmZYaezSpYjI8SrZY/ptUiTNzp/0Uv+YanjjSPPLU1zXadvEIy3aT v5o4VqNNG88XzFGWOsMxPE9i0sSGluTNc80hDIRCob4+w3O3JlKKF8LAgJIfnOhytiGU/Ojh3vGe jZg0iml8M0uFgb6QzEAAGnZyJNap4onGqq6V07TmKyoqaToQsaWnogjjxFS3VEqMkUciaNj+kBBl PEszGTEDsqs71A5NORtzJiH2Y6rSp1Qn1OmHW78Ssoz6k+pKQuGwtt+kZOGWiFBdV0i+vHC4kVSL lJ5yH4o2VMyBHy6gRkGpDIhHKNQLv7JqdkFOAKNnrBJMTn+WBH0ummtjSWlu276wKF8zK0TkklPY ai15ZZ2yLSAQwFFbbRG0Vb5mdjFytCWT2TIIfeE+fX2wXXDmERl6mifg3uXRkIb4Tb39vGI1imRq ZeGBRinGEDMvNcZmhVhJIJqr0omGqK5Jc5FEO0lTWsqUMjDTjVc6Gt3UF2KCJEYOctuvMV8RaKPm 2vITnhwTbZm+pCjGP7HVToBwXW8FyQaOH4R3BLiTJmKWqWoF3R0MPZMoF76BnDtmXsRIwisRRtRh ByWTl+nYXqWJeX00lq8qqebURDdS1qq4YtGrrrmnvDprq6bopKbsb9Ba2XyqMieZ5DiNXfvskEzK UpNS0wE0XjLTmuSenpprbxRh1NYQwiasjWYnTiKFie2JSOPyLL2TJuPSRL1S4phSiA+8R35P8ytf VeijKdfJxlcS4gkSQAJIIB56dS00NVXt/61j0Vb1aXej8mqe7iZeThgCI1G+IyFzIgCVhviJ9y8m gtKo46gTmDR+Am9+5Zp/TDfqbKdOhlNhbD86NWUqkJx49WKqjiJGtqSylZcbp8hJ8OW7F976EjUW 3mH2uGAFFLMj2fhmsvAeEkACU49ATCAbJPvKPis8+GxVaVGuyxkN9/gq79x94T3Ht9nddXjqYZsw Fo9E+Y6EzAkDlCwnrdpabALpjaqOLoGJ7SdDp2pnffFnN+34oOXWxMq4owtwKuc2pcb2I1pTphTJ CVRlpvgoYqRKamTnZMaf9ND+uyhKWEKMfsJtrmOy8c2l4V0kgASmHAFhoGVTYt0f2v7AIiwj9RHF lOM71gaPRPmOhMyx5mSRf7+0ATmtIN7tjPXmLSTg7alAYBL5CXypORVKbHzaOPnH9qNVUyY/yfHp wZZaTcFRhCWTYUfIAAkjNR8zXuVGw+Go05WX67KpYLLxbYrFaEgACUwhArFYJBKhGyS7cvNc+Nvi JCv7kSjfkZA5frHHwuGIw+l0kEoSc2AlGb8lNbaaoZ+MLf/Jk/tkH9uPXk2Z7CQnss9PrVHEiJfU VJw0GXGomAESQAJIAAkgASSABJAAEkACSAAJIAEkMPEJiNvET3wz0AIkgASQABJAAkgACSABJIAE kAASQAJIAAmkl0CykyaxYFdXMErfMU+vJuNfWiwcDARODJgqaieOqYCUb8aiwUBXV1cgeEaQZBhD UhaOCZEAEkACSAAJIAEkgASQABJAAkgACUw9ArYnTeJn27fdn5GRs3DJko5TQ1MPlCPW+9r8hUVF BcsD/IX97cQZCXSRIzszcuYsLFqyZEnRwtyZVbuPGUNGIl+UiQSQABJAAkgACSABJIAEkAASQAJI YBITsD1p4nA4L72yfsWFwMLptNimd1LycubmlWQ6sj5T5pqhMj96Sv3eDTvOSOPof6f0G6s9vvdg Td/el8neQLt/tPu6r2tC9vxzV3JvB2ntGmkLUD4SQAJIAAkgASSABJAAEkACSAAJIIFxSMD2pEnG bE95ZWX5inFowyipNOfKjvPC//zp4TzVnEnHmq+1qt+7YcUZafWC7c+9H3esLl4IGeWvfKa7rfnp e8K/c2hC9jVfn9RmHXq7RtoGlI8EkAASQAJIAAkgASSABJAAEkACSGD8EbA9aSKqntzbCuPP2mFr BNshJo5Y9yvLfH/O0793o4mTiD1iZ84MtVJOd1nFty+/RJUbCSlfPF8VYnHKscsiFd5GAkgACSAB JIAEkAASQAJIAAkgASQwyQhkp2CPc4bDEenZvqWh60y8uLK6upS84yAesUD7AZ+vJeCY4XYXl99U 6bk8s+uAP+IU5xFiUefCUs+COQ7hROuBXqfLGT03u2z5EhekFE41b9/SerTPmTPXU1lVWVqkngaQ ZJM/BvkgjXVEgkdbdx5y/7g2L/TWFl9L5KPZZVXVlSWKniDpTEdLc+tbJx0XnnVesbzaW56Y+4id aW/Y6tt72LlkeVlBZvTiG6uvE2ccxCS+P/3d9nU3gHph/875V6+GzNvbWl29Oa6i0uJ5OVSsFCd+ Nq22sygNnGjv7A0f7AY1WltbXQtynH/zN7HTpzUhC0tE5hzCYGyTz/fiMcfncz3XV1ZWLIky7WJB xjAkgASQABJAAkgACSABJIAEkAASQAKTnAAshGH/oEtmVNxXo4ayOdAvShCaKi+C8JqmQ0fe3E4j tIT6/S+soeeZ1z7V3TdIYg6GWzbdAoHe7W8PxOPCyQNwnrHqqbZXfbBoCBzZd+0XGDox5YsC1ZFP d1IhRFBBAflfPioayaof5Og/SuLMurmhpaVpPdHEMf0qf5iKEpqunp059wF/dzfV3NP4e0gR2k/W CoEju+wlottQpKGutmQRUbdgxR01Xm9D52l9nLiQPtvZlAZOHvRWeCsKxJmvohU13oonfT5dyOb2 kzzCwknCKuOSe1v8/s0rZoMtWddu+nldjc4uQgwPJIAEkAASQAJIAAkgASSABJAAEkACU4+AIymT 6aQJPF239MJEiXDk2VvhvFKcVoh/3FMxPTO7dBed7+h94Ta4VXPgjyCfpspe+4aSV++u0ml3i5dD kXrXjGkPvy3d+rCzQFwxpClkmA3hy1fEiieC0B/c7LkAcoej6cjxgVCgviiHXEy/6sjAUHwo2rDs QjJLAufi0S1akfW5J/ogoP8oKFDf+aF0a1OxeweZahEEoe/YXriVfdseZUInJK662hSUVGXGSY/t ppR0aoC2mhBe2pMhIA8zJr2CyEGcugIs3cKQJjkFgf8jASSABJAAEkACSAAJIAEkgASQABKYegRS +TxnW+Dj8vyZMAvhLl3ucOz5xa+DDXdc4cyYnTc9K+MreeTLmtiZYF8E/p6JklVQ8pffW5L5fOdT 32r/0VBZbgZ8nvP4D3658/0WEjHY+VD0nGP9N2v/Xw3EdfU9D2uawnHgaKgy7wpyphx8+UoU8cTp nDMvN3c6nMPcR2UxefnlwV+1t19S0vnJrwOnou5Zv1rl/yj7tupil7Sgq9u7ruSHezo/eKTjD2sq LyQKP3S1x/WrvVWehe6qrd5fEoPgA6Pc/MKi6ZnH4UI+6Aov9H8IY8ZJi+3mlHRqgCbqEF7a/fv3 /yJ6zuOryqdrsuSVtNTXtn70tdwZGVHRQMUu2Vz8iwSQABJAAkgACSABJIAEkAASQAJIYGoRSGXS JLHl8DlxhuMDgTDLmbfhr588PnCiue6alU++raE4s+DxB65ctvE3G/d1l9375WjXi7/I/en2BeLb H2K8+uZDZdLqJFVVDzsc5xyuQtX6I1SWiXxNZomLvLlyFhddWb3ios7m/s6evsq/DZMYfxE1p3Fn Xk7vtgdClSsWrJw94/3o736w7IofzLq56fWNtSuSWEKVytP8nxbbRYm2KGnyTlwY0/5P6MVfOBy5 yqq1GbPLH9xcLqagkyaJxHiGBJAAEkACSAAJIAEkgASQABJAAkhgShJIZdKEByrQtLbolk2ZtzzV O/C/HW33LrzleSVm8fd/5Ni4ouPHW8J37+xa9/TtTwfI+q/yEXHNc7svk6+4f03kM9Oo3pVwum/8 jqP5eccMRyT8Pon8aek1E33CjLkP9p/Krf32qqf/0/HXfSs9+zY+/MaRJ8jKrykfabEdcrdJiamn MW3w+FNE5lkVJDGl/popDgORABJAAkgACSABJIAEkAASQAJIAAlMAQLiyqtJ2smcQYid3AczJlnf 2/PxnvvzXfoozsv+kawkEn3Re0fZyhNlNaWa1zee8W4Pq978iPofXbZb/R0M0c9cvqUFsSh5HabU PT83/0o4OX+wK6LKkSb3uOfDPj4dvx2q2vpbAVZC8XwKwgPrv8WIShOI/+tNVd2ip8O3ncqxQ8mQ uRRgTHvXf5FZqs5HfWrywYbbtwQGaBpLu3h5YTgSQAJIAAkgASSABJAAEkACSAAJIIHJQSCVSZPw GfF7HAWA+NZG+OhbELCoQFzThGxJTF7omDHDEYuJ65o4nOWPPQoh7+zrnPZYrZuuowHrgLhyIXDo zE+/ePsL4RiZxoiF3im/5onVSzWzKhBuJR+iGA5RIAmNn21/+Bewymn+XKcrfzGs5xr/8zPN75yW EsTPhk8IsJmOe54TYtYu3wzfpzjzCh/0/6Wl5msQJ6izV0om/ekKwyxDLHzK5KOW4dpuTikS/h2o op7jUIfw0v6w7KuQCjjc9Mir9O2SaPcrC+/u8eRJ7wBp7IqeCgQCYVqSWvPxCgkgASSABJAAEkAC SAAJIAEkgASQwKQlkMzat4J//WIA4d4obXYzcPhpuMwqfgr2nRF+v5syqtn2Qv0ds+l5AWz6K27I QnI5H66ZSb4GatHujENlSvGXFsKJsgWPWjdr+YnY0ubEWbfuColbw3S/fD+IVbYc7hZ39gHF2sjG N0L3C9+Du3Sjn/hgEPYAqtj6trhFjtB03yWK/sLJg2Rnn1k3d8vb7tAdghyeO+pWXDBtLWFijCMp NTzbQQiX0mCY7g1U00q2RiaHIYSddkjw18yl2MHGihJCnm5jZLBL4iltt0xzwf+RABJAAkgACSAB JIAEkAASQAJIAAlMdgL2txwWmrwXS8/YDkfhmj1tu+5ULsnOtf2hbRXSSwolG9/oPdxI7mYtagrA 5sTS0bvr69lfeF7ZslcOFvybyNbF9Mi85ed0pkO+K/8dDFvKl6NKD/mySPK3xveuKl+BTqMoEepb j0lpxUkTJVzRP/Tmk4lAZd6n/yjMsEB45uInQGd2HFmnYdlOhDAoCXSfYEWzrEV7O19RrshJ1iJx ioqRlogciras+6YSv2LD/gESSvZdVtsFAf515IWgxM7QYiz8DwkgASSABJAAEkACSAAJIAEkgASQ wOQmkAHmKY/Nwz+JRaNk611xT5ZYLEbO1ULhWx3YGWe2JozehzvRSNThys01rIeiEWAuX4oaa175 2ZXN/U29/eW5GZFozJXrcmkVIRFj0XAk6nS64K5aIaI13IvCtyjwaYvmlloT+ZxhpXxL+3fYtoM4 m5S0GUtXvLQieCMinV2xyKmoa16uGhQzFwxEAkgACSABJIAEkAASQAJIAAkgASQwaQikedJkfHCR Jk0agoNVqo2Nx4duqAUSQAJIAAkgASSABJAAEkACSAAJIAEkMDEIpLIQ7MSwjLyXkc6XaCaK1agn EkACSAAJIAEkgASQABJAAkgACSABJJAWApNu0mSgZ8OyT8O3OUDnB+5PVe04RLeGSQssFIIEkAAS QAJIAAkgASSABJAAEkACSAAJTB0Ck+/znFg4HIG1VBxksiQGi6TkWS5LMnVKGy1FAkgACSABJIAE kAASQAJIAAkgASSABGwTmHyTJrZNx4hIAAkgASSABJAAEkACSAAJIAEkgASQABLgE5h0n+fwTcU7 SAAJIAEkgASQABJAAkgACSABJIAEkAASsE8AJ03ss8KYSAAJIAEkgASQABJAAkgACSABJIAEkMAU IoCTJlOosNFUJIAEkAASQAJIAAkgASSABJAAEkACSMA+AZw0sc8KYyIBJIAEkAASQAJIAAkgASSA BJAAEkACU4gATppMocJGU5EAEkACSAAJIAEkgASQABJAAkgACSAB+wRw0sQ+K4yJBJAAEkACSAAJ IAEkgASQABJAAkgACUwhAjhpMoUKG01FAkgACSABJIAEkAASQAJIAAkgASSABOwTwEkT+6wwJhJA AkgACSABJIAEkAASQAJIAAkgASQwhQjgpMkUKmw0FQkgASSABJAAEkACSAAJIAEkgASQABKwTwAn TeyzwphIAAkgASSABJAAEkACSAAJIAEkgASQwBQigJMmU6iw0VQkgASQABJAAkgACSABJIAEkAAS QAJIwD4BnDSxzwpjIgEkgASQABJAAkgACSABJIAEkAASQAJTiABOmkyhwkZTkQASQAJIAAkgASSA BJAAEkACSAAJIAH7BHDSxD4rjIkEkAASQAJIAAkgASSABJAAEkACSAAJTCECOGkyhQobTUUCSAAJ IAEkgASQABJAAkgACSABJIAE7BPASRP7rDAmEkACSAAJIAEkgASQABJAAkgACSABJDCFCOCkyRQq bDQVCSABJIAEkAASQAJIAAkgASSABJAAErBPACdN7LPCmEgACSABJIAEkAASQAJIAAkgASSABJDA FCKAkyZTqLDRVCSABJAAEkACSAAJIAEkgASQABJAAkjAPgGcNLHPCmMiASSABJAAEkACSAAJIAEk gASQABJAAlOIAE6aTKHCRlORABJAAkgACSABJIAEkAASQAJIAAkgAfsEcNLEPiuMiQSQABJAAkgA CSABJIAEkAASQAJIAAlMIQI4aTKFChtNRQJIAAkgASSABJAAEkACSAAJIAEkgATsE5iEkyaxyImu npB9BCMWMwaHJDxxlnJu6ZWWshpjnTAWDXR1hWPxEdAjFgx0Bc8IIyB5rEXGomBaV1eAZV0sHAwE TgykXcVouKerpy8tYsUanR5RadFnYgmZMO2hqZcmWtDEWRrLYaRqQcoqos+njI6ZcMLUAll7e+1n GkYFRIQyUJFzt/obC3Z1BaPy8MYqttV969pnj4ZVPuJ9rFm2MGEkJIAEkAASMBCYVJMm0d63qkpm 5Fyaf9U/+dPVnxuI2QyItVZ9Licnp/lU3NH3VkZOzgXzNkVSf9JPXVq45ZEMd0lllXhUVrpnlrSG J+a8gHDC9+AtGTlzipYsaT+RVhPiZzu23Z+RkbOwaMnKA702C3iiRIsc2QnQwLQlS4oW5s6s2n1M rXms97X5C4uKCpYH0jcPFfTvriycNme++6p/aktLNezaUFLy8+NqtfHcDoEJ1B6aemnKrV+sY8Ot hSVS61dZWenxeCqrarbsaOrSzhKORC2wU0AmcdDnTeAkdWsC1QJql+32M+V6IfEjZNzTYZQCR0Z2 wYbmFl/VV7f3DJrhjZ9tp33lkiUdp4bMYtq+Z177bNOwmx/WLLukMB4SQAJIAAloCUyqSRNHxoyy ynuIgRfO0Jo5Blexc+IcCfyGEzsL2Z8f6IrQkJR0SVla3k2PDTT/q6PpxcbGxpc+dV1r/8HyvJyU VBj7RLnuG72F00APpzMjvdo45y+ur/gyyMx3OpOQHD2Vvl/bksg2iaj975R+Y7XH9148Hu99+S5I uOefu9QTGc7cvJJMR9Znylwz0obUmTOvvOp2ouRlycDkWSWc2L7tzzvWfp13H8O5BCZKe2jlpam2 fk5P7a6DW+7p3Q2NX2Pk0sXV1dV54efWVN+yJP+iyp2HlYowErWAWyh2bqDP26FkM85EqQWyOfbb z1TrBckp1v3inCtKd2dX+3tDA30h/3Pffmjld1Y1vmfZtzovvbJ+xYUgwTKmbJDFX/Pax6aRcs+L NcuiNPA2EkACSAAJcAmkY9IEvpho2+m+6I5g+n6s5upresOVX1K5uto7I9Px6bQ9AZpmaH2TjMud s+G/zJl5LuvoFjG00s41r/xq1Y62sMVbsk5X/uLy75DMb76uOC+pSQELdUb3ds6CssrKsoWz0p9r xuzisorK5WTSJKmjY83XWtP0a1tS+dqPHGx/7v24Y3XxQkiSv/KZ7rbmfc3Xa2Yy5lzZcV74nz89 nJe+GpNXXFJZfj1R8i9JvlvFakliwXdemX2P5/LRnOmL2atZnHJgWcGJOrLBE6U9tPZSkVMqrZ/T mVvoLppOujmYMYGXTTZ0DPrXXwuXe1d/w6f8qD4CtcBu0bK8ZeL5vNFall3GWKMQMlFqgYIi2fYz lXrhiLX+6F5H1qJDv9rqyc9z5eZ5Vq0fOLZX0YF7kjHbU15ZWb6CGyGFG6a1j0nDVs/L8sDJULNS IIxJkAASQAJIIB0EhjVpEhs40QrvasIXEzesdv9zZW66f/9PxcBhvM2RSnbcNM78pV91TL8qf67T 4ZoH8ziZ17qHwYcpzelesaKx+ob5c3I8a7YFTtlYluIcV90JcoOMD0foSFZ0rPuVZb4/540Hn+cT cWaoZ0ic7rKK8sXzDdHHfiLNpCXpanws+4HKNM7pGMw3BiRfs0QZJlYY8xilkInQHlp56fBaP5mA UsE9Nf8Ob1fB0dkTVpXCaNcCE2+ZQD6vAiidmthljDxKIbIPjFJ23GyYnpzydDVTmu226zNZoGbs rFItHK6iFW0rL47Z+OkrkYZrabI3kqh9lj2viQdO6JqVLFOMjwSQABJAAuklkJ2auEhvZ/PG+9c0 HoN5gW2txypLi1zK01nsTHvDVt/ew84ly8sKMqMX31h9HXlOiwSPtu485P5xbV7orS2+lshHs8uq qitLyG/g4hELtB/w+VoCjhlud3H5TZWeBXMgPBo86tvR5K6rL47/wefzdf1hqLi8qmp5kZKblNrs T6qShVOtjc3NzU2OvBLPTZXlJYqNpuumZThds4l2ufnXZM75c+7sDEfGPM/fz+y5Kj+hs3CqefuW 1qN9zpy58JE90INb5pYypeXftC4evy/YcWBD7e1FW/4p4yv3vvqzH5QVL0xkZIbFcI9jr5OMZwwM L8/sOuCPiPccsahzYSkpL+FE64Fep8sZPTe7bPkS8nILy1JDxhBgkC+WPismCXPGY+GO17b42qKu uWUrqyvVEwGxMx0tza1vnXRceNZ5xfJqb7lmXsP8rpwfjLraO3vBuFgsGptTqPJSKUbYv3P+1avh or2t1dWb4yoqLZ4nvgphTz6VEg0dbd663blqU9XlHzU3Nnd19eYu81Z7l7lgjZVmX+vBbseli6tq qty5OQ4IOeCPiQNLUMlVtNwD2Qmn2l/rdsx2xs7N8Cxfpn+PSTQhDEIcjtbWVteCHOfCEjdUIqhN tfV5J/c9vuOQ+5a62usuAly+P/3d9nU3JNyGVWrm/kksImpv376jzTF/sXtoBwmx8cKXWUsCEsS3 qXe+X0SkwTFabUuyNcvMitHSmRKy8T+7rlmXL6d9gFIxW0fSvD2056WVrLY02TJKkMmYkTcts/Oc akUGsdomUQtUNQgqr75O3bjQvN0z8xbQchp7wXcAAEAASURBVIL4fIKnfGZmF9YCy1GBefvJapOH NSr4P+cd5393/eWlLT0HyvPJWAuO/H/0hsWTxH9QcE0+34vHHJ/P9VxfWVkhduvibSd8Ax3p2b6l oetMvLiyurpUGssl0a/RbJi1j0OD2/OKosw8ECJM2JpFOeH/SAAJIAEkMMYEYLGDZA6h199cIb7t 7Khc19Z9UtAnFpqunp059wF/d7f/hTVgm6fx9/HTnfSXPWJqQYHa4IpGstpCPC40VV4E4TVNh468 uZ1GaOkN1syU5nRK7vWqU23u+lCfrXI9GITXOrJv2yMrlqrk/qNEZ9ft/uO9/mfvVHLPmrd551c+ pVwyTrIWdQtDxKQ/vpL9heepGv6auTUdks7CyQOQKmPVU22v+iiWTO+2H84kP/vAwbOUJ02xe6C3 a7NX/MAka9Hm5kN9sv1iBAlCJZQF7+DYm533c2GIxTDUT8sXdM689qnuvkEieDDcsukWCPFuf3sA CBgszb5rv0YvSRmmfFGgXlspJiGlOrzNsl3Uilk3N7S0NK0nmsCknj8sizK9S5f8kBB9LJY+GLL5 ZX/3Sb0WQ5GGutqSReTX6oIVd9R4vQ2dp0kcU/kaIefDim+r7CCnhbWb6krE+RfxBlSlEHjTULRt /TU0JtDuHRApDoabniCB7of2A23dIZw86K3wVhSINahoRc2t/7hU/HUd4hcsLaSiHBmfpyfZZS8p 5WIsNTv+GR8M1l0wDd73bvAfVhxDVQ112sGlZUtCkgy893TGJfcSAuQYm7bFvGZhezic9tCWl866 OXB8L7MtpW4B/5uVkdgjgJ83BaV2QPj9bur2VXv/CGlD++9KthYkahBNqa5TRNtWCFa38HK7Nzl8 XqGunFjaNTY1V9EPWqdxPiowbz+NbTL1qOGMCmh/R/23YsP+kDhoSRATz4STZOQGLXCL3795BfnK OLt0F/Q1NG3FfTWy+5O/mwP98WT7NU7t49Lg9byTpDfR4cdLJIAEkAASGF8EHPbV6X75YdpH1mx7 tTciP4jq0vcfLchw1HdKEwTdm4rdO2BaRBD6g5s9F9DkTUeOD4QC9UXik+H0q44MDMU/7oGJGOiP 6ZNb7wu3Qcya1uPCYKSt7ptSqm54LhW6X/geXHqITM6hGx6lKFlo8V4MGTVI42yhYRlZ+Sxry9sD UQGsMT8UzYTEk6h8OhSpd82Y9vDbUpwPOwEXHI29Jy0tlUUQnIpgJS96IgyE217YQCTCA/8G5Vna ctLE1F4mwwPkeYMOnrLXvqGo0burdNrd4iXH0qaQwXP48hWx8ok8aTLrZn/v6YHTgXqPOIFFvWgo SooJZknAo8Sj+9lbgUPW557oE+cdzO7KtlSS+RehZd3X4Pm/RX7KknPX/A2J66oqT2Iwr2EuX5OY lOGAfxNZWwGOpt5+uBt6Vapf7g1vkFmRQWnSUHbCuL/uSojsfvJdRRTQJrNayrXhRKUkZNgn+VjW Iv/x7qb1q+557lDo2F7wwMTsBqfUrPxT8h+FBq2n6rkYtWq2WhIxAcw2Tn9Sruxj2rYYa5YtK8ZU Z4JwnLeHYimbe2mN713w8ESTl2zrJ0+abPYfh6ShY63SVDVMR9LZbUHos1kLeuRWWqpBd9zz7OsH aA8l16mahtd/Mnu6sYWv3/Ijsa47zHrPce/zooKa/7AWpGFUAD2OON5gt5+cNpn2pKnXi7jg30T6 R+Wo8x3SdCVivjBj0kvnU8SfQKB7hd+ElAmXFtJzCUfEfpb+3pBsvwZVUl/7zGlAR6nteW154ASs WZpqhhdIAAkgASQwDgjYnzRJdLH15EUGTfeaMOS0OAuQtWgbjFAhtP/o5r30LQDpcVeZT4l/KL1+ sg1+oBgMw8/U0kBTiLSIv5/TPph2z9sCH9Ms4KcV6ON5D2Mkju4hIUXJkrbKIIaqIT5RU0VS/F84 vpeOUWrW1Xjvq6m5WXppBSQnbSlbBSF0vIO+CpS5+An55yPrSRP6pg/bXj5DmO2iTyBtZFqCwIes 6UO+iaV6xU3k66NKhij+QHMEpBAi+UbiJaO4oh7YZX4X8qH8K7a82nDfpx0wKaO8n6LXQbqm8ZUZ DUv5RjF6pxLpKVOHMBilhaJkAVWGTLHB4xmdFRJdvabjv42SlRCdkvSyrp1MeEmHtr6YlBpNq5DX 1MTTB0mt/Lo06QmSNXflrOS/9loSiC0CUXwSXlij5o9R26KrWfasGGOdx3t7SF3C2ktl17H6qysj qVEiS4NrD++Gl+W2URSZZC1Q1yBdneLVIM+t11MVzHpP0GVc+7w0Ga0qBawFjuGPCuKm7SfPo5LJ l1UvxFIcOHZAenFY9E6YIumWf3Kg+dKd10jcoWhLfa33oT3Q1bP7Avk1Uno3oZ5lv6atfeY0QBFt c2HPAyHZBKtZBDkeSAAJIAEkMK4I6EeT2rGl+srpWfNSXIj4X97wUOXVl+ZwFh/NXbBy9gz4VvYH y67IuXBF8/uX1K64Qi0lb6786cFFV1avIJ/kdPb0OXLmbfjrJx/96LPNdddk5OTe9Miv1EngPLG5 HV3RzcZaCZKElCXDF7/wxW5U0GhCFlKNNX/TlWFyzFgasFpKDcbNVSuraldVVT38H91wdHXXL19I M0rd0tiZruathZk586/wRO5/rjvcf77rYc1yHhpLDBdcex1mpTOz4PEHyOsPG/eRtTOiXS/+Iven 5QvkInY4TCxNaGBVRomY8lmCUs6CB7eQT1RgTcfYqTC5r96xZebl1MfaAyHzuySheOyt/c6qp//i +dnjZNGQZA6b8hkiVavzklVlL1GWFnG6b/yOJv5FS7euuxIq15rnjkA40G6c/t3qxZdq4ti4cOdZ JDEptQR5VU2MBHsg23/wuhXVHWYrL9prScDAwFv75qxN7JszVm0Lu2bZs2KsdOa5gVVdY5YvEcZt H9LQHjKVtfRSTSp2GYlv8cnxpMlc8UUVX91Ky7bRpBYYddOFGNM2PP+Gde853n1ew1PkirXA4Rj2 qMBO+2n0KGXMIDs4669VvXAV3dh87uPuV7fSxPE/P/PVG7ZFxYtI8DfwN1dZoTVjdvmDm33rb8mV vUDfVnxgHCxJKln0a1Is6Y8dGqoU9jxw4tUslYl4igSQABJAAuODgP1JE1Ff51zPyjr4IRm+5M/z 1xTlXZRx9X2t8ESqGJMx98H+Uw33fZUE/HXfSs9lRY+8mbgLUw5KTIf8TAjLiTkcgaa1ORfl3/rB DbBeA/0lIRHReKZ+MDbe1YakJNlZ/KMfgpi1NdvJPsrCCd+TL8Iv/Kuvg6kNZ9murl6To2d3vtWO KhHXPLf6WOzmjuBtWBqLnGiuvxUmm5asrL2+4VBoQOiov9M9b44Wg/mVib0koQnD4u+T1847frwl HIu1r3v69qfL1SuS2rTURL653nDX6SILc8x1OSPh90lkzoSa+V2SUHV0eL/UfEI7BFTdZZ4mJZ8p wU6gZ/VPIFrg0QcDQrT9336W/W+1ls5mFKuqg8abJMRmqZGoon9GRfLvnqKDbRJsfVi2JA5H185/ zXq4UhmjO0a9bbGuWZZWjLrOluSTq2tS+2PSPqShPWTqbOmlNJV1GWmlw+rOiak97S3dlUktMOqm C2GntfSWCeHzOkxwaWkX1gLTUYGd9pPtUcaykEOs6kWs/cktZGxDDqf7pvvgbV+6asn595qDURIe i56B/yOq7XVIXM0Qjgak+X87NPRZWnrgBK1ZejvxGgkgASSABMaSQJKTJpKqznxPhS/wCVl+7/Pv 3lR0WU52wZYD3WTgKJzq+O1Q1dbfCrBqibjeRGD9t7oitG/W2xkT3+Modc+PndxXdMumrO/t+XjP /fmJbXj08VO4Tlly3vWPwhdDQ0cfWZiTmTEz/8ms7/t/3+kRH+BcefmmR57loPwZ7/awCknU/+iy 3cdTsC4S6HywYlbOpfkrn8xq6iDfQ23wLstLCaCJveYMnZf9I1nLI/qi946ylSfKakrnqw2xY6m5 fLU05nks+l8Q7l5waW4+eefl/EGGu3nc883vKpJrmg+3PUHkrCxebfnGEERTytqmfCWjFE/mLyVf v3/y66KZc1YeOvv68qIU5Cg689LaKTV1WqfzM3A5tLsrmVkTKsCkJTmxYfdfdsNGJMoxim1LkjXL xApsD63bQ6WE1SeWXppkGall2zo3qQVG3XQhJmmhzeD3nhPI540MTezCWmBWC+y0n6YepSkLm/Ui 8spjgYhqri9nXm3DO+RTnU9+HTxDwnMLl8L/nY/61GOVYMPtWwIDND+dz2uUGMaFHRognpW7iQdO 6Jo1DJqYFAkgASSABNJHILVJEyl/V/7iWt97sMhryzPXrPmul/xwET9bu3wzPDs58wof9P+lpeZr EDV4RvWjvfLpSvxs+8O/gHXF8uc6w0ffgmiLCqSBRaSHvDIwYwZsZRk9F1fNLkjZct8mUO4rJylL jvif2Sjkt5BVS8n73EP/+TTdAlmRnNqJ05ULCYfO/PSLt78QFlHEQu+UX/PE6qWauYaEcM57E2KE WPtd337yU/9ypPd0fGA3bIvLGkYkJJEz8aUebZB0ZWKvCUNxzOUsf+xRkPLOvs5pj9W65bds7Ftq JZ+hb8JS4cSWNb+CTY6K5znBG2HNC3jBuPmd01Ka+NkwvDAy62a31V0ljzMZc8seeg0W64VpoK8u l15UVu4aT7rCMIKMhU9FzXM3JkyE8AsFKgBESxhL0jjLfryNpoWVfSy/IYqEf2eQ4AhHpFEvlaP+ 336pSalE/8xdXAyX5z94ZMPBk1J47Cw5MfNeKSL9Y2xJot2v/fqSBzQGjlrbEk++ZolmGK3A9lBT zJyLZL1UFJN0GWnrEUcVMdiyFhhrkBJimVbJ2OgtE9HnFXOUE6NdWAsUOMwT8/bTvkeJwu3WC+fs rNufaBN7cFkpeAkLPr0Ru0sIcl06D/6H/vSmR16l0aLdryy8u8eTJ71LGlaP6yCqrrVPrl+TdYDJ Gnu9idLzJlLKZ0YPnBg1K3oqEAiEo5oykW3Cv0gACSABJDAOCKR5hRVxta2KrW+L68QKTfddQpdb V1a1zLp1F12Br/vl+8F6uuWwsgdkzbYX6u+YTakUwObE07/x3L+Q3XM8W6UdQwYOPw2XWcVP0YVH jcrDHpZktUjX7dK+v/LukklKJlskSmoULi2Bw7PCW3Xf5ubDol3GbJMI8a9fTCXD/3TrSrL255Dg X0/2UrFvaRJZDobpXkXuR2i5GJOa2csvHbKQPpElbzQozjElhLMtTdyXzqzlJ5IIDV8hezAV3rmL bLsrRJrETQeULai7xX2XwOXayMY30l5LNeJGPyDD9K6Wv7xJdtaaPcbdfKk6dI8nh+eOuhUXTFtL tkMylZ+wQT6Tc5R3w6GuS5bio1SHotuWzQJj1atOimkFanViTWVZov6vXO41rdJizNTH3A+/obix VF9m3ays/8cuNQv/lNasBW1rfIe6D0sblMAXbRXe+yyX1NWrTa6FtqpPixtvqW6OdduiUsX26Vjr PP7bQ/gugLZOJl5qGzcjokSAUY8SkZOtBaoaJNViVUicXYMSufHOJovPG+3DWmBkogmxaD9T9ShN HtoLKcesO3fB8mfQHcDuYE3ryFjLvZH0ZeIhwOZlEEKO6VdVlBTCX3G1fvB5MoZRYmpHZUn3a4ba Z0HD2PPKCvP+ToiaJVlttssBzz4MRwJIAAkggVEhYH/3HHvqiMMj0svSI2tRE2yOQ45ERyjfg+cr spckOQbD2yqkny9KNr7Re7iRxMn60v3fnqlELnxoT9uuO5XLxE54VIL4P92zQ4lD9t1IVfLAoUcU OeqTxJrwqnyTPE2s9w6SM2/5eUiQdhykGdmx1H6OveLkVMIE2EnXuOlvPG5mL5uhUrJEl95dX8/+ wvPKo7isntFS4/4LvNLXyJcFxoVQV33FlxPmzLq5RXIwGkWgk3FKhPrWY0paMo2ipSHdFbfvUZLA DsoDJw8ql3DCJAY7Qxl3KWLLV2kgn2pKPOv+/d1vbkzkCGV0rFvak1sM9ZKNkBNH35trYVowxGKp RBLoDpGK0MwFt8Gr1/KRKe63GnrzSTmA/JXNNJaaRlu2fw6GG7xfUaTRPZUcRbc3tB+D2a2kj8Eg TH3qd6ce07YlaRNogjHVefy3h3a8NEXyJJnQBnuHqw5mr2G3FnwcJi+gyQepQcYQOt2p3cxVbOFN 66rsKpPE540FhrXAyEQXYtF+GttkGx6ly0JzSX5+qFi/3ls4TfZo8rdmu27X4WiLOJNC41Rs2D8w JE3Z05DCNdpR2ad/8Myt0kAOItjp19i1z5wGo+fV2Ka/mCC9iX9dLkBL7FauNwOvkQASQAJIYIwJ pHvSBAaq5GcLYaAPDvXjkjRp0tTbLwwMhEJwT/8sBeHizgaECJzobw8DVNKSh6INFXPgx0N4ywAU GRCPUKgXfuHPVu9oOxyVgJBIYRgy0pfUhr0WDIFSlF1ixBdsWGohX2ur7F9qB1PFEMDBQlr3s31X FdHGKctPzXO3IdQqChnv6t/CsEqT7H2bpaYTS4pa5j4Q4b2jo0vEvBQgudGfxmHbwtReHTgOdU6q rhFbbLQPapMnzXlqtYCan3zayePzRgfAWmBkYgwxbz+T9yhjDokQaAToBZxABw0Ho8EVY0AE5oAt IWtkzkxpsHperhoTpWYJfeE+Y6/HNQtvIAEkgASQwOgSyKa/GKTxf3FzAvgOl8yaG49YhtPpypG/ itXcd7oSv1HY3uJAI4F3kazkcOtPVu0dqGp3E4XIdgvkc3iXyxXMyPj7a932v43n6SNKdeUyKZik GbFbduy1YAilyuECd+xYaiFfazuRyfYvMZ7TlWfC1vyuNiOrK5afplO+Ov9YBFZOmZsbO/7iqvf+ x78ilSVg1eLMz22Wmk4IKWo5yDU3UZ3lMPt/na65DH8ah22LpUnjUOek6hoYaKd9sOQwESOkVguo pcmnnTw+byxrrAVGJsYQ8/YzeY8y5pAIURoBOMlVDb0SMeQziGDSncqx0v/XlAar5+WqMFFqljN3 nsmwhmse3kACSAAJIIHRIZD+SRNzvWPKQrDm8cb0bkwgm+35yj4rPPhsVWlRrssZDff4Ku/cfeE9 x7eptvMYUyXTmPlUszeN6EZNVPDluxfe+hLNDt7g9bhg5R48NAQmRNui0RjWEMb2UEcEL5MhMCH8 x9KgCWEF9pKW5TiZIkwIn5xMwNEWJIAEkMAEIDAaL7b0S9sPUxze7bzlSEdDF1t5CAMtmxLrp1C1 4YPeSfvq5FSz15YTjK9Iof13UT+EpZR5qyCPL41HR5sJ17YAlgmnM7YPo+PMNnOZcP7DtGvCWYG1 gFmOkylwwvnkZIKPtiABJIAExj2BDNBw5Kd2YuFwBL5zccQgq5iDfK7BePd+5NVIModYLBKJEJXh 25wJonKSFmqjTzV7tdaP/6toOByFb39yh/PZy/i3MlkNJ2LbMhF1Jm/FTK32MFlPHL34E9N/9Hwm phVYC/TlOJmuJ6ZPTqYSQFuQABJAAuOYwOhMmoxjAKgaEkACSAAJIAEkgASQABJAAkgACSABJIAE WAQSu5Cy7mIYEkACSAAJIAEkgASQABJAAkgACSABJIAEpigBnDSZogWPZiMBJIAEkAASQAJIAAkg ASSABJAAEkAC5gRw0sScD95FAkgACSABJIAEkAASQAJIAAkgASSABKYoAZw0maIFj2YjASSABJAA EkACSAAJIAEkgASQABJAAuYEcNLEnA/eRQJIAAkgASSABJAAEkACSAAJIAEkgASmKAGcNJmiBY9m IwEkgASQABJAAkgACSABJIAEkAASQALmBHDSxJwP3kUCSAAJIAEkgASQABJAAkgACSABJIAEpigB nDSZogWPZiMBJIAEkAASQAJIAAkgASSABJAAEkAC5gRw0sScD95FAkgACSABJIAEkAASQAJIAAkg ASSABKYoAZw0maIFj2YjASSABJAAEkACSAAJIAEkgASQABJAAuYEcNLEnA/eRQJIAAkgASSABJAA EkACSAAJIAEkgASmKAGcNJmiBY9mIwEkgASQABJAAkgACSABJIAEkAASQALmBHDSxJwP3kUCSAAJ IAEkgASQABJAAkgACSABJIAEpigBnDSZogWPZiMBJIAEkAASQAJIAAkgASSABJAAEkAC5gRw0sSc D95FAkgACSABJIAEkAASQAJIAAkgASSABKYoAZw0maIFj2YjASSABJAAEkACSAAJIAEkgASQABJA AuYEcNLEnA/eRQJIAAkgASSABJAAEkACSAAJIAEkgASmKAGcNJmiBY9mIwEkgASQABJAAkgACSAB JIAEkAASQALmBHDSxJwP3kUCSAAJIAEkgASQABJAAkgACSABJIAEpigBnDSZogWPZiMBJIAEkAAS QAJIAAkgASSABJAAEkAC5gRw0sScD95FAkgACSABJIAEkAASQAJIAAkgASSABKYoAZw0maIFj2Yj ASSABJAAEkACSAAJIAEkgASQABJAAuYEcNLEnA/eRQJIAAkgASSABJAAEkACSAAJIAEkgASmKIFJ NWkSi5zo6gmNSknGgl1dwWhsVPJiZRKLBgNdXV2B4BmBdXuEwmLhYCBwYsBc+iiWglaRsWGi1YFc 2aJkTJbekDErhfSaMZbS7JTjWLcDY8lHk/co+Fs03NPV06fJdcwu7PiGpJyRjDFkzOywnfEo6Dye ytc2l9GNOAVKYTy3qONUN4NXJNE6ja7/Ym5IAAkggQlOIG7v6Dv0dMG0gooKrxf+bXxD0KYKvfmk o3Ap3IS7hTlL28KD2vsjfjVw/KB36XQoiuyv79Lplua8h6Jtz66hZb4t8HGahdsT13d4h9rpvI3v 2Us33FjC8b0k3+lXdQtDTFmjVwqG7MeKiUGRuCUlY5L0hoxhKaTXkLGVZlGO46AdGFs+Su6j4G+9 hxorCrKh7Rnx5l2xyvTEwjfktEYyxhA57vj9Owo6j7fyHYeFMflLYTy3qGOhW+jVh6VBtTyubgnp x9VMr7DZOo1DJ0eVkAASQALjnIDdN01yl9zdeeqVMufrjXv3NtZ9q2r3MfVze9719wptT+fu2/NS 9nWt/QfL5uWo77LPo6fS+aZGxoyyyntIRhfOYGc3zFCVts5Lr6xfcSHIczozkpaqkpN0Wpqg/53S b6z2+MhESe/Ld0HYiw+/0TNC77xotXXm5pVkOrI+U+aaoTJcHWekS4GHzMBkzz93jdVbQGxKPM1H InysSsG+LWqfsZ9qdGOyy1Gl+bDagZG2RaXnSGflSNbfktfNmTOvvOp2YshlzhE3h5mBVme2bxgT GskYQ4yp7IRo9bGTIvU4yeqcvG5jX76p0Une0tTyIammQCmM5xZ19HXLu+mxgeZ/dTS92NjY+NKn yLi6PM8wrmZ5hd3WKXVfxJRIAAkggalKILlJnaHo5i/PpKjqO/5bm1Zounq2p/n32kDulb/qkvr0 vqlx/oR3Rmb2bXtG4k0TnbYhcbaiIaif+OdaK9/QyZGDk/jbu+c24N8kZS10tzX/5IZPpZmkrA5L W0GHVx9nJEtB1kv/18ikpeukPtKoXuspjWrmkNlYlIJ9G/U+Yz/laMfUl6NO85TbgZG2Q6fnSGeX lL+lqNvJV6Ddyy57Sdf+jLhpYgYsnfW+wdbEWBONIeyUZqEsfcziD/deMjqnqNuYlm9qfFK0NLXM INUUKIVx26IC/rHQTWiqvAjavUqTcTXbK+y1Tim7IiZEAkgACUxJAnbfNKETJfBzR65rGj1/yPPZ 9lOGBTXOSRHN/8S6X1nm+3NeCm9qmMg9Fze5OZxbRm1Te4vBKCcFrZwZ6t9anflzMx578+M0kxTV 4mjrVGfPiDNipWDCSsfEXVZRvni+SfyRv6WhNPLZGXIYi1IwKMEOYPgMO+J4CNWUo1Hz1NqBkTbM qOdI5+iw7W9joNuwjeforPENbiZGMsYQbmL2DY4+7MjpCbWt8xjolh4Lk5YyBpZOgVIYny0qdY6x 1M1kXM32CnutU9JejwmQABJAAlOaAPlQPNmj7uWXw1W37f1k6Hr36t6+xnze3EfsTEdLc+tbJx0X nnVesbzaW06f7cP+nfOvXg2Ztre1unpzXEWlxfRzHuFU8/YtrUf7nDlzPZVVlaVF6udzlZKxQPsB n68l4JjhdheX31TpWTBHdVd1GjvT3rDVt/ewc8nysoLM6MU3Vl8nP0tzdFMllk652sLnOfAlUKRn +5aGrjPx4srq6tKFcnKGhiZy5FTyX55uAyfaO3vDB7shXmtrq2tBTvRsaGXV/XBph2Q0eNS3o8ld V18c/4PP5+v6w1BxeVXVcjZktraiYr4//d32dTdA0bDjyEZo/jJL1qR0NInFC9tMnAtLjP4QDR1t 3rrduWpT1eUfNTc2d3X15i7zVnuXueJnO5p9rYD00sVVNVXuXNXrr8wc42e7DvgjTnFEEos6F5aS vIQTrQd6nS5n9NzssuVLXFpKkinDJ6BlEgkebd15yP3j2rzQW1t8LZGPZpdVVVeWKB6ojU2uDD55 eWbHAX+MmhKLuoqWe6AaCqfaX+t2zHbGzs3wLF8GtnBrkDEHY4jB6giv7kNGTT7fi8ccn8/1XF9Z WbHEZZRGQgxWiHVf8u3a+ryT+x7fcch9S13tjQvBFnvtiYMdU1uOJt7ObwfYktnaKvaCT+5ti7pc jpgj31Oa78oIdxzois6Aa8W3TeoyU09WjvOZraiJZBG/fX9glBRTNyKWV1Kkem7fvqPNMX+xe0hc yOnTqg8DFWKcE6s6wtAQJOlYff5LeT/58b9AuKaN1fqGmD9bGkc1ORgMtKyDclz6l8lQp7Po/5O/ fAkQZistkmIxUTWPWMuU8dXwahkUgb6PuPYiyxaMlh2vzTdrUcXCVf3HqXdGrZSxn5JYXfvOzfaU Lgy2t0egIwe3gg5R7NzDHQcDUfg1LpZXXEqHo2a6sdoxth+yYip6DfdE3TrZGbFAfkx9Bnq2bGyK XVZa+/1lnKH4cDXF9EgACSCBCUYgyfdrhIavXNAQGhSO7aR2ZpfuGpBEiJ/nNMqf5/QfhfUvHLNu bmhpaVp/C4k8/So/LBA7FGmoqy1ZRN5wKVhxR43X29B5GgQIJw9ASMaqp9pe9ZGE8Cb2XftZb2JL 7yvWNB068uZ2Es/hkNbHGgxqP88h+mTOfcDf3e1/gSzd6rHUzciCoy1dTKTivhoxf+m/zYF+UQBL w5MhptXGDOM8bgTRQW+Fly6I6ChaUXPH8pU3V9khmend9sOZWVTLknu9Gp27PmTowLI6tJ+snwKH 9IY8Kw4RpS8FTskO8UvHqJB9Jt6Kze3aD3POh2tmsmcGC2s31ZUkZknAVULK+rbcHAXqS8Ah89qn uvvE77MGwy2biId7t7/do6Mk2sL27aQIqJmc7qQVhBRGQQH5Xz4qlCWB9aXA8snQ6bb119CkYEvv gFjbBsNNT5BA90P7B1LWkGN11p3P76yrYXkssSjjkntb/P7NK2ZD7qpWRW05y4reoFK+BUsLJRKz bg4cb4VzG+0J2z+DunLkeLtpO8CQrK6Jam17NSsrC72HpJWe6VLToWPt1FHdO96LDyb8mVGXjXoe PMri852n/hdZlUnTiqpIMiSTcuDXWTv+xmkD2bUDchsM1l0wzZG1qMF/WKl0dr++tK4jtn0p84tf /XtNb6VvCSkZ8S16DU+6aqOejLaFhAUmzesgEa46sHxVMLh9paqOYC2zGF8Np5aRsmC2CaYtmFiC wkl2m2/eoqoLn4qhX68Y6h1TK0NqUvvEoSkMDre8LQwJR17eSHuQjJVPHBF3Mwgdbia9rev27oEh c92M7RivtbffNxG89PMcZexqMEI34jK0ThYjFhi9GzWnY+/Qq2sJjaxFvIX/jbpgCBJAAkhgchNw JGkemTTZJi6oQbsQaFTdG98WhZCOSpqYGIo2LLuQzJIMSI+h3c/eSprfzz3RJwbQr0PlhTniMJNS 75ox7WEqJx7/sLNA/EGxybBaePzjnorpmfBMRedTel8gC3zUHPgjUUA3PO0/CkLqO6VJge5NxeSR Aw4r3Ugc7aHXVl6BFbJu6YWJEuGIaF0l7dj4GhrlaPOxpZtOiO6SR7Kx92Rb3TdBYTiaumGWSuh+ 4Xtw7qFM9HqQa51kQRD6ju0FpOrnFl0ckkxXCryS7e5glw4RoT1slBdDDZUMQRjwb7pWNN3RRMor TtalFw/3hjfIXMGg9OAtLVJjlSP1/Oy1byiZ9O4qnXY3uWRQGj4BJRvpRBD6g5s9F0gWHTk+EArU F4mzP9OvOkJrnK4U+D7pr7sS5LiffFfJBGzJzvs5qV+8GqRENTnhWR0a1BeWGBNmTKSJA3HylL1D E9OK1uPCQJ/k21mL/Me7m9avqml4/Sezp9tqTzh6Ngb77Xi70gYy2gGe5B65Jira+t6lrZkaJ20w E6smiSs+iC2MIAxGzOuyljC4v4HPDt//mpahb0WBpLlkE3+w7W9a3Uxa/v4W78XgmUofQdsr22ua WNUR+77kezcormClaMKo40xpzF4JyljHKh43q4Nqn5DPtQynZvma95UsJljLGOOrYdYysz6C34JJ tZ7Z5pu1qLL/J/7y6p1JS5VILJ211XwG2pmadnEMGY93i0PKxLjo4x6YNKE/y5npZr+1t983EQWT njRhtE7yeJU5YuGNGMnY+3QnDLbd39sj/yxqYIcBSAAJIIEpRkB8qYM+fiX5f/7KZ9pqvgaJAnXf rH3tpDp1LPTWKv9H2Suqi13S29Ru7zroe85/8EjHH8gyKPTrUOUb0Viw86Houf+7/pu1dbVVNbW1 1Te8L65PcuBoSC2WnGfMzpuelfGVPPK6YOxMsC8Cf88w946JEfEPXe3Z3tELZ+6qrV7y3qXDUjeI ozt02ip34Xfg8nz4MsjpLl0Ogb/4dZDE5GvIk6MItKObToj+kkOyrUfIK5wPGYHOle5LQef8klK4 /I8WAod56CTDJym5+YVF0zUOo4tjlMMr2dYjYYhsLB2GBCtfgiTmajidrtzceRANVlOrJOXlyCu7 g069Ham7gThFzrziG8kP7/SwLIX85feCM/+/p77VHhHdVDjx+A9+uXPtMkhupDR8ArJeyl+nc868 3FyywTbMCVYWL3TlFT74q3byg9gnvw6ciirxEid8n/Ss+ynMXgUequ4gLyHDa7onNvzTL+/xlYtV hXC1U0aJjOQzntVQo3WFRWOW/LRK+sovr6Slvta7tjpXvUMTFcu04mwcipf6dt0brZ6F7sqHXtiw ePCxs5/YaU94erYF+ux7O7Md4ErulWqiou0W79cJbe3hdCXegYI7sZhYOiSOE75eNK/LWsLE/XV8 ttzu+cKMbH0rCiTNJXNaVK3i4hWzpMRWWqubg0eptW3fTY0fwgbD5QskDrS9YuTFDrKqI0wNWb4E pUPRU80hN2MdN2nz2dppQ83qoDYmvdIynJrla96PM9oErGXG9nDYtYw0TOCTzD6C34JJtd6kzWe2 qIyqwKzF0M7wtTIK8Xj/HQJ/9i/ttOPMW0Be3uyo2xIUm9xw+zPvFu8qU21bw9SN1461GVp7+32T UVU7IYzWyeEwGbHwNCdj70uXNp873/38LZxPZe2og3GQABJAApOKAPvLBXsmOss2v77515etOTa4 dfkXPL0nnX+bTTue2KkwkfAXZaDvcMy8vHrFRZ3N/e2BUOWCK5jy65sPlUmrk1RVwasA5xyuwoX6 mDnzNvz1k8cHTjTXXbPyybf1d9XXuQtWzp7xfvR3P1h2xQ9m3dz0+sbaFWTWIDXd1IKV88SWw3Qt rg/EZXHta6gIkk/SpRuTZKyFZKPXOZk1AmQ1k/7L0Kcgt/lhRukYRaeLCZGsWk2NrMNzifKs6nTf +B1H8/M0d+scZxY8/sCVyzb+ZuO+7rJ7vxztevEXuT/dLj/dGU2AkOEQYAqkgXlz5Ufri66k9auz p6+6kEwMaQ4Tn7xo6dZ1xJY1zx3pfuDrYEvj9O/2LoZpNYeDU4M0kk0vGFYXLqR+qKSLBH9DslLW rcuYXf7g5nLltvrExAoxmjtPVFtOwsxdvqn5y44Z/4MmEv9CX6doOyDGZ0qmBHTa8sVz7+jztarL iRytSLIl2/cHK/k6k4yU/u/AW3sdjn/wupUqan+tWZ1wTh25wrwfSbDSiWNe/v/2zgSuqjJ9/OcK F64gXjQWlwQ3EFDUUsYW1BLnX7nNhKVlOalZadqozeQ6GdW4RM2oM5plucwvc03ql0v2G6lcyhw0 F1QQVOC6cS8g98p24QLn/7xnu+fes9xzAQPH53z4cM95z3ue93m/z7ud97yLl/F1l6GSB929ql07 dfakz3+BfT2X0gwqJxM1cmr35FkpP+EM8S6wQsPqCJUyn21AujMXlagu4JUIay+poEXUbwhMA3zv 6Iz9+ZOf6ar7eQfpQ6Gsn206tnL5EJ+vXto8I+1tZykkbUGJdJOWY9CClS3tZX26RK1pLzy1WH5t fZo2digNCSABJPBrEXAZOOB1oLrw2YePwkd7ePDJ2O7wbTAG1kaF1VHzz5AfT4144kd0FAZH9hcf g/rLbgpzauufWrePee7qCFiFQRgwKRLDn+rC598s2PjHgeS6bOezj3S/b9E++CzSMN14oZp+tWoo EdZUumkkScIXd2xJ9GkqBxl9WneQtY40xKZiIpWs5KIlxAde/jM8/sPilfl2+/65/5j4j9+rf41p DAElPcFd+PoNbTnS7wMHkwGlj6ikyUdeeRf8n/rL/FNV1v1/Xe3719kx7NLOCjlIKlzJRSbWkkWj 7VYzPF5oE0WFEed+zTiqxALuuz2iJXRGKqXdJ+tf+38VyW7aapep6NNTXhaHqE7SPQhWsjfpwSv5 UkpBNzJBhx9lh025K+fhWhRrlzyirqHoKQ/y2dvq0jyKUMyDHp8UeRDr7J0+d6B9tZTSwEbMRISq EaeYy8TwvCkThOe8KvOFp2RP5NO5V1q1ipz0j/Eg/ON/51E3//PE2l5rP5wPl3/7dL81/9ic8oRp 7CcE2eBdHaXlmNCCdUuHKj5dRTbZlXqL5dfXp8kihoKQABJAAr8igcZ1moCiAX03ndrqpnCHGLJQ Qt23P7PTF8R3H+lPhnuwh7j/Hlz++cJH+aKxKdbv//Lo/5zn/XK/9ss775vwd58XP6/4/PUYZrqN mwfnZVXBDxn1k1ZlVMGKD48EgvuppSNBIY26OeXwZ27agrPUBRw9aij7FBtIU+mmhSQfLQ+/KtoK T3r0I9XnkU/+LWsdQaZw0mAmggRvT7SEaOg+mqzaY/3shT88/uyFx2c95kzVssE1hoCsQKmj3UoG Oj0myl+CHw9pstsQsn5EzeH7Ato9+51t9+/u4x5UyEGCWI8n0lgLOVpIMx36DQE5B/+ySZz3szdO XHmq1E2+h1hI8qNK6G6StfuEBwXNBSFSF+GWimSVp4THnX7YyUoKPWKCf/GJ81neVXDxSJJ/wvVX c3rwKF/QhA1ASumFn0nFVP8/P7Nfnl31aPiVkEe81RCCdNNZrIRHaWLP8udKeVDeN3GV6iO4NFCf O8q+WkppWUpSogI3CnOZlI66i6c0I8vWY5nvfEo1dMV07kkrN6kxj78ELj/8KQUmhvu9sXzaK9Ng S4Hazc+16/5Y/3dTuE8I/DMquknLMWl9x4pR8cmH08S/6i2WX1+fJo4eikMCSAAJ/CoEvO40Meh0 ogn2REdD7Li89EWctswMiOCYQbBQAl30z22HrnPutC3/QhVsptM/0lnp/JwP70X2/AIrzLoHb/Xm 93tO3JDPTCW15x36/fAlrwxxfxfNP/Z/4DO+b1dWSuFpMqTF3x8msUrWNaFts3+3AtrcBljx4fvi L5nlV7LNVRp149QW/QjaCm75ZmY+jnDNjKxR0bCaJn1CUjmCAC26FeaTb7BOiMzDgkztJLlAPY0G EiQLSkpPVPwo6TMtsa2sdaTCG8xEKkppFAbxycyCZqlqCREs8Ps3/wLPHdp5UP/m7P6SARRC6A0g AJsUfvXV/mxJihZkOk+EpS5o2/6FX8D6qTHhbkmD+FVJk8wXMMPji9eyMmGhTbLxMHso5CC46VFD pVgLOVpIM8EdI0EglBVPLkpjP8dZT+6Ifen0I13dx+6oxILNWfmFXD+Lx9C5CIIVNZc8wiOC5oKL bDngUbKgrSBHenKKi5H91MFv4a50PI7LI655WUZPno9Hki5i4YKVrJwe3Px7lC/opkRpxnNk5WZY A2v5t/xqWXYbCYWPo8cU6FRJLo941FBqHUFnp2T+TEWa2xdm/gnpr0IelHrkXaT6CDqr6MPmFF4G /3sH2ldbKU0JTPioyvxiLmt4LvNUJsiy9Vjmy5aoUssppvOqq7Pk2n5SCZxLx9+QTWrKdq7aWfG/ L91HtYqcvYzbV27euAfdnpLVTakcE+o7IR169OkWHHfpTXe5vASFFouaPrQt+9SpUxfcv14oyEdn JIAEkMBdQMC7hW9vnoI+eNguR7rdw1FmgxJuBxl+EXJ4i/uGbLXD7dXCbXMDq3kzS5RTj/xh3rg2 +j+RTXO+XzpIgM1uEyhs7iDWsOrc/7DeZq3dsOwPRva8L2y86jf45/P7oaeGbA7H7t9ZmQ3zhsav YlWt2vrHUPDD3mIXSFfSTRwcey7RtorVlt82iC796R+gic8Df4O9gVQ0TPvoOaKwKNbSsDzoVpnP 7pMy6ytua2eJbgok60Fn8h7yyCpunxSxzlI1wEUqGfY8JoSDnobt9xTIwPZ1jB/BCkqWVbaOVBlv mUgk8HHn94hhlYTV+7mkUm9d+2gQwJnnuoS+hxTCb2bM7XjNhyqlJJ+2lQhUZpMlXWFLY/EWyLxw /pdbVN/nufV5TGo/ueV1eETYctjNCippkt9NsGors1mJsNsUCahRGiqkQ5l0VfX9rHASYTj8Bo8f 2g9+nRvf8BGGX+VYPPzJ22RnqP4L9wrlkjxzkTThVMmn1I6SHKFWDoB8ecl8ThRrKygjnLA7pACQ tVu3LhvHr1LsEz908t+yKvn0rJCX5fQkeV8I0SNJ+VJCKT2AaVxzvbL8wdIyUIkSu9cmqD1r03cn f/qKzRSw/+X4F/74fdapRuYRZQ1l0pKEJx9fviRUliaplSSsBIvDHZk8KLotnEr04dLDXWZfbqMT hVLanYlAT3yCuayxuUy5TPDAVr7M91Ciim0H54r5znfAYz462bafmwThsvS7VChq2K12iWRmEzdo 0Yk2jvGgm1I5xra7hLwJwuV9CqqIT/j2Xv9FMk1u1qNb2QuO0pqLE6nQYlHS58Y+Zsthvtks1gvP kQASQAJ3JwEvthw++nfmnR/qFjhgO2FmH3sRNbLlcP913Ms8FN3sixzrHf4v++oXp+ebx9iVUFoN WsK+9YH/70XyW01Yw7s7HyJnlflrx3OfoIe+tzfrp38R+T7x/9q9XggITsj2kEx17nT0id96imw3 yxyquvGenL8u2nJNW1Zyvzmff7N+ihAK2UXvZp6shiR0Fzlcv4MzFO5MUTe2IhfCgliT13UZmVKS Vez+nZzOCyQ6s91Mbqq4Ss7bR1oVwsH1FLj6qbq0Q/AAJ/wmnVJ96lWt46YHXHrJxEWAS9x9Xt91 ct97TiWB4S8nuf16GdcXtrEJWDFEseys9Q/59vhUeFGHW/KUZNO2UvoU3OGVTNYuRAOu08QZEfJu ye1cK2MFhVwjyhE0aSEFT8wTp0pBEzYYIQcJ7moaEiXlc7RrmiGxqbd+OZfbDxuCGr98l6ipSu5z h2wsWvV6RrSjE+lp4qAphM4LE/3K+JS3o4vmnsoBooZEckU+7K0uWE2krUgd9pRvLoNnnzmfZ51g CrpHX9v6/cntTPcWK6SfbF4W6ykboixJn96vjwoQdJORXEK6oQUPUP6w6ce79CbWTd1SlfkbXxgg BMd1mtw3ceP+X0pv8pqopUC1PCJfjyilJVedZdKGPE+ZWkmGlcjyMnlQdNd5Ktbn7rUv8FAopesw l2luXzUylwl1AZtR+TKBpFWlEuyH86TGlJb59VpKVCLYeSjku61HuehzpYdYK+fDrmeV5FuFc4t3 +I5yT+tHtnP7EJMKV1zqSlt93pX2knqBKwldVMpiPoQIBSDX3nPxQkvLE5nSSfSItMXC3JTXp/QE +RYIrYIsOfVEUvEUCSABJHC3ENBBRJ3lcmPP7HY7bHkmkmK35hdaYVPE4A7SBUjAM9m+UeSbzLKx Flop2CJW6l3kD3yRJ5lnZaTwPol8CvzCPAcYhCiRqKYbL8L5qxKO05NwpqyhNjmN1k0jSUFhhRMt 2mrxI2NZD9aRKuQdE+nz3rt4DBEowx5PRpc0rBSM1CJKBAAoTE9r1/+vJ20HFSb+2Lc92/nZbTe3 Zt38fQddodUOyTvYNStJ1VBOk+DXvmlg6KqXD558+X7xg43QkBMjjTVzQybNgHpaIqIaC7Hu5Fwh dHdv3viU0VxGnMhJuw6ih9hTu7Ww0G5gC0M7nMKZxI+Sg2c9vSLJKaReorrqoixfRjclSgwCiq0/ rGZrcDhHAEQ0Po8oa+gaE3Ilo7ObJ2+kuT3KXsrnQVmvt0kfpfwuq4NyfGVY3Qb78kp5LKV5jwq/ mMugkQSlS8NyGWQMlVaWB7aQhLSU+QqG45xl06GqVvLyiByoRfmbjFiPlSrvm/9VSuf8feevdp/O Zxp/BqEqtFhk9bEW5lPBXZ1QGq8ASkACSAAJ3MkEmrbT5E4mgbojgZZCwL5/XrfRZz4o++Y5oQ3n qhrXaQJfxiapbnXs+pT0yl5YAC+iHeznP2k34OXvS+sfCYb5V1oOjxpqEYJ+kECDCXhMgU2VRxqs ocYHG5wHNcq/Q715tO8dGq87S220wp1lL9QWCSABJIAEbiMB0XDr2xgKikYCSEAbgfqC2YFBo64t ufKlUo+JU47bkszOG9rOsre81LFrx9atddBjAsuIaO0x8UZDbYqgLyTgDQFvUmAj84g3ajXEbwPz YEOCunOe8ca+d06s7jRN0Qp3msVQXySABJAAEritBHCkyW3Fi8KRgNcEYEJZcLDyRIzS08uTH17w QwUr94WP0j96ZZjCgBQPQeenvdRt7KfgCRaUvfrZlA4aR5nA7jnqGnoIFm8jgcYS8JACmy6PNFZR T883OA96Enxn3/dg3zs7cneM9miFO8ZUqCgSQAJIAAncfgLYaXL7GWMISKApCdjz8wthTR+KbGcK M9E7NGbOsTU/H3b87urFYhlNGROUhQRuD4GmzCO3R0OnVMyDThZ4hgSQABJAAkgACSCBFkkAO01a pFlQKSSABJAAEkACSAAJIAEkgASQABJAAkiguQngmibNbQEMHwkgASSABJAAEkACSAAJIAEkgASQ ABJokQSw06RFmgWVQgJIAAkgASSABJAAEkACSAAJIAEkgASamwB2mjS3BTB8JIAEkAASQAJIAAkg ASSABJAAEkACSKBFEsBOkxZpFlQKCSABJIAEkAASQAJIAAkgASSABJAAEmhuAthp0twWwPCRABJA AkgACSABJIAEkAASQAJIAAkggRZJADtNWqRZUCkkgASQABJAAkgACSABJIAEkAASQAJIoLkJYKdJ c1sAw0cCSAAJIAEkgASQABJAAkgACSABJIAEWiQB7DRpkWZBpZAAEkACSAAJIAEkgASQABJAAkgA CSCB5iaAnSbNbQEMHwkgASSABJAAEkACSAAJIAEkgASQABJokQSw06RFmgWVQgJIAAkgASSABJAA EkACSAAJIAEkgASamwB2mjS3BTB8JIAEkAASQAJIAAkgASSABJAAEkACSKBFEsBOkxZpFlQKCSAB JIAEkAASQAJIAAkgASSABJAAEmhuAthp0twWwPCRABJAAkgACSABJIAEkAASQAJIAAkggRZJADtN WqRZUCkkgASQABJAAkgACSABJIAEkAASQAJIoLkJYKdJc1sAw0cCSAAJIAEkgASQABJAAkgACSAB JIAEWiQB7DRpkWZBpZAAEkACSAAJIAEkgASQABJAAkgACSCB5iaAnSbNbQEMHwkgASSABJAAEkAC SAAJIAEkgASQABJokQSw06RFmgWVQgJIAAkgASSABJAAEkACSAAJIAEkgASamwB2mjS3BTB8JIAE kAASQAJIAAkgASSABJAAEkACSKBFEsBOkxZpFlQKCSABJIAEkAASQAJIAAkgASSABJAAEmhuAthp 0twWwPCRABJAAkgACSABJIAEkAASQAJIAAkggRZJADtNWqRZUCkkgASQABJAAkgACSABJIAEkAAS QAJIoLkJYKdJc1sAw0cCSAAJIAEkgASQABJAAkgACSABJIAEWiQBLztN6IqcjMs51spfPy52S0HG eYs4XKmL+O7deU6YnL7SlHHXZvHmsQVdaTqfn5lb1Nj41pTbK+DP4ZTjKdZNwtmWn++WpJ0KKJ3V VBJVle7+F7trt7Un27lA8p5nQ6zmEmTzXWhnqFFH7+lpFNwM3v6b4gL47nJbN9iaTcWNrrTXyDaT HExdU26vEVU3zZDcmSArSnJOX87IuJRjsXmpgsMOlebtiwJDT1k+hK6E18t4NK/3hvPXpneDc4E2 8YKvhteJxI4eMgJJadDmEbxB2hACdj3R7tP1OberpsqhTSXHTT3tlw4lUBIR2n1KHkUHJHCXEfDV Gl+6NH1T/oSDpIBbPrd9dHCA1gebyN/x9Zax5UHmJWGCPKmLcOsuPLGdv7Bo7a2dZTSl9y/4pIuh 8Qi8sXiz2MJ+sSAhtYyidAfWhMQH6hoSY6tp7XJzSiHNPjsoNmD1jE65OwtU0nlTcHbkHLqQ+lnl bshMxFhhmoxVU5y2Kn/6uXpW1RUvd5nwUMeGRPn2P2M6kDnz/6rDdJSlkgMLYYYF6Ay+raja+tCH Q98aE+mtFpps7U2Kpbzm2SCreRvP2+lfE0ONCnhNT6Pcpvdmt15L326ZcrT2wJqB8qXEnRMX7XTu eFvTlUc+zBp7sn50uA9bPNoddZaItjtm9jLQ5rWzTN8YWkXodfba+t0lrTI+vD/Cj2fTOGs2lhtd mXPU9K9tZZ/egqLP5/Ca+6OFiokuObL92qL99mxe05jOfksmdUmMuoc4MPFdlF0f1ZbEF+LFFp5h bX0G9PCLH2BM7NeFf44y7T+d8EUNR6a2PtNc3y+Qym+li2jrA37g2VzK97Pl/SOYKhFK44RtduKZ +KTnLooZGRUE3swZZ/uuEbp1SjoH6h4K9oHy2cQU2hBunx6+8fFtB8Z1NgbqhaApypGzP+ulbVws nhpi/NuUXsRAvP7xgg43dR8siU8IrQU7QrzE7kuWxCeGCQYTySZyKjJ3XBr+Dfe6NzouYPGM3hEC Q4qC+vdP79t2MxVLTLjf6gW944P1QuhiegRdT8PAxNCEqFDXMJrsynPZohyUG/+nk0JWT+zu5t18 NHPcx1VR4b4Gqp7qEvjBzFhxU8HNsotTYpK6EsuSo3G5gJWh4X8j6sQKc9qHV9j2DB3mf+Stvs6c wgZM38rcX7AqrYo0k9gjyHfLi+3MG4ttL0dN7x3Mu0Ka0ezT+YzcmXoOlXtC3k1dDl2Z/sH5d0w0 5Aj7rbphf+g6IUE2fToyNp59N6s+Qk+bzPXDJt47e2gn+eAUXM2HzvX9zKfgk3hxmpH1q92n7OPo iATuKgLaR5rU+3cwLAgn9bC/CiHrtRyLUBMz/qQuKo8r3aq+uimHXvFcB+d9qYvz3t155jPsfqYL zKDdpuqgtFkcZDSTLQxGwyASA70xoEE9JnTxytfNbwUF5mz6jXlN5Ip7dceyKhNm5tV6SOdNwNkQ 4D9iIGOs9tqMRZemLc6DFsaLye0LVncGVeesu5pT4+ySUDfkr3zXXlJzzFLvf6/fKyOC2L+5I/x3 m+t3XqsMcGf/AAA2TklEQVTdaa5PeiCkAfpos7XmFNsgnl5brQHxvJ2PaGOoQYMG0dMgV9VLA+oR eJFbdyJy9rUpR0m7W77aapa4qEa0SW7e2bYGBLqAgZO6ZbwSZIFCg/nLhR6Tl7uTFwBd+8nLuk3y J+VJblvD4aU9nD0mjbZmo7iVX10569zgdbcyo9tkrIwzbxogvAfaLZdmTrk0dr89amDQ4dRuZ1Ij DjzfmrpWM3bJpYXbLhOL6wISX4rdMT0ol4ks3S3gzakhS6a2G2asTzlUOXbFjbC5p001xCMcEY9F 5cwLpq4TMjt89Z+tiUtd0WvJCD0LKuzh9t++25vtMSGek3oULA0JB8+Vvp+kxrI9JpTl0rg1lYOS QsybfnP4CVITXaug4fFMX99JI4LmPhU0rCO17JB9whpL9IyTb3+dR0JlDtP+c4O32akwn9FMR8oX h2zjNgj69/psaiCrg6Vb0NcrYxOgZ4SJl9O9SyC4K/aYUI6MD7OEHhMIcPf5yoQZp818RWc/fz46 1fZ1z8Aza+IyZgRkm2uGzz6VaaXd6Fna6if9NqBLWV3KwfJRS/Kmbrio+ZM7F03PP1rKFhUpLvwJ yp3flUmVDB/Q7evU8GH6Oqg3dx4vm/kZg5oXK1h2Bw1pINbZY9LoXMCH4Pm3gXUiXbx2jgnaM2vf 6Jqz5J4xRdWDZ5wUkjcJ1ZI3c0r28O1VX4f57VnYpWBNr5zUjhv60BNWFs2x0UZxc0+7T9XYeM6h qo8LNz3L0QUkzYr65GkD5JTdZfScddflR3lZTH8+6Dhmqdt5Tffm0l7e9phQdOm+zx2Uo+q4hS81 BBXdTrT7dHsQL5HAXUlA2zsboNHdk/hEbHKih5EpR/5+fd8Nl1wqdWkAZ/sl627aJzHW2bssdWmA 2P+mR4xxPZMnhT4N1UlTjQHSZnFg2Gy2COv29cY+BZu4T2reWtN+sWhZPf1ARz8jPBkYPuHPIUwX TF3ggB4q6bwpOOsjBkYlPxZIFHbtYFSMQsWtfdBy1PvNG9PT0KZz8oTW8Hnl7PVyRf/NeqPaRj/1 3L1rXus78okY9i+K/1T46vP3JoYxEfdWQy221pxiqYbw9N5q3sbxdvvXwlCLDg2hp0Wump+G1CM6 fdRjnaFRzuRrBeHNERcFVZrU+U62NQvCENg+IiHm69RQ1nzZF+zVfuyQB73Bal11hR70QPuDi/pE h5Hymzsab80GcysvmPna9WW36FefC/96ZmxEcBteJ4qy5o2bW7KTpl4dH/7pzNjosNDwsA7xw+MP ppKUuX5/8YyvC4hnv4DwHm3imRfCkUmRCf26xffrOWHuwIK5beGmzlI9cxfjjVwEGHt2HsF8wRoT HxwR2MbgZ4wfwFb8ukmPdzNwoIhU8GwIDR/QVjfooXbRYZxWOd9bsylq0gPkE3f0uJgDz/s9yPid NSkq+YmYxKExE2beb17TeXkHos2HaUUL/20i96tNM7fVrJjT9WDqgE/X9d71EBnYcuwk/7bv1yai b1vSAgHJSfcaA/mGiF9ARN+wBa3IjUmPRTjdiUfXo/zGx8frX3y8fQF8xtjYe89w1tw1Hx0yE390 8UcfVMD4nSMLe4cHtolI6HN4OChAD19zgdwFerEcvUnjeiaP6f3WP/rvSiAa7j50c+t5K/HThIeW skU5OFf+vQ48H7jhVbkBp35tjGGRE97tnuJH6O1OL175k8UplbfsA/eRNOB0b3wucMpSP2tgnZiz 50pKDT368fDk3mHGzj2WPAcd2rUzN1/kAqOvvTO/CPILZHDLkv4J0R0NgUZjWJeRrwzImcMmKmJW cmj3yfpX+q8xhyo9LrhrlONnjB7cns0plKM6TS5xZu4jOZQcnVsniIs41tHTf3vWjfnVpK8xNY3J ucr+tftUloF3kMBdREBzpwnDxK76jgffAcaa6IgAtqojD0hdGoTWcfx/q+iBRuHjCYwRlbg0SPB/ 2UM13NyNJoyWusWZgJrVFtBuaFxsjx2t4L7wwOQR5sgtrvQQ69vAWT0Sdls1GZDsqDNXkIow80g1 tIX7hIraSerP/5p36crcK9Qk8dQhy8W+G6qICp3bzBvu3RBTF8W12dqD7RiJdxJPFwSNvtDGUD2Y X59eQ+sRfXhkB2On0GdcPk26RO7Xj4tL8Lf14s60tTuSsG6fsW9KZdUTNzCvVdVXF/3lZnZ46x3T erp5bhprNoAbfWvLIgv7mvfWbyNdtXKkry0+Bk5B/vOecL0V1mP1WNJY+iLNkgHDJeDwazuM6Qqx O4Q5CZQhLmYP2z1x6pZoMALjHx5x8JW+MYB/DSOSXA/Gcy3vk6IMAWxlx/zXBcQndf8D0z8iDpcK 7Dx5Wc8VTN5Z/3kh0dAv6INF3Sf0CyPCdYGJv+cngwiB8TWjixxyt3UE85DEXXiSnNhNtt1hbZY+ 05MZTxSY8FyvDV1IZ8EJE/SVUOxHDircILQDo0e1Jx1quWWZTLVIuYeuT3yB8UBRP54oBY9Nengu W1SCc+c/vPfIBJXJtoZw+ErCHMvW5acXEBr84W5ZcG+aXMAH0PS/tHnblyR5P8mPOQ0f3G60jjp2 yJbDNm8+KVxDkqrv6lfcM7ixX68tXXQfnyhmtcrU7FM1Ft7kUDVB3sgRDROe/68ronzNBFBe8PHB Ojao0fHef2SiK3/cyyWSYz/b1IYka/epFnG8hwTuIgIeRo7IkjBAt4glb+Om0hM2asCj7ScP7wpV t+mnCwnrSJ9Kenqe8aJv21gYEVro6tIhoWugOffKvp1lfab2jLhx9aM9FUWV1LCRIckPRXABWQvW rrtZHRowbTIzUZZ1rTbD3JyVb4RzfuBHcKFLj+w3VzO9NHaHPnFYu5zvzBa9Dipdu4M2RoYlxt1j OnqBDOCkHCUVPp2DSSuh6XxSEQMi4sP4LypO/Siqwrx3h/nLX+xUW9+HE40jHgwxEiX1BvbzS0Xx kfTr3/ynlm5N+XdsPXl8jHjWLuXhrqpksQ7secW1tM3mfZfrYUWJhx5tlzy8m2IvQ0Vx+pfXtx6r ptr6PDzImDymh/AJT87ifEiCLYiDw5Z/JW2L1X9k5ISe9rQdJScu1Yb2Cpw8sZcRLLX9yjdna+m2 vs9O6ukCTTa+dGnGt2aLL0W0ddD+jCmp8qt7vys3BFA2hz7piR5G5sFtJr3LXF/Z+NYUp39+desv DkMXv2EROltIu8nDuxh6dt6ScCk9gK+TuDalbmCkkcokkVGLNbnPHfaKm9XOJi7v6vz1MQbzIJnJ rpt+BMK+fXS1xIs47chqzsgxhBigVbGbrks/faW6pGTUT3WDhrSPCKwli9dCunLUG7gPTQ5b7pUt O63xU3sNpCxbd5SeuEENSGz37BMio8uGArOC069s+3dVJq3rE6EfMaxjYlwosSYr7YXuEZeupu6t iX4o8IWh4K50MDHVBSS/2w/a1JwnumTtX9gGq+7AQmZKNkDYY7G11lEOKurBHtHBesihx600MPKP DIUMKw239yPtpg8JgiwjsXWDUixYVitPJhLqVoNJ+OmXt/272uzb6uFBbaICqveZ/BdPiaY0pYo7 Kb8IVveCnly+4+TI5npyzy3VVXfqqlt1jGQWvmbpEB9arzXHEYE+BnjlkB8D7W1KQFsrlTxkGQVp GUvwy5UtXpSZFAVvSrsSTo/NqD926GbaoCv+/1v4Ke1zeHEfaUXmRcoExWRLQtc6RaOe5sMFMGtA 9jUPWkoTLpA32wXPdpQqHPFo8KBdRcco+qNv8hOe7QZplRBzPxy3Spz9He43ndda/MCwF1P60UoT k6H2fkuaaqTUdVkrwymR0rVLnhk0Z8ktcGI1jI5y3rXbSIgvjmgnjZfTk9KZXGoxxPYoeFdUI0Jv zm98qSuOLkZxM1UUzdZ66EA5RtOZBbb4OOcwZGeYetaD04GcybRzGlQOE1nKZYtSC9BRLMMfaj0l //yAnVefDLzyVQV8O5nwVrbLWjlEDZdDUy7Q0r4CqbJ5BNwV6kQt+cV+3cb0ieiiQgVbt2KSUN3x Alt0j1sfHyX9BaMfv0foHRNFT//ws4HDCphsUm3S6pN9XqnG0ZpDLxpC60zQeGCk+XcKTYyo2nu4 3KDnm6Na5bA5vR46Sl4c4Lv+RC1lrtqXW5bMrDTEaprz/c2dtM+KB3VzjtY6e0XVY8HeZf/bbkw4 Ry94MvAsSTB1W49a3hoqentqmE/xU3iOBO5iAuLaSCuGfZ9fmJ7LvPLBVMzNFnto0PS+9JEfawb5 UlAXn71cHXy1prfRluvmorv2bkoF+eQCRe7Cc+w7I5zvXFe471Ltp8wiWKafS1POwwuoLWkcLSza Z8suhbk5i2OdnzVELqXVlysmZJBCdtADxiQ/X6rWMWU76belw/z2vsqUrb51H28vP0bplvTTTdhD atym8+lz4EGmwwaEig9L3pi50BLy2fVGGPWf0rHbS+ZvLyH3df4FG/sZuLu6FeODDJcqph8q+/DQ 8V1L4hI7M2/vmu4qSBbrwJzb83MiU6x0Z7+tj+hXba/aublozvdVBUvipK0c+7WL4xbdBJ03vGw0 fW2bn1Yy/9/lOf+Et19yyFi8H7N8HZhKsA59bdGUa58yXz6onEtz2Cfh/1XblwWnh1lqPiRr48FR u35udsbG+7kaUSm+nXyqi6umHGB6I4L8DrzJrEig01M3KiYcrYP153p9czJ6O3tX9wEjF/7Jx/ev 9+57I2+6DaCFUidLx+53DEqqnQy+dW2TZtyXxD+bsweiT8UMNELCy2EcVWLNPwTprCLt9UtzmJGQ TkfXswNrEkhiLr/6zh+vQ3NhxeR7Iq7cGnuApcF5lddcsJTfPSPamnfb6JR1hfBAyuSO04e0XjT5 JEcbat/xHZYO81k0jeM/aN2FYxf5HLq9yB7SZjqz2Jh8KH+N2LfgwvRC+sXHgt8MrR61uWr98bwN b1X89I6FlR+zLCebnQn0pW3Jlwpvn0w8uJiSjhzuyPxXPgzEhYvlc7rzOdoQZqwbu4F0sC6PrIgO DoSeo8ytZZA8Yob4HexhF2IhhLtze1HK9iIiMUhk64amWCJHC88nIohPVavB3ZWv31hWQ6cktx12 yz4hjRkEHlS/mC73nCpWd9r22vU7Kb8QHMyhkR59K00234EMpVwfYpVanzJTfX2pM86apSx3WaGm HMepq/qjMS4gA22tVPJATlGyNRSP0rJlic72Tp43FtQnvtpxKlO5TH//Bphiw6JoYbkQF+tqtqZs SXgksTpRXKdoLNsDSrZuYj8V16W9f3zZ+foYX92Tw9tNY0ZM2G3cF+OwYH60gFjjwOAnjcXHbPSe U5X2Z7n3Mbhv0DuLUPgcxXa7jL6vrbTiFgvTcm632r/8odJ+k5TJe05Vhd/QddEHKnaagCY9w5cb y+aDhj+VizWE1+mN75dBk2YxW066hi3Wn9zRuS77qpRaYIyPq0cb01uUFNvOKd5cB91TBrZP3q/1 AD/dTknla9BzfU8wcRiG/8Dhb+RdJLXGvP+z/qGi7jO2NtbebnEqJHfGlW8y7bQLb7WW4R9yS63F CA0bOxXVr+u8qLzdqVBv1g2efwbaZvCZQf7QkgseD1ZvX0G7SDaPkNajUp2opdZbkxBVyeSIIL9w ftIu5dduWPiNnYU0GM5uqmBNNqyvfPwMcXFvxZF4a/dJfCvVOJ0DNedQ+/zf+aSuK88m4qhXZ4Qn 6uu/3HELurFefTyY4PIyp1toasSwkD4XzdDfOm3HlRGL+GY5fe1faY5RT4YO9LNSR5nAhH/KsRC8 wEnOHmiH+E7+Xe/MnOO7z9V/uLlw9tBwWZrafYrl4zkSuJsJNKTTZHdu7Ya53UbGBmZsyhp1sO7E mVtUv24T3ghJ3H0yYZdj1ksxyVHM+/9DlIsLXZl8f8nGvxam3KKhx2TtjA5JnWo3vl0Crxy700sy RndLCNZF3B80entJbqfWopEXjsx9dnpgO1Gvs9ilXdKMvluWnYJWRZ8eQQZd24TRfQ/YTgw/UPdA TNuEruTjQ0QsKFO+YUncyM5+3ZrYZwxZud3toCv3/pMMx10xNzoxLoiKa7/i1AUoFukHgnOfCTfQ pVuWwF3drtSBibC/CEVFbTox/Ie6sYtyz2zsH06p31WV7KYGXMIc4HdsdGxby7wYuEp68NLQ2SXZ 18r35ZclC6uss0+BzzdLocfk8Lr7o2H2bGROyiIrVVZjqqCZvgpKzuJsp4nYFmFvrvZ/4vOCsT+R SnHt3G7JcaFknf9t1dkXq6kBQTmvxBprTIteg++EtUeyrBPg05AqjcTn7zusPzn4GwfdwS+enYwd GB4VeBVmeayZ0steYTsTeWNc6q1s4XOFUnzP3lhloxe83CWxdyjVu+uByuMzHWwTiY088788788H QG2/z16OFlyVYy14geZg4IS/RyeLHCSnPgZoHECqeO8G9JisXRTLflI4QJ0cDl1CpOvAs6VsWVem ky+Z5Hjx+cjpzHeDJe+VZZK+Od/Da+4jrxB0JfAf9mH+hHP10GMCS6wlx7XJ/PwChPJNZhnpNFHi k3WDLJgS5L/42WholB8uPDH4QN2PWXWLV3Qb9kkBSIMeE+j+s/xw83jr1nPHd1JuuDMxZbVk/sOs CkjbcBozMHgy38sGxKKH9DlwmSR7JnXpI/r1euv1rA9TyqL0Omg/vbnCzy3cn1u3nvmAbqKbrRuY YolmmniCPw9Wq0j7K+kx2fJ276RIUuKdichkJiK1onRtNKQK/6jVhjsxv2ilZyuRz3dquT5aav3j bdtODi5LFNcs/dp6znHEzp4PrXGB92e0tVLJA5iVbF1RLFO2nKlcqqXMFFtP1/nNhWWfMkMeqKBA bjVTsQfmXLM15WvGX7pGnJlrddYpGsv28sqzNFs401REmw0d7VPSHcv23/yyOOfgzGhLAbvEmy6+ k+xsSj8j9KVAR3SlaAAFRU1/7/x33XxgLZOzebXMoBAyt3H1M5GSGHvtYOgavfo9yrT75O5djrXz 4rimGi2e8eEmk9fQWc+WpG8ysRvMwaDfj/5tmv1bpn9Z9Ny0T7LNEb4wiZQ/6r/jt6gjLkqphffN /ZabVsEkhfDAEexHeD07pahm35kSrjapqfhRNM1BeNp8vdTeqd5SUDiTdDHA4TvvcUZDuXaOrrzu mfe7//5Lb9otQkiyJ6otQBh26s4f/C8+p9hi5IOorqw3xPU5/ARpEVFl1WNWk9TF33T51ZgL1NtX 0FpYKd96LPJfr9CS0VTr6WzF7BjbVmzbUqx6etbNpEimS4XSRXWSfc13eq9mO180+FRvZ1ZrzaFU l4fiDva8NHRuCfSbVBffshWQgT/L5/RgU6NJqxxRTg+8J3mibc7qKl1u+Y+WmiRmSynz4WL4lHJg eFfDd6ecsYUztXqzPzOrj/Fefe0f6XWjkkkvycDft6HO3YJlU9JdR7JwYrX7dNEDL5DAXU2ArYe8 Q7B8TvRIGL0PgycfJe2A3dlV7HcWdjUB8bRVFxf4jBDaPpypehe83C05IcLYufvsVHbSKX224CZR IqzHpxt/c3BJvLO8rL4Bc3M+ekw0uszdRf/w78g3nPU7itiP4BEx5GvFsUOl7AxJ05HSY3r/JDKO 43b4JFq7HjQ7dJx7t9S1HfgQ6ZkabdRDfWkvsEAHChUeMJDpMQH3+KdYAjU/XixTvwulpopkVx3I FTsHWJd1a2HqLzOX/LJw2U22j3zvGQa16AHW56CkdqTHBI5OoRsSfJ+Oaw3bxLK+lCxOudgCJh+F hBlJiiJLfJH5HVTEo2S2KryQf/tarBHMEhgywFm6U57iS0WPDIZJy1CjpLNrgFdfTU2vW/FcF5AM a4MJy+axSirGN5Mkz2Xr8jYeNMFZ/Lh7ngnhvjuxD8L/nL0wzAS2Lu7n3IiBDI6QT+fCU9xJoBGU Uf5j2spFV6dcIbtBc+0/6CxLFBqh6pZyZGw+GZ16a1BPPSEJ6Xwzt28OTF2GltbaRVHcR1fIX4Eh XWJI1EBzWGINcigbyrGTZN0WRT7ZNdAjSd/rT1JsRXEuk4ssJa0MwaGsNLJ6a++uyTPuXzolNthj TImOzFF99d332QEqvp/NcG/e+bd2KXnswvwmiIUk3NQpsRH8Eoms7IanWNigQSNPCEnVatT1azA8 JyauLdtjAt6NHUV90GqgILVAqrgT84s39GpI81ea71RzfZ3U+ksn9qSZdx9nzeKZLZtM1P97Exe0 tUrJA5gVbE3pfWXKluI6ynsLGkL57xNlFWnnyySm9cKaSiXh/+VWu9UpWvS03yDvTlBN7VmZMPuZ 2JET78t4nrwPZh+37r1WQdVynd2i4XcS3cHBWRuQu0/1b/3koICH4/2HdePLyWsV+04XyT3ZEDeX hpnXAvRhvQJWPMiVdcs+LyTRdD1i9T5Gow52tWP/wow+Ybz1iEel1OIqJPOLIgC7609RbFPKENlx LbPwyvwVl9MyTKbzF9+ZXsiQp8KZyc/C0ykbCyNnXEhItUH9+NTAgIw197HVukKtEdAlxLt2ixCQ wonndporf8/+mYBIcRo9rteWXqQdAKlr4TcmSHWuOniRC4g05faVUh7Z+9M1lZaMlvzCZQRznahP jYuEvaLebBKaAq4xk1xp96la45R5l0PDenzG5O71283RS8ufejzU+TXI+5xuh46wAWEzmCz+zo58 EkW6JG1TDT0gGIblsolEiLeHWPD+zMeKd9I6tpfQ0LMLm2Wm77jG33f+avfpfAbPkMBdT0DUytfM wp8f/chNt7vF9g1rfh7epUP5z9XGDpM63DxWSP945paz9BFJsmXadtO+S3qK5uZIXAyxoTNaFayB /tT8iuRI3fF/k5dkGMS49XjRW0P0e3c4Xnwhgqt3b4NPkbL8aRU5MVe47CLETkeqZrcWEn9WCgyb 1KEYCJBe9lDmEYW7yT1DKGXJfNjuvwuS2yVFcn0Ez4K1KyljXCc3T5ZLpP4K9eUrYF27kTPajWQ8 sf1QShaXWoeTLKxOx04B5Zadgyo+oM99vhR8KmEOdRpkREabe+f2Lhl7rn5VmilpWk/bsZLdtN/f YPwOd4j67HknmfjGBqQduAIb5czfWDh/o3ntyx2mjyHdLs6DLt73bb1o/gh3RynWzgfhDD5Bzz4v DANxucVdQF/MwLBsQnjQg4F8uoelG9yVl9E8rl3GujOwgklMbNCOebHVxzN3r4YUUPfSuksHZ3Ta t7qMjmoj9MJwoTGvl+6ai1rkcqF0iUjWz7UUwNhy2AXQJQqMtPhIBri2mHJzcGBHxn/AkCIiDLp1 RMPEXMQrXojD5Ty5KNbAFEtXZnySpZ2nWdVqZibXREWQHlv3AwYqz87ymCr4+UouiYGkkJaZX7yk R4UGP9mqVJrvPOd6GeuLAHuVDkXPuZx6GRe0tYeSR8HWlH/nxRs6u5UtNOVIm5XhRe4Ay8EepXOd ff3TU3MHChM8yV3v8jWbEuRKQqgZbzjTibaUFsU9oA/n1xuOSOowY0sBjCu02RxhPaADBap15XU3 2MfFlT4MC32sWxI7XHcMNc2S9+d5sJkIPX1FXliqUXm/XqfismdsVS57S5MjkyuJT13b+Ifgj0oe xU7ppY5ftI1kJxfzgsguPKz+nIvDcO7UbmGwiVJq4R+HX9vpszAUkdltjXwDI4eubfLbEfZ3TXOu 0tPXFLJuzH+/Pp3IQD/hgEG+E+IC7TUO2FLHWeHCFA1P7RxxpaxSDgsBKZ54207T7h82rJ3fLeWV PJj0un574cM99P5t+fWaGpALPLSvKGkecVjL9ii1ZLTVelHsCjXhetFIE+4NIqlfuwg9tN6hfUjn XrclBJOh4kpHRAyYSJNP9RpnRKx3OTQiqeeWjPPsjLlZ47sJ6jUop9dRuvBJT15fs8uRfdwG6xlH FdxIqae3ju8qiBVO1GPBLYlCl6bvIqXNeytOhdfS/nrqQzbT5ZbBQs4wll+QBuNWtPp0PoNnSAAJ UA3pNIHXtkaSszt4CbpA7i2aG3vpJhh2ZrHTD7QTjU6QukBtGv7MsKtrDtRt+s6SnFw34QK1fIh+ /iHHh/uKZvfUp9RThweGcXJvh083lXWBA0f7UZurU9ZdSYprH01f25pOhiNOeqwz/DdfghJN9FJE LpyH+l2Y16Ai2SnF9czSOjC+H7QF1Q47fPqDz+pV/Dcxzq/D7vw6xtvLRYycLVw8eLjwEF/ytH7g 00HUORusAW6abDv+ec1T4zs7RyHJiZeN7+z1vmHL8ubkQATp6eturDpc/u080dp3FWXf0fodwvwR p1jZWDtvkzNdYNLcDoehQSr+kiZ4oeth1jfMNTOZiN1/LuLWGRHui09kNLdcmsjMdfpgJmkgGAZE ru1AFh/JPn5zzB9vHivTpS8VxUIsyy2HCu1daDjKpAdH5vaTw2EaVJjfkZU9qcO5g3dxvVqsSC63 aosp+4jt50vQ1QXno5NCxCucgYu9ptLgJ+rFYR+Q++8sJSR3G5hii2782RueNlWrsXclqjEOujZa UoX8s8quzZxfvKRH6UJmr6ek+U5DLAgCRet7kw4VWXoZF7S1h5JHwdYGCsqWs25li47Se5k7HEc+ gKWRKFgyKargXCSZc1E78eOLB4Xdc7y0Jpsq5EpCGHYvSjLepTRxr26bPjCSlH1d4b8w2WDRbpmj ymQhroPuCxK/3jsHVUGxH9btg9kVO1eQQtxUXEkxY/hlJPFO4hjwbuS3zz3u4yvFdxXPi26sYiIy 6qE2Yg3Bv6Fzz9VjyYzsE5fs1FAXAWL9yQ2aafYIXhRTC+/DcjF6ReWox0LectttzT98wl/Dkyug uvUxBDi2LLg4pxB2rhW3D3kJMI5PvO8y46yh1hAeb8SJt+00r/2HTP972YnXyDCcKUuvgKKj4hht G5ILPLSvpHkkZ/MJCEy+JeNVrWd2wKIe3NeUCiuZxAcpChZC5l8ELPL5hYkp+0+zTw81jrc5VBfY paOOYlZ3XrU9b80zfL+Jt3L4qEQ8es/oNBgzRX+0Kzsptwom4j0sl8c9xIKRZr9YCCPZFzweFBXA lWQb4ms/3l4FS01/vN+UIJrfp90nryb+IgEkQAjwgz+9oUGKNuVDWIVL8CJ1Ea8SX11FWhvyyz6V 31h1hf7o8XBBFCV1Ye5F/z/yKn3sUPHCZaVUXPDkyWFk+z1zRfQiKyztKV407nb4dKrHnEFXNBlx 56gZPCMjfOb1D+tb7VrUg/1AFM5MHaLMdqgw3I6He7ZXvwv+VSS7SSOXzModsFmgSRSW7dDpMZ/l uXkOjyed/jChSewzZ/OZj06VsD7lLa5gCzfhKpce4wvPwqBcZtfDuplv5k6vpqYN6agoUCm+G88e OVE/YWFCwZLQBW1JX3t2Vtlxdr4PK0vvN2lce7cWIQlaNZ0Lahg7d4mO6xIdJfcXHRkd1YH0dzCz lnRZdvnPfQqaj9hszWaC4drB8Kltfgg7SedYGTUqubNzqEKFjR1eJWglc6IQyqg15K2G6hxoSu0f HSwz8V7Iv1piSsK15k38mPl2pvf/G7PAs1OZ8rxxr+QIqgqS2aYS7dqF67zrfJ47a1iKtd2o9Iqn B6sxNt19slyIjtDgAy21spJETcWhefOLt/So6muy+U5LLACC1PqCS+PZeh0XtLV6yaNga3v+Zdmy xSsLmg6cgx7YFW+QlaQNcbCTDmm0ZP98M+08rHdIDq+tqVASSmtGLXoaOgYMIlrU2SpFFS1xIYch sv2CVqTSSfmi0FlQMLfgnz2rEIZiwcncUffybnK/rtNP5HyQj+6MfBjSwk6KFPuym8qoh7u2Eztp O3cc+RdXB01OIl993I4w0plPDejhMtDDzY/MpUJq4Xxa86bOuxnzQPv1z3bnn3Xpb2JmwrYxH74K PSawDNni8ZG8Nw+/HmsND89rvu1dO83bdh2o0abb6oWw4o3L4XUuYJ5WbF8p5JGZl0hyVWrJaMov EUHM3tg1piIiihx6dvccnz492xgiw5b7k/yybN01+caSNW/mX85BUtfuU73G8TaHwkptg3+ofzGO NFa+2F+0N5+bm+atHBJx9mgTMSuJvFJ98V3Z9Cv02kldXNqifN+QeiwYSY7jX5RTQa2nwSTBMbHJ zN/IJ+KXMBuW795fImrea/fJ6Yg/SAAJsAQa0mlisrrW/q6fjY8XVMKcBdN152BaqYtzrApdkn4I Ok34ZZ/o0pzTlzNzubm7tmyYler7MDs7gNFX6sIZMjSMmbxHrzfTW57rROk6v/Ig17Mza5Tra3aT +7QWZp6+bLI6v+abf74MQ3M3pESbN/YpWHef+dMBiVHcXjPGnm1iiMZ1aUeZD0zkvMpEUOniI9uo 3wVPKpKJJK4LjLOpIYQd11o7cN5pE9Ntb792aeKG6kmDwyhXnY0dWZ91E1OzWNPaoGI4UPdw1/aM WErW4oq2gA9LzrdfVhlRMmOmpbDvPx7jS0LXtR35DKlEjlnqYT1gZzcBueciXDG+gwyL1lyFCtjQ udvsVXEbokmVnAuf7PgDViaLiqRtTgfuhmysmXsu4fJi1H7D4tlMUrPywHXOHzvYipmIoaT50105 jpnnuRxBBd87gl13BvY+SLtxJJ95bYB9i2ZeyK3gmyBSRZjAlUJ5wpf0WsZ0YdY0oRyWbDK+xqBv BdsHst8HTUVMD4hUrKwL7IywnCyEDJbb8777Cvg5X908Fuuco5R5nYFOV2YeISduY51cw3Vh3rAU K3RZaeSpbrWIGGZijrli40HOpqZMSRqSRSRxvCPyi7f0KEetbL7TlOvho7ok1cnVIxKUKg6isWDe xgVt7aHkUbC16RjJEbJli2sbQtFsUBMlbK6BtQMm9GbrUH3i1A5TSRFOTU+9xC5b5q01lUpCUjO6 1imKaolvBLabRNbaoLceIp/9mcNuJnW6D9m9XhcybQEzvdFctfU09xGC80WXbGU6l2H/eH7STekJ 9pO7aPccaE39uJNs+guHUdp7wr9TUYEBA2AhbYr6eI/7+gU5e0zQNWNkOv4YMQ4LM7ZU6IWkKNlw KzM2n2UHDAJ/VkMYJ8hI4P7l/kguR/QDbuzBVfQiyax7OTughnNXSC3Ea3nBzDlFuzu1+ZYMI3LA xCu7pWDllFNbXFexsedeYJbcpnYtEc/9VAqd1QHWnPLQztFYDnPixD+isgWcPbXT3Pl78q+DBpDd tXo3RMVkTOEmuLBTv73NBZz6Cu0rpTzy4m/ZN3r5lowYieK5/70vMI3zfadvsH5sv5TCjjnk6ya0 bWCX61lMxeqombjhoruQ8quL5hS1Hcrscq3Zp4cax6scCunz/fLRSaFL596/qzdJb1NScrnOCK/k UK2YVQ25l5T4UezKhmT5P2HCtYFptu2+xLW+PMQCVLGYxl6gl091X6o//vdG5qWjNu0o34zU7tPd AHiNBO52Alw1owkDXcnWtV/+Usr6r7Yx0w1ukk3gyMG8D3/61dW3559P2MjkT6kL43H2pgJm5Lsj cwepzkcn3cNOtzOnFwxeUTx8ST7M7oP6EubmxAwJds7Nkbow0sg/2D72d0xpDmPbmOm1USOZlore L8ltp5im9QnTnpdfGb6iOOHNPK4VCE2cbeR0SkrO0JfOjfvTqTGvZcxc9Mvar2EMK0UFd1s9nBSU y9YVpOdaoT2U+fkV2IDjxfHhpDtA/a66ZKhWiyszwRBmO/f+HBbJfpTTWaoTZpwcOvM/kYtKjkGh HEm76xx67y52dbGssshJGVNf+090ajkdZ0wwVilbXGIdiBVJIeQNvKiEm9giUon5WESX/JhBPGQW MCv5qccX/DGH8YH2bCt545Mu/V+88MpcKyNcKb49/KKo2j99dIExELv8mI40Z9mDNqf+xTw81Txx Vx7v4iGd8+HynLnH1H6ERew+3Hx14WcXMjMujGMX9jdXQNo44giVtdSziYGs0JQ1+Qs3ZB35Kfvt eaemV9ODmKQNXW9jU3LGzD0xZvK1T9u0jmI20GH5bztUzD7okkMV+Dw3mLS94Mvtwg1nVv7lFNtK zjxgjpxx8ZdCYscvD5dwaZsVqvo/Z88lmEBEvAT5Ga1XM8/nM38FOecvp338C/TEPdWHBMc2CD7c aNr4ddbK+edGMXtLw0ixMYtO5VRwqUgcLs+ct3VDUiwVznZzwFdfbTzVrXa8ddsUpgMrZePVMUtO r1xynJvWxPaPqVLibt5R+cVbepReJ5/v1HM9z0RsfZmaRQte1k+RhRn7TV+57vwC721cDD1D0dZq JY+CrSPiydukXNlySa2TlzVcjS1z9xmoiWA0wTzR2gEUvHQ9zr6kwt6rp3MqHN5ak1IoCUd0DXQv Z7QkMxgA+Ho7eC2BtSGPkCVRSasGlpxYMLkjO8SVvN8+T94D56+4xC5GDufQF7B2wWXYypesVzUF OgjIYb9eeYQpO4//fDUnv9BsKco5nbty/vkJ54jr6CHtnUuHVFqZby1Urolbhh96Zya/QcYJZp+/ NXV1lslis9eU264VpK0+AeUS9Ms4n62+efw0EXj8Ivdly37d7hpuYU7GhUUvn2WL5ZTJHdg5CPbc rMiXz4ZPPZH2U77NWnRk80my7MhzHYS1EuzFdtICAclZXAVELiBeRWVfMgNqOHeF1GK35M18zUx2 nL1WHjnpP+GTToZPPhs517ys3icxlqvzAK8p42zkEvgIooOdpxNFa6lwtoPWRT7XQGVDd/5XqzW8 abcIEuXKFtLJpdIChGfd+Hv0byv6robe9r3FrRaOGBK3hxlEwKrjdS7gYyHfvlLII797MIJdW1S+ JSNZEpgPxOU3YUIoDDZZ//kN0s63FqSug34B3erJPVhPxrg+GVNIfjl26GbY3FNHzl2xVZTbrcU5 P50fOvP6J/cHL/0tN99cq0/1GgdaIxpzaLV57ULLbl+/v03sBuolTg9lhv3WTFzKfWvUKodpq8Ps KouVr5KC753LDKBLmXov2ykFm7hnZjKvV/l25l3J07sDrCD7T8jOuj4dOQFO4kZDEvOet2ydKdMC n7Q1+3SKwDMkgAQ4Ajqa2y3PExHoHVh8HgaPsf5iogIWRzomMK86jAuzW601f+o8MtOS0vtlrOlP Viy3wEhLkYu+Im3Bee6dig/wxaT2iyf2ZDO67XRm9AooQBlp9JWhrxTOSumd3JV7daSqTe4uvBDy W20a80rhM2QNMGb5KLp049SLX44J//p3EWJfTe3TceT90/CeKezsC/JtR09Hf8zNqBAHDXvKfAqz CuG7+o4LZNAyfywYHzL7ie7clepdFcmrH7BHpjjHM3Jb29K3jnySy+4BDPLpMP/jb/WNCKyV6gzr Qu394NIUfh3Q0QOD/jajS/riLGWL67pT9Bti69AVexefJyurMwesUZo+qHb4ZmdFv+GNkNxVZIdp 1sPTj4eTPRRV48v6hP85m48PTtcXbOwnVAimA5kJm50jIDakxI6E3jHZ+NJXpr7GLbPPClw7p1ty P7K5Dznoko3TLs+vpp8a12HNiAho8ain8wOLAoezO18yTwtbCDNXqv+qzVuYRexYT4OgTQBnvj4r ngkeOaSHUS9rKZ054+y4NdykEvKgr8+W17smxd1jOnR24gbB3WdPagzsKSzmHxMbsLizJIfqy2TS g69l41um+UxPx6CBQR8Mqhu8hnw/HKOjvuZsRQLOWHe/eGshooz0gGEmsy+oLvHIb7pcfW3la9fZ xEBHBR4ZSQ9eWUm38fno2YDL68vfZ1rYjHgSLnVI1tbeplhSqhhPn9PKM4wpdtStVlnw9lzLh2yS 1vvtGu8zFtJkUOuCf8YLCVUKiXO5A/OLF6kR6JWbFPOdUq6nzStfJN3oPDQ+1bnVI+wHY96Tyq9p /6mEbc71FGKigr5dxC0D5F1cIAwr2lqh5FGxdbVZtmxZO7dHchw3+lLefNVXF027zq4kzXhgmgRM H2XO7pNuiy5BIfywtcC7fC1XU1BHz8rUKfL6ubvC2IeZS2HRes59+eSOk4d2EXuyX8v76B/Fy5iB JDG+VDbzQrT8+bDJw7sSb3Rl+gfn2M4R8VPk3Ff3dLTfk4+FJfXjvhlICXDVH3wxOZ397upbO52N CyJgQXL7aWO4JpY9PycyhZvWRO5R1OzuupWXeb1ZJ/a/ry5leNuRo7tHBPLjKCwXh87l9uBjvPhs mUuSBDmX0V+3K7VfYmjtkQ+yxp7jPqIwT+l2vRWy6R2mWchcwz9SI/cNhJ13of0Awz3YoRP8TWrQ kJCvp3SnIC29e2X+VdK78eKQoFnjY8LhOwF7yITuc3jN/eJ52bxPmVrjyOIsr9stMBROuWxRbadV u/EH2yXeuCzbYoRVXaaVlcLK5ZzylG7XkjhxPxE0eKDCXdUv5OAU8hrvdZnGy5W2r8gduTwCC7SB IdRaMhoLZ+ggI8sbMxr4+u5Z2iuBrXB5ley5ue+mln7qmpKXTw6bPLQr74X71eRTqcYRyfKUQ50v L2yrzyUbiip9T3LccjpfsllywudWntlINg+2HT8bvdplSBesiEzW91GKRfW1RdOuCaXli+M7LH2C f+upvjpz2nWOMxPZRyjqBz7W6j69aNzyAvEXCfzXE9DcaaKRBAynhG20yIaa/CF2gTdSptNk7dxu IzrpLBW0EbYwDRR/mXXYLCVU4D1GqKfpSltRpX9YiPP1Q+rCB8L+2i3FlMg/dE5TASEGuUK8KX3S FeYblcZO/IZAdMmWBZc/btfm67k9/Ssrq2EWRk29rbLi+HrL9JqAgvd6c9GpKDFZHf56X6NIYWds ZO9qlOyUwp3ZK4pt1lpK3zo8TBhe4aoz/wgQkzMKf1v868kWYr+ez2XjK36sxmarhD2bxUlFfNvl XBJfh70GFiiptFlr7JROBnhNqdlKh4dxc5FcZDX1hd1SZIFR1oHBxkDKZikzugYq0ZwJHhLY9dJq ytcY2Bp2rXZqRN8yX6+spnzCOvNpz3lP7UwuFIfdWgZr5xmYzGiHlfZgT1A1GU1xjyShW3aKSZYQ x6LqBpjAixQrqOw9TzWrkVjAjs4+RPn8rPCUMq2dJoI+DThpxvziBT1P+c5jLMRkxPWI2L0x517E hQkGbc3Slil5VGz9a5Ut3loTvvdKa8ZGJSfSYoGvBMZg+VYHyDafPtuXWdIVzmHZDudato0JV/Ks 3VpksTKfbQIMYbINDMkjWh3oChuZN0dTfn4ulZHW51l/KqlFWRDkvhu37L5+UGk2sm5qSK2hrJf7 HW/bad76dwuPrrA7Ap2tXO9zAZGn3L5SyiNqdaKbhkqXJC1VqiYk8jpgttUaAnz9xc1XGYHafGqo cZoqhzaVHJm4aoiFzFPohASQQFMQaOpOE3Wd+E6TFXNjJzg3jlV/5g67y35/eOr5yDXDw0WqO9Lf PPVOdMhBZlyfyN2L09sn2Qsl0CsSQAIKBMjw9SVlVHjrgvc0jDRREILOdwQBtPUdYaYWqCRMQnl3 URH7CX3B8x1nD3cZkNICFUaVvCLgbTvNW/9eKYOeG0CgqXJoU8lpQBTwESSABG4TAS86TcIn/ec2 KYFikQASQAJIAAkgASSABJAAEkACSKB5CZg3/aZ5FcDQkUALJODNQrAtUH1UCQkgASSABJAAEkAC SAAJIAEkgASQABJAAreHgBcjTRqrAH3LZKqkWvvARnJky2F96whhiY3Gim55z9fYzEVl1RBTna8x hFmipal0vH2Sm0pDlIME7j4CdkuhxUGRnYH0VLXD64Vm7j5gd3CM0dZ3sPFQdSTwKxDwtp3mrf9f IQoYBBJAAkgACbgS+BU7TVwDxiskgASQABJAAkgACSABJIAEkAASQAJIAAm0ZAI4PaclWwd1QwJI AAkgASSABJAAEkACSAAJIAEkgASajQB2mjQbegwYCSABJIAEkAASQAJIAAkgASSABJAAEmjJBLDT pCVbB3VDAkgACSABJIAEkAASQAJIAAkgASSABJqNAHaaNBt6DBgJIAEkgASQABJAAkgACSABJIAE kAASaMkEsNOkJVsHdUMCSAAJIAEkgASQABJAAkgACSABJIAEmo0Adpo0G3oMGAkgASSABJAAEkAC SAAJIAEkgASQABJoyQSw06QlWwd1QwJIAAkgASSABJAAEkACSAAJIAEkgASajQB2mjQbegwYCSAB JIAEkAASQAJIAAkgASSABJAAEmjJBLDTpCVbB3VDAkgACSABJIAEkAASQAJIAAkgASSABJqNAHaa NBt6DBgJIAEkgASQABJAAkgACSABJIAEkAASaMkEsNOkJVsHdUMCSAAJIAEkgASQABJAAkgACSAB JIAEmo0Adpo0G3oMGAkgASSABJAAEkACSAAJIAEkgASQABJoyQSw06QlWwd1QwJIAAkgASSABJAA EkACSAAJIAEkgASajQB2mjQbegwYCSABJIAEkAASQAJIAAkgASSABJAAEmjJBLDTpCVbB3VDAkgA CSABJIAEkAASQAJIAAkgASSABJqNAHaaNBt6DBgJIAEkgASQABJAAkgACSABJIAEkAASaMkEsNOk JVsHdUMCSAAJIAEkgASQABJAAkgACSABJIAEmo0Adpo0G3oMGAkgASSABJAAEkACSAAJIAEkgASQ ABJoyQT+Px9eFNgg7WdSAAAAAElFTkSuQmCC --14dae9340f2dbb734704d849bc46-- From paulej@packetizer.com Wed Mar 20 17:39:17 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231AD1F0D1C; Wed, 20 Mar 2013 17:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77khar3730St; Wed, 20 Mar 2013 17:39:15 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0F71F0CF7; Wed, 20 Mar 2013 17:39:15 -0700 (PDT) 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 r2L0dAs8013274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 20:39:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363826353; bh=Kg7GVYQBKK1XqFdhoP+dhUKJFedpQSpS/e9obnjPZRk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=B6LvmbQyhRY592N3Gos6grC6shCexRbVB8eh4ltR1Do13/uBqbl5jJuvsC+GBDx0U YjNLiEs96lEyz3y8KXr6Uq1MJFP/w/dHc5BB+c031ronCUiLL1UooI5DK+ijYuKZeZ iMkD48PvfMt3uesiiGPZ0jorznjhmPKIY3w9Q5AE= From: "Paul E. Jones" To: "'Dave Cridland'" , , , References: In-Reply-To: Date: Wed, 20 Mar 2013 20:39:26 -0400 Message-ID: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6xtTU7bBnElLUOVycpt5dUnTbtZfV0Bqg Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 00:39:17 -0000 Dave, My apologies for the belated reply. Please see my comments below. > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. Document: > draft-ietf-appsawg-webfinger-11 > Title: Webfinger > Reviewer: Dave Cridland > Review Date: 2013/03/11 > IESG Telechat Date: 2013/03/28 > Summary: Close to ready for publication as standards track; some > comments which suggest a new version may be required and/or technical > discussion needed. >=20 > Minor Comments: >=20 > 1) There's some suggestions that webfinger could be used for email > autoconfig; I suspect this is at best going to cause confusion > especially when there's a BOF tomorrow on the subject. This feels like > text that doesn't need to be present. This particular example provides a useful illustration of the = "properties" construct in the JRD format. It's there purely as an example and is not otherwise adopted as a provisioning mechanism. Would this have = presented confusion if the aggsrv BoF had not been scheduled? I think there are = some good ideas in the aggsrv proposal, but I do not think that that work or = this example will cause confusion. In the end, the IETF will adopt some mechanism for provision email servers and this small example in the WF document should not be a source of confusion. So, I do think the text should be there, but if you really think it = might cause some confusion, perhaps we insert a note to make it clearer that = this is only an example and not the way client devices should be provisioned? =20 > Also, it's a cursed subject anyway; see ACAP. :-) Yeah, I'll give you that. The outcome of the BoF seemed to be no = clearer than it was going in. =20 > Major Comments: >=20 > 1) I note that =A74.4.4.1 describes a 'rel' such that it redefines and > repeats RFC 5988's =A74; I think this should be deferred explicitly to = RFC > 5988 in entirety, rather than specifically only for registered link > relation types. >=20 > The good news is that this should simplify the text rather a lot: >=20 > """ > The value of the "rel" member is a string containing a link relation > type (see RFC 5988 [4]). Both registered and extended relation types = are > permitted. > """ I do not think we can simplify the text so much. There is an explicit limitation in the WebFinger draft that a "rel" value must either be a = single absolute URI or a registered link relation type. RFC 5988 allows for multiple values like 'rel=3D"shortcut icon"', but WebFinger does not. = RFC 5988 also allows URIs with fragments, but WebFinger does not. Valid = URIs must conform to Section 4.3 of RFC 3986 (Absolute URIs). These = decisions were intended to avoid ambiguity. Much of the text you removed talks about the other members of the link relation object, which include "type", "href", "titles", and = "properties". The value of the "rel" member dictates how the other members are = interpreted and so I think that text needs to remain. =20 > 2) The use of webfinger with arbitrary URIs is something I had not > previously realised. This raises some concerns for me, as it's not = clear > whether this is either genuinely desirable or whether it introduces > considerations (security and otherwise) beyond those discussed within > the document. >=20 > I would in general rather the mechanism were restricted to acct, http, > https, and perhaps mailto. I don't think use of one URI scheme vs. another makes any difference in terms of security. However, it was definitely the desire of the group = to be able to use any URI scheme, including some URIs like 'tel'. Use of = 'tel' would mean the exact resolution mechanism would have to be defined, but people did not want to preclude its use. For others that have a domain part, the desire is to be able to go to the server and request a JRD for that URI. There may or may not be information available for a given = URI, but the procedures for one URI or another would be exactly the same. =20 > 3) There is no use of SRV here; I would prefer an SRV resolution step > for at least acct and mailto scheme URIs, and possibly http/https as > well. My concern is that a corporate webserver is typically unlikely = to > be capable of providing webfinger services (being often externally > hosted), and while this could be solved by handling redirects, or by > reverse proxying, SRV feels like a more stable solution here. >=20 > I'd be curious as to whether this has been discussed. This was discussed at length, yes. We also discussed the use of the URI resource record type. SRV records will tell you what host to go to, but not what URI. URI records will tell you more precisely what URI to query. However, both mechanisms build a dependency on DNS that will not work in = web browsers. One of the first uses of WebFinger (for which there are = already a few libraries available) is to query for information about people = directly from JavaScript in a browser. Thus, it was preferred to use a = .well-known location rooted at the given host. =20 > 4) It would make =A78 more readable if it were split into subsections. = I > think the first three paragraphs form a discussion about the transport > security, the middle paragraphs discuss privacy, and the final = paragraph > discusses information reliability. That's a good suggestion. I'll make the changes (and adapt as I get = through other reviewers' comments). =20 > I suspect there is one more case to be concerned about, which is that = it > may be possible for an attacker to use webfinger resources to test the > existence of a hypothetical user; that is, one might use webfinger as = a > harvesting mechanism. Again, a valid point. I'll insert text into a new sub-section just = above "Information Reliability" and call it "Abuse Potential". Here's what I propose: ----------------- 8.3 Abuse Potential Service providers should be mindful of the potential for abuse using WebFinger. As one example, one might query a WebFinger server only to discover whether a given URI is valid or not. With such a query, the person may deduce that an email identifier is valid, for example. Such an approach could help spammers maintain a current list of known email addresses and to discover new ones. WebFinger could be used to associate a name or other personal information with an email address, allowing spammers to craft more convincing email messages. This might be of particular value in phishing attempts. ----------------- Paul From paulej@packetizer.com Wed Mar 20 17:59:49 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462F211E811F; Wed, 20 Mar 2013 17:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WE1wr87sWqt; Wed, 20 Mar 2013 17:59:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 406E911E810D; Wed, 20 Mar 2013 17:59:40 -0700 (PDT) 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 r2L0xaX7014544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 20:59:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363827578; bh=Gbv8w8Yy/uAzXWqd78pErRxMshh0SBrKeyLXphIN+AY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=orPqcga0mGXHHIas2XP3YrIKs7H93mslK30qdBBIzd3Dsvh2x9IsEpcJLOC8odkE7 EqpTpCHik0rvxP2tNmsu+A+uzQ4uJm7LY8+tgh6hOmZzl99d6UWXt72IZ2FJBU6bDu FP3GgWRA8ueKstgDNqAUtjf4Qm9OQwZBN4UPE9g0= From: "Paul E. Jones" To: "'Brian E Carpenter'" , , "'General Area Review Team'" References: <51449E79.2090205@gmail.com> In-Reply-To: <51449E79.2090205@gmail.com> Date: Wed, 20 Mar 2013 20:59:53 -0400 Message-ID: <054301ce25cf$66e8bdb0$34ba3910$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL3HBDAjlvSngARvBY4azfs2dJywJZdYzmQ Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Gen-ART LC review of draft-ietf-appsawg-webfinger-11.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 00:59:49 -0000 Brian, > Major Issues: =20 > ------------- >=20 > There is no explicit discussion of privacy in the draft, which seems = to > me to carry evident privacy risks. For example, imagine an ISP that > kindly decides to support webfinger for all customers by default, > and preloads personally identifiable information without consent. Barry commented on this indicating it is there. Per Dave's advice, I = think we should make it clearer with subsections in the security = section. =20 > There is some relevant text in the Security Considerations: >=20 > Further, WebFinger MUST NOT be used to provide any personal > information to any party unless explicitly or implicitly authorized > by the person whose information is being shared. >=20 > However, the weakness there is the words "or implicitly". IANAL, but = it > seems highly likely that would be illegal in the European Union, at = least. I have no strong preference on this, but "implicit" was asked by some, = since (as an example), your information might be shared via WebFinger = inside a company for company use. =20 > Has the draft been validated against the guidelines in > draft-iab-privacy-considerations? I have not, but Alissa was asked to weigh in (and she did). I trust she = provided recommendations. (I've not gotten that far down the stack, = yet.) Paul From paulej@packetizer.com Wed Mar 20 18:13:47 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0B711E8117 for ; Wed, 20 Mar 2013 18:13:47 -0700 (PDT) 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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQz-4YokdjeH for ; Wed, 20 Mar 2013 18:13:46 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C8DB421F88ED for ; Wed, 20 Mar 2013 18:13:45 -0700 (PDT) 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 r2L1Dgxu015384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Mar 2013 21:13:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363828424; bh=xkm+JRRCIyjLTLi269Qoky3H4zVdxhBDR3lePpRG6PA=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=PNfNKKTB0TMH/ieOMGg0XjNxzTv2Hjjc1UONEa2afAbSksi2ZVrBqeYRxz0xoyxxM 6VJvr+MMGY2HRFhV++T4Ri26Rk7tyF1gj601FM18Zxu8HjAkEa4VdWljus9XXXWQGq Tio8qxWmF8RZyLyHOTdOX9Z955ncz6WUo+4k69FA= From: "Paul E. Jones" To: Date: Wed, 20 Mar 2013 21:13:59 -0400 Message-ID: <054701ce25d1$5f1c3600$1d54a200$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0548_01CE25AF.D80B0B30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4l0MJ1aftKt9NESqCqZBMI2uQilA== Content-Language: en-us Subject: [webfinger] Suggested change to draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 01:13:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0548_01CE25AF.D80B0B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, Along with other suggested changes as part of the LC period, Mark Nottingham suggested that use this text in the "Related information" field for the IANA section where we register the webfinger well-known URI: "The query to the WebFinger resource will include one or more parameters in the query string; see Section 4.1 of RFCXXXX. Resources at this location are able to return a JSON Resource Descriptor (JRD) as described in Section 4.4 of RFCXXXX." I'll discuss this and other changes with Sal, but let me know if you have any concerns with this change. Paul ------=_NextPart_000_0548_01CE25AF.D80B0B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Along with = other suggested changes as part of the LC period, Mark Nottingham = suggested that use this text in the “Related information” = field for the IANA section where we register the webfinger well-known = URI:

 

“The query to the WebFinger resource will = include one or more parameters in the query string; see Section 4.1 of = RFCXXXX.  Resources at this location are able to return a JSON = Resource Descriptor (JRD) as described in Section 4.4 of = RFCXXXX.”

 

I’ll = discuss this and other changes with Sal, but let me know if you have any = concerns with this change.

 

Paul

 

------=_NextPart_000_0548_01CE25AF.D80B0B30-- From paulej@packetizer.com Wed Mar 20 18:28:05 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B03F21F8D59; Wed, 20 Mar 2013 18:28:05 -0700 (PDT) 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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ldg6BRsSmcga; Wed, 20 Mar 2013 18:28:04 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 55F3321F8D77; Wed, 20 Mar 2013 18:28:04 -0700 (PDT) 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 r2L1RiCk016022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 21:27:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363829267; bh=86zGJViPIp2tbNX1FeamPrVqsLRc0W6UOFA73ayJtco=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WntHBW0FDYHeimpy2qm2QElgasDO/P9pX5K43p3kDv7/DMhp0ri+9CW9yoy1zkW4R yze6JxjqY+1sD092+KyC3aGMbHW0QRc4gcP8eyEXGkFag7zRAsGYRFFz6pncFIXNpb 3HKt/+a6CybJcGE/IJQyoruj1EEyNIGjM/uiQyu4= From: "Paul E. Jones" To: "'Alissa Cooper'" , References: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 20 Mar 2013 21:28:01 -0400 Message-ID: <055401ce25d3$5566f120$0034d360$@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: AQKDaKO5ldokcAP290Gb0nohuKjS1AOIlQ8RlyiQfkA= Content-Language: en-us Cc: webfinger@ietf.org, apps-discuss@ietf.org Subject: Re: [webfinger] [apps-discuss] Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 01:28:05 -0000 Alissa, It was suggested that we remove the word "implicit". I'm OK with removing it. If we did that, would you want to add this new sentence or a modified version of it? Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Monday, March 18, 2013 11:31 AM > To: ietf@ietf.org > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Last Call: 10.txt> (WebFinger) to Proposed Standard > > Given how little control Internet users already have over which > information about them appears in which context, I do not have a lot of > confidence that the claimed discoverability benefits of WebFinger > outweigh its potential to further degrade users' ability to keep > particular information about themselves within specific silos. However, > I'm coming quite late to this document, so perhaps that balancing has > already been discussed, and it strikes me as unreasonable to try to > stand in the way of publication at this point. > > Two suggestions in section 8: > > s/personal information/personal data/ > (see http://tools.ietf.org/html/draft-iab-privacy-considerations- > 06#section-2.2 -- personal data is a more widely accepted term and > covers a larger range of information about people) > > The normative prohibition against using WebFinger to publish personal > data without authorization is good, but the notion of implicit > authorization leaves much uncertainty about what I imagine will be a use > case of interest: taking information out of a controlled context and > making it more widely available. To make it obvious that this has been > considered, I would suggest adding one more sentence to the end of the > fourth paragraph: > > "Publishing one's personal data within an access-controlled or otherwise > limited environment on the Internet does not equate to providing > implicit authorization of further publication of that data via > WebFinger." > > Alissa > > On Mar 4, 2013, at 3:24 PM, The IESG wrote: > > > > > The IESG has received a request from the Applications Area Working > > Group WG (appsawg) to consider the following document: > > - 'WebFinger' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2013-03-18. Exceptionally, comments may > > be sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > 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. WebFinger discovers > > information for a URI that might not be usable as a locator > > otherwise, such as account or email URIs. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From paulej@packetizer.com Wed Mar 20 19:38:19 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E0221F8B85; Wed, 20 Mar 2013 19:38:19 -0700 (PDT) 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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpilDfAhilha; Wed, 20 Mar 2013 19:38:13 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AEC2121F8B7E; Wed, 20 Mar 2013 19:38:13 -0700 (PDT) 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 r2L2c9UQ020143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 22:38:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363833491; bh=Fv2dgRo51HKtAwCVzg+V43FaBFbEHx5OK0EwcZyEHZw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=BsdkLWPAv7gYKPNoE8j69JGprD+61Z6uI+CR867sK40tg4UJsWAtrLp2es+XGNXa0 HGkMqXJexZxcARU2YJVFmkyqQfy6fE/GzWcRlJWyUHeMVM0djcmj26eV3XdDi0NXeI ZLKf1ktSrSOrQxmk/dopEH4ugO9IcFXDZrnSGVKI= From: "Paul E. Jones" To: "'Hannes Tschofenig'" , References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 20 Mar 2013 22:38:26 -0400 Message-ID: <056801ce25dd$2b28b010$817a1030$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI0gy1+Rm1ye8tHtMgU8uLcqP1pXAKuk/Htl80sTDA= Content-Language: en-us Cc: webfinger@ietf.org, apps-discuss@ietf.org Subject: Re: [webfinger] [apps-discuss] Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 02:38:20 -0000 Hannes, =20 > I was hoping that some of the remarks that I provided last year (e.g., > http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html) = would > help to clarify the content of the document. That didn't quite = happen... Yeah, I wasn't copied. =20 > In earlier versions of the document I had the impression that the = acct: > URI scheme always had to be used as input to the lookup process but as > Section 4.5 explains this is not necessary. The resource parameter may > contain other URIs as well. Section 4.5 does not give a lot of > description of when certain URIs are utilized.=20 Correct, any URI might be used. That does not mean that the server will = respond for every URI, but some wanted "acct" and "email" and "tel" = URIs, for example. Also, using an HTTP URI could be used to return = additional information about a URI. =20 > For example, in Section 3.1 the example talks about a user receiving = an > email from bob@examle.com and this email address is then used by > WebFinger but the request example shows an acct: URI scheme (rather = than > a mailto URI). It seems that there is the unstated assumption (at = least > in that example) that the mailto URI is the same as the acct: URI, = which > of course isn't necessarily the case. I believe it would be good to > state these assumptions to avoid confusing the reader.=20 Fair point. How about immediately following the example, we add: 'Note the assumption made in above example that there is an "acct" URI = for the given "mailto" URI. This is not always the case.' > Think about it: If you receive a SIP URI (which also has an email = alike > structure with a username @ domain part) that does not mean either = that > you can use this as an email address either. In some rare cases you > might.=20 That's definitely true. However, this is one reason for encouraging the = use of the "acct" URI scheme, though. In general (though not always), = there is account associated with the user. The SIP URI, mailto URI, = etc., each have a user part. I believe it is a reasonable assumption = that there *may be* an 'acct' URI for the user. If not, WF will return = nothing. We intended WF to be useful to humans, too, which means that if a user = sees paulej@packetizer.com, the user will assume that might be a means = of reaching "paulej" at "packetizer.com" using any number of tools = (email, XMPP, H.323, etc.). They would be correct for most. Thus, = there is encouragement for WF servers to use the acct URI. =20 > If you believe that everyone would get the difference anyway (because > the URI scheme determines the semantic of the identifier) then have a > look at the Google WebFinger page (see > http://code.google.com/p/webfinger/). At least these guys don't > understand the difference either.=20 There was even a proposal that we use no URI scheme at all and merely = have the user@domain identifier. However, there is value in using a = proper URI with WF, since querying "h323:paulej@packetizer.com" might = return the address of my Gatekeeper, for example, versus the information = that would be returned for my account.=20 > In general, I am wondering whether there are additional assumptions > implied about the URI scheme associated with the identifier in the > lookup mechanism. For example, the text in Section 3.3 talks about = email > client configuration and it seems that the requestor is interested in > receiving information about the email configuration based on the > resource=3Dmailto... URI scheme usage. If I use a different URI scheme > (like a aaa: URI scheme) would my response look different? Yeah, it might look different. What a WF server wishes to return for a = given URI is really up to the administrator. It might be that the same = information is returned for any given URI scheme having the same = user@domain part, but the server could return different responses. =20 > Then, there is a question about the lack of privacy considerations in > the document.=20 We do have quite a bit of text in the security considerations section. = This will be called out more clearly with sub-sections, but there are at = least three full paragraphs on privacy, even going to the point of = providing the example that sharing location information might put a = person in danger from someone who wishes to inflict harm on them. = Personally, I thought that went a bit overboard, but that text was = requested, so it's there. =20 > The usage of the WebFinger mechanism requires the requestor to have > access to the full username@domain identifier. While this may be OK in > some cases when the response relates very much to the specific user > account it may be a problem in other cases. For example, in the OAuth > case there is the idea that the user identifier may be hidden from the > relying party but you have just required that identifier to be = provided > to the relying party to start the entire OAuth exchange (in the > discovery). WF is not for use with every protocol, so I cannot address OAuth = generically. However, WF *is* used as a part of OpenID Connect. So, = yes, the user provides his/her identifier to the RP. However, that = decision is a matter outside the scope of WF. > The example in Section 3.1 returns information that relates to the > specific username and therefore it makes sense to provide the username > part of the identifier to the service that constructs the query. For = the > OpenID Connect discovery procedure described in Section 3.2 I wonder > whether this is always desirable. This was requested as an example to align with the OpenID Connect specs. > Could you expand the description a bit to explain why the relying = party > in this case has to obtain the username part as well? The returned > information does not seem to be specific to a certain user. It is the > server configuration. It would be nice if the configuration of an > identity provider software (e.g., OpenID Connect) is not different for > every user.=20 I'm not sure what to add, but I would welcome input. My understanding = is that this is how OpenID Connect works. If I were to visit a web site = and log in, what do I provide the site? It would not necessarily have = to be my email address. It could be = user123456@openid-connect-provider.net Whatever the case, something has = to be provided. A simple user@domain identifier is something most users = understand. The URIs used with OpenID were not so friendly for the = average user. =20 > I believe it is just fair to ask for a warning to be added to the > security consideration section indicating that WebFinger may have an > impact on your privacy expectation since it shares information with = the > relying party that other mechanisms do not provide. So, if you think > that this just works like other discovery mechanisms the IETF had = worked > on in the past then you might be surprised.=20 I'm OK with introducing more text to the security considerations = section, but it should not be heavily focused on OpenID or OpenID = Connect. Many readers of this spec would not even know what a "relying = party" is, ether. We should keep it generic. =20 > I would even volunteer to provide text but I fear that you are not = going > to like it.=20 :-) Well, I didn't like some of the other text that was added, but I = accepted it since people demanded it. If there is another broad point = that needs to be made, then I'm willing to add the text. I just added a = section on "abuse potential", as you might have seen. Paul From paulej@packetizer.com Wed Mar 20 19:55:08 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0C611E80A6 for ; Wed, 20 Mar 2013 19:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miM4iJvVlLgc for ; Wed, 20 Mar 2013 19:55:07 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 80FA61F0D0F for ; Wed, 20 Mar 2013 19:55:07 -0700 (PDT) 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 r2L2t14K020893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 22:55:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363834505; bh=eBkyRAuy9WaIYsFXEw7ll5DxEh1NTBf0bLGAiTFe85o=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=YKCpbBSn80nZwXLMXuQw/H0yg0mERZrIF6GP1NSf0yCntRq/cElBLVVUkqFsPwYq4 9SaU124hxoF4VihOwZVOb8RRHXr65rtQmmsk0OoYjKpjvcrFJZ+4hVpOmmjX5nFNtJ ktljF8R42TNjmrseaduT0iqkK8YFnsoL680rEoa0= From: "Paul E. Jones" To: "'Stephane Bortzmeyer'" , References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> In-Reply-To: <20130315150058.GA28881@laperouse.bortzmeyer.org> Date: Wed, 20 Mar 2013 22:55:18 -0400 Message-ID: <056a01ce25df$8760b600$96222200$@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: AQI0gy1+Rm1ye8tHtMgU8uLcqP1pXAIUtELjl9IRs0A= Content-Language: en-us Cc: ietf-languages@alvestrand.no Subject: Re: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 02:55:08 -0000 Stephanie, > > The "titles" object comprises zero or more name/value pairs whose name > > is a language tag or the string "default". [...] If the language is > > unknown or unspecified, then the name is "default". > > Why inventing a special value when the language tag registry already has > a specific value, "und"? To quote RFC 5646: > > > The 'und' (Undetermined) primary language subtag identifies linguistic > > content whose language is not determined. This subtag SHOULD NOT be > > used unless a language tag is required and language information is not > > available or cannot be determined. This is historical. The JRD syntax was first defined in RFC 6415 and that document said to use "default" when the corresponding XML document did not specify the xml:lang attribute. We could change it, but it would break any existing implementations of RFC 6415. > Editorial comment: the reference is wrong: > > [13] Phillips, A., Davis, M., "Tags for Identifying Languages", RFC > 5646, January 2001. > > [It is 2009] That's an easy one. Thanks! Paul From paulej@packetizer.com Wed Mar 20 19:57:16 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B39F11E80A6 for ; Wed, 20 Mar 2013 19:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZWaaPicTgQz for ; Wed, 20 Mar 2013 19:57:16 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D3C0E1F0D1C for ; Wed, 20 Mar 2013 19:57:15 -0700 (PDT) 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 r2L2vC3x021007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 22:57:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363834635; bh=E9lwfmfUBKNI862QDVsmMpvZKPCW9xilFlm2R4t5lCc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=iHUlky5mq1FmJsQlE075jfQW/zg7yPFt+XNHUTzLm/JSD4QPQvrg3PNWMWmQPX3zZ Yitp1iwR78Xg0avXhKujI8ghjghKq/TqNTpXMHX8FfGUBDDdSwJDiQseNpHaz62S64 dH2zAJQH8Mw8Qyb/okd00tV9SwTutYS+bvnimVtA= From: "Paul E. Jones" To: "'Stephane Bortzmeyer'" , "'Dave Cridland'" References: <20130315151027.GB28881@laperouse.bortzmeyer.org> In-Reply-To: <20130315151027.GB28881@laperouse.bortzmeyer.org> Date: Wed, 20 Mar 2013 22:57:29 -0400 Message-ID: <056c01ce25df$d4cf1940$7e6d4bc0$@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: AQI6xtTU7bBnElLUOVycpt5dUnTbtQITD5xDl8WZBzA= Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 02:57:16 -0000 Stephane, > > 1) There's some suggestions that webfinger could be used for email > > autoconfig; I suspect this is at best going to cause confusion > > Indeed, the example with IMAP in 3.3 confuses me. Why is is better than > the standard RFC 6186? Keep in mind that this is just an example, but one reason this approach is "better" is that I could build an email client entirely in JavaScript running in a browser using WF and some kind of configuration like this. In the end, we likely will not provision email clients exactly like this, but that was not the expectation. This example shows how one might do that and demonstrates how "properties" might be used in WF. Paul From paulej@packetizer.com Wed Mar 20 20:01:02 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2A511E80EE for ; Wed, 20 Mar 2013 20:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyx-TxuAtCyj for ; Wed, 20 Mar 2013 20:01:01 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA3811E80BA for ; Wed, 20 Mar 2013 20:01:01 -0700 (PDT) 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 r2L30uB6021169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 23:00:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363834859; bh=s2rRezrdHdpYzc44SHjfHZUusT6I95bTxw3g81y0/zQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZZbycR3B5kalUMRZqC3RjpDLSeYV0IcVvSndKRIuGK8Ahr/dF69+vdUS/OoqDpP6n TMwwR5GKdmGQRoj8OHmasUGBHbWyqImU4IMyBqKcXsPczKhUwI9P1CQwv35LPz/8oA kxrJqhI+nL4EsAv7zcwv0Zws7GIlEPo6KV4CuA2U= From: "Paul E. Jones" To: "'Stephane Bortzmeyer'" , References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <20130315151847.GA29361@laperouse.bortzmeyer.org> In-Reply-To: <20130315151847.GA29361@laperouse.bortzmeyer.org> Date: Wed, 20 Mar 2013 23:01:13 -0400 Message-ID: <057101ce25e0$5a634400$0f29cc00$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI0gy1+Rm1ye8tHtMgU8uLcqP1pXAIUtELjAWXufD6XxuSX4A== Content-Language: en-us Cc: ietf-languages@alvestrand.no Subject: Re: [webfinger] Language tag too specific (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 03:01:02 -0000 Stepane, > Another issue with language tags in = draft-ietf-appsawg-webfinger-11.txt: >=20 > > "titles" : > > { > > "en-us" : "The Magical World of Bob", > > "fr" : "Le Monde Magique de Bob" > > } >=20 > I understand that the purpose of the example is to show that you are = not > limited to the primary langauge subtag, you can add other subtags = (here, > the region "us"). But the example is not well chosen. RFC 5646 says: >=20 > > Use as precise a tag as possible, but no more specific than is > > justified. Avoid using subtags that are not important for > > distinguishing content in an application. > > > > * For example, 'de' might suffice for tagging an email written > > in German, while "de-CH-1996" is probably unnecessarily > > precise for such a task. >=20 > Which seems to apply exactly here (there is nothing US-specific in the > sentence). May be, instead: >=20 > "titles" : > { > "en-us" : "The Magical Theater of Bob", > "en-gb" : "The Magical Theatre of Bob", > "fr" : "Le Th=C3=A9=C3=A2tre Magique de Bob" > } You example illustrated why there is value in specifying the region in = this example. However, I really do not care what we use as language = tags. I selected these examples just to show that one might use a = language value only or a language and region value. What would you prefer we have in the example? Paul From dave@cridland.net Thu Mar 21 04:55:27 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A0E21F86D6 for ; Thu, 21 Mar 2013 04:55:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSMGLQQ4QhzU for ; Thu, 21 Mar 2013 04:55:24 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3D621F8904 for ; Thu, 21 Mar 2013 04:55:11 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k1so2960738oag.5 for ; Thu, 21 Mar 2013 04:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ii35btwD/vkpGfydFs1Yxw+icfbDkynIiK9rKp90JWs=; b=TtlSaWy2CjahzgouaH3m/VRvS/kOzklsrV5O4rLj0NWhBrntz6Oh/y+7RRPTSjufDK q3n+YJfO9ie59/UpYJKdrNpYtHkLnO2S3mbD92sIi3dxC2JiWu03HRJ1pNHJGudU+VFs cPf8c6k0qyx5alXFnDtpXWFSUzM7HNjMi6Tww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Ii35btwD/vkpGfydFs1Yxw+icfbDkynIiK9rKp90JWs=; b=Lcg9UlijE4UutEbVr4Tr9K18SZoeHbmeeNJo+gS+jBiv6cpQryZgBLZphRn2aW8gs3 j3VaMakwAjbP8yNsjBmel0/UwlStyNGVqrcNJBRMonXIepIjBwS3Mes8bymeAUPMUA8p NfnTXpHTy3Wp8JeqToQdcPzi0ZypCGZicBvEsF4IDzfJ3QCifdyA5R76g08otnm4JECj c1GZzvGu4B/VYnZOg0yrtXvd5jQBVKw2VmlkO66yPjzJV2IqlFqwrcZeO/1y9loIeTqX AoBEU2hkSVQtP4pazkIOiiwVNyUzNS+2coBSfQvG9E/kePX8s0oKSZTISYFV34fPcBhw HH4w== MIME-Version: 1.0 X-Received: by 10.182.131.4 with SMTP id oi4mr6360011obb.64.1363866910991; Thu, 21 Mar 2013 04:55:10 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Thu, 21 Mar 2013 04:55:10 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Thu, 21 Mar 2013 04:55:10 -0700 (PDT) In-Reply-To: <056c01ce25df$d4cf1940$7e6d4bc0$@packetizer.com> References: <20130315151027.GB28881@laperouse.bortzmeyer.org> <056c01ce25df$d4cf1940$7e6d4bc0$@packetizer.com> Date: Thu, 21 Mar 2013 11:55:10 +0000 Message-ID: From: Dave Cridland To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f646b9dc087b204d86e02c7 X-Gm-Message-State: ALoCoQlJM/r8pFTU5Qw9xbmcyP+krWxmaT+kdKFKyeMOw6eCypPMFPQePZs43dbPYAv9EtUpS/Rq Cc: webfinger@ietf.org, Stephane Bortzmeyer Subject: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 11:55:27 -0000 --e89a8f646b9dc087b204d86e02c7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 21 Mar 2013 02:57, "Paul E. Jones" wrote: > > Stephane, > > > > 1) There's some suggestions that webfinger could be used for email > > > autoconfig; I suspect this is at best going to cause confusion > > > > Indeed, the example with IMAP in 3.3 confuses me. Why is is better than > > the standard RFC 6186? > > Keep in mind that this is just an example, but one reason this approach i= s > "better" is that I could build an email client entirely in JavaScript > running in a browser using WF and some kind of configuration like this. In > the end, we likely will not provision email clients exactly like this, bu= t > that was not the expectation. This example shows how one might do that and > demonstrates how "properties" might be used in WF. Right, but you're mixing the canonical description of WF with a reasonable looking example which is actually not what's being standardized. I maintain that it'll almost certainly cause confusion when people are looking for how to provision and/or discovery email configuration, because it looks plausible enough and it's in a standards track document. The fact that St=E9phane is even asking why it's better suggests this is happening to a degree already; I'm afraid it looks like a standards proposal even if it's dressed as an example. Pick a small example that's not in conflict with ongoing standardization work, please. I understand you want to demonstrate that WF can be used for autoconfiguration; I suggest making up a service to autoconfigure. Dave. --e89a8f646b9dc087b204d86e02c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 21 Mar 2013 02:57, "Paul E. Jones" <paulej@packetizer.com> wrote:
>
> Stephane,
>
> > > 1) There's some suggestions that webfinger could be used= for email
> > > autoconfig; I suspect this is at best going to cause confusi= on
> >
> > Indeed, the example with IMAP in 3.3 confuses me. Why is is bette= r than
> > the standard RFC 6186?
>
> Keep in mind that this is just an example, but one reason this approac= h is
> "better" is that I could build an email client entirely in J= avaScript
> running in a browser using WF and some kind of configuration like this= . =A0In
> the end, we likely will not provision email clients exactly like this,= but
> that was not the expectation. =A0This example shows how one might do t= hat and
> demonstrates how "properties" might be used in WF.

Right, but you're mixing the canonical description of WF= with a reasonable looking example which is actually not what's being s= tandardized. I maintain that it'll almost certainly cause confusion whe= n people are looking for how to provision and/or discovery email configurat= ion, because it looks plausible enough and it's in a standards track do= cument. The fact that St=E9phane is even asking why it's better suggest= s this is happening to a degree already; I'm afraid it looks like a sta= ndards proposal even if it's dressed as an example.

Pick a small example that's not in conflict with ongoing= standardization work, please. I understand you want to demonstrate that WF= can be used for autoconfiguration; I suggest making up a service to autoco= nfigure.

Dave.

--e89a8f646b9dc087b204d86e02c7-- From dave@cridland.net Thu Mar 21 06:46:21 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F202F21F9037 for ; Thu, 21 Mar 2013 06:46:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpM4Y5eEluOQ for ; Thu, 21 Mar 2013 06:46:20 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBA821F9061 for ; Thu, 21 Mar 2013 06:46:19 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id un3so2848829obb.10 for ; Thu, 21 Mar 2013 06:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2ip52Yr96hR0pxxJDM3yrMgUPTz7RKJP5KuuXANjZgk=; b=WS7+JAR5PXsMuPcfhUVbsAU92VbwwYHyRGfkBWmb4K0xfM2rQ9caBZAoHLAquchtG1 6RLDOK+yP1HkZve/LArmmgXV7+jpfe5cPYXDqfa4AyANRRtSyf1PJpH7cC/wVeFqXyLy yfbWxLVNfpOhb1DEfsUszmxql9jQ5VesCj9tI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=2ip52Yr96hR0pxxJDM3yrMgUPTz7RKJP5KuuXANjZgk=; b=oHvhT27LI6g4pLwah69EvNZqB41ga85AA7IrsK3/EebGP4U1tzEKzfbIHG8ZuX62NV YapemZScRm2IZHUxLv4BAszVAj1YvH0pBugE4dwvx3FJskSDGkgJjD9kA3Zh+8BJQi9d DYp9+uDFqXgOjRWn7QGrPm2zFmZ8mQ27QF+kPW/XZ8zGE5+mhDVb+J6X9PrMeBwCoQz2 pPYCGkg0LODRwppDnhnM5JMzH5mRyZDvyKCcBUiZ72hvpW9Xx2P048IOVFRpoMzmGnB8 MiyaC8NOYh6f8LDI8kNDdNuM14qOk8x4P4SLigNHUC20kdnjZeouWCCa51IGA2/0Klr+ YOTQ== MIME-Version: 1.0 X-Received: by 10.60.29.72 with SMTP id i8mr6643636oeh.93.1363873571279; Thu, 21 Mar 2013 06:46:11 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Thu, 21 Mar 2013 06:46:11 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Thu, 21 Mar 2013 06:46:11 -0700 (PDT) In-Reply-To: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> Date: Thu, 21 Mar 2013 13:46:11 +0000 Message-ID: From: Dave Cridland To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f806bc7f9604d86f8f96 X-Gm-Message-State: ALoCoQkRJsqxWVUa/sqMhFSpHqqnVZWy4ZJhv+bza8+YISKpvwk2kgybKSXwAnVX7Jvy9oCT/vtA Cc: webfinger@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:46:21 -0000 --e89a8fb1f806bc7f9604d86f8f96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 21 Mar 2013 00:39, "Paul E. Jones" wrote: > > Dave, > > My apologies for the belated reply. Please see my comments below. > > > Please resolve these comments along with any other Last Call comments > > you may receive. Please wait for direction from your document shepherd > > or AD before posting a new version of the draft. Document: > > draft-ietf-appsawg-webfinger-11 > > Title: Webfinger > > Reviewer: Dave Cridland > > Review Date: 2013/03/11 > > IESG Telechat Date: 2013/03/28 > > Summary: Close to ready for publication as standards track; some > > comments which suggest a new version may be required and/or technical > > discussion needed. > > > > Minor Comments: > > > > 1) There's some suggestions that webfinger could be used for email > > autoconfig; I suspect this is at best going to cause confusion > > especially when there's a BOF tomorrow on the subject. This feels like > > text that doesn't need to be present. > > This particular example provides a useful illustration of the "properties= " > construct in the JRD format. It's there purely as an example and is not > otherwise adopted as a provisioning mechanism. Would this have presented > confusion if the aggsrv BoF had not been scheduled? I think there are some > good ideas in the aggsrv proposal, but I do not think that that work or this > example will cause confusion. In the end, the IETF will adopt some > mechanism for provision email servers and this small example in the WF > document should not be a source of confusion. > > So, I do think the text should be there, but if you really think it might > cause some confusion, perhaps we insert a note to make it clearer that this > is only an example and not the way client devices should be provisioned? > As stated elsewhere, I think this is very confusing, and already generating the confusion I'm concerned about, in relation to RFC 6186 rather than AggSrv, in fact. I'd strongly prefer this example were removed, and replaced with something else. > > Major Comments: > > > > 1) I note that =A74.4.4.1 describes a 'rel' such that it redefines and > > repeats RFC 5988's =A74; I think this should be deferred explicitly to = RFC > > 5988 in entirety, rather than specifically only for registered link > > relation types. > > > > The good news is that this should simplify the text rather a lot: > > > > """ > > The value of the "rel" member is a string containing a link relation > > type (see RFC 5988 [4]). Both registered and extended relation types ar= e > > permitted. > > """ > > I do not think we can simplify the text so much. There is an explicit > limitation in the WebFinger draft that a "rel" value must either be a single > absolute URI or a registered link relation type. RFC 5988 allows for > multiple values like 'rel=3D"shortcut icon"', but WebFinger does not. RF= C > 5988 also allows URIs with fragments, but WebFinger does not. Valid URIs > must conform to Section 4.3 of RFC 3986 (Absolute URIs). These decisions > were intended to avoid ambiguity. Link relation types are a single one of those values, the ABNF production, as opposed to the rel, which contains a . I'm entirely with you on why you want to restrict your rel to a single link relation type. Worth calling it out the difference, but it's not a deviation from RFC 5988. However, if you're changing the definition of link relation types, then: a) I'm deeply concerned. Redefining a standards-track specification seems worryingly close to NIH. There's horrible confusion lurking when someone says "Link relation type" and then has to qualify which definition. b) You need to make this absolutely clear in the document; it reads like you're restating, not redefining. c) The only distinction you claim above that appears to me to be an actual distinction is that fragments are disallowed. Yet no such restriction exists in the current draft. > Much of the text you removed talks about the other members of the link > relation object, which include "type", "href", "titles", and "properties"= . > The value of the "rel" member dictates how the other members are interpreted > and so I think that text needs to remain. Yes, I've probably trimmed too much there. > > 2) The use of webfinger with arbitrary URIs is something I had not > > previously realised. This raises some concerns for me, as it's not clea= r > > whether this is either genuinely desirable or whether it introduces > > considerations (security and otherwise) beyond those discussed within > > the document. > > > > I would in general rather the mechanism were restricted to acct, http, > > https, and perhaps mailto. > > I don't think use of one URI scheme vs. another makes any difference in > terms of security. However, it was definitely the desire of the group to be > able to use any URI scheme, including some URIs like 'tel'. Use of 'tel' > would mean the exact resolution mechanism would have to be defined, but > people did not want to preclude its use. For others that have a domain > part, the desire is to be able to go to the server and request a JRD for > that URI. There may or may not be information available for a given URI, > but the procedures for one URI or another would be exactly the same. I did say "security and otherwise". I'm not saying that any given URI scheme should be discounted forever more, I am suggesting the document should limit the schemes which have a defined behaviour for now. I have no clue what the possible impacts of using webfinger on a message id URI might be, nor do I wish to even think about it. I'm pretty sure that mailto has some corner cases we've not yet thought about; it's not just an email address after all. > > 3) There is no use of SRV here; I would prefer an SRV resolution step > > for at least acct and mailto scheme URIs, and possibly http/https as > > well. My concern is that a corporate webserver is typically unlikely to > > be capable of providing webfinger services (being often externally > > hosted), and while this could be solved by handling redirects, or by > > reverse proxying, SRV feels like a more stable solution here. > > > > I'd be curious as to whether this has been discussed. > > This was discussed at length, yes. We also discussed the use of the URI > resource record type. > > SRV records will tell you what host to go to, but not what URI. > URI records will tell you more precisely what URI to query. > > However, both mechanisms build a dependency on DNS that will not work in web > browsers. One of the first uses of WebFinger (for which there are already a > few libraries available) is to query for information about people directl= y > from JavaScript in a browser. Thus, it was preferred to use a .well-know= n > location rooted at the given host. That sucks. It's a shame that browsers are holding back use of SRV and other decade-old technology for things like this. But I accept that this has been discussed and blocked by browser brokenness= . > Here's what I propose: > > ----------------- > 8.3 Abuse Potential > > Service providers should be mindful of the potential for abuse using > WebFinger. > > As one example, one might query a WebFinger server only to discover > whether a given URI is valid or not. With such a query, the person > may deduce that an email identifier is valid, for example. Such an > approach could help spammers maintain a current list of known email > addresses and to discover new ones. > > WebFinger could be used to associate a name or other personal > information with an email address, allowing spammers to craft more > convincing email messages. This might be of particular value in > phishing attempts. > ----------------- That seems sensible. Dave. --e89a8fb1f806bc7f9604d86f8f96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 21 Mar 2013 00:39, "Paul E. Jones" <paulej@packetizer.com> wrote:
>
> Dave,
>
> My apologies for the belated reply. =A0Please see my comments below. >
> > Please resolve these comments along with any other Last Call comm= ents
> > you may receive. Please wait for direction from your document she= pherd
> > or AD before posting a new version of the draft. =A0Document:
> > draft-ietf-appsawg-webfinger-11
> > Title: Webfinger
> > Reviewer: Dave Cridland
> > Review Date: 2013/03/11
> > IESG Telechat Date: 2013/03/28
> > Summary: Close to ready for publication as standards track; some<= br> > > comments which suggest a new version may be required and/or techn= ical
> > discussion needed.
> >
> > Minor Comments:
> >
> > 1) There's some suggestions that webfinger could be used for = email
> > autoconfig; I suspect this is at best going to cause confusion > > especially when there's a BOF tomorrow on the subject. This f= eels like
> > text that doesn't need to be present.
>
> This particular example provides a useful illustration of the "pr= operties"
> construct in the JRD format. =A0It's there purely as an example an= d is not
> otherwise adopted as a provisioning mechanism. =A0Would this have pres= ented
> confusion if the aggsrv BoF had not been scheduled? =A0I think there a= re some
> good ideas in the aggsrv proposal, but I do not think that that work o= r this
> example will cause confusion. =A0In the end, the IETF will adopt some<= br> > mechanism for provision email servers and this small example in the WF=
> document should not be a source of confusion.
>
> So, I do think the text should be there, but if you really think it mi= ght
> cause some confusion, perhaps we insert a note to make it clearer that= this
> is only an example and not the way client devices should be provisione= d?
>

As stated elsewhere, I think this is very confusing, and alr= eady generating the confusion I'm concerned about, in relation to RFC 6= 186 rather than AggSrv, in fact.

I'd strongly prefer this example were removed, and repla= ced with something else.

> > Major Comments:
> >
> > 1) I note that =A74.4.4.1 describes a 'rel' such that it = redefines and
> > repeats RFC 5988's =A74; I think this should be deferred expl= icitly to RFC
> > 5988 in entirety, rather than specifically only for registered li= nk
> > relation types.
> >
> > The good news is that this should simplify the text rather a lot:=
> >
> > """
> > The value of the "rel" member is a string containing a = link relation
> > type (see RFC 5988 [4]). Both registered and extended relation ty= pes are
> > permitted.
> > =A0"""
>
> I do not think we can simplify the text so much. =A0There is an explic= it
> limitation in the WebFinger draft that a "rel" value must ei= ther be a single
> absolute URI or a registered link relation type. =A0RFC 5988 allows fo= r
> multiple values like 'rel=3D"shortcut icon"', but We= bFinger does not. =A0RFC
> 5988 also allows URIs with fragments, but WebFinger does not. =A0Valid= URIs
> must conform to Section 4.3 of RFC 3986 (Absolute URIs). =A0These deci= sions
> were intended to avoid ambiguity.

Link relation types are a single one of those values, the &l= t;relation-type> ABNF production, as opposed to the rel, which contains = a <relation-types>. I'm entirely with you on why you want to rest= rict your rel to a single link relation type. Worth calling it out the diff= erence, but it's not a deviation from RFC 5988.

However, if you're changing the definition of link relat= ion types, then:

a) I'm deeply concerned. Redefining a standards-track sp= ecification seems worryingly close to NIH. There's horrible confusion l= urking when someone says "Link relation type" and then has to qua= lify which definition.

b) You need to make this absolutely clear in the document; i= t reads like you're restating, not redefining.

c) The only distinction you claim above that appears to me t= o be an actual distinction is that fragments are disallowed. Yet no such re= striction exists in the current draft.

> Much of the text you removed talks about the other memb= ers of the link
> relation object, which include "type", "href", &qu= ot;titles", and "properties".
> The value of the "rel" member dictates how the other members= are interpreted
> and so I think that text needs to remain.

Yes, I've probably trimmed too much there.

> > 2) The use of webfinger with arbitrary URIs is som= ething I had not
> > previously realised. This raises some concerns for me, as it'= s not clear
> > whether this is either genuinely desirable or whether it introduc= es
> > considerations (security and otherwise) beyond those discussed wi= thin
> > the document.
> >
> > I would in general rather the mechanism were restricted to acct, = http,
> > https, and perhaps mailto.
>
> I don't think use of one URI scheme vs. another makes any differen= ce in
> terms of security. =A0However, it was definitely the desire of the gro= up to be
> able to use any URI scheme, including some URIs like 'tel'. = =A0Use of 'tel'
> would mean the exact resolution mechanism would have to be defined, bu= t
> people did not want to preclude its use. =A0For others that have a dom= ain
> part, the desire is to be able to go to the server and request a JRD f= or
> that URI. =A0There may or may not be information available for a given= URI,
> but the procedures for one URI or another would be exactly the same.

I did say "security and otherwise". I'm not sa= ying that any given URI scheme should be discounted forever more, I am sugg= esting the document should limit the schemes which have a defined behaviour= for now.

I have no clue what the possible impacts of using webfinger = on a message id URI might be, nor do I wish to even think about it.

I'm pretty sure that mailto has some corner cases we'= ;ve not yet thought about; it's not just an email address after all.

> > 3) There is no use of SRV here; I would prefer an = SRV resolution step
> > for at least acct and mailto scheme URIs, and possibly http/https= as
> > well. My concern is that a corporate webserver is typically unlik= ely to
> > be capable of providing webfinger services (being often externall= y
> > hosted), and while this could be solved by handling redirects, or= by
> > reverse proxying, SRV feels like a more stable solution here.
> >
> > I'd be curious as to whether this has been discussed.
>
> This was discussed at length, yes. =A0We also discussed the use of the= URI
> resource record type.
>
> SRV records will tell you what host to go to, but not what URI.
> URI records will tell you more precisely what URI to query.
>
> However, both mechanisms build a dependency on DNS that will not work = in web
> browsers. =A0One of the first uses of WebFinger (for which there are a= lready a
> few libraries available) is to query for information about people dire= ctly
> from JavaScript in a browser. =A0Thus, it was preferred to use a .well= -known
> location rooted at the given host.

That sucks.

It's a shame that browsers are holding back use of SRV a= nd other decade-old technology for things like this.

But I accept that this has been discussed and blocked by bro= wser brokenness.

> Here's what I propose:
>
> -----------------
> 8.3 Abuse Potential
>
> Service providers should be mindful of the potential for abuse using > WebFinger.
>
> As one example, one might query a WebFinger server only to discover > whether a given URI is valid or not. =A0With such a query, the person<= br> > may deduce that an email identifier is valid, for example. =A0Such an<= br> > approach could help spammers maintain a current list of known email > addresses and to discover new ones.
>
> WebFinger could be used to associate a name or other personal
> information with an email address, allowing spammers to craft more
> convincing email messages. =A0This might be of particular value in
> phishing attempts.
> -----------------

That seems sensible.

Dave.

--e89a8fb1f806bc7f9604d86f8f96-- From paulej@packetizer.com Thu Mar 21 19:05:29 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3298321F8DCF for ; Thu, 21 Mar 2013 19:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MibKZIzVNDa for ; Thu, 21 Mar 2013 19:05:27 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C9FD221F8BAE for ; Thu, 21 Mar 2013 19:05:26 -0700 (PDT) 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 r2M25MNJ005178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Mar 2013 22:05:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363917925; bh=15sql7V23RASwN3uYB3KQnI3k3o+U+Dm1Pft19OrKE0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=kMt5F2UNJDjJSY6qOADvS2nnJvBHlJsgXXktMpeZSzcfz/+yWwbws1PV4Op3xbmTp frNMit7PaeSVOXDoYuFP1A2io4KYkI+UsZpI4cTfCiWcOf8rzqhywGRy6CrIlnN8Hk wnrDw/CQoKUfiXPRZPV2JQ76acwWB6NQZIxbOo5s= From: "Paul E. Jones" To: "'Dave Cridland'" References: <20130315151027.GB28881@laperouse.bortzmeyer.org> <056c01ce25df$d4cf1940$7e6d4bc0$@packetizer.com> In-Reply-To: Date: Thu, 21 Mar 2013 22:05:41 -0400 Message-ID: <010201ce26a1$c30e5690$492b03b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0103_01CE2680.3BFD79E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6xtTU7bBnElLUOVycpt5dUnTbtQITD5xDAZSIwP0BPdUU+pewh1lw Content-Language: en-us Cc: webfinger@ietf.org, 'Stephane Bortzmeyer' Subject: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 02:05:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0103_01CE2680.3BFD79E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dave, =20 I agree that it looks entirely plausible. However, it cannot be = implemented as defined, because none of the rel values or property values are = defined. Of course, I could replace rel values like http://webfinger.example/rel/smtp-server with http://packetizer.com/rel/smtp-server and properties like http://webfinger.example/email/host with http://packetizer.com/ns/host. However, that does not make any of that standard. =20 I=92m not interested to demonstrate that WF can be used for = auto-provisioning. Rather, I am interested to demonstrate use of =93properties=94 in a = =93link relation object=94 that has no =93href=94 member. Basically, this is = example has information that is entirely self-contained in the JRD and not dependent = on an external link. =20 You suggest I make up a service to auto-provision. So, it concerns you = only that I have an example with IMAP or does it concern you that the example = is an auto-provisioning example? I=92m a little confused. =20 Paul =20 From: Dave Cridland [mailto:dave@cridland.net]=20 Sent: Thursday, March 21, 2013 7:55 AM To: Paul E. Jones Cc: webfinger@ietf.org; Stephane Bortzmeyer Subject: RE: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 =20 On 21 Mar 2013 02:57, "Paul E. Jones" wrote: > > Stephane, > > > > 1) There's some suggestions that webfinger could be used for email > > > autoconfig; I suspect this is at best going to cause confusion > > > > Indeed, the example with IMAP in 3.3 confuses me. Why is is better = than > > the standard RFC 6186? > > Keep in mind that this is just an example, but one reason this = approach is > "better" is that I could build an email client entirely in JavaScript > running in a browser using WF and some kind of configuration like = this. In > the end, we likely will not provision email clients exactly like this, = but > that was not the expectation. This example shows how one might do = that and > demonstrates how "properties" might be used in WF. Right, but you're mixing the canonical description of WF with a = reasonable looking example which is actually not what's being standardized. I = maintain that it'll almost certainly cause confusion when people are looking for = how to provision and/or discovery email configuration, because it looks plausible enough and it's in a standards track document. The fact that St=E9phane is even asking why it's better suggests this is happening to = a degree already; I'm afraid it looks like a standards proposal even if = it's dressed as an example. Pick a small example that's not in conflict with ongoing standardization work, please. I understand you want to demonstrate that WF can be used = for autoconfiguration; I suggest making up a service to autoconfigure. Dave. ------=_NextPart_000_0103_01CE2680.3BFD79E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dave,

 

I agree that it looks entirely plausible.=A0 However, it cannot be = implemented as defined, because none of the rel values or property = values are defined.=A0 Of course, I could replace rel values like http://webfinger.exampl= e/rel/smtp-server with http://packetizer.com/rel/= smtp-server and properties like http://webfinger.example/ema= il/host with http://packetizer.com/ns/host.= =A0 However, that does not make any of that = standard.

 

I’m not interested to demonstrate that WF can be used for = auto-provisioning.=A0 Rather, I am interested to demonstrate use of = “properties” in a “link relation object” that = has no “href” member.=A0 Basically, this is example has = information that is entirely self-contained in the JRD and not dependent = on an external link.

 

You suggest I make up a service to auto-provision.=A0 So, it concerns = you only that I have an example with IMAP or does it concern you that = the example is an auto-provisioning example?=A0 I’m a little = confused.

 

Paul

 

From:= = Dave Cridland [mailto:dave@cridland.net]
Sent: Thursday, = March 21, 2013 7:55 AM
To: Paul E. Jones
Cc: = webfinger@ietf.org; Stephane Bortzmeyer
Subject: RE: = [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review = of draft-ietf-appsawg-webfinger-11

 


On 21 Mar 2013 02:57, = "Paul E. Jones" <paulej@packetizer.com> = wrote:
>
> Stephane,
>
> > > 1) There's = some suggestions that webfinger could be used for email
> > = > autoconfig; I suspect this is at best going to cause = confusion
> >
> > Indeed, the example with IMAP in 3.3 = confuses me. Why is is better than
> > the standard RFC = 6186?
>
> Keep in mind that this is just an example, but one = reason this approach is
> "better" is that I could build = an email client entirely in JavaScript
> running in a browser = using WF and some kind of configuration like this.  In
> the = end, we likely will not provision email clients exactly like this, = but
> that was not the expectation.  This example shows how = one might do that and
> demonstrates how "properties" = might be used in WF.

Right, but you're mixing the = canonical description of WF with a reasonable looking example which is = actually not what's being standardized. I maintain that it'll almost = certainly cause confusion when people are looking for how to provision = and/or discovery email configuration, because it looks plausible enough = and it's in a standards track document. The fact that St=E9phane is even = asking why it's better suggests this is happening to a degree already; = I'm afraid it looks like a standards proposal even if it's dressed as an = example.

Pick a small example that's not in conflict = with ongoing standardization work, please. I understand you want to = demonstrate that WF can be used for autoconfiguration; I suggest making = up a service to = autoconfigure.

Dave.

------=_NextPart_000_0103_01CE2680.3BFD79E0-- From paulej@packetizer.com Thu Mar 21 19:08:32 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBE421F86F0; Thu, 21 Mar 2013 19:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGTrfYS6wHHz; Thu, 21 Mar 2013 19:08:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19C21F86E6; Thu, 21 Mar 2013 19:08:31 -0700 (PDT) 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 r2M28CVH005306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Mar 2013 22:08:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363918094; bh=bc15GVl2xaDMJW/1FawH8hpFk6YTLJ0bIZ4Il1mluAw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OuwrAyv1pVFP3rfmOFuvqg4kJI7YAwFWz99H4Fh45xxHS0pQ92vueqGm+v6EqLk9t Ae5yyApRyx0baosXXeTmcbvEhG3wXhEJ+VSsvsj/bvtk4or4l8WOcMw1ZFnovPKfGb M4boRJB4lAPMwLUAFvQ2IMzUQkUV082iET/RxdLE= From: "Paul E. Jones" To: "'Alissa Cooper'" References: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> <055401ce25d3$5566f120$0034d360$@packetizer.com> <8E7B73F6-808B-4D8B-BE42-73A56C475C06@cdt.org> In-Reply-To: <8E7B73F6-808B-4D8B-BE42-73A56C475C06@cdt.org> Date: Thu, 21 Mar 2013 22:08:31 -0400 Message-ID: <010f01ce26a2$2804e550$780eaff0$@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: AQKDaKO5ldokcAP290Gb0nohuKjS1AOIlQ8RAuxRp2gCurAmypb89gJw Content-Language: en-us Cc: webfinger@ietf.org, ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [webfinger] [apps-discuss] Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 02:08:32 -0000 Got it. Thanks! I'll make that change. Paul > -----Original Message----- > From: Alissa Cooper [mailto:acooper@cdt.org] > Sent: Thursday, March 21, 2013 9:45 AM > To: Paul E. Jones > Cc: ietf@ietf.org; apps-discuss@ietf.org; webfinger@ietf.org > Subject: Re: [apps-discuss] Last Call: 10.txt> (WebFinger) to Proposed Standard > > I suggest adding the sentence without the word "implicitly." The result > would be: > > "Further, WebFinger MUST NOT be used to provide any personal information > to any party unless explicitly authorized by the person whose > information is being shared. Publishing one's personal data within an > access-controlled or otherwise limited environment on the Internet does > not equate to providing authorization of further publication of that > data via WebFinger." > > Thanks, > Alissa > > On Mar 20, 2013, at 9:28 PM, Paul E. Jones wrote: > > > Alissa, > > > > It was suggested that we remove the word "implicit". I'm OK with > > removing it. If we did that, would you want to add this new sentence > > or a modified version of it? > > > > Paul > > > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > >> bounces@ietf.org] On Behalf Of Alissa Cooper > >> Sent: Monday, March 18, 2013 11:31 AM > >> To: ietf@ietf.org > >> Cc: apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Last Call: >> 10.txt> (WebFinger) to Proposed Standard > >> > >> Given how little control Internet users already have over which > >> information about them appears in which context, I do not have a lot > >> of confidence that the claimed discoverability benefits of WebFinger > >> outweigh its potential to further degrade users' ability to keep > >> particular information about themselves within specific silos. > >> However, I'm coming quite late to this document, so perhaps that > >> balancing has already been discussed, and it strikes me as > >> unreasonable to try to stand in the way of publication at this point. > >> > >> Two suggestions in section 8: > >> > >> s/personal information/personal data/ (see > >> http://tools.ietf.org/html/draft-iab-privacy-considerations- > >> 06#section-2.2 -- personal data is a more widely accepted term and > >> covers a larger range of information about people) > >> > >> The normative prohibition against using WebFinger to publish personal > >> data without authorization is good, but the notion of implicit > >> authorization leaves much uncertainty about what I imagine will be a > >> use case of interest: taking information out of a controlled context > >> and making it more widely available. To make it obvious that this has > >> been considered, I would suggest adding one more sentence to the end > >> of the fourth paragraph: > >> > >> "Publishing one's personal data within an access-controlled or > >> otherwise limited environment on the Internet does not equate to > >> providing implicit authorization of further publication of that data > >> via WebFinger." > >> > >> Alissa > >> > >> On Mar 4, 2013, at 3:24 PM, The IESG wrote: > >> > >>> > >>> The IESG has received a request from the Applications Area Working > >>> Group WG (appsawg) to consider the following document: > >>> - 'WebFinger' > >>> as Proposed Standard > >>> > >>> The IESG plans to make a decision in the next few weeks, and > >>> solicits final comments on this action. Please send substantive > >>> comments to the ietf@ietf.org mailing lists by 2013-03-18. > >>> Exceptionally, comments may be sent to iesg@ietf.org instead. In > >>> either case, please retain the beginning of the Subject line to > allow automated sorting. > >>> > >>> Abstract > >>> > >>> > >>> 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. WebFinger discovers > >>> information for a URI that might not be usable as a locator > >>> otherwise, such as account or email URIs. > >>> > >>> > >>> > >>> > >>> The file can be obtained via > >>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > >>> > >>> IESG discussion can be tracked via > >>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ > >>> > >>> > >>> No IPR declarations have been submitted directly on this I-D. > >>> > >>> > >>> _______________________________________________ > >>> apps-discuss mailing list > >>> apps-discuss@ietf.org > >>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>> > >> > >> > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > From paulej@packetizer.com Thu Mar 21 19:50:30 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF39621F8F3A; Thu, 21 Mar 2013 19:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em1En0uifGOX; Thu, 21 Mar 2013 19:50:28 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 812B721F8E65; Thu, 21 Mar 2013 19:50:28 -0700 (PDT) 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 r2M2oMMP007316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Mar 2013 22:50:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363920627; bh=pkvIqZ4sMbKUGFIjl07Opu7S/+5Mb6ODX63RVtP9Nys=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=U0A+vy8Db6tSedazaoJ73jTukGM2OSE8dPFu0iuv1wzmi9QNVBrTNT0VjskkJj0NN A18MRcJ5HXTOB12Dsh30WZh7rpY90rarm+4qooiyrS0dZFkesaPFm8LLpfsWCprs4C qvx171SSjqFOhbw5OqB23Z7HqpMDiVcWrce+dpW8= From: "Paul E. Jones" To: "'Dave Cridland'" References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> In-Reply-To: Date: Thu, 21 Mar 2013 22:50:41 -0400 Message-ID: <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6xtTU7bBnElLUOVycpt5dUnTbtQEse7f/Af/Bk0eXvlbvIA== Content-Language: en-us Cc: webfinger@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 02:50:30 -0000 Dave, > > > 1) I note that =A74.4.4.1 describes a 'rel' such that it redefines = and > > > repeats RFC 5988's =A74; I think this should be deferred = explicitly to RFC > > > 5988 in entirety, rather than specifically only for registered = link > > > relation types. > > > > > > The good news is that this should simplify the text rather a lot: > > > > > > """ > > > The value of the "rel" member is a string containing a link = relation > > > type (see RFC 5988 [4]). Both registered and extended relation = types are > > > permitted. > > > """ > > > > I do not think we can simplify the text so much. There is an = explicit > > limitation in the WebFinger draft that a "rel" value must either be = a single > > absolute URI or a registered link relation type. RFC 5988 allows = for > > multiple values like 'rel=3D"shortcut icon"', but WebFinger does = not. RFC > > 5988 also allows URIs with fragments, but WebFinger does not. Valid URIs > > must conform to Section 4.3 of RFC 3986 (Absolute URIs). These decisions > > were intended to avoid ambiguity. >=20 > Link relation types are a single one of those values, the > ABNF production, as opposed to the rel, which contains = a > . I'm entirely with you on why you want to restrict = your > rel to a single link relation type. Worth calling it out the = difference, > but it's not a deviation from RFC 5988. So, you are OK with the restriction? =20 > However, if you're changing the definition of link relation types, = then: > > a) I'm deeply concerned. Redefining a standards-track specification > seems worryingly close to NIH. There's horrible confusion lurking when > someone says "Link relation type" and then has to qualify which > definition. > > b) You need to make this absolutely clear in the document; it reads = like > you're restating, not redefining. >=20 > c) The only distinction you claim above that appears to me to be an > actual distinction is that fragments are disallowed. Yet no such > restriction exists in the current draft. I'm still missing something. How are we changing the definition of a = link relation type, aside from restricting rel to having a single value that = is either an absolute URI or a single link relation type? Perhaps what might be confusing is the part that starts with "The other members of the object have meaning only..." probably should be a = separate paragraph. The whole focus of the rest of the paragraph is to explain = that the other members of the "link relation object" can only be interpreted = once the link relation type is understood. We had no intention of changing the definition of a link relation type, though we do have the stated restrictions in 4.4.4.1: "rel" is exactly = one of either an absolute URI or a registered relation type. > > Much of the text you removed talks about the other members of the = link > > relation object, which include "type", "href", "titles", and "properties". > > The value of the "rel" member dictates how the other members are interpreted > > and so I think that text needs to remain. > Yes, I've probably trimmed too much there. > > > 2) The use of webfinger with arbitrary URIs is something I had not > > > previously realised. This raises some concerns for me, as it's not clear > > > whether this is either genuinely desirable or whether it = introduces > > > considerations (security and otherwise) beyond those discussed = within > > > the document. > > > > > > I would in general rather the mechanism were restricted to acct, = http, > > > https, and perhaps mailto. > > > > I don't think use of one URI scheme vs. another makes any difference = in > > terms of security. However, it was definitely the desire of the = group to be > > able to use any URI scheme, including some URIs like 'tel'. Use of 'tel' > > would mean the exact resolution mechanism would have to be defined, = but > > people did not want to preclude its use. For others that have a = domain > > part, the desire is to be able to go to the server and request a JRD = for > > that URI. There may or may not be information available for a given URI, > > but the procedures for one URI or another would be exactly the same. >=20 > I did say "security and otherwise". I'm not saying that any given URI > scheme should be discounted forever more, I am suggesting the document > should limit the schemes which have a defined behaviour for now. All URIs have the same defined behavior. You ask the server if it has = any information about X and it replies with a JRD if it does or 404 if it = does not. There is no difference in behavior between = acct:paulej@packetizer.com or h323:paulej@packetizer.com. Both are requesting information about = the person or thing associated with the URI. As you can see, you'll get the same answer: $ curl https://packetizer.com/.well-known/webfinger?resource=3Dacct:paulej@packe= tizer .com $ curl https://packetizer.com/.well-known/webfinger?resource=3Dh323:paulej@packe= tizer .com (Except that the aliases array is modified.) =20 > I have no clue what the possible impacts of using webfinger on a = message > id URI might be, nor do I wish to even think about it. Likely a 404. =20 > I'm pretty sure that mailto has some corner cases we've not yet = thought > about; it's not just an email address after all. On my server, that returns a JRD in the form of the example you do not = like so much. :-) It would be entirely reasonable to also return the same JRD as the acct: URI. We struggled several years with whether to use mailto or acct. = Given that some services do not have email (notably, Twitter), there were a = push for acct. That's fairly well adopted at this point, but I would not = dismiss the use of mailto if that is the identifier one has in hand. It might also be that aggsrv uses mailto to query for a JRD that has = links pointing to aggsrv documents. I outlined two ways WF could be used to = make that happen during the BoF. (But I did it with lightning speed due to = time constraints, so people might have blinked and missed it.) > > > 3) There is no use of SRV here; I would prefer an SRV resolution = step > > > for at least acct and mailto scheme URIs, and possibly http/https = as > > > well. My concern is that a corporate webserver is typically = unlikely to > > > be capable of providing webfinger services (being often externally > > > hosted), and while this could be solved by handling redirects, or = by > > > reverse proxying, SRV feels like a more stable solution here. > > > > > > I'd be curious as to whether this has been discussed. > > > > This was discussed at length, yes. We also discussed the use of the = URI > > resource record type. > > > > SRV records will tell you what host to go to, but not what URI. > > URI records will tell you more precisely what URI to query. > > > > However, both mechanisms build a dependency on DNS that will not = work in web > > browsers. One of the first uses of WebFinger (for which there are already a > > few libraries available) is to query for information about people directly > > from JavaScript in a browser. Thus, it was preferred to use a .well-known > > location rooted at the given host. >=20 > That sucks. > > It's a shame that browsers are holding back use of SRV and other > decade-old technology for things like this. But I accept that this = has > been discussed and blocked by browser brokenness. I agree. Folks have some security concerns with the prospect, though. = I'm not sure exactly what those concerns are, but it would be nice if there = was a secure was to do SRV or URI record lookups from the browser. Paul From dave@cridland.net Fri Mar 22 01:33:46 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B7421F9031 for ; Fri, 22 Mar 2013 01:33:46 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdDBnCONVAEt for ; Fri, 22 Mar 2013 01:33:45 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA3321F8DD9 for ; Fri, 22 Mar 2013 01:33:45 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so3982016oag.39 for ; Fri, 22 Mar 2013 01:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=H6Odxde4Adxxc9COR0iqLaG4E2WccCAw01rZ1BK4AJU=; b=h8fdKio3M0oYZu4DCYoDq9z/IU1ezAzbGsR4eZJyHx8iQhijrXSDANPCE7lWeJ+MPY 1EzDm4s4CqAilYZ+lOT/4Rv2EhuyDAlYiiY1462g+SjSZyNPTOuy/34JU+mG54m8tOfr nBwZa8E7uEgMu0w3FMcFB/TxRI6BXfafiBXcU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=H6Odxde4Adxxc9COR0iqLaG4E2WccCAw01rZ1BK4AJU=; b=G9DgNYeHF4A2RCyXKWXJKz4xgeqq2VuYNKhyizracpIS0LR72QAHuoq36OAbWcy5tU 5va5mi97KR3TfIo1eefk7utbMKjmpeaxe2bmT80uw/Z+/1rcSMC0YicLa5F4JIx+FOeD 3wcZHicpTgfltmn6PbQ9yx5K+Nm/5KAuosreMJRh4Oulsi1BXowf+0r9yqoGigOD8IIn RTMe+6Z6MMf40aiHZANtL4RS/PGUc71LuGYRZFiOUI1H/sJdt2hcmEvRxcayPeS9S9A3 W8FcwPS8UNqWXmbHwW2Pg3Pm0zx+QFfMYCPQQyAz7lDwEnrbQjYJBqtVeXuCl8SZ3KjA XWBg== MIME-Version: 1.0 X-Received: by 10.60.25.138 with SMTP id c10mr883089oeg.12.1363941224664; Fri, 22 Mar 2013 01:33:44 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Fri, 22 Mar 2013 01:33:44 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Fri, 22 Mar 2013 01:33:44 -0700 (PDT) In-Reply-To: <010201ce26a1$c30e5690$492b03b0$@packetizer.com> References: <20130315151027.GB28881@laperouse.bortzmeyer.org> <056c01ce25df$d4cf1940$7e6d4bc0$@packetizer.com> <010201ce26a1$c30e5690$492b03b0$@packetizer.com> Date: Fri, 22 Mar 2013 08:33:44 +0000 Message-ID: From: Dave Cridland To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8ff1c2fc31362304d87f50c1 X-Gm-Message-State: ALoCoQlu6UEkuRS7zy9/xv8zhNUQQUiJxma5WNRFQQxfcCQP+pM51DoBr+WaQwkr+qDdLmNfc9FY Cc: webfinger@ietf.org, Stephane Bortzmeyer Subject: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:33:46 -0000 --e89a8ff1c2fc31362304d87f50c1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 22 Mar 2013 02:05, "Paul E. Jones" wrote: > I=92m not interested to demonstrate that WF can be used for auto-provisioning. Rather, I am interested to demonstrate use of =93properties=94 in a =93link relation object=94 that has no =93href=94 mem= ber. Basically, this is example has information that is entirely self-contained in the JRD and not dependent on an external link. > > Great, so find an example that demonstrates that. > > You suggest I make up a service to auto-provision. So, it concerns you only that I have an example with IMAP or does it concern you that the example is an auto-provisioning example? I=92m a little confused. My concern is that you have an example which overlaps an area of standardization. I'd hate people to implement this instead of whatever aggsrv comes up with. Replace mail with blurdybloop and I'll be happy. Dave. --e89a8ff1c2fc31362304d87f50c1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On 22 Mar 2013 02:05, "Paul E. Jones" <paulej@packetizer.com> wrote:
> I=92m not interested to demonstrate that WF can be used for auto-provi= sioning.=A0 Rather, I am interested to demonstrate use of =93properties=94 = in a =93link relation object=94 that has no =93href=94 member.=A0 Basically= , this is example has information that is entirely self-contained in the JR= D and not dependent on an external link.
>
> =A0

Great, so find an example that demonstrates that.

>
> You suggest I make up a service to auto-provision.=A0 So, it concerns = you only that I have an example with IMAP or does it concern you that the e= xample is an auto-provisioning example?=A0 I=92m a little confused.

My concern is that you have an example which overlaps an are= a of standardization. I'd hate people to implement this instead of what= ever aggsrv comes up with.

Replace mail with blurdybloop and I'll be happy.

Dave.

--e89a8ff1c2fc31362304d87f50c1-- From laurentwalter.goix@telecomitalia.it Fri Mar 22 01:59:29 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4121F9097 for ; Fri, 22 Mar 2013 01:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzSlrXgfnYS9 for ; Fri, 22 Mar 2013 01:59:28 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 67BDB21F9092 for ; Fri, 22 Mar 2013 01:59:27 -0700 (PDT) Content-Type: multipart/mixed; boundary="_b72d0ac6-7446-43a1-bb0a-1df27d85dbb4_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 22 Mar 2013 09:59:20 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Fri, 22 Mar 2013 09:59:20 +0100 From: Goix Laurent Walter To: Dave Cridland , "Paul E. Jones" Date: Fri, 22 Mar 2013 09:59:17 +0100 Thread-Topic: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 Thread-Index: Ac4m2HoFUdhz1qHNSCOgXAfwLI73EQAAem1A Message-ID: References: <20130315151027.GB28881@laperouse.bortzmeyer.org> <056c01ce25df$d4cf1940$7e6d4bc0$@packetizer.com> <010201ce26a1$c30e5690$492b03b0$@packetizer.com> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "webfinger@ietf.org" , Stephane Bortzmeyer Subject: [webfinger] R: Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:59:30 -0000 --_b72d0ac6-7446-43a1-bb0a-1df27d85dbb4_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A7C58081GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A7C58081GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Autoconfiguration in general is a useful use case of webfinger and it would= make sense to me to call it out explicitly. I could try to make an example= focused on the social networking space in order not to conflict with email= provisioning, although it may contain hrefs if this can accommodate all. Then if we want an example to show link rels with properties and no href co= uld we move this to the fictitious tipsi example adding another link rel wi= th only properties (e.g. printer capabilities such as front-retro, a3 forma= t, color, etc) ? walter Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per cont= o di Dave Cridland Inviato: venerd=EC 22 marzo 2013 9.34 A: Paul E. Jones Cc: webfinger@ietf.org; Stephane Bortzmeyer Oggetto: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsD= ir Review of draft-ietf-appsawg-webfinger-11 On 22 Mar 2013 02:05, "Paul E. Jones" > wrote: > I'm not interested to demonstrate that WF can be used for auto-provisioni= ng. Rather, I am interested to demonstrate use of "properties" in a "link = relation object" that has no "href" member. Basically, this is example has= information that is entirely self-contained in the JRD and not dependent o= n an external link. > > Great, so find an example that demonstrates that. > > You suggest I make up a service to auto-provision. So, it concerns you o= nly that I have an example with IMAP or does it concern you that the exampl= e is an auto-provisioning example? I'm a little confused. My concern is that you have an example which overlaps an area of standardiz= ation. I'd hate people to implement this instead of whatever aggsrv comes u= p with. Replace mail with blurdybloop and I'll be happy. Dave. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A7C58081GRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Autoconfiguration in general is a useful use case of webfing= er and it would make sense to me to call it out explicitly. I could try to = make an example focused on the social networking space in order not to conflict wi= th email provisioning, although it may contain hrefs if this can accommodat= e all.

 

Then if we want an example to show link rels with properties= and no href could we move this to the fictitious tipsi example adding anot= her link rel with only properties (e.g. printer capabilities such as front-retro, a= 3 format, color, etc) ?

 

walter

 

Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf= .org] Per conto di Dave Cridland
Inviato: venerd=EC 22 marzo 2013 9.34
A: Paul E. Jones
Cc: webfinger@ietf.org; Stephane Bortzmeyer
Oggetto: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss= ] AppsDir Review of draft-ietf-appsawg-webfinger-11

 


On 22 Mar 2013 02:05, "Paul E. Jones" <paulej@packetizer.com> wrote:
> I’m not interested to demonstrate that WF can be used for auto-p= rovisioning.  Rather, I am interested to demonstrate use of “pro= perties” in a “link relation object” that has no “h= ref” member.  Basically, this is example has information that is= entirely self-contained in the JRD and not dependent on an external link.
>
>  

Great, so find an example that demonstrates that.

>
> You suggest I make up a service to auto-provision.  So, it concer= ns you only that I have an example with IMAP or does it concern you that th= e example is an auto-provisioning example?  I’m a little confuse= d.

My concern is that you have an example which overlaps an area of standar= dization. I'd hate people to implement this instead of whatever aggsrv come= s up with.

Replace mail with blurdybloop and I'll be happy.

Dave.

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A7C58081GRFMBX704BA02_-- --_b72d0ac6-7446-43a1-bb0a-1df27d85dbb4_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_b72d0ac6-7446-43a1-bb0a-1df27d85dbb4_-- From dave@cridland.net Fri Mar 22 02:32:13 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB23021F9032 for ; Fri, 22 Mar 2013 02:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNIw2iFwcbBB for ; Fri, 22 Mar 2013 02:32:10 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 181AE21F852B for ; Fri, 22 Mar 2013 02:32:10 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m17so2733485oag.12 for ; Fri, 22 Mar 2013 02:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eH+Ez5Rj8UiIvvZzTXcZ/BN+hif1ZGsCl89tpDr1G9M=; b=cBtHth8OVwCi17l62Wd6zUUxhlkkfZuH1tDF170gSUYh6/PspZYRm9vM2CaqJy7pty JoPegZTBVgiFR7gLoZvD/8Crss8yN7+v/qbIG0ikAtJjmQ7HIcZqbQdg2odVud2cnpqb JRMv+zeRtmfoK1qO94273k5NnLTps8zXdJsno= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=eH+Ez5Rj8UiIvvZzTXcZ/BN+hif1ZGsCl89tpDr1G9M=; b=Yp1LCH6DwmySI/MFLk3Ls9ZGkTL1utFbABxzHg3eVNeySqm+Dy8ZQy4CkQq74pR2mN xUMujLDB3yW5hvcncklp0xGo0YQ2eravVbshJPgrBKfK5yAx936WHU9frvcwFNh9mIRx IjkCLLe6AhTq4O/pNqhTpuoZ88MbF6lfDbT6UgfPtjYHUXJY/ruRV9w1YlzRahiNGjHF 0FVWf4OIRSGlgvQkmx0/xhhj46k56zd/9sqL91Iea2bQPX9kV+4+jfZNEjM1+W5COp3q +UsFO+boiR4Dlqgb2r2QnWWpapd5IDgRNkv4DyONQniB7s96RSGTcP6x/NZmUzU8AXQV AGUA== MIME-Version: 1.0 X-Received: by 10.60.29.72 with SMTP id i8mr935534oeh.93.1363944729377; Fri, 22 Mar 2013 02:32:09 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Fri, 22 Mar 2013 02:32:09 -0700 (PDT) In-Reply-To: <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> Date: Fri, 22 Mar 2013 09:32:09 +0000 Message-ID: From: Dave Cridland To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f80616e36004d88021be X-Gm-Message-State: ALoCoQmkD97FP5E7JEikJemUzpGHQcZUbbFGDG4K92MXaX7RuSXm/zUJaoFBIBiyWp9pz1kODGJq Cc: webfinger@ietf.org, iesg@ietf.org, "apps-discuss@ietf.org" , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 09:32:14 -0000 --e89a8fb1f80616e36004d88021be Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2013 at 2:50 AM, Paul E. Jones wrote: > > Dave, > > > > > 1) I note that =A74.4.4.1 describes a 'rel' such that it redefines = and > > > > repeats RFC 5988's =A74; I think this should be deferred explicitly= to > RFC > > > > 5988 in entirety, rather than specifically only for registered link > > > > relation types. > > > > > > > > The good news is that this should simplify the text rather a lot: > > > > > > > > """ > > > > The value of the "rel" member is a string containing a link relatio= n > > > > type (see RFC 5988 [4]). Both registered and extended relation type= s > are > > > > permitted. > > > > """ > > > > > > I do not think we can simplify the text so much. There is an explici= t > > > limitation in the WebFinger draft that a "rel" value must either be a > single > > > absolute URI or a registered link relation type. RFC 5988 allows for > > > multiple values like 'rel=3D"shortcut icon"', but WebFinger does not. RFC > > > 5988 also allows URIs with fragments, but WebFinger does not. Valid > URIs > > > must conform to Section 4.3 of RFC 3986 (Absolute URIs). These > decisions > > > were intended to avoid ambiguity. > > > > Link relation types are a single one of those values, the > > ABNF production, as opposed to the rel, which contains = a > > . I'm entirely with you on why you want to restrict you= r > > rel to a single link relation type. Worth calling it out the difference= , > > but it's not a deviation from RFC 5988. > > So, you are OK with the restriction? > Restricting it to a single link relation type (as defined by RFC 5988, and the ABNF production therein) is perfectly fine. > > > However, if you're changing the definition of link relation types, then= : > > > > a) I'm deeply concerned. Redefining a standards-track specification > > seems worryingly close to NIH. There's horrible confusion lurking when > > someone says "Link relation type" and then has to qualify which > > definition. > > > > b) You need to make this absolutely clear in the document; it reads lik= e > > you're restating, not redefining. > > > > c) The only distinction you claim above that appears to me to be an > > actual distinction is that fragments are disallowed. Yet no such > > restriction exists in the current draft. > > I'm still missing something. How are we changing the definition of a lin= k > relation type, aside from restricting rel to having a single value that i= s > either an absolute URI or a single link relation type? > So, you said, broken apart for readability: >>> RFC 5988 allows for multiple values like 'rel=3D"shortcut icon"', but WebFinger does not. I see that RFC 5988 allows its 'rel' parameter to hold multiple Link Relation Types, yes. I agree that restricting this is reasonable. (I have no view on whether it's sensible). However, that's referring to the RFC 5988 "rel" parameter (or attribute), and absolutely not the definition of Link Relation Type, which is always a single registered token or an absolute URI (which itself SHOULD be lowercased). >>> RFC 5988 also allows URIs with fragments, but WebFinger does not. Your current draft makes no restriction on whether a Link Relation Type may have a fragment or not. It stipulates an absolute URI, which in RFC 3986 may have a fragment; therefore this restriction is not in the draft as written. Neither is it in RFC 5988; however if you do intend adding this restriction then this represents a deviation. >>> Valid URIs must conform to Section 4.3 of RFC 3986 (Absolute URIs). I'm not sure if you considered this a difference or not; as far as I can tell RFC 5988 only allows absolute URIs (of the extended relation types), though it explicitly calls out this requirement for the Link header itself. Either way this seems reasonable, and not a deviation. > > We had no intention of changing the definition of a link relation type, > though we do have the stated restrictions in 4.4.4.1: "rel" is exactly on= e > of either an absolute URI or a registered relation type. > Right, which is a Link Relation Type as defined in RFC 5988. Either you have changed the definition (or at least, rel doesn't hold a link relation type), in which case my opinion remains that this is a bad thing, but in any case needs to be made abundantly clear in the document... ... or you haven't, in which case I don't understand why you won't simply reference RFC 5988 instead of referencing it piecemeal. > > > I have no clue what the possible impacts of using webfinger on a messag= e > > id URI might be, nor do I wish to even think about it. > > Likely a 404. > I don't think whether it works is the sole consideration. > > > I'm pretty sure that mailto has some corner cases we've not yet thought > > about; it's not just an email address after all. > > On my server, that returns a JRD in the form of the example you do not like > so much. :-) > I said corner cases. Please read RFC 6068; you appear to be labouring under the assumption that a mailto URI is identical to an acct URI except for the scheme. > > It would be entirely reasonable to also return the same JRD as the acct: > URI. We struggled several years with whether to use mailto or acct. Given > that some services do not have email (notably, Twitter), there were a pus= h > for acct. That's fairly well adopted at this point, but I would not dismiss > the use of mailto if that is the identifier one has in hand. > I don't think mailto is nearly as simple as you seem to think it is. I don't know enough about other URI schemes to know whether other schemes have the same problem. My issue here is not a matter of the good things that might reasonably happen from careful use of simple URIs with arbitrary schemes; my concern is that there may be bad things with odd cases and there's no evidence that these have been thought through. So for mailto, for example, I'd think you want to restrict the URI form used to being, using RFC 6068's ABNF, '"mailto:" to', and avoid any other forms. What I don't know - and given the way URIs can have entertaining corner cases like this, what worries me - is not only whether the whole thing works if you have an odd URI construct (mailto or no), but whether it's safe. I think as you look deeply into various URI schemes, there'll be cans of worms in a number of places, and the safer thing to do is to restrict the schemes and URI forms that are - currently - allowed. Look on the bright side, you'll have the fun of specifying what a telnet URI should give you back from WF. At the very least, I'd suggest that you add a security consideration > > It might also be that aggsrv uses mailto to query for a JRD that has link= s > pointing to aggsrv documents. I outlined two ways WF could be used to make > that happen during the BoF. (But I did it with lightning speed due to time > constraints, so people might have blinked and missed it.) > I listened to your presentation with interest, I've not yet formed a view on how aggsrv ought to work, and I've personally not ruled out that WebFinger ought to play a role in it. I've no "anti WF" axe to grind here; in fact I'd have unequivocally supported using WF if it weren't for the lack of SRV, which leaves me undecided. I'm just concerned that this has the potential to be sidestepping the standardization process inadvertently. Dave. --e89a8fb1f80616e36004d88021be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 22, 2013 at 2:50 AM, Paul E. Jones <paulej@packetizer.com> wrote:
&= gt;
> Dave,
>
> > > > 1) I note that =A74.4.4.1 = describes a 'rel' such that it redefines and
> > > > repeats RFC 5988's =A74; I think this should be def= erred explicitly to
> RFC
> > > > 5988 in entirety, ra= ther than specifically only for registered link
> > > > rela= tion types.
> > > >
> > > > The good news is that this shoul= d simplify the text rather a lot:
> > > >
> > > = > """
> > > > The value of the "rel&q= uot; member is a string containing a link relation
> > > > type (see RFC 5988 [4]). Both registered and extended r= elation types
> are
> > > > permitted.
> > &g= t; > =A0"""
> > >
> > > I do not = think we can simplify the text so much. =A0There is an explicit
> > > limitation in the WebFinger draft that a "rel" val= ue must either be a
> single
> > > absolute URI or a regi= stered link relation type. =A0RFC 5988 allows for
> > > multipl= e values like 'rel=3D"shortcut icon"', but WebFinger does= not. =A0RFC
> > > 5988 also allows URIs with fragments, but WebFinger does not= . =A0Valid
> URIs
> > > must conform to Section 4.3 of RF= C 3986 (Absolute URIs). =A0These
> decisions
> > > were i= ntended to avoid ambiguity.
> >
> > Link relation types are a single one of those values= , the
> > <relation-type> ABNF production, as opposed to the= rel, which contains a
> > <relation-types>. I'm entirel= y with you on why you want to restrict your
> > rel to a single link relation type. Worth calling it out the diff= erence,
> > but it's not a deviation from RFC 5988.
>> So, you are OK with the restriction?
>

Restricting it to= a single link relation type (as defined by RFC 5988, and the <relation-= type> ABNF production therein) is perfectly fine.
=A0
>
> > However, if you're changing the definition of = link relation types, then:
> >
> > a) I'm deeply conc= erned. Redefining a standards-track specification
> > seems worryi= ngly close to NIH. There's horrible confusion lurking when
> > someone says "Link relation type" and then has to quali= fy which
> > definition.
> >
> > b) You need to = make this absolutely clear in the document; it reads like
> > you&= #39;re restating, not redefining.
> >
> > c) The only distinction you claim above that appears= to me to be an
> > actual distinction is that fragments are disal= lowed. Yet no such
> > restriction exists in the current draft. >
> I'm still missing something. =A0How are we changing the de= finition of a link
> relation type, aside from restricting rel to hav= ing a single value that is
> either an absolute URI or a single link = relation type?
>

So, you said, broken apart for readability:

>>>= RFC 5988 allows for multiple values like 'rel=3D"shortcut icon&qu= ot;', but WebFinger does not.

I see that RFC 5988 allows its = 9;rel' parameter to hold multiple Link Relation Types, yes. I agree tha= t restricting this is reasonable. (I have no view on whether it's sensi= ble). However, that's referring to the RFC 5988 "rel" paramet= er (or attribute), and absolutely not the definition of Link Relation Type,= which is always a single registered token or an absolute URI (which itself= SHOULD be lowercased).

>>> RFC 5988 also allows URIs with fragments, but WebFinger do= es not.

Your current draft makes no restriction on whether a Link Re= lation Type may have a fragment or not. It stipulates an absolute URI, whic= h in RFC 3986 may have a fragment; therefore this restriction is not in the= draft as written. Neither is it in RFC 5988; however if you do intend addi= ng this restriction then this represents a deviation.

>>> Valid URIs must conform to Section 4.3 of RFC 3986 (Absolu= te URIs).

I'm not sure if you considered this a difference or no= t; as far as I can tell RFC 5988 only allows absolute URIs (of the extended= relation types), though it explicitly calls out this requirement for the L= ink header itself. Either way this seems reasonable, and not a deviation. =A0
>
> We had no intention of changing the definition of a lin= k relation type,
> though we do have the stated restrictions in 4.4.4.1: "rel" is exactly one
> o= f either an absolute URI or a registered relation type.
>

Right, which is a Link Relation Type as defined in RFC 5988.
Either you have changed the definition (or at least, rel doesn't h= old a link relation type), in which case my opinion remains that this is a = bad thing, but in any case needs to be made abundantly clear in the documen= t...

... or you haven't, in which case I don't understand why you wo= n't simply reference RFC 5988 instead of referencing it piecemeal.
= =A0
>
> > I have no clue what the possible impacts of using = webfinger on a message
> > id URI might be, nor do I wish to even think about it.
>> Likely a 404.
>

I don't think whether it works is th= e sole consideration.
=A0
>
> > I'm pretty sure that = mailto has some corner cases we've not yet thought
> > about; it's not just an email address after all.
>
&= gt; On my server, that returns a JRD in the form of the example you do not = like
> so much. :-)
>

I said corner cases. Please read R= FC 6068; you appear to be labouring under the assumption that a mailto URI = is identical to an acct URI except for the scheme.
=A0
>
> It would be entirely reasonable to also return the same= JRD as the acct:
> URI. =A0We struggled several years with whether t= o use mailto or acct. =A0Given
> that some services do not have email= (notably, Twitter), there were a push
> for acct. =A0That's fairly well adopted at this point, but I would= not dismiss
> the use of mailto if that is the identifier one has in= hand.
>

I don't think mailto is nearly as simple as you s= eem to think it is. I don't know enough about other URI schemes to know= whether other schemes have the same problem.

My issue here is not a matter of the good things that might reasonably = happen from careful use of simple URIs with arbitrary schemes; my concern i= s that there may be bad things with odd cases and there's no evidence t= hat these have been thought through.

So for mailto, for example, I'd think you want to restrict the URI = form used to being, using RFC 6068's ABNF, '"mailto:" to&= #39;, and avoid any other forms. What I don't know - and given the way = URIs can have entertaining corner cases like this, what worries me - is not= only whether the whole thing works if you have an odd URI construct (mailt= o or no), but whether it's safe.

I think as you look deeply into various URI schemes, there'll be ca= ns of worms in a number of places, and the safer thing to do is to restrict= the schemes and URI forms that are - currently - allowed. Look on the brig= ht side, you'll have the fun of specifying what a telnet URI should giv= e you back from WF.

At the very least, I'd suggest that you add a security consideratio= n
=A0
>
> It might also be that aggsrv uses mailto to query= for a JRD that has links
> pointing to aggsrv documents. =A0I outlin= ed two ways WF could be used to make
> that happen during the BoF. =A0(But I did it with lightning speed due = to time
> constraints, so people might have blinked and missed it.)>

I listened to your presentation with interest, I've not y= et formed a view on how aggsrv ought to work, and I've personally not r= uled out that WebFinger ought to play a role in it. I've no "anti = WF" axe to grind here; in fact I'd have unequivocally supported us= ing WF if it weren't for the lack of SRV, which leaves me undecided.
I'm just concerned that this has the potential to be sidestepping t= he standardization process inadvertently.

Dave.
--e89a8fb1f80616e36004d88021be-- From paulej@packetizer.com Fri Mar 22 07:09:13 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E8121F8BA1 for ; Fri, 22 Mar 2013 07:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35QXXE1ACRC6 for ; Fri, 22 Mar 2013 07:09:11 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5885A21F8B51 for ; Fri, 22 Mar 2013 07:09:11 -0700 (PDT) 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 r2ME99kD012522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Mar 2013 10:09:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363961350; bh=Cv7s6rQW/i8vcgzDbmgm9pvgtwV4DcwMzGWhIZtGKA0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=IxVmELgoMrfbdgzrlbv9T1TTf5/to4XOMUM99KAh8kNNZ1aAOSkuVGufA034hySNH RLn8j+ZOl6Th+zCHPs5lO06fksredDuPD7+53nAFlCGn+LTuhnIEWRaGaeMzBtMayg 4SKmt8BVMMeUkrQ3MyqQh9NQS2ubsMV4gkvYSoXY= From: "Paul E. Jones" To: "'Dave Cridland'" References: <20130315151027.GB28881@laperouse.bortzmeyer.org> <056c01ce25df$d4cf1940$7e6d4bc0$@packetizer.com> <010201ce26a1$c30e5690$492b03b0$@packetizer.com> In-Reply-To: Date: Fri, 22 Mar 2013 10:09:29 -0400 Message-ID: <01bd01ce2706$dec829f0$9c587dd0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BE_01CE26E5.57B74D40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6xtTU7bBnElLUOVycpt5dUnTbtQITD5xDAZSIwP0BPdUU+gG5UuEAApSZbM2XjuH28A== Content-Language: en-us Cc: webfinger@ietf.org, 'Stephane Bortzmeyer' Subject: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 14:09:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01BE_01CE26E5.57B74D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dave, This example does demonstrate what I wanted to demonstrate. So, in terms of objective for the example, the example does the job. So, the real concern is that it overlaps with aggsrv? I'll note we discussed this long before aggsrv, though it wasn't until November that such an example was inserted because I was hoping Cyrus would produce an example. He produced something that more-or-less replicates much of WebFinger. There is a danger in giving an example of "blurdybloop". The example in Section 3.4 is like that. It's entirely fictitious and people did express concern with that. There is no such thing as a "device" URI scheme, after all. However, I had to have something that demonstrated the applicability of WF to things like this. It's abstract, because I don't have a concrete example to point to. Now, with Section 3.3, I have something more concrete I can point to. You read it and understood it. You rightfully pointed out that it looks plausible. That's the whole point and I wish I had something equally as good for Section 3.4. Still, though it looks plausible, it's not implementable since none of the values (link relation type of properties) are standard. I'd say the example works. Now, I insert something off-the-wall, it might not make as much sense to people. I need an example that people can understand and it clicks when they read it. So what kind of example could that be? I don't have a good example coming to mind right now. Paul From: Dave Cridland [mailto:dave@cridland.net] Sent: Friday, March 22, 2013 4:34 AM To: Paul E. Jones Cc: webfinger@ietf.org; Stephane Bortzmeyer Subject: RE: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 On 22 Mar 2013 02:05, "Paul E. Jones" wrote: > I'm not interested to demonstrate that WF can be used for auto-provisioning. Rather, I am interested to demonstrate use of "properties" in a "link relation object" that has no "href" member. Basically, this is example has information that is entirely self-contained in the JRD and not dependent on an external link. > > Great, so find an example that demonstrates that. > > You suggest I make up a service to auto-provision. So, it concerns you only that I have an example with IMAP or does it concern you that the example is an auto-provisioning example? I'm a little confused. My concern is that you have an example which overlaps an area of standardization. I'd hate people to implement this instead of whatever aggsrv comes up with. Replace mail with blurdybloop and I'll be happy. Dave. ------=_NextPart_000_01BE_01CE26E5.57B74D40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 

This example does demonstrate what I wanted to demonstrate.  So, = in terms of objective for the example, the example does the = job.

 

So, the real concern is that it overlaps with aggsrv?  = I’ll note we discussed this long before aggsrv, though it = wasn’t until November that such an example was inserted because I = was hoping Cyrus would produce an example.  He produced something = that more-or-less replicates much of WebFinger.

 

There is a danger in giving an example of = “blurdybloop”.  The example in Section 3.4 is like = that.  It’s entirely fictitious and people did express = concern with that.  There is no such thing as a = “device” URI scheme, after all.  However, I had to have = something that demonstrated the applicability of WF to things like = this.  It’s abstract, because I don’t have a concrete = example to point to.

 

Now, with Section 3.3, I have something more concrete I can point = to.  You read it and understood it.  You rightfully pointed = out that it looks plausible.  That’s the whole point and I = wish I had something equally as good for Section 3.4.  Still, = though it looks plausible, it’s not implementable since none of = the values (link relation type of properties) are standard.  = I’d say the example works.

 

Now, I insert something off-the-wall, it might not make as much sense = to people.  I need an example that people can understand and it = clicks when they read it.  So what kind of example could that = be?  I don’t have a good example coming to mind right = now.

 

Paul

 

From:= = Dave Cridland [mailto:dave@cridland.net]
Sent: Friday, March = 22, 2013 4:34 AM
To: Paul E. Jones
Cc: = webfinger@ietf.org; Stephane Bortzmeyer
Subject: RE: = [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review = of draft-ietf-appsawg-webfinger-11

 


On 22 Mar 2013 02:05, = "Paul E. Jones" <paulej@packetizer.com> = wrote:
> I’m not interested to demonstrate that WF can be = used for auto-provisioning.  Rather, I am interested to demonstrate = use of “properties” in a “link relation object” = that has no “href” member.  Basically, this is example = has information that is entirely self-contained in the JRD and not = dependent on an external link.
>
> =  

Great, so find an example that demonstrates = that.

>
> You suggest I make up a service to = auto-provision.  So, it concerns you only that I have an example = with IMAP or does it concern you that the example is an = auto-provisioning example?  I’m a little = confused.

My concern is that you have an example which = overlaps an area of standardization. I'd hate people to implement this = instead of whatever aggsrv comes up with.

Replace mail = with blurdybloop and I'll be = happy.

Dave.

------=_NextPart_000_01BE_01CE26E5.57B74D40-- From paulej@packetizer.com Fri Mar 22 07:18:53 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDBE21F8C66 for ; Fri, 22 Mar 2013 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xX2dMFWqlZ2 for ; Fri, 22 Mar 2013 07:18:51 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CAA6E21F8AC1 for ; Fri, 22 Mar 2013 07:18:50 -0700 (PDT) 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 r2MEInVv013052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Mar 2013 10:18:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363961929; bh=68rL2lz8QK597kXu/IkashF8B+avQkNImfgrh7FUm6o=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=GYURV/5qLuo0NmnDATtmju+rfDHIs8beJ8c3fecOEMECPEhMfGvtTx7SarqtCFHEW JAW3qTB0jBAbnJ2YHe77nuAKSxKIdAd/hbtwWhhsMGJTA3uc8sSZAQTn1vdvvdAJDo ZTTCVfQ07v8bzF6l8RRaea+CvFswETcdZ84AeZD8= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , "'Dave Cridland'" References: <20130315151027.GB28881@laperouse.bortzmeyer.org> <056c01ce25df$d4cf1940$7e6d4bc0$@packetizer.com> <010201ce26a1$c30e5690$492b03b0$@packetizer.com> In-Reply-To: Date: Fri, 22 Mar 2013 10:19:09 -0400 Message-ID: <01e601ce2708$38655630$a9300290$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_01E7_01CE26E6.B154C7A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6xtTU7bBnElLUOVycpt5dUnTbtQITD5xDAZSIwP0BPdUU+gG5UuEAApSZbM0CBs3Mfpd+sPSw Content-Language: en-us Cc: webfinger@ietf.org, 'Stephane Bortzmeyer' Subject: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 14:18:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01E7_01CE26E6.B154C7A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01E8_01CE26E6.B154C7A0" ------=_NextPart_001_01E8_01CE26E6.B154C7A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If it=92s only a matter of email provisioning and any other kind of auto-provisioning is OK, then I could insert an example of provisioning = an H.323 terminal. =20 If you have a good example for social networking that does not require = an href, that would be good. Even if it was just one link that did not = have an href and only properties, that would work. It needs to be concise, = though. =20 Paul =20 From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20 Sent: Friday, March 22, 2013 4:59 AM To: Dave Cridland; Paul E. Jones Cc: webfinger@ietf.org; Stephane Bortzmeyer Subject: R: [webfinger] Email autoconfiguration (Was: [apps-discuss] = AppsDir Review of draft-ietf-appsawg-webfinger-11 =20 Hi all, =20 Autoconfiguration in general is a useful use case of webfinger and it = would make sense to me to call it out explicitly. I could try to make an = example focused on the social networking space in order not to conflict with = email provisioning, although it may contain hrefs if this can accommodate all. =20 Then if we want an example to show link rels with properties and no href could we move this to the fictitious tipsi example adding another link = rel with only properties (e.g. printer capabilities such as front-retro, a3 format, color, etc) ? =20 walter =20 Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per = conto di Dave Cridland Inviato: venerd=EC 22 marzo 2013 9.34 A: Paul E. Jones Cc: webfinger@ietf.org; Stephane Bortzmeyer Oggetto: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 =20 On 22 Mar 2013 02:05, "Paul E. Jones" wrote: > I=92m not interested to demonstrate that WF can be used for auto-provisioning. Rather, I am interested to demonstrate use of =93properties=94 in a =93link relation object=94 that has no =93href=94 = member. Basically, this is example has information that is entirely = self-contained in the JRD and not dependent on an external link. > > =20 Great, so find an example that demonstrates that. > > You suggest I make up a service to auto-provision. So, it concerns = you only that I have an example with IMAP or does it concern you that the example is an auto-provisioning example? I=92m a little confused. My concern is that you have an example which overlaps an area of standardization. I'd hate people to implement this instead of whatever aggsrv comes up with. Replace mail with blurdybloop and I'll be happy. Dave. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. = Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati = di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the = intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=20 rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non = =E8 necessario.=20 =20 ------=_NextPart_001_01E8_01CE26E6.B154C7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If it’s only a matter of email provisioning and any other kind = of auto-provisioning is OK, then I could insert an example of = provisioning an H.323 terminal.

 

If you have a good example for social networking that does not = require an href, that would be good.=A0 Even if it was just one link = that did not have an href and only properties, that would work.=A0 It = needs to be concise, though.

 

Paul

 

From:= = Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] =
Sent: Friday, March 22, 2013 4:59 AM
To: Dave = Cridland; Paul E. Jones
Cc: webfinger@ietf.org; Stephane = Bortzmeyer
Subject: R: [webfinger] Email autoconfiguration = (Was: [apps-discuss] AppsDir Review of = draft-ietf-appsawg-webfinger-11

 

Hi all,

 

Autoconfiguration in general is a useful use case of webfinger and it = would make sense to me to call it out explicitly. I could try to make an = example focused on the social networking space in order not to conflict = with email provisioning, although it may contain hrefs if this can = accommodate all.

 

Then if we want an example to show link rels with properties and no = href could we move this to the fictitious tipsi example adding another = link rel with only properties (e.g. printer capabilities such as = front-retro, a3 format, color, etc) ?

 

walter

 

Da: webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.= org] Per conto di Dave Cridland
Inviato: venerd=EC = 22 marzo 2013 9.34
A: Paul E. Jones
Cc: webfinger@ietf.org; Stephane = Bortzmeyer
Oggetto: Re: [webfinger] Email autoconfiguration = (Was: [apps-discuss] AppsDir Review of = draft-ietf-appsawg-webfinger-11

 


On 22 Mar 2013 02:05, "Paul E. Jones" <paulej@packetizer.com> = wrote:
> I’m not interested to demonstrate that WF can be = used for auto-provisioning.  Rather, I am interested to demonstrate = use of “properties” in a “link relation object” = that has no “href” member.  Basically, this is example = has information that is entirely self-contained in the JRD and not = dependent on an external link.
>
> =  

Great, so find an example = that demonstrates that.

>
> You suggest I make up a service to = auto-provision.  So, it concerns you only that I have an example = with IMAP or does it concern you that the example is an = auto-provisioning example?  I’m a little = confused.

My concern is that you = have an example which overlaps an area of standardization. I'd hate = people to implement this instead of whatever aggsrv comes up = with.

Replace mail with = blurdybloop and I'll be happy.

Dave.

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. =

= This e-mail and any attachments=  is = confidential and may contain privileged information intended for the = addressee(s) only. Dissemination, copying, printing or use by anybody = else is unauthorised. If you are not the intended recipient, please = delete this message and any attachments and advise the sender by return = e-mail, Thanks.

= 3D"rispettaRispetta l'ambiente. Non stampare questa mail se non =E8 = necessario.=

 

------=_NextPart_001_01E8_01CE26E6.B154C7A0-- ------=_NextPart_000_01E7_01CE26E6.B154C7A0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------=_NextPart_000_01E7_01CE26E6.B154C7A0-- From dave@cridland.net Fri Mar 22 07:25:27 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB2B21F8775 for ; Fri, 22 Mar 2013 07:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioulyLzEKISZ for ; Fri, 22 Mar 2013 07:25:27 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id F079921F85BC for ; Fri, 22 Mar 2013 07:25:26 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id wo10so1707597obc.25 for ; Fri, 22 Mar 2013 07:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kmEWL+AbqfV9UcSGofW3rA12SATSv39ZDKwOW8FUsNM=; b=JAdTRtrA+TGzar2i+f3XFxSvyJFk3LbeC/uvvSoP1OdQgQNHpyFsXYDY9n+oPlaeMn JemmhjqHk1u/PJ74jzq4ILFEKnFW2dTb5K4BssJDRlYzLn2ZLljJjU70rQSh0nEXEkXu CMlepnA2XZvpIi4/DlD3hS+5zjIxc6sSOLOGo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=kmEWL+AbqfV9UcSGofW3rA12SATSv39ZDKwOW8FUsNM=; b=LuLcqSWlfb7vgbV5zDINeua4DVb7AXpZVL8BmQminUwkSc5FXLXcTxop+s0ixmzlBL /ghTRWgL+kZZjV0n3udbnFYoB2qTN350oct0tsQmnQphxnzPnsSx6OLyvahM67XMbCHN ShxwkvLFnLZwaeJXU0/MWoCd6yf8eeVEuMDa4LaxX0ZnLA8dJ/2lBXaP+84v3abXeagU AmJRe3qy4wC3+8hq8T/+R2dRYWyASgzhScUetsZI9U71d/SZMw3agRTGQUkGsUVHWuYZ TB93H8u/KNqqDIUcMwKfe1/nJvUxi/sVvjWu+gB5cTWyxSdF0IMroaxuy4z1u/HzCmoJ I4WA== MIME-Version: 1.0 X-Received: by 10.60.3.233 with SMTP id f9mr1999389oef.32.1363962326352; Fri, 22 Mar 2013 07:25:26 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Fri, 22 Mar 2013 07:25:26 -0700 (PDT) In-Reply-To: <01bd01ce2706$dec829f0$9c587dd0$@packetizer.com> References: <20130315151027.GB28881@laperouse.bortzmeyer.org> <056c01ce25df$d4cf1940$7e6d4bc0$@packetizer.com> <010201ce26a1$c30e5690$492b03b0$@packetizer.com> <01bd01ce2706$dec829f0$9c587dd0$@packetizer.com> Date: Fri, 22 Mar 2013 14:25:26 +0000 Message-ID: From: Dave Cridland To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8ff242abf36c1204d8843931 X-Gm-Message-State: ALoCoQlCuXhVe7U8dTja94auO7FvBBU5RrxpAIhua7e6mZZmx+fwlfF1QJgpYEC0VuL6cSGweVDU Cc: webfinger@ietf.org, Stephane Bortzmeyer Subject: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 14:25:27 -0000 --e89a8ff242abf36c1204d8843931 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2013 at 2:09 PM, Paul E. Jones wrote= : > So, the real concern is that it overlaps with aggsrv? I=92ll note we > discussed this long before aggsrv, though it wasn=92t until November that > such an example was inserted because I was hoping Cyrus would produce an > example. He produced something that more-or-less replicates much of > WebFinger. > > This paragraph reads like your intention is to provide a proposal for AggSrv. I do hope that's not the case. > Now, with Section 3.3, I have something more concrete I can point to. Yo= u > read it and understood it. You rightfully pointed out that it looks > plausible. That=92s the whole point and I wish I had something equally a= s > good for Section 3.4. Still, though it looks plausible, it=92s not > implementable since none of the values (link relation type of properties) > are standard. I=92d say the example works. > > > It works as a strawman proposal for email autoconfiguration, but not as an example for a specification on something else. Dave. --e89a8ff242abf36c1204d8843931 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 22, 2013 at 2:09 PM, Paul E. Jones <pau= lej@packetizer.com> wrote:

So, the real concern is that it overl= aps with aggsrv?=A0 I=92ll note we discussed this long before aggsrv, thoug= h it wasn=92t until November that such an example was inserted because I wa= s hoping Cyrus would produce an example.=A0 He produced something that more= -or-less replicates much of WebFinger.


<= /div>
This paragraph reads like your intention is to provide a pr= oposal for AggSrv. I do hope that's not the case.
=A0

Now, with Section 3.3, = I have something more concrete I can point to.=A0 You read it and understoo= d it.=A0 You rightfully pointed out that it looks plausible.=A0 That=92s th= e whole point and I wish I had something equally as good for Section 3.4.= =A0 Still, though it looks plausible, it=92s not implementable since none o= f the values (link relation type of properties) are standard.=A0 I=92d say = the example works.



It works as a strawman proposal for email autoconfiguration, but not a= s an example for a specification on something else.
Dave.
--e89a8ff242abf36c1204d8843931-- From paulej@packetizer.com Fri Mar 22 08:16:32 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072B921F8F01; Fri, 22 Mar 2013 08:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3z2TTbgirUs; Fri, 22 Mar 2013 08:16:26 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id ECD0321F8EF1; Fri, 22 Mar 2013 08:16:25 -0700 (PDT) Received: from [192.168.1.19] (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 r2MFGNi3015976 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 11:16:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363965384; bh=7a83uDr5EDTG9Kf9emd+v/AFsvvVP7O6azmaWPqeoc8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=skaBayv5WATam/Uy5VKln3LoiQqaUCtbkgc9aeq9ScDMzokNeJ/QX8J3E8HVrKiBp Pr2UwBUNpUspwkw9px4SIYi0DEm0LQ34mSYkkXN7cE/FP6qJ9G/4TkdU7ViZsXBL91 plB0+xRxstjQs9z2I1J9Kk0ybX3JGwKXAuJ+go8o= Message-ID: <514C75C2.8050004@packetizer.com> Date: Fri, 22 Mar 2013 11:16:18 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Dave Cridland References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000203060508040002010601" Cc: webfinger@ietf.org, iesg@ietf.org, "apps-discuss@ietf.org" , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:16:32 -0000 This is a multi-part message in MIME format. --------------000203060508040002010601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dave, On 3/22/2013 5:32 AM, Dave Cridland wrote: > > > > So, you are OK with the restriction? > > > > Restricting it to a single link relation type (as defined by RFC 5988, > and the ABNF production therein) is perfectly fine. OK > > > > > > However, if you're changing the definition of link relation types, > then: > > > > > > a) I'm deeply concerned. Redefining a standards-track specification > > > seems worryingly close to NIH. There's horrible confusion lurking when > > > someone says "Link relation type" and then has to qualify which > > > definition. > > > > > > b) You need to make this absolutely clear in the document; it > reads like > > > you're restating, not redefining. > > > > > > c) The only distinction you claim above that appears to me to be an > > > actual distinction is that fragments are disallowed. Yet no such > > > restriction exists in the current draft. > > > > I'm still missing something. How are we changing the definition of > a link > > relation type, aside from restricting rel to having a single value > that is > > either an absolute URI or a single link relation type? > > > > So, you said, broken apart for readability: > > >>> RFC 5988 allows for multiple values like 'rel="shortcut icon"', > but WebFinger does not. > > I see that RFC 5988 allows its 'rel' parameter to hold multiple Link > Relation Types, yes. I agree that restricting this is reasonable. (I > have no view on whether it's sensible). However, that's referring to > the RFC 5988 "rel" parameter (or attribute), and absolutely not the > definition of Link Relation Type, which is always a single registered > token or an absolute URI (which itself SHOULD be lowercased). RFC 5988 says that "extension relation types are REQUIRED to be absolute URIs in Link headers". However, we cannot simply assume that "Link Headers" also means "Link Relation Objects" in WebFinger. That's why we make it clear: 'The value of the "rel" member is a string that is either an absolute URI or a registered relation type [10] (see RFC 5988 [4]).' So, I don't see an issue with that sentence. The rest of the first paragraph in the WF spec (up to the point where I'm proposing the paragraph break) would then read: "The value of the "rel" member MUST contain exactly one URI or registered relation type. The URI or registered relation type identifies the type of the link relation." Any concern with this part? > >>> RFC 5988 also allows URIs with fragments, but WebFinger does not. > > Your current draft makes no restriction on whether a Link Relation > Type may have a fragment or not. It stipulates an absolute URI, which > in RFC 3986 may have a fragment; therefore this restriction is not in > the draft as written. Neither is it in RFC 5988; however if you do > intend adding this restriction then this represents a deviation. The WF spec says link relation types MUST be either absolute URIs or registered a registered relation type. Per RFC 3986, absolute URIs do not have fragments (See Section 4.3). RFC 5988 also requires use of absolute URIs when used in Link Headers. Perhaps the intent was to always require absolute URIs? I don't know, since the text limits the statement to "Link Headers". WebFinger wants the same restriction, so we inserted an explicit statement. > >>> Valid URIs must conform to Section 4.3 of RFC 3986 (Absolute URIs). > > I'm not sure if you considered this a difference or not; as far as I > can tell RFC 5988 only allows absolute URIs (of the extended relation > types), though it explicitly calls out this requirement for the Link > header itself. Either way this seems reasonable, and not a deviation. It does, but the document is scoped for HTTP headers. We need an explicit statement for WEbFinger, since it's not HTTP headers and RFC 5988 limits the absolute URI wording to Link headers. > > > > > We had no intention of changing the definition of a link relation type, > > though we do have the stated restrictions in 4.4.4.1 > : "rel" is exactly one > > of either an absolute URI or a registered relation type. > > > > Right, which is a Link Relation Type as defined in RFC 5988. > > Either you have changed the definition (or at least, rel doesn't hold > a link relation type), in which case my opinion remains that this is a > bad thing, but in any case needs to be made abundantly clear in the > document... > > ... or you haven't, in which case I don't understand why you won't > simply reference RFC 5988 instead of referencing it piecemeal. We tried referencing RFC 5988 as much as we could. But, since that text speaks explicitly of HTTP Link Headers and places restrictions only there in the text, while the ABNF is more relaxes, we felt it was necessary to state more-or-less the same "absolute URI" requirement in WebFinger. I don't see this as a re-definition. I do think it's valuable, as it makes it clear. So, we have these two paragraphs now in that section: The value of the "rel" member is a string that is either an absolute URI or a registered relation type [10] (see RFC 5988 [4]). The value of the "rel" member MUST contain exactly one URI or registered relation type. The URI or registered relation type identifies the type of the link relation. The other members of the object have meaning only once the type of link relation is understood. In some instances, the link relation will have associated semantics enabling the client to query for other resources on the Internet. In other instances, the link relation will have associated semantics enabling the client to utilize the other members of the link relation object without fetching additional external resources. The first paragraph has to do with the "rel" values, leaning on RFC 5988, but being explicit in applying the same "absolute URI" requirement. It does add the restriction of not allowing more than one value inside "rel" (whereas RFC 5988 allow for an unlimited number). The second paragraph as WF-specific, talking about the other members of the "link relation object", which is something specific to WF. > > > > > I have no clue what the possible impacts of using webfinger on a > message > > > id URI might be, nor do I wish to even think about it. > > > > Likely a 404. > > > > I don't think whether it works is the sole consideration. > Agreed. > > > > > I'm pretty sure that mailto has some corner cases we've not yet > thought > > > about; it's not just an email address after all. > > > > On my server, that returns a JRD in the form of the example you do > not like > > so much. :-) > > > > I said corner cases. Please read RFC 6068; you appear to be labouring > under the assumption that a mailto URI is identical to an acct URI > except for the scheme. > I make no assumption. With WF, a URI of any form is just a "resource" identifier. Given that identifier, one gets back a JRD. > > > > It would be entirely reasonable to also return the same JRD as the acct: > > URI. We struggled several years with whether to use mailto or acct. > Given > > that some services do not have email (notably, Twitter), there were > a push > > for acct. That's fairly well adopted at this point, but I would not > dismiss > > the use of mailto if that is the identifier one has in hand. > > > > I don't think mailto is nearly as simple as you seem to think it is. I > don't know enough about other URI schemes to know whether other > schemes have the same problem. I'm quite familiar with mailto URIs and recognize that they're complex, or can be. > > My issue here is not a matter of the good things that might reasonably > happen from careful use of simple URIs with arbitrary schemes; my > concern is that there may be bad things with odd cases and there's no > evidence that these have been thought through. Nothing "bad" can happen. Either a WF query returns useful information or it does not. Use of any particular URI scheme will come about either through common usage or through standardization efforts. > > So for mailto, for example, I'd think you want to restrict the URI > form used to being, using RFC 6068's ABNF, '"mailto:" to', and avoid > any other forms. What I don't know - and given the way URIs can have > entertaining corner cases like this, what worries me - is not only > whether the whole thing works if you have an odd URI construct (mailto > or no), but whether it's safe. > > I think as you look deeply into various URI schemes, there'll be cans > of worms in a number of places, and the safer thing to do is to > restrict the schemes and URI forms that are - currently - allowed. > Look on the bright side, you'll have the fun of specifying what a > telnet URI should give you back from WF. URI schemes can have many forms, have parameters, etc. They range from simple to complex. However, a WF server that accepts any given URI scheme will understand that URI scheme and will return useful information. If it does not understand the scheme (or does not have information for the particular URI), it will return a 404. I strongly believe we should allow use of any URI scheme. Any complexities that arise will either be addressed through common usage or as part of a standardization effort. > > At the very least, I'd suggest that you add a security consideration What should we add? I'm not seeing any new or different security issues arising from use of any particular URI scheme. Every URI returns either a JRD or it does not. What would be different with mailto, http, sip, tel, gopher, or any other scheme? Paul --------------000203060508040002010601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dave,

On 3/22/2013 5:32 AM, Dave Cridland wrote:
>
> So, you are OK with the restriction?
>

Restricting it to a single link relation type (as defined by RFC 5988, and the <relation-type> ABNF production therein) is perfectly fine.

OK


>
> > However, if you're changing the definition of link relation types, then:
> >
> > a) I'm deeply concerned. Redefining a standards-track specification
> > seems worryingly close to NIH. There's horrible confusion lurking when
> > someone says "Link relation type" and then has to qualify which
> > definition.
> >
> > b) You need to make this absolutely clear in the document; it reads like
> > you're restating, not redefining.
> >
> > c) The only distinction you claim above that appears to me to be an
> > actual distinction is that fragments are disallowed. Yet no such
> > restriction exists in the current draft.
>
> I'm still missing something.  How are we changing the definition of a link
> relation type, aside from restricting rel to having a single value that is
> either an absolute URI or a single link relation type?
>

So, you said, broken apart for readability:

>>> RFC 5988 allows for multiple values like 'rel="shortcut icon"', but WebFinger does not.

I see that RFC 5988 allows its 'rel' parameter to hold multiple Link Relation Types, yes. I agree that restricting this is reasonable. (I have no view on whether it's sensible). However, that's referring to the RFC 5988 "rel" parameter (or attribute), and absolutely not the definition of Link Relation Type, which is always a single registered token or an absolute URI (which itself SHOULD be lowercased).

RFC 5988 says that "extension relation types are REQUIRED to be absolute URIs in Link headers".  However, we cannot simply assume that "Link Headers" also means "Link Relation Objects" in WebFinger.

That's why we make it clear:

'The value of the "rel" member is a string that is either an absolute URI or a registered relation type [10] (see RFC 5988 [4]).'

So, I don't see an issue with that sentence.  The rest of the first paragraph in the WF spec (up to the point where I'm proposing the paragraph break) would then read:

"The value of the “rel” member MUST contain exactly one URI or registered relation type.  The URI or registered relation type identifies the type of the link relation."

Any concern with this part?

>>> RFC 5988 also allows URIs with fragments, but WebFinger does not.

Your current draft makes no restriction on whether a Link Relation Type may have a fragment or not. It stipulates an absolute URI, which in RFC 3986 may have a fragment; therefore this restriction is not in the draft as written. Neither is it in RFC 5988; however if you do intend adding this restriction then this represents a deviation.

The WF spec says link relation types MUST be either absolute URIs or registered a registered relation type.  Per RFC 3986, absolute URIs do not have fragments (See Section 4.3).  RFC 5988 also requires use of absolute URIs when used in Link Headers.  Perhaps the intent was to always require absolute URIs?  I don't know, since the text limits the statement to "Link Headers".  WebFinger wants the same restriction, so we inserted an explicit statement.

>>> Valid URIs must conform to Section 4.3 of RFC 3986 (Absolute URIs).

I'm not sure if you considered this a difference or not; as far as I can tell RFC 5988 only allows absolute URIs (of the extended relation types), though it explicitly calls out this requirement for the Link header itself. Either way this seems reasonable, and not a deviation.

It does, but the document is scoped for HTTP headers.  We need an explicit statement for WEbFinger, since it's not HTTP headers and RFC 5988 limits the absolute URI wording to Link headers.

 
>
> We had no intention of changing the definition of a link relation type,
> though we do have the stated restrictions in 4.4.4.1: "rel" is exactly one
> of either an absolute URI or a registered relation type.
>

Right, which is a Link Relation Type as defined in RFC 5988.

Either you have changed the definition (or at least, rel doesn't hold a link relation type), in which case my opinion remains that this is a bad thing, but in any case needs to be made abundantly clear in the document...

... or you haven't, in which case I don't understand why you won't simply reference RFC 5988 instead of referencing it piecemeal.

We tried referencing RFC 5988 as much as we could.  But, since that text speaks explicitly of HTTP Link Headers and places restrictions only there in the text, while the ABNF is more relaxes, we felt it was necessary to state more-or-less the same "absolute URI" requirement in WebFinger.

I don't see this as a re-definition.  I do think it's valuable, as it makes it clear.

So, we have these two paragraphs now in that section:

The value of the “rel” member is a string that is either an absolute URI or a registered relation type [10] (see RFC 5988 [4]).  The value of the “rel” member MUST contain exactly one URI or registered relation type.  The URI or registered relation type identifies the type of the link relation. 

The other members of the object have meaning only once the type of link relation is understood.  In some instances, the link relation will have associated semantics enabling the client to query for other resources on the Internet.  In other instances, the link relation will have associated semantics enabling the client to utilize the other members of the link relation object without fetching additional external resources.

The first paragraph has to do with the "rel" values, leaning on RFC 5988, but being explicit in applying the same "absolute URI" requirement.  It does add the restriction of not allowing more than one value inside "rel" (whereas RFC 5988 allow for an unlimited number).  The second paragraph as WF-specific, talking about the other members of the "link relation object", which is something specific to WF.

>
> > I have no clue what the possible impacts of using webfinger on a message
> > id URI might be, nor do I wish to even think about it.
>
> Likely a 404.
>

I don't think whether it works is the sole consideration.
 

Agreed.

>
> > I'm pretty sure that mailto has some corner cases we've not yet thought
> > about; it's not just an email address after all.
>
> On my server, that returns a JRD in the form of the example you do not like
> so much. :-)
>

I said corner cases. Please read RFC 6068; you appear to be labouring under the assumption that a mailto URI is identical to an acct URI except for the scheme.
 

I make no assumption.  With WF, a URI of any form is just a "resource" identifier.  Given that identifier, one gets back a JRD.

>
> It would be entirely reasonable to also return the same JRD as the acct:
> URI.  We struggled several years with whether to use mailto or acct.  Given
> that some services do not have email (notably, Twitter), there were a push
> for acct.  That's fairly well adopted at this point, but I would not dismiss
> the use of mailto if that is the identifier one has in hand.
>

I don't think mailto is nearly as simple as you seem to think it is. I don't know enough about other URI schemes to know whether other schemes have the same problem.

I'm quite familiar with mailto URIs and recognize that they're complex, or can be.


My issue here is not a matter of the good things that might reasonably happen from careful use of simple URIs with arbitrary schemes; my concern is that there may be bad things with odd cases and there's no evidence that these have been thought through.

Nothing "bad" can happen.  Either a WF query returns useful information or it does not.  Use of any particular URI scheme will come about either through common usage or through standardization efforts.


So for mailto, for example, I'd think you want to restrict the URI form used to being, using RFC 6068's ABNF, '"mailto:" to', and avoid any other forms. What I don't know - and given the way URIs can have entertaining corner cases like this, what worries me - is not only whether the whole thing works if you have an odd URI construct (mailto or no), but whether it's safe.

I think as you look deeply into various URI schemes, there'll be cans of worms in a number of places, and the safer thing to do is to restrict the schemes and URI forms that are - currently - allowed. Look on the bright side, you'll have the fun of specifying what a telnet URI should give you back from WF.

URI schemes can have many forms, have parameters, etc.  They range from simple to complex.  However, a WF server that accepts any given URI scheme will understand that URI scheme and will return useful information.  If it does not understand the scheme (or does not have information for the particular URI), it will return a 404.

I strongly believe we should allow use of any URI scheme.  Any complexities that arise will either be addressed through common usage or as part of a standardization effort.


At the very least, I'd suggest that you add a security consideration

What should we add?  I'm not seeing any new or different security issues arising from use of any particular URI scheme.  Every URI returns either a JRD or it does not.  What would be different with mailto, http, sip, tel, gopher, or any other scheme?

Paul

--------------000203060508040002010601-- From paulej@packetizer.com Fri Mar 22 08:25:51 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727A821F8D3C for ; Fri, 22 Mar 2013 08:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D14o+k5yP4qQ for ; Fri, 22 Mar 2013 08:25:50 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2452D21F8D79 for ; Fri, 22 Mar 2013 08:25:50 -0700 (PDT) Received: from [192.168.1.19] (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 r2MFPkcD016479 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 11:25:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363965947; bh=WgfOVstAdGYmA4Ktcz6quT5SoApsdAooWyhJWh1L9QM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=g5WPMDul2IrrpeWgkX7faYSloLCHp/fcIloWl7ipD89O0nYmNLwu4C3MfZ511eHSK xkZypj17QnrIHB8nsqriYq9ELIHDKN8F27I0oVz4D8aGjZh5Jq67pu1SPWfXcx1/rA ohvB3LT1bQlznV5eZc0z63iUmXrrzxsyOp06YK5U= Message-ID: <514C77FB.3090600@packetizer.com> Date: Fri, 22 Mar 2013 11:25:47 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Dave Cridland References: <20130315151027.GB28881@laperouse.bortzmeyer.org> <056c01ce25df$d4cf1940$7e6d4bc0$@packetizer.com> <010201ce26a1$c30e5690$492b03b0$@packetizer.com> <01bd01ce2706$dec829f0$9c587dd0$@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090804070906080504010801" Cc: webfinger@ietf.org, Stephane Bortzmeyer Subject: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:25:51 -0000 This is a multi-part message in MIME format. --------------090804070906080504010801 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 3/22/2013 10:25 AM, Dave Cridland wrote: > On Fri, Mar 22, 2013 at 2:09 PM, Paul E. Jones > wrote: > > So, the real concern is that it overlaps with aggsrv? Ill note we > discussed this long before aggsrv, though it wasnt until November > that such an example was inserted because I was hoping Cyrus would > produce an example. He produced something that more-or-less > replicates much of WebFinger. > > > This paragraph reads like your intention is to provide a proposal for > AggSrv. I do hope that's not the case. No, I provided my proposal at the BoF. For those who did not see it, here are the slides: http://www.ietf.org/proceedings/86/slides/slides-86-aggsrv-3.pdf I believe WF could be used as a means of acquiring the service information, which could either be aggregated by a service provider or IT department (a bit of a pain, IMO) or aggregated by the client (work on the client, but allows for direct access to third-party service configuration documents.) But, this is off topic :-) > Now, with Section 3.3, I have something more concrete I can point > to. You read it and understood it. You rightfully pointed out > that it looks plausible. Thats the whole point and I wish I had > something equally as good for Section 3.4. Still, though it looks > plausible, its not implementable since none of the values (link > relation type of properties) are standard. Id say the example works. > > > It works as a strawman proposal for email autoconfiguration, but not > as an example for a specification on something else. > It wasn't intended to be a proposal, but just a clear example. Perhaps Walter or someone can come up with a replacement that is equally clear. However, I'd prefer to keep it and would not be opposed to adding a statement that made it abundantly clear that the example does not represent any agreed means of provisioning an email client as there are (or will be) other standards to accomplish that task. Would you like to suggest such wording or do you still insist we replace the example? And will we have someone else objecting to that example? :-( Paul --------------090804070906080504010801 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 3/22/2013 10:25 AM, Dave Cridland wrote:
On Fri, Mar 22, 2013 at 2:09 PM, Paul E. Jones <paulej@packetizer.com> wrote:

So, the real concern is that it overlaps with aggsrv? Ill note we discussed this long before aggsrv, though it wasnt until November that such an example was inserted because I was hoping Cyrus would produce an example. He produced something that more-or-less replicates much of WebFinger.


This paragraph reads like your intention is to provide a proposal for AggSrv. I do hope that's not the case.

No, I provided my proposal at the BoF. For those who did not see it, here are the slides:
http://www.ietf.org/proceedings/86/slides/slides-86-aggsrv-3.pdf

I believe WF could be used as a means of acquiring the service information, which could either be aggregated by a service provider or IT department (a bit of a pain, IMO) or aggregated by the client (work on the client, but allows for direct access to third-party service configuration documents.)

But, this is off topic :-)

Now, with Section 3.3, I have something more concrete I can point to. You read it and understood it. You rightfully pointed out that it looks plausible. Thats the whole point and I wish I had something equally as good for Section 3.4. Still, though it looks plausible, its not implementable since none of the values (link relation type of properties) are standard. Id say the example works.


It works as a strawman proposal for email autoconfiguration, but not as an example for a specification on something else.


It wasn't intended to be a proposal, but just a clear example. Perhaps Walter or someone can come up with a replacement that is equally clear.

However, I'd prefer to keep it and would not be opposed to adding a statement that made it abundantly clear that the example does not represent any agreed means of provisioning an email client as there are (or will be) other standards to accomplish that task.

Would you like to suggest such wording or do you still insist we replace the example? And will we have someone else objecting to that example? :-(

Paul

--------------090804070906080504010801-- From dave@cridland.net Fri Mar 22 09:53:37 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F281E21F8C7D for ; Fri, 22 Mar 2013 09:53:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSHqAWYlY-km for ; Fri, 22 Mar 2013 09:53:35 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id B097A21F87D9 for ; Fri, 22 Mar 2013 09:53:35 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o6so4614277oag.32 for ; Fri, 22 Mar 2013 09:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=M1KVtgfd7bkCUJOiKzNcsVOKNz+0LIb8nz5Ad4cyHuA=; b=P5QapScq/PlI3VZVayp2i2lPrQtvy/vgFLaedVYgQEk1tWjOejznQxFXgb3BVATBqj Rrk3TjxKOBRh5DVrwc+jRAbg3DHtwUHVfPfubf+LMpfDPdnUZ1jjMfs6reL1jorIY9LU 5BkRqK5dX4P3H4L3caHQu2mT4kjkMi51gW0qU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=M1KVtgfd7bkCUJOiKzNcsVOKNz+0LIb8nz5Ad4cyHuA=; b=dg5p7Et0wWZ7TWZt76Zgo99cfE9cNq0dWs6it6tqc+VkBEPxOFrndBoH/clnLnr+WO vE+j1altOPlt3Qa1/zYMSTOCvNwvfVj0nOD8ABuAo8uGMMKCCVeme+vDBmKtHDyU/DEn 1ZJhvxO0JdioLMAvdJAAHtfRB5hRcyeQQkn+ryMfi7nMydlvaYdyygAr+1ogqoDjGsa8 95O2TpmF3GxsVa9qptDmmAjwW553t/8p9jbu2jbATQbr3R62QslhSdES0LouN6pJYQNc cSBPz3YZ8e8khVnb1Vgx4l9DLrphC44WmAWJufwkjPlKIPveQq1twbHbP8JpsL/EBuLW q/+A== MIME-Version: 1.0 X-Received: by 10.60.26.231 with SMTP id o7mr2511039oeg.107.1363971215239; Fri, 22 Mar 2013 09:53:35 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Fri, 22 Mar 2013 09:53:35 -0700 (PDT) In-Reply-To: <514C75C2.8050004@packetizer.com> References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> <514C75C2.8050004@packetizer.com> Date: Fri, 22 Mar 2013 16:53:35 +0000 Message-ID: From: Dave Cridland To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f4c4c4c60e04d8864b06 X-Gm-Message-State: ALoCoQkHtu9TelB7XHmle2rR9XlXJRJ+xpWtH1g1aDO1vp/TVOcPNvR2Wx2F73pgCEtow/VfQv74 Cc: webfinger@ietf.org, iesg@ietf.org, "apps-discuss@ietf.org" , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:53:37 -0000 --e89a8fb1f4c4c4c60e04d8864b06 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 22, 2013 at 3:16 PM, Paul E. Jones wrote: > Dave, > > > On 3/22/2013 5:32 AM, Dave Cridland wrote: > > >>> RFC 5988 also allows URIs with fragments, but WebFinger does not. > > Your current draft makes no restriction on whether a Link Relation Type > may have a fragment or not. It stipulates an absolute URI, which in RFC > 3986 may have a fragment; therefore this restriction is not in the draft as > written. Neither is it in RFC 5988; however if you do intend adding this > restriction then this represents a deviation. > > > The WF spec says link relation types MUST be either absolute URIs or > registered a registered relation type. Per RFC 3986, absolute URIs do not > have fragments (See Section 4.3). RFC 5988 also requires use of absolute > URIs when used in Link Headers. Perhaps the intent was to always require > absolute URIs? I don't know, since the text limits the statement to "Link > Headers". WebFinger wants the same restriction, so we inserted an explicit > statement. > > Ah, there's my error, then - I'd made the mistake of assuming "absolute" meant the same as "not relative". I still think that first sentence might be reworded, but it's good enough as is. > My issue here is not a matter of the good things that might reasonably > happen from careful use of simple URIs with arbitrary schemes; my concern > is that there may be bad things with odd cases and there's no evidence that > these have been thought through. > > > Nothing "bad" can happen. > Oh, well that's OK, then. :-) > At the very least, I'd suggest that you add a security consideration > > > What should we add? I'm not seeing any new or different security issues > arising from use of any particular URI scheme. Every URI returns either a > JRD or it does not. What would be different with mailto, http, sip, tel, > gopher, or any other scheme? > sip, simple mailto, acct, xmpp, and so on - those URIs which refer explicitly to an individual - are, I think, adequately considered in the specification. http seems to be considered only when referring to a person. However, in general http resources can have links anyway, so I'm not concerned about these - however I'm not sure that the fragment identifier needs to be sent. I'm entirely willing to believe you've considered these considerably more than that, however there's no evidence of it in the specification as written. I've spent very little time considering what might happen (beyond a 404) with arbitrary URI schemes. Should a client ever send a file: URI, for example? I'm not concerned with what information in the JRD it might be expecting, or whether or not the WF server understands it, but what information transfer has occurred and whether this is safe and can reasonably be expected to be interoperable. For example, I'd expect a sensible WF client to only ever send a simple mailto:local-part@domain URI to a server, and if the initial input was one of the deliciously complex forms, to strip away the header fields and body and extract (if needed) the To field value. I have no clue what a WF server might usefully do with a subject line, mind, whether it's malicious or not - I just think it doesn't need to have it. I'd suggest simply stating that the security considerations and protocol are scoped to consider only URIs identifying an individual entity, (perhaps give some simple examples), and that use beyond that may involve further security considerations. Then everyone's happy. Dave. --e89a8fb1f4c4c4c60e04d8864b06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 22, 2013 at 3:16 PM, Paul E. Jones <pau= lej@packetizer.com> wrote:
=20 =20 =20
Dave,


On 3/22/2013 5:32 AM, Dave Cridland wrote:

>>> RFC 5988 also allows URIs with fragments, but WebFinger does not.

Your current draft makes no restriction on whether a Link Relation Type may have a fragment or not. It stipulates an absolute URI, which in RFC 3986 may have a fragment; therefore this restriction is not in the draft as written. Neither is it in RFC 5988; however if you do intend adding this restriction then this represents a deviation.

The WF spec says link relation types MUST be either absolute URIs or registered a registered relation type.=A0 Per RFC 3986, absolute URIs do not have fragments (See Section 4.3).=A0 RFC 5988 also requires use of absolute URIs when used in Link Headers.=A0 Perhaps the intent was to always require absolute URIs?=A0 I don't know, since the text limits the statement to "Link Headers".=A0 WebFinger wants th= e same restriction, so we inserted an explicit statement.

Ah, there's my erro= r, then - I'd made the mistake of assuming "absolute" meant t= he same as "not relative".

I still think that first sentence might be = reworded, but it's good enough as is.
My issue here is not a matter of the good thing= s that might reasonably happen from careful use of simple URIs with arbitrary schemes; my concern is that there may be bad things with odd cases and there's no evidence that these have been thought through.

Nothing "bad" can happen.=A0

Oh, well that's OK, then. :-)
At the very least, I'd suggest that you add= a security consideration

What should we add?=A0 I'm not seeing any new or different security issues arising from use of any particular URI scheme.=A0 Every URI returns either a JRD or it does not.=A0 What would be different with mailto, http, sip, tel, gopher, or any other scheme?
=

sip, simple mailto, acct, xmpp, and so on - those= URIs which refer explicitly to an individual - are, I think, adequately co= nsidered in the specification.

http seems to be considered only when refer= ring to a person. However, in general http resources can have links anyway,= so I'm not concerned about these - however I'm not sure that the f= ragment identifier needs to be sent.

I'm entirely willing to believe you'= ;ve considered these considerably more than that, however there's no ev= idence of it in the specification as written.

I've spent very little time considering what might happen (b= eyond a 404) with arbitrary URI schemes. Should a client ever send a file: = URI, for example? I'm not concerned with what information in the JRD it= might be expecting, or whether or not the WF server understands it, but wh= at information transfer has occurred and whether this is safe and can reaso= nably be expected to be interoperable.

For example, I'd expect a sensible WF c= lient to only ever send a simple mailto:local-part@domain URI to a server, and if the initial input was one o= f the deliciously complex forms, to strip away the header fields and body a= nd extract (if needed) the To field value. I have no clue what a WF server = might usefully do with a subject line, mind, whether it's malicious or = not - I just think it doesn't need to have it.

I'd suggest simply stating that the sec= urity considerations and protocol are scoped to consider only URIs identify= ing an individual entity, (perhaps give some simple examples), and that use= beyond that may involve further security considerations. Then everyone'= ;s happy.

Dave.
--e89a8fb1f4c4c4c60e04d8864b06-- From dave@cridland.net Fri Mar 22 10:17:04 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D1221F8F9F for ; Fri, 22 Mar 2013 10:17:04 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYw3-ueNPsfD for ; Fri, 22 Mar 2013 10:17:03 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7954421F8804 for ; Fri, 22 Mar 2013 10:17:03 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id er7so676726obc.7 for ; Fri, 22 Mar 2013 10:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0AThCesWYvXgRiE5GIK9y8EF0EU6WBTOAG1om3EQdWI=; b=KMJtYY26e59ftEayvegYmsAQWFZyEBiRzFuxiZvCktPguXWCAkdYAnrcR1fDWLpFZb Y2N9XN0pbeWDKMabEXrE6/oIjf7VbaKxqLd3wSDqmih2OAnCo6XYQZuLFdE80PMXlCO1 4HcL9Jh9I4MgDHm4QNc0r0qHJUpf2xJC9KXUg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=0AThCesWYvXgRiE5GIK9y8EF0EU6WBTOAG1om3EQdWI=; b=LNqIF1tQ0G5pK5XybCd71IqlmW/jwcNPBnF0jg8AFxsOIElEabJqIcqh9nug3ovoWg pB9thKxzM4EcfR+lFvFrpi4rVipyTvNQrpEosHU/Zt1LhZgYcQ0J6oYgw1WSkAriM5g5 npveCMOtGUxEmp6CuTm/Xo6sybPRoWP+1efni+tqxvELoyyJfTrhahs/0OV9wmVOaWUp yTtWPo5tDErxHHdu0kMmNiW4miKOln4VqJRyXjaog9/FArhKpkA4ebtsBD8GukePiKqk 9g0yqk+gNXhqfQKLRhMx/5dptbClL/iJOB/GStUyVm0xOB0JiAP5iLLDOoz/129ooPSW eHhw== MIME-Version: 1.0 X-Received: by 10.60.29.72 with SMTP id i8mr2564970oeh.93.1363972622681; Fri, 22 Mar 2013 10:17:02 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Fri, 22 Mar 2013 10:17:02 -0700 (PDT) In-Reply-To: <514C77FB.3090600@packetizer.com> References: <20130315151027.GB28881@laperouse.bortzmeyer.org> <056c01ce25df$d4cf1940$7e6d4bc0$@packetizer.com> <010201ce26a1$c30e5690$492b03b0$@packetizer.com> <01bd01ce2706$dec829f0$9c587dd0$@packetizer.com> <514C77FB.3090600@packetizer.com> Date: Fri, 22 Mar 2013 17:17:02 +0000 Message-ID: From: Dave Cridland To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f806a8eb2c04d8869fa4 X-Gm-Message-State: ALoCoQkWqhbSh1hANt6OBib5okzGaxX66CBlAoNHFTE/xB92bXG8g9OfvgRUahA3XwPHJ6hipVPD Cc: webfinger@ietf.org, Stephane Bortzmeyer Subject: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:17:04 -0000 --e89a8fb1f806a8eb2c04d8869fa4 Content-Type: text/plain; charset=ISO-8859-1 The problem with concrete examples is that people expect them to be concrete, rather than examples. My concerns remain with this example, but I'll leave it to your decision. --e89a8fb1f806a8eb2c04d8869fa4 Content-Type: text/html; charset=ISO-8859-1
The problem with concrete examples is that people expect them to be concrete, rather than examples.

My concerns remain with this example, but I'll leave it to your decision.
--e89a8fb1f806a8eb2c04d8869fa4-- From paulej@packetizer.com Sat Mar 23 12:04:50 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CB521F8D7A; Sat, 23 Mar 2013 12:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpgLZfvoyYDj; Sat, 23 Mar 2013 12:04:47 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 906B421F8D32; Sat, 23 Mar 2013 12:04:47 -0700 (PDT) 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 r2NJ4jAO010965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Mar 2013 15:04:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1364065486; bh=mPYXxI4vF8qEzw0JOTB3ohLPa7BUQe2Q8XhxByoN1FY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=qmBDzbnUS2OnGo4MzvzZPlwnU6QvkNNgTitPfnckiFGgYJx92tnhYnGcCApcvvQ+5 vPZgUgMHbvVHNviOYGAijWhfH79Nu+AxNdOoeOcBTDFjM3UJwMUvfdl3jb9yhE0r/L K+B228H+VUYgGU+2rW/r8m00j3RRqoNMr6CjL6Z4= From: "Paul E. Jones" To: "'Dave Cridland'" References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> <514C75C2.8050004@packetizer.com> In-Reply-To: Date: Sat, 23 Mar 2013 15:05:08 -0400 Message-ID: <03b401ce27f9$5668c5d0$033a5170$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B5_01CE27D7.CF57E920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6xtTU7bBnElLUOVycpt5dUnTbtQEse7f/Af/Bk0cCFB98AAKS9xmXAYAzFy4B85JRI5eAJN1Q Content-Language: en-us Cc: webfinger@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] AppsDir Review of draft-ietf-appsawg-webfinger-11 X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 19:04:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03B5_01CE27D7.CF57E920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dave, An "http" URI could be used to query information about a web page. It might return "copyright" or "author" or other defined link relation values. Had WF existed when OpenID 2.0 was drafted, it could have been used to resolve the OpenID Provider information for a given OpenID identifier. WebFinger might be used to find other information about things on the Internet, including printer, refrigerators, thermostats, or whatever. What one would or should expect for various URI schemes is not fully-defined, except that any URI will return a JRD document with links. How those links are interpreted will be defined by whatever document defines the link relation types or some document such as "Discovering Information about X using WebFinger" (where "X" might be a printer, thermostat, or whatever). So, it's not accurate to say the document is scoped to return information only about individuals. We put most of the emphasis there, because that has the most immediate practical use and we expect the 'acct' URI type to be used primarily. Paul What should we add? I'm not seeing any new or different security issues arising from use of any particular URI scheme. Every URI returns either a JRD or it does not. What would be different with mailto, http, sip, tel, gopher, or any other scheme? sip, simple mailto, acct, xmpp, and so on - those URIs which refer explicitly to an individual - are, I think, adequately considered in the specification. http seems to be considered only when referring to a person. However, in general http resources can have links anyway, so I'm not concerned about these - however I'm not sure that the fragment identifier needs to be sent. I'm entirely willing to believe you've considered these considerably more than that, however there's no evidence of it in the specification as written. I've spent very little time considering what might happen (beyond a 404) with arbitrary URI schemes. Should a client ever send a file: URI, for example? I'm not concerned with what information in the JRD it might be expecting, or whether or not the WF server understands it, but what information transfer has occurred and whether this is safe and can reasonably be expected to be interoperable. For example, I'd expect a sensible WF client to only ever send a simple mailto:local-part@domain URI to a server, and if the initial input was one of the deliciously complex forms, to strip away the header fields and body and extract (if needed) the To field value. I have no clue what a WF server might usefully do with a subject line, mind, whether it's malicious or not - I just think it doesn't need to have it. I'd suggest simply stating that the security considerations and protocol are scoped to consider only URIs identifying an individual entity, (perhaps give some simple examples), and that use beyond that may involve further security considerations. Then everyone's happy. Dave. ------=_NextPart_000_03B5_01CE27D7.CF57E920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 

An “http” URI could be used to query information about a = web page.  It might return “copyright” or = “author” or other defined link relation values.  Had WF = existed when OpenID 2.0 was drafted, it could have been used to resolve = the OpenID Provider information for a given OpenID identifier.  = WebFinger might be used to find other information about things on the = Internet, including printer, refrigerators, thermostats, or = whatever.  What one would or should expect for various URI schemes = is not fully-defined, except that any URI will return a JRD document = with links.  How those links are interpreted will be defined by = whatever document defines the link relation types or some document such = as “Discovering Information about X using WebFinger” (where = “X” might be a printer, thermostat, or = whatever).

 

So, it’s not accurate to say the document is scoped to return = information only about individuals.  We put most of the emphasis = there, because that has the most immediate practical use and we expect = the ‘acct’ URI type to be used = primarily.

 

Paul

 

 

What = should we add?  I'm not seeing any new or different security issues = arising from use of any particular URI scheme.  Every URI returns = either a JRD or it does not.  What would be different with mailto, = http, sip, tel, gopher, or any other = scheme?

 

sip, simple mailto, acct, xmpp, and so on - those URIs = which refer explicitly to an individual - are, I think, adequately = considered in the specification.

 

http seems to be considered only when referring to a = person. However, in general http resources can have links anyway, so I'm = not concerned about these - however I'm not sure that the fragment = identifier needs to be sent.

 

I'm entirely willing to believe you've considered = these considerably more than that, however there's no evidence of it in = the specification as written.

 

I've spent very little time considering what might = happen (beyond a 404) with arbitrary URI schemes. Should a client ever = send a file: URI, for example? I'm not concerned with what information = in the JRD it might be expecting, or whether or not the WF server = understands it, but what information transfer has occurred and whether = this is safe and can reasonably be expected to be = interoperable.

 

For example, I'd expect a sensible WF client to only = ever send a simple mailto:local-part@domain URI to a server, = and if the initial input was one of the deliciously complex forms, to = strip away the header fields and body and extract (if needed) the To = field value. I have no clue what a WF server might usefully do with a = subject line, mind, whether it's malicious or not - I just think it = doesn't need to have it.

 

I'd suggest simply stating that the security = considerations and protocol are scoped to consider only URIs identifying = an individual entity, (perhaps give some simple examples), and that use = beyond that may involve further security considerations. Then everyone's = happy.

 

Dave.

------=_NextPart_000_03B5_01CE27D7.CF57E920-- From acooper@cdt.org Thu Mar 21 06:44:36 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEB221F8F1E; Thu, 21 Mar 2013 06:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77sdWnP3FrFc; Thu, 21 Mar 2013 06:44:35 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8121F8F0B; Thu, 21 Mar 2013 06:44:34 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 21 Mar 2013 09:44:32 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Alissa Cooper In-Reply-To: <055401ce25d3$5566f120$0034d360$@packetizer.com> Date: Thu, 21 Mar 2013 09:44:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E7B73F6-808B-4D8B-BE42-73A56C475C06@cdt.org> References: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> <055401ce25d3$5566f120$0034d360$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Sun, 24 Mar 2013 11:26:49 -0700 Cc: webfinger@ietf.org, ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [webfinger] [apps-discuss] Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:44:36 -0000 I suggest adding the sentence without the word "implicitly." The result = would be: "Further, WebFinger MUST NOT be used to provide any personal information = to any party unless explicitly authorized by the person whose = information is being shared. Publishing one's personal data within an = access-controlled or otherwise limited environment on the Internet does = not equate to providing authorization of further publication of that = data via WebFinger." Thanks, Alissa On Mar 20, 2013, at 9:28 PM, Paul E. Jones = wrote: > Alissa, >=20 > It was suggested that we remove the word "implicit". I'm OK with = removing > it. If we did that, would you want to add this new sentence or a = modified > version of it? >=20 > Paul >=20 >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Alissa Cooper >> Sent: Monday, March 18, 2013 11:31 AM >> To: ietf@ietf.org >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Last Call: > 10.txt> (WebFinger) to Proposed Standard >>=20 >> Given how little control Internet users already have over which >> information about them appears in which context, I do not have a lot = of >> confidence that the claimed discoverability benefits of WebFinger >> outweigh its potential to further degrade users' ability to keep >> particular information about themselves within specific silos. = However, >> I'm coming quite late to this document, so perhaps that balancing has >> already been discussed, and it strikes me as unreasonable to try to >> stand in the way of publication at this point. >>=20 >> Two suggestions in section 8: >>=20 >> s/personal information/personal data/ >> (see http://tools.ietf.org/html/draft-iab-privacy-considerations- >> 06#section-2.2 -- personal data is a more widely accepted term and >> covers a larger range of information about people) >>=20 >> The normative prohibition against using WebFinger to publish personal >> data without authorization is good, but the notion of implicit >> authorization leaves much uncertainty about what I imagine will be a = use >> case of interest: taking information out of a controlled context and >> making it more widely available. To make it obvious that this has = been >> considered, I would suggest adding one more sentence to the end of = the >> fourth paragraph: >>=20 >> "Publishing one's personal data within an access-controlled or = otherwise >> limited environment on the Internet does not equate to providing >> implicit authorization of further publication of that data via >> WebFinger." >>=20 >> Alissa >>=20 >> On Mar 4, 2013, at 3:24 PM, The IESG wrote: >>=20 >>>=20 >>> The IESG has received a request from the Applications Area Working >>> Group WG (appsawg) to consider the following document: >>> - 'WebFinger' >>> as Proposed Standard >>>=20 >>> The IESG plans to make a decision in the next few weeks, and = solicits >>> final comments on this action. Please send substantive comments to = the >>> ietf@ietf.org mailing lists by 2013-03-18. Exceptionally, comments = may >>> be sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>>=20 >>> Abstract >>>=20 >>>=20 >>> 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. WebFinger discovers >>> information for a URI that might not be usable as a locator >>> otherwise, such as account or email URIs. >>>=20 >>>=20 >>>=20 >>>=20 >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ >>>=20 >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ >>>=20 >>>=20 >>> No IPR declarations have been submitted directly on this I-D. >>>=20 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 From paulej@packetizer.com Wed Mar 27 23:08:40 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499F721F9356 for ; Wed, 27 Mar 2013 23:08:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu8yRTXDJa7J for ; Wed, 27 Mar 2013 23:08:39 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 597AF21F9352 for ; Wed, 27 Mar 2013 23:08:36 -0700 (PDT) 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 r2S68ZLg006093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 28 Mar 2013 02:08:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1364450915; bh=7VhKL1BZNMEOmoN4z2T1HEqHSoHwR5JUzj2G3XufdFo=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=i8AhiilJKgJG2j+oBCsmIBjRXyuOBqqVhytmtWQggUeM01UPfC6oFjy0eve8YYDov T7toIbjxOFrg87RH1c7udomJ9yOAQtXHUU0oRJDjl/Kt+7lfszE7lkmIFZCKJkNBTr GM3K71WwPy5kwWcbJ8ShZKizificxp1e1fVGMg4w= From: "Paul E. Jones" To: References: <20130328060736.2908.27753.idtracker@ietfa.amsl.com> In-Reply-To: <20130328060736.2908.27753.idtracker@ietfa.amsl.com> Date: Thu, 28 Mar 2013 02:08:58 -0400 Message-ID: <033401ce2b7a$bc9c7de0$35d579a0$@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: AQJbTrBZI1d/h/jwxDCEZad1XtIe/pegWAyA Content-Language: en-us Subject: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-12.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 06:08:40 -0000 FYI > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Thursday, March 28, 2013 2:08 AM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-12.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group > Working Group of the IETF. > > Title : WebFinger > Author(s) : Paul E. Jones > Gonzalo Salgueiro > Joseph Smarr > Filename : draft-ietf-appsawg-webfinger-12.txt > Pages : 23 > Date : 2013-03-27 > > 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. WebFinger discovers > information for a URI that might not be usable as a locator > otherwise, such as account or email URIs. > > > 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-12 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-12 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From brian.e.carpenter@gmail.com Thu Mar 28 00:53:09 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DEB21F9056; Thu, 28 Mar 2013 00:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.951 X-Spam-Level: X-Spam-Status: No, score=-98.951 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP+t6Q+q69-S; Thu, 28 Mar 2013 00:53:08 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 19DE121F9060; Thu, 28 Mar 2013 00:53:07 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u12so1929966wey.19 for ; Thu, 28 Mar 2013 00:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HOwy+v1pZferMeg5X1viXVZ5PK/nQXGZfK9D9+RwbrE=; b=dE3JDGEBO50forJN6HPJxitPB9PJ0/s0NKDPX8tE9yv7WUz0wwKisrDV5/jNogGkmt qYsvHW+WiEc/PRGj0gczqU6EoprjyouqtJH6R9LIor8ecOsOSEnxBMfxMnsrtyOJmJJg yJ4u/saXrIaLPn3PyosxI+ObL/My4wWf7wHEllR9Jf6cZqH/+kM0BRoALjYqff5wb47O ON+rUoSarPB+6piZc44ZhxmUId23pdO3jBGuzp/5gx/3Z+1VfkRTuxyqaCG+HPFLcsbS XzTDVZyFshYT+RH0hXgAdlsRK5n8bc0u25jZvJgLHyQRjZcEskYtkIKfPuin7xJSos6P 5TJw== X-Received: by 10.194.109.136 with SMTP id hs8mr36476171wjb.8.1364457187142; Thu, 28 Mar 2013 00:53:07 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-148.as13285.net. [2.101.189.148]) by mx.google.com with ESMTPS id gl11sm12639580wic.8.2013.03.28.00.53.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 00:53:05 -0700 (PDT) Message-ID: <5153F6E6.7000507@gmail.com> Date: Thu, 28 Mar 2013 07:53:10 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Paul E. Jones" References: <51449E79.2090205@gmail.com> <054301ce25cf$66e8bdb0$34ba3910$@packetizer.com> In-Reply-To: <054301ce25cf$66e8bdb0$34ba3910$@packetizer.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Mar 2013 01:16:14 -0700 Cc: webfinger@ietf.org, 'General Area Review Team' , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] Gen-ART LC review of draft-ietf-appsawg-webfinger-11.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 07:53:09 -0000 I'm happy with the changes in the -12 draft. Thanks Brian Carpenter On 21/03/2013 00:59, Paul E. Jones wrote: > Brian, > >> Major Issues: >> ------------- >> >> There is no explicit discussion of privacy in the draft, which seems to >> me to carry evident privacy risks. For example, imagine an ISP that >> kindly decides to support webfinger for all customers by default, >> and preloads personally identifiable information without consent. > > Barry commented on this indicating it is there. Per Dave's advice, I think we should make it clearer with subsections in the security section. > >> There is some relevant text in the Security Considerations: >> >> Further, WebFinger MUST NOT be used to provide any personal >> information to any party unless explicitly or implicitly authorized >> by the person whose information is being shared. >> >> However, the weakness there is the words "or implicitly". IANAL, but it >> seems highly likely that would be illegal in the European Union, at least. > > I have no strong preference on this, but "implicit" was asked by some, since (as an example), your information might be shared via WebFinger inside a company for company use. > >> Has the draft been validated against the guidelines in >> draft-iab-privacy-considerations? > > I have not, but Alissa was asked to weigh in (and she did). I trust she provided recommendations. (I've not gotten that far down the stack, yet.) > > Paul > > >