From paul.bryan@forgerock.com Tue Nov 1 15:43:34 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9554C1F0C4C for ; Tue, 1 Nov 2011 15:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 aHtlMvYawcKx for ; Tue, 1 Nov 2011 15:43:33 -0700 (PDT) Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) by ietfa.amsl.com (Postfix) with SMTP id 1AF2C1F0C36 for ; Tue, 1 Nov 2011 15:43:32 -0700 (PDT) Received: from mail-yw0-f47.google.com ([209.85.213.47]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP; Tue, 01 Nov 2011 22:43:33 UTC Received: by ywf9 with SMTP id 9so8573550ywf.20 for ; Tue, 01 Nov 2011 15:43:04 -0700 (PDT) Received: by 10.101.37.14 with SMTP id p14mr415822anj.111.1320187384656; Tue, 01 Nov 2011 15:43:04 -0700 (PDT) Received: from [192.168.1.8] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id m33sm1200500ann.4.2011.11.01.15.43.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Nov 2011 15:43:04 -0700 (PDT) Message-ID: <1320187375.2622.25.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 01 Nov 2011 15:42:55 -0700 Content-Type: multipart/alternative; boundary="=-LG9oM+03B+92eIRWA5se" X-Mailer: Evolution 3.0.3-2 Mime-Version: 1.0 Subject: [apps-discuss] JSON Patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 22:43:34 -0000 --=-LG9oM+03B+92eIRWA5se Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I have published and have been maintaining a JSON Patch Internet-Draft: http://tools.ietf.org/html/draft-pbryan-json-patch-02 There's now at least three actively maintained implementations in as many programming languages. Interest has been expressed in moving this toward an RFC. I've discussed this briefly with Mark Nottingham, Pete Resnick and Peter Saint-Andre, and consensus seems to be to raise this with APPSAWG and see if there's any interest in developing this on a standards track. Thoughts? Paul --=-LG9oM+03B+92eIRWA5se Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I have published and have been maintaining a JSON Patch Internet-Draft:
http://tools.ietf.org/html/draft-pbryan-json-patch-02

There's now at least three actively maintained implementations in as many programming languages. Interest has been expressed in moving this toward an RFC. I've discussed this briefly with Mark Nottingham, Pete Resnick and Peter Saint-Andre, and consensus seems to be to raise this with APPSAWG and see if there's any interest in developing this on a standards track.

Thoughts?

Paul --=-LG9oM+03B+92eIRWA5se-- From enrico.marocco@telecomitalia.it Wed Nov 2 02:13:25 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BBC11E8113 for ; Wed, 2 Nov 2011 02:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.719 X-Spam-Level: X-Spam-Status: No, score=-100.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 y8Oi3p1BXu4c for ; Wed, 2 Nov 2011 02:13:24 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE4311E8100 for ; Wed, 2 Nov 2011 02:13:20 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 2 Nov 2011 10:13:02 +0100 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 2 Nov 2011 10:13:02 +0100 Message-ID: <4EB1099C.7090303@telecomitalia.it> Date: Wed, 2 Nov 2011 10:13:00 +0100 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Paul C. Bryan" References: <1320187375.2622.25.camel@neutron> In-Reply-To: <1320187375.2622.25.camel@neutron> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060102030701040302070403" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 09:13:25 -0000 --------------ms060102030701040302070403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, the need for such a mechanism periodically arises in the alto WG as a means for providing incremental updates with the JSON-based protocol that's being specified over there. I, for one, certainly support moving this forward, possibly in a specifically chartered WG where usecases and requirements from different contexts could be best evaluated. Enrico On 11/1/11 11:42 PM, Paul C. Bryan wrote: > I have published and have been maintaining a JSON Patch Internet-Draft:= > http://tools.ietf.org/html/draft-pbryan-json-patch-02 >=20 > There's now at least three actively maintained implementations in as > many programming languages. Interest has been expressed in moving this > toward an RFC. I've discussed this briefly with Mark Nottingham, Pete > Resnick and Peter Saint-Andre, and consensus seems to be to raise this > with APPSAWG and see if there's any interest in developing this on a > standards track. >=20 > Thoughts? >=20 > Paul --------------ms060102030701040302070403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINfjCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHQjCCBiqgAwIBAgIDAt9AMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTEwODIyMDYyNDA2 WhcNMTIwODIyMDM0MDM3WjB8MSAwHgYDVQQNExc0OTAyNDItOU1QZVJYRnFlVVU0QUMybTEo MCYGA1UEAwwfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEuMCwGCSqGSIb3DQEJ ARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBALl4L3Uj7TJrMbll5JAyphws2AMR67q3D2FH0JmRqQ5r+ujqaxyeHcrx Kclu2tz/D3SPtZAlcDOclxpEDbpxXlMpo+3DsbNweNgSF6mnyRDYU2ay3qO54ENz21GZ64bl ZRsMI6KsGnxm7sORWLUdx229ijARs3aQD1js9bidUJsnxg26UvnwpJ8eGoFiCLzzsQXUD+OL 3TXEGrTzt+B2RDb13TIOe085T8jzBh08wNKPTDmKjxy5m35Xn8QfRy8b93d0wUs98Fst5iND EgHEHc9CwurwLYrOd/1ZkbfAoRi7kRQ0Ih4wKkP+Lkww/0qHEIrrgW+aVmGjkQ0nidAaE+sC AwEAAaOCA7owggO2MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUYgEiK9qxBHth8ziqydxV7QYZn1QwHwYDVR0jBBgw FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVs ZWNvbWl0YWxpYS5pdDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4G CCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUF BwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhp cyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5j ZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVz IGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0 aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAF4gnxCzZVmINcZh7ZMB6G1+8/kV6pLqDxyUidalFSJ8KLwJxrxhESOb+E7d JHxZBuJFH1NBXuVn+MI7rqa/HI7PkLJjkHhMH8ay7jhR2VVMIFYAqRn9O22oDDw2iEigYkgo HcHP1vD5rtydbGr6mCcHOtWCk5B7FqEoMYTQRO1F6szoqORVaajVtZeSwtVAMufV20tohyUL hpOH5lZDblsej2XueyJVqD8RYSUJp7w4eMpr5CTP9QdNBS0cca83JA070JMudV+ozG6ADIBx mGPrWyPv7PmjBBGIXxPJJRxDsDyJBYhs+qh6fZWNl6WZkQNepkn7IAUB0+0ggds992kxggPQ MIIDzAIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30AwCQYF Kw4DAhoFAKCCAhAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTExMTAyMDkxMzAwWjAjBgkqhkiG9w0BCQQxFgQU8pE7TIwApGOKGLOXJ3LfPX1w6scwXwYJ KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQx gZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAt9AMIGnBgsqhkiG 9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30Aw DQYJKoZIhvcNAQEBBQAEggEASr77lqPDJkD4cSgZykzmAV3rPACHP8x2PPpQWiLxMTFoZNds erMqA8oaR8mbH/Kahfxd79ngLk4rnk+Ndhi4UcJ+gJhk7MPm5/Tq+z7iT8yOq6sbVjBu2j3q E11RyA63KZUscPQtDUfEav/rsSkJOvw30Qw8AnwHPOHtdL5yIMZ9sk6bXebCdtbZi0k1UFr5 NGKg0DE9NgK8MZ2Qc5z7j8zrrbZqeKu1hCh0Aw560iGGHauH6o5Bng2wNa4ztQBGae8Jj+1+ EIt11fi2/3UrTE6RZwRHa01RIg6Dp9dFmf+xLH7phgY5/vr5EcoTai3FXZR4f8D1cbesiCKF iLcw3wAAAAAAAA== --------------ms060102030701040302070403-- From GK@ninebynine.org Wed Nov 2 02:58:31 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61741F0CA4 for ; Wed, 2 Nov 2011 02:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFd3AvUqGcVv for ; Wed, 2 Nov 2011 02:58:31 -0700 (PDT) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id 27D221F0CA2 for ; Wed, 2 Nov 2011 02:58:31 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RLXaX-0005TE-3B; Wed, 02 Nov 2011 09:58:29 +0000 Received: from client-7-201.eduroam.oxuni.org.uk ([192.76.7.201] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLXaX-0002Zt-9K; Wed, 02 Nov 2011 09:58:29 +0000 Message-ID: <4EB11346.3010609@ninebynine.org> Date: Wed, 02 Nov 2011 09:54:14 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Paul C. Bryan" References: <1320187375.2622.25.camel@neutron> In-Reply-To: <1320187375.2622.25.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 09:58:31 -0000 I'm in favour of this. I'd be interested to hear if anyone has done any implementation work to use this to apply deltas to RDF data expressed using JSON (such as JSON-LD - http://json-ld.org/) - I'm guessing it should be a pretty good fit, but there may be devil in the detail. #g --= On 01/11/2011 22:42, Paul C. Bryan wrote: > I have published and have been maintaining a JSON Patch Internet-Draft: > http://tools.ietf.org/html/draft-pbryan-json-patch-02 > > There's now at least three actively maintained implementations in as > many programming languages. Interest has been expressed in moving this > toward an RFC. I've discussed this briefly with Mark Nottingham, Pete > Resnick and Peter Saint-Andre, and consensus seems to be to raise this > with APPSAWG and see if there's any interest in developing this on a > standards track. > > Thoughts? > > Paul > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From mnot@mnot.net Wed Nov 2 03:19:02 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD4611E8149 for ; Wed, 2 Nov 2011 03:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.478 X-Spam-Level: X-Spam-Status: No, score=-105.478 tagged_above=-999 required=5 tests=[AWL=-2.879, 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 w31Itq8ddafS for ; Wed, 2 Nov 2011 03:19:01 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 861BE11E8142 for ; Wed, 2 Nov 2011 03:19:01 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.71.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 721EC22E1FB; Wed, 2 Nov 2011 06:18:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <1320187375.2622.25.camel@neutron> Date: Wed, 2 Nov 2011 21:18:49 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5C4A4646-3160-40FA-BF64-6F6290CB1D4C@mnot.net> References: <1320187375.2622.25.camel@neutron> To: Paul C. Bryan X-Mailer: Apple Mail (2.1251.1) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:19:02 -0000 If it needs to be said, I'm +1 on this. I don't think we need a separate WG on this -- it's relatively simple = (and should stay that way). The important thing is to get momentum = behind a single way to do it. APPAWG can accomplish that easily (and if = it gets any harder, I'd recommend that the authors go Informational). Cheers, On 02/11/2011, at 9:42 AM, Paul C. Bryan wrote: > I have published and have been maintaining a JSON Patch = Internet-Draft: > http://tools.ietf.org/html/draft-pbryan-json-patch-02 >=20 > There's now at least three actively maintained implementations in as = many programming languages. Interest has been expressed in moving this = toward an RFC. I've discussed this briefly with Mark Nottingham, Pete = Resnick and Peter Saint-Andre, and consensus seems to be to raise this = with APPSAWG and see if there's any interest in developing this on a = standards track. >=20 > Thoughts? >=20 > Paul > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From mduerig@adobe.com Wed Nov 2 06:40:24 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC72521F8C9A for ; Wed, 2 Nov 2011 06:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4+Fn8XAvb8VS for ; Wed, 2 Nov 2011 06:40:24 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id CB22921F8C84 for ; Wed, 2 Nov 2011 06:40:23 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP; Wed, 02 Nov 2011 06:40:23 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pA2DchGh024391 for ; Wed, 2 Nov 2011 06:38:43 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pA2DeL5R016182 for ; Wed, 2 Nov 2011 06:40:21 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 2 Nov 2011 06:40:21 -0700 Received: from susi.eur.adobe.com (10.130.225.249) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.192.1; Wed, 2 Nov 2011 13:39:58 +0000 Message-ID: <4EB1482E.1040600@adobe.com> Date: Wed, 2 Nov 2011 13:39:58 +0000 From: =?ISO-8859-1?Q?Michael_D=FCrig?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] JSON Patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:44:57 -0000 Hi, This looks very interesting. There seem to be a lot of similarities to an earlier proposal [1, 2]. What is missing (wrt. to [2]) is a reorder operation. Furthermore I think the notion of the JSON path used in the operations should be defined somewhere. Michael [1] http://lists.w3.org/Archives/Public/w3c-dist-auth/2010JulSep/0008.html [2] http://www.slideshare.net/uncled/jsop From julian.reschke@gmx.de Wed Nov 2 06:57:06 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC1A21F8C0A for ; Wed, 2 Nov 2011 06:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.095 X-Spam-Level: X-Spam-Status: No, score=-104.095 tagged_above=-999 required=5 tests=[AWL=-1.796, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Poqf7DTBSkQr for ; Wed, 2 Nov 2011 06:57:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3656221F8BE8 for ; Wed, 2 Nov 2011 06:57:05 -0700 (PDT) Received: (qmail invoked by alias); 02 Nov 2011 13:57:03 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp015) with SMTP; 02 Nov 2011 14:57:03 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19EmdggGolEMViAz6XF5CoWTWIOU+XFQ2tggtz9Za a0CLN3Pbka+NYm Message-ID: <4EB14C2E.8040208@gmx.de> Date: Wed, 02 Nov 2011 14:57:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_D=FCrig?= References: <4EB1482E.1040600@adobe.com> In-Reply-To: <4EB1482E.1040600@adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:57:06 -0000 On 2011-11-02 14:39, Michael Dürig wrote: > > Hi, > > This looks very interesting. There seem to be a lot of similarities to > an earlier proposal [1, 2]. What is missing (wrt. to [2]) is a reorder > operation. > > Furthermore I think the notion of the JSON path used in the operations > should be defined somewhere. > ... That's defined in ... As an XML person, seeing an XPath-like syntax make me happy. But wouldn't be "dot" notation be much simpler, given where JSO comes from? Best regards, Julian From paul.bryan@forgerock.com Wed Nov 2 10:23:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD951F0C9F for ; Wed, 2 Nov 2011 10:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 y1eAfOUotC1h for ; Wed, 2 Nov 2011 10:23:00 -0700 (PDT) Received: from eu1sys200aog119.obsmtp.com (eu1sys200aog119.obsmtp.com [207.126.144.147]) by ietfa.amsl.com (Postfix) with SMTP id 289F31F0C76 for ; Wed, 2 Nov 2011 10:22:59 -0700 (PDT) Received: from mail-yw0-f42.google.com ([209.85.213.42]) (using TLSv1) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP; Wed, 02 Nov 2011 17:23:00 UTC Received: by ywb26 with SMTP id 26so662175ywb.1 for ; Wed, 02 Nov 2011 10:22:47 -0700 (PDT) Received: by 10.151.92.17 with SMTP id u17mr6522263ybl.22.1320254567261; Wed, 02 Nov 2011 10:22:47 -0700 (PDT) Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id x3sm9009463anl.6.2011.11.02.10.22.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Nov 2011 10:22:46 -0700 (PDT) Message-ID: <1320254564.2622.37.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Wed, 02 Nov 2011 10:22:44 -0700 In-Reply-To: <4EB14C2E.8040208@gmx.de> References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> Content-Type: multipart/alternative; boundary="=-9JYf1lj4zb15I+rBXMzH" X-Mailer: Evolution 3.0.3-2 Mime-Version: 1.0 Subject: Re: [apps-discuss] JSON Patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:23:01 -0000 --=-9JYf1lj4zb15I+rBXMzH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Thanks everyone for the feedback so far. Some replies: On Wed, 2011-11-02 at 13:39 +0000, Michael Dürig wrote: > What is missing (wrt. to [2]) is a reorder operation. The ability to move items in an array has come up and seems straightforward. A need (and semantics) of moving a value between two arbitrary locations in a JSON document is not well understood. On Wed, 2011-11-02 at 14:57 +0100, Julian Reschke wrote: > As an XML person, seeing an XPath-like syntax make me happy. But > wouldn't be "dot" notation be much simpler, given where JSO comes > from? A few of reasons we went with slashes: 1. Less confusing where array elements are involved. 2. Slashes are less likely to appear in object member names, hence less percent-encoding. 3. Pointers are intended to be specified in URI fragment identifiers, and would appear to some (unsophisticated humans or machines) like a filename extension. Paul --=-9JYf1lj4zb15I+rBXMzH Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Thanks everyone for the feedback so far. Some replies:

On Wed, 2011-11-02 at 13:39 +0000, Michael Dürig wrote:
What is missing (wrt. to [2]) is a reorder operation.

The ability to move items in an array has come up and seems straightforward. A need (and semantics) of moving a value between two arbitrary locations in a JSON document is not well understood.

On Wed, 2011-11-02 at 14:57 +0100, Julian Reschke wrote:
As an XML person, seeing an XPath-like syntax make me happy. But
wouldn't be "dot" notation be much simpler, given where JSO comes from?

A few of reasons we went with slashes:

1. Less confusing where array elements are involved.
2. Slashes are less likely to appear in object member names, hence less percent-encoding.
3. Pointers are intended to be specified in URI fragment identifiers, and would appear to some (unsophisticated humans or machines) like a filename extension. 

Paul --=-9JYf1lj4zb15I+rBXMzH-- From stpeter@stpeter.im Wed Nov 2 21:41:28 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DF611E80E8 for ; Wed, 2 Nov 2011 21:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 QTo90tpgtgS5 for ; Wed, 2 Nov 2011 21:41:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8A63311E8080 for ; Wed, 2 Nov 2011 21:41:26 -0700 (PDT) Received: from squire.local (unknown [63.145.238.4]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E621141FE4 for ; Wed, 2 Nov 2011 22:47:03 -0600 (MDT) Message-ID: <4EB21B75.6040009@stpeter.im> Date: Wed, 02 Nov 2011 21:41:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <4EB21B3B.7080708@stpeter.im> In-Reply-To: <4EB21B3B.7080708@stpeter.im> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <4EB21B3B.7080708@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: [weirds] FYI: workshop on domain names and persistence X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 04:41:28 -0000 Perhaps of interest here... -------- Original Message -------- Subject: [weirds] FYI: workshop on domain names and persistence Date: Wed, 02 Nov 2011 21:40:27 -0700 From: Peter Saint-Andre To: weirds@ietf.org I learned today of a call for participation in a workshop on domain names and persistence to be held in Bristol, UK on December 8: http://www.w3.org/2001/tag/doc/idcc_workshop.html It's possible that some folks on this list might be interested. Feel free to forward as appropriate. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds From julian.reschke@gmx.de Sun Nov 6 05:40:31 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF20421F84A1 for ; Sun, 6 Nov 2011 05:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.505 X-Spam-Level: X-Spam-Status: No, score=-104.505 tagged_above=-999 required=5 tests=[AWL=-1.906, 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 3uKIjz2iSAjP for ; Sun, 6 Nov 2011 05:40:30 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4D07521F8481 for ; Sun, 6 Nov 2011 05:40:29 -0800 (PST) Received: (qmail invoked by alias); 06 Nov 2011 13:40:26 -0000 Received: from p5DCCB7E7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.183.231] by mail.gmx.net (mp002) with SMTP; 06 Nov 2011 14:40:26 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+3oBQlMRq32KKnmy0jPtjsAMiduHICkMarEKt7Cj dvIG99Bnga/cCW Message-ID: <4EB68E47.5010807@gmx.de> Date: Sun, 06 Nov 2011 14:40:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ned Freed References: <01O827GOAJG200XBUL@mauve.mrochek.com> In-Reply-To: <01O827GOAJG200XBUL@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "happiana@ietf.org" , IETF Apps Discuss Subject: [apps-discuss] draft-freed-media-type-regs-01 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 13:40:31 -0000 On 2011-11-05 20:17, Ned Freed wrote: > The revised media type registration procedure document: > > http://tools.ietf.org/html/draft-freed-media-type-regs-01 > > is in need of review. In particular, comments are solicited on exactly how the > process should be modified to remove the IESG from the review process for > standards tree types. (Note that the IESG needs to retain the authority to > determine what external organization are qualified standards bodies and what > ones are not.) > ... Hi Ned, below are notes from a quick top-to-bottom read I just did...: Comments: - 4.2 - reg-name; it would be good to state how exactly it is more restrictive, to reference the actual subsection of 2045 (5.1), and maybe say why. - 4.2 - "X-" prefixes - this obviously should be coordinated with Peter's document. - 4.2.2 - "specifies one or more separate images that require appropriate hardware to display" - sounds a bit fine-tuned for a time where graphics hardware was something special. (Also, what about audio and video?? :-) - 4.2.8 - Structured Syntax Name Suffixes - would it make sense to relax the standards-tree registration requirements for types that use an existing structured syntax? (given the fact doing so makes it much harder to do things wrong) - 4.3 - parameter-name; this repeats the warning about the change from 2045, but adds "amended by RFC2231". Optimally have this in a single place and be consistent. - 4.3 - maybe repeat the requirements from 2045 about case-insensitivity and ordering? - 4.3 - the question about the validity to *repeat* parameters comes up from time to time. My understanding is that it's understood to be invalid, but I don't think any spec says that yet. Maybe it should be noted here because it affects definitions of new parameters? - 4.11 - Mac OS File Type - is this still useful information? Minimally, to avid confusion, it should be stated that this only affects ancient versions of MacOS (right?) - 5.8 - "When review is required, a change request may be denied if it renders entities that were valid under the previous definition invalid under the new definition." - see - two questions: 1) Is "valid" to be read as "processable" or as "conforming"? For instance, HTML5 makes many things invalid that were valid before, but recipients still need to process them. 2) "may be denied" is very vague? What are the guidelines? Do we have any? - References - The spec has a normative reference to RFC 3023, which in turn has a reference to RFC 2048, which this document is obsoleting (via 4288); do we really need a normative reference here? (maybe this can be fixed by processing this one in sync with 3023bis)? Editorial: - Boilerplate - Maybe move the "Historical Note" down into the "Introduction" section? (not only for being easier to cite in the future) - Boilerplate - I always recommend to have an Editorial Note on the front page telling reviewers where to send feedback. - 5.2 - do items 1) and 2) apply to "Specification Required" process? The way it's formatted is slightly confusing. - Throughout - The spec mixes uppercase and lowercase RFC2119 terms, and it's not totally clear what the "force" of the lowercase ones is. In many cases this can be avoided by substituting "MAY" by "can" etc. Nits: - 5.2 - s/[RFC2026] section 6.5.4/Section 6.5.4 of [RFC206]/ - References - RFC4234 -> RFC 5234 - References - in the reference for RFC2231, there's a line break that shouldn't be there (this may be a problem in the xml.resource.org-supplied reference, but still...) Best regards, Julian From julian.reschke@gmx.de Sun Nov 6 06:12:46 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAB121F84B5 for ; Sun, 6 Nov 2011 06:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.476 X-Spam-Level: X-Spam-Status: No, score=-104.476 tagged_above=-999 required=5 tests=[AWL=-1.877, 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 N9gogcmm88jb for ; Sun, 6 Nov 2011 06:12:46 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8495E21F84BB for ; Sun, 6 Nov 2011 06:12:45 -0800 (PST) Received: (qmail invoked by alias); 06 Nov 2011 14:12:34 -0000 Received: from p5DCCB7E7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.183.231] by mail.gmx.net (mp020) with SMTP; 06 Nov 2011 15:12:34 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+sD/d8WU2si5AmIPFmVTzGR/6cZ3BHofa8N6xsHW udSdIXO+91ROXP Message-ID: <4EB695CC.2010509@gmx.de> Date: Sun, 06 Nov 2011 15:12:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ned Freed References: <01O827GOAJG200XBUL@mauve.mrochek.com> <4EB68E47.5010807@gmx.de> In-Reply-To: <4EB68E47.5010807@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "happiana@ietf.org" , IETF Apps Discuss Subject: [apps-discuss] parameter syntax, was: draft-freed-media-type-regs-01 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 14:12:46 -0000 On 2011-11-06 14:40, Julian Reschke wrote: > ... > - 4.2 - reg-name; it would be good to state how exactly it is more > restrictive, to reference the actual subsection of 2045 (5.1), and maybe > say why. > ... So this is the same as in RFC 4288, and the difference between 2045 and 4288 appears to be: RFC2045.token: "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / DIGIT / ALPHA / "^" / "_" / "`" / "{" / "|" / "}" / "~" RFC4288.reg-name: "!" / "#" / "$" / "&" / "+" / "-" / "." / DIGIT / ALPHA / "^" / "_" RFC2045.token - RFC4288.reg-name: "%" / "'" / "*" / "`" / "{" / "|" / "}" / "~" HTTP has: RFC2616.token: "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / DIGIT / ALPHA / "^" / "_" / "`" / "|" / "~" which is somewhere in between 2045 and 4288. If HTTPbis adds recommendations for header field parameters, should we restrict the character repertoire accordingly? Best regards, Julian From ned.freed@mrochek.com Sun Nov 6 16:11:53 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D370121F8497; Sun, 6 Nov 2011 16:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 xwgKEFCuEW8I; Sun, 6 Nov 2011 16:11:50 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 32FDC21F849D; Sun, 6 Nov 2011 16:11:50 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O83KX3NAV4011J9C@mauve.mrochek.com>; Sun, 6 Nov 2011 11:57:32 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O7WPUFOG6O00XBUL@mauve.mrochek.com>; Sun, 6 Nov 2011 11:57:28 -0800 (PST) Message-id: <01O83KX13YW800XBUL@mauve.mrochek.com> Date: Sun, 06 Nov 2011 10:47:52 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 06 Nov 2011 14:40:23 +0100" <4EB68E47.5010807@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <01O827GOAJG200XBUL@mauve.mrochek.com> <4EB68E47.5010807@gmx.de> To: Julian Reschke Cc: Ned Freed , "happiana@ietf.org" , IETF Apps Discuss Subject: Re: [apps-discuss] draft-freed-media-type-regs-01 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 00:11:54 -0000 > On 2011-11-05 20:17, Ned Freed wrote: > > The revised media type registration procedure document: > > > > http://tools.ietf.org/html/draft-freed-media-type-regs-01 > > > > is in need of review. In particular, comments are solicited on exactly how the > > process should be modified to remove the IESG from the review process for > > standards tree types. (Note that the IESG needs to retain the authority to > > determine what external organization are qualified standards bodies and what > > ones are not.) > > ... > Hi Ned, > below are notes from a quick top-to-bottom read I just did...: > Comments: > - 4.2 - reg-name; it would be good to state how exactly it is more > restrictive, to reference the actual subsection of 2045 (5.1), and maybe > say why. Adding the section 5.1 reference is a good idea and I'll do that. But I really don't want to get into where all the restrictions originate - the point behind writing this using descriptive rather than proscriptive ABNF was to make it very easy for people to tell what characters they can use without having to wade through a lot of unncessary distractions. Remember: We're trying to make it easier for folks to figure out how to register stuff. Understanding the historical reasons why things are the way they are is a secondary goal at best. > - 4.2 - "X-" prefixes - this obviously should be coordinated with > Peter's document. Er, actually, it rather obviously should not. Peter's draft is focused on preventing *new* uses of the X- convention. It doesn't address the issue of what to do about existing x- usage, which is a rather naunced and tricky area. Now, if you want to argue that Peter's draft should address how to deal with existing x- usage in various places, well, that's a discussion you need to have to have elsewhere. If and when that happens it may make sense to refer to such a document. Or not - it would depend on what it said. In any case, the current approach taken to the X- issue here is to: (1) Strongly discourage the use of such names. (2) In the event such a name gets widely deployed in spite of it's lack of registration, allow it to be registered in the vnd. tree. This wasn't noted in the changes since the last version list and I have addressed that. > - 4.2.2 - "specifies one or more separate images that require > appropriate hardware to display" - sounds a bit fine-tuned for a time > where graphics hardware was something special. (Also, what about audio > and video?? :-) The point of the "separate image" line was to distinguish it from video. That said, I take your point about the hardware reference and will remove it. > - 4.2.8 - Structured Syntax Name Suffixes - would it make sense to relax > the standards-tree registration requirements for types that use an > existing structured syntax? (given the fact doing so makes it much > harder to do things wrong) Not sure what you're getting at here. Stuctured syntax name suffixes are available to all types in all registration trees and always have been. If there's text that says or implies otherwise let me know where it is and I'll fix it. If you're saying that the requirements for a structured syntax are too strict - they're currently that there be a referencable description of that syntax, preferably in some sort of standards document - then I quite simply disgree that that's a good iea. > - 4.3 - parameter-name; this repeats the warning about the change from > 2045, but adds "amended by RFC2231". Optimally have this in a single > place and be consistent. It's a different change and for different reasons. And the amendment made by RFC 2231 applies here but not to media type names, so it cannot be collapsed without making it incorrect. > - 4.3 - maybe repeat the requirements from 2045 about case-insensitivity > and ordering? Can't hurt. > - 4.3 - the question about the validity to *repeat* parameters comes up > from time to time. My understanding is that it's understood to be > invalid, but I don't think any spec says that yet. Maybe it should be > noted here because it affects definitions of new parameters? I'll add a note about it. > - 4.11 - Mac OS File Type - is this still useful information? Minimally, > to avid confusion, it should be stated that this only affects ancient > versions of MacOS (right?) Nope. The actual situation under Mac OS is rather complex, but suffice it to say that Mac OS still supports and uses these codes. (And yes, it also uses file extensions. As I say, it's complicated.) > - 5.8 - "When review is required, a change request may be denied if it > renders entities that were valid under the previous definition invalid > under the new definition." - see > - two questions: > 1) Is "valid" to be read as "processable" or as "conforming"? For > instance, HTML5 makes many things invalid that were valid before, but > recipients still need to process them. > 2) "may be denied" is very vague? What are the guidelines? Do we have any? The concern here is that someone may attempt to use the change procedure as a means of attack - for no good reason change a type in such a way that someone's software is now incompliant. This has never happened and this procedure has never been invoked. If and when it ever does, then maybe at that point we'll be able to come up with some better guidelines. But until then... I'm not comfortable trying to specify anything more and I'm not comfortable removing this either. That said, the part of this section that does bother me is the part about only making changes when there's a serious error. I'm going to qualify that to say significant changes to a definition should only be made to correct a serious error. (I may actually not have gone far enough on this one.) > - References - The spec has a normative reference to RFC 3023, which in > turn has a reference to RFC 2048, which this document is obsoleting (via > 4288); do we really need a normative reference here? (maybe this can be > fixed by processing this one in sync with 3023bis)? You need to understand the rules that apply specifically to XML types to register one and those rules are for better or worse, in RFC 3023. So IMO the reference is normative. As for trying to sync with another specification, that's almost always a really bad idea. The reality is specifications are both interdependent and get updates, so such situations are going to happen whether we like it or not. > Editorial: > - Boilerplate - Maybe move the "Historical Note" down into the > "Introduction" section? (not only for being easier to cite in the future) Seems reasonable. > - Boilerplate - I always recommend to have an Editorial Note on the > front page telling reviewers where to send feedback. I don't really see the point in this case. > - 5.2 - do items 1) and 2) apply to "Specification Required" process? > The way it's formatted is slightly confusing. This part is incomplete, pending input on exactly how the process should be modified to allow registration of standards tree types without involving the IESG. > - Throughout - The spec mixes uppercase and lowercase RFC2119 terms, and > it's not totally clear what the "force" of the lowercase ones is. In > many cases this can be avoided by substituting "MAY" by "can" etc. A lower case must, may, or should is by definition not a RFC 2119 term. And the choices for all of these have been made rather carefully over a prolonged period. I'm not about to start making further changes willy-nilly along the lines you suggest. > Nits: > - 5.2 - s/[RFC2026] section 6.5.4/Section 6.5.4 of [RFC206]/ OK. > - References - RFC4234 -> RFC 5234 Fixed. > - References - in the reference for RFC2231, there's a line break that > shouldn't be there (this may be a problem in the > xml.resource.org-supplied reference, but still...) I'll leave that one for the RFC Editor. Fixing XML resource stuff is above my pay grade. Ned From julian.reschke@gmx.de Mon Nov 7 10:20:08 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E761221F8C07 for ; Mon, 7 Nov 2011 10:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.197 X-Spam-Level: X-Spam-Status: No, score=-104.197 tagged_above=-999 required=5 tests=[AWL=-1.598, 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 ZG0-fkJYplrQ for ; Mon, 7 Nov 2011 10:20:08 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3191121F8B85 for ; Mon, 7 Nov 2011 10:20:07 -0800 (PST) Received: (qmail invoked by alias); 07 Nov 2011 18:20:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp055) with SMTP; 07 Nov 2011 19:20:05 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18v4sw0+CQvTlL76YXh/a62Q2/csgk8zcVVjT0zBP pkU9Kpsc0DOrHo Message-ID: <4EB82152.5010001@gmx.de> Date: Mon, 07 Nov 2011 19:20:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ned Freed References: <01O827GOAJG200XBUL@mauve.mrochek.com> <4EB68E47.5010807@gmx.de> <01O83KX13YW800XBUL@mauve.mrochek.com> In-Reply-To: <01O83KX13YW800XBUL@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "happiana@ietf.org" , IETF Apps Discuss Subject: Re: [apps-discuss] draft-freed-media-type-regs-01 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 18:20:09 -0000 On 2011-11-06 19:47, Ned Freed wrote: > ... >> Comments: > >> - 4.2 - reg-name; it would be good to state how exactly it is more >> restrictive, to reference the actual subsection of 2045 (5.1), and maybe >> say why. > > Adding the section 5.1 reference is a good idea and I'll do that. But I > really > don't want to get into where all the restrictions originate - the point > behind > writing this using descriptive rather than proscriptive ABNF was to make it > very easy for people to tell what characters they can use without having to > wade through a lot of unncessary distractions. > ... Understood, but the change actually removed a lot of characters, so it's not just a matter of style. As we have similar stuff in HTTPbis I'm personally interested to find out about the history for this. And no, it doesn't need to be addressed in this spec, and it's also not a change from 4288. > ... > (1) Strongly discourage the use of such names. > (2) In the event such a name gets widely deployed in spite of it's lack > of registration, allow it to be registered in the vnd. tree. > > This wasn't noted in the changes since the last version list and I have > addressed that. > ... +1 >> - 4.2.2 - "specifies one or more separate images that require >> appropriate hardware to display" - sounds a bit fine-tuned for a time >> where graphics hardware was something special. (Also, what about audio >> and video?? :-) > > The point of the "separate image" line was to distinguish it from video. > That > said, I take your point about the hardware reference and will remove it. Thanks. >> - 4.2.8 - Structured Syntax Name Suffixes - would it make sense to relax >> the standards-tree registration requirements for types that use an >> existing structured syntax? (given the fact doing so makes it much >> harder to do things wrong) > > Not sure what you're getting at here. Stuctured syntax name suffixes are > available to all types in all registration trees and always have been. If > there's text that says or implies otherwise let me know where it is and > I'll > fix it. > > If you're saying that the requirements for a structured syntax are > too strict - they're currently that there be a referencable description > of that syntax, preferably in some sort of standards document - then I > quite > simply disgree that that's a good iea. No, I meant to say something else; about registering a type that uses a registered suffix in the standards tree. But that requires either "IESG approval" or "Specification required"; and that's fine (my idea was to reduce load on the IESG in this case, but it seems I misremembered the requirement). >> - 4.3 - parameter-name; this repeats the warning about the change from >> 2045, but adds "amended by RFC2231". Optimally have this in a single >> place and be consistent. > > It's a different change and for different reasons. And the amendment made > by RFC 2231 applies here but not to media type names, so it cannot be > collapsed without making it incorrect. Sorry, indeed. Maybe it's worthwhile to point out that the character removed due to RFC 2231 is "*". > ... >> - 4.3 - the question about the validity to *repeat* parameters comes up >> from time to time. My understanding is that it's understood to be >> invalid, but I don't think any spec says that yet. Maybe it should be >> noted here because it affects definitions of new parameters? > > I'll add a note about it. > ... +1 > ... >> - 5.8 - "When review is required, a change request may be denied if it >> renders entities that were valid under the previous definition invalid >> under the new definition." - see >> - two questions: > >> 1) Is "valid" to be read as "processable" or as "conforming"? For >> instance, HTML5 makes many things invalid that were valid before, but >> recipients still need to process them. > >> 2) "may be denied" is very vague? What are the guidelines? Do we have >> any? > > The concern here is that someone may attempt to use the change procedure > as a > means of attack - for no good reason change a type in such a way that > someone's > software is now incompliant. > > This has never happened and this procedure has never been invoked. If > and when > it ever does, then maybe at that point we'll be able to come up with some > better guidelines. But until then... I'm not comfortable trying to specify > anything more and I'm not comfortable removing this either. > > That said, the part of this section that does bother me is the part > about only > making changes when there's a serious error. I'm going to qualify that > to say > significant changes to a definition should only be made to correct a > serious > error. (I may actually not have gone far enough on this one.) What about evolving a format? > ... >> - Throughout - The spec mixes uppercase and lowercase RFC2119 terms, and >> it's not totally clear what the "force" of the lowercase ones is. In >> many cases this can be avoided by substituting "MAY" by "can" etc. > > A lower case must, may, or should is by definition not a RFC 2119 term. > ... Depending on how you read RFC 2119, you might come to a different conclusion. Some people do. > And the > choices for all of these have been made rather carefully over a prolonged > period. I'm not about to start making further changes willy-nilly along the > lines you suggest. > ... Ack. > ... Best regards, Julian From stpeter@stpeter.im Mon Nov 7 14:49:30 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B081F0C46 for ; Mon, 7 Nov 2011 14:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 QHOevB8rii8f for ; Mon, 7 Nov 2011 14:49:29 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B735D1F0C45 for ; Mon, 7 Nov 2011 14:49:29 -0800 (PST) Received: from dhcp-64-101-72-196.cisco.com (unknown [64.101.72.196]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7056F41FE4 for ; Mon, 7 Nov 2011 15:55:20 -0700 (MST) Message-ID: <4EB86078.8070904@stpeter.im> Date: Mon, 07 Nov 2011 15:49:28 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 22:49:30 -0000 In talking with folks at the W3C meeting last week, I heard yet again of interest in defining a Content Type for fonts. Would anyone active in the IETF Applications Area want to work on such a spec? And do folks here think a new top-level content type is needed for fonts? Peter -- Peter Saint-Andre https://stpeter.im/ From dhc@dcrocker.net Mon Nov 7 14:58:13 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E341F0C47 for ; Mon, 7 Nov 2011 14:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, 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 V2BLO1bwgA3F for ; Mon, 7 Nov 2011 14:58:12 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 525BE1F0C45 for ; Mon, 7 Nov 2011 14:58:12 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pA7Mw4B4017176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Nov 2011 14:58:10 -0800 Message-ID: <4EB86272.10206@dcrocker.net> Date: Mon, 07 Nov 2011 14:57:54 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4EB86078.8070904@stpeter.im> In-Reply-To: <4EB86078.8070904@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 07 Nov 2011 14:58:10 -0800 (PST) Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 22:58:13 -0000 On 11/7/2011 2:49 PM, Peter Saint-Andre wrote: > In talking with folks at the W3C meeting last week, I heard yet again of > interest in defining a Content Type for fonts. Would anyone active in > the IETF Applications Area want to work on such a spec? And do folks > here think a new top-level content type is needed for fonts? sure. i don't know much about the details of font specification but am assuming the task here is one of packaging existing conventions rather than creating new ones. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john-ietf@jck.com Mon Nov 7 15:32:49 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DC611E80C1 for ; Mon, 7 Nov 2011 15:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, 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 fYiWGys8BjRh for ; Mon, 7 Nov 2011 15:32:49 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 005B911E80BB for ; Mon, 7 Nov 2011 15:32:48 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RNYgF-000Dik-9c; Mon, 07 Nov 2011 18:32:43 -0500 Date: Mon, 07 Nov 2011 18:32:42 -0500 From: John C Klensin To: Peter Saint-Andre , apps-discuss@ietf.org Message-ID: In-Reply-To: <4EB86078.8070904@stpeter.im> References: <4EB86078.8070904@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 23:32:49 -0000 --On Monday, November 07, 2011 15:49 -0700 Peter Saint-Andre wrote: > In talking with folks at the W3C meeting last week, I heard > yet again of interest in defining a Content Type for fonts. > Would anyone active in the IETF Applications Area want to work > on such a spec? And do folks here think a new top-level > content type is needed for fonts? Well, I think that a top-level would be in order -- these are really different from the existing types. Things may have changed, but my recollection from when I had some exposure to them in the early 90s is that there are a bunch of font definition languages out there. Unless all but one has atrophied or one could pick one to go with the top-level type, there is going to be a messy problem in which one either needs to have font/DefinitionLanguage fonttype=Foo or another round of font/Foo+DefinitionLanguage I'd hope we could avoid the latter, especially since some of those languages and definitional methods don't scale over a very broad range, s.t. one might actually need a tuple of Definition Language, Typeface, Style, and applicable range of sizes. Happy to try to help with this, but there better be some real typographic experts involved. We do not want to create a top-level type only to find ourselves locked into one particular kind of solution (even if it is open source rather than vendor-specific). I might still be able to carry on a useful conversation with such an expert, but it has been a very long time since I've had to do that, things have changed, and I've forgotten a lot of what I once knew. john From duerst@it.aoyama.ac.jp Mon Nov 7 22:18:52 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F3F21F8CDA for ; Mon, 7 Nov 2011 22:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.542 X-Spam-Level: X-Spam-Status: No, score=-99.542 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BclpHd-VLMdj for ; Mon, 7 Nov 2011 22:18:52 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E45CF21F8CD9 for ; Mon, 7 Nov 2011 22:18:50 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pA86Ia3G021016 for ; Tue, 8 Nov 2011 15:18:37 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2f06_255d_7dfd9568_09d1_11e1_9134_001d096c566a; Tue, 08 Nov 2011 15:18:36 +0900 Received: from [IPv6:::1] ([133.2.210.1]:56388) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 8 Nov 2011 15:18:41 +0900 Message-ID: <4EB8C9AD.5000809@it.aoyama.ac.jp> Date: Tue, 08 Nov 2011 15:18:21 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <4EB86078.8070904@stpeter.im> In-Reply-To: <4EB86078.8070904@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 06:18:52 -0000 Hello Peter, others, On 2011/11/08 7:49, Peter Saint-Andre wrote: > In talking with folks at the W3C meeting last week, I heard yet again of > interest in defining a Content Type for fonts. Would anyone active in > the IETF Applications Area want to work on such a spec? And do folks > here think a new top-level content type is needed for fonts? Yes, I think it's a good thing to do. But given the history of a top-level font/ type (see e.g. a report at http://lists.w3.org/Archives/Public/www-font/2009JulSep/1069.html), one other important question you should ask is: Is there anybody strongly opposed to such a top level type. If we can assure people at the W3C and elsewhere that we welcome a proposal for such a top level type, then it might even be that we don't need to be involved directly (although having somebody with apps experience involved could help). Regards, Martin. From duerst@it.aoyama.ac.jp Mon Nov 7 22:49:56 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8086511E80F4 for ; Mon, 7 Nov 2011 22:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.252 X-Spam-Level: X-Spam-Status: No, score=-99.252 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3, 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 IWBd8jp1-DBW for ; Mon, 7 Nov 2011 22:49:55 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 73E3911E80F0 for ; Mon, 7 Nov 2011 22:49:55 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pA86neZr000480 for ; Tue, 8 Nov 2011 15:49:41 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2206_18d8_d4ea43e0_09d5_11e1_9457_001d096c5782; Tue, 08 Nov 2011 15:49:40 +0900 Received: from [IPv6:::1] ([133.2.210.1]:59653) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 8 Nov 2011 15:49:44 +0900 Message-ID: <4EB8D0F4.9020907@it.aoyama.ac.jp> Date: Tue, 08 Nov 2011 15:49:24 +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: John C Klensin References: <4EB86078.8070904@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 06:49:56 -0000 Hello John, On 2011/11/08 8:32, John C Klensin wrote: > > > --On Monday, November 07, 2011 15:49 -0700 Peter Saint-Andre > wrote: > >> In talking with folks at the W3C meeting last week, I heard >> yet again of interest in defining a Content Type for fonts. >> Would anyone active in the IETF Applications Area want to work >> on such a spec? And do folks here think a new top-level >> content type is needed for fonts? > > Well, I think that a top-level would be in order -- these are > really different from the existing types. Things may have > changed, but my recollection from when I had some exposure to > them in the early 90s is that there are a bunch of font > definition languages out there. Unless all but one has > atrophied or one could pick one to go with the top-level type, > there is going to be a messy problem in which one either needs > to have > font/DefinitionLanguage fonttype=Foo > or another round of > font/Foo+DefinitionLanguage > I'd hope we could avoid the latter, especially since some of > those languages and definitional methods don't scale over a very > broad range, s.t. one might actually need a tuple of Definition > Language, Typeface, Style, and applicable range of sizes. > > Happy to try to help with this, but there better be some real > typographic experts involved. We do not want to create a > top-level type only to find ourselves locked into one particular > kind of solution (even if it is open source rather than > vendor-specific). I might still be able to carry on a useful > conversation with such an expert, but it has been a very long > time since I've had to do that, things have changed, and I've > forgotten a lot of what I once knew. There is no need to overengineer this stuff. Like all other types, it's simply a top level type, and a subtype. A very rough approximation of what could end up in the subtype can be found here: http://en.wikipedia.org/wiki/Category:Font_formats. If some kind of 'Definition Language' is used inside a font format, then that's just something under the hood. My understanding is that some popular formats such as OpenType essentially are mergers resulting from the "Definition Language" wars in the early 1990. Also, typeface, style, and applicable range of sizes shouldn't be necessary as part of the mime type because it's part of the content. Some such parameters were proposed in http://tools.ietf.org/html/draft-singer-font-mime-00, and may still be necessary, but not as much as 7 years ago, when you apparently shot down the proposal (see http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html). So if the font experts say they really need a parameter, we'll keep it, but we don't have to make thing more complicated than necessary in advance. The only RFC that defined a new top-level type is RFC 2077 (http://tools.ietf.org/html/rfc2077). It's rather short, and I expect the font/ RFC to be even shorter unless it also includes some registrations for actual subtypes (I'd probably do it in two separate documents, one for the top-level type and another for some low hanging subtypes, but I'll leave the decision to whoever does the actual work.) Regards, Martin. From GK@ninebynine.org Tue Nov 8 03:32:23 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7BC21F84D6 for ; Tue, 8 Nov 2011 03:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 suH4LjYaMvzR for ; Tue, 8 Nov 2011 03:32:23 -0800 (PST) Received: from relay9.mail.ox.ac.uk (relay9.mail.ox.ac.uk [163.1.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id D76A821F843E for ; Tue, 8 Nov 2011 03:32:22 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay9.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RNjub-0000QR-UZ; Tue, 08 Nov 2011 11:32:17 +0000 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RNjub-0006pZ-73; Tue, 08 Nov 2011 11:32:17 +0000 Message-ID: <4EB8E7FA.5030406@ninebynine.org> Date: Tue, 08 Nov 2011 08:27:38 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4EB86078.8070904@stpeter.im> In-Reply-To: <4EB86078.8070904@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 11:32:23 -0000 It's not clear to me what purpose would be served that cannot be handled perfectly adequately by application/* My understanding (or impression over the years) was that the top-level MIME type was a kind of high-level dispatch indicator to a device capable of rendering or otherwise presenting the broad kind of content, with application/* serving for types that needed further processing before they might meaningfully be considered for presentation If I receive a font/* file, what might I do with it that is different from any other application/* type of file? #g -- On 07/11/2011 22:49, Peter Saint-Andre wrote: > In talking with folks at the W3C meeting last week, I heard yet again of > interest in defining a Content Type for fonts. Would anyone active in > the IETF Applications Area want to work on such a spec? And do folks > here think a new top-level content type is needed for fonts? > > Peter > From eburger@standardstrack.com Tue Nov 8 06:15:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232ED21F8B0C for ; Tue, 8 Nov 2011 06:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.653 X-Spam-Level: X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 e7a-EWIt0diZ for ; Tue, 8 Nov 2011 06:15:37 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0CB21F8B0B for ; Tue, 8 Nov 2011 06:15:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=Atpds0AOqM/Y1IKwBj1VCePc3SOrJab8KMfIYGQP45b9myZPmu3avCvLGjKzsZdxnSW3Mf8FgHN/PiIO42HWC3tQ57ImUTDklDyH321F52SyMpsAO1C2cZ4uZh+CLzQE; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:50437 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RNmSe-0005ml-1D for apps-discuss@ietf.org; Tue, 08 Nov 2011 06:15:36 -0800 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-26-1004633302; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 8 Nov 2011 09:15:33 -0500 In-Reply-To: <4EB8E7FA.5030406@ninebynine.org> To: "apps-discuss@ietf.org Discuss" References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> Message-Id: X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 14:15:38 -0000 --Apple-Mail-26-1004633302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Agreed. On Nov 8, 2011, at 3:27 AM, Graham Klyne wrote: > It's not clear to me what purpose would be served that cannot be = handled perfectly adequately by application/* >=20 > My understanding (or impression over the years) was that the top-level = MIME type was a kind of high-level dispatch indicator to a device = capable of rendering or otherwise presenting the broad kind of content, = with application/* serving for types that needed further processing = before they might meaningfully be considered for presentation >=20 > If I receive a font/* file, what might I do with it that is different = from any other application/* type of file? >=20 > #g > -- >=20 >=20 > On 07/11/2011 22:49, Peter Saint-Andre wrote: >> In talking with folks at the W3C meeting last week, I heard yet again = of >> interest in defining a Content Type for fonts. Would anyone active in >> the IETF Applications Area want to work on such a spec? And do folks >> here think a new top-level content type is needed for fonts? >>=20 >> Peter >>=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-26-1004633302 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMTA4MTQxNTMzWjAjBgkqhkiG9w0BCQQxFgQU nUtHvc6FSIAZHhgBvXYWxF+WjAwwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAjZ6Y9YaJtDNxsFAV4UXIqGYDZ7t+xMYtKZNfKJIZmXZLBYDhE8/K l8VDV7x1vjAf91dCYmFUeo7vi7R/MhcDi34uypLR/xg+1xOCq/YR9UkhQ6W34gXiLRvAnq0W8jaF L4mUS8pL+efbbilUIJTMrKSc3vkAO5BsHDJ0I7rJ2NTzgRCejKyDHqUsI6iu6yR/kFj5CWPBbJRj ul8gp+pUU7fgwquj61ZT3AzN8L249l+4q5j4FYPFpslN9ZEMFqjpPmrdngxv3YIK6ciVeZ2Ko1uT ucIDjM6jKCfhEHUPVOW7MwfJfwNjvn7Y/Q1IEcyRMJYn64Sv7Njxbhc/gfq/qgAAAAAAAA== --Apple-Mail-26-1004633302-- From eburger@standardstrack.com Tue Nov 8 06:20:13 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353D221F8CC9 for ; Tue, 8 Nov 2011 06:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.352 X-Spam-Level: X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, 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 WTMvxvEsuR7X for ; Tue, 8 Nov 2011 06:20:12 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3F821F8CCB for ; Tue, 8 Nov 2011 06:20:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=0LrUs+n4saj0gym/sVud+fFlRYQLCawqqQEaxOe0MBE4Ffu6V12LHWCIRFt8AOBPPjG6m5HjEAScvanG+Eb4BpbC86AWhVh1fbbeOF5+PbfY9c30u1OqYSd0mfxkGAGl; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:50468 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RNmX4-0002Vd-UX for apps-discuss@ietf.org; Tue, 08 Nov 2011 06:20:11 -0800 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-27-1004908240; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 8 Nov 2011 09:20:08 -0500 In-Reply-To: <4EB8D0F4.9020907@it.aoyama.ac.jp> To: "apps-discuss@ietf.org Discuss" References: <4EB86078.8070904@stpeter.im> <4EB8D0F4.9020907@it.aoyama.ac.jp> Message-Id: <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 14:20:13 -0000 --Apple-Mail-27-1004908240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Is the idea we would see something like font/Times or one of=20 font/PostScript/Times font/TrueType/Times font/OpenType/Times font/METATYPE/Times or one of font/Times/PostScript font/Times/TrueType font/Times/OpenType font/Times/METATYPE One cannot just say it's font/* and assume it is an opaque container, as = one could see battles over the latter examples. On Nov 8, 2011, at 1:49 AM, Martin J. D=FCrst wrote: > Hello John, >=20 > On 2011/11/08 8:32, John C Klensin wrote: >>=20 >>=20 >> --On Monday, November 07, 2011 15:49 -0700 Peter Saint-Andre >> wrote: >>=20 >>> In talking with folks at the W3C meeting last week, I heard >>> yet again of interest in defining a Content Type for fonts. >>> Would anyone active in the IETF Applications Area want to work >>> on such a spec? And do folks here think a new top-level >>> content type is needed for fonts? >>=20 >> Well, I think that a top-level would be in order -- these are >> really different from the existing types. Things may have >> changed, but my recollection from when I had some exposure to >> them in the early 90s is that there are a bunch of font >> definition languages out there. Unless all but one has >> atrophied or one could pick one to go with the top-level type, >> there is going to be a messy problem in which one either needs >> to have >> font/DefinitionLanguage fonttype=3DFoo >> or another round of >> font/Foo+DefinitionLanguage >> I'd hope we could avoid the latter, especially since some of >> those languages and definitional methods don't scale over a very >> broad range, s.t. one might actually need a tuple of Definition >> Language, Typeface, Style, and applicable range of sizes. >>=20 >> Happy to try to help with this, but there better be some real >> typographic experts involved. We do not want to create a >> top-level type only to find ourselves locked into one particular >> kind of solution (even if it is open source rather than >> vendor-specific). I might still be able to carry on a useful >> conversation with such an expert, but it has been a very long >> time since I've had to do that, things have changed, and I've >> forgotten a lot of what I once knew. >=20 > There is no need to overengineer this stuff. Like all other types, = it's simply a top level type, and a subtype. A very rough approximation = of what could end up in the subtype can be found here: = http://en.wikipedia.org/wiki/Category:Font_formats. >=20 > If some kind of 'Definition Language' is used inside a font format, = then that's just something under the hood. My understanding is that some = popular formats such as OpenType essentially are mergers resulting from = the "Definition Language" wars in the early 1990. Also, typeface, style, = and applicable range of sizes shouldn't be necessary as part of the mime = type because it's part of the content. >=20 > Some such parameters were proposed in = http://tools.ietf.org/html/draft-singer-font-mime-00, and may still be = necessary, but not as much as 7 years ago, when you apparently shot down = the proposal (see = http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html). So if = the font experts say they really need a parameter, we'll keep it, but we = don't have to make thing more complicated than necessary in advance. >=20 > The only RFC that defined a new top-level type is RFC 2077 = (http://tools.ietf.org/html/rfc2077). It's rather short, and I expect = the font/ RFC to be even shorter unless it also includes some = registrations for actual subtypes (I'd probably do it in two separate = documents, one for the top-level type and another for some low hanging = subtypes, but I'll leave the decision to whoever does the actual work.) >=20 >=20 > Regards, Martin. >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-27-1004908240 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMTA4MTQyMDA4WjAjBgkqhkiG9w0BCQQxFgQU sb+YKw7IuQGm3Is3ZEtc5/g0t7kwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAQObOidm77hUWnbDPed76y7qFgnrH7U+EgH1lh+ZqPj+d6qXzX8SS mUmmNElnk+eQgTfa1nA07D7WXY6UIY/pmZojF7AkAloh34svTrzXd8JB/BmszopZ6sp4vmAt/fBc X3PGA+Auhstoy3qx6aTGnxiTH1FuiVYKIhik6iId65wN943nmwIH0wP2h2IUl7lcwS0VJblzazKm qbDr6lI7OHoS0gto5x519vhIgRLE00bWkAG7xzuq3/Pgvto4Ht8CrkOPkBILcxlGW6UxHYtkpNID 6eYp4SqGhpAsPgHkdJnA3YGSahdwqwXMGcl/E3IZ12qUJEEfNJhnNgiq3h1QBwAAAAAAAA== --Apple-Mail-27-1004908240-- From ddooss@wp.pl Tue Nov 8 04:42:59 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F9621F8C4E for ; Tue, 8 Nov 2011 04:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] 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 SwgLzrkHl2xr for ; Tue, 8 Nov 2011 04:42:58 -0800 (PST) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by ietfa.amsl.com (Postfix) with ESMTP id 34B2021F8AF3 for ; Tue, 8 Nov 2011 04:42:58 -0800 (PST) Received: (wp-smtpd smtp.wp.pl 2878 invoked from network); 8 Nov 2011 13:42:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1320756176; bh=QlvrTFb/wvUHODGHNSfBm8CUHXG5Preq2cm+D/ODUok=; h=From:To:Subject; b=dgFvIyOKExMzEQTQpfu21GVzp6JGyDeZifyxDN9NYWR1MBBp697T9NNSvAm77VgsL H0WhuSofG4iNummnbOugYh22XxRGsbg3rwYxk8d323pkdNOe3t+Txr8eAshf8y2X18 tMSuJpuVchBWpFK3Fb7SmtSQWOvz+TieUcEupFJY= Received: from 87-205-152-25.adsl.inetia.pl (HELO [192.168.1.1]) (ddooss@[87.205.152.25]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 8 Nov 2011 13:42:56 +0100 Message-ID: <4EB923CF.7080600@wp.pl> Date: Tue, 08 Nov 2011 13:42:55 +0100 From: Dominik Tomaszuk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000006 [QbaA] X-Mailman-Approved-At: Tue, 08 Nov 2011 08:41:40 -0800 Subject: [apps-discuss] draft-saintandre-json-namespaces-00 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 12:42:59 -0000 Hi Peter, Clark Notation can sometimes be too heavy, especially when namespaces are placed in many keys. I propose to give possibility to declare namespace. For instance: { "$namespaces": { "foo": "http://example.com/foo" }, "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "{$foo}bar":"baz" } This capability allows JSON documents to be lightweight. Best regards, Dominik Tomaszuk From paul.hoffman@vpnc.org Tue Nov 8 09:05:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949E311E8081 for ; Tue, 8 Nov 2011 09:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 SYvGFmQIDWLE for ; Tue, 8 Nov 2011 09:05:10 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F382511E807F for ; Tue, 8 Nov 2011 09:05:09 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pA8H58ms041111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2011 10:05:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4EB923CF.7080600@wp.pl> Date: Tue, 8 Nov 2011 09:05:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> References: <4EB923CF.7080600@wp.pl> To: apps-discuss Discuss X-Mailer: Apple Mail (2.1251.1) Cc: Dominik Tomaszuk Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:05:10 -0000 On Nov 8, 2011, at 4:42 AM, Dominik Tomaszuk wrote: > Clark Notation can sometimes be too heavy, especially when namespaces = are placed in many keys. +1 > I propose to give possibility to declare namespace. -1. Actually, -10. While somewhat useful for XML, namespaces have also = proven to cause many headaches for corner cases. Please strongly consider using a much simpler naming scheme, such as = "names with periods in them". --Paul Hoffman From julian.reschke@gmx.de Tue Nov 8 09:05:16 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0911E80A2 for ; Tue, 8 Nov 2011 09:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.159 X-Spam-Level: X-Spam-Status: No, score=-104.159 tagged_above=-999 required=5 tests=[AWL=-1.560, 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 j3RfEHXOWQCf for ; Tue, 8 Nov 2011 09:05:15 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1C14911E809B for ; Tue, 8 Nov 2011 09:05:14 -0800 (PST) Received: (qmail invoked by alias); 08 Nov 2011 17:05:13 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp071) with SMTP; 08 Nov 2011 18:05:13 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18scIIAfIwsdOFWgo48Td2xzkkF1Ttr0Sip7z0xrN GP+Coe6dfozgdu Message-ID: <4EB96142.5070305@gmx.de> Date: Tue, 08 Nov 2011 18:05:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dominik Tomaszuk References: <4EB923CF.7080600@wp.pl> In-Reply-To: <4EB923CF.7080600@wp.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:05:16 -0000 On 2011-11-08 13:42, Dominik Tomaszuk wrote: > Hi Peter, > > Clark Notation can sometimes be too heavy, especially when namespaces > are placed in many keys. I propose to give possibility to declare > namespace. For instance: > ... This copies a design pattern that many people hate in XML namespaces (*not* including myself...). Also, if compactness is an issue, the obvious answer is to gzip the payload. Best regards, Julian From mnot@mnot.net Tue Nov 8 09:11:14 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3691311E80BB for ; Tue, 8 Nov 2011 09:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E3uiSZyAXy9 for ; Tue, 8 Nov 2011 09:10:53 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 434CC21F8AF0 for ; Tue, 8 Nov 2011 09:10:51 -0800 (PST) Received: from [10.6.129.78] (unknown [64.39.4.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 77E8922E253; Tue, 8 Nov 2011 12:10:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> Date: Tue, 8 Nov 2011 11:10:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) Cc: Dominik Tomaszuk , apps-discuss Discuss Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:11:14 -0000 +1 to Paul's -10. My take on it: http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json Let's keep this simple and avoid repeating the mistakes of XML, OK? On 08/11/2011, at 11:05 AM, Paul Hoffman wrote: > On Nov 8, 2011, at 4:42 AM, Dominik Tomaszuk wrote: >=20 >> Clark Notation can sometimes be too heavy, especially when namespaces = are placed in many keys. >=20 > +1 >=20 >> I propose to give possibility to declare namespace. >=20 > -1. Actually, -10. While somewhat useful for XML, namespaces have also = proven to cause many headaches for corner cases. >=20 > Please strongly consider using a much simpler naming scheme, such as = "names with periods in them". >=20 > --Paul Hoffman >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Nov 8 09:15:03 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1ED411E80B4 for ; Tue, 8 Nov 2011 09:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, 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 5uwvWLwvz0lu for ; Tue, 8 Nov 2011 09:15:02 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE1911E80B7 for ; Tue, 8 Nov 2011 09:15:02 -0800 (PST) Received: from [10.6.129.78] (unknown [64.39.4.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A0D5822E258; Tue, 8 Nov 2011 12:15:01 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> Date: Tue, 8 Nov 2011 11:15:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> References: <4EB86078.8070904@stpeter.im> <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1251.1) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:15:03 -0000 Oh, I had thought it would be font/PostScript font/TrueType i.e., NOT identifying the specific typeface in use. After all, we don't = have text/html/home-page, do we? BTW, before naming this thing, please have a discussion with a = typographer about the difference between a "font" and a "typeface."=20 (My wife, who teaches typography, would beat me if I didn't make that = distinction) Cheers, On 08/11/2011, at 8:20 AM, Eric Burger wrote: > Is the idea we would see something like >=20 > font/Times >=20 > or one of=20 >=20 > font/PostScript/Times > font/TrueType/Times > font/OpenType/Times > font/METATYPE/Times >=20 > or one of >=20 > font/Times/PostScript > font/Times/TrueType > font/Times/OpenType > font/Times/METATYPE >=20 > One cannot just say it's font/* and assume it is an opaque container, = as one could see battles over the latter examples. >=20 > On Nov 8, 2011, at 1:49 AM, Martin J. D=FCrst wrote: >=20 >> Hello John, >>=20 >> On 2011/11/08 8:32, John C Klensin wrote: >>>=20 >>>=20 >>> --On Monday, November 07, 2011 15:49 -0700 Peter Saint-Andre >>> wrote: >>>=20 >>>> In talking with folks at the W3C meeting last week, I heard >>>> yet again of interest in defining a Content Type for fonts. >>>> Would anyone active in the IETF Applications Area want to work >>>> on such a spec? And do folks here think a new top-level >>>> content type is needed for fonts? >>>=20 >>> Well, I think that a top-level would be in order -- these are >>> really different from the existing types. Things may have >>> changed, but my recollection from when I had some exposure to >>> them in the early 90s is that there are a bunch of font >>> definition languages out there. Unless all but one has >>> atrophied or one could pick one to go with the top-level type, >>> there is going to be a messy problem in which one either needs >>> to have >>> font/DefinitionLanguage fonttype=3DFoo >>> or another round of >>> font/Foo+DefinitionLanguage >>> I'd hope we could avoid the latter, especially since some of >>> those languages and definitional methods don't scale over a very >>> broad range, s.t. one might actually need a tuple of Definition >>> Language, Typeface, Style, and applicable range of sizes. >>>=20 >>> Happy to try to help with this, but there better be some real >>> typographic experts involved. We do not want to create a >>> top-level type only to find ourselves locked into one particular >>> kind of solution (even if it is open source rather than >>> vendor-specific). I might still be able to carry on a useful >>> conversation with such an expert, but it has been a very long >>> time since I've had to do that, things have changed, and I've >>> forgotten a lot of what I once knew. >>=20 >> There is no need to overengineer this stuff. Like all other types, = it's simply a top level type, and a subtype. A very rough approximation = of what could end up in the subtype can be found here: = http://en.wikipedia.org/wiki/Category:Font_formats. >>=20 >> If some kind of 'Definition Language' is used inside a font format, = then that's just something under the hood. My understanding is that some = popular formats such as OpenType essentially are mergers resulting from = the "Definition Language" wars in the early 1990. Also, typeface, style, = and applicable range of sizes shouldn't be necessary as part of the mime = type because it's part of the content. >>=20 >> Some such parameters were proposed in = http://tools.ietf.org/html/draft-singer-font-mime-00, and may still be = necessary, but not as much as 7 years ago, when you apparently shot down = the proposal (see = http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html). So if = the font experts say they really need a parameter, we'll keep it, but we = don't have to make thing more complicated than necessary in advance. >>=20 >> The only RFC that defined a new top-level type is RFC 2077 = (http://tools.ietf.org/html/rfc2077). It's rather short, and I expect = the font/ RFC to be even shorter unless it also includes some = registrations for actual subtypes (I'd probably do it in two separate = documents, one for the top-level type and another for some low hanging = subtypes, but I'll leave the decision to whoever does the actual work.) >>=20 >>=20 >> Regards, Martin. >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Tue Nov 8 09:38:44 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E45D21F8B75 for ; Tue, 8 Nov 2011 09:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 LFKZhb5RaCvT for ; Tue, 8 Nov 2011 09:38:42 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 22EF921F8B73 for ; Tue, 8 Nov 2011 09:38:42 -0800 (PST) Received: from dhcp-64-101-72-243.cisco.com (unknown [64.101.72.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ABFD9420C9; Tue, 8 Nov 2011 10:44:34 -0700 (MST) Message-ID: <4EB9691F.1080400@stpeter.im> Date: Tue, 08 Nov 2011 10:38:39 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <4EB86078.8070904@stpeter.im> <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> In-Reply-To: <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:38:44 -0000 On 11/8/11 10:15 AM, Mark Nottingham wrote: > Oh, I had thought it would be > > font/PostScript > font/TrueType > > i.e., NOT identifying the specific typeface in use. After all, we don't have text/html/home-page, do we? > > BTW, before naming this thing, please have a discussion with a typographer about the difference between a "font" and a "typeface." > > (My wife, who teaches typography, would beat me if I didn't make that distinction) Well, we wouldn't want that! :) Clearly I need to follow up with the folks I talked with at the W3C meeting to learn more about their requirements. /psa From julian.reschke@gmx.de Tue Nov 8 10:13:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA49C11E8095 for ; Tue, 8 Nov 2011 10:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.124 X-Spam-Level: X-Spam-Status: No, score=-104.124 tagged_above=-999 required=5 tests=[AWL=-1.525, 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 GQkG92BlxItu for ; Tue, 8 Nov 2011 10:13:01 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B1D7911E807F for ; Tue, 8 Nov 2011 10:13:00 -0800 (PST) Received: (qmail invoked by alias); 08 Nov 2011 18:12:58 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp068) with SMTP; 08 Nov 2011 19:12:58 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1++SMJekQK+wNHa+j6EMPjb0nJk8V5vOz3JseHuLu Msx1vVgNh/5u91 Message-ID: <4EB97122.7010206@gmx.de> Date: Tue, 08 Nov 2011 19:12:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Mark Nottingham References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> In-Reply-To: <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Paul Hoffman , apps-discuss Discuss , Dominik Tomaszuk Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 18:13:02 -0000 On 2011-11-08 18:10, Mark Nottingham wrote: > +1 to Paul's -10. > > My take on it: > > http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json > > Let's keep this simple and avoid repeating the mistakes of XML, OK? > ... Well, there are two different issues: 1) Using URIs for disambiguation, and 2) Using a prefix-URI mapping to make things more compact. The reasons for 2) would be readability and compactness, but would make processing the content much more complex. I don't believe it's needed here. Re 1) -- well, if you have URI-based identifiers to start with, there's little choice. You could declare the problem to be an SOP, in which case you shouldn't even look at the draft. Or one could introduce yet another indirection mechanism (-> 2). Best regards, Julian From ietfc@btconnect.com Tue Nov 8 10:45:03 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9409A1F0C3B for ; Tue, 8 Nov 2011 10:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, J_CHICKENPOX_83=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 NgicXsqM6Lr2 for ; Tue, 8 Nov 2011 10:45:03 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8280B1F0C35 for ; Tue, 8 Nov 2011 10:45:01 -0800 (PST) Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr10.btconnect.com with SMTP id FAE21545; Tue, 08 Nov 2011 18:44:48 +0000 (GMT) Message-ID: <006901cc9e3d$5d0e1760$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Mark Nottingham" , "Eric Burger" References: <4EB86078.8070904@stpeter.im><4EB8D0F4.9020907@it.aoyama.ac.jp><555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> Date: Tue, 8 Nov 2011 18:39:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4EB9789F.0034, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.8.180315:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4EB978A1.0115,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 18:45:03 -0000 ----- Original Message ----- From: "Mark Nottingham" To: "Eric Burger" Cc: Sent: Tuesday, November 08, 2011 6:15 PM Oh, I had thought it would be font/PostScript font/TrueType i.e., NOT identifying the specific typeface in use. After all, we don't have text/html/home-page, do we? BTW, before naming this thing, please have a discussion with a typographer about the difference between a "font" and a "typeface." and typeface, versus typeface family (which, I suspect, is what many mean when they say 'font') Tom Petch (My wife, who teaches typography, would beat me if I didn't make that distinction) Cheers, On 08/11/2011, at 8:20 AM, Eric Burger wrote: > Is the idea we would see something like > > font/Times > > or one of > > font/PostScript/Times > font/TrueType/Times > font/OpenType/Times > font/METATYPE/Times > > or one of > > font/Times/PostScript > font/Times/TrueType > font/Times/OpenType > font/Times/METATYPE > > One cannot just say it's font/* and assume it is an opaque container, as one could see battles over the latter examples. > > On Nov 8, 2011, at 1:49 AM, Martin J. Dürst wrote: > >> Hello John, >> >> On 2011/11/08 8:32, John C Klensin wrote: >>> >>> >>> --On Monday, November 07, 2011 15:49 -0700 Peter Saint-Andre >>> wrote: >>> >>>> In talking with folks at the W3C meeting last week, I heard >>>> yet again of interest in defining a Content Type for fonts. >>>> Would anyone active in the IETF Applications Area want to work >>>> on such a spec? And do folks here think a new top-level >>>> content type is needed for fonts? >>> >>> Well, I think that a top-level would be in order -- these are >>> really different from the existing types. Things may have >>> changed, but my recollection from when I had some exposure to >>> them in the early 90s is that there are a bunch of font >>> definition languages out there. Unless all but one has >>> atrophied or one could pick one to go with the top-level type, >>> there is going to be a messy problem in which one either needs >>> to have >>> font/DefinitionLanguage fonttype=Foo >>> or another round of >>> font/Foo+DefinitionLanguage >>> I'd hope we could avoid the latter, especially since some of >>> those languages and definitional methods don't scale over a very >>> broad range, s.t. one might actually need a tuple of Definition >>> Language, Typeface, Style, and applicable range of sizes. >>> >>> Happy to try to help with this, but there better be some real >>> typographic experts involved. We do not want to create a >>> top-level type only to find ourselves locked into one particular >>> kind of solution (even if it is open source rather than >>> vendor-specific). I might still be able to carry on a useful >>> conversation with such an expert, but it has been a very long >>> time since I've had to do that, things have changed, and I've >>> forgotten a lot of what I once knew. >> >> There is no need to overengineer this stuff. Like all other types, it's simply a top level type, and a subtype. A very rough approximation of what could end up in the subtype can be found here: http://en.wikipedia.org/wiki/Category:Font_formats. >> >> If some kind of 'Definition Language' is used inside a font format, then that's just something under the hood. My understanding is that some popular formats such as OpenType essentially are mergers resulting from the "Definition Language" wars in the early 1990. Also, typeface, style, and applicable range of sizes shouldn't be necessary as part of the mime type because it's part of the content. >> >> Some such parameters were proposed in http://tools.ietf.org/html/draft-singer-font-mime-00, and may still be necessary, but not as much as 7 years ago, when you apparently shot down the proposal (see http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html). So if the font experts say they really need a parameter, we'll keep it, but we don't have to make thing more complicated than necessary in advance. >> >> The only RFC that defined a new top-level type is RFC 2077 (http://tools.ietf.org/html/rfc2077). It's rather short, and I expect the font/ RFC to be even shorter unless it also includes some registrations for actual subtypes (I'd probably do it in two separate documents, one for the top-level type and another for some low hanging subtypes, but I'll leave the decision to whoever does the actual work.) >> >> >> Regards, Martin. >> >> _______________________________________________ >> 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 -- Mark Nottingham http://www.mnot.net/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From evnikita2@gmail.com Tue Nov 8 11:07:02 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B007711E808B; Tue, 8 Nov 2011 11:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 Ij4Nc3NpUOAC; Tue, 8 Nov 2011 11:07:01 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19E9411E8088; Tue, 8 Nov 2011 11:07:00 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so895337bkb.31 for ; Tue, 08 Nov 2011 11:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6UcBHfe/o5H54YnC2SFHNmVveZcJoI18A8LMqDtrHyI=; b=X35gjX3fUrE6p8Tn/OU+3WvNlj8Ky1G0UuHjf9U3GTHxz83qZIXwR89/vi6r53iLIP mGHOaEiY6Su9EaugmkWFkYCoIWhSbjEfkjP69BEjcVP/6iv6DMJg6mI46Xm8uC0YbHHF lpCNdlJMdyPjH+7RfWArxayDCVBhUtbL+kwMU= Received: by 10.204.155.152 with SMTP id s24mr8287066bkw.5.1320779220072; Tue, 08 Nov 2011 11:07:00 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id fu17sm2433123bkc.9.2011.11.08.11.06.57 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 11:06:58 -0800 (PST) Message-ID: <4EB97E02.4080608@gmail.com> Date: Tue, 08 Nov 2011 21:07:46 +0200 From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: happiana@ietf.org References: <01O827GOAJG200XBUL@mauve.mrochek.com> <4EB68E47.5010807@gmx.de> In-Reply-To: <4EB68E47.5010807@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps-discuss list , draft-freed-media-type-regs@tools.ietf.org Subject: Re: [apps-discuss] [happiana] draft-freed-media-type-regs-01 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 19:07:02 -0000 Ned, all, Some additional (to Julian's) comments. In Abstract, it must be mentioned that the document obsoletes RFC 4288. I find the current text in Introduction very confusing (or irrelevant), as it is very generic and not related to media types. It should be rewritten to make clear the goal of the doc. I also concur with Julian that Historical Note should be moved in the Introduction section. In Section 3.1: when specifying the procedures for registration media types in Standards Tree, you mentioned (in terms of RFC 5226): IESG approval, Specification Required, IETF Consensus, RFC Required with IESG Approval, i.e. 4 different registration policies. Whereas they serve a variety of possible cases, I think we would benefit from a single policy which would cover all of them. I suppose it is "Specification Required with IESG Approval" that would cover the following cases: (1) IESG-approved document, (2) specification of other standards body; registration undergoing IESG approval, (3) non-IESG-approved RFCs, registration of which also undergo IESG approval. The possible cases may also be discussed, though. Section 3.3: the "vanity" naming. I may be wrong cause it may be some sort of stylistic choice, but I actually think that "personal" is enough to characterize this tree. Whereas English native speakers would understand such naming, this would be frankly difficult for those who speak English as a foreign lang. I can't manage to find Russian or Ukrainian translation of RFC 4288 to prove, but I'm sure that the said formulation is applicable in English language only, and isn't appropriate for the international-scoped document. Section 3.4: this is what Julian has already mentioned for Section 4.2. APPSAWG is obliged to bring the draft deprecating x- to BCP, so if we revising the procedures docs, we need to take it into account. I propose you remove Section 3.4 and naming convention from Section 4.2 but put a note in Appendix B referring to the RFC-to-be. I think that if we produce new version of the doc we should take into account the current practice documented as BCP (and I hope it will get BCP). At least you should note that their registration is not absolutely prohibited; I also agree that in exceptional cases they can be registered, but only if wide use is demonstrated. Section 4.2: Shouldn't it explain the differences between RFC 2045 and the given ABNF? Section 4.10: "Proposals for media types registered in the standards tree by the IETF itself MUST be published as RFCs.". Do you really mean "proposal"? Also, do we need to encourage publishing RFCs for vnd and prs registrations? Section 5.1: "Registrations in other trees MAY be sent to the list for review as well." Maybe SHOULD? Section 5.9: Do we need to leave mail-style lines in the template (I mean To: and Subject:)? Ibid: Please move the para about MacOS file types into Section 4.11. Section 6: s/RFC 3978/RFC 5378/ (and in References) Sections 6 and 8: As your document sets up the registry for +suffixes, it should contain the description as required by RFC 5226, which it currently doesn't have. Thanks, Mykyta Yevstifeyev 06.11.2011 15:40, Julian Reschke wrote: > On 2011-11-05 20:17, Ned Freed wrote: >> The revised media type registration procedure document: >> >> http://tools.ietf.org/html/draft-freed-media-type-regs-01 >> >> is in need of review. In particular, comments are solicited on >> exactly how the >> process should be modified to remove the IESG from the review process >> for >> standards tree types. (Note that the IESG needs to retain the >> authority to >> determine what external organization are qualified standards bodies >> and what >> ones are not.) >> ... > > Hi Ned, > > below are notes from a quick top-to-bottom read I just did...: > > Comments: > > - 4.2 - reg-name; it would be good to state how exactly it is more > restrictive, to reference the actual subsection of 2045 (5.1), and > maybe say why. > > - 4.2 - "X-" prefixes - this obviously should be coordinated with > Peter's document. > > - 4.2.2 - "specifies one or more separate images that require > appropriate hardware to display" - sounds a bit fine-tuned for a time > where graphics hardware was something special. (Also, what about audio > and video?? :-) > > - 4.2.8 - Structured Syntax Name Suffixes - would it make sense to > relax the standards-tree registration requirements for types that use > an existing structured syntax? (given the fact doing so makes it much > harder to do things wrong) > > - 4.3 - parameter-name; this repeats the warning about the change from > 2045, but adds "amended by RFC2231". Optimally have this in a single > place and be consistent. > > - 4.3 - maybe repeat the requirements from 2045 about > case-insensitivity and ordering? > > - 4.3 - the question about the validity to *repeat* parameters comes > up from time to time. My understanding is that it's understood to be > invalid, but I don't think any spec says that yet. Maybe it should be > noted here because it affects definitions of new parameters? > > - 4.11 - Mac OS File Type - is this still useful information? > Minimally, to avid confusion, it should be stated that this only > affects ancient versions of MacOS (right?) > > - 5.8 - "When review is required, a change request may be denied if it > renders entities that were valid under the previous definition invalid > under the new definition." - see > - two questions: > > 1) Is "valid" to be read as "processable" or as "conforming"? For > instance, HTML5 makes many things invalid that were valid before, but > recipients still need to process them. > > 2) "may be denied" is very vague? What are the guidelines? Do we have > any? > > - References - The spec has a normative reference to RFC 3023, which > in turn has a reference to RFC 2048, which this document is obsoleting > (via 4288); do we really need a normative reference here? (maybe this > can be fixed by processing this one in sync with 3023bis)? > > > Editorial: > > - Boilerplate - Maybe move the "Historical Note" down into the > "Introduction" section? (not only for being easier to cite in the future) > > - Boilerplate - I always recommend to have an Editorial Note on the > front page telling reviewers where to send feedback. > > - 5.2 - do items 1) and 2) apply to "Specification Required" process? > The way it's formatted is slightly confusing. > > - Throughout - The spec mixes uppercase and lowercase RFC2119 terms, > and it's not totally clear what the "force" of the lowercase ones is. > In many cases this can be avoided by substituting "MAY" by "can" etc. > > > Nits: > > - 5.2 - s/[RFC2026] section 6.5.4/Section 6.5.4 of [RFC206]/ > > - References - RFC4234 -> RFC 5234 > > - References - in the reference for RFC2231, there's a line break that > shouldn't be there (this may be a problem in the > xml.resource.org-supplied reference, but still...) > > > Best regards, Julian > _______________________________________________ > happiana mailing list > happiana@ietf.org > https://www.ietf.org/mailman/listinfo/happiana > From julian.reschke@gmx.de Tue Nov 8 11:10:55 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1975321F8A64 for ; Tue, 8 Nov 2011 11:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.94 X-Spam-Level: X-Spam-Status: No, score=-103.94 tagged_above=-999 required=5 tests=[AWL=-1.641, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 cp-gBEX85Jxy for ; Tue, 8 Nov 2011 11:10:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 34F6B1F0C3D for ; Tue, 8 Nov 2011 11:10:54 -0800 (PST) Received: (qmail invoked by alias); 08 Nov 2011 19:10:40 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp008) with SMTP; 08 Nov 2011 20:10:40 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18jGU5bT/ojZctpDFv2PMYOw5fllh6Le3Wu3RR2yH bObnS1FPfZAEht Message-ID: <4EB97EA8.5020003@gmx.de> Date: Tue, 08 Nov 2011 20:10:32 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsiki?= References: <01O827GOAJG200XBUL@mauve.mrochek.com> <4EB68E47.5010807@gmx.de> <4EB97E02.4080608@gmail.com> In-Reply-To: <4EB97E02.4080608@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: happiana@ietf.org, Apps-discuss list , draft-freed-media-type-regs@tools.ietf.org Subject: Re: [apps-discuss] [happiana] draft-freed-media-type-regs-01 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 19:10:55 -0000 On 2011-11-08 20:07, "Mykyta Yevstifeyev (Ğœ. ЄвÑтіфеєв)" wrote: > Ned, all, > > Some additional (to Julian's) comments. > > In Abstract, it must be mentioned that the document obsoletes RFC 4288. No. But maybe in the introduction (with a forward reference to the Changes appendix). > ... Best regards, Julian From mnot@mnot.net Tue Nov 8 11:11:00 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA6411E8086 for ; Tue, 8 Nov 2011 11:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 60dOtzoAY4td for ; Tue, 8 Nov 2011 11:11:00 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D92B911E808F for ; Tue, 8 Nov 2011 11:10:59 -0800 (PST) Received: from [10.6.129.78] (unknown [64.39.4.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DE85522E254; Tue, 8 Nov 2011 14:10:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <4EB97122.7010206@gmx.de> Date: Tue, 8 Nov 2011 13:10:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , apps-discuss Discuss , Dominik Tomaszuk Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 19:11:00 -0000 I don't think URIs should be used for this. On 08/11/2011, at 12:12 PM, Julian Reschke wrote: > On 2011-11-08 18:10, Mark Nottingham wrote: >> +1 to Paul's -10. >>=20 >> My take on it: >>=20 >> http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json >>=20 >> Let's keep this simple and avoid repeating the mistakes of XML, OK? >> ... >=20 > Well, there are two different issues: >=20 > 1) Using URIs for disambiguation, and >=20 > 2) Using a prefix-URI mapping to make things more compact. >=20 > The reasons for 2) would be readability and compactness, but would = make processing the content much more complex. I don't believe it's = needed here. >=20 > Re 1) -- well, if you have URI-based identifiers to start with, = there's little choice. You could declare the problem to be an SOP, in = which case you shouldn't even look at the draft. Or one could introduce = yet another indirection mechanism (-> 2). >=20 > Best regards, Julian -- Mark Nottingham http://www.mnot.net/ From evnikita2@gmail.com Tue Nov 8 11:15:14 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477F821F8B02 for ; Tue, 8 Nov 2011 11:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.343 X-Spam-Level: X-Spam-Status: No, score=-3.343 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aKeSC7EAns0v for ; Tue, 8 Nov 2011 11:15:13 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3882621F8B01 for ; Tue, 8 Nov 2011 11:15:13 -0800 (PST) Received: by faas12 with SMTP id s12so1074460faa.31 for ; Tue, 08 Nov 2011 11:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=bjzIq9FFEBfzONrISs0uwHvJd9CA70nHWIWylPDNk/U=; b=OSuzBqb1WHwopiTh5okLzMPwFpzAKuUHc4a6OOFO/xP3eOK+Rn7VkYUfRFMSU0zRJa /3d8aoJmqw7BEQHipqTkhZJPxCheoLNWyj9he4vgzYziD/0stBP5+/KGeyNooDk48l+W uJ6y8EOyJ+3D7YaE98q6Le54N19eNywClON8A= Received: by 10.223.76.66 with SMTP id b2mr57966264fak.15.1320779712330; Tue, 08 Nov 2011 11:15:12 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id d22sm3289074fad.19.2011.11.08.11.15.10 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 11:15:11 -0800 (PST) Message-ID: <4EB97FEF.5060300@gmail.com> Date: Tue, 08 Nov 2011 21:15:59 +0200 From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020404020005090008070403" Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 19:15:14 -0000 This is a multi-part message in MIME format. --------------020404020005090008070403 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit +1. From RFC 2046: > The "application" media type is to be used for discrete data which do > not fit in any of the other categories, and particularly for data to > be processed by some type of application program. This is > information which must be processed by an application before it is > viewable or usable by a user. Font files are processed by applications, and they are processed before the text with some font is visible to user. That's not the case for new content type. Mykyta Yevstifeyev 08.11.2011 16:15, Eric Burger wrote: > Agreed. > > On Nov 8, 2011, at 3:27 AM, Graham Klyne wrote: > >> It's not clear to me what purpose would be served that cannot be handled perfectly adequately by application/* >> >> My understanding (or impression over the years) was that the top-level MIME type was a kind of high-level dispatch indicator to a device capable of rendering or otherwise presenting the broad kind of content, with application/* serving for types that needed further processing before they might meaningfully be considered for presentation >> >> If I receive a font/* file, what might I do with it that is different from any other application/* type of file? >> >> #g >> -- >> >> >> On 07/11/2011 22:49, Peter Saint-Andre wrote: >>> In talking with folks at the W3C meeting last week, I heard yet again of >>> interest in defining a Content Type for fonts. Would anyone active in >>> the IETF Applications Area want to work on such a spec? And do folks >>> here think a new top-level content type is needed for fonts? >>> >>> Peter >>> >> _______________________________________________ >> 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 --------------020404020005090008070403 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit +1. From RFC 2046:

   The "application" media type is to be used for discrete data which do
   not fit in any of the other categories, and particularly for data to
   be processed by some type of application program.  This is
   information which must be processed by an application before it is
   viewable or usable by a user.

Font files are processed by applications, and they are processed before the text with some font is visible to user.  That's not the case for new content type.

Mykyta Yevstifeyev

08.11.2011 16:15, Eric Burger wrote: 
Agreed.

On Nov 8, 2011, at 3:27 AM, Graham Klyne wrote:


It's not clear to me what purpose would be served that cannot be handled perfectly adequately by application/*

My understanding (or impression over the years) was that the top-level MIME type was a kind of high-level dispatch indicator to a device capable of rendering or otherwise presenting the broad kind of content, with application/* serving for types that needed further processing before they might meaningfully be considered for presentation

If I receive a font/* file, what might I do with it that is different from any other application/* type of file?

#g
--


On 07/11/2011 22:49, Peter Saint-Andre wrote:

In talking with folks at the W3C meeting last week, I heard yet again of
interest in defining a Content Type for fonts. Would anyone active in
the IETF Applications Area want to work on such a spec? And do folks
here think a new top-level content type is needed for fonts?

Peter


_______________________________________________
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


    

    

  


--------------020404020005090008070403--

From julian.reschke@gmx.de  Tue Nov  8 11:18:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB22121F8AD8 for ; Tue,  8 Nov 2011 11:18:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.02
X-Spam-Level: 
X-Spam-Status: No, score=-104.02 tagged_above=-999 required=5 tests=[AWL=-1.421, 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 VsyI9+jZPPPP for ; Tue,  8 Nov 2011 11:18:46 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id DFC2321F8AF2 for ; Tue,  8 Nov 2011 11:18:45 -0800 (PST)
Received: (qmail invoked by alias); 08 Nov 2011 19:18:44 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp060) with SMTP; 08 Nov 2011 20:18:44 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/cyhsKg8DcUiHcxh8Mf5BUgL2ydLeqeflX3C4mrV kr21f2RvpXKoWS
Message-ID: <4EB98090.5020203@gmx.de>
Date: Tue, 08 Nov 2011 20:18:40 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Mark Nottingham 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Paul Hoffman , apps-discuss Discuss , Dominik Tomaszuk 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 19:18:46 -0000

On 2011-11-08 20:10, Mark Nottingham wrote:
> I don't think URIs should be used for this.
> ...

Well, one use case that the proposal is addressing is the transport of 
data from frameworks that *already* use URIs; such a WebDAV properties 
or JCR identifiers. In these cases you really have only the choice of 
using the identifiers you have, or establishing a completely new 
identifier system.

And yes, it would be helpful if the draft was just saying that and not 
make the impression that it was solving the generic problem for JSON.

Best regards, Julian

From mnot@mnot.net  Tue Nov  8 11:20:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5445421F8AF6 for ; Tue,  8 Nov 2011 11:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMjVjS2f344r for ; Tue,  8 Nov 2011 11:20:45 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A868921F8AED for ; Tue,  8 Nov 2011 11:20:45 -0800 (PST)
Received: from [10.6.129.78] (unknown [64.39.4.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D4DF422E258; Tue,  8 Nov 2011 14:20:44 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Mark Nottingham 
In-Reply-To: <4EB98090.5020203@gmx.de>
Date: Tue, 8 Nov 2011 13:20:45 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net>
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de>
To: Julian Reschke 
X-Mailer: Apple Mail (2.1251.1)
Cc: Paul Hoffman , apps-discuss Discuss , Dominik Tomaszuk 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 19:20:46 -0000

On 08/11/2011, at 1:18 PM, Julian Reschke wrote:

> On 2011-11-08 20:10, Mark Nottingham wrote:
>> I don't think URIs should be used for this.
>> ...
>=20
> Well, one use case that the proposal is addressing is the transport of =
data from frameworks that *already* use URIs; such a WebDAV properties =
or JCR identifiers. In these cases you really have only the choice of =
using the identifiers you have, or establishing a completely new =
identifier system.
>=20
> And yes, it would be helpful if the draft was just saying that and not =
make the impression that it was solving the generic problem for JSON.

Ah. I see that as almost an application-specific issue, nothing that =
should be standardised. Doing that would be leaving sharp tools around =
small children.

Cheers,

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





From msk@cloudmark.com  Tue Nov  8 11:22:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953A811E8090 for ; Tue,  8 Nov 2011 11:22:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.294
X-Spam-Level: 
X-Spam-Status: No, score=-103.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, 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 GquNeGi8XB3t for ; Tue,  8 Nov 2011 11:22:13 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id D8F4F11E8086 for ; Tue,  8 Nov 2011 11:22:10 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 8 Nov 2011 11:22:10 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Tue, 8 Nov 2011 11:22:08 -0800
Thread-Topic: [apps-discuss] font/*
Thread-Index: AcyeChcXU6WEEr2yTGGZ5lkb8y2QpAAQN3WQ
Message-ID: 
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org>
In-Reply-To: <4EB8E7FA.5030406@ninebynine.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 19:22:13 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Graham Klyne
> Sent: Tuesday, November 08, 2011 12:28 AM
> To: Peter Saint-Andre
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] font/*
>=20
> My understanding (or impression over the years) was that the top-level MI=
ME type
> was a kind of high-level dispatch indicator to a device capable of render=
ing or
> otherwise presenting the broad kind of content, with application/* servin=
g for
> types that needed further processing before they might meaningfully be
> considered for presentation
>=20
> If I receive a font/* file, what might I do with it that is different fro=
m any
> other application/* type of file?

I think by your definition, a font doesn't by itself get presented; it gets=
 installed, and then used by other things as input to the presentation proc=
ess.  A font needs to be loaded or stored or something before a text/* part=
 can make use of it, for example.


From julian.reschke@gmx.de  Tue Nov  8 11:24:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40141F0C5F for ; Tue,  8 Nov 2011 11:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.991
X-Spam-Level: 
X-Spam-Status: No, score=-103.991 tagged_above=-999 required=5 tests=[AWL=-1.392, 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 N9j+PIyG8cSu for ; Tue,  8 Nov 2011 11:24:08 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8C6601F0C35 for ; Tue,  8 Nov 2011 11:24:07 -0800 (PST)
Received: (qmail invoked by alias); 08 Nov 2011 19:23:37 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp057) with SMTP; 08 Nov 2011 20:23:37 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/FNowJrLvFYgm8eCq99z76Ur4tnuDnE/e+BIfaok NZwuOhVbFKJfeZ
Message-ID: <4EB981B6.1090003@gmx.de>
Date: Tue, 08 Nov 2011 20:23:34 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Mark Nottingham 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de> <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net>
In-Reply-To: <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Paul Hoffman , apps-discuss Discuss , Dominik Tomaszuk 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 19:24:08 -0000

On 2011-11-08 20:20, Mark Nottingham wrote:
>
> On 08/11/2011, at 1:18 PM, Julian Reschke wrote:
>
>> On 2011-11-08 20:10, Mark Nottingham wrote:
>>> I don't think URIs should be used for this.
>>> ...
>>
>> Well, one use case that the proposal is addressing is the transport of data from frameworks that *already* use URIs; such a WebDAV properties or JCR identifiers. In these cases you really have only the choice of using the identifiers you have, or establishing a completely new identifier system.
>>
>> And yes, it would be helpful if the draft was just saying that and not make the impression that it was solving the generic problem for JSON.
>
> Ah. I see that as almost an application-specific issue, nothing that should be standardised. Doing that would be leaving sharp tools around small children.
> ...

I think it's worthwhile to have a spec that says:

"If you're identifiers are XML names, then this how to use them in JSON. 
But if you don't have identifiers like these, don't *start* using them 
if you want to use JSON."

Which of course leaves the question open what to do instead :-) (and 
yes, I saw your proposal)

Best regards, Julian

From paul.bryan@forgerock.com  Tue Nov  8 11:32:21 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEBB21F8B26 for ; Tue,  8 Nov 2011 11:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 vC77ZSDWyOCU for ; Tue,  8 Nov 2011 11:32:21 -0800 (PST)
Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) by ietfa.amsl.com (Postfix) with SMTP id 7627E21F8B1F for ; Tue,  8 Nov 2011 11:32:14 -0800 (PST)
Received: from mail-qw0-f43.google.com ([209.85.216.43]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP;  Tue, 08 Nov 2011 19:32:14 UTC
Received: by mail-qw0-f43.google.com with SMTP id g1so949077qab.16 for ; Tue, 08 Nov 2011 11:32:02 -0800 (PST)
Received: by 10.224.42.134 with SMTP id s6mr6289232qae.78.1320780721245; Tue, 08 Nov 2011 11:32:01 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id do8sm2547966qab.17.2011.11.08.11.31.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Nov 2011 11:31:59 -0800 (PST)
Message-ID: <1320780711.26119.30.camel@neutron>
From: "Paul C. Bryan" 
To: Julian Reschke 
Date: Tue, 08 Nov 2011 11:31:51 -0800
In-Reply-To: <4EB981B6.1090003@gmx.de>
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de> <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net> <4EB981B6.1090003@gmx.de>
Content-Type: multipart/alternative; boundary="=-ktDZ0diAZnb9xehvc1s3"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Cc: Mark Nottingham , Paul Hoffman , apps-discuss Discuss , Dominik Tomaszuk 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 19:32:22 -0000

--=-ktDZ0diAZnb9xehvc1s3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

My 2¢: Leave the field wide-open. Let implementers pick the namespace
that gives them the best comfort of avoiding collisions. As far as I can
tell, the best to pick from would be: reverse-domain-name-prefixed
dot-delimited value, URI w. scheme, and even OID in some cases. Allowing
all of these namespace conventions seems to avoid all the collisions
that I can currently imagine.

Paul

On Tue, 2011-11-08 at 20:23 +0100, Julian Reschke wrote:

> On 2011-11-08 20:20, Mark Nottingham wrote:
> >
> > On 08/11/2011, at 1:18 PM, Julian Reschke wrote:
> >
> >> On 2011-11-08 20:10, Mark Nottingham wrote:
> >>> I don't think URIs should be used for this.
> >>> ...
> >>
> >> Well, one use case that the proposal is addressing is the transport of data from frameworks that *already* use URIs; such a WebDAV properties or JCR identifiers. In these cases you really have only the choice of using the identifiers you have, or establishing a completely new identifier system.
> >>
> >> And yes, it would be helpful if the draft was just saying that and not make the impression that it was solving the generic problem for JSON.
> >
> > Ah. I see that as almost an application-specific issue, nothing that should be standardised. Doing that would be leaving sharp tools around small children.
> > ...
> 
> I think it's worthwhile to have a spec that says:
> 
> "If you're identifiers are XML names, then this how to use them in JSON. 
> But if you don't have identifiers like these, don't *start* using them 
> if you want to use JSON."
> 
> Which of course leaves the question open what to do instead :-) (and 
> yes, I saw your proposal)
> 
> Best regards, Julian
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



--=-ktDZ0diAZnb9xehvc1s3
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


My 2¢: Leave the field wide-open. Let implementers pick the namespace that gives them the best comfort of avoiding collisions. As far as I can tell, the best to pick from would be: reverse-domain-name-prefixed dot-delimited value, URI w. scheme, and even OID in some cases. Allowing all of these namespace conventions seems to avoid all the collisions that I can currently imagine.



Paul



On Tue, 2011-11-08 at 20:23 +0100, Julian Reschke wrote:



On 2011-11-08 20:20, Mark Nottingham wrote:
>
> On 08/11/2011, at 1:18 PM, Julian Reschke wrote:
>
>> On 2011-11-08 20:10, Mark Nottingham wrote:
>>> I don't think URIs should be used for this.
>>> ...
>>
>> Well, one use case that the proposal is addressing is the transport of data from frameworks that *already* use URIs; such a WebDAV properties or JCR identifiers. In these cases you really have only the choice of using the identifiers you have, or establishing a completely new identifier system.
>>
>> And yes, it would be helpful if the draft was just saying that and not make the impression that it was solving the generic problem for JSON.
>
> Ah. I see that as almost an application-specific issue, nothing that should be standardised. Doing that would be leaving sharp tools around small children.
> ...

I think it's worthwhile to have a spec that says:

"If you're identifiers are XML names, then this how to use them in JSON. 
But if you don't have identifiers like these, don't *start* using them 
if you want to use JSON."

Which of course leaves the question open what to do instead :-) (and 
yes, I saw your proposal)

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









--=-ktDZ0diAZnb9xehvc1s3--


From msk@cloudmark.com  Tue Nov  8 11:34:21 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874D421F8B31 for ; Tue,  8 Nov 2011 11:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.297
X-Spam-Level: 
X-Spam-Status: No, score=-103.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, 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 sRb9qbf-D15z for ; Tue,  8 Nov 2011 11:34:20 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9F36421F8B2E for ; Tue,  8 Nov 2011 11:34:20 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 8 Nov 2011 11:34:20 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org Discuss" 
Date: Tue, 8 Nov 2011 11:34:18 -0800
Thread-Topic: [apps-discuss] font/*
Thread-Index: AcyeOfX1cq3dBMvvTsaQDhUKQ8CriwAE1ywg
Message-ID: 
References: <4EB86078.8070904@stpeter.im> 	<4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>
In-Reply-To: <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 19:34:21 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Mark Nottingham
> Sent: Tuesday, November 08, 2011 9:15 AM
> To: Eric Burger
> Cc: apps-discuss@ietf.org Discuss
> Subject: Re: [apps-discuss] font/*
>=20
> Oh, I had thought it would be
>=20
>   font/PostScript
>   font/TrueType
>=20
> i.e., NOT identifying the specific typeface in use. After all, we don't
> have text/html/home-page, do we?

Ditto, with maybe name=3D"TimesRoman" after it.


From john-ietf@jck.com  Tue Nov  8 11:57:56 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFD61F0C52 for ; Tue,  8 Nov 2011 11:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.255
X-Spam-Level: 
X-Spam-Status: No, score=-102.255 tagged_above=-999 required=5 tests=[AWL=0.344, 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 pz17pxwEpK07 for ; Tue,  8 Nov 2011 11:57:56 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 3072A1F0C4A for ; Tue,  8 Nov 2011 11:57:56 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RNrnv-000FcD-AB for apps-discuss@ietf.org; Tue, 08 Nov 2011 14:57:55 -0500
Date: Tue, 08 Nov 2011 14:57:54 -0500
From: John C Klensin 
To: "apps-discuss@ietf.org Discuss" 
Message-ID: <2D7514C468E718253193221B@PST.JCK.COM>
In-Reply-To: <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 19:57:57 -0000

--On Tuesday, November 08, 2011 09:20 -0500 Eric Burger
 wrote:

> Is the idea we would see something like
> 
> 	font/Times
> 
> or one of 
> 
> 	font/PostScript/Times
> 	font/TrueType/Times
> 	font/OpenType/Times
> 	font/METATYPE/Times
> 
> or one of
> 
> 	font/Times/PostScript
> 	font/Times/TrueType
> 	font/Times/OpenType
> 	font/Times/METATYPE
> 
> One cannot just say it's font/* and assume it is an opaque
> container, as one could see battles over the latter examples.

Yes, that is part of what I was concerned about.

If the intent is merely to pass the descriptions/ definitions
around, then things like
   font/TrueType name="Times" 
might work, where "TrueType" is what I called a description
language in my earlier note.

But...


>...

--On Tuesday, November 08, 2011 18:39 +0100 "t.petch"
 wrote:

>...
> BTW, before naming this thing, please have a discussion with a
> typographer about the difference between a "font" and a
> "typeface."
> 
> 
> and typeface, versus typeface family (which, I suspect, is
> what many mean when they say 'font')
> 
> Tom Petch
> 
> 

Indeed.  And that is why I made the comment about size ranges
(for description types that facilitate scaling) and about
styles. Does, e.g., 
   font/TrueType name="Times"
require that the entire typeface family be sent?  Think about
what happens if one wants to send the Bold style only.  Is 

   font/TrueType name="Times" style="Bold" 

sufficient?  Can TrueType handle some or all of that internally?
Is external labeling (as part of the Content Type) needed to
provide a referencing handle?  Can all of the other description
formats do the same thing.

Note that it is common to have mail messages in which a body
part (possibly text/html) references images that are additional
body parts of the same message.   Could one contemplate sending
a font and the content that uses it in the same message?  Does
that create any special issues?

I think this is probably worth doing, but I think there are a
lot of questions to be answered... and that the result is
unlikely to be a one-page RFC.

For example, I can see a really interesting IANA registry for
subtypes and keywords coming along -- probably not with a
one-page spec.

    john


From GK@ninebynine.org  Tue Nov  8 12:58:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C0021F852E for ; Tue,  8 Nov 2011 12:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmR5Cw9NhcmQ for ; Tue,  8 Nov 2011 12:58:21 -0800 (PST)
Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id DF9AA21F8512 for ; Tue,  8 Nov 2011 12:58:04 -0800 (PST)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RNsk7-0003oV-5h for apps-discuss@ietf.org; Tue, 08 Nov 2011 20:58:03 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RNsk7-0004a7-4X for apps-discuss@ietf.org; Tue, 08 Nov 2011 20:58:03 +0000
Message-ID: <4EB997DA.9030207@ninebynine.org>
Date: Tue, 08 Nov 2011 20:58:02 +0000
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 20:58:22 -0000

On 08/11/2011 19:22, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Graham Klyne
>> Sent: Tuesday, November 08, 2011 12:28 AM
>> To: Peter Saint-Andre
>> Cc: apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] font/*
>>
>> My understanding (or impression over the years) was that the top-level MIME type
>> was a kind of high-level dispatch indicator to a device capable of rendering or
>> otherwise presenting the broad kind of content, with application/* serving for
>> types that needed further processing before they might meaningfully be
>> considered for presentation
>>
>> If I receive a font/* file, what might I do with it that is different from any
>> other application/* type of file?
>
> I think by your definition, a font doesn't by itself get presented; it gets installed, and then used by other things as input to the presentation process.  A font needs to be loaded or stored or something before a text/* part can make use of it, for example.

Quite.  I think that puts it in the same category as, say, application/pkix-cert.

#g
--

From Martin.Thomson@commscope.com  Tue Nov  8 13:57:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B261C21F8AE1 for ; Tue,  8 Nov 2011 13:57:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.28
X-Spam-Level: 
X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=-0.681,  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 cEdr7oZKYSHM for ; Tue,  8 Nov 2011 13:57:24 -0800 (PST)
Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 1878221F8ADE for ; Tue,  8 Nov 2011 13:57:23 -0800 (PST)
X-AuditID: 0a0404e8-b7c2eae000002297-88-4eb9a5bf1db4
Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id C3.D5.08855.FB5A9BE4; Tue,  8 Nov 2011 15:57:19 -0600 (CST)
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 8 Nov 2011 15:57:19 -0600
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 9 Nov 2011 05:57:15 +0800
From: "Thomson, Martin" 
To: Mark Nottingham , Paul Hoffman 
Date: Wed, 9 Nov 2011 05:57:13 +0800
Thread-Topic: [apps-discuss] draft-saintandre-json-namespaces-00 comments
Thread-Index: AcyeOW71ZK3B8ukTRe+81yjMKgjB3wAJRjMw
Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910D7C1F43F@SISPE7MB1.commscope.com>
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net>
In-Reply-To: <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: Dominik Tomaszuk , apps-discuss Discuss 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 21:57:24 -0000

And another +1 to the -10.

To make the reason clear, the problem this causes is that names are no long=
er able to be treated opaquely.  Having "{$foo}x" with more than one potent=
ial semantic in the same context is a crazy sort of problem that only an un=
necessary optimization can produce.

I'm generally with Mark, and Paul.  The lessons learned from "X-" and XML i=
ndicate that a private playpen is nice.  Proscribing the shape of that play=
pen seems unnecessary, at least for now. =20

On the one hand, you could attempt to establish a convention for the shape =
of the playpen.  This draft does that with {} and URIs.  There's certainly =
merit in convention, but the proposal is heavyweight.

On the other, all you need is a mechanism to avoid collisions in a given ho=
st format.  Given the identifier's inherent opacity, extensions can take an=
y form (c.f. Paul's comment) and the goal is still achieved.  You can use a=
 registry and bear the management overhead; use dotted names, uris or somet=
hing similar; you can just use real names and risk collisions; or you can c=
ombine the approaches.

For instance, you could say: "official" extensions wont use '.', come see u=
s if you want one; otherwise, try to play nice.  For instance, I haven't se=
en too many problems with namespace collisions in Java class names.

--Martin

On 2011-11-09 at 04:10:44, Mark Nottingham wrote:
> +1 to Paul's -10.
>=20
> My take on it:
>=20
> http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json
>=20
> Let's keep this simple and avoid repeating the mistakes of XML, OK?
>=20
>=20
> On 08/11/2011, at 11:05 AM, Paul Hoffman wrote:
>=20
> > On Nov 8, 2011, at 4:42 AM, Dominik Tomaszuk wrote:
> >
> >> Clark Notation can sometimes be too heavy, especially when
> namespaces are placed in many keys.
> >
> > +1
> >
> >> I propose to give possibility to declare namespace.
> >
> > -1. Actually, -10. While somewhat useful for XML, namespaces have
> also proven to cause many headaches for corner cases.
> >
> > Please strongly consider using a much simpler naming scheme, such as
> "names with periods in them".
> >
> > --Paul Hoffman
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> --
> Mark Nottingham
> http://www.mnot.net/
>=20
>=20
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



From barryleiba.mailing.lists@gmail.com  Tue Nov  8 14:53:27 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCCD1F0C6D for ; Tue,  8 Nov 2011 14:53:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.938
X-Spam-Level: 
X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.039, 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 pM2auODFkA9l for ; Tue,  8 Nov 2011 14:53:26 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3C81F0C4A for ; Tue,  8 Nov 2011 14:53:26 -0800 (PST)
Received: by ggnv1 with SMTP id v1so1292439ggn.31 for ; Tue, 08 Nov 2011 14:53:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eZ7TNnFZ37Xj6K/S9/wfp47AeJ8O7K6++XW5VOkWvoA=; b=rcYdgdcSrks8QPodKrn1cnI7vFhN/5txbV24cPLOUCM15SPfjvoTgrut9/HJUG4jIb MIjmx/kCLlHIQKJtbl6dH8wVb/Qud6xpkLuB/GX0qChfn4JVZabipKCt8qM88lRyzYXl ZNXC+smRhpTimMdu8HjNUY1jQvop5XCpO3+Jg=
MIME-Version: 1.0
Received: by 10.146.159.5 with SMTP id h5mr7777671yae.1.1320792806256; Tue, 08 Nov 2011 14:53:26 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.250.14 with HTTP; Tue, 8 Nov 2011 14:53:24 -0800 (PST)
In-Reply-To: <4EB8E7FA.5030406@ninebynine.org>
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org>
Date: Tue, 8 Nov 2011 17:53:24 -0500
X-Google-Sender-Auth: L3VVoABv-qNtIbcAfWuWpFzKwgU
Message-ID: 
From: Barry Leiba 
To: Graham Klyne 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 22:53:27 -0000

> It's not clear to me what purpose would be served that cannot be handled
> perfectly adequately by application/*

This was my first thought as well.

But then I thought again, and I said, "Gee: that's always true.  If we
always think that, then wouldn't *everything* just be
'application/'?  And then what would the point of top-level
types be in the first place?"

We have the precedent, as it's set up in the first place, to say,
"This is text," and "This is audio," and "This is an image," and "This
is video."  It seems to me that, "This is a font definition," is as
much a statement of a distinct media type as the others are.

Barry

From julian.reschke@gmx.de  Tue Nov  8 15:01:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E951F0C73 for ; Tue,  8 Nov 2011 15:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.479
X-Spam-Level: 
X-Spam-Status: No, score=-104.479 tagged_above=-999 required=5 tests=[AWL=-1.880, 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 nRpBl1mtFmaG for ; Tue,  8 Nov 2011 15:01:26 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9CD981F0C6F for ; Tue,  8 Nov 2011 15:01:25 -0800 (PST)
Received: (qmail invoked by alias); 08 Nov 2011 23:01:24 -0000
Received: from p5DCCB151.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.177.81] by mail.gmx.net (mp012) with SMTP; 09 Nov 2011 00:01:24 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/ENNNbc+bE9FeuVVRC9ecURplKrWJ5yosRE5KFGq wBMpa8EdkH8OFP
Message-ID: <4EB9B4BF.2080506@gmx.de>
Date: Wed, 09 Nov 2011 00:01:19 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Barry Leiba 
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 23:01:26 -0000

On 2011-11-08 23:53, Barry Leiba wrote:
>> It's not clear to me what purpose would be served that cannot be handled
>> perfectly adequately by application/*
>
> This was my first thought as well.
>
> But then I thought again, and I said, "Gee: that's always true.  If we
> always think that, then wouldn't *everything* just be
> 'application/'?  And then what would the point of top-level
> types be in the first place?"
>
> We have the precedent, as it's set up in the first place, to say,
> "This is text," and "This is audio," and "This is an image," and "This
> is video."  It seems to me that, "This is a font definition," is as
> much a statement of a distinct media type as the others are.
>...

+1

From msk@cloudmark.com  Tue Nov  8 15:02:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155C71F0C75 for ; Tue,  8 Nov 2011 15:02:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.3
X-Spam-Level: 
X-Spam-Status: No, score=-103.3 tagged_above=-999 required=5 tests=[AWL=0.299,  BAYES_00=-2.599, 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 01Boj+KC+BGa for ; Tue,  8 Nov 2011 15:02:23 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id A3ADC1F0C6F for ; Tue,  8 Nov 2011 15:02:23 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 8 Nov 2011 15:02:23 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Tue, 8 Nov 2011 15:02:22 -0800
Thread-Topic: [apps-discuss] font/*
Thread-Index: AcyeaT5jeA/aT3oqR6mAM/kEB6B6xgAASLHg
Message-ID: 
References: <4EB86078.8070904@stpeter.im>	<4EB8E7FA.5030406@ninebynine.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 23:02:24 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Barry Leiba
> Sent: Tuesday, November 08, 2011 2:53 PM
> To: Graham Klyne
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] font/*
>=20
> But then I thought again, and I said, "Gee: that's always true.  If we
> always think that, then wouldn't *everything* just be
> 'application/'?  And then what would the point of top-level
> types be in the first place?"
>=20
> We have the precedent, as it's set up in the first place, to say,
> "This is text," and "This is audio," and "This is an image," and "This
> is video."  It seems to me that, "This is a font definition," is as
> much a statement of a distinct media type as the others are.

I think that's part of what I was trying to get at earlier, but you did a f=
ar better job than I did.

+1.

-MSK

From mark@coactus.com  Tue Nov  8 16:51:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B2821F8AEA for ; Tue,  8 Nov 2011 16:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.727
X-Spam-Level: 
X-Spam-Status: No, score=-104.727 tagged_above=-999 required=5 tests=[AWL=-1.750, 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 xSn5f1Mbgs66 for ; Tue,  8 Nov 2011 16:51:08 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95C7F21F8801 for ; Tue,  8 Nov 2011 16:51:08 -0800 (PST)
Received: by iaeo4 with SMTP id o4so1496555iae.31 for ; Tue, 08 Nov 2011 16:51:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.168.202 with SMTP id x10mr209863icy.4.1320799868077; Tue, 08 Nov 2011 16:51:08 -0800 (PST)
Sender: mark@coactus.com
Received: by 10.42.165.194 with HTTP; Tue, 8 Nov 2011 16:51:08 -0800 (PST)
In-Reply-To: <4EB981B6.1090003@gmx.de>
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de> <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net> <4EB981B6.1090003@gmx.de>
Date: Tue, 8 Nov 2011 19:51:08 -0500
X-Google-Sender-Auth: RHO0awihG_mNz9daxl48PS8bDZA
Message-ID: 
From: Mark Baker 
To: Julian Reschke 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Mark Nottingham , Paul Hoffman , apps-discuss Discuss , Dominik Tomaszuk 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 00:51:09 -0000

On Tue, Nov 8, 2011 at 2:23 PM, Julian Reschke  wrote:
> I think it's worthwhile to have a spec that says:
>
> "If you're identifiers are XML names, then this how to use them in JSON. But
> if you don't have identifiers like these, don't *start* using them if you
> want to use JSON."

Completely agreed, though XML names aren't the only ones grounded in
URI space (e.g. RDF).

> Which of course leaves the question open what to do instead :-) (and yes, I
> saw your proposal)

After working with it for a couple of weeks, I agree completely with
Manu (in the comments of Mark's blog post); JSON-LD is a terrific fit.
It uses the same basic approach suggested in the message which started
this thread, and has other features which make it easy to bolt-on to
existing JSON based formats, in many cases without breaking existing
recipients.

http://json-ld.org

Mark.

From duerst@it.aoyama.ac.jp  Tue Nov  8 17:13:02 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F84511E8095 for ; Tue,  8 Nov 2011 17:13:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.558
X-Spam-Level: 
X-Spam-Status: No, score=-99.558 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtJmC5Ez4grs for ; Tue,  8 Nov 2011 17:13:02 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 584BA21F85A4 for ; Tue,  8 Nov 2011 17:13:00 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pA91Co2e022527 for ; Wed, 9 Nov 2011 10:12:50 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5912_1291_f16f20fe_0a6f_11e1_bbef_001d096c5782; Wed, 09 Nov 2011 10:12:50 +0900
Received: from [IPv6:::1] ([133.2.210.1]:34924) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Wed, 9 Nov 2011 10:12:54 +0900
Message-ID: <4EB9D383.1060901@it.aoyama.ac.jp>
Date: Wed, 09 Nov 2011 10:12:35 +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: Barry Leiba 
References: <4EB86078.8070904@stpeter.im>	<4EB8E7FA.5030406@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 01:13:02 -0000

On 2011/11/09 7:53, Barry Leiba wrote:
>> It's not clear to me what purpose would be served that cannot be handled
>> perfectly adequately by application/*
>
> This was my first thought as well.
>
> But then I thought again, and I said, "Gee: that's always true.  If we
> always think that, then wouldn't *everything* just be
> 'application/'?  And then what would the point of top-level
> types be in the first place?"
>
> We have the precedent, as it's set up in the first place, to say,
> "This is text," and "This is audio," and "This is an image," and "This
> is video."  It seems to me that, "This is a font definition," is as
> much a statement of a distinct media type as the others are.

Very well put!

Regards,   Martin.

From dhc@dcrocker.net  Tue Nov  8 17:16:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5871F0C45 for ; Tue,  8 Nov 2011 17:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIH3ik9bmp7c for ; Tue,  8 Nov 2011 17:16:53 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D9CD11F0C3B for ; Tue,  8 Nov 2011 17:16:53 -0800 (PST)
Received: from [192.168.0.229] (61-31-89-133.static.tfn.net.tw [61.31.89.133]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pA91GcqD000606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Nov 2011 17:16:51 -0800
Message-ID: <4EB9D46B.8010808@dcrocker.net>
Date: Wed, 09 Nov 2011 09:16:27 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Graham Klyne 
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org>
In-Reply-To: <4EB8E7FA.5030406@ninebynine.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 08 Nov 2011 17:16:53 -0800 (PST)
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 01:16:54 -0000

On 11/8/2011 4:27 PM, Graham Klyne wrote:
> It's not clear to me what purpose would be served that cannot be handled
> perfectly adequately by application/*

Thanks for raising this point.  On reflection, I seem to recall that adding 
top-level types is a Big Deal and not done.

Your question points to the alternative that constitutes a less disruptive 
challenge to the current proposal.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From duerst@it.aoyama.ac.jp  Tue Nov  8 17:17:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB6B11E80AD for ; Tue,  8 Nov 2011 17:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.065
X-Spam-Level: 
X-Spam-Status: No, score=-99.065 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_BACKHAIR_34=1, MIME_8BIT_HEADER=0.3, 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 Fm0QB5H266vt for ; Tue,  8 Nov 2011 17:17:33 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5A94711E8095 for ; Tue,  8 Nov 2011 17:17:32 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pA91HVBj026110 for ; Wed, 9 Nov 2011 10:17:31 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6627_3aae_98f70b98_0a70_11e1_89fb_001d096c566a; Wed, 09 Nov 2011 10:17:31 +0900
Received: from [IPv6:::1] ([133.2.210.1]:55751) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Wed, 9 Nov 2011 10:17:35 +0900
Message-ID: <4EB9D49C.5010100@it.aoyama.ac.jp>
Date: Wed, 09 Nov 2011 10:17:16 +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: Mark Nottingham 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>
In-Reply-To: <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 01:17:34 -0000

On 2011/11/09 2:15, Mark Nottingham wrote:
> Oh, I had thought it would be
>
>    font/PostScript
>    font/TrueType
>
> i.e., NOT identifying the specific typeface in use. After all, we don't have text/html/home-page, do we?

It's definitely that.

 From http://tools.ietf.org/html/draft-singer-font-mime-00
(which requires some serious rewriting around security issues, but 
otherwise is recommended reading for people who want to comment in this 
discussion):

    This document defines a top-level MIME type "font" under which
    differing representation formats of fonts may be registered (e.g. a
    bitmap or outline format).  It should be emphasized that, just as
    under the "image" top-level type one does not find registration for,
    for example, "The Night-watch" (by Rembrandt) but instead "JPEG" (an
    image representation system), so, under "font" one will not find
    "Courier" (the name of a popular font) but perhaps "BDF" (the name of
    a commonly used bitmap font format).

> BTW, before naming this thing, please have a discussion with a typographer about the difference between a "font" and a "typeface."
>
> (My wife, who teaches typography, would beat me if I didn't make that distinction)

http://fontfeed.com/archives/font-or-typeface/ explains that in very 
simple terms. As far as the analogy there with MP3<=>font, 
song<=>typeface goes, we definitely need Mime types for fonts, not for 
typefaces.

Regards,   Martin.

From paul.hoffman@vpnc.org  Tue Nov  8 18:19:21 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F4121F84FB for ; Tue,  8 Nov 2011 18:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level: 
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 Q9VO0LiIx-8a for ; Tue,  8 Nov 2011 18:19:20 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C20E721F84FA for ; Tue,  8 Nov 2011 18:19:20 -0800 (PST)
Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pA92JHWP062539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2011 19:19:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: 
Date: Tue, 8 Nov 2011 18:19:17 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <7797835D-26FA-45E4-B66B-A336666F7AC7@vpnc.org>
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de> <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net> <4EB981B6.1090003@gmx.de> 
To: apps-discuss Discuss 
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 02:19:21 -0000

On Nov 8, 2011, at 4:51 PM, Mark Baker wrote:

> http://json-ld.org


I would prefer that the output of this work was much, much simpler than this.

--Paul Hoffman


From Martin.Thomson@commscope.com  Tue Nov  8 19:03:47 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEA81F0C61 for ; Tue,  8 Nov 2011 19:03:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.256
X-Spam-Level: 
X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=-0.657, 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 5z1n2En2XIgv for ; Tue,  8 Nov 2011 19:03:46 -0800 (PST)
Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8F05E1F0C5C for ; Tue,  8 Nov 2011 19:03:46 -0800 (PST)
X-AuditID: 0a0404e8-b7c2eae000002297-fd-4eb9ed8d67aa
Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 49.CB.08855.D8DE9BE4; Tue,  8 Nov 2011 21:03:41 -0600 (CST)
Received: from CDCE10HC2.commscope.com (10.86.28.22) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 8 Nov 2011 21:03:41 -0600
Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 8 Nov 2011 21:03:39 -0600
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 9 Nov 2011 11:03:35 +0800
From: "Thomson, Martin" 
To: Paul Hoffman , apps-discuss Discuss 
Date: Wed, 9 Nov 2011 11:03:32 +0800
Thread-Topic: [apps-discuss] draft-saintandre-json-namespaces-00 comments
Thread-Index: AcyehhwdGzuty0ioTAyOeYiEyqowHQABbwTA
Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910D7C1F479@SISPE7MB1.commscope.com>
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net>	<4EB97122.7010206@gmx.de> 	<4EB98090.5020203@gmx.de> <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net>	<4EB981B6.1090003@gmx.de>  <7797835D-26FA-45E4-B66B-A336666F7AC7@vpnc.org>
In-Reply-To: <7797835D-26FA-45E4-B66B-A336666F7AC7@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 03:03:47 -0000

On 2011-11-09 at 13:19:17, Paul Hoffman wrote:
> > http://json-ld.org
>=20
> I would prefer that the output of this work was much, much simpler=20
> than this.

+1.

@context is essentially the same as XML namespace prefixes, with the same b=
asic problem: two labels can have different semantics, determined by anothe=
r "special" label.


From john-ietf@jck.com  Wed Nov  9 05:06:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFAC21F8AF2 for ; Wed,  9 Nov 2011 05:06:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.114
X-Spam-Level: 
X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 LJmqB27mTrT9 for ; Wed,  9 Nov 2011 05:06:44 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 2565D21F8468 for ; Wed,  9 Nov 2011 05:06:44 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RO7rO-000B8Y-0g; Wed, 09 Nov 2011 08:06:34 -0500
Date: Wed, 09 Nov 2011 08:06:32 -0500
From: John C Klensin 
To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= 
Message-ID: <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>
In-Reply-To: <4EB8D0F4.9020907@it.aoyama.ac.jp>
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 13:06:48 -0000

Hi Martin,

The links you gave to earlier messages don't work, but I don't
recall "killing" a font proposal.  See inline below.

--On Tuesday, November 08, 2011 15:49 +0900 "\"Martin J.
D=C3=BCrst\""  wrote:

>...
>> Well, I think that a top-level would be in order -- these are
>> really different from the existing types.  Things may have
>> changed, but my recollection from when I had some exposure to
>> them in the early 90s is that there are a bunch of font
>...
> There is no need to overengineer this stuff. Like all other
> types, it's simply a top level type, and a subtype. A very
> rough approximation of what could end up in the subtype can be
> found here: =
http://en.wikipedia.org/wiki/Category:Font_formats.

I was, and remain, very hesitant about creating new top-level
types.  As others have noted, it is a big deal.  There are
several reasons for that but at least one important one is that
the model for what an application is expected to do when it
encounters an unknown top-level type is not, IMO, really well
sorted out.  One cannot do much of anything (in that sense, it
isn't much different from an application/ subtype), but it isn't
clear how one should present that fact to a user who doesn't
have much understanding or vocabulary about what is going on at
the content-type level.

"Model/" (as described in RFC 2077) was not a problem because
the request came from a particular community for a particular
type of use, one on which there was little or no likelihood of
interaction with other types, especially with multipart content.
I assume that the community that wanted that type is using it,
but confess to never having seen the type in the wild.  If
others haven't either, that reinforces the claim that the
"model/" type really is independent of the others.

If font/* is simply a "type and a subtype", then I'm inclined to
agree with those who say "use application/".  Certainly it is
feasible to say, e.g., "application/OpenType", specify it as
being bound to the OpenType font definition model, say some
things about encoding and parameters, and move on.  The fact
that it and an equally hypothetical "application/TrueType" both
encode/carry fonts creates no more of a requirement or
justification for a top-level type than the observation that
there application/ subtypes for Open Document and MSWord formats
implies that we should have a top-level type for WordProcessor/
or DocumentFormatter/.  And, as Graham and others have pointed
out, we use "application/" (a lot) for subtypes that require
processing or installation before something else can make use of
them.

I think a font/ top-level type would be worth looking at
carefully if there really were a use case for which some
application/ subtypes would not be appropriate.  One of those
might lie along the path of compound documents that I mentioned
in the context of "image/".   Perhaps there might be others, or
perhaps not.  "Distinct media type" doesn't do much for me
because what is, and is not, is largely in the mind of the
beholder.

> If some kind of 'Definition Language' is used inside a font
> format, then that's just something under the hood. My
> understanding is that some popular formats such as OpenType
> essentially are mergers resulting from the "Definition
> Language" wars in the early 1990.

I used "Definition Language" to refer to what you are referring
to as a "format" (which often means something else in this
context).  I don't have enough contemporary knowledge to know
what would be most accurate and consistent with current
terminology -- another topic for Mark's wife or some other
typographic expert.

> Also, typeface, style, and
> applicable range of sizes shouldn't be necessary as part of
> the mime type because it's part of the content.

I don't know what that means in practice.  Having struggled
several times with what needs to be a parameter on a media type
and subtype, it isn't obvious that parameters are unnecessary
even if the information can be deduced from content.   I am
particularly concerned about transmission of files that contain
parts of a typeface family, but not all of it, as well as about
a type and subtype that don't even identify the type family and
hence may require a lot of work before a system can decide
whether to install it.

I also don't know whether all "Definition Languages" in use
today contain the same descriptor information in reasonably
compatible formats.   If some do and others require, e.g., the
name of the font in supplemental information because only the
glyph descriptions are stored in the file, then there is a lot
of justification for parameters across the board if one is going
to have a well-designed top-level type with homogeneous
subtypes.  Of course, homogeneous subtypes are not a
requirement, but, if each subtype will have to establish its own
parameter model, it seems to me that the argument for just
sticking with "application/" becomes stronger.

> Some such parameters were proposed in
> http://tools.ietf.org/html/draft-singer-font-mime-00, and may
> still be necessary, but not as much as 7 years ago, when you
> apparently shot down the proposal (see
> http://www.ietf.org/mail-archive/web/ietf/current/msg33267.htm
> l). So if the font experts say they really need a parameter,
> we'll keep it, but we don't have to make thing more
> complicated than necessary in advance.

> The only RFC that defined a new top-level type is RFC 2077
> (http://tools.ietf.org/html/rfc2077). It's rather short, and I
> expect the font/ RFC to be even shorter unless it also
> includes some registrations for actual subtypes (I'd probably
> do it in two separate documents, one for the top-level type
> and another for some low hanging subtypes, but I'll leave the
> decision to whoever does the actual work.)

While the "model/" spec is rather short, it contains the
elements I'm trying to advocate here: a clear description of why
a top-level type is needed, a discussion of use cases, and
definitions of enough subtypes to make the use cases clear, as
well as the required templates and mechanisms for defining
future subtypes.

Recommendation to those who want this:  Work on a few subtype
definitions.  Sort the details, such as what parameters are
needed, out with the typographic community.  Examine the use
cases.   The would would need to be done --and would be almost
the same-- for a subtype of application/ or a subtype of font/.
With those tentative subtype descriptions in hand, the rest of
us will be a lot more able to identify commonalities and to
participate in an evaluation of whether a top-level type is
really justified.

best,
   john



From mark@coactus.com  Wed Nov  9 07:19:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5B421F8C44 for ; Wed,  9 Nov 2011 07:19:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.144
X-Spam-Level: 
X-Spam-Status: No, score=-104.144 tagged_above=-999 required=5 tests=[AWL=-1.167, 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 weK3MiVLXoYa for ; Wed,  9 Nov 2011 07:19:34 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAE7A21F8C43 for ; Wed,  9 Nov 2011 07:19:33 -0800 (PST)
Received: by iaeo4 with SMTP id o4so2364182iae.31 for ; Wed, 09 Nov 2011 07:19:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.159.1 with SMTP id j1mr3267265icx.20.1320851973219; Wed, 09 Nov 2011 07:19:33 -0800 (PST)
Sender: mark@coactus.com
Received: by 10.42.165.194 with HTTP; Wed, 9 Nov 2011 07:19:32 -0800 (PST)
In-Reply-To: <7797835D-26FA-45E4-B66B-A336666F7AC7@vpnc.org>
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de> <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net> <4EB981B6.1090003@gmx.de>  <7797835D-26FA-45E4-B66B-A336666F7AC7@vpnc.org>
Date: Wed, 9 Nov 2011 10:19:32 -0500
X-Google-Sender-Auth: _cwViX8lIlNoPSRza4CHVwtZyVs
Message-ID: 
From: Mark Baker 
To: Paul Hoffman 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss Discuss 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 15:19:38 -0000

On Tue, Nov 8, 2011 at 9:19 PM, Paul Hoffman  wrote:
> On Nov 8, 2011, at 4:51 PM, Mark Baker wrote:
>
>> http://json-ld.org
>
>
> I would prefer that the output of this work was much, much simpler than this.

JSON-LD lets the people who need URI-grounded names have them, but at
the same time presents enough of a barrier to discourage those who
don't need them from using them.  The last thing JSON needs is the
simple equivalent of xmlns.

Mark.

From paul.hoffman@vpnc.org  Wed Nov  9 08:20:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3048B21F8C4B for ; Wed,  9 Nov 2011 08:20:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 t97AhFU+VlUX for ; Wed,  9 Nov 2011 08:20:46 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 876FB21F8C81 for ; Wed,  9 Nov 2011 08:20:45 -0800 (PST)
Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pA9GKgAE096791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 09:20:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: 
Date: Wed, 9 Nov 2011 08:20:42 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de> <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net> <4EB981B6.1090003@gmx.de>  <7797835D-26FA-45E4-B66B-A336666F7AC7@vpnc.org> 
To: Mark Baker 
X-Mailer: Apple Mail (2.1251.1)
Cc: apps-discuss Discuss 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 16:20:52 -0000

On Nov 9, 2011, at 7:19 AM, Mark Baker wrote:

> On Tue, Nov 8, 2011 at 9:19 PM, Paul Hoffman  =
wrote:
>> On Nov 8, 2011, at 4:51 PM, Mark Baker wrote:
>>=20
>>> http://json-ld.org
>>=20
>>=20
>> I would prefer that the output of this work was much, much simpler =
than this.
>=20
> JSON-LD lets the people who need URI-grounded names have them, but at
> the same time presents enough of a barrier to discourage those who
> don't need them from using them.

Great! Then let those people adopt it. I would prefer that the output of =
*this work* in the IETF be much, much simpler than JSON-LD.

>  The last thing JSON needs is the
> simple equivalent of xmlns.

JSON doesn't need anything: JSON-using communities do. They should have =
good, simple, standardized tools.

--Paul Hoffman


From stpeter@stpeter.im  Wed Nov  9 08:31:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC7421F8B03 for ; Wed,  9 Nov 2011 08:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEBxnNLQSIm4 for ; Wed,  9 Nov 2011 08:31:24 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 013A221F8A70 for ; Wed,  9 Nov 2011 08:31:24 -0800 (PST)
Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A558D420DE; Wed,  9 Nov 2011 09:37:19 -0700 (MST)
Message-ID: <4EBAAAD8.8000903@stpeter.im>
Date: Wed, 09 Nov 2011 09:31:20 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Julian Reschke 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de>
In-Reply-To: <4EB98090.5020203@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham , Paul Hoffman , apps-discuss Discuss , Dominik Tomaszuk 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 16:31:28 -0000

On 11/8/11 12:18 PM, Julian Reschke wrote:
> On 2011-11-08 20:10, Mark Nottingham wrote:
>> I don't think URIs should be used for this.
>> ...
>
> Well, one use case that the proposal is addressing is the transport of
> data from frameworks that *already* use URIs; such a WebDAV properties
> or JCR identifiers. In these cases you really have only the choice of
> using the identifiers you have, or establishing a completely new
> identifier system.
>
> And yes, it would be helpful if the draft was just saying that and not
> make the impression that it was solving the generic problem for JSON.

There's always an opportunity for publishing -01. ;-)

I agree that a range of approaches might be appropriate among JSON-using 
communities -- pretty much the same range of approaches mentioned in the 
x- draft:

        implementation-specific and
        private-use parameters could at least incorporate the
        organization's name (e.g., "ExampleInc-foo" or, consistent with
        [RFC4288], "VND.ExampleInc.foo") or primary domain name (e.g.,
        "com.example.foo" or a Uniform Resource Identifier [RFC3986] such
        as "http://example.com/foo").

I'll work with my co-authors to submit -01 next week or soon thereafter.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From tbray@textuality.com  Wed Nov  9 08:31:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE8221F8C0A for ; Wed,  9 Nov 2011 08:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56Qk90ciDPep for ; Wed,  9 Nov 2011 08:31:44 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0B5921F8B08 for ; Wed,  9 Nov 2011 08:31:43 -0800 (PST)
Received: by vws5 with SMTP id 5so1872407vws.31 for ; Wed, 09 Nov 2011 08:31:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.169.34 with SMTP id ab2mr1007145obc.27.1320856302295; Wed, 09 Nov 2011 08:31:42 -0800 (PST)
Received: by 10.182.38.70 with HTTP; Wed, 9 Nov 2011 08:31:42 -0800 (PST)
X-Originating-IP: [12.185.136.2]
In-Reply-To: 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de> <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net> <4EB981B6.1090003@gmx.de>  <7797835D-26FA-45E4-B66B-A336666F7AC7@vpnc.org>  
Date: Wed, 9 Nov 2011 08:31:42 -0800
Message-ID: 
From: Tim Bray 
To: Paul Hoffman 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss Discuss 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 16:31:48 -0000

FWIW, I'd like to go on the record with my opinion that this work is
misguided.  This is a solution looking for a problem.   Clearly, a
robust JSON-based protocol SHOULD have a MustIgnore policy for things
it don't understand. And if I were putting things into a JSON message
that was to be tied to my software, it'd look like

{
    "size" : 23,
    "name" : "foo"
    "com.textuality.inferential-interfluidity" : 42
}

I think there are better ways to spend our time than on designing
something that really is not needed.

 -T

On Wed, Nov 9, 2011 at 8:20 AM, Paul Hoffman  wrote:
> On Nov 9, 2011, at 7:19 AM, Mark Baker wrote:
>
>> On Tue, Nov 8, 2011 at 9:19 PM, Paul Hoffman  wro=
te:
>>> On Nov 8, 2011, at 4:51 PM, Mark Baker wrote:
>>>
>>>> http://json-ld.org
>>>
>>>
>>> I would prefer that the output of this work was much, much simpler than=
 this.
>>
>> JSON-LD lets the people who need URI-grounded names have them, but at
>> the same time presents enough of a barrier to discourage those who
>> don't need them from using them.
>
> Great! Then let those people adopt it. I would prefer that the output of =
*this work* in the IETF be much, much simpler than JSON-LD.
>
>> =A0The last thing JSON needs is the
>> simple equivalent of xmlns.
>
> JSON doesn't need anything: JSON-using communities do. They should have g=
ood, simple, standardized tools.
>
> --Paul Hoffman
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From mnot@mnot.net  Wed Nov  9 09:23:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2636C21F8B9E for ; Wed,  9 Nov 2011 09:23:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 omr2AEk7IpRw for ; Wed,  9 Nov 2011 09:22:59 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E626F21F8BC5 for ; Wed,  9 Nov 2011 09:22:58 -0800 (PST)
Received: from [10.6.129.82] (unknown [64.39.4.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BA86422E25A; Wed,  9 Nov 2011 12:22:51 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 9 Nov 2011 11:22:51 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de> <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net> <4EB981B6.1090003@gmx.de>  <7797835D-26FA-45E4-B66B-A336666F7AC7@vpnc.org>  
To: Paul Hoffman 
X-Mailer: Apple Mail (2.1251.1)
Cc: apps-discuss Discuss 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 17:23:03 -0000

On 09/11/2011, at 10:20 AM, Paul Hoffman wrote:

> Great! Then let those people adopt it. I would prefer that the output =
of *this work* in the IETF be much, much simpler than JSON-LD.

+1

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





From mark@coactus.com  Wed Nov  9 09:43:12 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C00621F8C65 for ; Wed,  9 Nov 2011 09:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.852
X-Spam-Level: 
X-Spam-Status: No, score=-103.852 tagged_above=-999 required=5 tests=[AWL=-0.875, 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 9d1jfCfdjBx2 for ; Wed,  9 Nov 2011 09:43:07 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF8E21F8C41 for ; Wed,  9 Nov 2011 09:43:07 -0800 (PST)
Received: by iaeo4 with SMTP id o4so2544766iae.31 for ; Wed, 09 Nov 2011 09:43:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.153.74 with SMTP id l10mr4085782icw.52.1320860586593; Wed, 09 Nov 2011 09:43:06 -0800 (PST)
Sender: mark@coactus.com
Received: by 10.42.165.194 with HTTP; Wed, 9 Nov 2011 09:43:06 -0800 (PST)
In-Reply-To: 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <9D5B00CA-9370-45D6-835B-3C7A1ADFEBBC@mnot.net> <4EB97122.7010206@gmx.de>  <4EB98090.5020203@gmx.de> <6A0CCE36-5FBE-48E9-A307-1C59C155D8BB@mnot.net> <4EB981B6.1090003@gmx.de>  <7797835D-26FA-45E4-B66B-A336666F7AC7@vpnc.org>  
Date: Wed, 9 Nov 2011 12:43:06 -0500
X-Google-Sender-Auth: WoaDZBDVJM4c1fsCLQHiF-swxig
Message-ID: 
From: Mark Baker 
To: Paul Hoffman 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss Discuss 
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 17:43:12 -0000

On Wed, Nov 9, 2011 at 11:20 AM, Paul Hoffman  wrote:
> On Nov 9, 2011, at 7:19 AM, Mark Baker wrote:
>
>> On Tue, Nov 8, 2011 at 9:19 PM, Paul Hoffman  wrote:
>>> On Nov 8, 2011, at 4:51 PM, Mark Baker wrote:
>>>
>>>> http://json-ld.org
>>>
>>>
>>> I would prefer that the output of this work was much, much simpler than this.
>>
>> JSON-LD lets the people who need URI-grounded names have them, but at
>> the same time presents enough of a barrier to discourage those who
>> don't need them from using them.
>
> Great! Then let those people adopt it. I would prefer that the output of *this work* in the IETF be much, much simpler than JSON-LD.

Perhaps I wasn't clear; I'd prefer that there be no more work done, in
the IETF or anywhere.  I think JSON-LD is good enough for anybody
needing URI-grounded names.

Mark.

From julian.reschke@gmx.de  Wed Nov  9 09:56:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBB421F8C67 for ; Wed,  9 Nov 2011 09:56:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.962
X-Spam-Level: 
X-Spam-Status: No, score=-103.962 tagged_above=-999 required=5 tests=[AWL=-1.363, 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 Qf3+D3Eut+q5 for ; Wed,  9 Nov 2011 09:56:11 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4AF9921F8C58 for ; Wed,  9 Nov 2011 09:56:11 -0800 (PST)
Received: (qmail invoked by alias); 09 Nov 2011 17:56:09 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp007) with SMTP; 09 Nov 2011 18:56:09 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19xBVF7rNxxFR+hkOJl5P72wHKo9yoQHZN65jcdI+ SOMUHRF+OPKfnb
Message-ID: <4EBABEB4.2000108@gmx.de>
Date: Wed, 09 Nov 2011 18:56:04 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Graham Klyne 
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org>
In-Reply-To: <4EB8E7FA.5030406@ninebynine.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 17:56:16 -0000

On 2011-11-08 09:27, Graham Klyne wrote:
> It's not clear to me what purpose would be served that cannot be handled
> perfectly adequately by application/*
>
> My understanding (or impression over the years) was that the top-level
> MIME type was a kind of high-level dispatch indicator to a device
> capable of rendering or otherwise presenting the broad kind of content,
> with application/* serving for types that needed further processing
> before they might meaningfully be considered for presentation
>
> If I receive a font/* file, what might I do with it that is different
> from any other application/* type of file?
> ...

In HTTP:

	Accept: font/*

(not sure whether it would be useful, but at least that's one thing you 
need a top level type for...)

Best regards, Julian

From stpeter@stpeter.im  Wed Nov  9 09:57:05 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DED221F8C67 for ; Wed,  9 Nov 2011 09:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 vKP1bpP+59IG for ; Wed,  9 Nov 2011 09:57:05 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 18E4221F8C39 for ; Wed,  9 Nov 2011 09:57:00 -0800 (PST)
Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 22EC741FC7; Wed,  9 Nov 2011 11:02:56 -0700 (MST)
Message-ID: <4EBABEEA.8030905@stpeter.im>
Date: Wed, 09 Nov 2011 10:56:58 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp>
In-Reply-To: <4EB9D49C.5010100@it.aoyama.ac.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 17:57:05 -0000

On 11/8/11 6:17 PM, "Martin J. Dürst" wrote:
> On 2011/11/09 2:15, Mark Nottingham wrote:
>> Oh, I had thought it would be
>>
>> font/PostScript
>> font/TrueType
>>
>> i.e., NOT identifying the specific typeface in use. After all, we
>> don't have text/html/home-page, do we?
>
> It's definitely that.

Verified through conversation on the websec@ietf.org list. We're talking 
about a small number of file formats for fonts (TrueType, OpenType, Web 
Open Font Format, etc.) -- talking about typefaces, font families, 
particular fonts, etc.

Now, whether we need a top-level content type of "font", resulting in 
subtypes like font/woff (instead of, say, application/font-woff [1]) is 
another story...

/psa

[1] http://www.ietf.org/mail-archive/web/ietf-types/current/msg01115.html

From stpeter@stpeter.im  Wed Nov  9 09:58:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED2C21F8C39 for ; Wed,  9 Nov 2011 09:58:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.437
X-Spam-Level: 
X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 VPj5QkWJ+O8K for ; Wed,  9 Nov 2011 09:58:04 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F355D21F84ED for ; Wed,  9 Nov 2011 09:58:03 -0800 (PST)
Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 332FB41FC7; Wed,  9 Nov 2011 11:04:00 -0700 (MST)
Message-ID: <4EBABF2A.3060505@stpeter.im>
Date: Wed, 09 Nov 2011 10:58:02 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBABEEA.8030905@stpeter.im>
In-Reply-To: <4EBABEEA.8030905@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 17:58:04 -0000

On 11/9/11 10:56 AM, Peter Saint-Andre wrote:
> On 11/8/11 6:17 PM, "Martin J. Dürst" wrote:
>> On 2011/11/09 2:15, Mark Nottingham wrote:
>>> Oh, I had thought it would be
>>>
>>> font/PostScript
>>> font/TrueType
>>>
>>> i.e., NOT identifying the specific typeface in use. After all, we
>>> don't have text/html/home-page, do we?
>>
>> It's definitely that.
>
> Verified through conversation on the websec@ietf.org list. We're talking
> about a small number of file formats for fonts (TrueType, OpenType, Web
> Open Font Format, etc.) -- talking about typefaces, font families,
                            ^not^
> particular fonts, etc.




From paul.hoffman@vpnc.org  Wed Nov  9 10:01:43 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD2D21F8A95 for ; Wed,  9 Nov 2011 10:01:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level: 
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 0l96ddBJm+BX for ; Wed,  9 Nov 2011 10:01:42 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDD021F86AA for ; Wed,  9 Nov 2011 10:01:35 -0800 (PST)
Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pA9I1YGQ002718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 9 Nov 2011 11:01:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Paul Hoffman 
In-Reply-To: <4EBABEB4.2000108@gmx.de>
Date: Wed, 9 Nov 2011 10:01:34 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E4D8B6B-5674-4423-B1D9-31956D8D564A@vpnc.org>
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> <4EBABEB4.2000108@gmx.de>
To: apps-discuss Discuss 
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 18:01:43 -0000

On Nov 9, 2011, at 9:56 AM, Julian Reschke wrote:

> On 2011-11-08 09:27, Graham Klyne wrote:
>> It's not clear to me what purpose would be served that cannot be =
handled
>> perfectly adequately by application/*
>>=20
>> My understanding (or impression over the years) was that the =
top-level
>> MIME type was a kind of high-level dispatch indicator to a device
>> capable of rendering or otherwise presenting the broad kind of =
content,
>> with application/* serving for types that needed further processing
>> before they might meaningfully be considered for presentation
>>=20
>> If I receive a font/* file, what might I do with it that is different
>> from any other application/* type of file?
>> ...
>=20
> In HTTP:
>=20
> 	Accept: font/*
>=20
> (not sure whether it would be useful, but at least that's one thing =
you need a top level type for...)


The genesis for the current thread, I thought, was the websec WG's work =
on font-sniffing. "What might I do different" would be "do security =
checks", I believe. Folks who are more active on websec can answer this =
better.

--Paul Hoffman


From lyndon@orthanc.ca  Wed Nov  9 10:05:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B648121F8C8A for ; Wed,  9 Nov 2011 10:05:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwCS0wUNjGFT for ; Wed,  9 Nov 2011 10:05:38 -0800 (PST)
Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by ietfa.amsl.com (Postfix) with ESMTP id 4563621F8C73 for ; Wed,  9 Nov 2011 10:05:38 -0800 (PST)
Received: from rastawifi.orthanc.ca ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pA9I5beu041451 for ; Wed, 9 Nov 2011 10:05:37 -0800 (PST) (envelope-from lyndon@orthanc.ca)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Lyndon Nerenberg 
In-Reply-To: <4EBABEB4.2000108@gmx.de>
Date: Wed, 9 Nov 2011 10:05:36 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> <4EBABEB4.2000108@gmx.de>
To: apps-discuss@ietf.org
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 18:05:38 -0000

On 2011-11-09, at 9:56 AM, Julian Reschke wrote:

> In HTTP:
>=20
> 	Accept: font/*
>=20
> (not sure whether it would be useful, but at least that's one thing =
you need a top level type for...)

I was just about to argue the more general case.  IMAP is another place =
where there is utility in being able to recognize font blobs outright, =
without requiring knowledge of specific font representations.  E.g. a =
text-only IMAP client could ignore all font/* sections without having to =
annoy the end-user, who probably doesn't know what an =
application/opentype is.

Also, font/* with well defined parameters makes possible aggressive =
caching of fonts on bandwidth-constrained mobile clients.  XMPP =
immediately leaps to mind.

--lyndon=

From julian.reschke@gmx.de  Wed Nov  9 10:11:37 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0C21F84BD for ; Wed,  9 Nov 2011 10:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.935
X-Spam-Level: 
X-Spam-Status: No, score=-103.935 tagged_above=-999 required=5 tests=[AWL=-1.336, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DddgIo2OAwYR for ; Wed,  9 Nov 2011 10:11:36 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 523BA21F84BA for ; Wed,  9 Nov 2011 10:11:27 -0800 (PST)
Received: (qmail invoked by alias); 09 Nov 2011 18:11:22 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp010) with SMTP; 09 Nov 2011 19:11:22 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/fqTg/Md7fVfRw2R5O6GJP6qUhJeHedpNFwWXK9p UY+ipeWFLx9mRR
Message-ID: <4EBAC242.8020304@gmx.de>
Date: Wed, 09 Nov 2011 19:11:14 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Paul Hoffman 
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> <4EBABEB4.2000108@gmx.de> <7E4D8B6B-5674-4423-B1D9-31956D8D564A@vpnc.org>
In-Reply-To: <7E4D8B6B-5674-4423-B1D9-31956D8D564A@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss Discuss 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 18:11:37 -0000

On 2011-11-09 19:01, Paul Hoffman wrote:
> ...
> The genesis for the current thread, I thought, was the websec WG's work on font-sniffing. "What might I do different" would be "do security checks", I believe. Folks who are more active on websec can answer this better.
> ...

I think we got here because somebody claimed that font types don't have 
registered media types, because, some time ago, the IETF didn't want to 
register the top level type. Which, of course, is a totally separate issue.

Best regards, Julian

From ddooss@wp.pl  Wed Nov  9 12:21:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3D31F0C77 for ; Wed,  9 Nov 2011 12:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level: 
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95]
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 OmCGzSNMR6VY for ; Wed,  9 Nov 2011 12:21:45 -0800 (PST)
Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD571F0C6F for ; Wed,  9 Nov 2011 12:21:44 -0800 (PST)
Received: (wp-smtpd smtp.wp.pl 763 invoked from network); 9 Nov 2011 21:21:43 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1320870103; bh=uu+Fzo068BJAP22kI6mApDnAFMS8VN722uEPyTDdgHg=; h=From:To:CC:Subject; b=JWn6o5Kv1LNIN/JvZEH6FlTORhRQW8SskUMkchGa9cQUvElemPE8giyb7pJSecVYo NJED5931TG6QEDzYtPB34YyU/yrFje8OwbaUWQXGVDpTmsqhANv4cOPkfbDbjdBajP F7TsuH+eSVNMHBEeKMduvWo6yue2EVb4A63vGn00=
Received: from 77-253-97-19.adsl.inetia.pl (HELO [192.168.1.1]) (ddooss@[77.253.97.19]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 9 Nov 2011 21:21:43 +0100
Message-ID: <4EBAE0D6.3080801@wp.pl>
Date: Wed, 09 Nov 2011 21:21:42 +0100
From: Dominik Tomaszuk 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Paul Hoffman 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org>
In-Reply-To: <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO 0000006 [EebQ]                               
X-Mailman-Approved-At: Wed, 09 Nov 2011 12:46:48 -0800
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 20:21:46 -0000

On 08.11.2011 18:05, Paul Hoffman wrote:
>> I propose to give possibility to declare namespace.
>
> -1. Actually, -10. While somewhat useful for XML, namespaces have also proven to cause many headaches for corner cases.
I do not propose to reject Clark Notation and add declarative XML-like 
namespaces. My proposal was optional. If like long Clark Notation URLs' 
you can use it (advantage: easy processing). If you want short and 
non-repeated namespace you can declare it and use only reference 
(advantage: smaller and easier to read file).

All proposals for shortening are similar to my. You can use something 
like QNames, CURIE, or JSON-LD terms, but it is almost the same - all of 
them should be declared first.

Best regards,
Dominik Tomaszuk

From eburger@standardstrack.com  Wed Nov  9 13:00:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDB01F0C53 for ; Wed,  9 Nov 2011 13:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.641
X-Spam-Level: 
X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 V2Zny7t9XlCv for ; Wed,  9 Nov 2011 13:00:39 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 90F3F1F0C4D for ; Wed,  9 Nov 2011 13:00:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com;  h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=hNduliC+zPBHhxNBo7aCboHeRaF6zTaLruKv4LPq9WtvDt+3lkJyl4BijzNnEvet1L4WX4tAoRocxK3K0fvZZru8MFiiYaqUPTCWMEPqprGTVd7RWYw4qmQ7hXRFQMdE;
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:61740 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1ROFGA-00028C-54 for apps-discuss@ietf.org; Wed, 09 Nov 2011 13:00:38 -0800
From: Eric Burger 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-227--1032149059; protocol="application/pkcs7-signature"; micalg=sha1
Date: Wed, 9 Nov 2011 16:00:34 -0500
In-Reply-To: <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>
To: "apps-discuss@ietf.org Discuss" 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>
Message-Id: <56B202FE-ED81-4C36-AB4C-0A809F51D009@standardstrack.com>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 21:00:41 -0000

--Apple-Mail-227--1032149059
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Sounds like a call for a BOF.

On Nov 9, 2011, at 8:06 AM, John C Klensin wrote:

> Hi Martin,
>=20
> The links you gave to earlier messages don't work, but I don't
> recall "killing" a font proposal.  See inline below.
>=20
> --On Tuesday, November 08, 2011 15:49 +0900 "\"Martin J.
> D=FCrst\""  wrote:
>=20
>> ...
>>> Well, I think that a top-level would be in order -- these are
>>> really different from the existing types.  Things may have
>>> changed, but my recollection from when I had some exposure to
>>> them in the early 90s is that there are a bunch of font
>> ...
>> There is no need to overengineer this stuff. Like all other
>> types, it's simply a top level type, and a subtype. A very
>> rough approximation of what could end up in the subtype can be
>> found here: http://en.wikipedia.org/wiki/Category:Font_formats.
>=20
> I was, and remain, very hesitant about creating new top-level
> types.  As others have noted, it is a big deal.  There are
> several reasons for that but at least one important one is that
> the model for what an application is expected to do when it
> encounters an unknown top-level type is not, IMO, really well
> sorted out.  One cannot do much of anything (in that sense, it
> isn't much different from an application/ subtype), but it isn't
> clear how one should present that fact to a user who doesn't
> have much understanding or vocabulary about what is going on at
> the content-type level.
>=20
> "Model/" (as described in RFC 2077) was not a problem because
> the request came from a particular community for a particular
> type of use, one on which there was little or no likelihood of
> interaction with other types, especially with multipart content.
> I assume that the community that wanted that type is using it,
> but confess to never having seen the type in the wild.  If
> others haven't either, that reinforces the claim that the
> "model/" type really is independent of the others.
>=20
> If font/* is simply a "type and a subtype", then I'm inclined to
> agree with those who say "use application/".  Certainly it is
> feasible to say, e.g., "application/OpenType", specify it as
> being bound to the OpenType font definition model, say some
> things about encoding and parameters, and move on.  The fact
> that it and an equally hypothetical "application/TrueType" both
> encode/carry fonts creates no more of a requirement or
> justification for a top-level type than the observation that
> there application/ subtypes for Open Document and MSWord formats
> implies that we should have a top-level type for WordProcessor/
> or DocumentFormatter/.  And, as Graham and others have pointed
> out, we use "application/" (a lot) for subtypes that require
> processing or installation before something else can make use of
> them.
>=20
> I think a font/ top-level type would be worth looking at
> carefully if there really were a use case for which some
> application/ subtypes would not be appropriate.  One of those
> might lie along the path of compound documents that I mentioned
> in the context of "image/".   Perhaps there might be others, or
> perhaps not.  "Distinct media type" doesn't do much for me
> because what is, and is not, is largely in the mind of the
> beholder.
>=20
>> If some kind of 'Definition Language' is used inside a font
>> format, then that's just something under the hood. My
>> understanding is that some popular formats such as OpenType
>> essentially are mergers resulting from the "Definition
>> Language" wars in the early 1990.
>=20
> I used "Definition Language" to refer to what you are referring
> to as a "format" (which often means something else in this
> context).  I don't have enough contemporary knowledge to know
> what would be most accurate and consistent with current
> terminology -- another topic for Mark's wife or some other
> typographic expert.
>=20
>> Also, typeface, style, and
>> applicable range of sizes shouldn't be necessary as part of
>> the mime type because it's part of the content.
>=20
> I don't know what that means in practice.  Having struggled
> several times with what needs to be a parameter on a media type
> and subtype, it isn't obvious that parameters are unnecessary
> even if the information can be deduced from content.   I am
> particularly concerned about transmission of files that contain
> parts of a typeface family, but not all of it, as well as about
> a type and subtype that don't even identify the type family and
> hence may require a lot of work before a system can decide
> whether to install it.
>=20
> I also don't know whether all "Definition Languages" in use
> today contain the same descriptor information in reasonably
> compatible formats.   If some do and others require, e.g., the
> name of the font in supplemental information because only the
> glyph descriptions are stored in the file, then there is a lot
> of justification for parameters across the board if one is going
> to have a well-designed top-level type with homogeneous
> subtypes.  Of course, homogeneous subtypes are not a
> requirement, but, if each subtype will have to establish its own
> parameter model, it seems to me that the argument for just
> sticking with "application/" becomes stronger.
>=20
>> Some such parameters were proposed in
>> http://tools.ietf.org/html/draft-singer-font-mime-00, and may
>> still be necessary, but not as much as 7 years ago, when you
>> apparently shot down the proposal (see
>> http://www.ietf.org/mail-archive/web/ietf/current/msg33267.htm
>> l). So if the font experts say they really need a parameter,
>> we'll keep it, but we don't have to make thing more
>> complicated than necessary in advance.
>=20
>> The only RFC that defined a new top-level type is RFC 2077
>> (http://tools.ietf.org/html/rfc2077). It's rather short, and I
>> expect the font/ RFC to be even shorter unless it also
>> includes some registrations for actual subtypes (I'd probably
>> do it in two separate documents, one for the top-level type
>> and another for some low hanging subtypes, but I'll leave the
>> decision to whoever does the actual work.)
>=20
> While the "model/" spec is rather short, it contains the
> elements I'm trying to advocate here: a clear description of why
> a top-level type is needed, a discussion of use cases, and
> definitions of enough subtypes to make the use cases clear, as
> well as the required templates and mechanisms for defining
> future subtypes.
>=20
> Recommendation to those who want this:  Work on a few subtype
> definitions.  Sort the details, such as what parameters are
> needed, out with the typographic community.  Examine the use
> cases.   The would would need to be done --and would be almost
> the same-- for a subtype of application/ or a subtype of font/.
> With those tentative subtype descriptions in hand, the rest of
> us will be a lot more able to identify commonalities and to
> participate in an evaluation of whether a top-level type is
> really justified.
>=20
> best,
>   john
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail-227--1032149059
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w
ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR
Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w
NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx
FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx
ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz
dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx
B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8
om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG
TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl
yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j
BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j
b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu
Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw
DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8
NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s
APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK
N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU
TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD
AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU
IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw
MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD
VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9
VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD
jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS
TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy
fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B
AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU
ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw
EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0
LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG
AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy
dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN
BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu
PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i
kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq
szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L
SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC
AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E
TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI
hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T
aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ
9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX
56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0
FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud
IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC
mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB
BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw
KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK
oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k
U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny
dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi
dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp
KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R
nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P
e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0
okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A
JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM
aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMTA5MjEwMDM0WjAjBgkqhkiG9w0BCQQxFgQU
YeNKTYiDwps6nsCcw29GEm9vSwQwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug
gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT
B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw
DQYJKoZIhvcNAQEBBQAEggEAfhofjI2QILKYyvrEt7GtliM2hpkhIitsaNCihu5J58D18SHKXYtC
hyD58FERlhFwjYJS3ovkaHw8m39T0ErvUu23JXBYFTsRalGkUJisKrk6SyWOCOQ5z1qcfxyKbFFb
tjkIIW/eMYpMLwKicNn6dxMGcnQQF3ibJfOPj09LTl74E/D6TNvVyPGQqPHA7QLaLTtK8PgKyxwL
k/ZofLBEQoLVDu3q3scP/rOo4ruuOmBCRnwl0UYeDA3WAFbB6BG+uHDLK4ntunklQJEAps0wtvqo
+vfOQu3AOZDCTyra63CG2Y6LB6REmyvXDZyLzLuOqZZX92mcD8UFnEAGPvZpVgAAAAAAAA==

--Apple-Mail-227--1032149059--

From john-ietf@jck.com  Wed Nov  9 13:07:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071B311E80A1 for ; Wed,  9 Nov 2011 13:07:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.269
X-Spam-Level: 
X-Spam-Status: No, score=-102.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 n63bFbphVY+v for ; Wed,  9 Nov 2011 13:07:47 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9312F11E80AB for ; Wed,  9 Nov 2011 13:07:46 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1ROFN3-00002L-SD; Wed, 09 Nov 2011 16:07:46 -0500
Date: Wed, 09 Nov 2011 16:07:45 -0500
From: John C Klensin 
To: Eric Burger , "apps-discuss@ietf.org Discuss" 
Message-ID: 
In-Reply-To: <56B202FE-ED81-4C36-AB4C-0A809F51D009@standardstrack.com>
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <56B202FE-ED81-4C36-AB4C-0A809F51D009@standardstrack.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 21:07:48 -0000

--On Wednesday, November 09, 2011 16:00 -0500 Eric Burger
 wrote:

> Sounds like a call for a BOF.

Only if we can get some serious typographic folks there.
Otherwise, I'd personally prefer to see a few I-Ds.  Since there
is no change of getting a BOF together before next week, some
documents on which the community could base decisions would have
a chance of being a lot faster, too.

best,
   john

 
> On Nov 9, 2011, at 8:06 AM, John C Klensin wrote:
> 
>> Hi Martin,
>> 
>> The links you gave to earlier messages don't work, but I don't
>> recall "killing" a font proposal.  See inline below.
>...
>> I was, and remain, very hesitant about creating new top-level
>> types.  As others have noted, it is a big deal.  There are
>> several reasons for that but at least one important one is
>> that the model for what an application is expected to do when
>> it encounters an unknown top-level type is not, IMO, really
>> well sorted out.  One cannot do much of anything (in that
>> sense, it isn't much different from an application/ subtype),
>> but it isn't clear how one should present that fact to a user
>> who doesn't have much understanding or vocabulary about what
>> is going on at the content-type level.
>...
>> Recommendation to those who want this:  Work on a few subtype
>> definitions.  Sort the details, such as what parameters are
>> needed, out with the typographic community.  Examine the use
>> cases.   The would would need to be done --and would be almost
>> the same-- for a subtype of application/ or a subtype of
>> font/. With those tentative subtype descriptions in hand, the
>> rest of us will be a lot more able to identify commonalities
>> and to participate in an evaluation of whether a top-level
>> type is really justified.
>> 
>> best,
>>   john
>> 
>> 
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
> 





From stpeter@stpeter.im  Wed Nov  9 13:11:12 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A7121F8496 for ; Wed,  9 Nov 2011 13:11:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level: 
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 g5+uY5aU5mua for ; Wed,  9 Nov 2011 13:11:12 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1C01921F8495 for ; Wed,  9 Nov 2011 13:11:12 -0800 (PST)
Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 81D8941FC7; Wed,  9 Nov 2011 14:17:08 -0700 (MST)
Message-ID: <4EBAEC6E.2040405@stpeter.im>
Date: Wed, 09 Nov 2011 14:11:10 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: John C Klensin 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <56B202FE-ED81-4C36-AB4C-0A809F51D009@standardstrack.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 21:11:12 -0000

On 11/9/11 2:07 PM, John C Klensin wrote:
>
>
> --On Wednesday, November 09, 2011 16:00 -0500 Eric Burger
>   wrote:
>
>> Sounds like a call for a BOF.
>
> Only if we can get some serious typographic folks there.
> Otherwise, I'd personally prefer to see a few I-Ds.  Since there
> is no change of getting a BOF together before next week, some
> documents on which the community could base decisions would have
> a chance of being a lot faster, too.

Documents are good. I'll reach out to folks at the W3C to see if someone 
who's involved in the Web Open Font Format work might be able to put 
some energy into these discussions.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From stpeter@stpeter.im  Wed Nov  9 15:54:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE3311E809A; Wed,  9 Nov 2011 15:54:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.83
X-Spam-Level: 
X-Spam-Status: No, score=-102.83 tagged_above=-999 required=5 tests=[AWL=-0.231, 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 nat7wzQdx+ZW; Wed,  9 Nov 2011 15:54:04 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBAD11E8080; Wed,  9 Nov 2011 15:54:03 -0800 (PST)
Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E26CA41FC7; Wed,  9 Nov 2011 16:59:57 -0700 (MST)
Message-ID: <4EBB1296.1090803@stpeter.im>
Date: Wed, 09 Nov 2011 16:53:58 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ned Freed 
References: <01O827GOAJG200XBUL@mauve.mrochek.com> <4EB68E47.5010807@gmx.de> <01O83KX13YW800XBUL@mauve.mrochek.com>
In-Reply-To: <01O83KX13YW800XBUL@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "happiana@ietf.org" , IETF Apps Discuss 
Subject: Re: [apps-discuss] [happiana] draft-freed-media-type-regs-01 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 23:54:04 -0000

On 11/6/11 11:47 AM, Ned Freed wrote:



>> - 4.2 - "X-" prefixes - this obviously should be coordinated with
>> Peter's document.

draft-ietf-appsawg-xdash, that is. It's not only my draft, since I have 
two capable co-authors helping me. :)

> Er, actually, it rather obviously should not. Peter's draft is focused on
> preventing *new* uses of the X- convention. It doesn't address the issue of
> what to do about existing x- usage, which is a rather naunced and tricky
> area.
>
> Now, if you want to argue that Peter's draft should address how to deal
> with
> existing x- usage in various places, well, that's a discussion you need
> to have
> to have elsewhere. If and when that happens it may make sense to refer to
> such a document. Or not - it would depend on what it said.

We've deliberately punted on that issue in draft-ietf-appsawg-xdash, 
which does *not* modify registration procedures for any existing registries.

> In any case, the current approach taken to the X- issue here is to:
>
> (1) Strongly discourage the use of such names.

At which point an informational reference to draft-ietf-appsawg-xdash 
might be appropriate (for those who want a more detailed treatment of 
the topic).

> (2) In the event such a name gets widely deployed in spite of it's lack
> of registration, allow it to be registered in the vnd. tree.
>
> This wasn't noted in the changes since the last version list and I have
> addressed that.

Thanks for the clarifications.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From duerst@it.aoyama.ac.jp  Wed Nov  9 17:40:17 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4802B1F0C3E for ; Wed,  9 Nov 2011 17:40:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.557
X-Spam-Level: 
X-Spam-Status: No, score=-99.557 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Veqs99RblitL for ; Wed,  9 Nov 2011 17:40:16 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 304501F0C34 for ; Wed,  9 Nov 2011 17:40:16 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAA1e2Em006743 for ; Thu, 10 Nov 2011 10:40:02 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5910_43da_e7c7b8b8_0b3c_11e1_bbef_001d096c5782; Thu, 10 Nov 2011 10:40:01 +0900
Received: from [IPv6:::1] ([133.2.210.1]:36242) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Nov 2011 10:40:04 +0900
Message-ID: <4EBB2B60.9010108@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 10:39:44 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBABEEA.8030905@stpeter.im>
In-Reply-To: <4EBABEEA.8030905@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 01:40:17 -0000

On 2011/11/10 2:56, Peter Saint-Andre wrote:

> Now, whether we need a top-level content type of "font", resulting in
> subtypes like font/woff (instead of, say, application/font-woff [1]) is
> another story...

It would be good if we could answer this question soon, and hopefully in 
the positive.

The (Web)font community has tried to get a font/ top level type 
repeatedly, with bad results. At least two attempts are documented.

In http://lists.w3.org/Archives/Public/www-font/2009JulSep/1069.html, 
Chris Lilley describes his attempt around 1998 or so, which met active 
resistance ("we will strenuously oppose this and take up lots of your 
time if you persist").

The second attempt is documented at
http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0012.html
which got a single, (from their point of view) rather scary reply.

Unless we can tell them that we will look at a new proposal favorably, 
(at least) because either a new font/ or reusing application/ look okay, 
and if they think font/ is better, they should go with it, then I don't 
think they'll have the courage to try again.

Regards,   Martin.

From duerst@it.aoyama.ac.jp  Wed Nov  9 17:40:40 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F771F0C47 for ; Wed,  9 Nov 2011 17:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.564
X-Spam-Level: 
X-Spam-Status: No, score=-99.564 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNEfGBcd7HAB for ; Wed,  9 Nov 2011 17:40:39 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 16D8E1F0C34 for ; Wed,  9 Nov 2011 17:40:37 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAA1ea8H015833 for ; Thu, 10 Nov 2011 10:40:37 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6626_67ca_fcf59c0a_0b3c_11e1_89fb_001d096c566a; Thu, 10 Nov 2011 10:40:36 +0900
Received: from [IPv6:::1] ([133.2.210.1]:36249) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Nov 2011 10:40:40 +0900
Message-ID: <4EBB2B83.3060901@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 10:40:19 +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: John C Klensin 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>
In-Reply-To: <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 01:40:40 -0000

Hello John, others,

On 2011/11/09 22:06, John C Klensin wrote:
> Hi Martin,
>
> The links you gave to earlier messages don't work,

Please try again at
http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html

If it still doesn't work (it worked for me), please make sure to put all 
the pieces back together that have been split over more than one line. 
It seems that in my mail, the final "l" of the ".html" extension got 
split off to the next line.

> but I don't
> recall "killing" a font proposal.  See inline below.

I have to apologize for using the word "killing", I regretted it shortly 
after sending the mail.

It was after I looked at
http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0012.html,
which links to your mail.

Reading your mail, and David Singer's summary, it's not surprising that 
they gave up. You ask for very strong arguments of why a new top-level 
type is needed, and application/ isn't good enough. You also ask them to 
examine whether there's not a more general concept behind the top-level 
type of font.

For people e.g. on this list who now your writing style, such a mail 
wouldn't have been too much of a show-stopper. But for outsiders, and 
given that this was the only feedback they got (which isn't your fault), 
it must have sounded quite scary.

> --On Tuesday, November 08, 2011 15:49 +0900 "\"Martin J.
> Dürst\""  wrote:
>
>> ...
>>> Well, I think that a top-level would be in order -- these are
>>> really different from the existing types.  Things may have
>>> changed, but my recollection from when I had some exposure to
>>> them in the early 90s is that there are a bunch of font
>> ...
>> There is no need to overengineer this stuff. Like all other
>> types, it's simply a top level type, and a subtype. A very
>> rough approximation of what could end up in the subtype can be
>> found here: http://en.wikipedia.org/wiki/Category:Font_formats.
>
> I was, and remain, very hesitant about creating new top-level
> types.

In general, that's a good idea.

> As others have noted, it is a big deal.

I think that it's a big deal mostly because some people think it's a big 
deal. I haven't seen any serious arguments about why it actually is a 
big deal.

> There are
> several reasons for that but at least one important one is that
> the model for what an application is expected to do when it
> encounters an unknown top-level type is not, IMO, really well
> sorted out.

RFC 2046 clearly envisions the creation of additional top-level types, 
and so if there are applications that aren't ready to deal with them, 
then that's their fault. But I don't think that in actual practice, this 
would be a problem (if you think it will, please show me a concrete case).

>  One cannot do much of anything (in that sense, it
> isn't much different from an application/ subtype), but it isn't
> clear how one should present that fact to a user who doesn't
> have much understanding or vocabulary about what is going on at
> the content-type level.

Do you think the user will be more confused by a message saying
     Downloading file, type: font/woff, Open or Save?
or by a message saying
     Downloading file, type: application/woff, Open or Save?

At least in the former, they might see the word "font" and get a clue. 
So I think this issue is essentially irrelevant.


> "Model/" (as described in RFC 2077) was not a problem because
> the request came from a particular community for a particular
> type of use, one on which there was little or no likelihood of
> interaction with other types, especially with multipart content.

I think this is wrong. There is lots of potential interaction between 3D 
models and text, audio, video, images, and other application data. The 
reason you aren't seeing any of this is because there are umpteen 
reasons (which I don't think we need to discuss here) for why 3D hasn't 
caught on (yet?) on the Web and the Internet.

> I assume that the community that wanted that type is using it,
> but confess to never having seen the type in the wild.  If
> others haven't either, that reinforces the claim that the
> "model/" type really is independent of the others.

See above.

> If font/* is simply a "type and a subtype", then I'm inclined to
> agree with those who say "use application/".  Certainly it is
> feasible to say, e.g., "application/OpenType", specify it as
> being bound to the OpenType font definition model, say some
> things about encoding and parameters, and move on.  The fact
> that it and an equally hypothetical "application/TrueType" both
> encode/carry fonts creates no more of a requirement or
> justification for a top-level type than the observation that
> there application/ subtypes for Open Document and MSWord formats
> implies that we should have a top-level type for WordProcessor/
> or DocumentFormatter/.  And, as Graham and others have pointed
> out, we use "application/" (a lot) for subtypes that require
> processing or installation before something else can make use of
> them.

We can always throw everything into application/. But then, why do we 
have image/, audio/, and video/ (and text/; I'm putting text/ in 
parentheses because there are very specific handling rules that don't 
apply to any of the other types) in the first place?

For people involved with fonts (and many others, as we have seen on this 
list), fonts are not images, they are not video, and they are not audio, 
but they are also not just application data. These people (including 
many typographers and other font experts, with lots of Web and Internet 
experience) think that font/ is the right thing to do. They have tried 
several times (see my mail to Peter).


> I think a font/ top-level type would be worth looking at
> carefully if there really were a use case for which some
> application/ subtypes would not be appropriate.  One of those
> might lie along the path of compound documents that I mentioned
> in the context of "image/".   Perhaps there might be others, or
> perhaps not.  "Distinct media type" doesn't do much for me
> because what is, and is not, is largely in the mind of the
> beholder.

So why don't we change policies so that new image types also have to be 
registered under application/?

>> If some kind of 'Definition Language' is used inside a font
>> format, then that's just something under the hood. My
>> understanding is that some popular formats such as OpenType
>> essentially are mergers resulting from the "Definition
>> Language" wars in the early 1990.
>
> I used "Definition Language" to refer to what you are referring
> to as a "format" (which often means something else in this
> context).  I don't have enough contemporary knowledge to know
> what would be most accurate and consistent with current
> terminology -- another topic for Mark's wife or some other
> typographic expert.

There are experts who have the knowledge. They have tried to register 
font/ previously. Why don't we trust them?


>> Also, typeface, style, and
>> applicable range of sizes shouldn't be necessary as part of
>> the mime type because it's part of the content.
>
> I don't know what that means in practice.  Having struggled
> several times with what needs to be a parameter on a media type
> and subtype, it isn't obvious that parameters are unnecessary
> even if the information can be deduced from content.   I am
> particularly concerned about transmission of files that contain
> parts of a typeface family, but not all of it, as well as about
> a type and subtype that don't even identify the type family and
> hence may require a lot of work before a system can decide
> whether to install it.

With Web fonts, or with fonts attached to other documents such as 
emails, partial fonts are indeed very important. But they will be 
installed temporarily. Also, for Web fonts, the main usage is via CSS, 
which makes sure there's enough meta-information.


> I also don't know whether all "Definition Languages" in use
> today contain the same descriptor information in reasonably
> compatible formats.   If some do and others require, e.g., the
> name of the font in supplemental information because only the
> glyph descriptions are stored in the file, then there is a lot
> of justification for parameters across the board if one is going
> to have a well-designed top-level type with homogeneous
> subtypes.

Would it be possible to let the font experts figure this out?


>> Some such parameters were proposed in
>> http://tools.ietf.org/html/draft-singer-font-mime-00, and may
>> still be necessary, but not as much as 7 years ago, when you
>> apparently shot down the proposal (see
>> http://www.ietf.org/mail-archive/web/ietf/current/msg33267.htm
>> l). So if the font experts say they really need a parameter,
>> we'll keep it, but we don't have to make thing more
>> complicated than necessary in advance.
>
>> The only RFC that defined a new top-level type is RFC 2077
>> (http://tools.ietf.org/html/rfc2077). It's rather short, and I
>> expect the font/ RFC to be even shorter unless it also
>> includes some registrations for actual subtypes (I'd probably
>> do it in two separate documents, one for the top-level type
>> and another for some low hanging subtypes, but I'll leave the
>> decision to whoever does the actual work.)
>
> While the "model/" spec is rather short, it contains the
> elements I'm trying to advocate here: a clear description of why
> a top-level type is needed, a discussion of use cases, and
> definitions of enough subtypes to make the use cases clear, as
> well as the required templates and mechanisms for defining
> future subtypes.

I don't disagree here (except that RFC 2077 doesn't actually define 
subtypes, just gives some example of things that might be expected).

I agree that having a bit of text on why a new subtype was chosen can't 
hurt at all. But I think we have to be careful and not make this a 
sysiphean exercise by requiring something like a proof that a new 
top-level type was absolutely necessary because otherwise the world will 
go under.

> Recommendation to those who want this:  Work on a few subtype
> definitions.  Sort the details, such as what parameters are
> needed, out with the typographic community.  Examine the use
> cases.   The would would need to be done --and would be almost
> the same-- for a subtype of application/ or a subtype of font/.
> With those tentative subtype descriptions in hand, the rest of
> us will be a lot more able to identify commonalities and to
> participate in an evaluation of whether a top-level type is
> really justified.

Sorry, John, but they have tried before. They don't have much trust 
anymore. If we again tell them what sounds to them as "bring it on, and 
we'll do our best to shoot it down and make your life miserable",  then 
they won't do the work. They won't do it for font/, and they also won't 
do it for application/. I don't think that's what we want.

Regards,    Martin.

From duerst@it.aoyama.ac.jp  Wed Nov  9 17:47:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2EB1F0C3D for ; Wed,  9 Nov 2011 17:47:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.571
X-Spam-Level: 
X-Spam-Status: No, score=-99.571 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0wqGbmHHm9J for ; Wed,  9 Nov 2011 17:47:26 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 91ACB1F0C34 for ; Wed,  9 Nov 2011 17:47:25 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAA1lOe7020331 for ; Thu, 10 Nov 2011 10:47:24 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6625_4307_f02f4bbe_0b3d_11e1_89fb_001d096c566a; Thu, 10 Nov 2011 10:47:24 +0900
Received: from [IPv6:::1] ([133.2.210.1]:60666) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Nov 2011 10:47:28 +0900
Message-ID: <4EBB2D1B.5010206@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 10:47:07 +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: dcrocker@bbiw.net
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> <4EB9D46B.8010808@dcrocker.net>
In-Reply-To: <4EB9D46B.8010808@dcrocker.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 01:47:26 -0000

On 2011/11/09 10:16, Dave CROCKER wrote:
> On 11/8/2011 4:27 PM, Graham Klyne wrote:
>> It's not clear to me what purpose would be served that cannot be handled
>> perfectly adequately by application/*

Then why do we have image/, audio/, and video/? application/ would be 
perfectly adequate for them, wouldn't it?

> Thanks for raising this point. On reflection, I seem to recall that
> adding top-level types is a Big Deal and not done.

Please don't use hearsay and rumors as arguments.

Of course adding a top-level type isn't something that's done every day, 
but the last one was added almost 15 years (model/, January 1997, RFC 
2077), and no next one (after font/) is lined up.

Also, RFC 2046 explicitly allows additions of top-level types (see the 
very end of 
http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0012.html):

    It should be noted that the list of media type values given here may
    be augmented in time, via the mechanisms described above, and that
    the set of subtypes is expected to grow substantially.

> Your question points to the alternative that constitutes a less
> disruptive challenge to the current proposal.

In what sense is adding a font/ top-level type "disruptive"?

Regards,   Martin.

From derhoermi@gmx.net  Wed Nov  9 17:58:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F1E1F0C34 for ; Wed,  9 Nov 2011 17:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level: 
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 NB2lis9UCicM for ; Wed,  9 Nov 2011 17:58:24 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id F41551F0C3E for ; Wed,  9 Nov 2011 17:58:23 -0800 (PST)
Received: (qmail invoked by alias); 10 Nov 2011 01:58:21 -0000
Received: from dslb-094-222-132-099.pools.arcor-ip.net (EHLO HIVE) [94.222.132.99] by mail.gmx.net (mp008) with SMTP; 10 Nov 2011 02:58:21 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+009N2gLS0l6EG9PKDmj2ey9aGs7KyiNygEwlb1t GjyI3JZbXhbAyB
From: Bjoern Hoehrmann 
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
Date: Thu, 10 Nov 2011 02:58:18 +0100
Message-ID: <4ibmb7ldnqafmpem59e5umf9286ivn1f1k@hive.bjoern.hoehrmann.de>
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> <4EB9D46B.8010808@dcrocker.net> <4EBB2D1B.5010206@it.aoyama.ac.jp>
In-Reply-To: <4EBB2D1B.5010206@it.aoyama.ac.jp>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Graham Klyne , dcrocker@bbiw.net, "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 01:58:25 -0000

* Martin J. Dürst wrote:
>On 2011/11/09 10:16, Dave CROCKER wrote:
>> Thanks for raising this point. On reflection, I seem to recall that
>> adding top-level types is a Big Deal and not done.

>Of course adding a top-level type isn't something that's done every day, 
>but the last one was added almost 15 years (model/, January 1997, RFC 
>2077), and no next one (after font/) is lined up.

RFC 4735 introduced the "example" top level type in 2006. As far as I
can tell, there were a total of three comments on it, one on ietf-types
and two from the IESG, none of which were particularily negative.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From dhc@dcrocker.net  Wed Nov  9 17:59:20 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76A41F0C3E for ; Wed,  9 Nov 2011 17:59:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.538
X-Spam-Level: 
X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_34=1, RCVD_IN_DNSWL_MED=-4, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=1.666]
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 YMqOpMbTYp6U for ; Wed,  9 Nov 2011 17:59:19 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A43401F0C34 for ; Wed,  9 Nov 2011 17:59:17 -0800 (PST)
Received: from [192.168.0.229] (61-230-51-213.dynamic.hinet.net [61.230.51.213]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAA1x85R005379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Nov 2011 17:59:16 -0800
Message-ID: <4EBB2FEA.5060602@dcrocker.net>
Date: Thu, 10 Nov 2011 09:59:06 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org Discuss" 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp>
In-Reply-To: <4EB9D49C.5010100@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 09 Nov 2011 17:59:16 -0800 (PST)
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 01:59:20 -0000

> http://fontfeed.com/archives/font-or-typeface/ explains that in very simple
> terms. As far as the analogy there with MP3<=>font, song<=>typeface goes, we
> definitely need Mime types for fonts, not for typefaces.


Forgive me for feeling the need to be entirely pedantic here, but the article 
went just shy of being completely clear (for me) and I think it is indeed worth 
having us all not merely on the same page, but the same place on the page...

Is this correct:

    Typeface:  times roman

    Font:      times roman, 12pt

    Font:      times roman, 10pt

    Font:      times roman, 10pt, italic

    Font:      times roman, 10pt, bold

Yes?

That is, typeface is the basic design (or abstraction) while typeface + physical 
details (such as specific size) is a font?

Tnx.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From dhc@dcrocker.net  Wed Nov  9 18:31:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C72E11E8086 for ; Wed,  9 Nov 2011 18:31:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQyU4fAJJUMc for ; Wed,  9 Nov 2011 18:31:12 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C7B9D11E8088 for ; Wed,  9 Nov 2011 18:31:12 -0800 (PST)
Received: from [192.168.0.229] (61-31-89-133.static.tfn.net.tw [61.31.89.133]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAA2V00n005895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Nov 2011 18:31:11 -0800
Message-ID: <4EBB3762.6000907@dcrocker.net>
Date: Thu, 10 Nov 2011 10:30:58 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Eric Burger 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <56B202FE-ED81-4C36-AB4C-0A809F51D009@standardstrack.com>
In-Reply-To: <56B202FE-ED81-4C36-AB4C-0A809F51D009@standardstrack.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 09 Nov 2011 18:31:12 -0800 (PST)
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 02:31:13 -0000

On 11/10/2011 5:00 AM, Eric Burger wrote:
> Sounds like a call for a BOF.


For a topic like this, I believe a BOF makes sense only for either or both of:

    1.  Interactive tutorial, to create a community of folk who share a common 
set of information and are going to proceed doing some work on the topic. 
Hence, this would prime the work pump.

    2.  Debate particulars, prior to formulating a spec.  One can argue that 
that sounds like a regular working group, but I've tailored the description to 
fit a before-wg phase.  In any event, this presumes that folks are already 
sharing a common base of knowledge and details and merely need to debates some 
details.

My sense of this extended thread is that the group ain't quite far enough along 
for #2.  I can't tell whether #1 is needed.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From derhoermi@gmx.net  Wed Nov  9 18:38:45 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B0421F858D for ; Wed,  9 Nov 2011 18:38:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level: 
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 ea2cKynSaFv8 for ; Wed,  9 Nov 2011 18:38:44 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6E51321F858C for ; Wed,  9 Nov 2011 18:38:44 -0800 (PST)
Received: (qmail invoked by alias); 10 Nov 2011 02:38:42 -0000
Received: from dslb-094-222-132-099.pools.arcor-ip.net (EHLO HIVE) [94.222.132.99] by mail.gmx.net (mp060) with SMTP; 10 Nov 2011 03:38:42 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/OyAJ9OVDOvDGqhCS6un2uux1v4t3NZcygFsUwcy qxzuMclGjGtOPb
From: Bjoern Hoehrmann 
To: Peter Saint-Andre 
Date: Thu, 10 Nov 2011 03:38:41 +0100
Message-ID: 
References: <4EB86078.8070904@stpeter.im>
In-Reply-To: <4EB86078.8070904@stpeter.im>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 02:38:45 -0000

* Peter Saint-Andre wrote:
>In talking with folks at the W3C meeting last week, I heard yet again of
>interest in defining a Content Type for fonts. Would anyone active in
>the IETF Applications Area want to work on such a spec? And do folks
>here think a new top-level content type is needed for fonts?

As it is, the expectation is that HTTP responses should indicate the
format of frequently used resources should be indicated in the Content-
Type header, and Content-Type values should be registered MIME types.
We can expect the number of HTTP responses that carry some "font" will
increase in frequency, so there should be registered types for the un-
derlying formats. I don't think that is controversial, and I do not
think it matters much whether the few interesting types would go under
"font/" or under "application/". This thread seems to have generated
more feedback than I would expect if someone had just gone ahead and
brought a corresponding Internet-Draft to the IESG for approval. I am
happy to review any font type registrations on ietf-types, and would
of course support such registrations if they meet relevant criteria.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From dhc@dcrocker.net  Wed Nov  9 18:55:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6CD21F86EE for ; Wed,  9 Nov 2011 18:55:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGwLYwn70LHW for ; Wed,  9 Nov 2011 18:55:18 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 22FB121F8449 for ; Wed,  9 Nov 2011 18:55:18 -0800 (PST)
Received: from [192.168.0.229] (61-31-89-133.static.tfn.net.tw [61.31.89.133]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAA2sspr006330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Nov 2011 18:55:07 -0800
Message-ID: <4EBB3CFC.5050608@dcrocker.net>
Date: Thu, 10 Nov 2011 10:54:52 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 09 Nov 2011 18:55:17 -0800 (PST)
Subject: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 02:55:18 -0000

Folks,

The font thread has re-raised the issue of registering a Top-Level Content-Type 
(TLCT).  I haven't seen clear statements or documents of a theory or rationale 
that would guide accepting or rejecting a request for a TLCT, and I think we 
should (finally) remedy this deficiency.

In an earlier note I cited a recollection of resistance to new TLCTs.  But I 
don't remember the reasons, though I seem to recall both substance and vigor to 
the reasons.

We should try to resurrect or re-create a simple, pragmatic set of guidelines, 
and document them, so we don't have to go through the kind of vague exchanges 
happening now, with respect to arguing whether a new TLCT is appropriate.

The purpose of this thread is to press for a brief document that resolves this 
kind of debate and that can be used going forward in designing the "structure" 
of new registration groups.  This ought to be in terms of real pragmatics, 
rather than aesthetics or personal preference.

I can think of only two pragmatic issues in registering names like this:

    1.  Administrative convenience.  A hierarchy permits administrative grouping 
and possibly the convenience of delegating subsets of registration.  Obviously 
the DNS is the prime example.  At very large scale, this is essential.  At small 
scale, extra structure can be a hassle.

        I'm not seeing convenience as an issue for Content-Type, but perhaps 
others see the issue differently.  That is, my sense is that the entire data 
base of content-types is small enough to a) remain centralized, and b) not 
otherwise needing to benefit from sub-setting.

        This calls to question why there are /any/ sub-types, of course,  but 
I'd rather cast the issue in terms of going forward, rather than of history.


    2.  Code dispatching.  Different content-types invoke different software 
segments.  Parameters are input to the code but do invoke different "programs".

        I am not seeing how a TLCT vs. sub-type distinction affects this issue. 
  That is, it seems to me that

           C-T: major/minor

has equal software utility as

           C-T:application/major-minor

Any useful difference seems to be to fall under #1, above, rather than under a 
software behavior distinction.  What am I missing?


The 'model' document talks about a benefit of grouping sub-types, but I do not 
understand what the software benefit is, in terms of MIME Content-type.  That 
is, the benefit seems to be a local benefit within the model world, rather than 
more generally within the MIME world.  Again, what am I missing?


To take the 'font' discussion as an immediate, real-world exemplar, I think the 
above says that a logical hierarchy should have the representation engine be 
superior to the typeface or font specification, since it affects software 
dispatch.

Also, I don't see what the driving need for a TLCT is for font (or face...) 
It's aesthetically appealing, but I don't see the technical or administrative 
benefit.  Hence, here's one last:  what am I missing?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From john-ietf@jck.com  Wed Nov  9 18:56:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0933311E8082 for ; Wed,  9 Nov 2011 18:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.127
X-Spam-Level: 
X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 mGYL39RuUIMx for ; Wed,  9 Nov 2011 18:56:34 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 2412811E8081 for ; Wed,  9 Nov 2011 18:56:33 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1ROKoR-0008Va-Kb; Wed, 09 Nov 2011 21:56:24 -0500
Date: Wed, 09 Nov 2011 21:56:22 -0500
From: John C Klensin 
To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= 
Message-ID: 
In-Reply-To: <4EBB2B83.3060901@it.aoyama.ac.jp>
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 02:56:35 -0000

--On Thursday, November 10, 2011 10:40 +0900 "\"Martin J.
D=C3=BCrst\""  wrote:

> Hello John, others,
>=20
> On 2011/11/09 22:06, John C Klensin wrote:
>> Hi Martin,
>>=20
>> The links you gave to earlier messages don't work,
>=20
> Please try again at
> =
http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html

That did it, thanks.

>...
>> but I don't
>> recall "killing" a font proposal.  See inline below.
>=20
> I have to apologize for using the word "killing", I regretted
> it shortly after sending the mail.

No problem.  It does seem as if I'm consistent in wondering
whether a top-level type is actually necessary.   I am slightly
less concerned about the implications of a relatively small
number of subtypes than I was then.  But, as others have said
more emphatically than I have, a new top-level type should
require a lot of justification.

> It was after I looked at
> http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov
> /0012.html,
> which links to your mail.

That note suggests that mine was the only comment.   If so, I'd
assume the proposal basically ran out of steam because not
enough people cared.   In that sense, more progress has already
been made this time because there has been a discussion.

> Reading your mail, and David Singer's summary, it's not
> surprising that they gave up. You ask for very strong
> arguments of why a new top-level type is needed, and
> application/ isn't good enough. You also ask them to examine
> whether there's not a more general concept behind the
> top-level type of font.

I think others have made the same request wrt new top-level
types rather than application/.   Of course the existence of PFR
(which I assume is still in use) as an application/ subtype
doesn't strengthen the case that a separate top-level type is
needed.

And, yes, creating a new top level type for a half-dozen or
fewer subtypes does seem wasteful, but, again, I don't feel
quite as strongly about that as I did seven years ago (although
others may).

> For people e.g. on this list who now your writing style, such
> a mail wouldn't have been too much of a show-stopper. But for
> outsiders, and given that this was the only feedback they got
> (which isn't your fault), it must have sounded quite scary.

I think Dave Singer actually does know my writing style.  But,
more important (at least IMO), the lack of response should have
been scary for another reason: hard to propel something like
this through the IETF if very few people care.   The lack of
response might not have meant that, but...

>...
> I think that it's a big deal mostly because some people think
> it's a big deal. I haven't seen any serious arguments about
> why it actually is a big deal.

I tried to outline this earlier but, again, others may have
different reasons.   I think a top-level type requires either
relatively strong justification that it is a necessary special
case or specification of what happens with unrecognized
subtypes, parameters, etc.  That is a lot of definitional work,
followed by significant implementation work... just not
something to be done lightly because some class of file formats
seems special.

>> There are
>> several reasons for that but at least one important one is
>> that the model for what an application is expected to do when
>> it encounters an unknown top-level type is not, IMO, really
>> well sorted out.
>=20
> RFC 2046 clearly envisions the creation of additional
> top-level types, and so if there are applications that aren't
> ready to deal with them, then that's their fault. But I don't
> think that in actual practice, this would be a problem (if you
> think it will, please show me a concrete case).

I'll let Ned or Nathaniel speak to that, but my impression at
the time was that it allowed for additional types because not
doing so would represent a claim to really comprehensive
knowledge of the future.  It wasn't intended as license to go
out and create a bunch of them -- application/ was really
intended to be quite comprehensive wrt the things that need, as
someone else put it, to be processed and usually stored
somewhere, not rendered directly to the user.  We render text,
video, and images.  Fonts are used to build tables that are then
used with a list of characters and other information to create
something that is rendered.  The latter is either pretty close
to application/ or, as I suggested in 2004, represents a
different sort of creature that should be generalized.

>>  One cannot do much of anything (in that sense, it
>> isn't much different from an application/ subtype), but it
>> isn't clear how one should present that fact to a user who
>> doesn't have much understanding or vocabulary about what is
>> going on at the content-type level.
>=20
> Do you think the user will be more confused by a message =
saying
>      Downloading file, type: font/woff, Open or Save?
> or by a message saying
>      Downloading file, type: application/woff, Open or Save?

If I were a user, I'd be pretty upset by either message.  They
both look like gibberish and I'd have no clue which action I
should take.

> At least in the former, they might see the word "font" and get
> a clue. So I think this issue is essentially irrelevant.

More so if one considered application/font-woff (as in
application/font-tdpfr).

>> "Model/" (as described in RFC 2077) was not a problem because
>> the request came from a particular community for a particular
>> type of use, one on which there was little or no likelihood =
of
>> interaction with other types, especially with multipart
>> content.
>=20
> I think this is wrong. There is lots of potential interaction
> between 3D models and text, audio, video, images, and other
> application data. The reason you aren't seeing any of this is
> because there are umpteen reasons (which I don't think we need
> to discuss here) for why 3D hasn't caught on (yet?) on the Web
> and the Internet.

Ok.  But, if you see the distinction in terms of the
interactions, make that case for fonts.  I'm actually much more
open to this idea than you seem to have concluded (and was open
to it in 2004) - I just think the questions I've asked (as
questions, not rebuttal) are appropriate and should be addressed
in a serious way... with a default if there aren't satisfactory
answers of "use application/".

>...
>> If font/* is simply a "type and a subtype", then I'm inclined
>> to agree with those who say "use application/".  Certainly it
>> is feasible to say, e.g., "application/OpenType", specify it
>> as being bound to the OpenType font definition model, say =
some
>> things about encoding and parameters, and move on.  The fact
>> that it and an equally hypothetical "application/TrueType"
>> both encode/carry fonts creates no more of a requirement or
>> justification for a top-level type than the observation that
>> there application/ subtypes for Open Document and MSWord
>> formats implies that we should have a top-level type for
>> WordProcessor/ or DocumentFormatter/.  And, as Graham and
>> others have pointed out, we use "application/" (a lot) for
>> subtypes that require processing or installation before
>> something else can make use of them.
>=20
> We can always throw everything into application/. But then,
> why do we have image/, audio/, and video/ (and text/; I'm
> putting text/ in parentheses because there are very specific
> handling rules that don't apply to any of the other types) in
> the first place?

Because of what I'm describing as the rendering issue.  And the
compound body/message ("multipart") issue.

> For people involved with fonts (and many others, as we have
> seen on this list), fonts are not images, they are not video,
> and they are not audio, but they are also not just application
> data. These people (including many typographers and other font
> experts, with lots of Web and Internet experience) think that
> font/ is the right thing to do. They have tried several times
> (see my mail to Peter).

To repeat what I said earlier, I'd like to see some I-Ds that
drill down into the subtypes.  The observation that Bitstream
thought that application/ was adequate for PFR (and did write a
document) is some evidence that "these people" are not unanimous
that a top-level type is needed.  Now, if someone came forward
and said "we tried using application/font-tdpfr and the fact
that 'font' wasn't a top level type caused the following
specific problems so we have learned that putting it into
application/ was a bad idea", I, at least, would find that
extremely persuasive. =20

That isn't the only way to persuade me (and presumably, others
who have suggested using application/ subtypes).  But I think
somewhat more is needed than an assertion that "people involved
with fonts" want and/or need this.

>> I think a font/ top-level type would be worth looking at
>> carefully if there really were a use case for which some
>> application/ subtypes would not be appropriate.  One of those
>> might lie along the path of compound documents that I
>> mentioned in the context of "image/".   Perhaps there might
>> be others, or perhaps not.  "Distinct media type" doesn't do
>> much for me because what is, and is not, is largely in the
>> mind of the beholder.
>=20
> So why don't we change policies so that new image types also
> have to be registered under application/?

See above, plus the fact that image/ already exists as a basic
type and part of what you are arguing against is a principle
that we should not create a lot of top-level types... or any
more of them without considerable justification.

>...
> With Web fonts, or with fonts attached to other documents such
> as emails, partial fonts are indeed very important. But they
> will be installed temporarily. Also, for Web fonts, the main
> usage is via CSS, which makes sure there's enough
> meta-information.

But, unless you propose to restrict the use of this type to the
web, the broader questions need to be addressed.  And I haven't
seen anything proposed yet that would result in a different
handling or definitional model for temporary versus more
permanent installations.  Again, an I-D that explored or
specified these things would be a big help here.

I said before that I've got a relatively open mind about this.
The one thing about which I don't have an open mind is the idea
of saying "ok, let's create a top-level 'font/' type and assume
that the subtype definitions and all of the other issues will
sort themselves out".  I think a top-level type needs an
architecture, not just a string of characters.  YMMD.

>> I also don't know whether all "Definition Languages" in use
>> today contain the same descriptor information in reasonably
>> compatible formats.   If some do and others require, e.g., =
the
>> name of the font in supplemental information because only the
>> glyph descriptions are stored in the file, then there is a =
lot
>> of justification for parameters across the board if one is
>> going to have a well-designed top-level type with homogeneous
>> subtypes.
>=20
> Would it be possible to let the font experts figure this out?

Sure.  Get someone to produce an I-D or three.  Don't expect
people to believe that they will figure it out because they are
font experts.

>...
>> While the "model/" spec is rather short, it contains the
>> elements I'm trying to advocate here: a clear description of
>> why a top-level type is needed, a discussion of use cases, =
and
>> definitions of enough subtypes to make the use cases clear, =
as
>> well as the required templates and mechanisms for defining
>> future subtypes.
>=20
> I don't disagree here (except that RFC 2077 doesn't actually
> define subtypes, just gives some example of things that might
> be expected).
>=20
> I agree that having a bit of text on why a new subtype was
> chosen can't hurt at all. But I think we have to be careful
> and not make this a sysiphean exercise by requiring something
> like a proof that a new top-level type was absolutely
> necessary because otherwise the world will go under.

I don't think anyone has suggested that.  Certainly I haven't.

>> Recommendation to those who want this:  Work on a few subtype
>> definitions.  Sort the details, such as what parameters are
>> needed, out with the typographic community.  Examine the use
>> cases.   The would would need to be done --and would be =
almost
>> the same-- for a subtype of application/ or a subtype of
>> font/. With those tentative subtype descriptions in hand, the
>> rest of us will be a lot more able to identify commonalities
>> and to participate in an evaluation of whether a top-level
>> type is really justified.
=20
> Sorry, John, but they have tried before. They don't have much
> trust anymore.

As far as I can tell, only one subtype definition has been tried
and it resulted in RFC 3073.  If "tried before" means "thought
about it but decided to not post drafts and open discussions"
then I sympathize but I don't know how to get unstuck (in this
area or others with which you are familiar) from vague claims
about obstructions and problems.

>  If we again tell them what sounds to them as
> "bring it on, and we'll do our best to shoot it down and make
> your life miserable",  then they won't do the work. They won't
> do it for font/, and they also won't do it for application/. I
> don't think that's what we want.

I agree.  So your help, and Peter's, and that of others, are
going to be needed to be sure that the message comes across
well.  But I don't think that either a top-level type, or even
an application/ subtype, are going to get very far unless there
are definitions that can be examined by others and shown to work
and to be sufficiently comprehensive.

regards,
    john




From ned.freed@mrochek.com  Wed Nov  9 19:50:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED4B1F0C38 for ; Wed,  9 Nov 2011 19:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.428
X-Spam-Level: 
X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.871,  BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3]
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 lb0PxFlYRgKp for ; Wed,  9 Nov 2011 19:50:32 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB9F1F0C34 for ; Wed,  9 Nov 2011 19:50:30 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O88AB5HQ7K011NIG@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 9 Nov 2011 20:47:28 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O84YP18WJ400RCTX@mauve.mrochek.com>; Wed, 9 Nov 2011 20:47:23 -0800 (PST)
Message-id: <01O88AB2EM7S00RCTX@mauve.mrochek.com>
Date: Wed, 09 Nov 2011 20:06:12 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Thu, 10 Nov 2011 10:40:19 +0900" <4EBB2B83.3060901@it.aoyama.ac.jp>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp>
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 03:50:33 -0000

> > As others have noted, it is a big deal.

> I think that it's a big deal mostly because some people think it's a big
> deal. I haven't seen any serious arguments about why it actually is a
> big deal.

I have to agree with Martin here. In my experience whether or not a type is a
"big deal" has everything to do with whether or not it represents a new
structuring convention that needs to be handled (leaf versus non-leaf as far as
MIME is concerned) and nothing to do with whether or not a new top level is
involved.

So: Introduce some font/* types, and as long as I don't have to take it apart
to find other parts inside I'm fine. My media type tables (and all of the
tables in software I've encountered) deal in whole type names and let you
specify pretty much anything.

EAI's introduction of message/global, OTOH, *is* a big deal, even though it is
not a new top-level type. For such types I have to carefully consider in every
context where MIME processing is being done if I want to "go inside" or not,
and perhaps even provide options to control whether or an object of this type
is seen as a leaf or non-leaf. This is actually a bigger deal to me than
a new content-transfer-encoding.

New subtypes of text can also be a big deal, as can adding parameters to
existing text subtypes, because this stuff affects the basic rendering of
messages in user agents.

The only place I know where there might be a problem with a new top-level
font type is SDP. I confess to knowing next to nothing about SDP, but
it uses media types and has some really screwy constraints on on what it can
handle. I'm not seeing an application for font types in SDP, but if there
is someone more familiar with it sohuld be consulted on possible issues.

Anyway, my position on this is if there are behaviors that need to apply to
font parts in the aggregate then a new font top level type is in order to deal
with that. If, OTOH, there's no common behavior needed, a top-level font type
is still a nice-to-have.

> > There are
> > several reasons for that but at least one important one is that
> > the model for what an application is expected to do when it
> > encounters an unknown top-level type is not, IMO, really well
> > sorted out.

I'm sorry, but this is clearly misreading the intent, and I think at least some
of the letter, of RFC 2046. There was a time when we thought it was good idea
to talk about processing top-level types as entities in their own right, but
this was early in the MIME effort. We later came to the conclusion that in the
case of leaf parts, unknown types should be treated like
application/octet-stream and unknown top-levels should be treated like
application (but with the subtypes in their own namespace, of course).

Again, the problem for processing agents of all types is really with non-leaf
objects, where clean defaulting rules really aren't possible.

> RFC 2046 clearly envisions the creation of additional top-level types,
> and so if there are applications that aren't ready to deal with them,
> then that's their fault.

Well, I wouldn't go quite that far - if there was a significant widely deployed
set of applications that would break then we need to take application set into
account. But no such issue exists in any application set I know of.

> But I don't think that in actual practice, this
> would be a problem (if you think it will, please show me a concrete case).

Exactly.

> >  One cannot do much of anything (in that sense, it
> > isn't much different from an application/ subtype), but it isn't
> > clear how one should present that fact to a user who doesn't
> > have much understanding or vocabulary about what is going on at
> > the content-type level.

> Do you think the user will be more confused by a message saying
>      Downloading file, type: font/woff, Open or Save?
> or by a message saying
>      Downloading file, type: application/woff, Open or Save?

> At least in the former, they might see the word "font" and get a clue.
> So I think this issue is essentially irrelevant.

Agreed.

> > "Model/" (as described in RFC 2077) was not a problem because
> > the request came from a particular community for a particular
> > type of use, one on which there was little or no likelihood of
> > interaction with other types, especially with multipart content.

> I think this is wrong. There is lots of potential interaction between 3D
> models and text, audio, video, images, and other application data. The
> reason you aren't seeing any of this is because there are umpteen
> reasons (which I don't think we need to discuss here) for why 3D hasn't
> caught on (yet?) on the Web and the Internet.

> > I assume that the community that wanted that type is using it,
> > but confess to never having seen the type in the wild.

I actually have encountered objects with the model type. Then again, I did
quite a lot of mathematical modelling work before I got into email, so this may
be a holdover from that.

And they didn't cause any problems either. I had no trouble associating
handlers with them and as always there was the "extract to file" approach.

> > If
> > others haven't either, that reinforces the claim that the
> > "model/" type really is independent of the others.

> See above.

> > If font/* is simply a "type and a subtype", then I'm inclined to
> > agree with those who say "use application/".  Certainly it is
> > feasible to say, e.g., "application/OpenType", specify it as
> > being bound to the OpenType font definition model, say some
> > things about encoding and parameters, and move on.  The fact
> > that it and an equally hypothetical "application/TrueType" both
> > encode/carry fonts creates no more of a requirement or
> > justification for a top-level type than the observation that
> > there application/ subtypes for Open Document and MSWord formats
> > implies that we should have a top-level type for WordProcessor/
> > or DocumentFormatter/.  And, as Graham and others have pointed
> > out, we use "application/" (a lot) for subtypes that require
> > processing or installation before something else can make use of
> > them.

> We can always throw everything into application/. But then, why do we
> have image/, audio/, and video/ (and text/; I'm putting text/ in
> parentheses because there are very specific handling rules that don't
> apply to any of the other types) in the first place?

Well, this gets into whether or not there's an aggregrate handling approach
that makes sense for the type. Font seems to qualify in this regard.

> For people involved with fonts (and many others, as we have seen on this
> list), fonts are not images, they are not video, and they are not audio,
> but they are also not just application data. These people (including
> many typographers and other font experts, with lots of Web and Internet
> experience) think that font/ is the right thing to do. They have tried
> several times (see my mail to Peter).

Seems reasonable to me.

> > I think a font/ top-level type would be worth looking at
> > carefully if there really were a use case for which some
> > application/ subtypes would not be appropriate.  One of those
> > might lie along the path of compound documents that I mentioned
> > in the context of "image/".   Perhaps there might be others, or
> > perhaps not.  "Distinct media type" doesn't do much for me
> > because what is, and is not, is largely in the mind of the
> > beholder.

> So why don't we change policies so that new image types also have to be
> registered under application/?

> >> If some kind of 'Definition Language' is used inside a font
> >> format, then that's just something under the hood. My
> >> understanding is that some popular formats such as OpenType
> >> essentially are mergers resulting from the "Definition
> >> Language" wars in the early 1990.
> >
> > I used "Definition Language" to refer to what you are referring
> > to as a "format" (which often means something else in this
> > context).  I don't have enough contemporary knowledge to know
> > what would be most accurate and consistent with current
> > terminology -- another topic for Mark's wife or some other
> > typographic expert.

> There are experts who have the knowledge. They have tried to register
> font/ previously. Why don't we trust them?

In practice the issue of what to register where has never been much of a
problem. Speaking now as media types reviewer, I have not infrequently  pushed
back on top-level type choices, usually successfully and always amicably.

> >> Also, typeface, style, and
> >> applicable range of sizes shouldn't be necessary as part of
> >> the mime type because it's part of the content.
> >
> > I don't know what that means in practice.  Having struggled
> > several times with what needs to be a parameter on a media type
> > and subtype, it isn't obvious that parameters are unnecessary
> > even if the information can be deduced from content.   I am
> > particularly concerned about transmission of files that contain
> > parts of a typeface family, but not all of it, as well as about
> > a type and subtype that don't even identify the type family and
> > hence may require a lot of work before a system can decide
> > whether to install it.

> With Web fonts, or with fonts attached to other documents such as
> emails, partial fonts are indeed very important. But they will be
> installed temporarily. Also, for Web fonts, the main usage is via CSS,
> which makes sure there's enough meta-information.

Meta-information needs to either be part of the font or part of whatever
is using the font. Putting it in, say, content-type parameters strikes me
as a bad idea. Media features could be used if this is a real issue, but I
rather suspect it is not.

> > I also don't know whether all "Definition Languages" in use
> > today contain the same descriptor information in reasonably
> > compatible formats.   If some do and others require, e.g., the
> > name of the font in supplemental information because only the
> > glyph descriptions are stored in the file, then there is a lot
> > of justification for parameters across the board if one is going
> > to have a well-designed top-level type with homogeneous
> > subtypes.

> Would it be possible to let the font experts figure this out?

I don't think you're going to find as much variability amongst these things as 
people seem to be worried about here. I'll also point out that similar issues
exists for images and video, where we went to a lot of trouble to define a
fairly elaborate media features language, which AFAICT pretty much nobody uses.

> >> Some such parameters were proposed in
> >> http://tools.ietf.org/html/draft-singer-font-mime-00, and may
> >> still be necessary, but not as much as 7 years ago, when you
> >> apparently shot down the proposal (see
> >> http://www.ietf.org/mail-archive/web/ietf/current/msg33267.htm
> >> l). So if the font experts say they really need a parameter,
> >> we'll keep it, but we don't have to make thing more
> >> complicated than necessary in advance.
> >
> >> The only RFC that defined a new top-level type is RFC 2077
> >> (http://tools.ietf.org/html/rfc2077). It's rather short, and I
> >> expect the font/ RFC to be even shorter unless it also
> >> includes some registrations for actual subtypes (I'd probably
> >> do it in two separate documents, one for the top-level type
> >> and another for some low hanging subtypes, but I'll leave the
> >> decision to whoever does the actual work.)
> >
> > While the "model/" spec is rather short, it contains the
> > elements I'm trying to advocate here: a clear description of why
> > a top-level type is needed, a discussion of use cases, and
> > definitions of enough subtypes to make the use cases clear, as
> > well as the required templates and mechanisms for defining
> > future subtypes.

> I don't disagree here (except that RFC 2077 doesn't actually define
> subtypes, just gives some example of things that might be expected).

I'm ambivalent about whether or not a bunch of subtypes are defined in the
base document.

> I agree that having a bit of text on why a new subtype was chosen can't
> hurt at all. But I think we have to be careful and not make this a
> sysiphean exercise by requiring something like a proof that a new
> top-level type was absolutely necessary because otherwise the world will
> go under.

Exactly!

> > Recommendation to those who want this:  Work on a few subtype
> > definitions.  Sort the details, such as what parameters are
> > needed, out with the typographic community.  Examine the use
> > cases.   The would would need to be done --and would be almost
> > the same-- for a subtype of application/ or a subtype of font/.
> > With those tentative subtype descriptions in hand, the rest of
> > us will be a lot more able to identify commonalities and to
> > participate in an evaluation of whether a top-level type is
> > really justified.

> Sorry, John, but they have tried before. They don't have much trust
> anymore. If we again tell them what sounds to them as "bring it on, and
> we'll do our best to shoot it down and make your life miserable",  then
> they won't do the work. They won't do it for font/, and they also won't
> do it for application/. I don't think that's what we want.

+1

				Ned

From duerst@it.aoyama.ac.jp  Wed Nov  9 20:20:29 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3CA21F8505 for ; Wed,  9 Nov 2011 20:20:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.077
X-Spam-Level: 
X-Spam-Status: No, score=-99.077 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_BACKHAIR_34=1, MIME_8BIT_HEADER=0.3, 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 vfIjM6HbFkaa for ; Wed,  9 Nov 2011 20:20:28 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id A04A521F84D3 for ; Wed,  9 Nov 2011 20:20:28 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAA4KLfM028500 for ; Thu, 10 Nov 2011 13:20:21 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6623_2de0_4dfc3576_0b53_11e1_89fb_001d096c566a; Thu, 10 Nov 2011 13:20:21 +0900
Received: from [IPv6:::1] ([133.2.210.1]:51130) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Nov 2011 13:20:25 +0900
Message-ID: <4EBB50F4.7020501@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 13:20:04 +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: dcrocker@bbiw.net
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>	<60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>	<4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net>
In-Reply-To: <4EBB2FEA.5060602@dcrocker.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 04:20:29 -0000

On 2011/11/10 10:59, Dave CROCKER wrote:
>
>> http://fontfeed.com/archives/font-or-typeface/ explains that in very
>> simple
>> terms. As far as the analogy there with MP3<=>font, song<=>typeface
>> goes, we
>> definitely need Mime types for fonts, not for typefaces.
>
>
> Forgive me for feeling the need to be entirely pedantic here, but the
> article went just shy of being completely clear (for me) and I think it
> is indeed worth having us all not merely on the same page, but the same
> place on the page...
>
> Is this correct:
>
> Typeface: times roman
>
> Font: times roman, 12pt
>
> Font: times roman, 10pt
>
> Font: times roman, 10pt, italic
>
> Font: times roman, 10pt, bold
>
> Yes?
>
> That is, typeface is the basic design (or abstraction) while typeface +
> physical details (such as specific size) is a font?

Not exactly. On the one hand, the italic version of times roman actually 
is a design by itself, so it can very well be seen as a typeface.

On the other hand, specific size was important for lead type (which 
doesn't scale) and bitmap font formats. With today's outline and hinting 
technologies, most fonts are designed to work at many different sizes, 
so the specific size is rather irrelevant.

Anyway, what we are looking at is to have media types for font formats. 
Typeface affects this only marginally.

Regards,   Martin.

From duerst@it.aoyama.ac.jp  Wed Nov  9 20:29:23 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9F621F85CE for ; Wed,  9 Nov 2011 20:29:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.569
X-Spam-Level: 
X-Spam-Status: No, score=-99.569 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-sbV1X7bSuj for ; Wed,  9 Nov 2011 20:29:22 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4034E21F85C7 for ; Wed,  9 Nov 2011 20:29:22 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAA4TL1x009303 for ; Thu, 10 Nov 2011 13:29:21 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 591c_abef_8f9137e2_0b54_11e1_bbef_001d096c5782; Thu, 10 Nov 2011 13:29:21 +0900
Received: from [IPv6:::1] ([133.2.210.1]:38195) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Nov 2011 13:29:24 +0900
Message-ID: <4EBB5310.6080103@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 13:29:04 +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: dcrocker@bbiw.net
References: <4EBB3CFC.5050608@dcrocker.net>
In-Reply-To: <4EBB3CFC.5050608@dcrocker.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 04:29:23 -0000

Hello Dave,

On 2011/11/10 11:54, Dave CROCKER wrote:
> Folks,
>
> The font thread has re-raised the issue of registering a Top-Level
> Content-Type (TLCT). I haven't seen clear statements or documents of a
> theory or rationale that would guide accepting or rejecting a request
> for a TLCT, and I think we should (finally) remedy this deficiency.

If somebody has some free time to work on this, why not. But both in the 
IETF and elsewhere, my experience is that it's difficult to create a 
general theory with very few examples. And this is a case with extremely 
few examples. So I'd rather spend my time on the concrete case. This 
would hopefully result in some mime types actually being registered.

> In an earlier note I cited a recollection of resistance to new TLCTs.
> But I don't remember the reasons, though I seem to recall both substance
> and vigor to the reasons.

That has been reported elsewhere, see e.g.
http://lists.w3.org/Archives/Public/www-font/2009JulSep/1069.html

It would be good if we found an archive of this discussion, just so that 
we could understand what went on then. But if we can't find that 
anymore, then we shouldn't care too much. If we forgot why there was 
resistance, maybe it wasn't that important.

> We should try to resurrect or re-create a simple, pragmatic set of
> guidelines, and document them, so we don't have to go through the kind
> of vague exchanges happening now, with respect to arguing whether a new
> TLCT is appropriate.
>
> The purpose of this thread is to press for a brief document that
> resolves this kind of debate and that can be used going forward in
> designing the "structure" of new registration groups. This ought to be
> in terms of real pragmatics, rather than aesthetics or personal preference.

I'm going to discuss this with you here because I'm interested in the 
example at hand, not because I want to create a general theory.

> I can think of only two pragmatic issues in registering names like this:
>
> 1. Administrative convenience. A hierarchy permits administrative
> grouping and possibly the convenience of delegating subsets of
> registration. Obviously the DNS is the prime example. At very large
> scale, this is essential. At small scale, extra structure can be a hassle.
>
> I'm not seeing convenience as an issue for Content-Type, but perhaps
> others see the issue differently. That is, my sense is that the entire
> data base of content-types is small enough to a) remain centralized, and
> b) not otherwise needing to benefit from sub-setting.
>
> This calls to question why there are /any/ sub-types, of course, but I'd
> rather cast the issue in terms of going forward, rather than of history.

I agree that delegating subsets along major types doesn't make sense. 
But there's another administrative reason for having major/minor types: 
It's hopefully easier to find a type you're looking for, or check that a 
type hasn't been registered. As a clear example, for image formats, I 
know that http://www.iana.org/assignments/media-types/image/index.html 
is where I have to check.


> 2. Code dispatching. Different content-types invoke different software
> segments. Parameters are input to the code but do invoke different
> "programs".
>
> I am not seeing how a TLCT vs. sub-type distinction affects this issue.
> That is, it seems to me that
>
> C-T: major/minor
>
> has equal software utility as
>
> C-T:application/major-minor
>
> Any useful difference seems to be to fall under #1, above, rather than
> under a software behavior distinction. What am I missing?

I think that fonts are dispatched quite differently e.g. from 
application data. For application data, the general solution is to call 
up the respective application (or ask the user to select or confirm 
one). For font data, there are of course applications that work on the 
data directly (e.g. editors). But the main usage is that they are saved 
(or installed) separately and used as auxiliary documents.


> The 'model' document talks about a benefit of grouping sub-types, but I
> do not understand what the software benefit is, in terms of MIME
> Content-type. That is, the benefit seems to be a local benefit within
> the model world, rather than more generally within the MIME world.
> Again, what am I missing?

You may not be missing too much. It's easy to imagine a world with a 
flat type system, or with a type system that didn't have image/, audio/, 
and video/.

But the fact is that we have a major/minor type system. We can as well 
make reasonable use of it.


> To take the 'font' discussion as an immediate, real-world exemplar, I
> think the above says that a logical hierarchy should have the
> representation engine be superior to the typeface or font specification,
> since it affects software dispatch.

I'm not sure I understand this point. Can you elaborate. What do you 
mean by "representation engine"?


> Also, I don't see what the driving need for a TLCT is for font (or
> face...) It's aesthetically appealing, but I don't see the technical or
> administrative benefit. Hence, here's one last: what am I missing?

Glad you agree that it's aesthetically appealing. And please remember 
that people involved with fonts care quite a lot about aestetics.

As for the technical/administrative benefits, things such as easy 
searchability and easier negotiation (e.g. Accept: font/*) and despatch 
have already been mentioned.

These benefits are not necessarily tremendous, but the same applies to 
image/, video/, and audio/.

Regards,   Martin.

From dhc@dcrocker.net  Wed Nov  9 20:37:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CDB11E8097 for ; Wed,  9 Nov 2011 20:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 K0Mw5vgsUmj9 for ; Wed,  9 Nov 2011 20:37:12 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DB83611E8073 for ; Wed,  9 Nov 2011 20:37:12 -0800 (PST)
Received: from [192.168.0.229] (61-31-89-133.static.tfn.net.tw [61.31.89.133]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAA4aoD5008307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Nov 2011 20:37:11 -0800
Message-ID: <4EBB54E0.9090005@dcrocker.net>
Date: Thu, 10 Nov 2011 12:36:48 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>	<60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>	<4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp>
In-Reply-To: <4EBB50F4.7020501@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 09 Nov 2011 20:37:12 -0800 (PST)
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 04:37:13 -0000

On 11/10/2011 12:20 PM, "Martin J. Dürst" wrote:
>>
>> That is, typeface is the basic design (or abstraction) while typeface +
>> physical details (such as specific size) is a font?
>
> Not exactly. On the one hand, the italic version of times roman actually is a
> design by itself, so it can very well be seen as a typeface.
>
> On the other hand, specific size was important for lead type (which doesn't
> scale) and bitmap font formats. With today's outline and hinting technologies,
> most fonts are designed to work at many different sizes, so the specific size is
> rather irrelevant.
>
> Anyway, what we are looking at is to have media types for font formats. Typeface
> affects this only marginally.


Well, I think I tracked your response and I think it made sense to me, including 
the wrinkle added to the historical perspective by the 'outline' model(s).

The problem is that where it landed leaves me still unclear about the exact 
difference between face and font, and it seems that it would be useful for 
font/face non-geeks, like me, to be able to use the terms properly.


mumble.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From tony@att.com  Wed Nov  9 21:07:12 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4CC11E8088 for ; Wed,  9 Nov 2011 21:07:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.099
X-Spam-Level: 
X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_34=1, 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 2YSUPlx9iLNL for ; Wed,  9 Nov 2011 21:07:12 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id EA73511E8073 for ; Wed,  9 Nov 2011 21:07:11 -0800 (PST)
X-Env-Sender: tony@att.com
X-Msg-Ref: server-13.tower-120.messagelabs.com!1320901627!48667081!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5996 invoked from network); 10 Nov 2011 05:07:07 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Nov 2011 05:07:07 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAA57YKF028827 for ; Thu, 10 Nov 2011 00:07:34 -0500
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAA57S60028736 for ; Thu, 10 Nov 2011 00:07:28 -0500
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pAA570Vl006042 for ; Thu, 10 Nov 2011 00:07:00 -0500
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pAA56vaq005887 for ; Thu, 10 Nov 2011 00:06:58 -0500
Received: from [135.70.143.111] (vpn-135-70-143-111.vpn.mwst.att.com[135.70.143.111]) by maillennium.att.com (mailgw1) with ESMTP id <20111110050604gw100e4l2me> (Authid: tony); Thu, 10 Nov 2011 05:06:05 +0000
X-Originating-IP: [135.70.143.111]
Message-ID: <4EBB5BF0.1080503@att.com>
Date: Thu, 10 Nov 2011 00:06:56 -0500
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org Discuss" 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net>
In-Reply-To: <4EBB2FEA.5060602@dcrocker.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 05:07:12 -0000

By the definitions of that article and other things I've read, what's 
being proposed to be included as sub-types of the new font/* are neither 
fonts nor typefaces. Instead they are font description language file 
formats.

     Tony Hansen
     tony@att.com

On 11/9/2011 8:59 PM, Dave CROCKER wrote:
>
>> http://fontfeed.com/archives/font-or-typeface/ explains that in very 
>> simple
>> terms. As far as the analogy there with MP3<=>font, song<=>typeface 
>> goes, we
>> definitely need Mime types for fonts, not for typefaces.
>
>
> Forgive me for feeling the need to be entirely pedantic here, but the 
> article went just shy of being completely clear (for me) and I think 
> it is indeed worth having us all not merely on the same page, but the 
> same place on the page...
>
> Is this correct:
>
>    Typeface:  times roman
>
>    Font:      times roman, 12pt
>
>    Font:      times roman, 10pt
>
>    Font:      times roman, 10pt, italic
>
>    Font:      times roman, 10pt, bold
>
> Yes?
>
> That is, typeface is the basic design (or abstraction) while typeface 
> + physical details (such as specific size) is a font?
>
> Tnx.
>
> d/
>

From barryleiba.mailing.lists@gmail.com  Wed Nov  9 22:07:51 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F1F11E80A4 for ; Wed,  9 Nov 2011 22:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.939
X-Spam-Level: 
X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ota6YcJL3t5W for ; Wed,  9 Nov 2011 22:07:50 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4AD11E8097 for ; Wed,  9 Nov 2011 22:07:50 -0800 (PST)
Received: by yenl7 with SMTP id l7so1873301yen.31 for ; Wed, 09 Nov 2011 22:07:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rg/spooqxvQ8IgEjrhkBai+JKIyb3GpA35F6mZ0F4gI=; b=l/W0v6mFiQlZCYzqeS+MluOcHFe9JMT0K6TUwXnvwL8dX1ZtJAN3QDJt2QSm2rlF8F oKqjGKy0Ht6YJUAlzBPLeUtdQV3/kRshx/zLvFZDjLOSLYgG9YD5lMfH8oA0KQxc0F/Q dyxlBTBGSqM5rlBs31E+s94LEmGEd9co6QjRs=
MIME-Version: 1.0
Received: by 10.182.222.7 with SMTP id qi7mr1553308obc.43.1320904925311; Wed, 09 Nov 2011 22:02:05 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.182.15.130 with HTTP; Wed, 9 Nov 2011 22:02:05 -0800 (PST)
In-Reply-To: <4EBB5310.6080103@it.aoyama.ac.jp>
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 01:02:05 -0500
X-Google-Sender-Auth: IE-w-oTz21lX-Sq_ZgqSmS4J8XY
Message-ID: 
From: Barry Leiba 
To: dcrocker@bbiw.net
Content-Type: text/plain; charset=ISO-8859-1
Cc: Apps Discuss 
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 06:07:51 -0000

I agree with Martin's comments, and especially with this one:

>> I am not seeing how a TLCT vs. sub-type distinction affects this issue.
>> That is, it seems to me that
>>
>> C-T: major/minor
>>
>> has equal software utility as
>>
>> C-T:application/major-minor
>>
>> Any useful difference seems to be to fall under #1, above, rather than
>> under a software behavior distinction. What am I missing?
...
>> The 'model' document talks about a benefit of grouping sub-types, but I
>> do not understand what the software benefit is, in terms of MIME
>> Content-type. That is, the benefit seems to be a local benefit within
>> the model world, rather than more generally within the MIME world.
>> Again, what am I missing?
>
> You may not be missing too much. It's easy to imagine a world with a flat
> type system, or with a type system that didn't have image/, audio/, and
> video/.
>
> But the fact is that we have a major/minor type system. We can as well make
> reasonable use of it.

As I said in the other thread (on font/*), we already have the concept
of saying "This is text," "This is an image," and "This is audio," and
I see only negative points in insisting that everything other than the
few TLMTs that we're already defined have to be "application".  We
should do some filtering and apply some judgment, of course, but
making everything the equivalent to "application/image-jpeg" is silly
and non-useful.

The point of "image/xxx" was to allow a program to say "I do/don't
handle images," and have it send the media content over to its image
processing, or to shortcut things because it just doesn't do images at
all.  The same thinking applies to other things, and it's not just
application or administrative "convenience".  Of course, the problem
with "application/xxx-yyy" is that unless we define a hierarchy for
the subtype field, the processing I described above that could apply
to "image/jpeg" can't apply to "application/image-jpeg".

For what it's worth, I think it was a mistake to put office document
stuff into "application"; we should have made a TLMT for "document",
so we could have, say, "document/spreadsheet" or "document/MS-excel"
or "document/ODS", "document/PDF", "document/presentation", and so on.
 (For that matter, "text/html" seems a bit silly these days, and
"document/html" might be more appropriate, but I digress.)

I do understand that we don't want to have TLMTs proliferating out of
control.  On the other hand, I think we're being *way* too restrictive
about defining them when there's a reasonable argument why they make
sense.

And I'm happy to participate in a document that talks about this.

Barry

From duerst@it.aoyama.ac.jp  Wed Nov  9 22:56:01 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7D711E80AB for ; Wed,  9 Nov 2011 22:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.575
X-Spam-Level: 
X-Spam-Status: No, score=-99.575 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ1xMe8t42+5 for ; Wed,  9 Nov 2011 22:56:00 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9495011E8088 for ; Wed,  9 Nov 2011 22:56:00 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAA6trkq007150 for ; Thu, 10 Nov 2011 15:55:53 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6627_3d8b_0804ccde_0b69_11e1_89fb_001d096c566a; Thu, 10 Nov 2011 15:55:53 +0900
Received: from [IPv6:::1] ([133.2.210.1]:45807) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Nov 2011 15:55:56 +0900
Message-ID: <4EBB7568.1020003@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 15:55:36 +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: dcrocker@bbiw.net
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<24FBF40353ABCC3A4F15E82B@PST.JCK.COM>	<56B202FE-ED81-4C36-AB4C-0A809F51D009@standardstrack.com> <4EBB3762.6000907@dcrocker.net>
In-Reply-To: <4EBB3762.6000907@dcrocker.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 06:56:01 -0000

I think it may be too early to discuss procedural points, but we are 
speaking about one, potentially two, drafts, both of which quite short. 
In the old days, AD-sponsored individual submission(s) would have been 
best. Now, we might need to move it through the Apps WG.

Trying to do anything like a BOF or a WG seems complete overkill. There 
are many people involved in fonts (in particular Web fonts). But I can't 
imagine them shell out the money just to come to an IETF meeting for 
getting a few types registered.

This is not about a spec for a new protocol or format. The formats 
exist, some of them for more than 10 years, some of them more recent. 
It's just about giving them labels.

Regards,    Martin.

On 2011/11/10 11:30, Dave CROCKER wrote:
>
>
> On 11/10/2011 5:00 AM, Eric Burger wrote:
>> Sounds like a call for a BOF.
>
>
> For a topic like this, I believe a BOF makes sense only for either or
> both of:
>
> 1. Interactive tutorial, to create a community of folk who share a
> common set of information and are going to proceed doing some work on
> the topic. Hence, this would prime the work pump.
>
> 2. Debate particulars, prior to formulating a spec. One can argue that
> that sounds like a regular working group, but I've tailored the
> description to fit a before-wg phase. In any event, this presumes that
> folks are already sharing a common base of knowledge and details and
> merely need to debates some details.
>
> My sense of this extended thread is that the group ain't quite far
> enough along for #2. I can't tell whether #1 is needed.
>
> d/

From dhc@dcrocker.net  Wed Nov  9 22:59:57 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A80111E8088 for ; Wed,  9 Nov 2011 22:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.788
X-Spam-Level: 
X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=1.666]
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 wick9oAbbTGg for ; Wed,  9 Nov 2011 22:59:56 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 283B911E80B4 for ; Wed,  9 Nov 2011 22:59:56 -0800 (PST)
Received: from [192.168.0.229] (61-230-51-213.dynamic.hinet.net [61.230.51.213]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAA6xlGE011605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Nov 2011 22:59:55 -0800
Message-ID: <4EBB7660.6040904@dcrocker.net>
Date: Thu, 10 Nov 2011 14:59:44 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Apps Discuss 
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 09 Nov 2011 22:59:56 -0800 (PST)
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 06:59:57 -0000

Folks,

On 11/10/2011 2:02 PM, Barry Leiba wrote:
>> But the fact is that we have a major/minor type system. We can as well make
>> reasonable use of it.
>
> As I said in the other thread (on font/*), we already have the concept
> of saying "This is text," "This is an image," and "This is audio," and
> I see only negative points in insisting that everything other than the
> few TLMTs that we're already defined have to be "application".  We
> should do some filtering and apply some judgment, of course, but
> making everything the equivalent to "application/image-jpeg" is silly
> and non-useful.


That states a basic direction/goal: To have a lower hurdle than perhaps was 
there before.

Does it have any basic downsides?

My sense from the latest round of postings, including Ned's, is that there is no 
current reason to impose a high hurdle on TLCTs.


      Consensus check
      ===============

      Is there anyone out there who believes that it is extremely expensive or 
dangerous to introduce new, top-level Content-Type and that, therefore, the 
barrier to new TLCTs should be (kept) high?


Assuming the answer and the consensus is no, that still leaves open what 
pragmatic guidance is to be used for accepting or rejecting a request for a 
TLCT.  (We could take the ICANN approach and just filter based on huge gobs of 
money, but I doubt that model will transfer to the IETF.)

So far, the most cogent guidance I've seen seems to be related to the 
justification in the model spec (RFC 2077):

   "The important fact is that these
    various subtypes can be converted between each other with less loss
    of information then to that of other primary types.  This fact groups
    these subtypes together into the model primary type.  All of the
    expected subtypes have several features in common and that are unique
    to this primary type."

I had suggested a guideline in terms of "dispatching" to different applications. 
  Ned's note offered a better framing, in terms of common code among a set of 
content sub-types.  A particular form of such code, implied by the model 
document, is for translating among sub-types.

Martin pointed out an "administrative" issue quite different from the basic 
registration scaling or decentralization I cited, namely the search for related 
types by an implementer, where separate sub-tables would be helpful.  He noted:

      http://www.iana.org/assignments/media-types/image/index.html

as a good example.


      Consensus Check
      ===============

      So, I think this leaves guidance in favor of a new top-level content-type 
if one or more of the following apply:

      1.  Strong semantic relationship among the sub-types

      2.  Likelihood of some common code for the set of sub-types

      3.  Expectation that implementors will benefit from easily discovering the 
current set of sub-types in the registry.


Does this summarize the guidance that should be offered for justifying a new TLCT?

d/


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From julian.reschke@gmx.de  Thu Nov 10 00:11:58 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D6521F849D for ; Thu, 10 Nov 2011 00:11:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.222
X-Spam-Level: 
X-Spam-Status: No, score=-104.222 tagged_above=-999 required=5 tests=[AWL=-1.923, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 cfTAHkmwcq78 for ; Thu, 10 Nov 2011 00:11:56 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 27FC321F844C for ; Thu, 10 Nov 2011 00:11:50 -0800 (PST)
Received: (qmail invoked by alias); 10 Nov 2011 08:11:48 -0000
Received: from p5DCC32E8.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.50.232] by mail.gmx.net (mp005) with SMTP; 10 Nov 2011 09:11:48 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18ktXw687okFR/App5AXHpwjAUr99W68BVhGycSYk zk0ctbHLnSIySm
Message-ID: <4EBB873D.4020107@gmx.de>
Date: Thu, 10 Nov 2011 09:11:41 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<24FBF40353ABCC3A4F15E82B@PST.JCK.COM>	<56B202FE-ED81-4C36-AB4C-0A809F51D009@standardstrack.com> <4EBB3762.6000907@dcrocker.net> <4EBB7568.1020003@it.aoyama.ac.jp>
In-Reply-To: <4EBB7568.1020003@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: dcrocker@bbiw.net, "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 08:11:58 -0000

On 2011-11-10 07:55, "Martin J. Dürst" wrote:
> I think it may be too early to discuss procedural points, but we are
> speaking about one, potentially two, drafts, both of which quite short.
> In the old days, AD-sponsored individual submission(s) would have been
> best. Now, we might need to move it through the Apps WG.
>
> Trying to do anything like a BOF or a WG seems complete overkill. There
> are many people involved in fonts (in particular Web fonts). But I can't
> imagine them shell out the money just to come to an IETF meeting for
> getting a few types registered.
>
> This is not about a spec for a new protocol or format. The formats
> exist, some of them for more than 10 years, some of them more recent.
> It's just about giving them labels.
>
> Regards, Martin.

++++++1

Best regards, Julian

From barryleiba.mailing.lists@gmail.com  Thu Nov 10 01:33:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D05021F84DC for ; Thu, 10 Nov 2011 01:33:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.941
X-Spam-Level: 
X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.036, 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 Ncbr69MzlDSR for ; Thu, 10 Nov 2011 01:33:27 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC25221F84D7 for ; Thu, 10 Nov 2011 01:33:27 -0800 (PST)
Received: by ggnr4 with SMTP id r4so1378640ggn.31 for ; Thu, 10 Nov 2011 01:33:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FARLalTd3jShBCbccmUfFepqON1qUX0vw6HMCWyAueM=; b=JNJuZJ5BXM0clO/9pecw0QMCmDVVYNY4KR+pNF4mLG/zbAfkkn61pXaCpiaQSbpH6q FPso+qLgdfIU7VcAqHc4K0qZQWxVOqU63Pbeb1EUa/0kXQXGJLsc6XofICqqThq7OBZw yq7JAZdB+53kvN3O4UnGgtYj6/dJw28izG3rY=
MIME-Version: 1.0
Received: by 10.146.159.5 with SMTP id h5mr2946159yae.1.1320917607238; Thu, 10 Nov 2011 01:33:27 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.250.14 with HTTP; Thu, 10 Nov 2011 01:33:27 -0800 (PST)
In-Reply-To: <4EBB7660.6040904@dcrocker.net>
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp>  <4EBB7660.6040904@dcrocker.net>
Date: Thu, 10 Nov 2011 04:33:27 -0500
X-Google-Sender-Auth: 63SnosmJr_jTO8p6JnzaA4BFsLM
Message-ID: 
From: Barry Leiba 
To: dcrocker@bbiw.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Apps Discuss 
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 09:33:28 -0000

> =A0 =A0 Consensus Check
> =A0 =A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> =A0 =A0 So, I think this leaves guidance in favor of a new top-level
> content-type if one or more of the following apply:
>
> =A0 =A0 1. =A0Strong semantic relationship among the sub-types
>
> =A0 =A0 2. =A0Likelihood of some common code for the set of sub-types
>
> =A0 =A0 3. =A0Expectation that implementors will benefit from easily disc=
overing
> the current set of sub-types in the registry.
>
>
> Does this summarize the guidance that should be offered for justifying a =
new
> TLCT?

WFM.

[Quick and nitty terminology check: the term of art is "media type",
which is why I was calling them "TLMTs".  We all understand what
people mean when they say "MIME type" or "content type", but "media
type" is what's used in the registry.]

Barry

From ddooss@wp.pl  Thu Nov 10 01:39:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC321F8B3A for ; Thu, 10 Nov 2011 01:39:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.381
X-Spam-Level: 
X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95]
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 XsAaEzyNNDDr for ; Thu, 10 Nov 2011 01:39:49 -0800 (PST)
Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by ietfa.amsl.com (Postfix) with ESMTP id A111E21F8B39 for ; Thu, 10 Nov 2011 01:39:48 -0800 (PST)
Received: (wp-smtpd smtp.wp.pl 11633 invoked from network); 10 Nov 2011 10:39:45 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1320917985; bh=uu+Fzo068BJAP22kI6mApDnAFMS8VN722uEPyTDdgHg=; h=From:To:Subject; b=Wi2/+/YP6288ahBDtYnPi5eVLBXJgnLCOT2OU9SSRmKFsO/MWms194soCGyWFaQc0 1qqJsv7kMqPA5G2+z5tTox2OjHcqNE/OejYJCJ7Phruf+JQckypDmJw832UUOQEdjL Emb3FiGdznYS8cj8n+f7aZ12/BchsbzSBB54P0pA=
Received: from 87-205-152-63.adsl.inetia.pl (HELO [192.168.1.2]) (ddooss@[87.205.152.63]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 10 Nov 2011 10:39:45 +0100
Message-ID: <4EBB9BE1.6020802@wp.pl>
Date: Thu, 10 Nov 2011 10:39:45 +0100
From: Dominik Tomaszuk 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org>
In-Reply-To: <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO 0000006 [oWZA]                               
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 09:39:54 -0000

On 08.11.2011 18:05, Paul Hoffman wrote:
>> I propose to give possibility to declare namespace.
>
> -1. Actually, -10. While somewhat useful for XML, namespaces have also proven to cause many headaches for corner cases.
I do not propose to reject Clark Notation and add declarative XML-like 
namespaces. My proposal was optional. If like long Clark Notation URLs' 
you can use it (advantage: easy processing). If you want short and 
non-repeated namespace you can declare it and use only reference 
(advantage: smaller and easier to read file).

All proposals for shortening are similar to my. You can use something 
like QNames, CURIE, or JSON-LD terms, but it is almost the same - all of 
them should be declared first.

Best regards,
Dominik Tomaszuk

From barryleiba.mailing.lists@gmail.com  Thu Nov 10 01:40:45 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922C421F8B3D for ; Thu, 10 Nov 2011 01:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.792
X-Spam-Level: 
X-Spam-Status: No, score=-102.792 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 1KzGFjN0rxWz for ; Thu, 10 Nov 2011 01:40:45 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07EDD21F8B3A for ; Thu, 10 Nov 2011 01:40:44 -0800 (PST)
Received: by yenl7 with SMTP id l7so2087997yen.31 for ; Thu, 10 Nov 2011 01:40:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=k9OuvgtfXCYlwY9y/sfpyyNTxNgXTATYDjdzhwSI0L8=; b=OqYMe/ux/giLzDfAf9hOVCm5L7Qx0xUQn9Dxk/2/qr2dEWfjsk/69U+r/PEHRT1lFy HqSWLCPIXY/zwvR0WfHndGDjDYqh9Rr5yXq5ZWytDVN6qvRbyQEA5pmfbRDLEwcN7Lrx u6pF6Zni2s1qzVdsQmJEjwbNu3NpCD2lnsx5M=
MIME-Version: 1.0
Received: by 10.146.120.12 with SMTP id s12mr1598584yac.21.1320918028433; Thu, 10 Nov 2011 01:40:28 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.250.14 with HTTP; Thu, 10 Nov 2011 01:40:28 -0800 (PST)
In-Reply-To: <4EBB7568.1020003@it.aoyama.ac.jp>
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <56B202FE-ED81-4C36-AB4C-0A809F51D009@standardstrack.com> <4EBB3762.6000907@dcrocker.net> <4EBB7568.1020003@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 04:40:28 -0500
X-Google-Sender-Auth: qv5iI6lfkTUH-RpgVhU3SRS-b1w
Message-ID: 
From: Barry Leiba 
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= 
Content-Type: text/plain; charset=ISO-8859-1
Cc: dcrocker@bbiw.net, "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 09:40:45 -0000

> I think it may be too early to discuss procedural points, but we are
> speaking about one, potentially two, drafts, both of which quite short. In
> the old days, AD-sponsored individual submission(s) would have been best.
> Now, we might need to move it through the Apps WG.

Yes, I agree.  As appsawg chair, I think this is appropriate for
appsawg (but I haven't discussed this with my co-chairs).  That said,
the right way to start this is, indeed, to float individual-submission
drafts for this gang to review and comment on.  If that discussion
results in adoption of those drafts by appsawg, you're on your way.

Barry

From julian.reschke@gmx.de  Thu Nov 10 01:50:56 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001E521F8B3B for ; Thu, 10 Nov 2011 01:50:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.376
X-Spam-Level: 
X-Spam-Status: No, score=-104.376 tagged_above=-999 required=5 tests=[AWL=-1.777, 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 t0pu77QNvlxa for ; Thu, 10 Nov 2011 01:50:54 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0239421F8B00 for ; Thu, 10 Nov 2011 01:50:53 -0800 (PST)
Received: (qmail invoked by alias); 10 Nov 2011 09:50:52 -0000
Received: from p5DCC32E8.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.50.232] by mail.gmx.net (mp071) with SMTP; 10 Nov 2011 10:50:52 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+aeEoBi0WafIheA5MtpT1bKM2eQacWCUgzEKp2Ig mWgWMDpc3N7CZ2
Message-ID: <4EBB9E75.9060405@gmx.de>
Date: Thu, 10 Nov 2011 10:50:45 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Dominik Tomaszuk 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <4EBB9BE1.6020802@wp.pl>
In-Reply-To: <4EBB9BE1.6020802@wp.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 09:50:56 -0000

On 2011-11-10 10:39, Dominik Tomaszuk wrote:
> On 08.11.2011 18:05, Paul Hoffman wrote:
>>> I propose to give possibility to declare namespace.
>>
>> -1. Actually, -10. While somewhat useful for XML, namespaces have also
>> proven to cause many headaches for corner cases.
> I do not propose to reject Clark Notation and add declarative XML-like
> namespaces. My proposal was optional. If like long Clark Notation URLs'

The added complexity is there, even if it's optional.

> you can use it (advantage: easy processing). If you want short and
> non-repeated namespace you can declare it and use only reference
> (advantage: smaller and easier to read file).

Again, why would you want it? In XML, manual editing and recomposing was 
a use case; do you think the same it true for JSON?

> ...

Best regards, Julian

From julian.reschke@gmx.de  Thu Nov 10 02:01:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0C221F8B20 for ; Thu, 10 Nov 2011 02:01:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.352
X-Spam-Level: 
X-Spam-Status: No, score=-104.352 tagged_above=-999 required=5 tests=[AWL=-1.753, 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 1qD7g8qNVnrH for ; Thu, 10 Nov 2011 02:01:10 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id CF40D21F8B1C for ; Thu, 10 Nov 2011 02:01:09 -0800 (PST)
Received: (qmail invoked by alias); 10 Nov 2011 10:01:08 -0000
Received: from p5DCC32E8.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.50.232] by mail.gmx.net (mp072) with SMTP; 10 Nov 2011 11:01:08 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18oixdUE1koq/ERQx+v09kgL6ZjFiBt/CPY2DAOOo sL50dQjlmcY6Kt
Message-ID: <4EBBA0DD.9020605@gmx.de>
Date: Thu, 10 Nov 2011 11:01:01 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul C. Bryan" 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron>
In-Reply-To: <1320254564.2622.37.camel@neutron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 10:01:11 -0000

On 2011-11-02 18:22, Paul C. Bryan wrote:
> Thanks everyone for the feedback so far. Some replies:
>
> On Wed, 2011-11-02 at 13:39 +0000, Michael Dürig wrote:
>> What is missing (wrt. to [2]) is a reorder operation.
>
> The ability to move items in an array has come up and seems
> straightforward. A need (and semantics) of moving a value between two
> arbitrary locations in a JSON document is not well understood.

+1. So are you planning to add this? Would it make sense to make a 
concrete proposal?

> On Wed, 2011-11-02 at 14:57 +0100, Julian Reschke wrote:
>> As an XML person, seeing an XPath-like syntax make me happy. But
>> wouldn't be "dot" notation be much simpler, given where JSO comes from?
>
> A few of reasons we went with slashes:
>
> 1. Less confusing where array elements are involved.

...I'll have to ask :-). What about changing the notation for array 
elements to use [ and ]? More complexity in the expression language, but 
also more readability, I believe...

> 2. Slashes are less likely to appear in object member names, hence less
> percent-encoding.
> 3. Pointers are intended to be specified in URI fragment identifiers,
> and would appear to some (unsophisticated humans or machines) like a
> filename extension.

Thanks for the explanation.

Best regards, Julian

From ddooss@wp.pl  Thu Nov 10 02:08:55 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420A021F8AD8 for ; Thu, 10 Nov 2011 02:08:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.237
X-Spam-Level: 
X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95]
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 MxR3dVybWIx8 for ; Thu, 10 Nov 2011 02:08:54 -0800 (PST)
Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6115921F8AD2 for ; Thu, 10 Nov 2011 02:08:54 -0800 (PST)
Received: (wp-smtpd smtp.wp.pl 1087 invoked from network); 10 Nov 2011 11:08:49 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1320919729; bh=Q10/hdWAtjZbMqApt07VbbEkR4qnKmFSaf2IM+weTEw=; h=From:To:CC:Subject; b=dodFw/WveOcs1ZvnUPGcMNNIvcJWx+53R23oh2Y42a+JbwK/6sFq1VIkjeupRNLkU cubOomNkYYqpB82nU94iWibOwY0rGr1f93M3EGDEa8D6tNgMqsdM7aYDgA4p7bUGBs 36XhrUENTn5Y+ca8U2TekD/RF+f19Z29h02VJN5M=
Received: from 87-205-152-63.adsl.inetia.pl (HELO [192.168.1.2]) (ddooss@[87.205.152.63]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 10 Nov 2011 11:08:49 +0100
Message-ID: <4EBBA2B0.7090404@wp.pl>
Date: Thu, 10 Nov 2011 11:08:48 +0100
From: Dominik Tomaszuk 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Julian Reschke 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <4EBB9BE1.6020802@wp.pl> <4EBB9E75.9060405@gmx.de>
In-Reply-To: <4EBB9E75.9060405@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO 0000006 [0ZYE]                               
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 10:08:55 -0000

On 10.11.2011 10:50, Julian Reschke wrote:
> The added complexity is there, even if it's optional.
Agree, if you use it.

> Again, why would you want it? In XML, manual editing and recomposing was
> a use case; do you think the same it true for JSON?
Yes, I do.

Best regards,
Dominik Tomaszuk


From ietfc@btconnect.com  Thu Nov 10 02:11:56 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCB021F8B31 for ; Thu, 10 Nov 2011 02:11:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.373
X-Spam-Level: 
X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 dD8gAntM7yvc for ; Thu, 10 Nov 2011 02:11:55 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7FB21F8508 for ; Thu, 10 Nov 2011 02:11:54 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr10.btconnect.com with SMTP id FAU12083; Thu, 10 Nov 2011 10:11:37 +0000 (GMT)
Message-ID: <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: , "=?iso-8859-1?Q?Martin_J._D=FCrst?=" 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>	<60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>	<4EB9D49C.5010100@it.aoyama.ac.jp><4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net>
Date: Thu, 10 Nov 2011 10:06:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4EBBA357.0077, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.10.85714:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4EBBA35B.0116,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 10:11:56 -0000

Dave

My bibles say

Type(face) Family; Courier, Futura, Century Schoolbook,  ..
Typeface; one of the above with a defined
 - Style: Roman, Italic
 - Weight: Light, Semibold, Bold, ...
 - Width: Ultracondensed, Condensed, Expanded, ...
Type Font; one of the above with a defined Size
 - eg 12-point

I always think that the developers of the world's most widely used word
processing software do not understand this, when they try to persuade me to use
a different Type Family for my running heading and my running footing, which is
a glorious way of making a document really ugly, but in a way that is quite hard
to detect. Mixing Typefaces is fine, mixing families is not.

Tom Petch

p.s. I am sometimes (well, often) told I am too pedantic, but I think that a
virtue with standards:-)

----- Original Message -----
From: "Dave CROCKER" 
To: "Martin J. Dürst" 
Cc: 
Sent: Thursday, November 10, 2011 5:36 AM

On 11/10/2011 12:20 PM, "Martin J. Dürst" wrote:
>>
>> That is, typeface is the basic design (or abstraction) while typeface +
>> physical details (such as specific size) is a font?
>
> Not exactly. On the one hand, the italic version of times roman actually is a
> design by itself, so it can very well be seen as a typeface.
>
> On the other hand, specific size was important for lead type (which doesn't
> scale) and bitmap font formats. With today's outline and hinting technologies,
> most fonts are designed to work at many different sizes, so the specific size
is
> rather irrelevant.
>
> Anyway, what we are looking at is to have media types for font formats.
Typeface
> affects this only marginally.

Well, I think I tracked your response and I think it made sense to me, including
the wrinkle added to the historical perspective by the 'outline' model(s).

The problem is that where it landed leaves me still unclear about the exact
difference between face and font, and it seems that it would be useful for
font/face non-geeks, like me, to be able to use the terms properly.

mumble.

d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



From ietfc@btconnect.com  Thu Nov 10 02:34:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3707521F8A96 for ; Thu, 10 Nov 2011 02:34:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level: 
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091,  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 GgUPNEIrNuUp for ; Thu, 10 Nov 2011 02:34:34 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 63CCA21F8A80 for ; Thu, 10 Nov 2011 02:34:33 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr09.btconnect.com with SMTP id FCN83492; Thu, 10 Nov 2011 10:34:25 +0000 (GMT)
Message-ID: <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: , "Apps Discuss" 
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp> <4EBB7660.6040904@dcrocker.net>
Date: Thu, 10 Nov 2011 10:28:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4EBBA8B0.0040, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.10.94215:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_MEDIA_BODY, __CP_URI_IN_BODY, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4EBBA8B1.01B3,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 10:34:36 -0000

----- Original Message -----
From: "Dave CROCKER" 
To: "Apps Discuss" 
Sent: Thursday, November 10, 2011 7:59 AM
> Folks,
>
> On 11/10/2011 2:02 PM, Barry Leiba wrote:
> >> But the fact is that we have a major/minor type system. We can as well make
> >> reasonable use of it.
> >
> > As I said in the other thread (on font/*), we already have the concept
> > of saying "This is text," "This is an image," and "This is audio," and
> > I see only negative points in insisting that everything other than the
> > few TLMTs that we're already defined have to be "application".  We
> > should do some filtering and apply some judgment, of course, but
> > making everything the equivalent to "application/image-jpeg" is silly
> > and non-useful.
>
> That states a basic direction/goal: To have a lower hurdle than perhaps was
> there before.
>
> Does it have any basic downsides?
>
> My sense from the latest round of postings, including Ned's, is that there is
no
> current reason to impose a high hurdle on TLCTs.
>
>       Consensus check
>       ===============
>
>       Is there anyone out there who believes that it is extremely expensive or
> dangerous to introduce new, top-level Content-Type and that, therefore, the
> barrier to new TLCTs should be (kept) high?

Yes.  Based on FUD rather than concrete information, but what will all the
deployed software do when face with a new top-level Content-Type?  And how long
will it take for the makers of commercial software to incorporate this in their
products (1-2years) and how long will it take for that software to be widely
deployed(3-5 years)?

I just received an (antisocial) e-mail with .gif's attached, so I edited the
Content-Type to be font/various things, and my MUA took no notice, just
processed them as .gif.

I modified the Content-Description in the same way, same result.

Only when I modified the filename (eg to .ttf) did the MUA take any notice and
complain that the attachment was not a font, pdf etc.

I think we need to know this for commonly deployed platforms before we can say
it is not dangerous.

Tom Petch

>
> Assuming the answer and the consensus is no, that still leaves open what
> pragmatic guidance is to be used for accepting or rejecting a request for a
> TLCT.  (We could take the ICANN approach and just filter based on huge gobs of
> money, but I doubt that model will transfer to the IETF.)
>
> So far, the most cogent guidance I've seen seems to be related to the
> justification in the model spec (RFC 2077):
>
>    "The important fact is that these
>     various subtypes can be converted between each other with less loss
>     of information then to that of other primary types.  This fact groups
>     these subtypes together into the model primary type.  All of the
>     expected subtypes have several features in common and that are unique
>     to this primary type."
>
> I had suggested a guideline in terms of "dispatching" to different
applications.
>   Ned's note offered a better framing, in terms of common code among a set of
> content sub-types.  A particular form of such code, implied by the model
> document, is for translating among sub-types.
>
> Martin pointed out an "administrative" issue quite different from the basic
> registration scaling or decentralization I cited, namely the search for
related
> types by an implementer, where separate sub-tables would be helpful.  He
noted:
>
>       http://www.iana.org/assignments/media-types/image/index.html
>
> as a good example.
>
>
>       Consensus Check
>       ===============
>
>       So, I think this leaves guidance in favor of a new top-level
content-type
> if one or more of the following apply:
>
>       1.  Strong semantic relationship among the sub-types
>
>       2.  Likelihood of some common code for the set of sub-types
>
>       3.  Expectation that implementors will benefit from easily discovering
the
> current set of sub-types in the registry.
>
> Does this summarize the guidance that should be offered for justifying a new
TLCT?
>
> d/
> --
>
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net



From martin.thomson@gmail.com  Thu Nov 10 02:45:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5E121F8AFB for ; Thu, 10 Nov 2011 02:45:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPeh3jugqGfu for ; Thu, 10 Nov 2011 02:45:07 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42D3021F8A97 for ; Thu, 10 Nov 2011 02:45:07 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so2624479bkb.31 for ; Thu, 10 Nov 2011 02:45:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kx7jBAJdPNXg7YTig9VF/UB1vgPt9QfXbRFJwVWwe9A=; b=AyFx70FQITEyZ0hvMI9vQTRFZ2PSBD2eimzSgpauiYbn3UPSuAJjpVL6axiTRYv/Bc LBjf57c4w2+Percu8XHsvPsKp8szviNMrJ0zjFJEoKXirYyS8qMnIfi+dsoiFNBFzyi/ YZCFqmiX69d3QXxHJZ3qJP0ztYwaSfCQdO8Dw=
MIME-Version: 1.0
Received: by 10.204.140.129 with SMTP id i1mr4671033bku.19.1320921906123; Thu, 10 Nov 2011 02:45:06 -0800 (PST)
Received: by 10.204.72.210 with HTTP; Thu, 10 Nov 2011 02:45:06 -0800 (PST)
In-Reply-To: <4EBBA0DD.9020605@gmx.de>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de>
Date: Thu, 10 Nov 2011 21:45:06 +1100
Message-ID: 
From: Martin Thomson 
To: Julian Reschke 
Content-Type: text/plain; charset=UTF-8
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 10:45:08 -0000

On 10 November 2011 21:01, Julian Reschke  wrote:
> ...I'll have to ask :-). What about changing the notation for array elements
> to use [ and ]? More complexity in the expression language, but also more
> readability, I believe...

That sounds like a good idea.  Use JSON string representation and you
can deal with any sort of identifier without much new code...
["foo"][3]["bar"]  The approach worked for JSON itself, why not here
too?

From ddooss@wp.pl  Thu Nov 10 02:46:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDC621F8512 for ; Thu, 10 Nov 2011 02:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.133
X-Spam-Level: 
X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95]
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 E459FxnDggRQ for ; Thu, 10 Nov 2011 02:46:35 -0800 (PST)
Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2B33E21F8508 for ; Thu, 10 Nov 2011 02:46:34 -0800 (PST)
Received: (wp-smtpd smtp.wp.pl 6239 invoked from network); 10 Nov 2011 11:46:31 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1320921991; bh=FZB5byNEfIIf15LE0YUWAqYCV7I142beBtMfPW5QUHc=; h=From:To:CC:Subject; b=BCWen8hzU4+dM3PCn2jirpqoMb/ilTcKoW84/mgEAySPGlANZNMPrWGKpQOFPl6oq YFp6Pkt77mVLLur5gAWQ+whgJABNCw8gt6idrUZ97tFLlU6g1cCm5mj+ZQ15yHkCB+ u9mLVA+KUKTP0zQzU0rhVVivTmuYirO9ttBf3lQw=
Received: from 87-205-152-63.adsl.inetia.pl (HELO [192.168.1.2]) (ddooss@[87.205.152.63]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 10 Nov 2011 11:46:31 +0100
Message-ID: <4EBBAB86.8050202@wp.pl>
Date: Thu, 10 Nov 2011 11:46:30 +0100
From: Dominik Tomaszuk 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Julian Reschke 
References: <4EB923CF.7080600@wp.pl> <566A345F-15CD-473B-8472-11EDF73A3862@vpnc.org> <4EBB9BE1.6020802@wp.pl> <4EBB9E75.9060405@gmx.de> <4EBBA2A0.9050308@wp.pl> <4EBBA372.4080403@gmx.de>
In-Reply-To: <4EBBA372.4080403@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO 0000006 [4Sb0]                               
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-saintandre-json-namespaces-00 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 10:46:36 -0000

On 10.11.2011 11:12, Julian Reschke wrote:
>>> Again, why would you want it? In XML, manual editing and recomposing was
>>> a use case; do you think the same it true for JSON?
>> Yes, I do.
>
> So you're editing JSON payloads in a text editor?

Sometimes, but more often I edit MongoDB console.

Best regards,
Dominik Tomaszuk

From duerst@it.aoyama.ac.jp  Thu Nov 10 02:47:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B13E21F8A97 for ; Thu, 10 Nov 2011 02:47:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.281
X-Spam-Level: 
X-Spam-Status: No, score=-99.281 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 BXr1+-BHJLFm for ; Thu, 10 Nov 2011 02:47:52 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id CF5D221F8A4B for ; Thu, 10 Nov 2011 02:47:51 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAAAlkA0014231 for ; Thu, 10 Nov 2011 19:47:46 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5910_5969_6ce89228_0b89_11e1_bbef_001d096c5782; Thu, 10 Nov 2011 19:47:46 +0900
Received: from [IPv6:::1] ([133.2.210.1]:36110) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Nov 2011 19:47:49 +0900
Message-ID: <4EBBABC1.1010101@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 19:47:29 +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: "t.petch" 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>	<60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>	<4EB9D49C.5010100@it.aoyama.ac.jp><4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net>
In-Reply-To: <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 10:47:52 -0000

On 2011/11/10 18:06, t.petch wrote:
> Dave
>
> My bibles say
>
> Type(face) Family; Courier, Futura, Century Schoolbook,  ..
> Typeface; one of the above with a defined
>   - Style: Roman, Italic
>   - Weight: Light, Semibold, Bold, ...
>   - Width: Ultracondensed, Condensed, Expanded, ...
> Type Font; one of the above with a defined Size
>   - eg 12-point

As I said before in a mail to Dave, the last point worked well for lead 
type or bitmap fonts, but technology has moved beyond.

Regards,    Martin.

From duerst@it.aoyama.ac.jp  Thu Nov 10 02:53:50 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A6521F8A62 for ; Thu, 10 Nov 2011 02:53:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.279
X-Spam-Level: 
X-Spam-Status: No, score=-99.279 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 7x3XXolbt+jt for ; Thu, 10 Nov 2011 02:53:49 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 946B421F8783 for ; Thu, 10 Nov 2011 02:53:49 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAAArmcA018798 for ; Thu, 10 Nov 2011 19:53:48 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5910_598d_4506078a_0b8a_11e1_bbef_001d096c5782; Thu, 10 Nov 2011 19:53:48 +0900
Received: from [IPv6:::1] ([133.2.210.1]:39132) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Nov 2011 19:53:52 +0900
Message-ID: <4EBBAD2C.5000106@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 19:53:32 +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: "t.petch" 
References: <4EBB3CFC.5050608@dcrocker.net>	<4EBB5310.6080103@it.aoyama.ac.jp>	<4EBB7660.6040904@dcrocker.net> <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net>
In-Reply-To: <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dcrocker@bbiw.net, Apps Discuss 
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 10:53:50 -0000

On 2011/11/10 18:28, t.petch wrote:
> ----- Original Message -----
> From: "Dave CROCKER"
> To: "Apps Discuss"
> Sent: Thursday, November 10, 2011 7:59 AM
>> Folks,
>>
>> On 11/10/2011 2:02 PM, Barry Leiba wrote:
>>>> But the fact is that we have a major/minor type system. We can as well make
>>>> reasonable use of it.
>>>
>>> As I said in the other thread (on font/*), we already have the concept
>>> of saying "This is text," "This is an image," and "This is audio," and
>>> I see only negative points in insisting that everything other than the
>>> few TLMTs that we're already defined have to be "application".  We
>>> should do some filtering and apply some judgment, of course, but
>>> making everything the equivalent to "application/image-jpeg" is silly
>>> and non-useful.
>>
>> That states a basic direction/goal: To have a lower hurdle than perhaps was
>> there before.
>>
>> Does it have any basic downsides?
>>
>> My sense from the latest round of postings, including Ned's, is that there is
> no
>> current reason to impose a high hurdle on TLCTs.
>>
>>        Consensus check
>>        ===============
>>
>>        Is there anyone out there who believes that it is extremely expensive or
>> dangerous to introduce new, top-level Content-Type and that, therefore, the
>> barrier to new TLCTs should be (kept) high?
>
> Yes.  Based on FUD rather than concrete information,

It's nice for you to admit that your argument is based on FUD. But I 
think its a bad idea to use that for standards development.

Ned has given some very good arguments for why most if not all software 
uses the full (i.e. major/minor) type for dispatching,... All the 
experience I have (which I have to admit is way less than Ned) points in 
the same direction.


> but what will all the
> deployed software do when face with a new top-level Content-Type?  And how long
> will it take for the makers of commercial software to incorporate this in their
> products (1-2years) and how long will it take for that software to be widely
> deployed(3-5 years)?

If it will have taken the IETF more than 10 years to get around to 
finally approve the font/ top level type, we can't blame developers when 
it takes them 3-5 years to deploy that.

And the deployment time is the same if we register new types under 
application/.

Regards,   Martin.

> I just received an (antisocial) e-mail with .gif's attached, so I edited the
> Content-Type to be font/various things, and my MUA took no notice, just
> processed them as .gif.
>
> I modified the Content-Description in the same way, same result.
>
> Only when I modified the filename (eg to .ttf) did the MUA take any notice and
> complain that the attachment was not a font, pdf etc.
>
> I think we need to know this for commonly deployed platforms before we can say
> it is not dangerous.
>
> Tom Petch

From duerst@it.aoyama.ac.jp  Thu Nov 10 03:04:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3090621F8AD8 for ; Thu, 10 Nov 2011 03:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.576
X-Spam-Level: 
X-Spam-Status: No, score=-99.576 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CP2JHOzjgEf for ; Thu, 10 Nov 2011 03:04:08 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB5E21F8A71 for ; Thu, 10 Nov 2011 03:04:08 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAAB47Bb016746 for ; Thu, 10 Nov 2011 20:04:07 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6627_5e94_b595d88a_0b8b_11e1_89fb_001d096c566a; Thu, 10 Nov 2011 20:04:07 +0900
Received: from [IPv6:::1] ([133.2.210.1]:48329) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Nov 2011 20:04:10 +0900
Message-ID: <4EBBAF96.4000304@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 20:03:50 +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: dcrocker@bbiw.net
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp>	 <4EBB7660.6040904@dcrocker.net>
In-Reply-To: <4EBB7660.6040904@dcrocker.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 11:04:09 -0000

On 2011/11/10 15:59, Dave CROCKER wrote:
> Folks,
>
> On 11/10/2011 2:02 PM, Barry Leiba wrote:
>>> But the fact is that we have a major/minor type system. We can as
>>> well make
>>> reasonable use of it.
>>
>> As I said in the other thread (on font/*), we already have the concept
>> of saying "This is text," "This is an image," and "This is audio," and
>> I see only negative points in insisting that everything other than the
>> few TLMTs that we're already defined have to be "application". We
>> should do some filtering and apply some judgment, of course, but
>> making everything the equivalent to "application/image-jpeg" is silly
>> and non-useful.
>
>
> That states a basic direction/goal: To have a lower hurdle than perhaps
> was there before.
>
> Does it have any basic downsides?

In particular for the example now at hand, not that I know.

> My sense from the latest round of postings, including Ned's, is that
> there is no current reason to impose a high hurdle on TLCTs.
>
>
> Consensus check
> ===============
>
> Is there anyone out there who believes that it is extremely expensive or
> dangerous to introduce new, top-level Content-Type and that, therefore,
> the barrier to new TLCTs should be (kept) high?
>
>
> Assuming the answer and the consensus is no, that still leaves open what
> pragmatic guidance is to be used for accepting or rejecting a request
> for a TLCT. (We could take the ICANN approach and just filter based on
> huge gobs of money, but I doubt that model will transfer to the IETF.)

I hope it won't, too.

> So far, the most cogent guidance I've seen seems to be related to the
> justification in the model spec (RFC 2077):
>
> "The important fact is that these
> various subtypes can be converted between each other with less loss
> of information then to that of other primary types. This fact groups
> these subtypes together into the model primary type. All of the
> expected subtypes have several features in common and that are unique
> to this primary type."
>
> I had suggested a guideline in terms of "dispatching" to different
> applications. Ned's note offered a better framing, in terms of common
> code among a set of content sub-types. A particular form of such code,
> implied by the model document, is for translating among sub-types.

That would definitely apply to the font/ proposal.

> Martin pointed out an "administrative" issue quite different from the
> basic registration scaling or decentralization I cited, namely the
> search for related types by an implementer, where separate sub-tables
> would be helpful. He noted:
>
> http://www.iana.org/assignments/media-types/image/index.html
>
> as a good example.
>
>
> Consensus Check
> ===============
>
> So, I think this leaves guidance in favor of a new top-level
> content-type if one or more of the following apply:
>
> 1. Strong semantic relationship among the sub-types
>
> 2. Likelihood of some common code for the set of sub-types
>
> 3. Expectation that implementors will benefit from easily discovering
> the current set of sub-types in the registry.
>
>
> Does this summarize the guidance that should be offered for justifying a
> new TLCT?

I still think that past, present, and future examples of new top-level 
types were/are/will be so rare that having explicit guidelines doesn't 
make much sense.

But while we are at it, I'd suggest that we add some degree of 
parallelism with existing top level types (I think font/ fits in well 
with image/, audio/, and video/).

On the negative side, we could include:

- Expectation that there will only be a single subtype, or only a couple.

- Majority of existing types already registered under another type (e.g. 
application)

Regards,   Martin.

From duerst@it.aoyama.ac.jp  Thu Nov 10 03:09:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFC721F8AED for ; Thu, 10 Nov 2011 03:09:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.582
X-Spam-Level: 
X-Spam-Status: No, score=-99.582 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn2VjF2sy8oC for ; Thu, 10 Nov 2011 03:09:52 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id B72D921F8A91 for ; Thu, 10 Nov 2011 03:09:51 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAAB9oND031072 for ; Thu, 10 Nov 2011 20:09:50 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 591a_9091_825082ee_0b8c_11e1_bbef_001d096c5782; Thu, 10 Nov 2011 20:09:50 +0900
Received: from [IPv6:::1] ([133.2.210.1]:40905) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Nov 2011 20:09:54 +0900
Message-ID: <4EBBB0EE.8050502@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 20:09:34 +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: Ned Freed 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com>
In-Reply-To: <01O88AB2EM7S00RCTX@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 11:09:52 -0000

Hello Ned,

On 2011/11/10 13:06, Ned Freed wrote:

> The only place I know where there might be a problem with a new top-level
> font type is SDP. I confess to knowing next to nothing about SDP, but
> it uses media types and has some really screwy constraints on on what it
> can
> handle. I'm not seeing an application for font types in SDP, but if there
> is someone more familiar with it sohuld be consulted on possible issues.

Who would we contact to check about this?


> In practice the issue of what to register where has never been much of a
> problem. Speaking now as media types reviewer, I have not infrequently
> pushed
> back on top-level type choices, usually successfully and always amicably.

Do you know of any examples? This could help Dave with the general list 
of criteria that he wants to develop.

Regards,    Martin.

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Thu Nov 10 03:24:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C119D21F8B1C for ; Thu, 10 Nov 2011 03:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level: 
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_15=0.6, 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 0ir5+7HhOFxs for ; Thu, 10 Nov 2011 03:24:46 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 188D421F8B0D for ; Thu, 10 Nov 2011 03:24:45 -0800 (PST)
Received: by wyf28 with SMTP id 28so783720wyf.31 for ; Thu, 10 Nov 2011 03:24:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A/Em30PbNGUIK/rbRyO2yGomEmvfNrCMdhEZmHSGmAY=; b=xaobXMc9Ew1kSPNU5kI3QkRR9aLfYAeStdtFoYnhQhAUpJVhzBTCUlYVljiECdZT9g kp+8RQAH2qQ1m+hop3I3nJFESXAyc5H61rtmUQdk58yRcxYurT1tvfOng3MwjcYEmmyN oZYHrYEoG//Jm8ra7l9irW4Nh3x4Rqt69GI1A=
Received: by 10.216.72.145 with SMTP id t17mr6263836wed.88.1320924285112; Thu, 10 Nov 2011 03:24:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.184.147 with HTTP; Thu, 10 Nov 2011 03:24:05 -0800 (PST)
In-Reply-To: <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net>
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net>
From: Frank Ellermann 
Date: Thu, 10 Nov 2011 12:24:05 +0100
Message-ID: 
To: "t.petch" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 11:24:46 -0000

On 10 November 2011 10:06, t.petch wrote:

> I am sometimes (well, often) told I am too
> pedantic, but I think that a virtue with
> standards:-)

+1

Here's my obviously stupid question:  Mostly I'm
happy with the fonts shipped with my current OS.

Therefore I'd like a font/* only for the purpose
of a "do not font me" HTTPbis feature, same idea
as "do not track me" (with 5 GB per month at a
reasonable download speed I don't want nonsense.)

Actually I'd like a real Courier instead of the
horrible "new courier", or a real Helvetica, as
I had it on OS/2 (supplied by Adobe).

Out of curiosity an "Everson" mono would be also
nice, but sadly I know that this would a copyvio.

And I'd be interested in these three fonts only
once.  For the roughly 200,000 Unicode points.

How is the font/* magic supposed to work, does
cover only code points for a specific document?

-Frank (likes Tahoma and Palatino Linotype)

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Thu Nov 10 03:45:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C4621F8B1D for ; Thu, 10 Nov 2011 03:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.561
X-Spam-Level: 
X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_15=0.6, 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 CYS9zdHXOZpD for ; Thu, 10 Nov 2011 03:45:48 -0800 (PST)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 40FAD21F8B1F for ; Thu, 10 Nov 2011 03:45:48 -0800 (PST)
Received: by wwi18 with SMTP id 18so534801wwi.1 for ; Thu, 10 Nov 2011 03:45:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zav2Ti9JZgU7H7nwtSsKMZ6nCHi9KTWKTTPgxcNtL3o=; b=A7vL/RjecsvfNHk7ZwfC3REWhHtBKsZnSj51A9MPcrJoPDdbAYj5YG1lZhohkqbC+6 KKBwkIvDJdrABgQppYn9riU67AJd2/PfJ90CriFXvFV4MqK5pZBQoTRDJEW3VEhIVNjo 4MIai7zCPwuEwywu905UxWYoCb7VBViWQCRmU=
Received: by 10.216.52.16 with SMTP id d16mr1274524wec.88.1320925547141; Thu, 10 Nov 2011 03:45:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.184.147 with HTTP; Thu, 10 Nov 2011 03:45:06 -0800 (PST)
In-Reply-To: <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net>
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp>  <4EBB7660.6040904@dcrocker.net> <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net>
From: Frank Ellermann 
Date: Thu, 10 Nov 2011 12:45:06 +0100
Message-ID: 
To: "t.petch" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Apps Discuss 
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 11:45:48 -0000

On 10 November 2011 10:28, t.petch wrote:


> I just received an (antisocial) e-mail with .gif's
> attached, so I edited the Content-Type to be
> font/various things, and my MUA took no notice,
> just processed them as .gif.

That's okay.  RFC 2049 maps "dunno" to "application
octet-stream", and your UA or OS can figure out that
it's actually GIF looking at the first bytes...

> Only when I modified the filename (eg to .ttf) did
> the MUA take any notice and complain that the
> attachment was not a font, pdf etc.

...or looking at the extension.

> I think we need to know this for commonly deployed > platforms before we can say it is not dangerous.

+1  I vaguely recall than some fonts on my platform
use the format of a DLL.

-Frank

From ietfc@btconnect.com  Thu Nov 10 03:54:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED7521F8ADC for ; Thu, 10 Nov 2011 03:54:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level: 
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076,  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 eAldiB6kaVts for ; Thu, 10 Nov 2011 03:54:28 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9021F8AE1 for ; Thu, 10 Nov 2011 03:54:26 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr06.btconnect.com with SMTP id FHK43123; Thu, 10 Nov 2011 11:54:19 +0000 (GMT)
Message-ID: <022c01cc9f96$577b2220$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: , "Apps Discuss" 
References: <4EBB3CFC.5050608@dcrocker.net>
Date: Thu, 10 Nov 2011 11:48:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4EBBBB6A.00A7, actions=TAG
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.10.104515:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4EBBBB6B.006D,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 11:54:29 -0000

Dave

In this thread, there have been a number of references to how easy it is, or
not, to implement which, for me, should always be secondary to how easy it is to
use.

There is a use which is perhaps being missed which, for me, is the most
important one, and that is in keeping spam out of the system.  Being able to say
.exe goes into the bin unread is very important.  I am out of touch with current
spam filtering but believe that Media Type is a significant part of it.
(Personally, I would like ietf lists to be restricted to text/plain and while no
list moderators go that far, I have seen posts, in the past, from some
explaining what they will not allow on WG lists).

In this context, as has been said already, perhaps for very different reasons,
html should have been top-level, but we are too late for that.

Tom Petch

----- Original Message -----
From: "Dave CROCKER" 
To: "Apps Discuss" 
Sent: Thursday, November 10, 2011 3:54 AM

> Folks,
>
> The font thread has re-raised the issue of registering a Top-Level
Content-Type
> (TLCT).  I haven't seen clear statements or documents of a theory or rationale
> that would guide accepting or rejecting a request for a TLCT, and I think we
> should (finally) remedy this deficiency.
>
> In an earlier note I cited a recollection of resistance to new TLCTs.  But I
> don't remember the reasons, though I seem to recall both substance and vigor
to
> the reasons.
>
> We should try to resurrect or re-create a simple, pragmatic set of guidelines,
> and document them, so we don't have to go through the kind of vague exchanges
> happening now, with respect to arguing whether a new TLCT is appropriate.
>
> The purpose of this thread is to press for a brief document that resolves this
> kind of debate and that can be used going forward in designing the "structure"
> of new registration groups.  This ought to be in terms of real pragmatics,
> rather than aesthetics or personal preference.
>
> I can think of only two pragmatic issues in registering names like this:
>
>     1.  Administrative convenience.  A hierarchy permits administrative
grouping
> and possibly the convenience of delegating subsets of registration.  Obviously
> the DNS is the prime example.  At very large scale, this is essential.  At
small
> scale, extra structure can be a hassle.
>
>         I'm not seeing convenience as an issue for Content-Type, but perhaps
> others see the issue differently.  That is, my sense is that the entire data
> base of content-types is small enough to a) remain centralized, and b) not
> otherwise needing to benefit from sub-setting.
>
>         This calls to question why there are /any/ sub-types, of course,  but
> I'd rather cast the issue in terms of going forward, rather than of history.
>
>     2.  Code dispatching.  Different content-types invoke different software
> segments.  Parameters are input to the code but do invoke different
"programs".
>
>         I am not seeing how a TLCT vs. sub-type distinction affects this
issue.
>   That is, it seems to me that
>
>            C-T: major/minor
>
> has equal software utility as
>
>            C-T:application/major-minor
>
> Any useful difference seems to be to fall under #1, above, rather than under a
> software behavior distinction.  What am I missing?
>
> The 'model' document talks about a benefit of grouping sub-types, but I do not
> understand what the software benefit is, in terms of MIME Content-type.  That
> is, the benefit seems to be a local benefit within the model world, rather
than
> more generally within the MIME world.  Again, what am I missing?
>
> To take the 'font' discussion as an immediate, real-world exemplar, I think
the
> above says that a logical hierarchy should have the representation engine be
> superior to the typeface or font specification, since it affects software
> dispatch.
>
> Also, I don't see what the driving need for a TLCT is for font (or face...)
> It's aesthetically appealing, but I don't see the technical or administrative
> benefit.  Hence, here's one last:  what am I missing?
>
> d/
> --
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net


From nsb@guppylake.com  Thu Nov 10 06:03:02 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5D421F84AC for ; Thu, 10 Nov 2011 06:03:02 -0800 (PST)
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.299,  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 a9a6HJCmjzWb for ; Thu, 10 Nov 2011 06:03:01 -0800 (PST)
Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id BADD521F8ACC for ; Thu, 10 Nov 2011 06:03:01 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=A3dEE7oohfdaogPsiIZz2sh7LX35h+NTA+1hjPT+0IRL3uNyPTvge41fVDVMay1i30r8+W0i5WBg9mcuzI8UqZA9IcBDuCsnaYXA2YcIGpb6dZtSF2utPAlg2CtWlOqD;
Received: from 174-158-149-172.pools.spcsdns.net ([174.158.149.172] helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1ROVDR-0007IU-BW; Thu, 10 Nov 2011 09:03:01 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-618--970835550
From: Nathaniel Borenstein 
In-Reply-To: <4EBB7660.6040904@dcrocker.net>
Date: Thu, 10 Nov 2011 09:02:27 -0500
Message-Id: <678FC35A-1730-48BE-A0F2-152E5D49BC10@guppylake.com>
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp>  <4EBB7660.6040904@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server1.netnutz.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - guppylake.com
Cc: Apps Discuss 
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 14:03:02 -0000

--Apple-Mail-618--970835550
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

One other pragmatic condition might indicate the desirability of a =
top-level type:  the possibility of defining a reasonable default =
behavior for unrecognized subtypes.

Thus, for text/*, it is sometimes reasonable to just show users the raw =
text.  For image/* with an unrecognized subtype, it is sometimes =
reasonable to invoke a "smarter" program like xv.  For multipart/* you =
can at least find the parts, even if you're not sure what to do with =
them.  For video/* you  might choose to reject or strip out the data in =
a resource-challenged environment.  And I suspect this argues in favor =
of "font" as a TLCT, as the mail code may often be able to pass the data =
on to a "smarter" font engine.

I believe this is related, but not identical, to #1 and #2 below.  -- =
Nathaniel


On Nov 10, 2011, at 1:59 AM, Dave CROCKER wrote:

>     So, I think this leaves guidance in favor of a new top-level =
content-type if one or more of the following apply:
>=20
>     1.  Strong semantic relationship among the sub-types
>=20
>     2.  Likelihood of some common code for the set of sub-types
>=20
>     3.  Expectation that implementors will benefit from easily =
discovering the current set of sub-types in the registry.
>=20
>=20
> Does this summarize the guidance that should be offered for justifying =
a new TLCT?


--Apple-Mail-618--970835550
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

One =
other pragmatic condition might indicate the desirability of a top-level =
type:  the possibility of defining a reasonable default behavior =
for unrecognized subtypes.

Thus, for text/*, it is =
sometimes reasonable to just show users the raw text.  For image/* =
with an unrecognized subtype, it is sometimes reasonable to invoke a =
"smarter" program like xv.  For multipart/* you can at least find =
the parts, even if you're not sure what to do with them.  For =
video/* you  might choose to reject or strip out the data in a =
resource-challenged environment.  And I suspect this argues in =
favor of "font" as a TLCT, as the mail code may often be able to pass =
the data on to a "smarter" font engine.

I =
believe this is related, but not identical, to #1 and #2 below.  -- =
Nathaniel


On Nov 10, 2011, at =
1:59 AM, Dave CROCKER wrote:


MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com> <4EBBB0EE.8050502@it.aoyama.ac.jp>
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Cc: Ned Freed , apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 15:34:23 -0000

> Hello Ned,

> On 2011/11/10 13:06, Ned Freed wrote:

> > The only place I know where there might be a problem with a new top-level
> > font type is SDP. I confess to knowing next to nothing about SDP, but
> > it uses media types and has some really screwy constraints on on what it
> > can
> > handle. I'm not seeing an application for font types in SDP, but if there
> > is someone more familiar with it sohuld be consulted on possible issues.

> Who would we contact to check about this?

SDP, aka application/sdp, defined in RFC 4566, was a product of MMUSIC. Back
when this came up previously I think Spencer Dawkins, Jon Peterson, and maybe
Colin Perkins were the ones we talked to? Sorry, this was almost 10
years back.

> > In practice the issue of what to register where has never been much of a
> > problem. Speaking now as media types reviewer, I have not infrequently
> > pushed
> > back on top-level type choices, usually successfully and always amicably.

> Do you know of any examples? This could help Dave with the general list
> of criteria that he wants to develop.

I can't get into specifics without talking about the content of
preliminary registration requests, which I try not to do. I can say that
the most common one has been someone asking for application when image or
video would be more appropriate.

The most common name change I request, however, is the addition of +xml.

				Ned

From ietfc@btconnect.com  Thu Nov 10 10:11:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7267721F8B70 for ; Thu, 10 Nov 2011 10:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level: 
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065,  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 XiMohE1XVVUZ for ; Thu, 10 Nov 2011 10:11:18 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7744F21F8B6F for ; Thu, 10 Nov 2011 10:11:17 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr10.btconnect.com with SMTP id FAZ77076; Thu, 10 Nov 2011 18:11:01 +0000 (GMT)
Message-ID: <02de01cc9fca$f7c08020$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Frank Ellermann" 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net> 
Date: Thu, 10 Nov 2011 18:05:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4EBC13B4.006D, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.10.163914:17:7.944, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __INT_PROD_LOC, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1800_1899, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS
X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4EBC13BA.008E,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 18:11:19 -0000

----- Original Message -----
From: "Frank Ellermann" 
To: "t.petch" 
Cc: ; "Martin J. Dürst" ;

Sent: Thursday, November 10, 2011 12:24 PM


> Here's my obviously stupid question:  Mostly I'm
> happy with the fonts shipped with my current OS.
>
> Therefore I'd like a font/* only for the purpose
> of a "do not font me" HTTPbis feature, same idea
> as "do not track me" (with 5 GB per month at a
> reasonable download speed I don't want nonsense.)
>
> Actually I'd like a real Courier instead of the
> horrible "new courier", or a real Helvetica, as
> I had it on OS/2 (supplied by Adobe).
>
> Out of curiosity an "Everson" mono would be also
> nice, but sadly I know that this would a copyvio.
>
> And I'd be interested in these three fonts only
> once.  For the roughly 200,000 Unicode points.
>
> How is the font/* magic supposed to work, does
> cover only code points for a specific document?

I don't know what the proposal is.

What I see at present is that when I access certain web sites, I get a message
saying the my machine has not got the fonts installed to view the web site
properly and would I like the web site to instal some more for me.  NO WAY.  I
decide what and when I instal on my machine from where.  But I am curious, and
might try it when I have machine ready to be trashed, as to just how it would do
it.  I am assuming it would try to instal a .ttf file in  a suitable directory
(which I would expect to fail unless it is a temporary file).

I did ask the maintainers of the web site what was going on, and they had not a
clue.  My guess would be something Chinese or Korean (although the web site is
not).

Tom Petch

> -Frank (likes Tahoma and Palatino Linotype)


From mnot@mnot.net  Thu Nov 10 15:05:57 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A671F0C58 for ; Thu, 10 Nov 2011 15:05:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.216
X-Spam-Level: 
X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=-0.617, 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 8wdjM4zHaBrx for ; Thu, 10 Nov 2011 15:05:56 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 626051F0C50 for ; Thu, 10 Nov 2011 15:05:56 -0800 (PST)
Received: from [10.6.129.79] (unknown [64.39.4.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7416E22E1FB; Thu, 10 Nov 2011 18:05:49 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Mark Nottingham 
In-Reply-To: <4EBBA0DD.9020605@gmx.de>
Date: Thu, 10 Nov 2011 17:05:51 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de>
To: Julian Reschke 
X-Mailer: Apple Mail (2.1251.1)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 23:05:57 -0000

On 10/11/2011, at 4:01 AM, Julian Reschke wrote:

> ...I'll have to ask :-). What about changing the notation for array =
elements to use [ and ]? More complexity in the expression language, but =
also more readability, I believe...

+1 -- I gave similar feedback.

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





From ned.freed@mrochek.com  Thu Nov 10 16:08:47 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4641F0C5C for ; Thu, 10 Nov 2011 16:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002,  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 MWGAbamwG8RA for ; Thu, 10 Nov 2011 16:08:46 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A86BF1F0C5B for ; Thu, 10 Nov 2011 16:08:46 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O89GUJADTS011V40@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 10 Nov 2011 17:05:42 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O894J8R5DC00RCTX@mauve.mrochek.com>; Thu, 10 Nov 2011 17:05:38 -0800 (PST)
Message-id: <01O89GUH11DU00RCTX@mauve.mrochek.com>
Date: Thu, 10 Nov 2011 16:46:04 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Thu, 10 Nov 2011 10:28:49 +0100" <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp>  <4EBB7660.6040904@dcrocker.net> <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net>
To: "t.petch" 
Cc: dcrocker@bbiw.net, Apps Discuss 
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type	'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 00:08:47 -0000

> ----- Original Message -----
> From: "Dave CROCKER" 
> To: "Apps Discuss" 
> Sent: Thursday, November 10, 2011 7:59 AM
> > Folks,
> >
> > On 11/10/2011 2:02 PM, Barry Leiba wrote:
> > >> But the fact is that we have a major/minor type system. We can as well make
> > >> reasonable use of it.
> > >
> > > As I said in the other thread (on font/*), we already have the concept
> > > of saying "This is text," "This is an image," and "This is audio," and
> > > I see only negative points in insisting that everything other than the
> > > few TLMTs that we're already defined have to be "application".  We
> > > should do some filtering and apply some judgment, of course, but
> > > making everything the equivalent to "application/image-jpeg" is silly
> > > and non-useful.
> >
> > That states a basic direction/goal: To have a lower hurdle than perhaps was
> > there before.
> >
> > Does it have any basic downsides?
> >
> > My sense from the latest round of postings, including Ned's, is that there is
> no
> > current reason to impose a high hurdle on TLCTs.
> >
> >       Consensus check
> >       ===============
> >
> >       Is there anyone out there who believes that it is extremely expensive or
> > dangerous to introduce new, top-level Content-Type and that, therefore, the
> > barrier to new TLCTs should be (kept) high?

> Yes.  Based on FUD rather than concrete information, but what will all the
> deployed software do when face with a new top-level Content-Type?

I'm pretty familiar with a lot of different software that handles media types,
and in every case I know of the answer is "it already supports it".

This is a consequence of the fact that it's easiest to treat leaf media type
names as simple case-insensitive strings. Anything else is more work for no
good purpose. And one thing you can usually count on implementors to do is not
go to a lot of extra effort only to make their software harder to use and more
fragile.

> And how long
> will it take for the makers of commercial software to incorporate this in their
> products (1-2years) and how long will it take for that software to be widely
> deployed(3-5 years)?

I have yet to see any evidence that any software currently has problems of this
sort.

> I just received an (antisocial) e-mail with .gif's attached, so I edited the
> Content-Type to be font/various things, and my MUA took no notice, just
> processed them as .gif.

A lot of agents, when presented with a type they don't know, will either
use the file extension, sniff the data, or both. 

Now, you may think this handling is a bad idea (or not), but it has almost
nothing to do with top-level type usage. In fact the same thing would almost
certainly have happened had you changed the media type to image/foo or
application/foo. 

The only thing you have demonstrated in regards to unknown top-level types is
that your application doesn't choke on them.

> I modified the Content-Description in the same way, same result.

I completely fail to see why you would expect any other result. It's a textual
description, not supposed to be machine actionable, you know.

> Only when I modified the filename (eg to .ttf) did the MUA take any notice and
> complain that the attachment was not a font, pdf etc.

In other words, you changed the file extension to one that your application
knows is associated with a font of some kind. So it tried to process it
as such and got an error.

And again, to the extent this has anything to do with top-level types, you have
just shown your application to be capable of handling previously unknown ones
without falling over. And that's all you have shown.

But if you want to actually perform a more complete test, you should have tried
to add a font/* entry to your application's media type tables and then tested
with content having that label. I've done that lots of times and previously
unknown top-level types have never been a problem.

> I think we need to know this for commonly deployed platforms before we can say
> it is not dangerous.

If you regard the behavior you describe as dangerous, well, we appear to be
working from very different definitions of the word "dangerous".

				Ned

From ned.freed@mrochek.com  Thu Nov 10 17:48:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8F811E8087 for ; Thu, 10 Nov 2011 17:48:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002,  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 EcBk+XbCPEnL for ; Thu, 10 Nov 2011 17:48:18 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 33A6A11E8089 for ; Thu, 10 Nov 2011 17:48:16 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O89KBQHKG001892B@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 10 Nov 2011 18:45:04 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O894J8R5DC00RCTX@mauve.mrochek.com>; Thu, 10 Nov 2011 18:44:59 -0800 (PST)
Message-id: <01O89KBNEZAE00RCTX@mauve.mrochek.com>
Date: Thu, 10 Nov 2011 18:29:36 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Thu, 10 Nov 2011 14:59:44 +0800" <4EBB7660.6040904@dcrocker.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp>  <4EBB7660.6040904@dcrocker.net>
To: Dave CROCKER 
Cc: Apps Discuss 
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 01:48:19 -0000

> Folks,

> On 11/10/2011 2:02 PM, Barry Leiba wrote:
> >> But the fact is that we have a major/minor type system. We can as well make
> >> reasonable use of it.
> >
> > As I said in the other thread (on font/*), we already have the concept
> > of saying "This is text," "This is an image," and "This is audio," and
> > I see only negative points in insisting that everything other than the
> > few TLMTs that we're already defined have to be "application".  We
> > should do some filtering and apply some judgment, of course, but
> > making everything the equivalent to "application/image-jpeg" is silly
> > and non-useful.


> That states a basic direction/goal: To have a lower hurdle than perhaps was
> there before.

> Does it have any basic downsides?

> My sense from the latest round of postings, including Ned's, is that there is no
> current reason to impose a high hurdle on TLCTs.


>       Consensus check
>       ===============

>       Is there anyone out there who believes that it is extremely expensive or
> dangerous to introduce new, top-level Content-Type and that, therefore, the
> barrier to new TLCTs should be (kept) high?

I want to be very very clear here: It depends critically on whether or not it
has additional special semantics that MIME processors have to understand. New
leaf types generally do not have such semantics even when they are associated
with a new top-level type (text is a possible exception here).

However, a new top-level type with multipart semantics would be a *huge* deal,
especially if it had a different syntax than the existing multipart type.

New types with message semantics are a little better, but only a little.
message/global is something of a pain for two reasons: (1) The differing
syntax (CTE allowed) has to be accomodated, and (2) You have to know when has
to be decoded and when it must not be.

The only way a new leaf top-level type can have similar impact is if it
needs to be handled specially in some way when doing basic display actions.
Changes to text/plain are potentially problematic for this reason - adding
format=flowed support was actually a fair bit of work.

But I don't see how any of this applies to font/*.

> Assuming the answer and the consensus is no, that still leaves open what
> pragmatic guidance is to be used for accepting or rejecting a request for a
> TLCT.  (We could take the ICANN approach and just filter based on huge gobs of
> money, but I doubt that model will transfer to the IETF.)

Oh, I don't know. We always seem to be strapped for cash...

> So far, the most cogent guidance I've seen seems to be related to the
> justification in the model spec (RFC 2077):

>    "The important fact is that these
>     various subtypes can be converted between each other with less loss
>     of information then to that of other primary types.  This fact groups
>     these subtypes together into the model primary type.  All of the
>     expected subtypes have several features in common and that are unique
>     to this primary type."

> I had suggested a guideline in terms of "dispatching" to different applications.

As others have pointed out, it is also potentially helpful in certain sorts of
negotiation activities.

>   Ned's note offered a better framing, in terms of common code among a set of
> content sub-types.  A particular form of such code, implied by the model
> document, is for translating among sub-types.

> Martin pointed out an "administrative" issue quite different from the basic
> registration scaling or decentralization I cited, namely the search for related
> types by an implementer, where separate sub-tables would be helpful.  He noted:

>       http://www.iana.org/assignments/media-types/image/index.html

> as a good example.


>       Consensus Check
>       ===============

>       So, I think this leaves guidance in favor of a new top-level content-type
> if one or more of the following apply:

>       1.  Strong semantic relationship among the sub-types

Yes, this is the key.

>       2.  Likelihood of some common code for the set of sub-types

It's more like it's convenient to be able to treat them as a group. It doesn't
necessarily result in code sharing.

>       3.  Expectation that implementors will benefit from easily discovering the
> current set of sub-types in the registry.

Certainly a nice to have. I would also add:

        4.  It makes sense politically, socially, or both.

The [un]happiana discussion has just as much to do with perceptions as with
reality. If putting some stuff under a new top-level helps get stuff
registered and has no real cost, then I'm all for it.
 
> Does this summarize the guidance that should be offered for justifying a new
> TLCT?

Pretty close.

				Ned

From duerst@it.aoyama.ac.jp  Thu Nov 10 23:28:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420FD1F0C62 for ; Thu, 10 Nov 2011 23:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.587
X-Spam-Level: 
X-Spam-Status: No, score=-99.587 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIQsygRGVdFP for ; Thu, 10 Nov 2011 23:28:18 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 35D501F0C35 for ; Thu, 10 Nov 2011 23:28:13 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAB7S7HF016842 for ; Fri, 11 Nov 2011 16:28:07 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5306_5498_b3a3cc48_0c36_11e1_8c7e_001d096c566a; Fri, 11 Nov 2011 16:28:07 +0900
Received: from [IPv6:::1] ([133.2.210.1]:43017) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 11 Nov 2011 16:28:11 +0900
Message-ID: <4EBCCE76.2090807@it.aoyama.ac.jp>
Date: Fri, 11 Nov 2011 16:27:50 +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: Ned Freed 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com> <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>
In-Reply-To: <01O88YVG6MQY00RCTX@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 07:28:19 -0000

On 2011/11/11 1:23, Ned Freed wrote:

>> On 2011/11/10 13:06, Ned Freed wrote:

>> > In practice the issue of what to register where has never been much
>> of a
>> > problem. Speaking now as media types reviewer, I have not infrequently
>> > pushed
>> > back on top-level type choices, usually successfully and always
>> amicably.
>
>> Do you know of any examples? This could help Dave with the general list
>> of criteria that he wants to develop.
>
> I can't get into specifics without talking about the content of
> preliminary registration requests, which I try not to do. I can say that
> the most common one has been someone asking for application when image or
> video would be more appropriate.
>
> The most common name change I request, however, is the addition of +xml.

Okay. This is about change from one existing top-level type to another, 
and about tweaking the minor type name with a suffix. Out of the context 
of the discussion, I thought that you were speaking about new top-level 
types when you wrote "I have not infrequently pushed back on top-level 
type choices", but now I see that that's not a necessary interpretation.

Regards,   Martin.

From duerst@it.aoyama.ac.jp  Fri Nov 11 00:18:55 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181AE1F0C6E for ; Fri, 11 Nov 2011 00:18:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.292
X-Spam-Level: 
X-Spam-Status: No, score=-99.292 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 u+uEl5aee4Uv for ; Fri, 11 Nov 2011 00:18:54 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7971F0C65 for ; Fri, 11 Nov 2011 00:18:53 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAB8IgA5011797 for ; Fri, 11 Nov 2011 17:18:46 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 455c_2d3f_c4356146_0c3d_11e1_8c0a_001d096c5782; Fri, 11 Nov 2011 17:18:42 +0900
Received: from [IPv6:::1] ([133.2.210.1]:42857) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 11 Nov 2011 17:18:45 +0900
Message-ID: <4EBCD919.9050600@it.aoyama.ac.jp>
Date: Fri, 11 Nov 2011 17:13:13 +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: "t.petch" 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net>  <02de01cc9fca$f7c08020$4001a8c0@gateway.2wire.net>
In-Reply-To: <02de01cc9fca$f7c08020$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 08:18:55 -0000

On 2011/11/11 2:05, t.petch wrote:

> What I see at present is that when I access certain web sites, I get a message
> saying the my machine has not got the fonts installed to view the web site
> properly and would I like the web site to instal some more for me.  NO WAY.  I
> decide what and when I instal on my machine from where.  But I am curious, and
> might try it when I have machine ready to be trashed, as to just how it would do
> it.  I am assuming it would try to instal a .ttf file in  a suitable directory
> (which I would expect to fail unless it is a temporary file).
>
> I did ask the maintainers of the web site what was going on, and they had not a
> clue.  My guess would be something Chinese or Korean (although the web site is
> not).

To look at this case, it would help if you would tell us what your 
browser was, and what websites they were.

Regards,   Martin.

From cathryn@infc.ulst.ac.uk  Fri Nov 11 01:15:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA7721F8888 for ; Fri, 11 Nov 2011 01:15:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d8h2Ni5boz6 for ; Fri, 11 Nov 2011 01:15:52 -0800 (PST)
Received: from e4.ulster.ac.uk (e4.ulster.ac.uk [194.80.87.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0E33F21F849C for ; Fri, 11 Nov 2011 01:15:51 -0800 (PST)
Received: from m0.ulster.ac.uk (m0.ulster.ac.uk [194.80.87.153]) by e4.ulster.ac.uk (UU/BC) with ESMTP id pAB9FpF2029764 for ; Fri, 11 Nov 2011 09:15:51 GMT
Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by m0.ulster.ac.uk (UU/BC) with ESMTP id pAB9FphU007293 for ; Fri, 11 Nov 2011 09:15:51 GMT (envelope-from cathryn@infc.ulst.ac.uk)
Received: from localhost (localhost.localdomain [127.0.0.1]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id 13D133D06FB for ; Fri, 11 Nov 2011 09:15:51 +0000 (GMT)
X-Virus-Scanned: amavisd-new at martello.infc.ulst.ac.uk
Received: from martello.infc.ulst.ac.uk ([127.0.0.1]) by localhost (martello.infc.ulst.ac.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGUyNbD+daCn for ; Fri, 11 Nov 2011 09:15:51 +0000 (GMT)
Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id F1C2C3D05BD for ; Fri, 11 Nov 2011 09:15:50 +0000 (GMT)
Date: Fri, 11 Nov 2011 09:15:50 +0000 (GMT)
From: "Peoples, Cathryn" 
To: apps-discuss@ietf.org
Message-ID: <1612798177.831321002950950.JavaMail.root@martello.infc.ulst.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [193.61.166.86]
X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraWebClient - SAF3 (Win)/5.0.18_GA_3011.RHEL5_64)
Subject: [apps-discuss] [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Maui, Hawaii, USA
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 09:15:52 -0000

-----------------------------------------------------------------------------------------------------
 Please accept our apologies if you receive multiple copies of this CfP
-----------------------------------------------------------------------------------------------------

IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) 
==================================================================================
16 April 2012
Maui, Hawaii, USA
http://www.manfi.org


CALL FOR PAPERS
---------------
The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM).
It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner.
In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic.

Topics of interest
------------------
Authors are invited to submit papers that fall into or are related to the topic areas listed below:
- Architectural Issues
   * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet
   * Separation of data, control, and management planes
   * Design of architectural building blocks for managing the Future Internet
   * Advances in measurement, management, security, accounting, mobility, and other functions
   * Virtualization of resources and services
   * Dynamic composition of management and operational functionality
   * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet
   * Implications of social network success on the Future Internet architecture
- Design and Implementation Issues
   * Abstractions for programmable network elements
   * Accommodating context-awareness in management
   * Applying  situation awareness to network management
   * Federation between administrative domains and support of all constituencies
   * The role of models, ontologies, and other knowledge abstractions in the Future Internet
   * Uncertainty and probabilistic approaches to management of the Future Internet
   * Approaches for the organization of management data, data analytics and visualization
   * Experience reports from Future Internet experimental facilities set-up and results
- Economic Issues
   * Economic aspects driving the deployment of Future Internet management technology
   * Economic opportunities and challenges for management technology
   * Experience reports from management in test beds

Paper submission
----------------
Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/).

Proceedings
-----------
Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review.

Workshop Co-Chairs
------------------
- Prof. James Won-Ki Hong, POSTECH, Korea
- Prof. Filip De Turck, Ghent University - IBBT, Belgium
- Dr. Yoshiaki Kiriha, NEC, Japan
- Dr. Sven van der Meer, Ericsson LM, Ireland

Publicity Co-Chairs
-------------------
- Leonidas Lymberopoulos, National Technical University of Athens, Greece 
- Cathryn Peoples, University of Ulster, UK 
 
Important dates
---------------
- Abstract registration deadline: December 14, 2011
- Paper submission: December 20, 2011
- Notification of acceptance: January 31, 2012
- Final version of papers due: February 15, 2012
- Workshop date: April 16, 2012

For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org

From duerst@it.aoyama.ac.jp  Fri Nov 11 01:25:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F24021F8783 for ; Fri, 11 Nov 2011 01:25:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.432
X-Spam-Level: 
X-Spam-Status: No, score=-99.432 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315, 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 Pfi+CfQu98yk for ; Fri, 11 Nov 2011 01:25:26 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 08B8421F87FA for ; Fri, 11 Nov 2011 01:25:24 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAB9PBED031813 for ; Fri, 11 Nov 2011 18:25:16 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 4565_9e1a_0e077a58_0c47_11e1_8c0a_001d096c5782; Fri, 11 Nov 2011 18:25:11 +0900
Received: from [IPv6:::1] ([133.2.210.1]:60119) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 11 Nov 2011 18:25:14 +0900
Message-ID: <4EBCE9E5.2040501@it.aoyama.ac.jp>
Date: Fri, 11 Nov 2011 18:24:53 +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: John C Klensin 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 09:25:30 -0000

Hello John,

On 2011/11/10 11:56, John C Klensin wrote:

> --On Thursday, November 10, 2011 10:40 +0900 "\"Martin J.
> Dürst\""  wrote:

> And, yes, creating a new top level type for a half-dozen or
> fewer subtypes does seem wasteful, but, again, I don't feel
> quite as strongly about that as I did seven years ago (although
> others may).

On the page I pointed to before, at 
http://en.wikipedia.org/wiki/Category:Font_formats, I count 24. Of 
course, we don't know how many of these may get registered, but there's 
a good chance it will be more than half a dozen.


> I'll let Ned or Nathaniel speak to that, but my impression at
> the time was that it allowed for additional types because not
> doing so would represent a claim to really comprehensive
> knowledge of the future.  It wasn't intended as license to go
> out and create a bunch of them

And we haven't, and we aren't proposing to.

> -- application/ was really
> intended to be quite comprehensive wrt the things that need, as
> someone else put it, to be processed and usually stored
> somewhere, not rendered directly to the user.  We render text,
> video, and images.

And application/pdf, and application/msword, and lots of other stuff. 
These days, software may kindly ask whether the user agrees, so that 
they can disclaim responsibility for macro viruses, but that's about the 
only difference.


> Fonts are used to build tables that are then
> used with a list of characters and other information to create
> something that is rendered.  The latter is either pretty close
> to application/

It isn't necesarily. Except for the special case font editors, fonts are 
used as auxiliary documents. They make the main document look more 
pretty, but without the actual text that uses the font, they are rather 
useless.


> or, as I suggested in 2004, represents a
> different sort of creature that should be generalized.

You have brought up "should be generalized" in 2004, and you are 
apparently still believing in it. Can you please, please give a single 
concrete example of what you think should be thrown together with fonts 
so that we can claim that it has been generalized?


> Ok.  But, if you see the distinction in terms of the
> interactions, make that case for fonts.  I'm actually much more
> open to this idea than you seem to have concluded (and was open
> to it in 2004) - I just think the questions I've asked (as
> questions, not rebuttal) are appropriate and should be addressed
> in a serious way... with a default if there aren't satisfactory
> answers of "use application/".

You made a request for generalization. What if people come back and say: 
"Sorry, fonts are fonts, we don't see any way to generalize them without 
getting overly metaphysical and therefore useless."? Or even more 
direct, say "what the hell are you talking about"? (frankly, I'd like to 
know, too)


> To repeat what I said earlier, I'd like to see some I-Ds that
> drill down into the subtypes.  The observation that Bitstream
> thought that application/ was adequate for PFR (and did write a
> document) is some evidence that "these people" are not unanimous
> that a top-level type is needed.  Now, if someone came forward
> and said "we tried using application/font-tdpfr and the fact
> that 'font' wasn't a top level type caused the following
> specific problems so we have learned that putting it into
> application/ was a bad idea", I, at least, would find that
> extremely persuasive.

I have absolutely no inside knowledge, but one plausible story would be 
that somebody at Netscape told Bitstream that they better had a 
registered type for their format, and Bitstream did what they thought 
they could get through most quickly. But that's a wild guess.

As Ned has explained in quite a bit of detail, for most software 
purposes, you could register a font format under video/, or an audio 
format under image/, and sofware wouldn't care because it uses composite 
strings. But the problem is that that looks wrong to humans.


>> So why don't we change policies so that new image types also
>> have to be registered under application/?
>
> See above, plus the fact that image/ already exists as a basic
> type and part of what you are arguing against is a principle
> that we should not create a lot of top-level types... or any
> more of them without considerable justification.

So are you saying that we have image/ just because it already exists, 
but it wouldn't have a chance these days (or at least it would have to 
undergo much, much more scrutinity these days than when it was defined 
originally)?


>> ...
>> With Web fonts, or with fonts attached to other documents such
>> as emails, partial fonts are indeed very important. But they
>> will be installed temporarily. Also, for Web fonts, the main
>> usage is via CSS, which makes sure there's enough
>> meta-information.
>
> But, unless you propose to restrict the use of this type to the
> web, the broader questions need to be addressed.  And I haven't
> seen anything proposed yet that would result in a different
> handling or definitional model for temporary versus more
> permanent installations.  Again, an I-D that explored or
> specified these things would be a big help here.

I don't think there is a need for a different handling or definitional 
model for temporary versus permanent installations. These are not 
questions for transmitting the font, but questions that differ by 
OS/rendering engine,...

And there are many aspects that are quite similar (if not the same) as 
for images. If somebody receives a mail with images included or 
attached, then these images shouldn't be permanently "installed" (i.e. 
saved) on the machine, they should go away when the mail is deleted 
(unless they have been saved separately). Most mailers do a reasonable 
job for this (but not necessarily a perfect one). But I haven't seen any 
details about this in the description of the image/ top level type. So 
why would we need it for font/?


> I said before that I've got a relatively open mind about this.

Great.

> The one thing about which I don't have an open mind is the idea
> of saying "ok, let's create a top-level 'font/' type and assume
> that the subtype definitions and all of the other issues will
> sort themselves out".  I think a top-level type needs an
> architecture, not just a string of characters.  YMMD.

Oh, so what's the "architecture" for image/? From what you have written 
about fonts, I'd expect all image types to have parameters for width and 
height, maybe pixel aspect ration, and so on. Looking at 
http://tools.ietf.org/html/rfc2046#section-4.2, I can find none of that. 
Same for audio/, and video/.

Maybe there's actually a good reason for that. And maybe that's that 
these formats are self-describing, because they get bounced around in 
many contexts (in particular the file system) where they need to be 
self-describing, because there's no place to store additional parameters.

And maybe, and just maybe, the same thing actually could apply to fonts.

So I don't really understand why we need an "architecture" for font/. If 
it turns out there are some common parameters than (optionally) make 
sense, then why not have them. There are some in 
http://tools.ietf.org/html/draft-singer-font-mime-00, and we can review 
and tweak that.


>> Would it be possible to let the font experts figure this out?
>
> Sure.  Get someone to produce an I-D or three.  Don't expect
> people to believe that they will figure it out because they are
> font experts.

I should have been more precise. I didn't mean people who are "font 
experts" just because they are good at using fonts, or because they 
design fonts. I meant font experts who understand the various formats, 
maybe even have helped design one or two, define standards for formats, 
implement these, write converters between formats, and so on.


>> I agree that having a bit of text on why a new subtype was
>> chosen can't hurt at all. But I think we have to be careful
>> and not make this a sysiphean exercise by requiring something
>> like a proof that a new top-level type was absolutely
>> necessary because otherwise the world will go under.
>
> I don't think anyone has suggested that.  Certainly I haven't.

But much of what you write looks pretty close to it, at least from the 
outside.

>> Sorry, John, but they have tried before. They don't have much
>> trust anymore.
>
> As far as I can tell, only one subtype definition has been tried
> and it resulted in RFC 3073.  If "tried before" means "thought
> about it but decided to not post drafts and open discussions"
> then I sympathize but I don't know how to get unstuck (in this
> area or others with which you are familiar) from vague claims
> about obstructions and problems.

When I wrote "tried before", I specifically meant the font/ top level type.

>>   If we again tell them what sounds to them as
>> "bring it on, and we'll do our best to shoot it down and make
>> your life miserable",  then they won't do the work. They won't
>> do it for font/, and they also won't do it for application/. I
>> don't think that's what we want.
>
> I agree.  So your help, and Peter's, and that of others, are
> going to be needed to be sure that the message comes across
> well.  But I don't think that either a top-level type, or even
> an application/ subtype, are going to get very far unless there
> are definitions that can be examined by others and shown to work
> and to be sufficiently comprehensive.

"or even an application/ subtype"? Now I really don't understand things 
anymore. There are well-defined font formats that work on millions and 
millions of computers (and soon probably more than that number of 
smartphones), have published specifications and several independent 
implementations including open-source ones. What exactly do you want to 
"examine" before we allow them to be registered?


Regards,   Martin.

From evnikita2@gmail.com  Fri Nov 11 09:58:21 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CF721F8AF2 for ; Fri, 11 Nov 2011 09:58:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.34
X-Spam-Level: 
X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=-0.042,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Ed9+tam1g5Co for ; Fri, 11 Nov 2011 09:58:20 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B02A21F8AE1 for ; Fri, 11 Nov 2011 09:58:20 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so4296445bkb.31 for ; Fri, 11 Nov 2011 09:58:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=PwwpOIogzYUlpA/RwT2DgOyXdPWeYeR9SZ/YRT+AIDY=; b=Czm8bbgcDdcONY+CGoIVck4TbLictt3NsZfB2hSUw5joZ1LCufYEw6GT59hj+RXEbg q8/DPUCWDbOplqy1rIgENRf6j0e3356kOAN+1oXCLCrjq384esJmXrct/cooYIR0qAkH HAOffL4bQ3Q3+c+lk3VO2fni4enpv2myHPjJI=
Received: by 10.205.83.78 with SMTP id af14mr9177934bkc.69.1321034298030; Fri, 11 Nov 2011 09:58:18 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id by2sm2244483bkb.15.2011.11.11.09.58.14 (version=SSLv3 cipher=OTHER); Fri, 11 Nov 2011 09:58:16 -0800 (PST)
Message-ID: <4EBD6266.6030307@gmail.com>
Date: Fri, 11 Nov 2011 19:59:02 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>
In-Reply-To: <032101cc9288$e3a06910$aae13b30$@packetizer.com>
Content-Type: multipart/alternative; boundary="------------020706060006040502090104"
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 17:58:21 -0000

This is a multi-part message in MIME format.
--------------020706060006040502090104
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Paul and all,

I think you contributed a very interesting proposal indeed.  Really, RFC 
1288 finger protocol is now outdated, and you're right claiming that it 
provides no means of automatic processing.  BTW, RFC 1288 is currently 
at Draft Standard maturity level, which has been abandoned by RFC 6410, 
and we should therefore undertake something with this respect, as should 
we with respect of other Apps-related DSs, but that is what is to be 
discussed separately.

With respect to proposed 'acct' URI scheme:  how are you going to handle 
internationalization (i18n)?  We have RFC 5335 defining  
(Experimental RFC) and IESG has already approved EAI 5335bis, that will 
be Standards Track.  So will  be allowed in 'acct' URIs 
in some way?

Webfinger implies use of some link relations.  Is it anticipated that 
URIs will be used as link relations types, or we'll need to define link 
relation types for all possible use-cases of Webfinger?

Your Section 4 seems to be somewhat narrative.  I propose to divide it 
into normative specification and examples.

With regard to CORS - I'm not actually acquainted with this technology, 
but I see it is currently documented as W3C working draft, so I don't 
suspect it is now widely-used (I may of course be wrong, so please feel 
free to correct me), and I think there is no use putting MUST 
requirement on its use in Webfinger.  You could better remove your 
section on CORS from the document at all.

I think we should also provide some means of mentioning Webfinger 
accounts in vCards.  You could please see VCARDDAV document 
http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 which 
Webfinger elements may also be incorporated.

In Abstract, you should be more specific about what your document 
defines.  I propose mentioning directly that the document is the 
specification of Webfinger protocol, not "procedures for dicovering 
information about people".

In Section 7 you should clearly state that Webfinger (so as finger 
itself) is intentionally left w/o any means of controlling access to 
information (unless we want to produce *such* protocol).

I see the document is on APPSAWG agenda on the meeting, so I anticipate 
it will soon become APPSAWG item doc.  I won't be on meeting, but if you 
discuss the adaptation of Webfinger draft please also take into account 
I'm in favor of such adaptation (consider this as my 2p).

Mykyta Yevstifeyev

24.10.2011 23:09, Paul E. Jones wrote:
>
> Folks,
>
> We just submitted this:
>
> http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt
>
> The tools for Webfinger are now defined, but the procedures need to be 
> clearer with respect to what most of us understand as “webfingerâ€.  
> This is just a first stab at making that happen and we hope to 
> progress this to publish an RFC in the application area.
>
> We welcome any comments you have on the topic, either privately or 
> publicly.
>
> Paul
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--------------020706060006040502090104
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Paul and all,

    

    I think you contributed a very interesting proposal indeed.  Really,
    RFC 1288 finger protocol is now outdated, and you're right claiming
    that it provides no means of automatic processing.  BTW, RFC 1288 is
    currently at Draft Standard maturity level, which has been abandoned
    by RFC 6410, and we should therefore undertake something with this
    respect, as should we with respect of other Apps-related DSs, but
    that is what is to be discussed separately.

    

    With respect to proposed 'acct' URI scheme:  how are you going to
    handle internationalization (i18n)?  We have RFC 5335 defining
    <utf8-addr-spec> (Experimental RFC) and IESG has already
    approved EAI 5335bis, that will be Standards Track.  So will
    <utf8-addr-spec> be allowed in 'acct' URIs in some way?

    

    Webfinger implies use of some link relations.  Is it anticipated
    that URIs will be used as link relations types, or we'll need to
    define link relation types for all possible use-cases of Webfinger?

    

    Your Section 4 seems to be somewhat narrative.  I propose to divide
    it into normative specification and examples.

    

    With regard to CORS - I'm not actually acquainted with this
    technology, but I see it is currently documented as W3C working
    draft, so I don't suspect it is now widely-used (I may of course be
    wrong, so please feel free to correct me), and I think there is no
    use putting MUST requirement on its use in Webfinger.  You could
    better remove your section on CORS from the document at all.

    

    I think we should also provide some means of mentioning Webfinger
    accounts in vCards.  You could please see VCARDDAV document
    http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00
    which Webfinger elements may also be incorporated.

    

    In Abstract, you should be more specific about what your document
    defines.  I propose mentioning directly that the document is the
    specification of Webfinger protocol, not "procedures for dicovering
    information about people".

    

    In Section 7 you should clearly state that Webfinger (so as finger
    itself) is intentionally left w/o any means of controlling access to
    information (unless we want to produce *such* protocol).

    

    I see the document is on APPSAWG agenda on the meeting, so I
    anticipate it will soon become APPSAWG item doc.  I won't be on
    meeting, but if you discuss the adaptation of Webfinger draft please
    also take into account I'm in favor of such adaptation (consider
    this as my 2p).

    

    Mykyta Yevstifeyev

    

    24.10.2011 23:09, Paul E. Jones wrote:
    

      
      
      
      

        
Folks,

        
 

        
We just submitted this:

        
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

        
 

        
The tools for Webfinger are now defined,
          but the procedures need to be clearer with respect to what
          most of us understand as “webfingerâ€.  This is just a first
          stab at making that happen and we hope to progress this to
          publish an RFC in the application area.

        
 

        
We welcome any comments you have on the
          topic, either privately or publicly.

        
 

        
Paul

        
 

      

      

      

      

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


    

    

  


--------------020706060006040502090104--

From ned.freed@mrochek.com  Fri Nov 11 11:52:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F6D21F8560 for ; Fri, 11 Nov 2011 11:52:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 BVsSTAebyukE for ; Fri, 11 Nov 2011 11:52:19 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6F24D21F84AF for ; Fri, 11 Nov 2011 11:52:17 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8AM6KB24G00205E@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 11 Nov 2011 12:48:58 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8ALRTHV3K00RCTX@mauve.mrochek.com>; Fri, 11 Nov 2011 12:48:52 -0800 (PST)
Message-id: <01O8AM6GDT5000RCTX@mauve.mrochek.com>
Date: Fri, 11 Nov 2011 12:46:27 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 11 Nov 2011 16:27:50 +0900" <4EBCCE76.2090807@it.aoyama.ac.jp>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com> <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com> <4EBCCE76.2090807@it.aoyama.ac.jp>
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Cc: Ned Freed , apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 19:52:19 -0000

> On 2011/11/11 1:23, Ned Freed wrote:

> >> On 2011/11/10 13:06, Ned Freed wrote:

> >> > In practice the issue of what to register where has never been much
> >> of a
> >> > problem. Speaking now as media types reviewer, I have not infrequently
> >> > pushed
> >> > back on top-level type choices, usually successfully and always
> >> amicably.
> >
> >> Do you know of any examples? This could help Dave with the general list
> >> of criteria that he wants to develop.
> >
> > I can't get into specifics without talking about the content of
> > preliminary registration requests, which I try not to do. I can say that
> > the most common one has been someone asking for application when image or
> > video would be more appropriate.
> >
> > The most common name change I request, however, is the addition of +xml.

> Okay. This is about change from one existing top-level type to another,
> and about tweaking the minor type name with a suffix.

Understood. Both things happen. As I said, the most common top level change
is from application to image or video. Next up would probably moves from
text to application, but come to think of it I haven't have one of those
in a while.

> Out of the context
> of the discussion, I thought that you were speaking about new top-level
> types when you wrote "I have not infrequently pushed back on top-level
> type choices", but now I see that that's not a necessary interpretation.

I was simply noting that the most common change isn't a top-level change, but
rather the addition of +xml. My apologies if that was confusing.

				Ned

From ietfc@btconnect.com  Fri Nov 11 11:57:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1973E21F84DF for ; Fri, 11 Nov 2011 11:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level: 
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057,  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 0tO3B49Aanj0 for ; Fri, 11 Nov 2011 11:57:18 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 3484721F84AC for ; Fri, 11 Nov 2011 11:57:17 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr09.btconnect.com with SMTP id FDD22908; Fri, 11 Nov 2011 19:56:56 +0000 (GMT)
Message-ID: <019201cca0a2$ed2e91a0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Ned Freed" 
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp>  <4EBB7660.6040904@dcrocker.net> <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net> <01O89GUH11DU00RCTX@mauve.mrochek.com>
Date: Fri, 11 Nov 2011 19:51:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4EBD7E07.0001, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.11.175117:17:7.944, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __CP_MEDIA_BODY, BODY_SIZE_1900_1999, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS
X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4EBD7E09.009C,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: dcrocker@bbiw.net, Apps Discuss 
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 19:57:19 -0000

----- Original Message -----
From: "Ned Freed" 
To: "t.petch" 
Cc: ; "Apps Discuss" 
Sent: Friday, November 11, 2011 1:46 AM
> > ----- Original Message -----
> > From: "Dave CROCKER" 
> > To: "Apps Discuss" 
> > Sent: Thursday, November 10, 2011 7:59 AM
> > > Folks,
> > >


> In other words, you changed the file extension to one that your application
> knows is associated with a font of some kind. So it tried to process it
> as such and got an error.
>
> And again, to the extent this has anything to do with top-level types, you
have
> just shown your application to be capable of handling previously unknown ones
> without falling over. And that's all you have shown.
>
> But if you want to actually perform a more complete test, you should have
tried
> to add a font/* entry to your application's media type tables and then tested
> with content having that label. I've done that lots of times and previously
> unknown top-level types have never been a problem.
>
> > I think we need to know this for commonly deployed platforms before we can
say
> > it is not dangerous.
>
> If you regard the behavior you describe as dangerous, well, we appear to be
> working from very different definitions of the word "dangerous".

On the contrary, it suggested to me that the top level type was ignored and so
it did not matter what it was; ie the behaviour I see is safe, not dangerous.
If there is a danger, it might lie in cleverer software that took more notice of
the top level typ.

Just to be clear, I tried a variety of combinations, including ones where the
type was one I would expect the MUA to understand, eg 'image', with a filename
of eg .ttf, and the MUA preferred the file name extension to the type.  Or
perhaps it treats everything not text the same.

Tom Petch



>
> Ned
>
>


From nico@cryptonector.com  Fri Nov 11 12:43:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B90A21F8B5B for ; Fri, 11 Nov 2011 12:43:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.931
X-Spam-Level: 
X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.046,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XUnYTfLjuox for ; Fri, 11 Nov 2011 12:43:59 -0800 (PST)
Received: from homiemail-a16.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 087FA21F8A62 for ; Fri, 11 Nov 2011 12:43:58 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 9E09750807D for ; Fri, 11 Nov 2011 12:43:57 -0800 (PST)
Received: by ggnr4 with SMTP id r4so3597491ggn.31 for ; Fri, 11 Nov 2011 12:43:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.39.34 with SMTP id m2mr27092868pbk.75.1321044236739; Fri, 11 Nov 2011 12:43:56 -0800 (PST)
Received: by 10.68.40.162 with HTTP; Fri, 11 Nov 2011 12:43:56 -0800 (PST)
In-Reply-To: <019201cca0a2$ed2e91a0$4001a8c0@gateway.2wire.net>
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp>  <4EBB7660.6040904@dcrocker.net> <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net> <01O89GUH11DU00RCTX@mauve.mrochek.com> <019201cca0a2$ed2e91a0$4001a8c0@gateway.2wire.net>
Date: Fri, 11 Nov 2011 14:43:56 -0600
Message-ID: 
From: Nico Williams 
To: Apps Discuss 
Content-Type: text/plain; charset=UTF-8
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 20:43:59 -0000

Maybe we should standardize file(1) magic, create a file magic
registry, and be done.

Nico
--

From barryleiba.mailing.lists@gmail.com  Fri Nov 11 14:20:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239C421F84F5 for ; Fri, 11 Nov 2011 14:20:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.789
X-Spam-Level: 
X-Spam-Status: No, score=-102.789 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 Yaz1OnD9a7hO for ; Fri, 11 Nov 2011 14:20:15 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 990D721F84ED for ; Fri, 11 Nov 2011 14:20:15 -0800 (PST)
Received: by ywt34 with SMTP id 34so2877366ywt.31 for ; Fri, 11 Nov 2011 14:20:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WC/8vM5Bp8fMa7WE1z1BGoGE6E03N6PAXrbCuVgL06U=; b=UO6uZd3C8zenFLJCJOfKyhqteZ/erKaOgnNU+lA5Nxf9V1GtsiTYn9+PDBOYOCmlcD i+8qU9YREj3B6M0or5umuX8ZGjb3Ql1OHXIhvD2p8ikEgeJnAyMsMsFGUEguHz6sLvhV gMV32CTmMTog/jFa5qAK98sxyJOJazmeA5MT0=
MIME-Version: 1.0
Received: by 10.146.91.10 with SMTP id o10mr1480152yab.21.1321050008874; Fri, 11 Nov 2011 14:20:08 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.250.14 with HTTP; Fri, 11 Nov 2011 14:20:08 -0800 (PST)
In-Reply-To: <4EBD6266.6030307@gmail.com>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <4EBD6266.6030307@gmail.com>
Date: Fri, 11 Nov 2011 17:20:08 -0500
X-Google-Sender-Auth: pFNAPXdvXB2jrCkqAYqXVi8hg_4
Message-ID: 
From: Barry Leiba 
To: =?UTF-8?B?TXlreXRhIFlldnN0aWZleWV2ICjQnC4g0ITQstGB0YLRltGE0LXRlNCyKQ==?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 22:20:16 -0000

> I see the document is on APPSAWG agenda on the meeting, so I anticipate i=
t
> will soon become APPSAWG item doc.=A0 I won't be on meeting, but if you
> discuss the adaptation of Webfinger draft please also take into account I=
'm
> in favor of such adaptation (consider this as my 2p).

As the agenda says, some things are not verified... and, in
particular, this item is likely to be removed.  The chairs might
mention it in the meeting, but discussion of the document will be on
the mailing list.

More importantly, your assumption that a document's getting meeting
time implies that it "will soon become [a working group] doc" is very
much wrong.  Having it on the meeting agenda simply means that the
chairs think there will be some benefit to the working group process
to have a chance to talk about it face to face.  We still would need
to see enough interest in it, before the working group would accept
it.

Until now, there's been no interest expressed.  Thanks, Mykyta, for
weighing in.  Others should also, please, comment here and let the
working group and the document authors know whether you think this is
something we (and they -- possibly separate points) should pursue.

Barry, appsawg chair

From paulej@packetizer.com  Fri Nov 11 15:37:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECFB11E8098 for ; Fri, 11 Nov 2011 15:37:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 FNpmyHCOAVpt for ; Fri, 11 Nov 2011 15:37:24 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D365811E8088 for ; Fri, 11 Nov 2011 15:37:23 -0800 (PST)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pABNbJ1O028104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Nov 2011 18:37:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321054641; bh=/8Xmz/sVueGsdGQoswZ00nZZ0VN9ByE1Dd6E/pDnvBI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=R6MwXKVGU2bqiDnuQ0OU1lGTwo7DtFXBHGqCEE9EX9sN+xKJbV8Ub1jwx+7XKKUi2 6MPuFEZ3+XbiT2S9JKwlva47fJHVBMlzzKuPjn0zuZv8SxxZUeDdjPEIcevWsn4n6f 40nNB8+Y2vkkB0ahXMaGKJJzrMHls2jYyoPZ6cno=
From: "Paul E. Jones" 
To: =?UTF-8?B?JyJNeWt5dGEgWWV2c3RpZmV5ZXYgKNCcLiDQhNCy0YHRgtGW0YTQtQ==?= =?UTF-8?B?0ZTQsikiJw==?= , 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <4EBD6266.6030307@gmail.com>
In-Reply-To: <4EBD6266.6030307@gmail.com>
Date: Fri, 11 Nov 2011 18:37:15 -0500
Message-ID: <023801cca0ca$d9860a20$8c921e60$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0239_01CCA0A0.F0B1FDF0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQFe+7+KlLcGQ7A=
Content-Language: en-us
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Nov 2011 23:37:25 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0239_01CCA0A0.F0B1FDF0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Mykyta,

=20

Thanks for your positive response.

=20

To your specific questions=E2=80=A6

=20

We would definitely want to ensure that Unicode is properly supported.  =
In wasn=E2=80=99t aware of RFC 5335, so I=E2=80=99m glad you brought =
that to my attention.  Do you have a pointer to the bis draft so I can =
see exactly what is there?  I=E2=80=99d be fully in favor of using =
utf8-addr-spec.

=20

Link relation types might be names like =E2=80=9Ccopyright=E2=80=9D or =
they might be URIs.  The definition of the link relation types is =
outside the scope of the Webfinger document itself.  RFC 6415 defines =
the structure of the documents and provides examples of some link =
relations and the order of processing.  RFC 5988 defines the link =
relations more generically and establishes the registry for them.  Do =
you think we need to say more about link relations beyond what those =
documents cover?

=20

On section 4: noted.  We=E2=80=99ll try to clearly separate the =
normative and non-normative pieces better.

=20

On  CORS, there are some who have strongly advocated for it.  It would =
be very useful to allow JavaScript code to perform these queries.  =
Otherwise, the queries would have to be pushed to server-side code.  =
Let=E2=80=99s wait on deciding what to do until we get a definitive =
answer on CORS from the W3C.  I think Peter was going to do some =
investigating there.

=20

Putting Webfinger into vcard: isn=E2=80=99t that circular?  The idea =
with Webfinger is that you have the identity of the user (e.g., =
paulej@packetizer.com), but you want to find more information.  If you =
have a vcard, then you have the user=E2=80=99s identity (via the email =
tag).  Or are you suggesting that we formally introduce the acct URI in =
vcard?  That might make sense to do.  Can you clarify your proposal?

=20

For comments on particular sections, I=E2=80=99ve added notes to each =
one to revise them as you suggest: they=E2=80=99re all good suggestions.

=20

I would very much like to make this a WG item, of course, but none of =
the authors will be present at this IETF meeting.  Perhaps hallway =
dialog might take place, but not sure.  In any case, we can do this via =
the mailing list, too.

=20

Thanks!

Paul

=20

From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of "Mykyta Yevstifeyev =
(?. ?????????)"
Sent: Friday, November 11, 2011 12:59 PM
To: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger

=20

Hi Paul and all,

I think you contributed a very interesting proposal indeed.  Really, RFC =
1288 finger protocol is now outdated, and you're right claiming that it =
provides no means of automatic processing.  BTW, RFC 1288 is currently =
at Draft Standard maturity level, which has been abandoned by RFC 6410, =
and we should therefore undertake something with this respect, as should =
we with respect of other Apps-related DSs, but that is what is to be =
discussed separately.

With respect to proposed 'acct' URI scheme:  how are you going to handle =
internationalization (i18n)?  We have RFC 5335 defining  =
(Experimental RFC) and IESG has already approved EAI 5335bis, that will =
be Standards Track.  So will  be allowed in 'acct' URIs =
in some way?

Webfinger implies use of some link relations.  Is it anticipated that =
URIs will be used as link relations types, or we'll need to define link =
relation types for all possible use-cases of Webfinger?

Your Section 4 seems to be somewhat narrative.  I propose to divide it =
into normative specification and examples.

With regard to CORS - I'm not actually acquainted with this technology, =
but I see it is currently documented as W3C working draft, so I don't =
suspect it is now widely-used (I may of course be wrong, so please feel =
free to correct me), and I think there is no use putting MUST =
requirement on its use in Webfinger.  You could better remove your =
section on CORS from the document at all.

I think we should also provide some means of mentioning Webfinger =
accounts in vCards.  You could please see VCARDDAV document =
http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 which =
Webfinger elements may also be incorporated.

In Abstract, you should be more specific about what your document =
defines.  I propose mentioning directly that the document is the =
specification of Webfinger protocol, not "procedures for dicovering =
information about people".

In Section 7 you should clearly state that Webfinger (so as finger =
itself) is intentionally left w/o any means of controlling access to =
information (unless we want to produce *such* protocol).

I see the document is on APPSAWG agenda on the meeting, so I anticipate =
it will soon become APPSAWG item doc.  I won't be on meeting, but if you =
discuss the adaptation of Webfinger draft please also take into account =
I'm in favor of such adaptation (consider this as my 2p).

Mykyta Yevstifeyev

24.10.2011 23:09, Paul E. Jones wrote:=20

Folks,

=20

We just submitted this:

http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

=20

The tools for Webfinger are now defined, but the procedures need to be =
clearer with respect to what most of us understand as =
=E2=80=9Cwebfinger=E2=80=9D.  This is just a first stab at making that =
happen and we hope to progress this to publish an RFC in the application =
area.

=20

We welcome any comments you have on the topic, either privately or =
publicly.

=20

Paul

=20






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

=20


------=_NextPart_000_0239_01CCA0A0.F0B1FDF0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Mykyta,
 
Thanks for your positive =
response.
 
To your specific =
questions=E2=80=A6
 
We would definitely want =
to ensure that Unicode is properly supported.=C2=A0 In wasn=E2=80=99t =
aware of RFC 5335, so I=E2=80=99m glad you brought that to my =
attention.=C2=A0 Do you have a pointer to the bis draft so I can see =
exactly what is there?=C2=A0 I=E2=80=99d be fully in favor of using =
utf8-addr-spec.
 
Link relation types =
might be names like =E2=80=9Ccopyright=E2=80=9D or they might be =
URIs.=C2=A0 The definition of the link relation types is outside the =
scope of the Webfinger document itself.=C2=A0 RFC 6415 defines the =
structure of the documents and provides examples of some link relations =
and the order of processing.=C2=A0 RFC 5988 defines the link relations =
more generically and establishes the registry for them.=C2=A0 Do you =
think we need to say more about link relations beyond what those =
documents cover?
 
On section 4: =
noted.=C2=A0 We=E2=80=99ll try to clearly separate the normative and =
non-normative pieces better.
 
On=C2=A0 CORS, there are =
some who have strongly advocated for it.=C2=A0 It would be very useful =
to allow JavaScript code to perform these queries.=C2=A0 Otherwise, the =
queries would have to be pushed to server-side code.=C2=A0 Let=E2=80=99s =
wait on deciding what to do until we get a definitive answer on CORS =
from the W3C.=C2=A0 I think Peter was going to do some investigating =
there.
 
Putting Webfinger into =
vcard: isn=E2=80=99t that circular?=C2=A0 The idea with Webfinger is =
that you have the identity of the user (e.g., paulej@packetizer.com), but =
you want to find more information.=C2=A0 If you have a vcard, then you =
have the user=E2=80=99s identity (via the email tag).=C2=A0 Or are you =
suggesting that we formally introduce the acct URI in vcard?=C2=A0 That =
might make sense to do. =C2=A0Can you clarify your =
proposal?
 
For comments on =
particular sections, I=E2=80=99ve added notes to each one to revise them =
as you suggest: they=E2=80=99re all good =
suggestions.
 
I would very much like =
to make this a WG item, of course, but none of the authors will be =
present at this IETF meeting.=C2=A0 Perhaps hallway dialog might take =
place, but not sure.=C2=A0 In any case, we can do this via the mailing =
list, too.
 
Thanks!
Paul
 
From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of "Mykyta =
Yevstifeyev (?. ?????????)"
Sent: Friday, November 11, =
2011 12:59 PM
To: apps-discuss@ietf.org
Subject: Re: =
[apps-discuss] Webfinger
 
Hi Paul and =
all,

I think you contributed a very interesting proposal =
indeed.  Really, RFC 1288 finger protocol is now outdated, and =
you're right claiming that it provides no means of automatic =
processing.  BTW, RFC 1288 is currently at Draft Standard maturity =
level, which has been abandoned by RFC 6410, and we should therefore =
undertake something with this respect, as should we with respect of =
other Apps-related DSs, but that is what is to be discussed =
separately.

With respect to proposed 'acct' URI scheme:  how =
are you going to handle internationalization (i18n)?  We have RFC =
5335 defining <utf8-addr-spec> (Experimental RFC) and IESG has =
already approved EAI 5335bis, that will be Standards Track.  So =
will <utf8-addr-spec> be allowed in 'acct' URIs in some =
way?

Webfinger implies use of some link relations.  Is it =
anticipated that URIs will be used as link relations types, or we'll =
need to define link relation types for all possible use-cases of =
Webfinger?

Your Section 4 seems to be somewhat narrative.  I =
propose to divide it into normative specification and =
examples.

With regard to CORS - I'm not actually acquainted with =
this technology, but I see it is currently documented as W3C working =
draft, so I don't suspect it is now widely-used (I may of course be =
wrong, so please feel free to correct me), and I think there is no use =
putting MUST requirement on its use in Webfinger.  You could better =
remove your section on CORS from the document at all.

I think we =
should also provide some means of mentioning Webfinger accounts in =
vCards.  You could please see VCARDDAV document http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 =
which Webfinger elements may also be incorporated.

In Abstract, =
you should be more specific about what your document defines.  I =
propose mentioning directly that the document is the specification of =
Webfinger protocol, not "procedures for dicovering information =
about people".

In Section 7 you should clearly state that =
Webfinger (so as finger itself) is intentionally left w/o any means of =
controlling access to information (unless we want to produce *such* =
protocol).

I see the document is on APPSAWG agenda on the =
meeting, so I anticipate it will soon become APPSAWG item doc.  I =
won't be on meeting, but if you discuss the adaptation of Webfinger =
draft please also take into account I'm in favor of such adaptation =
(consider this as my 2p).

Mykyta Yevstifeyev

24.10.2011 =
23:09, Paul E. Jones wrote: 
Folks,
 
We just =
submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinge=
r-00.txt
 
The tools for Webfinger are now defined, but the =
procedures need to be clearer with respect to what most of us understand =
as =E2=80=9Cwebfinger=E2=80=9D.  This is just a first stab at =
making that happen and we hope to progress this to publish an RFC in the =
application area.
 
We welcome =
any comments you have on the topic, either privately or =
publicly.
 
Paul
 



__________________=
_____________________________
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.i=
etf.org/mailman/listinfo/apps-discuss
 

------=_NextPart_000_0239_01CCA0A0.F0B1FDF0--


From evnikita2@gmail.com  Fri Nov 11 21:31:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B0721F8497 for ; Fri, 11 Nov 2011 21:31:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.338
X-Spam-Level: 
X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4MyyBdSlgJeG for ; Fri, 11 Nov 2011 21:31:07 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4611421F8496 for ; Fri, 11 Nov 2011 21:31:06 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so4799072bkb.31 for ; Fri, 11 Nov 2011 21:31:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Eb1Xj2XMeZIF7J4d99MFRN8f5Bwa1Jj7vN2JV9cNgBQ=; b=A6rXXAytbmTRLPYkifN7VTZPHaTR84Ua1pp+Wayty7lVwPGO+V8EbAlUCdBU/OAwVJ sFeg74z1Q8rMxq10U4yuFbHqMV5wSaLb4QIH9sm2sn72Di6yOU46BLAR4ETodLaqu/3K fPcn28dBAvKJbV+/i8H19pN+ZcQhhWdQECDEs=
Received: by 10.204.149.215 with SMTP id u23mr3196106bkv.105.1321075865168; Fri, 11 Nov 2011 21:31:05 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id a4sm5614591bkq.13.2011.11.11.21.31.01 (version=SSLv3 cipher=OTHER); Fri, 11 Nov 2011 21:31:02 -0800 (PST)
Message-ID: <4EBE04C7.5090400@gmail.com>
Date: Sat, 12 Nov 2011 07:31:51 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <4EBD6266.6030307@gmail.com> <023801cca0ca$d9860a20$8c921e60$@packetizer.com>
In-Reply-To: <023801cca0ca$d9860a20$8c921e60$@packetizer.com>
Content-Type: multipart/alternative; boundary="------------050706020201070302070605"
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Nov 2011 05:31:08 -0000

This is a multi-part message in MIME format.
--------------050706020201070302070605
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Paul,

12.11.2011 1:37, Paul E. Jones wrote:
>
> Mykyta,
>
> Thanks for your positive response.
>
> To your specific questions…
>
> We would definitely want to ensure that Unicode is properly 
> supported.  In wasn’t aware of RFC 5335, so I’m glad you brought that 
> to my attention.  Do you have a pointer to the bis draft so I can see 
> exactly what is there?  I’d be fully in favor of using utf8-addr-spec.
>

This is http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13.  But 
please note that this document, unlike RFC 5335, introduced UTF-8 
additions to *base* RFC 5322 productions.  This means that  
will be defined as follows now:

>     addr-spec       =   local-part "@" domain
>     local-part      =   dot-atom / quoted-string / obs-local-part
>     domain          =   dot-atom / domain-literal / obs-domain
>     domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
>     dtext           =   %d33-90 /          ; Printable US-ASCII
>                         %d94-126 /         ;  characters not including
>                         obs-dtext          ;  "[", "]", or "\"
>     dtext           =/  UTF8-non-ascii     ; from 5335bis
>     dot-atom        =   [CFWS] dot-atom-text [CFWS]
>     dot-atom-text   =   1*atext *("." 1*atext)
>     atext           =/  UTF8-non-ascii     ; from 5335bis

So everything you will have to do is to have a note on 'acct' RI being 
possible to carry UTF8 characters and therefore being possibly IRIs.

> Link relation types might be names like “copyright†or they might be 
> URIs.  The definition of the link relation types is outside the scope 
> of the Webfinger document itself.  RFC 6415 defines the structure of 
> the documents and provides examples of some link relations and the 
> order of processing.  RFC 5988 defines the link relations more 
> generically and establishes the registry for them.  Do you think we 
> need to say more about link relations beyond what those documents cover?
>

I mean that Webfinger will have to operate on a variety of link 
relations in LRDD documents, and nobody will benefit from link relation 
types defined by URIs used there, as this eliminates the possibility for 
automatic processing.  So I ask whether we'll have to define non-URI 
link relation types for all the possible Webfinger use-cases?

> On section 4: noted.  We’ll try to clearly separate the normative and 
> non-normative pieces better.
>

Thanks.

> On  CORS, there are some who have strongly advocated for it.  It would 
> be very useful to allow JavaScript code to perform these queries.  
> Otherwise, the queries would have to be pushed to server-side code.  
> Let’s wait on deciding what to do until we get a definitive answer on 
> CORS from the W3C.  I think Peter was going to do some investigating 
> there.
>
> Putting Webfinger into vcard: isn’t that circular?  The idea with 
> Webfinger is that you have the identity of the user (e.g., 
> paulej@packetizer.com ), but you want to 
> find more information.  If you have a vcard, then you have the user’s 
> identity (via the email tag).  Or are you suggesting that we formally 
> introduce the acct URI in vcard?  That might make sense to do.  Can 
> you clarify your proposal?
>

 From RFC 6350, Section 6.4.2:

> 6.4.2. EMAIL
>
>    Purpose:  To specify the electronic mail address for communication
>       with the object the vCard represents.

...and the use might have email address different from Webfinger ID.  
I've already pointed to 
http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00, which 
VCARDDAV WG works on, and so you may try to introduce some similar 
property for Webfinger IDs.  (You see, vCards may not carry all the 
variety of information, though some people actually think in other way, 
and thus it would be a good idea to provide a means of accessing some 
additional info.)

> For comments on particular sections, I’ve added notes to each one to 
> revise them as you suggest: they’re all good suggestions.
>

Yes, thanks as well.

> I would very much like to make this a WG item, of course, but none of 
> the authors will be present at this IETF meeting.  Perhaps hallway 
> dialog might take place, but not sure.  In any case, we can do this 
> via the mailing list, too.
>

See Barry's note on this.

> Thanks!
>
> Paul
>

All the best,
Mykyta Yevstifeyev

> *From:*apps-discuss-bounces@ietf.org 
> [mailto:apps-discuss-bounces@ietf.org] *On Behalf Of *"Mykyta 
> Yevstifeyev (?. ?????????)"
> *Sent:* Friday, November 11, 2011 12:59 PM
> *To:* apps-discuss@ietf.org
> *Subject:* Re: [apps-discuss] Webfinger
>
> Hi Paul and all,
>
> I think you contributed a very interesting proposal indeed.  Really, 
> RFC 1288 finger protocol is now outdated, and you're right claiming 
> that it provides no means of automatic processing.  BTW, RFC 1288 is 
> currently at Draft Standard maturity level, which has been abandoned 
> by RFC 6410, and we should therefore undertake something with this 
> respect, as should we with respect of other Apps-related DSs, but that 
> is what is to be discussed separately.
>
> With respect to proposed 'acct' URI scheme:  how are you going to 
> handle internationalization (i18n)?  We have RFC 5335 defining 
>  (Experimental RFC) and IESG has already approved EAI 
> 5335bis, that will be Standards Track.  So will  be 
> allowed in 'acct' URIs in some way?
>
> Webfinger implies use of some link relations.  Is it anticipated that 
> URIs will be used as link relations types, or we'll need to define 
> link relation types for all possible use-cases of Webfinger?
>
> Your Section 4 seems to be somewhat narrative.  I propose to divide it 
> into normative specification and examples.
>
> With regard to CORS - I'm not actually acquainted with this 
> technology, but I see it is currently documented as W3C working draft, 
> so I don't suspect it is now widely-used (I may of course be wrong, so 
> please feel free to correct me), and I think there is no use putting 
> MUST requirement on its use in Webfinger.  You could better remove 
> your section on CORS from the document at all.
>
> I think we should also provide some means of mentioning Webfinger 
> accounts in vCards.  You could please see VCARDDAV document 
> http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 
> which Webfinger elements may also be incorporated.
>
> In Abstract, you should be more specific about what your document 
> defines.  I propose mentioning directly that the document is the 
> specification of Webfinger protocol, not "procedures for dicovering 
> information about people".
>
> In Section 7 you should clearly state that Webfinger (so as finger 
> itself) is intentionally left w/o any means of controlling access to 
> information (unless we want to produce *such* protocol).
>
> I see the document is on APPSAWG agenda on the meeting, so I 
> anticipate it will soon become APPSAWG item doc.  I won't be on 
> meeting, but if you discuss the adaptation of Webfinger draft please 
> also take into account I'm in favor of such adaptation (consider this 
> as my 2p).
>
> Mykyta Yevstifeyev
>
> 24.10.2011 23:09, Paul E. Jones wrote:
>
> Folks,
>
> We just submitted this:
>
> http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt
>
> The tools for Webfinger are now defined, but the procedures need to be 
> clearer with respect to what most of us understand as “webfingerâ€.  
> This is just a first stab at making that happen and we hope to 
> progress this to publish an RFC in the application area.
>
> We welcome any comments you have on the topic, either privately or 
> publicly.
>
> Paul
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org  
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


--------------050706020201070302070605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hello Paul,

    

    12.11.2011 1:37, Paul E. Jones wrote:
    

      
      
      
      

        
Mykyta,

        
 

        
Thanks for your
            positive response.

        
 

        
To your
            specific questions…

        
 

        
We
            would definitely want to ensure that Unicode is properly
            supported.  In wasn’t aware of RFC 5335, so I’m glad you
            brought that to my attention.  Do you have a pointer to the
            bis draft so I can see exactly what is there?  I’d be fully
            in favor of using utf8-addr-spec.

      

    

    

    This is http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13. 
    But please note that this document, unlike RFC 5335, introduced
    UTF-8 additions to *base* RFC 5322 productions.  This means that
    <addr-spec> will be defined as follows now:

    

    

      
   addr-spec       =   local-part "@" domain
   local-part      =   dot-atom / quoted-string / obs-local-part
   domain          =   dot-atom / domain-literal / obs-domain
   domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
   dtext           =   %d33-90 /          ; Printable US-ASCII
                       %d94-126 /         ;  characters not including
                       obs-dtext          ;  "[", "]", or "\" 
   dtext           =/  UTF8-non-ascii     ; from 5335bis   
   dot-atom        =   [CFWS] dot-atom-text [CFWS]   
   dot-atom-text   =   1*atext *("." 1*atext)    
   atext           =/  UTF8-non-ascii     ; from 5335bis

    

    

    So everything you will have to do is to have a note on 'acct' RI
    being possible to carry UTF8 characters and therefore being possibly
    IRIs.

    

    

      

        

        
 

        
Link
            relation types might be names like “copyright†or they might
            be URIs.  The definition of the link relation types is
            outside the scope of the Webfinger document itself.  RFC
            6415 defines the structure of the documents and provides
            examples of some link relations and the order of
            processing.  RFC 5988 defines the link relations more
            generically and establishes the registry for them.  Do you
            think we need to say more about link relations beyond what
            those documents cover?

      

    

    

    I mean that Webfinger will have to operate on a variety of link
    relations in LRDD documents, and nobody will benefit from link
    relation types defined by URIs used there, as this eliminates the
    possibility for automatic processing.  So I ask whether we'll have
    to define non-URI link relation types for all the possible Webfinger
    use-cases?

    

    

      

        

        
 

        
On
            section 4: noted.  We’ll try to clearly separate the
            normative and non-normative pieces better.

      

    

    

    Thanks.

    

    

      

        

        
 

        
On  CORS, there
            are some who have strongly advocated for it.  It would be
            very useful to allow JavaScript code to perform these
            queries.  Otherwise, the queries would have to be pushed to
            server-side code.  Let’s wait on deciding what to do until
            we get a definitive answer on CORS from the W3C.  I think
            Peter was going to do some investigating there.

        
 

        
Putting
            Webfinger into vcard: isn’t that circular?  The idea with
            Webfinger is that you have the identity of the user (e.g., paulej@packetizer.com),
            but you want to find more information.  If you have a vcard,
            then you have the user’s identity (via the email tag).  Or
            are you suggesting that we formally introduce the acct URI
            in vcard?  That might make sense to do.  Can you clarify
            your proposal?

      

    

    

    From RFC 6350, Section 6.4.2:

    

    
6.4.2. EMAIL

        

      
      
           Purpose:  To specify the electronic mail address for
        communication

              with the object the vCard represents.

    

    ...and the use might have email address different from Webfinger
    ID.  I've already pointed to
    http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00,
    which VCARDDAV WG works on, and so you may try to introduce some
    similar property for Webfinger IDs.  (You see, vCards may not carry
    all the variety of information, though some people actually think in
    other way, and thus it would be a good idea to provide a means of
    accessing some additional info.)

    

    

      

        

        
 

        
For
            comments on particular sections, I’ve added notes to each
            one to revise them as you suggest: they’re all good
            suggestions.

      

    

    

    Yes, thanks as well.

    

    

      

        

        
 

        
I
            would very much like to make this a WG item, of course, but
            none of the authors will be present at this IETF meeting. 
            Perhaps hallway dialog might take place, but not sure.  In
            any case, we can do this via the mailing list, too.

      

    

    

    See Barry's note on this.

    

    

      

        

        
 

        
Thanks!

        
Paul

      

    

    

    All the best,

    Mykyta Yevstifeyev

    

    

      

        

        
 

        

          

            

              
From:
                  apps-discuss-bounces@ietf.org
                  [mailto:apps-discuss-bounces@ietf.org] On Behalf
                    Of "Mykyta Yevstifeyev (?. ?????????)"

                  Sent: Friday, November 11, 2011 12:59 PM

                  To: apps-discuss@ietf.org

                  Subject: Re: [apps-discuss] Webfinger

            

          

          
 

          
Hi Paul and all,

            

            I think you contributed a very interesting proposal indeed. 
            Really, RFC 1288 finger protocol is now outdated, and you're
            right claiming that it provides no means of automatic
            processing.  BTW, RFC 1288 is currently at Draft Standard
            maturity level, which has been abandoned by RFC 6410, and we
            should therefore undertake something with this respect, as
            should we with respect of other Apps-related DSs, but that
            is what is to be discussed separately.

            

            With respect to proposed 'acct' URI scheme:  how are you
            going to handle internationalization (i18n)?  We have RFC
            5335 defining <utf8-addr-spec> (Experimental RFC) and
            IESG has already approved EAI 5335bis, that will be
            Standards Track.  So will <utf8-addr-spec> be allowed
            in 'acct' URIs in some way?

            

            Webfinger implies use of some link relations.  Is it
            anticipated that URIs will be used as link relations types,
            or we'll need to define link relation types for all possible
            use-cases of Webfinger?

            

            Your Section 4 seems to be somewhat narrative.  I propose to
            divide it into normative specification and examples.

            

            With regard to CORS - I'm not actually acquainted with this
            technology, but I see it is currently documented as W3C
            working draft, so I don't suspect it is now widely-used (I
            may of course be wrong, so please feel free to correct me),
            and I think there is no use putting MUST requirement on its
            use in Webfinger.  You could better remove your section on
            CORS from the document at all.

            

            I think we should also provide some means of mentioning
            Webfinger accounts in vCards.  You could please see VCARDDAV
            document http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00
            which Webfinger elements may also be incorporated.

            

            In Abstract, you should be more specific about what your
            document defines.  I propose mentioning directly that the
            document is the specification of Webfinger protocol, not
            "procedures for dicovering information about people".

            

            In Section 7 you should clearly state that Webfinger (so as
            finger itself) is intentionally left w/o any means of
            controlling access to information (unless we want to produce
            *such* protocol).

            

            I see the document is on APPSAWG agenda on the meeting, so I
            anticipate it will soon become APPSAWG item doc.  I won't be
            on meeting, but if you discuss the adaptation of Webfinger
            draft please also take into account I'm in favor of such
            adaptation (consider this as my 2p).

            

            Mykyta Yevstifeyev

            

            24.10.2011 23:09, Paul E. Jones wrote: 

          
Folks,

          
 

          
We just submitted this:

          
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

          
 

          
The tools for Webfinger are now defined,
            but the procedures need to be clearer with respect to what
            most of us understand as “webfingerâ€.  This is just a first
            stab at making that happen and we hope to progress this to
            publish an RFC in the application area.

          
 

          
We welcome any comments you have on the
            topic, either privately or publicly.

          
 

          
Paul

          
 

          


              

              

              

          
_______________________________________________

          
apps-discuss mailing list

          
apps-discuss@ietf.org

          
https://www.ietf.org/mailman/listinfo/apps-discuss

          
 

        

      

    

    

  


--------------050706020201070302070605--

From GK@ninebynine.org  Sat Nov 12 01:31:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E5121F8880 for ; Sat, 12 Nov 2011 01:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 FUNCU5oz-mYe for ; Sat, 12 Nov 2011 01:31:16 -0800 (PST)
Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id D68E221F85F1 for ; Sat, 12 Nov 2011 01:31:15 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RP9vZ-0001xM-2X; Sat, 12 Nov 2011 09:31:09 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RP9vZ-0007ri-1T; Sat, 12 Nov 2011 09:31:09 +0000
Message-ID: <4EBE2B02.8070500@ninebynine.org>
Date: Sat, 12 Nov 2011 08:14:58 +0000
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> <4EB9D46B.8010808@dcrocker.net> <4EBB2D1B.5010206@it.aoyama.ac.jp>
In-Reply-To: <4EBB2D1B.5010206@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc: dcrocker@bbiw.net, "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Nov 2011 09:31:16 -0000

On 10/11/2011 01:47, "Martin J. Dürst" wrote:
> On 2011/11/09 10:16, Dave CROCKER wrote:
>> On 11/8/2011 4:27 PM, Graham Klyne wrote:
>>> It's not clear to me what purpose would be served that cannot be handled
>>> perfectly adequately by application/*
>
> Then why do we have image/, audio/, and video/? application/ would be perfectly
> adequate for them, wouldn't it?

My supposition (and this is probably no more than post-hoc rationalization) was 
that the top level types were available for routing messages to an appropriate 
client, which might be a different device in a multimodal environment.  E.g. 
text/* to device that handles text, image/* to one that handles static images/*, 
similarly for audio/* and video/*.

Application/* then becomes appropriate for any content that doesn't depend on 
any particular presentation capabilities or modalities.

Interestingly, model/* has been mentioned in discussion as an example.  With 
increasing use of personal 3D printing (cf. http://reprap.org and spinout 
projects), I think it's a top-level type who's time is coming.  (I've even 
wondered about an update for RFC 1437...)

Of course, it all hinges on why we have top-level types at all.  From, a purely 
taxonomical perspective, I think a strictly 2-level hierarchy is always going to 
call for some arbitrary choices.

#g

From masinter@adobe.com  Sat Nov 12 02:22:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BBA21F849B for ; Sat, 12 Nov 2011 02:22:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.179
X-Spam-Level: 
X-Spam-Status: No, score=-106.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, 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 HagBqWsfUPUk for ; Sat, 12 Nov 2011 02:22:10 -0800 (PST)
Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 550BA21F8497 for ; Sat, 12 Nov 2011 02:22:09 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKTr5IzeQJuHNGpYpBYLtRs2XfzRybziJ2@postini.com; Sat, 12 Nov 2011 02:22:09 PST
Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pACAM3QB014300; Sat, 12 Nov 2011 02:22:04 -0800 (PST)
Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pACAM25R020562; Sat, 12 Nov 2011 02:22:02 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Sat, 12 Nov 2011 02:22:02 -0800
From: Larry Masinter 
To: Nico Williams , Apps Discuss 
Date: Sat, 12 Nov 2011 02:21:58 -0800
Thread-Topic: [apps-discuss] seeking pragmatic guidelines for content-type'structure': when to go top-level?
Thread-Index: AcygsqeWgvtbEUePTs6UsjkIAm9YywAcZsoQ
Message-ID: 
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp>  <4EBB7660.6040904@dcrocker.net> <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net> <01O89GUH11DU00RCTX@mauve.mrochek.com> <019201cca0a2$ed2e91a0$4001a8c0@gateway.2wire.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Nov 2011 10:22:10 -0000

Media type sniffing, http://tools.ietf.org/html/draft-ietf-websec-mime-snif=
f, standardizes the method for examining content and determining its type.

In issue http://trac.tools.ietf.org/wg/websec/trac/ticket/17  I proposed us=
ing the media type registry (after fixing it to be accurate) to be the sour=
ce of the standard.

I don't see what "file magic numbers" are good for if they're not good for =
the standard for how to determine content-type when none is supplied.

Larry


-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Nico Williams
Sent: Friday, November 11, 2011 12:44 PM
To: Apps Discuss
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type's=
tructure': when to go top-level?

Maybe we should standardize file(1) magic, create a file magic registry, an=
d be done.

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

From ietfc@btconnect.com  Sat Nov 12 04:33:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D88D21F8507 for ; Sat, 12 Nov 2011 04:33:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3]
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 l5b3VL-aME65 for ; Sat, 12 Nov 2011 04:33:30 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by ietfa.amsl.com (Postfix) with ESMTP id C129F21F84C3 for ; Sat, 12 Nov 2011 04:33:28 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr07.btconnect.com with SMTP id FDA38842; Sat, 12 Nov 2011 12:33:21 +0000 (GMT)
Message-ID: <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "=?UTF-8?Q?Martin_J._D=C3=BCrst?=" 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>	<60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>	<4EB9D49C.5010100@it.aoyama.ac.jp><4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net> <4EBBABC1.1010101@it.aoyama.ac.jp>
Date: Sat, 12 Nov 2011 12:27:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4EBE6790.005F, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.12.114514:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_1300_1399, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4EBE6792.010A,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Nov 2011 12:33:30 -0000

----- Original Message -----
From: "Martin J. Dürst" 
To: "t.petch" 
Cc: ; 
Sent: Thursday, November 10, 2011 11:47 AM


> On 2011/11/10 18:06, t.petch wrote:
> > Dave
> >
> > My bibles say
> >
> > Type(face) Family; Courier, Futura, Century Schoolbook,  ..
> > Typeface; one of the above with a defined
> >   - Style: Roman, Italic
> >   - Weight: Light, Semibold, Bold, ...
> >   - Width: Ultracondensed, Condensed, Expanded, ...
> > Type Font; one of the above with a defined Size
> >   - eg 12-point
>
> As I said before in a mail to Dave, the last point worked well for lead
> type or bitmap fonts, but technology has moved beyond.

Martin

The concepts have not changed and remain useful, IMO, in any discussion
on presentation.  What has changed is the implementation detail so when
I download a new package to my PC, then it will apply to all Fonts, within
a Typeface, as opposed to having a separate module for each Font.
(Incidentally, my bibles all relate to laser printing ie to modern technology
and have nothing to do with lead:-).

But more significantly, as other posts have clarified for me, this thread
is nothing to do with fonts but with type definition languages, so perhaps
it should be 'type/*'.

Tom Petch

> Regards,    Martin.


From masinter@adobe.com  Sat Nov 12 12:25:57 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5632A21F84DF for ; Sat, 12 Nov 2011 12:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.115
X-Spam-Level: 
X-Spam-Status: No, score=-106.115 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 UJb+n0Di9WR8 for ; Sat, 12 Nov 2011 12:25:56 -0800 (PST)
Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 2630E21F8A80 for ; Sat, 12 Nov 2011 12:25:53 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTr7WQhadwhQRUM9l20JxZhrCzUCulNr8@postini.com; Sat, 12 Nov 2011 12:25:56 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pACKPbQB001913; Sat, 12 Nov 2011 12:25:37 -0800 (PST)
Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id pACKPXLV025523; Sat, 12 Nov 2011 12:25:34 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sat, 12 Nov 2011 12:25:33 -0800
From: Larry Masinter 
To: "t.petch" , =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= 
Date: Sat, 12 Nov 2011 12:25:30 -0800
Thread-Topic: [apps-discuss] font/* (and draft-freed-media-type-regs)
Thread-Index: AcyheTdYnPX+VrnbTTGaIgyaA9nG5g==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: David Singer , "apps-discuss@ietf.org" , "gadams@xfsi.com" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Nov 2011 20:25:57 -0000

SSBzZWUgbm8gdXNlIGNhc2UgZm9yIHdoeSBoYXZpbmcgZm9udC9vcGVudHlwZSBpcyBhbnkgYmV0
dGVyIHRoYW4gYXBwbGljYXRpb24vb3BlbnR5cGUNCg0KVGhlIG9ubHkgdXNlIGNhc2UgSSBjYW4g
aW1hZ2luZSBmcm9tIGxvb2tpbmcgYXQNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LXNpbmdlci1mb250LW1pbWUtMDANCmlzIHRoZSBwb3NzaWJpbGl0eSBvZiBkZWZpbmluZyBjb21t
b24gcGFyYW1ldGVycyBhY3Jvc3MgZm9udCBkYXRhIHR5cGVzIChpbiB0aGUgc2FtZSB3YXkgdGhh
dCB0ZXh0Ly4uIGhhcyBhIGNvbW1vbiBjaGFyc2V0IHBhcmFtZXRlcikuDQoNCkJ1dCB0aGVyZSBp
c24ndCByZWFsbHkgYW55IGNvbW1vbiBwcm9jZXNzaW5nIHByb3Bvc2VkIHRoYXQgb25lIGNvdWxk
IGRvIGtub3dpbmcgdGhhdCB5b3UgaGF2ZSBmb250L3guLi4gc28gSSBhZ3JlZSB3aXRoIEdyYWhh
bSB0aGF0IHRoZXJlIGlzbid0IGEgY2FzZSBmb3IgZm9udC8uDQoNCg0KDQpUaGUgYXJndW1lbnRz
IGluIGZhdm9yIHNlZW0gdG8gYmUgb2YgdGhlIGZvcm0gIndlbGwsIHdlIGFsbG93IGZvciBuZXcg
dG9wIGxldmVsIHR5cGVzLCBzbyB3aHkgbm90IHVzZSBpdD8iDQoNCkkgYWxzbyByZWNhbGwgYSBu
dW1iZXIgb2YgeWVhcnMgYWdvIGFuIGF0dGVtcHQgdG8gZGVmaW5lICJjaGVtaWNhbC8qIiBhcyBh
IG5ldyB0b3AgbGV2ZWwgdHlwZSBmb3IgdXNlIGluIGRlZmluaW5nIGZpbGUgZm9ybWF0cz8NCg0K
TXkgY29uY2x1c2lvbiBmcm9tIHRoaXMgZGlzY3Vzc2lvbiBpcyB0aGF0IHdlIHNob3VsZCBkZWNs
YXJlIHRoZSBNSU1FIGhpZXJhcmNoeSBjbG9zZWQgdG8gbmV3IHRvcCBsZXZlbCB0eXBlczsgd2Un
dmUgb25seSBnb3R0ZW4gdmVyeSBsaW1pdGVkIHVzZSBhbmQgdmFsdWUgb3V0IG9mIHRoZSBoaWVy
YXJjaHksIGNvbXBhcmVkIHRvIHRoZSBwYWluIGFuZCBkaWZmaWN1bHR5ICh0ZXh0L3htbCB2cyBh
cHBsaWNhdGlvbi94bWwpLg0KDQpUbyBiZSBzcGVjaWZpYzogaW4gaHR0cDovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtZnJlZWQtbWVkaWEtdHlwZS1yZWdzDQogSSB3b3VsZCBwcm9wb3NlIGNo
YW5naW5nIA0KDQpPTEQ6DQogICBJbiBzb21lIGNhc2VzIGEgbmV3IG1lZGlhIHR5cGUgbWF5IG5v
dCAiZml0IiB1bmRlciBhbnkgY3VycmVudGx5DQogICBkZWZpbmVkIHRvcC1sZXZlbCBjb250ZW50
IHR5cGUuICBTdWNoIGNhc2VzIGFyZSBleHBlY3RlZCB0byBiZSBxdWl0ZQ0KICAgcmFyZS4gIEhv
d2V2ZXIsIGlmIHN1Y2ggYSBjYXNlIGRvZXMgYXJpc2UgYSBuZXcgdG9wLWxldmVsIHR5cGUgY2Fu
IGJlDQogICBkZWZpbmVkIHRvIGFjY29tbW9kYXRlIGl0LiAgU3VjaCBhIGRlZmluaXRpb24gTVVT
VCBiZSBkb25lIHZpYQ0KICAgc3RhbmRhcmRzLXRyYWNrIFJGQzsgbm8gb3RoZXIgbWVjaGFuaXNt
IGNhbiBiZSB1c2VkIHRvIGRlZmluZQ0KICAgYWRkaXRpb25hbCB0b3AtbGV2ZWwgY29udGVudCB0
eXBlcy4NCg0KTkVXOg0KDQogICBPcmlnaW5hbGx5LCBpdCB3YXMgYmVsaWV2ZWQgdGhhdCB0aGVy
ZSBtaWdodCBiZSByYXJlIGNhc2VzIHdoZXJlIG5ldyBtZWRpYSB0eXBlcyBtaWdodCBub3QgImZp
dCIgdW5kZXIgdGhlIGN1cnJlbnRseSBkZWZpbmVkIHRvcCBsZXZlbCB0eXBlcy4gSG93ZXZlciwg
dGhlIGJlbmVmaXQgb2YgaW50cm9kdWNpbmcgYSBuZXcgdG9wIGxldmVsIHR5cGUgaXMgbGlrZWx5
IHRvIGJlIGxvdyBjb21wYXJlZCB0byB0aGUgYWRkaXRpb25hbCBjb3N0IGFuZCBjb25mdXNpb24u
ICBXaGlsZSBhIG5ldyB0b3AtbGV2ZWwgdHlwZSBjYW4gYmUgZGVmaW5lZCBieSBhIHN0YW5kYXJk
cy10cmFjayBSRkMsIGl0IGlzIGxpa2VseSB0aGF0IGFkZGl0aW9uYWwgYXBwbGljYXRpb25zIGNh
biBiZSBzYXRpc2ZpZWQgYnkgdXNpbmcgdGhlICJhcHBsaWNhdGlvbi8iIHRvcC1sZXZlbCB0eXBl
Lg0KDQoNCihBZGRpdGlvbmFsIGNvbW1lbnRzIG9uIGRyYWZ0LWZyZWVkLW1lZGlhLXR5cGUtcmVn
cyBpbiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaGFwcGlhbmEvY3VycmVu
dC9tc2cwMDE4Ny5odG1sICkNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB0LnBldGNoDQpTZW50OiBTYXR1cmRheSwgTm92
ZW1iZXIgMTIsIDIwMTEgMzoyOCBBTQ0KVG86IE1hcnRpbiBKLiBEw7xyc3QNCkNjOiBhcHBzLWRp
c2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBmb250LyoNCg0KLS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIk1hcnRpbiBKLiBEw7xyc3QiIDxkdWVy
c3RAaXQuYW95YW1hLmFjLmpwPg0KVG86ICJ0LnBldGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNvbT4N
CkNjOiA8ZGNyb2NrZXJAYmJpdy5uZXQ+OyA8YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KU2VudDog
VGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDExIDExOjQ3IEFNDQoNCg0KPiBPbiAyMDExLzExLzEw
IDE4OjA2LCB0LnBldGNoIHdyb3RlOg0KPiA+IERhdmUNCj4gPg0KPiA+IE15IGJpYmxlcyBzYXkN
Cj4gPg0KPiA+IFR5cGUoZmFjZSkgRmFtaWx5OyBDb3VyaWVyLCBGdXR1cmEsIENlbnR1cnkgU2No
b29sYm9vaywgIC4uDQo+ID4gVHlwZWZhY2U7IG9uZSBvZiB0aGUgYWJvdmUgd2l0aCBhIGRlZmlu
ZWQNCj4gPiAgIC0gU3R5bGU6IFJvbWFuLCBJdGFsaWMNCj4gPiAgIC0gV2VpZ2h0OiBMaWdodCwg
U2VtaWJvbGQsIEJvbGQsIC4uLg0KPiA+ICAgLSBXaWR0aDogVWx0cmFjb25kZW5zZWQsIENvbmRl
bnNlZCwgRXhwYW5kZWQsIC4uLg0KPiA+IFR5cGUgRm9udDsgb25lIG9mIHRoZSBhYm92ZSB3aXRo
IGEgZGVmaW5lZCBTaXplDQo+ID4gICAtIGVnIDEyLXBvaW50DQo+DQo+IEFzIEkgc2FpZCBiZWZv
cmUgaW4gYSBtYWlsIHRvIERhdmUsIHRoZSBsYXN0IHBvaW50IHdvcmtlZCB3ZWxsIGZvciANCj4g
bGVhZCB0eXBlIG9yIGJpdG1hcCBmb250cywgYnV0IHRlY2hub2xvZ3kgaGFzIG1vdmVkIGJleW9u
ZC4NCg0KTWFydGluDQoNClRoZSBjb25jZXB0cyBoYXZlIG5vdCBjaGFuZ2VkIGFuZCByZW1haW4g
dXNlZnVsLCBJTU8sIGluIGFueSBkaXNjdXNzaW9uIG9uIHByZXNlbnRhdGlvbi4gIFdoYXQgaGFz
IGNoYW5nZWQgaXMgdGhlIGltcGxlbWVudGF0aW9uIGRldGFpbCBzbyB3aGVuIEkgZG93bmxvYWQg
YSBuZXcgcGFja2FnZSB0byBteSBQQywgdGhlbiBpdCB3aWxsIGFwcGx5IHRvIGFsbCBGb250cywg
d2l0aGluIGEgVHlwZWZhY2UsIGFzIG9wcG9zZWQgdG8gaGF2aW5nIGEgc2VwYXJhdGUgbW9kdWxl
IGZvciBlYWNoIEZvbnQuDQooSW5jaWRlbnRhbGx5LCBteSBiaWJsZXMgYWxsIHJlbGF0ZSB0byBs
YXNlciBwcmludGluZyBpZSB0byBtb2Rlcm4gdGVjaG5vbG9neSBhbmQgaGF2ZSBub3RoaW5nIHRv
IGRvIHdpdGggbGVhZDotKS4NCg0KQnV0IG1vcmUgc2lnbmlmaWNhbnRseSwgYXMgb3RoZXIgcG9z
dHMgaGF2ZSBjbGFyaWZpZWQgZm9yIG1lLCB0aGlzIHRocmVhZCBpcyBub3RoaW5nIHRvIGRvIHdp
dGggZm9udHMgYnV0IHdpdGggdHlwZSBkZWZpbml0aW9uIGxhbmd1YWdlcywgc28gcGVyaGFwcyBp
dCBzaG91bGQgYmUgJ3R5cGUvKicuDQoNClRvbSBQZXRjaA0KDQo+IFJlZ2FyZHMsICAgIE1hcnRp
bi4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFw
cHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg==

From stpeter@stpeter.im  Sat Nov 12 16:46:43 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0A221F8467 for ; Sat, 12 Nov 2011 16:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1agZyhzFakZg for ; Sat, 12 Nov 2011 16:46:42 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 93F6F21F8461 for ; Sat, 12 Nov 2011 16:46:42 -0800 (PST)
Received: from dhcp-13ac.meeting.ietf.org (unknown [130.129.19.172]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B468D404FF; Sat, 12 Nov 2011 17:52:47 -0700 (MST)
Message-ID: <4EBF136F.2080703@stpeter.im>
Date: Sun, 13 Nov 2011 08:46:39 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Barry Leiba 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <4EBD6266.6030307@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 00:46:43 -0000

On 11/12/11 6:20 AM, Barry Leiba wrote:
>> I see the document is on APPSAWG agenda on the meeting, so I anticipate it
>> will soon become APPSAWG item doc.  I won't be on meeting, but if you
>> discuss the adaptation of Webfinger draft please also take into account I'm
>> in favor of such adaptation (consider this as my 2p).
>
> As the agenda says, some things are not verified... and, in
> particular, this item is likely to be removed.  The chairs might
> mention it in the meeting, but discussion of the document will be on
> the mailing list.
>
> More importantly, your assumption that a document's getting meeting
> time implies that it "will soon become [a working group] doc" is very
> much wrong.  Having it on the meeting agenda simply means that the
> chairs think there will be some benefit to the working group process
> to have a chance to talk about it face to face.  We still would need
> to see enough interest in it, before the working group would accept
> it.
>
> Until now, there's been no interest expressed.  Thanks, Mykyta, for
> weighing in.  Others should also, please, comment here and let the
> working group and the document authors know whether you think this is
> something we (and they -- possibly separate points) should pursue.



I think that documentation of the webfinger protocol would be a good 
thing, given that it's somewhat widely used on the web. I do not have a 
strong opinion about whether it is needful for the APPSAWG to take on 
this work.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From tony@att.com  Sat Nov 12 16:57:15 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E103211E8082 for ; Sat, 12 Nov 2011 16:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.216
X-Spam-Level: 
X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 rlmV1meWM-gr for ; Sat, 12 Nov 2011 16:57:14 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id B47D611E8083 for ; Sat, 12 Nov 2011 16:57:14 -0800 (PST)
X-Env-Sender: tony@att.com
X-Msg-Ref: server-14.tower-119.messagelabs.com!1321145832!830033!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14944 invoked from network); 13 Nov 2011 00:57:12 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-14.tower-119.messagelabs.com with AES256-SHA encrypted SMTP; 13 Nov 2011 00:57:12 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAD0veoH031673 for ; Sat, 12 Nov 2011 19:57:40 -0500
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAD0va7L031629 for ; Sat, 12 Nov 2011 19:57:36 -0500
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pAD0v8Sn029051 for ; Sat, 12 Nov 2011 19:57:08 -0500
Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pAD0v23H028731 for ; Sat, 12 Nov 2011 19:57:03 -0500
Received: from [135.70.66.34] (vpn-135-70-66-34.vpn.swst.att.com[135.70.66.34]) by maillennium.att.com (mailgw1) with ESMTP id <20111113005607gw100e4l76e> (Authid: tony); Sun, 13 Nov 2011 00:56:07 +0000
X-Originating-IP: [135.70.66.34]
Message-ID: <4EBF15DD.4050801@att.com>
Date: Sat, 12 Nov 2011 19:57:01 -0500
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>	<60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>	<4EB9D49C.5010100@it.aoyama.ac.jp><4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net> <4EBBABC1.1010101@it.aoyama.ac.jp> <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net>
In-Reply-To: <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 00:57:16 -0000

On 11/12/2011 6:27 AM, t.petch wrote:
> ----- Original Message -----
> From: "Martin J. D=C3=BCrst"
> To: "t.petch"
> Cc:;
> Sent: Thursday, November 10, 2011 11:47 AM
>
>
>> On 2011/11/10 18:06, t.petch wrote:
>>> Dave
>>>
>>> My bibles say
>>>
>>> Type(face) Family; Courier, Futura, Century Schoolbook,  ..
>>> Typeface; one of the above with a defined
>>>    - Style: Roman, Italic
>>>    - Weight: Light, Semibold, Bold, ...
>>>    - Width: Ultracondensed, Condensed, Expanded, ...
>>> Type Font; one of the above with a defined Size
>>>    - eg 12-point
>> As I said before in a mail to Dave, the last point worked well for lea=
d
>> type or bitmap fonts, but technology has moved beyond.
> Martin
>
> The concepts have not changed and remain useful, IMO, in any discussion=

> on presentation.  What has changed is the implementation detail so when=

> I download a new package to my PC, then it will apply to all Fonts, wit=
hin
> a Typeface, as opposed to having a separate module for each Font.
> (Incidentally, my bibles all relate to laser printing ie to modern tech=
nology
> and have nothing to do with lead:-).
>
> But more significantly, as other posts have clarified for me, this thre=
ad
> is nothing to do with fonts but with type definition languages, so perh=
aps
> it should be 'type/*'.

I've seen several hints of wanting to do web Accept-style queries along=20
the line of

     Accept: font/arial, font/comicsans

What is it that is really desired?

While this sounds like it might be a nice capability, it really doesn't=20
agree with what media types are all about. The Arial font can be=20
described in many different font file formats.

Media types are more for describing things like:
     MMMM/datafork-truetype
     MMMM/intellifont
     MMMM/postscriptfont
     MMMM/truedocfont
     MMMM/truetype
     MMMM/webopenfont

(where MMMM is some prefix yet to be determined), within which you can=20
have a description of many different fonts, including Arial and ComicSans=
=2E

=3D=3D=3D=3D=3D=3D=3D

*IF* we were to define a top-level media type, I do *not* think it=20
should be named "font", but instead should name it "fontformat" or=20
something like that. I think naming it "font" just leads people to have=20
false expectations.

=3D=3D=3D=3D=3D=3D=3D

I notice that if "application" were used for font format file names,=20
some of the font format names would need to include the word "font" as=20
part of the name. For example, "application/postscript" can not be used=20
for the font format defined in the postscript standard. Instead, it=20
would have to be "application/postscriptfont". This *could* be taken an=20
argument for using "fontformat" as a top level type, as in=20
"fontformat/postscript". However, I don't find it a convincing argument=20
by itself.

     Tony Hansen


From wwwrun@rfc-editor.org  Sat Nov 12 22:16:49 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8C121F8485; Sat, 12 Nov 2011 22:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.513
X-Spam-Level: 
X-Spam-Status: No, score=-104.513 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, 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 3eZWdec2UO9X; Sat, 12 Nov 2011 22:16:48 -0800 (PST)
Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id D332121F8482; Sat, 12 Nov 2011 22:16:48 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 2C691B1E007; Sat, 12 Nov 2011 22:11:47 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20111113061147.2C691B1E007@rfc-editor.org>
Date: Sat, 12 Nov 2011 22:11:47 -0800 (PST)
Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org
Subject: [apps-discuss] RFC 6452 on The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 06:16:49 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6452

        Title:      The Unicode Code Points and 
                    Internationalized Domain Names for Applications (IDNA) 
                    - Unicode 6.0 
        Author:     P. Faltstrom, Ed.,
                    P. Hoffman, Ed.
        Status:     Standards Track
        Stream:     IETF
        Date:       November 2011
        Mailbox:    paf@cisco.com, 
                    paul.hoffman@vpnc.org
        Pages:      4
        Characters: 6817
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-faltstrom-5892bis-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6452.txt

This memo documents IETF consensus for Internationalized Domain Names
for Applications (IDNA) derived character properties related to the
three code points, existing in Unicode 5.2, that changed property
values when version 6.0 was released.  The consensus is that no
update is needed to RFC 5892 based on the changes made in Unicode
6.0.  [STANDARDS-TRACK]

This document is a product of the Applications Area Working Group Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From julian.reschke@gmx.de  Sun Nov 13 02:11:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F83F21F8B56 for ; Sun, 13 Nov 2011 02:11:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.388
X-Spam-Level: 
X-Spam-Status: No, score=-104.388 tagged_above=-999 required=5 tests=[AWL=-1.789, 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 8Ck9+yowWR2c for ; Sun, 13 Nov 2011 02:11:31 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 486D521F8B49 for ; Sun, 13 Nov 2011 02:11:30 -0800 (PST)
Received: (qmail invoked by alias); 13 Nov 2011 10:11:30 -0000
Received: from p5DCCAC94.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.172.148] by mail.gmx.net (mp014) with SMTP; 13 Nov 2011 11:11:30 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+CpRJkWbeCKd94JrmzxVoLACsf9GlzzpcPMDYsQ/ z7HuKhGadc+dkl
Message-ID: <4EBF97CF.6030204@gmx.de>
Date: Sun, 13 Nov 2011 11:11:27 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Tony Hansen 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>	<60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>	<4EB9D49C.5010100@it.aoyama.ac.jp><4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net> <4EBBABC1.1010101@it.aoyama.ac.jp> <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net> <4EBF15DD.4050801@att.com>
In-Reply-To: <4EBF15DD.4050801@att.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 10:11:32 -0000

On 2011-11-13 01:57, Tony Hansen wrote:
> ...
> *IF* we were to define a top-level media type, I do *not* think it
> should be named "font", but instead should name it "fontformat" or
> something like that. I think naming it "font" just leads people to have
> false expectations.
> ...

Doesn't this also argue for "imageformat" and "videoformat"?

Best regards, Julian

From tianlinyi@huawei.com  Sun Nov 13 04:03:21 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC66C21F8B98 for ; Sun, 13 Nov 2011 04:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.749
X-Spam-Level: **
X-Spam-Status: No, score=2.749 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 djmlmLKKWR7j for ; Sun, 13 Nov 2011 04:03:21 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D44D721F8B90 for ; Sun, 13 Nov 2011 04:03:20 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUL008TULHJNN@szxga05-in.huawei.com> for apps-discuss@ietf.org; Sun, 13 Nov 2011 20:03:19 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUL0020WLHIAT@szxga05-in.huawei.com> for apps-discuss@ietf.org; Sun, 13 Nov 2011 20:03:19 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEY53494; Sun, 13 Nov 2011 20:02:39 +0800
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 13 Nov 2011 20:02:38 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Sun, 13 Nov 2011 20:02:29 +0800
Date: Sun, 13 Nov 2011 12:02:27 +0000
From: TianLinyi 
In-reply-to: <4EBF15DD.4050801@att.com>
X-Originating-IP: [172.24.2.41]
To: Tony Hansen , "apps-discuss@ietf.org" 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA181FF7DB@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [apps-discuss] font/*
Thread-index: AQHMoS4cofDqxFROr0KXII3D5pJmlpWpddWAgAE/iUw=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net> <4EBBABC1.1010101@it.aoyama.ac.jp> <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net> <4EBF15DD.4050801@att.com>
Subject: [apps-discuss] =?gb2312?b?tPC4tDogIGZvbnQvKg==?=
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 12:03:22 -0000

d2h5IG5vdCBkZWZpbmUgc29tZXRoaW5nIGxpa2UgdGhpczoNCmFwcGxpY2F0aW9uL2ZvbnRmb3Jt
YXQtYXJpYWwNCg0KZGVmaW5lIGEgdG9wIGxldmVsIHR5cGUgbWF5IG5vdCBiZSBuZWVkZWQNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGFwcHMtZGlz
Y3Vzcy1ib3VuY2VzQGlldGYub3JnIFthcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gtPqx
7SBUb255IEhhbnNlbiBbdG9ueUBhdHQuY29tXQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MIxM8jVIDg6
NTcNCrW9OiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbYXBwcy1kaXNjdXNzXSBm
b250LyoNCg0KT24gMTEvMTIvMjAxMSA2OjI3IEFNLCB0LnBldGNoIHdyb3RlOg0KPiAtLS0tLSBP
cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJNYXJ0aW4gSi4gRKi5cnN0IjxkdWVyc3RA
aXQuYW95YW1hLmFjLmpwPg0KPiBUbzogInQucGV0Y2giPGlldGZjQGJ0Y29ubmVjdC5jb20+DQo+
IENjOjxkY3JvY2tlckBiYml3Lm5ldD47PGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4NCj4gU2VudDog
VGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDExIDExOjQ3IEFNDQo+DQo+DQo+PiBPbiAyMDExLzEx
LzEwIDE4OjA2LCB0LnBldGNoIHdyb3RlOg0KPj4+IERhdmUNCj4+Pg0KPj4+IE15IGJpYmxlcyBz
YXkNCj4+Pg0KPj4+IFR5cGUoZmFjZSkgRmFtaWx5OyBDb3VyaWVyLCBGdXR1cmEsIENlbnR1cnkg
U2Nob29sYm9vaywgIC4uDQo+Pj4gVHlwZWZhY2U7IG9uZSBvZiB0aGUgYWJvdmUgd2l0aCBhIGRl
ZmluZWQNCj4+PiAgICAtIFN0eWxlOiBSb21hbiwgSXRhbGljDQo+Pj4gICAgLSBXZWlnaHQ6IExp
Z2h0LCBTZW1pYm9sZCwgQm9sZCwgLi4uDQo+Pj4gICAgLSBXaWR0aDogVWx0cmFjb25kZW5zZWQs
IENvbmRlbnNlZCwgRXhwYW5kZWQsIC4uLg0KPj4+IFR5cGUgRm9udDsgb25lIG9mIHRoZSBhYm92
ZSB3aXRoIGEgZGVmaW5lZCBTaXplDQo+Pj4gICAgLSBlZyAxMi1wb2ludA0KPj4gQXMgSSBzYWlk
IGJlZm9yZSBpbiBhIG1haWwgdG8gRGF2ZSwgdGhlIGxhc3QgcG9pbnQgd29ya2VkIHdlbGwgZm9y
IGxlYWQNCj4+IHR5cGUgb3IgYml0bWFwIGZvbnRzLCBidXQgdGVjaG5vbG9neSBoYXMgbW92ZWQg
YmV5b25kLg0KPiBNYXJ0aW4NCj4NCj4gVGhlIGNvbmNlcHRzIGhhdmUgbm90IGNoYW5nZWQgYW5k
IHJlbWFpbiB1c2VmdWwsIElNTywgaW4gYW55IGRpc2N1c3Npb24NCj4gb24gcHJlc2VudGF0aW9u
LiAgV2hhdCBoYXMgY2hhbmdlZCBpcyB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlsIHNvIHdoZW4N
Cj4gSSBkb3dubG9hZCBhIG5ldyBwYWNrYWdlIHRvIG15IFBDLCB0aGVuIGl0IHdpbGwgYXBwbHkg
dG8gYWxsIEZvbnRzLCB3aXRoaW4NCj4gYSBUeXBlZmFjZSwgYXMgb3Bwb3NlZCB0byBoYXZpbmcg
YSBzZXBhcmF0ZSBtb2R1bGUgZm9yIGVhY2ggRm9udC4NCj4gKEluY2lkZW50YWxseSwgbXkgYmli
bGVzIGFsbCByZWxhdGUgdG8gbGFzZXIgcHJpbnRpbmcgaWUgdG8gbW9kZXJuIHRlY2hub2xvZ3kN
Cj4gYW5kIGhhdmUgbm90aGluZyB0byBkbyB3aXRoIGxlYWQ6LSkuDQo+DQo+IEJ1dCBtb3JlIHNp
Z25pZmljYW50bHksIGFzIG90aGVyIHBvc3RzIGhhdmUgY2xhcmlmaWVkIGZvciBtZSwgdGhpcyB0
aHJlYWQNCj4gaXMgbm90aGluZyB0byBkbyB3aXRoIGZvbnRzIGJ1dCB3aXRoIHR5cGUgZGVmaW5p
dGlvbiBsYW5ndWFnZXMsIHNvIHBlcmhhcHMNCj4gaXQgc2hvdWxkIGJlICd0eXBlLyonLg0KDQpJ
J3ZlIHNlZW4gc2V2ZXJhbCBoaW50cyBvZiB3YW50aW5nIHRvIGRvIHdlYiBBY2NlcHQtc3R5bGUg
cXVlcmllcyBhbG9uZw0KdGhlIGxpbmUgb2YNCg0KICAgICBBY2NlcHQ6IGZvbnQvYXJpYWwsIGZv
bnQvY29taWNzYW5zDQoNCldoYXQgaXMgaXQgdGhhdCBpcyByZWFsbHkgZGVzaXJlZD8NCg0KV2hp
bGUgdGhpcyBzb3VuZHMgbGlrZSBpdCBtaWdodCBiZSBhIG5pY2UgY2FwYWJpbGl0eSwgaXQgcmVh
bGx5IGRvZXNuJ3QNCmFncmVlIHdpdGggd2hhdCBtZWRpYSB0eXBlcyBhcmUgYWxsIGFib3V0LiBU
aGUgQXJpYWwgZm9udCBjYW4gYmUNCmRlc2NyaWJlZCBpbiBtYW55IGRpZmZlcmVudCBmb250IGZp
bGUgZm9ybWF0cy4NCg0KTWVkaWEgdHlwZXMgYXJlIG1vcmUgZm9yIGRlc2NyaWJpbmcgdGhpbmdz
IGxpa2U6DQogICAgIE1NTU0vZGF0YWZvcmstdHJ1ZXR5cGUNCiAgICAgTU1NTS9pbnRlbGxpZm9u
dA0KICAgICBNTU1NL3Bvc3RzY3JpcHRmb250DQogICAgIE1NTU0vdHJ1ZWRvY2ZvbnQNCiAgICAg
TU1NTS90cnVldHlwZQ0KICAgICBNTU1NL3dlYm9wZW5mb250DQoNCih3aGVyZSBNTU1NIGlzIHNv
bWUgcHJlZml4IHlldCB0byBiZSBkZXRlcm1pbmVkKSwgd2l0aGluIHdoaWNoIHlvdSBjYW4NCmhh
dmUgYSBkZXNjcmlwdGlvbiBvZiBtYW55IGRpZmZlcmVudCBmb250cywgaW5jbHVkaW5nIEFyaWFs
IGFuZCBDb21pY1NhbnMuDQoNCj09PT09PT0NCg0KKklGKiB3ZSB3ZXJlIHRvIGRlZmluZSBhIHRv
cC1sZXZlbCBtZWRpYSB0eXBlLCBJIGRvICpub3QqIHRoaW5rIGl0DQpzaG91bGQgYmUgbmFtZWQg
ImZvbnQiLCBidXQgaW5zdGVhZCBzaG91bGQgbmFtZSBpdCAiZm9udGZvcm1hdCIgb3INCnNvbWV0
aGluZyBsaWtlIHRoYXQuIEkgdGhpbmsgbmFtaW5nIGl0ICJmb250IiBqdXN0IGxlYWRzIHBlb3Bs
ZSB0byBoYXZlDQpmYWxzZSBleHBlY3RhdGlvbnMuDQoNCj09PT09PT0NCg0KSSBub3RpY2UgdGhh
dCBpZiAiYXBwbGljYXRpb24iIHdlcmUgdXNlZCBmb3IgZm9udCBmb3JtYXQgZmlsZSBuYW1lcywN
CnNvbWUgb2YgdGhlIGZvbnQgZm9ybWF0IG5hbWVzIHdvdWxkIG5lZWQgdG8gaW5jbHVkZSB0aGUg
d29yZCAiZm9udCIgYXMNCnBhcnQgb2YgdGhlIG5hbWUuIEZvciBleGFtcGxlLCAiYXBwbGljYXRp
b24vcG9zdHNjcmlwdCIgY2FuIG5vdCBiZSB1c2VkDQpmb3IgdGhlIGZvbnQgZm9ybWF0IGRlZmlu
ZWQgaW4gdGhlIHBvc3RzY3JpcHQgc3RhbmRhcmQuIEluc3RlYWQsIGl0DQp3b3VsZCBoYXZlIHRv
IGJlICJhcHBsaWNhdGlvbi9wb3N0c2NyaXB0Zm9udCIuIFRoaXMgKmNvdWxkKiBiZSB0YWtlbiBh
bg0KYXJndW1lbnQgZm9yIHVzaW5nICJmb250Zm9ybWF0IiBhcyBhIHRvcCBsZXZlbCB0eXBlLCBh
cyBpbg0KImZvbnRmb3JtYXQvcG9zdHNjcmlwdCIuIEhvd2V2ZXIsIEkgZG9uJ3QgZmluZCBpdCBh
IGNvbnZpbmNpbmcgYXJndW1lbnQNCmJ5IGl0c2VsZi4NCg0KICAgICBUb255IEhhbnNlbg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXBwcy1kaXNj
dXNzIG1haWxpbmcgbGlzdA0KYXBwcy1kaXNjdXNzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0K

From tony@att.com  Sun Nov 13 06:30:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FBE21F87E2 for ; Sun, 13 Nov 2011 06:30:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.485
X-Spam-Level: 
X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, 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 eA3rAJe1dvBe for ; Sun, 13 Nov 2011 06:30:31 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4A721F85FF for ; Sun, 13 Nov 2011 06:30:31 -0800 (PST)
X-Env-Sender: tony@att.com
X-Msg-Ref: server-12.tower-119.messagelabs.com!1321194629!878414!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9021 invoked from network); 13 Nov 2011 14:30:29 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Nov 2011 14:30:29 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pADEUv8Y029466 for ; Sun, 13 Nov 2011 09:30:57 -0500
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pADEUqfG029376 for ; Sun, 13 Nov 2011 09:30:53 -0500
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pADEUOIn002664 for ; Sun, 13 Nov 2011 09:30:24 -0500
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pADEUKoF002443 for ; Sun, 13 Nov 2011 09:30:22 -0500
Received: from [135.70.107.72] (vpn-135-70-107-72.vpn.swst.att.com[135.70.107.72]) by maillennium.att.com (mailgw1) with ESMTP id <20111113142920gw100e4l7ge> (Authid: tony); Sun, 13 Nov 2011 14:29:25 +0000
X-Originating-IP: [135.70.107.72]
Message-ID: <4EBFD473.1080804@att.com>
Date: Sun, 13 Nov 2011 09:30:11 -0500
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>	<60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>	<4EB9D49C.5010100@it.aoyama.ac.jp><4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net> <4EBBABC1.1010101@it.aoyama.ac.jp> <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net> <4EBF15DD.4050801@att.com> <4EBF97CF.6030204@gmx.de>
In-Reply-To: <4EBF97CF.6030204@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 14:30:32 -0000

Certainly not. My argument is that "font" is a bad name because of its 
overloaded connotations -- I'm not arguing *for* any particular 
replacement for it. Any of "fontformat", "fontdl", and others would be 
better than just "font".

     Tony Hansen

On 11/13/2011 5:11 AM, Julian Reschke wrote:
> On 2011-11-13 01:57, Tony Hansen wrote:
>> ...
>> *IF* we were to define a top-level media type, I do *not* think it
>> should be named "font", but instead should name it "fontformat" or
>> something like that. I think naming it "font" just leads people to have
>> false expectations.
>> ...
>
> Doesn't this also argue for "imageformat" and "videoformat"?
>
> Best regards, Julian

From tony@att.com  Sun Nov 13 06:33:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90B221F8B40 for ; Sun, 13 Nov 2011 06:33:46 -0800 (PST)
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=-3.848, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, 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 8hjVTOjaI7mj for ; Sun, 13 Nov 2011 06:33:46 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 19FB321F8AE9 for ; Sun, 13 Nov 2011 06:33:39 -0800 (PST)
X-Env-Sender: tony@att.com
X-Msg-Ref: server-13.tower-120.messagelabs.com!1321194817!49128184!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22313 invoked from network); 13 Nov 2011 14:33:38 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Nov 2011 14:33:38 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pADEY5aS031123 for ; Sun, 13 Nov 2011 09:34:05 -0500
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pADEY19C031100 for ; Sun, 13 Nov 2011 09:34:02 -0500
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pADEXXuX008630 for ; Sun, 13 Nov 2011 09:33:33 -0500
Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pADEXTBs008504 for ; Sun, 13 Nov 2011 09:33:29 -0500
Received: from [135.70.107.72] (vpn-135-70-107-72.vpn.swst.att.com[135.70.107.72]) by maillennium.att.com (mailgw1) with ESMTP id <20111113143234gw100e4l7he> (Authid: tony); Sun, 13 Nov 2011 14:32:34 +0000
X-Originating-IP: [135.70.107.72]
Message-ID: <4EBFD537.9070005@att.com>
Date: Sun, 13 Nov 2011 09:33:27 -0500
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net> <4EBBABC1.1010101@it.aoyama.ac.jp> <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net> <4EBF15DD.4050801@att.com> <3615F3CCD55F054395A882F51C6E5FDA181FF7DB@szxeml513-mbx.china.huawei.com>
In-Reply-To: <3615F3CCD55F054395A882F51C6E5FDA181FF7DB@szxeml513-mbx.china.huawei.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] =?gb2312?b?tPC4tDogIGZvbnQvKg==?=
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 14:33:46 -0000

application/fontformat-truetype perhaps, but certainly not
application/fontformat-arial.The first is a media format, whereas the
latter mixes in a non-concrete look and feel.

Tony Hansen

On 11/13/2011 7:02 AM, TianLinyi wrote:
> why not define something like this:
> application/fontformat-arial
>
> define a top level type may not be needed
>
> _______________________________________
> =B7=A2=BC=FE=C8=CB: apps-discuss-bounces@ietf.org [apps-discuss-bounces=
@ietf.org] =B4=FA=B1=ED Tony Hansen [tony@att.com]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C213=C8=D5 8:57
> =B5=BD: apps-discuss@ietf.org
> =D6=F7=CC=E2: Re: [apps-discuss] font/*
>
> On 11/12/2011 6:27 AM, t.petch wrote:
>> ----- Original Message -----
>> From: "Martin J. D=A8=B9rst"
>> To: "t.petch"
>> Cc:;
>> Sent: Thursday, November 10, 2011 11:47 AM
>>
>>
>>> On 2011/11/10 18:06, t.petch wrote:
>>>> Dave
>>>>
>>>> My bibles say
>>>>
>>>> Type(face) Family; Courier, Futura, Century Schoolbook,  ..
>>>> Typeface; one of the above with a defined
>>>>    - Style: Roman, Italic
>>>>    - Weight: Light, Semibold, Bold, ...
>>>>    - Width: Ultracondensed, Condensed, Expanded, ...
>>>> Type Font; one of the above with a defined Size
>>>>    - eg 12-point
>>> As I said before in a mail to Dave, the last point worked well for le=
ad
>>> type or bitmap fonts, but technology has moved beyond.
>> Martin
>>
>> The concepts have not changed and remain useful, IMO, in any discussio=
n
>> on presentation.  What has changed is the implementation detail so whe=
n
>> I download a new package to my PC, then it will apply to all Fonts, wi=
thin
>> a Typeface, as opposed to having a separate module for each Font.
>> (Incidentally, my bibles all relate to laser printing ie to modern tec=
hnology
>> and have nothing to do with lead:-).
>>
>> But more significantly, as other posts have clarified for me, this thr=
ead
>> is nothing to do with fonts but with type definition languages, so per=
haps
>> it should be 'type/*'.
> I've seen several hints of wanting to do web Accept-style queries along=

> the line of
>
>      Accept: font/arial, font/comicsans
>
> What is it that is really desired?
>
> While this sounds like it might be a nice capability, it really doesn't=

> agree with what media types are all about. The Arial font can be
> described in many different font file formats.
>
> Media types are more for describing things like:
>      MMMM/datafork-truetype
>      MMMM/intellifont
>      MMMM/postscriptfont
>      MMMM/truedocfont
>      MMMM/truetype
>      MMMM/webopenfont
>
> (where MMMM is some prefix yet to be determined), within which you can
> have a description of many different fonts, including Arial and ComicSa=
ns.
>
> =3D=3D=3D=3D=3D=3D=3D
>
> *IF* we were to define a top-level media type, I do *not* think it
> should be named "font", but instead should name it "fontformat" or
> something like that. I think naming it "font" just leads people to have=

> false expectations.
>
> =3D=3D=3D=3D=3D=3D=3D
>
> I notice that if "application" were used for font format file names,
> some of the font format names would need to include the word "font" as
> part of the name. For example, "application/postscript" can not be used=

> for the font format defined in the postscript standard. Instead, it
> would have to be "application/postscriptfont". This *could* be taken an=

> argument for using "fontformat" as a top level type, as in
> "fontformat/postscript". However, I don't find it a convincing argument=

> by itself.
>
>      Tony Hansen
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From paulej@packetizer.com  Sun Nov 13 09:22:01 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E203421F84A0 for ; Sun, 13 Nov 2011 09:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level: 
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040,  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 vi9Lw0JLQMk4 for ; Sun, 13 Nov 2011 09:22:01 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF8C21F848A for ; Sun, 13 Nov 2011 09:22:01 -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 pADHLvUc012906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Nov 2011 12:21:58 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321204920; bh=BLiwcwlrbaLgH0Jqqhlzk+SvcYv+qAkOB+7aoxtgHeY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ke321g0Mfk6F5ltYEDTGX2eAtnt8bMI4wHocWOFo3rnjodQ7j7fithN1HvAORmgL6 i9eUzcxTCF7dhXczoICUFnx8/ptaK3/6AhPnH4HXDV/bVUe5ItDBTTFb47BJ6GyjW2 61XL4h+xDsiwj5U3eHx9Co/3CbrpvcpgcpFonTug=
From: "Paul E. Jones" 
To: "'Peter Saint-Andre'" , "'Barry Leiba'" 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>	<4EBD6266.6030307@gmail.com>	 <4EBF136F.2080703@stpeter.im>
In-Reply-To: <4EBF136F.2080703@stpeter.im>
Date: Sun, 13 Nov 2011 12:21:51 -0500
Message-ID: <013501cca228$bcaba9a0$3602fce0$@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: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQFe+7+KAQRuCq8B+4mldZSh2Z0A
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 17:22:02 -0000

Peter,

> I think that documentation of the webfinger protocol would be a good
> thing, given that it's somewhat widely used on the web. I do not have a
> strong opinion about whether it is needful for the APPSAWG to take on
> this work.

The main reason I see a need for the WG item is that we're proposing a new
URI scheme ("acct").  Presently, the text also recommends the use of CORS
and makes other normative statements.

I could be persuaded that "acct" should be pulled out into its own document,
since I can imagine the utility for it might be broader than Webfinger.  If
we did that, then perhaps there is less of an argument for it being a WG
item, but I'm not sure out the text would be progressed in that case.

In any case, I'll take input on the best way to go forward.  I don't care
how we get there, but I fully agree with you that it ought to be documented.

Paul



From nsb@guppylake.com  Sun Nov 13 10:05:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4621F8B28 for ; Sun, 13 Nov 2011 10:05:26 -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 BSn-tPu4FA9B for ; Sun, 13 Nov 2011 10:05:25 -0800 (PST)
Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id AD2BE21F8B27 for ; Sun, 13 Nov 2011 10:05:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=U8dSHkJMurl05HHtmmpqBCA6UBhXGEe5uB6Xgdy/eZ5hE0lJ6pGMXyrvfIPNo+G+e1mNG6jwUrM1+XiQxFGx5itqd74I6fqbpJOdMz4QVFYC63ef1f7/x5FzTyvdrjgd;
Received: from [108.98.149.133] (helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1RPeQd-00042h-NB; Sun, 13 Nov 2011 13:05:17 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-898--697071665
From: Nathaniel Borenstein 
In-Reply-To: 
Date: Sun, 13 Nov 2011 13:05:11 -0500
Message-Id: <0A2AA11A-0283-49F6-8B36-9DAF1F48C33D@guppylake.com>
References: 
To: Larry Masinter 
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server1.netnutz.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - guppylake.com
Cc: "gadams@xfsi.com" , "apps-discuss@ietf.org" , David Singer 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 18:05:26 -0000

--Apple-Mail-898--697071665
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 12, 2011, at 3:25 PM, Larry Masinter wrote:

> My conclusion from this discussion is that we should declare the MIME =
hierarchy closed to new top level types; we've only gotten very limited =
use and value out of the hierarchy, compared to the pain and difficulty =
(text/xml vs application/xml).

I strongly disagree.  I always expected such difficulties, but I believe =
a new top level type continues to make sense for certain relatively rare =
cases, and that "font" (or "fontformat" as per Tony's helpful =
suggestion) may well be one of them.  I think it would be imprudent to =
completely rule out any new types in the future, because I don't think =
we have any real idea what kinds of media human beings will some day =
invent.   I, at least, always saw "application" as a catch-all for =
things that didn't fit in any broader media buckets, not also as a =
catch-all for new possible new buckets.

But I also recognize that since there are few functional differences =
between "fontformat/xyz" and "application/font; format=3Dxyz" and any =
number of other alternatives, this question may not have a definitive =
engineering-level answer.  That's another reason I'd just as soon stick =
to a more intuitive human notion of top-level media-types:  it's the =
only level at which it *ever* made sense.  If it's clear to a random =
civilian why jpeg and gif are in the same category, then the 'image' =
TLMT makes at least some sense.

On Nov 13, 2011, at 5:11 AM, Julian Reschke wrote:

> Doesn't this also argue for "imageformat" and "videoformat"?

It probably would, if there had been anyone arguing for =
"image/cutebabies" or "image/dogsplayingpoker".  I think that people =
just more naturally assumed it was the format with "image," whereas =
there are two obvious ways to interpret "font" so a disambiguation might =
be helpful.  -- Nathaniel


--Apple-Mail-898--697071665
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


My conclusion =
from this discussion is that we should declare the MIME hierarchy closed =
to new top level types; we've only gotten very limited use and value out =
of the hierarchy, compared to the pain and difficulty (text/xml vs =
application/xml).

I strongly =
disagree.  I always expected such difficulties, but I believe a new =
top level type continues to make sense for certain relatively rare =
cases, and that "font" (or "fontformat" as per Tony's helpful =
suggestion) may well be one of them.  I think it would be imprudent =
to completely rule out any new types in the future, because I don't =
think we have any real idea what kinds of media human beings will some =
day invent.   I, at least, always saw "application" as a catch-all =
for things that didn't fit in any broader media buckets, not also as a =
catch-all for new possible new buckets.

But I =
also recognize that since there are few functional differences between =
"fontformat/xyz" and "application/font; format=3Dxyz" and any number of =
other alternatives, this question may not have a definitive =
engineering-level answer.  That's another reason I'd just as soon =
stick to a more intuitive human notion of top-level media-types: =
 it's the only level at which it *ever* made sense.  If it's =
clear to a random civilian why jpeg and gif are in the same category, =
then the 'image' TLMT makes at least some =
sense.

On Nov 13, 2011, at 5:11 AM, Julian =
Reschke wrote:

Doesn't =
this also argue for "imageformat" and =
"videoformat"?

It probably =
would, if there had been anyone arguing for "image/cutebabies" or =
"image/dogsplayingpoker".  I think that people just more naturally =
assumed it was the format with "image," whereas there are two obvious =
ways to interpret "font" so a disambiguation might be helpful.  -- =
Nathaniel

=

--Apple-Mail-898--697071665--

From nsb@guppylake.com  Sun Nov 13 10:06:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5292021F8B28 for ; Sun, 13 Nov 2011 10:06:28 -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 3GYGHA+c74NP for ; Sun, 13 Nov 2011 10:06:27 -0800 (PST)
Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 8C60A21F8B31 for ; Sun, 13 Nov 2011 10:06:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=gjDIVfZrpnxZQLtspuy3xWsfmxrNqJ2ksFVm4IYNY6podsTyPrLgpPAUSN6dytx7ezsyc+UOyJQdAEuuwhzGY2n1/r8jQvB5BsVOvk6qHByRl4N/cIrsDXI5shK7Z2Rv;
Received: from [108.98.149.133] (helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1RPeRk-00049p-Jk; Sun, 13 Nov 2011 13:06:25 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-900--697004606
From: Nathaniel Borenstein 
In-Reply-To: <4EBE2B02.8070500@ninebynine.org>
Date: Sun, 13 Nov 2011 13:06:18 -0500
Message-Id: 
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> <4EB9D46B.8010808@dcrocker.net> <4EBB2D1B.5010206@it.aoyama.ac.jp> <4EBE2B02.8070500@ninebynine.org>
To: Graham Klyne 
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server1.netnutz.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - guppylake.com
Cc: dcrocker@bbiw.net, "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 18:06:28 -0000

--Apple-Mail-900--697004606
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 12, 2011, at 3:14 AM, Graham Klyne wrote:

> Interestingly, model/* has been mentioned in discussion as an example. =
 With increasing use of personal 3D printing (cf. http://reprap.organd =
spinout projects), I think it's a top-level type who's time is coming.  =
(I've even wondered about an update for RFC 1437...)

IANA already has 14 subtypes of model registered, so it's time may =
already be here.  But as one of the authors I agree that RFC 1437 is =
getting a bit long in the tooth.  (There are now so many better examples =
than Dan Quayle!)  Perhaps I can get a revision together over the next, =
I don't know, 4 1/2 months....

> Of course, it all hinges on why we have top-level types at all.  From, =
a purely taxonomical perspective, I think a strictly 2-level hierarchy =
is always going to call for some arbitrary choices.

Absolutely.  I always viewed it as a pragmatic compromise between a flat =
namespace and an unbounded tree.  There were good reasons not to want =
either of those, while everyone seemed able to live with the two-level =
system, albeit while endlessly bickering over the details. -- Nathaniel=

--Apple-Mail-900--697004606
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


 http://reprap.organd spinout projects), =
I think it's a top-level type who's time is coming.  (I've even =
wondered about an update for RFC =
1437...)

IANA already has 14 =
subtypes of model registered, so it's time may already be here. =
 But as one of the authors I agree that RFC 1437 is getting a bit =
long in the tooth.  (There are now so many better examples than Dan =
Quayle!)  Perhaps I can get a revision together over the next, I =
don't know, 4 1/2 months....

Of course, it =
all hinges on why we have top-level types at all.  From, a purely =
taxonomical perspective, I think a strictly 2-level hierarchy is always =
going to call for some arbitrary =
choices.

Absolutely.  I =
always viewed it as a pragmatic compromise between a flat namespace and =
an unbounded tree.  There were good reasons not to want either of =
those, while everyone seemed able to live with the two-level system, =
albeit while endlessly bickering over the details. -- =
Nathaniel
=

--Apple-Mail-900--697004606--

From eburger@standardstrack.com  Sun Nov 13 10:06:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A8721F8548 for ; Sun, 13 Nov 2011 10:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.338
X-Spam-Level: 
X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 J16V+JCPr5aA for ; Sun, 13 Nov 2011 10:06:58 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 38B4221F861E for ; Sun, 13 Nov 2011 10:06:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com;  h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=k7X+T5MwnpGTPAspzUVyR/wkVv/7l1np7jWztph+eT+/D60ZNVQlCmp842rcoVX0GH1zPntnuZJo+6Uj4AYOmvdmuRAW11wC/4+88cf+8yEPh258pAV/36iLKaDqIEQK;
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:58031 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RPeS3-0003ci-Mn for apps-discuss@ietf.org; Sun, 13 Nov 2011 10:06:44 -0800
From: Eric Burger 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-166--696982848; protocol="application/pkcs7-signature"; micalg=sha1
Date: Sun, 13 Nov 2011 13:06:40 -0500
In-Reply-To: 
To: "apps-discuss@ietf.org Discuss" 
References: 
Message-Id: <8D5D1E18-FA41-475E-9570-46B9739741E3@standardstrack.com>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 18:06:59 -0000

--Apple-Mail-166--696982848
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Shockingly, +1

On Nov 12, 2011, at 3:25 PM, Larry Masinter wrote:

> I see no use case for why having font/opentype is any better than =
application/opentype
>=20
> The only use case I can imagine from looking at
> http://tools.ietf.org/html/draft-singer-font-mime-00
> is the possibility of defining common parameters across font data =
types (in the same way that text/.. has a common charset parameter).
>=20
> But there isn't really any common processing proposed that one could =
do knowing that you have font/x... so I agree with Graham that there =
isn't a case for font/.
>=20
>=20
>=20
> The arguments in favor seem to be of the form "well, we allow for new =
top level types, so why not use it?"
>=20
> I also recall a number of years ago an attempt to define "chemical/*" =
as a new top level type for use in defining file formats?
>=20
> My conclusion from this discussion is that we should declare the MIME =
hierarchy closed to new top level types; we've only gotten very limited =
use and value out of the hierarchy, compared to the pain and difficulty =
(text/xml vs application/xml).
>=20
> To be specific: in =
http://tools.ietf.org/html/draft-freed-media-type-regs
> I would propose changing=20
>=20
> OLD:
>   In some cases a new media type may not "fit" under any currently
>   defined top-level content type.  Such cases are expected to be quite
>   rare.  However, if such a case does arise a new top-level type can =
be
>   defined to accommodate it.  Such a definition MUST be done via
>   standards-track RFC; no other mechanism can be used to define
>   additional top-level content types.
>=20
> NEW:
>=20
>   Originally, it was believed that there might be rare cases where new =
media types might not "fit" under the currently defined top level types. =
However, the benefit of introducing a new top level type is likely to be =
low compared to the additional cost and confusion.  While a new =
top-level type can be defined by a standards-track RFC, it is likely =
that additional applications can be satisfied by using the =
"application/" top-level type.
>=20
>=20
> (Additional comments on draft-freed-media-type-regs in =
http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html )
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of t.petch
> Sent: Saturday, November 12, 2011 3:28 AM
> To: Martin J. D=FCrst
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] font/*
>=20
> ----- Original Message -----
> From: "Martin J. D=FCrst" 
> To: "t.petch" 
> Cc: ; 
> Sent: Thursday, November 10, 2011 11:47 AM
>=20
>=20
>> On 2011/11/10 18:06, t.petch wrote:
>>> Dave
>>>=20
>>> My bibles say
>>>=20
>>> Type(face) Family; Courier, Futura, Century Schoolbook,  ..
>>> Typeface; one of the above with a defined
>>>  - Style: Roman, Italic
>>>  - Weight: Light, Semibold, Bold, ...
>>>  - Width: Ultracondensed, Condensed, Expanded, ...
>>> Type Font; one of the above with a defined Size
>>>  - eg 12-point
>>=20
>> As I said before in a mail to Dave, the last point worked well for=20
>> lead type or bitmap fonts, but technology has moved beyond.
>=20
> Martin
>=20
> The concepts have not changed and remain useful, IMO, in any =
discussion on presentation.  What has changed is the implementation =
detail so when I download a new package to my PC, then it will apply to =
all Fonts, within a Typeface, as opposed to having a separate module for =
each Font.
> (Incidentally, my bibles all relate to laser printing ie to modern =
technology and have nothing to do with lead:-).
>=20
> But more significantly, as other posts have clarified for me, this =
thread is nothing to do with fonts but with type definition languages, =
so perhaps it should be 'type/*'.
>=20
> Tom Petch
>=20
>> Regards,    Martin.
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail-166--696982848
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w
ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR
Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w
NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx
FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx
ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz
dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx
B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8
om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG
TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl
yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j
BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j
b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu
Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw
DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8
NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s
APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK
N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU
TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD
AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU
IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw
MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD
VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9
VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD
jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS
TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy
fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B
AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU
ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw
EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0
LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG
AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy
dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN
BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu
PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i
kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq
szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L
SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC
AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E
TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI
hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T
aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ
9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX
56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0
FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud
IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC
mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB
BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw
KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK
oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k
U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny
dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi
dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp
KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R
nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P
e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0
okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A
JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM
aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMTEzMTgwNjQxWjAjBgkqhkiG9w0BCQQxFgQU
YtiXd34gFjoyygPzpKhHCPhm3QIwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug
gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT
B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw
DQYJKoZIhvcNAQEBBQAEggEAPdktp+HwUt4TddzyDq86WbzUccoq8QDo4dhoVUzJasaFrkp1KHWZ
WdpRstpaXyJ7he6fI/GTk14s47MO2vZk4jDy32SUQazdQpHPDyNi/JrezMJVAvGspn/2//54F0Om
8Zc6KiqdxEXDWPpHVwxZxqz4Fb906gZH+2PayJ9x55w2RTA5+ztLa9zPg60AKPlEyUnKlfHC7eJE
FfPDjN6guNbx2vOClqBwZjUW2Z5aufBdtmX34876yfqs6wa3bz1+BN34BdsQ6LFYsUpRik+daFec
3J/1NsPITlSzQuLbAPAvOQhRbN6HYOES2+QaDJYjftJbvfssrb76mppN0dTI+gAAAAAAAA==

--Apple-Mail-166--696982848--

From paulej@packetizer.com  Sun Nov 13 10:31:37 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B969221F8B31 for ; Sun, 13 Nov 2011 10:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.414
X-Spam-Level: 
X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 gVqOLEXVPJat for ; Sun, 13 Nov 2011 10:31:36 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE6D21F8B0E for ; Sun, 13 Nov 2011 10:31:35 -0800 (PST)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pADIVZJt014885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Nov 2011 13:31:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321209096; bh=v3xOLa7Ndawr70x42Et5VsRyoon5ucqFurcouDclUi8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=i/OQ66fqIi5njePJt3uuBbsut+A3oYeLWxNja+333g2JrM4G5uJZWiyEv4qRj1oSD FxTtmRpsWFPK6NpTlxXuC5AFJDIARR8IHYer6E5qjxi+zAFIQj+YzkVqfAVTH1XJTb HmOP1qRaPT0R83bG7JHCiHYxZ7jAzIe1Xail+FFM=
From: "Paul E. Jones" 
To: =?UTF-8?B?JyJNeWt5dGEgWWV2c3RpZmV5ZXYgKNCcLiDQhNCy0YHRgtGW0YTQtQ==?= =?UTF-8?B?0ZTQsikiJw==?= 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <4EBD6266.6030307@gmail.com> <023801cca0ca$d9860a20$8c921e60$@packetizer.com> <4EBE04C7.5090400@gmail.com>
In-Reply-To: <4EBE04C7.5090400@gmail.com>
Date: Sun, 13 Nov 2011 13:31:28 -0500
Message-ID: <015301cca232$75ea36d0$61bea470$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0154_01CCA208.8D169FD0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQFe+7+KAmEa8QsCfngenZSS74Tg
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 18:31:37 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0154_01CCA208.8D169FD0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Mykyta,

=20

I fear this might get complicated with references to the email =
documents.  Those documents are trying to solve a real problem, but =
Webfinger does not have some of those historical constraints.

=20

Here=E2=80=99s my proposal: let=E2=80=99s not reference 5335 or 5322.  =
Rather, let=E2=80=99s only reference the generic URI syntax spec (RFC =
3986).  Let=E2=80=99s define the URI scheme using the syntax found =
there:

   acctURI   =3D "acct:" userinfo "@" host

=20

The productions =E2=80=9Cuserinfo=E2=80=9D and =E2=80=9Chost=E2=80=9D =
are already defined.  Perhaps the one thing I don=E2=80=99t like is that =
=E2=80=9Chost=E2=80=9D might be an IP address, but perhaps some people =
prefer that.

=20

RFC 3986 already says that these components are UTF-8 encoded and then =
percent-escaped when a character is outside the ASCII character set =
range.

=20

Would this be a suitable replacement for the current text?

=20

With respect to your comments on link relations and URIs, I still do not =
understand.  You say that =E2=80=9Cnobody will benefit from link =
relation types defined by URIs=E2=80=9D, but why not?  There are several =
already define and used today.  In any case, I would prefer that all =
link relation values (URI or simple strings) be defined outside of the =
Webfinger draft.  As I mentioned, there is already a registry, so one =
can be proposed any time.

=20

Paul

=20

From: "Mykyta Yevstifeyev (=D0=9C. =
=D0=84=D0=B2=D1=81=D1=82=D1=96=D1=84=D0=B5=D1=94=D0=B2)" =
[mailto:evnikita2@gmail.com]=20
Sent: Saturday, November 12, 2011 12:32 AM
To: Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger

=20

Hello Paul,

12.11.2011 1:37, Paul E. Jones wrote:=20

Mykyta,

=20

Thanks for your positive response.

=20

To your specific questions=E2=80=A6

=20

We would definitely want to ensure that Unicode is properly supported.  =
In wasn=E2=80=99t aware of RFC 5335, so I=E2=80=99m glad you brought =
that to my attention.  Do you have a pointer to the bis draft so I can =
see exactly what is there?  I=E2=80=99d be fully in favor of using =
utf8-addr-spec.


This is http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13.  But =
please note that this document, unlike RFC 5335, introduced UTF-8 =
additions to *base* RFC 5322 productions.  This means that  =
will be defined as follows now:




   addr-spec       =3D   local-part "@" domain
   local-part      =3D   dot-atom / quoted-string / obs-local-part
   domain          =3D   dot-atom / domain-literal / obs-domain
   domain-literal  =3D   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
   dtext           =3D   %d33-90 /          ; Printable US-ASCII
                       %d94-126 /         ;  characters not including
                       obs-dtext          ;  "[", "]", or "\"=20
   dtext           =3D/  UTF8-non-ascii     ; from 5335bis  =20
   dot-atom        =3D   [CFWS] dot-atom-text [CFWS]  =20
   dot-atom-text   =3D   1*atext *("." 1*atext)   =20
   atext           =3D/  UTF8-non-ascii     ; from 5335bis


So everything you will have to do is to have a note on 'acct' RI being =
possible to carry UTF8 characters and therefore being possibly IRIs.




=20

Link relation types might be names like =E2=80=9Ccopyright=E2=80=9D or =
they might be URIs.  The definition of the link relation types is =
outside the scope of the Webfinger document itself.  RFC 6415 defines =
the structure of the documents and provides examples of some link =
relations and the order of processing.  RFC 5988 defines the link =
relations more generically and establishes the registry for them.  Do =
you think we need to say more about link relations beyond what those =
documents cover?


I mean that Webfinger will have to operate on a variety of link =
relations in LRDD documents, and nobody will benefit from link relation =
types defined by URIs used there, as this eliminates the possibility for =
automatic processing.  So I ask whether we'll have to define non-URI =
link relation types for all the possible Webfinger use-cases?




=20

On section 4: noted.  We=E2=80=99ll try to clearly separate the =
normative and non-normative pieces better.


Thanks.




=20

On  CORS, there are some who have strongly advocated for it.  It would =
be very useful to allow JavaScript code to perform these queries.  =
Otherwise, the queries would have to be pushed to server-side code.  =
Let=E2=80=99s wait on deciding what to do until we get a definitive =
answer on CORS from the W3C.  I think Peter was going to do some =
investigating there.

=20

Putting Webfinger into vcard: isn=E2=80=99t that circular?  The idea =
with Webfinger is that you have the identity of the user (e.g., =
paulej@packetizer.com), but you want to find more information.  If you =
have a vcard, then you have the user=E2=80=99s identity (via the email =
tag).  Or are you suggesting that we formally introduce the acct URI in =
vcard?  That might make sense to do.  Can you clarify your proposal?


>From RFC 6350, Section 6.4.2:




6.4.2. EMAIL

   Purpose:  To specify the electronic mail address for communication
      with the object the vCard represents.


...and the use might have email address different from Webfinger ID.  =
I've already pointed to =
http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00, which =
VCARDDAV WG works on, and so you may try to introduce some similar =
property for Webfinger IDs.  (You see, vCards may not carry all the =
variety of information, though some people actually think in other way, =
and thus it would be a good idea to provide a means of accessing some =
additional info.)




=20

For comments on particular sections, I=E2=80=99ve added notes to each =
one to revise them as you suggest: they=E2=80=99re all good suggestions.


Yes, thanks as well.




=20

I would very much like to make this a WG item, of course, but none of =
the authors will be present at this IETF meeting.  Perhaps hallway =
dialog might take place, but not sure.  In any case, we can do this via =
the mailing list, too.


See Barry's note on this.




=20

Thanks!

Paul


All the best,
Mykyta Yevstifeyev




=20

From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of "Mykyta Yevstifeyev =
(?. ?????????)"
Sent: Friday, November 11, 2011 12:59 PM
To: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger

=20

Hi Paul and all,

I think you contributed a very interesting proposal indeed.  Really, RFC =
1288 finger protocol is now outdated, and you're right claiming that it =
provides no means of automatic processing.  BTW, RFC 1288 is currently =
at Draft Standard maturity level, which has been abandoned by RFC 6410, =
and we should therefore undertake something with this respect, as should =
we with respect of other Apps-related DSs, but that is what is to be =
discussed separately.

With respect to proposed 'acct' URI scheme:  how are you going to handle =
internationalization (i18n)?  We have RFC 5335 defining  =
(Experimental RFC) and IESG has already approved EAI 5335bis, that will =
be Standards Track.  So will  be allowed in 'acct' URIs =
in some way?

Webfinger implies use of some link relations.  Is it anticipated that =
URIs will be used as link relations types, or we'll need to define link =
relation types for all possible use-cases of Webfinger?

Your Section 4 seems to be somewhat narrative.  I propose to divide it =
into normative specification and examples.

With regard to CORS - I'm not actually acquainted with this technology, =
but I see it is currently documented as W3C working draft, so I don't =
suspect it is now widely-used (I may of course be wrong, so please feel =
free to correct me), and I think there is no use putting MUST =
requirement on its use in Webfinger.  You could better remove your =
section on CORS from the document at all.

I think we should also provide some means of mentioning Webfinger =
accounts in vCards.  You could please see VCARDDAV document =
http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 which =
Webfinger elements may also be incorporated.

In Abstract, you should be more specific about what your document =
defines.  I propose mentioning directly that the document is the =
specification of Webfinger protocol, not "procedures for dicovering =
information about people".

In Section 7 you should clearly state that Webfinger (so as finger =
itself) is intentionally left w/o any means of controlling access to =
information (unless we want to produce *such* protocol).

I see the document is on APPSAWG agenda on the meeting, so I anticipate =
it will soon become APPSAWG item doc.  I won't be on meeting, but if you =
discuss the adaptation of Webfinger draft please also take into account =
I'm in favor of such adaptation (consider this as my 2p).

Mykyta Yevstifeyev

24.10.2011 23:09, Paul E. Jones wrote:=20

Folks,

=20

We just submitted this:

http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

=20

The tools for Webfinger are now defined, but the procedures need to be =
clearer with respect to what most of us understand as =
=E2=80=9Cwebfinger=E2=80=9D.  This is just a first stab at making that =
happen and we hope to progress this to publish an RFC in the application =
area.

=20

We welcome any comments you have on the topic, either privately or =
publicly.

=20

Paul

=20







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

=20

=20


------=_NextPart_000_0154_01CCA208.8D169FD0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Mykyta,
 
I fear this might get =
complicated with references to the email documents.=C2=A0 Those =
documents are trying to solve a real problem, but Webfinger does not =
have some of those historical constraints.
 
Here=E2=80=99s my =
proposal: let=E2=80=99s not reference 5335 or 5322.=C2=A0 Rather, =
let=E2=80=99s only reference the generic URI syntax spec (RFC =
3986).=C2=A0 Let=E2=80=99s define the URI scheme using the syntax found =
there:
=C2=A0=C2=A0 acctURI=C2=A0=C2=A0 =3D =
"acct:" userinfo "@" host
 
The productions =
=E2=80=9Cuserinfo=E2=80=9D and =E2=80=9Chost=E2=80=9D are already =
defined.=C2=A0 Perhaps the one thing I don=E2=80=99t like is that =
=E2=80=9Chost=E2=80=9D might be an IP address, but perhaps some people =
prefer that.
 
RFC 3986 already says =
that these components are UTF-8 encoded and then percent-escaped when a =
character is outside the ASCII character set =
range.
 
Would this be a suitable =
replacement for the current text?
 
With respect to your =
comments on link relations and URIs, I still do not understand.=C2=A0 =
You say that =E2=80=9Cnobody will benefit from link relation types =
defined by URIs=E2=80=9D, but why not?=C2=A0 There are several already =
define and used today.=C2=A0 In any case, I would prefer that all link =
relation values (URI or simple strings) be defined outside of the =
Webfinger draft.=C2=A0 As I mentioned, there is already a registry, so =
one can be proposed any time.
 
Paul
 
From: "Mykyta Yevstifeyev (=D0=9C. =
=D0=84=D0=B2=D1=81=D1=82=D1=96=D1=84=D0=B5=D1=94=D0=B2)" =
[mailto:evnikita2@gmail.com] 
Sent: Saturday, November 12, =
2011 12:32 AM
To: Paul E. Jones
Cc: =
apps-discuss@ietf.org
Subject: Re: [apps-discuss] =
Webfinger
 
Hello =
Paul,

12.11.2011 1:37, Paul E. Jones wrote: 
Mykyta,
 
Thanks for your positive =
response.
 
To your specific =
questions=E2=80=A6
 
We would definitely want =
to ensure that Unicode is properly supported.  In wasn=E2=80=99t =
aware of RFC 5335, so I=E2=80=99m glad you brought that to my =
attention.  Do you have a pointer to the bis draft so I can see =
exactly what is there?  I=E2=80=99d be fully in favor of using =
utf8-addr-spec.

This is http://t=
ools.ietf.org/html/draft-ietf-eai-rfc5335bis-13.  But please =
note that this document, unlike RFC 5335, introduced UTF-8 additions to =
*base* RFC 5322 productions.  This means that <addr-spec> =
will be defined as follows =
now:


=C2=A0=C2=A0 =
addr-spec=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D=C2=A0=C2=A0 local-part =
"@" domain
=C2=A0=C2=A0 =
local-part=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D=C2=A0=C2=A0 dot-atom / =
quoted-string / obs-local-part
=C2=A0=C2=A0 =
domain=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=3D=C2=A0=C2=A0 dot-atom / domain-literal / =
obs-domain
=C2=A0=C2=A0 domain-literal=C2=A0 =
=3D=C2=A0=C2=A0 [CFWS] "[" *([FWS] dtext) [FWS] "]" =
[CFWS]
=C2=A0=C2=A0 =
dtext=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=3D=C2=A0=C2=A0 %d33-90 =
/=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; Printable =
US-ASCII
=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 %d94-126 /=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
;=C2=A0 characters not including
 =
=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=A0obs-dtext=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;=C2=A0 "[", =
"]", or "\" =

=C2=A0=C2=A0=C2=A0dtext=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D/=C2=A0 =
UTF8-non-ascii=C2=A0=C2=A0=C2=A0=C2=A0 ; from 5335bis=C2=A0=C2=A0 =

=C2=A0=C2=A0=C2=A0dot-atom=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =3D=C2=A0=C2=A0 [CFWS] dot-atom-text [CFWS]=C2=A0=C2=A0 =

=C2=A0=C2=A0=C2=A0dot-atom-text=C2=A0=C2=A0 =
=3D=C2=A0=C2=A0 1*atext *("." 1*atext)=C2=A0=C2=A0=C2=A0 =

=C2=A0=C2=A0=C2=A0atext=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D/=C2=A0 =
UTF8-non-ascii=C2=A0=C2=A0=C2=A0=C2=A0 ; from 5335bis

So everything you will have to do is to have a note =
on 'acct' RI being possible to carry UTF8 characters and therefore being =
possibly IRIs.


 
Link relation types =
might be names like =E2=80=9Ccopyright=E2=80=9D or they might be =
URIs.  The definition of the link relation types is outside the =
scope of the Webfinger document itself.  RFC 6415 defines the =
structure of the documents and provides examples of some link relations =
and the order of processing.  RFC 5988 defines the link relations =
more generically and establishes the registry for them.  Do you =
think we need to say more about link relations beyond what those =
documents cover?

I =
mean that Webfinger will have to operate on a variety of link relations =
in LRDD documents, and nobody will benefit from link relation types =
defined by URIs used there, as this eliminates the possibility for =
automatic processing.  So I ask whether we'll have to define =
non-URI link relation types for all the possible Webfinger =
use-cases?


 
On section 4: =
noted.  We=E2=80=99ll try to clearly separate the normative and =
non-normative pieces better.

Thanks.


 
On  CORS, there are =
some who have strongly advocated for it.  It would be very useful =
to allow JavaScript code to perform these queries.  Otherwise, the =
queries would have to be pushed to server-side code.  Let=E2=80=99s =
wait on deciding what to do until we get a definitive answer on CORS =
from the W3C.  I think Peter was going to do some investigating =
there.
 
Putting Webfinger into =
vcard: isn=E2=80=99t that circular?  The idea with Webfinger is =
that you have the identity of the user (e.g., paulej@packetizer.com), but =
you want to find more information.  If you have a vcard, then you =
have the user=E2=80=99s identity (via the email tag).  Or are you =
suggesting that we formally introduce the acct URI in vcard?  That =
might make sense to do.  Can you clarify your =
proposal?

From RFC 6350, Section =
6.4.2:


6.4.2. EMAIL

   Purpose:  To specify the electronic =
mail address for =
communication
      with the object =
the vCard represents.

...and the use might have email address different =
from Webfinger ID.  I've already pointed to http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00, =
which VCARDDAV WG works on, and so you may try to introduce some similar =
property for Webfinger IDs.  (You see, vCards may not carry all the =
variety of information, though some people actually think in other way, =
and thus it would be a good idea to provide a means of accessing some =
additional info.)


 
For comments on =
particular sections, I=E2=80=99ve added notes to each one to revise them =
as you suggest: they=E2=80=99re all good =
suggestions.

Yes, thanks as =
well.


 
I would very much like =
to make this a WG item, of course, but none of the authors will be =
present at this IETF meeting.  Perhaps hallway dialog might take =
place, but not sure.  In any case, we can do this via the mailing =
list, too.

See =
Barry's note on this.


 
Thanks!
Paul

All the best,
Mykyta =
Yevstifeyev


 
From: apps-discuss-bounces@ietf.o=
rg [mailto:apps-discuss-bounces=
@ietf.org] On Behalf Of "Mykyta Yevstifeyev (?. =
?????????)"
Sent: Friday, November 11, 2011 12:59 =
PM
To: apps-discuss@ietf.org
Sub=
ject: Re: [apps-discuss] =
Webfinger
 
Hi Paul and =
all,

I think you contributed a very interesting proposal =
indeed.  Really, RFC 1288 finger protocol is now outdated, and =
you're right claiming that it provides no means of automatic =
processing.  BTW, RFC 1288 is currently at Draft Standard maturity =
level, which has been abandoned by RFC 6410, and we should therefore =
undertake something with this respect, as should we with respect of =
other Apps-related DSs, but that is what is to be discussed =
separately.

With respect to proposed 'acct' URI scheme:  how =
are you going to handle internationalization (i18n)?  We have RFC =
5335 defining <utf8-addr-spec> (Experimental RFC) and IESG has =
already approved EAI 5335bis, that will be Standards Track.  So =
will <utf8-addr-spec> be allowed in 'acct' URIs in some =
way?

Webfinger implies use of some link relations.  Is it =
anticipated that URIs will be used as link relations types, or we'll =
need to define link relation types for all possible use-cases of =
Webfinger?

Your Section 4 seems to be somewhat narrative.  I =
propose to divide it into normative specification and =
examples.

With regard to CORS - I'm not actually acquainted with =
this technology, but I see it is currently documented as W3C working =
draft, so I don't suspect it is now widely-used (I may of course be =
wrong, so please feel free to correct me), and I think there is no use =
putting MUST requirement on its use in Webfinger.  You could better =
remove your section on CORS from the document at all.

I think we =
should also provide some means of mentioning Webfinger accounts in =
vCards.  You could please see VCARDDAV document http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 =
which Webfinger elements may also be incorporated.

In Abstract, =
you should be more specific about what your document defines.  I =
propose mentioning directly that the document is the specification of =
Webfinger protocol, not "procedures for dicovering information =
about people".

In Section 7 you should clearly state that =
Webfinger (so as finger itself) is intentionally left w/o any means of =
controlling access to information (unless we want to produce *such* =
protocol).

I see the document is on APPSAWG agenda on the =
meeting, so I anticipate it will soon become APPSAWG item doc.  I =
won't be on meeting, but if you discuss the adaptation of Webfinger =
draft please also take into account I'm in favor of such adaptation =
(consider this as my 2p).

Mykyta Yevstifeyev

24.10.2011 =
23:09, Paul E. Jones wrote: 
Folks,
 
We just =
submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinge=
r-00.txt
 
The tools for Webfinger are now defined, but the =
procedures need to be clearer with respect to what most of us understand =
as =E2=80=9Cwebfinger=E2=80=9D.  This is just a first stab at =
making that happen and we hope to progress this to publish an RFC in the =
application area.
 
We welcome =
any comments you have on the topic, either privately or =
publicly.
 
Paul
 




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

------=_NextPart_000_0154_01CCA208.8D169FD0--


From masinter@adobe.com  Sun Nov 13 10:59:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFA921F8B61 for ; Sun, 13 Nov 2011 10:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.211
X-Spam-Level: 
X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, 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 J4A6eyjLf3nV for ; Sun, 13 Nov 2011 10:59:35 -0800 (PST)
Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8747221F8B55 for ; Sun, 13 Nov 2011 10:59:34 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKTsATkG5w9WkRzjpGKiGWBmdTHOoEL5+Z@postini.com; Sun, 13 Nov 2011 10:59:36 PST
Received: from inner-relay-1.corp.adobe.com (inner-relay-1.sea.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pADIxQQB006950 for ; Sun, 13 Nov 2011 10:59:27 -0800 (PST)
Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pADIxO5R021357 for ; Sun, 13 Nov 2011 10:59:25 -0800 (PST)
Received: from SJ1SWM219.corp.adobe.com (10.5.77.61) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.192.1; Sun, 13 Nov 2011 10:59:24 -0800
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%12]) with mapi; Sun, 13 Nov 2011 10:59:24 -0800
From: Larry Masinter 
To: "apps-discuss@ietf.org" 
Date: Sun, 13 Nov 2011 10:59:21 -0800
Thread-Topic: A modest proposal for MIME types (and URI schemes)
Thread-Index: AcyiNloh63jyxDw9QzCPclPJZQCAMw==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Roy Fielding 
Subject: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 18:59:35 -0000

SSdkIGxpa2UgdG8gZGlzY3VzcyB0aGUgcHJvcG9zYWwgZm9yIE1JTUUgcmVnaXN0cmF0aW9ucyBm
cm9tIFJveSBGaWVsZGluZyBpbiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv
aGFwcGlhbmEvY3VycmVudC9tc2cwMDE4Ny5odG1sDQphbmQgdGhlIHBvc3NpYmlsaXR5IHRoYXQg
c3VjaCBjaGFuZ2VzIHNob3VsZCBhbHNvIGFwcGx5IHRvIFVSSSBzY2hlbWVzLg0KDQpZb3UgY2Fu
IHJlYWQgUm95J3MgcmF0aW9uYWxlLCB3aGljaCBtYWtlcyBzZW5zZSB0byBtZSwgYnV0IG15IHN1
bW1hcnkgaXM6IA0KDQoqIEVsaW1pbmF0ZSBzdGFuZGFyZHMsIHZlbmRvciwgcGVyc29uYWwgdHJl
ZXMgZGlzdGluY3Rpb24gZm9yIE1JTUUgdHlwZXMgKEZvciBVUkkgc2NoZW1lcywgZWxpbWluYXRl
IGRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdmlzaW9uYWwgYW5kIHBlcm1hbmVudCBzY2hlbWVzKQ0K
KiBFTkNPVVJBR0UgdmVuZG9ycyB0byBzaGlwIHdpdGggdmVuZG9yLW5ldXRyYWwgc2hvcnQtbmFt
ZWQgdHlwZXMgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZXkgaGF2ZSBiZWVuIHJlZ2lzdGVyZWQg
eWV0IG9yIG5vdDsNCiAgIEVOQ09VUkFHRSB0aGUgcHVibGljIHRvIHJlZ2lzdGVyIGFueSBuYW1l
cyB0aGF0IHRoZXkgaGF2ZSBzZWVuIGluIGRlcGxveWVkIHNvZnR3YXJlLiAoc2FtZSBmb3IgVVJJ
IHNjaGVtZXMpDQoqIERPIE5PVCB0cnkgdG8gYXZvaWQgZHVwbGljYXRlcyANCiogRVhQRVJUIFJF
VklFVyBmb3IgdXBkYXRlcyB0byBleGlzdGluZyByZWdpc3RyYXRpb25zDQoqIEVsaW1pbmF0ZSBh
bnkgSUVTRyBvciBjb25zZW5zdXMgcmV2aWV3IHJlcXVpcmVtZW50DQoNCiJUaGVyZSBpcyBhYnNv
bHV0ZWx5IG5vIG5lZWQgdG8gcHJldmVudCBuYW1lIGNvbGxpc2lvbnMgaW4gdGhlIHJlZ2lzdHJ5
IGl0c2VsZiBiZWNhdXNlIHRob3NlIGNvbGxpc2lvbnMgYXJlIGlycmVsZXZhbnQgLS0gd2hhdCBt
YXR0ZXJzIGlzIGhvdyB0aGUgbmFtZXMgYXJlIGludGVycHJldGVkIGJ5IHJlY2lwaWVudHMgb2Yg
bWVzc2FnZXMuIg0KIlRoZXJlIGlzIGFic29sdXRlbHkgbm8gbmVlZCB0byBwcmV2ZW50IHBlb3Bs
ZSB3aG8gYXJlIG5vdCB0aGUgb3duZXJzIG9mIGEgbWVkaWEgdHlwZSBmcm9tIHJlZ2lzdGVyaW5n
IHRoYXQgdHlwZSB3aXRob3V0IGFueSBwcmVmaXhlcy4iDQoiVGhlIHJlZ2lzdHJ5IGlzIG5vdCBv
cGVyYWJsZSAtLSBpdCBpcyBqdXN0IGRvY3VtZW50YXRpb24gb2YgaG93IHRoZSBJbnRlcm5ldCBp
cyBvcGVyYXRpbmcsIGFuZCBpdCBzaG91bGQgcmVmbGVjdCB0aGUgcmVhbGl0eSBvZiB0aGF0IG9w
ZXJhdGlvbiBldmVuIGlmIHRoYXQgbWVhbnMgd2UgaGF2ZSBtdWx0aXBsZSBkZWZpbml0aW9ucyBw
ZXIgcmVnaXN0ZXJlZCB0eXBlLiINCg0KSSBmaW5kIHRoaXMgcGVyc3BlY3RpdmUgYXBwZWFsaW5n
LCBhbmQgY2FuJ3QgZmluZCBhbnl0aGluZyB3cm9uZyB3aXRoIGl0IGV4Y2VwdCB0aGF0IGl0J3Mg
YSBicmVhayB3aXRoIHRyYWRpdGlvbi4gSWYgeW91J3JlIGF0IElFVEYgdGhpcyB3ZWVrIGFuZCB3
YW50IHRvIHRhbGsgYWJvdXQgaXQsIGZpbmQgbWUuDQoNCkxhcnJ5IA0K

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Sun Nov 13 13:21:57 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8590221F8481 for ; Sun, 13 Nov 2011 13:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_23=0.6, 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 O1ROUvtxheHI for ; Sun, 13 Nov 2011 13:21:57 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA18321F8480 for ; Sun, 13 Nov 2011 13:21:56 -0800 (PST)
Received: by wyf28 with SMTP id 28so3937563wyf.31 for ; Sun, 13 Nov 2011 13:21:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aBQII7XLp9MaYTyzfhY+19GLhXqUvHxow8qVBY5DpwU=; b=gYdRKDbJv63xz+huFsIRYTe/3X8SOXWyusUKq/wlCEZmXhZ9lAJo/7nu7WNjChE7db HqUO4C+P1gDxJZJUWLX+YGQKwehHk2d+XZ8cyZmeQt6ocBbWTzn/nsPjWKzsgIoo5ryk LQ9JxDelOkLBJzz6kpe6xS15ghw2uGfYueM2E=
Received: by 10.216.72.145 with SMTP id t17mr755130wed.88.1321219316073; Sun, 13 Nov 2011 13:21:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.184.147 with HTTP; Sun, 13 Nov 2011 13:21:15 -0800 (PST)
In-Reply-To: 
References: 
From: Frank Ellermann 
Date: Sun, 13 Nov 2011 22:21:15 +0100
Message-ID: 
To: Larry Masinter 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 21:21:57 -0000

On 13 November 2011 19:59, Larry Masinter wrote:

> I find this perspective appealing

In an ideal world it's not only appealing.  But in
the real world the "secret mission" of the IETF is
IMHO to protect the IANA from "patent nonsense".

It cannot work if *everybody* is free to register
new media types or URI schemes falling into various
WP:NOT categories (= "what Wikipedia is not").

And the IANA also is also not Wikipedia, it is no
dictionary of locations, encyclopedia of emoticons,
registry of vanity URI schemes, or anything else
requiring unlimited disk space or server bandwidth.

-Frank

From stpeter@stpeter.im  Sun Nov 13 16:33:42 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D032A11E8090 for ; Sun, 13 Nov 2011 16:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.524
X-Spam-Level: 
X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=-0.925, 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 8PYsjrLdH4MO for ; Sun, 13 Nov 2011 16:33:42 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 53E6611E8073 for ; Sun, 13 Nov 2011 16:33:42 -0800 (PST)
Received: from dhcp-13ac.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BE3524214C for ; Sun, 13 Nov 2011 17:39:50 -0700 (MST)
Message-ID: <4EC061E3.8090503@stpeter.im>
Date: Mon, 14 Nov 2011 08:33:39 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] meeting coordinates
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 00:33:43 -0000

Here are pointers to various meeting-related information for today...

Agenda:
http://tools.ietf.org/wg/appsawg/agenda?item=agenda82.html

Materials:
https://datatracker.ietf.org/meeting/82/materials.html#wg-appsawg

Chatroom:
xmpp:appsawg@jabber.ietf.org?join

Audio:
http://ietf82streaming.dnsalias.net/ietf/ietf825.m3u

See you soon!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From msk@cloudmark.com  Sun Nov 13 17:56:53 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2752D11E8082 for ; Sun, 13 Nov 2011 17:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.806
X-Spam-Level: 
X-Spam-Status: No, score=-102.806 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HTML_MESSAGE=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 Xp5VXH52cjKr for ; Sun, 13 Nov 2011 17:56:52 -0800 (PST)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6417021F8510 for ; Sun, 13 Nov 2011 17:56:52 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 13 Nov 2011 17:56:51 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Sun, 13 Nov 2011 17:56:50 -0800
Thread-Topic: draft-kucherawy-greylisting-bcp into APPSAWG?
Thread-Index: AcyicKz1WilxOxrqQziE0yZx+SjG6w==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15000EXCHC2corpclo_"
MIME-Version: 1.0
Subject: [apps-discuss] draft-kucherawy-greylisting-bcp into APPSAWG?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 01:56:53 -0000

--_000_F5833273385BB34F99288B3648C4F06F19C6C15000EXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

As discussed in the APPSAWG meeting just now, I'd like to see if there's in=
terest in adopting this into APPSAWG for processing.  There wasn't any resi=
stance, but a few people provided the following useful input towards its de=
velopment:


-          Should it be BCP or Informational?

-          It should discuss how not to do greylisting as well as how to do=
 it

-          Some collaboration with the ASRG is suggested in terms of collec=
ting data about which approaches work best, etc.

And of course the main question is: Is this appropriate for APPSAWG?

-MSK

--_000_F5833273385BB34F99288B3648C4F06F19C6C15000EXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi all,
 
As dis=
cussed in the APPSAWG meeting just now, I’d like to see if there̵=
7;s interest in adopting this into APPSAWG for processing.  There wasn=
’t any resistance, but a few people provided the following useful inp=
ut towards its development:
 <=
/o:p>
-      =
    Should it be BCP or Informationa=
l?
-    &nbs=
p;     It should discuss how no=
t to do greylisting as well as how to do it
-          =
Some collaboration with the ASRG is suggested in terms of =
collecting data about which approaches work best, etc.
 
And of course the =
main question is: Is this appropriate for APPSAWG?
 
-MSK
<=
/div>=

--_000_F5833273385BB34F99288B3648C4F06F19C6C15000EXCHC2corpclo_--

From rg+ietf@qualcomm.com  Sun Nov 13 18:20:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEEC1F0C49; Sun, 13 Nov 2011 18:20:30 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -106.276
X-Spam-Level: 
X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, 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 SfPTPCB93Rnd; Sun, 13 Nov 2011 18:20:29 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 850B71F0C46; Sun, 13 Nov 2011 18:20:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=rg+ietf@qualcomm.com; q=dns/txt; s=qcdkim; t=1321237229; x=1352773229; h=message-id:x-mailer:date:to:from:subject:cc:content-type: x-random-sig-tag; z=Message-Id:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Sun,=201 3=20Nov=202011=2018:20:17=20-0800|To:=20,=20Peter=20Saint-Andre=20, =0D=0A=20=20=20=20=20=20=20=20Dave=20Crocker=20,=20Mark=20Nottingham=20=20=20 |From:=20Randall=20Gellens=20 |Subject:=20Re:=20[apps-discuss]=20I-D=20Action:=20draft- ietf-appsawg-xdash-02.txt|Cc:=20 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=20 =3B=20format=3D"flowed"|X-Random-Sig-Tag:=201.0b28; bh=+61EcHAU5XTtCnH4GxVcJjWLBMkzsMMNy/nAG6fx39g=; b=edmy93bzrTgqNR3vy7LEcdJTrAG5vEK9YMrrnGZQ8kiWtw+eMKMt6oFb Jji1bdScEaUcahr+p5qZy4O5BEeq55wE/27yhDU6pLXGBw5uRmz2Lp1nF fQ2yspkoXp2/VULqJQV5irf6ekgz9S3KQhxNBSWPV42CsZ7z9OeFP5rrX s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6529"; a="134957402"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 13 Nov 2011 18:20:29 -0800
X-IronPort-AV: E=Sophos;i="4.69,502,1315206000"; d="scan'208";a="112678273"
Received: from warlock.qualcomm.com ([129.46.50.49]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2011 18:20:22 -0800
Received: from [172.21.1.9] (myvpn-l-dyp000696dys.ras.qualcomm.com [10.64.135.172]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id pAE2KIP3017198; Sun, 13 Nov 2011 18:20:19 -0800
Mime-Version: 1.0
Message-Id: 
X-Mailer: Eudora for Mac OS X
Date: Sun, 13 Nov 2011 18:20:17 -0800
To: , Peter Saint-Andre , Dave Crocker , Mark Nottingham   
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 02:20:30 -0000

One thing I noticed is that the text in Appendix B, to me, makes an 
argument for preserving some mechanism to distinguish between 
standard and ad-hoc:

    Furthermore, often standardization of a non-standard parameter or
    protocol element leads to subtly different behavior (e.g., the
    standard version might have different security properties as a result
    of security review provided during the standardization process).  If
    implementers treat the old, non-standard parameter and the new,
    standard parameter as equivalent, interoperability and security
    problems can ensue.

To me, this text points out that sometimes people slap together an 
ad-hoc "x-" parameter, and later go for a standard version, which 
after wider review is modified to address security or other issues; 
the text notes that if this happens, and if implementations treat the 
old and new versions as identical, then they are being exposed to the 
vulnerabilities.  However, the solution proposed here means that, 
once an ad-hoc version is deployed, there won't be a standard 
version, and hence no wider review, no revised version with a non-x 
name, and no chance for implementations to avoid the problems.  It 
seems to me that it would be better for the standard version to 
deprecate the non-standard in these cases, or at least describe how 
to avoid its problems.

I can't help but think that we'd be better off with a middle ground, 
similar to "vnd." namespace, for ad-hoc parameters that might or 
might not be standardized, but that clearly have not been through 
IETF consensus.  One advantage is that it provides some impetus 
(however slight) to develop a standard version if it's useful. 
Another advantage is that it might provide better clues as to the 
source of and change control over the ad-hoc parameter.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Anyone can do any amount of work provided it isn't the work he is
supposed to be doing at the moment.               --Robert Benchley
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It has always seemed to me that the most difficult part of building
a bridge would be the start.                      --Robert Benchley

From rg+ietf@qualcomm.com  Sun Nov 13 18:20:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F03711E8132 for ; Sun, 13 Nov 2011 18:20:36 -0800 (PST)
X-Quarantine-ID: <2qEojMg2Hc9a>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -105.322
X-Spam-Level: 
X-Spam-Status: No, score=-105.322 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_1=2, 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 2qEojMg2Hc9a for ; Sun, 13 Nov 2011 18:20:35 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1337811E8117 for ; Sun, 13 Nov 2011 18:20:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=rg+ietf@qualcomm.com; q=dns/txt; s=qcdkim; t=1321237235; x=1352773235; h=message-id:x-mailer:date:to:from:subject:content-type: x-random-sig-tag; z=Message-Id:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Sun,=201 3=20Nov=202011=2018:20:31=20-0800|To:=20"Murray=20S.=20Ku cherawy"=20,=0D=0A=20=20=20=20=20=20 =20=20"apps-discuss@ietf.org"=20 |From:=20Randall=20Gellens=20 |Subject:=20Re:=20[apps-discuss]=20draft-kucherawy-greyli sting-bcp=20into=20=0D=0A=20APPSAWG?|Content-Type:=20text /plain=3B=20charset=3D"us-ascii"=20=3B=20format=3D"flowed "|X-Random-Sig-Tag:=201.0b28; bh=AfAupWm962vn/PHoRHcEdJDm8ZGWXXCOXxJyCbpYrXA=; b=hyjA4oBkr0NRMNwDcyosDwNtAvIxz8SSp7aiRfbEu4Bn5LN9gB8QRq5r S/u678TaIPPOVBEI+tHcfJ/sgtMeiaZbuIS1Yni39tipCuptmoVqSoCaP F2KtJU4h7DSiLm7GpVZlJ6h4DIt99eWRTq8schq1EtIlAuJLnaE55z02B g=;
X-IronPort-AV: E=McAfee;i="5400,1158,6529"; a="134957412"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 13 Nov 2011 18:20:34 -0800
X-IronPort-AV: E=Sophos;i="4.69,502,1315206000"; d="scan'208";a="112678642"
Received: from warlock.qualcomm.com ([129.46.50.49]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2011 18:20:34 -0800
Received: from [172.21.1.9] (myvpn-l-dyp000696dys.ras.qualcomm.com [10.64.135.172]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id pAE2KV3X017223; Sun, 13 Nov 2011 18:20:33 -0800
Mime-Version: 1.0
Message-Id: 
X-Mailer: Eudora for Mac OS X
Date: Sun, 13 Nov 2011 18:20:31 -0800
To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
Subject: Re: [apps-discuss] draft-kucherawy-greylisting-bcp into  APPSAWG?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 02:20:36 -0000

At 5:56 PM -0800 11/13/11, Murray S. Kucherawy wrote:

>   As discussed in the APPSAWG meeting just now, I'd like to see if 
> there's interest in adopting this into APPSAWG for processing. 
> There wasn't any resistance, but a few people provided the 
> following useful input towards its development:
>
>   -          Should it be BCP or Informational?

I'd say it depends on how prescriptive versus informative the text 
ends up.  I think it would be fine as Informational, and can still 
point out that some means of implementing greylisting can mitigate or 
worsen the ill effects (for example, some implementations greylist 
based on a tuple of [IP, MAIL FROM, RECPT TO], while others use only 
the IP address; the former method aggravates the delay issue, to no 
real benefit, since any given client side will or won't retry, 
regardless of the MAIL FROM and RCPT TO).

>   -          It should discuss how not to do greylisting as well as 
> how to do it
>   -          Some collaboration with the ASRG is suggested in terms 
> of collecting data about which approaches work best, etc.
>
>   And of course the main question is: Is this appropriate for APPSAWG?

Seems fine to me.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
#Random Tag
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Democracy is a government where you can say what you think even if you
don't think.                                       --Winston Churchill

From tianlinyi@huawei.com  Sun Nov 13 18:25:14 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D289811E8143 for ; Sun, 13 Nov 2011 18:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.127
X-Spam-Level: 
X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[AWL=2.522,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 wWV3z448rlwU for ; Sun, 13 Nov 2011 18:25:14 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 655BF11E812D for ; Sun, 13 Nov 2011 18:25:13 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM006A1PDUKV@szxga03-in.huawei.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 10:25:06 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM00M0HPDUIT@szxga03-in.huawei.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 10:25:06 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEY67081; Mon, 14 Nov 2011 10:24:19 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 10:24:17 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 10:24:11 +0800
Date: Mon, 14 Nov 2011 02:24:11 +0000
From: TianLinyi 
In-reply-to: 
X-Originating-IP: [172.24.2.40]
To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA181FFAD4@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_93aS+311JjSLsqUm1p2RUQ)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: draft-kucherawy-greylisting-bcp into APPSAWG?
Thread-index: AcyicKz1WilxOxrqQziE0yZx+SjG6wAA47bj
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: 
Subject: Re: [apps-discuss] draft-kucherawy-greylisting-bcp into APPSAWG?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 02:25:15 -0000

--Boundary_(ID_93aS+311JjSLsqUm1p2RUQ)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

SGksIGFsbA0KDQoNCg0KQmFzZWQgb24gdGhlIGNvbnRlbnQgd3JpdHRlbiBpbiB0aGUgZHJhZnQg
c28gZmFyLCBpdCBzaG91bGQgYmUgdGhlIEJDUC4NCg0KDQoNCkNoZWVycywNCg0KTGlueWkNCg0K
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGFwcHMtZGlzY3Vz
cy1ib3VuY2VzQGlldGYub3JnIFthcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBN
dXJyYXkgUy4gS3VjaGVyYXd5IFttc2tAY2xvdWRtYXJrLmNvbV0NCreiy83KsbzkOiAyMDExxOox
MdTCMTTI1SA5OjU2DQq1vTogYXBwcy1kaXNjdXNzQGlldGYub3JnDQrW98ziOiBbYXBwcy1kaXNj
dXNzXSBkcmFmdC1rdWNoZXJhd3ktZ3JleWxpc3RpbmctYmNwIGludG8gQVBQU0FXRz8NCg0KSGkg
YWxsLA0KDQpBcyBkaXNjdXNzZWQgaW4gdGhlIEFQUFNBV0cgbWVldGluZyBqdXN0IG5vdywgSaGv
ZCBsaWtlIHRvIHNlZSBpZiB0aGVyZaGvcyBpbnRlcmVzdCBpbiBhZG9wdGluZyB0aGlzIGludG8g
QVBQU0FXRyBmb3IgcHJvY2Vzc2luZy4gIFRoZXJlIHdhc26hr3QgYW55IHJlc2lzdGFuY2UsIGJ1
dCBhIGZldyBwZW9wbGUgcHJvdmlkZWQgdGhlIGZvbGxvd2luZyB1c2VmdWwgaW5wdXQgdG93YXJk
cyBpdHMgZGV2ZWxvcG1lbnQ6DQoNCg0KLSAgICAgICAgICBTaG91bGQgaXQgYmUgQkNQIG9yIElu
Zm9ybWF0aW9uYWw/DQoNCi0gICAgICAgICAgSXQgc2hvdWxkIGRpc2N1c3MgaG93IG5vdCB0byBk
byBncmV5bGlzdGluZyBhcyB3ZWxsIGFzIGhvdyB0byBkbyBpdA0KDQotICAgICAgICAgIFNvbWUg
Y29sbGFib3JhdGlvbiB3aXRoIHRoZSBBU1JHIGlzIHN1Z2dlc3RlZCBpbiB0ZXJtcyBvZiBjb2xs
ZWN0aW5nIGRhdGEgYWJvdXQgd2hpY2ggYXBwcm9hY2hlcyB3b3JrIGJlc3QsIGV0Yy4NCg0KQW5k
IG9mIGNvdXJzZSB0aGUgbWFpbiBxdWVzdGlvbiBpczogSXMgdGhpcyBhcHByb3ByaWF0ZSBmb3Ig
QVBQU0FXRz8NCg0KLU1TSw0K

--Boundary_(ID_93aS+311JjSLsqUm1p2RUQ)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable










Hi, all


 


Based on the content written in the draft so far, it should be the BCP. =



 


Cheers,


Linyi


 




=B7=A2=BC=FE=C8=CB: apps-discuss-bounces@i=
etf.org [apps-discuss-bounces@ietf.org] =B4=FA=B1=ED Murray S. Kucherawy [m=
sk@cloudmark.com]

=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8=D5 9:56

=B5=BD: apps-discuss@ietf.org

=D6=F7=CC=E2: [apps-discuss] draft-kucherawy-greylisting-bcp into AP=
PSAWG?












Hi all,


 


As discussed in the APPSAWG meeting just now, I=A1=
=AFd like to see if there=A1=AFs interest in adopting this into APPSAWG for=
 processing.  There wasn=A1=AFt any resistance, but a few people provi=
ded the following useful input towards its development:


 


-      &n=
bsp;  
Should it be BCP or Informational?


-      &n=
bsp;  
It should discuss how not to do greylisting as well as how to=
 do it


-      &n=
bsp;  
Some collaboration with the ASRG is suggested in terms of col=
lecting data about which approaches work best, etc.


 


And of course the main question is: Is this appropri=
ate for APPSAWG?


 


-MSK












--Boundary_(ID_93aS+311JjSLsqUm1p2RUQ)--

From rg+ietf@qualcomm.com  Sun Nov 13 18:43:06 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E1A1F0C86 for ; Sun, 13 Nov 2011 18:43:06 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -106.232
X-Spam-Level: 
X-Spam-Status: No, score=-106.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, 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 mPCM5WWg6Lzc for ; Sun, 13 Nov 2011 18:43:05 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0DB1F0C84 for ; Sun, 13 Nov 2011 18:43:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=rg+ietf@qualcomm.com; q=dns/txt; s=qcdkim; t=1321238585; x=1352774585; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:content-type:x-random-sig-tag; z=Message-Id:=20 |In-Reply-To:=20|References:=20<20111018234005.22724.87290.idtracke r@ietfa.amsl.com>=0D=0A=20|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |Date:=20Sun,=2013=20Nov=202011=2018:33:01=20-0800|To:=20 Mark=20Nottingham=20,=20Apps=20Discuss=09< apps-discuss@ietf.org>|From:=20Randall=20Gellens=20|Subject:=20Re:=20[apps-discuss]=20I-D=20 Action:=20=0D=0A=20draft-nottingham-http-new-status-02.tx t|Cc:=20Jan=20Algermissen=20,=0D =0A=20=20=20=20=20=20=20=20httpbis=20Group=20|Content-Type:=20text/plain=3B=20charset=3D"us-a scii"=20=3B=20format=3D"flowed"|X-Random-Sig-Tag:=201.0b2 8; bh=JV8rokZxLNZkzXSZVsXMfAPVBHjG4bQ4/Nm+8ooxe+Q=; b=xhF5BVW8YqPxV3I8qHeg64hbD4tyOC8NyrX6CuEsdH3IfkHRKoTEqeYR 7aPqqZfwGZeRDW5VFm+wV2Ko2jLMR2XvN91LHwXmjssiNuWwV73CZJ3b7 oyoKZAkIPbGR1+OFhI1wGzO3m3asogLjJldlWuXUW39ZbTaU7/IEESImm g=;
X-IronPort-AV: E=McAfee;i="5400,1158,6529"; a="137319273"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 13 Nov 2011 18:43:04 -0800
X-IronPort-AV: E=Sophos;i="4.69,504,1315206000"; d="scan'208";a="112691481"
Received: from warlock.qualcomm.com ([129.46.50.49]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2011 18:43:03 -0800
Received: from [172.21.1.9] (myvpn-l-dyp000696dys.ras.qualcomm.com [10.64.135.172]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id pAE2gxuY019754; Sun, 13 Nov 2011 18:43:00 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <20111018234005.22724.87290.idtracker@ietfa.amsl.com> 
X-Mailer: Eudora for Mac OS X
Date: Sun, 13 Nov 2011 18:33:01 -0800
To: Mark Nottingham , Apps Discuss	
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
Cc: Jan Algermissen , httpbis Group 
Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-new-status-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 02:43:06 -0000

In today's APPAREA/APPSWG session, Mark briefly talked about this 
draft, and when mentioning the 511 code, said that his intent was not 
to encourage captive portal interception as a technique for network 
access authorization or authentication, but rather to reduce the harm 
that such mechanisms cause.

I agree with all these goals, but in looking at 
draft-nottingham-http-new-status-03.txt, I wonder if it would be 
helpful to add some text in section 6 that mentions some of the ill 
effects of the method, and mentions or points to a few better 
alternative mechanisms for authorizing network access.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Hofstadter's Law:
   It always takes longer than you expect, even when you take
   Hofstadter's Law into account.

From mnot@mnot.net  Sun Nov 13 19:12:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C9C1F0CB8 for ; Sun, 13 Nov 2011 19:12:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, 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 66RhRdeEXqAA for ; Sun, 13 Nov 2011 19:12:23 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 515171F0C8E for ; Sun, 13 Nov 2011 19:12:23 -0800 (PST)
Received: from [10.10.1.235] (unknown [12.14.58.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6BFDD509DB; Sun, 13 Nov 2011 22:12:16 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: 
Date: Sun, 13 Nov 2011 21:12:13 -0600
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <20111018234005.22724.87290.idtracker@ietfa.amsl.com>  
To: Randall Gellens 
X-Mailer: Apple Mail (2.1251.1)
Cc: Jan Algermissen , Apps Discuss , httpbis Group 
Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-new-status-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 03:12:24 -0000

Seems sensible; I'll try to come up with something.

Cheers,


On 13/11/2011, at 8:33 PM, Randall Gellens wrote:

> In today's APPAREA/APPSWG session, Mark briefly talked about this 
> draft, and when mentioning the 511 code, said that his intent was not 
> to encourage captive portal interception as a technique for network 
> access authorization or authentication, but rather to reduce the harm 
> that such mechanisms cause.
> 
> I agree with all these goals, but in looking at 
> draft-nottingham-http-new-status-03.txt, I wonder if it would be 
> helpful to add some text in section 6 that mentions some of the ill 
> effects of the method, and mentions or points to a few better 
> alternative mechanisms for authorizing network access.
> 
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Hofstadter's Law:
>   It always takes longer than you expect, even when you take
>   Hofstadter's Law into account.

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





From barryleiba@gmail.com  Sun Nov 13 20:35:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E542B11E80F8 for ; Sun, 13 Nov 2011 20:35:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.891
X-Spam-Level: 
X-Spam-Status: No, score=-102.891 tagged_above=-999 required=5 tests=[AWL=0.086, 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 VvXcI75ahnuS for ; Sun, 13 Nov 2011 20:35:04 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69CFE11E80F2 for ; Sun, 13 Nov 2011 20:35:04 -0800 (PST)
Received: by ywt34 with SMTP id 34so4288597ywt.31 for ; Sun, 13 Nov 2011 20:35:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=D31zSolZXOZdBtQIHwxx2ySkKdwR8KtMmr5tUgsm/28=; b=xmSgHFgZGa/nZYbE0XodFrvcuvl2pkg4PcQbYnr1ZhyVveMcpYHYCdtRxThF+KE83A sowpAJUZz1IRkygIwibg/rGH5G5QoTEfOOU1ILeIPf94G6cyT5O5f7vcAVmtiz/mn2mH 1Nvt+E5dpc8NjY6Z8KyGfLwEgEcrTXY7FMK3E=
MIME-Version: 1.0
Received: by 10.236.161.65 with SMTP id v41mr11902283yhk.42.1321245304023; Sun, 13 Nov 2011 20:35:04 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.236.203.196 with HTTP; Sun, 13 Nov 2011 20:35:03 -0800 (PST)
Date: Mon, 14 Nov 2011 12:35:03 +0800
X-Google-Sender-Auth: dAJu9yPnqKXefS0KQgMtCtj_P-s
Message-ID: 
From: Barry Leiba 
To: Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Minutes for AppsAWG and Apps Area General Session, IETF 82
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 04:35:05 -0000

I've posted minutes on the meeting materials site.  Find them here:
http://www.ietf.org/proceedings/82/minutes/appsawg.txt

Barry, appsawg chair

From tianlinyi@huawei.com  Sun Nov 13 21:03:51 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BFF11E81D5 for ; Sun, 13 Nov 2011 21:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.606
X-Spam-Level: 
X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=3.994,  BAYES_00=-2.599, 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 AFS7e-AJ+W+2 for ; Sun, 13 Nov 2011 21:03:51 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id F297F11E81D3 for ; Sun, 13 Nov 2011 21:03:50 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM00E98WOQRR@szxga05-in.huawei.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 13:02:50 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM004PPWONE1@szxga05-in.huawei.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 13:02:50 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEY78906; Mon, 14 Nov 2011 13:02:48 +0800
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 13:02:46 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 13:02:41 +0800
Date: Mon, 14 Nov 2011 05:02:40 +0000
From: TianLinyi 
In-reply-to: 
X-Originating-IP: [172.24.2.40]
To: Mark Nottingham , Randall Gellens 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA181FFC67@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: [apps-discuss] I-D Action:	draft-nottingham-http-new-status-02.txt
Thread-index: AQHMontARCaQnFCFfUWvAeIRwf4ZNZWrzDsk
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <20111018234005.22724.87290.idtracker@ietfa.amsl.com>   
Cc: Jan Algermissen , Apps Discuss , httpbis Group 
Subject: Re: [apps-discuss] I-D Action:	draft-nottingham-http-new-status-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 05:03:51 -0000

Hi, Mark

I am wondering the relationship betwen "511 Network Authentication Required" and " 401 Unauthorized". 401 is a general status code for requiring user authentication. However "requiring network access" may be part of the sementics of user authentication. How to clearly distinguish them?

In the description it mentioned the following sentence:
The response representation SHOULD indicate how to do this; e.g.,
   with an HTML form for submitting credentials.
However it is clear how to do this? Will it be leaving to implementation (e.g. the parameters included in the HTML form)?

Cheers,
Linyi

On 13/11/2011, at 8:33 PM, Randall Gellens wrote:

> In today's APPAREA/APPSWG session, Mark briefly talked about this
> draft, and when mentioning the 511 code, said that his intent was not
> to encourage captive portal interception as a technique for network
> access authorization or authentication, but rather to reduce the harm
> that such mechanisms cause.
>
> I agree with all these goals, but in looking at
> draft-nottingham-http-new-status-03.txt, I wonder if it would be
> helpful to add some text in section 6 that mentions some of the ill
> effects of the method, and mentions or points to a few better
> alternative mechanisms for authorizing network access.


>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Hofstadter's Law:
>   It always takes longer than you expect, even when you take
>   Hofstadter's Law into account.

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




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

From msk@blackops.org  Sun Nov 13 21:46:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9325821F8CBC for ; Sun, 13 Nov 2011 21:46:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Byr++RMJp3+T for ; Sun, 13 Nov 2011 21:46:07 -0800 (PST)
Received: from medusa.blackops.org (medusa.blackops.org [208.69.40.157]) by ietfa.amsl.com (Postfix) with ESMTP id D98B121F846B for ; Sun, 13 Nov 2011 21:46:06 -0800 (PST)
Received: from medusa.blackops.org (msk@localhost.blackops.org [127.0.0.1]) by medusa.blackops.org (8.14.4/8.14.4) with ESMTP id pAE5k2HC035232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 13 Nov 2011 21:46:03 -0800 (PST) (envelope-from msk@medusa.blackops.org)
X-DKIM: OpenDKIM Filter v2.4.2 medusa.blackops.org pAE5k2HC035232
X-SenderID: Sendmail Sender-ID Filter v1.0.0 medusa.blackops.org pAE5k2HC035232
Authentication-Results: medusa.blackops.org; sender-id=softfail header.from=msk@cloudmark.com; spf=none smtp.mfrom=msk@medusa.blackops.org
Received: (from msk@localhost) by medusa.blackops.org (8.14.4/8.14.2/Submit) id pAE5k1aW035215; Sun, 13 Nov 2011 21:46:01 -0800 (PST) (envelope-from msk)
Date: Sun, 13 Nov 2011 21:46:01 -0800 (PST)
Message-Id: <201111140546.pAE5k1aW035215@medusa.blackops.org>
From: "Murray S. Kucherawy" 
To: apps-discuss@ietf.org
Subject: [apps-discuss] Proposed "spfbis" working group charter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 05:46:58 -0000

As discussed today in the APPSAWG meeting.  Comments welcome.

--- 8< --- snip --- 8< ---

Working Group Name:
	SPF Update (SPFBIS)

IETF Area:
	Applications Area

Chair(s):
	TBD

Applications Area Director(s):
	Pete Resnick 
	Peter Saint-Andre 

Applications Area Advisor:
	Pete Resnick 

Mailing Lists:
	General Discussion: spfbis@ietf.org
	To Subscribe:	    https://www.ietf.org/mailman/listinfo/spfbis
	Archive:	    http://www.ietf.org/mail-archive/web/spfbis/

Description of Working Group:
	The Sender Policy Framework (SPF, RFC4408) specifies the publication
	of a DNS record which states that a listed IP address is authorized
	to send mail on behalf of the listing domain name's owner.  SMTP
	servers extract the domain name in the SMTP "MAIL FROM" command for
	confirming this authorization.  The protocol has had Experimental
	status for some years and has become widely deployed.  This working
	group will revise the specification, based on deployment experience
	and listed errata, an will seek Standards Track status for the
	protocol.

	The MARID working group created two specifications for publication of 
	email-sending authorization:  Sender-ID (RFFC4405, RFC4406 and RFC4407)
	and SPF (RFC4408), with both having Experimental status.  By using
	IP addresses, both protocols specify authorization in terms of path,
	though unlike SPF, Sender-ID uses domain names found in the header of
	the message rather than the envelope.

	The two protocols rely on the same policy mechanism, namely a
	specific TXT resource record in the DNS.  This creates a basic 
        ambiguity about the interpretation of any specific instance of the TXT 
        record.  Because of this, there were concerns about conflicts between 
        the two in concurrent operation.  The IESG Note added to each invited
	an expression of community consensus in the period following these
	publications.

	Both enjoyed initially large deployments.  Broad SPF use continues,
	and its linkage to the envelope -- rather than Sender-ID's linkage
	to identifiers in the message content -- has proven sufficient among
	operators.  This concludes the experiment.

	This working group will therefore refine the SPF specification based
	on deployment experience and listed errata, and will seek Standards
	Track status for the protocol.  Changes to the specification will be
	limited to the correction of errors, removal of unused features,
	addition of any enhancements that have already gained widespread
	support, and addition of clarifying language.

	The working group will also produce a document describing the
	course of the SPF/Sender-ID experiment (defined in the IESG note
	on the RFCs in question), bringing that experiment to a formal
	conclusion.

	Specifically out-of-scope for this working group:

	* Revisiting past technical arguments that were covered
	  in the MARID working group, except where review is reasonably
	  warranted based on operational experience.

	* Discussion of the merits of SPF.

	* Discussion of the merits of Sender-ID in preference to SPF.

	* Extensions to SPF other than the one specified in the "scope"
	  document.  The working group will re-charter to process other
	  specific proposed extensions as they are identified.

	The initial draft set:
		draft-kitterman-rfc4408bis
		draft-mehnle-spfbis-scope

Goals and Milestones:
	MMM YYYY:	A standards track document defining SPF,
			based on RFC4408 and as amended above,
 			to the IESG for publication.

	MMM YYYY:	A document describing the SPF/Sender-ID experiment
			and its conclusions to the IESG for publication.

	MMM YYYY:	A standards track document creating the "scope"
			extension to the IESG for publication.

From dhc@dcrocker.net  Sun Nov 13 21:56:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD6111E81FE; Sun, 13 Nov 2011 21:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, 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 yie-S1CBfESa; Sun, 13 Nov 2011 21:56:35 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB6D11E81FD; Sun, 13 Nov 2011 21:56:35 -0800 (PST)
Received: from [130.129.82.22] (dhcp-5216.meeting.ietf.org [130.129.82.22]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAE5uMfU000703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Nov 2011 21:56:30 -0800
Message-ID: <4EC0AD84.5060502@dcrocker.net>
Date: Mon, 14 Nov 2011 13:56:20 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Randall Gellens 
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 13 Nov 2011 21:56:33 -0800 (PST)
Cc: apps-discuss@ietf.org, Mark Nottingham , internet-drafts@ietf.org, Dave Crocker 
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 05:56:36 -0000

On 11/14/2011 10:00 AM, Randall Gellens wrote:
> To me, this text points out that sometimes people slap together an ad-hoc "x-"
> parameter, and later go for a standard version, which after wider review is
> modified to address security or other issues; the text notes that if this

I think the essence of what you've cited is that the later process produces a 
revised specification.  Hence, what is produced is not the same thing as was 
getting used.  Unfortunately the implication is a practise of re-using the name 
without any version indication, which is generally frowned upon, protocol 
technique-wise...


> I can't help but think that we'd be better off with a middle ground, similar to
> "vnd." namespace, for ad-hoc parameters that might or might not be standardized,
> but that clearly have not been through IETF consensus.

Yuch.


 > One advantage is that it
> provides some impetus (however slight) to develop a standard version if it's
> useful. Another advantage is that it might provide better clues as to the source
> of and change control over the ad-hoc parameter.

At base, this would continue the core model that has proved problematic.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From duerst@it.aoyama.ac.jp  Sun Nov 13 22:08:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AF411E820A for ; Sun, 13 Nov 2011 22:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.59
X-Spam-Level: 
X-Spam-Status: No, score=-99.59 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4vsagQcPuSf for ; Sun, 13 Nov 2011 22:08:10 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E7F5F11E820F for ; Sun, 13 Nov 2011 22:08:09 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAE684G4029797 for ; Mon, 14 Nov 2011 15:08:04 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 73a6_1798_0392f3d0_0e87_11e1_aa25_001d096c566a; Mon, 14 Nov 2011 15:08:04 +0900
Received: from [IPv6:::1] ([133.2.210.1]:59603) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 14 Nov 2011 15:08:03 +0900
Message-ID: <4EC0B043.2060907@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 15:08:03 +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: "Murray S. Kucherawy" 
References: <201111140546.pAE5k1aW035215@medusa.blackops.org>
In-Reply-To: <201111140546.pAE5k1aW035215@medusa.blackops.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed "spfbis" working group charter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 06:08:11 -0000

I'm somewhat surprised that there is a long charter text, but it ends 
essentially with "what we'll do is in draft foo". I think the "what 
we'll do" is the core of the charter, and shouldn't be just a reference.

At the absolute minimum, please refer to a numbered or dated version of 
draft-mehnle-spfbis-scope, otherwise its author(s) can easily change the 
scope of the WG.

In addition, draft-mehnle-spfbis-scope isn't even existing; I'm really 
not sure that's the way to charter a WG. Same for 
draft-kitterman-rfc4408bis.

If the above problems are sorted out, I also hope that the new WG can 
deal with EAI appropriately.

Regards,    Martin.


On 2011/11/14 14:46, Murray S. Kucherawy wrote:
> As discussed today in the APPSAWG meeting.  Comments welcome.
>
> --- 8<  --- snip --- 8<  ---
>
> Working Group Name:
> 	SPF Update (SPFBIS)
>
> IETF Area:
> 	Applications Area
>
> Chair(s):
> 	TBD
>
> Applications Area Director(s):
> 	Pete Resnick
> 	Peter Saint-Andre
>
> Applications Area Advisor:
> 	Pete Resnick
>
> Mailing Lists:
> 	General Discussion: spfbis@ietf.org
> 	To Subscribe:	    https://www.ietf.org/mailman/listinfo/spfbis
> 	Archive:	    http://www.ietf.org/mail-archive/web/spfbis/
>
> Description of Working Group:
> 	The Sender Policy Framework (SPF, RFC4408) specifies the publication
> 	of a DNS record which states that a listed IP address is authorized
> 	to send mail on behalf of the listing domain name's owner.  SMTP
> 	servers extract the domain name in the SMTP "MAIL FROM" command for
> 	confirming this authorization.  The protocol has had Experimental
> 	status for some years and has become widely deployed.  This working
> 	group will revise the specification, based on deployment experience
> 	and listed errata, an will seek Standards Track status for the
> 	protocol.
>
> 	The MARID working group created two specifications for publication of
> 	email-sending authorization:  Sender-ID (RFFC4405, RFC4406 and RFC4407)
> 	and SPF (RFC4408), with both having Experimental status.  By using
> 	IP addresses, both protocols specify authorization in terms of path,
> 	though unlike SPF, Sender-ID uses domain names found in the header of
> 	the message rather than the envelope.
>
> 	The two protocols rely on the same policy mechanism, namely a
> 	specific TXT resource record in the DNS.  This creates a basic
>          ambiguity about the interpretation of any specific instance of the TXT
>          record.  Because of this, there were concerns about conflicts between
>          the two in concurrent operation.  The IESG Note added to each invited
> 	an expression of community consensus in the period following these
> 	publications.
>
> 	Both enjoyed initially large deployments.  Broad SPF use continues,
> 	and its linkage to the envelope -- rather than Sender-ID's linkage
> 	to identifiers in the message content -- has proven sufficient among
> 	operators.  This concludes the experiment.
>
> 	This working group will therefore refine the SPF specification based
> 	on deployment experience and listed errata, and will seek Standards
> 	Track status for the protocol.  Changes to the specification will be
> 	limited to the correction of errors, removal of unused features,
> 	addition of any enhancements that have already gained widespread
> 	support, and addition of clarifying language.
>
> 	The working group will also produce a document describing the
> 	course of the SPF/Sender-ID experiment (defined in the IESG note
> 	on the RFCs in question), bringing that experiment to a formal
> 	conclusion.
>
> 	Specifically out-of-scope for this working group:
>
> 	* Revisiting past technical arguments that were covered
> 	  in the MARID working group, except where review is reasonably
> 	  warranted based on operational experience.
>
> 	* Discussion of the merits of SPF.
>
> 	* Discussion of the merits of Sender-ID in preference to SPF.
>
> 	* Extensions to SPF other than the one specified in the "scope"
> 	  document.  The working group will re-charter to process other
> 	  specific proposed extensions as they are identified.
>
> 	The initial draft set:
> 		draft-kitterman-rfc4408bis
> 		draft-mehnle-spfbis-scope
>
> Goals and Milestones:
> 	MMM YYYY:	A standards track document defining SPF,
> 			based on RFC4408 and as amended above,
>   			to the IESG for publication.
>
> 	MMM YYYY:	A document describing the SPF/Sender-ID experiment
> 			and its conclusions to the IESG for publication.
>
> 	MMM YYYY:	A standards track document creating the "scope"
> 			extension to the IESG for publication.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From msk@cloudmark.com  Sun Nov 13 22:18:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C47B11E80C1 for ; Sun, 13 Nov 2011 22:18:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.305
X-Spam-Level: 
X-Spam-Status: No, score=-103.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, 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 jnwECXuDBzRm for ; Sun, 13 Nov 2011 22:18:45 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA1611E8095 for ; Sun, 13 Nov 2011 22:18:45 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 13 Nov 2011 22:18:45 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Sun, 13 Nov 2011 22:18:42 -0800
Thread-Topic: [apps-discuss] Proposed "spfbis" working group charter
Thread-Index: Acyik8ou1EOvgCioQIGY/4BNOhoYHQAAKinQ
Message-ID: 
References: <201111140546.pAE5k1aW035215@medusa.blackops.org> <4EC0B043.2060907@it.aoyama.ac.jp>
In-Reply-To: <4EC0B043.2060907@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [apps-discuss] Proposed "spfbis" working group charter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 06:18:46 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiAiTWFydGluIEouIETDvHJzdCIg
W21haWx0bzpkdWVyc3RAaXQuYW95YW1hLmFjLmpwXQ0KPiBTZW50OiBTdW5kYXksIE5vdmVtYmVy
IDEzLCAyMDExIDEwOjA4IFBNDQo+IFRvOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+IENjOiBhcHBz
LWRpc2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFByb3Bvc2Vk
ICJzcGZiaXMiIHdvcmtpbmcgZ3JvdXAgY2hhcnRlcg0KPiANCj4gSSdtIHNvbWV3aGF0IHN1cnBy
aXNlZCB0aGF0IHRoZXJlIGlzIGEgbG9uZyBjaGFydGVyIHRleHQsIGJ1dCBpdCBlbmRzDQo+IGVz
c2VudGlhbGx5IHdpdGggIndoYXQgd2UnbGwgZG8gaXMgaW4gZHJhZnQgZm9vIi4gSSB0aGluayB0
aGUgIndoYXQNCj4gd2UnbGwgZG8iIGlzIHRoZSBjb3JlIG9mIHRoZSBjaGFydGVyLCBhbmQgc2hv
dWxkbid0IGJlIGp1c3QgYQ0KPiByZWZlcmVuY2UuDQoNCkhpIE1hcnRpbiwNCg0KQ2FuIHlvdSBl
eHBsYWluIGhvdyB5b3UgZ290IHRoYXQ/ICBJIHRob3VnaHQgdGhlIGNoYXJ0ZXIgd2FzIHByZXR0
eSBjbGVhciBhYm91dCB3aGF0IGlzIGludGVuZGVkLCByYXRoZXIgdGhhbiBwb2ludGluZyBvZmYg
dG8gd2hhdCdzIGluIHNvbWUgZHJhZnQuICBJbiBlc3NlbmNlIGl0IHNheXMgIkhlcmUncyB3aGF0
IHdlIHBsYW4gdG8gZG8iLCBmb2xsb3dlZCBieSAiSGVyZSdzIHRoZSBkcmFmdCB3aGVyZSB3ZSd2
ZSBzdGFydGVkIGRvaW5nIGl0LiINCg0KPiBBdCB0aGUgYWJzb2x1dGUgbWluaW11bSwgcGxlYXNl
IHJlZmVyIHRvIGEgbnVtYmVyZWQgb3IgZGF0ZWQgdmVyc2lvbiBvZg0KPiBkcmFmdC1tZWhubGUt
c3BmYmlzLXNjb3BlLCBvdGhlcndpc2UgaXRzIGF1dGhvcihzKSBjYW4gZWFzaWx5IGNoYW5nZQ0K
PiB0aGUgc2NvcGUgb2YgdGhlIFdHLg0KPiANCj4gSW4gYWRkaXRpb24sIGRyYWZ0LW1laG5sZS1z
cGZiaXMtc2NvcGUgaXNuJ3QgZXZlbiBleGlzdGluZzsgSSdtIHJlYWxseQ0KPiBub3Qgc3VyZSB0
aGF0J3MgdGhlIHdheSB0byBjaGFydGVyIGEgV0cuIFNhbWUgZm9yIGRyYWZ0LWtpdHRlcm1hbi0N
Cj4gcmZjNDQwOGJpcy4NCg0KWWVzLCBpdCB3YXMgcmVhZHkgb25seSBhZnRlciB0aGUgdGVtcG9y
YXJ5IGVtYmFyZ28gb24gcG9zdGluZ3Mgd2FzIGVzdGFibGlzaGVkLiAgSGUnbGwgZ2V0IGl0IHBv
c3RlZCB2ZXJ5IHNvb24gbm93IHRoYXQgaXQncyBsaWZ0ZWQuICBJIHNlbnQgaGltIGEgcmVtaW5k
ZXIuDQoNClRoZSBvdGhlciBvbmUgaXMgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k
cmFmdC1raXR0ZXJtYW4tNDQwOGJpcy8sIHNvIHRoZSBuYW1lIGlzIHNsaWdodGx5IHdyb25nOyBl
YXNpbHkgZml4ZWQuDQoNCkkgaGF2ZW4ndCBldmVyIGhhZCB0aGUgcmVxdWVzdCB0byBuYW1lIGEg
c3BlY2lmaWMgdmVyc2lvbiBhcyBhIHN0YXJ0aW5nIHBvaW50IGluIGEgY2hhcnRlciBiZWZvcmUs
IHdoaWNoIGlzIHdoeSBpdCB3YXNuJ3QgZG9uZSBoZXJlLg0KDQo+IElmIHRoZSBhYm92ZSBwcm9i
bGVtcyBhcmUgc29ydGVkIG91dCwgSSBhbHNvIGhvcGUgdGhhdCB0aGUgbmV3IFdHIGNhbg0KPiBk
ZWFsIHdpdGggRUFJIGFwcHJvcHJpYXRlbHkuDQoNClRoYXQgaXMgaW5kZWVkIGEgY29uc2lkZXJh
dGlvbjsgc2VlIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZWxsZXJtYW5u
LXNwZi1lYWkvLiAgVGhlIGdyb3VwIGNvdWxkIHRha2UgdGhpcyBvbiBhcyB3ZWxsLCB0aG91Z2gg
dGhlIHNjb3BlIHdvbid0IHF1aXRlIGJlIHNvIHRpZ2h0IGF0IGZpcnN0IGlmIGl0IGRvZXMuICBJ
J20gZmluZSBlaXRoZXIgd2F5Lg0KDQotTVNLDQo=

From msk@cloudmark.com  Sun Nov 13 22:31:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A4211E820F for ; Sun, 13 Nov 2011 22:31:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.807
X-Spam-Level: 
X-Spam-Status: No, score=-102.807 tagged_above=-999 required=5 tests=[AWL=-0.208, 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 TGyfQxedJzRo for ; Sun, 13 Nov 2011 22:31:19 -0800 (PST)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 67CB711E8209 for ; Sun, 13 Nov 2011 22:31:19 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 13 Nov 2011 22:31:18 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Sun, 13 Nov 2011 22:31:15 -0800
Thread-Topic: [apps-discuss] Proposed "spfbis" working group charter
Thread-Index: Acyik8ou1EOvgCioQIGY/4BNOhoYHQAAxINg
Message-ID: 
References: <201111140546.pAE5k1aW035215@medusa.blackops.org> <4EC0B043.2060907@it.aoyama.ac.jp>
In-Reply-To: <4EC0B043.2060907@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [apps-discuss] Proposed "spfbis" working group charter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 06:31:19 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiAiTWFydGluIEouIETDvHJzdCIg
W21haWx0bzpkdWVyc3RAaXQuYW95YW1hLmFjLmpwXQ0KPiBTZW50OiBTdW5kYXksIE5vdmVtYmVy
IDEzLCAyMDExIDEwOjA4IFBNDQo+IFRvOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+IENjOiBhcHBz
LWRpc2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFByb3Bvc2Vk
ICJzcGZiaXMiIHdvcmtpbmcgZ3JvdXAgY2hhcnRlcg0KPiANCj4gSSdtIHNvbWV3aGF0IHN1cnBy
aXNlZCB0aGF0IHRoZXJlIGlzIGEgbG9uZyBjaGFydGVyIHRleHQsIGJ1dCBpdCBlbmRzDQo+IGVz
c2VudGlhbGx5IHdpdGggIndoYXQgd2UnbGwgZG8gaXMgaW4gZHJhZnQgZm9vIi4gSSB0aGluayB0
aGUgIndoYXQNCj4gd2UnbGwgZG8iIGlzIHRoZSBjb3JlIG9mIHRoZSBjaGFydGVyLCBhbmQgc2hv
dWxkbid0IGJlIGp1c3QgYQ0KPiByZWZlcmVuY2UuDQoNCkl0IHdhcyBicm91Z2h0IHRvIG15IGF0
dGVudGlvbiB0aGF0IHlvdSBtaWdodCBiZWxpZXZlIHRoZSB3b3JraW5nIGdyb3VwJ3Mgc2NvcGUg
aXMgZGVmaW5lZCBpbiB0aGUgIi1zY29wZSIgZHJhZnQuICBJdCdzIG5vdDsgdGhhdCBkb2N1bWVu
dCBwcm9wb3NlcyBhbiBleHRlbnNpb24gdG8gU1BGIGNhbGxlZCAic2NvcGUiLCBidXQgZG9lc24n
dCBjb250YWluIGFueSBzY29wZSBkZWZpbml0aW9uIGZvciB0aGUgcHJvcG9zZWQgd29ya2luZyBn
cm91cC4NCg0KLU1TSw0K

From duerst@it.aoyama.ac.jp  Sun Nov 13 22:58:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEE611E80BD for ; Sun, 13 Nov 2011 22:58:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.595
X-Spam-Level: 
X-Spam-Status: No, score=-99.595 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUkkQx8nEPKs for ; Sun, 13 Nov 2011 22:58:03 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id A047111E80B8 for ; Sun, 13 Nov 2011 22:58:03 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAE6vquh031697 for ; Mon, 14 Nov 2011 15:57:54 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 73af_273a_f8b281ea_0e8d_11e1_aa25_001d096c566a; Mon, 14 Nov 2011 15:57:52 +0900
Received: from [IPv6:::1] ([133.2.210.1]:38218) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 14 Nov 2011 15:57:52 +0900
Message-ID: <4EC0BBEE.4050201@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 15:57:50 +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: "Murray S. Kucherawy" 
References: <201111140546.pAE5k1aW035215@medusa.blackops.org>	<4EC0B043.2060907@it.aoyama.ac.jp> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Proposed "spfbis" working group charter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 06:58:04 -0000

On 2011/11/14 15:31, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp]
>> Sent: Sunday, November 13, 2011 10:08 PM
>> To: Murray S. Kucherawy
>> Cc: apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] Proposed "spfbis" working group charter
>>
>> I'm somewhat surprised that there is a long charter text, but it ends
>> essentially with "what we'll do is in draft foo". I think the "what
>> we'll do" is the core of the charter, and shouldn't be just a
>> reference.
>
> It was brought to my attention that you might believe the working group's scope is defined in the "-scope" draft.  It's not; that document proposes an extension to SPF called "scope", but doesn't contain any scope definition for the proposed working group.

Yes indeed. I read:

	* Extensions to SPF other than the one specified in the "scope"
	  document.  The working group will re-charter to process other
	  specific proposed extensions as they are identified.

So I though that what's in the scope document is in scope, and other 
things are out of scope, so the scope document defines the WG scope.

If that's not the case, I propose to rewrite the above to:

	* Extensions to SPF other than the "scope" extension (see
           draft-...)  The working group will re-charter to process other
	  specific proposed extensions as they are identified.

Actually, the fact that the "scope" extension is in-scope should be 
mentioned before the list of scope exclusions, it shouldn't be included 
as a side-effect of the exclusions.

Regards,    Martin.

From msk@cloudmark.com  Sun Nov 13 23:05:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA85811E8232 for ; Sun, 13 Nov 2011 23:05:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.308
X-Spam-Level: 
X-Spam-Status: No, score=-103.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, 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 xyhlHYhi1prg for ; Sun, 13 Nov 2011 23:05:35 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 25A8A11E822C for ; Sun, 13 Nov 2011 23:05:25 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 13 Nov 2011 23:05:13 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Sun, 13 Nov 2011 23:05:10 -0800
Thread-Topic: [apps-discuss] Proposed "spfbis" working group charter
Thread-Index: Acyimr5FWTwVmgqjRBK2C+cdULs7uwAAPG6A
Message-ID: 
References: <201111140546.pAE5k1aW035215@medusa.blackops.org> <4EC0B043.2060907@it.aoyama.ac.jp>  <4EC0BBEE.4050201@it.aoyama.ac.jp>
In-Reply-To: <4EC0BBEE.4050201@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [apps-discuss] Proposed "spfbis" working group charter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 07:05:36 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiAiTWFydGluIEouIETDvHJzdCIg
W21haWx0bzpkdWVyc3RAaXQuYW95YW1hLmFjLmpwXQ0KPiBTZW50OiBTdW5kYXksIE5vdmVtYmVy
IDEzLCAyMDExIDEwOjU4IFBNDQo+IFRvOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+IENjOiBhcHBz
LWRpc2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFByb3Bvc2Vk
ICJzcGZiaXMiIHdvcmtpbmcgZ3JvdXAgY2hhcnRlcg0KPiANCj4gSWYgdGhhdCdzIG5vdCB0aGUg
Y2FzZSwgSSBwcm9wb3NlIHRvIHJld3JpdGUgdGhlIGFib3ZlIHRvOg0KPiBbLi4uXQ0KDQpUaGFu
a3M7IEkndmUgbWFkZSB5b3VyIGNoYW5nZXMgaW4gdGhlIHdvcmtpbmcgY29weS4NCg0KLU1TSw0K

From duerst@it.aoyama.ac.jp  Sun Nov 13 23:09:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253D911E8240 for ; Sun, 13 Nov 2011 23:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.599
X-Spam-Level: 
X-Spam-Status: No, score=-99.599 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSmfdb-8tIaA for ; Sun, 13 Nov 2011 23:09:24 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E356F11E823D for ; Sun, 13 Nov 2011 23:09:20 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAE79K3C007430 for ; Mon, 14 Nov 2011 16:09:20 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 73ad_1cc7_9299c4b6_0e8f_11e1_aa25_001d096c566a; Mon, 14 Nov 2011 16:09:20 +0900
Received: from [IPv6:::1] ([133.2.210.1]:44953) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 14 Nov 2011 16:09:19 +0900
Message-ID: <4EC0BE9E.8020702@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 16:09:18 +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: Larry Masinter 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 07:09:25 -0000

Hello Larry,

On 2011/11/14 3:59, Larry Masinter wrote:
> I'd like to discuss the proposal for MIME registrations from Roy Fielding in http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html
> and the possibility that such changes should also apply to URI schemes.
>
> You can read Roy's rationale, which makes sense to me,

Some of it makes quite a bit of sense to me, but the first thing that 
doesn't make sense to me is the title of your mail. The proposal seems 
rather radical, not modest.

> but my summary is:
>
> * Eliminate standards, vendor, personal trees distinction for MIME types (For URI schemes, eliminate distinction between provisional and permanent schemes)
> * ENCOURAGE vendors to ship with vendor-neutral short-named types regardless of whether they have been registered yet or not;

I think that makes sense for something widely known and used (e.g. 
application/pdf), but not necessarily for some really company-specific 
type. (Of course, we don't know in advance which way something may go in 
the end, but we could use this rule at least for when the company e.g. 
wants to express that a type is NOT intended for general use).

>     ENCOURAGE the public to register any names that they have seen in deployed software. (same for URI schemes)

I think third-party registration is indeed something we should encourage 
more.

> * DO NOT try to avoid duplicates

I'm not sure this makes sense. I think it would make sense if it read 
"give up on trying to avoid duplicates at all cost". But it almost reads 
like "let's have many duplicates, this will be fun".

> * EXPERT REVIEW for updates to existing registrations
> * Eliminate any IESG or consensus review requirement
>
> "There is absolutely no need to prevent name collisions in the registry itself because those collisions are irrelevant -- what matters is how the names are interpreted by recipients of messages."

Well, but isn't one goal of the effort to get the registry to (more 
closely) reflect reality? In this case, if there are two 
application/foo, and applications recognize one and not the other, then 
there's a disconnect.

Regards,   Martin.

> "There is absolutely no need to prevent people who are not the owners of a media type from registering that type without any prefixes."
> "The registry is not operable -- it is just documentation of how the Internet is operating, and it should reflect the reality of that operation even if that means we have multiple definitions per registered type."
>
> I find this perspective appealing, and can't find anything wrong with it except that it's a break with tradition. If you're at IETF this week and want to talk about it, find me.
>
> Larry
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From barryleiba.mailing.lists@gmail.com  Sun Nov 13 23:09:31 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C2B11E823C for ; Sun, 13 Nov 2011 23:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.748
X-Spam-Level: 
X-Spam-Status: No, score=-102.748 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 22KMu0GNGVfX for ; Sun, 13 Nov 2011 23:09:30 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA6B011E8240 for ; Sun, 13 Nov 2011 23:09:29 -0800 (PST)
Received: by ggnr5 with SMTP id r5so624810ggn.31 for ; Sun, 13 Nov 2011 23:09:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VWi1XtygNQlqnQzgmhYpMJAn9nqxyKwM6x1bBL41qe4=; b=ffzeBr1LmL5iFv0qnNVBT+LfRtmIWPgJVdcZAWMlX2NpIlWSlOy1xx+HnbxtgMTybM gcl8jRVz/dFCVu66Dos05Z5dN3vlAKqP/b7ktaf2mE0xnUgLe9IRZRr4vKqkomYw0/t7 qiuC1wxGGytzzVO3+R7xXkSmMHGG5QK9Gi9SM=
MIME-Version: 1.0
Received: by 10.146.34.4 with SMTP id h4mr1608390yah.16.1321254569317; Sun, 13 Nov 2011 23:09:29 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.250.14 with HTTP; Sun, 13 Nov 2011 23:09:29 -0800 (PST)
In-Reply-To: <4EC0BBEE.4050201@it.aoyama.ac.jp>
References: <201111140546.pAE5k1aW035215@medusa.blackops.org> <4EC0B043.2060907@it.aoyama.ac.jp>  <4EC0BBEE.4050201@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 02:09:29 -0500
X-Google-Sender-Auth: _9uxU8OwgzpdRczcuM-aDWfqEfI
Message-ID: 
From: Barry Leiba 
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Proposed "spfbis" working group charter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 07:09:31 -0000

> Actually, the fact that the "scope" extension is in-scope should be
> mentioned before the list of scope exclusions, it shouldn't be included as a
> side-effect of the exclusions.

I have this image of a bunch of Vikings in a Monty Python sketch, all
sitting around chanting, "Scope, scope, scope, scope, scope, scope,
scope, scope...."

Barry

From duerst@it.aoyama.ac.jp  Sun Nov 13 23:14:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E8511E8247 for ; Sun, 13 Nov 2011 23:14:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.603
X-Spam-Level: 
X-Spam-Status: No, score=-99.603 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMNKupO-OTC7 for ; Sun, 13 Nov 2011 23:14:02 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2CD11E8246 for ; Sun, 13 Nov 2011 23:13:59 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAE7DpCE010560 for ; Mon, 14 Nov 2011 16:13:51 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 73b4_4f93_33f983f0_0e90_11e1_aa25_001d096c566a; Mon, 14 Nov 2011 16:13:50 +0900
Received: from [IPv6:::1] ([133.2.210.1]:34618) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 14 Nov 2011 16:13:50 +0900
Message-ID: <4EC0BFAD.8060501@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 16:13:49 +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: "Paul E. Jones" 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>	<4EBD6266.6030307@gmail.com>	<023801cca0ca$d9860a20$8c921e60$@packetizer.com>	<4EBE04C7.5090400@gmail.com> <015301cca232$75ea36d0$61bea470$@packetizer.com>
In-Reply-To: <015301cca232$75ea36d0$61bea470$@packetizer.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 07:14:03 -0000

Hello Paul,

You can also have a look at RFC http://tools.ietf.org/html/rfc6068 and 
http://tools.ietf.org/html/draft-duerst-eai-mailto-01.

If I understand the acct: scheme correctly, it should be possible to 
make the syntax a subset of mailto:.

Regards,    Martin.

On 2011/11/14 3:31, Paul E. Jones wrote:
> Mykyta,
>
>
>
> I fear this might get complicated with references to the email documents.  Those documents are trying to solve a real problem, but Webfinger does not have some of those historical constraints.
>
>
>
> Here’s my proposal: let’s not reference 5335 or 5322.  Rather, let’s only reference the generic URI syntax spec (RFC 3986).  Let’s define the URI scheme using the syntax found there:
>
>     acctURI   = "acct:" userinfo "@" host
>
>
>
> The productions “userinfo†and “host†are already defined.  Perhaps the one thing I don’t like is that “host†might be an IP address, but perhaps some people prefer that.
>
>
>
> RFC 3986 already says that these components are UTF-8 encoded and then percent-escaped when a character is outside the ASCII character set range.
>
>
>
> Would this be a suitable replacement for the current text?
>
>
>
> With respect to your comments on link relations and URIs, I still do not understand.  You say that “nobody will benefit from link relation types defined by URIsâ€, but why not?  There are several already define and used today.  In any case, I would prefer that all link relation values (URI or simple strings) be defined outside of the Webfinger draft.  As I mentioned, there is already a registry, so one can be proposed any time.
>
>
>
> Paul
>
>
>
> From: "Mykyta Yevstifeyev (Ğœ. ЄвÑтіфеєв)" [mailto:evnikita2@gmail.com]
> Sent: Saturday, November 12, 2011 12:32 AM
> To: Paul E. Jones
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Webfinger
>
>
>
> Hello Paul,
>
> 12.11.2011 1:37, Paul E. Jones wrote:
>
> Mykyta,
>
>
>
> Thanks for your positive response.
>
>
>
> To your specific questions…
>
>
>
> We would definitely want to ensure that Unicode is properly supported.  In wasn’t aware of RFC 5335, so I’m glad you brought that to my attention.  Do you have a pointer to the bis draft so I can see exactly what is there?  I’d be fully in favor of using utf8-addr-spec.
>
>
> This is http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13.  But please note that this document, unlike RFC 5335, introduced UTF-8 additions to *base* RFC 5322 productions.  This means that  will be defined as follows now:
>
>
>
>
>     addr-spec       =   local-part "@" domain
>     local-part      =   dot-atom / quoted-string / obs-local-part
>     domain          =   dot-atom / domain-literal / obs-domain
>     domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
>     dtext           =   %d33-90 /          ; Printable US-ASCII
>                         %d94-126 /         ;  characters not including
>                         obs-dtext          ;  "[", "]", or "\"
>     dtext           =/  UTF8-non-ascii     ; from 5335bis
>     dot-atom        =   [CFWS] dot-atom-text [CFWS]
>     dot-atom-text   =   1*atext *("." 1*atext)
>     atext           =/  UTF8-non-ascii     ; from 5335bis
>
>
> So everything you will have to do is to have a note on 'acct' RI being possible to carry UTF8 characters and therefore being possibly IRIs.
>
>
>
>
>
>
> Link relation types might be names like “copyright†or they might be URIs.  The definition of the link relation types is outside the scope of the Webfinger document itself.  RFC 6415 defines the structure of the documents and provides examples of some link relations and the order of processing.  RFC 5988 defines the link relations more generically and establishes the registry for them.  Do you think we need to say more about link relations beyond what those documents cover?
>
>
> I mean that Webfinger will have to operate on a variety of link relations in LRDD documents, and nobody will benefit from link relation types defined by URIs used there, as this eliminates the possibility for automatic processing.  So I ask whether we'll have to define non-URI link relation types for all the possible Webfinger use-cases?
>
>
>
>
>
>
> On section 4: noted.  We’ll try to clearly separate the normative and non-normative pieces better.
>
>
> Thanks.
>
>
>
>
>
>
> On  CORS, there are some who have strongly advocated for it.  It would be very useful to allow JavaScript code to perform these queries.  Otherwise, the queries would have to be pushed to server-side code.  Let’s wait on deciding what to do until we get a definitive answer on CORS from the W3C.  I think Peter was going to do some investigating there.
>
>
>
> Putting Webfinger into vcard: isn’t that circular?  The idea with Webfinger is that you have the identity of the user (e.g., paulej@packetizer.com), but you want to find more information.  If you have a vcard, then you have the user’s identity (via the email tag).  Or are you suggesting that we formally introduce the acct URI in vcard?  That might make sense to do.  Can you clarify your proposal?
>
>
>> From RFC 6350, Section 6.4.2:
>
>
>
>
> 6.4.2. EMAIL
>
>     Purpose:  To specify the electronic mail address for communication
>        with the object the vCard represents.
>
>
> ...and the use might have email address different from Webfinger ID.  I've already pointed to http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00, which VCARDDAV WG works on, and so you may try to introduce some similar property for Webfinger IDs.  (You see, vCards may not carry all the variety of information, though some people actually think in other way, and thus it would be a good idea to provide a means of accessing some additional info.)
>
>
>
>
>
>
> For comments on particular sections, I’ve added notes to each one to revise them as you suggest: they’re all good suggestions.
>
>
> Yes, thanks as well.
>
>
>
>
>
>
> I would very much like to make this a WG item, of course, but none of the authors will be present at this IETF meeting.  Perhaps hallway dialog might take place, but not sure.  In any case, we can do this via the mailing list, too.
>
>
> See Barry's note on this.
>
>
>
>
>
>
> Thanks!
>
> Paul
>
>
> All the best,
> Mykyta Yevstifeyev
>
>
>
>
>
>
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of "Mykyta Yevstifeyev (?. ?????????)"
> Sent: Friday, November 11, 2011 12:59 PM
> To: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Webfinger
>
>
>
> Hi Paul and all,
>
> I think you contributed a very interesting proposal indeed.  Really, RFC 1288 finger protocol is now outdated, and you're right claiming that it provides no means of automatic processing.  BTW, RFC 1288 is currently at Draft Standard maturity level, which has been abandoned by RFC 6410, and we should therefore undertake something with this respect, as should we with respect of other Apps-related DSs, but that is what is to be discussed separately.
>
> With respect to proposed 'acct' URI scheme:  how are you going to handle internationalization (i18n)?  We have RFC 5335 defining  (Experimental RFC) and IESG has already approved EAI 5335bis, that will be Standards Track.  So will  be allowed in 'acct' URIs in some way?
>
> Webfinger implies use of some link relations.  Is it anticipated that URIs will be used as link relations types, or we'll need to define link relation types for all possible use-cases of Webfinger?
>
> Your Section 4 seems to be somewhat narrative.  I propose to divide it into normative specification and examples.
>
> With regard to CORS - I'm not actually acquainted with this technology, but I see it is currently documented as W3C working draft, so I don't suspect it is now widely-used (I may of course be wrong, so please feel free to correct me), and I think there is no use putting MUST requirement on its use in Webfinger.  You could better remove your section on CORS from the document at all.
>
> I think we should also provide some means of mentioning Webfinger accounts in vCards.  You could please see VCARDDAV document http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 which Webfinger elements may also be incorporated.
>
> In Abstract, you should be more specific about what your document defines.  I propose mentioning directly that the document is the specification of Webfinger protocol, not "procedures for dicovering information about people".
>
> In Section 7 you should clearly state that Webfinger (so as finger itself) is intentionally left w/o any means of controlling access to information (unless we want to produce *such* protocol).
>
> I see the document is on APPSAWG agenda on the meeting, so I anticipate it will soon become APPSAWG item doc.  I won't be on meeting, but if you discuss the adaptation of Webfinger draft please also take into account I'm in favor of such adaptation (consider this as my 2p).
>
> Mykyta Yevstifeyev
>
> 24.10.2011 23:09, Paul E. Jones wrote:
>
> Folks,
>
>
>
> We just submitted this:
>
> http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt
>
>
>
> The tools for Webfinger are now defined, but the procedures need to be clearer with respect to what most of us understand as “webfingerâ€.  This is just a first stab at making that happen and we hope to progress this to publish an RFC in the application area.
>
>
>
> We welcome any comments you have on the topic, either privately or publicly.
>
>
>
> Paul
>
>
>
>
>
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
>
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From duerst@it.aoyama.ac.jp  Sun Nov 13 23:27:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA42021F8CA4 for ; Sun, 13 Nov 2011 23:27:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.607
X-Spam-Level: 
X-Spam-Status: No, score=-99.607 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Y9XhPZuAXPh for ; Sun, 13 Nov 2011 23:27:08 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E805721F8CA3 for ; Sun, 13 Nov 2011 23:27:06 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAE7R63W019668 for ; Mon, 14 Nov 2011 16:27:06 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 73a4_0656_0df60280_0e92_11e1_aa25_001d096c566a; Mon, 14 Nov 2011 16:27:06 +0900
Received: from [IPv6:::1] ([133.2.210.1]:38530) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 14 Nov 2011 16:27:05 +0900
Message-ID: <4EC0C2C8.2010500@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 16:27:04 +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: Larry Masinter 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: David Singer , "apps-discuss@ietf.org" , "gadams@xfsi.com" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 07:27:08 -0000

Hello Larry,

On 2011/11/13 5:25, Larry Masinter wrote:
> I see no use case for why having font/opentype is any better than application/opentype

It's just fine if you, and some others, don't see it. Does that mean 
that you have to fight against it? You haven't shown, even less 
mentioned, any problem for font/opentype.

My guess is that we would have around 10 or so font types registered 
(and no font type sniffing) if a font/ top level type had been approved 
in a 1990'ish timeframe.

> The only use case I can imagine from looking at
> http://tools.ietf.org/html/draft-singer-font-mime-00
> is the possibility of defining common parameters across font data types (in the same way that text/.. has a common charset parameter).
>
> But there isn't really any common processing proposed that one could do knowing that you have font/x... so I agree with Graham that there isn't a case for font/.

Well, actually, if an OS has a capability of "install that font 
[temporarily] for me", and the OS knows which formats it can handle, 
then that would be a good use case, isn't it?

Also, the use case of easier searching, and the use case of content 
negotiation (font/*) was mentioned.


> The arguments in favor seem to be of the form "well, we allow for new top level types, so why not use it?"

That's definitely an argument, in particular because for the people 
concerned, font/ looks very parallel to image/, video/, audio/,...


> I also recall a number of years ago an attempt to define "chemical/*" as a new top level type for use in defining file formats?

So what? Were there good reasons to reject it? Or was it rejected 
because some people believed that new top level types were "A BIG 
NO-NO"? Or because of some FUD?

> My conclusion from this discussion is that we should declare the MIME hierarchy closed to new top level types; we've only gotten very limited use and value out of the hierarchy, compared to the pain and difficulty (text/xml vs application/xml).

The problems between text/xml and application/xml are very specific. And 
they may be interpreted to say that tying particular processing rules to 
particular types, unless absolutely necessary (e.g. structured types), 
may be a bad idea. That doesn't mean that top-level types in general are 
a bad idea.

The reason that we have gotten very little value out of registering new 
top level types may be mostly that virtually no new types have been 
registered, because people are claiming that we get very little value 
out of them. It sounds funny, but it isn't.


Regards,   Martin.

From duerst@it.aoyama.ac.jp  Sun Nov 13 23:31:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7672F21F8531 for ; Sun, 13 Nov 2011 23:31:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.311
X-Spam-Level: 
X-Spam-Status: No, score=-99.311 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 T38hMLXtCJnq for ; Sun, 13 Nov 2011 23:31:51 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 49D8821F8432 for ; Sun, 13 Nov 2011 23:31:51 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAE7VaXD022839 for ; Mon, 14 Nov 2011 16:31:36 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 73ab_17ae_aeff7fd0_0e92_11e1_aa25_001d096c566a; Mon, 14 Nov 2011 16:31:36 +0900
Received: from [IPv6:::1] ([133.2.210.1]:36012) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 14 Nov 2011 16:31:36 +0900
Message-ID: <4EC0C3D6.1070506@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 16:31:34 +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: "t.petch" 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>	<60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>	<4EB9D49C.5010100@it.aoyama.ac.jp><4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net> <4EBBABC1.1010101@it.aoyama.ac.jp> <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net>
In-Reply-To: <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 07:31:52 -0000

Hello Tom, others,

On 2011/11/12 20:27, t.petch wrote:

> But more significantly, as other posts have clarified for me, this thread
> is nothing to do with fonts but with type definition languages, so perhaps
> it should be 'type/*'.

Perhaps it should be type/* or fontformat/* or whatever. But most 
probably it should be font/. Because the people who are working on this 
repeatedly have asked for font/*, and never for type/*, and never for 
fontformat/* or some such.

Regards,   Martin.

From duerst@it.aoyama.ac.jp  Sun Nov 13 23:36:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3EA11E80C2 for ; Sun, 13 Nov 2011 23:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.608
X-Spam-Level: 
X-Spam-Status: No, score=-99.608 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzQFBaJ04hZR for ; Sun, 13 Nov 2011 23:36:03 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9687311E80B6 for ; Sun, 13 Nov 2011 23:36:02 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAE7a16C025943 for ; Mon, 14 Nov 2011 16:36:01 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 73af_28bc_4d488db2_0e93_11e1_aa25_001d096c566a; Mon, 14 Nov 2011 16:36:01 +0900
Received: from [IPv6:::1] ([133.2.210.1]:40639) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 14 Nov 2011 16:36:01 +0900
Message-ID: <4EC0C4E0.9000304@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 16:36:00 +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: Tony Hansen 
References: <4EB86078.8070904@stpeter.im>		<4EB8D0F4.9020907@it.aoyama.ac.jp>	<555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com>	<60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net>	<4EB9D49C.5010100@it.aoyama.ac.jp><4EBB2FEA.5060602@dcrocker.net>	<4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net>	<00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net>	<4EBBABC1.1010101@it.aoyama.ac.jp>	<003201cca12e$1f35f860$4001a8c0@gateway.2wire.net> <4EBF15DD.4050801@att.com>
In-Reply-To: <4EBF15DD.4050801@att.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 07:36:03 -0000

On 2011/11/13 9:57, Tony Hansen wrote:

> I've seen several hints of wanting to do web Accept-style queries along
> the line of
>
> Accept: font/arial, font/comicsans

Where did you see that?

> What is it that is really desired?
>
> While this sounds like it might be a nice capability,

It's a nice capability, but it's something for search engines, not for 
content negotiation.


> it really doesn't
> agree with what media types are all about.

Of course not.

> The Arial font can be
> described in many different font file formats.
>
> Media types are more for describing things like:
> MMMM/datafork-truetype
> MMMM/intellifont
> MMMM/postscriptfont
> MMMM/truedocfont
> MMMM/truetype
> MMMM/webopenfont
>
> (where MMMM is some prefix yet to be determined), within which you can
> have a description of many different fonts, including Arial and ComicSans.
>
> =======
>
> *IF* we were to define a top-level media type, I do *not* think it
> should be named "font", but instead should name it "fontformat" or
> something like that. I think naming it "font" just leads people to have
> false expectations.

I don't think so. At least once there are a few registrations, things 
should be clear. As Julian pointed out, it hasn't be a problem for 
image/, video/, ...

Regards,    Martin.


> =======
>
> I notice that if "application" were used for font format file names,
> some of the font format names would need to include the word "font" as
> part of the name. For example, "application/postscript" can not be used
> for the font format defined in the postscript standard. Instead, it
> would have to be "application/postscriptfont". This *could* be taken an
> argument for using "fontformat" as a top level type, as in
> "fontformat/postscript". However, I don't find it a convincing argument
> by itself.
>
> Tony Hansen
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From stpeter@stpeter.im  Mon Nov 14 00:09:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D39011E8277 for ; Mon, 14 Nov 2011 00:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.216
X-Spam-Level: 
X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=-0.617, 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 2a9reQ8fU688 for ; Mon, 14 Nov 2011 00:09:24 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 57B2F11E8275 for ; Mon, 14 Nov 2011 00:09:24 -0800 (PST)
Received: from dhcp-13ac.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 698CA404FF; Mon, 14 Nov 2011 01:15:32 -0700 (MST)
Message-ID: <4EC0CCAE.5070402@stpeter.im>
Date: Mon, 14 Nov 2011 16:09:18 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ned Freed 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com> <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com> <4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com>
In-Reply-To: <01O8AM6GDT5000RCTX@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] type name suffixes (was: Re:  font/*)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 08:09:25 -0000

On 11/12/11 4:46 AM, Ned Freed wrote:
>> On 2011/11/11 1:23, Ned Freed wrote:
>
>> >> On 2011/11/10 13:06, Ned Freed wrote:
>
>> >> > In practice the issue of what to register where has never been much
>> >> of a
>> >> > problem. Speaking now as media types reviewer, I have not
>> infrequently
>> >> > pushed
>> >> > back on top-level type choices, usually successfully and always
>> >> amicably.
>> >
>> >> Do you know of any examples? This could help Dave with the general
>> list
>> >> of criteria that he wants to develop.
>> >
>> > I can't get into specifics without talking about the content of
>> > preliminary registration requests, which I try not to do. I can say
>> that
>> > the most common one has been someone asking for application when
>> image or
>> > video would be more appropriate.
>> >
>> > The most common name change I request, however, is the addition of
>> +xml.
>
>> Okay. This is about change from one existing top-level type to another,
>> and about tweaking the minor type name with a suffix.
>
> Understood. Both things happen. As I said, the most common top level change
> is from application to image or video. Next up would probably moves from
> text to application, but come to think of it I haven't have one of those
> in a while.
>
>> Out of the context
>> of the discussion, I thought that you were speaking about new top-level
>> types when you wrote "I have not infrequently pushed back on top-level
>> type choices", but now I see that that's not a necessary interpretation.
>
> I was simply noting that the most common change isn't a top-level
> change, but
> rather the addition of +xml. My apologies if that was confusing.

I notice that draft-freed-media-type-regs-01 talked about structured 
type name suffixes (e.g., "+xml") and calls for creation of a registry 
for such suffixes. Ned, do you have thoughts on how people can more 
easily define such suffixes, before draft-freed-media-type-regs (or 
something like it) is approved? The reason I ask is that I've had a few 
people ask me about this topic recently.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From yutaka-oiwa-aist-temp@g.oiwa.jp  Mon Nov 14 00:19:43 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C4011E80B9 for ; Mon, 14 Nov 2011 00:19:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.477
X-Spam-Level: 
X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 eYkHlYd+XE1Q for ; Mon, 14 Nov 2011 00:19:39 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFE6E11E80C5 for ; Mon, 14 Nov 2011 00:19:38 -0800 (PST)
Received: by gye5 with SMTP id 5so5607515gye.31 for ; Mon, 14 Nov 2011 00:19:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.156.5 with SMTP id l5mr12542310yhk.29.1321258776703; Mon, 14 Nov 2011 00:19:36 -0800 (PST)
Sender: yutaka@g.oiwa.jp
X-Google-Sender-Delegation: yutaka@g.oiwa.jp
Received: by 10.150.197.13 with HTTP; Mon, 14 Nov 2011 00:19:36 -0800 (PST)
In-Reply-To: <3615F3CCD55F054395A882F51C6E5FDA181FFC67@szxeml513-mbx.china.huawei.com>
References: <20111018234005.22724.87290.idtracker@ietfa.amsl.com>    <3615F3CCD55F054395A882F51C6E5FDA181FFC67@szxeml513-mbx.china.huawei.com>
Date: Mon, 14 Nov 2011 17:19:36 +0900
X-Google-Sender-Auth: bkNi1GsUF3s9GxIBzRCPoCOKVFo
Message-ID: 
From: Yutaka OIWA 
To: TianLinyi 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: httpbis Group , Apps Discuss 
Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-new-status-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 08:19:43 -0000

401 is a specific status code for kicking in *HTTP* authentication.
It requires servers to supply an appropriate WWW-Authenticate header.
It seems to be not a "general status code" of your sense.

The proposed 511 is a status code in general 5XX category,
indicating that there is no way at HTTP level to successfully
complete the request at this moment, due to some server-side reason.
The 511 status carries a "hint", in addition to usual 5XX statuses,
to clients that the provided response is not supplied directly
from the requested peer, and some man-in-the-middle has
refused to forward a request without some more user
interactions (usually an application-level authentication or payments).
Such interactions are performed in some higher protocol layer than HTTP.

2011/11/14 TianLinyi :
> Hi, Mark
>
> I am wondering the relationship betwen "511 Network Authentication Requir=
ed" and " 401 Unauthorized". 401 is a general status code for requiring use=
r authentication. However "requiring network access" may be part of the sem=
entics of user authentication. How to clearly distinguish them?
>
> In the description it mentioned the following sentence:
> The response representation SHOULD indicate how to do this; e.g.,
> =A0 with an HTML form for submitting credentials.
> However it is clear how to do this? Will it be leaving to implementation =
(e.g. the parameters included in the HTML form)?
>
> Cheers,
> Linyi
>
> On 13/11/2011, at 8:33 PM, Randall Gellens wrote:
>
>> In today's APPAREA/APPSWG session, Mark briefly talked about this
>> draft, and when mentioning the 511 code, said that his intent was not
>> to encourage captive portal interception as a technique for network
>> access authorization or authentication, but rather to reduce the harm
>> that such mechanisms cause.
>>
>> I agree with all these goals, but in looking at
>> draft-nottingham-http-new-status-03.txt, I wonder if it would be
>> helpful to add some text in section 6 that mentions some of the ill
>> effects of the method, and mentions or points to a few better
>> alternative mechanisms for authorizing network access.
>
>
>>
>> --
>> Randall Gellens
>> Opinions are personal; =A0 =A0facts are suspect; =A0 =A0I speak for myse=
lf only
>> -------------- Randomly selected tag: ---------------
>> Hofstadter's Law:
>> =A0 It always takes longer than you expect, even when you take
>> =A0 Hofstadter's Law into account.
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



--=20
--
Yutaka OIWA, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 Research Scientist
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Research Center for =
Information Security (RCIS)
=A0 =A0National Institute of Advanced Industrial Science and Technology (AI=
ST)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mail addresses: , 
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D =A03139 8677 9BD2 4405 46=
B5]

From rg+ietf@qualcomm.com  Mon Nov 14 00:20:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BD311E80D3 for ; Mon, 14 Nov 2011 00:20:33 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -106.273
X-Spam-Level: 
X-Spam-Status: No, score=-106.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, 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 VjhzHjSEJFep for ; Mon, 14 Nov 2011 00:20:31 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id BF58711E80C6 for ; Mon, 14 Nov 2011 00:20:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=rg+ietf@qualcomm.com; q=dns/txt; s=qcdkim; t=1321258830; x=1352794830; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:content-type:x-random-sig-tag; z=Message-Id:=20 |In-Reply-To:=20<4EC0AD84.5060502@dcrocker.net> |References:=20<20111024161910.8048.2279.idtracker@ietfa. amsl.com>=0D=0A=20=20 <4EC0AD84.5060502@dcrocker.net>|X-Mailer:=20Eudora=20for =20Mac=20OS=20X|Date:=20Mon,=2014=20Nov=202011=2000:11:36 =20-0800|To:=20|From:=20Randall=20Gell ens=20|Subject:=20Re:=20[apps-discu ss]=20I-D=20Action:=20draft-ietf-appsawg-xdash-02.txt|Cc: =20=20Peter=20Saint-Andre=20,=20Dave =20Crocker=20,=0D=0A=20=20=20=20=20=20 =20=20Mark=20Nottingham=20,=20|Content-Type:=20text/plain=3B=20charset=3D"us -ascii"=20=3B=20format=3D"flowed"|X-Random-Sig-Tag:=201.0 b28; bh=kWg8b4K9TJPbDTHj/FrsaTpwcS9rl/dGLOY/btdMoTo=; b=G5WVJgQ5ZglDTtBJONLtvD0l07urbvoBROA/DS763X7bpzby1XyRn4yH QiAiutRjua0YXnVDFcDTrgIccKaN82cDjR+JyOA/S4kypIdKzIlbHOTnY p/NpDyV/sARorY83TVwY0EkzVpENoqyEbZMJdumT/gRHzDoiPsjznBFwL s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6529"; a="137362622"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 14 Nov 2011 00:20:29 -0800
X-IronPort-AV: E=Sophos;i="4.69,504,1315206000"; d="scan'208";a="112898915"
Received: from warlock.qualcomm.com ([129.46.50.49]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2011 00:20:16 -0800
Received: from [172.21.1.9] (myvpn-r-03258.ras.qualcomm.com [10.64.10.48]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id pAE8K8Bb010076; Mon, 14 Nov 2011 00:20:09 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4EC0AD84.5060502@dcrocker.net>
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com>  <4EC0AD84.5060502@dcrocker.net>
X-Mailer: Eudora for Mac OS X
Date: Mon, 14 Nov 2011 00:11:36 -0800
To: 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
Cc: apps-discuss@ietf.org, Mark Nottingham , Dave Crocker 
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 08:20:33 -0000

At 1:56 PM +0800 11/14/11, Dave CROCKER wrote:

>  On 11/14/2011 10:00 AM, Randall Gellens wrote:
>>  To me, this text points out that sometimes people slap together an 
>> ad-hoc "x-"
>>  parameter, and later go for a standard version, which after wider review is
>>  modified to address security or other issues; the text notes that if this
>
>  I think the essence of what you've cited is that the later process 
> produces a revised specification.  Hence, what is produced is not 
> the same thing as was getting used.  Unfortunately the implication 
> is a practise of re-using the name without any version indication, 
> which is generally frowned upon, protocol technique-wise...

Right, but the answer, I think, is to use a different name for the 
standardized version, not to do away with wider review.

We saw this in the past few years with IMAP extensions, where a 
proposal used a capability name for the I-D versions, and a new 
capability name for the RFC.

>
>
>>  I can't help but think that we'd be better off with a middle 
>> ground, similar to
>>  "vnd." namespace, for ad-hoc parameters that might or might not be 
>> standardized,
>>  but that clearly have not been through IETF consensus.
>
>  Yuch.

Why?  There are a number of situations where it would be helpful to 
have some namespace distinguisher, including where other SDOs specify 
a set of parameters (as well as case of some implementation wanting 
to use a parameter value for its own purposes).

>   > One advantage is that it
>>  provides some impetus (however slight) to develop a standard version if it's
>>  useful. Another advantage is that it might provide better clues as 
>> to the source
>>  of and change control over the ad-hoc parameter.
>
>  At base, this would continue the core model that has proved problematic.

But it would improve some of the problems of that model, and avoid 
some of the problems with just abandoning the model entirely.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Never look at the trombones, it only encourages them.
                                   --Richard Strauss

From vinayakh@gmail.com  Mon Nov 14 00:25:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA7111E80E9 for ; Mon, 14 Nov 2011 00:25:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.977
X-Spam-Level: 
X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-2.223, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345]
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 bwHWuKhv97JI for ; Mon, 14 Nov 2011 00:25:19 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B913F11E8111 for ; Mon, 14 Nov 2011 00:25:18 -0800 (PST)
Received: by vcbfk1 with SMTP id fk1so5699751vcb.31 for ; Mon, 14 Nov 2011 00:25:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y0THwkFiIyO/9xnfgEjkmr6aNoTmlLwSLKqhO1v4YG4=; b=uVGvZCyyQA3bWn+B7rtDIpSpjQt50nlt7pLcZezXRLOoevFwdo0scgWmHtScOKLNPe BnCpP065Y6bbEAPeCNmDNDnXWqSSxot0Pdig2gavDcZRDBirO4pSx/KxcfxMW0Wr5KT4 JSNN8hQcU0sYi9Bmr9YtTJWcu8xNtPcnLpiMY=
MIME-Version: 1.0
Received: by 10.52.89.206 with SMTP id bq14mr33507467vdb.39.1321259118166; Mon, 14 Nov 2011 00:25:18 -0800 (PST)
Received: by 10.52.156.226 with HTTP; Mon, 14 Nov 2011 00:25:18 -0800 (PST)
In-Reply-To: <3615F3CCD55F054395A882F51C6E5FDA181FF7DB@szxeml513-mbx.china.huawei.com>
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net> <4EBBABC1.1010101@it.aoyama.ac.jp> <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net> <4EBF15DD.4050801@att.com> <3615F3CCD55F054395A882F51C6E5FDA181FF7DB@szxeml513-mbx.china.huawei.com>
Date: Mon, 14 Nov 2011 13:55:18 +0530
Message-ID: 
From: Vinayak Hegde 
To: TianLinyi 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] =?gb2312?b?tPC4tDogZm9udC8q?=
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 08:25:19 -0000

2011/11/13 TianLinyi :
> why not define something like this:
> application/fontformat-arial
>
> define a top level type may not be needed

Media-types define the type (font/fontformat). Combining a value
(Arial) for creating a mime-type is asking for disaster.

Typically mime-types are used to identify application associations,
you will have to create an association for every single font on your
system. Now imagine adding a font using this scheme.

-- Vinayak

From dhc@dcrocker.net  Mon Nov 14 00:45:29 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7D021F8E67 for ; Mon, 14 Nov 2011 00:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHXVG38MA-1W for ; Mon, 14 Nov 2011 00:45:29 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC2C21F8E65 for ; Mon, 14 Nov 2011 00:45:29 -0800 (PST)
Received: from [130.129.82.22] (dhcp-5216.meeting.ietf.org [130.129.82.22]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAE8jDtZ007686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2011 00:45:24 -0800
Message-ID: <4EC0D517.3030400@dcrocker.net>
Date: Mon, 14 Nov 2011 16:45:11 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Randall Gellens 
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com>  <4EC0AD84.5060502@dcrocker.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 14 Nov 2011 00:45:28 -0800 (PST)
Cc: apps-discuss@ietf.org, Mark Nottingham , dcrocker@bbiw.net
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 08:45:30 -0000

On 11/14/2011 4:11 PM, Randall Gellens wrote:
> At 1:56 PM +0800 11/14/11, Dave CROCKER wrote:
>> I think the essence of what you've cited is that the later process produces a
>> revised specification. Hence, what is produced is not the same thing as was
>> getting used. Unfortunately the implication is a practise of re-using the name
>> without any version indication, which is generally frowned upon, protocol
>> technique-wise...
>
> Right, but the answer, I think, is to use a different name for the standardized
> version, not to do away with wider review.

+1

(but for clarity:  I, for one, hadn't called for doing away with wider review.)


>>> I can't help but think that we'd be better off with a middle ground, similar to
>>> "vnd." namespace, for ad-hoc parameters that might or might not be standardized,
>>> but that clearly have not been through IETF consensus.
>>
>> Yuch.
>
> Why?

because it really is perpetuated essentially the same model that we are trying 
to do away with.


> But it would improve some of the problems of that model, and avoid some of the
> problems with just abandoning the model entirely.

or it wouldn't.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From GK@ninebynine.org  Mon Nov 14 02:10:27 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B4821F8D26 for ; Mon, 14 Nov 2011 02:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.584
X-Spam-Level: 
X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, 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 FPaMoz-FgqE8 for ; Mon, 14 Nov 2011 02:10:26 -0800 (PST)
Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3635321F85CE for ; Mon, 14 Nov 2011 02:02:33 -0800 (PST)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RPtMx-00088X-Qj; Mon, 14 Nov 2011 10:02:27 +0000
Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RPtMx-000206-3m; Mon, 14 Nov 2011 10:02:27 +0000
Message-ID: <4EC0CA2A.80005@ninebynine.org>
Date: Mon, 14 Nov 2011 07:58:34 +0000
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Larry Masinter 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 10:10:27 -0000

On 13/11/2011 18:59, Larry Masinter wrote:
 > I find this perspective appealing, and can't find anything wrong with it 
except that it's a break with tradition.

+1

In particular, I think, the tradition that IANA registries were/are an extension 
point for the IETF standards series (a perspective, if not strictly true).  The 
concern, and this was voiced quite strongly by some participants when we were 
working on the header field registry, is that appearance in an IANA registry may 
give the appearance of being an IETF standard.

But I sense that, in the applications area at least, the world has moved on and 
there are other ways for developers to figure out which options are likely to be 
interoperable.

I think it's worth considering.

#g
--

> I'd like to discuss the proposal for MIME registrations from Roy Fielding in http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html
> and the possibility that such changes should also apply to URI schemes.
>
> You can read Roy's rationale, which makes sense to me, but my summary is:
>
> * Eliminate standards, vendor, personal trees distinction for MIME types (For URI schemes, eliminate distinction between provisional and permanent schemes)
> * ENCOURAGE vendors to ship with vendor-neutral short-named types regardless of whether they have been registered yet or not;
>     ENCOURAGE the public to register any names that they have seen in deployed software. (same for URI schemes)
> * DO NOT try to avoid duplicates
> * EXPERT REVIEW for updates to existing registrations
> * Eliminate any IESG or consensus review requirement
>
> "There is absolutely no need to prevent name collisions in the registry itself because those collisions are irrelevant -- what matters is how the names are interpreted by recipients of messages."
> "There is absolutely no need to prevent people who are not the owners of a media type from registering that type without any prefixes."
> "The registry is not operable -- it is just documentation of how the Internet is operating, and it should reflect the reality of that operation even if that means we have multiple definitions per registered type."
>
> I find this perspective appealing, and can't find anything wrong with it except that it's a break with tradition. If you're at IETF this week and want to talk about it, find me.
>
> Larry
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From GK@ninebynine.org  Mon Nov 14 02:10:27 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899D321F85CE for ; Mon, 14 Nov 2011 02:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.588
X-Spam-Level: 
X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011,  BAYES_00=-2.599, 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 9DncpGdnbALI for ; Mon, 14 Nov 2011 02:10:26 -0800 (PST)
Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3653121F8E0C for ; Mon, 14 Nov 2011 02:02:33 -0800 (PST)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RPtMx-00088f-SU for apps-discuss@ietf.org; Mon, 14 Nov 2011 10:02:27 +0000
Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RPtMx-000209-5g for apps-discuss@ietf.org; Mon, 14 Nov 2011 10:02:27 +0000
Message-ID: <4EC0CCB8.1000406@ninebynine.org>
Date: Mon, 14 Nov 2011 08:09:28 +0000
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Apps Discuss 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Subject: [apps-discuss] draft-gregorio-uritemplate (was: Minutes for AppsAWG and Apps Area General Session, IETF 82)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 10:10:28 -0000

On 14/11/2011 04:35, Barry Leiba wrote:
> I've posted minutes on the meeting materials site.  Find them here:
> http://www.ietf.org/proceedings/82/minutes/appsawg.txt

Noting:
[[
09:35 draft-gregorio-uritemplate (Nottingham)

Ted Hardie: This is useful, but has been around for a while, with
different authors.  Need to get this done soon, so it doesn't languish
again.
]]

Yes please!  I'm currently working on a W3C spec that intends to cite this.  I 
assumed it was about to go LC.

#g
--

From GK@ninebynine.org  Mon Nov 14 02:10:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5120E21F8CBF for ; Mon, 14 Nov 2011 02:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.59
X-Spam-Level: 
X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599, 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 r+BRirmFSB+Y for ; Mon, 14 Nov 2011 02:10:27 -0800 (PST)
Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 367B421F8E3E for ; Mon, 14 Nov 2011 02:02:33 -0800 (PST)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RPtMy-0007HZ-Ar for apps-discuss@ietf.org; Mon, 14 Nov 2011 10:02:28 +0000
Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RPtMy-00020C-4B for apps-discuss@ietf.org; Mon, 14 Nov 2011 10:02:28 +0000
Message-ID: <4EC0D212.7010806@ninebynine.org>
Date: Mon, 14 Nov 2011 08:32:18 +0000
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Subject: [apps-discuss] draft-nordman-classification (was: Minutes for AppsAWG and Apps Area General Session, IETF 82)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 10:10:32 -0000

On 14/11/2011 04:35, Barry Leiba wrote:
> I've posted minutes on the meeting materials site.  Find them here:
> http://www.ietf.org/proceedings/82/minutes/appsawg.txt

Re:
-----
11:20 Basic Device Classification (Bruce Nordman) - 5 min
    draft-nordman-classification

Looking for assitance/comment/collaboration.
Want to make a registry for generic device "names", as known by humans.
"computer", "projector", that sort of thing.
question about properties vs names, and what the use case is.
question about behaviour of devices, related to proerties vs names.
answer: Not addressing functional aspects of the devices.
question: Why is "what they are" useful?  Unclear on purpose.
CORE could use something like this, but needs *types*, rather than names.
-----

My first thought was: "OMG, are the IETF going to do ontologies now?" :)

I'm ambivalent whether this activity is of value in an IETF context - I'm not 
seeing it yet.

But some thoughts did occur to me:
(1) the discussion may be not-unrelated to recent discussion of top level MIME 
types (font/*, etc.)
(2) there are some other past activities that could relate to this
http://www.ietf.org/rfc/rfc3458.txt - "Message Context"
http://tools.ietf.org/html/rfc2506 - "Media features"

#g
--

From rg+ietf@qualcomm.com  Mon Nov 14 02:11:02 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6947D21F8E1C for ; Mon, 14 Nov 2011 02:11:02 -0800 (PST)
X-Quarantine-ID: <6EGLvFKEObcp>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -106.305
X-Spam-Level: 
X-Spam-Status: No, score=-106.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, 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 6EGLvFKEObcp for ; Mon, 14 Nov 2011 02:11:00 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3523411E80E5 for ; Mon, 14 Nov 2011 02:06:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=rg+ietf@qualcomm.com; q=dns/txt; s=qcdkim; t=1321265175; x=1352801175; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:content-type:x-random-sig-tag; z=Message-Id:=20 |In-Reply-To:=20<4EC0D517.3030400@dcrocker.net> |References:=20<20111024161910.8048.2279.idtracker@ietfa. amsl.com>=0D=0A=20=09 <4EC0AD84.5060502@dcrocker.net>=0D=0A=20=20<4EC0D517.3030400@dcrocker.net> |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Mon,=201 4=20Nov=202011=2001:42:42=20-0800|To:=20|From:=20Randall=20Gellens=20 |Subject:=20Re:=20[apps-discuss]=20I-D=20Action:=20draft- ietf-appsawg-xdash-02.txt|Cc:=20, =20Mark=20Nottingham=20,=0D=0A=20=20=20=20 =20=20=20=20,=20Dave=20CROCKER=20|Content-Type:=20text/plain=3B=20charset=3D" us-ascii"=20=3B=20format=3D"flowed"|X-Random-Sig-Tag:=201 .0b28; bh=DggFmVGWN6lPN5drA1oQJj8La2TRHW4rkV5ZH8FXfG4=; b=CByo7dRKr6BVoBVRGhCfuRR+HPlIYFrW116DXXaJRVagermOP2CI596n rK1X8fBIB8aOy1t+IJq4lvTrX/WsWJCwYJi/w+J2jVAXivHUan9VtsMRA LugzQ6DwOSPADP3RAPkKK7H70cwZuJAsrBobdiThW9ZE6PdsjZPeuenMY M=;
X-IronPort-AV: E=McAfee;i="5400,1158,6529"; a="137378057"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 14 Nov 2011 02:06:10 -0800
X-IronPort-AV: E=Sophos;i="4.69,504,1315206000"; d="scan'208";a="112969965"
Received: from warlock.qualcomm.com ([129.46.50.49]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2011 02:06:10 -0800
Received: from [172.21.1.9] (myvpn-l-dyp000696dys.ras.qualcomm.com [10.64.135.172]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id pAEA66dT029837; Mon, 14 Nov 2011 02:06:08 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4EC0D517.3030400@dcrocker.net>
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com> 	<4EC0AD84.5060502@dcrocker.net>  <4EC0D517.3030400@dcrocker.net>
X-Mailer: Eudora for Mac OS X
Date: Mon, 14 Nov 2011 01:42:42 -0800
To: 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
Cc: Mark Nottingham , dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 10:11:02 -0000

At 4:45 PM +0800 11/14/11, Dave CROCKER wrote:

>  On 11/14/2011 4:11 PM, Randall Gellens wrote:
>>  At 1:56 PM +0800 11/14/11, Dave CROCKER wrote:
>>>  I think the essence of what you've cited is that the later 
>>> process produces a
>>>  revised specification. Hence, what is produced is not the same thing as was
>>>  getting used. Unfortunately the implication is a practise of 
>>> re-using the name
>>>  without any version indication, which is generally frowned upon, protocol
>>>  technique-wise...
>>
>>  Right, but the answer, I think, is to use a different name for the 
>> standardized
>>  version, not to do away with wider review.
>
>  +1
>
>  (but for clarity:  I, for one, hadn't called for doing away with 
> wider review.)

The current model, with all its flaws, does try to distinguish 
between ad-hoc parameters that anyone can just start using, with no 
review, and standard ones, that have been through wider review.  To 
move to a model that does away with this distinction seems to 
encourage more use of ad-hoc parameters that have not been through 
wide review.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Sorry, no obscene fortunes.  Don't want to offend anyone.
(Now that's obscene!)

From msk@cloudmark.com  Mon Nov 14 02:37:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF5311E810E for ; Mon, 14 Nov 2011 02:37:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.31
X-Spam-Level: 
X-Spam-Status: No, score=-103.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, 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 TWq6nyCxcldY for ; Mon, 14 Nov 2011 02:37:40 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 77D8911E80EA for ; Mon, 14 Nov 2011 02:37:40 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 14 Nov 2011 02:37:36 -0800
From: "Murray S. Kucherawy" 
To: Apps Discuss 
Date: Mon, 14 Nov 2011 02:37:33 -0800
Thread-Topic: [apps-discuss] draft-gregorio-uritemplate (was: Minutes for AppsAWG and Apps Area General Session, IETF 82)
Thread-Index: AcyitdbWY9UvFS0NTOGoTalTfzSy6AAA3kwg
Message-ID: 
References:  <4EC0CCB8.1000406@ninebynine.org>
In-Reply-To: <4EC0CCB8.1000406@ninebynine.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] draft-gregorio-uritemplate (was: Minutes for AppsAWG and Apps Area General Session, IETF 82)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 10:37:41 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Graham Klyne
> Sent: Monday, November 14, 2011 12:09 AM
> To: Apps Discuss
> Subject: [apps-discuss] draft-gregorio-uritemplate (was: Minutes for Apps=
AWG and Apps Area General Session, IETF 82)
>=20
> Yes please!  I'm currently working on a W3C spec that intends to cite
> this.  I assumed it was about to go LC.

(As I said in appsawg today)

+1 to this.  REPUTE (currently) plans to use it.  Happy to help however I c=
an, including shepherding.

From stpeter@stpeter.im  Mon Nov 14 02:42:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3329D11E812C for ; Mon, 14 Nov 2011 02:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.562
X-Spam-Level: 
X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=-0.962, 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 99TiG7Iy0BdF for ; Mon, 14 Nov 2011 02:42:12 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8922E11E80F9 for ; Mon, 14 Nov 2011 02:42:12 -0800 (PST)
Received: from dhcp-13ac.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A8FE4404FF; Mon, 14 Nov 2011 03:48:21 -0700 (MST)
Message-ID: <4EC0F080.9010306@stpeter.im>
Date: Mon, 14 Nov 2011 18:42:08 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" 
References:  <4EC0CCB8.1000406@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] draft-gregorio-uritemplate
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 10:42:13 -0000

On 11/14/11 6:37 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Graham Klyne
>> Sent: Monday, November 14, 2011 12:09 AM
>> To: Apps Discuss
>> Subject: [apps-discuss] draft-gregorio-uritemplate (was: Minutes for AppsAWG and Apps Area General Session, IETF 82)
>>
>> Yes please!  I'm currently working on a W3C spec that intends to cite
>> this.  I assumed it was about to go LC.
>
> (As I said in appsawg today)
>
> +1 to this.  REPUTE (currently) plans to use it.  Happy to help however I can, including shepherding.



Murray, if you will volunteer to be the document shepherd, then I will 
volunteer to progress this specification as AD-sponsored rather than 
asking the APPSAWG to take this on as a WG item. IMHO this document has 
received a great deal of review on the uri@w3.org list (etc.) over the 
years, and we can encourage further reviews during IETF Last Call.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From dhc@dcrocker.net  Mon Nov 14 02:46:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE14911E8199 for ; Mon, 14 Nov 2011 02:46:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, 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 VaBqo5OTbn69 for ; Mon, 14 Nov 2011 02:46:35 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AE4D311E8163 for ; Mon, 14 Nov 2011 02:46:35 -0800 (PST)
Received: from [130.129.82.22] (dhcp-5216.meeting.ietf.org [130.129.82.22]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAEAkMc0011144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2011 02:46:31 -0800
Message-ID: <4EC0F17B.5020003@dcrocker.net>
Date: Mon, 14 Nov 2011 18:46:19 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Randall Gellens 
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com> 	<4EC0AD84.5060502@dcrocker.net>  <4EC0D517.3030400@dcrocker.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 14 Nov 2011 02:46:35 -0800 (PST)
Cc: Mark Nottingham , apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 10:46:37 -0000

On 11/14/2011 5:42 PM, Randall Gellens wrote:
> At 4:45 PM +0800 11/14/11, Dave CROCKER wrote:
>>> Right, but the answer, I think, is to use a different name for the standardized
>>> version, not to do away with wider review.
>>
>> +1
>>
>> (but for clarity: I, for one, hadn't called for doing away with wider review.)
>
> The current model, with all its flaws, does try to distinguish between ad-hoc
> parameters that anyone can just start using, with no review, and standard ones,


Yes, it tries.  It was an entirely reasonable and well-intentioned, idea.  But 
in making its attempt, it created a problem.

You aren't solving that demonstrated problem.

Note that a strategically isomorphic problem is distinguishing which RFCs are 
standards.  Folks get very upset that some people think all RFCs are standards, 
but it does not actually cause serious real-world problems.  It's just 
unaesthetic.

Rather than split the structure of RFC "names" between standard and 
non-standard, we create a separate attribute for labeling some RFCs as standards.

That's the sort of thing to do in the current case.  Keep status separate from name.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From stpeter@stpeter.im  Mon Nov 14 02:48:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA50221F8E92 for ; Mon, 14 Nov 2011 02:48:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.455
X-Spam-Level: 
X-Spam-Status: No, score=-103.455 tagged_above=-999 required=5 tests=[AWL=-0.856, 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 H3rU1Kx8pt77 for ; Mon, 14 Nov 2011 02:48:13 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4813721F8DF0 for ; Mon, 14 Nov 2011 02:48:13 -0800 (PST)
Received: from dhcp-13ac.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD196404FF; Mon, 14 Nov 2011 03:54:20 -0700 (MST)
Message-ID: <4EC0F1E7.7000602@stpeter.im>
Date: Mon, 14 Nov 2011 18:48:07 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com> 	<4EC0AD84.5060502@dcrocker.net>  <4EC0D517.3030400@dcrocker.net>  <4EC0F17B.5020003@dcrocker.net>
In-Reply-To: <4EC0F17B.5020003@dcrocker.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham , Randall Gellens , apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 10:48:13 -0000

On 11/14/11 6:46 PM, Dave CROCKER wrote:

> Keep status separate from name.

Exactly!

From msk@cloudmark.com  Mon Nov 14 03:14:23 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C737D11E8262 for ; Mon, 14 Nov 2011 03:14:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.813
X-Spam-Level: 
X-Spam-Status: No, score=-102.813 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 OGOJOFYTsEcQ for ; Mon, 14 Nov 2011 03:14:23 -0800 (PST)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 54E4411E8259 for ; Mon, 14 Nov 2011 03:14:23 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 14 Nov 2011 03:14:22 -0800
From: "Murray S. Kucherawy" 
To: Peter Saint-Andre 
Date: Mon, 14 Nov 2011 03:14:20 -0800
Thread-Topic: [apps-discuss] draft-gregorio-uritemplate
Thread-Index: AcyiuhT2Obye4ZUNS96BCTYyX26iKQABHHeA
Message-ID: 
References:  <4EC0CCB8.1000406@ninebynine.org>  <4EC0F080.9010306@stpeter.im>
In-Reply-To: <4EC0F080.9010306@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Apps Discuss 
Subject: Re: [apps-discuss] draft-gregorio-uritemplate
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 11:14:23 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZXRlciBTYWludC1BbmRyZSBb
bWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbV0NCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxNCwg
MjAxMSAyOjQyIEFNDQo+IFRvOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+IENjOiBBcHBzIERpc2N1
c3MNCj4gU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIGRyYWZ0LWdyZWdvcmlvLXVyaXRlbXBs
YXRlDQo+IA0KPiBNdXJyYXksIGlmIHlvdSB3aWxsIHZvbHVudGVlciB0byBiZSB0aGUgZG9jdW1l
bnQgc2hlcGhlcmQsIHRoZW4gSSB3aWxsDQo+IHZvbHVudGVlciB0byBwcm9ncmVzcyB0aGlzIHNw
ZWNpZmljYXRpb24gYXMgQUQtc3BvbnNvcmVkIHJhdGhlciB0aGFuDQo+IGFza2luZyB0aGUgQVBQ
U0FXRyB0byB0YWtlIHRoaXMgb24gYXMgYSBXRyBpdGVtLiBJTUhPIHRoaXMgZG9jdW1lbnQgaGFz
DQo+IHJlY2VpdmVkIGEgZ3JlYXQgZGVhbCBvZiByZXZpZXcgb24gdGhlIHVyaUB3My5vcmcgbGlz
dCAoZXRjLikgb3ZlciB0aGUNCj4geWVhcnMsIGFuZCB3ZSBjYW4gZW5jb3VyYWdlIGZ1cnRoZXIg
cmV2aWV3cyBkdXJpbmcgSUVURiBMYXN0IENhbGwuDQoNCkknbSBpbi4gIFlvdXIgbW92ZS4gIDot
KQ0K

From stpeter@stpeter.im  Mon Nov 14 03:19:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F71711E80CB for ; Mon, 14 Nov 2011 03:19:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.369
X-Spam-Level: 
X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=-0.770, 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 iv4yJydeByHj for ; Mon, 14 Nov 2011 03:19:03 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E8DB611E80BB for ; Mon, 14 Nov 2011 03:19:02 -0800 (PST)
Received: from dhcp-13ac.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5AC15404FF; Mon, 14 Nov 2011 04:25:10 -0700 (MST)
Message-ID: <4EC0F921.3000907@stpeter.im>
Date: Mon, 14 Nov 2011 19:18:57 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" 
References:  <4EC0CCB8.1000406@ninebynine.org>  <4EC0F080.9010306@stpeter.im> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] draft-gregorio-uritemplate
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 11:19:03 -0000

On 11/14/11 7:14 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
>> Sent: Monday, November 14, 2011 2:42 AM
>> To: Murray S. Kucherawy
>> Cc: Apps Discuss
>> Subject: Re: [apps-discuss] draft-gregorio-uritemplate
>>
>> Murray, if you will volunteer to be the document shepherd, then I will
>> volunteer to progress this specification as AD-sponsored rather than
>> asking the APPSAWG to take this on as a WG item. IMHO this document has
>> received a great deal of review on the uri@w3.org list (etc.) over the
>> years, and we can encourage further reviews during IETF Last Call.
>
> I'm in.  Your move.  :-)

It's now in the datatracker with a state of "AD Evaluation". :)

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Mon Nov 14 05:24:15 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6BE21F8E43 for ; Mon, 14 Nov 2011 05:24:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.885
X-Spam-Level: 
X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 wjukTkak7U6W for ; Mon, 14 Nov 2011 05:24:15 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 314B421F8E42 for ; Mon, 14 Nov 2011 05:24:14 -0800 (PST)
Received: by wwe5 with SMTP id 5so3102013wwe.13 for ; Mon, 14 Nov 2011 05:24:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wfqaKjnrhxBdVHWWDyapiKyr87AIfynz6wdDOkCgwto=; b=iRSbCVGvQMsyAWVb6FZyyaVVEJcb9k+7PAhNYRcG8eGGbyHKkUudDp4NkePqQO1UKi g9peeVh0bDvRoRPJNx0p26NBQmlde2ZddGZwtwZZGJ5ah5eH6lIwRdT79xoIeN6dTSkl qq8RrTKFk9e5WDlFNPUKufjZpy3yB4OqiZZHY=
Received: by 10.216.139.83 with SMTP id b61mr4010379wej.73.1321277054118; Mon, 14 Nov 2011 05:24:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.184.147 with HTTP; Mon, 14 Nov 2011 05:23:33 -0800 (PST)
In-Reply-To: <4EC0F1E7.7000602@stpeter.im>
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com>  <4EC0AD84.5060502@dcrocker.net>  <4EC0D517.3030400@dcrocker.net>  <4EC0F17B.5020003@dcrocker.net> <4EC0F1E7.7000602@stpeter.im>
From: Frank Ellermann 
Date: Mon, 14 Nov 2011 14:23:33 +0100
Message-ID: 
To: Peter Saint-Andre 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 13:24:16 -0000

On 14 November 2011 11:48, Peter Saint-Andre  wrote:

> On 11/14/11 6:46 PM, Dave CROCKER wrote:

>> Keep status separate from name.

> Exactly!

Good idea, maybe "status" can be inherited from the status of the spec.

-Frank

From paulej@packetizer.com  Mon Nov 14 06:07:47 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B4711E81D3 for ; Mon, 14 Nov 2011 06:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level: 
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 wFpumVo++YOr for ; Mon, 14 Nov 2011 06:07:46 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEAF11E819E for ; Mon, 14 Nov 2011 06:07:46 -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 pAEE7hSm004182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 09:07:45 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321279665; bh=/Ytk+L4vufYqZr2GpK0Xom0BFN/R5bKqqiwJZ5c/i9E=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xo6FUp/n02NAq7/frv8dho4XIlUy31c6pPUKLVCPYxbR8ZBeioEbfHDGhMvm417+y +5p+5f37xkNB0wDgOIM9dFEOo646dZkf9OQ+NklWMU7TLNfFF3bdTmTiCl1X/q5Vd9 pO6dIl2pLye7A+l11dXoCRXnEXEt+Lad4D5pbMZs=
From: "Paul E. Jones" 
To: "=?UTF-8?Q?'=22Martin_J._D=C3=BCrst=22'?=" 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>	<4EBD6266.6030307@gmail.com>	<023801cca0ca$d9860a20$8c921e60$@packetizer.com>	<4EBE04C7.5090400@gmail.com> <015301cca232$75ea36d0$61bea470$@packetizer.com> <4EC0BFAD.8060501@it.aoyama.ac.jp>
In-Reply-To: <4EC0BFAD.8060501@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 09:07:35 -0500
Message-ID: <02eb01cca2d6$c36a81e0$4a3f85a0$@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: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQFe+7+KAmEa8QsCfngenQIEt9zYAdF9rjiUdYda4A==
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 14:07:47 -0000

Martin,

That's actually where I started, but decided to narrow the definition to =
addr-spec only, since we do not want a lot of the other syntax =
associated with "mailto".  However, feedback I got was that addr-spec =
might even be too broad.  Do we need anything more than =
acct:user@domain?  If not, I think RFC 3986 might define enough.  Would =
we lose anything?

Paul

> -----Original Message-----
> From: "Martin J. D=C3=BCrst" [mailto:duerst@it.aoyama.ac.jp]
> Sent: Monday, November 14, 2011 2:14 AM
> To: Paul E. Jones
> Cc: "'\"Mykyta Yevstifeyev (=D0=9C. =
=D0=84=D0=B2=D1=81=D1=82=D1=96=D1=84=D0=B5=D1=94=D0=B2)\"'"; =
apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Webfinger
>=20
> Hello Paul,
>=20
> You can also have a look at RFC http://tools.ietf.org/html/rfc6068 and
> http://tools.ietf.org/html/draft-duerst-eai-mailto-01.
>=20
> If I understand the acct: scheme correctly, it should be possible to
> make the syntax a subset of mailto:.
>=20
> Regards,    Martin.
>=20
> On 2011/11/14 3:31, Paul E. Jones wrote:
> > Mykyta,
> >
> >
> >
> > I fear this might get complicated with references to the email
> documents.  Those documents are trying to solve a real problem, but
> Webfinger does not have some of those historical constraints.
> >
> >
> >
> > Here=E2=80=99s my proposal: let=E2=80=99s not reference 5335 or =
5322.  Rather, let=E2=80=99s
> only reference the generic URI syntax spec (RFC 3986).  Let=E2=80=99s =
define the
> URI scheme using the syntax found there:
> >
> >     acctURI   =3D "acct:" userinfo "@" host
> >
> >
> >
> > The productions =E2=80=9Cuserinfo=E2=80=9D and =
=E2=80=9Chost=E2=80=9D are already defined.  Perhaps
> the one thing I don=E2=80=99t like is that =E2=80=9Chost=E2=80=9D =
might be an IP address, but
> perhaps some people prefer that.
> >
> >
> >
> > RFC 3986 already says that these components are UTF-8 encoded and =
then
> percent-escaped when a character is outside the ASCII character set
> range.
> >
> >
> >
> > Would this be a suitable replacement for the current text?
> >
> >
> >
> > With respect to your comments on link relations and URIs, I still do
> not understand.  You say that =E2=80=9Cnobody will benefit from link =
relation
> types defined by URIs=E2=80=9D, but why not?  There are several =
already define
> and used today.  In any case, I would prefer that all link relation
> values (URI or simple strings) be defined outside of the Webfinger
> draft.  As I mentioned, there is already a registry, so one can be
> proposed any time.
> >
> >
> >
> > Paul
> >
> >
> >
> > From: "Mykyta Yevstifeyev (=D0=9C. =
=D0=84=D0=B2=D1=81=D1=82=D1=96=D1=84=D0=B5=D1=94=D0=B2)" =
[mailto:evnikita2@gmail.com]
> > Sent: Saturday, November 12, 2011 12:32 AM
> > To: Paul E. Jones
> > Cc: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Webfinger
> >
> >
> >
> > Hello Paul,
> >
> > 12.11.2011 1:37, Paul E. Jones wrote:
> >
> > Mykyta,
> >
> >
> >
> > Thanks for your positive response.
> >
> >
> >
> > To your specific questions=E2=80=A6
> >
> >
> >
> > We would definitely want to ensure that Unicode is properly =
supported.
> In wasn=E2=80=99t aware of RFC 5335, so I=E2=80=99m glad you brought =
that to my
> attention.  Do you have a pointer to the bis draft so I can see =
exactly
> what is there?  I=E2=80=99d be fully in favor of using utf8-addr-spec.
> >
> >
> > This is http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13.  =
But
> please note that this document, unlike RFC 5335, introduced UTF-8
> additions to *base* RFC 5322 productions.  This means that
> will be defined as follows now:
> >
> >
> >
> >
> >     addr-spec       =3D   local-part "@" domain
> >     local-part      =3D   dot-atom / quoted-string / obs-local-part
> >     domain          =3D   dot-atom / domain-literal / obs-domain
> >     domain-literal  =3D   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
> >     dtext           =3D   %d33-90 /          ; Printable US-ASCII
> >                         %d94-126 /         ;  characters not =
including
> >                         obs-dtext          ;  "[", "]", or "\"
> >     dtext           =3D/  UTF8-non-ascii     ; from 5335bis
> >     dot-atom        =3D   [CFWS] dot-atom-text [CFWS]
> >     dot-atom-text   =3D   1*atext *("." 1*atext)
> >     atext           =3D/  UTF8-non-ascii     ; from 5335bis
> >
> >
> > So everything you will have to do is to have a note on 'acct' RI =
being
> possible to carry UTF8 characters and therefore being possibly IRIs.
> >
> >
> >
> >
> >
> >
> > Link relation types might be names like =E2=80=9Ccopyright=E2=80=9D =
or they might be
> URIs.  The definition of the link relation types is outside the scope =
of
> the Webfinger document itself.  RFC 6415 defines the structure of the
> documents and provides examples of some link relations and the order =
of
> processing.  RFC 5988 defines the link relations more generically and
> establishes the registry for them.  Do you think we need to say more
> about link relations beyond what those documents cover?
> >
> >
> > I mean that Webfinger will have to operate on a variety of link
> relations in LRDD documents, and nobody will benefit from link =
relation
> types defined by URIs used there, as this eliminates the possibility =
for
> automatic processing.  So I ask whether we'll have to define non-URI
> link relation types for all the possible Webfinger use-cases?
> >
> >
> >
> >
> >
> >
> > On section 4: noted.  We=E2=80=99ll try to clearly separate the =
normative and
> non-normative pieces better.
> >
> >
> > Thanks.
> >
> >
> >
> >
> >
> >
> > On  CORS, there are some who have strongly advocated for it.  It =
would
> be very useful to allow JavaScript code to perform these queries.
> Otherwise, the queries would have to be pushed to server-side code.
> Let=E2=80=99s wait on deciding what to do until we get a definitive =
answer on
> CORS from the W3C.  I think Peter was going to do some investigating
> there.
> >
> >
> >
> > Putting Webfinger into vcard: isn=E2=80=99t that circular?  The idea =
with
> Webfinger is that you have the identity of the user (e.g.,
> paulej@packetizer.com), but you want to find more information.  If you
> have a vcard, then you have the user=E2=80=99s identity (via the email =
tag).  Or
> are you suggesting that we formally introduce the acct URI in vcard?
> That might make sense to do.  Can you clarify your proposal?
> >
> >
> >> From RFC 6350, Section 6.4.2:
> >
> >
> >
> >
> > 6.4.2. EMAIL
> >
> >     Purpose:  To specify the electronic mail address for =
communication
> >        with the object the vCard represents.
> >
> >
> > ...and the use might have email address different from Webfinger ID.
> > I've already pointed to
> > http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00,
> > which VCARDDAV WG works on, and so you may try to introduce some
> > similar property for Webfinger IDs.  (You see, vCards may not carry
> > all the variety of information, though some people actually think in
> > other way, and thus it would be a good idea to provide a means of
> > accessing some additional info.)
> >
> >
> >
> >
> >
> >
> > For comments on particular sections, I=E2=80=99ve added notes to =
each one to
> revise them as you suggest: they=E2=80=99re all good suggestions.
> >
> >
> > Yes, thanks as well.
> >
> >
> >
> >
> >
> >
> > I would very much like to make this a WG item, of course, but none =
of
> the authors will be present at this IETF meeting.  Perhaps hallway
> dialog might take place, but not sure.  In any case, we can do this =
via
> the mailing list, too.
> >
> >
> > See Barry's note on this.
> >
> >
> >
> >
> >
> >
> > Thanks!
> >
> > Paul
> >
> >
> > All the best,
> > Mykyta Yevstifeyev
> >
> >
> >
> >
> >
> >
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of "Mykyta Yevstifeyev (?. ?????????)"
> > Sent: Friday, November 11, 2011 12:59 PM
> > To: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Webfinger
> >
> >
> >
> > Hi Paul and all,
> >
> > I think you contributed a very interesting proposal indeed.  Really,
> RFC 1288 finger protocol is now outdated, and you're right claiming =
that
> it provides no means of automatic processing.  BTW, RFC 1288 is
> currently at Draft Standard maturity level, which has been abandoned =
by
> RFC 6410, and we should therefore undertake something with this =
respect,
> as should we with respect of other Apps-related DSs, but that is what =
is
> to be discussed separately.
> >
> > With respect to proposed 'acct' URI scheme:  how are you going to
> handle internationalization (i18n)?  We have RFC 5335 defining addr-spec>  (Experimental RFC) and IESG has already approved EAI
> 5335bis, that will be Standards Track.  So will  be
> allowed in 'acct' URIs in some way?
> >
> > Webfinger implies use of some link relations.  Is it anticipated =
that
> URIs will be used as link relations types, or we'll need to define =
link
> relation types for all possible use-cases of Webfinger?
> >
> > Your Section 4 seems to be somewhat narrative.  I propose to divide =
it
> into normative specification and examples.
> >
> > With regard to CORS - I'm not actually acquainted with this
> technology, but I see it is currently documented as W3C working draft,
> so I don't suspect it is now widely-used (I may of course be wrong, so
> please feel free to correct me), and I think there is no use putting
> MUST requirement on its use in Webfinger.  You could better remove =
your
> section on CORS from the document at all.
> >
> > I think we should also provide some means of mentioning Webfinger
> accounts in vCards.  You could please see VCARDDAV document
> http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 =
which
> Webfinger elements may also be incorporated.
> >
> > In Abstract, you should be more specific about what your document
> defines.  I propose mentioning directly that the document is the
> specification of Webfinger protocol, not "procedures for dicovering
> information about people".
> >
> > In Section 7 you should clearly state that Webfinger (so as finger
> itself) is intentionally left w/o any means of controlling access to
> information (unless we want to produce *such* protocol).
> >
> > I see the document is on APPSAWG agenda on the meeting, so I
> anticipate it will soon become APPSAWG item doc.  I won't be on =
meeting,
> but if you discuss the adaptation of Webfinger draft please also take
> into account I'm in favor of such adaptation (consider this as my 2p).
> >
> > Mykyta Yevstifeyev
> >
> > 24.10.2011 23:09, Paul E. Jones wrote:
> >
> > Folks,
> >
> >
> >
> > We just submitted this:
> >
> > =
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.t
> > xt
> >
> >
> >
> > The tools for Webfinger are now defined, but the procedures need to =
be
> clearer with respect to what most of us understand as =
=E2=80=9Cwebfinger=E2=80=9D.  This
> is just a first stab at making that happen and we hope to progress =
this
> to publish an RFC in the application area.
> >
> >
> >
> > We welcome any comments you have on the topic, either privately or
> publicly.
> >
> >
> >
> > Paul
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss


From mnot@mnot.net  Mon Nov 14 07:32:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B7B21F8DBD for ; Mon, 14 Nov 2011 07:32:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.969
X-Spam-Level: 
X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=-0.370, 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 kE1Y-ksVd5yX for ; Mon, 14 Nov 2011 07:32:12 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 93B5621F8D96 for ; Mon, 14 Nov 2011 07:32:11 -0800 (PST)
Received: from [10.6.129.23] (unknown [64.39.4.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2838922E254; Mon, 14 Nov 2011 10:32:01 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: <4EC0F1E7.7000602@stpeter.im>
Date: Mon, 14 Nov 2011 09:32:02 -0600
Content-Transfer-Encoding: 7bit
Message-Id: <4B9A1851-31B5-4147-A284-77A63664401C@mnot.net>
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com> 	<4EC0AD84.5060502@dcrocker.net>  <4EC0D517.3030400@dcrocker.net>  <4EC0F17B.5020003@dcrocker.net> <4EC0F1E7.7000602@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1251.1)
Cc: Randall Gellens , dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 15:32:13 -0000

On 14/11/2011, at 4:48 AM, Peter Saint-Andre wrote:

> On 11/14/11 6:46 PM, Dave CROCKER wrote:
> 
>> Keep status separate from name.
> 
> Exactly!


+1

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





From nsb@guppylake.com  Mon Nov 14 07:32:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F059511E81A3 for ; Mon, 14 Nov 2011 07:32:18 -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 3cK9Nktympxa for ; Mon, 14 Nov 2011 07:32:18 -0800 (PST)
Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 1D62911E80CF for ; Mon, 14 Nov 2011 07:32:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=mIM4OBy84Cm9tIGsvvpbkryYc7Gtw/3hPUX1iJOB6+qXX0sk72PmA0dViJ+FdLF77t+rq0ai7jdGkdysWjiAKPlWvkKG9E/u+ikifx2J9TznDirHHx+rPwIkR14T3Czu;
Received: from [108.98.149.133] (helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1RPyW8-0001vx-D2; Mon, 14 Nov 2011 10:32:17 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Nathaniel Borenstein 
In-Reply-To: 
Date: Mon, 14 Nov 2011 10:32:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Larry Masinter 
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server1.netnutz.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - guppylake.com
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 15:32:19 -0000

I certainly don't believe that name collisions are irrelevant; they can =
cause plenty of problems.  In particular, I don't understand what's =
supposed to happen in this kind of case:

1.  Company X designs a new media type, perhaps even only for internal =
use, and registers it as application/foobar

2.  Company Y designs something entirely different and registers it as =
application/foobar as well.

3.  Each company builds up months or years of experience with their own =
type, which gets scattered all through the archives, etc.

4.  Company X buys company Y and starts to integrate its infrastructure.

This wouldn't trouble me so much if there were *any* way to tell the two =
uses apart.  Isn't that the whole point of a registry?  If name =
collisions are to be allowed, why do we need a registry at all?  Why not =
just have independent communities of folk wisdom with their own =
interpretations of media type names, and pay big bucks to consultants to =
sort out the problems?=20

If I want to define a media type for a moving picture flip-book, is it =
really OK if I call it "My Pictures Emerge Galloping" and use a media =
type of video/mpeg?  Mightn't my doing that cause problems for a whole =
lot of people with no responsibility for my idiocy?  -- Nathaniel


On Nov 13, 2011, at 1:59 PM, Larry Masinter wrote:

> I'd like to discuss the proposal for MIME registrations from Roy =
Fielding in =
http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html
> and the possibility that such changes should also apply to URI =
schemes.
>=20
> You can read Roy's rationale, which makes sense to me, but my summary =
is:=20
>=20
> * Eliminate standards, vendor, personal trees distinction for MIME =
types (For URI schemes, eliminate distinction between provisional and =
permanent schemes)
> * ENCOURAGE vendors to ship with vendor-neutral short-named types =
regardless of whether they have been registered yet or not;
>  ENCOURAGE the public to register any names that they have seen in =
deployed software. (same for URI schemes)
> * DO NOT try to avoid duplicates=20
> * EXPERT REVIEW for updates to existing registrations
> * Eliminate any IESG or consensus review requirement
>=20
> "There is absolutely no need to prevent name collisions in the =
registry itself because those collisions are irrelevant -- what matters =
is how the names are interpreted by recipients of messages."
> "There is absolutely no need to prevent people who are not the owners =
of a media type from registering that type without any prefixes."
> "The registry is not operable -- it is just documentation of how the =
Internet is operating, and it should reflect the reality of that =
operation even if that means we have multiple definitions per registered =
type."
>=20
> I find this perspective appealing, and can't find anything wrong with =
it except that it's a break with tradition. If you're at IETF this week =
and want to talk about it, find me.
>=20
> Larry=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From ned.freed@mrochek.com  Mon Nov 14 10:16:37 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF0111E8334 for ; Mon, 14 Nov 2011 10:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.144
X-Spam-Level: 
X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3]
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 aykK3ulJEHtW for ; Mon, 14 Nov 2011 10:16:36 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C0F7D11E8332 for ; Mon, 14 Nov 2011 10:16:35 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8ENPJYBAO018FHF@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 10:16:27 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 10:16:23 -0800 (PST)
Message-id: <01O8ENPHIUAQ00RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 10:13:29 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 14 Nov 2011 16:31:34 +0900" <4EC0C3D6.1070506@it.aoyama.ac.jp>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net> <4EBBABC1.1010101@it.aoyama.ac.jp> <003201cca12e$1f35f860$4001a8c0@gateway.2wire.net> <4EC0C3D6.1070506@it.aoyama.ac.jp>
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 18:16:37 -0000

> Hello Tom, others,

> On 2011/11/12 20:27, t.petch wrote:

> > But more significantly, as other posts have clarified for me, this thread
> > is nothing to do with fonts but with type definition languages, so perhaps
> > it should be 'type/*'.

> Perhaps it should be type/* or fontformat/* or whatever. But most
> probably it should be font/. Because the people who are working on this
> repeatedly have asked for font/*, and never for type/*, and never for
> fontformat/* or some such.

If that's indeed what they asked for, then +1.

				Ned

From singer@apple.com  Mon Nov 14 10:35:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF81811E81EE for ; Mon, 14 Nov 2011 10:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JDl6791JQF4u for ; Mon, 14 Nov 2011 10:35:24 -0800 (PST)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 65E2311E81B0 for ; Mon, 14 Nov 2011 10:35:24 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LUN00ERCYAZU6Z0@mail-out.apple.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 10:35:23 -0800 (PST)
X-AuditID: 11807112-b7b05ae000001108-ed-4ec15f625e3f
Received: from [17.151.77.208] (Unknown_Domain [17.151.77.208]) by relay17.apple.com (Apple SCV relay) with SMTP id A4.06.04360.66F51CE4; Mon, 14 Nov 2011 10:35:22 -0800 (PST)
From: David Singer 
In-reply-to: 
Date: Mon, 14 Nov 2011 10:35:12 -0800
Message-id: <3C5268E5-FE9E-4148-8955-0450304BB407@apple.com>
References: 
To: Larry Masinter 
X-Mailer: Apple Mail (2.1251.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUiON33gm5W/EE/g8mPrS1Wv1zBZtF+9wq7 xbaDSxgtrj26z2Lx784EZgdWj2k/e5g9dh39we6xZMlPJo+myzOYPJbN3cMSwBrFZZOSmpNZ llqkb5fAlXFl61XGggVsFdeWXGNrYGxh7WLk5JAQMJFYcGAiG4QtJnHh3nogm4tDSGAjo8SF 7v1MIAlhAReJRZfWg9m8AsYSa269YwGxmQW0JG78ewkWZxNQlXgw5xgjiM0pECTxdslOoBoO Dhag+Oq5wSAzmQX2MUpMn/2EHaJXW2LZwtfMEDNtJN5u/A1mCwkESsybdhrsOBEBdYlvx9+x QxwnL9Hy9Q7bBEb+WUjOmIXkjFlIxi5gZF7FKFiUmpNYaWiul1hQkJOql5yfu4kRFLINhUI7 GO/v0jvEKMDBqMTDqxB+0E+INbGsuDL3EKMEB7OSCC+vI1CINyWxsiq1KD++qDQntfgQozQH i5I475OKA35CAumJJanZqakFqUUwWSYOTqkGRm7J1PupckL3ck8wZVrwlEXL1GVc19k8bdMn V/d2MzWFzQ8S5b9FxR9tK+v3uFy2uyKzmev5EffAGGfn3PtxxT6FE1lNOyV+ljdlc9+YuzV0 +8bmPRUO0lIFV0yNDC5I1XsypUe5rLi+TEL5yqJtz2TkXj2+wXY26oPunP/XpBaqqW88GLlV iaU4I9FQi7moOBEAVYmB1VUCAAA=
Cc: "apps-discuss@ietf.org" , "gadams@xfsi.com" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 18:35:24 -0000

On Nov 12, 2011, at 12:25 , Larry Masinter wrote:

> I see no use case for why having font/opentype is any better than application/opentype
> 
> The only use case I can imagine from looking at
> http://tools.ietf.org/html/draft-singer-font-mime-00
> is the possibility of defining common parameters across font data types (in the same way that text/.. has a common charset parameter).

How serious is the first concern "First, the  "application" sub-tree is treated (correctly) with great caution with respect to viruses and other active code."?

(The reason I abandoned the draft was not the difficulty of getting it through, by the way, but because the W3C Timed Text group decided it didn't need it).

David Singer
Multimedia and Software Standards, Apple Inc.


From nico@cryptonector.com  Mon Nov 14 10:56:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C32D21F8E57 for ; Mon, 14 Nov 2011 10:56:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.632
X-Spam-Level: 
X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=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 b+1ed7AT99g3 for ; Mon, 14 Nov 2011 10:56:37 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8297D21F8E56 for ; Mon, 14 Nov 2011 10:56:37 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 5217F674060 for ; Mon, 14 Nov 2011 10:56:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=ORJHOaDUTT6RGiwTxEVYmN2LL4Lw1qm+Y31oJbjjXuOK pvSi4w3b7iULibnlpQ0qs3i0AdGtTq2ZGegvlGo07BAfK9pp47ZGyRoWgKb9tgYq LnTGGLUoZMaxJcBHnoY/RMRJ0FKHlzDXy89LZRwT+WM3/cujj2CoWtvlRsCCx+c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ykHMJGvE4Y7SKvQnxs47kcwI7mk=; b=myBUBBSMPq4 s9oT407aCjJ2sJlq3MaNxnYvZHygN3ygzfgU397VggKh5SqbDwjsjZcHl7Baxp5T yyLW21CI2p6FOUaikx3Ltji6Wu/QECea99uD7zhGRD4HaghKAv+Jf72Qap6N8tjK /Hc6EfFNy32U4jQd0u+S0cPbzFvEXG1E=
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 43D22674078 for ; Mon, 14 Nov 2011 10:56:31 -0800 (PST)
Received: by pzk5 with SMTP id 5so10499891pzk.9 for ; Mon, 14 Nov 2011 10:56:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.39.193 with SMTP id r1mr6799847pbk.75.1321296989802; Mon, 14 Nov 2011 10:56:29 -0800 (PST)
Received: by 10.68.40.162 with HTTP; Mon, 14 Nov 2011 10:56:29 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 14 Nov 2011 12:56:29 -0600
Message-ID: 
From: Nico Williams 
To: Frank Ellermann 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 18:56:38 -0000

On Sun, Nov 13, 2011 at 3:21 PM, Frank Ellermann
 wrote:
> On 13 November 2011 19:59, Larry Masinter wrote:
>> I find this perspective appealing
>
> In an ideal world it's not only appealing. =C2=A0But in
> the real world the "secret mission" of the IETF is
> IMHO to protect the IANA from "patent nonsense".

I assume you're not referring to patents here (as in IPR).

> It cannot work if *everybody* is free to register
> new media types or URI schemes falling into various
> WP:NOT categories (=3D "what Wikipedia is not").
>
> And the IANA also is also not Wikipedia, it is no
> dictionary of locations, encyclopedia of emoticons,
> registry of vanity URI schemes, or anything else
> requiring unlimited disk space or server bandwidth.

I think IANA can jufge frivolous requests.  If not we can require
enough review to filter out frivolous requests.

Aside from this, what is the objection to Roy's proposal?  The more I
think about it, the more I think it's on the money.

Nico
--

From nico@cryptonector.com  Mon Nov 14 11:06:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEC711E834F for ; Mon, 14 Nov 2011 11:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.778
X-Spam-Level: 
X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3]
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 BCVFxKB6zdms for ; Mon, 14 Nov 2011 11:06:10 -0800 (PST)
Received: from homiemail-a71.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id D831E11E834C for ; Mon, 14 Nov 2011 11:06:10 -0800 (PST)
Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id C35C8428075 for ; Mon, 14 Nov 2011 11:06:09 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 9EAA0428072 for ; Mon, 14 Nov 2011 11:06:09 -0800 (PST)
Received: by ggnr5 with SMTP id r5so1383202ggn.31 for ; Mon, 14 Nov 2011 11:06:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.12.105 with SMTP id x9mr52179834pbb.109.1321297568729; Mon, 14 Nov 2011 11:06:08 -0800 (PST)
Received: by 10.68.40.162 with HTTP; Mon, 14 Nov 2011 11:06:08 -0800 (PST)
In-Reply-To: <4EC0BE9E.8020702@it.aoyama.ac.jp>
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 13:06:08 -0600
Message-ID: 
From: Nico Williams 
To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 19:06:11 -0000

On Mon, Nov 14, 2011 at 1:09 AM, "Martin J. D=C3=BCrst"
 wrote:
> On 2011/11/14 3:59, Larry Masinter wrote:
>> * Eliminate standards, vendor, personal trees distinction for MIME types
>> (For URI schemes, eliminate distinction between provisional and permanen=
t
>> schemes)
>> * ENCOURAGE vendors to ship with vendor-neutral short-named types
>> regardless of whether they have been registered yet or not;
>
> I think that makes sense for something widely known and used (e.g.
> application/pdf), but not necessarily for some really company-specific ty=
pe.
> (Of course, we don't know in advance which way something may go in the en=
d,
> but we could use this rule at least for when the company e.g. wants to
> express that a type is NOT intended for general use).

I'm not sure what "really company-specific type" means.  Not to be
leaked on the public Internet?  Even so, and even assuming there's an
enormous number of private-use-only media types (I doubt it), what's
the reason to not encourage registration of them?

>> * DO NOT try to avoid duplicates
>
> I'm not sure this makes sense. I think it would make sense if it read "gi=
ve
> up on trying to avoid duplicates at all cost". But it almost reads like
> "let's have many duplicates, this will be fun".

I think we should discourage collisions, but the very existence of the
registry does that.  If a collision arose from registry avoidance, and
implementations have been deployed widely, then what more can we do
but accept it?

>> * EXPERT REVIEW for updates to existing registrations
>> * Eliminate any IESG or consensus review requirement
>>
>> "There is absolutely no need to prevent name collisions in the registry
>> itself because those collisions are irrelevant -- what matters is how th=
e
>> names are interpreted by recipients of messages."

If two implementations interpret the same media type name to mean
different things and thus fail to interop, *that* is a collision.
Collisions are bad, but I don't think it's necessary to avoid them at
all costs, since collisions are hardly fatal (the market will pick a
winner, or implementors will disambiguate in some other manner, such
as by content sniffing).

> Well, but isn't one goal of the effort to get the registry to (more close=
ly)
> reflect reality? In this case, if there are two application/foo, and
> applications recognize one and not the other, then there's a disconnect.

If the collision has been deployed, not allowing it to be documented
hardly makes the collision go away.

Nico
--

From evnikita2@gmail.com  Mon Nov 14 11:11:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA74911E8356 for ; Mon, 14 Nov 2011 11:11:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.334
X-Spam-Level: 
X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 d0+fTw18531z for ; Mon, 14 Nov 2011 11:11:36 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5F7121F8DC8 for ; Mon, 14 Nov 2011 11:11:33 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so119910bkb.31 for ; Mon, 14 Nov 2011 11:11:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=CE3PvmwGFDFTi4L+bpYvX8oF6H3Mr1ApiVDlVMgF9DI=; b=QxHDhqNXao/lOwqSpF0Gd3v/uuDIwJEU4DTjLlG8+x53r86WEVuM2b6Leqrprxd3Ct GLazVAF7SVDFOPHtvFDpsy3hSw5nPbYlUrPEQa6jzyqa1qgWKSKYUY9lEpUBAihDczrn FqhCAmgGXyCtnvMEOdBzPZDE48ZkA5pkNUZLo=
Received: by 10.204.154.137 with SMTP id o9mr20565812bkw.80.1321297892669; Mon, 14 Nov 2011 11:11:32 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id a4sm24228147bkq.13.2011.11.14.11.11.30 (version=SSLv3 cipher=OTHER); Mon, 14 Nov 2011 11:11:31 -0800 (PST)
Message-ID: <4EC16815.80501@gmail.com>
Date: Mon, 14 Nov 2011 21:12:21 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Apps-discuss list 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 19:11:36 -0000

Hello,

 From minutes:

> 09:05 draft-ietf-appsawg-about-uri-scheme (chairs)
>
> Room consensus for registry to be FCFS with minimal doc via template.

That is what the WG reached at the previous meeting and what is not 
there currently is in the doc.  Before it became a WG item, the authors, 
ADs and me did have a discussion on this point, but there was no 
agreement - that's why it became WG item.  What I actually think is that 
FCFS should be appropriate, but there is no point of adding a registry 
entry given no specification available whereas the MUST restriction is 
imposed.  Recently Barry has sent me the following proposal: to have the 
policy FCFS but make specification reference mandatory for 
registration.  Therefore, if there is nobody who objects, I may change 
the following text in IANA Considerations:

OLD:

>     The registration policy for new entries is "Specification Required",
>     as defined in RFC 5226 [RFC5226].  Additionally, the following
>     template MUST be provided by the registrant:

NEW:

>     The registration policy for new entries is "First Come First Served",
>     as defined in RFC 5226 [RFC5226].  Additionally, the following
>     template MUST be provided by the registrant:

OLD:

>     o Published specifications:  A reference to the published
>       specification for the registered token.

NEW:

>     o Published specifications:  A reference to the stable specification
>       MUST be provided.  The specification SHALL cover what the SPU
>       with the token being registered ought to resolve to, and SHOULD
>       cover other issues related to SPU usage.

Any comments are welcome.

Mykyta Yevstifeyev


From evnikita2@gmail.com  Mon Nov 14 11:18:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD2F11E8373 for ; Mon, 14 Nov 2011 11:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.332
X-Spam-Level: 
X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 s8zrXCip7ckI for ; Mon, 14 Nov 2011 11:18:17 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7339311E8371 for ; Mon, 14 Nov 2011 11:18:16 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so128158bkb.31 for ; Mon, 14 Nov 2011 11:18:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=DIcvXO8I/srzx4WVmvtNV6F0Raia8tIzVcm2LO/62pc=; b=VUDTIlVyG599fhx+8aA4rZNeIlF4Dg4UVaqRpGUsUPG+6zyuozXJzPZFeSOpBSNXJ0 aCK6X7G+ToA7UvCerRUCAeT+JlbNYUeE1lghzN6p01JtDBHk+Ah045clGdDehp2SBr9C o89PV1A4wYORMIVe2FmaiSko+pkl8owOzJ7Ew=
Received: by 10.205.132.69 with SMTP id ht5mr12749336bkc.115.1321298294128; Mon, 14 Nov 2011 11:18:14 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id o7sm24288427bkw.16.2011.11.14.11.18.11 (version=SSLv3 cipher=OTHER); Mon, 14 Nov 2011 11:18:12 -0800 (PST)
Message-ID: <4EC169A6.2040908@gmail.com>
Date: Mon, 14 Nov 2011 21:19:02 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <4EBD6266.6030307@gmail.com> <023801cca0ca$d9860a20$8c921e60$@packetizer.com> <4EBE04C7.5090400@gmail.com> <015301cca232$75ea36d0$61bea470$@packetizer.com>
In-Reply-To: <015301cca232$75ea36d0$61bea470$@packetizer.com>
Content-Type: multipart/alternative; boundary="------------050105010405080002060805"
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 19:18:18 -0000

This is a multi-part message in MIME format.
--------------050105010405080002060805
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

13.11.2011 20:31, Paul E. Jones wrote:
>
> Mykyta,
>
> I fear this might get complicated with references to the email 
> documents.  Those documents are trying to solve a real problem, but 
> Webfinger does not have some of those historical constraints.
>
> Here’s my proposal: let’s not reference 5335 or 5322.  Rather, let’s 
> only reference the generic URI syntax spec (RFC 3986).  Let’s define 
> the URI scheme using the syntax found there:
>
>    acctURI   = "acct:" userinfo "@" host
>

Again, if you re-use RFC 3986 productions, please have a look at RFC 
3987, a companion doc., defining IRIs and i18ned variants of  
and .  I really doubt you'll manage to avoid i18n issues anyway :-)

> The productions “userinfo†and “host†are already defined.  Perhaps 
> the one thing I don’t like is that “host†might be an IP address, but 
> perhaps some people prefer that.
>

Yes, and that is also an issue.  RFC 5322/i18n addition defined a very 
suitable production for this case, I think, so please re-consider 
returning to them.

> RFC 3986 already says that these components are UTF-8 encoded and then 
> percent-escaped when a character is outside the ASCII character set range.
>

Shouldn't we allow direct UTF-8?

> Would this be a suitable replacement for the current text?
>
> With respect to your comments on link relations and URIs, I still do 
> not understand.  You say that “nobody will benefit from link relation 
> types defined by URIsâ€, but why not?  There are several already define 
> and used today.  In any case, I would prefer that all link relation 
> values (URI or simple strings) be defined outside of the Webfinger 
> draft.  As I mentioned, there is already a registry, so one can be 
> proposed any time.
>

How will there be an automatic processing if URI relation types are only 
suitable for humans as they need to follow that URI to know out the 
meaning of the rel.?  Moreover, is that possible to define that variety 
of ever possible link relations for Webfinger?

Mykyta Yevstifeyev

> Paul
>
> *From:*"Mykyta Yevstifeyev (Ğœ. ЄвÑтіфеєв)" [mailto:evnikita2@gmail.com]
> *Sent:* Saturday, November 12, 2011 12:32 AM
> *To:* Paul E. Jones
> *Cc:* apps-discuss@ietf.org
> *Subject:* Re: [apps-discuss] Webfinger
>
> Hello Paul,
>
> 12.11.2011 1:37, Paul E. Jones wrote:
>
> Mykyta,
>
> Thanks for your positive response.
>
> To your specific questions…
>
> We would definitely want to ensure that Unicode is properly 
> supported.  In wasn’t aware of RFC 5335, so I’m glad you brought that 
> to my attention.  Do you have a pointer to the bis draft so I can see 
> exactly what is there?  I’d be fully in favor of using utf8-addr-spec.
>
>
> This is http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13.  But 
> please note that this document, unlike RFC 5335, introduced UTF-8 
> additions to *base* RFC 5322 productions.  This means that  
> will be defined as follows now:
>
>
>     addr-spec       =   local-part "@" domain
>     local-part      =   dot-atom / quoted-string / obs-local-part
>     domain          =   dot-atom / domain-literal / obs-domain
>     domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
>     dtext           =   %d33-90 /          ; Printable US-ASCII
>                         %d94-126 /         ;  characters not including
>                          obs-dtext          ;  "[", "]", or "\"
>     dtext           =/  UTF8-non-ascii     ; from 5335bis
>     dot-atom        =   [CFWS] dot-atom-text [CFWS]
>     dot-atom-text   =   1*atext *("." 1*atext)
>     atext           =/  UTF8-non-ascii     ; from 5335bis
>
>
> So everything you will have to do is to have a note on 'acct' RI being 
> possible to carry UTF8 characters and therefore being possibly IRIs.
>
>
> Link relation types might be names like “copyright†or they might be 
> URIs.  The definition of the link relation types is outside the scope 
> of the Webfinger document itself.  RFC 6415 defines the structure of 
> the documents and provides examples of some link relations and the 
> order of processing.  RFC 5988 defines the link relations more 
> generically and establishes the registry for them.  Do you think we 
> need to say more about link relations beyond what those documents cover?
>
>
> I mean that Webfinger will have to operate on a variety of link 
> relations in LRDD documents, and nobody will benefit from link 
> relation types defined by URIs used there, as this eliminates the 
> possibility for automatic processing.  So I ask whether we'll have to 
> define non-URI link relation types for all the possible Webfinger 
> use-cases?
>
>
> On section 4: noted.  We’ll try to clearly separate the normative and 
> non-normative pieces better.
>
>
> Thanks.
>
>
> On  CORS, there are some who have strongly advocated for it.  It would 
> be very useful to allow JavaScript code to perform these queries.  
> Otherwise, the queries would have to be pushed to server-side code.  
> Let’s wait on deciding what to do until we get a definitive answer on 
> CORS from the W3C.  I think Peter was going to do some investigating 
> there.
>
> Putting Webfinger into vcard: isn’t that circular?  The idea with 
> Webfinger is that you have the identity of the user (e.g., 
> paulej@packetizer.com ), but you want to 
> find more information.  If you have a vcard, then you have the user’s 
> identity (via the email tag).  Or are you suggesting that we formally 
> introduce the acct URI in vcard?  That might make sense to do.  Can 
> you clarify your proposal?
>
>
> From RFC 6350, Section 6.4.2:
>
>
> 6.4.2. EMAIL
>
>    Purpose:  To specify the electronic mail address for communication
>       with the object the vCard represents.
>
>
> ...and the use might have email address different from Webfinger ID.  
> I've already pointed to 
> http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00, 
> which VCARDDAV WG works on, and so you may try to introduce some 
> similar property for Webfinger IDs.  (You see, vCards may not carry 
> all the variety of information, though some people actually think in 
> other way, and thus it would be a good idea to provide a means of 
> accessing some additional info.)
>
>
> For comments on particular sections, I’ve added notes to each one to 
> revise them as you suggest: they’re all good suggestions.
>
>
> Yes, thanks as well.
>
>
> I would very much like to make this a WG item, of course, but none of 
> the authors will be present at this IETF meeting.  Perhaps hallway 
> dialog might take place, but not sure.  In any case, we can do this 
> via the mailing list, too.
>
>
> See Barry's note on this.
>
>
> Thanks!
>
> Paul
>
>
> All the best,
> Mykyta Yevstifeyev
>
>
> *From:*apps-discuss-bounces@ietf.org 
>  
> [mailto:apps-discuss-bounces@ietf.org] *On Behalf Of *"Mykyta 
> Yevstifeyev (?. ?????????)"
> *Sent:* Friday, November 11, 2011 12:59 PM
> *To:* apps-discuss@ietf.org 
> *Subject:* Re: [apps-discuss] Webfinger
>
> Hi Paul and all,
>
> I think you contributed a very interesting proposal indeed.  Really, 
> RFC 1288 finger protocol is now outdated, and you're right claiming 
> that it provides no means of automatic processing.  BTW, RFC 1288 is 
> currently at Draft Standard maturity level, which has been abandoned 
> by RFC 6410, and we should therefore undertake something with this 
> respect, as should we with respect of other Apps-related DSs, but that 
> is what is to be discussed separately.
>
> With respect to proposed 'acct' URI scheme:  how are you going to 
> handle internationalization (i18n)?  We have RFC 5335 defining 
>  (Experimental RFC) and IESG has already approved EAI 
> 5335bis, that will be Standards Track.  So will  be 
> allowed in 'acct' URIs in some way?
>
> Webfinger implies use of some link relations.  Is it anticipated that 
> URIs will be used as link relations types, or we'll need to define 
> link relation types for all possible use-cases of Webfinger?
>
> Your Section 4 seems to be somewhat narrative.  I propose to divide it 
> into normative specification and examples.
>
> With regard to CORS - I'm not actually acquainted with this 
> technology, but I see it is currently documented as W3C working draft, 
> so I don't suspect it is now widely-used (I may of course be wrong, so 
> please feel free to correct me), and I think there is no use putting 
> MUST requirement on its use in Webfinger.  You could better remove 
> your section on CORS from the document at all.
>
> I think we should also provide some means of mentioning Webfinger 
> accounts in vCards.  You could please see VCARDDAV document 
> http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 
> which Webfinger elements may also be incorporated.
>
> In Abstract, you should be more specific about what your document 
> defines.  I propose mentioning directly that the document is the 
> specification of Webfinger protocol, not "procedures for dicovering 
> information about people".
>
> In Section 7 you should clearly state that Webfinger (so as finger 
> itself) is intentionally left w/o any means of controlling access to 
> information (unless we want to produce *such* protocol).
>
> I see the document is on APPSAWG agenda on the meeting, so I 
> anticipate it will soon become APPSAWG item doc.  I won't be on 
> meeting, but if you discuss the adaptation of Webfinger draft please 
> also take into account I'm in favor of such adaptation (consider this 
> as my 2p).
>
> Mykyta Yevstifeyev
>
> 24.10.2011 23:09, Paul E. Jones wrote:
>
> Folks,
>
> We just submitted this:
>
> http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt
>
> The tools for Webfinger are now defined, but the procedures need to be 
> clearer with respect to what most of us understand as “webfingerâ€.  
> This is just a first stab at making that happen and we hope to 
> progress this to publish an RFC in the application area.
>
> We welcome any comments you have on the topic, either privately or 
> publicly.
>
> Paul
>
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org  
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


--------------050105010405080002060805
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    13.11.2011 20:31, Paul E. Jones wrote:
    

      
      
      
      

        
Mykyta,

        
 

        
I fear this
            might get complicated with references to the email
            documents.  Those documents are trying to solve a real
            problem, but Webfinger does not have some of those
            historical constraints.

        
 

        
Here’s my
            proposal: let’s not reference 5335 or 5322.  Rather, let’s
            only reference the generic URI syntax spec (RFC 3986). 
            Let’s define the URI scheme using the syntax found there:

        
  
            acctURI   = "acct:" userinfo "@" host

      

    

    

    Again, if you re-use RFC 3986 productions, please have a look at RFC
    3987, a companion doc., defining IRIs and i18ned variants of
    <userinfo> and <host>.  I really doubt you'll manage to
    avoid i18n issues anyway :-)

    

    

      

        

        
 

        
The
            productions “userinfo†and “host†are already defined. 
            Perhaps the one thing I don’t like is that “host†might be
            an IP address, but perhaps some people prefer that.

      

    

    

    Yes, and that is also an issue.  RFC 5322/i18n addition defined a
    very suitable production for this case, I think, so please
    re-consider returning to them.

    

    

      

        

        
 

        
RFC
            3986 already says that these components are UTF-8 encoded
            and then percent-escaped when a character is outside the
            ASCII character set range.

      

    

    

    Shouldn't we allow direct UTF-8?

    

    

      

        

        
 

        
Would this be a
            suitable replacement for the current text?

        
 

        
With
            respect to your comments on link relations and URIs, I still
            do not understand.  You say that “nobody will benefit from
            link relation types defined by URIsâ€, but why not?  There
            are several already define and used today.  In any case, I
            would prefer that all link relation values (URI or simple
            strings) be defined outside of the Webfinger draft.  As I
            mentioned, there is already a registry, so one can be
            proposed any time.

      

    

    

    How will there be an automatic processing if URI relation types are
    only suitable for humans as they need to follow that URI to know out
    the meaning of the rel.?  Moreover, is that possible to define that
    variety of ever possible link relations for Webfinger?

    

    Mykyta Yevstifeyev

    

    

      

        

        
 

        
Paul

        
 

        

          

            

              
From:
                  "Mykyta Yevstifeyev (Ğœ. ЄвÑтіфеєв)"
                  [mailto:evnikita2@gmail.com] 

                  Sent: Saturday, November 12, 2011 12:32 AM

                  To: Paul E. Jones

                  Cc: apps-discuss@ietf.org

                  Subject: Re: [apps-discuss] Webfinger

            

          

          
 

          
Hello Paul,

            

            12.11.2011 1:37, Paul E. Jones wrote: 

          
Mykyta,

          
 

          
Thanks for
              your positive response.

          
 

          
To your
              specific questions…

          
 

          
We would
              definitely want to ensure that Unicode is properly
              supported.  In wasn’t aware of RFC 5335, so I’m glad you
              brought that to my attention.  Do you have a pointer to
              the bis draft so I can see exactly what is there?  I’d be
              fully in favor of using utf8-addr-spec.

          


              This is http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13. 
              But please note that this document, unlike RFC 5335,
              introduced UTF-8 additions to *base* RFC 5322
              productions.  This means that <addr-spec> will be
              defined as follows now:

              

              

              

          
   addr-spec       =   local-part "@" domain

          
   local-part      =   dot-atom / quoted-string / obs-local-part

          
   domain          =   dot-atom / domain-literal / obs-domain

          
   domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

          
   dtext           =   %d33-90 /          ; Printable US-ASCII

          
                       %d94-126 /         ;  characters not including

          
                       obs-dtext          ;  "[", "]", or "\" 

          
   dtext           =/  UTF8-non-ascii     ; from 5335bis   

          
   dot-atom        =   [CFWS] dot-atom-text [CFWS]   

          
   dot-atom-text   =   1*atext *("." 1*atext)    

          
   atext           =/  UTF8-non-ascii     ; from 5335bis

          


              So everything you will have to do is to have a note on
              'acct' RI being possible to carry UTF8 characters and
              therefore being possibly IRIs.

              

              

              

          
 

          
Link relation
              types might be names like “copyright†or they might be
              URIs.  The definition of the link relation types is
              outside the scope of the Webfinger document itself.  RFC
              6415 defines the structure of the documents and provides
              examples of some link relations and the order of
              processing.  RFC 5988 defines the link relations more
              generically and establishes the registry for them.  Do you
              think we need to say more about link relations beyond what
              those documents cover?

          


              I mean that Webfinger will have to operate on a variety of
              link relations in LRDD documents, and nobody will benefit
              from link relation types defined by URIs used there, as
              this eliminates the possibility for automatic processing. 
              So I ask whether we'll have to define non-URI link
              relation types for all the possible Webfinger use-cases?

              

              

              

          
 

          
On section 4:
              noted.  We’ll try to clearly separate the normative and
              non-normative pieces better.

          


              Thanks.

              

              

              

          
 

          
On  CORS,
              there are some who have strongly advocated for it.  It
              would be very useful to allow JavaScript code to perform
              these queries.  Otherwise, the queries would have to be
              pushed to server-side code.  Let’s wait on deciding what
              to do until we get a definitive answer on CORS from the
              W3C.  I think Peter was going to do some investigating
              there.

          
 

          
Putting
              Webfinger into vcard: isn’t that circular?  The idea with
              Webfinger is that you have the identity of the user (e.g.,
              paulej@packetizer.com),
              but you want to find more information.  If you have a
              vcard, then you have the user’s identity (via the email
              tag).  Or are you suggesting that we formally introduce
              the acct URI in vcard?  That might make sense to do.  Can
              you clarify your proposal?

          


              From RFC 6350, Section 6.4.2:

              

              

              

          
6.4.2.
                EMAIL

              

                 Purpose:  To specify the electronic mail address
                for communication

                    with the object the vCard represents.

          


              ...and the use might have email address different from
              Webfinger ID.  I've already pointed to http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00,
              which VCARDDAV WG works on, and so you may try to
              introduce some similar property for Webfinger IDs.  (You
              see, vCards may not carry all the variety of information,
              though some people actually think in other way, and thus
              it would be a good idea to provide a means of accessing
              some additional info.)

              

              

              

          
 

          
For comments
              on particular sections, I’ve added notes to each one to
              revise them as you suggest: they’re all good suggestions.

          


              Yes, thanks as well.

              

              

              

          
 

          
I would very
              much like to make this a WG item, of course, but none of
              the authors will be present at this IETF meeting.  Perhaps
              hallway dialog might take place, but not sure.  In any
              case, we can do this via the mailing list, too.

          


              See Barry's note on this.

              

              

              

          
 

          
Thanks!

          
Paul

          


              All the best,

              Mykyta Yevstifeyev

              

              

              

          
 

          

            

              

                
From:
                    apps-discuss-bounces@ietf.org
                    [mailto:apps-discuss-bounces@ietf.org]
                    On Behalf Of "Mykyta Yevstifeyev (?.
                    ?????????)"

                    Sent: Friday, November 11, 2011 12:59 PM

                    To: apps-discuss@ietf.org

                    Subject: Re: [apps-discuss] Webfinger

              

            

            
 

            
Hi Paul and all,

              

              I think you contributed a very interesting proposal
              indeed.  Really, RFC 1288 finger protocol is now outdated,
              and you're right claiming that it provides no means of
              automatic processing.  BTW, RFC 1288 is currently at Draft
              Standard maturity level, which has been abandoned by RFC
              6410, and we should therefore undertake something with
              this respect, as should we with respect of other
              Apps-related DSs, but that is what is to be discussed
              separately.

              

              With respect to proposed 'acct' URI scheme:  how are you
              going to handle internationalization (i18n)?  We have RFC
              5335 defining <utf8-addr-spec> (Experimental RFC)
              and IESG has already approved EAI 5335bis, that will be
              Standards Track.  So will <utf8-addr-spec> be
              allowed in 'acct' URIs in some way?

              

              Webfinger implies use of some link relations.  Is it
              anticipated that URIs will be used as link relations
              types, or we'll need to define link relation types for all
              possible use-cases of Webfinger?

              

              Your Section 4 seems to be somewhat narrative.  I propose
              to divide it into normative specification and examples.

              

              With regard to CORS - I'm not actually acquainted with
              this technology, but I see it is currently documented as
              W3C working draft, so I don't suspect it is now
              widely-used (I may of course be wrong, so please feel free
              to correct me), and I think there is no use putting MUST
              requirement on its use in Webfinger.  You could better
              remove your section on CORS from the document at all.

              

              I think we should also provide some means of mentioning
              Webfinger accounts in vCards.  You could please see
              VCARDDAV document http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00
              which Webfinger elements may also be incorporated.

              

              In Abstract, you should be more specific about what your
              document defines.  I propose mentioning directly that the
              document is the specification of Webfinger protocol, not
              "procedures for dicovering information about people".

              

              In Section 7 you should clearly state that Webfinger (so
              as finger itself) is intentionally left w/o any means of
              controlling access to information (unless we want to
              produce *such* protocol).

              

              I see the document is on APPSAWG agenda on the meeting, so
              I anticipate it will soon become APPSAWG item doc.  I
              won't be on meeting, but if you discuss the adaptation of
              Webfinger draft please also take into account I'm in favor
              of such adaptation (consider this as my 2p).

              

              Mykyta Yevstifeyev

              

              24.10.2011 23:09, Paul E. Jones wrote: 

            
Folks,

            
 

            
We just submitted this:

            
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

            
 

            
The tools for Webfinger are now
              defined, but the procedures need to be clearer with
              respect to what most of us understand as “webfingerâ€. 
              This is just a first stab at making that happen and we
              hope to progress this to publish an RFC in the application
              area.

            
 

            
We welcome any comments you have on the
              topic, either privately or publicly.

            
 

            
Paul

            
 

            


                

                

                

              

            
_______________________________________________

            
apps-discuss mailing list

            
apps-discuss@ietf.org

            
https://www.ietf.org/mailman/listinfo/apps-discuss

            
 

          

          
 

        

      

    

    

  


--------------050105010405080002060805--

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Mon Nov 14 11:29:56 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003C111E81EF for ; Mon, 14 Nov 2011 11:29:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.894
X-Spam-Level: 
X-Spam-Status: No, score=-102.894 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 n1PUHxxjRcgK for ; Mon, 14 Nov 2011 11:29:55 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4059511E8164 for ; Mon, 14 Nov 2011 11:29:54 -0800 (PST)
Received: by wwe5 with SMTP id 5so3499508wwe.13 for ; Mon, 14 Nov 2011 11:29:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=FHVbSZ/eTiHf/nMMx6k5+1wfR8hqdALI4L7JqbidfhM=; b=sygY7X9/gOqTQEw+RtFubGNuEtI/DWbettlzZjOpASC9c4oLasT5DXVy+yWvV+8uBp +EIQnx0OR0le63cUJXSnFy2r2MELuca6d3U2iu6oY1vRXwHkSWr9RCBeXX+v/d5x0qa8 Xmj3W1ysuYrLrGEiu16sbr9B8+rY+iLGjQ34s=
Received: by 10.216.230.90 with SMTP id i68mr1394450weq.73.1321298994160; Mon, 14 Nov 2011 11:29:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.184.147 with HTTP; Mon, 14 Nov 2011 11:29:13 -0800 (PST)
In-Reply-To: 
References:   
From: Frank Ellermann 
Date: Mon, 14 Nov 2011 20:29:13 +0100
Message-ID: 
To: Nico Williams 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 19:29:56 -0000

On 14 November 2011 19:56, Nico Williams wrote:

>> in the real world the "secret mission" of the IETF
>> is IMHO to protect the IANA from "patent nonsense".

> I assume you're not referring to patents here (as in IPR).

"Patent nonsense" is one of the reason for a "speedy
deletion" in Wikipedia.  IANA is not a Wikipedia, it
has no "recent change patrol" to revert vandalism or
controversial "bold" registrations.

> I think IANA can jufge frivolous requests. =A0If not
> we can require enough review to filter out frivolous
> requests.

That they do not not have to judge this (generally),
because there is an appointed expert and an appeal
chain independent of IANA, is a feature of most IANA
registries I'm interested in.

>From my five happIANA tests the one not yet handled
is a about a registry populated by RFCs, where an old
value in an RFC published before the registry existed
did not yet make it into the registry (as "historic").

-Frank

From ned.freed@mrochek.com  Mon Nov 14 12:57:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767811F0D07 for ; Mon, 14 Nov 2011 12:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level: 
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 esE9XQzbC1E6 for ; Mon, 14 Nov 2011 12:57:32 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C099B1F0CF6 for ; Mon, 14 Nov 2011 12:57:31 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8ETBRYZGG00033H@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 12:57:09 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 12:57:04 -0800 (PST)
Message-id: <01O8ETBP3QY400RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 11:33:47 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 14 Nov 2011 16:09:18 +0900" <4EC0BE9E.8020702@it.aoyama.ac.jp>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp>
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI	schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 20:57:33 -0000

> > * Eliminate standards, vendor, personal trees distinction for MIME types
> > (For URI schemes, eliminate distinction between provisional and permanent
> > schemes)

OK, so let's see if I have this straight. There are four subprocesses involved:

(1) Personal type registrations. Rarely used.
(2) Vendor type registration. Commonly and successfully used.
(3) Standards tree registration. Used but has issues with timely processing
    of requests that we're supposed to be tryhing to fix.
(4) Third party revisions and comments process. Essentially never used.

And the proposal is to throw out (1)-(3) and depend on (4) happening because
... well, because.. This seems ... unlikely.

> > * ENCOURAGE vendors to ship with vendor-neutral short-named types
> > regardless of whether they have been registered yet or not;

I think encouraging vendor-neutral registrations would be great. The
question is how we'd actually do it.

> I think that makes sense for something widely known and used (e.g.
> application/pdf), but not necessarily for some really company-specific
> type. (Of course, we don't know in advance which way something may go in
> the end, but we could use this rule at least for when the company e.g.
> wants to express that a type is NOT intended for general use).

> >     ENCOURAGE the public to register any names that they have seen in
> > deployed software. (same for URI schemes)

> I think third-party registration is indeed something we should encourage
> more.

How do you propose we do that?

> > * DO NOT try to avoid duplicates

> I'm not sure this makes sense. I think it would make sense if it read
> "give up on trying to avoid duplicates at all cost". But it almost reads
> like "let's have many duplicates, this will be fun".

Agreed.

> > * EXPERT REVIEW for updates to existing registrations
> > * Eliminate any IESG or consensus review requirement
> >
> > "There is absolutely no need to prevent name collisions in the registry itself because those collisions are irrelevant -- what matters is how the names are interpreted by recipients of messages."

> Well, but isn't one goal of the effort to get the registry to (more
> closely) reflect reality? In this case, if there are two
> application/foo, and applications recognize one and not the other, then
> there's a disconnect.

Indeed there is, but not as big as the disconnect in thinking there's a magical
cure here that's going to solve all the problems.

				Ned

From ned.freed@mrochek.com  Mon Nov 14 13:14:27 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2FC11E818E for ; Mon, 14 Nov 2011 13:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level: 
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018,  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 EAVsbBYh30J0 for ; Mon, 14 Nov 2011 13:14:27 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2C44E11E812F for ; Mon, 14 Nov 2011 13:14:27 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8ETX488PS0025DU@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 13:14:21 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=utf-8
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 13:14:15 -0800 (PST)
Message-id: <01O8ETX0DJ4U00RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 13:06:16 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 14 Nov 2011 13:06:08 -0600" 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> 
To: Nico Williams 
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI	schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 21:14:27 -0000

> On Mon, Nov 14, 2011 at 1:09 AM, "Martin J. Dürst"
>  wrote:
> > On 2011/11/14 3:59, Larry Masinter wrote:
> >> * Eliminate standards, vendor, personal trees distinction for MIME types
> >> (For URI schemes, eliminate distinction between provisional and permanent
> >> schemes)
> >> * ENCOURAGE vendors to ship with vendor-neutral short-named types
> >> regardless of whether they have been registered yet or not;
> >
> > I think that makes sense for something widely known and used (e.g.
> > application/pdf), but not necessarily for some really company-specific type.
> > (Of course, we don't know in advance which way something may go in the end,
> > but we could use this rule at least for when the company e.g. wants to
> > express that a type is NOT intended for general use).

> I'm not sure what "really company-specific type" means.  Not to be
> leaked on the public Internet?  Even so, and even assuming there's an
> enormous number of private-use-only media types (I doubt it), what's
> the reason to not encourage registration of them?

There actually a fairly large number of company-specific types, which is why we
allow the company name to be included in the type name. But as you say, the
majority of types aren't of this sort, which is why we don't require the
company name be present.

> >> * DO NOT try to avoid duplicates
> >
> > I'm not sure this makes sense. I think it would make sense if it read "give
> > up on trying to avoid duplicates at all cost". But it almost reads like
> > "let's have many duplicates, this will be fun".

> I think we should discourage collisions, but the very existence of the
> registry does that.  If a collision arose from registry avoidance, and
> implementations have been deployed widely, then what more can we do
> but accept it?

Agreed, but in practice it doesn't seem like outright collisions have
been much of an issue.

				Ned

From ned.freed@mrochek.com  Mon Nov 14 13:52:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DBB21F8EA5 for ; Mon, 14 Nov 2011 13:52:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.431
X-Spam-Level: 
X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 3kztmOf7fNSq for ; Mon, 14 Nov 2011 13:52:32 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6271A21F8AD6 for ; Mon, 14 Nov 2011 13:52:32 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8EV9BVJCG011863@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 13:52:27 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 13:52:21 -0800 (PST)
Message-id: <01O8EV98HXC800RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 13:44:09 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 14 Nov 2011 16:27:04 +0900" <4EC0C2C8.2010500@it.aoyama.ac.jp>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp>
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Cc: "gadams@xfsi.com" , David Singer , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 21:52:33 -0000

> On 2011/11/13 5:25, Larry Masinter wrote:
> > I see no use case for why having font/opentype is any better than application/opentype

> It's just fine if you, and some others, don't see it. Does that mean
> that you have to fight against it? You haven't shown, even less
> mentioned, any problem for font/opentype.

Good point. I have no skin in this particular game - aside from slightly
complicating the media review process I have no personal need for font/*. But
if there's a constituency this type helps, I'm all for it.

> My guess is that we would have around 10 or so font types registered
> (and no font type sniffing) if a font/ top level type had been approved
> in a 1990'ish timeframe.

And we may or may not have any luck rectifying this at this late date. But I'm
not  seeing a reason not to try.

> ...

> > I also recall a number of years ago an attempt to define "chemical/*" as a
> > new top level type for use in defining file formats?

> So what? Were there good reasons to reject it? Or was it rejected
> because some people believed that new top level types were "A BIG
> NO-NO"? Or because of some FUD?

Didn't chemical kind of morph into model? Or am I getting the history confused?

> > My conclusion from this discussion is that we should declare the MIME
> > hierarchy closed to new top level types; we've only gotten very limited use and
> > value out of the hierarchy, compared to the pain and difficulty (text/xml vs
> > application/xml).

> The problems between text/xml and application/xml are very specific. And
> they may be interpreted to say that tying particular processing rules to
> particular types, unless absolutely necessary (e.g. structured types),
> may be a bad idea. That doesn't mean that top-level types in general are
> a bad idea.

Agreed.

> The reason that we have gotten very little value out of registering new
> top level types may be mostly that virtually no new types have been
> registered, because people are claiming that we get very little value
> out of them. It sounds funny, but it isn't.

No, it really isn't funny, is it?

				Ned

From stpeter@stpeter.im  Mon Nov 14 13:53:51 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CB011E81C7 for ; Mon, 14 Nov 2011 13:53:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.704
X-Spam-Level: 
X-Spam-Status: No, score=-101.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_061228=0.895, 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 iVDp3iywWP5t for ; Mon, 14 Nov 2011 13:53:51 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3D00C11E8190 for ; Mon, 14 Nov 2011 13:53:51 -0800 (PST)
Received: from squire.local (unknown [61.230.53.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3E9BF4214E; Mon, 14 Nov 2011 15:00:01 -0700 (MST)
Message-ID: <4EC18DEB.6090003@stpeter.im>
Date: Tue, 15 Nov 2011 05:53:47 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Mark Nottingham 
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com> 	<4EC0AD84.5060502@dcrocker.net>  <4EC0D517.3030400@dcrocker.net>  <4EC0F17B.5020003@dcrocker.net> <4EC0F1E7.7000602@stpeter.im> <4B9A1851-31B5-4147-A284-77A63664401C@mnot.net>
In-Reply-To: <4B9A1851-31B5-4147-A284-77A63664401C@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Randall Gellens , dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: [apps-discuss] status and name (was: Re: I-D Action: draft-ietf-appsawg-xdash-02.txt)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 21:53:51 -0000

On 11/14/11 11:32 PM, Mark Nottingham wrote:
>
> On 14/11/2011, at 4:48 AM, Peter Saint-Andre wrote:
>
>> On 11/14/11 6:46 PM, Dave CROCKER wrote:
>>
>>> Keep status separate from name.
>>
>> Exactly!
>
>
> +1

The same principle has emerged from discussions on the "Happy IANA" list 
(i.e., registration of parameters does not imply advancement along a 
standardization path). I sense a theme...

/psa



From dhc@dcrocker.net  Mon Nov 14 14:05:43 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C540211E824D for ; Mon, 14 Nov 2011 14:05:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.795
X-Spam-Level: 
X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[AWL=0.243,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=1.666]
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 di4yphW4WSzB for ; Mon, 14 Nov 2011 14:05:43 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E01F11E8243 for ; Mon, 14 Nov 2011 14:05:43 -0800 (PST)
Received: from [192.168.0.229] (61-230-53-171.dynamic.hinet.net [61.230.53.171]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAEM5WCg027969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2011 14:05:40 -0800
Message-ID: <4EC190AA.3000705@dcrocker.net>
Date: Tue, 15 Nov 2011 06:05:30 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com> 	<4EC0AD84.5060502@dcrocker.net>  <4EC0D517.3030400@dcrocker.net>  <4EC0F17B.5020003@dcrocker.net> <4EC0F1E7.7000602@stpeter.im> <4B9A1851-31B5-4147-A284-77A63664401C@mnot.net> <4EC18DEB.6090003@stpeter.im>
In-Reply-To: <4EC18DEB.6090003@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 14 Nov 2011 14:05:42 -0800 (PST)
Cc: Mark Nottingham , Randall Gellens , apps-discuss@ietf.org
Subject: Re: [apps-discuss] status and name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 22:05:43 -0000

On 11/15/2011 5:53 AM, Peter Saint-Andre wrote:

> The same principle has emerged from discussions on the "Happy IANA" list (i.e.,
> registration of parameters does not imply advancement along a standardization
> path). I sense a theme...


It's actually closer to a principle.

It is extremely natural to want names to carry deep semantics.  It's an easy 
place to put parametric information.  Unfortunately it seems to always create 
problems, most notably when there is a change in state, which is exactly the 
concern we are dealing with in the draft.

d/


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From stpeter@stpeter.im  Mon Nov 14 14:10:29 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D9A11E824F for ; Mon, 14 Nov 2011 14:10:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.704
X-Spam-Level: 
X-Spam-Status: No, score=-101.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_061228=0.895, 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 BaORZyGDdhqu for ; Mon, 14 Nov 2011 14:10:28 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABC211E820F for ; Mon, 14 Nov 2011 14:10:28 -0800 (PST)
Received: from squire.local (unknown [61.230.53.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4194F4214E; Mon, 14 Nov 2011 15:16:31 -0700 (MST)
Message-ID: <4EC191C9.2070609@stpeter.im>
Date: Tue, 15 Nov 2011 06:10:17 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ned Freed 
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com>
In-Reply-To: <01O8EV98HXC800RCTX@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: David Singer , "apps-discuss@ietf.org" , "gadams@xfsi.com" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 22:10:29 -0000

On 11/15/11 5:44 AM, Ned Freed wrote:
>> On 2011/11/13 5:25, Larry Masinter wrote:
>> > I see no use case for why having font/opentype is any better than
>> application/opentype
>
>> It's just fine if you, and some others, don't see it. Does that mean
>> that you have to fight against it? You haven't shown, even less
>> mentioned, any problem for font/opentype.
>
> Good point. I have no skin in this particular game - aside from slightly
> complicating the media review process I have no personal need for
> font/*. But
> if there's a constituency this type helps, I'm all for it.

I think the ball is now in the court of those who think they might want 
to register font/ -- any volunteers? I will also ping our W3C friends to 
see if someone active there has energy to work on this.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From nico@cryptonector.com  Mon Nov 14 14:11:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAD211E8215 for ; Mon, 14 Nov 2011 14:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.926
X-Spam-Level: 
X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.051,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 57n31WT5Hm61 for ; Mon, 14 Nov 2011 14:11:35 -0800 (PST)
Received: from homiemail-a95.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 2A29C11E820F for ; Mon, 14 Nov 2011 14:11:35 -0800 (PST)
Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id C38BA1E06E for ; Mon, 14 Nov 2011 14:11:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=x0SFFiFGt7xrYfDxCH9lMFp1b46olX1pMTs1NJZa4aKi diCmLrxCxCEANAjZwTe9w9NKH42AutilfXWs9dBnQOSMUaZLLdrYkMhqRsF62mSd Sa4r9AyDGTct8upeo6ajjl1A1WdegMi8o4/3Lm+U5h3CMhcgx/3z+r4J895HnAA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=bBsDzhKKAMZGG1CxrWhLqgQdLMA=; b=PpcHi86Fz8e i/CJZW+tIgl6LOyfuRzW4oF1ZsljZ2Lpz1Ixd7xal+r6DA4+kPGtqb8088z2fsjv EWnKpYtGH7SvE7Km1Hfhrq+IZFhKc5luaNyfS60UihvOJncp7XRVUOdNCcckj6GF +8pfcRPysY30o4FycOeLJeZ8Zam2LFAs=
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 9CFEC1E06C for ; Mon, 14 Nov 2011 14:11:34 -0800 (PST)
Received: by ggnr5 with SMTP id r5so1595335ggn.31 for ; Mon, 14 Nov 2011 14:11:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.38.68 with SMTP id e4mr52565428pbk.126.1321308693721; Mon, 14 Nov 2011 14:11:33 -0800 (PST)
Received: by 10.68.40.162 with HTTP; Mon, 14 Nov 2011 14:11:33 -0800 (PST)
In-Reply-To: <01O8ETX0DJ4U00RCTX@mauve.mrochek.com>
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp>  <01O8ETX0DJ4U00RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 16:11:33 -0600
Message-ID: 
From: Nico Williams 
To: Ned Freed 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 22:11:35 -0000

On Mon, Nov 14, 2011 at 3:06 PM, Ned Freed  wrote:
>> >> * DO NOT try to avoid duplicates
>> >
>> > I'm not sure this makes sense. I think it would make sense if it read =
"give
>> > up on trying to avoid duplicates at all cost". But it almost reads lik=
e
>> > "let's have many duplicates, this will be fun".
>
>> I think we should discourage collisions, but the very existence of the
>> registry does that. =C2=A0If a collision arose from registry avoidance, =
and
>> implementations have been deployed widely, then what more can we do
>> but accept it?
>
> Agreed, but in practice it doesn't seem like outright collisions have
> been much of an issue.

I think what Roy F. is saying is that the cost of registration has to
come down a lot.  If collisions are a problem at all they must be a
relatively small problem, and you (and Roy F.) claim that collisions
are of little consequence, in which case we can lower the cost of
registration still more.

Nico
--

From ned.freed@mrochek.com  Mon Nov 14 14:31:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D21111E8330 for ; Mon, 14 Nov 2011 14:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level: 
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021,  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 8yQv01ONKpMq for ; Mon, 14 Nov 2011 14:31:30 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC2A11E8323 for ; Mon, 14 Nov 2011 14:31:30 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8EWMME3OG0025HE@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 14:31:24 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 14:31:20 -0800 (PST)
Message-id: <01O8EWMK2T8E00RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 14:10:33 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 14 Nov 2011 16:09:18 +0800" <4EC0CCAE.5070402@stpeter.im>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com> <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com> <4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im>
To: Peter Saint-Andre 
Cc: Ned Freed , apps-discuss@ietf.org
Subject: Re: [apps-discuss] type name suffixes (was: Re:  font/*)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 22:31:30 -0000

> On 11/12/11 4:46 AM, Ned Freed wrote:
> >> On 2011/11/11 1:23, Ned Freed wrote:
> >
> >> >> On 2011/11/10 13:06, Ned Freed wrote:
> >
> >> >> > In practice the issue of what to register where has never been much
> >> >> of a
> >> >> > problem. Speaking now as media types reviewer, I have not
> >> infrequently
> >> >> > pushed
> >> >> > back on top-level type choices, usually successfully and always
> >> >> amicably.
> >> >
> >> >> Do you know of any examples? This could help Dave with the general
> >> list
> >> >> of criteria that he wants to develop.
> >> >
> >> > I can't get into specifics without talking about the content of
> >> > preliminary registration requests, which I try not to do. I can say
> >> that
> >> > the most common one has been someone asking for application when
> >> image or
> >> > video would be more appropriate.
> >> >
> >> > The most common name change I request, however, is the addition of
> >> +xml.
> >
> >> Okay. This is about change from one existing top-level type to another,
> >> and about tweaking the minor type name with a suffix.
> >
> > Understood. Both things happen. As I said, the most common top level change
> > is from application to image or video. Next up would probably moves from
> > text to application, but come to think of it I haven't have one of those
> > in a while.
> >
> >> Out of the context
> >> of the discussion, I thought that you were speaking about new top-level
> >> types when you wrote "I have not infrequently pushed back on top-level
> >> type choices", but now I see that that's not a necessary interpretation.
> >
> > I was simply noting that the most common change isn't a top-level
> > change, but
> > rather the addition of +xml. My apologies if that was confusing.

> I notice that draft-freed-media-type-regs-01 talked about structured
> type name suffixes (e.g., "+xml") and calls for creation of a registry
> for such suffixes. Ned, do you have thoughts on how people can more
> easily define such suffixes, before draft-freed-media-type-regs (or
> something like it) is approved?

Well, right now there is no process. RFC 4288 has some weasel-words about
"using +sufffixes with care", so as reviewer that's what I do - I've allowed
types with +json and +wbxml, I believe, but given the language I haven't felt
comfortable asking people to add anything other than +xml to types that
had no suffx.

I don't recall pushing back on any suffix usage, but I may have - I've reviewed
a lot of types!

> The reason I ask is that I've had a few
> people ask me about this topic recently.

Well, the preferable thing would be to get the process Tony defined that I
included in 4288bis approved. Absent that, the rule is more or less that you
can use a suffix if you like and if it seems to make sense.

				Ned

From sm@elandsys.com  Mon Nov 14 14:36:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D58411E81C7 for ; Mon, 14 Nov 2011 14:36:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T8YO7Z33c3c for ; Mon, 14 Nov 2011 14:36:37 -0800 (PST)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 17E2E11E817C for ; Mon, 14 Nov 2011 14:36:37 -0800 (PST)
Received: from sm-THINK.elandsys.com (dhcp-4349.meeting.ietf.org [130.129.67.73]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id pAEMaVCK000884; Mon, 14 Nov 2011 14:36:35 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1321310196; bh=vC5z6V41DLOjeJB/o6yeRk/6/AQ=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=iBR8k2U2moGyeJ9Q/8cYFiEVl5BLwzK6ITTWwla8OM5ctyOuhYzOtfostYxESTb5B HphxX1TpN1ngO36IXqv7zoi5PcDZQXI1ZajvY0G9eDgvwG7kQIWI4D3KqR/Af3jQWB zEh9/Nr7YFw3ZSYgbgt9LQMRncg2bXipExgliJaM=
Message-Id: <6.2.5.6.2.20111114142451.09b74390@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 14 Nov 2011 14:35:02 -0800
To: apps-discuss@ietf.org
From: S Moonesamy 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ietf-smtp@imc.org
Subject: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 22:36:41 -0000

Hello,

I would appreciate some feedback on 
draft-moonesamy-smtp-ipv6-00.  The I-D discusses about SMTP in an 
IPv4/IPv6 dual stack environment.  It documents the algorithm 
initially specified in RFC 3974 which is used in several SMTP implementations.

The change from RFC 3974 is:

  - Removal of the Basic DNS Resource Record Definitions for Mail 
Routing section

  - Removal of the SMTP Sender Algorithm in a Dual-Stack Environment section

  - Removal of the Operational Experience and open issues sections.

  - RFC 5321 remains authoritative for SMTP

Please note that the algorithm has already been used in several 
existing implementations.

Regards,
S. Moonesamy


From mnot@mnot.net  Mon Nov 14 14:46:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC44A11E817C for ; Mon, 14 Nov 2011 14:46:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.907
X-Spam-Level: 
X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=-0.308, 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 neZB5O2fr0NG for ; Mon, 14 Nov 2011 14:46:46 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 281C911E80D6 for ; Mon, 14 Nov 2011 14:46:46 -0800 (PST)
Received: from [10.6.129.23] (unknown [64.39.4.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 884CA22E1EB; Mon, 14 Nov 2011 17:46:39 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: 
Date: Mon, 14 Nov 2011 16:46:41 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <5900EAE0-9572-42DB-990C-5ADAD3B443A6@mnot.net>
References: 
To: Larry Masinter 
X-Mailer: Apple Mail (2.1251.1)
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 22:46:47 -0000

Larry,

I was happy to see your positive response to this; what we're trying to =
do with happiana is aligned with the spirit of what Roy is proposing (as =
was said later in this thread, to reduce the cost of registration), if =
not the details (because that's where the devil lies, as pointed out by =
Frank and others).

Folks who haven't been following that list may want to have a quick look =
through:
  http://www.w3.org/wiki/FriendlyRegistries
  http://www.w3.org/wiki/FriendlyRegistryProcess

Cheers,


On 13/11/2011, at 12:59 PM, Larry Masinter wrote:

> I'd like to discuss the proposal for MIME registrations from Roy =
Fielding in =
http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html
> and the possibility that such changes should also apply to URI =
schemes.
>=20
> You can read Roy's rationale, which makes sense to me, but my summary =
is:=20
>=20
> * Eliminate standards, vendor, personal trees distinction for MIME =
types (For URI schemes, eliminate distinction between provisional and =
permanent schemes)
> * ENCOURAGE vendors to ship with vendor-neutral short-named types =
regardless of whether they have been registered yet or not;
>   ENCOURAGE the public to register any names that they have seen in =
deployed software. (same for URI schemes)
> * DO NOT try to avoid duplicates=20
> * EXPERT REVIEW for updates to existing registrations
> * Eliminate any IESG or consensus review requirement
>=20
> "There is absolutely no need to prevent name collisions in the =
registry itself because those collisions are irrelevant -- what matters =
is how the names are interpreted by recipients of messages."
> "There is absolutely no need to prevent people who are not the owners =
of a media type from registering that type without any prefixes."
> "The registry is not operable -- it is just documentation of how the =
Internet is operating, and it should reflect the reality of that =
operation even if that means we have multiple definitions per registered =
type."
>=20
> I find this perspective appealing, and can't find anything wrong with =
it except that it's a break with tradition. If you're at IETF this week =
and want to talk about it, find me.
>=20
> Larry=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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





From stpeter@stpeter.im  Mon Nov 14 15:02:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FF41F0C6C for ; Mon, 14 Nov 2011 15:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPdbJses7bSd for ; Mon, 14 Nov 2011 15:02:08 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2F61F0C77 for ; Mon, 14 Nov 2011 15:02:08 -0800 (PST)
Received: from squire.local (unknown [61.31.89.133]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 32CE74214E; Mon, 14 Nov 2011 16:08:17 -0700 (MST)
Message-ID: <4EC19DEC.6020908@stpeter.im>
Date: Tue, 15 Nov 2011 07:02:04 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Mark Nottingham 
References:  <5900EAE0-9572-42DB-990C-5ADAD3B443A6@mnot.net>
In-Reply-To: <5900EAE0-9572-42DB-990C-5ADAD3B443A6@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 23:02:08 -0000

On 11/15/11 6:46 AM, Mark Nottingham wrote:
> Larry,
>
> I was happy to see your positive response to this; what we're trying to do with happiana is aligned with the spirit of what Roy is proposing (as was said later in this thread, to reduce the cost of registration), if not the details (because that's where the devil lies, as pointed out by Frank and others).
>
> Folks who haven't been following that list may want to have a quick look through:
>    http://www.w3.org/wiki/FriendlyRegistries
>    http://www.w3.org/wiki/FriendlyRegistryProcess

It's a wiki, feel free to edit. :)

Also, the happiana list is public:

https://www.ietf.org/mailman/listinfo/happiana

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From ned.freed@mrochek.com  Mon Nov 14 15:02:49 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B68D1F0C6C for ; Mon, 14 Nov 2011 15:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level: 
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020,  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 X68zQ4YGtNNy for ; Mon, 14 Nov 2011 15:02:48 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C71461F0CB7 for ; Mon, 14 Nov 2011 15:02:47 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8EXP7UM740180D5@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 15:02:31 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 15:02:24 -0800 (PST)
Message-id: <01O8EXP3E5XQ00RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 14:50:57 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 14 Nov 2011 16:11:33 -0600" 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp>  <01O8ETX0DJ4U00RCTX@mauve.mrochek.com> 
To: Nico Williams 
Cc: Ned Freed , Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 23:02:49 -0000

> On Mon, Nov 14, 2011 at 3:06 PM, Ned Freed  wrote:
> >> >> * DO NOT try to avoid duplicates
> >> >
> >> > I'm not sure this makes sense. I think it would make sense if it read "give
> >> > up on trying to avoid duplicates at all cost". But it almost reads like
> >> > "let's have many duplicates, this will be fun".
> >
> >> I think we should discourage collisions, but the very existence of the
> >> registry does that.  If a collision arose from registry avoidance, and
> >> implementations have been deployed widely, then what more can we do
> >> but accept it?
> >
> > Agreed, but in practice it doesn't seem like outright collisions have
> > been much of an issue.

> I think what Roy F. is saying is that the cost of registration has to
> come down a lot.

And what I'm saying is that the current cost is, Roy's beliefs to the contrary
notwithstanding, quite low - as in answer a half dozen questions on a web form
low. And we've been actively pursuing various tweaks to move the bar even
lower.

Furthermore, the proposed alternative of allowing a sort of free-for-all where
random folks can register and comment on stuff willy-nilly, is actually pretty
much the process we already have for media type comments. Except here's the
funny thing: Despite the current ready availability of the process that's
supposed to cure all our ills, essentially nobody ever uses it.

> If collisions are a problem at all they must be a
> relatively small problem, and you (and Roy F.) claim that collisions
> are of little consequence, in which case we can lower the cost of
> registration still more.

This assumes that currently there's significant cost associated with collision
checks. I can't speak to other registries, but I can assure you the amount
of time spent on this in the case of media types is truly negligable.

				Ned

From singer@apple.com  Mon Nov 14 15:50:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC2F21F8DEF for ; Mon, 14 Nov 2011 15:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level: 
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 T6k3U3gQ6KlM for ; Mon, 14 Nov 2011 15:50:35 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id B8AAF11E8081 for ; Mon, 14 Nov 2011 15:50:34 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LUO009P4CSKCLX2@mail-out.apple.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 15:50:07 -0800 (PST)
X-AuditID: 11807134-b7ce4ae0000052e8-91-4ec1a92f3a11
Received: from [17.151.77.208] (Unknown_Domain [17.151.77.208]) by relay14.apple.com (Apple SCV relay) with SMTP id 64.48.21224.F29A1CE4; Mon, 14 Nov 2011 15:50:07 -0800 (PST)
From: David Singer 
In-reply-to: <01O8EV98HXC800RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 15:50:06 -0800
Content-transfer-encoding: quoted-printable
Message-id: <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com>
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com>
To: Ned Freed 
X-Mailer: Apple Mail (2.1251.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUiON33gq7+yoN+Bv+71C1Wv1zBZtF+9wq7 xbaDSxgt/t2ZwGyxfuU0NouNfxaxO7B5TPvZw+yxZMlPJo+myzOYPObtOMTk8W/udnaPZXP3 sASwRXHZpKTmZJalFunbJXBlbP3SxFJwUqRiwstVzA2MXQJdjJwcEgImEmea5rNC2GISF+6t Z+ti5OIQEtjIKPHx4h6whLCAi8SiS+uZQGxeAWOJNbfesYDYzAJ6Ejuu/wKrYRNQlXgw5xgj iM0JVLOocSlYnAUo3r75KzPIUGaB74wS+6+uYYdo1pZYtvA1M8RQG4kNN38zQ2yezSjxZGkb 2CQRoO4Fe5tZIM6Tl2j5eodtAiP/LCSHzEJyyCwkcxcwMq9iFCxKzUmsNDTRSywoyEnVS87P 3cQICuWGQpMdjAd/8h9iFOBgVOLhPRly0E+INbGsuDL3EKMEB7OSCG9QGVCINyWxsiq1KD++ qDQntfgQozQHi5I4LzdISiA9sSQ1OzW1ILUIJsvEwSnVwBif2/Mk7vnOA8u8Lr/hWrqhmXHD 2tjs7Av/1BiLghKnRp1W4Jqyc/HtzgfPnEviNu3PC26YHZ/71nG56mfOVs6OPUL39orq/D7k NFuzdeqWJJusQ0U743bKnVxcuq/08N2k4s1fk5gerT3++b/Y5B96MRpW87jFxX+kzGaQ3qa7 PfnysikKQiuUWIozEg21mIuKEwGuDZd2YQIAAA==
Cc: "gadams@xfsi.com Adams" , Vladimir Levantovsky , apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Nov 2011 23:50:36 -0000

I probably shouldn't volunteer people, but I know Vladimir Levantovsky =
has expressed interest in this question in the past.  I am sure he'd =
want to be aware of this discussion.  In fact, I am cc'ing him here=85.


On Nov 14, 2011, at 13:44 , Ned Freed wrote:

>> On 2011/11/13 5:25, Larry Masinter wrote:
>> > I see no use case for why having font/opentype is any better than =
application/opentype
>=20
>> It's just fine if you, and some others, don't see it. Does that mean
>> that you have to fight against it? You haven't shown, even less
>> mentioned, any problem for font/opentype.
>=20
> Good point. I have no skin in this particular game - aside from =
slightly
> complicating the media review process I have no personal need for =
font/*. But
> if there's a constituency this type helps, I'm all for it.
>=20
>> My guess is that we would have around 10 or so font types registered
>> (and no font type sniffing) if a font/ top level type had been =
approved
>> in a 1990'ish timeframe.
>=20
> And we may or may not have any luck rectifying this at this late date. =
But I'm
> not  seeing a reason not to try.
>=20
>> ...
>=20
>> > I also recall a number of years ago an attempt to define =
"chemical/*" as a
>> > new top level type for use in defining file formats?
>=20
>> So what? Were there good reasons to reject it? Or was it rejected
>> because some people believed that new top level types were "A BIG
>> NO-NO"? Or because of some FUD?
>=20
> Didn't chemical kind of morph into model? Or am I getting the history =
confused?
>=20
>> > My conclusion from this discussion is that we should declare the =
MIME
>> > hierarchy closed to new top level types; we've only gotten very =
limited use and
>> > value out of the hierarchy, compared to the pain and difficulty =
(text/xml vs
>> > application/xml).
>=20
>> The problems between text/xml and application/xml are very specific. =
And
>> they may be interpreted to say that tying particular processing rules =
to
>> particular types, unless absolutely necessary (e.g. structured =
types),
>> may be a bad idea. That doesn't mean that top-level types in general =
are
>> a bad idea.
>=20
> Agreed.
>=20
>> The reason that we have gotten very little value out of registering =
new
>> top level types may be mostly that virtually no new types have been
>> registered, because people are claiming that we get very little value
>> out of them. It sounds funny, but it isn't.
>=20
> No, it really isn't funny, is it?
>=20
> 				Ned

David Singer
Multimedia and Software Standards, Apple Inc.


From duerst@it.aoyama.ac.jp  Mon Nov 14 17:15:14 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C3611E818C for ; Mon, 14 Nov 2011 17:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.612
X-Spam-Level: 
X-Spam-Status: No, score=-99.612 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZVMVJaEa0as for ; Mon, 14 Nov 2011 17:15:14 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3C71611E8134 for ; Mon, 14 Nov 2011 17:15:14 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAF1F80W015468 for ; Tue, 15 Nov 2011 10:15:08 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2029_0fb0_41eec60e_0f27_11e1_a079_001d096c5782; Tue, 15 Nov 2011 10:15:08 +0900
Received: from [IPv6:::1] ([133.2.210.1]:35220) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Tue, 15 Nov 2011 10:15:11 +0900
Message-ID: <4EC1BD19.6050407@it.aoyama.ac.jp>
Date: Tue, 15 Nov 2011 10:15:05 +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: David Singer 
References:  <3C5268E5-FE9E-4148-8955-0450304BB407@apple.com>
In-Reply-To: <3C5268E5-FE9E-4148-8955-0450304BB407@apple.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "gadams@xfsi.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 01:15:15 -0000

On 2011/11/15 3:35, David Singer wrote:
>
> On Nov 12, 2011, at 12:25 , Larry Masinter wrote:
>
>> I see no use case for why having font/opentype is any better than application/opentype
>>
>> The only use case I can imagine from looking at
>> http://tools.ietf.org/html/draft-singer-font-mime-00
>> is the possibility of defining common parameters across font data types (in the same way that text/.. has a common charset parameter).
>
> How serious is the first concern "First, the  "application" sub-tree is treated (correctly) with great caution with respect to viruses and other active code."?

I very much think that having a  font/ top level type is actually a good 
idea. But I hinted at this before: a type shouldn't be treated as "more 
safe" just because it says font/, rather than application/. Many font 
formats contain active code that is executed by the font engine. Several 
security holes have been found in this area. So I'd actually 
de-emphasize or remove this point. draft-singer-font-mime-00 also 
doesn't have a security section, and it of course needs one.


> (The reason I abandoned the draft was not the difficulty of getting it through, by the way, but because the W3C Timed Text group decided it didn't need it).

Can you be more specific? E.g., does Timed Text only use one font 
format? Or does it not contain any field that indicates the format, 
which makes this "somebody else's problem"? Or some other reason?

Regards,    Martin.

From duerst@it.aoyama.ac.jp  Mon Nov 14 17:43:56 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE1A11E8099 for ; Mon, 14 Nov 2011 17:43:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.615
X-Spam-Level: 
X-Spam-Status: No, score=-99.615 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzr4oahzVqqq for ; Mon, 14 Nov 2011 17:43:55 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2D11E80CC for ; Mon, 14 Nov 2011 17:43:55 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAF1hsUu028267 for ; Tue, 15 Nov 2011 10:43:54 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2c90_2d54_46ba6716_0f2b_11e1_bd48_001d096c566a; Tue, 15 Nov 2011 10:43:54 +0900
Received: from [IPv6:::1] ([133.2.210.1]:47226) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Tue, 15 Nov 2011 10:43:57 +0900
Message-ID: <4EC1C3D7.7070402@it.aoyama.ac.jp>
Date: Tue, 15 Nov 2011 10:43:51 +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: Ned Freed 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com>
In-Reply-To: <01O8ETBP3QY400RCTX@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: [apps-discuss] Encouraging third party registrations (was: Re: A modest proposal for MIME types (and URI	schemes))
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 01:43:56 -0000

Hello Ned, others,

On 2011/11/15 4:33, Ned Freed wrote:

>> > ENCOURAGE the public to register any names that they have seen in
>> > deployed software. (same for URI schemes)
>
>> I think third-party registration is indeed something we should encourage
>> more.
>
> How do you propose we do that?

It seems that currently, people don't even know that it is possible. So 
the first step is to make this more known. On another list, you write: 
"We have always allowed registrations by any interested party." That's 
apparently true, but is it done because nowhere in RFC 4288 it says it's 
not possible? Then making it explicit in draft-freed-media-type-regs 
should help.

For example, you could put in a section 4.12, (Non-)Requirements for 
Contact Information, Author, and Change Controller, saying explicitly 
that third-party registrations are welcome.

This could also explain what in such a case contact information, author, 
and change controller should be. I'd assume that contact information 
goes to the submitter, but change controller stays with the company or 
individual that created the format, but you'll know better what's 
current practice. If I did a third-party registration, this would be the 
place where I'd really not know which way to go.

You can also add pointers to that new section, or just mention the fact, 
in other places where somebody might potentially look. As an example, in 
http://tools.ietf.org/html/draft-freed-media-type-regs-01#section-5.5, 
you could say that in addition to providing comments, new registrations 
and change requests by third parties are also possible.

The next step would then be to put text saying "Media Types may also be 
registered by third parties." or so on the relevant pages at IANA (e.g. 
http://www.iana.org/cgi-bin/mediatypes.pl and 
http://www.iana.org/assignments/media-types/index.html).


Regards,   Martin.

From singer@apple.com  Mon Nov 14 17:59:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E3911E82DA for ; Mon, 14 Nov 2011 17:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level: 
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 XMStI0PSNO+B for ; Mon, 14 Nov 2011 17:59:38 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 27D0011E816C for ; Mon, 14 Nov 2011 17:59:38 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_WjTW5upL3PDd9wc9rQTuzw)"
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LUO009Z8IUACLJ4@mail-out.apple.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 17:59:37 -0800 (PST)
X-AuditID: 11807137-b7c56ae0000051ed-ea-4ec1c7835e0c
Received: from [17.151.71.218] (Unknown_Domain [17.151.71.218]) by relay16.apple.com (Apple SCV relay) with SMTP id 01.16.20973.587C1CE4; Mon, 14 Nov 2011 17:59:36 -0800 (PST)
From: David Singer 
In-reply-to: <4EC1BD19.6050407@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 17:59:30 -0800
Message-id: <8063B542-6DD3-4D0E-8BFB-6443724284F1@apple.com>
References:  <3C5268E5-FE9E-4148-8955-0450304BB407@apple.com> <4EC1BD19.6050407@it.aoyama.ac.jp>
To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
X-Mailer: Apple Mail (2.1251.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42IRnO5+S7fj+EE/g2uXrCxWv1zBZtF+9wq7 xbaDSxgtrj26z2Lx784EZgdWj2k/e5g9dh39we6xZMlPJo+myzOYPJbN3cMSwBrFZZOSmpNZ llqkb5fAlXFlSydbweWLrBUnHk1kb2D8sJu1i5GTQ0LARGLeodNsELaYxIV764FsLg4hgY2M Ei/nfmAESQgLuEgsurSeCcTmFTCWWHPrHQuIzSwQJXHu9hKwGjYBVYkHc46B2ZwC+hJ9G9+D 1bMAxe+dvww2lFlgCaPE7p4nrBCDbCSm7v7MCLFtKaPE1DczwRIiAu4SjT9usUCcJC/R8vUO 2wRGvllIls9CshzC1pZYtvA1M4StJ/Gy6R07hO0pcfhOH9sssOW9QB/1noIqUpSY0v2QHVUz B5CtIzF5IeMCRs5VjIJFqTmJlYZmeokFBTmpesn5uZsYQTHTUGi+g3H7X7lDjAIcjEo8vArh B/2EWBPLiitzDzFKcDArifAGlQGFeFMSK6tSi/Lji0pzUosPMUpzsCiJ85btAkoJpCeWpGan phakFsFkmTg4pRoYdzLNY9c0Fp5z6JXhpmrzs8y95epaNfmrmBdPC+9rKxCtcdmusI53X5bW zlXpVZeFK5/0H5yszuMVljdf7uTe1/1bRbT+rnc81jaJKVpmdueUZQdi3qxQcfh/acPb57Os xL4zrOSX0WDMvPwmuPO0B2/jBd6ZV1IvP/5cfPaeQ+KS5b8XLDjmrsRSnJFoqMVcVJwIAL7l OcSVAgAA
Cc: "gadams@xfsi.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 01:59:39 -0000

--Boundary_(ID_WjTW5upL3PDd9wc9rQTuzw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable


On Nov 14, 2011, at 17:15 , Martin J. D=FCrst wrote:

> On 2011/11/15 3:35, David Singer wrote:
>>=20
>> On Nov 12, 2011, at 12:25 , Larry Masinter wrote:
>>=20
>>> I see no use case for why having font/opentype is any better than =
application/opentype
>>>=20
>>> The only use case I can imagine from looking at
>>> http://tools.ietf.org/html/draft-singer-font-mime-00
>>> is the possibility of defining common parameters across font data =
types (in the same way that text/.. has a common charset parameter).
>>=20
>> How serious is the first concern "First, the  "application" sub-tree =
is treated (correctly) with great caution with respect to viruses and =
other active code."?
>=20
> I very much think that having a  font/ top level type is actually a =
good idea. But I hinted at this before: a type shouldn't be treated as =
"more safe" just because it says font/, rather than application/. Many =
font formats contain active code that is executed by the font engine. =
Several security holes have been found in this area. So I'd actually =
de-emphasize or remove this point. draft-singer-font-mime-00 also =
doesn't have a security section, and it of course needs one.
>=20

It's very old.  I did it in a way I used to do I-Ds -- matching Word =
layout with nroff commands embedded as hidden text, so it could be saved =
as plain text, piped through nroff, and then through that old tool that =
fiddled with nroff output to make an I-D.

Here it is, it's all yours!


--Boundary_(ID_WjTW5upL3PDd9wc9rQTuzw)
Content-type: application/msword; x-mac-type=5738424E; x-mac-creator=4D535744;
 x-unix-mode=0644; name=draft-singer-font-mime-00.doc
Content-transfer-encoding: base64
Content-disposition: attachment; filename=draft-singer-font-mime-00.doc

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAewAAAAAAAAAA
EAAAfQAAAAEAAAD+////AAAAAHoAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAAWAJBAAA8BK/AAAAAAABEQABAAEABgAATkYAAA4AamJqYg79Dv0AAAAAAAAAAAAAAAAAAAAA
AAAJBBYAKHgAAGSfAABknwAAyT8AAAAAAACEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAANADAAAAAAAA0AMAANAD
AAAAAAAA0AMAAAAAAADQAwAAAAAAANADAAAAAAAA0AMAABQAAAAAAAAAAAAAAPAEAAAAAAAAuDcA
AAAAAAC4NwAAAAAAALg3AAA4AAAA8DcAACQAAAAUOAAAfAAAAPAEAAAAAAAASVQAAJ4BAACcOAAA
7gAAAIo5AAAWAAAAoDkAAAAAAACgOQAAAAAAAKA5AAAAAAAAezoAACAAAACbOgAADAAAAKc6AAAI
AAAAwFMAAAIAAADCUwAAAAAAAMJTAAAAAAAAwlMAAAAAAADCUwAAAAAAAMJTAAAAAAAAwlMAACwA
AADnVQAAUgIAADlYAABYAAAA7lMAABUAAAAAAAAAAAAAAAAAAAAAAAAA0AMAAAAAAACvOgAAAAAA
AAAAAAAAAAAAAAAAAAAAAAB7OgAAAAAAAHs6AAAAAAAArzoAAAAAAACvOgAAAAAAAO5TAAAAAAAA
n0YAAAAAAADQAwAAAAAAANADAAAAAAAAoDkAAAAAAAAAAAAAAAAAAKA5AADbAAAAA1QAABYAAACf
RgAAAAAAAJ9GAAAAAAAAn0YAAAAAAACvOgAAHAYAANADAAAAAAAAoDkAAAAAAADQAwAAAAAAAKA5
AAAAAAAAwFMAAAAAAAAAAAAAAAAAAJ9GAAAAAAAA5AMAAKQAAACIBAAAaAAAANADAAAAAAAA0AMA
AAAAAADQAwAAAAAAANADAAAAAAAArzoAAAAAAADAUwAAAAAAAAAAAAAAAAAAn0YAAAAAAACfRgAA
jgAAAAhTAABoAAAA0AMAAAAAAADQAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkFMAAAwAAAAAAAAAAAAAAJA4AAAMAAAAZnOUvQAA
AAAAAAAAAAAAALg3AAAAAAAAy0AAANQFAABwUwAAEAAAAAAAAAAAAAAAnFMAACQAAAAZVAAAMAAA
AElUAAAAAAAAgFMAABAAAACRWAAAAAAAAJ9GAAAAAAAAkVgAACAAAACcUwAAAAAAAJ9GAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAEAAAAAAAA8AQAAAQuAAD0MgAA
xAQAAAAAAAAAAAAAAAAAAAAAAADwBAAAAAAAAPAEAAAAAAAA9DIAAAAAAAAEAAEBDwAEAQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcIiBD
aGFuZ2UgaGlzdG9yeQ1cIiANXCIgMC41CQk0LzcvMDQJCWZpcnN0IGRyYWZ0DVwiIA1cIiBOb3Rl
cw1cIiANXCIgDVwiIDEuIHNhdmUgYXMgdGV4dCB3aXRob3V0IGxpbmUgYnJlYWtzICgTIEZJTEVO
QU1FICBcKiBNRVJHRUZPUk1BVCAUZHJhZnQtc2luZ2VyLWZvbnQtbWltZS0wMC5kb2MVLm5yb2Zm
KQ1cIiANXCIgMi4gbW92ZSB0byBhIHVuaXggYm94IGFuZCBkbywgbnJvZmYgLW1zIBMgRklMRU5B
TUUgIFwqIE1FUkdFRk9STUFUIBRkcmFmdC1zaW5nZXItZm9udC1taW1lLTAwLmRvYxUubnJvZmYg
PiATIEZJTEVOQU1FICBcKiBNRVJHRUZPUk1BVCAUZHJhZnQtc2luZ2VyLWZvbnQtbWltZS0wMC5k
b2MVLnR4dG5wYg1cIiANXCIgMy4gb3BlbiB0aGUgLHR4dG5wYiBmaWxlIHdpdGggdmkuIGRvIDEs
JHMvXF0kL1xdXkwvLiBUaGlzIGFkZHMgdGhlIHBhZ2UgYnJlYWtzIChpLmUuIGZvcm0gZmVlZHMp
LiBUaGVuIGZpeCBzb21lIG9mIHRoZSBwbGFjZXMgd2hlcmUgYSBmb3JtZmVlZCBzaG91bGQgbm90
IGhhdmUgaGFwcGVuZWQgKGxpa2UgaW4gdGhlIHJlZmVyZW5jZSBtYXJrZXJzKS4gU2F2ZSB0aGUg
bmV3IGZpbGUgYXMgEyBGSUxFTkFNRSAgXCogTUVSR0VGT1JNQVQgFGRyYWZ0LXNpbmdlci1mb250
LW1pbWUtMDAuZG9jFS50eHR0bXAuDVwiIA1cIiA0LiBkbyBjYXQgEyBGSUxFTkFNRSAgXCogTUVS
R0VGT1JNQVQgFGRyYWZ0LXNpbmdlci1mb250LW1pbWUtMDAuZG9jFS50eHR0bXAgfCBmaXguc2gg
PiATIEZJTEVOQU1FICBcKiBNRVJHRUZPUk1BVCAUZHJhZnQtc2luZ2VyLWZvbnQtbWltZS0wMC5k
b2MVLnR4dCAobG9vayBhdCBSRkMxNTQzIGZvciBmaXguc2gpIG9yIHVzZSBmaXgucGwgb24gYSBz
dWl0YWJsZSBwbGF0Zm9ybQ1cIiANLnBsIDEwLjBpDS5wbyAwDS5sbCA3LjJpDS5sdCA3LjJpDS5u
ciBMTCA3LjJpDS5uciBMVCA3LjJpDS5kcyBMRiBELiBTaW5nZXIgYW5kIEcuIEFkYW1zDS5kcyBS
RiBbUGFnZSAlXQ0uZHMgQ0YNLmRzIExIIEludGVybmV0IERyYWZ0DS5kcyBSSCATIERPQ1BST1BF
UlRZICJ3cml0ZWRhdGUiIFwqIE1FUkdFRk9STUFUIBRPY3QgMTQgMjAwNBUgIA0uZHMgQ0ggEyBG
SUxFTkFNRSAgXCogTUVSR0VGT1JNQVQgFGRyYWZ0LXNpbmdlci1mb250LW1pbWUtMDAuZG9jFQ0u
aHkgMA0uYWQgbA0uaW4gMA0ubmYNLnRhIDcuMmlSDUludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sg
Rm9yY2UJDUlOVEVSTkVULURSQUZUCUQuIFNpbmdlcg0TIEZJTEVOQU1FICBcKiBNRVJHRUZPUk1B
VCAUZHJhZnQtc2luZ2VyLWZvbnQtbWltZS0wMC5kb2MVCUFwcGxlIENvbXB1dGVyDQ0JRy4gQWRh
bXMNCVhGU0kNDQkTIERPQ1BST1BFUlRZICJ3cml0ZWRhdGUiIFwqIE1FUkdFRk9STUFUIBRPY3Qg
MTQgMjAwNBUNCUV4cGlyZXM6IBMgRE9DUFJPUEVSVFkgImV4cGlyZWRhdGUiIFwqIE1FUkdFRk9S
TUFUIBRBcHIgMTQgMjAwNRUNDS5maQ0uY2UNVGhlIEZvbnQgUHJpbWFyeSBDb250ZW50IFR5cGUg
Zm9yDS5jZQ1NdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbCBFeHRlbnNpb25zDQ0udGkgMA1JUFIg
Tm90aWNlDQ1CeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIEkgY2VydGlmeSB0aGF0
IGFueSBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIEkgYW0g
YXdhcmUgaGF2ZSBiZWVuIGRpc2Nsb3NlZCwgb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkg
b2Ygd2hpY2ggSSBiZWNvbWUgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ug
d2l0aCBSRkMgMzY2OC4NDQ0udGkgMA1TdGF0dXMgb2YgVGhpcyBNZW1vDS5maQ0uaW4gMw0NVGhp
cyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5j
ZSB3aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NDUludGVybmV0
LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n
IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBO
b3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVu
dHMgYXMgSW50ZXJuZXQtRHJhZnRzLg0NSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu
dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwg
cmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IHRpbWUuICBJ
dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIG1h
dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGEgIndvcmsgaW4gcHJvZ3Jlc3MuIg0N
VGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA1o
dHRwOi8vd3d3LmlldGYub3JnLzFpZC1hYnN0cmFjdHMuaHRtbA0NVGhlIGxpc3Qgb2YgSW50ZXJu
ZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA1odHRwOi8vd3d3
LmlldGYub3JnL3NoYWRvdy5odG1sDQ1UaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwg
IlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIs
ICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFy
ZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkuDQ0udGkgMA1EaXN0
cmlidXRpb24gb2YgdGhpcyBkb2N1bWVudCBpcyB1bmxpbWl0ZWQuDQ0udGkgMA1Db3B5cmlnaHQg
Tm90aWNlIA0NQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNCkuICBBbGwg
UmlnaHRzIFJlc2VydmVkLg0NUG9zdFNjcmlwdCwgT3BlblR5cGUsIGFuZCBUcnVlVHlwZSBhcmUg
cmVnaXN0ZXJlZCB0cmFkZW1hcmtzIG9mIEFkb2JlIFN5c3RlbXMuIEluYy4sIE1pY3Jvc29mdCBD
b3JwLiwgYW5kIEFwcGxlIENvbXB1dGVyIEluYy4sIHJlc3BlY3RpdmVseS4NDS50aSAwDUFic3Ry
YWN0IA0NVGhpcyBkb2N1bWVudCBzZXJ2ZXMgdG8gcmVnaXN0ZXIgYW5kIGRvY3VtZW50IHRoZSB0
b3AtbGV2ZWwgTUlNRSB0eXBlIGZvciBmb250cywgdW5kZXIgd2hpY2ggdGhlIHJlcHJlc2VudGF0
aW9uIGZvcm1hdHMgZm9yIGZvbnRzIG1heSBiZSByZWdpc3RlcmVkLiAgSXQgYWxzbyByZWdpc3Rl
cnMgc29tZSBzcGVjaWZpYyBmb250IHR5cGVzIHVuZGVyIHRoYXQgdG9wLWxldmVsIHR5cGUuIA0N
DS50aSAwDTEgSW50cm9kdWN0aW9uDQ1UaGUgcHJvY2VzcyBvZiBzZXR0aW5nIHR5cGUgaW4gY29t
cHV0ZXIgc3lzdGVtcyBhbmQgb3RoZXIgZm9ybXMgb2YgdGV4dCBwcmVzZW50YXRpb24gc3lzdGVt
cyB1c2VzIGZvbnRzIGluIG9yZGVyIHRvIHByb3ZpZGUgdmlzdWFsIHJlcHJlc2VudGF0aW9ucyBv
ZiB0aGUgZ2x5cGhzLiAgSnVzdCBhcyB3aXRoIGltYWdlcywgZm9yIGV4YW1wbGUsIHRoZXJlIGFy
ZSBhIG51bWJlciBvZiB3YXlzIHRvIHJlcHJlc2VudCB0aGUgdmlzdWFsIGluZm9ybWF0aW9uIG9m
IHRoZSBnbHlwaHMuICBFYXJseSBmb3JtYXRzIG9mdGVuIHVzZWQgYml0bWFwcywgYXMgdGhlc2Ug
Y291bGQgYmUgY2FyZWZ1bGx5IHR1bmVkIGZvciBtYXhpbXVtIHJlYWRhYmlsaXR5IGF0IGEgZ2l2
ZW4gc2l6ZSwgYW5kIHRoZSBkaXNwbGF5cyB3ZXJlIG9mdGVuIDEtYml0IGRlZXAgb25seS4gIE1v
cmUgcmVjZW50bHksIG91dGxpbmUgZm9udHMgaGF2ZSBjb21lIGludG8gdXNlOiAgaW4gdGhlc2Ug
Zm9udHMsIHRoZSBvdXRsaW5lcyBvZiB0aGUgZ2x5cGhzIGFyZSBkZXNjcmliZWQsIGFuZCB0aGUg
cHJlc2VudGF0aW9uIHN5c3RlbSByZW5kZXJzIHRoZSBvdXRsaW5lIGluIHRoZSBkZXNpcmVkIHBv
c2l0aW9uIGFuZCBzaXplLg0NVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgdG9wLWxldmVsIE1JTUUg
dHlwZSCTZm9udJQgdW5kZXIgd2hpY2ggZGlmZmVyaW5nIHJlcHJlc2VudGF0aW9uIGZvcm1hdHMg
b2YgZm9udHMgbWF5IGJlIHJlZ2lzdGVyZWQgKGUuZy4gYSBiaXRtYXAgb3Igb3V0bGluZSBmb3Jt
YXQpLiAgSXQgc2hvdWxkIGJlIGVtcGhhc2l6ZWQgdGhhdCwganVzdCBhcyB1bmRlciB0aGUgk2lt
YWdllCB0b3AtbGV2ZWwgdHlwZSBvbmUgZG9lcyBub3QgZmluZCByZWdpc3RyYXRpb24gZm9yLCBm
b3IgZXhhbXBsZSwgk1RoZSBOaWdodC13YXRjaJQgKGJ5IFJlbWJyYW5kdCkgYnV0IGluc3RlYWQg
k0pQRUeUIChhbiBpbWFnZSByZXByZXNlbnRhdGlvbiBzeXN0ZW0pLCBzbywgdW5kZXIgk2ZvbnSU
IG9uZSB3aWxsIG5vdCBmaW5kIJNDb3VyaWVylCAodGhlIG5hbWUgb2YgYSBwb3B1bGFyIGZvbnQp
IGJ1dCBwZXJoYXBzIJNCREaUICh0aGUgbmFtZSBvZiBhIGNvbW1vbmx5IHVzZWQgYml0bWFwIGZv
bnQgZm9ybWF0KS4NDUhpc3RvcmljYWxseSB0aGVyZSBoYXMgbm90IGJlZW4gYSByZWdpc3RyYXRp
b24gb2YgZm9ybWF0cyBmb3IgZm9udHMuICBDdXJyZW50bHkgdGhlcmUgaXMgb25seSBvbmUgZm9u
dCByZXByZXNlbnRhdGlvbiBmb3JtYXQgcmVnaXN0ZXJlZCBpbiBNSU1FLCBhbmQgdGhhdCBpcyB1
bmRlciB0aGUgk2FwcGxpY2F0aW9ulCB0b3AtbGV2ZWwgdHlwZS4gIEhvd2V2ZXIsIHRoZSB1c2Ug
b2YgdGhpcyB0b3AtbGV2ZWwgdHlwZSBpcyBub3QgaWRlYWwuICBGaXJzdCwgdGhlIJNhcHBsaWNh
dGlvbpQgc3ViLXRyZWUgaXMgdHJlYXRlZCAoY29ycmVjdGx5KSB3aXRoIGdyZWF0IGNhdXRpb24g
d2l0aCByZXNwZWN0IHRvIHZpcnVzZXMgYW5kIG90aGVyIGFjdGl2ZSBjb2RlLiAgU2Vjb25kbHks
IHRoZSBsYWNrIG9mIGEgdG9wLWxldmVsIHR5cGUgbWVhbnMgdGhhdCB0aGVyZSBpcyBubyBvcHBv
cnR1bml0eSB0byBoYXZlIGEgY29tbW9uIHNldCBvZiBvcHRpb25hbCBhdHRyaWJ1dGVzLCBzdWNo
IGFzIGFyZSBzcGVjaWZpZWQgaGVyZS4gIFRoaXJkLCBmb250cyBoYXZlIGEgdW5pcXVlIHNldCBv
ZiBsaWNlbnNpbmcgYW5kIHVzYWdlIHJlc3RyaWN0aW9ucywgd2hpY2ggbWFrZXMgaXQgd29ydGh3
aGlsZSB0byBpZGVudGlmeSB0aGlzIGdlbmVyYWwgY2F0ZWdvcnkgd2l0aCBhIHVuaXF1ZSB0b3At
bGV2ZWwgdHlwZS4NDS50aSAwDQ0udGkgMA0yIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQ1Gb250
cyBhcmUgaW50ZXJwcmV0ZWQgZGF0YSBzdHJ1Y3R1cmVzLg0NRm9udHMgbWF5IGNvbnRhaW4gkWhp
bnRzkiBmb3IgdGhlIGFsaWdubWVudCBvZiB2aXN1YWwgYXNwZWN0cyBvZiB0aGUgZ2x5cGhzIHdp
dGggdGhlIGRpc3BsYXksIGFuZCB0aGVzZSBoaW50cyBtYXkgYXBwZWFyIHRvIGJlIGFjdGl2ZSBj
b2RlLiAgSG93ZXZlciwgdGhleSBvcGVyYXRlIHdpdGhpbiB0aGUgY29uZmluZXMgb2YgdGhlIGds
eXBoIG91dGxpbmUgY29udmVyc2lvbiBzeXN0ZW0gYW5kIGhhdmUgbm8gYWNjZXNzIG91dHNpZGUg
dGhlIGZvbnQgcmVuZGVyaW5nIG1hY2hpbmVyeS4NDUZvbnRzIGNhbiBiZSwgaG93ZXZlciwgcXVp
dGUgY29tcGxleCwgYW5kIGEgbWFsaWNpb3VzbHkgZGVzaWduZWQgY29tcGxleCBmb250IGNvdWxk
IGNhdXNlIHVuZHVlIHJlc291cmNlIGNvbnN1bXB0aW9uIChlLmcuIG1lbW9yeSBvciBDUFUgY3lj
bGVzKSBvbiBhIG1hY2hpbmUgaW50ZXJwcmV0aW5nIGl0LiAgVGhpcyBpcyB0aGUgY2FzZSBmb3Ig
bWFueSBmb3JtYXRzIGhvd2V2ZXIuICBJbmRlZWQsIGZvbnRzIGFyZSBzdWZmaWNpZW50bHkgY29t
cGxleCB0aGF0IG1vc3QgaWYgbm90IGFsbCBpbnRlcnByZXRlcnMgY2Fubm90IGJlIGNvbXBsZXRl
bHkgcHJvdGVjdGVkIGZyb20gbWFsaWNpb3VzIGZvbnRzIHdpdGhvdXQgdW5kdWUgcGVyZm9ybWFu
Y2UgcGVuYWx0aWVzLiAgDQ1Gb250cyBhcmUgb2Z0ZW4gbGljZW5zZWQgYW5kIHRoYXQgbGljZW5z
ZSBtYXkgcGxhY2UgcmVzdHJpY3Rpb25zIG9uIHRoZSB0cmFuc21pc3Npb24gb2YgYWxsIG9yIHBh
cnQgb2YgdGhlIGZvbnQuICBJdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmlj
YXRpb24gdG8gbWFuZGF0ZSBhbnkgcGFydGljdWxhciBiZWhhdmlvciwgYnV0IHRoZSBhdXRob3Jz
IG9mIE1JTUUgcmVnaXN0cmF0aW9ucyB1bmRlciB0aGUgkWZvbnSSIHRvcC1sZXZlbCB0eXBlIFNI
T1VMRCBhdCB0aGUgdmVyeSBsZWFzdCBhbHNvIG1lbnRpb24gdGhlIGxpY2Vuc2luZyBjb25zaWRl
cmF0aW9ucyBmb3IgdGhlIHRyYW5zbWlzc2lvbiBvZiBmb250cy4NDS50aSAwDTMgRGVmaW5pdGlv
bg0NLnRpIDANMy4xIEVuY29kaW5nDQ1VbnJlY29nbml6ZWQgc3ViLXR5cGVzIG9mIJNmb250lCBz
aG91bGQgYmUgdHJlYXRlZCBhcyCTYXBwbGljYXRpb24vb2N0ZXQtc3RyZWFtlC4gICBJbXBsZW1l
bnRhdGlvbnMgbWF5IHBhc3MgdW5yZWNvZ25pemVkIHN1Yi10eXBlcyB0byBhIGNvbW1vbiBmb250
LWhhbmRsaW5nIHN5c3RlbSwgaWYgYW55Lg0NRGlmZmVyZW50IHN1YnR5cGVzIG9mIGZvbnQgbWF5
IGJlIGVuY29kZWQgYXMgdGV4dHVhbCByZXByZXNlbnRhdGlvbnMgb3IgYXMgYmluYXJ5IGRhdGEu
IFVubGVzcyBub3RlZCBpbiB0aGUgc3VidHlwZSByZWdpc3RyYXRpb24sIHN1YnR5cGVzIG9mIGZv
bnQgc2hvdWxkIGJlIGFzc3VtZWQgdG8gY29udGFpbiBiaW5hcnkgZGF0YSwgaW1wbHlpbmcgYSBj
b250ZW50IGVuY29kaW5nIG9mIGJhc2U2NCBmb3IgZW1haWwgYW5kIGJpbmFyeSB0cmFuc2ZlciBm
b3IgZnRwIGFuZCBodHRwLg0NLnRpIDANMy4xIENvbW1vbiBQYXJhbWV0ZXJzDQ1UaGUgZm9sbG93
aW5nIHR3byBwYXJhbWV0ZXJzIG1heSBiZSBzdXBwbGllZCBmb3IgYW55IHJlZ2lzdHJhdGlvbiB1
bmRlciB0aGUgk2ZvbnSUIHRvcC1sZXZlbCB0eXBlIHVubGVzcyBzcGVjaWZpY2FsbHkgZGlzYWxs
b3dlZCBieSB0aGUgcmVnaXN0cmF0aW9uIG9mIHRoYXQgZm9ybWF0LiANDUl0IG1pZ2h0IGJlIHRo
b3VnaHQgZGVzaXJhYmxlIHRvIGhhdmUgYSBzdWItcGFyYW1ldGVyIGZvciB0aGUgZ2x5cGggY292
ZXJhZ2Ugb2YgYSBmb250LCBidXQgdGhlcmUgaXMgbm8ga25vd24gbWV0aG9kIHRoYXQgZ2l2ZXMg
YW4gYWRlcXVhdGUgc3VtbWFyeSBvZiB0aGUgY292ZXJhZ2UgaW4gYW4gZXhhY3QgZW5vdWdoIGZv
cm0gdG8gYmUgdXNlZnVsLiAgVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90LCB0aGVyZWZvcmUs
IGRlZmluZSBhbnkgc3VjaCBwYXJhbWV0ZXIuICBIb3dldmVyLCB0aGUgYXV0aG9ycyBhcmUgaW52
ZXN0aWdhdGluZyB3aGV0aGVyIHRoZSBVbmljb2RlIHNldHMgYXMgZGVmaW5lZCBhdCA8IGh0dHA6
Ly93d3cudW5pY29kZS5vcmcvcmVwb3J0cy90cjM1LyNVbmljb2RlX1NldHM+IGNvdWxkIG1lZXQg
dGhpcyBuZWVkLg0NVGhlc2UgcGFyYW1ldGVycyBhcmUgaW5mb3JtYXRpdmUgYW5kIHR5cGljYWxs
eSBkdXBsaWNhdGUgaW5mb3JtYXRpb24gZm91bmQgaW4gdGhlIGZvbnQgaXRzZWxmLiAgRm9yIGlu
dGVycHJldGluZyB0aGUgZm9udCBmaWxlLCB0aGUgaW5mb3JtYXRpb24gd2l0aGluIHRoZSBmaWxl
IGlzIGRlZmluaXRpdmUgYW5kIG92ZXItcmlkZXMgYW55IG9mIHRoZXNlIHBhcmFtZXRlcnMuICBU
aGVzZSBwYXJhbWV0ZXJzIGNhbiBiZSB1c2VkIHRvIGRldGVybWluZSB3aGV0aGVyIGEgZm9udCBj
YW4gb3Igc2hvdWxkIGJlIG9wZW5lZCwgZm9yIGV4YW1wbGUuICBUaGUgcGFyYW1ldGVycyBTSE9V
TEQgY29ycmVzcG9uZCB0byB3aGF0IGlzIGluIHRoZSBmaWxlLg0NZm9udC1uYW1lPZNzdHJpbmeU
DQ1UaGlzIGlzIHRoZSByZWZlcmVuY2UgbmFtZSBmb3IgdGhlIGZvbnQ7ICBhIG5vbi1sb2NhbGl6
ZWQgbmFtZSB0aGF0IGlzIHVzZWQgdG8gcmVmZXIgdG8gaXQuICBJbiBtYW55IGZvbnRzIChldmVu
IHRob3NlIG5vdCB1c2luZyBQb3N0U2NyaXB0KSwgdGhpcyBpcyB0aGUgY2FsbGVkIJN0aGUgcG9z
dHNjcmlwdCBuYW1llC4gKGUuZy4gk0NvdXJpZXKUKS4NDWZvbnQtc2l6ZT2TaW50ZWdlcpQNDUlm
IGEgZm9udCBpcyBkZXNpZ25lZCBmb3IgdXNlIGF0IGEgcGFydGljdWxhciBzaXplIChlLmcuIGEg
Yml0bWFwIGZvbnQpLCB0aGVuIHRoaXMgcGFyYW1ldGVyIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhl
IGludGVuZGVkIGRpc3BsYXkgc2l6ZS4gIFRoZSB2YWx1ZSBvZiB0aGUgcGFyYW1ldGVyIGlzIHRo
ZSBub21pbmFsIJFkZXNpZ24gc2l6ZZIgb2YgdGhlIGZvbnQsIGluIHBpeGVscyAoZS5nLiBhIGZv
bnQgZGVzaWduZWQgZm9yIGEgbm9taW5hbCBkaXNwbGF5IHNpemUgb2YgMTAgcG9pbnRzIG9uIGEg
ZGlzcGxheSB3aXRoIDEgcGl4ZWwgcGVyIHBvaW50IHdvdWxkIHJlcG9ydCB0aGUgdmFsdWUgkzEw
lCBoZXJlKS4gIFRoaXMgcGFyYW1ldGVyIGlzIG5vcm1hbGx5IG9ubHkgdXNlZCBmb3IgZm9udHMg
c3VjaCBhcyBhIHNpbmdsZS1zaXplIGJpdG1hcCBmb250LCBkZXNpZ25lZCBmb3IgdXNlIGF0IG9u
ZSBzaXplIG9ubHkuDQ1zdWJmb3JtYXQ9k3N0cmluZ5QNDUZvciBmb250IGNvbnRhaW5lcnMgdGhh
dCBhbGxvdyBtdWx0aXBsZSByZXByZXNlbnRhdGlvbnMsIGFuZCB0aGVyZWZvcmUgY291bGQgcmVx
dWlyZSBkaWZmZXJlbnQgZm9udCBtYWNoaW5lcnksIHRoaXMgaWRlbnRpZmllcyB0aGUgZm9ybWF0
IG5lZWRlZCwgZnJvbSBhbiBlbnVtZXJhdGVkIHNldCBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNh
dGlvbiBvciBzcGVjaWZpY2F0aW9ucyBvZiBzcGVjaWZpYyBmb3JtYXRzIHVuZGVyIHRoZSCTZm9u
dC+UIG5vZGUuICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyCTdHJ1ZXR5cGWUIGFuZCCTcG9z
dHNjcmlwdJQgYXMgcG9zc2libGUgdmFsdWVzIGZvciB0aGlzIHBhcmFtZXRlci4NDXVuaWNvZGU9
k2Jvb2xlYW6UDQ1UaGUgdmFsdWUgb2YgdGhpcyBwYXJhbWV0ZXIgaW5kaWNhdGVzIHdoZXRoZXIg
dGhlIGZvbnQgc3VwcG9ydHMgYSBtYXBwaW5nIGZyb20gVW5pY29kZSBzY2FsYXIgdmFsdWVzICBv
ciBVbmljb2RlIGVuY29kaW5nIGZvcm0gdG8gc3BlY2lmaWMgZ2x5cGgocyk7ICBpdCB0YWtlcyB0
aGUgdmFsdWUgk3RydWWUIG9yIJNmYWxzZZQuDQ0NLnRpIDANNCBEZWZpbmVkIGFuZCBFeHBlY3Rl
ZCBTdWItdHlwZXMNDUluIHRoaXMgc2VjdGlvbiB0aGUgaW5pdGlhbCBlbnRyaWVzIHVuZGVyIHRo
ZSB0b3AtbGV2ZWwgkWZvbnSSIE1JTUUgdHlwZSBhcmUgZG9jdW1lbnRlZC4gIFRoZXkgYWxzbyBz
ZXJ2ZSBhcyBleGFtcGxlcyBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnMuDQ1Ob3RlIHRoYXQgTWFj
aW50b3NoIG9wZXJhdGluZyBzeXN0ZW1zIGFyZSBub3QgcGFydGljdWxhciBhYm91dCB0aGUgZmls
ZS10eXBlIGNvZGUgdXNlZCBmb3IgZm9udHMsIGFuZCB0aGF0IGl0IGlzIGNvcnJlY3QgdGhhdCB0
aGUgdHdvIG92ZXJsYXBwaW5nIGZvcm1hdHMgcmVnaXN0ZXJlZCBoZXJlIHVzZSB0aGUgc2FtZSBm
aWxlIHR5cGUuDQ0udGkgMA00LjEgT3BlblR5cGUNDVRoZSBmb250L29wZW50eXBlIGNvbnRlbnQt
dHlwZSByZWZlcnMgZm9udHMgdGhhdCBjb25mb3JtIHRvIHRoZSBPcGVuVHlwZSBzcGVjaWZpY2F0
aW9uLiAgT3BlblR5cGUgZm9udHMgYXJlIGEgc3BlY2lhbCBjYXNlIG9mIFNGTlQgZm9udHMsIHdo
aWNoIGhhdmUgYSBzZXBhcmF0ZSBNSU1FIHR5cGUuICBUaGUgc3BlY2lmaWMgT3BlblR5cGUgTUlN
RSB0eXBlIGlzIHByZWZlcnJlZCB3aGVuIHRoZSBmYWN0IHRoYXQgaXQgaXMgYW4gT3BlblR5cGUg
Zm9udCBpcyBzYWxpZW50IHRvIHRoZSBhcHBsaWNhdGlvbiBvciB1c2FnZSwgYW5kIHdoZW4gdGhl
IG9yaWdpbmF0aW5nIHN5c3RlbSBjYW4gcmVhc29uYWJseSBkZXRlcm1pbmUgdGhhdCBhIGZvbnQg
aXMgYSB2YWxpZCBPcGVuVHlwZSBmb250Lg0NLmJyDVRvOiBpZXRmLXR5cGVzQGlhbmEub3JnDS5i
cg1TdWJqZWN0OiBSZWdpc3RyYXRpb24gb2YgU3RhbmRhcmQgTUlNRSBtZWRpYSB0eXBlIGZvbnQv
b3BlbnR5cGUNDS50YSAzLjVpIDRpDS5pbiAzLjVpDS50aSAwDU1JTUUgbWVkaWEgdHlwZSBuYW1l
Oglmb250DS5icg0udGkgMA1NSU1FIHN1YnR5cGUgbmFtZToJb3BlbnR5cGUNLmJyDS50aSAwDVJl
cXVpcmVkIHBhcmFtZXRlcnM6CW5vbmUNLmJyDS50aSAwDU9wdGlvbmFsIHBhcmFtZXRlcnM6CWFu
eSBvZiB0aGUgY29tbW9uIHBhcmFtZXRlcnMgZm9yIJFmb250kiBtYXkgYmUgdXNlZCwgYXMgZG9j
dW1lbnRlZCBpbiBSRkMgWFhYWA0uYnINLnRpIDANRW5jb2RpbmcgY29uc2lkZXJhdGlvbnM6CWZp
bGVzIGFyZSBiaW5hcnkgYW5kIHNob3VsZCBiZSB0cmFuc21pdHRlZCBpbiBhIHN1aXRhYmxlIGVu
Y29kaW5nIHdpdGhvdXQgQ1IvTEYgY29udmVyc2lvbiwgNy1iaXQgc3RyaXBwaW5nIGV0Yy47IGJh
c2U2NCBpcyBhIHN1aXRhYmxlIGVuY29kaW5nOw0uYnINLnRpIDANU2VjdXJpdHkgY29uc2lkZXJh
dGlvbnM6CXNlZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpbiBSRkMgWFhY
WA0uYnINLnRpIDANSW50ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0aW9uczoJT3BlblR5cGUgZm9u
dHMgc2hvdWxkIIUNLmJyDS50aSAwDVB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9uOiAJDS5icg0udGkg
MQ1odHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vdHlwb2dyYXBoeS9vdHNwZWMvZGVmYXVsdC5odG0N
LmJyDS50aSAwDUFwcGxpY2F0aW9ucyB3aGljaCB1c2UgdGhpcyBtZWRpYSB0eXBlOglNZXNzYWdp
bmcgYW5kIG11bHRpLW1lZGlhDS5icg0udGkgMA1BZGRpdGlvbmFsIGluZm9ybWF0aW9uOg0uYnIN
LnRpIDANTWFnaWMgbnVtYmVyKHMpOglubyB0cnVlIG1hZ2ljIG51bWJlciwgYnV0IGN1cnJlbnRs
eSBmaWxlcyBzdGFydCB3aXRoIGEgMzItYml0IGZpZWxkLCB3aGljaCBjb250YWlucyBlaXRoZXIg
MHgwMDAxMDAwMCBvciCRT1RUT5INLmJyDS50aSAwDUZpbGUgZXh0ZW5zaW9uKHMpOgmTb3RmlCBp
cyB0aGUgY29tbW9uIGV4dGVuc2lvbiB1c2VkOyCTdHRmlCBtYXkgYmUgdXNlZCBmb3IgT3BlblR5
cGUgZm9udHMgY29udGFpbmluZyBUcnVlVHlwZSBvdXRsaW5lcywgk3R0Y5QgaXMgdXNlZCBmb3Ig
VHJ1ZVR5cGUgQ29sbGVjdGlvbnMgZm9udHMNLmJyDS50aSAwDU1hY2ludG9zaCBGaWxlIFR5cGUg
Q29kZShzKToJc2ZudCBtYXkgYmUgdXNlZCBidXQgaXMgbm90IHJlcXVpcmVkDS5icg0udGkgMA1Q
ZXJzb24gJiBlbWFpbCBhZGRyZXNzIHRvIGNvbnRhY3QgZm9yIGZ1cnRoZXIgaW5mb3JtYXRpb246
IA0uYnINPz8/OiA/Pz9APz8/LmNvbQ0udGkgMA1JbnRlbmRlZCB1c2FnZToJQ09NTU9ODS50aSAw
DUNoYW5nZSBjb250cm9sbGVyOgk/Pz86ID8/P0A/Pz8uY29tDQ0uZmkNLmluIDMNDS50aSAwDTQu
MiBTZm50DQ1UaGUgZm9udC9zZm50IGNvbnRlbnQtdHlwZSByZWZlcnMgZm9udHMgdGhhdCBhcmUg
Y29udGFpbmVkIHdpdGhpbiBhbiCRc2ZudJIgKHNjYWxhYmxlIGZvbnQpIGNvbnRhaW5lciwgYnV0
IHRoYXQgYXJlIG5vdCBuZWNlc3NhcmlseSBPcGVuVHlwZS4gIChPcGVuVHlwZSBmb250cyBhbHNv
IHVzZSB0aGlzIGNvbnRhaW5lciBmb3JtYXQsIGJ1dCB0aGVyZSBpcyBhIHN1YnN0YW50aWFsIGJv
ZHkgb2YgZm9udHMgdXNpbmcgdGhlIGNvbnRhaW5lciBmb3JtYXQgdGhhdCBhcmUgbm90IE9wZW5U
eXBlIGZvbnRzKS4gDQ0uYnINVG86IGlldGYtdHlwZXNAaWFuYS5vcmcNLmJyDVN1YmplY3Q6IFJl
Z2lzdHJhdGlvbiBvZiBTdGFuZGFyZCBNSU1FIG1lZGlhIHR5cGUgZm9udC9zZm50DQ0udGEgMy41
aSA0aQ0uaW4gMy41aQ0udGkgMA1NSU1FIG1lZGlhIHR5cGUgbmFtZToJZm9udA0uYnINLnRpIDAN
TUlNRSBzdWJ0eXBlIG5hbWU6CXNmbnQNLmJyDS50aSAwDVJlcXVpcmVkIHBhcmFtZXRlcnM6CW5v
bmUNLmJyDS50aSAwDU9wdGlvbmFsIHBhcmFtZXRlcnM6CWFueSBvZiB0aGUgY29tbW9uIHBhcmFt
ZXRlcnMgZm9yIJFmb250kiBtYXkgYmUgdXNlZCwgYXMgZG9jdW1lbnRlZCBpbiBSRkMgWFhYWA0u
YnINLnRpIDANRW5jb2RpbmcgY29uc2lkZXJhdGlvbnM6CWZpbGVzIGFyZSBiaW5hcnkgYW5kIHNo
b3VsZCBiZSB0cmFuc21pdHRlZCBpbiBhIHN1aXRhYmxlIGVuY29kaW5nIHdpdGhvdXQgQ1IvTEYg
Y29udmVyc2lvbiwgNy1iaXQgc3RyaXBwaW5nIGV0Yy47IGJhc2U2NCBpcyBhIHN1aXRhYmxlIGVu
Y29kaW5nOw0uYnINLnRpIDANU2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6CXNlZSB0aGUgc2VjdXJp
dHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpbiBSRkMgWFhYWA0uYnINLnRpIDANSW50ZXJvcGVy
YWJpbGl0eSBjb25zaWRlcmF0aW9uczoJU2ZudCBmb250cyBtYXkgY29udGFpbiBhIHZhcmlldHkg
b2YgdGFibGVzLCBzb21lIG9yIGFsbCBvZiB3aGljaCBtYXkgYmUgdmVuZG9yLXNwZWNpZmljIG9y
IG90aGVyd2lzZSBub24tc3RhbmRhcmQuICBUaGUgU0ZOVCBzdHJ1Y3R1cmUgZG9lcyBub3QgcmVx
dWlyZSBhbnkgc3BlY2lmaWMgc2V0IG9mIHRhYmxlcywgdGhvdWdoIHRoZXJlIGFyZSB0YWJsZXMg
aW4gY29tbW9uIHVzZS4gIEludGVyb3BlcmFiaWxpdHkgaXMgbm90IGFzc3VyZWQuDS5icg0udGkg
MA1QdWJsaXNoZWQgc3BlY2lmaWNhdGlvbjogCQ0uYnINLnRpIDENaHR0cDovL2RldmVsb3Blci5h
cHBsZS5jb20vZm9udHMvVFRSZWZNYW4vDS5icg0udGkgMA1BcHBsaWNhdGlvbnMgd2hpY2ggdXNl
IHRoaXMgbWVkaWEgdHlwZToJTWVzc2FnaW5nIGFuZCBtdWx0aS1tZWRpYQ0uYnINLnRpIDANQWRk
aXRpb25hbCBpbmZvcm1hdGlvbjoNLmJyDS50aSAwDU1hZ2ljIG51bWJlcihzKToJbm8gdHJ1ZSBt
YWdpYyBudW1iZXIsIGJ1dCBjdXJyZW50bHkgZmlsZXMgc3RhcnQgd2l0aCBhIDMyLWJpdCBmaWVs
ZCwgd2hpY2ggY29udGFpbnMgZWl0aGVyIDB4MDAwMTAwMDAsIG9yIJFPVFRPkiwgb3IgkXRydWWS
IG9yIJF0eXAxkg0uYnINLnRpIDANRmlsZSBleHRlbnNpb24ocyk6CZN0dGaUIGlzIGEgY29tbW9u
IGV4dGVuc2lvbiB1c2VkLCBmb3Igc2ZudC1ob3VzZWQgVHJ1ZVR5cGUgZm9udHMNLmJyDS50aSAw
DU1hY2ludG9zaCBGaWxlIFR5cGUgQ29kZShzKToJc2ZudCBtYXkgYmUgdXNlZCBidXQgaXMgbm90
IHJlcXVpcmVkDS5icg0udGkgMA1QZXJzb24gJiBlbWFpbCBhZGRyZXNzIHRvIGNvbnRhY3QgZm9y
IGZ1cnRoZXIgaW5mb3JtYXRpb246IA0uYnINPz8/OiA/Pz9APz8/LmNvbQ0udGkgMA1JbnRlbmRl
ZCB1c2FnZToJQ09NTU9ODS50aSAwDUNoYW5nZSBjb250cm9sbGVyOgk/Pz86ID8/P0A/Pz8uY29t
DQ0uZmkNLmluIDMNDQ0udGkgMA01IElBTkEgQ29uc2lkZXJhdGlvbnMNDVRoaXMgZG9jdW1lbnQg
cmVnaXN0ZXJzIHRoZSB0b3AtbGV2ZWwgTUlNRSB0eXBlIJNmb250lCwgYW5kIHRoZSCTb3BlbnR5
cGWUIGZvbnQgdHlwZSB1bmRlciCTZm9udJQuDQ0udGkgMA02IFJGQyBFZGl0b3IgQ29uc2lkZXJh
dGlvbnMNDVRoZSByZWZlcmVuY2VzIHRvIFJGQyBYWFhYIGluIHRoZSBNSU1FIHJlZ2lzdHJhdGlv
bnMgbmVlZCB0byBiZSByZXBsYWNlZCB3aXRoIHRoZSBhY3R1YWwgUkZDIG51bWJlciB3aGVuIGl0
IGlzIGlzc3VlZC4NDS50aSAwDTcgRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQ1Db3B5cmlnaHQg
KEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVj
dCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBC
Q1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFp
biBhbGwgdGhlaXIgcmlnaHRzLg0NVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNv
bnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBD
T05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUyBPUiBJUyBTUE9O
U09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQg
RU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBP
UiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFU
IFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkg
UklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJ
VE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0NLnRpIDANOCBJbnRlbGxlY3R1YWwgUHJv
cGVydHkgTm90aWNlDQ1UaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZh
bGlkaXR5IG9yIHNjb3BlIG9mIGFueSBpbnRlbGxlY3R1YWwgcHJvcGVydHkgb3Igb3RoZXIgcmln
aHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0byBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlv
biBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgb3Ig
dGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyBtaWdodCBv
ciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBuZWl0aGVyIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQg
aXQgaGFzIG1hZGUgYW55IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZv
cm1hdGlvbiBvbiB0aGUgSUVURidzIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBp
biBzdGFuZGFyZHMtdHJhY2sgYW5kIHN0YW5kYXJkcy1yZWxhdGVkIGRvY3VtZW50YXRpb24gY2Fu
IGJlIGZvdW5kIGluIEJDUC0xMS4gIENvcGllcyBvZiBjbGFpbXMgb2YgcmlnaHRzIG1hZGUgYXZh
aWxhYmxlIGZvciBwdWJsaWNhdGlvbiBhbmQgYW55IGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8g
YmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlIHRvIG9i
dGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mIHN1Y2gg
cHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzIHNwZWNp
ZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgU2VjcmV0YXJpYXQuDQ1UaGUg
SUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRp
b24gYW55IGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3Ro
ZXIgcHJvcHJpZXRhcnkgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5
IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0
aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgRXhlY3V0aXZlIERpcmVjdG9yLg0NDS50aSAwDUFj
a25vd2xlZGdtZW50cw0NVGhlIGluaXRpYWwgcmV2aWV3IGJ5IHRoZSBXM0MgVGltZWQgVGV4dCBn
cm91cCwgYW5kIHR5cGUgZXhwZXJ0cywgaXMgZ3JhdGVmdWxseSBhY2tub3dsZWRnZWQuDQ0uYnAN
LnRpIDANDA0NLnRpIDANQXV0aG9ycycgQ29udGFjdCBJbmZvcm1hdGlvbg0ubmYNRGF2aWQgU2lu
Z2VyDUFwcGxlIENvbXB1dGVyLCBJbmMuDU9uZSBJbmZpbml0ZSBMb29wLCBNUzozMDItM01UDUN1
cGVydGlubyAgQ0EgOTUwMTQNVVNBDUVtYWlsOiBzaW5nZXJAYXBwbGUuY29tDVRlbDogKzEgNDA4
IDk3NCAzMTYyDQ0NR2xlbm4gQWRhbXMNRXh0ZW5zaWJsZSBGb3JtYXR0aW5nIFN5c3RlbXMsIElu
Yy4gKFhGU0kpDTExNCBNb3VudCBBdWJ1cm4gU3QsIDR0aCBGbG9vcg1DYW1icmlkZ2UsIE1BIDAy
MTM4DVVTQQ1UZWw6ICsxIDYxNyA4NjQtMDAwNQ1GYXg6ICsxIDYxNyA4NjQtMDAwNg1FbWFpbDog
Z2FkYW1zQHhmc2kuY29tDQ0udGkgMA02LiBSZWZlcmVuY2VzDS5maQ0uYnINW0lTTy1KUEVHMjAw
MC0xXQ0uYnINSVRVLVQgUmVjb21tZW5kYXRpb24gVC44MDAgfCBJU08vSUVDIDE1NDQ0LTEuIElu
dGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJKUEVHIDIwMDAg
SW1hZ2UgQ29kaW5nIFN5c3RlbTogQ29yZSBDb2RpbmcgU3lzdGVtIi4NDS5icg1bTUlNRTFdIEZy
ZWVkLCBOLiBhbmQgTi4gQm9yZW5zdGVpbiwgIk11bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsIA0u
YnINRXh0ZW5zaW9ucyAoTUlNRSkgUGFydCBPbmU6IEZvcm1hdCBvZiBJbnRlcm5ldCBNZXNzYWdl
IEJvZGllcyIsIFJGQyAyMDQ1LCBOb3ZlbWJlciAxOTk2Lg0NLnRpIDANRGF0ZXMNLm5mDS50YSAz
LjZpQw0JV3JpdHRlbjogEyBET0NQUk9QRVJUWSAid3JpdGVkYXRlIiBcKiBNRVJHRUZPUk1BVCAU
T2N0IDE0IDIwMDQVDQlFeHBpcmVzOiATIERPQ1BST1BFUlRZICJleHBpcmVkYXRlIiBcKiBNRVJH
RUZPUk1BVCAUQXByIDE0IDIwMDUVDQ1cIkludGVybmV0IERyYWZ0CRMgRklMRU5BTUUgIFwqIE1F
UkdFRk9STUFUIBRkcmFmdC1zaW5nZXItZm9udC1taW1lLmRvYxUJSnVseSA0LCAyMDAxDQ1cIkQg
U2luZ2VyCQlbUGFnZSAAXQ0NXCJEIFNpbmdlcgkJW1BhZ2UgAF0NDQ0NAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAGAABvBgAAcAYAAIoGAACLBgAAqAYAAKkGAADgBgAA4QYAAPsGAAD8
BgAAGQcAABoHAAAjBwAAJAcAAD4HAAA/BwAAXAcAAF0HAABKCAAASwgAAGUIAABmCAAAgwgAAIQI
AACeCAAAnwgAALkIAAC6CAAA1wgAANgIAADrCAAA7AgAAAYJAAAHCQAAJAkAACUJAAD8CQAA/QkA
ACUKAAAmCgAAMQoAADIKAAA0CgAAPAoAAD0KAABXCgAAWAoAAHUKAAB2CgAAlwoAANEKAADSCgAA
7AoAAO0KAAAKCwAACwsAAC4LAAAvCwAAVwsAAFgLAABjCwAAZAsAAG8LAABwCwAAmQsAAJoLAACl
CwAApgsAAKgLAACvCwAA0gsAANULAAD9CwAAAgwAAPwMAAABDQAAFg0AACANAADjEAAA+vD68OXw
+vD68OXw+vD68OXw+vD68OXw+vD68OXw+vD68OXw+t3Z3dHd2frw+vDl8PrZ8Prw5fDZ3dnd2d3Z
3dnd2d3ZyNnI2frZ+tn62QARFmi7EJgAPAiBQ0oSAEVIBgAPFWi7EJgAFmi7EJgANQiBBhZouxCY
AAAPA2oAAAAAFmi7EJgAVQgBFBZouxCYADwIgW1IAARuSAAEdQgBABIDagAAAAAWaLsQmAA8CIFV
CAEACRZouxCYADwIgQBPAAYAABIGAAAWBgAAMgYAADYGAAA/BgAAQwYAAEcGAACxBgAAtQYAAGUH
AABpBwAAjQgAAJEIAABsCQAAcAkAAHoJAACACQAAiQkAAJIJAACeCQAAqgkAAMgJAADYCQAA3wkA
APUJAAA1CgAAdwoAAH0KAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
9gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAADcYI
AALgEMAhAQIAAQAAABwABgAAyUUAAE1GAAD+/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAgEBAn0KAACDCgAAiQoAAI0KAACXCgAAuAoAANEKAAAbCwAAHAsAACYLAAAsCwAA
LQsAAGULAACnCwAAqAsAAKwLAACwCwAA0gsAANYLAAD8CwAA/QsAAAMMAAAODAAADwwAAPoMAAD7
DAAA/AwAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAO8AAAAAAAAAAAAA
AADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAA
AAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAAAAQAAGdkuxCYAAAEAAADJAFhJAEABQAADcYFAAHAIQIACAAAAyQDDcYFAAHAIQJhJAMABAAA
AyQDYSQDAAEAAAAa/AwAAAINAAAWDQAAGg0AACANAAAhDQAAjQ0AAI4NAABYDgAAWQ4AAF0PAABe
DwAAlg8AAL0PAAC+DwAA/w8AAB8QAAAgEAAA4hAAAOMQAADpEAAAFREAABYRAAAcEQAALhEAAC8R
AABwEQAAcREAAP4RAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA9gAAAAAAAAAA
AAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2
AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQPAGdkuxCY
AAABDwAAAQAAABzjEAAA6BAAABYRAAAbEQAALxEAAP4RAAD/EQAABBIAAO8SAAD0EgAA9RIAAAMT
AAAbGgAAIBoAACIaAAAnGgAAcR4AAHYeAAB3HgAAhR4AAIoeAACLHgAAmB4AAFwgAABhIAAAYiAA
AHggAAB+IgAAsCIAAMciAADIIgAAUCkAAFUpAABWKQAAeCkAAMsqAADMKgAA0SoAANIqAADfKgAA
aywAAG8sAACHLAAAiywAAMwsAADnLAAAAi0AAAwtAAAoLQAAMi0AAEwtAABWLQAAui0AAMQtAABu
LgAAeC4AAMUuAADPLgAACC8AABIvAAAtLwAANy8AAG4vAAB4LwAAui8AAMQvAADcLwAA5i8AAGcw
AABxMAAAGDEAACIxAABkMQAAbjEAAKoxAACuMQAAvzEAAMUxAADcMQAA4jEAAAYyAAAHMgAAETIA
ABIyAAAXMgAAGDIAACEyAABFMwAASTMAAPr2+vbs9vr2+vbn9vr2+vb69uf69uf2+vbn9uD24Pb6
9uf25/r25/b69vr2+vb69vr2+vb69vr2+vb69vr2+vb69vr2+vb69vr2+vb69vr25/r2+vbn9voA
AAAADBVoKWXMABZouxCYAAAJFmi7EJgAPioBExZouxCYAEIqAUNKFgBwaAAAAAAGFmi7EJgAAAkW
aLsQmAA8CIEAWP4RAAD/EQAABRIAAA8SAAAQEgAA7RIAAO4SAADvEgAA9RIAAAQTAAAFEwAAchUA
AHMVAABuFwAAbxcAABoaAAAbGgAAIRoAACIaAAAoGgAAQhoAAEMaAABqGgAAaxoAAIIbAACDGwAA
Ax0AAAQdAABwHgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAAABEAAA
AQ8AAAEAAAAccB4AAHEeAAB3HgAAhB4AAIUeAACLHgAAmB4AAJkeAABHHwAASB8AAFsgAABcIAAA
YiAAAHggAAB5IAAAHyEAACAhAADIIgAAySIAADkkAAA6JAAATSQAAE4kAAAYJQAAGSUAAC0lAAAu
JQAABScAAAYnAAAZJwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAA
AAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAAAAAAAAAAB
EAAAAQAAAB0ZJwAAGicAAH4oAAB/KAAAkSgAAJIoAABOKQAATykAAFApAABWKQAAdykAAHgpAAAI
KgAACSoAAMsqAADMKgAA0ioAAN8qAADgKgAAaiwAAGssAABvLAAAhywAAIssAADLLAAAzCwAANgs
AADhLAAA5ywAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADzAAAAAAAA
AAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAAAAAAAAAAAARYAAAUQAA+EAABehAAAAAEA
AAABEAAAHOcsAAACLQAABi0AAAwtAAAoLQAALC0AADItAABMLQAAUC0AAFYtAAC6LQAAvi0AAMQt
AABuLgAAci4AAHguAADFLgAAyS4AAM8uAAAILwAADC8AABIvAAAtLwAA8AAAAAAAAAAAAAAAAOEA
AAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAA
AAAAAAAA8AAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAA
AOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAA
AAAAAAAAAAAA8AAAAAAAAAAAAAAAANAAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAAvwAAAAAAAAAA
AAAAANAAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAAvwAAAAAAAAAAAAAAAAAAAAAREAANxggAAhAO
4BAAAA+EEA4RhMD0E6TwAF6EEA5ghMD0ERYADcYIAAIQDuAQAAAPhBAOEYTA9BOk8ABehBAOYITA
9A8WAA3GCAACEA7gEAAAD4QQDhGEwPRehBAOYITA9A8QAA3GCAACEA7gEAAAD4QQDhGEwPRehBAO
YITA9AAWLS8AADEvAAA3LwAAbi8AAHIvAAB4LwAAui8AAL4vAADELwAA3C8AAOAvAADmLwAAZzAA
AGswAABxMAAAGDEAABwxAAAiMQAAZDEAAGgxAABuMQAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAA
AADdAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAzgAA
AAAAAAAAAAAAAM4AAAAAAAAAAAAAAAC/AAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAM4AAAAAAAAA
AAAAAAC/AAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAA
zgAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAAAC/AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAA
AAAAAAAAAAAAABIQAA3GCAACEA7gEAAAD4QQDhGEwPRehBAOYITA9GdkuxCYAA8QAA3GCAACEA7g
EAAAD4QQDhGEwPRehBAOYITA9A8WAA3GCAACEA7gEAAAD4QQDhGEwPRehBAOYITA9BEQAA3GCAAC
EA7gEAAAD4QQDhGEwPQTpPAAXoQQDmCEwPQRFgANxggAAhAO4BAAAA+EEA4RhMD0E6TwAF6EEA5g
hMD0ABRuMQAAqjEAAK4xAAC/MQAAxTEAANwxAADiMQAABjIAAAcyAAALMgAAETIAABIyAAAYMgAA
ITIAACIyAABEMwAARTMAAEkzAABhMwAAZTMAAKEzAADuAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAA
ANgAAAAAAAAAAAAAAADHAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAMcAAAAAAAAAAAAAAAC4AAAA
AAAAAAAAAAAAtgAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtgAAAAAAAAAA
AAAAALYAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACs
AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAsgAAAAAA
AAAAAAAAAAAFEAAPhAAAXoQAAAABEAAAARYAAAEAAA8QAA3GCAACEA7gEAAAD4QQDhGEwPRehBAO
YITA9BEWAA3GCAACEA7gEAAAD4QQDhGEwPQTpPAAXoQQDmCEwPQLEAANxggAAhAO4BAAAA+EEA5e
hBAOCxYADcYIAAIQDuAQAAAPhBAOXoQQDhEQAA3GCAACEA7gEAAAD4QQDhGEwPQTpPAAXoQQDmCE
wPQAFEkzAABhMwAAZTMAAKIzAAC9MwAA2DMAAOIzAAD6MwAABDQAAB40AAAoNAAAjDQAAJY0AABA
NQAASjUAAJc1AAChNQAAvzYAAMk2AADkNgAA7jYAABk3AAAjNwAAZTcAAG83AACHNwAAkTcAACg4
AAAyOAAAhjgAAJA4AADSOAAA3DgAABg5AAAcOQAALTkAADM5AABKOQAAUDkAAHQ5AAB1OQAAfzkA
AIE5AACGOQAAhzkAAJ45AAABOgAAAjoAAAc6AAAIOgAAJToAAJw6AACdOgAAojoAAF09AABiPQAA
4EEAAOFBAADmQQAA50EAAPdBAABXQgAAYEIAAGFCAABiQgAAZEIAAGlCAABqQgAAh0IAAIpCAADC
QwAAx0MAANZDAADZQwAA2kMAAN1DAADvQwAA8kMAAIdEAACKRAAAzUQAANBEAAArRQAAMEUAADFF
AAA3RQAAREUAAEVFAABPRQAAUEUAAHhFAAB5RQAAhEUAAPz3/Pf89/z3/Pf89/z3/Pf89/z3/Pf8
9/z3/Pf89/z3/Pf89/z3/PL3/Pf88vzy9/zy/PL3/Pf88vf88vz3/PL89/zy9/z3/Pf89/z3/Pf8
9/z3/PL38vzq/Or8AAAAAA8DagAAAAAWaLsQmABVCAEJFmi7EJgAPioBCRZouxCYADwIgQYWaLsQ
mABcoTMAAKIzAACuMwAAtzMAAL0zAADYMwAA3DMAAOIzAAD6MwAA/jMAAAQ0AAAeNAAAIjQAACg0
AACMNAAAkDQAAJY0AABANQAARDUAAEo1AACXNQAAmzUAAKE1AAD9AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA
AADdAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA7AAA
AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAN0AAAAAAAAA
AAAAAADdAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA
7AAAAAAAAAAAAAAAAMwAAAAAAAAAAAAAAADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAERYADcYIAAIQDuAQAAAPhBAOEYTA9BOk8ABehBAOYITA9A8WAA3GCAACEA7g
EAAAD4QQDhGEwPRehBAOYITA9A8QAA3GCAACEA7gEAAAD4QQDhGEwPRehBAOYITA9AABFgAAARAA
ABahNQAAvzYAAMM2AADJNgAA5DYAAOg2AADuNgAAGTcAAB03AAAjNwAAZTcAAGk3AABvNwAAhzcA
AIs3AACRNwAAKDgAACw4AAAyOAAAhjgAAIo4AACQOAAA0jgAAO4AAAAAAAAAAAAAAADdAAAAAAAA
AAAAAAAA3QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA
AO4AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADOAAAA
AAAAAAAAAAAAzgAAAAAAAAAAAAAAAL8AAAAAAAAAAAAAAADOAAAAAAAAAAAAAAAAzgAAAAAAAAAA
AAAAAL8AAAAAAAAAAAAAAADOAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAL8AAAAAAAAAAAAAAADO
AAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAL8AAAAAAAAAAAAAAAAAAAAADxAADcYIAAIQDuAQAAAP
hBAOEYTA9F6EEA5ghMD0DxYADcYIAAIQDuAQAAAPhBAOEYTA9F6EEA5ghMD0ERYADcYIAAIQDuAQ
AAAPhBAOEYTA9BOk8ABehBAOYITA9BEQAA3GCAACEA7gEAAAD4QQDhGEwPQTpPAAXoQQDmCEwPQA
FtI4AADWOAAA3DgAABg5AAAcOQAALTkAADM5AABKOQAAUDkAAHQ5AAB1OQAAeTkAAH85AACAOQAA
gTkAAIc5AACdOQAAnjkAAAE6AAACOgAACDoAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA3QAA
AAAAAAAAAAAAANIAAAAAAAAAAAAAAADHAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAN0AAAAAAAAA
AAAAAADuAAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALYAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAA
tAAAAAAAAAAAAAAAALYAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAtgAAAAAAAAAAAAAAALYAAAAA
AAAAAAAAAAC2AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALYAAAAAAAAAAAAAAAC2AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAEQAAABFgAAAQAADxAADcYIAAIQDuAQAAAPhBAOEYTA9F6EEA5ghMD0
CxAADcYIAAIQDuAQAAAPhBAOXoQQDgsWAA3GCAACEA7gEAAAD4QQDl6EEA4REAANxggAAhAO4BAA
AA+EEA4RhMD0E6TwAF6EEA5ghMD0ERYADcYIAAIQDuAQAAAPhBAOEYTA9BOk8ABehBAOYITA9AAU
CDoAACQ6AAAlOgAAnDoAAJ06AACjOgAAvjoAAL86AACIOwAAiTsAAFw9AABdPQAAYz0AAII9AACD
PQAAx0AAAMhAAADfQQAA4EEAAOFBAADnQQAA90EAAPhBAABWQgAAV0IAAFtCAABhQgAAY0IAAGRC
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA
AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPIA
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAABEwAABBAAZ2S7EJgAAAEBAAABEAAAAQAAABxk
QgAAakIAAIdCAACLQgAAmEIAAK1CAADLQgAA30IAAONCAAD7QgAAEEMAABFDAAASQwAAHkMAAElD
AABoQwAAfEMAAIBDAACVQwAAqkMAAMFDAADCQwAAyEMAANZDAADaQwAA3kMAAO9DAADzQwAAhkQA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAA
AAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2
AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAA
AAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBAAZ2S7EJgAAAEQAAABAAAAHIZE
AACHRAAAi0QAAM1EAADRRAAAKkUAACtFAAAxRQAAN0UAADtFAABFRQAAhkUAAMhFAADJRQAAH0YA
ACBGAAA1RgAANkYAAEtGAABMRgAATUYAAE5GAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA
AN0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADUAAAA
AAAAAAAAAAAA1wAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADFQAxJAADAAAxJAADFAAxJAAACAAADcYFAAFAFIFnZLsQ
mAAACwAAAyQDDcYFAAHAIQJhJANnZLsQmAAABAAAAyQDYSQDAAUAAA3GBQABwCECAAEAAAAVhEUA
AIVFAACQRQAAkUUAALpFAAC7RQAAxkUAAMdFAADJRQAAy0UAANpFAADbRQAA9UUAAPZFAAAQRgAA
EUYAACBGAAAiRgAAMkYAADNGAAA2RgAAOEYAAEhGAABJRgAATkYAAPfz9/P38/fz7vPk7uTu5PPu
89zz7vPc8wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPA2oAABgAFmi7EJgAVQgBEgNq
AAAAABZouxCYADwIgVUIAQAJFmi7EJgAPAiBBhZouxCYAAAPA2oAAAAAFmi7EJgAVQgBABgmAAow
ARQwKhxQAQAfsNAvILDgPSGwCAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAGQAS
AAEApQAPAAIAAwAAAAMAAAA4AABA8f8CADgADAAAAAAAAAAAAAYATgBvAHIAbQBhAGwAAAACAAAA
EABDShgAbUgJBHNICQR0SAkEOAABQAEAAgA4AAwAAAAAAAAAAAAJAEgAZQBhAGQAaQBuAGcAIAAx
AAAACAABAAYkAUAmAAMAPioBAAAAAAAAAAAAAAAAAAAAAABEAEFA8v+hAEQADAAAAAAAAAAAABYA
RABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAWgBpQPP/swBa
AAwBAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAIAA6VgsAF/YDAAA01gYAAQoD
bAA01gYAAQUDAABh9gMAAAIACwAEAF9IAAQoAGsA9P/BACgAAAEAAAAAAAAAAAcATgBvACAATABp
AHMAdAAAAAIADAAAAAAAQAD+TwEA8gBAAAwAAAAAAAAAAAAIAGEAYgBzAHQAcgBhAGMAdAAAABIA
DwAOhNACD4TQAl2E0AJehNACBABDShQAOAD+TwEAAgE4AAwAAAAAAAAAAAAEAGIAbwBkAHkAAAAS
ABAADoRoAQ+EaAFdhGgBXoRoAQQAQ0oUADgA/k8BARIBOAAMAAAAAAAAAAAABgBiAHUAbABsAGUA
dAAAABIAEQAPhBwCEYRM/16EHAJghEz/AABAAP5PAQEiAUAADAAAAAAAAAAAAA4AcABhAGMAawBl
AHQAIABmAG8AcgBtAGEAdABzAAAAAgASAAgAT0oEAFFKBABCAP5PAQAyAUIADAAAAAAAAAAAAAkA
cgBlAGYAZQByAGUAbgBjAGUAAAASABMAD4RoARGEmP5ehGgBYISY/gQAQ0oUADgAH0ABAEIBOAAM
AAAAAAAAAAAABgBIAGUAYQBkAGUAcgAAAA0AFAANxggAAuAQwCEBAgAEAENKFAA4ACBAAQBSATgA
DAAAAAAAAAAAAAYARgBvAG8AdABlAHIAAAANABUADcYIAALgEMAhAQIABABDShQAPABaQAEAYgE8
AAwAAAAAAAAAAAAKAFAAbABhAGkAbgAgAFQAZQB4AHQAAAACABYADABDShQAT0oFAFFKBQAwAFVA
ogBxATAADAAAAAAAAAAAAAkASAB5AHAAZQByAGwAaQBuAGsAAAAGAD4qAUIqAkQA/k8BAIIBRAAM
AAAAAAAAAAAABgBmAGkAZQBsAGQAcwAAABoAGAANxgUAAUofAA+E0AIRhJj+XoTQAmCEmP4EAENK
FAAAAAAATkAAAAYAAHgAAAUA/////woAAAAEIAAA//8BAKB6mQAAAAAAACAAAP//AgCgepkAAAAA
AAQgAAD//wMAoHqZAAAAAAAAIAAA//8EAKB6mQAAAAAABCAAAP//BQCgepkAAAAAAAAgAAD//wYA
oHqZAAAAAAAEIAAA//8HAKB6mQAAAAAAACAAAP//CACgepkAAAAAAAQgAAD//wkAoHqZAAAAAAAA
IAAA//8KAKB6mQAAAAAAAAAAAKgFAAD/CwAA0BcAAJEiAADPKAAAISwAAB0xAAC/NAAAYjwAAE5A
AAAAAAQAAAABAAYAAAACAKAAAAADAAEAAAAEADkAAAAFAAEAAAAGAAYAAAAHAMkAAAAIAAEAAAAJ
AAAAAAAAAAAAEgAAABYAAAAyAAAANgAAAD8AAABDAAAARwAAALEAAAC1AAAAZQEAAGkBAACNAgAA
kQIAAGwDAABwAwAAegMAAIADAACJAwAAkgMAAJ4DAACqAwAAyAMAANgDAADfAwAA9QMAADUEAAB3
BAAAfQQAAIMEAACJBAAAjQQAAJcEAAC4BAAA0QQAABsFAAAcBQAAJgUAACwFAAAtBQAAZQUAAKcF
AACoBQAArAUAALAFAADSBQAA1gUAAPwFAAD9BQAAAwYAAA4GAAAPBgAA+gYAAPsGAAD8BgAAAgcA
ABYHAAAaBwAAIAcAACEHAACNBwAAjgcAAFgIAABZCAAAXQkAAF4JAACWCQAAvQkAAL4JAAD/CQAA
HwoAACAKAADiCgAA4woAAOkKAAAVCwAAFgsAABwLAAAuCwAALwsAAHALAABxCwAA/gsAAP8LAAAF
DAAADwwAABAMAADtDAAA7gwAAO8MAAD1DAAABA0AAAUNAAByDwAAcw8AAG4RAABvEQAAGhQAABsU
AAAhFAAAIhQAACgUAABCFAAAQxQAAGoUAABrFAAAghUAAIMVAAADFwAABBcAAHAYAABxGAAAdxgA
AIQYAACFGAAAixgAAJgYAACZGAAARxkAAEgZAABbGgAAXBoAAGIaAAB4GgAAeRoAAB8bAAAgGwAA
yBwAAMkcAAA5HgAAOh4AAE0eAABOHgAAGB8AABkfAAAtHwAALh8AAAUhAAAGIQAAGSEAABohAAB+
IgAAfyIAAJEiAACSIgAATiMAAE8jAABQIwAAViMAAHcjAAB4IwAACCQAAAkkAADLJAAAzCQAANIk
AADfJAAA4CQAAGomAABrJgAAbyYAAIcmAACLJgAAyyYAAMwmAADYJgAA4SYAAOcmAAACJwAABicA
AAwnAAAoJwAALCcAADInAABMJwAAUCcAAFYnAAC6JwAAvicAAMQnAABuKAAAcigAAHgoAADFKAAA
ySgAAM8oAAAIKQAADCkAABIpAAAtKQAAMSkAADcpAABuKQAAcikAAHgpAAC6KQAAvikAAMQpAADc
KQAA4CkAAOYpAABnKgAAayoAAHEqAAAYKwAAHCsAACIrAABkKwAAaCsAAG4rAACqKwAArisAAL8r
AADFKwAA3CsAAOIrAAAGLAAABywAAAssAAARLAAAEiwAABgsAAAhLAAAIiwAAEQtAABFLQAASS0A
AGEtAABlLQAAoS0AAKItAACuLQAAty0AAL0tAADYLQAA3C0AAOItAAD6LQAA/i0AAAQuAAAeLgAA
Ii4AACguAACMLgAAkC4AAJYuAABALwAARC8AAEovAACXLwAAmy8AAKEvAAC/MAAAwzAAAMkwAADk
MAAA6DAAAO4wAAAZMQAAHTEAACMxAABlMQAAaTEAAG8xAACHMQAAizEAAJExAAAoMgAALDIAADIy
AACGMgAAijIAAJAyAADSMgAA1jIAANwyAAAYMwAAHDMAAC0zAAAzMwAASjMAAFAzAAB0MwAAdTMA
AHkzAAB/MwAAgDMAAIEzAACHMwAAnTMAAJ4zAAABNAAAAjQAAAg0AAAkNAAAJTQAAJw0AACdNAAA
ozQAAL40AAC/NAAAiDUAAIk1AABcNwAAXTcAAGM3AACCNwAAgzcAAMc6AADIOgAA3zsAAOA7AADh
OwAA5zsAAPc7AAD4OwAAVjwAAFc8AABbPAAAYTwAAGM8AABkPAAAajwAAIc8AACLPAAAmDwAAK08
AADLPAAA3zwAAOM8AAD7PAAAED0AABE9AAASPQAAHj0AAEk9AABoPQAAfD0AAIA9AACVPQAAqj0A
AME9AADCPQAAyD0AANY9AADaPQAA3j0AAO89AADzPQAAhj4AAIc+AACLPgAAzT4AANE+AAAqPwAA
Kz8AADE/AAA3PwAAOz8AAEU/AACGPwAAyD8AAMk/AAAfQAAAIEAAADVAAAA2QAAAS0AAAE9AAACY
AAAAADAAAAAAAAAAgAAAAIAAAABwAACgy4EAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgA
AAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAA
AAAwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAA
ADAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAA
MAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAAAAw
AAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAADAA
AAAAAAAAgAAAAIAAAABwAACgywEAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAAMAAA
AAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAAAAwAAAA
AAAAAIAAAACAAAAAcAAAoMsBAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAADAAAAAA
AAAAgAAAAIAAAABwAACgywEAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAAMAAAAAAA
AACAAAAAgAAAAHAAAKDLAQCYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAAAAwAAAAAAAA
AIAAAACAAAAAcAAAoMsBAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAADAAAAAAAAAA
gAAAAIAAAABwAACgywEAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAAMAAAAAAAAACA
AAAAgAAAAHAAAKDLAQCYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAAAAwAAAAAAAAAIAA
AACAAAAAcAAAoMsBAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAADAAAAAAAAAAgAAA
AIAAAABwAACgywEAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAAMAAAAAAAAACAAAAA
gAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAA
AABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAA
cAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABw
AACgywEAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAA
AKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAA
oMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACg
ywAAmEAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJhAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDL
AACYQAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmEAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsA
AJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCY
AAAAADAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgA
AAAPMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAADzAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAA
AA8wAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAA
DzAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAA8wAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAP
MAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAADzAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAA8w
AAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAADzAA
AAAAAAAAgAAAAIAAAABwAACgywAAmAAAAA8wAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAPMAAA
AAAAAACAAAAAgAAAAHAAAKDLAACYAAAADzAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAA
AAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAA
AAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAA
AACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAA
gAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAA
AACAAAAAcAAAoMsAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAADzAAAAAAAAAAgAAA
AIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAA
gAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAA
AABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAA
AHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAA
cAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABw
AACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAAgAAAABMAAAAAAAAACAAAAAgAAAAHAA
AKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAA
oMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACg
ywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDL
AACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsA
AJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACY
AAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgA
AAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAA
ABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAA
EDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAA
MAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAw
AAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAA
AAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAA
AAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAA
AAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAA
AAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAA
AACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAA
AIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAA
gAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACA
AAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAA
AACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAA
AIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAA
gAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAA
AABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAA
AHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAA
cAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABw
AACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAA
AKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAA
oMsAAJgAAAAWMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACg
ywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAWMAAAAAAAAACAAAAAgAAAAHAAAKDL
AQCYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsB
AJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEA
mAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACY
AAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgA
AAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAA
ABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAA
FjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQ
MAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYw
AAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAA
AAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAA
AAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAA
AAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAA
AAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAA
AACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAA
AIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAA
gAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACA
AAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAA
AACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAA
AIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAA
gAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACA
AAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAA
AABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAA
AHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABAwAAAAAAAAAIAAAACAAAAA
cAAAoMsAAJgAAAAWMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAEDAAAAAAAAAAgAAAAIAAAABw
AACgywAAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAA
AKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAA
oMsBAJgAAAAWMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAADAAAAAAAAAAgAAAAIAAAABwAACg
ywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDL
AACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsA
AJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEA
mAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAWMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCY
AAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgA
AAAWMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAA
ABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAA
FjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQ
MAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYw
AAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAA
AAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAA
AAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAA
AAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAA
AAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAA
AACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAA
AIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAA
gAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACA
AAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAA
AACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAA
AIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAA
gAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACA
AAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAA
AABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAA
AHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAA
cAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABw
AACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAA
AKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAA
oMsBAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAFjAAAAAAAAAAgAAAAIAAAABwAACg
ywEAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAWMAAAAAAAAACAAAAAgAAAAHAAAKDL
AQCYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsB
AJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAA
mAAAABYwAAAAAAAAAIAAAACAAAAAcAAAoMsBAJgAAAAWMAAAAAAAAACAAAAAgAAAAHAAAKDLAQCY
AAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAA
AAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAA
ADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAA
MAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAw
AAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAA
AAAAAAAAgAAAAIAAAABwAACgywAACAAAAAEwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAA
AAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAA
AAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAA
AAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAAgAAAABMAAAAAAA
AACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAA
AIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAA
gAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAA
AACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAA
AIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAA
gAAAAHAAAKDLAQCYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABMwAAAAAAAAAIAAAACA
AAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAA
AABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAA
cAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABw
AACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAA
AKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAA
oMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACg
ywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDL
AACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsA
AJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAEDAAAAAAAAAAgAAAAIAAAABwAACgywAA
mAAAABAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAQMAAAAAAAAACAAAAAgAAAAHAAAKDLAACY
AAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAA
AAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAA
ADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAA
MAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAA
AAAAAAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAAAAAAgAAAAIAAAABwAACgywEAmAAAAAAwAAAA
AAAAAIAAAACAAAAAcAAAoMsAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHAAAKDLAACYAAAAADAAAAAA
AAAAgAAAAIAAAABwAACgywAAmAAAAAAwAAAAAAAAAIAAAACAAAAAcAAAoMsAAJgAAAAUMAAAAAAA
AACAAAAAgAAAAHAAAHDLAAAIAFQAADAAAAAAAABWAAAABgAAAAcA/78BAMoHmAAAABUwAAAAAAAA
AIAAAACAAAAAcAAAcMsAAAgAUAEHMwAAVHIAAAAAAAAGAAAABwD/vwEAygeYAAAAFTAAAAAAAAAA
gAAAAIAAAABwAABwy4AAmgAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAQAABwAAAACoBQAArAUAALAF
AADSBQAA1gUAAPwFAAD9BQAAAwYAAA4GAAAPBgAA+wYAAPwGAAACBwAAFgcAABoHAAAgBwAAIQcA
AI0HAACOBwAAHwoAAOIKAADjCgAA6QoAABULAAAWCwAAHAsAAC4LAAAvCwAAcAsAAHELAAD+CwAA
/wsAADEpAAA3KQAA6DAAAO4wAAAePQAAT0AAAAoAexAAMAAAfBAAAAAAAAAGAAAABwD/vwEAtwcI
AHsQADAAAHwQAAAAAAAABgAAAAAA/78BAIEBCAB7EAAwAAB8EAAAAAAAAAYAAAAAAP+/AQCAAQgA
exAAMAAAfBAAAAAAAAAGAAAAAAD/vwEAgAEIAHsQADAAAHwQAAAAAAAABgAAAAAA/78BAIABCAB7
EAAwAAB8EAAAAAAAAAYAAAAAAP+/AQCAAQpAexAAMAAAfBAAAAAAAAAGAAAAAAD/vwEAgAEKQHsQ
ADAAAHwQAAAAAAAABgAAAAAA/78BAIAHCEB7EAAwAAB8EAAAAAAAAAYAAAAAAP+/AQCAAQhAexAA
MAAAfBAAAAAAAAAGAAAAAAD/vwEAgAEKQAAAADAAAAAAAAAAAAAAAAAAAAAA/78BAIAHCgB7EAAw
AAB8EAAAAAAAAAYAAAAAAP+/AQCAAQgAexAAMAAAfBAAAAAAAAAGAAAAAAD/vwEAgAEIAHsQADAA
AHwQAAAAAAAABgAAAAAA/78BAIABCAB7EAAwAAB8EAAAAAAAAAYAAAAAAP+/AQCBAQgAexAAMAAA
fBAAAAAAAAAGAAAAAAD/vwEAgQEIAHsQADAAAHwQAAAAAAAABgAAAAAA/78BAIABCAB7EAAwAAB8
EAAAAAAAAAYAAAAAAP+/AQCAAQgAexAAMAAAfBAAAAAAAAAGAAAAAAD/vwEAgAEKAHsQADAAAHwQ
AAAAAAAABgAAAAAA/78BAIAHCgB7EAAwAAB8EAAAAAAAAAYAAAAAAP+/AQCABwgAexAAMAAAfBAA
AAAAAAAGAAAAAAD/vwEAgAEIAHsQADAAAHwQAAAAAAAABgAAAAAA/78BAIABCAB7EAAwAAB8EAAA
AAAAAAYAAAAAAP+/AQCAAQgAexAAMAAAfBAAAAAAAAAGAAAAAAD/vwEAgAEIAHsQADAAAHwQAAAA
AAAABgAAAAAA/78BAIABCAB7EAAwAAB8EAAAAAAAAAYAAAAAAP+/AQCAAQgAexAAMAAAfBAAAAAA
AAAGAAAAAAD/vwEAgAEKAHsQADAAAHwQAAAAAAAABgAAAAAA/78BAIAHCAB7EAAwAAB8EAAAAAAA
AAYAAAAAAP+/AQCAAQgAexAAMAAAfBAAAAAAAAAGAAAAAAD/vwEAgAEIAAAAADAAAAAAAAB7CgAA
BAAAAAcA/78BAOcH////////AAD//wAAAAAAAAQAAAAHAP+/AQDnBwoAAAAAMAAAAAAAAAAAAAAA
AAAAAAAAAAAAzgf/v+DVBTMAAABwAAB3JAAABAAAAAcA/78BAOcHCgAAAAAwAAAAAAAAAAAAAAAA
AAAAAAAAAADOB5pAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgAAAAID/
v9QPWjiwsQAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABXAAAAVwAAAG0AAABtAAAA
gwAAAIYAAAAABgAA4xAAAEkzAACERQAATkYAACgAAAAtAAAANAAAADsAAAAABgAAfQoAAPwMAAD+
EQAAcB4AABknAADnLAAALS8AAG4xAAChMwAAoTUAANI4AAAIOgAAZEIAAIZEAABORgAAKQAAACsA
AAAsAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAAAYA
AE1GAAAqAAAAbwAAAIoAAACoAAAA4AAAAPsAAAAZAQAAIwEAAD4BAABcAQAASgIAAGUCAACDAgAA
ngIAALkCAADXAgAA6wIAAAYDAAAkAwAA/AMAACUEAAAxBAAAPAQAAFcEAAB1BAAA0QQAAOwEAAAK
BQAALgUAAFcFAABjBQAAbwUAAJkFAAClBQAATz8AAHg/AACEPwAAkD8AALo/AADGPwAATkAAABMd
FP+VgBMdFP+VgBMdFP+VgBMdFP+VgBMdFP+VgBMdFP+VgBNVFP+VgBMdFP+VgBMdFP+VgBNVFP+V
gBNVFP+VgBNVFP+VgBNVFP+VhBEAAAAsAAAARwAAAIYAAAATHdT/lYAPAADwOAAAAAAABvAYAAAA
AggAAAIAAAABAAAAAQAAAAEAAAACAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvCSAAAA
EAAI8AgAAAABAAAAAQQAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC
AArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAA
AAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAD//wEAAAAMAF8AVABvAGMANAA0ADYAOAA1
ADIANgA1AF03AABPQAAAAAAAAIE3AABPQAAAAAAAAMkDAADLAwAANgQAADgEAACpBQAAqwUAAK0F
AACvBQAA0wUAANUFAAD+BQAAAAYAAP0GAAD/BgAAwAgAAMkIAAB9CwAAhQsAAAAMAAACDAAAchgA
AHQYAACGGAAAiBgAAF0aAABfGgAABiEAAA8hAAA8IgAARCIAAH8iAACGIgAAiCIAAI8iAABRIwAA
UyMAAM0kAADPJAAA1iQAAN4kAADpJAAA8SQAACAlAAAoJQAAOSUAAEElAACZJQAAoSUAANUlAADd
JQAAWyYAAGMmAABsJgAAbiYAAIgmAACKJgAAwiYAAMomAADNJgAAzyYAAOImAADkJgAAAycAAAUn
AAAHJwAACScAAB8nAAAnJwAAKScAACsnAAAtJwAALycAAE0nAABPJwAAUScAAFMnAAC7JwAAvScA
AL8nAADBJwAAbygAAHEoAABzKAAAdSgAAMYoAADIKAAAyigAAMwoAADwKAAA+CgAAAkpAAALKQAA
DSkAAA8pAAAuKQAAMCkAADIpAAA0KQAAbykAAHEpAABzKQAAdSkAALspAAC9KQAAvykAAMEpAADd
KQAA3ykAAOEpAADjKQAAaCoAAGoqAABsKgAAbioAAIUqAACIKgAAqSoAAKwqAAC+KgAAxioAAOwq
AADvKgAAGSsAABsrAAAdKwAAHysAAD8rAABDKwAAZSsAAGcrAABpKwAAaysAAKsrAACtKwAAwCsA
AMIrAADdKwAA3ysAAAgsAAAKLAAAEywAABUsAAAcLAAAICwAACssAAAvLAAAaCwAAGwsAACmLAAA
riwAALIsAAC6LAAAMi0AADotAABGLQAASC0AAGItAABkLQAAnC0AAKAtAACjLQAApS0AALgtAAC6
LQAA2S0AANstAADdLQAA3y0AAPUtAAD5LQAA+y0AAP0tAAD/LQAAAS4AAB8uAAAhLgAAIy4AACUu
AACNLgAAjy4AAJEuAACTLgAAQS8AAEMvAABFLwAARy8AAJgvAACaLwAAnC8AAJ4vAADCLwAAxi8A
AMAwAADCMAAAxDAAAMYwAADlMAAA5zAAAOkwAADrMAAAGjEAABwxAAAeMQAAIDEAAGYxAABoMQAA
ajEAAGwxAACIMQAAijEAAIwxAACOMQAAKTIAACsyAAAtMgAALzIAAEYyAABJMgAAazIAAG8yAACH
MgAAiTIAAIsyAACNMgAArTIAALEyAADTMgAA1TIAANcyAADZMgAAGTMAABszAAAuMwAAMDMAAEsz
AABNMwAAdjMAAHgzAACCMwAAhDMAAN8zAADnMwAAAzQAAAU0AABeNwAAYDcAABM5AAAZOQAAwz0A
AMU9AACkPgAArj4AACw/AAAuPwAAOD8AADo/AAA8PwAAPj8AAMk/AABPQAAABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAHAAAAAACq
AwAArQMAAMgDAADLAwAA9QMAAPgDAAALBQAAGgUAAP0FAAAABgAALwsAAFkLAADACwAA/QsAAP8L
AAACDAAAJhMAAGoTAAAiFAAAJRQAAHkYAACDGAAAhRgAAIgYAABcGgAAXxoAADoeAAA+HgAAdR4A
AHkeAAAHHwAACB8AABkfAAAdHwAABiEAAA8hAAB/IgAAhiIAAPAiAAD6IgAAUCMAAFMjAADMJAAA
zyQAAGsmAABuJgAAhyYAAIomAADMJgAAzyYAANgmAADbJgAA4SYAAOQmAAACJwAABScAAAYnAAAJ
JwAAKCcAACsnAAAsJwAALycAAEwnAABPJwAAUCcAAFMnAAC6JwAAvScAAL4nAADBJwAAbigAAHEo
AAByKAAAdSgAAMUoAADIKAAAySgAAMwoAAAIKQAACykAAAwpAAAPKQAALSkAADApAAAxKQAANCkA
AG4pAABxKQAAcikAAHUpAAB4KQAAiikAALopAAC9KQAAvikAAMEpAADcKQAA3ykAAOApAADjKQAA
ZyoAAGoqAABrKgAAbioAABgrAAAbKwAAHCsAAB8rAABkKwAAZysAAGgrAABrKwAAqisAAK0rAACu
KwAAsisAALcrAAC+KwAAvysAAMIrAADcKwAA3ysAAPMrAAD2KwAA/isAAAUsAAAHLAAACiwAAAss
AAAOLAAAEiwAABUsAABkLAAAbSwAAEUtAABILQAAYS0AAGQtAACiLQAApS0AAK4tAACxLQAAty0A
ALotAADYLQAA2y0AANwtAADfLQAA+i0AAP0tAAD+LQAAAS4AAB4uAAAhLgAAIi4AACUuAACMLgAA
jy4AAJAuAACTLgAAQC8AAEMvAABELwAARy8AAJcvAACaLwAAmy8AAJ4vAACDMAAAmzAAAL8wAADC
MAAAwzAAAMYwAADkMAAA5zAAAOgwAADrMAAAGTEAABwxAAAdMQAAIDEAACMxAAA1MQAAZTEAAGgx
AABpMQAAbDEAAIcxAACKMQAAizEAAI4xAAAoMgAAKzIAACwyAAAvMgAAhjIAAIkyAACKMgAAjTIA
ANIyAADVMgAA1jIAANkyAAAYMwAAGzMAABwzAAAgMwAAJTMAACwzAAAtMwAAMDMAAEozAABNMwAA
YTMAAGQzAABsMwAAczMAAHUzAAB4MwAAeTMAAHwzAACBMwAAhDMAAAI0AAAFNAAAnTQAAKA0AAC/
NAAA6TQAAF03AABgNwAATTsAAFk7AADCPAAAxjwAAMs8AADYPAAA8z0AACA+AAArPwAALj8AADc/
AAA6PwAAOz8AAD4/AADJPwAAT0AAAAcAOgAHADoABwA6AAcABQAHADoABwA6AAcAOgAHADoABwA6
AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoA
BwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAH
ADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcA
OgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6
AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoA
BwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAH
ADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcA
OgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6
AAcABwAFAIcgbwWQkTao/w//D/8P/w//D/8P/w//D/8PEACwe7Ae4mIkpv8P/w//D/8P/w//D/8P
/w//DxAAWB1xYIRo/AH/D/8P/w//D/8P/w//D/8P/w8QAI9x9mGcdRyG/w//D/8P/w//D/8P/w//
D/8PEABBcPJ92Avcjv8P/w//D/8P/w//D/8P/w//DxAAAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAA
DxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAwBQSgAAUUoDAG8oAAEALQABAAAAF4AAAAAA
AAAAAAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oFAFFKBQBvKAABAG8A
AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KBgBR
SgYAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEALEYSY/hXGBQABQAsGXoRA
C2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4QQDhGEmP4V
xgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA
AA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAA
AAAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AA
AAAAAAAAAAAAAAAAAAAAAAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oFAFFKBQBvKAAB
AG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9K
BgBRSgYAbygAAQCn8AMAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIG
XoTQAmCEmP5PSgAAUEoAAFFKAABvKAABAC0AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E
oAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAA
AAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF4AAAAAA
AAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKAABALfw
AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBQBR
SgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTg
EGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SwExGEmP4V
xgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA
AA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAA
AAAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgYAUUoGAG8oAAEAp/ADAAAAFxAA
AAAAAAAAAAAAaAEAAAAAAAAPGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+T0oAAFBKAABRSgAA
bygAAQAtAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CE
mP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TYCRGEmP4VxgUA
AdgJBl6E2AlghJj+T0oGAFFKBgBvKAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E
qAwRhJj+FcYFAAGoDAZehKgMYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAA
AAAAAAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAA
AAAAAAAAaAEAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+T0oGAFFKBgBvKAABAKfw
AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY/k9KAQBR
SgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOgXEYSY/hXGBQAB6BcGXoTo
F2CEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4S4GhGEmP4V
xgUAAbgaBl6EuBpghJj+T0oGAFFKBgBvKAABAKfwAwAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxgA
AA+E0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAABQSgAAUUoAAG8oAAEALQABAAAAF4AAAAAAAAAA
AAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oFAFFKBQBvKAABAG8AAQAA
ABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KBgBRSgYA
bygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CE
mP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4QQDhGEmP4VxgUA
ARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E
4BARhJj+FcYFAAHgEAZehOAQYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAA
AAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAA
AAAAAAAAAAAAAAAAAAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oFAFFKBQBvKAABAG8A
AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBgBR
SgYAbygAAQCn8AMAAAAXEAAAAAAAAAAAAABoAQAAAAAAAA8YAAAPhDgEEYSY/hXGBQABOAQGXoQ4
BGCEmP5PSgAAUEoAAFFKAABvKAABAC0AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ECAcR
hJj+FcYFAAEIBwZehAgHYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAA
AAsYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAA
AAAAaAEAAAAAAAALGAAAD4SoDBGEmP4VxgUAAagMBl6EqAxghJj+T0oBAFFKAQBvKAABALfwAQAA
ABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KBQBRSgUA
bygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCE
mP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QYFRGEmP4VxgUA
ARgVBl6EGBVghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E
6BcRhJj+FcYFAAHoFwZehOgXYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAA
AAAAAAsYAAAPhLgaEYSY/hXGBQABuBoGXoS4GmCEmP5PSgYAUUoGAG8oAAEAp/AFAAAAj3H2YQAA
AAAAAAAAAAAAALB7sB4AAAAAAAAAAAAAAACHIG8FAAAAAAAAAAAAAAAAWB1xYAAAAAAAAAAAAAAA
AEFw8n0AAAAAAAAAAAAAAAD/////////////////////////////BQAAAAAAAAAAAAAAAAD//wUA
AAAAAAAAAAAAAAAAAQAAAAEACQQCAAYAAAAAACk/AAAqPwAAyD8AAE9AAAAAAAAAAQAAAAEAAAAB
AAAA/0ABgAEAxgQAAMYEAACQHVEJAQABAMYEAAAAAAAAxgQAAAAAAAADAAMA6gNmAwIQAAAAAAAA
AE5AAABgAAAMAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAA
AAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAHAAAARwaQAQAAAAICBgMFBAUCAwAAAAMAAAAAAAAA
AAAAAAABAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANQaQAQIAAAIABQAA
AAAAAAAAAAAAAAAAAAEAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMwaQAQAAAAILBgQCAgIC
AgAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAAADMGkAEAAAACAAUAAAAAAAAAAAAD
AAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAAAA3BpABAAAAAgAFAAAAAAAAAAAAAwAAAAAA
AAAAAAAAAAEAAAAAAAAAQwBvAHUAcgBpAGUAcgAAAD8GkAEAAAACBwMJAgIFAgQAAAADAAAAAAAA
AAAAAAAAAQAAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAA7BpABAgAABQIBAgEIBAgHAAAA
AAAAAAAAAQAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAAiAAQAcQiMGADw0AIAAGgB
AAAAAAgjeYbScoqG6EuEphcAZwAAAHcIAADYLgAACgBnAAAABACDEFoBAAB3CAAA2C4AAAoAZwAA
AFoBAAAAAAAAtAQA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACAAD40AAAR
ABkAZAAAABkAAAAyNwAAMjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
iwkAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAABeAgAAAAAIO4NxAPAQAN8DAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAADw/w8AAAAAAAAAAAAA////f////3////9/////f////3////9/
////f4dIjgD//xIAAAAAAAAAAAAAAAAAAAALAEQAYQB2AGUAIABTAGkAbgBnAGUAcgAMAEQAYQB2
AGkAZAAgAFMAaQBuAGcAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAYAAAAFAAAAAAAMAAEA
DAACAAwAAwAMAAQADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAP7/AAADCgEAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAIQB
AAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAACsAAAABAAAALgAAAAFAAAAzAAAAAYAAADYAAAABwAA
AOQAAAAIAAAA9AAAAAkAAAAMAQAAEgAAABgBAAAKAAAANAEAAAsAAABAAQAADAAAAEwBAAANAAAA
WAEAAA4AAABkAQAADwAAAGwBAAAQAAAAdAEAABMAAAB8AQAAAgAAABAnAAAeAAAAAQAAAAAAAAAe
AAAAAQAAAAAAAAAeAAAADAAAAERhdmUgU2luZ2VyAB4AAAABAAAAAAAAAB4AAAABAAAAAAAAAB4A
AAAHAAAATm9ybWFsAAEeAAAADQAAAERhdmlkIFNpbmdlcgAAAAAeAAAAAwAAADIzAAAeAAAAFAAA
AE1pY3Jvc29mdCBXb3JkIDExLjAAQAAAAAAqkWMOAAAAQAAAAAAgO5eDHsQBQAAAAACod9sXc8MB
QAAAAAB8CiMassQBAwAAAAoAAAADAAAAdwgAAAMAAADYLgAAAwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+
/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOX
CAArLPmuWAEAABQBAAAOAAAAAQAAAHgAAAACAAAAgAAAAA4AAACMAAAADwAAAJgAAAAFAAAAqAAA
AAYAAACwAAAAEQAAALgAAAAXAAAAwAAAAAsAAADIAAAAEAAAANAAAAATAAAA2AAAABYAAADgAAAA
DQAAAOgAAAAMAAAA9QAAAAIAAAAQJwAAHgAAAAEAAAAAAAAAHgAAAAEAAAAAAAAAHgAAAAYAAABB
cHBsZQAAAAMAAABaAQAAAwAAAGcAAAADAAAAMjcAAAMAAAAAAAsACwAAAAAAAAALAAAAAAAAAAsA
AAAAAAAACwAAAAAAAAAeEAAAAQAAAAEAAAAADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAA
AKwAAAAFAAAAAAAAADAAAAABAAAAbwAAAAIAAAB3AAAAAwAAAIMAAAAEAAAAlwAAAAMAAAACAAAA
DgAAAF9QSURfTElOS0JBU0UAAwAAAAoAAAB3cml0ZWRhdGUABAAAAAsAAABleHBpcmVkYXRlAAIA
AAAQJwAAQQAAAAIAAAAAAAAHHgAAAAwAAABPY3QgMTQgMjAwNAAeAAAADAAAAEFwciAxNCAyMDA1
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAAD
AAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEA
AAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAA
ACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAA
LgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8
AAAA/v///z4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoA
AABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAA
AFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAA
ZwAAAGgAAABpAAAA/v///2sAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAD+////cwAAAHQAAAB1
AAAAdgAAAHcAAAB4AAAAeQAAAP7////9////fAAAAP7////+/////v////////9SAG8AbwB0ACAA
RQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAF
Af//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAA3wN/37HEAX4AAACAAAAA
AAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAOAAIB/////wUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAPQAAALFYAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEBAAAA//////////8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKHgAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwBy
AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAEAAAAAAAAAUARABvAGMAdQBt
AGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcgAAAAAQAAAA
AAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////8BAP7/AgABAP////8G
CQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AP7///9OQjZXEAAAAFdv
cmQuRG9jdW1lbnQuOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

--Boundary_(ID_WjTW5upL3PDd9wc9rQTuzw)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT



> 
>> (The reason I abandoned the draft was not the difficulty of getting it through, by the way, but because the W3C Timed Text group decided it didn't need it).
> 
> Can you be more specific? E.g., does Timed Text only use one font format? Or does it not contain any field that indicates the format, which makes this "somebody else's problem"?

I think that was it.

> Or some other reason?
> 
> Regards,    Martin.

David Singer
Multimedia and Software Standards, Apple Inc.


--Boundary_(ID_WjTW5upL3PDd9wc9rQTuzw)--

From alexey.melnikov@isode.com  Mon Nov 14 18:08:44 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E8311E80FA for ; Mon, 14 Nov 2011 18:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFeSmzNMxLJy for ; Mon, 14 Nov 2011 18:08:44 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id D64BB11E80E8 for ; Mon, 14 Nov 2011 18:08:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1321322923; d=isode.com; s=selector; i=@isode.com; bh=TeegiNT0lKC6VFJaJ52J9msFRRDWJ0Y0K05tqwJI2bc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=tKJauv8QVMl9U1LQsv9DctG/evy4Ytt7kBsJ1HA5HVL6JxRzoX+fmsi8/wSBb0/EIUo2FZ R93hzzvX7re2atp+6NjVWRRnV4d6QhOnvzDe680E1uvXTF1yEwZaitSskCGiOsoqfgAXuV iNALgf6ZtnxWlDmY+njvFxPIs/UDCfU=;
Received: from [192.168.174.158] (60-251-183-229.HINET-IP.hinet.net [60.251.183.229])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 15 Nov 2011 02:08:42 +0000
Message-ID: <4EC1C9A6.6080201@isode.com>
Date: Tue, 15 Nov 2011 02:08:38 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: Ned Freed 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com>
In-Reply-To: <01O8ETBP3QY400RCTX@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 02:08:44 -0000

Hi Ned,

On 14/11/2011 19:33, Ned Freed wrote:
>> > * Eliminate standards, vendor, personal trees distinction for MIME 
>> types
>> > (For URI schemes, eliminate distinction between provisional and 
>> permanent
>> > schemes)
> OK, so let's see if I have this straight. There are four subprocesses 
> involved:
> (1) Personal type registrations. Rarely used.
> (2) Vendor type registration. Commonly and successfully used.
> (3) Standards tree registration. Used but has issues with timely 
> processing
>    of requests that we're supposed to be tryhing to fix.
> (4) Third party revisions and comments process. Essentially never used.
>
> And the proposal is to throw out (1)-(3)
If by "throw out (1)-(3)" you mean just have 1 type of registration, 
then yes, I think this is what Roy proposed.

I would personally like to better understand the thinking behind having 
a separate standards tree registration. What would be disadvanteges of 
dropping (3)? What was the original purpose for having a separate 
registration from vendor types?
> and depend on (4) happening because
> ... well, because.. This seems ... unlikely.
>
>> > * ENCOURAGE vendors to ship with vendor-neutral short-named types
>> > regardless of whether they have been registered yet or not;
> I think encouraging vendor-neutral registrations would be great. The
> question is how we'd actually do it.
>
>> I think that makes sense for something widely known and used (e.g.
>> application/pdf), but not necessarily for some really company-specific
>> type. (Of course, we don't know in advance which way something may go in
>> the end, but we could use this rule at least for when the company e.g.
>> wants to express that a type is NOT intended for general use).
  [...]

From alexey.melnikov@isode.com  Mon Nov 14 18:13:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8232611E830B for ; Mon, 14 Nov 2011 18:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 VO4X3T6ZsmiT for ; Mon, 14 Nov 2011 18:13:33 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 897F221F8D4C for ; Mon, 14 Nov 2011 18:13:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1321323212; d=isode.com; s=selector; i=@isode.com; bh=qs5sCYsck7z00/K84xl8oq76NR9WyCFDMtVfkac6Cgs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=A1Br/EKg7rJqgr5Nx77zsTX8muTd6QbStuTE2vsI9RQxaw20nfSrHsXcfM6b/od89pUPq2 5t9I58XatHSiHVLpBkhuBxza3RT20ZwLb3uJPI1/vjKPeQT0K+FX+W+5L/9Sqdf2xoOvEy awbYELnPysJQ1NUoQf/46uiS2o5rV6o=;
Received: from [192.168.174.158] (60-251-183-229.HINET-IP.hinet.net [60.251.183.229])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 15 Nov 2011 02:13:32 +0000
Message-ID: <4EC1CAC9.7000301@isode.com>
Date: Tue, 15 Nov 2011 02:13:29 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp>
In-Reply-To: <4EC1C3D7.7070402@it.aoyama.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: quoted-printable
Cc: Roy Fielding , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 02:13:34 -0000

Hi Martin,

On 15/11/2011 01:43, "Martin J. D=FCrst" wrote:
> Hello Ned, others,
>
> On 2011/11/15 4:33, Ned Freed wrote:
>
>>> > ENCOURAGE the public to register any names that they have seen in
>>> > deployed software. (same for URI schemes)
>>
>>> I think third-party registration is indeed something we should=20
>>> encourage
>>> more.
>>
>> How do you propose we do that?
>
> It seems that currently, people don't even know that it is possible.=20
> So the first step is to make this more known. On another list, you=20
> write: "We have always allowed registrations by any interested party."=20
> That's apparently true, but is it done because nowhere in RFC 4288 it=20
> says it's not possible? Then making it explicit in=20
> draft-freed-media-type-regs should help.
+1. To be honest I didn't know that this procedure was to be expected.=20
In all cases I was expecting that some representative of the=20
company/organization that defined the media type should be involved in a=20
registration, even if somebody else does the work to actually document it.
> For example, you could put in a section 4.12, (Non-)Requirements for=20
> Contact Information, Author, and Change Controller, saying explicitly=20
> that third-party registrations are welcome.
Exactly.
> This could also explain what in such a case contact information,=20
> author, and change controller should be. I'd assume that contact=20
> information goes to the submitter, but change controller stays with=20
> the company or individual that created the format, but you'll know=20
> better what's current practice. If I did a third-party registration,=20
> this would be the place where I'd really not know which way to go.
>
> You can also add pointers to that new section, or just mention the=20
> fact, in other places where somebody might potentially look. As an=20
> example, in=20
> http://tools.ietf.org/html/draft-freed-media-type-regs-01#section-5.5,=20
> you could say that in addition to providing comments, new=20
> registrations and change requests by third parties are also possible.
>
> The next step would then be to put text saying "Media Types may also=20
> be registered by third parties." or so on the relevant pages at IANA=20
> (e.g. http://www.iana.org/cgi-bin/mediatypes.pl and=20
> http://www.iana.org/assignments/media-types/index.html).
>
>
> Regards,   Martin.
Best Regards,
Alexey


From masinter@adobe.com  Mon Nov 14 18:15:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFBC11E8316 for ; Mon, 14 Nov 2011 18:15:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.089
X-Spam-Level: 
X-Spam-Status: No, score=-106.089 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, 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 BVxhMZHbD29X for ; Mon, 14 Nov 2011 18:15:35 -0800 (PST)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A211E82F4 for ; Mon, 14 Nov 2011 18:15:34 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKTsHLLxAUtguBWWMrPCgUdlnfcgrgNtmK@postini.com; Mon, 14 Nov 2011 18:15:34 PST
Received: from inner-relay-1.corp.adobe.com (inner-relay-1.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pAF2FAQB022930; Mon, 14 Nov 2011 18:15:10 -0800 (PST)
Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pAF2F95R014840; Mon, 14 Nov 2011 18:15:09 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Mon, 14 Nov 2011 18:15:09 -0800
From: Larry Masinter 
To: Alexey Melnikov , =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
Date: Mon, 14 Nov 2011 18:15:07 -0800
Thread-Topic: [apps-discuss] Encouraging third party registrations
Thread-Index: AcyjPDEPbUNdqW/mRCq7Pn6CRzHnRAAACWgA
Message-ID: 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp>	<01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp> <4EC1CAC9.7000301@isode.com>
In-Reply-To: <4EC1CAC9.7000301@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Roy Fielding , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 02:15:35 -0000

Who should a third-party registrar list as the "change controller" ?



-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Alexey Melnikov
Sent: Tuesday, November 15, 2011 10:13 AM
To: "Martin J. D=FCrst"
Cc: Roy Fielding; Ned Freed; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Encouraging third party registrations

Hi Martin,

On 15/11/2011 01:43, "Martin J. D=FCrst" wrote:
> Hello Ned, others,
>
> On 2011/11/15 4:33, Ned Freed wrote:
>
>>> > ENCOURAGE the public to register any names that they have seen in=20
>>> > deployed software. (same for URI schemes)
>>
>>> I think third-party registration is indeed something we should=20
>>> encourage more.
>>
>> How do you propose we do that?
>
> It seems that currently, people don't even know that it is possible.=20
> So the first step is to make this more known. On another list, you
> write: "We have always allowed registrations by any interested party."=20
> That's apparently true, but is it done because nowhere in RFC 4288 it=20
> says it's not possible? Then making it explicit in=20
> draft-freed-media-type-regs should help.
+1. To be honest I didn't know that this procedure was to be expected.=20
In all cases I was expecting that some representative of the company/organi=
zation that defined the media type should be involved in a registration, ev=
en if somebody else does the work to actually document it.
> For example, you could put in a section 4.12, (Non-)Requirements for=20
> Contact Information, Author, and Change Controller, saying explicitly=20
> that third-party registrations are welcome.
Exactly.
> This could also explain what in such a case contact information,=20
> author, and change controller should be. I'd assume that contact=20
> information goes to the submitter, but change controller stays with=20
> the company or individual that created the format, but you'll know=20
> better what's current practice. If I did a third-party registration,=20
> this would be the place where I'd really not know which way to go.
>
> You can also add pointers to that new section, or just mention the=20
> fact, in other places where somebody might potentially look. As an=20
> example, in=20
> http://tools.ietf.org/html/draft-freed-media-type-regs-01#section-5.5,
> you could say that in addition to providing comments, new=20
> registrations and change requests by third parties are also possible.
>
> The next step would then be to put text saying "Media Types may also=20
> be registered by third parties." or so on the relevant pages at IANA=20
> (e.g. http://www.iana.org/cgi-bin/mediatypes.pl and=20
> http://www.iana.org/assignments/media-types/index.html).
>
>
> Regards,   Martin.
Best Regards,
Alexey

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

From duerst@it.aoyama.ac.jp  Mon Nov 14 18:24:53 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0E911E8385 for ; Mon, 14 Nov 2011 18:24:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.618
X-Spam-Level: 
X-Spam-Status: No, score=-99.618 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oNZcu1nFZsQ for ; Mon, 14 Nov 2011 18:24:52 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id ECC8D11E837E for ; Mon, 14 Nov 2011 18:24:48 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAF2OhWj004864 for ; Tue, 15 Nov 2011 11:24:43 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 201e_0a49_fa650db6_0f30_11e1_a079_001d096c5782; Tue, 15 Nov 2011 11:24:43 +0900
Received: from [IPv6:::1] ([133.2.210.1]:55369) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Tue, 15 Nov 2011 11:24:46 +0900
Message-ID: <4EC1CD67.5030400@it.aoyama.ac.jp>
Date: Tue, 15 Nov 2011 11:24:39 +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: Larry Masinter 
References: 	<4EC0BE9E.8020702@it.aoyama.ac.jp>	<01O8ETBP3QY400RCTX@mauve.mrochek.com>	<4EC1C3D7.7070402@it.aoyama.ac.jp> <4EC1CAC9.7000301@isode.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Roy Fielding , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 02:24:53 -0000

On 2011/11/15 11:15, Larry Masinter wrote:
> Who should a third-party registrar list as the "change controller" ?

Good question. I already proposed that it be answered in Ned's document. 
See below.

Regards,   Martin.

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alexey Melnikov
> Sent: Tuesday, November 15, 2011 10:13 AM
> To: "Martin J. Dürst"
> Cc: Roy Fielding; Ned Freed; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Encouraging third party registrations

> On 15/11/2011 01:43, "Martin J. Dürst" wrote:

>> For example, you could put in a section 4.12, (Non-)Requirements for
>> Contact Information, Author, and Change Controller, saying explicitly
>> that third-party registrations are welcome.
> Exactly.
>> This could also explain what in such a case contact information,
>> author, and change controller should be. I'd assume that contact
>> information goes to the submitter, but change controller stays with
>> the company or individual that created the format, but you'll know
>> better what's current practice. If I did a third-party registration,
>> this would be the place where I'd really not know which way to go.

From alexey.melnikov@isode.com  Mon Nov 14 18:56:12 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0BE1F0D61 for ; Mon, 14 Nov 2011 18:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.399
X-Spam-Level: 
X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 J-Q1cxt8+HLw for ; Mon, 14 Nov 2011 18:56:11 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6D71F0D60 for ; Mon, 14 Nov 2011 18:56:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1321325770; d=isode.com; s=selector; i=@isode.com; bh=7qZ2UiXn2ZBuhwGtkshXUwOFT7WUk/pk+91PssYwRmE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=aooJQhpaDZXJHv32U5XU9wbjNPOrs6wuigH9AyPJd15J3yd0mLV25euZAwkL0qUjRy2W0I Q9hyP4e5J3JHrYH2S2Spm1R5kZS32+Q0fIdaaNrP9mrfnPs5hLJ0VBH648HVeJuCmGkChI uxMmavQj9QYXUkGW5UVQLzOlgGkh1Bk=;
Received: from [192.168.174.158] (60-251-183-229.HINET-IP.hinet.net [60.251.183.229])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 15 Nov 2011 02:56:08 +0000
Message-ID: <4EC1D4C1.7080406@isode.com>
Date: Tue, 15 Nov 2011 02:56:01 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsiki?= 
References: <4EC16815.80501@gmail.com>
In-Reply-To: <4EC16815.80501@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps-discuss list 
Subject: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 02:56:12 -0000

Hi Mykyta,

In Section 1:

    The concept of 'about' URIs has been formed at the times when the
    applications did not have the "friendly" user interface, in order to
    provide an access to the aforementioned resources via typing the URIs
    in the address bar.

Sorry, are you saying that typing about: URIs into the address bar is 
"friendly" interface?
I think I disagree. Or is "not" missing somewhere?

    Even though the user interface of current
    Internet-targeted software effectively rescinds the issue, and
    'about' URIs can be thought to be a rudimentary phenomenon, they are
    still supported by a variety of Web browsers and are not going to
    cease to exist.

URIs are useful in contexts when one wants to reference a resource and
can only pass in a string. So no, about: URIs are not going to go away
and not for reasons you've mentioned. I suggest removing or rewording
this text.



2.1. URI Scheme Syntax

    The 'about' URI MUST syntactically conform to the  rule
    below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]:

      about-uri   = "about:" about-token [ about-query ]
      about-token = segment
      about-query = "?" query
      segment     = 
      query       = 

    In terms of RFC 3986,  part corresponds to ,
    and  to the query component of URI.

s/query/ ? (I didn't check RFC 3986)


2.2. URI Scheme Semantics

    However, it is impossible to specify binding between all the possible
    tokens and the semantics of 'about' URIs that would contain such
    tokens.  Therefore any application MAY resolve an 'about' URI to any
    desired resource, and MAY redirect such URIs.

The meaning of redirection is not defined here. Do you mean redirection 
in HTTP sense?
If yes, I think a reference to HTTP (RFC 2616) is needed.


2.2.1. Special-Purpose 'about' URIs

    A small, though expandable, range of s are reserved for
    use in special-purpose 'about' URIs, abbreviated "SPU" (special-
    purpose URI).  Such tokens are named "special-purpose 'about' URI
    tokens", and abbreviated "SPT" (special-purpose token).

    An SPU is an 'about' URI containing one of the registered SPTs as the
 part.  An SPU MUST be handled in strict accordance with
    the rules defined for SPT contained therein.  The SPT specification
    MAY define additional provisions on handling of  part in
    the corresponding SPU; by default, it MUST be ignored for the purpose
    of handling SPU.

Where is this requirement coming from? Is this common behaviour among
existing browsers?

    SPU MAY be defined to be unresolvable.  This means that an
    application MUST NOT resolve it in some particular resource.  Such
    SPUs may be used as placeholders, or in some other way.

I fail to see utility in this. Can you maybe provide an example
of an unresolvable about URI?
(This might also affect the IANA registration section which includes
this flag in the token registration template.)


2.2.2. Unrecognized 'about' URIs

    Naturally, an application will support only a particular range of
    'about' URIs; also, some applications will support 'about' URIs that
    are not supported by an other one.  This document specifies the rules
    for handling unrecognized 'about' URIs.

    An unrecognized 'about' URIs as a URI that may not be recognized by
    an application.  (Correspondingly, such categorization is per-
    application, not per-fact.)

I don't understand the comment in () and I don't think it adds any value
anyway.

    An unrecognized 'about' URI SHOULD be
    handled as the  URI, although other behavior is
    possible.

Is there a reason why this is a SHOULD? This seems rather strong here.
I am thinking that displaying an error about unrecognized token would be
another reasonable choice. In fact it would be my preferred choice.

2.3. Encoding Considerations

    'about' URIs are subject to encoding rules defined in RFC 3986
    [RFC3986].  'about' IRIs [RFC3987] are not permitted.

The last quoted sentence: why?
If an about URI is used to edit configuration, I can see some Unicode being
passed in the query part of such URI.



4.2. A Registry for SPTs

    The registration policy for new entries is "Specification Required",

This was already discussed in the face to face meeting and I will 
comment on this separately. (Yes, I think this is too restrictive.)


From johnl@iecc.com  Mon Nov 14 18:58:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59FD1F0D62 for ; Mon, 14 Nov 2011 18:58:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.982
X-Spam-Level: 
X-Spam-Status: No, score=-110.982 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 aoEmLb2u+A2b for ; Mon, 14 Nov 2011 18:58:11 -0800 (PST)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EB9F01F0C8F for ; Mon, 14 Nov 2011 18:58:10 -0800 (PST)
Received: (qmail 53139 invoked from network); 15 Nov 2011 02:58:09 -0000
Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 15 Nov 2011 02:58:09 -0000
Received: (qmail 51444 invoked from network); 15 Nov 2011 02:58:09 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Nov 2011 02:58:09 -0000
Date: 15 Nov 2011 02:57:46 -0000
Message-ID: <20111115025746.26808.qmail@joyce.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: <6.2.5.6.2.20111114142451.09b74390@elandnews.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: sm+ietf@elandsys.com
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 02:58:11 -0000

Looks mostly reasonable.

In step (9), you say "If a transient failure condition is reported,
try the next MX RR" which looks wrong to me.  If you get a 4xx, you
requeue the message and try it again later.

R's,
John


From nico@cryptonector.com  Mon Nov 14 19:00:12 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552C91F0D7E for ; Mon, 14 Nov 2011 19:00:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.693
X-Spam-Level: 
X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455]
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 2T-uTCVnPr3d for ; Mon, 14 Nov 2011 19:00:11 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA741F0D86 for ; Mon, 14 Nov 2011 19:00:09 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id CA83E678055 for ; Mon, 14 Nov 2011 19:00:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Qz6qw3bEpS/70xAIVxwu7 6eUU+cwfgpj1x+ZJGCrkzUMB0+l24qoALDyOjtJFzHI34HRu4BlWHpI/lgcJoB2S zCD1I/mV6HTV7MKptt1ITtwlJRIBwlJkRRjkhHvjcXQ25wZWSXLqQXgVRAk5K21S o+BsjAaQt6hm94NAD6hmBo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=SZu59/6mxrg0ILesp2v5 LotLke8=; b=H3k9C2aezdu3Dp9QOIqIjyTahh5mpZwdWFlkLbsok/EAwg0p5RwN UbVXzZ6+jSQEKQIOY2Ed4uukfgLVvO3s6lK7YFaU7vBJ069tjmY4UjWcwmd/5/2U 8kpVEocrr1BpNYBSnYVj3OI6bUEnW7+f48+BqepUjjG+IWhOLTjRLm0=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 9E4C467803E for ; Mon, 14 Nov 2011 19:00:08 -0800 (PST)
Received: by vcbfk1 with SMTP id fk1so6793777vcb.31 for ; Mon, 14 Nov 2011 19:00:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.33.140 with SMTP id r12mr39857542vdi.36.1321326007917; Mon, 14 Nov 2011 19:00:07 -0800 (PST)
Received: by 10.220.98.6 with HTTP; Mon, 14 Nov 2011 19:00:07 -0800 (PST)
In-Reply-To: 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp> <4EC1CAC9.7000301@isode.com> 
Date: Mon, 14 Nov 2011 21:00:07 -0600
Message-ID: 
From: Nico Williams 
To: Larry Masinter 
Content-Type: text/plain; charset=UTF-8
Cc: Ned Freed , Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 03:00:12 -0000

On Mon, Nov 14, 2011 at 8:15 PM, Larry Masinter  wrote:
> Who should a third-party registrar list as the "change controller" ?

If collisions don't matter then who cares?  Just add more collisions :)

Alternatively, how about:

   A third party should not claim to be the owner.
   The third party could specify an owner, but that should be considered
      informative.
   Anyone could make a claim on a registration that has no owner already.
   Anyone claiming to be the owner of a registration that already has an
      owner would have to submit their claim to  (IESG?),
      with appeals going to  (IAB?).

But I think it's better to just not have to have an owner, nor any
change control -- it's easier and cheaper that way, particularly if it
is true that collisions in this namespace are of little consequence.

Nico
--

From msk@cloudmark.com  Mon Nov 14 19:04:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F95F1F0D96 for ; Mon, 14 Nov 2011 19:04:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.51
X-Spam-Level: 
X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 tufhS7V4ZYxZ for ; Mon, 14 Nov 2011 19:04:40 -0800 (PST)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE2D1F0D94 for ; Mon, 14 Nov 2011 19:04:40 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 14 Nov 2011 19:04:39 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Mon, 14 Nov 2011 19:04:37 -0800
Thread-Topic: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
Thread-Index: AcyjHemJf30dmThPQRaQAVM6mBjDUgAJJtOw
Message-ID: 
References: <6.2.5.6.2.20111114142451.09b74390@elandnews.com>
In-Reply-To: <6.2.5.6.2.20111114142451.09b74390@elandnews.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ietf-smtp@imc.org" 
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 03:04:41 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of S Moonesamy
> Sent: Monday, November 14, 2011 2:35 PM
> To: apps-discuss@ietf.org
> Cc: ietf-smtp@imc.org
> Subject: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
>=20
> The change from RFC 3974 is:
>=20
>   - Removal of the Basic DNS Resource Record Definitions for Mail
> Routing section
>=20
>   - Removal of the SMTP Sender Algorithm in a Dual-Stack Environment
> section

Why were these removed?  They seemed useful for illustration in RFC3974.

>   - Removal of the Operational Experience and open issues sections.

Replacing this with more current operational experience might be better tha=
n removing it outright.

Also, I wonder if the v6ops "Happy Eyeballs" work might be an interesting r=
eference here.

> Please note that the algorithm has already been used in several
> existing implementations.

Excellent.

RFC5321 talked about aspects of RFC3974 that were in conflict with what RFC=
5321 says.  Have those been resolved in your draft?  (Alas, I can't tell af=
ter a cursory read what those might've been.  Maybe it's simply the thing J=
ohn Levine just pointed out in another message.)

It's worth pointing out the document state change as well (which I support)=
.

-MSK

From masinter@adobe.com  Mon Nov 14 19:34:31 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BFB11E81A2 for ; Mon, 14 Nov 2011 19:34:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.253
X-Spam-Level: 
X-Spam-Status: No, score=-106.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, 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 fxsHyOhhnfC2 for ; Mon, 14 Nov 2011 19:34:31 -0800 (PST)
Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 65BF511E80E0 for ; Mon, 14 Nov 2011 19:34:30 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKTsHdxcucVoDacwgc54kOLZyinls8uhZj@postini.com; Mon, 14 Nov 2011 19:34:30 PST
Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pAF3YRQB027440 for ; Mon, 14 Nov 2011 19:34:28 -0800 (PST)
Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pAF3YR5R029783 for ; Mon, 14 Nov 2011 19:34:27 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Mon, 14 Nov 2011 19:34:27 -0800
From: Larry Masinter 
To: "apps-discuss@ietf.org" 
Date: Mon, 14 Nov 2011 19:34:24 -0800
Thread-Topic: MIME sniffing and the media type registry magic numbers
Thread-Index: AcyjR3dOdvrAwmf7S4mRisFiNDNxjA==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [apps-discuss] MIME sniffing and the media type registry magic numbers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 03:34:31 -0000

SSBhZG1pdCB0byBhIHN0cm9uZyBjYXNlIG9mIGNvZ25pdGl2ZSBkaXNzb25hbmNlIGFyZ3Vpbmcg
dHdvIHNpZGVzIG9mIHRoZXNlIGlzc3VlcywgYnV0IEkgdGhpbmsgdGhlcmUncyBhIHJlc29sdXRp
b246DQoNCkNvbnRleHQ6ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi13
ZWJzZWMtbWltZS1zbmlmZiBwcm9wb3NlcyBhIHN0YW5kYXJkcyB0cmFjayBub3JtYXRpdmUgYWxn
b3JpdGhtIGZvciAic25pZmZpbmciIGNvbnRlbnQgdG8gZGV0ZXJtaW5lIGl0cyBtZWRpYSB0eXBl
Lg0KRG9jdW1lbnQgd2lsbCBiZSBkaXNjdXNzZWQgYXQgd2Vic2VjIHdvcmtpbmcgZ3JvdXAgbWVl
dGluZyB0b21vcnJvdyAoV2VkbmVzZGF5KS4NCg0KSW4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v
cmcvd2cvd2Vic2VjL3RyYWMvdGlja2V0LzE3IEkgcHJvcG9zZWQgdXNpbmcgYSAodXBkYXRlZCwg
Y2xlYW5lZCB1cCwgcmV2aWV3ZWQ/KSByZWdpc3RyeSBmb3IgbWFnaWMgbnVtYmVycyByYXRoZXIg
dGhhbiBhbiBleHBsaWNpdCB0YWJsZS4NCg0KSSBhbSBxdWl0ZSBjb25mbGljdGVkIGFib3V0IGZp
cnN0IGFyZ3VpbmcgZm9yIGxvb3NlIGNvbnRyb2xzIG9uIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9u
IGluIGdlbmVyYWwsIGJ1dCBzdGFuZGFyZHMgdHJhY2sgZm9yIG9uZSBvZiB0aGUgZmllbGRzICh0
aGUgbWFnaWMgbnVtYmVyKS4NCg0KQW4gYWx0ZXJuYXRpdmUgaXMgdG8gYWRkIGEgbmV3IHJlZ2lz
dHJ5IG9mICJWYWxpZGF0ZWQgbWFnaWMgbnVtYmVycyIgYW5kIGJlIGNsZWFyZXIgaW4gdGhlIG1l
ZGlhIHR5cGUgcmVnaXN0cnkgaXRzZWxmIHRoYXQgdGhlICJtYWdpYyBudW1iZXIiIGZpZWxkIGlz
IG9ubHkgYSBoaW50LCBhbmQgcG9pbnQgcGVvcGxlIGF0IHRoZSBwYXJhbGxlbCByZWdpc3RyeS4N
Cg0KSW4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvd2Vic2VjL3RyYWMvdGlja2V0LzE4
IGkgbm90ZWQgdGhhdCBzbmlmZmluZyBhbHNvIGNvdmVycyByZXRyaWV2aW5nIGRvY3VtZW50cyBm
cm9tIGZ0cDogYW5kIGZpbGU6IFVSSXMgaW50byBicm93c2VycywgaW4gd2hpY2ggY2FzZXMgdGhl
IGZpbGUgZXh0ZW5zaW9ucyAqYXJlKiB1c2VkOyBhZ2FpbiwgSSB0aGluayB0aGlzIG1ha2VzIHRo
ZSAiZmlsZSBleHRlbnNpb24iIGZpZWxkIHdoaWNoIGlzIG9wdGlvbmFsIG5vdyBpbnRvIHNvbWV0
aGluZyB0aGF0IG1pZ2h0IGhhdmUgYSAidmFsaWRhdGVkIiB2YWx1ZS4NCg0KU28gcmF0aGVyIHRo
YW4gY29uc2lkZXJpbmcgYSAicmVnaXN0cmF0aW9uIiB0byBoYXZlIGRpZmZlcmVudCBzdGF0dXMg
KEZDRlMsIHN0YW5kYXJkcyB0cmFjaywgZXRjLikgcGVyaGFwcyB0aGUgaW5kaXZpZHVhbCBmaWVs
ZHMgb2YgdGhlIHJlZ2lzdHJhdGlvbiBuZWVkIHN0YXR1cyBtZXRhZGF0YS4NCg0KTGFycnkNCg0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogIk1hcnRpbiBKLiBEw7xyc3QiIFtt
YWlsdG86ZHVlcnN0QGl0LmFveWFtYS5hYy5qcF0gDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAx
NSwgMjAxMSA5OjE1IEFNDQpUbzogRGF2aWQgU2luZ2VyDQpDYzogTGFycnkgTWFzaW50ZXI7IHQu
cGV0Y2g7IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzsgZ2FkYW1zQHhmc2kuY29tDQpTdWJqZWN0OiBS
ZTogW2FwcHMtZGlzY3Vzc10gZm9udC8qIChhbmQgZHJhZnQtZnJlZWQtbWVkaWEtdHlwZS1yZWdz
KQ0KDQpPbiAyMDExLzExLzE1IDM6MzUsIERhdmlkIFNpbmdlciB3cm90ZToNCj4NCj4gT24gTm92
IDEyLCAyMDExLCBhdCAxMjoyNSAsIExhcnJ5IE1hc2ludGVyIHdyb3RlOg0KPg0KPj4gSSBzZWUg
bm8gdXNlIGNhc2UgZm9yIHdoeSBoYXZpbmcgZm9udC9vcGVudHlwZSBpcyBhbnkgYmV0dGVyIHRo
YW4gDQo+PiBhcHBsaWNhdGlvbi9vcGVudHlwZQ0KPj4NCj4+IFRoZSBvbmx5IHVzZSBjYXNlIEkg
Y2FuIGltYWdpbmUgZnJvbSBsb29raW5nIGF0DQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1zaW5nZXItZm9udC1taW1lLTAwDQo+PiBpcyB0aGUgcG9zc2liaWxpdHkgb2YgZGVm
aW5pbmcgY29tbW9uIHBhcmFtZXRlcnMgYWNyb3NzIGZvbnQgZGF0YSB0eXBlcyAoaW4gdGhlIHNh
bWUgd2F5IHRoYXQgdGV4dC8uLiBoYXMgYSBjb21tb24gY2hhcnNldCBwYXJhbWV0ZXIpLg0KPg0K
PiBIb3cgc2VyaW91cyBpcyB0aGUgZmlyc3QgY29uY2VybiAiRmlyc3QsIHRoZSAgImFwcGxpY2F0
aW9uIiBzdWItdHJlZSBpcyB0cmVhdGVkIChjb3JyZWN0bHkpIHdpdGggZ3JlYXQgY2F1dGlvbiB3
aXRoIHJlc3BlY3QgdG8gdmlydXNlcyBhbmQgb3RoZXIgYWN0aXZlIGNvZGUuIj8NCg0KSSB2ZXJ5
IG11Y2ggdGhpbmsgdGhhdCBoYXZpbmcgYSAgZm9udC8gdG9wIGxldmVsIHR5cGUgaXMgYWN0dWFs
bHkgYSBnb29kIGlkZWEuIEJ1dCBJIGhpbnRlZCBhdCB0aGlzIGJlZm9yZTogYSB0eXBlIHNob3Vs
ZG4ndCBiZSB0cmVhdGVkIGFzICJtb3JlIHNhZmUiIGp1c3QgYmVjYXVzZSBpdCBzYXlzIGZvbnQv
LCByYXRoZXIgdGhhbiBhcHBsaWNhdGlvbi8uIE1hbnkgZm9udCBmb3JtYXRzIGNvbnRhaW4gYWN0
aXZlIGNvZGUgdGhhdCBpcyBleGVjdXRlZCBieSB0aGUgZm9udCBlbmdpbmUuIFNldmVyYWwgc2Vj
dXJpdHkgaG9sZXMgaGF2ZSBiZWVuIGZvdW5kIGluIHRoaXMgYXJlYS4gU28gSSdkIGFjdHVhbGx5
IGRlLWVtcGhhc2l6ZSBvciByZW1vdmUgdGhpcyBwb2ludC4gZHJhZnQtc2luZ2VyLWZvbnQtbWlt
ZS0wMCBhbHNvIGRvZXNuJ3QgaGF2ZSBhIHNlY3VyaXR5IHNlY3Rpb24sIGFuZCBpdCBvZiBjb3Vy
c2UgbmVlZHMgb25lLg0KDQoNCj4gKFRoZSByZWFzb24gSSBhYmFuZG9uZWQgdGhlIGRyYWZ0IHdh
cyBub3QgdGhlIGRpZmZpY3VsdHkgb2YgZ2V0dGluZyBpdCB0aHJvdWdoLCBieSB0aGUgd2F5LCBi
dXQgYmVjYXVzZSB0aGUgVzNDIFRpbWVkIFRleHQgZ3JvdXAgZGVjaWRlZCBpdCBkaWRuJ3QgbmVl
ZCBpdCkuDQoNCkNhbiB5b3UgYmUgbW9yZSBzcGVjaWZpYz8gRS5nLiwgZG9lcyBUaW1lZCBUZXh0
IG9ubHkgdXNlIG9uZSBmb250IGZvcm1hdD8gT3IgZG9lcyBpdCBub3QgY29udGFpbiBhbnkgZmll
bGQgdGhhdCBpbmRpY2F0ZXMgdGhlIGZvcm1hdCwgd2hpY2ggbWFrZXMgdGhpcyAic29tZWJvZHkg
ZWxzZSdzIHByb2JsZW0iPyBPciBzb21lIG90aGVyIHJlYXNvbj8NCg0KUmVnYXJkcywgICAgTWFy
dGluLg0K

From stpeter@stpeter.im  Mon Nov 14 20:14:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8752E21F8D9A for ; Mon, 14 Nov 2011 20:14:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.585
X-Spam-Level: 
X-Spam-Status: No, score=-101.585 tagged_above=-999 required=5 tests=[AWL=-2.041, BAYES_00=-2.599, FRT_ADOBE2=2.455, J_CHICKENPOX_24=0.6, 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 l4ePmBqGFDD1 for ; Mon, 14 Nov 2011 20:14:06 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E164121F8D89 for ; Mon, 14 Nov 2011 20:14:06 -0800 (PST)
Received: from dhcp-15ab.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A83624216E; Mon, 14 Nov 2011 21:20:17 -0700 (MST)
Message-ID: <4EC1E70A.7030909@stpeter.im>
Date: Tue, 15 Nov 2011 12:14:02 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Nico Williams 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp> <4EC1CAC9.7000301@isode.com>  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Roy Fielding , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 04:14:07 -0000

On 11/15/11 11:00 AM, Nico Williams wrote:
> On Mon, Nov 14, 2011 at 8:15 PM, Larry Masinter  wrote:
>> Who should a third-party registrar list as the "change controller" ?
>
> If collisions don't matter then who cares?  Just add more collisions :)
>
> Alternatively, how about:
>
>     A third party should not claim to be the owner.
>     The third party could specify an owner, but that should be considered
>        informative.
>     Anyone could make a claim on a registration that has no owner already.
>     Anyone claiming to be the owner of a registration that already has an
>        owner would have to submit their claim to  (IESG?),
>        with appeals going to  (IAB?).
>
> But I think it's better to just not have to have an owner, nor any
> change control -- it's easier and cheaper that way, particularly if it
> is true that collisions in this namespace are of little consequence.

I think I might buy into that. So the change controller and owner is 
IANA, right? Do we expect that IANA would keep track of who has asked it 
to register or modify any given entry?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From nico@cryptonector.com  Mon Nov 14 20:26:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29D31F0D54 for ; Mon, 14 Nov 2011 20:26:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 8ejslK4X8GVW for ; Mon, 14 Nov 2011 20:26:33 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE0A1F0D51 for ; Mon, 14 Nov 2011 20:26:33 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id D8E0736006F for ; Mon, 14 Nov 2011 20:26:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=RWvw3mZ/vau25A728eqR2 KbUx7EyfG80TQ3OxN4SCzvNqdkfyvK3CATzDw/1HbDKYmIma4xlbZz7+AHXpFOoc cQhCLPUW9ZaV8Y3AzHneL6XuUX5Ckp5V8YbqHc7/ckk8v2nmu08/uYFOsFcx8wN7 DHt1FqgeOMm5gYKJ19EQdk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=D9dEb9k1FptsIwNSY95Y MtAECkw=; b=mMUoKicJXLlbB1POyUORUbiMSHwfbLNKrT8wUXBijJTe/5KksD9W 61wSQAcUzuk4R0fMHRqEj95JFprackTX4cXRgHusVXwFjRHDEwjqatKzqbpTyUEE 7ULTqqE1E8/K4eH6TryqeDLAZ+X1p0Izcp1PVcQXryTL7pnq3Cp6H4Q=
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id AD60336006D for ; Mon, 14 Nov 2011 20:26:32 -0800 (PST)
Received: by vws5 with SMTP id 5so6979857vws.31 for ; Mon, 14 Nov 2011 20:26:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.65.176 with SMTP id y16mr40259102vds.53.1321331192126; Mon, 14 Nov 2011 20:26:32 -0800 (PST)
Received: by 10.220.98.6 with HTTP; Mon, 14 Nov 2011 20:26:32 -0800 (PST)
In-Reply-To: <4EC1E70A.7030909@stpeter.im>
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp> <4EC1CAC9.7000301@isode.com>   <4EC1E70A.7030909@stpeter.im>
Date: Mon, 14 Nov 2011 22:26:32 -0600
Message-ID: 
From: Nico Williams 
To: Peter Saint-Andre 
Content-Type: text/plain; charset=UTF-8
Cc: Roy Fielding , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 04:26:33 -0000

On Mon, Nov 14, 2011 at 10:14 PM, Peter Saint-Andre  wrote:
> On 11/15/11 11:00 AM, Nico Williams wrote:
>> But I think it's better to just not have to have an owner, nor any
>> change control -- it's easier and cheaper that way, particularly if it
>> is true that collisions in this namespace are of little consequence.
>
> I think I might buy into that. So the change controller and owner is IANA,
> right? Do we expect that IANA would keep track of who has asked it to
> register or modify any given entry?

Each entry could be immutable, in which case changes would be in the
form of new entries, and entries would include the name (e-mail
address) of the registrant and various details not just pertaining to
the registration but also to its relation to the others that already
exist.  Sort of like version control; changes -> versions, collisions
-> branches.

From marc.blanchet@viagenie.ca  Mon Nov 14 20:27:05 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE3A1F0D5C for ; Mon, 14 Nov 2011 20:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.45
X-Spam-Level: 
X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 01YGsr9m07Ly for ; Mon, 14 Nov 2011 20:27:05 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 44B581F0CFA for ; Mon, 14 Nov 2011 20:27:05 -0800 (PST)
Received: from [IPv6:2001:df8::80:5c24:2c3a:5b4b:3fba] (unknown [IPv6:2001:df8:0:80:5c24:2c3a:5b4b:3fba]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E98EB20CC2; Mon, 14 Nov 2011 23:26:33 -0500 (EST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Marc Blanchet 
Date: Tue, 15 Nov 2011 12:26:31 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <2165AF3C-4D1E-4B9E-8B2A-0FC93E1E4766@viagenie.ca>
References: <20111115041829.5614.17081.idtracker@ietfa.amsl.com>
To: RjS@nostrum.com
X-Mailer: Apple Mail (2.1251.1)
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Fwd: I-D Action: draft-sparks-genarea-mailarch-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 04:27:05 -0000

- great doing this. completly agree. please!
- I would really like to add anonymous IMAP capabilities: Cyrus Daboo =
while having his own company selling a mail client (Mulberry) set up =
email mailing list available via IMAP anonymous. That was great to use, =
and then all the search capabilities are within the IMAP client.
- cc: apps area for the above IMAP suggestion.

Marc.

D=E9but du message r=E9exp=E9di=E9 :

> De : internet-drafts@ietf.org
> Objet : I-D Action: draft-sparks-genarea-mailarch-00.txt
> Date : 15 novembre 2011 12:18:29 UTC+08:00
> =C0 : i-d-announce@ietf.org
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
> 	Title           : IETF Email List Archiving and Search Tool =
Requirements
> 	Author(s)       : Robert Sparks
> 	Filename        : draft-sparks-genarea-mailarch-00.txt
> 	Pages           : 7
> 	Date            : 2011-11-14
>=20
>   The IETF makes heavy use of email lists to conduct its work.
>   Participants frequently need to search and browse the archives of
>   these lists, and have asked for improved search capabilities.  The
>   current archive mechanism could also be made more efficient.  This
>   memo captures the requirements for improved email list archiving and
>   searching systems.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-sparks-genarea-mailarch-00.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-sparks-genarea-mailarch-00.txt
> _______________________________________________
> 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


From ned.freed@mrochek.com  Mon Nov 14 20:38:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E591F0DA9 for ; Mon, 14 Nov 2011 20:38:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.429
X-Spam-Level: 
X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 bNGkYSkmQH+e for ; Mon, 14 Nov 2011 20:38:38 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 085501F0DB0 for ; Mon, 14 Nov 2011 20:38:38 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8F9FSZFV4016US7@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 20:38:32 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 20:38:27 -0800 (PST)
Message-id: <01O8F9FQDXQ400RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 20:35:48 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 15 Nov 2011 10:43:51 +0900" <4EC1C3D7.7070402@it.aoyama.ac.jp>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp>
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Cc: Roy Fielding , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations (was: Re: A modest proposal for MIME types (and URI	schemes))
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 04:38:38 -0000

> Hello Ned, others,

> On 2011/11/15 4:33, Ned Freed wrote:

> >> > ENCOURAGE the public to register any names that they have seen in
> >> > deployed software. (same for URI schemes)
> >
> >> I think third-party registration is indeed something we should encourage
> >> more.
> >
> > How do you propose we do that?

> It seems that currently, people don't even know that it is possible. So
> the first step is to make this more known. On another list, you write:
> "We have always allowed registrations by any interested party." That's
> apparently true, but is it done because nowhere in RFC 4288 it says it's
> not possible? Then making it explicit in draft-freed-media-type-regs
> should help.

Seems like a good idea to me. I'll see what I can come up with. Unfortunately
we're in draft-blackout so I can't post a revision.

> For example, you could put in a section 4.12, (Non-)Requirements for
> Contact Information, Author, and Change Controller, saying explicitly
> that third-party registrations are welcome.

OK.

> This could also explain what in such a case contact information, author,
> and change controller should be. I'd assume that contact information
> goes to the submitter, but change controller stays with the company or
> individual that created the format, but you'll know better what's
> current practice. If I did a third-party registration, this would be the
> place where I'd really not know which way to go.

That's nominally how it works, but I'm not strongly wedded to it as an
approach.

> You can also add pointers to that new section, or just mention the fact,
> in other places where somebody might potentially look. As an example, in
> http://tools.ietf.org/html/draft-freed-media-type-regs-01#section-5.5,
> you could say that in addition to providing comments, new registrations
> and change requests by third parties are also possible.

OK.

> The next step would then be to put text saying "Media Types may also be
> registered by third parties." or so on the relevant pages at IANA (e.g.
> http://www.iana.org/cgi-bin/mediatypes.pl and
> http://www.iana.org/assignments/media-types/index.html).

Realistically, that's the place where it is likely to do the most good.

				Ned

From stpeter@stpeter.im  Mon Nov 14 20:41:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DD211E8160 for ; Mon, 14 Nov 2011 20:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.942
X-Spam-Level: 
X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=-0.343, 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 YzEKaCqEJuL8 for ; Mon, 14 Nov 2011 20:41:00 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4A28F11E80E7 for ; Mon, 14 Nov 2011 20:41:00 -0800 (PST)
Received: from dhcp-15ab.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2F70B42170; Mon, 14 Nov 2011 21:47:10 -0700 (MST)
Message-ID: <4EC1ED58.4080102@stpeter.im>
Date: Tue, 15 Nov 2011 12:40:56 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ned Freed 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp> <01O8F9FQDXQ400RCTX@mauve.mrochek.com>
In-Reply-To: <01O8F9FQDXQ400RCTX@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 04:41:00 -0000

On 11/15/11 12:35 PM, Ned Freed wrote:

> we're in draft-blackout so I can't post a revision.

The blackout is now finished. Or at least I've seen I-Ds coming out.

/psa

From ned.freed@mrochek.com  Mon Nov 14 20:48:44 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B2321F8D12 for ; Mon, 14 Nov 2011 20:48:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022,  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 zztCE1jOGEoB for ; Mon, 14 Nov 2011 20:48:44 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0720B21F8CFC for ; Mon, 14 Nov 2011 20:48:44 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8F9SD7W1S00KTFO@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 20:48:39 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 20:48:35 -0800 (PST)
Message-id: <01O8F9SALNSQ00RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 20:38:44 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 15 Nov 2011 02:08:38 +0000" <4EC1C9A6.6080201@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C9A6.6080201@isode.com>
To: Alexey Melnikov 
Cc: Ned Freed , Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 04:48:44 -0000

> Hi Ned,

> On 14/11/2011 19:33, Ned Freed wrote:
> >> > * Eliminate standards, vendor, personal trees distinction for MIME
> >> types
> >> > (For URI schemes, eliminate distinction between provisional and
> >> permanent
> >> > schemes)
> > OK, so let's see if I have this straight. There are four subprocesses
> > involved:
> > (1) Personal type registrations. Rarely used.
> > (2) Vendor type registration. Commonly and successfully used.
> > (3) Standards tree registration. Used but has issues with timely
> > processing
> >    of requests that we're supposed to be tryhing to fix.
> > (4) Third party revisions and comments process. Essentially never used.
> >
> > And the proposal is to throw out (1)-(3)
> If by "throw out (1)-(3)" you mean just have 1 type of registration,
> then yes, I think this is what Roy proposed.

No, that's not what I meant. The ad-hoc, incomplete, duplicates allowed
approach being proposed bears a strong resemblance to our current comment and
revision process (4) - you know, the one nobody has ever seen any value in
using.

> I would personally like to better understand the thinking behind having
> a separate standards tree registration. What would be disadvanteges of
> dropping (3)? What was the original purpose for having a separate
> registration from vendor types?

The original reason was that people weren't registering their types under the
standards-tree-only rules we originally set up. When we looked at the problem
we didn't see a need for there to be publicly available documentation and
change control associated with a standards body for a format to be useful.  So
we created a means by which formats used by commercial products could be
registered with comparative simplicity and ease.

And the result was people started registering stuff. Of course it wasn't as
many as we hoped, and by this point a large number of unregistered types had
gotten deployed as a result of our original choice to set the bar too high.
We're still paying for that.

				Ned

From ned.freed@mrochek.com  Mon Nov 14 20:54:56 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915931F0C5E for ; Mon, 14 Nov 2011 20:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.05
X-Spam-Level: 
X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-1.506,  BAYES_00=-2.599, FRT_ADOBE2=2.455, J_CHICKENPOX_24=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 Q-ada+x080in for ; Mon, 14 Nov 2011 20:54:56 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6EF1F0C4F for ; Mon, 14 Nov 2011 20:54:56 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8FA10MBKW018S61@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 20:54:51 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 20:54:46 -0800 (PST)
Message-id: <01O8FA0XHURA00RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 20:50:09 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 15 Nov 2011 12:14:02 +0800" <4EC1E70A.7030909@stpeter.im>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp> <4EC1CAC9.7000301@isode.com>   <4EC1E70A.7030909@stpeter.im>
To: Peter Saint-Andre 
Cc: Roy Fielding , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 04:54:56 -0000

> On 11/15/11 11:00 AM, Nico Williams wrote:
> > On Mon, Nov 14, 2011 at 8:15 PM, Larry Masinter  wrote:
> >> Who should a third-party registrar list as the "change controller" ?
> >
> > If collisions don't matter then who cares?  Just add more collisions :)
> >
> > Alternatively, how about:
> >
> >     A third party should not claim to be the owner.
> >     The third party could specify an owner, but that should be considered
> >        informative.
> >     Anyone could make a claim on a registration that has no owner already.
> >     Anyone claiming to be the owner of a registration that already has an
> >        owner would have to submit their claim to  (IESG?),
> >        with appeals going to  (IAB?).
> >
> > But I think it's better to just not have to have an owner, nor any
> > change control -- it's easier and cheaper that way, particularly if it
> > is true that collisions in this namespace are of little consequence.

> I think I might buy into that. So the change controller and owner is
> IANA, right?

No, if you're going to weaken or even eliminate the owner/change controller
concept - and I think this is an idea that's worth exploring - you need to do
that, not put IANA in the middle of the process as some sort of substitute.

> Do we expect that IANA would keep track of who has asked it
> to register or modify any given entry?

That's how it works currently. In practice I don't believe there has ever been
a problem caused by someone registering something they shouldn't have, and
there definitely have been third party registrations.

				Ned

From duerst@it.aoyama.ac.jp  Mon Nov 14 21:23:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FD311E81D0 for ; Mon, 14 Nov 2011 21:23:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.622
X-Spam-Level: 
X-Spam-Status: No, score=-99.622 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxSQAYRFJk4O for ; Mon, 14 Nov 2011 21:23:18 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id DA51611E8073 for ; Mon, 14 Nov 2011 21:23:17 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAF5NBCJ017779 for ; Tue, 15 Nov 2011 14:23:11 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2c89_0b9a_e9206334_0f49_11e1_bd48_001d096c566a; Tue, 15 Nov 2011 14:23:11 +0900
Received: from [IPv6:::1] ([133.2.210.1]:37752) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Tue, 15 Nov 2011 14:23:15 +0900
Message-ID: <4EC1F73C.4000006@it.aoyama.ac.jp>
Date: Tue, 15 Nov 2011 14:23:08 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Peter Saint-Andre 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp> <01O8F9FQDXQ400RCTX@mauve.mrochek.com> <4EC1ED58.4080102@stpeter.im>
In-Reply-To: <4EC1ED58.4080102@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Roy Fielding , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 05:23:18 -0000

On 2011/11/15 13:40, Peter Saint-Andre wrote:
> On 11/15/11 12:35 PM, Ned Freed wrote:
>
>> we're in draft-blackout so I can't post a revision.
>
> The blackout is now finished.

That's correct. It may be a secret about as well known as the fact that 
third-party media type registrations are allowed, but the blackout 
usually ends when the IETF starts. I'm not sure about the exact time, 
but it's some time Sunday or Monday, and we already have Tuesday.

This is very handy for uploading new drafts for WGs that e.g. met on 
Monday, or otherwise for people who manage to do some draft work during 
the IETF week.

Regards,    Martin.

From stpeter@stpeter.im  Mon Nov 14 22:27:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9305D1F0C5B for ; Mon, 14 Nov 2011 22:27:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.867
X-Spam-Level: 
X-Spam-Status: No, score=-102.867 tagged_above=-999 required=5 tests=[AWL=-0.268, 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 oU1uaAfd5EDW for ; Mon, 14 Nov 2011 22:27:24 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 08FA81F0D7B for ; Mon, 14 Nov 2011 22:27:24 -0800 (PST)
Received: from dhcp-15ab.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F61F4216E for ; Mon, 14 Nov 2011 23:33:35 -0700 (MST)
Message-ID: <4EC20649.6000008@stpeter.im>
Date: Tue, 15 Nov 2011 14:27:21 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] NomCom feedback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 06:27:24 -0000

Folks, I just stopped by the NomCom office during office hours and 
provided feedback and input on various nominees. Your colleagues 
currently serving on the NomCom would greatly appreciate it if you would 
do the same, either in person or at the NomCom website:

https://www.ietf.org/group/nomcom/2011/

Thanks for your consideration.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From sm@elandsys.com  Tue Nov 15 00:09:37 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9639211E8114 for ; Tue, 15 Nov 2011 00:09:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 huF+Rjn1fsdL for ; Tue, 15 Nov 2011 00:09:33 -0800 (PST)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7999F11E80E9 for ; Tue, 15 Nov 2011 00:09:33 -0800 (PST)
Received: from sm-THINK.elandsys.com (dhcp-16fb.meeting.ietf.org [130.129.22.251]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id pAF89Rrj000769; Tue, 15 Nov 2011 00:09:32 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1321344573; bh=efoOHNLu02hZv37cWsVZtB7FS6M=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=IQWY7y9hLa1usCyxDSqDH/8qvf88qnEJ8xDNx6I7vbEFrtfbdo9pkyKG631qEpiCX D5OnW2m0fHavusU1KsmFHNT+yM4ThPSOM69VSqyXng/bgtNdv55t7awTYmqJxCctMm 3cOQ73yBsDYXJfGSome2MCeKorUxgKmS4rWizu/M=
Message-Id: <6.2.5.6.2.20111114202257.08a2c6b0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 14 Nov 2011 20:46:25 -0800
To: John Levine 
From: S Moonesamy 
In-Reply-To: <20111115025746.26808.qmail@joyce.lan>
References: <6.2.5.6.2.20111114142451.09b74390@elandnews.com> <20111115025746.26808.qmail@joyce.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 08:09:37 -0000

Hi John,
At 06:57 PM 11/14/2011, John Levine wrote:
>Looks mostly reasonable.

Thanks for the feedback.

>In step (9), you say "If a transient failure condition is reported,
>try the next MX RR" which looks wrong to me.  If you get a 4xx, you
>requeue the message and try it again later.

I agree that it looks wrong.  I was going to suggest "going to Step 
7" instead of Step 3.  The problem though is that you cannot retry 
against the same IP address in all cases as you have to take into 
account the DNS TTL.  The workaround I see is:

(9)  Attempt to deliver the email over the connection established, as
      specified in RFC 5321.  If a transient failure condition is
      reported, try again as defined in RFC 5321 Section 4.5.4.1.

Regards,
S. Moonesamy 


From GK@ninebynine.org  Tue Nov 15 00:32:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3338121F8D7A for ; Tue, 15 Nov 2011 00:32:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level: 
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, 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 YcMLlC4KflXZ for ; Tue, 15 Nov 2011 00:32:02 -0800 (PST)
Received: from relay2.mail.ox.ac.uk (relay2.mail.ox.ac.uk [163.1.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9336121F8D74 for ; Tue, 15 Nov 2011 00:32:02 -0800 (PST)
Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay2.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RQEQt-00074X-6r; Tue, 15 Nov 2011 08:31:55 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQEQs-00056m-8w; Tue, 15 Nov 2011 08:31:55 +0000
Message-ID: <4EC21CCD.3040808@ninebynine.org>
Date: Tue, 15 Nov 2011 08:03:25 +0000
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Ned Freed 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp>  <01O8ETX0DJ4U00RCTX@mauve.mrochek.com>  <01O8EXP3E5XQ00RCTX@mauve.mrochek.com>
In-Reply-To: <01O8EXP3E5XQ00RCTX@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 08:32:03 -0000

On 14/11/2011 22:50, Ned Freed wrote:
> This assumes that currently there's significant cost associated with collision
> checks. I can't speak to other registries, but I can assure you the amount
> of time spent on this in the case of media types is truly negligable.

Similarly for header fields and URI schemes.

In practice, I think submitters check this in their own interest.  Completeness 
of the registry could help here.

On this point, I think it's sensible to discourage collision, but not to insist 
on uniqueness in every case.

#g
--

From GK@ninebynine.org  Tue Nov 15 00:32:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEAE21F8D74 for ; Tue, 15 Nov 2011 00:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.549
X-Spam-Level: 
X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, 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 1w6Lf6Dq5kI3 for ; Tue, 15 Nov 2011 00:32:07 -0800 (PST)
Received: from relay9.mail.ox.ac.uk (relay9.mail.ox.ac.uk [163.1.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1798021F8D96 for ; Tue, 15 Nov 2011 00:32:07 -0800 (PST)
Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay9.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RQEQw-0002jb-VZ; Tue, 15 Nov 2011 08:31:58 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQEQw-00056y-80; Tue, 15 Nov 2011 08:31:58 +0000
Message-ID: <4EC221C5.6040003@ninebynine.org>
Date: Tue, 15 Nov 2011 08:24:37 +0000
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Larry Masinter 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp>	<01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp> <4EC1CAC9.7000301@isode.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc: Ned Freed , Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 08:32:08 -0000

On 15/11/2011 02:15, Larry Masinter wrote:
> Who should a third-party registrar list as the "change controller" ?

I think the attribute "change controller" belongs to a notion of registries as 
extension-of-standards.  If we move towards registries-as-documentation then I 
think this becomes less important; maybe record "original specifier" instead. 
Or nothing at all, since this information should be available in the linked 
specification document (if there is one).

#g
--

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alexey Melnikov
> Sent: Tuesday, November 15, 2011 10:13 AM
> To: "Martin J. Dürst"
> Cc: Roy Fielding; Ned Freed; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Encouraging third party registrations
>
> Hi Martin,
>
> On 15/11/2011 01:43, "Martin J. Dürst" wrote:
>> Hello Ned, others,
>>
>> On 2011/11/15 4:33, Ned Freed wrote:
>>
>>>>> ENCOURAGE the public to register any names that they have seen in
>>>>> deployed software. (same for URI schemes)
>>>
>>>> I think third-party registration is indeed something we should
>>>> encourage more.
>>>
>>> How do you propose we do that?
>>
>> It seems that currently, people don't even know that it is possible.
>> So the first step is to make this more known. On another list, you
>> write: "We have always allowed registrations by any interested party."
>> That's apparently true, but is it done because nowhere in RFC 4288 it
>> says it's not possible? Then making it explicit in
>> draft-freed-media-type-regs should help.
> +1. To be honest I didn't know that this procedure was to be expected.
> In all cases I was expecting that some representative of the company/organization that defined the media type should be involved in a registration, even if somebody else does the work to actually document it.
>> For example, you could put in a section 4.12, (Non-)Requirements for
>> Contact Information, Author, and Change Controller, saying explicitly
>> that third-party registrations are welcome.
> Exactly.
>> This could also explain what in such a case contact information,
>> author, and change controller should be. I'd assume that contact
>> information goes to the submitter, but change controller stays with
>> the company or individual that created the format, but you'll know
>> better what's current practice. If I did a third-party registration,
>> this would be the place where I'd really not know which way to go.
>>
>> You can also add pointers to that new section, or just mention the
>> fact, in other places where somebody might potentially look. As an
>> example, in
>> http://tools.ietf.org/html/draft-freed-media-type-regs-01#section-5.5,
>> you could say that in addition to providing comments, new
>> registrations and change requests by third parties are also possible.
>>
>> The next step would then be to put text saying "Media Types may also
>> be registered by third parties." or so on the relevant pages at IANA
>> (e.g. http://www.iana.org/cgi-bin/mediatypes.pl and
>> http://www.iana.org/assignments/media-types/index.html).
>>
>>
>> Regards,   Martin.
> Best Regards,
> Alexey
>
> _______________________________________________
> 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 GK@ninebynine.org  Tue Nov 15 00:32:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C121F8D92 for ; Tue, 15 Nov 2011 00:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.412
X-Spam-Level: 
X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 4i6o80z3S3A3 for ; Tue, 15 Nov 2011 00:32:08 -0800 (PST)
Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5A27E21F8D74 for ; Tue, 15 Nov 2011 00:32:08 -0800 (PST)
Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RQEQv-0006ql-A0; Tue, 15 Nov 2011 08:31:57 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQEQu-00056s-8D; Tue, 15 Nov 2011 08:31:56 +0000
Message-ID: <4EC220C6.5060601@ninebynine.org>
Date: Tue, 15 Nov 2011 08:20:22 +0000
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp>
In-Reply-To: <4EC1C3D7.7070402@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc: Roy Fielding , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 08:32:09 -0000

On 15/11/2011 01:43, "Martin J. Dürst" wrote:
>>> > ENCOURAGE the public to register any names that they have seen in
>>> > deployed software. (same for URI schemes)
>>
>>> I think third-party registration is indeed something we should encourage
>>> more.
>>
>> How do you propose we do that?
>
> It seems that currently, people don't even know that it is possible. So the
> first step is to make this more known. On another list, you write: "We have
> always allowed registrations by any interested party." That's apparently true,
> but is it done because nowhere in RFC 4288 it says it's not possible? Then
> making it explicit in draft-freed-media-type-regs should help.

+1

I think a wiki-FAQ linked from each registry page could go a long way to help.

[[
Make registration procedures / contacts / requirements / guidelines available in 
a user-friendly format (NOT just an RFC) linked from the registry page. E.g., 
give each registry some wiki space linked from its registry page.
]]
-- http://www.w3.org/wiki/FriendlyRegistries#Clear_Process

If we want a simple enhancement to smooth the path of registration, I think this 
is something we could do now which could have a significant effect, without 
updating any RFCs, etc.  As reviewer for URIs and Header fields, I'd be happy to 
put up some initial content for those.  Maybe a common list of FAQs to get this 
started; e.g.

q. Who can register a ?

q. What are the requirements for registering a ?

q. Where should I send my request to register ?

q. What happens next?

q. Who should I contact if I'm not happy with a response to my request?

q. Who has the final say about any registration request?

q. What do I do if I think there is an error in a registration?

q. How do I update a registration?

q. [How] can I add a comment to a registration?

(I've added this suggestion to 
http://www.w3.org/wiki/FriendlyRegistries#Clear_Process)

#g

From sm@elandsys.com  Tue Nov 15 00:39:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A29321F8F77 for ; Tue, 15 Nov 2011 00:39:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.296
X-Spam-Level: 
X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 dZpXjqR8I2hZ for ; Tue, 15 Nov 2011 00:39:31 -0800 (PST)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 766C121F8DE9 for ; Tue, 15 Nov 2011 00:39:31 -0800 (PST)
Received: from sm-THINK.elandsys.com (dhcp-16fb.meeting.ietf.org [130.129.22.251]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id pAF8dLDl002905; Tue, 15 Nov 2011 00:39:25 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1321346366; bh=nNsCVuXMLEvPzRMkrJ/xS7K2QeI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=tBgguyjQX15vsAOc+OYVHmcrurFtFIsynZ93q9mjIi551yneWBxOZUsCfY4ETTCnN nNGpHckmuOhNnwa+IupIawUGC0xYxFe2LR3BsNWaaZOOyShXGDK1pjL6ujpIpXhlgY ItbYuhcWOEpMZZQAjaCA9U35KNzyxi6j+30LPPjQ=
Message-Id: <6.2.5.6.2.20111115001537.08fdc6f8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 15 Nov 2011 00:38:49 -0800
To: "Murray S. Kucherawy" 
From: S Moonesamy 
In-Reply-To: 
References: <6.2.5.6.2.20111114142451.09b74390@elandnews.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ietf-smtp@imc.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 08:39:35 -0000

Hi Murray,
At 07:04 PM 11/14/2011, Murray S. Kucherawy wrote:
>Why were these removed?  They seemed useful for illustration in RFC3974.

RFC 3974 has an IESG Note about a specific interpretation of the 
applicability of the MX processing algorithm in RFC 2821.  You may 
have noticed that MX processing and sending strategy are kept 
separate in RFC 5321.  The illustration is based on a specific 
reading/interpretation of the SMTP specification and that can open 
the way for ancillary problems, e.g. less leeway for operational 
considerations.

>Replacing this with more current operational experience might be 
>better than removing it outright.

I'll leave this comment open.

>Also, I wonder if the v6ops "Happy Eyeballs" work might be an 
>interesting reference here.

SMTP is not affected by the happy eyeball problem.  Getting this 
message to you 50 ms earlier would not make that much of a difference.

>RFC5321 talked about aspects of RFC3974 that were in conflict with 
>what RFC5321 says.  Have those been resolved in your draft?  (Alas, 
>I can't tell after a cursory read what those might've been.  Maybe 
>it's simply the thing John Levine just pointed out in another message.)

John Levine pointed out one of the issues.  A clear resolution of all 
the aspects would require removal of the algorithm.  The path I 
picked is to try to align the algorithm with RFC 5321.

>It's worth pointing out the document state change as well (which I support).

Ok.

Regards,
S. Moonesamy 


From ietfc@btconnect.com  Tue Nov 15 02:13:44 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A0C11E81F9 for ; Tue, 15 Nov 2011 02:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.281
X-Spam-Level: 
X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_00=-2.599, FRT_ADOBE2=2.455]
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 UiaMy-zMzKQA for ; Tue, 15 Nov 2011 02:13:43 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3B05011E81B0 for ; Tue, 15 Nov 2011 02:13:42 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2bthomr07.btconnect.com with SMTP id FHQ86187; Tue, 15 Nov 2011 10:13:35 +0000 (GMT)
Message-ID: <001301cca376$15d43940$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Larry Masinter" , 
References: 
Date: Tue, 15 Nov 2011 10:07:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4EC23B4D.0078, actions=TAG
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.15.91515:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4EC23B4F.023B,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine
X-Junkmail-IWF: false
Cc: Roy Fielding 
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 10:13:44 -0000

I would suggest reading
http://www.ietf.org/mail-archive/web/ietf/current/msg68153.html
and then changing the subject line.

Tom Petch


----- Original Message -----
From: "Larry Masinter" 
To: 
Cc: "Roy Fielding" 
Sent: Sunday, November 13, 2011 7:59 PM
Subject: [apps-discuss] A modest proposal for MIME types (and URI schemes)


> I'd like to discuss the proposal for MIME registrations from Roy Fielding in
http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html
> and the possibility that such changes should also apply to URI schemes.
>
> You can read Roy's rationale, which makes sense to me, but my summary is:
>
> * Eliminate standards, vendor, personal trees distinction for MIME types (For
URI schemes, eliminate distinction between provisional and permanent schemes)
> * ENCOURAGE vendors to ship with vendor-neutral short-named types regardless
of whether they have been registered yet or not;
>    ENCOURAGE the public to register any names that they have seen in deployed
software. (same for URI schemes)
> * DO NOT try to avoid duplicates
> * EXPERT REVIEW for updates to existing registrations
> * Eliminate any IESG or consensus review requirement
>
> "There is absolutely no need to prevent name collisions in the registry itself
because those collisions are irrelevant -- what matters is how the names are
interpreted by recipients of messages."
> "There is absolutely no need to prevent people who are not the owners of a
media type from registering that type without any prefixes."
> "The registry is not operable -- it is just documentation of how the Internet
is operating, and it should reflect the reality of that operation even if that
means we have multiple definitions per registered type."
>
> I find this perspective appealing, and can't find anything wrong with it
except that it's a break with tradition. If you're at IETF this week and want to
talk about it, find me.
>
> Larry
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>


From ietfc@btconnect.com  Tue Nov 15 02:27:50 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F9911E8242 for ; Tue, 15 Nov 2011 02:27:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3]
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 J8mc2SJMtKsa for ; Tue, 15 Nov 2011 02:27:49 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id B166811E8202 for ; Tue, 15 Nov 2011 02:27:47 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2bthomr09.btconnect.com with SMTP id FFT87624; Tue, 15 Nov 2011 10:27:29 +0000 (GMT)
Message-ID: <00ac01cca378$0680a940$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "=?UTF-8?Q?Martin_J._D=C3=BCrst?=" 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com> <60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net> <4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net> <4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net> <00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net>  <02de01cc9fca$f7c08020$4001a8c0@gateway.2wire.net> <4EBCD919.9050600@it.aoyama.ac.jp>
Date: Tue, 15 Nov 2011 10:18:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4EC23E8D.0151, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.15.81515:17:7.944, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __STOCK_PHRASE_7, __INT_PROD_LOC, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS
X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4EC23E94.021E,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 10:27:50 -0000

----- Original Message -----
From: "Martin J. Dürst" 
To: "t.petch" 
Cc: "Frank Ellermann" ;
; 
Sent: Friday, November 11, 2011 9:13 AM
> On 2011/11/11 2:05, t.petch wrote:
>
> > What I see at present is that when I access certain web sites, I get a
message
> > saying the my machine has not got the fonts installed to view the web site
> > properly and would I like the web site to instal some more for me.  NO WAY.
I
> > decide what and when I instal on my machine from where.  But I am curious,
and
> > might try it when I have machine ready to be trashed, as to just how it
would do
> > it.  I am assuming it would try to instal a .ttf file in  a suitable
directory
> > (which I would expect to fail unless it is a temporary file).
> >
> > I did ask the maintainers of the web site what was going on, and they had
not a
> > clue.  My guess would be something Chinese or Korean (although the web site
is
> > not).
>
> To look at this case, it would help if you would tell us what your
> browser was, and what websites they were.

Indeed, I intend to do so, but the most recent example, when accessing
https://catalogue.library.manchester.ac.uk/login?message=borrowerservices_notlog
gedin&referer=https%3A%2F%2Fcatalogue.library.manchester.ac.uk%2Faccount
only occurs once I have entered my userid and password, and you
may not be surprised to learn that I do not intend to disclose that
information by e-mail.

My memory is that I have seen it on other pages on that host and will
continue to look for one and post it as and when I find it.

My browser is Internet Explorer 6.0 but I suspect that it is the Fonts
directory in Windows that is lacking either a 'font' or more likely, some
code points in a font (I do get displays of Russian and CJK characters
which I did not on older software).  One thing I link to this is the
display I get on the Subject: line of some e-mails, on lists such as
MPLS-TP, from users with a Chinese affiliation, where the line
displays with many underscores, whereas at an Internet cafe,
looking at the archives, as one does, I get CJK characters instead,
probably a language variant of 'Re: '.
My MUA does not generate messages about wanting to download
'fonts'.

Tom Petch

> Regards,   Martin.
>
>


From fanf2@hermes.cam.ac.uk  Tue Nov 15 02:59:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E62121F8EDC for ; Tue, 15 Nov 2011 02:59:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5HZYW1Ax1Qa for ; Tue, 15 Nov 2011 02:59:15 -0800 (PST)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id F084921F8EDF for ; Tue, 15 Nov 2011 02:59:14 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36192) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1RQGjP-0005V6-sV (Exim 4.72) (return-path ); Tue, 15 Nov 2011 10:59:11 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RQGjP-0001M9-SG (Exim 4.67) (return-path ); Tue, 15 Nov 2011 10:59:11 +0000
Date: Tue, 15 Nov 2011 10:59:11 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: John Levine 
In-Reply-To: <20111115025746.26808.qmail@joyce.lan>
Message-ID: 
References: <20111115025746.26808.qmail@joyce.lan>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: sm+ietf@elandsys.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 10:59:16 -0000

John Levine  wrote:
>
> In step (9), you say "If a transient failure condition is reported,
> try the next MX RR" which looks wrong to me.  If you get a 4xx, you
> requeue the message and try it again later.

This is a point of repeated disagreement and there is no accepted
consensus. When they get a 4yz, some SMTP implementations will immediately
re-try delivery on the other hosts, and only queue the message for later
delivery if none of the hosts will take the message.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Shannon: Southeasterly 5 to 7, veering southwesterly 4 or 5 in west. Moderate
or rough. Rain or showers. Moderate or poor, occasionally good later.

From fanf2@hermes.cam.ac.uk  Tue Nov 15 03:12:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348881F0C4C for ; Tue, 15 Nov 2011 03:12:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+YtJyTZYhA9 for ; Tue, 15 Nov 2011 03:12:12 -0800 (PST)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 769B321F8F18 for ; Tue, 15 Nov 2011 03:12:12 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49696) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1RQGvz-0006YQ-s9 (Exim 4.72) (return-path ); Tue, 15 Nov 2011 11:12:11 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RQGvz-0003dW-OI (Exim 4.67) (return-path ); Tue, 15 Nov 2011 11:12:11 +0000
Date: Tue, 15 Nov 2011 11:12:11 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: "John R. Levine" 
In-Reply-To: 
Message-ID: 
References: <20111115025746.26808.qmail@joyce.lan>  
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 11:12:13 -0000

John R. Levine  wrote:
>
> Ah, right.  Can you suggest language that means "if you get a 4yz do whatever
> you do now."

It's already specified in RFC 5321:

   Although the capability to try multiple alternative addresses is
   required, specific installations may want to limit or disable the use
   of alternative addresses.  The question of whether a sender should
   attempt retries using the different addresses of a multihomed host
   has been controversial.  The main argument for using the multiple
   addresses is that it maximizes the probability of timely delivery,
   and indeed sometimes the probability of any delivery; the counter-
   argument is that it may result in unnecessary resource use.  Note
   that resource use is also strongly determined by the sending strategy
   discussed in Section 4.5.4.1.

I'm not sure what SM's draft is for, since RFC 3974 is obsoleted by RFC 5321
(even though the RFC index fails to say so).

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Trafalgar: Westerly or northwesterly 4 or 5, occasionally 6 in north at first,
becoming variable 3 later. Rough, occasionally moderate later. Thundery
showers. Moderate or good, occasionally poor.

From duerst@it.aoyama.ac.jp  Tue Nov 15 03:14:37 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2226A21F8F2D for ; Tue, 15 Nov 2011 03:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.628
X-Spam-Level: 
X-Spam-Status: No, score=-99.628 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSUptK76XVVz for ; Tue, 15 Nov 2011 03:14:36 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 71E8A21F8F27 for ; Tue, 15 Nov 2011 03:14:36 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAFBEWUv000970 for ; Tue, 15 Nov 2011 20:14:32 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2c8e_27b1_fe89a9fc_0f7a_11e1_bd48_001d096c566a; Tue, 15 Nov 2011 20:14:32 +0900
Received: from [IPv6:::1] ([133.2.210.1]:58652) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Tue, 15 Nov 2011 20:14:37 +0900
Message-ID: <4EC24995.8030102@it.aoyama.ac.jp>
Date: Tue, 15 Nov 2011 20:14:29 +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: Graham Klyne 
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp> <4EC220C6.5060601@ninebynine.org>
In-Reply-To: <4EC220C6.5060601@ninebynine.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Roy Fielding , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 11:14:37 -0000

Graham - Very good idea!   Regards,   Martin.

On 2011/11/15 17:20, Graham Klyne wrote:

> I think a wiki-FAQ linked from each registry page could go a long way to
> help.
>
> [[
> Make registration procedures / contacts / requirements / guidelines
> available in a user-friendly format (NOT just an RFC) linked from the
> registry page. E.g., give each registry some wiki space linked from its
> registry page.
> ]]
> -- http://www.w3.org/wiki/FriendlyRegistries#Clear_Process
>
> If we want a simple enhancement to smooth the path of registration, I
> think this is something we could do now which could have a significant
> effect, without updating any RFCs, etc. As reviewer for URIs and Header
> fields, I'd be happy to put up some initial content for those. Maybe a
> common list of FAQs to get this started; e.g.
>
> q. Who can register a ?
>
> q. What are the requirements for registering a ?
>
> q. Where should I send my request to register ?
>
> q. What happens next?
>
> q. Who should I contact if I'm not happy with a response to my request?
>
> q. Who has the final say about any registration request?
>
> q. What do I do if I think there is an error in a registration?
>
> q. How do I update a registration?
>
> q. [How] can I add a comment to a registration?
>
> (I've added this suggestion to
> http://www.w3.org/wiki/FriendlyRegistries#Clear_Process)
>
> #g
>

From cyrus@daboo.name  Tue Nov 15 07:17:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD15021F8B4C for ; Tue, 15 Nov 2011 07:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.716
X-Spam-Level: 
X-Spam-Status: No, score=-103.716 tagged_above=-999 required=5 tests=[AWL=-1.117, 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 bq9eCPUNiN+F for ; Tue, 15 Nov 2011 07:17:32 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 42BE921F8B35 for ; Tue, 15 Nov 2011 07:17:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B0D971CE6FB5; Tue, 15 Nov 2011 10:17:22 -0500 (EST)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTywvf7GCE-s; Tue, 15 Nov 2011 10:17:16 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 9ECFA1CE6FA6; Tue, 15 Nov 2011 10:17:15 -0500 (EST)
Date: Tue, 15 Nov 2011 10:17:12 -0500
From: Cyrus Daboo 
To: Marc Blanchet , RjS@nostrum.com
Message-ID: 
In-Reply-To: <2165AF3C-4D1E-4B9E-8B2A-0FC93E1E4766@viagenie.ca>
References: <20111115041829.5614.17081.idtracker@ietfa.amsl.com> <2165AF3C-4D1E-4B9E-8B2A-0FC93E1E4766@viagenie.ca>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1235
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-sparks-genarea-mailarch-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 15:17:32 -0000

Hi,

--On November 15, 2011 12:26:31 PM +0800 Marc Blanchet 
 wrote:

> - great doing this. completly agree. please!
> - I would really like to add anonymous IMAP capabilities: Cyrus Daboo
> while having his own company selling a mail client (Mulberry) set up
> email mailing list available via IMAP anonymous. That was great to use,
> and then all the search capabilities are within the IMAP client. - cc:
> apps area for the above IMAP suggestion.

Yes a public IMAP server with mailboxes for each mailing list would be a 
fine option. In fact, I still read several IETF mailing lists that way. In 
addition to the benefits Marc cites, the other major benefit is that it is 
trivial to reply to mailing list messages because you are already in your 
email client.

One downside of an anonymous service would be the lack of of per-user seen 
state. It would be much more convenient if users had accounts on the IMAP 
server just for reading the public archives - that way each user would have 
their own seen flag status on the email messages, making it easier to keep 
track of what has been read. I would guess that hooking into the existing 
IETF accounts infrastructure would be ideal.

-- 
Cyrus Daboo


From nsb@guppylake.com  Tue Nov 15 07:52:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925CA11E809D for ; Tue, 15 Nov 2011 07:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 uiTTSrEiBLvu for ; Tue, 15 Nov 2011 07:52:35 -0800 (PST)
Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 6409211E8099 for ; Tue, 15 Nov 2011 07:52:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=BWhwOYR4BOAKW574uww0rM5Ahj5jyg6HagGBKXGrwZA5Fvg8qzja3Qmtp4xttSwJru6UJdRWLLjNs+c1Yl6ikGc5+UgQQ+sY4l+mXe4doUmz3FwjRiSIhPgNt2Bms/UU;
Received: from [108.98.149.133] (helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1RQLJE-00058c-P7; Tue, 15 Nov 2011 10:52:29 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-1032--532239389
From: Nathaniel Borenstein 
In-Reply-To: <4EC1BD19.6050407@it.aoyama.ac.jp>
Date: Tue, 15 Nov 2011 10:52:24 -0500
Message-Id: <23361539-218D-44C3-9F35-63B86C25730D@guppylake.com>
References:  <3C5268E5-FE9E-4148-8955-0450304BB407@apple.com> <4EC1BD19.6050407@it.aoyama.ac.jp>
To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= 
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server1.netnutz.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - guppylake.com
Cc: David Singer , "apps-discuss@ietf.org" , "gadams@xfsi.com" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 15:52:39 -0000

--Apple-Mail-1032--532239389
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On Nov 14, 2011, at 8:15 PM, Martin J. D=FCrst wrote:

> I very much think that having a  font/ top level type is actually a =
good idea. But I hinted at this before: a type shouldn't be treated as =
"more safe" just because it says font/, rather than application/. Many =
font formats contain active code that is executed by the font engine.

Not more safe, but possibly more cost-effective to screen.  If something =
is labeled as a font, you might be able to reject all non-font content =
much faster than you can reject application/octet-stream.   (Obviously =
you'd still have to look through any active code in the stuff that is =
accepted.)  -- Nathaniel=

--Apple-Mail-1032--532239389
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


I very much =
think that having a  font/ top level type is actually a good idea. =
But I hinted at this before: a type shouldn't be treated as "more safe" =
just because it says font/, rather than application/. Many font formats =
contain active code that is executed by the font =
engine.

Not more safe, but possibly =
more cost-effective to screen.  If something is labeled as a font, =
you might be able to reject all non-font content much faster than you =
can reject application/octet-stream.   (Obviously you'd still have =
to look through any active code in the stuff that is accepted.)  -- =
Nathaniel
=

--Apple-Mail-1032--532239389--

From ned.freed@mrochek.com  Tue Nov 15 08:31:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC44521F8B5A for ; Tue, 15 Nov 2011 08:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level: 
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051,  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 tlMmgphOw6Kj for ; Tue, 15 Nov 2011 08:31:24 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0156F21F8B58 for ; Tue, 15 Nov 2011 08:31:24 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8FYC4JVSW014KM7@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 15 Nov 2011 08:30:59 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Tue, 15 Nov 2011 08:30:58 -0800 (PST)
Message-id: <01O8FYC3HF5M00RCTX@mauve.mrochek.com>
Date: Tue, 15 Nov 2011 08:30:18 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 15 Nov 2011 10:17:12 -0500" 
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <20111115041829.5614.17081.idtracker@ietfa.amsl.com> <2165AF3C-4D1E-4B9E-8B2A-0FC93E1E4766@viagenie.ca> 
To: Cyrus Daboo 
Cc: apps-discuss@ietf.org, RjS@nostrum.com
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-sparks-genarea-mailarch-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 16:31:29 -0000

+1 on all of Cyrus' points here.

				Ned

> Hi,

> --On November 15, 2011 12:26:31 PM +0800 Marc Blanchet
>  wrote:

> > - great doing this. completly agree. please!
> > - I would really like to add anonymous IMAP capabilities: Cyrus Daboo
> > while having his own company selling a mail client (Mulberry) set up
> > email mailing list available via IMAP anonymous. That was great to use,
> > and then all the search capabilities are within the IMAP client. - cc:
> > apps area for the above IMAP suggestion.

> Yes a public IMAP server with mailboxes for each mailing list would be a
> fine option. In fact, I still read several IETF mailing lists that way. In
> addition to the benefits Marc cites, the other major benefit is that it is
> trivial to reply to mailing list messages because you are already in your
> email client.

> One downside of an anonymous service would be the lack of of per-user seen
> state. It would be much more convenient if users had accounts on the IMAP
> server just for reading the public archives - that way each user would have
> their own seen flag status on the email messages, making it easier to keep
> track of what has been read. I would guess that hooking into the existing
> IETF accounts infrastructure would be ideal.

> --
> Cyrus Daboo

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

From ned.freed@mrochek.com  Tue Nov 15 08:38:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E311F0C5B for ; Tue, 15 Nov 2011 08:38:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050,  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 sq6d7IaxxFGV for ; Tue, 15 Nov 2011 08:38:23 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE731F0C5A for ; Tue, 15 Nov 2011 08:38:22 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8FYL5CNWG00Z7UX@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 15 Nov 2011 08:38:16 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Tue, 15 Nov 2011 08:38:14 -0800 (PST)
Message-id: <01O8FYL3XLFO00RCTX@mauve.mrochek.com>
Date: Tue, 15 Nov 2011 08:33:30 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 15 Nov 2011 08:20:22 +0000" <4EC220C6.5060601@ninebynine.org>
References:  <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C3D7.7070402@it.aoyama.ac.jp> <4EC220C6.5060601@ninebynine.org>
To: Graham Klyne 
Cc: Ned Freed , Roy Fielding , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Encouraging third party registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 16:38:24 -0000

> On 15/11/2011 01:43, "Martin J. Dürst" wrote:
> >>> > ENCOURAGE the public to register any names that they have seen in
> >>> > deployed software. (same for URI schemes)
> >>
> >>> I think third-party registration is indeed something we should encourage
> >>> more.
> >>
> >> How do you propose we do that?
> >
> > It seems that currently, people don't even know that it is possible. So the
> > first step is to make this more known. On another list, you write: "We have
> > always allowed registrations by any interested party." That's apparently true,
> > but is it done because nowhere in RFC 4288 it says it's not possible? Then
> > making it explicit in draft-freed-media-type-regs should help.

> +1

> I think a wiki-FAQ linked from each registry page could go a long way to
> help.

Very good idea.

> [[
> Make registration procedures / contacts / requirements / guidelines available in
> a user-friendly format (NOT just an RFC) linked from the registry page. E.g.,
> give each registry some wiki space linked from its registry page.
> ]]
> -- http://www.w3.org/wiki/FriendlyRegistries#Clear_Process

> If we want a simple enhancement to smooth the path of registration, I think this
> is something we could do now which could have a significant effect, without
> updating any RFCs, etc.  As reviewer for URIs and Header fields, I'd be happy to
> put up some initial content for those.  Maybe a common list of FAQs to get this
> started; e.g.

> q. Who can register a ?

> q. What are the requirements for registering a ?

> q. Where should I send my request to register ?

> q. What happens next?

> q. Who should I contact if I'm not happy with a response to my request?

> q. Who has the final say about any registration request?

> q. What do I do if I think there is an error in a registration?

> q. How do I update a registration?

> q. [How] can I add a comment to a registration?

> (I've added this suggestion to
> http://www.w3.org/wiki/FriendlyRegistries#Clear_Process)

Great list.

One of the problems with the material in the RFC is that while the overall
process is fairly complex, the process for any given case is not. But you still
have to get past all the other cases to understand yours.

It would help a lot if these links can be made as context-sensitive as
possible, especially if we end up folding standards tree registrations into
the same form.

				Ned

From ned.freed@mrochek.com  Tue Nov 15 09:43:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4BE21F86A0 for ; Tue, 15 Nov 2011 09:43:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049,  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 XVagMC8ynj+H for ; Tue, 15 Nov 2011 09:43:13 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B003B21F869E for ; Tue, 15 Nov 2011 09:43:12 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8G0UKPQRK015A4Y@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 15 Nov 2011 09:43:08 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Tue, 15 Nov 2011 09:43:06 -0800 (PST)
Message-id: <01O8G0UJD0VS00RCTX@mauve.mrochek.com>
Date: Tue, 15 Nov 2011 09:40:25 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 15 Nov 2011 10:59:11 +0000" 
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20111115025746.26808.qmail@joyce.lan> 
To: Tony Finch 
Cc: sm+ietf@elandsys.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 17:43:13 -0000

> John Levine  wrote:
> >
> > In step (9), you say "If a transient failure condition is reported,
> > try the next MX RR" which looks wrong to me.  If you get a 4xx, you
> > requeue the message and try it again later.

> This is a point of repeated disagreement and there is no accepted
> consensus. When they get a 4yz, some SMTP implementations will immediately
> re-try delivery on the other hosts, and only queue the message for later
> delivery if none of the hosts will take the message.

The point in the dialogue at which the 4yz is returned can also be a factor.
It's one thing to retry on a different A after getting a 4yz host temporarily
unavailable response to EHLO; it's rather different to retry a different A
after getting a 4yz user is over quota response to the final dot.

				Ned

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Tue Nov 15 11:20:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91ED611E8081 for ; Tue, 15 Nov 2011 11:20:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.907
X-Spam-Level: 
X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 irtxTzt-Y1BP for ; Tue, 15 Nov 2011 11:20:32 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E07DC11E8073 for ; Tue, 15 Nov 2011 11:20:31 -0800 (PST)
Received: by wwe5 with SMTP id 5so4784705wwe.13 for ; Tue, 15 Nov 2011 11:20:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yK1rjr/uVi7Nuw5FZcW2r/XjGJDohS/yR+1BH+xvLmw=; b=nJw9fiXgZZG1jok8OQ/KeCucAWVbPKgrQyal6d9f/d8hlXR4jcaT7FINW6YjtcbXIZ nJnhq9Rx2arHTlHwyQJG6FKYA4yJ68+KOc9RbO78ZN9sfVbFZ6ya62BUD5GRzJZIB9k9 jnxOl/pZTraVFQ9x/AIPXoJ62xMlRG/UE80FE=
Received: by 10.216.230.90 with SMTP id i68mr568474weq.73.1321384831092; Tue, 15 Nov 2011 11:20:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.184.147 with HTTP; Tue, 15 Nov 2011 11:19:50 -0800 (PST)
In-Reply-To: 
References: <20111115025746.26808.qmail@joyce.lan>   
From: Frank Ellermann 
Date: Tue, 15 Nov 2011 20:19:50 +0100
Message-ID: 
To: Tony Finch 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "John R. Levine" , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 19:20:32 -0000

On 15 November 2011 12:12, Tony Finch wrote:

> RFC 3974 is obsoleted by RFC 5321 (even though the RFC index fails
> to say so).

The first page of RFC 5321 doesn't confirm that theory, there is no
"obsoletes 3974".  Maybe 5321bis could state this explicitly.

It would be nice to have both, an official STD 10 fresher than 821,
and an informational companion obsoleting 3974 with the dual stack
example.

-Frank

"In any case, the SMTP adds its own identifier to the reverse-path"

From fanf2@hermes.cam.ac.uk  Tue Nov 15 11:25:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265B411E809C for ; Tue, 15 Nov 2011 11:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CcOumjx0CGn for ; Tue, 15 Nov 2011 11:25:34 -0800 (PST)
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 178DD11E8090 for ; Tue, 15 Nov 2011 11:25:33 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56679) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1RQOdQ-0001ii-Fh (Exim 4.72) (return-path ); Tue, 15 Nov 2011 19:25:32 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RQOdQ-0005Dg-R9 (Exim 4.67) (return-path ); Tue, 15 Nov 2011 19:25:32 +0000
Date: Tue, 15 Nov 2011 19:25:32 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Frank Ellermann 
In-Reply-To: 
Message-ID: 
References: <20111115025746.26808.qmail@joyce.lan>    
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 19:25:38 -0000

Frank Ellermann  wrote:
>
> It would be nice to have both, an official STD 10 fresher than 821,
> and an informational companion obsoleting 3974 with the dual stack
> example.

WRT sual stack, what is missing from section 5 of RFC 5321?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire, South Utsire, Forties, Cromarty: Southerly or
southeasterly 4 or 5, occasionally 6 in Cromarty. Slight or moderate.
Occasional drizzle. Moderate or good.

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Tue Nov 15 11:40:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E851F0C75 for ; Tue, 15 Nov 2011 11:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.91
X-Spam-Level: 
X-Spam-Status: No, score=-102.91 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 JfvX6Xj108aK for ; Tue, 15 Nov 2011 11:40:28 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D44331F0C4B for ; Tue, 15 Nov 2011 11:40:27 -0800 (PST)
Received: by wyf28 with SMTP id 28so6434794wyf.31 for ; Tue, 15 Nov 2011 11:40:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q9kyoJU+fwASg0LtfohPvnX2lJMdMn9NJLAOJpQ4yyE=; b=cqjyuKc/Xphp8SD7WBOPoQAO7qilfy2agtWxNkz6R7cFPinJ/vwW/jwnJmQ3I8Zs2L sc0XOoLw2nHrJyggzyAoApHdU7FMSwcIOJGMlCVY7UcL7Uyp0A/1DYUctU8ncRecOUWN W7ShBSGwxMzIvUUsy/Cok6XrMrjx6GT2x7xgA=
Received: by 10.216.139.83 with SMTP id b61mr5052082wej.73.1321386027057; Tue, 15 Nov 2011 11:40:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.184.147 with HTTP; Tue, 15 Nov 2011 11:39:45 -0800 (PST)
In-Reply-To: 
References: <20111115025746.26808.qmail@joyce.lan>     
From: Frank Ellermann 
Date: Tue, 15 Nov 2011 20:39:45 +0100
Message-ID: 
To: Tony Finch 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 19:40:28 -0000

On 15 November 2011 20:25, Tony Finch  wrote:

>> It would be nice to have both, an official STD 10 fresher than 821,
>> and an informational companion obsoleting 3974 with the dual stack
>> example.

> WRT sual stack, what is missing from section 5 of RFC 5321?

The simple step-by-step "how to" is missing, or rather, because 5321
is already long enough I don't miss it _in_ RFC 5321.  But I'd like
an external text with "ESMTP IPv6 considerations" not limited to the
3974 business.

-Frank

From msk@cloudmark.com  Tue Nov 15 13:28:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE7C21F85A1 for ; Tue, 15 Nov 2011 13:28:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.308
X-Spam-Level: 
X-Spam-Status: No, score=-103.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, 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 sG8qmQAEEWhU for ; Tue, 15 Nov 2011 13:28:25 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id C4F4121F858D for ; Tue, 15 Nov 2011 13:28:24 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 15 Nov 2011 13:28:21 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Tue, 15 Nov 2011 13:28:20 -0800
Thread-Topic: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
Thread-Index: AcyjvhbUOatle0zDS0qalvxhQPMb6QAHyxNA
Message-ID: 
References: <20111115025746.26808.qmail@joyce.lan>  <01O8G0UJD0VS00RCTX@mauve.mrochek.com>
In-Reply-To: <01O8G0UJD0VS00RCTX@mauve.mrochek.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 21:28:25 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Ned Freed
> Sent: Tuesday, November 15, 2011 9:40 AM
> To: Tony Finch
> Cc: sm+ietf@elandsys.com; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
>=20
> The point in the dialogue at which the 4yz is returned can also be a fact=
or.
> It's one thing to retry on a different A after getting a 4yz host
> temporarily unavailable response to EHLO; it's rather different to
> retry a different A after getting a 4yz user is over quota response to
> the final dot.

I thought the theory was that you only try different As or lower-precedence=
 MXs if you fail completely to make an SMTP connection.  That is, if you ge=
t any 4yz reply at all, you stop there and requeue; if you get any 2yz or 5=
yz reply at all, you're done.


From stpeter@stpeter.im  Tue Nov 15 13:40:27 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555CB11E80D6 for ; Tue, 15 Nov 2011 13:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.704
X-Spam-Level: 
X-Spam-Status: No, score=-101.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_061228=0.895, 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 M88R71fkDKvr for ; Tue, 15 Nov 2011 13:40:23 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC8011E80C6 for ; Tue, 15 Nov 2011 13:40:23 -0800 (PST)
Received: from squire.local (unknown [61.230.53.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C8A6E4214E; Tue, 15 Nov 2011 14:46:35 -0700 (MST)
Message-ID: <4EC2DC42.7010307@stpeter.im>
Date: Wed, 16 Nov 2011 05:40:18 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ned Freed 
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com> <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com> <4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com>
In-Reply-To: <01O8EWMK2T8E00RCTX@mauve.mrochek.com>
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] type name suffixes
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 21:40:27 -0000

On 11/15/11 6:10 AM, Ned Freed wrote:
>> On 11/12/11 4:46 AM, Ned Freed wrote:
>> >> On 2011/11/11 1:23, Ned Freed wrote:
>> >
>> >> >> On 2011/11/10 13:06, Ned Freed wrote:
>> >
>> >> >> > In practice the issue of what to register where has never been
>> much
>> >> >> of a
>> >> >> > problem. Speaking now as media types reviewer, I have not
>> >> infrequently
>> >> >> > pushed
>> >> >> > back on top-level type choices, usually successfully and always
>> >> >> amicably.
>> >> >
>> >> >> Do you know of any examples? This could help Dave with the general
>> >> list
>> >> >> of criteria that he wants to develop.
>> >> >
>> >> > I can't get into specifics without talking about the content of
>> >> > preliminary registration requests, which I try not to do. I can say
>> >> that
>> >> > the most common one has been someone asking for application when
>> >> image or
>> >> > video would be more appropriate.
>> >> >
>> >> > The most common name change I request, however, is the addition of
>> >> +xml.
>> >
>> >> Okay. This is about change from one existing top-level type to
>> another,
>> >> and about tweaking the minor type name with a suffix.
>> >
>> > Understood. Both things happen. As I said, the most common top level
>> change
>> > is from application to image or video. Next up would probably moves
>> from
>> > text to application, but come to think of it I haven't have one of
>> those
>> > in a while.
>> >
>> >> Out of the context
>> >> of the discussion, I thought that you were speaking about new
>> top-level
>> >> types when you wrote "I have not infrequently pushed back on top-level
>> >> type choices", but now I see that that's not a necessary
>> interpretation.
>> >
>> > I was simply noting that the most common change isn't a top-level
>> > change, but
>> > rather the addition of +xml. My apologies if that was confusing.
> 
>> I notice that draft-freed-media-type-regs-01 talked about structured
>> type name suffixes (e.g., "+xml") and calls for creation of a registry
>> for such suffixes. Ned, do you have thoughts on how people can more
>> easily define such suffixes, before draft-freed-media-type-regs (or
>> something like it) is approved?
> 
> Well, right now there is no process. RFC 4288 has some weasel-words about
> "using +sufffixes with care", so as reviewer that's what I do - I've
> allowed
> types with +json and +wbxml, I believe, but given the language I haven't
> felt
> comfortable asking people to add anything other than +xml to types that
> had no suffx.
> 
> I don't recall pushing back on any suffix usage, but I may have - I've
> reviewed
> a lot of types!
> 
>> The reason I ask is that I've had a few
>> people ask me about this topic recently.
> 
> Well, the preferable thing would be to get the process Tony defined that I
> included in 4288bis approved. Absent that, the rule is more or less that
> you
> can use a suffix if you like and if it seems to make sense.

Thanks for the clarification. I agree that the right place to define
this more carefully is 4288bis. In the meantime, let's say that someone
wants to register "application/foo+bar" -- do we feel that they need to
describe the "+bar" suffix in a separate specification, or can they
simply go ahead and use the suffix in the I-D that registers the "foo"
application, perhaps along with some explanatory text?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From dhc@dcrocker.net  Tue Nov 15 13:51:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE93A11E80F4 for ; Tue, 15 Nov 2011 13:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.83
X-Spam-Level: 
X-Spam-Status: No, score=-3.83 tagged_above=-999 required=5 tests=[AWL=0.208,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=1.666]
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 uCoCODtX-sUl for ; Tue, 15 Nov 2011 13:51:21 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 367FF11E80EB for ; Tue, 15 Nov 2011 13:51:21 -0800 (PST)
Received: from [192.168.0.229] (61-230-53-171.dynamic.hinet.net [61.230.53.171]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAFLpAJG005136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Nov 2011 13:51:20 -0800
Message-ID: <4EC2DEC9.4070905@dcrocker.net>
Date: Wed, 16 Nov 2011 05:51:05 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20111115025746.26808.qmail@joyce.lan>   
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 15 Nov 2011 13:51:21 -0800 (PST)
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 21:51:25 -0000

Folks,


On 11/15/2011 7:12 PM, Tony Finch wrote:
> I'm not sure what SM's draft is for, since RFC 3974 is obsoleted by RFC 5321
> (even though the RFC index fails to say so).


I would like to see some very explicit discussion and reasonably clear consensus 
that answers this question.

By explicit, I mean specification of what details need to be covered that are 
not covered by 5321 (and to help get the consensus, what details in the new 
draft are redundant with which details in 5321.)

It seems to me something close to a absolute rule that the document MUST NOT 
replicate specification already in a standards track document, but rather must 
simply cite it.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From johnl@iecc.com  Tue Nov 15 01:44:06 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710CA21F8F21 for ; Tue, 15 Nov 2011 01:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 YD8waesTNG9A for ; Tue, 15 Nov 2011 01:44:05 -0800 (PST)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BC2EF21F8F10 for ; Tue, 15 Nov 2011 01:44:05 -0800 (PST)
Received: (qmail 75173 invoked from network); 15 Nov 2011 09:44:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=125a4.4ec23464.k1111; bh=ZdnkTKh5/E6cKbfmeU4lG9GW4DbfF3Pkoa40leRA7ao=; b=f1kEbYl1WwPgOdKImQfRyDXdFAG6KO9EZsexKf133q7Rr9WdCRoAawCkOSy30fWhreAlnfyK2XdpFo2OV+bhroPyf43tmk2zYbRcYv2gQ7LS/oSOtd9kvhaoFpOr/TrymuaBoEVAauYJk0bBCelGfVHtSNttpnBQQObN0NyDecM=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Nov 2011 09:43:42 -0000
Date: 15 Nov 2011 17:44:01 +0800
Message-ID: 
From: "John R. Levine" 
To: "S Moonesamy" 
In-Reply-To: <6.2.5.6.2.20111114202257.08a2c6b0@elandnews.com>
References: <6.2.5.6.2.20111114142451.09b74390@elandnews.com> <20111115025746.26808.qmail@joyce.lan> <6.2.5.6.2.20111114202257.08a2c6b0@elandnews.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Mailman-Approved-At: Tue, 15 Nov 2011 15:23:45 -0800
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 09:44:06 -0000

> (9)  Attempt to deliver the email over the connection established, as
>     specified in RFC 5321.  If a transient failure condition is
>     reported, try again as defined in RFC 5321 Section 4.5.4.1.

That seems reasonably aligned with reality.  Different MTAs have rather 
different retry strategies, both different timeouts, and different rules 
for how they retry, e.g., retry the same target host, retry starting at 
the same MX distance, retry from scratch.  Whether some or all of the 
hosts are on IPv6 doesn't change any of that.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

From johnl@iecc.com  Tue Nov 15 03:04:37 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E215F11E8080 for ; Tue, 15 Nov 2011 03:04:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, 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 HLcRnjOx4WZ7 for ; Tue, 15 Nov 2011 03:04:32 -0800 (PST)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4672911E807F for ; Tue, 15 Nov 2011 03:04:32 -0800 (PST)
Received: (qmail 85498 invoked from network); 15 Nov 2011 11:04:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=14df8.4ec2473f.k1111; bh=2JT6FFrsQQOFY1lI1ewiPRAq0a/919OXOVQo4usTps8=; b=tXK0L/8MCnskw25qP+uk7rmY5/RwGSvlwhc5FzBZ9oY+94pg8YZuLFpNCg8J/aycT0+5T2i+zG4JYKJpj3L/l1mG8gaQZW2cYW2fundwPGuuGDN4pMGWhA/pttf7mR/I2/AjLzNaJK3QGtUUh9UXz0yGW6yntbDSwL8Paev12e8=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Nov 2011 11:04:09 -0000
Date: 15 Nov 2011 19:04:28 +0800
Message-ID: 
From: "John R. Levine" 
To: "Tony Finch" 
In-Reply-To: 
References: <20111115025746.26808.qmail@joyce.lan> 
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Mailman-Approved-At: Tue, 15 Nov 2011 15:23:45 -0800
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 11:04:38 -0000

>> In step (9), you say "If a transient failure condition is reported,
>> try the next MX RR" which looks wrong to me.  If you get a 4xx, you
>> requeue the message and try it again later.
>
> This is a point of repeated disagreement and there is no accepted
> consensus. When they get a 4yz, some SMTP implementations will immediately
> re-try delivery on the other hosts, and only queue the message for later
> delivery if none of the hosts will take the message.

Ah, right.  Can you suggest language that means "if you get a 4yz do 
whatever you do now."

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

From Vladimir.Levantovsky@MonotypeImaging.com  Tue Nov 15 15:22:15 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9354011E80B3 for ; Tue, 15 Nov 2011 15:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 KavsHFtepHMS for ; Tue, 15 Nov 2011 15:22:14 -0800 (PST)
Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by ietfa.amsl.com (Postfix) with ESMTP id 59FD311E8088 for ; Tue, 15 Nov 2011 15:22:13 -0800 (PST)
Received: from wob-email-01.agfamonotype.org ([209.113.171.111]) (using TLSv1) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKTsL0I7HnqXVXdzfpVCOJzyw44Q/gULgG@postini.com; Tue, 15 Nov 2011 15:22:14 PST
Received: from WOB-EMAIL-01.agfamonotype.org ([192.168.50.7]) by wob-email-01.agfamonotype.org ([192.168.50.7]) with mapi; Tue, 15 Nov 2011 18:22:10 -0500
From: "Levantovsky, Vladimir" 
To: David Singer , Ned Freed 
Date: Tue, 15 Nov 2011 18:22:10 -0500
Thread-Topic: [apps-discuss] font/* (and draft-freed-media-type-regs)
Thread-Index: AcyjKDWoX23OaD0kT12CW7nwptH5aQAulHRQ
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org>
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com>
In-Reply-To: <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 15 Nov 2011 15:24:31 -0800
Cc: "gadams@xfsi.com Adams" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 23:23:31 -0000

Hi all,

First of all, thank you David. This is probably one of those times when I d=
on't mind having been volunteered.

I did express a good deal of interest in the past in registering "font" as =
a new top-level type, and the preliminary exploration work done few years a=
go had shown that we would've had about two dozens of subtype entries eligi=
ble for font/* tree.

However, the sentiments expressed at the time were very similar to this dis=
cussion; I was told that applying for a new top-level type was "A BIG NO-NO=
", that prior attempts to register font/* failed, and that unless I am will=
ing to dedicate significant part of my life to this activity (i.e. applying=
 and lobbying for a new top-level "font" type) the effort would most likely=
 get us nowhere.=20

As far as "application/*" is concerned, aside from being heavily overloaded=
 with various unrelated subtypes and, therefore, utterly confusing IMHO - I=
 am not in a position to argue why font/* is better than application/* - it=
 [font/*] just makes sense. However, since font/* was (and still is) not an=
 option, there are already a number of font types registered either as vend=
or-specific or as part of the application/* tree - both "ancient" (tdpfr) a=
nd very recent (woff) come to mind.=20

In fact, SC29/WG11 is in the process of finalizing a new application (as pa=
rt of the ISO/IEC 14496-22:2009/Amd.2 work) where we decided to apply for a=
 new "application/font-sfnt" type using additional optional parameters to s=
pecify types of outlines and advanced layout mechanisms supported by a font=
. Doing so allows creating a flexible and extensible (albeit slightly cumbe=
rsome) mechanism to identify any SFNT-based font using same MIME type defin=
ition for a number of font flavors combining either TTF or CFF outlines wit=
h any currently known layout engine support (e.g. OpenType, AAT or SIL). Un=
der the circumstances, this seemed to be a pragmatic way to compensate for =
the lack of "font" type.

I am sure that having a top-level "font/*" type would have made lives easie=
r for many people, but having lived through the times where application/* w=
as the only usable option to register font types (and having few of them al=
ready defined as such) - I have even less of an incentive to argue about it=
 now. I would be happy to have font/* type defined, but I am not willing to=
 spend my (and other people) valuable time to fight for it.

Thank you,
Vladimir



> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: Monday, November 14, 2011 6:50 PM
> To: Ned Freed
> Cc: "Martin J. D=FCrst"; Larry Masinter; apps-discuss@ietf.org;
> gadams@xfsi.com Adams; Levantovsky, Vladimir
> Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
>=20
> I probably shouldn't volunteer people, but I know Vladimir Levantovsky
> has expressed interest in this question in the past.  I am sure he'd
> want to be aware of this discussion.  In fact, I am cc'ing him here..
>=20
>=20
> On Nov 14, 2011, at 13:44 , Ned Freed wrote:
>=20
> >> On 2011/11/13 5:25, Larry Masinter wrote:
> >> > I see no use case for why having font/opentype is any better than
> application/opentype
> >
> >> It's just fine if you, and some others, don't see it. Does that mean
> >> that you have to fight against it? You haven't shown, even less
> >> mentioned, any problem for font/opentype.
> >
> > Good point. I have no skin in this particular game - aside from
> slightly
> > complicating the media review process I have no personal need for
> font/*. But
> > if there's a constituency this type helps, I'm all for it.
> >
> >> My guess is that we would have around 10 or so font types registered
> >> (and no font type sniffing) if a font/ top level type had been
> approved
> >> in a 1990'ish timeframe.
> >
> > And we may or may not have any luck rectifying this at this late
> date. But I'm
> > not  seeing a reason not to try.
> >
> >> ...
> >
> >> > I also recall a number of years ago an attempt to define
> "chemical/*" as a
> >> > new top level type for use in defining file formats?
> >
> >> So what? Were there good reasons to reject it? Or was it rejected
> >> because some people believed that new top level types were "A BIG
> >> NO-NO"? Or because of some FUD?
> >
> > Didn't chemical kind of morph into model? Or am I getting the history
> confused?
> >
> >> > My conclusion from this discussion is that we should declare the
> MIME
> >> > hierarchy closed to new top level types; we've only gotten very
> limited use and
> >> > value out of the hierarchy, compared to the pain and difficulty
> (text/xml vs
> >> > application/xml).
> >
> >> The problems between text/xml and application/xml are very specific.
> And
> >> they may be interpreted to say that tying particular processing
> rules to
> >> particular types, unless absolutely necessary (e.g. structured
> types),
> >> may be a bad idea. That doesn't mean that top-level types in general
> are
> >> a bad idea.
> >
> > Agreed.
> >
> >> The reason that we have gotten very little value out of registering
> new
> >> top level types may be mostly that virtually no new types have been
> >> registered, because people are claiming that we get very little
> value
> >> out of them. It sounds funny, but it isn't.
> >
> > No, it really isn't funny, is it?
> >
> > 				Ned
>=20
> David Singer
> Multimedia and Software Standards, Apple Inc.


From ned.freed@mrochek.com  Tue Nov 15 15:26:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BE911E8101 for ; Tue, 15 Nov 2011 15:26:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048,  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 Qk0G4pQx9KgS for ; Tue, 15 Nov 2011 15:26:36 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1317411E80D4 for ; Tue, 15 Nov 2011 15:26:36 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8GCUDGXVK016P1H@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 15 Nov 2011 15:26:34 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Tue, 15 Nov 2011 15:26:32 -0800 (PST)
Message-id: <01O8GCUC3SSU00RCTX@mauve.mrochek.com>
Date: Tue, 15 Nov 2011 15:20:18 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 15 Nov 2011 13:28:20 -0800" 
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20111115025746.26808.qmail@joyce.lan>  <01O8G0UJD0VS00RCTX@mauve.mrochek.com> 
To: "Murray S. Kucherawy" 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 23:26:36 -0000

> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Ned Freed
> > Sent: Tuesday, November 15, 2011 9:40 AM
> > To: Tony Finch
> > Cc: sm+ietf@elandsys.com; apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
> >
> > The point in the dialogue at which the 4yz is returned can also be a factor.
> > It's one thing to retry on a different A after getting a 4yz host
> > temporarily unavailable response to EHLO; it's rather different to
> > retry a different A after getting a 4yz user is over quota response to
> > the final dot.

> I thought the theory was that you only try different As or lower-precedence
> MXs if you fail completely to make an SMTP connection.

That's *a* theory. It is not *the* theory. Plenty of MTAs - in fact it seems to
be a significant percentage of them - don't work this way. Some will move on to
other MXes even if the failure occurs during inside the actual transaction. (I
happen to think this last extreme is wrong, but that's *my* theory for how this
should be done; it's not prohibited by any standard I'm aware of.)

> That is, if you get any 4yz reply at all, you stop there and requeue; if you
> get any 2yz or 5yz reply at all, you're done.

I think a pretty good case can be made for trying secondary MXes when the
banner response is a 4yz.

				Ned

From barryleiba.mailing.lists@gmail.com  Tue Nov 15 15:41:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000FE11E812B for ; Tue, 15 Nov 2011 15:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.83
X-Spam-Level: 
X-Spam-Status: No, score=-102.83 tagged_above=-999 required=5 tests=[AWL=0.147, 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 JuZdlC1s7PLn for ; Tue, 15 Nov 2011 15:40:59 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8847B11E8119 for ; Tue, 15 Nov 2011 15:40:59 -0800 (PST)
Received: by ywt34 with SMTP id 34so7035407ywt.31 for ; Tue, 15 Nov 2011 15:40:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NB0T2zAXd+uTcpDN9y4ZF40fpIMcRNkOVKd/MBnWsE0=; b=VLLuurtIwR58VKwNVaE6pN3Xgu2cN8TN/Zv/pzycF8mNrza/3qo4X/iHMnAxxTKrUr YGNk8AFfSPKbpSp4/uQJKZzLDnQ5qU7gQ16IFnJ05kLyKnVtWhPWu4pImwNwVdfWCDvU GLTUllT8OxslJ8WF6rdDgHTlA0vUhY7as1qK8=
MIME-Version: 1.0
Received: by 10.147.7.10 with SMTP id k10mr1171409yai.26.1321400459145; Tue, 15 Nov 2011 15:40:59 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.250.14 with HTTP; Tue, 15 Nov 2011 15:40:59 -0800 (PST)
In-Reply-To: <01O8FYC3HF5M00RCTX@mauve.mrochek.com>
References: <20111115041829.5614.17081.idtracker@ietfa.amsl.com> <2165AF3C-4D1E-4B9E-8B2A-0FC93E1E4766@viagenie.ca>  <01O8FYC3HF5M00RCTX@mauve.mrochek.com>
Date: Tue, 15 Nov 2011 18:40:59 -0500
X-Google-Sender-Auth: uZAdipPPQmteHdvZzmbu0hlWaGA
Message-ID: 
From: Barry Leiba 
To: Ned Freed 
Content-Type: text/plain; charset=ISO-8859-1
Cc: RjS@nostrum.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-sparks-genarea-mailarch-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 23:41:00 -0000

> +1 on all of Cyrus' points here.

For me, too.  In fact, I accumulate what amounts to an IMAP-based
archive of the lists I care about.  If I had this, I could turn off
message delivery on my subscriptions, and just use the archive
instead.

Barry

From ned.freed@mrochek.com  Tue Nov 15 16:04:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A770211E814A for ; Tue, 15 Nov 2011 16:04:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047,  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 R-Ke-GdyLXeG for ; Tue, 15 Nov 2011 16:04:00 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0521F11E8119 for ; Tue, 15 Nov 2011 16:04:00 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8GE5PPLMO018591@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 15 Nov 2011 16:03:57 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Tue, 15 Nov 2011 16:03:54 -0800 (PST)
Message-id: <01O8GE5O3B5K00RCTX@mauve.mrochek.com>
Date: Tue, 15 Nov 2011 16:00:37 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Wed, 16 Nov 2011 05:40:18 +0800" <4EC2DC42.7010307@stpeter.im>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4EB86078.8070904@stpeter.im>  <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com> <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com> <4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im>
To: Peter Saint-Andre 
Cc: Ned Freed , apps-discuss@ietf.org
Subject: Re: [apps-discuss] type name suffixes
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 00:04:00 -0000

> > > The reason I ask is that I've had a few
> > > people ask me about this topic recently.

> > Well, the preferable thing would be to get the process Tony defined that I
> > included in 4288bis approved. Absent that, the rule is more or less that
> > you can use a suffix if you like and if it seems to make sense.

> Thanks for the clarification. I agree that the right place to define
> this more carefully is 4288bis.

Yes, and that text is already in 4288bis. Please have a look and see if you
think it is OK - there have been very few comments on it.

 In the meantime, let's say that someone
> wants to register "application/foo+bar" -- do we feel that they need to
> describe the "+bar" suffix in a separate specification, or can they
> simply go ahead and use the suffix in the I-D that registers the "foo"
> application, perhaps along with some explanatory text?

I'd reccomment including some explanatory text saying where the format
associated with the suffix is defined, but I see no need for a separate
specification. In fact the 4288bis approach is specifically intended to make a
separate specification unnecessary.

				Ned

From singer@apple.com  Tue Nov 15 16:20:17 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B0C21F8AE1 for ; Tue, 15 Nov 2011 16:20:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.999
X-Spam-Level: 
X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 8rk6Z+0JzXQK for ; Tue, 15 Nov 2011 16:20:17 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2E60921F8ADC for ; Tue, 15 Nov 2011 16:20:17 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LUQ00LQF8XJ24H1@mail-out.apple.com> for apps-discuss@ietf.org; Tue, 15 Nov 2011 16:20:16 -0800 (PST)
X-AuditID: 11807112-b7b05ae000001108-99-4ec301c0f71f
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by relay17.apple.com (Apple SCV relay) with SMTP id A9.83.04360.0C103CE4; Tue, 15 Nov 2011 16:20:16 -0800 (PST)
From: David Singer 
In-reply-to: <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org>
Date: Tue, 15 Nov 2011 16:20:16 -0800
Content-transfer-encoding: quoted-printable
Message-id: <96C60FA2-1722-464E-AEB0-73A79C3A25D0@apple.com>
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org>
To: "Levantovsky, Vladimir" 
X-Mailer: Apple Mail (2.1251.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUieFSBW/cA42E/gxmPZSxWv1zBZtF+9wq7 xbaDSxgt/t2ZwGyxfuU0NouNfxaxO7B5TPvZw+yxZMlPJo+myzOYPObtOMTk8W/udnaPZXP3 sASwRXHZpKTmZJalFunbJXBlLFl3la3gr3HF/BvnWRsYj2h2MXJySAiYSCx5fJcJwhaTuHBv PVsXIxeHkMBmRokTSy4wgySEBVwkFl1aD1bEK2AssebWOxYQm1lAT2LH9V+sIDabgKrEgznH GEFsToFwiaV/PrJ3MXJwsADF2xfpgMxkFvjMKHGsvY8JoldbYtnC18wQM20kbr6/zAixeDqT xN+988EGiQi4SbyEOkJCQF6i5esdtgmM/LOQ3DELyR2zkMxdwMi8ilGwKDUnsdLQXC+xoCAn VS85P3cTIyiQGwqFdjDe36V3iFGAg1GJh/fVnEN+QqyJZcWVuYcYJTiYlUR4Dy0ECvGmJFZW pRblxxeV5qQWH2KU5mBREuct33XQT0ggPbEkNTs1tSC1CCbLxMEp1cA4b2W8Zcpl5xxOl5QF neVuD7LM6mV3h/EoTSwIENS99Mv2NPNz56ZFQXlbTj3QPXpefJnmovOhzaHJJjpi/bsUpPh+ rL3QHPl0w4ermw/87pjWq37y2qW5v1rjfyiKiu5/t+oM2546O47LSW/lvr6yEJklpcl1wS5n +52oHj71k6uWHjp18G6OEktxRqKhFnNRcSIATlUkg2ACAAA=
Cc: "gadams@xfsi.com Adams" , Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 00:20:18 -0000

Thanks Vlad

I think a valid question to ask is whether "application/", being a =
grab-bag for everything not-image-video-or-audio, is a good idea.  =
Perhaps that horse has already bolted, but the idea of a top-level type =
its, in my mind, to give the recipient some clues as to what the thing =
claims to offer, what use it might be, how it might be screened, and so =
on.  image/ tells you it's an image, that will need rendering space;  =
video and audio need timing, and video also needs rendering space, and =
audio needs audio presentation capability.

But application/ tells you nothing at all; it's the wild west, anything =
goes.  it might need rendering, it might make sound, it might need =
timing, it might be an unpresented resource (like a font), it might be=85 =
anything!

On Nov 15, 2011, at 15:22 , Levantovsky, Vladimir wrote:

> Hi all,
>=20
> First of all, thank you David. This is probably one of those times =
when I don't mind having been volunteered.
>=20
> I did express a good deal of interest in the past in registering =
"font" as a new top-level type, and the preliminary exploration work =
done few years ago had shown that we would've had about two dozens of =
subtype entries eligible for font/* tree.
>=20
> However, the sentiments expressed at the time were very similar to =
this discussion; I was told that applying for a new top-level type was =
"A BIG NO-NO", that prior attempts to register font/* failed, and that =
unless I am willing to dedicate significant part of my life to this =
activity (i.e. applying and lobbying for a new top-level "font" type) =
the effort would most likely get us nowhere.=20
>=20
> As far as "application/*" is concerned, aside from being heavily =
overloaded with various unrelated subtypes and, therefore, utterly =
confusing IMHO - I am not in a position to argue why font/* is better =
than application/* - it [font/*] just makes sense. However, since font/* =
was (and still is) not an option, there are already a number of font =
types registered either as vendor-specific or as part of the =
application/* tree - both "ancient" (tdpfr) and very recent (woff) come =
to mind.=20
>=20
> In fact, SC29/WG11 is in the process of finalizing a new application =
(as part of the ISO/IEC 14496-22:2009/Amd.2 work) where we decided to =
apply for a new "application/font-sfnt" type using additional optional =
parameters to specify types of outlines and advanced layout mechanisms =
supported by a font. Doing so allows creating a flexible and extensible =
(albeit slightly cumbersome) mechanism to identify any SFNT-based font =
using same MIME type definition for a number of font flavors combining =
either TTF or CFF outlines with any currently known layout engine =
support (e.g. OpenType, AAT or SIL). Under the circumstances, this =
seemed to be a pragmatic way to compensate for the lack of "font" type.
>=20
> I am sure that having a top-level "font/*" type would have made lives =
easier for many people, but having lived through the times where =
application/* was the only usable option to register font types (and =
having few of them already defined as such) - I have even less of an =
incentive to argue about it now. I would be happy to have font/* type =
defined, but I am not willing to spend my (and other people) valuable =
time to fight for it.
>=20
> Thank you,
> Vladimir
>=20
>=20
>=20
>> -----Original Message-----
>> From: David Singer [mailto:singer@apple.com]
>> Sent: Monday, November 14, 2011 6:50 PM
>> To: Ned Freed
>> Cc: "Martin J. D=FCrst"; Larry Masinter; apps-discuss@ietf.org;
>> gadams@xfsi.com Adams; Levantovsky, Vladimir
>> Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
>>=20
>> I probably shouldn't volunteer people, but I know Vladimir =
Levantovsky
>> has expressed interest in this question in the past.  I am sure he'd
>> want to be aware of this discussion.  In fact, I am cc'ing him here..
>>=20
>>=20
>> On Nov 14, 2011, at 13:44 , Ned Freed wrote:
>>=20
>>>> On 2011/11/13 5:25, Larry Masinter wrote:
>>>>> I see no use case for why having font/opentype is any better than
>> application/opentype
>>>=20
>>>> It's just fine if you, and some others, don't see it. Does that =
mean
>>>> that you have to fight against it? You haven't shown, even less
>>>> mentioned, any problem for font/opentype.
>>>=20
>>> Good point. I have no skin in this particular game - aside from
>> slightly
>>> complicating the media review process I have no personal need for
>> font/*. But
>>> if there's a constituency this type helps, I'm all for it.
>>>=20
>>>> My guess is that we would have around 10 or so font types =
registered
>>>> (and no font type sniffing) if a font/ top level type had been
>> approved
>>>> in a 1990'ish timeframe.
>>>=20
>>> And we may or may not have any luck rectifying this at this late
>> date. But I'm
>>> not  seeing a reason not to try.
>>>=20
>>>> ...
>>>=20
>>>>> I also recall a number of years ago an attempt to define
>> "chemical/*" as a
>>>>> new top level type for use in defining file formats?
>>>=20
>>>> So what? Were there good reasons to reject it? Or was it rejected
>>>> because some people believed that new top level types were "A BIG
>>>> NO-NO"? Or because of some FUD?
>>>=20
>>> Didn't chemical kind of morph into model? Or am I getting the =
history
>> confused?
>>>=20
>>>>> My conclusion from this discussion is that we should declare the
>> MIME
>>>>> hierarchy closed to new top level types; we've only gotten very
>> limited use and
>>>>> value out of the hierarchy, compared to the pain and difficulty
>> (text/xml vs
>>>>> application/xml).
>>>=20
>>>> The problems between text/xml and application/xml are very =
specific.
>> And
>>>> they may be interpreted to say that tying particular processing
>> rules to
>>>> particular types, unless absolutely necessary (e.g. structured
>> types),
>>>> may be a bad idea. That doesn't mean that top-level types in =
general
>> are
>>>> a bad idea.
>>>=20
>>> Agreed.
>>>=20
>>>> The reason that we have gotten very little value out of registering
>> new
>>>> top level types may be mostly that virtually no new types have been
>>>> registered, because people are claiming that we get very little
>> value
>>>> out of them. It sounds funny, but it isn't.
>>>=20
>>> No, it really isn't funny, is it?
>>>=20
>>> 				Ned
>>=20
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>=20

David Singer
Multimedia and Software Standards, Apple Inc.


From masinter@adobe.com  Tue Nov 15 18:15:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D340721F8DEF for ; Tue, 15 Nov 2011 18:15:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.275
X-Spam-Level: 
X-Spam-Status: No, score=-106.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, 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 WkhKr0D3g7Ye for ; Tue, 15 Nov 2011 18:15:20 -0800 (PST)
Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id F12A821F8DEC for ; Tue, 15 Nov 2011 18:15:19 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTsMcnFlZb7NOeUpFylelaLCQcgeYNyi5@postini.com; Tue, 15 Nov 2011 18:15:20 PST
Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pAG2EoZc015406; Tue, 15 Nov 2011 18:14:51 -0800 (PST)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pAG2Eo5R021491; Tue, 15 Nov 2011 18:14:50 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Tue, 15 Nov 2011 18:14:50 -0800
From: Larry Masinter 
To: Ned Freed , Peter Saint-Andre 
Date: Tue, 15 Nov 2011 18:14:47 -0800
Thread-Topic: [apps-discuss] type name suffixes
Thread-Index: Acyj80bY/md1a688QAGsLSWP530vxQAEUVpw
Message-ID: 
References: <4EB86078.8070904@stpeter.im> 	<4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>	<4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com>	<4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>
In-Reply-To: <01O8GE5O3B5K00RCTX@mauve.mrochek.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] type name suffixes
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 02:15:22 -0000

I believe that the suffix +xml has an important function as an indicator th=
at the body of the content is suitable for generic XML processing, for exam=
ple, in the use of XPointer as a fragment identifier, and the ability to us=
e a generic XML parser to scan the content. The expectation is that Media t=
ypes that end in +xml are, in fact, restricted to only contain content that=
 fits, and that RFC 3023 (and RFC 3023bis in preparation) defines that mean=
ing and establishes that requirement.

The URI specification defers the interpretation of fragment identifiers (#x=
xx at the end of a URI) to the definition of the media type of the retrieve=
d content.

The reason for holding back on other +xxx typename suffix is only to insure=
 that there is a clear definition for what expectation there might be for c=
ommon processing techniques and fragment identifiers....  that is, there is=
 an operational requirement and definition, not just a vague "feel good".

So, for example,  type/subtype+json content labeled with a +json media type=
 should be restricted, for example, to content that can be updated with jso=
n-patch PATCH operations, and generic json processing.

I think a separate specification for what the generic processing requiremen=
ts and compatibility should be strongly recommended. It's not just a "feel =
good sounds right" matter.

Larry


-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Ned Freed
Sent: Wednesday, November 16, 2011 8:01 AM
To: Peter Saint-Andre
Cc: Ned Freed; apps-discuss@ietf.org
Subject: Re: [apps-discuss] type name suffixes

> > > The reason I ask is that I've had a few people ask me about this=20
> > > topic recently.

> > Well, the preferable thing would be to get the process Tony defined=20
> > that I included in 4288bis approved. Absent that, the rule is more=20
> > or less that you can use a suffix if you like and if it seems to make s=
ense.

> Thanks for the clarification. I agree that the right place to define=20
> this more carefully is 4288bis.

Yes, and that text is already in 4288bis. Please have a look and see if you=
 think it is OK - there have been very few comments on it.

 In the meantime, let's say that someone
> wants to register "application/foo+bar" -- do we feel that they need=20
> to describe the "+bar" suffix in a separate specification, or can they=20
> simply go ahead and use the suffix in the I-D that registers the "foo"
> application, perhaps along with some explanatory text?

I'd reccomment including some explanatory text saying where the format asso=
ciated with the suffix is defined, but I see no need for a separate specifi=
cation. In fact the 4288bis approach is specifically intended to make a sep=
arate specification unnecessary.

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

From stpeter@stpeter.im  Tue Nov 15 18:17:12 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5159E21F8E0C for ; Tue, 15 Nov 2011 18:17:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.819
X-Spam-Level: 
X-Spam-Status: No, score=-102.819 tagged_above=-999 required=5 tests=[AWL=-0.220, 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 qNU0uCK9RroB for ; Tue, 15 Nov 2011 18:17:05 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6E11E8112 for ; Tue, 15 Nov 2011 18:17:05 -0800 (PST)
Received: from dhcp-15ab.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AFA1B4214E; Tue, 15 Nov 2011 19:23:18 -0700 (MST)
Message-ID: <4EC31D1D.1000509@stpeter.im>
Date: Wed, 16 Nov 2011 10:17:01 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Levantovsky, Vladimir" 
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org>
In-Reply-To: <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org>
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Ned Freed , David Singer , "apps-discuss@ietf.org" , "gadams@xfsi.com Adams" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 02:17:12 -0000

On 11/16/11 7:22 AM, Levantovsky, Vladimir wrote:

> However, the sentiments expressed at the time were very similar to
> this discussion; I was told that applying for a new top-level type
> was "A BIG NO-NO", that prior attempts to register font/* failed, and
> that unless I am willing to dedicate significant part of my life to
> this activity (i.e. applying and lobbying for a new top-level "font"
> type) the effort would most likely get us nowhere.

Perhaps I am mistaken, but I read the discussion differently: I see an
openness to registering font/* now.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From stpeter@stpeter.im  Tue Nov 15 18:25:42 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E8711E818F for ; Tue, 15 Nov 2011 18:25:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.812
X-Spam-Level: 
X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=-0.213, 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 RapLo9p1hbSV for ; Tue, 15 Nov 2011 18:25:37 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DC61F11E80EE for ; Tue, 15 Nov 2011 18:25:37 -0800 (PST)
Received: from dhcp-15ab.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6E28B4214E; Tue, 15 Nov 2011 19:31:51 -0700 (MST)
Message-ID: <4EC31F1E.6070304@stpeter.im>
Date: Wed, 16 Nov 2011 10:25:34 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Larry Masinter 
References: <4EB86078.8070904@stpeter.im> 	<4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>	<4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com>	<4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com> 
In-Reply-To: 
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] type name suffixes
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 02:25:42 -0000

On 11/16/11 10:14 AM, Larry Masinter wrote:

> I believe that the suffix +xml has an important function as an
> indicator that the body of the content is suitable for generic XML
> processing, for example, in the use of XPointer as a fragment
> identifier, and the ability to use a generic XML parser to scan the
> content. The expectation is that Media types that end in +xml are, in
> fact, restricted to only contain content that fits, and that RFC 3023
> (and RFC 3023bis in preparation) defines that meaning and establishes
> that requirement.
> 
> The URI specification defers the interpretation of fragment
> identifiers (#xxx at the end of a URI) to the definition of the media
> type of the retrieved content.
> 
> The reason for holding back on other +xxx typename suffix is only to
> insure that there is a clear definition for what expectation there
> might be for common processing techniques and fragment
> identifiers....  that is, there is an operational requirement and
> definition, not just a vague "feel good".
> 
> So, for example,  type/subtype+json content labeled with a +json
> media type should be restricted, for example, to content that can be
> updated with json-patch PATCH operations, and generic json
> processing.
> 
> I think a separate specification for what the generic processing
> requirements and compatibility should be strongly recommended. It's
> not just a "feel good sounds right" matter.

Larry, that is helpful.

To be clear, the two suffixes I've seen interest in are:

+json = 

+exi = 

We do need to take these on a case-by-case basis and we need to define
them clearly, but I doubt that we will see a flood of them.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From derhoermi@gmx.net  Tue Nov 15 18:45:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55411F0CA4 for ; Tue, 15 Nov 2011 18:45:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level: 
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186,  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 oB796XCGotSI for ; Tue, 15 Nov 2011 18:45:31 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5C3701F0C60 for ; Tue, 15 Nov 2011 18:45:31 -0800 (PST)
Received: (qmail invoked by alias); 16 Nov 2011 02:45:29 -0000
Received: from dslb-094-223-211-067.pools.arcor-ip.net (EHLO HIVE) [94.223.211.67] by mail.gmx.net (mp009) with SMTP; 16 Nov 2011 03:45:29 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19pejJH/BBpngD5t/PKjCr2Df9KU27MLwwaOCSyae IkUpZWZWVRo+UF
From: Bjoern Hoehrmann 
To: Peter Saint-Andre 
Date: Wed, 16 Nov 2011 03:45:35 +0100
Message-ID: <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de>
References: <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com>	<4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>  <4EC31F1E.6070304@stpeter.im>
In-Reply-To: <4EC31F1E.6070304@stpeter.im>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] type name suffixes
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 02:45:36 -0000

* Peter Saint-Andre wrote:
>To be clear, the two suffixes I've seen interest in are:
>
>+json = 
>
>+exi = 

(I was under the impression the W3C had decided against "+exi" suffixes,
and instead use the "exi" content coding as the specification there re-
commends. I'd rather not duplicate all "+xml" entries with "+exi" types)
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From stpeter@stpeter.im  Tue Nov 15 18:59:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABF521F8F25 for ; Tue, 15 Nov 2011 18:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.805
X-Spam-Level: 
X-Spam-Status: No, score=-102.805 tagged_above=-999 required=5 tests=[AWL=-0.206, 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 dJzB+KPDBMzu for ; Tue, 15 Nov 2011 18:59:14 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EFFE121F8F24 for ; Tue, 15 Nov 2011 18:59:13 -0800 (PST)
Received: from dhcp-15ab.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BE7834214E; Tue, 15 Nov 2011 20:05:27 -0700 (MST)
Message-ID: <4EC326FE.1010809@stpeter.im>
Date: Wed, 16 Nov 2011 10:59:10 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Bjoern Hoehrmann 
References: <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com>	<4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>  <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de>
In-Reply-To: <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de>
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: [apps-discuss] +exi (was: Re:  type name suffixes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 02:59:18 -0000

On 11/16/11 10:45 AM, Bjoern Hoehrmann wrote:
> * Peter Saint-Andre wrote:
>> To be clear, the two suffixes I've seen interest in are:
>>
>> +json = 
>>
>> +exi = 
> 
> (I was under the impression the W3C had decided against "+exi" suffixes,
> and instead use the "exi" content coding as the specification there re-
> commends. I'd rather not duplicate all "+xml" entries with "+exi" types)

So, let's say I have "foo" data that can be represented in either plain
old XML or as EXI. If I send that "foo" data as plain old XML, the
"application/foo+xml" media type is right. If I send that "foo" data as
EXI, the "application/foo+exi" media type seems wrong, and so does the
"application/exi" media type (just as "application/xml" would not be
right for the first encoding). Sure, I don't particularly want to
duplicate all "+xml" entries with "+exi" entries, but I don't think that
every protocol or community that sends around XML data will also send
around EXI-encoded data.

But I freely admit that I might be missing context or historical
information about the W3C's decisions in this area.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From derhoermi@gmx.net  Tue Nov 15 19:06:43 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F9311E81E1 for ; Tue, 15 Nov 2011 19:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163,  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 s4pVXAaI-mLN for ; Tue, 15 Nov 2011 19:06:39 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 898F521F8FB9 for ; Tue, 15 Nov 2011 19:06:38 -0800 (PST)
Received: (qmail invoked by alias); 16 Nov 2011 03:06:37 -0000
Received: from dslb-094-223-211-067.pools.arcor-ip.net (EHLO HIVE) [94.223.211.67] by mail.gmx.net (mp040) with SMTP; 16 Nov 2011 04:06:37 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX18zDQhrgMEzDe08tm7Aob0Gnm88sckRqcQYYSzBsf aFwk6dxhe/PyTJ
From: Bjoern Hoehrmann 
To: Peter Saint-Andre 
Date: Wed, 16 Nov 2011 04:06:42 +0100
Message-ID: 
References: <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>  <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de> <4EC326FE.1010809@stpeter.im>
In-Reply-To: <4EC326FE.1010809@stpeter.im>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] +exi (was: Re:  type name suffixes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 03:06:44 -0000

* Peter Saint-Andre wrote:
>So, let's say I have "foo" data that can be represented in either plain
>old XML or as EXI. If I send that "foo" data as plain old XML, the
>"application/foo+xml" media type is right. If I send that "foo" data as
>EXI, the "application/foo+exi" media type seems wrong, and so does the
>"application/exi" media type (just as "application/xml" would not be
>right for the first encoding). Sure, I don't particularly want to
>duplicate all "+xml" entries with "+exi" entries, but I don't think that
>every protocol or community that sends around XML data will also send
>around EXI-encoded data.

The idea is that "EXI" is more like "gzip", so with HTTP you would do

  Content-Type: application/foo+xml
  Content-Encoding: exi

As you would for gzip-compressed content.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From stpeter@stpeter.im  Tue Nov 15 19:14:58 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A9411E80B0 for ; Tue, 15 Nov 2011 19:14:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.798
X-Spam-Level: 
X-Spam-Status: No, score=-102.798 tagged_above=-999 required=5 tests=[AWL=-0.199, 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 8Osuo-yRR2DL for ; Tue, 15 Nov 2011 19:14:54 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F58721F9050 for ; Tue, 15 Nov 2011 19:14:54 -0800 (PST)
Received: from dhcp-15ab.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 385244214E; Tue, 15 Nov 2011 20:21:08 -0700 (MST)
Message-ID: <4EC32AA8.7090205@stpeter.im>
Date: Wed, 16 Nov 2011 11:14:48 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Bjoern Hoehrmann 
References: <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>  <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de> <4EC326FE.1010809@stpeter.im> 
In-Reply-To: 
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] +exi
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 03:14:58 -0000

On 11/16/11 11:06 AM, Bjoern Hoehrmann wrote:
> * Peter Saint-Andre wrote:
>> So, let's say I have "foo" data that can be represented in either plain
>> old XML or as EXI. If I send that "foo" data as plain old XML, the
>> "application/foo+xml" media type is right. If I send that "foo" data as
>> EXI, the "application/foo+exi" media type seems wrong, and so does the
>> "application/exi" media type (just as "application/xml" would not be
>> right for the first encoding). Sure, I don't particularly want to
>> duplicate all "+xml" entries with "+exi" entries, but I don't think that
>> every protocol or community that sends around XML data will also send
>> around EXI-encoded data.
> 
> The idea is that "EXI" is more like "gzip", so with HTTP you would do
> 
>   Content-Type: application/foo+xml
>   Content-Encoding: exi
> 
> As you would for gzip-compressed content.

Right. We did something similar for SVG, where there is a gzipped
encoding but not a separate media type for svgz.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From zach@sensinode.com  Tue Nov 15 19:21:47 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5221B11E80F8 for ; Tue, 15 Nov 2011 19:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.349
X-Spam-Level: 
X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, 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 BkfXLWAwNxHo for ; Tue, 15 Nov 2011 19:21:42 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id EDD3911E80E2 for ; Tue, 15 Nov 2011 19:21:41 -0800 (PST)
Received: from dhcp-123b.meeting.ietf.org (dhcp-123b.meeting.ietf.org [130.129.18.59]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pAG3LRVc023722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 05:21:33 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-656--490897481; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Wed, 16 Nov 2011 11:21:25 +0800
Message-Id: 
References: <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>  <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de> <4EC326FE.1010809@stpeter.im> 
To: Bjoern Hoehrmann 
X-Mailer: Apple Mail (2.1084)
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] +exi (was: Re:  type name suffixes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 03:21:47 -0000

--Apple-Mail-656--490897481
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 16, 2011, at 11:06 AM, Bjoern Hoehrmann wrote:

> * Peter Saint-Andre wrote:
>> So, let's say I have "foo" data that can be represented in either =
plain
>> old XML or as EXI. If I send that "foo" data as plain old XML, the
>> "application/foo+xml" media type is right. If I send that "foo" data =
as
>> EXI, the "application/foo+exi" media type seems wrong, and so does =
the
>> "application/exi" media type (just as "application/xml" would not be
>> right for the first encoding). Sure, I don't particularly want to
>> duplicate all "+xml" entries with "+exi" entries, but I don't think =
that
>> every protocol or community that sends around XML data will also send
>> around EXI-encoded data.
>=20
> The idea is that "EXI" is more like "gzip", so with HTTP you would do
>=20
>  Content-Type: application/foo+xml
>  Content-Encoding: exi
>=20
> As you would for gzip-compressed content.

Ouch, don't do that.=20

The main interest right now for EXI is in constrained networks, and in =
particular over CoAP. We don't have support for indicating =
content-encoding in CoAP. Besides, the current media type for EXI is =
application/exi. Thus it would make perfect sense to have +exi entries. =
Furthermore, EXI is totally different than gzip, which is a generic =
encoding that can be applied to anything. EXI can be applied only to XML =
objects, and in particular EXI is often used in a schema mode where it =
is only applicable to a single schema. Thus the form =
application/schema+exi makes even more sense, as that EXI format is =
actually specific to that particular schema and the media type tells you =
everything that is needed to decode the representation.=20

Zach

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-656--490897481
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTExMTYw
MzIxMjZaMCMGCSqGSIb3DQEJBDEWBBTJwA5ia+e6rPdwAT5lx77dn6fIzDCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQAXY2rvhopFUIOgz4hjmhm4ndnxR5jHrL4IswunXqrYifyvGFkU
/82ZRZI/MMmahvFnvI9UodPOf6vqGxmJvjQs0cUC1PR5Jr8oeBqh2N34n/wKnFWwUWFoWB6TDOYY
z7ZxmkgRpWQr1kb/UgAqG/gE12LX1hx3h0nfZlLkTCVtLO5kibgfbkJPcqxfR3U+RXDuqlcsj+Sy
3+kvjE9Lf+NGYn/wyMDAUB2oc2mRzEdqLyYL3EG9g8fbTPo9f9EV8LNhlLtM3deZ/O3Bbo6lDLaX
/p74EXpV5rFcw4/Xdz/tVzk6qoIsvQ5X5iS8occm3XYCkFKrtQJQV5pbdhXTQxa0AAAAAAAA

--Apple-Mail-656--490897481--

From mnot@mnot.net  Tue Nov 15 20:13:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796501F0C4B for ; Tue, 15 Nov 2011 20:13:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.799
X-Spam-Level: 
X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=-3.200, 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 wkvvcs02uQpq for ; Tue, 15 Nov 2011 20:13:50 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 312F31F0C47 for ; Tue, 15 Nov 2011 20:13:49 -0800 (PST)
Received: from [10.10.1.235] (unknown [12.14.58.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4930650A5D; Tue, 15 Nov 2011 23:13:38 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 15 Nov 2011 22:13:32 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <187EB539-B92A-4E65-BAF2-F18E01AC32F3@mnot.net>
References: <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>  <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de> <4EC326FE.1010809@stpeter.im>  
To: Zach Shelby 
X-Mailer: Apple Mail (2.1251.1)
Cc: Bjoern Hoehrmann , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] +exi (was: Re:  type name suffixes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 04:13:54 -0000

On 15/11/2011, at 9:21 PM, Zach Shelby wrote:

> Ouch, don't do that.=20
>=20
> The main interest right now for EXI is in constrained networks, and in =
particular over CoAP. We don't have support for indicating =
content-encoding in CoAP.

Maybe it should be added?

> Besides, the current media type for EXI is application/exi. Thus it =
would make perfect sense to have +exi entries. Furthermore, EXI is =
totally different than gzip, which is a generic encoding that can be =
applied to anything. EXI can be applied only to XML objects, and in =
particular EXI is often used in a schema mode where it is only =
applicable to a single schema. Thus the form application/schema+exi =
makes even more sense, as that EXI format is actually specific to that =
particular schema and the media type tells you everything that is needed =
to decode the representation.=20

These arguments were part of the discussion during EXI, and W3C decided =
to use a content-coding.

Cheers,

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





From cabo@tzi.org  Tue Nov 15 20:43:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8E61F0C6F for ; Tue, 15 Nov 2011 20:43:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 WP3rVfjpEa9y for ; Tue, 15 Nov 2011 20:43:04 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 82A601F0C4B for ; Tue, 15 Nov 2011 20:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAG4gp0d005530; Wed, 16 Nov 2011 05:42:51 +0100 (CET)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 63B4C395; Wed, 16 Nov 2011 05:42:49 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <187EB539-B92A-4E65-BAF2-F18E01AC32F3@mnot.net>
Date: Wed, 16 Nov 2011 12:42:44 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <16B1EA83-5B6B-4512-9358-7F2474D6280C@tzi.org>
References: <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>  <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de> <4EC326FE.1010809@stpeter.im>   <187EB539-B92A-4E65-BAF2-F18E01AC32F3@mnot.net>
To: Mark Nottingham 
X-Mailer: Apple Mail (2.1251.1)
Cc: Bjoern Hoehrmann , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] +exi (was: Re:  type name suffixes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 04:43:04 -0000

On Nov 16, 2011, at 12:13, Mark Nottingham wrote:

>=20
> On 15/11/2011, at 9:21 PM, Zach Shelby wrote:
>=20
>> Ouch, don't do that.=20
>>=20
>> The main interest right now for EXI is in constrained networks, and =
in particular over CoAP. We don't have support for indicating =
content-encoding in CoAP.
>=20
> Maybe it should be added?

YAGNI.
(Or, in terms of Monday's plenary, "fluff".)

>> Besides, the current media type for EXI is application/exi. Thus it =
would make perfect sense to have +exi entries. Furthermore, EXI is =
totally different than gzip, which is a generic encoding that can be =
applied to anything. EXI can be applied only to XML objects, and in =
particular EXI is often used in a schema mode where it is only =
applicable to a single schema. Thus the form application/schema+exi =
makes even more sense, as that EXI format is actually specific to that =
particular schema and the media type tells you everything that is needed =
to decode the representation.=20
>=20
> These arguments were part of the discussion during EXI, and W3C =
decided to use a content-coding.

Maybe we need to interpret CoAP's Content-Type option to stand for a =
pair of a media-type and a content-coding.

Gr=FC=DFe, Carsten


From mnot@mnot.net  Tue Nov 15 20:45:20 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3A71F0C6F for ; Tue, 15 Nov 2011 20:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.266
X-Spam-Level: 
X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=-2.667, 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 dXgD0+MikKRe for ; Tue, 15 Nov 2011 20:45:16 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 745611F0C47 for ; Tue, 15 Nov 2011 20:45:16 -0800 (PST)
Received: from [10.10.1.235] (unknown [12.14.58.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F20B1509EB; Tue, 15 Nov 2011 23:45:06 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Mark Nottingham 
In-Reply-To: <16B1EA83-5B6B-4512-9358-7F2474D6280C@tzi.org>
Date: Tue, 15 Nov 2011 22:45:03 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>  <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de> <4EC326FE.1010809@stpeter.im>   <187EB539-B92A-4E65-BAF2-F18E01AC32F3@mnot.net> <16B1EA83-5B6B-4512-9358-7F2474D6280C@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1251.1)
Cc: Bjoern Hoehrmann , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] +exi (was: Re:  type name suffixes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 04:45:20 -0000

On 15/11/2011, at 10:42 PM, Carsten Bormann wrote:

>> Maybe it should be added?
>=20
> YAGNI.
> (Or, in terms of Monday's plenary, "fluff".)

Uh huh.


>>> Besides, the current media type for EXI is application/exi. Thus it =
would make perfect sense to have +exi entries. Furthermore, EXI is =
totally different than gzip, which is a generic encoding that can be =
applied to anything. EXI can be applied only to XML objects, and in =
particular EXI is often used in a schema mode where it is only =
applicable to a single schema. Thus the form application/schema+exi =
makes even more sense, as that EXI format is actually specific to that =
particular schema and the media type tells you everything that is needed =
to decode the representation.=20
>>=20
>> These arguments were part of the discussion during EXI, and W3C =
decided to use a content-coding.
>=20
> Maybe we need to interpret CoAP's Content-Type option to stand for a =
pair of a media-type and a content-coding.

Wow.

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





From zach@sensinode.com  Tue Nov 15 20:48:06 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8358B1F0C9F for ; Tue, 15 Nov 2011 20:48:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167,  BAYES_00=-2.599, 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 5cSVh25A+mKI for ; Tue, 15 Nov 2011 20:48:01 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3A10E1F0CA6 for ; Tue, 15 Nov 2011 20:48:01 -0800 (PST)
Received: from dhcp-123b.meeting.ietf.org (dhcp-123b.meeting.ietf.org [130.129.18.59]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pAG4lojE027829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 06:47:55 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-657--485713743; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: <187EB539-B92A-4E65-BAF2-F18E01AC32F3@mnot.net>
Date: Wed, 16 Nov 2011 12:47:49 +0800
Message-Id: <7ED2D66E-E262-4E6B-804D-4E11DACC899F@sensinode.com>
References: <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>  <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de> <4EC326FE.1010809@stpeter.im>   <187EB539-B92A-4E65-BAF2-F18E01AC32F3@mnot.net>
To: Mark Nottingham 
X-Mailer: Apple Mail (2.1084)
Cc: Bjoern Hoehrmann , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] +exi (was: Re:  type name suffixes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 04:48:06 -0000

--Apple-Mail-657--485713743
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Nov 16, 2011, at 12:13 PM, Mark Nottingham wrote:

>> Besides, the current media type for EXI is application/exi. Thus it =
would make perfect sense to have +exi entries. Furthermore, EXI is =
totally different than gzip, which is a generic encoding that can be =
applied to anything. EXI can be applied only to XML objects, and in =
particular EXI is often used in a schema mode where it is only =
applicable to a single schema. Thus the form application/schema+exi =
makes even more sense, as that EXI format is actually specific to that =
particular schema and the media type tells you everything that is needed =
to decode the representation.=20
>=20
> These arguments were part of the discussion during EXI, and W3C =
decided to use a content-coding.

The W3C standard defines application/exi here=20

http://www.w3.org/TR/2009/CR-exi-20091208/#mediaTypeRegistration

Zach

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-657--485713743
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTExMTYw
NDQ3NTBaMCMGCSqGSIb3DQEJBDEWBBQ+lklKchJKNkXnu16D9fYflXrLIjCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQBqU7xRxvqVB13QJn4Iy++C6yUdYf9giP/rAetvfxXppNxnB0KB
llH98gS1sShN6rC6Zzu6CDsS71FscXpPChjy0LZpQudF4Bm2mbTgTrxPw27y2UCiey81BBOQOXmZ
OJ6SoKhA5+bEuhLilNCe0z6ena/8pWardsMULSO4B4lwvAaXqDIMa6zchp6KqYcyiYR0JCeW5ee1
5r+kXyxtN9dX+bqiwqZkVIgcAFgk7Zp1rHjWskMCmdoz7AktpwXQmcuW34tqYSR/ljuwPVx68iql
O6uD2/czCGHtdIfaiTmtwEF2VfV9oPIh3fUPSeH+n8edBda51MELjIiT+YSw8v0kAAAAAAAA

--Apple-Mail-657--485713743--

From mnot@mnot.net  Tue Nov 15 20:50:31 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4CF1F0CA6 for ; Tue, 15 Nov 2011 20:50:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.885
X-Spam-Level: 
X-Spam-Status: No, score=-104.885 tagged_above=-999 required=5 tests=[AWL=-2.286, 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 sKxNt0fisym2 for ; Tue, 15 Nov 2011 20:50:27 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC041F0CB7 for ; Tue, 15 Nov 2011 20:50:26 -0800 (PST)
Received: from [10.10.1.235] (unknown [12.14.58.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CCFB450A64; Tue, 15 Nov 2011 23:50:24 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: <7ED2D66E-E262-4E6B-804D-4E11DACC899F@sensinode.com>
Date: Tue, 15 Nov 2011 22:50:24 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <64D06F72-1BCE-4B4B-80AB-415654F8365C@mnot.net>
References: <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com>	<4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com>  <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de> <4EC326FE.1010809@stpeter.im>   <187EB539-B92A-4E65-BAF2-F18E01AC32F3@mnot.net> <7ED2D66E-E262-4E6B-804D-4E11DACC899F@sensinode.com>
To: Zach Shelby 
X-Mailer: Apple Mail (2.1251.1)
Cc: Bjoern Hoehrmann , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] +exi (was: Re:  type name suffixes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 04:50:31 -0000

On 15/11/2011, at 10:47 PM, Zach Shelby wrote:

>=20
> On Nov 16, 2011, at 12:13 PM, Mark Nottingham wrote:
>=20
>>> Besides, the current media type for EXI is application/exi. Thus it =
would make perfect sense to have +exi entries. Furthermore, EXI is =
totally different than gzip, which is a generic encoding that can be =
applied to anything. EXI can be applied only to XML objects, and in =
particular EXI is often used in a schema mode where it is only =
applicable to a single schema. Thus the form application/schema+exi =
makes even more sense, as that EXI format is actually specific to that =
particular schema and the media type tells you everything that is needed =
to decode the representation.=20
>>=20
>> These arguments were part of the discussion during EXI, and W3C =
decided to use a content-coding.
>=20
> The W3C standard defines application/exi here=20
>=20
> http://www.w3.org/TR/2009/CR-exi-20091208/#mediaTypeRegistration


Yes, and they register the content coding right above that.=20

Just because they registered a generic media type, it doesn't follow =
that automatically creating +exi media types for everything is a good =
idea.

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





From stpeter@stpeter.im  Wed Nov 16 02:06:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603C221F9644 for ; Wed, 16 Nov 2011 02:06:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 5l8ig7xb8PM5 for ; Wed, 16 Nov 2011 02:06:21 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D4A6921F9642 for ; Wed, 16 Nov 2011 02:06:21 -0800 (PST)
Received: from squire.local (unknown [130.129.21.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 70BC6404FF; Wed, 16 Nov 2011 03:12:36 -0700 (MST)
Message-ID: <4EC38B1A.4080704@stpeter.im>
Date: Wed, 16 Nov 2011 18:06:18 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>	<4EBD6266.6030307@gmail.com>	 <4EBF136F.2080703@stpeter.im> <013501cca228$bcaba9a0$3602fce0$@packetizer.com>
In-Reply-To: <013501cca228$bcaba9a0$3602fce0$@packetizer.com>
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: 'Barry Leiba' , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 10:06:22 -0000

On 11/14/11 1:21 AM, Paul E. Jones wrote:
> Peter,
> 
>> I think that documentation of the webfinger protocol would be a good
>> thing, given that it's somewhat widely used on the web. I do not have a
>> strong opinion about whether it is needful for the APPSAWG to take on
>> this work.
> 
> The main reason I see a need for the WG item is that we're proposing a new
> URI scheme ("acct").  Presently, the text also recommends the use of CORS
> and makes other normative statements.
> 
> I could be persuaded that "acct" should be pulled out into its own document,
> since I can imagine the utility for it might be broader than Webfinger.  If
> we did that, then perhaps there is less of an argument for it being a WG
> item, but I'm not sure out the text would be progressed in that case.
> 
> In any case, I'll take input on the best way to go forward.  I don't care
> how we get there, but I fully agree with you that it ought to be documented.

Your point about the 'acct' URI scheme makes sense. I don't see a strong
need to pull it into a separate spec, but perhaps that's because I don't
know of other uses for the scheme outside of webfinger.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From gsalguei@cisco.com  Wed Nov 16 06:30:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707441F0C59 for ; Wed, 16 Nov 2011 06:30:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 VY6XUcv0F5rf for ; Wed, 16 Nov 2011 06:30:02 -0800 (PST)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC071F0C57 for ; Wed, 16 Nov 2011 06:30:02 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAGEU1s1019475 for ; Wed, 16 Nov 2011 09:30:01 -0500 (EST)
Received: from dhcp-64-102-210-204.cisco.com (dhcp-64-102-210-204.cisco.com [64.102.210.204]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAGETwWg022520; Wed, 16 Nov 2011 09:29:58 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-263--450787310
From: Gonzalo Salgueiro 
In-Reply-To: <4EC38B1A.4080704@stpeter.im>
Date: Wed, 16 Nov 2011 09:29:56 -0500
Message-Id: <3E9D7309-D8E2-42B4-8FFC-9EF1FAD4AC53@cisco.com>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>	<4EBD6266.6030307@gmail.com>	 <4EBF136F.2080703@stpeter.im> <013501cca228$bcaba9a0$3602fce0$@packetizer.com> <4EC38B1A.4080704@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1084)
Cc: 'Barry Leiba' , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 14:30:03 -0000

--Apple-Mail-263--450787310
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Nov 16, 2011, at 5:06 AM, Peter Saint-Andre wrote:

> On 11/14/11 1:21 AM, Paul E. Jones wrote:
>> Peter,
>>=20
>>> I think that documentation of the webfinger protocol would be a good
>>> thing, given that it's somewhat widely used on the web. I do not =
have a
>>> strong opinion about whether it is needful for the APPSAWG to take =
on
>>> this work.
>>=20
>> The main reason I see a need for the WG item is that we're proposing =
a new
>> URI scheme ("acct").  Presently, the text also recommends the use of =
CORS
>> and makes other normative statements.
>>=20
>> I could be persuaded that "acct" should be pulled out into its own =
document,
>> since I can imagine the utility for it might be broader than =
Webfinger.  If
>> we did that, then perhaps there is less of an argument for it being a =
WG
>> item, but I'm not sure out the text would be progressed in that case.
>>=20
>> In any case, I'll take input on the best way to go forward.  I don't =
care
>> how we get there, but I fully agree with you that it ought to be =
documented.
>=20
> Your point about the 'acct' URI scheme makes sense. I don't see a =
strong
> need to pull it into a separate spec, but perhaps that's because I =
don't
> know of other uses for the scheme outside of webfinger.

I don't think this needs to break that off into a separate doc. I'll =
also weigh in on the fact that this can certainly be progressed as an =
AD-sponsored independent submission, but given the choice, I tend to =
agree that there would be a benefit to have it be a WG item based on the =
normative addition introduced by 'acct' URI and the added WG focus in =
reviewing.

Regards,

Gonzalo

>=20
> Peter
>=20
> --=20
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20


--Apple-Mail-263--450787310
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On 11/14/11 1:21 AM, Paul E. Jones =
wrote:
Peter,

I think that documentation of the webfinger protocol would =
be a good
thing, given that it's somewhat =
widely used on the web. I do not have =
a
strong opinion about whether it is needful for the APPSAWG =
to take on
this =
work.

The main reason =
I see a need for the WG item is that we're proposing a =
new
URI scheme ("acct"). =
 Presently, the text also recommends the use of =
CORS
and makes other normative =
statements.

I could be =
persuaded that "acct" should be pulled out into its own =
document,
since I can imagine =
the utility for it might be broader than Webfinger. =
 If
we did that, then =
perhaps there is less of an argument for it being a =
WG
item, but I'm not sure out =
the text would be progressed in that case.

In any case, =
I'll take input on the best way to go forward.  I don't =
care
how we get there, but I =
fully agree with you that it ought to be =
documented.

Your point about the 'acct' URI scheme =
makes sense. I don't see a strong
need to pull it into a separate =
spec, but perhaps that's because I don't
know of other uses for the =
scheme outside of webfinger.

I =
don't think this needs to break that off into a separate doc. I'll also =
weigh in on the fact that this can certainly be progressed as an =
AD-sponsored independent submission, but given the choice, I tend to =
agree that there would be a benefit to have it be a WG item based on the =
normative addition introduced by 'acct' URI and the added WG focus in =
reviewing.

Regards,

Gonz=
alo


Peter

-- =

Peter Saint-Andre
https://stpeter.im/


__________=
_____________________________________
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/app=
s-discuss


=

--Apple-Mail-263--450787310--

From evnikita2@gmail.com  Wed Nov 16 11:27:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E9A1F0C6E for ; Wed, 16 Nov 2011 11:27:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.33
X-Spam-Level: 
X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=-0.031,  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 U8BP0FyXM2PA for ; Wed, 16 Nov 2011 11:27:25 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF371F0C60 for ; Wed, 16 Nov 2011 11:27:17 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so1165052bkb.31 for ; Wed, 16 Nov 2011 11:27:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C2a7de2FudHh91jLBIM7B6ieqg4DtzzJGYTnc1vPx2M=; b=F1lwzfjar+A9oZoCEg42inZvTRFXY9wsJprIuTsW8E5ptU+yLWCZIUopwSNgknJJUf eQzWHNz6up2vUdi9iYAYSww4i79VeoOXkqxAD3FiUQVEedtDU5AjVUpH8L8XsfNMA1aR dDn6qiU7Jw0Zu8eguvQlJw97rsJitRaHKQnXU=
Received: by 10.205.122.139 with SMTP id gg11mr1186284bkc.67.1321471636419; Wed, 16 Nov 2011 11:27:16 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id j4sm3889155fae.3.2011.11.16.11.27.12 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 11:27:13 -0800 (PST)
Message-ID: <4EC40EC3.9080304@gmail.com>
Date: Wed, 16 Nov 2011 21:28:03 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Alexey Melnikov 
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com>
In-Reply-To: <4EC1D4C1.7080406@isode.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 19:27:26 -0000

15.11.2011 4:56, Alexey Melnikov wrote:
> Hi Mykyta,

Hello Alexey.

>
> In Section 1:
>
>    The concept of 'about' URIs has been formed at the times when the
>    applications did not have the "friendly" user interface, in order to
>    provide an access to the aforementioned resources via typing the URIs
>    in the address bar.
>
> Sorry, are you saying that typing about: URIs into the address bar is 
> "friendly" interface?
> I think I disagree. Or is "not" missing somewhere?

Address bar was present in console browsers even, that were far from 
friendly interface, and that is precisely what I have in the doc: "did 
not have the "friendly" user interface"

>
>    Even though the user interface of current
>    Internet-targeted software effectively rescinds the issue, and
>    'about' URIs can be thought to be a rudimentary phenomenon, they are
>    still supported by a variety of Web browsers and are not going to
>    cease to exist.
>
> URIs are useful in contexts when one wants to reference a resource and
> can only pass in a string. So no, about: URIs are not going to go away
> and not for reasons you've mentioned. I suggest removing or rewording
> this text.

I have "still supported" here, and this is an answer to you sentence 2.  
With respect to the first question, this is just what I wanted to say in 
the first paragraph you cited.  So I don't see a need for any text 
change here.

>
>
>
> 2.1. URI Scheme Syntax
>
>    The 'about' URI MUST syntactically conform to the  rule
>    below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]:
>
>      about-uri   = "about:" about-token [ about-query ]
>      about-token = segment
>      about-query = "?" query
>      segment     = 
>      query       = 
>
>    In terms of RFC 3986,  part corresponds to ,
>    and  to the query component of URI.
>
> s/query/ ? (I didn't check RFC 3986)

 doesn't include "?" - so query component.

>
>
> 2.2. URI Scheme Semantics
>
>    However, it is impossible to specify binding between all the possible
>    tokens and the semantics of 'about' URIs that would contain such
>    tokens.  Therefore any application MAY resolve an 'about' URI to any
>    desired resource, and MAY redirect such URIs.
>
> The meaning of redirection is not defined here. Do you mean 
> redirection in HTTP sense?
> If yes, I think a reference to HTTP (RFC 2616) is needed.

Yes, redirection needs clarification.  That is not HTTP sense here - I 
meant they can be replaced by some other URIs and than resolved to what 
these URIs refer to, and the latter of them needn't necessarily be 
'http' URIs.

>
>
> 2.2.1. Special-Purpose 'about' URIs
>
>    A small, though expandable, range of s are reserved for
>    use in special-purpose 'about' URIs, abbreviated "SPU" (special-
>    purpose URI).  Such tokens are named "special-purpose 'about' URI
>    tokens", and abbreviated "SPT" (special-purpose token).
>
>    An SPU is an 'about' URI containing one of the registered SPTs as the
>  part.  An SPU MUST be handled in strict accordance with
>    the rules defined for SPT contained therein.  The SPT specification
>    MAY define additional provisions on handling of  part in
>    the corresponding SPU; by default, it MUST be ignored for the purpose
>    of handling SPU.
>
> Where is this requirement coming from? Is this common behaviour among
> existing browsers?

We still haven't had such a term as 'special-purpose about URI', and so 
we can't speak of common behavior.  IMO, taking into account the 
intended semantics of SPUs, if the meaning of query isn't defined, it 
must be ignored not to eliminate the said semantics and their utility.

>
>    SPU MAY be defined to be unresolvable.  This means that an
>    application MUST NOT resolve it in some particular resource.  Such
>    SPUs may be used as placeholders, or in some other way.
>
> I fail to see utility in this. Can you maybe provide an example
> of an unresolvable about URI?
> (This might also affect the IANA registration section which includes
> this flag in the token registration template.)

That is what HTML5 wants to define (actually, defines).  we had a 
discussion on this previously.

>
>
> 2.2.2. Unrecognized 'about' URIs
>
>    Naturally, an application will support only a particular range of
>    'about' URIs; also, some applications will support 'about' URIs that
>    are not supported by an other one.  This document specifies the rules
>    for handling unrecognized 'about' URIs.
>
>    An unrecognized 'about' URIs as a URI that may not be recognized by
>    an application.  (Correspondingly, such categorization is per-
>    application, not per-fact.)
>
> I don't understand the comment in () and I don't think it adds any value
> anyway.

It means that 'about' URI can't be defined to be unrecognized - this all 
depends on application.

>
>    An unrecognized 'about' URI SHOULD be
>    handled as the  URI, although other behavior is
>    possible.
>
> Is there a reason why this is a SHOULD? This seems rather strong here.
> I am thinking that displaying an error about unrecognized token would be
> another reasonable choice. In fact it would be my preferred choice.

This is for what I place SHOULD.  And this *is* common behavior.

>
> 2.3. Encoding Considerations
>
>    'about' URIs are subject to encoding rules defined in RFC 3986
>    [RFC3986].  'about' IRIs [RFC3987] are not permitted.
>
> The last quoted sentence: why?
> If an about URI is used to edit configuration, I can see some Unicode 
> being
> passed in the query part of such URI.

We have no evidence of use.  That is the reason.

>
>
>
> 4.2. A Registry for SPTs
>
>    The registration policy for new entries is "Specification Required",
>
> This was already discussed in the face to face meeting and I will 
> comment on this separately. (Yes, I think this is too restrictive.)

I'll wait for your further comment on this before replying (though my 
opinion has been stated to WG).

Mykyta Yevstifeyev

>
>



From Vladimir.Levantovsky@MonotypeImaging.com  Wed Nov 16 12:01:40 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A2321F9016 for ; Wed, 16 Nov 2011 12:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.242
X-Spam-Level: 
X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.357,  BAYES_00=-2.599, 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 SWkOca+Ak6pa for ; Wed, 16 Nov 2011 12:01:40 -0800 (PST)
Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7971F0C45 for ; Wed, 16 Nov 2011 12:01:39 -0800 (PST)
Received: from wob-email-01.agfamonotype.org ([209.113.171.111]) (using TLSv1) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP ID DSNKTsQWkg6ZFPjcgiJmWZWr1sXTu1z5Da3Q@postini.com; Wed, 16 Nov 2011 12:01:39 PST
Received: from WOB-EMAIL-01.agfamonotype.org ([192.168.50.7]) by wob-email-01.agfamonotype.org ([192.168.50.7]) with mapi; Wed, 16 Nov 2011 15:01:21 -0500
From: "Levantovsky, Vladimir" 
To: Peter Saint-Andre 
Date: Wed, 16 Nov 2011 15:01:20 -0500
Thread-Topic: [apps-discuss] font/* (and draft-freed-media-type-regs)
Thread-Index: AcykBdaNeVMOyBtlS4CbjFC4bg4jqAAkwQXQ
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org>
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im>
In-Reply-To: <4EC31D1D.1000509@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Chris Lilley , Ned Freed , David Singer , "apps-discuss@ietf.org" , "gadams@xfsi.com Adams" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 20:01:40 -0000

QWRkaW5nIENocmlzIExpbGxleSBmcm9tIFczQw0KDQoNCk9uIFR1ZXNkYXksIE5vdmVtYmVyIDE1
LCAyMDExIDk6MTcgUE0gUGV0ZXIgU2FpbnQtQW5kcmUgd3JvdGU6DQo+IA0KPiBPbiAxMS8xNi8x
MSA3OjIyIEFNLCBMZXZhbnRvdnNreSwgVmxhZGltaXIgd3JvdGU6DQo+IA0KPiA+IEhvd2V2ZXIs
IHRoZSBzZW50aW1lbnRzIGV4cHJlc3NlZCBhdCB0aGUgdGltZSB3ZXJlIHZlcnkgc2ltaWxhciB0
bw0KPiA+IHRoaXMgZGlzY3Vzc2lvbjsgSSB3YXMgdG9sZCB0aGF0IGFwcGx5aW5nIGZvciBhIG5l
dyB0b3AtbGV2ZWwgdHlwZQ0KPiA+IHdhcyAiQSBCSUcgTk8tTk8iLCB0aGF0IHByaW9yIGF0dGVt
cHRzIHRvIHJlZ2lzdGVyIGZvbnQvKiBmYWlsZWQsIGFuZA0KPiA+IHRoYXQgdW5sZXNzIEkgYW0g
d2lsbGluZyB0byBkZWRpY2F0ZSBzaWduaWZpY2FudCBwYXJ0IG9mIG15IGxpZmUgdG8NCj4gPiB0
aGlzIGFjdGl2aXR5IChpLmUuIGFwcGx5aW5nIGFuZCBsb2JieWluZyBmb3IgYSBuZXcgdG9wLWxl
dmVsICJmb250Ig0KPiA+IHR5cGUpIHRoZSBlZmZvcnQgd291bGQgbW9zdCBsaWtlbHkgZ2V0IHVz
IG5vd2hlcmUuDQo+IA0KPiBQZXJoYXBzIEkgYW0gbWlzdGFrZW4sIGJ1dCBJIHJlYWQgdGhlIGRp
c2N1c3Npb24gZGlmZmVyZW50bHk6IEkgc2VlIGFuDQo+IG9wZW5uZXNzIHRvIHJlZ2lzdGVyaW5n
IGZvbnQvKiBub3cuDQo+IA0KDQpZZXMuIEkgZ3Vlc3MgSSBzaG91bGQndmUgYmVlbiBtb3JlIHNw
ZWNpZmljIGFuZCBzaG91bGQgaGF2ZSBzYWlkIHRoYXQgdGhlIHNlbnRpbWVudHMgZXhwcmVzc2Vk
IGZldyB5ZWFycyBhZ28gd2VyZSBzaW1pbGFyIHRvIHdoYXQgd2FzIG1lbnRpb25lZCBhcyBwYXJ0
IG9mIHRoaXMgZGlzY3Vzc2lvbiAob3IgYXMgcXVvdGVkIGZyb20gcHJpb3IgZGlzY3Vzc2lvbnMp
LiBJIGRvIHNlZSBhIG11Y2ggbW9yZSBvcGVuLW1pbmRlZCBwb3NpdGlvbiB0byByZWdpc3Rlcmlu
ZyBmb250Lyogbm93IC0gdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlcmUgaXMgc3RpbGwgYSB1
dGlsaXR5IHZhbHVlIGxlZnQgaW4gZG9pbmcgdGhpcyAoc2luY2Ugd2UgYWxyZWFkeSBoYXZlIHF1
aXRlIGEgZmV3IGZvbnQtKiBzdWJ0eXBlcyByZWdpc3RlcmVkIHVuZGVyIHRoZSBhcHBsaWNhdGlv
bi8qIHRyZWUuDQoNCk15IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCByZWdpc3RlcmluZyBmb250
LyogdHlwZSBzdGlsbCBtYWtlcyBhIGxvdCBvZiBzZW5zZSBhbmQgdGhpcyBpcyBzb21ldGhpbmcg
d2UgbmVlZCB0byBkbywgZXZlbiBpZiBpdCBpbnZvbHZlcyByZS1yZWdpc3RlcmluZyBzb21lIG9m
IHRoZSBleGlzdGluZyBzdWJ0eXBlcyB1bmRlciB0aGUgbmV3IGZvbnQvKiB0cmVlLiBJIGJyb3Vn
aHQgdGhpcyB1cCBmb3IgZGlzY3Vzc2lvbiBhdCB0b2RheSdzIGNvbmZlcmVuY2UgY2FsbCB3aXRo
IFczQyBXZWJGb250cyBXRywgYW5kIHRoZSBnZW5lcmFsIG9waW5pb24gd2FzIHRoYXQgaGF2aW5n
IGZvbnQvKiB0eXBlIHJlZ2lzdGVyZWQgd291bGQgc3RpbGwgYmUgYSBnb29kIHRoaW5nIGZvciB0
aGUgaW5kdXN0cnkuDQoNClRoYW5rIHlvdSwNClZsYWQNCg0K

From barryleiba.mailing.lists@gmail.com  Wed Nov 16 18:23:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0E21F0CA2 for ; Wed, 16 Nov 2011 18:23:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.684
X-Spam-Level: 
X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 9Dd-xM9Ry2t6 for ; Wed, 16 Nov 2011 18:23:17 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 689C71F0CA0 for ; Wed, 16 Nov 2011 18:23:17 -0800 (PST)
Received: by ywt34 with SMTP id 34so528786ywt.31 for ; Wed, 16 Nov 2011 18:23:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+s2hEcVa30aQSEX9bxUTpYKLLzX4CYnwaVe6FxDsJXc=; b=HsIvkVSU8pOG7/d3pjXAsZo8EmDceG3+dtqOmLgkW3k69vuMYeL8l/wD32JIE9XRI4 VffnWD/XRPoJauL1dpaCdv8XN9mZgww2+4Q3bG95ZJI/kDD4r7MdC6vD3q2lQxW7kcbK wiYsd2cdWc8TpD82l7mODNfVwLtuv4smZWow8=
MIME-Version: 1.0
Received: by 10.236.79.38 with SMTP id h26mr5908875yhe.39.1321496597051; Wed, 16 Nov 2011 18:23:17 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.250.14 with HTTP; Wed, 16 Nov 2011 18:23:16 -0800 (PST)
In-Reply-To: <4EC40EC3.9080304@gmail.com>
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com> <4EC40EC3.9080304@gmail.com>
Date: Wed, 16 Nov 2011 21:23:16 -0500
X-Google-Sender-Auth: _DcgjUqqTTHCqjHMdooi3BoRM88
Message-ID: 
From: Barry Leiba 
To: =?UTF-8?B?TXlreXRhIFlldnN0aWZleWV2ICjQnC4g0ITQstGB0YLRltGE0LXRlNCyKQ==?= 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 02:23:19 -0000

Responding to Alexey's comments and Mykyta's response to them, and
adding my own review:

I find the Introduction section to be pontificating, and I suggest
avoiding that.  I'm talking about the reference to "Easter Eggs"
and the rambling about the friendliness of about URIs compared
with point-and-click interfaces.  I'm not going to pick on that
further, but just think about taking some of that out.

In the ABNF in 2.1:

- By defining about-token as "segment", you're allowing these:

  about:
  about:?banana
  about::::

  Are you sure you don't want to define it as "segment-nz", or
  even "segment-nz-nc".

- I think the definition of "about-query" is correct.

With reference to Alexey's comment about "redirect", if you hadn't
ignored my review comments before, when you sent the wrong version
for review, you'd have seen that I had comments on that as well.
It's just wrong, and it needs to be fixed.

In fact, let me take this opportunity to repeat the essence of my
ignored comments.  Please do not ignore them this time.

One general comment:
Throughout the document, there are non-normative "may" and "should".
People -- WG participants, last-call commenters, and ADs -- often push
on those and look to have them changed to words that don't look so
much like 2119 keywords, despite their being in lower case.  We
usually change "may" to "might" or "can", depending upon context.  The
"should" cases are harder, but do try to rephrase things to avoid
using "should".  I hate this silly exercise, but it does save trouble
with the nitpickers later.

Also, I suggest changing the single quote to a double quote, so
"about" instead of 'about' (and I think the RFC Editor will do this
anyway, if you don't).  You can do this in the XML by switching the
quote marks:
OLD: 

NEW: 


[...] I also don't like
how the "redirect" part is put, because I think it might lead some to
think that "about" URIs might often redirect to other resources on the
Internet (imagine, say, "about:me?barryleiba" redirecting to my web
site, Facebook page, or some such).  How about this?:

OLD
   Therefore any application MAY resolve an 'about' URI to any
   desired resource, and MAY redirect such URIs.  Several exceptions are
   defined, though; they are named "special-purpose 'about' URIs" and
   MUST be handled in strict accordance with provisions set in Section
   2.2.1.

NEW
  Any application resolving an "about" URI MAY
  choose the resource it is resolved to at its own discretion, with the
  exception of those defined below as 'special-purpose "about" URIs'.
  They MAY use internal redirection to accomplish this  (for
  instance, Opera redirects all "about" URIs except "about:blank"
  to its internal "opera" URIs).


Section 4.1:
OLD
   IANA is asked to update the register the 'about' URI scheme
   using the following template, per [RFC4395]:

It's useful to be very specific about the registry you want.

NEW
  IANA is asked to register the "about" URI scheme in the
  "URI Schemes" registry defined in section 5.4 of RFC 4395
  [RFC4395]:


I don't think it's appropriate to specify the general IETF
discussion list as the contact point (Author/Change controller).
Put something "real" in there.


Section 4.2:
OLD
   IANA is asked to set up a new registry entitled "'about'
   URIs SPTs" following the guidelines below.

In English, we don't use plurals like this.  We say "tool box", not
"tools box", for example.  We should also expand the "SPT"
abreviation in the registry name.

NEW
   IANA is asked to set up a new registry entitled "'about'
   URI Special Purpose Tokens" following the guidelines below.


Now, back to the new stuff.  I think the whole section on
special-purpose stuff (2.2.1) becomes convoluted by being full of
"SPT" and "SPU".  It's excessive.  Let me try to re-work the whole
section here.  The "unresolvable" paragraph makes no sense to me,
and I see no use case for it.  Unless there's been a documented
need for it, we should not have it here.  I've eliminated that
paragraph in my re-write.  I know you said something about HTML5,
but you need to be more specific before we can add this.
Remember: as a document editor, you may not just add things as you
please.  We need consensus to add them.

NEW
--------------------------

A small, though expandable, range of s are reserved
for special purposes ("special-purpose tokens").

A special-purpose URI is an 'about' URI that has a special-purpose
token as its  part.  Such URIs MUST be handled in
strict accordance with the rules defined in the special-purpose
token registry (see Section 4.2).  The registered entry MAY also
define additional provisions for handling of the 
part.  If no such provisions are defined, the query part has no
meaning, and MUST be ignored.

This document defines one special-purpose token: "blank".
The URI "about:blank" MUST resolve to a blank page, as seen by
the end user. There is no additional handling of the query
component in "about:blank" URIs.

Additional special-purpose tokens can be defined by registering
an registry created in Section 4.2. Special-purpose "about" URIs
are intended to be uncommon, and new ones should be defined only
when there is a need to strongly connect a particular
 with a particular function in all applications.

--------------------------

Section 2.2.2

The first paragraph is pointless; please remove it.

The second paragraph is full of problems, some of which Alexey
commented on:

OLD
 An unrecognized 'about' URIs as a URI that may not be recognized by
 an application.  (Correspondingly, such categorization is per-
 application, not per-fact.)  An unrecognized 'about' URI SHOULD be
 handled as the  URI, although other behavior is
 possible.

For the first sentence, I think you mean, "An unrecognized URI is
a URI that is not recognized by a particular application."
Again, that's kind of pointless, but OK for now.  The sentence in
parentheses is simply not comprehensible.  I *think* you mean what
I've captured in my rewrite of the first sentence, by adding the
word "particular".  So let's remove that.

But the main point is this: how is *interoperability* affected by
the SHOULD in the third sentence?  Not at all.  In any case, I
can't see any justification for something as strong as SHOULD.
I suggest that this whole thing be made non-normative, this way:

NEW
When an application does not recognize a particular "about" URI,
common practice is to handle it in the same way as "about:blank",
though other handling is possible.


Now for the meaty issue: the registration policy for the new
registry in Section 4.2.  As I suggested in my ignored message:

I don't think the registry needs "Specification Required", which
implies expert review; I think that's overkill, and that there's no
need for any expert review to be done.  I think we should use First
Come First Served, and specify the level of documentation we want
available.  Something like this (adjust as needed):

NEW
  The registration procedures for this registry are "First Come First
  Served', described in RFC 5226 [RFC5226], with supporting
  documentation meeting the requirements below.  The registrant
  of the token MUST provide the following registration template,
  which will be made available on IANA web site:
...
    Specification.  REQUIRED field.  This provides documentation
    at a level that could be used to create a compliant, interoperable
    implementation of the registered "about" URI.  The full
    specification SHOULD be included here, but it MAY be a
    reference to a document published elsewhere, if there is a
    reasonable expectation that the documentation will remain
    available.  IANA will consult with the IESG or its specified
    delegate if there is doubt about whether the specification is
    adequate for the purpose.

This provides for a sort of "expert review" only to determine whether
the documentation is suitable, and does not have an expert at the gate
to block registrations.  I think this is a perfect example of a
registry where we'd rather have things registered and documented than
not, so encouraging that with minimal hassle and minimal risk for
rejection is best.

This mechanism is what had consensus in the room in Taipei.  We
can discuss it on the mailing list now.

Barry

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Wed Nov 16 20:10:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EEB21F9460 for ; Wed, 16 Nov 2011 20:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.164
X-Spam-Level: 
X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_55=0.6, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, 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 w9TOg8jJtO0i for ; Wed, 16 Nov 2011 20:10:24 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2C6421F8C0E for ; Wed, 16 Nov 2011 20:10:23 -0800 (PST)
Received: by wyf28 with SMTP id 28so1621198wyf.31 for ; Wed, 16 Nov 2011 20:10:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=kpxfO0LETu7tEhHOG/FmADWj04ww2ZglHKUudhj3e6o=; b=hhrT7LTSxPUkx/q1/h8c/jodElpd+wu+KT86+uM8EVCJ42Uv4w/rop7gT4xY6Lp/NP qk1fXuR0/SA1XcCQhHRfI54ekABqhfKvS7CEzzVJlMMUA9MUIFGefRV+hQYCEsO66Glh iIVIgWCQc7v/WEBoClSyQXNbzCGviLrE6z6/A=
Received: by 10.216.72.145 with SMTP id t17mr1092128wed.88.1321503023120; Wed, 16 Nov 2011 20:10:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.184.147 with HTTP; Wed, 16 Nov 2011 20:09:41 -0800 (PST)
In-Reply-To: <4EC40EC3.9080304@gmail.com>
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com> <4EC40EC3.9080304@gmail.com>
From: Frank Ellermann 
Date: Thu, 17 Nov 2011 05:09:41 +0100
Message-ID: 
To: =?UTF-8?B?TXlreXRhIFlldnN0aWZleWV2ICjQnC4g0ITQstGB0YLRltGE0LXRlNCyKQ==?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 04:10:25 -0000

2011/11/16 "Mykyta Yevstifeyev (=D0=9C. =D0=84=D0=B2=D1=81=D1=82=D1=96=D1=
=84=D0=B5=D1=94=D0=B2)" wrote:

>> =C2=A0 'about' URIs are subject to encoding rules defined in RFC 3986
>> =C2=A0 [RFC3986]. =C2=A0'about' IRIs [RFC3987] are not permitted.

>> The last quoted sentence: why?
>> If an about URI is used to edit configuration, I can see some Unicode
>> being
>> passed in the query part of such URI.

> We have no evidence of use. =C2=A0That is the reason.

Strong objection.  about: URIs are the territory of UA implementors.
They are free to do anything they like as long as it is compatible
with 3986/3987 and doesn't break .

For example they are free to create an equivalent of about:mozilla in
any language plus appropriate script.  They are also free to create
say about:punycode?=C3=A4=C3=B6=C3=BC.de as a service (maybe a stupid plan,=
 but
about: URIs and IRIs can be stupid.)

They are also free to use slashes in their about URIs, and I have no
evidence that this never happened anywhere.  With slashes you'd get
maybe "path-rootless" or similar, not only "segment-nz".

The purpose of the draft should be to get the about: URIs registered
without twisting them into something they are not.  And as user of UAs
with poor documentation which essential about: URIs exist in the UA,
e.g., about:support in newer Firefox versions, I'd really like a hint
that offering an about:about list will beat "Google it" as a manual.

-Frank

From paul.hoffman@vpnc.org  Wed Nov 16 22:16:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8052A21F979A for ; Wed, 16 Nov 2011 22:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.956
X-Spam-Level: 
X-Spam-Status: No, score=-101.956 tagged_above=-999 required=5 tests=[AWL=0.643, 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 LtBNS5g9BCQM for ; Wed, 16 Nov 2011 22:16:18 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EB08621F9799 for ; Wed, 16 Nov 2011 22:16:17 -0800 (PST)
Received: from dhcp-2121.meeting.ietf.org (dhcp-2121.meeting.ietf.org [130.129.33.33]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAH6GFrj097210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 16 Nov 2011 23:16:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
From: Paul Hoffman 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 17 Nov 2011 14:16:17 +0800
References: <20111117045856.117E6B1E003@rfc-editor.org>
To: apps-discuss Discuss 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Subject: [apps-discuss] Fwd: RFC 6449 on Complaint Feedback Loop Operational Recommendations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 06:16:18 -0000

Of interest to folks here...

Begin forwarded message:

> From: rfc-editor@rfc-editor.org
> Subject: RFC 6449 on Complaint Feedback Loop Operational Recommendations
> Date: November 17, 2011 12:58:54 PM GMT+08:00
> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
> Cc: rfc-editor@rfc-editor.org
> 
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>        RFC 6449
> 
>        Title:      Complaint Feedback Loop Operational Recommendations 
>        Author:     J. Falk, Ed.
>        Status:     Informational
>        Stream:     IETF
>        Date:       November 2011
>        Mailbox:    ietf@cybernothing.org
>        Pages:      31
>        Characters: 75139
>        Updates/Obsoletes/SeeAlso:   None
> 
>        I-D Tag:    draft-jdfalk-maawg-cfblbcp-03.txt
> 
>        URL:        http://www.rfc-editor.org/rfc/rfc6449.txt
> 
> Complaint Feedback Loops similar to those described herein have
> existed for more than a decade, resulting in many de facto standards
> and best practices.  This document is an attempt to codify, and thus
> clarify, the ways that both providers and consumers of these feedback
> mechanisms intend to use the feedback, describing some already common
> industry practices.
> 
> This document is the result of cooperative efforts within the
> Messaging Anti-Abuse Working Group, a trade organization separate
> from the IETF.  The original MAAWG document upon which this document
> is based was published in April, 2010.  This document does not
> represent the consensus of the IETF; rather it is being published as
> an Informational RFC to make it widely available to the Internet
> community and simplify reference to this material from IETF work.
> This document is not an Internet Standards Track specification; it is
> published for informational purposes.
> 
> 
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.


From stpeter@stpeter.im  Wed Nov 16 22:17:12 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4C721F97A0 for ; Wed, 16 Nov 2011 22:17:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.542
X-Spam-Level: 
X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 Inshiv4hwXnb for ; Wed, 16 Nov 2011 22:17:07 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9F51421F979D for ; Wed, 16 Nov 2011 22:17:07 -0800 (PST)
Received: from dhcp-1422.meeting.ietf.org (unknown [130.129.20.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B2A79421AB; Wed, 16 Nov 2011 23:23:24 -0700 (MST)
Message-ID: <4EC4A6E0.6000503@stpeter.im>
Date: Thu, 17 Nov 2011 14:17:04 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Paul Hoffman 
References: <20111117045856.117E6B1E003@rfc-editor.org> 
In-Reply-To: 
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss Discuss 
Subject: Re: [apps-discuss] Fwd: RFC 6449 on Complaint Feedback Loop Operational Recommendations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 06:17:12 -0000

Good work. Congratulations to all involved.

On 11/17/11 2:16 PM, Paul Hoffman wrote:
> Of interest to folks here...
> 
> Begin forwarded message:
> 
>> From: rfc-editor@rfc-editor.org
>> Subject: RFC 6449 on Complaint Feedback Loop Operational Recommendations
>> Date: November 17, 2011 12:58:54 PM GMT+08:00
>> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
>> Cc: rfc-editor@rfc-editor.org
>>
>>
>> A new Request for Comments is now available in online RFC libraries.
>>
>>
>>        RFC 6449
>>
>>        Title:      Complaint Feedback Loop Operational Recommendations 
>>        Author:     J. Falk, Ed.
>>        Status:     Informational
>>        Stream:     IETF
>>        Date:       November 2011
>>        Mailbox:    ietf@cybernothing.org
>>        Pages:      31
>>        Characters: 75139
>>        Updates/Obsoletes/SeeAlso:   None
>>
>>        I-D Tag:    draft-jdfalk-maawg-cfblbcp-03.txt
>>
>>        URL:        http://www.rfc-editor.org/rfc/rfc6449.txt
>>
>> Complaint Feedback Loops similar to those described herein have
>> existed for more than a decade, resulting in many de facto standards
>> and best practices.  This document is an attempt to codify, and thus
>> clarify, the ways that both providers and consumers of these feedback
>> mechanisms intend to use the feedback, describing some already common
>> industry practices.
>>
>> This document is the result of cooperative efforts within the
>> Messaging Anti-Abuse Working Group, a trade organization separate
>> from the IETF.  The original MAAWG document upon which this document
>> is based was published in April, 2010.  This document does not
>> represent the consensus of the IETF; rather it is being published as
>> an Informational RFC to make it widely available to the Internet
>> community and simplify reference to this material from IETF work.
>> This document is not an Internet Standards Track specification; it is
>> published for informational purposes.
>>
>>
>> INFORMATIONAL: This memo provides information for the Internet community.
>> It does not specify an Internet standard of any kind. Distribution of
>> this memo is unlimited.
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From msk@cloudmark.com  Wed Nov 16 22:23:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FDF11E8133 for ; Wed, 16 Nov 2011 22:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.307
X-Spam-Level: 
X-Spam-Status: No, score=-103.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, 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 MSNmgQNQGB10 for ; Wed, 16 Nov 2011 22:23:39 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 294D911E8130 for ; Wed, 16 Nov 2011 22:23:39 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 16 Nov 2011 22:23:35 -0800
From: "Murray S. Kucherawy" 
To: apps-discuss Discuss 
Date: Wed, 16 Nov 2011 22:23:34 -0800
Thread-Topic: [apps-discuss] Fwd: RFC 6449 on Complaint Feedback Loop Operational Recommendations
Thread-Index: Acyk8I/KgEDKto9fT3ChlROc1b5r5gAAMzzA
Message-ID: 
References: <20111117045856.117E6B1E003@rfc-editor.org>  <4EC4A6E0.6000503@stpeter.im>
In-Reply-To: <4EC4A6E0.6000503@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Fwd: RFC 6449 on Complaint Feedback Loop Operational Recommendations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 06:23:42 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Peter Saint-Andre
> Sent: Wednesday, November 16, 2011 10:17 PM
> To: Paul Hoffman
> Cc: apps-discuss Discuss
> Subject: Re: [apps-discuss] Fwd: RFC 6449 on Complaint Feedback Loop Oper=
ational Recommendations
>=20
> Good work. Congratulations to all involved.

+1.  And that's perhaps the biggest "+1" I've ever dropped.

From msk@cloudmark.com  Wed Nov 16 22:52:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D4C21F97F0 for ; Wed, 16 Nov 2011 22:52:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.309
X-Spam-Level: 
X-Spam-Status: No, score=-103.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, 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 buIZZN8bnzlS for ; Wed, 16 Nov 2011 22:52:36 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1408121F97EF for ; Wed, 16 Nov 2011 22:52:35 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 16 Nov 2011 22:52:35 -0800
From: "Murray S. Kucherawy" 
To: apps-discuss Discuss 
Date: Wed, 16 Nov 2011 22:52:34 -0800
Thread-Topic: [apps-discuss] Fwd: RFC 6449 on Complaint Feedback Loop Operational Recommendations
Thread-Index: Acyk8I/KgEDKto9fT3ChlROc1b5r5gAAMzzAAADq0KA=
Message-ID: 
References: <20111117045856.117E6B1E003@rfc-editor.org>  <4EC4A6E0.6000503@stpeter.im> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Fwd: RFC 6449 on Complaint Feedback Loop Operational Recommendations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 06:52:41 -0000

> > Good work. Congratulations to all involved.
>=20
> +1.  And that's perhaps the biggest "+1" I've ever dropped.

...and now, to explain why:

The author of RFC6449 has been battling illness for much of this year.  As =
his illness suddenly became quite grave, we asked for the support of MARF's=
 Area Director and the RFC Editor team to help advance his document to publ=
ication hoping he would enjoy seeing it published.

The staff's effort to expedite publication was extraordinary.  There's quit=
e a bit of work to the process and it normally would have taken another mon=
th or two.  The technical editor Stateside stayed up all night to complete =
her part of the process.

The publication announcement came about 20 minutes before his passing.  I f=
orwarded it, and it was read into his room moments before he left us.

My heartfelt thanks, and those of his myriad friends and family back home, =
go to those who helped to make this happen.


From alexey.melnikov@isode.com  Wed Nov 16 22:56:45 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB7F11E809B for ; Wed, 16 Nov 2011 22:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sixdaDkxklHL for ; Wed, 16 Nov 2011 22:56:44 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 82C5D11E8083 for ; Wed, 16 Nov 2011 22:56:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1321513003; d=isode.com; s=selector; i=@isode.com; bh=xcDTQhDQGO263BKM/O3zq6T+gnqz3gc+by1BhZAdoGU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=pwjn6VuV434JW3WEcnl9xg+enicfX0rqVv8C4YEFJUy3IoJBv17pHo7fZyBOCVILjxLDPr pg8i2VLFva+zz25yyjdZegqSTExzBPc39cy06nsNP/bEeEhWf7ws20Sa4UCjQe6GH51vpq 15dGvq3Q4pvw1uW4fNOrbckSwM5KdGQ=;
Received: from [130.129.18.66] (dhcp-1242.meeting.ietf.org [130.129.18.66])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Thu, 17 Nov 2011 06:56:42 +0000
Message-ID: <4EC4B024.50503@isode.com>
Date: Thu, 17 Nov 2011 06:56:36 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: "apps-discuss@ietf.org" 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Acceptance of MIME type registration document as an APPSAWG document
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 06:56:45 -0000

Hi
During Quebec IETF there were some indication in the APPSAWG WG meeting 
that draft-freed-media-type-regs should be adopted as a APPSAWG 
document. Based on active discussions of the document on this mailing I 
conclude that there is clear support for working on it. If you have any 
objections to accepting this document as the WG document, please speak 
up before November 25th.

Alexey,
As an APPSAWG co-chair.



From ietfc@btconnect.com  Thu Nov 17 05:01:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F63C1F0C69 for ; Thu, 17 Nov 2011 05:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.378
X-Spam-Level: 
X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221,  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 bczKdD24uTH6 for ; Thu, 17 Nov 2011 05:01:53 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD461F0C4F for ; Thu, 17 Nov 2011 05:01:52 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2bthomr07.btconnect.com with SMTP id FIM66062; Thu, 17 Nov 2011 13:01:13 +0000 (GMT)
Message-ID: <042901cca51f$d3ff60c0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Levantovsky, Vladimir" 
References: <4EC0C2C8.2010500@it.aoyama.ac.jp><01O8EV98HXC800RCTX@mauve.mrochek.com><99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com><7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org><4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org>
Date: Thu, 17 Nov 2011 12:55:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4EC50597.003E, actions=TAG
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.17.111815:17:7.944, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_1700_1799, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS
X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4EC5059A.019B,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine
X-Junkmail-IWF: false
Cc: Chris Lilley , David Singer , apps-discuss@ietf.org, gadams@xfsi.com
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 13:01:59 -0000

----- Original Message -----
From: "Levantovsky, Vladimir" 
To: "Peter Saint-Andre" 
Cc: "Chris Lilley" ; "Ned Freed" ; "David
Singer" ; ; 
Sent: Wednesday, November 16, 2011 9:01 PM
> Adding Chris Lilley from W3C
>
> On Tuesday, November 15, 2011 9:17 PM Peter Saint-Andre wrote:
> >
> > On 11/16/11 7:22 AM, Levantovsky, Vladimir wrote:
> >
> > > However, the sentiments expressed at the time were very similar to
> > > this discussion; I was told that applying for a new top-level type
> > > was "A BIG NO-NO", that prior attempts to register font/* failed, and
> > > that unless I am willing to dedicate significant part of my life to
> > > this activity (i.e. applying and lobbying for a new top-level "font"
> > > type) the effort would most likely get us nowhere.
> >
> > Perhaps I am mistaken, but I read the discussion differently: I see an
> > openness to registering font/* now.
> >
> > My personal opinion is that registering font/* type still makes a lot of
sense and this is something we need to do, even if it involves re-registering
some of the existing subtypes under the new font/* tree. I brought this up for
discussion at today's conference call with W3C WebFonts WG, and the general
opinion was that having font/* type registered would still be a good thing for
the industry.
>
Vlad

Just to be clear, what meaning does WebFonts attach to 'font', were it an object
class, how would it be characterised?  This thread has shown a number of
different meanings of the term and I am not familiar with the work of W3C.

Tom Petch

> Thank you,
> Vlad
>


From tianlinyi@huawei.com  Thu Nov 17 06:10:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DD811E8126 for ; Thu, 17 Nov 2011 06:10:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 BjJxS4tmSAgK for ; Thu, 17 Nov 2011 06:10:38 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id F0C1F11E80E4 for ; Thu, 17 Nov 2011 06:10:34 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUT002PQ5XRQ3@szxga03-in.huawei.com> for apps-discuss@ietf.org; Thu, 17 Nov 2011 22:08:15 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUT008D85XR6D@szxga03-in.huawei.com> for apps-discuss@ietf.org; Thu, 17 Nov 2011 22:08:15 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFD47142; Thu, 17 Nov 2011 22:07:11 +0800
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Nov 2011 22:07:04 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Thu, 17 Nov 2011 22:06:59 +0800
Date: Thu, 17 Nov 2011 14:06:59 +0000
From: TianLinyi 
In-reply-to: <042901cca51f$d3ff60c0$4001a8c0@gateway.2wire.net>
X-Originating-IP: [172.24.2.41]
To: "t.petch" , "Levantovsky, Vladimir" 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA1820227B@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [apps-discuss] font/* (and draft-freed-media-type-regs)
Thread-index: AQHMpR/QnPX+VrnbTTGaIgyaA9nG5pWxGVU8
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <042901cca51f$d3ff60c0$4001a8c0@gateway.2wire.net>
Cc: Chris Lilley , David Singer , "apps-discuss@ietf.org" , "gadams@xfsi.com" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 14:10:39 -0000

SGksIEFsbA0KDQpTaW5jZSB0aGVyZSBpcyBubyBjbGVhciBhZHZhbnRhZ2UgZm9yIGJvdGggd2F5
cywgaXMgdGhlcmUgYW55IGd1aWRhbmNlIG9uIGhvdyB0byBtYWtlIGEgZGVjaXNpb24/IEkgdGhp
bmsgd2UgZG9uJ3QgbmVlZCB0byBzcGVuZCB0b28gbXVjaCB0aW1lIG9uIHRoaXMuIE1heWJlIGl0
IGlzIHRoZSB0aW1lIHRvIG1ha2UgYSBjaG9pY2Ugbm93IGJhc2VkIG9uIHJvdWdoIGNvbnNlbnN1
cywgcmlnaHQ/IE9yIGlmIHRoZXJlIGlzIGFuIGFsdGVybmF0aXZlIHdheSB0byBnZXQgZ3VpZGFu
Y2UgZnJvbSBzb21ld2hlcmUgaW4gSUVURiBmaXJzdCByZWdhcmRpbmcgaG93IHRvIGNyZWF0ZSBh
IHRvcCBsZXZlbCByZWdpc3RyeT8NCg0KQ2hlZXJzLA0KTGlueWkNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBhcHBzLWRpc2N1c3MtYm91bmNlc0Bp
ZXRmLm9yZyBbYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gdC5wZXRjaCBbaWV0
ZmNAYnRjb25uZWN0LmNvbV0NCreiy83KsbzkOiAyMDExxOoxMdTCMTfI1SAxOTo1NQ0Ktb06IExl
dmFudG92c2t5LCBWbGFkaW1pcg0KQ2M6IENocmlzIExpbGxleTsgRGF2aWQgU2luZ2VyOyBhcHBz
LWRpc2N1c3NAaWV0Zi5vcmc7IGdhZGFtc0B4ZnNpLmNvbQ0K1vfM4jogUmU6IFthcHBzLWRpc2N1
c3NdIGZvbnQvKiAoYW5kIGRyYWZ0LWZyZWVkLW1lZGlhLXR5cGUtcmVncykNCg0KLS0tLS0gT3Jp
Z2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkxldmFudG92c2t5LCBWbGFkaW1pciIgPFZsYWRp
bWlyLkxldmFudG92c2t5QE1vbm90eXBlSW1hZ2luZy5jb20+DQpUbzogIlBldGVyIFNhaW50LUFu
ZHJlIiA8c3RwZXRlckBzdHBldGVyLmltPg0KQ2M6ICJDaHJpcyBMaWxsZXkiIDxjaHJpc0B3My5v
cmc+OyAiTmVkIEZyZWVkIiA8bmVkLmZyZWVkQG1yb2NoZWsuY29tPjsgIkRhdmlkDQpTaW5nZXIi
IDxzaW5nZXJAYXBwbGUuY29tPjsgPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz47IDxnYWRhbXNAeGZz
aS5jb20+DQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE2LCAyMDExIDk6MDEgUE0NCj4gQWRk
aW5nIENocmlzIExpbGxleSBmcm9tIFczQw0KPg0KPiBPbiBUdWVzZGF5LCBOb3ZlbWJlciAxNSwg
MjAxMSA5OjE3IFBNIFBldGVyIFNhaW50LUFuZHJlIHdyb3RlOg0KPiA+DQo+ID4gT24gMTEvMTYv
MTEgNzoyMiBBTSwgTGV2YW50b3Zza3ksIFZsYWRpbWlyIHdyb3RlOg0KPiA+DQo+ID4gPiBIb3dl
dmVyLCB0aGUgc2VudGltZW50cyBleHByZXNzZWQgYXQgdGhlIHRpbWUgd2VyZSB2ZXJ5IHNpbWls
YXIgdG8NCj4gPiA+IHRoaXMgZGlzY3Vzc2lvbjsgSSB3YXMgdG9sZCB0aGF0IGFwcGx5aW5nIGZv
ciBhIG5ldyB0b3AtbGV2ZWwgdHlwZQ0KPiA+ID4gd2FzICJBIEJJRyBOTy1OTyIsIHRoYXQgcHJp
b3IgYXR0ZW1wdHMgdG8gcmVnaXN0ZXIgZm9udC8qIGZhaWxlZCwgYW5kDQo+ID4gPiB0aGF0IHVu
bGVzcyBJIGFtIHdpbGxpbmcgdG8gZGVkaWNhdGUgc2lnbmlmaWNhbnQgcGFydCBvZiBteSBsaWZl
IHRvDQo+ID4gPiB0aGlzIGFjdGl2aXR5IChpLmUuIGFwcGx5aW5nIGFuZCBsb2JieWluZyBmb3Ig
YSBuZXcgdG9wLWxldmVsICJmb250Ig0KPiA+ID4gdHlwZSkgdGhlIGVmZm9ydCB3b3VsZCBtb3N0
IGxpa2VseSBnZXQgdXMgbm93aGVyZS4NCj4gPg0KPiA+IFBlcmhhcHMgSSBhbSBtaXN0YWtlbiwg
YnV0IEkgcmVhZCB0aGUgZGlzY3Vzc2lvbiBkaWZmZXJlbnRseTogSSBzZWUgYW4NCj4gPiBvcGVu
bmVzcyB0byByZWdpc3RlcmluZyBmb250Lyogbm93Lg0KPiA+DQo+ID4gTXkgcGVyc29uYWwgb3Bp
bmlvbiBpcyB0aGF0IHJlZ2lzdGVyaW5nIGZvbnQvKiB0eXBlIHN0aWxsIG1ha2VzIGEgbG90IG9m
DQpzZW5zZSBhbmQgdGhpcyBpcyBzb21ldGhpbmcgd2UgbmVlZCB0byBkbywgZXZlbiBpZiBpdCBp
bnZvbHZlcyByZS1yZWdpc3RlcmluZw0Kc29tZSBvZiB0aGUgZXhpc3Rpbmcgc3VidHlwZXMgdW5k
ZXIgdGhlIG5ldyBmb250LyogdHJlZS4gSSBicm91Z2h0IHRoaXMgdXAgZm9yDQpkaXNjdXNzaW9u
IGF0IHRvZGF5J3MgY29uZmVyZW5jZSBjYWxsIHdpdGggVzNDIFdlYkZvbnRzIFdHLCBhbmQgdGhl
IGdlbmVyYWwNCm9waW5pb24gd2FzIHRoYXQgaGF2aW5nIGZvbnQvKiB0eXBlIHJlZ2lzdGVyZWQg
d291bGQgc3RpbGwgYmUgYSBnb29kIHRoaW5nIGZvcg0KdGhlIGluZHVzdHJ5Lg0KPg0KVmxhZA0K
DQpKdXN0IHRvIGJlIGNsZWFyLCB3aGF0IG1lYW5pbmcgZG9lcyBXZWJGb250cyBhdHRhY2ggdG8g
J2ZvbnQnLCB3ZXJlIGl0IGFuIG9iamVjdA0KY2xhc3MsIGhvdyB3b3VsZCBpdCBiZSBjaGFyYWN0
ZXJpc2VkPyAgVGhpcyB0aHJlYWQgaGFzIHNob3duIGEgbnVtYmVyIG9mDQpkaWZmZXJlbnQgbWVh
bmluZ3Mgb2YgdGhlIHRlcm0gYW5kIEkgYW0gbm90IGZhbWlsaWFyIHdpdGggdGhlIHdvcmsgb2Yg
VzNDLg0KDQpUb20gUGV0Y2gNCg0KPiBUaGFuayB5b3UsDQo+IFZsYWQNCj4NCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMtZGlzY3VzcyBtYWls
aW5nIGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3M=

From singer@apple.com  Thu Nov 17 09:15:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6724911E80FB for ; Thu, 17 Nov 2011 09:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.999
X-Spam-Level: 
X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 lYTMLgzJOuh1 for ; Thu, 17 Nov 2011 09:15:08 -0800 (PST)
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id B12E311E8095 for ; Thu, 17 Nov 2011 09:15:08 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LUT0060AEJT2S90@mail-out.apple.com> for apps-discuss@ietf.org; Thu, 17 Nov 2011 09:15:07 -0800 (PST)
X-AuditID: 11807112-b7b05ae000001108-2c-4ec5411bbe7b
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by relay17.apple.com (Apple SCV relay) with SMTP id 63.A1.04360.B1145CE4; Thu, 17 Nov 2011 09:15:07 -0800 (PST)
From: David Singer 
In-reply-to: <3615F3CCD55F054395A882F51C6E5FDA1820227B@szxeml513-mbx.china.huawei.com>
Date: Thu, 17 Nov 2011 09:15:06 -0800
Content-transfer-encoding: quoted-printable
Message-id: <7EA8144E-2216-4696-BD5D-C485D2F4557D@apple.com>
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <042901cca51f$d3ff60c0$4001a8c0@gateway.2wire.net> <3615F3CCD55F054395A882F51C6E5FDA1820227B@szxeml513-mbx.china.huawei.com>
To: TianLinyi 
X-Mailer: Apple Mail (2.1251.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUieFSBW1fa8aifwdUN3BarX65gs7izvofR YtvBJYwW1x7dZ7GY/fMPq8XGP4vYHdg8dh39we7RcuQtq8eSJT+ZPObtOMTkcXTeflaPZXP3 sASwRXHZpKTmZJalFunbJXBlHNw/m7Xgl0TFlUubWBsYN4l0MXJySAiYSOxbdYEZwhaTuHBv PRuILSSwmVHi04ZoEFtYwEVi0aX1TCA2r4CxxJpb71hAbGYBdYk/8y6B9bIJqEo8mHOMEcTm FAiT+POmEyzOAhSf3LaEvYuRC6j+EaPE4hWboJq1JZYtfM0MMdRG4var/ywgRUICf5klVly5 D9TBwSEioCKx/YgBxHHyEi1f77BNYOSfheSOWUjumIVk7AJG5lWMgkWpOYmVhuZ6iQUFOal6 yfm5mxhBYdxQKLSD8f4uvUOMAhyMSjy8ltZH/YRYE8uKK3MPMUpwMCuJ8PI+P+InxJuSWFmV WpQfX1Sak1p8iFGag0VJnLd810E/IYH0xJLU7NTUgtQimCwTB6dUA6Ozut865pnfWHLEZs0o PPzuvHT2yUnzu7T3S+x9e3Tis+Xpy7ijzsSc7pSpqti207tmbcRPHv/gCfsc7wanVc/a+Ub5 yNkW6YJnlR4n5lV+ernRbDrLpxSrbIaMWVVRZ1LYTj67aK7mkV7e0hlslXYkXEbie+g1hWKu +gXt4ee7LMqKO/VbtymxFGckGmoxFxUnAgBzA+sKXwIAAA==
Cc: Chris Lilley , "apps-discuss@ietf.org" , "Levantovsky, Vladimir" , "gadams@xfsi.com" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 17:15:09 -0000

On Nov 17, 2011, at 6:06 , TianLinyi wrote:

> Hi, All
>=20
> Since there is no clear advantage for both ways, is there any guidance =
on how to make a decision? I think we don't need to spend too much time =
on this. Maybe it is the time to make a choice now based on rough =
consensus, right? Or if there is an alternative way to get guidance from =
somewhere in IETF first regarding how to create a top level registry?

I think that it's way overdue for us to work out whether everything [not =
[image | video | audio]] should be application, and if not, why not.

>=20
> Cheers,
> Linyi
>=20
> ________________________________________
> =E5=8F=91=E4=BB=B6=E4=BA=BA: apps-discuss-bounces@ietf.org =
[apps-discuss-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 t.petch =
[ietfc@btconnect.com]
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B411=E6=9C=8817=E6=97=A5=
 19:55
> =E5=88=B0: Levantovsky, Vladimir
> Cc: Chris Lilley; David Singer; apps-discuss@ietf.org; gadams@xfsi.com
> =E4=B8=BB=E9=A2=98: Re: [apps-discuss] font/* (and =
draft-freed-media-type-regs)
>=20
> ----- Original Message -----
> From: "Levantovsky, Vladimir" =

> To: "Peter Saint-Andre" 
> Cc: "Chris Lilley" ; "Ned Freed" =
; "David
> Singer" ; ; 
> Sent: Wednesday, November 16, 2011 9:01 PM
>> Adding Chris Lilley from W3C
>>=20
>> On Tuesday, November 15, 2011 9:17 PM Peter Saint-Andre wrote:
>>>=20
>>> On 11/16/11 7:22 AM, Levantovsky, Vladimir wrote:
>>>=20
>>>> However, the sentiments expressed at the time were very similar to
>>>> this discussion; I was told that applying for a new top-level type
>>>> was "A BIG NO-NO", that prior attempts to register font/* failed, =
and
>>>> that unless I am willing to dedicate significant part of my life to
>>>> this activity (i.e. applying and lobbying for a new top-level =
"font"
>>>> type) the effort would most likely get us nowhere.
>>>=20
>>> Perhaps I am mistaken, but I read the discussion differently: I see =
an
>>> openness to registering font/* now.
>>>=20
>>> My personal opinion is that registering font/* type still makes a =
lot of
> sense and this is something we need to do, even if it involves =
re-registering
> some of the existing subtypes under the new font/* tree. I brought =
this up for
> discussion at today's conference call with W3C WebFonts WG, and the =
general
> opinion was that having font/* type registered would still be a good =
thing for
> the industry.
>>=20
> Vlad
>=20
> Just to be clear, what meaning does WebFonts attach to 'font', were it =
an object
> class, how would it be characterised?  This thread has shown a number =
of
> different meanings of the term and I am not familiar with the work of =
W3C.
>=20
> Tom Petch
>=20
>> Thank you,
>> Vlad
>>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

David Singer
Multimedia and Software Standards, Apple Inc.


From masinter@adobe.com  Thu Nov 17 17:30:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0DF11E80C0 for ; Thu, 17 Nov 2011 17:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.311
X-Spam-Level: 
X-Spam-Status: No, score=-106.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, 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 Z28jp-Q6LEAQ for ; Thu, 17 Nov 2011 17:30:47 -0800 (PST)
Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 383F111E80BE for ; Thu, 17 Nov 2011 17:30:46 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTsW1HrIW7tpWPEHkK2OmDwrWVvSSrbN4@postini.com; Thu, 17 Nov 2011 17:30:47 PST
Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pAI1U3Zc004929; Thu, 17 Nov 2011 17:30:04 -0800 (PST)
Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pAI1U25S020805; Thu, 17 Nov 2011 17:30:02 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Thu, 17 Nov 2011 17:30:02 -0800
From: Larry Masinter 
To: "Levantovsky, Vladimir" , Peter Saint-Andre 
Date: Thu, 17 Nov 2011 17:29:58 -0800
Thread-Topic: [apps-discuss] font/* (and draft-freed-media-type-regs)
Thread-Index: AcylkZDfSneCQizjQ4mlYmG4Ya4h4w==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Chris Lilley , Ned Freed , David Singer , "apps-discuss@ietf.org" , "gadams@xfsi.com Adams" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 01:30:49 -0000

# My personal opinion is that registering font/* type still makes a lot of =
sense and this is something we need to do

I think any definition of a new top level type should come with some use ca=
ses, some protocol or operation, which is more functional, reliable, better=
, improved, useful,.

#  even if it involves re-registering some of the existing subtypes under t=
he new font/* tree.

Types with two names seem like more of a problem, and re-registering existi=
ng types with a potentially long tail of overlapping use problematic.

#  I brought this up for discussion at today's conference call with W3C Web=
Fonts WG, and the general opinion was that having font/* type registered wo=
uld still be a good thing for the industry.

I think we still need at least one concrete practical use case. Just asking=
 in the abstract won't necessarily get you a good answer.

David Singer:
# I think that it's way overdue for us to work out whether everything [not =
[image | video | audio]] should be application, and if not, why not.

Everything else should be "application" unless there's a good reason for it=
.   For text/*, we at least had some hope of common "charset" parameters ha=
ving some meaning. For image/*, there's at least the use case of a HTTP "ac=
cept: image/*" header (although I'm not sure how useful that is, in practic=
e.).

But I'm having trouble imagining a use case for "font/*", even in the conte=
xt of sniffing.

Larry
--
http://larry.masinter.net


From duerst@it.aoyama.ac.jp  Thu Nov 17 23:03:15 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18EA21F8EF0 for ; Thu, 17 Nov 2011 23:03:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.633
X-Spam-Level: 
X-Spam-Status: No, score=-99.633 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkVoRP9N2+m3 for ; Thu, 17 Nov 2011 23:03:15 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E2D5F21F8F1F for ; Thu, 17 Nov 2011 23:03:14 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAI732Cv009505 for ; Fri, 18 Nov 2011 16:03:05 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 54e7_4fd7_5afc31e8_11b3_11e1_877a_001d096c566a; Fri, 18 Nov 2011 16:03:02 +0900
Received: from [IPv6:::1] ([133.2.210.1]:39056) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 18 Nov 2011 16:03:04 +0900
Message-ID: <4EC6031F.7000002@it.aoyama.ac.jp>
Date: Fri, 18 Nov 2011 16:02:55 +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: "Levantovsky, Vladimir" 
References: 	<4EC0C2C8.2010500@it.aoyama.ac.jp>	<01O8EV98HXC800RCTX@mauve.mrochek.com>	<99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com>	<7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org>	<4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org>
In-Reply-To: <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ned Freed , "apps-discuss@ietf.org" , "gadams@xfsi.com Adams" , Chris Lilley , David Singer 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 07:03:15 -0000

Hello Vlad,

On 2011/11/17 5:01, Levantovsky, Vladimir wrote:
> Adding Chris Lilley from W3C

> On Tuesday, November 15, 2011 9:17 PM Peter Saint-Andre wrote:

>> Perhaps I am mistaken, but I read the discussion differently: I see an
>> openness to registering font/* now.
>>
>
> Yes. I guess I should've been more specific and should have said that the sentiments expressed few years ago were similar to what was mentioned as part of this discussion (or as quoted from prior discussions). I do see a much more open-minded position to registering font/* now - the question is whether there is still a utility value left in doing this (since we already have quite a few font-* subtypes registered under the application/* tree.

You mention that there are quite a few font types already registered 
under application/. Earlier discussion only brought up 
application/font-tdpfr (http://tools.ietf.org/html/rfc3073), a format 
that as far as I was able to conclude from a quick web search, is no 
longer much in fashion (you may know better).

Can you tell us what the other font types under application/ are?

Regards,    Martin.

From derhoermi@gmx.net  Thu Nov 17 23:16:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6CD21F9423 for ; Thu, 17 Nov 2011 23:16:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.319
X-Spam-Level: 
X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 5IJVsU4VBedd for ; Thu, 17 Nov 2011 23:16:29 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 065E321F93D1 for ; Thu, 17 Nov 2011 23:16:28 -0800 (PST)
Received: (qmail invoked by alias); 18 Nov 2011 07:16:27 -0000
Received: from dslb-094-223-197-085.pools.arcor-ip.net (EHLO HIVE) [94.223.197.85] by mail.gmx.net (mp068) with SMTP; 18 Nov 2011 08:16:27 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19ETNET5q5EWHnE7q4q0JeGpsW9fubNBrKh7xruJ+ nnvBJjTm/F8GCA
From: Bjoern Hoehrmann 
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
Date: Fri, 18 Nov 2011 08:16:23 +0100
Message-ID: <111cc7pjhrtbb5n5es31827g5pb5i7m6i8@hive.bjoern.hoehrmann.de>
References: 	<4EC0C2C8.2010500@it.aoyama.ac.jp>	<01O8EV98HXC800RCTX@mauve.mrochek.com>	<99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com>	<7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org>	<4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <4EC6031F.7000002@it.aoyama.ac.jp>
In-Reply-To: <4EC6031F.7000002@it.aoyama.ac.jp>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 07:16:30 -0000

* Martin J. Dürst wrote:
>You mention that there are quite a few font types already registered 
>under application/. Earlier discussion only brought up 
>application/font-tdpfr (http://tools.ietf.org/html/rfc3073), a format 
>that as far as I was able to conclude from a quick web search, is no 
>longer much in fashion (you may know better).
>
>Can you tell us what the other font types under application/ are?

There are application/vnd.ms-fontobject for Microsoft's "EOT" format and
application/vnd.font-fontforge-sfd for Fontforge's "SFD" format.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From duerst@it.aoyama.ac.jp  Thu Nov 17 23:25:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC321F0C56 for ; Thu, 17 Nov 2011 23:25:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.636
X-Spam-Level: 
X-Spam-Status: No, score=-99.636 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmsmaYRTZCxC for ; Thu, 17 Nov 2011 23:25:44 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 195B41F0C51 for ; Thu, 17 Nov 2011 23:25:43 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAI7PhGa024808 for ; Fri, 18 Nov 2011 16:25:43 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 54e7_5247_86393a24_11b6_11e1_877a_001d096c566a; Fri, 18 Nov 2011 16:25:43 +0900
Received: from [IPv6:::1] ([133.2.210.1]:40923) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 18 Nov 2011 16:25:45 +0900
Message-ID: <4EC60870.4080805@it.aoyama.ac.jp>
Date: Fri, 18 Nov 2011 16:25:36 +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: Larry Masinter 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ned Freed , "Levantovsky, Vladimir" , "apps-discuss@ietf.org" , "gadams@xfsi.com Adams" , Chris Lilley , David Singer 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 07:25:49 -0000

Hello Larry,

On 2011/11/18 10:29, Larry Masinter wrote:
> I think any definition of a new top level type should come with some use cases, some protocol or operation, which is more functional, reliable, better, improved, useful,.

I don't see anything like this for image/, video/, or audio/ in the 
original documents. They just started with the assumption that these are 
not the same media, so they shouldn't be in the main top-level type. 
What's the problem with applying this same argument to font/? What will 
stop working, or otherwise produce undesired consequences, if we 
introduce font/?


> #  even if it involves re-registering some of the existing subtypes under the new font/* tree.
>
> Types with two names seem like more of a problem, and re-registering existing types with a potentially long tail of overlapping use problematic.

It's definitely not optimal. It would have been better to register these 
under font/ much earlier. We can still learn from that experience.


> #  I brought this up for discussion at today's conference call with W3C WebFonts WG, and the general opinion was that having font/* type registered would still be a good thing for the industry.
>
> I think we still need at least one concrete practical use case. Just asking in the abstract won't necessarily get you a good answer.

I don't think we need to continue to press for concrete, practical, 
fail-safe, everybody-will-be-satisfied use cases. At some point, not 
everybody will be convinced of the absolute need of font/. But that's 
fine. The main point is that those who think having font/ is useful can 
use it.


> David Singer:
> # I think that it's way overdue for us to work out whether everything [not [image | video | audio]] should be application, and if not, why not.
>
> Everything else should be "application" unless there's a good reason for it.   For text/*, we at least had some hope of common "charset" parameters having some meaning. For image/*, there's at least the use case of a HTTP "accept: image/*" header (although I'm not sure how useful that is, in practice.).
>
> But I'm having trouble imagining a use case for "font/*", even in the context of sniffing.

With "sniffing", do you mean content negotiation? "font/*" can indeed be 
as useful as "image/*". "image/*" expresses that the recipient can 
handle a wide range of images. "font/*" expresses that the recipient can 
handle a wide range of fonts. Why wouldn't this be useful?


Regards,    Martin.

From duerst@it.aoyama.ac.jp  Thu Nov 17 23:39:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1801211E808F for ; Thu, 17 Nov 2011 23:39:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.638
X-Spam-Level: 
X-Spam-Status: No, score=-99.638 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ18tx0kgLUE for ; Thu, 17 Nov 2011 23:39:21 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id B84AE11E8083 for ; Thu, 17 Nov 2011 23:39:20 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAI7d9aM001718 for ; Fri, 18 Nov 2011 16:39:13 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 4762_7ed8_66f9f7c8_11b8_11e1_9434_001d096c5782; Fri, 18 Nov 2011 16:39:09 +0900
Received: from [IPv6:::1] ([133.2.210.1]:41171) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 18 Nov 2011 16:39:12 +0900
Message-ID: <4EC60B98.9090606@it.aoyama.ac.jp>
Date: Fri, 18 Nov 2011 16:39:04 +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: Bjoern Hoehrmann 
References: 	<4EC0C2C8.2010500@it.aoyama.ac.jp>	<01O8EV98HXC800RCTX@mauve.mrochek.com>	<99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com>	<7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org>	<4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <4EC6031F.7000002@it.aoyama.ac.jp> <111cc7pjhrtbb5n5es31827g5pb5i7m6i8@hive.bjoern.hoehrmann.de>
In-Reply-To: <111cc7pjhrtbb5n5es31827g5pb5i7m6i8@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 07:39:22 -0000

On 2011/11/18 16:16, Bjoern Hoehrmann wrote:
> * Martin J. Dürst wrote:
>> You mention that there are quite a few font types already registered
>> under application/. Earlier discussion only brought up
>> application/font-tdpfr (http://tools.ietf.org/html/rfc3073), a format
>> that as far as I was able to conclude from a quick web search, is no
>> longer much in fashion (you may know better).
>>
>> Can you tell us what the other font types under application/ are?
>
> There are application/vnd.ms-fontobject for Microsoft's "EOT" format and
> application/vnd.font-fontforge-sfd for Fontforge's "SFD" format.

Okay. That would be altogether 3 out of e.g. the 24 on 
http://en.wikipedia.org/wiki/Category:Font_formats. Not too late to 
introduce font/, I'd say.

Regards,    Martin.

From duerst@it.aoyama.ac.jp  Thu Nov 17 23:52:01 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BAE1F0C51 for ; Thu, 17 Nov 2011 23:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.641
X-Spam-Level: 
X-Spam-Status: No, score=-99.641 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTrM3hlQf-Mx for ; Thu, 17 Nov 2011 23:52:01 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA0421F9247 for ; Thu, 17 Nov 2011 23:52:01 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAI7q0Ud011444 for ; Fri, 18 Nov 2011 16:52:00 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 4762_811b_3231c14a_11ba_11e1_9434_001d096c5782; Fri, 18 Nov 2011 16:52:00 +0900
Received: from [IPv6:::1] ([133.2.210.1]:58133) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 18 Nov 2011 16:52:02 +0900
Message-ID: <4EC60E99.2060904@it.aoyama.ac.jp>
Date: Fri, 18 Nov 2011 16:51:53 +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: "Levantovsky, Vladimir" 
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org>
In-Reply-To: <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "gadams@xfsi.com Adams" , Ned Freed , David Singer , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 07:52:02 -0000

Hello Vlad,

On 2011/11/16 8:22, Levantovsky, Vladimir wrote:

> In fact, SC29/WG11 is in the process of finalizing a new application (as part of the ISO/IEC 14496-22:2009/Amd.2 work) where we decided to apply for a new "application/font-sfnt" type using additional optional parameters to specify types of outlines and advanced layout mechanisms supported by a font. Doing so allows creating a flexible and extensible (albeit slightly cumbersome) mechanism to identify any SFNT-based font using same MIME type definition for a number of font flavors combining either TTF or CFF outlines with any currently known layout engine support (e.g. OpenType, AAT or SIL). Under the circumstances, this seemed to be a pragmatic way to compensate for the lack of "font" type.

I have no idea about the details involved, but what you say here about 
optional parameters sounds rather dangerous to me.

Setting parameters correctly on Web servers, while in theory not too 
complicated, turns out to be quite brittle and impractical in many 
scenarios. Even the base media type often isn't correct.

What you call a "flexible and extensible (albeit slightly cumbersome) 
mechanism" may turn out, in actual practice, to be highly cumbersome, 
confusing, and rarely used.

Again, I have to admit that I'm not familiar with the details, so if for 
example these parameters are only advisory and in practice things work 
perfectly well even if they are not used, then it might be less big of a 
deal.

Can you give use a bit more information to help understand the 
trade-offs involved?

Regards,   Martin.

From laurentwalter.goix@telecomitalia.it  Fri Nov 18 03:34:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E84721F8A7E for ; Fri, 18 Nov 2011 03:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.956
X-Spam-Level: 
X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=-0.185,  BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 q7PTSMWoVZGY for ; Fri, 18 Nov 2011 03:34:28 -0800 (PST)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id BDC5E21F85FF for ; Fri, 18 Nov 2011 03:34:27 -0800 (PST)
Content-Type: multipart/mixed; boundary="_8e07cc13-7458-4972-bb38-7fc9de15600a_"
Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 18 Nov 2011 12:34:23 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 18 Nov 2011 12:34:23 +0100
From: Goix Laurent Walter 
To: "apps-discuss@ietf.org" 
Date: Fri, 18 Nov 2011 12:34:20 +0100
Thread-Topic: Webfinger & acct: draft
Thread-Index: Acyl5gOYDz7w0SDaRsC/e3Ibnc5EzA==
Message-ID: 
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [apps-discuss] Webfinger & acct: draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 11:34:33 -0000

--_8e07cc13-7458-4972-bb38-7fc9de15600a_
Content-Type: multipart/alternative;
	boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE4056F73E86GRFMBX704BA02_"

--_000_A09A9E0A4B9C654E8672D1DC003633AE4056F73E86GRFMBX704BA02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Paul, all,

Thank you for starting addressing this standardization topic within IETF. W=
ebfinger (and acct:) indeed are being increasingly used and the whole commu=
nity would benefit from a well-referenced specification for it.

Here are some comments on the draft:

-          At this stage acct: scheme is needed from a formal point of view=
 only I guess, so there may not be the need for a full addr-spec support.

-          I also support the point raised by Mykyta around i18n.  I guess =
as we are targeting user addressing more than resource addressing in genera=
l, and given the rise of Internet & social networks in non-ascii countries =
it would be important to target a dual URI/IRI scheme (following the path o=
f the mailto rfc6068bis draft)

-          If no other spec is currently using the acct: scheme then it may=
 be kept in the webfinger spec, but some existing specifications may be int=
erested in referencing it as primary/preferred addressing mechanism (indepe=
ndently from webfinger), e.g. Opensocial, activitystrea.ms

-          From a more structural point of view it may be useful to better =
distinguish the sections related to the scheme from the ones relates to web=
finger. Right now 4.1 and 4.2 are very different in purpose and may become =
4 and 5. Current section 5 could become a subsection of webfinger (say 5.2)

-          It may also be good to distinguish the behavior on the server si=
de (creating/exposing the descriptor and its content) from the actual disco=
very behavior from the client.

-          Webfinger further uses specific link "rels", which now are refer=
enced under webfinger.net domain. I guess some of these rels would need to =
be registered as pure tokens (no URI), e.g. "avatar", "profile-page" and sp=
ecified in this spec.

-          Reference 8 can now be updated to rfc6415

Cheers
Walter

------------------------------------------------------------------
Telecom Italia
Laurent-Walter Goix
Innovation & Industry Relations, Research & Prototyping, Future Internet
Piazza Einaudi 8 - 20124 Milano (Italy)
Tel. +39 026213445
Mob. +39 3356114196
Fax +39 0641869055


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:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No=
n stampare questa mail se non ? necessario.


--_000_A09A9E0A4B9C654E8672D1DC003633AE4056F73E86GRFMBX704BA02_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Paul, all,

 


Thank you for starting addressi=
ng this standardization topic within IETF. Webfinger (and acct:) indeed are=
 being increasingly used and the whole community would benefit from a well-=
referenced specification for it.


 


Here are some comments on the d=
raft:


-  =
;       
At this stage acct: sch=
eme is needed from a formal point of view only I guess, so there may not be=
 the need for a full addr-spec support.



-  =
;       
I also support the poin=
t raised by Mykyta around i18n.  I guess as we are targeting user addr=
essing more than resource addressing in general, and given the rise of Inte=
rnet & social networks in non-ascii countries
 it would be important to target a dual URI/IRI scheme (following the path =
of the mailto rfc6068bis draft)


-  =
;       
If no other spec is cur=
rently using the acct: scheme then it may be kept in the webfinger spec, bu=
t some existing specifications may be interested in referencing it as prima=
ry/preferred addressing mechanism
 (independently from webfinger), e.g. Opensocial, activitystrea.ms


-  =
;       
From a more structural =
point of view it may be useful to better distinguish the sections related t=
o the scheme from the ones relates to webfinger. Right now 4.1 and 4.2 are =
very different in purpose and may
 become 4 and 5. Current section 5 could become a subsection of webfinger (=
say 5.2)


-  =
;       
It may also be good to =
distinguish the behavior on the server side (creating/exposing the descript=
or and its content) from the actual discovery behavior from the client.


-  =
;       
Webfinger further uses =
specific link “rels”, which now are referenced under webfinger.=
net domain. I guess some of these rels would need to be registered as pure =
tokens (no URI), e.g. “avatar”, “profile-page”
 and specified in this spec.


-  =
;       
Reference 8 can now be =
updated to rfc6415


 


Cheers


Walter


 


----------------------------------------------------------------=
--

Telecom Italia

Laurent-Walter Goix=



Innovation & Industry=
 Relations, Research & Prototyping, Future Internet 


Piazza Einaudi 8 - 2012=
4 Milano (Italy)

Tel. +39 026213445


Mob. +39 3356114196



Fax +39 0641869055


 =



 











=
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 è necessario.











--_000_A09A9E0A4B9C654E8672D1DC003633AE4056F73E86GRFMBX704BA02_--

--_8e07cc13-7458-4972-bb38-7fc9de15600a_
Content-Description: logo Ambiente_foglia.jpg
Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg"
Content-Disposition: inline; filename="logo Ambiente_foglia.jpg"
Content-Transfer-Encoding: base64
Content-ID: 00000000000000000000000000000001@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=

--_8e07cc13-7458-4972-bb38-7fc9de15600a_--

From Vladimir.Levantovsky@MonotypeImaging.com  Fri Nov 18 06:35:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A155621F8B35 for ; Fri, 18 Nov 2011 06:35:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.211
X-Spam-Level: 
X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.088,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 se1hitrRad0Z for ; Fri, 18 Nov 2011 06:35:31 -0800 (PST)
Received: from exprod8og119.obsmtp.com (exprod8og119.obsmtp.com [64.18.3.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4F85421F8B34 for ; Fri, 18 Nov 2011 06:35:30 -0800 (PST)
Received: from wob-email-01.agfamonotype.org ([209.113.171.111]) (using TLSv1) by exprod8ob119.postini.com ([64.18.7.12]) with SMTP ID DSNKTsZtJgg3Pq+UtEIyRDmDdDcruJ7wYbXR@postini.com; Fri, 18 Nov 2011 06:35:31 PST
Received: from WOB-EMAIL-01.agfamonotype.org ([192.168.50.7]) by wob-email-01.agfamonotype.org ([192.168.50.7]) with mapi; Fri, 18 Nov 2011 09:35:17 -0500
From: "Levantovsky, Vladimir" 
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Date: Fri, 18 Nov 2011 09:35:15 -0500
Thread-Topic: [apps-discuss] font/* (and draft-freed-media-type-regs)
Thread-Index: AcylwB7vKVuamf8mTdSCfNLyTIgvkAAPfDiw
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D117FCD7382@wob-email-01.agfamonotype.org>
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp>	<01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <4EC6031F.7000002@it.aoyama.ac.jp>
In-Reply-To: <4EC6031F.7000002@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Ned Freed , "apps-discuss@ietf.org" , "gadams@xfsi.com Adams" , Chris Lilley , David Singer 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 14:35:32 -0000

SGVsbG8gTWFyaW4sIGFsbCwNCg0KQmVzaWRlcyB2ZW5kb3Itc3BlY2lmaWMgdHlwZXMsIHRoZSBv
bmx5IHJlZ2lzdGVyZWQgZm9udCB0eXBlIHRoYXQgSSBhbSBhd2FyZSBvZiBpcyAnYXBwbGljYXRp
b24vZm9udC13b2ZmJy4gVzNDIFdlYkZvbnRzIFdHIGhhcyBzdWJtaXR0ZWQgYSByZWdpc3RyYXRp
b24gZm9yIHRoaXMgc3VidHlwZSBhYm91dCBhIHllYXIgYWdvLCBhbmQgdGhlIHRleHQgb2YgdGhl
IHJlZ2lzdHJhdGlvbiBpcyBhdmFpbGFibGUgYXMgQW5uZXggQiBvZiB0aGUgV09GRiBzcGVjaWZp
Y2F0aW9uOiBodHRwOi8vZGV2LnczLm9yZy93ZWJmb250cy9XT0ZGL3NwZWMvI2FwcGVuZGl4LWIN
Cg0KSVNPIFNDMjkvV0cxMSBoYXMgcHJlcGFyZWQgdGhlIGRyYWZ0IHRvIHJlZ2lzdGVyIGFwcGxp
Y2F0aW9uL2ZvbnQtc2ZudCBidXQgaXQgd2Fzbid0IHN1Ym1pdHRlZCB5ZXQuIA0KDQpUaGFuayB5
b3UsDQpWbGFkDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiAiTWFy
dGluIEouIETDvHJzdCIgW21haWx0bzpkdWVyc3RAaXQuYW95YW1hLmFjLmpwXQ0KPiBTZW50OiBG
cmlkYXksIE5vdmVtYmVyIDE4LCAyMDExIDI6MDMgQU0NCj4gVG86IExldmFudG92c2t5LCBWbGFk
aW1pcg0KPiBDYzogUGV0ZXIgU2FpbnQtQW5kcmU7IENocmlzIExpbGxleTsgTmVkIEZyZWVkOyBE
YXZpZCBTaW5nZXI7IGFwcHMtDQo+IGRpc2N1c3NAaWV0Zi5vcmc7IGdhZGFtc0B4ZnNpLmNvbSBB
ZGFtcw0KPiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gZm9udC8qIChhbmQgZHJhZnQtZnJl
ZWQtbWVkaWEtdHlwZS1yZWdzKQ0KPiANCj4gSGVsbG8gVmxhZCwNCj4gDQo+IE9uIDIwMTEvMTEv
MTcgNTowMSwgTGV2YW50b3Zza3ksIFZsYWRpbWlyIHdyb3RlOg0KPiA+IEFkZGluZyBDaHJpcyBM
aWxsZXkgZnJvbSBXM0MNCj4gDQo+ID4gT24gVHVlc2RheSwgTm92ZW1iZXIgMTUsIDIwMTEgOTox
NyBQTSBQZXRlciBTYWludC1BbmRyZSB3cm90ZToNCj4gDQo+ID4+IFBlcmhhcHMgSSBhbSBtaXN0
YWtlbiwgYnV0IEkgcmVhZCB0aGUgZGlzY3Vzc2lvbiBkaWZmZXJlbnRseTogSSBzZWUNCj4gYW4N
Cj4gPj4gb3Blbm5lc3MgdG8gcmVnaXN0ZXJpbmcgZm9udC8qIG5vdy4NCj4gPj4NCj4gPg0KPiA+
IFllcy4gSSBndWVzcyBJIHNob3VsZCd2ZSBiZWVuIG1vcmUgc3BlY2lmaWMgYW5kIHNob3VsZCBo
YXZlIHNhaWQgdGhhdA0KPiB0aGUgc2VudGltZW50cyBleHByZXNzZWQgZmV3IHllYXJzIGFnbyB3
ZXJlIHNpbWlsYXIgdG8gd2hhdCB3YXMNCj4gbWVudGlvbmVkIGFzIHBhcnQgb2YgdGhpcyBkaXNj
dXNzaW9uIChvciBhcyBxdW90ZWQgZnJvbSBwcmlvcg0KPiBkaXNjdXNzaW9ucykuIEkgZG8gc2Vl
IGEgbXVjaCBtb3JlIG9wZW4tbWluZGVkIHBvc2l0aW9uIHRvIHJlZ2lzdGVyaW5nDQo+IGZvbnQv
KiBub3cgLSB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB0aGVyZSBpcyBzdGlsbCBhIHV0aWxpdHkg
dmFsdWUNCj4gbGVmdCBpbiBkb2luZyB0aGlzIChzaW5jZSB3ZSBhbHJlYWR5IGhhdmUgcXVpdGUg
YSBmZXcgZm9udC0qIHN1YnR5cGVzDQo+IHJlZ2lzdGVyZWQgdW5kZXIgdGhlIGFwcGxpY2F0aW9u
LyogdHJlZS4NCj4gDQo+IFlvdSBtZW50aW9uIHRoYXQgdGhlcmUgYXJlIHF1aXRlIGEgZmV3IGZv
bnQgdHlwZXMgYWxyZWFkeSByZWdpc3RlcmVkDQo+IHVuZGVyIGFwcGxpY2F0aW9uLy4gRWFybGll
ciBkaXNjdXNzaW9uIG9ubHkgYnJvdWdodCB1cA0KPiBhcHBsaWNhdGlvbi9mb250LXRkcGZyICho
dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMDczKSwgYSBmb3JtYXQNCj4gdGhhdCBhcyBm
YXIgYXMgSSB3YXMgYWJsZSB0byBjb25jbHVkZSBmcm9tIGEgcXVpY2sgd2ViIHNlYXJjaCwgaXMg
bm8NCj4gbG9uZ2VyIG11Y2ggaW4gZmFzaGlvbiAoeW91IG1heSBrbm93IGJldHRlcikuDQo+IA0K
PiBDYW4geW91IHRlbGwgdXMgd2hhdCB0aGUgb3RoZXIgZm9udCB0eXBlcyB1bmRlciBhcHBsaWNh
dGlvbi8gYXJlPw0KPiANCj4gUmVnYXJkcywgICAgTWFydGluLg0K

From Vladimir.Levantovsky@MonotypeImaging.com  Fri Nov 18 07:17:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7069721F89BA for ; Fri, 18 Nov 2011 07:17:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.233
X-Spam-Level: 
X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.066,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 j1f8JI38GQDa for ; Fri, 18 Nov 2011 07:17:07 -0800 (PST)
Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by ietfa.amsl.com (Postfix) with ESMTP id 092FE21F88AB for ; Fri, 18 Nov 2011 07:17:06 -0800 (PST)
Received: from wob-email-01.agfamonotype.org ([209.113.171.111]) (using TLSv1) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP ID DSNKTsZ28gl52MfFUtext0m6Qz/tya4+42Dv@postini.com; Fri, 18 Nov 2011 07:17:07 PST
Received: from WOB-EMAIL-01.agfamonotype.org ([192.168.50.7]) by wob-email-01.agfamonotype.org ([192.168.50.7]) with mapi; Fri, 18 Nov 2011 10:17:05 -0500
From: "Levantovsky, Vladimir" 
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Date: Fri, 18 Nov 2011 10:17:04 -0500
Thread-Topic: [apps-discuss] font/* (and draft-freed-media-type-regs)
Thread-Index: AcylxvYSRSPoOj1mRmeScfmjQcQt3gAO/ddQ
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D117FCD73B2@wob-email-01.agfamonotype.org>
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC60E99.2060904@it.aoyama.ac.jp>
In-Reply-To: <4EC60E99.2060904@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "gadams@xfsi.com Adams" , Ned Freed , David Singer , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 15:17:08 -0000

T24gRnJpZGF5LCBOb3ZlbWJlciAxOCwgMjAxMSAyOjUyIEFNIE1hcnRpbiBKLiBEw7xyc3Qgd3Jv
dGU6DQo+IA0KPiBPbiAyMDExLzExLzE2IDg6MjIsIExldmFudG92c2t5LCBWbGFkaW1pciB3cm90
ZToNCj4gDQo+ID4gSW4gZmFjdCwgU0MyOS9XRzExIGlzIGluIHRoZSBwcm9jZXNzIG9mIGZpbmFs
aXppbmcgYSBuZXcgYXBwbGljYXRpb24NCj4gKGFzIHBhcnQgb2YgdGhlIElTTy9JRUMgMTQ0OTYt
MjI6MjAwOS9BbWQuMiB3b3JrKSB3aGVyZSB3ZSBkZWNpZGVkIHRvDQo+IGFwcGx5IGZvciBhIG5l
dyAiYXBwbGljYXRpb24vZm9udC1zZm50IiB0eXBlIHVzaW5nIGFkZGl0aW9uYWwgb3B0aW9uYWwN
Cj4gcGFyYW1ldGVycyB0byBzcGVjaWZ5IHR5cGVzIG9mIG91dGxpbmVzIGFuZCBhZHZhbmNlZCBs
YXlvdXQgbWVjaGFuaXNtcw0KPiBzdXBwb3J0ZWQgYnkgYSBmb250LiBEb2luZyBzbyBhbGxvd3Mg
Y3JlYXRpbmcgYSBmbGV4aWJsZSBhbmQgZXh0ZW5zaWJsZQ0KPiAoYWxiZWl0IHNsaWdodGx5IGN1
bWJlcnNvbWUpIG1lY2hhbmlzbSB0byBpZGVudGlmeSBhbnkgU0ZOVC1iYXNlZCBmb250DQo+IHVz
aW5nIHNhbWUgTUlNRSB0eXBlIGRlZmluaXRpb24gZm9yIGEgbnVtYmVyIG9mIGZvbnQgZmxhdm9y
cyBjb21iaW5pbmcNCj4gZWl0aGVyIFRURiBvciBDRkYgb3V0bGluZXMgd2l0aCBhbnkgY3VycmVu
dGx5IGtub3duIGxheW91dCBlbmdpbmUNCj4gc3VwcG9ydCAoZS5nLiBPcGVuVHlwZSwgQUFUIG9y
IFNJTCkuIFVuZGVyIHRoZSBjaXJjdW1zdGFuY2VzLCB0aGlzDQo+IHNlZW1lZCB0byBiZSBhIHBy
YWdtYXRpYyB3YXkgdG8gY29tcGVuc2F0ZSBmb3IgdGhlIGxhY2sgb2YgImZvbnQiIHR5cGUuDQo+
IA0KPiBJIGhhdmUgbm8gaWRlYSBhYm91dCB0aGUgZGV0YWlscyBpbnZvbHZlZCwgYnV0IHdoYXQg
eW91IHNheSBoZXJlIGFib3V0DQo+IG9wdGlvbmFsIHBhcmFtZXRlcnMgc291bmRzIHJhdGhlciBk
YW5nZXJvdXMgdG8gbWUuDQo+IA0KPiBTZXR0aW5nIHBhcmFtZXRlcnMgY29ycmVjdGx5IG9uIFdl
YiBzZXJ2ZXJzLCB3aGlsZSBpbiB0aGVvcnkgbm90IHRvbw0KPiBjb21wbGljYXRlZCwgdHVybnMg
b3V0IHRvIGJlIHF1aXRlIGJyaXR0bGUgYW5kIGltcHJhY3RpY2FsIGluIG1hbnkNCj4gc2NlbmFy
aW9zLiBFdmVuIHRoZSBiYXNlIG1lZGlhIHR5cGUgb2Z0ZW4gaXNuJ3QgY29ycmVjdC4NCj4gDQo+
IFdoYXQgeW91IGNhbGwgYSAiZmxleGlibGUgYW5kIGV4dGVuc2libGUgKGFsYmVpdCBzbGlnaHRs
eSBjdW1iZXJzb21lKQ0KPiBtZWNoYW5pc20iIG1heSB0dXJuIG91dCwgaW4gYWN0dWFsIHByYWN0
aWNlLCB0byBiZSBoaWdobHkgY3VtYmVyc29tZSwNCj4gY29uZnVzaW5nLCBhbmQgcmFyZWx5IHVz
ZWQuDQo+IA0KPiBBZ2FpbiwgSSBoYXZlIHRvIGFkbWl0IHRoYXQgSSdtIG5vdCBmYW1pbGlhciB3
aXRoIHRoZSBkZXRhaWxzLCBzbyBpZiBmb3INCj4gZXhhbXBsZSB0aGVzZSBwYXJhbWV0ZXJzIGFy
ZSBvbmx5IGFkdmlzb3J5IGFuZCBpbiBwcmFjdGljZSB0aGluZ3Mgd29yaw0KPiBwZXJmZWN0bHkg
d2VsbCBldmVuIGlmIHRoZXkgYXJlIG5vdCB1c2VkLCB0aGVuIGl0IG1pZ2h0IGJlIGxlc3MgYmln
IG9mDQo+IGEgZGVhbC4NCj4gDQo+IENhbiB5b3UgZ2l2ZSB1c2UgYSBiaXQgbW9yZSBpbmZvcm1h
dGlvbiB0byBoZWxwIHVuZGVyc3RhbmQgdGhlDQo+IHRyYWRlLW9mZnMgaW52b2x2ZWQ/DQo+IA0K
DQpUaGUgU0MyOS9XRzExIHBsYW5uZWQgdG8gcmVnaXN0ZXIgdGhlICJhcHBsaWNhdGlvbi9mb250
LXNmbnQiIHR5cGUgd2l0aCB0aGUgZm9sbG93aW5nIHR3byBvcHRpb25hbCBwYXJhbWV0ZXJzOg0K
MSkgCU5hbWU6IAlPdXRsaW5lcw0KCVZhbHVlOiAJVFRGLCBDRkYNCjIpIAlOYW1lOiAJTGF5b3V0
DQoJVmFsdWU6IAlPVEYsIEFBVCwgU0lMIA0KDQpUaGlzIHdvdWxkIGFsbG93IHRvIGlkZW50aWZ5
IGZvbnRzIG9mIG11bHRpcGxlIGZsYXZvcnMsIGUuZy46DQpUcnVlVHlwZSAtIGFwcGxpY2F0aW9u
L2ZvbnQtc2ZudCAoT3V0bGluZXM9VFRGKTsNCk9wZW5UeXBlIHdpdGggVFRGIG91dGxpbmVzIC0g
YXBwbGljYXRpb24vZm9udC1zZm50IChPdXRsaW5lcz1UVEYsIExheW91dD1PVEYpOw0KT3BlblR5
cGUgd2l0aCBDRkYgb3V0bGluZXMgLSBhcHBsaWNhdGlvbi9mb250LXNmbnQgKE91dGxpbmVzPUNG
RiwgTGF5b3V0PU9URik7DQpBQVQgZm9udHMgLSBhcHBsaWNhdGlvbi9mb250LXNmbnQgKE91dGxp
bmVzPVRURiwgTGF5b3V0PUFBVCk7IGV0Yy4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgdGhlIGFsdGVy
bmF0aXZlIHdvdWxkIGJlIHRvIHJlZ2lzdGVyIGEgbnVtYmVyIG9mIHNlcGFyYXRlIHN1YnR5cGVz
IGZvciBlYWNoIGZvbnQgZmxhdm9yLCBhbmQgaXQgd291bGQgcHJvYmFibHkgYmUgdGhlIHdheSB3
ZSB3aWxsIGdvIGlmIGZvbnQvKiBpcyBhdmFpbGFibGUuDQoNClRoYW5rIHlvdSwNClZsYWQNCg0K

From ned.freed@mrochek.com  Fri Nov 18 11:58:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8968E1F0C58 for ; Fri, 18 Nov 2011 11:58:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046,  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 cwmAh-xyRxuh for ; Fri, 18 Nov 2011 11:58:30 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 156671F0C4A for ; Fri, 18 Nov 2011 11:58:30 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8KCG8WQ0W0117HM@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 18 Nov 2011 11:58:22 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8BZ5CHRHS00XBUL@mauve.mrochek.com>; Fri, 18 Nov 2011 11:58:15 -0800 (PST)
Message-id: <01O8KCG4WZZE00XBUL@mauve.mrochek.com>
Date: Fri, 18 Nov 2011 11:50:51 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 18 Nov 2011 09:35:15 -0500" <7534F85A589E654EB1E44E5CFDC19E3D117FCD7382@wob-email-01.agfamonotype.org>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=utf-8
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <4EC6031F.7000002@it.aoyama.ac.jp> <7534F85A589E654EB1E44E5CFDC19E3D117FCD7382@wob-email-01.agfamonotype.org>
To: "Levantovsky, Vladimir" 
Cc: Ned Freed , "apps-discuss@ietf.org" , "gadams@xfsi.com Adams" , Chris Lilley , David Singer 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 19:58:30 -0000

> Besides vendor-specific types, the only registered font type that I am aware
> of is 'application/font-woff'. W3C WebFonts WG has submitted a registration for
> this subtype about a year ago, and the text of the registration is available as
> Annex B of the WOFF specification:

> http://dev.w3.org/webfonts/WOFF/spec/#appendix-b

Submitted to whom? It isn't on the IANA page so it hasn't been approved unless
approval was very recent.

It's one thing if this registration is still bouncing around inside of the W3C
process - that's entirely the W3C's baliwick. But if this was submitted to the
IESG for approval, having an outstanding request for "about a year" is
COMPLETELY UNACCEPTABLE. And this is very much the main problem this entire
effort was intended to address, and which we seem to have great difficulty
focusing on.

> ISO SC29/WG11 has prepared the draft to register application/font-sfnt but it
> wasn't submitted yet.

FWIW, there are presently four registered font-ish types:

application/font-tdpfr (RFC 3073)
application/vnd.font-fontforge-sfd
application/vnd.ms-fontobject
application/vnd.openxmlformats-officedocument.wordprocessingml.fontTable+xml

				Ned

From paulej@packetizer.com  Fri Nov 18 15:08:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F55721F84A5 for ; Fri, 18 Nov 2011 15:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level: 
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[AWL=-1.419, BAYES_05=-1.11, 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 aRZzRnwiggKQ for ; Fri, 18 Nov 2011 15:08:31 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA9121F84A1 for ; Fri, 18 Nov 2011 15:08:31 -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 pAIN8RNj024181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Nov 2011 18:08:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321657710; bh=bHXA6tb/w3RY84/eMnvNd0+fKr6DAq3IdhF9x3uuhrI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=NujVmjGwtZk4jCgCVeKfo5dBx8JLiugLDIcRDBl550vDp26YACc9ZAx84vS3d0DlP JAo46TOhG4tCW1BPe/Wl6t6Ua6YIaAMrjJtNJKiv3d8nOiVZVGzIVb9XeK9wHYUYTA CfHVrps8DzflG83c92rZI82VflS1SufLmsnZ7Szk=
From: "Paul E. Jones" 
To: "'Goix Laurent Walter'" , 
References: 
In-Reply-To: 
Date: Fri, 18 Nov 2011 18:08:11 -0500
Message-ID: <047c01cca646$f32f8100$d98e8300$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_047D_01CCA61D.0A5BEA00"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIL4OqBz9QyEd+IvRAI24Ft4P15EZU0yWdw
Content-Language: en-us
Subject: Re: [apps-discuss] Webfinger & acct: draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 23:08:34 -0000

This is a multipart message in MIME format.

------=_NextPart_000_047D_01CCA61D.0A5BEA00
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_047E_01CCA61D.0A5BEA00"


------=_NextPart_001_047E_01CCA61D.0A5BEA00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Walter,

=20

Thanks for your feedback on the text.  I=92ll be revising the document
accordingly.  Based on comments from you and others, section 4 will =
likely
undergo heavy restructuring :-)

=20

For the webfinger link relations under webfinger.net, are those that =
should
go into the existing IANA registry for link relations that was defined =
by
RFC 5988?  (See
http://www.iana.org/assignments/link-relations/link-relations.xml)  In =
any
case, registration of link relations can certainly be done as a part of =
this
specification or it could be done separately.  My own opinion is that it
would be better to define link relations separately, but I=92m willing =
to
follow the group opinion on this one.  Even I don=92t know what those
webfinger.net relations are :-)

=20

Paul

=20

From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Goix Laurent Walter
Sent: Friday, November 18, 2011 6:34 AM
To: apps-discuss@ietf.org
Subject: [apps-discuss] Webfinger & acct: draft

=20

Paul, all,

=20

Thank you for starting addressing this standardization topic within =
IETF.
Webfinger (and acct:) indeed are being increasingly used and the whole
community would benefit from a well-referenced specification for it.

=20

Here are some comments on the draft:

-          At this stage acct: scheme is needed from a formal point of =
view
only I guess, so there may not be the need for a full addr-spec support. =


-          I also support the point raised by Mykyta around i18n.  I =
guess
as we are targeting user addressing more than resource addressing in
general, and given the rise of Internet & social networks in non-ascii
countries it would be important to target a dual URI/IRI scheme =
(following
the path of the mailto rfc6068bis draft)

-          If no other spec is currently using the acct: scheme then it =
may
be kept in the webfinger spec, but some existing specifications may be
interested in referencing it as primary/preferred addressing mechanism
(independently from webfinger), e.g. Opensocial, activitystrea.ms

-          From a more structural point of view it may be useful to =
better
distinguish the sections related to the scheme from the ones relates to
webfinger. Right now 4.1 and 4.2 are very different in purpose and may
become 4 and 5. Current section 5 could become a subsection of webfinger
(say 5.2)

-          It may also be good to distinguish the behavior on the server
side (creating/exposing the descriptor and its content) from the actual
discovery behavior from the client.

-          Webfinger further uses specific link =93rels=94, which now =
are
referenced under webfinger.net domain. I guess some of these rels would =
need
to be registered as pure tokens (no URI), e.g. =93avatar=94, =
=93profile-page=94 and
specified in this spec.

-          Reference 8 can now be updated to rfc6415

=20

Cheers

Walter

=20

------------------------------------------------------------------
Telecom Italia
Laurent-Walter Goix

Innovation & Industry Relations, Research & Prototyping, Future Internet =


Piazza Einaudi 8 - 20124 Milano (Italy)
Tel. +39 026213445

Mob. +39 3356114196=20

Fax +39 0641869055

=20

=20


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_047E_01CCA61D.0A5BEA00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Walter,
 
Thanks for your feedback =
on the text.=A0 I’ll be revising the document accordingly.=A0 =
Based on comments from you and others, section 4 will likely undergo =
heavy restructuring :-)
 
For the webfinger link =
relations under webfinger.net, are those that should go into the =
existing IANA registry for link relations that was defined by RFC =
5988?=A0 (See http://www.iana.org/assignments/link-relations/link-relations.xml)=A0=
 In any case, registration of link relations can certainly be done as a =
part of this specification or it could be done separately.=A0 My own =
opinion is that it would be better to define link relations separately, =
but I’m willing to follow the group opinion on this one.=A0 Even I =
don’t know what those webfinger.net relations are =
:-)
 
Paul
 
From:=
 =
apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Goix Laurent Walter
Sent: Friday, November =
18, 2011 6:34 AM
To: apps-discuss@ietf.org
Subject: =
[apps-discuss] Webfinger & acct: =
draft
 
Paul, =
all,
 
Thank you for starting addressing this standardization =
topic within IETF. Webfinger (and acct:) indeed are being increasingly =
used and the whole community would benefit from a well-referenced =
specification for it.
 
Here are =
some comments on the draft:
-          =
At this stage acct: scheme is needed from a =
formal point of view only I guess, so there may not be the need for a =
full addr-spec support. 
-          =
I also support the point raised by Mykyta around =
i18n.  I guess as we are targeting user addressing more than =
resource addressing in general, and given the rise of Internet & =
social networks in non-ascii countries it would be important to target a =
dual URI/IRI scheme (following the path of the mailto rfc6068bis =
draft)
-          =
If no other spec is currently using the acct: =
scheme then it may be kept in the webfinger spec, but some existing =
specifications may be interested in referencing it as primary/preferred =
addressing mechanism (independently from webfinger), e.g. Opensocial, =
activitystrea.ms
-          =
From a more structural point of view it may be =
useful to better distinguish the sections related to the scheme from the =
ones relates to webfinger. Right now 4.1 and 4.2 are very different in =
purpose and may become 4 and 5. Current section 5 could become a =
subsection of webfinger (say 5.2)
-          =
It may also be good to distinguish the behavior =
on the server side (creating/exposing the descriptor and its content) =
from the actual discovery behavior from the client.
-          =
Webfinger further uses specific link =
“rels”, which now are referenced under webfinger.net domain. =
I guess some of these rels would need to be registered as pure tokens =
(no URI), e.g. “avatar”, “profile-page” and =
specified in this spec.
-          =
Reference 8 can now be updated to =
rfc6415
 
Cheers
Walter
 
-----------------------------------------=
-------------------------
Telecom =
Italia
Laurent-Walt=
er Goix
Innovation =
& Industry Relations, Research & Prototyping, Future =
Internet 
Piazza =
Einaudi 8 - 20124 Milano (Italy)
Tel. +39 026213445
Mob. +39 =
3356114196 =

Fax +39 =
0641869055
 
 
=
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_047E_01CCA61D.0A5BEA00--

------=_NextPart_000_047D_01CCA61D.0A5BEA00
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_047D_01CCA61D.0A5BEA00--


From gsalguei@cisco.com  Fri Nov 18 15:53:56 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E4311E809D for ; Fri, 18 Nov 2011 15:53:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 oDj2Wguk9kSK for ; Fri, 18 Nov 2011 15:53:55 -0800 (PST)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 196DB11E8091 for ; Fri, 18 Nov 2011 15:53:55 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAINrrsk009416 for ; Fri, 18 Nov 2011 18:53:53 -0500 (EST)
Received: from dhcp-64-102-209-148.cisco.com (dhcp-64-102-209-148.cisco.com [64.102.209.148]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAINrliX013238; Fri, 18 Nov 2011 18:53:47 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-325--244156301
From: Gonzalo Salgueiro 
In-Reply-To: <047c01cca646$f32f8100$d98e8300$@packetizer.com>
Date: Fri, 18 Nov 2011 18:53:47 -0500
Message-Id: <740878FD-AA49-4F62-8612-7AE76CA36710@cisco.com>
References:  <047c01cca646$f32f8100$d98e8300$@packetizer.com>
To: "Paul E. Jones" 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger & acct: draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 23:53:56 -0000

--Apple-Mail-325--244156301
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

 I agree. Both the notion of registering link relations and the =
possibility of a broader usage of the acct: URI beyond Webfinger really =
require some group discussion to help us decide if the draft remains =
self-contained as a single document or gets broken into several.

Regards,

Gonzalo



On Nov 18, 2011, at 6:08 PM, Paul E. Jones wrote:

> Walter,
> =20
> Thanks for your feedback on the text.  I=92ll be revising the document =
accordingly.  Based on comments from you and others, section 4 will =
likely undergo heavy restructuring :-)
> =20
> For the webfinger link relations under webfinger.net, are those that =
should go into the existing IANA registry for link relations that was =
defined by RFC 5988?  (See =
http://www.iana.org/assignments/link-relations/link-relations.xml)  In =
any case, registration of link relations can certainly be done as a part =
of this specification or it could be done separately.  My own opinion is =
that it would be better to define link relations separately, but I=92m =
willing to follow the group opinion on this one.  Even I don=92t know =
what those webfinger.net relations are :-)
> =20
> Paul
> =20
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Goix Laurent Walter
> Sent: Friday, November 18, 2011 6:34 AM
> To: apps-discuss@ietf.org
> Subject: [apps-discuss] Webfinger & acct: draft
> =20
> Paul, all,
> =20
> Thank you for starting addressing this standardization topic within =
IETF. Webfinger (and acct:) indeed are being increasingly used and the =
whole community would benefit from a well-referenced specification for =
it.
> =20
> Here are some comments on the draft:
> -          At this stage acct: scheme is needed from a formal point of =
view only I guess, so there may not be the need for a full addr-spec =
support.
> -          I also support the point raised by Mykyta around i18n.  I =
guess as we are targeting user addressing more than resource addressing =
in general, and given the rise of Internet & social networks in =
non-ascii countries it would be important to target a dual URI/IRI =
scheme (following the path of the mailto rfc6068bis draft)
> -          If no other spec is currently using the acct: scheme then =
it may be kept in the webfinger spec, but some existing specifications =
may be interested in referencing it as primary/preferred addressing =
mechanism (independently from webfinger), e.g. Opensocial, =
activitystrea.ms
> -          =46rom a more structural point of view it may be useful to =
better distinguish the sections related to the scheme from the ones =
relates to webfinger. Right now 4.1 and 4.2 are very different in =
purpose and may become 4 and 5. Current section 5 could become a =
subsection of webfinger (say 5.2)
> -          It may also be good to distinguish the behavior on the =
server side (creating/exposing the descriptor and its content) from the =
actual discovery behavior from the client.
> -          Webfinger further uses specific link =93rels=94, which now =
are referenced under webfinger.net domain. I guess some of these rels =
would need to be registered as pure tokens (no URI), e.g. =93avatar=94, =
=93profile-page=94 and specified in this spec.
> -          Reference 8 can now be updated to rfc6415
> =20
> Cheers
> Walter
> =20
> ------------------------------------------------------------------
> Telecom Italia
> Laurent-Walter Goix
> Innovation & Industry Relations, Research & Prototyping, Future =
Internet=20
> Piazza Einaudi 8 - 20124 Milano (Italy)
> Tel. +39 026213445
> Mob. +39 3356114196
> Fax +39 0641869055
> =20
> =20
> 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.
>=20
> Rispetta l'ambiente. Non stampare questa mail se non =E8 =
necessario.
> =20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail-325--244156301
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

 I agree. Both the notion of registering link =
relations and the possibility of a broader usage of the acct: URI beyond =
Webfinger really require some group discussion to help us decide if the =
draft remains self-contained as a single document or gets broken into =
several.

Regards,

Gonzalo



On Nov 18, 2011, =
at 6:08 PM, Paul E. Jones wrote:

Walter,
Thanks for your feedback on the text.  I=92ll =
be revising the document accordingly.  Based on comments from you =
and others, section 4 will likely undergo heavy restructuring =
:-)
For the webfinger link relations under webfinger.net, are those that should go into the =
existing IANA registry for link relations that was defined by RFC =
5988?  (See  webfinger.net relations are =
:-)
Paul
 apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@=
ietf.org] On Behalf =
Of Goix Laurent =
Walter
Sent: Friday, November 18, 2011 =
6:34 AM
To:  [apps-discuss] Webfinger =
& acct: draft
 
Paul, =
all,
 
Thank you for starting addressing this standardization topic =
within IETF. Webfinger (and acct:) indeed are being increasingly used =
and the whole community would benefit from a well-referenced =
specification for it.
 
Here are some comments on the draft:
- At this stage =
acct: scheme is needed from a formal point of view only I guess, so =
there may not be the need for a full addr-spec =
support.
- I also =
support the point raised by Mykyta around i18n.  I guess as we are =
targeting user addressing more than resource addressing in general, and =
given the rise of Internet & social networks in non-ascii countries =
it would be important to target a dual URI/IRI scheme (following the =
path of the mailto rfc6068bis draft)
- If no other =
spec is currently using the acct: scheme then it may be kept in the =
webfinger spec, but some existing specifications may be interested in =
referencing it as primary/preferred addressing mechanism (independently =
from webfinger), e.g. Opensocial, activitystrea.ms
- =46rom a more =
structural point of view it may be useful to better distinguish the =
sections related to the scheme from the ones relates to webfinger. Right =
now 4.1 and 4.2 are very different in purpose and may become 4 and 5. =
Current section 5 could become a subsection of webfinger (say =
5.2)
- It may also =
be good to distinguish the behavior on the server side =
(creating/exposing the descriptor and its content) from the actual =
discovery behavior from the client.
- Webfinger =
further uses specific link =93rels=94, which now are referenced =
under webfinger.net domain. I guess some of =
these rels would need to be registered as pure tokens (no URI), e.g. =
=93avatar=94, =93profile-page=94 and specified in this =
spec.
- Reference 8 =
can now be updated to rfc6415
Cheers
Walter
 
Telecom Italia
Laurent-Walter =
Goix
Innovation & Industry =
Relations, Research & Prototyping, Future =
Internet 
Piazza =
Einaudi 8 - 20124 Milano (Italy)
Tel. +39 026213445
Mob. +39 =
3356114196
Fax +39 0641869055 
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.
apps-discuss@ietf.org
> registration of parameters does not imply advancement along a =
standardization
>> path). I sense a theme...
>=20
>=20
> It's actually closer to a principle.
>=20
> It is extremely natural to want names to carry deep semantics.  It's =
an easy place to put parametric information.  Unfortunately it seems to =
always create problems, most notably when there is a change in state, =
which is exactly the concern we are dealing with in the draft.
>=20
> d/
>=20
>=20
> --=20
>=20
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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





From dhc@dcrocker.net  Fri Nov 18 19:10:51 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D081711E809B for ; Fri, 18 Nov 2011 19:10:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.933
X-Spam-Level: 
X-Spam-Status: No, score=-4.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RECV_SPAM_DOMN0b=1.666]
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 tkBhCed+FXlM for ; Fri, 18 Nov 2011 19:10:51 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2964B21F8922 for ; Fri, 18 Nov 2011 19:10:51 -0800 (PST)
Received: from [192.168.0.77] (59-115-128-147.dynamic.hinet.net [59.115.128.147]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAJ3AKFn008509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Nov 2011 19:10:33 -0800
Message-ID: <4EC71E16.3000200@dcrocker.net>
Date: Sat, 19 Nov 2011 11:10:14 +0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Mark Nottingham 
References: <20111024161910.8048.2279.idtracker@ietfa.amsl.com> 	<4EC0AD84.5060502@dcrocker.net>  <4EC0D517.3030400@dcrocker.net>  <4EC0F17B.5020003@dcrocker.net> <4EC0F1E7.7000602@stpeter.im> <4B9A1851-31B5-4147-A284-77A63664401C@mnot.net> <4EC18DEB.6090003@stpeter.im> <4EC190AA.3000705@dcrocker.net> <2D961F5E-1613-4B8B-AD35-FF2077DFF8B8@mnot.net>
In-Reply-To: <2D961F5E-1613-4B8B-AD35-FF2077DFF8B8@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 18 Nov 2011 19:10:34 -0800 (PST)
Cc: Randall Gellens , apps-discuss@ietf.org
Subject: Re: [apps-discuss] status and name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Nov 2011 03:10:52 -0000

With apologies, I'm going to try to follow a serious path in spite of that not
being what you intended:

    Note that the problem is not with ICANN but with the population of folk
making registrations.  THEY provide the initiative for the misguided model(s) of
name use..

    That fact can be an important lesson for anyone else doing work involving
name/string registration.

d/


On 11/19/2011 9:34 AM, Mark Nottingham wrote:
> Perhaps this could be communicated to ICANN.
>
> /me ducks
>
> On 14/11/2011, at 2:05 PM, Dave CROCKER wrote:
>> On 11/15/2011 5:53 AM, Peter Saint-Andre wrote:
>>> The same principle has emerged from discussions on the "Happy IANA" list
>>> (i.e., registration of parameters does not imply advancement along a
>>> standardization path). I sense a theme...
>>
>> It's actually closer to a principle.
>>
>> It is extremely natural to want names to carry deep semantics.  It's an
>> easy place to put parametric information.  Unfortunately it seems to
>> always create problems, most notably when there is a change in state, which
>> is exactly the concern we are dealing with in the draft.


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From romeda@gmail.com  Fri Nov 18 22:58:51 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24DA21F8B5B for ; Fri, 18 Nov 2011 22:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level: 
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ljgjI3KL4F8x for ; Fri, 18 Nov 2011 22:58:50 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D93021F861E for ; Fri, 18 Nov 2011 22:58:50 -0800 (PST)
Received: by ggeq3 with SMTP id q3so2038626gge.31 for ; Fri, 18 Nov 2011 22:58:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BDqM1qD7tHNKUse56H3pHcddXcwxRAiyEuYfO0t5rgo=; b=vv3lemtXRYXd+alod3ll+04mFyToSaZCryiKutcGyFuv4atDkDgkv3x22/LtKugYUV jWDarZzPAk4BocsSsGoUM4hT6DoTxAk3gBUxtp59I3UrgIUjG3gFYlhaKXeQ5mxNCToa ehJQFARTw5U9UKkk9qdXTyXZKoOztn2QBLTM0=
Received: by 10.182.45.3 with SMTP id i3mr1380839obm.62.1321685928363; Fri, 18 Nov 2011 22:58:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.44.35 with HTTP; Fri, 18 Nov 2011 22:58:27 -0800 (PST)
In-Reply-To: <740878FD-AA49-4F62-8612-7AE76CA36710@cisco.com>
References:  <047c01cca646$f32f8100$d98e8300$@packetizer.com> <740878FD-AA49-4F62-8612-7AE76CA36710@cisco.com>
From: Blaine Cook 
Date: Sat, 19 Nov 2011 06:58:27 +0000
Message-ID: 
To: Gonzalo Salgueiro 
Content-Type: multipart/alternative; boundary=f46d0444e8f143c6bd04b210fcb6
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger & acct: draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Nov 2011 06:58:51 -0000

--f46d0444e8f143c6bd04b210fcb6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1; defining the actual link relations should be done outside the webfinger
spec, most likely as part of RFC 5988 as Paul mentioned.

The relations are perhaps the trickiest bit of webfinger to standardise,
but thankfully 5988 offers guidance; new relations should be defined as
specifically as possible, with obvious relation overlap being aggregated
into more general identifiers, and eventually being submitted to the
registry once sufficient deployment mandates it.

b.

On 18 November 2011 23:53, Gonzalo Salgueiro  wrote:

>  I agree. Both the notion of registering link relations and the
> possibility of a broader usage of the acct: URI beyond Webfinger really
> require some group discussion to help us decide if the draft remains
> self-contained as a single document or gets broken into several.
>
> Regards,
>
> Gonzalo
>
>
>
> On Nov 18, 2011, at 6:08 PM, Paul E. Jones wrote:
>
>  Walter,****
> ** **
> Thanks for your feedback on the text.  I=E2=80=99ll be revising the docum=
ent
> accordingly.  Based on comments from you and others, section 4 will likel=
y
> undergo heavy restructuring :-)****
> ** **
> For the webfinger link relations under webfinger.net, are those that
> should go into the existing IANA registry for link relations that was
> defined by RFC 5988?  (See
> http://www.iana.org/assignments/link-relations/link-relations.xml)  In
> any case, registration of link relations can certainly be done as a part =
of
> this specification or it could be done separately.  My own opinion is tha=
t
> it would be better to define link relations separately, but I=E2=80=99m w=
illing to
> follow the group opinion on this one.  Even I don=E2=80=99t know what tho=
se
> webfinger.net relations are :-)****
> ** **
> Paul****
> ** **
>  *From:* apps-discuss-bounces@ietf.org [mailto:
> apps-discuss-bounces@ietf.org] *On Behalf Of *Goix Laurent Walter
> *Sent:* Friday, November 18, 2011 6:34 AM
> *To:* apps-discuss@ietf.org
> *Subject:* [apps-discuss] Webfinger & acct: draft****
> ** **
> Paul, all,****
> ** **
> Thank you for starting addressing this standardization topic within IETF.
> Webfinger (and acct:) indeed are being increasingly used and the whole
> community would benefit from a well-referenced specification for it.****
> ** **
> Here are some comments on the draft:****
> -          At this stage acct: scheme is needed from a formal point of
> view only I guess, so there may not be the need for a full addr-spec
> support.****
> -          I also support the point raised by Mykyta around i18n.  I
> guess as we are targeting user addressing more than resource addressing i=
n
> general, and given the rise of Internet & social networks in non-ascii
> countries it would be important to target a dual URI/IRI scheme (followin=
g
> the path of the mailto rfc6068bis draft)****
> -          If no other spec is currently using the acct: scheme then it
> may be kept in the webfinger spec, but some existing specifications may b=
e
> interested in referencing it as primary/preferred addressing mechanism
> (independently from webfinger), e.g. Opensocial, activitystrea.ms****
> -          From a more structural point of view it may be useful to
> better distinguish the sections related to the scheme from the ones relat=
es
> to webfinger. Right now 4.1 and 4.2 are very different in purpose and may
> become 4 and 5. Current section 5 could become a subsection of webfinger
> (say 5.2)****
> -          It may also be good to distinguish the behavior on the server
> side (creating/exposing the descriptor and its content) from the actual
> discovery behavior from the client.****
> -          Webfinger further uses specific link =E2=80=9Crels=E2=80=9D, w=
hich now are
> referenced under webfinger.net domain. I guess some of these rels would
> need to be registered as pure tokens (no URI), e.g. =E2=80=9Cavatar=E2=80=
=9D,
> =E2=80=9Cprofile-page=E2=80=9D and specified in this spec.****
> -          Reference 8 can now be updated to rfc6415****
> ** **
> Cheers****
> Walter****
> ** **
> ------------------------------------------------------------------
> *Telecom Italia
> *Laurent-Walter Goix****
> Innovation & Industry Relations, Research & Prototyping, Future Internet =
*
> ***
> Piazza Einaudi 8 - 20124 Milano (Italy)
> Tel. +39 026213445****
> Mob. +39 3356114196****
> Fax +39 0641869055****
> ** **
> ** **
>  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. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> 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 an=
d
> advise the sender by return e-mail, Thanks.*****
> *Rispetta l'ambiente. Non stampare questa mail se non =C3=
=A8
> necessario.*****
> ** **
> _______________________________________________
> 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
>
>

--f46d0444e8f143c6bd04b210fcb6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1; defining the actual link relations should be done outside the webfinger=
 spec, most likely as part of RFC 5988 as Paul mentioned.

The relations are perhaps the trickiest bit of webfinger to standardise, =
but thankfully 5988 offers guidance; new relations should be defined as spe=
cifically as possible, with obvious relation overlap being aggregated into =
more general identifiers, and eventually being submitted to the registry on=
ce sufficient deployment mandates it.


On 18 Novem=
ber 2011 23:53, Gonzalo Salgueiro <gsalguei@cisco.com> wrote:



=C2=A0I agree. Both the notion of regis=
tering link relations and the possibility of a broader usage of the acct: U=
RI beyond Webfinger really require some group discussion to help us decide =
if the draft remains self-contained as a single document or gets broken int=
o several.



Regards,

Gonzalo



On Nov 18, =
2011, at 6:08 PM, Paul E. Jones wrote:







Walter,=




=C2=A0


Thanks for your feedback on the text.=
=C2=A0 I=E2=80=99ll be revising the document accordingly.=C2=A0 Based on co=
mments from you and others, section 4 will likely undergo heavy restructuri=
ng :-)



=C2=A0


For the webfinger link relations under=
=C2=A0webfinger.net, are those that=
 should go into the existing IANA registry for link relations that was defi=
ned by RFC 5988?=C2=A0 (See=C2=A0http://www.iana.org/assignments/link=
-relations/link-relations.xml)=C2=A0 In any case, registration of link =
relations can certainly be done as a part of this specification or it could=
 be done separately.=C2=A0 My own opinion is that it would be better to def=
ine link relations separately, but I=E2=80=99m willing to follow the group =
opinion on this one.=C2=A0 Even I don=E2=80=99t know what those=C2=A0=
webfinger.net=C2=A0relations=
 are :-)



=C2=A0


Paul
=C2=A0









From:=C2=A0apps-discuss-bounces@ietf.org=C2=
=A0[mailto:apps-discuss-bounces@ietf.org]=C2=A0On Beha=
lf Of=C2=A0Goix Laurent Walter


Sent:=C2=A0Friday, November 18, 2011 6:34 AM
To:<=
/b>=C2=A0apps-discuss@ietf.org<=
/a>
Subject:=C2=A0[apps-discuss] Webfinger & acc=
t: draft






=C2=A0


Here are some comments on the draft:
-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0At this stag=
e acct: scheme is needed from a formal point of view only I guess, so there=
 may not be the need for a full addr-spec support.



-=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I also support the point raised by Mykyta around i18n. =C2=A0I gue=
ss as we are targeting user addressing more than resource addressing in gen=
eral, and given the rise of Internet & social networks in non-ascii cou=
ntries it would be important to target a dual URI/IRI scheme (following the=
 path of the mailto rfc6068bis draft)





-=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0From a more structural point of view it may be useful to better di=
stinguish the sections related to the scheme from the ones relates to webfi=
nger. Right now 4.1 and 4.2 are very different in purpose and may become 4 =
and 5. Current section 5 could become a subsection of webfinger (say 5.2)



-=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0It may also be good to distinguish the behavior on the server side=
 (creating/exposing the descriptor and its content) from the actual discove=
ry behavior from the client.



-=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Webfinger further uses specific link =E2=80=9Crels=E2=80=9D, which=
 now are referenced under=C2=A0webfinge=
r.net=C2=A0domain. I guess some of these rels would need t=
o be registered as pure tokens (no URI), e.g. =E2=80=9Cavatar=E2=80=9D, =E2=
=80=9Cprofile-page=E2=80=9D and specified in this spec.



-=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Reference 8 can now be updated to rfc6415



=C2=A0


Cheers
Walter


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


Te=
lecom Italia
Laurent-Walter Goix


Innovation &=
amp; Industry Relations, Research & Prototyping, Future Internet=C2=A0<=
u>


=
Piazza Einaudi 8=C2=A0- 20124 Milano (Italy)
Tel. +39 026213445







=C2=A0



=
=C2=A0








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



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



<image001.gif>Rispetta l'ambiente. N=
on stampare questa mail se non =C3=A8 necessario.



=C2=A0



_______________________________________________
apps-discuss=
 mailing list
apps-discuss@ietf.org

https://www.ietf.org/m=
ailman/listinfo/apps-discuss





_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





--f46d0444e8f143c6bd04b210fcb6--

From evnikita2@gmail.com  Fri Nov 18 23:02:17 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FEC21F8BBC for ; Fri, 18 Nov 2011 23:02:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.028
X-Spam-Level: 
X-Spam-Status: No, score=-3.028 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, 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 oQfPLVK7L7vI for ; Fri, 18 Nov 2011 23:02:16 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4EC621F8BBB for ; Fri, 18 Nov 2011 23:02:15 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so5002604bkb.31 for ; Fri, 18 Nov 2011 23:02:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=H7u5Wp4ebFatt0Ce9KuZ0AEQrVdPFY16DBby5VonQzQ=; b=ZxntJG+0pshsHQgQwq1iAO7WXi9eKYJ+HYbVQU4p5wLAbATau8J6zc/wc1WzyqYEuK NkiVlNCfwn24IgKwVGHolsrBLcxRwX67k/dS62jLBO/UEzJpUoQWnhkd3GtJpdDJZSFg adqlFXSSqwYdYUwC4EpucgAAWRKr/QO8njW4E=
Received: by 10.204.156.219 with SMTP id y27mr6337464bkw.125.1321686134582; Fri, 18 Nov 2011 23:02:14 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x19sm7794132fag.5.2011.11.18.23.02.12 (version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 23:02:13 -0800 (PST)
Message-ID: <4EC754A8.3090408@gmail.com>
Date: Sat, 19 Nov 2011 09:03:04 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References:  <047c01cca646$f32f8100$d98e8300$@packetizer.com> <740878FD-AA49-4F62-8612-7AE76CA36710@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010607030606090009060208"
Subject: Re: [apps-discuss] Webfinger & acct: draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Nov 2011 07:02:17 -0000

This is a multi-part message in MIME format.
--------------010607030606090009060208
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

19.11.2011 8:58, Blaine Cook wrote:
> +1; defining the actual link relations should be done outside the 
> webfinger spec, most likely as part of RFC 5988 as Paul mentioned.
>
> The relations are perhaps the trickiest bit of webfinger to 
> standardise, but thankfully 5988 offers guidance; new relations should 
> be defined as specifically as possible, with obvious relation overlap 
> being aggregated into more general identifiers, and eventually being 
> submitted to the registry once sufficient deployment mandates it.

How many of them will we have to define?  Can we at all predict how will 
Webfinger be used?

Mykyta Yevstifeyev

>
> b.
>
> On 18 November 2011 23:53, Gonzalo Salgueiro  > wrote:
>
>      I agree. Both the notion of registering link relations and the
>     possibility of a broader usage of the acct: URI beyond Webfinger
>     really require some group discussion to help us decide if the
>     draft remains self-contained as a single document or gets broken
>     into several.
>
>     Regards,
>
>     Gonzalo
>
>
>
>     On Nov 18, 2011, at 6:08 PM, Paul E. Jones wrote:
>
>>     Walter,
>>     Thanks for your feedback on the text.  I’ll be revising the
>>     document accordingly.  Based on comments from you and others,
>>     section 4 will likely undergo heavy restructuring :-)
>>     For the webfinger link relations underwebfinger.net
>>     , are those that should go into the
>>     existing IANA registry for link relations that was defined by RFC
>>     5988? 
>>     (Seehttp://www.iana.org/assignments/link-relations/link-relations.xml) 
>>     In any case, registration of link relations can certainly be done
>>     as a part of this specification or it could be done separately. 
>>     My own opinion is that it would be better to define link
>>     relations separately, but I’m willing to follow the group opinion
>>     on this one.  Even I don’t know what thosewebfinger.net
>>     relations are :-)
>>     Paul
>>     *From:*apps-discuss-bounces@ietf.org
>>     [mailto:apps-discuss-bounces@ietf.org
>>     ]*On Behalf Of*Goix Laurent
>>     Walter
>>     *Sent:*Friday, November 18, 2011 6:34 AM
>>     *To:*apps-discuss@ietf.org 
>>     *Subject:*[apps-discuss] Webfinger & acct: draft
>>     Paul, all,
>>     Thank you for starting addressing this standardization topic
>>     within IETF. Webfinger (and acct:) indeed are being increasingly
>>     used and the whole community would benefit from a well-referenced
>>     specification for it.
>>     Here are some comments on the draft:
>>     -At this stage acct: scheme is needed from a formal point of view
>>     only I guess, so there may not be the need for a full addr-spec
>>     support.
>>     -I also support the point raised by Mykyta around i18n.  I guess
>>     as we are targeting user addressing more than resource addressing
>>     in general, and given the rise of Internet & social networks in
>>     non-ascii countries it would be important to target a dual
>>     URI/IRI scheme (following the path of the mailto rfc6068bis draft)
>>     -If no other spec is currently using the acct: scheme then it may
>>     be kept in the webfinger spec, but some existing specifications
>>     may be interested in referencing it as primary/preferred
>>     addressing mechanism (independently from webfinger), e.g.
>>     Opensocial, activitystrea.ms 
>>     -From a more structural point of view it may be useful to better
>>     distinguish the sections related to the scheme from the ones
>>     relates to webfinger. Right now 4.1 and 4.2 are very different in
>>     purpose and may become 4 and 5. Current section 5 could become a
>>     subsection of webfinger (say 5.2)
>>     -It may also be good to distinguish the behavior on the server
>>     side (creating/exposing the descriptor and its content) from the
>>     actual discovery behavior from the client.
>>     -Webfinger further uses specific link “relsâ€, which now are
>>     referenced underwebfinger.net domain. I
>>     guess some of these rels would need to be registered as pure
>>     tokens (no URI), e.g. “avatarâ€, “profile-page†and specified in
>>     this spec.
>>     -Reference 8 can now be updated to rfc6415
>>     Cheers
>>     Walter
>>     ------------------------------------------------------------------
>>     *Telecom Italia
>>     *Laurent-Walter Goix
>>     Innovation & Industry Relations, Research & Prototyping, Future
>>     Internet
>>     Piazza Einaudi 8 - 20124 Milano (Italy)
>>     Tel. +39 026213445 
>>     Mob. +39 3356114196 
>>     Fax +39 0641869055 
>>     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./
>>
>>     *Rispetta l'ambiente. Non stampare questa mail se
>>     non è necessario.*
>>
>>     _______________________________________________
>>     apps-discuss mailing list
>>     apps-discuss@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>     _______________________________________________
>     apps-discuss mailing list
>     apps-discuss@ietf.org 
>     https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--------------010607030606090009060208
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    19.11.2011 8:58, Blaine Cook wrote:
    
+1; defining the actual link relations should be done
      outside the webfinger spec, most likely as part of RFC 5988 as
      Paul mentioned.
      


      

      
The relations are perhaps the trickiest bit of webfinger to
        standardise, but thankfully 5988 offers guidance; new relations
        should be defined as specifically as possible, with obvious
        relation overlap being aggregated into more general identifiers,
        and eventually being submitted to the registry once sufficient
        deployment mandates it.

    

    

    How many of them will we have to define?  Can we at all predict how
    will Webfinger be used?

    

    Mykyta Yevstifeyev

    

    

      


      

      
b.

      


        
On 18 November 2011 23:53, Gonzalo
          Salgueiro <gsalguei@cisco.com>
          wrote:

          

            
 I agree. Both the notion
              of registering link relations and the possibility of a
              broader usage of the acct: URI beyond Webfinger really
              require some group discussion to help us decide if the
              draft remains self-contained as a single document or gets
              broken into several.
              

                

              

              
Regards,

              


              

              
Gonzalo

              


                


                

                

                  


                  

                  

                    

                      

                        
On Nov 18, 2011, at 6:08 PM, Paul E. Jones
                          wrote:

                        

                      

                    

                    

                      
                        

                          

                            

                              

                                
Walter,

                                
 

                                
Thanks
                                    for your feedback on the text.  I’ll
                                    be revising the document
                                    accordingly.  Based on comments from
                                    you and others, section 4 will
                                    likely undergo heavy restructuring
                                    :-)

                                
 

                                
For the
                                    webfinger link relations under webfinger.net,
                                    are those that should go into the
                                    existing IANA registry for link
                                    relations that was defined by RFC
                                    5988?  (See http://www.iana.org/assignments/link-relations/link-relations.xml) 
                                    In any case, registration of link
                                    relations can certainly be done as a
                                    part of this specification or it
                                    could be done separately.  My own
                                    opinion is that it would be better
                                    to define link relations separately,
                                    but I’m willing to follow the group
                                    opinion on this one.  Even I don’t
                                    know what those webfinger.net relations
                                    are :-)

                                
 

                                
Paul

                                
 

                              

                            

                            

                              

                                

                                  

                                    

                                      
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On
                                            Behalf Of Goix
                                          Laurent Walter

                                          Sent: Friday,
                                          November 18, 2011 6:34 AM

                                          To: apps-discuss@ietf.org

                                          Subject: [apps-discuss]
                                          Webfinger & acct: draft

                                    

                                  

                                  
 

                                  
Paul,
                                    all,

                                  
 

                                  
Thank
                                    you for starting addressing this
                                    standardization topic within IETF.
                                    Webfinger (and acct:) indeed are
                                    being increasingly used and the
                                    whole community would benefit from a
                                    well-referenced specification for
                                    it.

                                  
 

                                  
Here
                                    are some comments on the draft:

                                  
-          At
                                    this stage acct: scheme is needed
                                    from a formal point of view only I
                                    guess, so there may not be the need
                                    for a full addr-spec support.

                                  
-          I
                                    also support the point raised by
                                    Mykyta around i18n.  I guess as we
                                    are targeting user addressing more
                                    than resource addressing in general,
                                    and given the rise of Internet &
                                    social networks in non-ascii
                                    countries it would be important to
                                    target a dual URI/IRI scheme
                                    (following the path of the mailto
                                    rfc6068bis draft)

                                  
-          If
                                    no other spec is currently using the
                                    acct: scheme then it may be kept in
                                    the webfinger spec, but some
                                    existing specifications may be
                                    interested in referencing it as
                                    primary/preferred addressing
                                    mechanism (independently from
                                    webfinger), e.g. Opensocial, activitystrea.ms

                                  
-          From
                                    a more structural point of view it
                                    may be useful to better distinguish
                                    the sections related to the scheme
                                    from the ones relates to webfinger.
                                    Right now 4.1 and 4.2 are very
                                    different in purpose and may become
                                    4 and 5. Current section 5 could
                                    become a subsection of webfinger
                                    (say 5.2)

                                  
-          It
                                    may also be good to distinguish the
                                    behavior on the server side
                                    (creating/exposing the descriptor
                                    and its content) from the actual
                                    discovery behavior from the client.

                                  
-          Webfinger
                                    further uses specific link “relsâ€,
                                    which now are referenced under webfinger.net domain.
                                    I guess some of these rels would
                                    need to be registered as pure tokens
                                    (no URI), e.g. “avatarâ€,
                                    “profile-page†and specified in this
                                    spec.

                                  
-          Reference
                                    8 can now be updated to rfc6415

                                  
 

                                  
Cheers

                                  
Walter

                                  
 

                                  
------------------------------------------------------------------

                                    Telecom
                                        Italia

                                      Laurent-Walter
                                      Goix

                                  
Innovation &
                                      Industry Relations, Research &
                                      Prototyping, Future Internet 

                                  
Piazza
                                      Einaudi 8 - 20124 Milano (Italy)

                                      Tel. +39 026213445

                                  
                                  
                                  
 

                                  
 

                                

                              

                              

                                
                                  

                                    
                                      

                                        

                                          

                                            
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.

                                        

                                      

                                      
<image001.gif>Rispetta
                                            l'ambiente. Non stampare
                                            questa mail se non è
                                            necessario.

                                    		
                                  

                                
                              

                              
 

                            

                          

_______________________________________________

                          apps-discuss mailing list

                          apps-discuss@ietf.org

                          https://www.ietf.org/mailman/listinfo/apps-discuss

                        

                      

                  

                  

                

              

            

            

            _______________________________________________

            apps-discuss mailing list

            apps-discuss@ietf.org

            https://www.ietf.org/mailman/listinfo/apps-discuss

            

          

        

        

      

      

      

      

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


    

    

  


--------------010607030606090009060208--

From stpeter@stpeter.im  Fri Nov 18 23:44:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CCD21F8906 for ; Fri, 18 Nov 2011 23:44:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.608
X-Spam-Level: 
X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 5i2xpoU5GInl for ; Fri, 18 Nov 2011 23:44:24 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AAF2C21F88B6 for ; Fri, 18 Nov 2011 23:44:24 -0800 (PST)
Received: from squire.local (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2F2FF4214E; Sat, 19 Nov 2011 00:50:46 -0700 (MST)
Message-ID: <4EC75E54.4010208@stpeter.im>
Date: Sat, 19 Nov 2011 16:44:20 +0900
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
References:  <4EC60870.4080805@it.aoyama.ac.jp>
In-Reply-To: <4EC60870.4080805@it.aoyama.ac.jp>
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: Ned Freed , "apps-discuss@ietf.org" , "gadams@xfsi.com Adams" , Chris Lilley , "Levantovsky, Vladimir" , David Singer 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Nov 2011 07:44:25 -0000

On 11/18/11 4:25 PM, "Martin J. Dürst" wrote:
> Hello Larry,
> 
> On 2011/11/18 10:29, Larry Masinter wrote:
>> I think any definition of a new top level type should come with some
>> use cases, some protocol or operation, which is more functional,
>> reliable, better, improved, useful,.
> 
> I don't see anything like this for image/, video/, or audio/ in the
> original documents. They just started with the assumption that these are
> not the same media, so they shouldn't be in the main top-level type.
> What's the problem with applying this same argument to font/? What will
> stop working, or otherwise produce undesired consequences, if we
> introduce font/?
> 
> 
>> #  even if it involves re-registering some of the existing subtypes
>> under the new font/* tree.
>>
>> Types with two names seem like more of a problem, and re-registering
>> existing types with a potentially long tail of overlapping use
>> problematic.
> 
> It's definitely not optimal. It would have been better to register these
> under font/ much earlier. We can still learn from that experience.
> 
> 
>> #  I brought this up for discussion at today's conference call with
>> W3C WebFonts WG, and the general opinion was that having font/* type
>> registered would still be a good thing for the industry.
>>
>> I think we still need at least one concrete practical use case. Just
>> asking in the abstract won't necessarily get you a good answer.
> 
> I don't think we need to continue to press for concrete, practical,
> fail-safe, everybody-will-be-satisfied use cases. At some point, not
> everybody will be convinced of the absolute need of font/. But that's
> fine. The main point is that those who think having font/ is useful can
> use it.

Agreed. So, who holds the pen on writing an I-D?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From romeda@gmail.com  Sat Nov 19 04:24:51 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3409221F8A95 for ; Sat, 19 Nov 2011 04:24:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.448
X-Spam-Level: 
X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 e6AhgEJ1wCOk for ; Sat, 19 Nov 2011 04:24:46 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 282E921F84DC for ; Sat, 19 Nov 2011 04:24:46 -0800 (PST)
Received: by ggeq3 with SMTP id q3so2192190gge.31 for ; Sat, 19 Nov 2011 04:24:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+IpfktO10mLH1ck5ftgVQaEVrlaqEbro4lPqrNPZ7ss=; b=VpOFTRKH3ZWB88gTrFzadUfY+hmbmcL0rWMxkceVWNFnTRjMxm2/Cjcw9rCjl+SWND cGK8XCtngi05eupsUSxPL79zYUqp2m0wa7/QGVAIaQm/Y7iPyItZ66zFuZWdpm6GneAS LOYh92rl8NHAswRXLzfxp49Dy9MDmJg85cZnI=
Received: by 10.182.172.41 with SMTP id az9mr1569096obc.42.1321705485699; Sat, 19 Nov 2011 04:24:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.44.35 with HTTP; Sat, 19 Nov 2011 04:24:24 -0800 (PST)
In-Reply-To: <4EC754A8.3090408@gmail.com>
References:  <047c01cca646$f32f8100$d98e8300$@packetizer.com> <740878FD-AA49-4F62-8612-7AE76CA36710@cisco.com>  <4EC754A8.3090408@gmail.com>
From: Blaine Cook 
Date: Sat, 19 Nov 2011 12:24:24 +0000
Message-ID: 
To: =?UTF-8?B?TXlreXRhIFlldnN0aWZleWV2ICjQnC4g0ITQstGB0YLRltGE0LXRlNCyKQ==?= 
Content-Type: multipart/alternative; boundary=e89a8f83a729f90c0a04b21589e2
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger & acct: draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Nov 2011 12:24:51 -0000

--e89a8f83a729f90c0a04b21589e2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2011/11/19 "Mykyta Yevstifeyev (=D0=9C. =D0=84=D0=B2=D1=81=D1=82=D1=96=D1=
=84=D0=B5=D1=94=D0=B2)" 

>  19.11.2011 8:58, Blaine Cook wrote:
>
> +1; defining the actual link relations should be done outside the
> webfinger spec, most likely as part of RFC 5988 as Paul mentioned.
>
>  The relations are perhaps the trickiest bit of webfinger to standardise,
> but thankfully 5988 offers guidance; new relations should be defined as
> specifically as possible, with obvious relation overlap being aggregated
> into more general identifiers, and eventually being submitted to the
> registry once sufficient deployment mandates it.
>
>
> How many of them will we have to define?  Can we at all predict how will
> Webfinger be used?
>

We don't know, and no. :-)

We can make educated guesses, but it would be folly to start defining
shared, generic terminology before implementation. The XMPP specs are a
great example of too much definition stifling actual implementations from
growing and evolving.

b.

--e89a8f83a729f90c0a04b21589e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2011/11/19 "Mykyta Yevstifeyev (=D0=9C. =D0=84=D0=B2=D1=81=D1=82=D1=96=
=D1=84=D0=B5=D1=94=D0=B2)" <evnikita2@gmail.com>



 =20
   =20
 =20
  

    19.11.2011 8:58, Blaine Cook wrote:
    
+1; defining the actual link relations should=
 be done
      outside the webfinger spec, most likely as part of RFC 5988 as
      Paul mentioned.
      


      

      
The relations are perhaps the trickiest bit of webfinger to
        standardise, but thankfully 5988 offers guidance; new relations
        should be defined as specifically as possible, with obvious
        relation overlap being aggregated into more general identifiers,
        and eventually being submitted to the registry once sufficient
        deployment mandates it.

    

    

    How many of them will we have to define?=C2=A0 Can we at all predict ho=
w
    will Webfinger be used?

We don=
9;t know, and no. :-)

We can make educated guesses=
, but it would be folly to start defining shared, generic terminology befor=
e implementation. The XMPP specs are a great example of too much definition=
 stifling actual implementations from growing and evolving.




b.


--e89a8f83a729f90c0a04b21589e2--

From ietfc@btconnect.com  Sat Nov 19 04:38:06 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709E521F8512 for ; Sat, 19 Nov 2011 04:38:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.245
X-Spam-Level: 
X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.054,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 nDaXN8Hxdr-B for ; Sat, 19 Nov 2011 04:38:05 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 62DEF21F8507 for ; Sat, 19 Nov 2011 04:38:04 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr09.btconnect.com with SMTP id FFR71920; Sat, 19 Nov 2011 12:37:44 +0000 (GMT)
Message-ID: <006f01cca6ae$dfa5b100$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Levantovsky, Vladimir" , "=?UTF-8?Q?Martin_J._D=C3=BCrst?=" 
References: <4EC0C2C8.2010500@it.aoyama.ac.jp>	<01O8EV98HXC800RCTX@mauve.mrochek.com><99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com><7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org><4EC31D1D.1000509@stpeter.im><7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org><4EC6031F.7000002@it.aoyama.ac.jp> <7534F85A589E654EB1E44E5CFDC19E3D117FCD7382@wob-email-01.agfamonotype.org>
Date: Sat, 19 Nov 2011 12:29:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4EC7A316.00CB, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.19.120314:17:7.944, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS
X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4EC7A319.014A,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: Chris Lilley , Ned Freed , apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Nov 2011 12:38:06 -0000

----- Original Message -----
From: "Levantovsky, Vladimir" 
To: "Martin J. Dürst" 
Cc: "Ned Freed" ; ;
; "Chris Lilley" ; "David Singer"

Sent: Friday, November 18, 2011 3:35 PM

> Hello Marin, all,
>
> Besides vendor-specific types, the only registered font type that I am aware
of is 'application/font-woff'. W3C WebFonts WG has submitted a registration for
this subtype about a year ago, and the text of the registration is available as
Annex B of the WOFF specification:
http://dev.w3.org/webfonts/WOFF/spec/#appendix-b
>

Looking at this URI I found at least a partial answer to my earlier question as
to what W3C mean by font, namely
"This document specifies a simple compressed file format for fonts, designed
primarily for use on the Web and known as WOFF (Web Open Font Format). Despite
this name, WOFF should be regarded as a container format or "wrapper" for font
data in already-existing formats rather than an actual font format in its own
right."
which, to me, broadens the scope yet more, not that it should not be registered
but just what branch of the tree it should be in.

Tom Petch

> ISO SC29/WG11 has prepared the draft to register application/font-sfnt but it
wasn't submitted yet.
>
> Thank you,
> Vlad
>
>
> > -----Original Message-----
> > From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp]
> > Sent: Friday, November 18, 2011 2:03 AM
> > To: Levantovsky, Vladimir
> > Cc: Peter Saint-Andre; Chris Lilley; Ned Freed; David Singer; apps-
> > discuss@ietf.org; gadams@xfsi.com Adams
> > Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
> >
> > Hello Vlad,
> >
> > On 2011/11/17 5:01, Levantovsky, Vladimir wrote:
> > > Adding Chris Lilley from W3C
> >
> > > On Tuesday, November 15, 2011 9:17 PM Peter Saint-Andre wrote:
> >
> > >> Perhaps I am mistaken, but I read the discussion differently: I see
> > an
> > >> openness to registering font/* now.
> > >>
> > >
> > > Yes. I guess I should've been more specific and should have said that
> > the sentiments expressed few years ago were similar to what was
> > mentioned as part of this discussion (or as quoted from prior
> > discussions). I do see a much more open-minded position to registering
> > font/* now - the question is whether there is still a utility value
> > left in doing this (since we already have quite a few font-* subtypes
> > registered under the application/* tree.
> >
> > You mention that there are quite a few font types already registered
> > under application/. Earlier discussion only brought up
> > application/font-tdpfr (http://tools.ietf.org/html/rfc3073), a format
> > that as far as I was able to conclude from a quick web search, is no
> > longer much in fashion (you may know better).
> >
> > Can you tell us what the other font types under application/ are?
> >
> > Regards,    Martin.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


From eran@hueniverse.com  Sat Nov 19 07:03:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8ED21F8511 for ; Sat, 19 Nov 2011 07:03:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level: 
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.071,  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 1c6aYb-3-bTg for ; Sat, 19 Nov 2011 07:03:24 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id A1D3D21F8500 for ; Sat, 19 Nov 2011 07:03:23 -0800 (PST)
Received: (qmail 8448 invoked from network); 19 Nov 2011 15:03:22 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Nov 2011 15:03:22 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 19 Nov 2011 08:03:21 -0700
From: Eran Hammer-Lahav 
To: "Paul E. Jones" , "apps-discuss@ietf.org" 
Date: Sat, 19 Nov 2011 08:03:05 -0700
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AcySiOHWZHrUUWZ0SIe1B4nUS477zwUQENTg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>
In-Reply-To: <032101cc9288$e3a06910$aae13b30$@packetizer.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234526735EDEDP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: Joseph Smarr 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Nov 2011 15:03:26 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735EDEDP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is a good start. Some feedback and nits:


1.       The protocol flow is incorrect and needs to be adjusted based on t=
he final host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger p=
roviders to support the JRD format. This does not preclude using XRD (XML) =
but it will ensure that every compliant WebFinger implementation provides f=
ull JSON support which is much more likely to be adopted. This is something=
 we could not do in host-meta due to the late stage it was in, but this is =
the right time to make the switch (without taking away any existing functio=
nality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each exa=
mple needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta e=
ndpoint by defining a 'resource' query parameter. Using the example in RFC =
6415 section 1.1.1 (example not properly encoded to make it easier to read)=
:

> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1

   {
      "subject":"http://example.com/xy",

      "properties":{
        "http://spec.example.net/color":"red"
      },

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/hub",
        },
        {
          "rel":"hub",
          "href":"http://example.com/another/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/john",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }
      ]
    }

The rules for this extension parameter are pretty simple:


1.       JSON is implied. If the server understands '?resource' it MUST ret=
urn a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.) =
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making s=
ure the response is both JRD and has the requested subject (this will ensur=
e full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that =
clients can make a single call and get the full WebFinger result in JSON. T=
his would significantly improve adoption and usability, and adds very littl=
e work to providers.

EHL


From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

Folks,

We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

The tools for Webfinger are now defined, but the procedures need to be clea=
rer with respect to what most of us understand as "webfinger".  This is jus=
t a first stab at making that happen and we hope to progress this to publis=
h an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly=
.

Paul


--_000_90C41DD21FB7C64BB94121FBBC2E7234526735EDEDP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



--Gonzalo


2)      You wanted to mandate =
HTTPS. I=92m not opposed, but host-meta does =
not
mandate it.  =
Shouldn=92t we Webfinger requirements on what is =
there?

host-meta does not necessarily have security =
implications. Webfinger
almost certainly does, and as such should =
mandate =
HTTPS.

b.


=

--Apple-Mail-339-6095399--

From paul.bryan@forgerock.com  Mon Nov 21 13:51:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCAE11E80EF for ; Mon, 21 Nov 2011 13:51:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.67
X-Spam-Level: 
X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=-0.072,  BAYES_00=-2.599, 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 q5m0Ondt+L0x for ; Mon, 21 Nov 2011 13:51:30 -0800 (PST)
Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) by ietfa.amsl.com (Postfix) with SMTP id 5722D11E80ED for ; Mon, 21 Nov 2011 13:51:29 -0800 (PST)
Received: from mail-iy0-f182.google.com ([209.85.210.182]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKTsrH0XSlU0v9/CUR048ctHk4t428gzGW@postini.com; Mon, 21 Nov 2011 21:51:29 UTC
Received: by mail-iy0-f182.google.com with SMTP id l21so11446835iak.13 for ; Mon, 21 Nov 2011 13:51:12 -0800 (PST)
Received: by 10.231.44.196 with SMTP id b4mr3689802ibf.82.1321912272733; Mon, 21 Nov 2011 13:51:12 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id a2sm29012731igj.7.2011.11.21.13.51.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 13:51:12 -0800 (PST)
Message-ID: <1321912269.1990.32.camel@neutron>
From: "Paul C. Bryan" 
To: IETF Apps Discuss 
Date: Mon, 21 Nov 2011 13:51:09 -0800
In-Reply-To: <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>
Content-Type: multipart/alternative; boundary="=-zdFFbLtPn+S+mwrYKVQU"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 21:51:34 -0000

--=-zdFFbLtPn+S+mwrYKVQU
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Okay, so I'll write-up separate sections for JSON string values and URI
fragment identifiers. Any objections?

Paul

On Tue, 2011-11-22 at 07:55 +1100, Mark Nottingham wrote:

> +1 to Julian here -- there's no reason why non-ASCII chars need to be percent-encoded when they occur inside a JSON document, only when they're in a URI (or similar context).
> 
> Cheers,
> 
> 
> On 22/11/2011, at 7:12 AM, Julian Reschke wrote:
> 
> > On 2011-11-21 21:09, Paul C. Bryan wrote:
> >> The intent is to allow a JSON Pointer to be expressed as a JSON string
> >> value as well as a URI fragment identifier. The latter is the most
> >> significant driver for URI percent-encoding.
> >> ...
> > 
> > Well, you could use it as fragment identifier (or otherwise URI component) by UTF-8-percent-escaping.
> > 
> > The question is whether that use case requires them to be all ASCII every else, such as in a JSON patch document.
> > 
> > Best regards, Julian
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 



--=-zdFFbLtPn+S+mwrYKVQU
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


Okay, so I'll write-up separate sections for JSON string values and URI fragment identifiers. Any objections?



Paul



On Tue, 2011-11-22 at 07:55 +1100, Mark Nottingham wrote:



+1 to Julian here -- there's no reason why non-ASCII chars need to be percent-encoded when they occur inside a JSON document, only when they're in a URI (or similar context).

Cheers,


On 22/11/2011, at 7:12 AM, Julian Reschke wrote:

> On 2011-11-21 21:09, Paul C. Bryan wrote:
>> The intent is to allow a JSON Pointer to be expressed as a JSON string
>> value as well as a URI fragment identifier. The latter is the most
>> significant driver for URI percent-encoding.
>> ...
> 
> Well, you could use it as fragment identifier (or otherwise URI component) by UTF-8-percent-escaping.
> 
> The question is whether that use case requires them to be all ASCII every else, such as in a JSON patch document.
> 
> Best regards, Julian
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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












--=-zdFFbLtPn+S+mwrYKVQU--


From mnot@mnot.net  Mon Nov 21 15:43:45 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFBC1F0C4C for ; Mon, 21 Nov 2011 15:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.334
X-Spam-Level: 
X-Spam-Status: No, score=-105.334 tagged_above=-999 required=5 tests=[AWL=-2.735, 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 sQIv1szxej6h for ; Mon, 21 Nov 2011 15:43:41 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABAC1F0C34 for ; Mon, 21 Nov 2011 15:43:41 -0800 (PST)
Received: from mnot-mini.mnot.net (unknown [118.209.190.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9814050A64; Mon, 21 Nov 2011 18:43:34 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: <1321912269.1990.32.camel@neutron>
Date: Tue, 22 Nov 2011 10:43:30 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net> <1321912269.1990.32.camel@neutron>
To: Paul C. Bryan 
X-Mailer: Apple Mail (2.1251.1)
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 23:43:46 -0000

The usual approach to this sort of thing is to define the "canonical" =
way to do it; i.e., json pointers *are* unicode strings; then you can =
define encodings into various environments (like URIs).

In this case, it'd probably be good enough to say that json pointers are =
unicode strings, but that when they need to be in ASCII environments =
(like URIs) they get UTF-8'ed and then percent-escaped.

Cheers,


On 22/11/2011, at 8:51 AM, Paul C. Bryan wrote:

> Okay, so I'll write-up separate sections for JSON string values and =
URI fragment identifiers. Any objections?
>=20
> Paul
>=20
> On Tue, 2011-11-22 at 07:55 +1100, Mark Nottingham wrote:
>> +1 to Julian here -- there's no reason why non-ASCII chars need to be =
percent-encoded when they occur inside a JSON document, only when =
they're in a URI (or similar context).
>>=20
>> Cheers,
>>=20
>>=20
>> On 22/11/2011, at 7:12 AM, Julian Reschke wrote:
>>=20
>> > On 2011-11-21 21:09, Paul C. Bryan wrote:
>> >> The intent is to allow a JSON Pointer to be expressed as a JSON =
string
>> >> value as well as a URI fragment identifier. The latter is the most
>> >> significant driver for URI percent-encoding.
>> >> ...
>> >=20
>> > Well, you could use it as fragment identifier (or otherwise URI =
component) by UTF-8-percent-escaping.
>> >=20
>> > The question is whether that use case requires them to be all ASCII =
every else, such as in a JSON patch document.
>> >=20
>> > Best regards, Julian
>> > _______________________________________________
>> > apps-discuss mailing list
>> >=20
>> apps-discuss@ietf.org
>>=20
>> >=20
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
>>=20
>> --
>> Mark Nottingham  =20
>> http://www.mnot.net/
>>=20
>>=20
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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




From paul.bryan@forgerock.com  Mon Nov 21 16:56:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50FE21F84B7 for ; Mon, 21 Nov 2011 16:56:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.665
X-Spam-Level: 
X-Spam-Status: No, score=-6.665 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, 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 bPZrY0-EFmBM for ; Mon, 21 Nov 2011 16:56:18 -0800 (PST)
Received: from eu1sys200aog102.obsmtp.com (eu1sys200aog102.obsmtp.com [207.126.144.113]) by ietfa.amsl.com (Postfix) with SMTP id 8035F1F0C67 for ; Mon, 21 Nov 2011 16:56:17 -0800 (PST)
Received: from mail-yw0-f46.google.com ([209.85.213.46]) (using TLSv1) by eu1sys200aob102.postini.com ([207.126.147.11]) with SMTP ID DSNKTsrzI76063RJTvVofxrm2DBU6f5rN6Qc@postini.com; Tue, 22 Nov 2011 00:56:17 UTC
Received: by mail-yw0-f46.google.com with SMTP id 32so7174436ywt.33 for ; Mon, 21 Nov 2011 16:56:03 -0800 (PST)
Received: by 10.236.179.7 with SMTP id g7mr23118337yhm.74.1321923363588; Mon, 21 Nov 2011 16:56:03 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id c10sm16902279yhj.2.2011.11.21.16.56.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 16:56:03 -0800 (PST)
Message-ID: <1321923360.1990.34.camel@neutron>
From: "Paul C. Bryan" 
To: IETF Apps Discuss 
Date: Mon, 21 Nov 2011 16:56:00 -0800
In-Reply-To: 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net> <1321912269.1990.32.camel@neutron> 
Content-Type: multipart/alternative; boundary="=-w6SzAmO2CMbMNO51UqSh"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 00:56:22 -0000

--=-w6SzAmO2CMbMNO51UqSh
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

And of course, if a pointer references a member name with a slash, then
%25 MUST be used...

Paul

On Tue, 2011-11-22 at 10:43 +1100, Mark Nottingham wrote:

> The usual approach to this sort of thing is to define the "canonical" way to do it; i.e., json pointers *are* unicode strings; then you can define encodings into various environments (like URIs).
> 
> In this case, it'd probably be good enough to say that json pointers are unicode strings, but that when they need to be in ASCII environments (like URIs) they get UTF-8'ed and then percent-escaped.
> 
> Cheers,
> 
> 
> On 22/11/2011, at 8:51 AM, Paul C. Bryan wrote:
> 
> > Okay, so I'll write-up separate sections for JSON string values and URI fragment identifiers. Any objections?
> > 
> > Paul
> > 
> > On Tue, 2011-11-22 at 07:55 +1100, Mark Nottingham wrote:
> >> +1 to Julian here -- there's no reason why non-ASCII chars need to be percent-encoded when they occur inside a JSON document, only when they're in a URI (or similar context).
> >> 
> >> Cheers,
> >> 
> >> 
> >> On 22/11/2011, at 7:12 AM, Julian Reschke wrote:
> >> 
> >> > On 2011-11-21 21:09, Paul C. Bryan wrote:
> >> >> The intent is to allow a JSON Pointer to be expressed as a JSON string
> >> >> value as well as a URI fragment identifier. The latter is the most
> >> >> significant driver for URI percent-encoding.
> >> >> ...
> >> > 
> >> > Well, you could use it as fragment identifier (or otherwise URI component) by UTF-8-percent-escaping.
> >> > 
> >> > The question is whether that use case requires them to be all ASCII every else, such as in a JSON patch document.
> >> > 
> >> > Best regards, Julian
> >> > _______________________________________________
> >> > apps-discuss mailing list
> >> > 
> >> apps-discuss@ietf.org
> >> 
> >> > 
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >> 
> >> 
> >> --
> >> Mark Nottingham   
> >> http://www.mnot.net/
> >> 
> >> 
> >> 
> >> 
> >> 
> > 
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 



--=-w6SzAmO2CMbMNO51UqSh
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


And of course, if a pointer references a member name with a slash, then %25 MUST be used...



Paul



On Tue, 2011-11-22 at 10:43 +1100, Mark Nottingham wrote:



The usual approach to this sort of thing is to define the "canonical" way to do it; i.e., json pointers *are* unicode strings; then you can define encodings into various environments (like URIs).

In this case, it'd probably be good enough to say that json pointers are unicode strings, but that when they need to be in ASCII environments (like URIs) they get UTF-8'ed and then percent-escaped.

Cheers,


On 22/11/2011, at 8:51 AM, Paul C. Bryan wrote:

> Okay, so I'll write-up separate sections for JSON string values and URI fragment identifiers. Any objections?
> 
> Paul
> 
> On Tue, 2011-11-22 at 07:55 +1100, Mark Nottingham wrote:
>> +1 to Julian here -- there's no reason why non-ASCII chars need to be percent-encoded when they occur inside a JSON document, only when they're in a URI (or similar context).
>> 
>> Cheers,
>> 
>> 
>> On 22/11/2011, at 7:12 AM, Julian Reschke wrote:
>> 
>> > On 2011-11-21 21:09, Paul C. Bryan wrote:
>> >> The intent is to allow a JSON Pointer to be expressed as a JSON string
>> >> value as well as a URI fragment identifier. The latter is the most
>> >> significant driver for URI percent-encoding.
>> >> ...
>> > 
>> > Well, you could use it as fragment identifier (or otherwise URI component) by UTF-8-percent-escaping.
>> > 
>> > The question is whether that use case requires them to be all ASCII every else, such as in a JSON patch document.
>> > 
>> > Best regards, Julian
>> > _______________________________________________
>> > apps-discuss mailing list
>> > 
>> apps-discuss@ietf.org
>> 
>> > 
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 
>> 
>> --
>> Mark Nottingham   
>> http://www.mnot.net/
>> 
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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












--=-w6SzAmO2CMbMNO51UqSh--


From paul.bryan@forgerock.com  Mon Nov 21 16:57:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0241421F8797 for ; Mon, 21 Nov 2011 16:57:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.661
X-Spam-Level: 
X-Spam-Status: No, score=-6.661 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, 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 uvDBha8cb8SP for ; Mon, 21 Nov 2011 16:57:33 -0800 (PST)
Received: from eu1sys200aog113.obsmtp.com (eu1sys200aog113.obsmtp.com [207.126.144.135]) by ietfa.amsl.com (Postfix) with SMTP id C1C6421F84B7 for ; Mon, 21 Nov 2011 16:57:27 -0800 (PST)
Received: from mail-yw0-f46.google.com ([209.85.213.46]) (using TLSv1) by eu1sys200aob113.postini.com ([207.126.147.11]) with SMTP ID DSNKTsrzdiTMPvFO3llBixmt2LD+BrLrAMxY@postini.com; Tue, 22 Nov 2011 00:57:27 UTC
Received: by mail-yw0-f46.google.com with SMTP id 32so5340656ywt.19 for ; Mon, 21 Nov 2011 16:57:26 -0800 (PST)
Received: by 10.236.197.103 with SMTP id s67mr24294458yhn.5.1321923446687; Mon, 21 Nov 2011 16:57:26 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id a24sm12139949ana.15.2011.11.21.16.57.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 16:57:26 -0800 (PST)
Message-ID: <1321923443.1990.35.camel@neutron>
From: "Paul C. Bryan" 
To: IETF Apps Discuss 
Date: Mon, 21 Nov 2011 16:57:23 -0800
In-Reply-To: <1321923360.1990.34.camel@neutron>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net> <1321912269.1990.32.camel@neutron>  <1321923360.1990.34.camel@neutron>
Content-Type: multipart/alternative; boundary="=-fJ3QoqTTUBVfvbMxhxHM"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 00:57:34 -0000

--=-fJ3QoqTTUBVfvbMxhxHM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Mon, 2011-11-21 at 16:56 -0800, Paul C. Bryan wrote:

> And of course, if a pointer references a member name with a slash,
> then %25 MUST be used...


s/%25/%2F/

--=-fJ3QoqTTUBVfvbMxhxHM
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


On Mon, 2011-11-21 at 16:56 -0800, Paul C. Bryan wrote:



    And of course, if a pointer references a member name with a slash, then %25 MUST be used...





s/%25/%2F/



--=-fJ3QoqTTUBVfvbMxhxHM--


From eran@hueniverse.com  Mon Nov 21 18:52:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9EF21F8B00 for ; Mon, 21 Nov 2011 18:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.545
X-Spam-Level: 
X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.053,  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 70fWrKFr0XKp for ; Mon, 21 Nov 2011 18:52:20 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 08BB421F8AFC for ; Mon, 21 Nov 2011 18:52:19 -0800 (PST)
Received: (qmail 9535 invoked from network); 22 Nov 2011 02:52:18 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Nov 2011 02:52:18 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 21 Nov 2011 19:52:18 -0700
From: Eran Hammer-Lahav 
To: "Paul E. Jones" , "apps-discuss@ietf.org" 
Date: Mon, 21 Nov 2011 19:52:13 -0700
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnyslL87CjCAALv8UA==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com>
In-Reply-To: <06b001cca865$1d9ccb80$58d66280$@packetizer.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234526735F00BP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: 'Joseph Smarr' 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 02:52:24 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F00BP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

1.       Require the server to offer JRD, leave it to the client to pick on=
e flavor.

2.       Host-meta dumps the decision on the applications. You need to deci=
de if WebFinger is an application or just syntactic sugar on top of host-me=
ta.

3.       Expand every template in host-meta + level one LRDD links (excludi=
ng templates in LRDD).

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

Eran,

Thanks for your feedback.  The editorial, structural, and behavioral items =
we'll addressed (including adhering to host-meta section 4.2).

Let me ask about specific comments:


1)      You want to mandate use of JSON, which we also indicated in the dra=
ft.  However, I would personally prefer to give both XML and JSON equal wei=
ght and require both.

2)      You wanted to mandate HTTPS. I'm not opposed, but host-meta does no=
t mandate it.  Shouldn't we Webfinger requirements on what is there?

3)      Regarding "resource" extension: if I query host-meta, there may be =
any number of templates.  Would we want the server to automatically expand =
every template it finds?  Or would we only expand the 'lrdd' template?  (An=
d how many levels of recursion might be possible?)

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

This is a good start. Some feedback and nits:


1.       The protocol flow is incorrect and needs to be adjusted based on t=
he final host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger p=
roviders to support the JRD format. This does not preclude using XRD (XML) =
but it will ensure that every compliant WebFinger implementation provides f=
ull JSON support which is much more likely to be adopted. This is something=
 we could not do in host-meta due to the late stage it was in, but this is =
the right time to make the switch (without taking away any existing functio=
nality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each exa=
mple needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta e=
ndpoint by defining a 'resource' query parameter. Using the example in RFC =
6415 section 1.1.1 (example not properly encoded to make it easier to read)=
:

> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1

   {
      "subject":"http://example.com/xy",

      "properties":{
        "http://spec.example.net/color":"red"
      },

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/hub",
        },
        {
          "rel":"hub",
          "href":"http://example.com/another/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/john",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }
      ]
    }

The rules for this extension parameter are pretty simple:


1.       JSON is implied. If the server understands '?resource' it MUST ret=
urn a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.) =
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making s=
ure the response is both JRD and has the requested subject (this will ensur=
e full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that =
clients can make a single call and get the full WebFinger result in JSON. T=
his would significantly improve adoption and usability, and adds very littl=
e work to providers.

EHL


From: apps-discuss-bounces@ietf.org [=
mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

Folks,

We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

The tools for Webfinger are now defined, but the procedures need to be clea=
rer with respect to what most of us understand as "webfinger".  This is jus=
t a first stab at making that happen and we hope to progress this to publis=
h an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly=
.

Paul


--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F00BP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This is a good start. Some feedback and nits:
 <=
/span>
1.&nbs=
p;      The protocol flow is incorrect =
and needs to be adjusted based on the final host-meta specification (RFC 64=
15). Namely, WebFinger must follow section 4.2 exactly as specified.
2.       WebFinger should focus exclu=
sively on JSON and mandate WebFinger providers to support the JRD format. T=
his does not preclude using XRD (XML) but it will ensure that every complia=
nt WebFinger implementation provides full JSON support which is much more l=
ikely to be adopted. This is something we could not do in host-meta due to =
the late stage it was in, but this is the right time to make the switch (wi=
thout taking away any existing functionality).
<=
![if !supportLists]>3.   &nb=
sp;   Are there reasons not to mandate HTTPS?=

4.&nb=
sp;      Section 3 should be a sub-secti=
on of the introduction and each example needs actual JRD code.
 
In addition=
, I would very much like to see WebFinger extend the host-meta endpoint by =
defining a ‘resource’ query parameter. Using the example in RFC=
 6415 section 1.1.1 (example not properly encoded to make it easier to read=
):
=
 
> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1=
.1
=
 
   {
      "subject":"ht=
tp://example.com/xy",
 
      "properties=
":{
        "http://spec.example.=
net/color":"red"
<=
span style=3D'color:#1F497D'>      },
 
  =
;    "links":[
      &n=
bsp; {
          "rel":=
"hub",
          "=
href":"http://example.com/hub",
     &=
nbsp;  },
        {<=
/p>
   &nb=
sp;      "rel":"hub",
  =
;        "href":"http://e=
xample.com/another/hub",
        },
 =
;       {
      &n=
bsp;   "rel":"author",
<=
p class=3DMsoNormal>    &=
nbsp;     "href":"http://example.com/joh=
n",
        },
    &n=
bsp;   {
          &quo=
t;rel":"author",
<=
span style=3D'color:#1F497D'>       &nbs=
p;  "template":"http://example.com/author?q=3Dhttp%3A%2=
F%2Fexample.com%2Fxy"
        }
 &nb=
sp;    ]
    }
 
The rules for this extension par=
ameter are pretty simple:
 
1.       <=
/span>JSON is implied. If the server understands ‘?resource’ =
it MUST return a JRD document.
2.       =
The subject must be set to the value of the ‘resource’=
 parameter.
3.       If the ser=
ver does not support that resource (wrong domain, etc.) it must return an e=
mpty JRD with the right subject.
4.      =
; The client MUST verify the server supports ‘?resource̵=
7; by making sure the response is both JRD and has the requested subject (t=
his will ensure full compatibility with any other host-meta endpoint).=

&n=
bsp;
I w=
ould like to see such endpoint extension required for WebFinger so that cli=
ents can make a single call and get the full WebFinger result in JSON. This=
 would significantly improve adoption and usability, and adds very little w=
ork to providers.
 
EHL
 
 
<=
p class=3DMsoNormal>From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-=
bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday,=
 October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc:=
 Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinge=
r
 
Folks,
 =
;
We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-a=
ppsawg-webfinger-00.txt
 <=
/o:p>
The tools for Webfinger are now defined, but =
the procedures need to be clearer with respect to what most of us understan=
d as “webfinger”.  This is just a first stab at making tha=
t happen and we hope to progress this to publish an RFC in the application =
area.
 
We welcome any comments you have on the topic, either privately or =
publicly.
 
Paul
 
<=
/div>
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735EDEDP3PW5EX1MB01E_--

From eran@hueniverse.com  Sat Nov 19 07:05:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02E021F8511 for ; Sat, 19 Nov 2011 07:05:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXX7DIiMU0yC for ; Sat, 19 Nov 2011 07:05:01 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id AED3A21F8A35 for ; Sat, 19 Nov 2011 07:05:00 -0800 (PST)
Received: (qmail 14604 invoked from network); 19 Nov 2011 15:04:56 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Nov 2011 15:04:56 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 19 Nov 2011 08:04:55 -0700
From: Eran Hammer-Lahav 
To: "eran@sled.com" , "Paul E. Jones" ,  "apps-discuss@ietf.org" 
Date: Sat, 19 Nov 2011 08:04:41 -0700
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AcySiOHWZHrUUWZ0SIe1B4nUS477zwUQENTgAADUz8A=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234526735EDEE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234526735EDEEP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: Joseph Smarr 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Nov 2011 15:05:03 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735EDEEP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This can be further improved by specifying another 'rel' query filter to re=
turn only matching links, but that's less important to me.

EHL

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Eran Hammer-Lahav
Sent: Saturday, November 19, 2011 7:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr
Subject: Re: [apps-discuss] Webfinger

This is a good start. Some feedback and nits:


1.       The protocol flow is incorrect and needs to be adjusted based on t=
he final host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger p=
roviders to support the JRD format. This does not preclude using XRD (XML) =
but it will ensure that every compliant WebFinger implementation provides f=
ull JSON support which is much more likely to be adopted. This is something=
 we could not do in host-meta due to the late stage it was in, but this is =
the right time to make the switch (without taking away any existing functio=
nality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each exa=
mple needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta e=
ndpoint by defining a 'resource' query parameter. Using the example in RFC =
6415 section 1.1.1 (example not properly encoded to make it easier to read)=
:

> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1

   {
      "subject":"http://example.com/xy",

      "properties":{
        "http://spec.example.net/color":"red"
      },

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/hub",
        },
        {
          "rel":"hub",
          "href":"http://example.com/another/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/john",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }
      ]
    }

The rules for this extension parameter are pretty simple:


1.       JSON is implied. If the server understands '?resource' it MUST ret=
urn a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.) =
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making s=
ure the response is both JRD and has the requested subject (this will ensur=
e full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that =
clients can make a single call and get the full WebFinger result in JSON. T=
his would significantly improve adoption and usability, and adds very littl=
e work to providers.

EHL


From: apps-discuss-bounces@ietf.org [=
mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

Folks,

We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

The tools for Webfinger are now defined, but the procedures need to be clea=
rer with respect to what most of us understand as "webfinger".  This is jus=
t a first stab at making that happen and we hope to progress this to publis=
h an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly=
.

Paul


--_000_90C41DD21FB7C64BB94121FBBC2E7234526735EDEEP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This can be further improved by specifying another ‘rel=
’ query filter to return only matching links, but that’s less i=
mportant to me.
 
EHL
 
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounc=
es@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Saturday=
, November 19, 2011 7:03 AM
To: Paul E. Jones; apps-discuss@ietf.=
org
Cc: Joseph Smarr
Subject: Re: [apps-discuss] Webfin=
ger
 =

This is a good start=
. Some feedback and nits:
 
1.       <=
/span>The protocol flow is incorrect and needs to be adjusted based on th=
e final host-meta specification (RFC 6415). Namely, WebFinger must follow s=
ection 4.2 exactly as specified.
2.      =
; WebFinger should focus exclusively on JSON and mandate WebFinger=
 providers to support the JRD format. This does not preclude using XRD (XML=
) but it will ensure that every compliant WebFinger implementation provides=
 full JSON support which is much more likely to be adopted. This is somethi=
ng we could not do in host-meta due to the late stage it was in, but this i=
s the right time to make the switch (without taking away any existing funct=
ionality).
3.       Are there r=
easons not to mandate HTTPS?
4.       Section 3 should be a sub-section of the introduction and each examp=
le needs actual JRD code.
 
In addition, I would very much like to see WebFi=
nger extend the host-meta endpoint by defining a ‘resource’ que=
ry parameter. Using the example in RFC 6415 section 1.1.1 (example not prop=
erly encoded to make it easier to read):
 
> GET /.well-known/host-meta?=
resource=3Dhttp://example.com/xy HTTP/1.1
 
   {=

   &n=
bsp;  "subject":"http=
://example.com/xy",
 
=
      "properti=
es":{
        "http://spec.example.net/color":"red&q=
uot;
      },
 
      "l=
inks":[
        {
    =
;      "rel":"hub",=

  &=
nbsp;       "href":"http://example.com/hub",
   &=
nbsp;    },
        {
 &nb=
sp;        "rel":"hub&quo=
t;,
          "href":&q=
uot;http://example.com/another/h=
ub",
        },<=
/p>
   &nb=
sp;    {
         =
 "rel":"author",
       =
;   "href":"ht=
tp://example.com/john",
=
        },=

&n=
bsp;       {
      =
;    "rel":"author",
   &nbs=
p;      "template":"http://example.com=
/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"
    &n=
bsp;   }
      ]
    }
 =

The rul=
es for this extension parameter are pretty simple:
 
1.  &=
nbsp;    JSON is implied. If the server understands=
 ‘?resource’ it MUST return a JRD document.
2.  =
     The subject must be set to the value of t=
he ‘resource’ parameter.
3.<=
span style=3D'font:7.0pt "Times New Roman"'>     &=
nbsp; If the server does not support that resource (wrong domain, =
etc.) it must return an empty JRD with the right subject.=

4. &nbs=
p;     <=
/span>The client MUST verify the server suppo=
rts ‘?resource’ by making sure the response is both JRD and has=
 the requested subject (this will ensure full compatibility with any other =
host-meta endpoint).
 
I would like to see such endpoint extension required=
 for WebFinger so that clients can make a single call and get the full WebF=
inger result in JSON. This would significantly improve adoption and usabili=
ty, and adds very little work to providers.
 
EHL
 
 
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf=
.org] On Behalf Of Paul E. Jones
Sent: Monday, October=
 24, 2011 1:10 PM
To: ap=
ps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger
 
Folks,
 
We jus=
t submitted this:
http://www.i=
etf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt=

 
The tool=
s for Webfinger are now defined, but the procedures need to be clearer with=
 respect to what most of us understand as “webfinger”.  Th=
is is just a first stab at making that happen and we hope to progress this =
to publish an RFC in the application area.
 
We welcome any comments you ha=
ve on the topic, either privately or publicly.
 
Paul
 
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735EDEEP3PW5EX1MB01E_--

From romeda@gmail.com  Sat Nov 19 07:40:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180A021F891D for ; Sat, 19 Nov 2011 07:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.523
X-Spam-Level: 
X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, 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 47+nZkM51h9A for ; Sat, 19 Nov 2011 07:40:29 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9AF21F8906 for ; Sat, 19 Nov 2011 07:40:29 -0800 (PST)
Received: by ywt34 with SMTP id 34so4160537ywt.31 for ; Sat, 19 Nov 2011 07:40:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=FTxwYzHgOP68U9G+1WuhZufl8KTQd8W4QbjV0sgelkI=; b=Dcz+vyu6IafZ/864pV7/jLNz7H91i4UoTE9ju7T97olV8aCjconnw0Nb/tscDcA1u+ W/QJ7aZ50zOBsmvt139tjeUc7sEbFg9qNt55R/hlJYz+PLEaHGaVCIaaDuvIpqJq9E7R GBlBdSDOE+LBzwKA9nbnTve/dTCcpt7unDKNE=
Received: by 10.182.45.3 with SMTP id i3mr1630905obm.62.1321717229139; Sat, 19 Nov 2011 07:40:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.44.35 with HTTP; Sat, 19 Nov 2011 07:40:07 -0800 (PST)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Blaine Cook 
Date: Sat, 19 Nov 2011 15:40:07 +0000
Message-ID: 
To: Eran Hammer-Lahav 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Joseph Smarr , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Nov 2011 15:40:30 -0000

On 19 November 2011 15:03, Eran Hammer-Lahav  wrote:

One minor objection:

> 4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The client MUST verify the server =
supports =E2=80=98?resource=E2=80=99 by making
> sure the response is both JRD and has the requested subject (this will
> ensure full compatibility with any other host-meta endpoint).
>
> I would like to see such endpoint extension required for WebFinger so tha=
t
> clients can make a single call and get the full WebFinger result in JSON.
> This would significantly improve adoption and usability, and adds very
> little work to providers.

The '?resource' form of host-meta responses shouldn't be *required*,
since many providers will be unable to provide dynamic responses from
their host-meta location.

b.

From evnikita2@gmail.com  Sat Nov 19 21:05:05 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF291F0C3B for ; Sat, 19 Nov 2011 21:05:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.315
X-Spam-Level: 
X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0uwu8FY-nLvF for ; Sat, 19 Nov 2011 21:05:04 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A73AB21F84AA for ; Sat, 19 Nov 2011 21:05:03 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so5916212bkb.31 for ; Sat, 19 Nov 2011 21:05:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=27+1YnJ3AnK8lkup0eB5Ty49Bmw0MhpZ3DT6I5dCjUs=; b=euEbF9SPShQHgRU6Yn1izMOxGQ6WakNzvBUO2GsxdGY1HEuvYYeJfg1AgSuuvcDa+p HvAhz78VyF0x/YxthQcW/+9vYDuXhpBoLQ2HrrGdTbz9Uz3YetDxcxjS83z4pqmTVRnS n28KHVnz1Gn1Brx2QIyGqGJsqGtvGCwyRwpjQ=
Received: by 10.204.12.68 with SMTP id w4mr9242140bkw.31.1321765502525; Sat, 19 Nov 2011 21:05:02 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id i3sm10998792faf.0.2011.11.19.21.04.59 (version=SSLv3 cipher=OTHER); Sat, 19 Nov 2011 21:05:00 -0800 (PST)
Message-ID: <4EC88AAF.2000007@gmail.com>
Date: Sun, 20 Nov 2011 07:05:51 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: multipart/alternative; boundary="------------080202090303050509080304"
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Nov 2011 05:05:05 -0000

This is a multi-part message in MIME format.
--------------080202090303050509080304
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

19.11.2011 17:03, Eran Hammer-Lahav wrote:
>
> 3.Are there reasons not to mandate HTTPS?
>

I don't think the document should put MUST on using HTTPS.  RFC 6415 
specified that host-meta document can be located using both HTTP and 
HTTPS, and I don't see a reason to constrain this in Webfinger.  Maybe 
the spec. should repeat that both HTTP and secured variants may be used.

Mykyta Yevstifeyev

--------------080202090303050509080304
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    19.11.2011 17:03, Eran Hammer-Lahav wrote:
    

      
      
      
      

        
3.       Are
            there reasons not to mandate HTTPS?

      

    

    

    I don't think the document should put MUST on using HTTPS.  RFC 6415
    specified that host-meta document can be located using both HTTP and
    HTTPS, and I don't see a reason to constrain this in Webfinger. 
    Maybe the spec. should repeat that both HTTP and secured variants
    may be used.

    

    Mykyta Yevstifeyev

  


--------------080202090303050509080304--

From laurentwalter.goix@telecomitalia.it  Mon Nov 21 02:14:27 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2F21F8B76 for ; Mon, 21 Nov 2011 02:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.269
X-Spam-Level: 
X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[AWL=0.687,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 rpI-mYrMX7bs for ; Mon, 21 Nov 2011 02:14:26 -0800 (PST)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id EA1A921F8B73 for ; Mon, 21 Nov 2011 02:14:25 -0800 (PST)
Content-Type: multipart/mixed; boundary="_023dfe26-0d0a-4271-9c98-d203f31a29d9_"
Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Nov 2011 11:14:24 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Mon, 21 Nov 2011 11:14:23 +0100
From: Goix Laurent Walter 
To: Blaine Cook , =?utf-8?B?TXlreXRhIFlldnN0aWZleWV2ICjQnC4g0ITQstGB0YLRltGE0LXRlNCyKQ==?= 
Date: Mon, 21 Nov 2011 11:14:19 +0100
Thread-Topic: [apps-discuss] Webfinger & acct: draft
Thread-Index: AcymtkGkZ8pA6hY0STyw9QQ/TdX8DgBfvA+Q
Message-ID: 
References:  <047c01cca646$f32f8100$d98e8300$@packetizer.com> <740878FD-AA49-4F62-8612-7AE76CA36710@cisco.com>  <4EC754A8.3090408@gmail.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
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: [apps-discuss] R:  Webfinger & acct: draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 10:14:27 -0000

--_023dfe26-0d0a-4271-9c98-d203f31a29d9_
Content-Type: multipart/alternative;
	boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE4057005F1EGRFMBX704BA02_"

--_000_A09A9E0A4B9C654E8672D1DC003633AE4057005F1EGRFMBX704BA02_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGE6IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJv
dW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBCbGFpbmUgQ29vaw0KDQoyMDExLzExLzE5ICJN
eWt5dGEgWWV2c3RpZmV5ZXYgKNCcLiDQhNCy0YHRgtGW0YTQtdGU0LIpIiA8ZXZuaWtpdGEyQGdt
YWlsLmNvbTxtYWlsdG86ZXZuaWtpdGEyQGdtYWlsLmNvbT4+DQoxOS4xMS4yMDExIDg6NTgsIEJs
YWluZSBDb29rIHdyb3RlOg0KKzE7IGRlZmluaW5nIHRoZSBhY3R1YWwgbGluayByZWxhdGlvbnMg
c2hvdWxkIGJlIGRvbmUgb3V0c2lkZSB0aGUgd2ViZmluZ2VyIHNwZWMsIG1vc3QgbGlrZWx5IGFz
IHBhcnQgb2YgUkZDIDU5ODggYXMgUGF1bCBtZW50aW9uZWQuDQoNClRoZSByZWxhdGlvbnMgYXJl
IHBlcmhhcHMgdGhlIHRyaWNraWVzdCBiaXQgb2Ygd2ViZmluZ2VyIHRvIHN0YW5kYXJkaXNlLCBi
dXQgdGhhbmtmdWxseSA1OTg4IG9mZmVycyBndWlkYW5jZTsgbmV3IHJlbGF0aW9ucyBzaG91bGQg
YmUgZGVmaW5lZCBhcyBzcGVjaWZpY2FsbHkgYXMgcG9zc2libGUsIHdpdGggb2J2aW91cyByZWxh
dGlvbiBvdmVybGFwIGJlaW5nIGFnZ3JlZ2F0ZWQgaW50byBtb3JlIGdlbmVyYWwgaWRlbnRpZmll
cnMsIGFuZCBldmVudHVhbGx5IGJlaW5nIHN1Ym1pdHRlZCB0byB0aGUgcmVnaXN0cnkgb25jZSBz
dWZmaWNpZW50IGRlcGxveW1lbnQgbWFuZGF0ZXMgaXQuDQoNCkhvdyBtYW55IG9mIHRoZW0gd2ls
bCB3ZSBoYXZlIHRvIGRlZmluZT8gIENhbiB3ZSBhdCBhbGwgcHJlZGljdCBob3cgd2lsbCBXZWJm
aW5nZXIgYmUgdXNlZD8NCg0KV2UgZG9uJ3Qga25vdywgYW5kIG5vLiA6LSkNCg0KV2UgY2FuIG1h
a2UgZWR1Y2F0ZWQgZ3Vlc3NlcywgYnV0IGl0IHdvdWxkIGJlIGZvbGx5IHRvIHN0YXJ0IGRlZmlu
aW5nIHNoYXJlZCwgZ2VuZXJpYyB0ZXJtaW5vbG9neSBiZWZvcmUgaW1wbGVtZW50YXRpb24uIFRo
ZSBYTVBQIHNwZWNzIGFyZSBhIGdyZWF0IGV4YW1wbGUgb2YgdG9vIG11Y2ggZGVmaW5pdGlvbiBz
dGlmbGluZyBhY3R1YWwgaW1wbGVtZW50YXRpb25zIGZyb20gZ3Jvd2luZyBhbmQgZXZvbHZpbmcu
DQoNClt3YWx0ZXJdIGZyb20gd2hhdCBp4oCZdmUgc2VlbiBtb3N0IHdlYmZpbmdlciBpbXBsZW1l
bnRhdGlvbnMgdXNlIHRoZSDigJxwcm9maWxlLXBhZ2XigJ0gYW5kIOKAnGF2YXRhcuKAnSBsaW5r
IHJlbHMgdG8gaGVscCBiZXR0ZXIgaWRlbnRpZnkgd2hlbiBzdWJzY3JpYmluZyB0byB0aGF0IHVz
ZXIsIGkuZS4gYWZ0ZXIgaW5zZXJ0aW5nIHRoZSBhY2N0OiBVUkkgb2YgdGhhdCB1c2VyLCB0eXBp
Y2FsbHkgYSDigJxjb25maXJtYXRpb27igJ0gcGFnZSBpcyBkaXNwbGF5ZWQgdG8gdGhlIHVzZXIg
cHJpb3IgdG8gYWN0dWFsbHkgc3Vic2NyaWJlIHRvIHRoYXQgdXNlciwgdGhhdCBzaG93cyBpdHMg
YXZhdGFyIGFuZCBhIGxpbmsgdG8gaXRzIHByb2ZpbGUtcGFnZS4gQnV0IG9mIGNvdXJzZSB0aGUg
4oCcZGVzY3JpYmVkYnnigJ0gcmVsIG1heSBhbHNvIGJlIHVzZWQgaW4gdGhhdCBjb250ZXh0OiBk
ZXBlbmRpbmcgb24gaXRzIHR5cGUgaXQgbWF5IHN1Z2dlc3Qgd2hldGhlciB0aGlzIGlzIGEgZGVw
aWN0aW9uIG9mIHRoYXQgdXNlciAobW9yZSB0aGFuIHRoZSDigJxpY29u4oCdIHJlbCkgcmF0aGVy
IHRoYW4gYSB3ZWIgcGFnZSBwb2ludGluZyB0byBoaXMgcHJvZmlsZS4gQW55d2F5IGZyb20gdGhl
IHdlYmZpbmdlciBzcGVjIHBlcnNwZWN0aXZlIGl0IG1heSBiZSBnb29kIHRvIHN1Z2dlc3Qgc29t
ZSBzcGVjaWZpYyB0eXBlIG9mIGluZm9ybWF0aW9uIGFuZCB1cGRhdGUgdGhlIGV4YW1wbGVzIGNv
bnNpc3RlbnRseS4gVGhlbiB3ZSBtYXkgZGlzY3VzcyBmdXJ0aGVyIHBvc3NpYmxlIHZhbHVlcyBm
b3IgdGhpcywgYXQgbGVhc3QgdGhlaXIgc2VtYW50aWNzIGluIHRoZSB3ZWJmaW5nZXIgY29udGV4
dC4NCg0Kd2FsdGVyDQoNCmIuDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNv
bm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBk
aWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxh
IGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmll
dGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9y
ZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6
aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdy
YXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwg
YW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBh
ZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNl
IGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl
bmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNo
bWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0K
W2NpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMUBUSS5EaXNjbGFpbWVyXVJpc3Bl
dHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNz
YXJpby4NCg0K

--_000_A09A9E0A4B9C654E8672D1DC003633AE4057005F1EGRFMBX704BA02_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206
b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw
QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4
MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj
Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw
dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl
YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u
ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2
YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z
OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9
Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB
VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z
Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n
cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y
MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz
ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h
cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht
bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg
eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz
LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9
Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0
cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0
dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i
aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3
Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv
IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp
Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp
Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0
cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v
c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s
bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4
bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw
Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv
aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl
bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6
cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl
TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No
YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3
LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu
dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i
R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+
DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIg
NCAyIDQgMiAyIDM7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxp
Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t
YW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6
dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5T
dGlsZU1lc3NhZ2dpb0RpUG9zdGFFbGV0dHJvbmljYTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6
IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9
DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw
dCAyLjBjbSAyLjBjbSAyLjBjbTt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQot
LT4NCjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu
ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw
bGUiPg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkRhOjwvc3Bhbj48c3BhbiBsYW5nPSJJVCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGFw
cHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNA
aWV0Zi5vcmddIFBlcg0KIGNvbnRvIGRpIEJsYWluZSBDb29rPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJJVCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxMS8xMS8xOSAmcXVv
dDtNeWt5dGEgWWV2c3RpZmV5ZXYgKNCcLiDQhNCy0YHRgtGW0YTQtdGU0LIpJnF1b3Q7ICZsdDs8
YSBocmVmPSJtYWlsdG86ZXZuaWtpdGEyQGdtYWlsLmNvbSI+ZXZuaWtpdGEyQGdtYWlsLmNvbTwv
YT4mZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2
LjBwdDsNCm1hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xOS4xMS4yMDExIDg6NTgsIEJsYWluZSBDb29rIHdyb3Rl
OiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTsgZGVmaW5pbmcg
dGhlIGFjdHVhbCBsaW5rIHJlbGF0aW9ucyBzaG91bGQgYmUgZG9uZSBvdXRzaWRlIHRoZSB3ZWJm
aW5nZXIgc3BlYywgbW9zdCBsaWtlbHkgYXMgcGFydCBvZiBSRkMgNTk4OCBhcyBQYXVsIG1lbnRp
b25lZC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl
IHJlbGF0aW9ucyBhcmUgcGVyaGFwcyB0aGUgdHJpY2tpZXN0IGJpdCBvZiB3ZWJmaW5nZXIgdG8g
c3RhbmRhcmRpc2UsIGJ1dCB0aGFua2Z1bGx5IDU5ODggb2ZmZXJzIGd1aWRhbmNlOyBuZXcgcmVs
YXRpb25zIHNob3VsZCBiZSBkZWZpbmVkIGFzIHNwZWNpZmljYWxseSBhcyBwb3NzaWJsZSwgd2l0
aCBvYnZpb3VzIHJlbGF0aW9uIG92ZXJsYXAgYmVpbmcgYWdncmVnYXRlZCBpbnRvIG1vcmUgZ2Vu
ZXJhbA0KIGlkZW50aWZpZXJzLCBhbmQgZXZlbnR1YWxseSBiZWluZyBzdWJtaXR0ZWQgdG8gdGhl
IHJlZ2lzdHJ5IG9uY2Ugc3VmZmljaWVudCBkZXBsb3ltZW50IG1hbmRhdGVzIGl0LjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IG1hbnkgb2YgdGhlbSB3aWxsIHdl
IGhhdmUgdG8gZGVmaW5lPyZuYnNwOyBDYW4gd2UgYXQgYWxsIHByZWRpY3QgaG93IHdpbGwgV2Vi
ZmluZ2VyIGJlIHVzZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGRvbid0IGtub3csIGFuZCBuby4gOi0pPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGNh
biBtYWtlIGVkdWNhdGVkIGd1ZXNzZXMsIGJ1dCBpdCB3b3VsZCBiZSBmb2xseSB0byBzdGFydCBk
ZWZpbmluZyBzaGFyZWQsIGdlbmVyaWMgdGVybWlub2xvZ3kgYmVmb3JlIGltcGxlbWVudGF0aW9u
LiBUaGUgWE1QUCBzcGVjcyBhcmUgYSBncmVhdCBleGFtcGxlIG9mIHRvbyBtdWNoIGRlZmluaXRp
b24gc3RpZmxpbmcgYWN0dWFsIGltcGxlbWVudGF0aW9ucyBmcm9tIGdyb3dpbmcgYW5kIGV2b2x2
aW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlt3YWx0ZXJdIGZyb20gd2hhdCBp4oCZdmUgc2VlbiBt
b3N0IHdlYmZpbmdlciBpbXBsZW1lbnRhdGlvbnMgdXNlIHRoZSDigJxwcm9maWxlLXBhZ2XigJ0g
YW5kIOKAnGF2YXRhcuKAnSBsaW5rIHJlbHMgdG8gaGVscCBiZXR0ZXIgaWRlbnRpZnkgd2hlbiBz
dWJzY3JpYmluZw0KIHRvIHRoYXQgdXNlciwgaS5lLiBhZnRlciBpbnNlcnRpbmcgdGhlIGFjY3Q6
IFVSSSBvZiB0aGF0IHVzZXIsIHR5cGljYWxseSBhIOKAnGNvbmZpcm1hdGlvbuKAnSBwYWdlIGlz
IGRpc3BsYXllZCB0byB0aGUgdXNlciBwcmlvciB0byBhY3R1YWxseSBzdWJzY3JpYmUgdG8gdGhh
dCB1c2VyLCB0aGF0IHNob3dzIGl0cyBhdmF0YXIgYW5kIGEgbGluayB0byBpdHMgcHJvZmlsZS1w
YWdlLiBCdXQgb2YgY291cnNlIHRoZSDigJxkZXNjcmliZWRieeKAnSByZWwgbWF5DQogYWxzbyBi
ZSB1c2VkIGluIHRoYXQgY29udGV4dDogZGVwZW5kaW5nIG9uIGl0cyB0eXBlIGl0IG1heSBzdWdn
ZXN0IHdoZXRoZXIgdGhpcyBpcyBhIGRlcGljdGlvbiBvZiB0aGF0IHVzZXIgKG1vcmUgdGhhbiB0
aGUg4oCcaWNvbuKAnSByZWwpIHJhdGhlciB0aGFuIGEgd2ViIHBhZ2UgcG9pbnRpbmcgdG8gaGlz
IHByb2ZpbGUuIEFueXdheSBmcm9tIHRoZSB3ZWJmaW5nZXIgc3BlYyBwZXJzcGVjdGl2ZSBpdCBt
YXkgYmUgZ29vZCB0byBzdWdnZXN0IHNvbWUNCiBzcGVjaWZpYyB0eXBlIG9mIGluZm9ybWF0aW9u
IGFuZCB1cGRhdGUgdGhlIGV4YW1wbGVzIGNvbnNpc3RlbnRseS4gVGhlbiB3ZSBtYXkgZGlzY3Vz
cyBmdXJ0aGVyIHBvc3NpYmxlIHZhbHVlcyBmb3IgdGhpcywgYXQgbGVhc3QgdGhlaXIgc2VtYW50
aWNzIGluIHRoZSB3ZWJmaW5nZXIgY29udGV4dC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K
Y29sb3I6IzFGNDk3RCI+d2FsdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmIuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3R5bGUgdHlwZT0idGV4dC9j
c3MiPg0KPCEtLQ0Kc3Bhbi5HcmFtRSB7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5
ZXM7fQ0KLS0+DQo8L3N0eWxlPg0KPHRhYmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KPHRib2R5
Pg0KPHRyPg0KPHRkIHN0eWxlPSJ3aWR0aDo1ODVweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFy
aWFsOyBmb250LXNpemU6MTJweDsgY29sb3I6IzAwMDsgdGV4dC1hbGlnbjoganVzdGlmeSIgd2lk
dGg9IjM5NSI+DQo8ZGl2IGFsaWduPSJqdXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5OyBsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYSI+UXVlc3RvIG1lc3NhZ2dpbyBl
IGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVy
c29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBh
emlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBz
b25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0
byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJu
ZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxs
YSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8cCBhbGln
bj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz
dGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv
bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdC
Ij5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzPC9zcGFuPjwvaT48aT48c3BhbiBsYW5n
PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7bXNvLWJpZGktZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4mbmJzcDs8
c3BhbiBjbGFzcz0iR3JhbUUiPmlzPC9zcGFuPiZuYnNwOzwvc3Bhbj48L2k+PGk+PHNwYW4gbGFu
Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6DQogIDcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7
bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPmNvbmZpZGVudGlhbA0KIGFuZCBtYXkgY29udGFpbiBw
cml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHku
IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2Ug
aXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw
bGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2Ug
dGhlIHNlbmRlcg0KIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy48L3NwYW4+PC9pPjxzcGFuIGxh
bmc9IkVOLUdCIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPg0KPC9zcGFuPjwvc3Bh
bj48L3A+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0Ow0KICBmb250LWZhbWlseTpW
ZXJkYW5hIj48aW1nIHNyYz0iY2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAxQFRJ
LkRpc2NsYWltZXIiIGFsdD0icmlzcGV0dGEgbCdhbWJpZW50ZSIgd2lkdGg9IjI2IiBoZWlnaHQ9
IjQwIj5SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9u
IMOoIG5lY2Vzc2FyaW8uPC9zcGFuPjwvYj4NCjxwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k
eT4NCjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_A09A9E0A4B9C654E8672D1DC003633AE4057005F1EGRFMBX704BA02_--

--_023dfe26-0d0a-4271-9c98-d203f31a29d9_
Content-Description: logo Ambiente_foglia.jpg
Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg"
Content-Disposition: inline; filename="logo Ambiente_foglia.jpg"
Content-Transfer-Encoding: base64
Content-ID: 00000000000000000000000000000001@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=

--_023dfe26-0d0a-4271-9c98-d203f31a29d9_--

From alexey.melnikov@isode.com  Mon Nov 21 02:21:56 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD83B21F8B98 for ; Mon, 21 Nov 2011 02:21:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.19
X-Spam-Level: 
X-Spam-Status: No, score=-101.19 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, MIME_8BIT_HEADER=0.3, 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 NSqo-sN7jkyU for ; Mon, 21 Nov 2011 02:21:52 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3F43421F8B8D for ; Mon, 21 Nov 2011 02:21:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1321870908; d=isode.com; s=selector; i=@isode.com; bh=7TUtcmfey+e8DY5a+yUN2f8RU4TBwtO+I6KkOaX1g94=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=HD+q2ZbgdKAf2ej1t/UAHTpcOsmD3BnB4O+FHiuWs02DU31hIWUCHzkxIhhnw6ntrqzo2F viwTAWrPTL20VUmD8EFmm/wYxCAgX8iIQsNCE9kWv8HuBJchc+BGThlCWQiHci4C+JQfvp hY7Um8SP7F/6R6m3V3HROYwm6dlykCA=;
Received: from [192.168.1.144] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Mon, 21 Nov 2011 10:21:48 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4EC8B6D9.3080507@isode.com>
Date: Sun, 20 Nov 2011 08:14:17 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsiki?= 
References: <4EC16815.80501@gmail.com>
In-Reply-To: <4EC16815.80501@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 10:21:56 -0000

On 14/11/2011 19:12, "Mykyta Yevstifeyev (=D0=9C. =D0=84=D0=B2=D1=81=D1=82=
=D1=96=D1=84=D0=B5=D1=94=D0=B2)" wrote:
> Hello,
>
> From minutes:
>
>> 09:05 draft-ietf-appsawg-about-uri-scheme (chairs)
>>
>> Room consensus for registry to be FCFS with minimal doc via template.
>
> That is what the WG reached at the previous meeting and what is not=20
> there currently is in the doc.  Before it became a WG item, the=20
> authors, ADs and me did have a discussion on this point, but there was=20
> no agreement - that's why it became WG item.  What I actually think is=20
> that FCFS should be appropriate, but there is no point of adding a=20
> registry entry given no specification available whereas the MUST=20
> restriction is imposed.  Recently Barry has sent me the following=20
> proposal: to have the policy FCFS but make specification reference=20
> mandatory for registration.  Therefore, if there is nobody who=20
> objects, I may change the following text in IANA Considerations:
>
> OLD:
>
>>     The registration policy for new entries is "Specification Required",
>>     as defined in RFC 5226 [RFC5226].  Additionally, the following
>>     template MUST be provided by the registrant:
>
> NEW:
>
>>     The registration policy for new entries is "First Come First=20
>> Served",
>>     as defined in RFC 5226 [RFC5226].  Additionally, the following
>>     template MUST be provided by the registrant:
>
> OLD:
>
>>     o Published specifications:  A reference to the published
>>       specification for the registered token.
>
> NEW:
>
>>     o Published specifications:  A reference to the stable specification
>>       MUST be provided.
I think allowing for specifications in an email message to IANA (or=20
similar) should be sufficient, as long as IANA archives a copy of the=20
registration on their website.

Otherwise this looks Ok.
>> The specification SHALL cover what the SPU
>>       with the token being registered ought to resolve to, and SHOULD
>>       cover other issues related to SPU usage.
> Any comments are welcome.


From alexey.melnikov@isode.com  Mon Nov 21 02:22:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B86F21F8B8D for ; Mon, 21 Nov 2011 02:22:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.153
X-Spam-Level: 
X-Spam-Status: No, score=-101.153 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, MIME_8BIT_HEADER=0.3, 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 nA553yNtRwEJ for ; Mon, 21 Nov 2011 02:21:56 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id EDC3921F8B95 for ; Mon, 21 Nov 2011 02:21:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1321870915; d=isode.com; s=selector; i=@isode.com; bh=8gLgfaGC9AUWYiH1cGkHWYZxsfjuE1g3w85Bewu8A9k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=INw4eXS5GSCbCoLHP7L1NOosoCCW0wdtXRd3PsRJ2Ku/zhc3GhGYzdGf9kDqdJ4xDIeiA5 BprVBLjVPx4nUhfsF+3TDzMYFC8GRkE8+FPMrWZYPZPtyVHD2YSWxwALeWIg+n8FGQqab9 zQS8hmoHIk4EkRTWrNIMiFBM+8zhgsE=;
Received: from [192.168.1.144] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Mon, 21 Nov 2011 10:21:53 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4EC8B870.7070105@isode.com>
Date: Sun, 20 Nov 2011 08:21:04 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsiki?= 
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com> <4EC40EC3.9080304@gmail.com>
In-Reply-To: <4EC40EC3.9080304@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 10:22:00 -0000

On 16/11/2011 19:28, "Mykyta Yevstifeyev (=D0=9C. =D0=84=D0=B2=D1=81=D1=82=
=D1=96=D1=84=D0=B5=D1=94=D0=B2)" wrote:
> 15.11.2011 4:56, Alexey Melnikov wrote:
>> Hi Mykyta,
> Hello Alexey.
Hi,

  [...]
>>    The 'about' URI MUST syntactically conform to the  rule
>>    below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]:
>>
>>      about-uri   =3D "about:" about-token [ about-query ]
>>      about-token =3D segment
>>      about-query =3D "?" query
>>      segment     =3D 
>>      query       =3D 
>>
>>    In terms of RFC 3986,  part corresponds to ,
>>    and  to the query component of URI.
>>
>> s/query/ ? (I didn't check RFC 3986)
> 2.1. URI Scheme Syntax
>
>  doesn't include "?" - so query component.
You misunderstood. You have "about-token" enclosed in <>, I think you=20
need <> around "query" as well.
>
>>
>>
>> 2.2. URI Scheme Semantics
>>
>>    However, it is impossible to specify binding between all the possible
>>    tokens and the semantics of 'about' URIs that would contain such
>>    tokens.  Therefore any application MAY resolve an 'about' URI to any
>>    desired resource, and MAY redirect such URIs.
>>
>> The meaning of redirection is not defined here. Do you mean=20
>> redirection in HTTP sense?
>> If yes, I think a reference to HTTP (RFC 2616) is needed.
> Yes, redirection needs clarification.  That is not HTTP sense here - I=20
> meant they can be replaced by some other URIs and than resolved to=20
> what these URIs refer to, and the latter of them needn't necessarily=20
> be 'http' URIs.
I don't know of any better reference than RFC 2616. Conceptually one URI=20
is replaced with another, so even if a non HTTP URI is used, this should=20
work.
>> 2.2.1. Special-Purpose 'about' URIs
>>
>>    A small, though expandable, range of s are reserved for
>>    use in special-purpose 'about' URIs, abbreviated "SPU" (special-
>>    purpose URI).  Such tokens are named "special-purpose 'about' URI
>>    tokens", and abbreviated "SPT" (special-purpose token).
>>
>>    An SPU is an 'about' URI containing one of the registered SPTs as the
>>  part.  An SPU MUST be handled in strict accordance with
>>    the rules defined for SPT contained therein.  The SPT specification
>>    MAY define additional provisions on handling of  part in
>>    the corresponding SPU; by default, it MUST be ignored for the purpose
>>    of handling SPU.
>>
>> Where is this requirement coming from? Is this common behaviour among
>> existing browsers?
>
> We still haven't had such a term as 'special-purpose about URI', and=20
> so we can't speak of common behavior.  IMO, taking into account the=20
> intended semantics of SPUs, if the meaning of query isn't defined, it=20
> must be ignored not to eliminate the said semantics and their utility.
It looks like the first part of the sentence is as a recommendation for=20
new SPU designers, the second part is a recommendation for developers.=20
This adds to confusion and I suggest you reword this, for example:

    The SPT specification MAY define additional provisions on handling=20
of  part in
    the corresponding SPU. Unless specified otherwise, implementations=20
MUST ignore the 
    part when processing SPUs.

This also avoids passive voice.
>>    SPU MAY be defined to be unresolvable.  This means that an
>>    application MUST NOT resolve it in some particular resource.
Did you mean "context" instead of "resource" here?
>>   Such
>>    SPUs may be used as placeholders, or in some other way.
>>
>> I fail to see utility in this. Can you maybe provide an example
>> of an unresolvable about URI?
>> (This might also affect the IANA registration section which includes
>> this flag in the token registration template.)
> That is what HTML5 wants to define (actually, defines).  we had a=20
> discussion on this previously.
I think that if the document wants to talk about these, it needs to=20
provide more details.

The fact that some URIs might be unresolvable in some contexts is kind=20
of self evident. But maybe it is just me.
>> 2.2.2. Unrecognized 'about' URIs
>>
>>    Naturally, an application will support only a particular range of
>>    'about' URIs; also, some applications will support 'about' URIs that
>>    are not supported by an other one.  This document specifies the rules
>>    for handling unrecognized 'about' URIs.
>>
>>    An unrecognized 'about' URIs as a URI that may not be recognized by
>>    an application.  (Correspondingly, such categorization is per-
>>    application, not per-fact.)
>>
>> I don't understand the comment in () and I don't think it adds any value
>> anyway.
> It means that 'about' URI can't be defined to be unrecognized - this=20
> all depends on application.
The first sentence quoted above already says that. Besides, I don't=20
understand the meaning of "per-fact" in this context.
>>    An unrecognized 'about' URI SHOULD be
>>    handled as the  URI, although other behavior is
>>    possible.
>>
>> Is there a reason why this is a SHOULD? This seems rather strong here.
>> I am thinking that displaying an error about unrecognized token would be
>> another reasonable choice. In fact it would be my preferred choice.
> This is for what I place SHOULD.  And this *is* common behavior.
>> 2.3. Encoding Considerations
>>
>>    'about' URIs are subject to encoding rules defined in RFC 3986
>>    [RFC3986].  'about' IRIs [RFC3987] are not permitted.
>>
>> The last quoted sentence: why?
>> If an about URI is used to edit configuration, I can see some Unicode=20
>> being
>> passed in the query part of such URI.
> We have no evidence of use.  That is the reason.
I suppose I should test browser behaviour in the 2 cases mentioned above.



From laurentwalter.goix@telecomitalia.it  Mon Nov 21 02:26:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C98021F8BAB for ; Mon, 21 Nov 2011 02:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.784
X-Spam-Level: 
X-Spam-Status: No, score=0.784 tagged_above=-999 required=5 tests=[AWL=-0.287,  BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 IBqlTrXLmGun for ; Mon, 21 Nov 2011 02:26:34 -0800 (PST)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id BABE121F8BA9 for ; Mon, 21 Nov 2011 02:26:33 -0800 (PST)
Content-Type: multipart/mixed; boundary="_7fa74c1e-a0cb-4fca-b9d3-9aed82472b1d_"
Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Nov 2011 11:26:33 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Mon, 21 Nov 2011 11:26:32 +0100
From: Goix Laurent Walter 
To: =?utf-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsiki?= , "apps-discuss@ietf.org" 
Date: Mon, 21 Nov 2011 11:26:31 +0100
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AcynQf+MU+OlG+4OSBC52mee0899vwA9NKaQ
Message-ID: 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4EC88AAF.2000007@gmail.com>
In-Reply-To: <4EC88AAF.2000007@gmail.com>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [apps-discuss] R:  Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 10:26:35 -0000

--_7fa74c1e-a0cb-4fca-b9d3-9aed82472b1d_
Content-Type: multipart/alternative;
	boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE4057005F31GRFMBX704BA02_"

--_000_A09A9E0A4B9C654E8672D1DC003633AE4057005F31GRFMBX704BA02_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

KzEgZm9yIHRoaXMuIFRoZXJlIG1heSBub3QgYmUgdGhlIG5lZWQgZm9yIEhUVFBTIGFsbCB0aGUg
dGltZS4gU29tZSBzZWN1cml0eSBjb3VsZCBiZSBwcm92aWRlZCB1c2luZyBYUkQgc2lnbmF0dXJl
LCB3aGljaCBtYXkgYmUgY29uc2lkZXJlZCBlbm91Z2ggYnkgc29tZSBpbXBsZW1lbnRhdGlvbnMu
DQoNCkFsc28gSSBkbyBub3Qgc2VlIHdoeSBKUkQgbmVlZCBiZSBtYW5kYXRlZCBpbnN0ZWFkIG9m
IFhSRCwgd2hpY2ggZXhpc3RlZCBsb25nIGJlZm9yZSBhbmQgaXMgYWxyZWFkeSB1c2VkIGFuZCBy
ZWZlcmVuY2VkIGJ5IHNldmVyYWwgc3BlY3MsIHdoaWNoIG1heSBub3QgYmUgYXdhcmUvYWtlZW4g
dG8gYWxzbyBzdXBwb3J0IGpzb24uDQpJIGd1ZXNzIGl0IGFsc28gcmVsYXRlcyB0byB3aGljaCBl
bnRpdHkgd2lsbCB1c2Ugd2ViZmluZ2VyLiBNeSB1bmRlcnN0YW5kIGlzIHRoYXQgbm93YWRheXMg
YSB3ZWJmaW5nZXIgY2xpZW50IGlzIGltcGxlbWVudGVkIGJ5IGEgbmV0d29yayByZXNvdXJjZSBm
b3IgZmVkZXJhdGlvbiBwdXJwb3NlcyBtb3JlIHRoYW4gd2l0aGluIHNvbWUgamF2YXNjcmlwdCBj
b2RlLiBJIGNhbiB1bmRlcnN0YW5kIGZ1dHVyZSB1c2FnZXMgZm9yIGEgZGlyZWN0IGphdmFzY3Jp
cHQgaW52b2NhdGlvbiBidXQgd291bGRu4oCZdCBsaW1pdCB0byBpdCwgdG8ga2VlcCBjb25zaXN0
ZW5jeSB3aXRoIFhSRC4NCg0Kd2FsdGVyDQoNCkRhOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRm
Lm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSBQZXIgY29udG8gZGkg
Ik15a3l0YSBZZXZzdGlmZXlldiAoPy4gPz8/Pz8/Pz8/KSINCkludmlhdG86IGRvbWVuaWNhIDIw
IG5vdmVtYnJlIDIwMTEgNi4wNg0KQTogYXBwcy1kaXNjdXNzQGlldGYub3JnDQpPZ2dldHRvOiBS
ZTogW2FwcHMtZGlzY3Vzc10gV2ViZmluZ2VyDQoNCjE5LjExLjIwMTEgMTc6MDMsIEVyYW4gSGFt
bWVyLUxhaGF2IHdyb3RlOg0KDQpBcmUgdGhlcmUgcmVhc29ucyBub3QgdG8gbWFuZGF0ZSBIVFRQ
Uz8NCg0KSSBkb24ndCB0aGluayB0aGUgZG9jdW1lbnQgc2hvdWxkIHB1dCBNVVNUIG9uIHVzaW5n
IEhUVFBTLiAgUkZDIDY0MTUgc3BlY2lmaWVkIHRoYXQgaG9zdC1tZXRhIGRvY3VtZW50IGNhbiBi
ZSBsb2NhdGVkIHVzaW5nIGJvdGggSFRUUCBhbmQgSFRUUFMsIGFuZCBJIGRvbid0IHNlZSBhIHJl
YXNvbiB0byBjb25zdHJhaW4gdGhpcyBpbiBXZWJmaW5nZXIuICBNYXliZSB0aGUgc3BlYy4gc2hv
dWxkIHJlcGVhdCB0aGF0IGJvdGggSFRUUCBhbmQgc2VjdXJlZCB2YXJpYW50cyBtYXkgYmUgdXNl
ZC4NCg0KTXlreXRhIFlldnN0aWZleWV2DQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVn
YXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRl
LiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRl
IGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVu
dGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVy
IGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29t
dW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlv
bmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRl
bnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9y
IHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcg
b3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRo
ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkg
YXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5r
cy4NCg0KW2NpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMUBUSS5EaXNjbGFpbWVy
XVJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6gg
bmVjZXNzYXJpby4NCg0K

--_000_A09A9E0A4B9C654E8672D1DC003633AE4057005F31GRFMBX704BA02_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206
b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw
QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4
MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj
Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw
dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl
YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u
ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2
YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z
OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9
Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB
VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z
Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n
cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y
MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz
ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h
cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht
bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg
eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz
LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9
Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0
cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0
dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i
aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3
Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv
IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp
Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp
Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0
cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v
c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s
bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4
bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw
Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv
aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl
bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6
cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl
TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No
YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3
LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu
dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i
R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+
DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIg
NCAyIDQgMiAyIDM7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxp
Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz
dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJ
bWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4w
cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlN0aWxl
TWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0
O30NCnNwYW4uU3RpbGVNZXNzYWdnaW9EaVBvc3RhRWxldHRyb25pY2ExOQ0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5TdGlsZU1lc3NhZ2dpb0RpUG9zdGFFbGV0dHJvbmljYTIwDQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24x
DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3
Mi4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw
aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0
IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiYjNDM7MSBmb3IgdGhpcy4gVGhl
cmUgbWF5IG5vdCBiZSB0aGUgbmVlZCBmb3IgSFRUUFMgYWxsIHRoZSB0aW1lLiBTb21lIHNlY3Vy
aXR5IGNvdWxkIGJlIHByb3ZpZGVkIHVzaW5nIFhSRCBzaWduYXR1cmUsIHdoaWNoIG1heSBiZSBj
b25zaWRlcmVkIGVub3VnaCBieSBzb21lIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QWxzbyBJIGRv
IG5vdCBzZWUgd2h5IEpSRCBuZWVkIGJlIG1hbmRhdGVkIGluc3RlYWQgb2YgWFJELCB3aGljaCBl
eGlzdGVkIGxvbmcgYmVmb3JlIGFuZCBpcyBhbHJlYWR5IHVzZWQgYW5kIHJlZmVyZW5jZWQgYnkg
c2V2ZXJhbCBzcGVjcywgd2hpY2ggbWF5IG5vdCBiZSBhd2FyZS9ha2VlbiB0byBhbHNvIHN1cHBv
cnQganNvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgZ3Vlc3MgaXQgYWxzbyByZWxh
dGVzIHRvIHdoaWNoIGVudGl0eSB3aWxsIHVzZSB3ZWJmaW5nZXIuIE15IHVuZGVyc3RhbmQgaXMg
dGhhdCBub3dhZGF5cyBhIHdlYmZpbmdlciBjbGllbnQgaXMgaW1wbGVtZW50ZWQgYnkgYSBuZXR3
b3JrIHJlc291cmNlIGZvciBmZWRlcmF0aW9uIHB1cnBvc2VzIG1vcmUgdGhhbiB3aXRoaW4gc29t
ZSBqYXZhc2NyaXB0DQogY29kZS4gSSBjYW4gdW5kZXJzdGFuZCBmdXR1cmUgdXNhZ2VzIGZvciBh
IGRpcmVjdCBqYXZhc2NyaXB0IGludm9jYXRpb24gYnV0IHdvdWxkbuKAmXQgbGltaXQgdG8gaXQs
IHRvIGtlZXAgY29uc2lzdGVuY3kgd2l0aCBYUkQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPndhbHRlcjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KJnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EYTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBhcHBzLWRpc2N1
c3MtYm91bmNlc0BpZXRmLm9yZw0KIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5v
cmddIDxiPlBlciBjb250byBkaSA8L2I+PC9zcGFuPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ow0KY29sb3I6d2luZG93dGV4dCI+JnF1b3Q7TXlreXRhIFlldnN0aWZleWV2
ICg/LiA/Pz8/Pz8/Pz8pJnF1b3Q7PGJyPg0KPGI+SW52aWF0bzo8L2I+IGRvbWVuaWNhIDIwIG5v
dmVtYnJlIDIwMTEgNi4wNjxicj4NCjxiPkE6PC9iPiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8YnI+
DQo8Yj5PZ2dldHRvOjwvYj4gUmU6IFthcHBzLWRpc2N1c3NdIFdlYmZpbmdlcjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjE5LjExLjIwMTEgMTc6MDMsIEVy
YW4gSGFtbWVyLUxhaGF2IHdyb3RlOiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0
UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMxRjQ5N0QiPkFyZSB0aGVyZSByZWFzb25zIG5vdCB0byBtYW5kYXRlIEhUVFBTPzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz
ZXJpZiZxdW90OyI+PGJyPg0KSSBkb24ndCB0aGluayB0aGUgZG9jdW1lbnQgc2hvdWxkIHB1dCBN
VVNUIG9uIHVzaW5nIEhUVFBTLiZuYnNwOyBSRkMgNjQxNSBzcGVjaWZpZWQgdGhhdCBob3N0LW1l
dGEgZG9jdW1lbnQgY2FuIGJlIGxvY2F0ZWQgdXNpbmcgYm90aCBIVFRQIGFuZCBIVFRQUywgYW5k
IEkgZG9uJ3Qgc2VlIGEgcmVhc29uIHRvIGNvbnN0cmFpbiB0aGlzIGluIFdlYmZpbmdlci4mbmJz
cDsgTWF5YmUgdGhlIHNwZWMuIHNob3VsZCByZXBlYXQgdGhhdCBib3RoIEhUVFAgYW5kIHNlY3Vy
ZWQNCiB2YXJpYW50cyBtYXkgYmUgdXNlZC48YnI+DQo8YnI+DQpNeWt5dGEgWWV2c3RpZmV5ZXY8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQo8
IS0tDQpzcGFuLkdyYW1FIHttc28tc3R5bGUtbmFtZToiIjsNCgltc28tZ3JhbS1lOnllczt9DQot
LT4NCjwvc3R5bGU+DQo8dGFibGUgc3R5bGU9IndpZHRoOjYwMHB4OyI+DQo8dGJvZHk+DQo8dHI+
DQo8dGQgc3R5bGU9IndpZHRoOjU4NXB4OyBmb250LWZhbWlseTogVmVyZGFuYSwgQXJpYWw7IGZv
bnQtc2l6ZToxMnB4OyBjb2xvcjojMDAwOyB0ZXh0LWFsaWduOiBqdXN0aWZ5IiB3aWR0aD0iMzk1
Ij4NCjxkaXYgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0
ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hIj5RdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9p
IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGlu
ZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaQ0KIGFsdHJhIGF6aW9uZSBk
ZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmln
b3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3Vt
ZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVk
aWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBk
aXN0cnV6aW9uZSwgR3JhemllLg0KPC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjxwIGFsaWduPSJqdXN0
aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5OyBs
aW5lLWhlaWdodDpub3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl
OjcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPlRoaXMg
ZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHM8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVOLUdC
IiBzdHlsZT0iZm9udC1zaXplOg0KICA3LjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOzxzcGFuIGNs
YXNzPSJHcmFtRSI+aXM8L3NwYW4+Jm5ic3A7PC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1H
QiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTttc28tYW5z
aS1sYW5ndWFnZTpFTi1HQiI+Y29uZmlkZW50aWFsDQogYW5kIG1heSBjb250YWluIHByaXZpbGVn
ZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2Vt
aW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1
dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBk
ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2Vu
ZGVyDQogYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4t
R0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+DQo8L3NwYW4+PC9zcGFuPjwvcD4N
CjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7DQogIGZvbnQtZmFtaWx5OlZlcmRhbmEi
PjxpbWcgc3JjPSJjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDFAVEkuRGlzY2xh
aW1lciIgYWx0PSJyaXNwZXR0YSBsJ2FtYmllbnRlIiB3aWR0aD0iMjYiIGhlaWdodD0iNDAiPlJp
c3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVj
ZXNzYXJpby48L3NwYW4+PC9iPg0KPHA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90
YWJsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_A09A9E0A4B9C654E8672D1DC003633AE4057005F31GRFMBX704BA02_--

--_7fa74c1e-a0cb-4fca-b9d3-9aed82472b1d_
Content-Description: logo Ambiente_foglia.jpg
Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg"
Content-Disposition: inline; filename="logo Ambiente_foglia.jpg"
Content-Transfer-Encoding: base64
Content-ID: 00000000000000000000000000000001@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=

--_7fa74c1e-a0cb-4fca-b9d3-9aed82472b1d_--

From evnikita2@gmail.com  Mon Nov 21 03:31:12 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BD321F8BA6 for ; Mon, 21 Nov 2011 03:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.313
X-Spam-Level: 
X-Spam-Status: No, score=-3.313 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 v7g5jWSBHOQe for ; Mon, 21 Nov 2011 03:31:11 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8564F21F8B9B for ; Mon, 21 Nov 2011 03:31:11 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so7371552bkb.31 for ; Mon, 21 Nov 2011 03:31:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xpg4Q56s/dilhO8f3JPMaUhCbf76RM2k4wfFxTi8xE0=; b=yDp5yl2Kvfo07pW0OuXzVi6qqQc/9G/RvXOM4x1ZvlnRDqcwcTizYy4k4kVWmjyijx 7HhbsZuEXAVI0fPBtziirvKnQIOOBvUPUF2qzweIBpRX6PmtYX6MO96Gqm1lEpFOmrR9 azLza30fM+2w8Ki10Yv/R39YPpt688FNhtVdw=
Received: by 10.204.130.90 with SMTP id r26mr14245384bks.46.1321875069579; Mon, 21 Nov 2011 03:31:09 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x14sm7019629bkf.10.2011.11.21.03.31.07 (version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 03:31:08 -0800 (PST)
Message-ID: <4ECA36AF.7050102@gmail.com>
Date: Mon, 21 Nov 2011 13:31:59 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Alexey Melnikov 
References: <4EC16815.80501@gmail.com> <4EC8B6D9.3080507@isode.com>
In-Reply-To: <4EC8B6D9.3080507@isode.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 11:31:12 -0000

20.11.2011 10:14, Alexey Melnikov wrote:
> On 14/11/2011 19:12, "Mykyta Yevstifeyev (Ğœ. ЄвÑтіфеєв)" wrote:
>> Hello,
>>
>> From minutes:
>>
>>> 09:05 draft-ietf-appsawg-about-uri-scheme (chairs)
>>>
>>> Room consensus for registry to be FCFS with minimal doc via template.
>>
>> That is what the WG reached at the previous meeting and what is not 
>> there currently is in the doc.  Before it became a WG item, the 
>> authors, ADs and me did have a discussion on this point, but there 
>> was no agreement - that's why it became WG item.  What I actually 
>> think is that FCFS should be appropriate, but there is no point of 
>> adding a registry entry given no specification available whereas the 
>> MUST restriction is imposed.  Recently Barry has sent me the 
>> following proposal: to have the policy FCFS but make specification 
>> reference mandatory for registration.  Therefore, if there is nobody 
>> who objects, I may change the following text in IANA Considerations:
>>
>> OLD:
>>
>>>     The registration policy for new entries is "Specification 
>>> Required",
>>>     as defined in RFC 5226 [RFC5226].  Additionally, the following
>>>     template MUST be provided by the registrant:
>>
>> NEW:
>>
>>>     The registration policy for new entries is "First Come First 
>>> Served",
>>>     as defined in RFC 5226 [RFC5226].  Additionally, the following
>>>     template MUST be provided by the registrant:
>>
>> OLD:
>>
>>>     o Published specifications:  A reference to the published
>>>       specification for the registered token.
>>
>> NEW:
>>
>>>     o Published specifications:  A reference to the stable 
>>> specification
>>>       MUST be provided.
> I think allowing for specifications in an email message to IANA (or 
> similar) should be sufficient, as long as IANA archives a copy of the 
> registration on their website.

This can't be allowed as we need to provide a specification in terms of 
what is defined by Section 7 of RFC 2026.  Whenever the special-purpose 
URI is defined, we should ensure that it is the part of some 
standardization effort by some organization, and not me wanting to 
register "about:yevstifeyev" mandatory displaying my name (that's 
actually why I still like Specification required with DE involved, but 
must follow community consensus on this.)

Mykyta Yevstifeyev

>
> Otherwise this looks Ok.
>>> The specification SHALL cover what the SPU
>>>       with the token being registered ought to resolve to, and SHOULD
>>>       cover other issues related to SPU usage.
>> Any comments are welcome.
>
>


From evnikita2@gmail.com  Mon Nov 21 03:46:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F069621F8BBB for ; Mon, 21 Nov 2011 03:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.012
X-Spam-Level: 
X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 M+aW6YPdWBXX for ; Mon, 21 Nov 2011 03:46:03 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9BBC21F84A9 for ; Mon, 21 Nov 2011 03:46:02 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so7389504bkb.31 for ; Mon, 21 Nov 2011 03:46:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hcG/P+g4WtmYh4kptu6Z3/iC/7B+aWfTebVVU6n71GA=; b=rVy98Y4APnQx4gxZq993Bn8mKTV+hkz+TgOhBqa/VfnKEQPQI/m99CpexLcVXcVyFK VboS3MlgSy+Lnk21YGMsLhMRdibcD60p2Z7SlTV8DvrGMHZSuOxUmt/HyS6dQi2XhdyO lmNAO51nZ2MVmXBZveGZPyBSU1CYGGiggEoFg=
Received: by 10.205.141.73 with SMTP id jd9mr14303601bkc.21.1321875961741; Mon, 21 Nov 2011 03:46:01 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x14sm7052587bkf.10.2011.11.21.03.46.00 (version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 03:46:01 -0800 (PST)
Message-ID: <4ECA3A2C.1010606@gmail.com>
Date: Mon, 21 Nov 2011 13:46:52 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Alexey Melnikov 
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com> <4EC40EC3.9080304@gmail.com> <4EC8B870.7070105@isode.com>
In-Reply-To: <4EC8B870.7070105@isode.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 11:46:04 -0000

20.11.2011 10:21, Alexey Melnikov wrote:
> On 16/11/2011 19:28, "Mykyta Yevstifeyev (Ğœ. ЄвÑтіфеєв)" wrote:
>> 15.11.2011 4:56, Alexey Melnikov wrote:
>>> Hi Mykyta,
>> Hello Alexey.
> Hi,
>
>  [...]
>>>    The 'about' URI MUST syntactically conform to the  rule
>>>    below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]:
>>>
>>>      about-uri   = "about:" about-token [ about-query ]
>>>      about-token = segment
>>>      about-query = "?" query
>>>      segment     = 
>>>      query       = 
>>>
>>>    In terms of RFC 3986,  part corresponds to ,
>>>    and  to the query component of URI.
>>>
>>> s/query/ ? (I didn't check RFC 3986)
>> 2.1. URI Scheme Syntax
>>
>>  doesn't include "?" - so query component.
> You misunderstood. You have "about-token" enclosed in <>, I think you 
> need <> around "query" as well.

The RFC 3986  production does not include "?" delimiter but only 
the range of chars allowed in the query component while  
stands for query itself and the delimiter.  That would be technically 
inaccurate if I mentioned .

>>
>>>
>>>
>>> 2.2. URI Scheme Semantics
>>>
>>>    However, it is impossible to specify binding between all the 
>>> possible
>>>    tokens and the semantics of 'about' URIs that would contain such
>>>    tokens.  Therefore any application MAY resolve an 'about' URI to any
>>>    desired resource, and MAY redirect such URIs.
>>>
>>> The meaning of redirection is not defined here. Do you mean 
>>> redirection in HTTP sense?
>>> If yes, I think a reference to HTTP (RFC 2616) is needed.
>> Yes, redirection needs clarification.  That is not HTTP sense here - 
>> I meant they can be replaced by some other URIs and than resolved to 
>> what these URIs refer to, and the latter of them needn't necessarily 
>> be 'http' URIs.
> I don't know of any better reference than RFC 2616. Conceptually one 
> URI is replaced with another, so even if a non HTTP URI is used, this 
> should work.

I've added the following text:

>
>    and MAY redirect such URIs, i.e. resolve it to a resource commonly
>    referred to by an other URI.

>>> 2.2.1. Special-Purpose 'about' URIs
>>>
>>>    A small, though expandable, range of s are reserved for
>>>    use in special-purpose 'about' URIs, abbreviated "SPU" (special-
>>>    purpose URI).  Such tokens are named "special-purpose 'about' URI
>>>    tokens", and abbreviated "SPT" (special-purpose token).
>>>
>>>    An SPU is an 'about' URI containing one of the registered SPTs as 
>>> the
>>>  part.  An SPU MUST be handled in strict accordance with
>>>    the rules defined for SPT contained therein.  The SPT specification
>>>    MAY define additional provisions on handling of  
>>> part in
>>>    the corresponding SPU; by default, it MUST be ignored for the 
>>> purpose
>>>    of handling SPU.
>>>
>>> Where is this requirement coming from? Is this common behaviour among
>>> existing browsers?
>>
>> We still haven't had such a term as 'special-purpose about URI', and 
>> so we can't speak of common behavior.  IMO, taking into account the 
>> intended semantics of SPUs, if the meaning of query isn't defined, it 
>> must be ignored not to eliminate the said semantics and their utility.
> It looks like the first part of the sentence is as a recommendation 
> for new SPU designers, the second part is a recommendation for 
> developers. This adds to confusion and I suggest you reword this, for 
> example:
>
>    The SPT specification MAY define additional provisions on handling 
> of  part in
>    the corresponding SPU. Unless specified otherwise, implementations 
> MUST ignore the 
>    part when processing SPUs.

Agreed.

>
> This also avoids passive voice.

What's bad of passive voice, BTW? :-)

>>>    SPU MAY be defined to be unresolvable.  This means that an
>>>    application MUST NOT resolve it in some particular resource.
> Did you mean "context" instead of "resource" here?

I meant "to" instead of "in" actually.

>>>   Such
>>>    SPUs may be used as placeholders, or in some other way.
>>>
>>> I fail to see utility in this. Can you maybe provide an example
>>> of an unresolvable about URI?
>>> (This might also affect the IANA registration section which includes
>>> this flag in the token registration template.)
>> That is what HTML5 wants to define (actually, defines).  we had a 
>> discussion on this previously.
> I think that if the document wants to talk about these, it needs to 
> provide more details.

What are such possible details?

>
> The fact that some URIs might be unresolvable in some contexts is kind 
> of self evident. But maybe it is just me.
>>> 2.2.2. Unrecognized 'about' URIs
>>>
>>>    Naturally, an application will support only a particular range of
>>>    'about' URIs; also, some applications will support 'about' URIs that
>>>    are not supported by an other one.  This document specifies the 
>>> rules
>>>    for handling unrecognized 'about' URIs.
>>>
>>>    An unrecognized 'about' URIs as a URI that may not be recognized by
>>>    an application.  (Correspondingly, such categorization is per-
>>>    application, not per-fact.)
>>>
>>> I don't understand the comment in () and I don't think it adds any 
>>> value
>>> anyway.
>> It means that 'about' URI can't be defined to be unrecognized - this 
>> all depends on application.
> The first sentence quoted above already says that. Besides, I don't 
> understand the meaning of "per-fact" in this context.

"per-fact" is meant to be predefined for some particular URI.  However, 
if you insist, I don't object to removing that sentence.

>>>    An unrecognized 'about' URI SHOULD be
>>>    handled as the  URI, although other behavior is
>>>    possible.
>>>
>>> Is there a reason why this is a SHOULD? This seems rather strong here.
>>> I am thinking that displaying an error about unrecognized token 
>>> would be
>>> another reasonable choice. In fact it would be my preferred choice.
>> This is for what I place SHOULD.  And this *is* common behavior.
>>> 2.3. Encoding Considerations
>>>
>>>    'about' URIs are subject to encoding rules defined in RFC 3986
>>>    [RFC3986].  'about' IRIs [RFC3987] are not permitted.
>>>
>>> The last quoted sentence: why?
>>> If an about URI is used to edit configuration, I can see some 
>>> Unicode being
>>> passed in the query part of such URI.
>> We have no evidence of use.  That is the reason.
> I suppose I should test browser behaviour in the 2 cases mentioned above.

Case 1 (testing about:yevstifeyev):
FF 7.0.1: a warning and about:blank
IE8: tried to load the error page (res://ieframe.dll/navcancl.htm) but 
failed
Chrome 15: redirected to chrome://yevstifeyev and displayed an error.
Safari 3.2.1 for Win: about:blank.

Conclusion: let's remove the recognized/unrecognized section at all, and 
leave this to app designers.

Case 2: (testing about:євÑтіфеєв - that's my surname in Ukrainian)
FF: the same
IE: the same
Chrome: translated to chrome://xn--b1aai1cfm2ifp/ and showed an error
Safari: the same

However, that's really not the case for such testing as all 
currently-in-use 'about' RIs are URIs and not IRIs.  Conclusion: no 
change, I think (we'll be able to change this at any time, should we 
need that).

Mykyta Yevstifeyev

>
>
>


From julian.reschke@gmx.de  Mon Nov 21 06:13:14 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21A321F8B66 for ; Mon, 21 Nov 2011 06:13:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.133
X-Spam-Level: 
X-Spam-Status: No, score=-104.133 tagged_above=-999 required=5 tests=[AWL=-1.534, 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 DkzqTG3kUF17 for ; Mon, 21 Nov 2011 06:13:10 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0B88C21F8B40 for ; Mon, 21 Nov 2011 06:13:08 -0800 (PST)
Received: (qmail invoked by alias); 21 Nov 2011 14:13:07 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp070) with SMTP; 21 Nov 2011 15:13:07 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18i/GwELvkinPWmo5UIpa+ydCdVgEbv1EUwzB5CRt 1Iv6BFw5yc/GB7
Message-ID: <4ECA5C66.1040305@gmx.de>
Date: Mon, 21 Nov 2011 15:12:54 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: IETF Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: draft-pbryan-zyp-json-pointer@tools.ietf.org
Subject: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 14:13:14 -0000

Hi there.

In 
 
we have:

    A JSON Pointer is a sequence of zero or more reference tokens, each
    prefixed by a "/" (%x2F) character.  Each reference token is a
    sequence of unreserved and/or percent-encoded characters, per
    [RFC3986].

    json-pointer = *( "/" reference-token )
    reference-token = *( unreserved / pct-encoded )

    Characters in reference tokens that are not unreserved SHOULD be
    percent-encoded, per [RFC3986], and MUST be so encoded as "%2F" if
    the character is "/" to avoid being interpreted as a reference token
    prefix.

    It is an error condition if a JSON Pointer does not conform to this
    syntax.

This doesn't seem to consider the case where the reference token 
contains non-ASCII characters, which can happen with JSON.

There seem to be to obvious ways to address this:

(1) Allow non-ASCII characters in the pointer (which would make the 
pointers be more IRI-like, and I think that's consistent with XPath), or

(2) Require UTF-8 encoding.

I believe (1) makes more sense here.

Best regards, Julian

From paulej@packetizer.com  Mon Nov 21 07:49:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA3211E80B6 for ; Mon, 21 Nov 2011 07:49:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Level: 
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG1yIERGqSkU for ; Mon, 21 Nov 2011 07:49:20 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE0611E80B0 for ; Mon, 21 Nov 2011 07:49:20 -0800 (PST)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pALFnCT9027400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Nov 2011 10:49:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321890555; bh=X25JpWQiW7Pzd/ID4H+IUPGFMIFfMB/RZ2UMkFuArZ4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=gUi0oZ8ldiv8PL46J0hCXGAMvz4PDRKkOiJY4ADMMpGjwYZnGGBDK63ed2ZzJZ+Ie IqmJZU4VlyyECMRgF3N4o28LUdRJ/zx8IqLOD0GMQLEGvXTO+hE64cLJkJoAxoYA9e IGBp4ZqX5VahfUp0ADiR3SbFe8jmsbHNor+3vh6A=
From: "Paul E. Jones" 
To: "'Eran Hammer-Lahav'" , 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Mon, 21 Nov 2011 10:49:10 -0500
Message-ID: <06b001cca865$1d9ccb80$58d66280$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B1_01CCA83B.34C9D0C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnyslL87CjA=
Content-Language: en-us
Cc: 'Joseph Smarr' 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 15:49:25 -0000

This is a multipart message in MIME format.

------=_NextPart_000_06B1_01CCA83B.34C9D0C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Eran,

 

Thanks for your feedback.  The editorial, structural, and behavioral items
we'll addressed (including adhering to host-meta section 4.2).

 

Let me ask about specific comments:

 

1)      You want to mandate use of JSON, which we also indicated in the
draft.  However, I would personally prefer to give both XML and JSON equal
weight and require both.

2)      You wanted to mandate HTTPS. I'm not opposed, but host-meta does not
mandate it.  Shouldn't we Webfinger requirements on what is there?

3)      Regarding "resource" extension: if I query host-meta, there may be
any number of templates.  Would we want the server to automatically expand
every template it finds?  Or would we only expand the 'lrdd' template?  (And
how many levels of recursion might be possible?)

 

Paul

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

 

This is a good start. Some feedback and nits:

 

1.       The protocol flow is incorrect and needs to be adjusted based on
the final host-meta specification (RFC 6415). Namely, WebFinger must follow
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger
providers to support the JRD format. This does not preclude using XRD (XML)
but it will ensure that every compliant WebFinger implementation provides
full JSON support which is much more likely to be adopted. This is something
we could not do in host-meta due to the late stage it was in, but this is
the right time to make the switch (without taking away any existing
functionality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each
example needs actual JRD code.

 

In addition, I would very much like to see WebFinger extend the host-meta
endpoint by defining a 'resource' query parameter. Using the example in RFC
6415 section 1.1.1 (example not properly encoded to make it easier to read):

 

> GET /.well-known/host-meta?resource=http://example.com/xy HTTP/1.1

 

   {

      "subject":"http://example.com/xy",

 

      "properties":{

        "http://spec.example.net/color":"red"

      },

 

      "links":[

        {

          "rel":"hub",

          "href":"http://example.com/hub",

        },

        {

          "rel":"hub",

          "href":"http://example.com/another/hub",

        },

        {

          "rel":"author",

          "href":"http://example.com/john",

        },

        {

          "rel":"author",

 
"template":"http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy"

        }

      ]

    }

 

The rules for this extension parameter are pretty simple:

 

1.       JSON is implied. If the server understands '?resource' it MUST
return a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.)
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making
sure the response is both JRD and has the requested subject (this will
ensure full compatibility with any other host-meta endpoint).

 

I would like to see such endpoint extension required for WebFinger so that
clients can make a single call and get the full WebFinger result in JSON.
This would significantly improve adoption and usability, and adds very
little work to providers.

 

EHL

 

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

 

Folks,

 

We just submitted this:

http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

 

The tools for Webfinger are now defined, but the procedures need to be
clearer with respect to what most of us understand as "webfinger".  This is
just a first stab at making that happen and we hope to progress this to
publish an RFC in the application area.

 

We welcome any comments you have on the topic, either privately or publicly.

 

Paul

 


------=_NextPart_000_06B1_01CCA83B.34C9D0C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Eran,
 
Thanks for your =
feedback.  The editorial, structural, and behavioral items =
we’ll addressed (including adhering to host-meta section =
4.2).
 
Let me ask about =
specific comments:
 
1)      =
You want to =
mandate use of JSON, which we also indicated in the draft.  =
However, I would personally prefer to give both XML and JSON equal =
weight and require both.
2)      =
You wanted =
to mandate HTTPS. I’m not opposed, but host-meta does not mandate =
it.  Shouldn’t we Webfinger requirements on what is =
there?
3)      =
Regarding =
“resource” extension: if I query host-meta, there may be any =
number of templates.  Would we want the server to automatically =
expand every template it finds?  Or would we only expand the =
‘lrdd’ template?  (And how many levels of recursion =
might be possible?)
 
Paul
 
From:=
 =
Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: =
Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; =
apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; =
Blaine Cook
Subject: RE: [apps-discuss] =
Webfinger
 
This is a good start. Some feedback and =
nits:
 
1.       =
The =
protocol flow is incorrect and needs to be adjusted based on the final =
host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.
2.       =
WebFinger =
should focus exclusively on JSON and mandate WebFinger providers to =
support the JRD format. This does not preclude using XRD (XML) but it =
will ensure that every compliant WebFinger implementation provides full =
JSON support which is much more likely to be adopted. This is something =
we could not do in host-meta due to the late stage it was in, but this =
is the right time to make the switch (without taking away any existing =
functionality).
3.       =
Are there =
reasons not to mandate HTTPS?
4.       =
Section 3 =
should be a sub-section of the introduction and each example needs =
actual JRD code.
 
In addition, I would =
very much like to see WebFinger extend the host-meta endpoint by =
defining a ‘resource’ query parameter. Using the example in =
RFC 6415 section 1.1.1 (example not properly encoded to make it easier =
to read):
 
> GET =
/.well-known/host-meta?resource=3Dhttp://example.com/xy =
HTTP/1.1
 
   =
{
      =
"subject":"http://example.com/xy",
 
      =
"properties":{
        =
"http://spec.example.net/color&=
quot;:"red"
      =
},
 
      =
"links":[
        =
{
        &=
nbsp; "rel":"hub",
        &=
nbsp; "href":"http://example.com/hub",
        =
},
        =
{
        &=
nbsp; "rel":"hub",
        &=
nbsp; "href":"http://example.com/another/hub",
        =
},
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "href":"http://example.com/john",<=
/o:p>
        =
},
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "template":"http=
://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"
        =
}
      =
]
    }
 
The rules for this =
extension parameter are pretty simple:
 
1.       =
JSON is =
implied. If the server understands ‘?resource’ it MUST =
return a JRD document.
2.       =
The subject =
must be set to the value of the ‘resource’ =
parameter.
3.       =
If the =
server does not support that resource (wrong domain, etc.) it must =
return an empty JRD with the right subject.
4.       =
The client =
MUST verify the server supports ‘?resource’ by making sure =
the response is both JRD and has the requested subject (this will ensure =
full compatibility with any other host-meta =
endpoint).
 
I would like to see such =
endpoint extension required for WebFinger so that clients can make a =
single call and get the full WebFinger result in JSON. This would =
significantly improve adoption and usability, and adds very little work =
to providers.
 
EHL
 
 
From:=
 =
apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] On Behalf Of Paul E. =
Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc:=
 Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] =
Webfinger
 
Folks,
 
We just =
submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinge=
r-00.txt
 
The tools for Webfinger are now defined, but the =
procedures need to be clearer with respect to what most of us understand =
as “webfinger”.  This is just a first stab at making =
that happen and we hope to progress this to publish an RFC in the =
application area.
 
We welcome =
any comments you have on the topic, either privately or =
publicly.
 
Paul
 

------=_NextPart_000_06B1_01CCA83B.34C9D0C0--


From chris@w3.org  Mon Nov 21 04:22:23 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B8821F8BD5 for ; Mon, 21 Nov 2011 04:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.91
X-Spam-Level: 
X-Spam-Status: No, score=-7.91 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_32=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8]
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 213TIX+y3p8R for ; Mon, 21 Nov 2011 04:22:23 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 5363321F8BF9 for ; Mon, 21 Nov 2011 04:22:23 -0800 (PST)
Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtpa (Exim 4.69) (envelope-from ) id 1RSSsy-0000z7-Vl; Mon, 21 Nov 2011 07:22:09 -0500
Date: Mon, 21 Nov 2011 13:22:15 +0100
From: Chris Lilley 
X-Mailer: The Bat! (v3.95.6) Home
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <210354501.20111121132215@w3.org>
To: Ned Freed 
In-Reply-To: <01O8KCG4WZZE00XBUL@mauve.mrochek.com>
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <4EC6031F.7000002@it.aoyama.ac.jp> <7534F85A589E654EB1E44E5CFDC19E3D117FCD7382@wob-email-01.agfamonotype.org> <01O8KCG4WZZE00XBUL@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 21 Nov 2011 08:03:24 -0800
Cc: "Levantovsky, Vladimir" , "apps-discuss@ietf.org" , "gadams@xfsi.com Adams" , David Singer 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Chris Lilley 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 12:22:24 -0000

(Catching upon this thread)

On Friday, November 18, 2011, 8:50:51 PM, Ned wrote:

>> Besides vendor-specific types, the only registered font type that I am aware
>> of is 'application/font-woff'. W3C WebFonts WG has submitted a registration for
>> this subtype about a year ago, and the text of the registration is available as
>> Annex B of the WOFF specification:

>> http://dev.w3.org/webfonts/WOFF/spec/#appendix-b

NF> Submitted to whom? It isn't on the IANA page so it hasn't been approved unless
NF> approval was very recent.

In accordance with the usual W3C process for media type registrations
- the registration template is an appendix in the technical specification
- at last call, it gets sent to ietf-types to start discussion
- at proposed rec (ie one the spec is fixed) W3C will ask for IESG approval. This has not happened yet; the spec is in Candidate  Recommendation phase.

NF> It's one thing if this registration is still bouncing around inside of the W3C
NF> process - that's entirely the W3C's baliwick.

Its bouncing around the early stages of both W3C and IETF/IANA processes.

NF>  But if this was submitted to the IESG for approval,

No, not yet, since that requires a stable document to reference,and changes are still possible as a result of Candidate Recommendation implementation experience.

>> ISO SC29/WG11 has prepared the draft to register application/font-sfnt but it
>> wasn't submitted yet.

It has neither been sent to ietf-types not has it been sent to IESG to request approval.

NF> FWIW, there are presently four registered font-ish types:

NF> application/font-tdpfr (RFC 3073)

Yes, Bitstream TrueDoc portable font resource (as used in Netscape 4.x). 

NF> application/vnd.font-fontforge-sfd

Right, the fontforge source file format. Hmm,so UFO format is not yet registered.

NF> application/vnd.ms-fontobject
NF> application/vnd.openxmlformats-officedocument.wordprocessingml.fontTable+xml

I was unaware of those, thanks for the pointer. of course, had all these been registered in a font/* tree then discovery would be so much easier.



-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups


From romeda@gmail.com  Mon Nov 21 09:54:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D93A11E80E1 for ; Mon, 21 Nov 2011 09:54:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.549
X-Spam-Level: 
X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 mGw8jBD-Tp4C for ; Mon, 21 Nov 2011 09:54:03 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2C5F11E80DB for ; Mon, 21 Nov 2011 09:54:03 -0800 (PST)
Received: by vcbfy13 with SMTP id fy13so3343224vcb.31 for ; Mon, 21 Nov 2011 09:54:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=w40+XmYpkFbW3yehZ11/LHUZfbs4J+MsOtSQ/JCVXWk=; b=k3L1u7yk1c00pFKhrtx+skkj+4P45LPXvROD1G1ncaDxHvM7hZBUdUP0rxmTgArFCy Fy5PI9DSaspZKiaRN4rhOp1MMajveDOd25E8lTMaK/AFsdju+z9FWPySNwJnsMMDRpM7 nlMPWq7/Hk818XDfAbid2QOaOBXU5A+ejz7sw=
Received: by 10.182.45.3 with SMTP id i3mr3192606obm.62.1321898043278; Mon, 21 Nov 2011 09:54:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.44.35 with HTTP; Mon, 21 Nov 2011 09:53:42 -0800 (PST)
In-Reply-To: <06b001cca865$1d9ccb80$58d66280$@packetizer.com>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com>
From: Blaine Cook 
Date: Mon, 21 Nov 2011 17:53:42 +0000
Message-ID: 
To: "Paul E. Jones" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Joseph Smarr , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 17:54:04 -0000

On 21 November 2011 15:49, Paul E. Jones  wrote:
> 1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 You want to mandate use of JSON, which w=
e also indicated in the
> draft.=C2=A0 However, I would personally prefer to give both XML and JSON=
 equal
> weight and require both.

Implementations of XML-based host-meta clients are significantly more
complex than JSON implementations. To completely abandon XML-based
host-meta would have been impossible, but JSON is vastly preferred. To
lower the barrier for Webfinger adoption, +1 for JSON as a strong
recommendation over XML. It's still early days, so existing
implementations shouldn't be given undue weight.

> 2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 You wanted to mandate HTTPS. I=E2=80=99m=
 not opposed, but host-meta does not
> mandate it.=C2=A0 Shouldn=E2=80=99t we Webfinger requirements on what is =
there?

host-meta does not necessarily have security implications. Webfinger
almost certainly does, and as such should mandate HTTPS.

b.

From simon.perreault@viagenie.ca  Mon Nov 21 10:27:42 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4DB1F0C57 for ; Mon, 21 Nov 2011 10:27:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCsbc-xLpM1v for ; Mon, 21 Nov 2011 10:27:38 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id D245421F8564 for ; Mon, 21 Nov 2011 10:27:37 -0800 (PST)
Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d77:a020:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1E7B920E64; Mon, 21 Nov 2011 13:27:07 -0500 (EST)
Message-ID: <4ECA97FA.3040309@viagenie.ca>
Date: Mon, 21 Nov 2011 13:27:06 -0500
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>
In-Reply-To: <032101cc9288$e3a06910$aae13b30$@packetizer.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Joseph Smarr , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 18:27:43 -0000

Paul E. Jones wrote, on 10/24/2011 04:09 PM:
> We just submitted this:
> 
> http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

One general comment I have is that there seems to be a lot of overlap with
features already in vCard or that could be defined as extensions to vCard. Let's
take for example one example from the draft:

     
     
       acct:bob@example.com
       
       
       
       
       
       
     

All of the  elements, except the one pointing to the vCard itself, could
be contained inside the vCard.

Did you look at vCard and find it inappropriate for your needs?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From romeda@gmail.com  Mon Nov 21 10:57:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB82F21F8B07 for ; Mon, 21 Nov 2011 10:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.561
X-Spam-Level: 
X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 lo7voP+E-t31 for ; Mon, 21 Nov 2011 10:57:35 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D55ED21F8B06 for ; Mon, 21 Nov 2011 10:57:34 -0800 (PST)
Received: by vcbfy13 with SMTP id fy13so3425181vcb.31 for ; Mon, 21 Nov 2011 10:57:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Dv0DzonX5xOlbOsVTuUgI6jKUPgIQ9vowEAv9C5VBU8=; b=KWOYyus63OTNgTtmhMzqgr+r7CKfgZBfekZxLG2AR59gEEsVpHbseXQnoG7o+yrpk0 MqkRugNC/Fk6sq4qXAw601biafacS5qGtCWYTwlxXxYWA6SI6mwG7ZY+SeK08w+WBXck Ayp7vE2UhvqMrZnM3db+LAu26iChihJ5kOwRM=
Received: by 10.182.227.41 with SMTP id rx9mr3311277obc.12.1321901853049; Mon, 21 Nov 2011 10:57:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.44.35 with HTTP; Mon, 21 Nov 2011 10:57:12 -0800 (PST)
In-Reply-To: <4ECA97FA.3040309@viagenie.ca>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <4ECA97FA.3040309@viagenie.ca>
From: Blaine Cook 
Date: Mon, 21 Nov 2011 18:57:12 +0000
Message-ID: 
To: Simon Perreault 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Joseph Smarr , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 18:57:40 -0000

+1 - Ideally, the webfinger profile would link to a VCard; however,
there are many links within a webfinger profile that might be
inappropriate for vcards, and as such it seemed prudent to not confuse
the two.

b.

On 21 November 2011 18:27, Simon Perreault  wr=
ote:
> Paul E. Jones wrote, on 10/24/2011 04:09 PM:
>> We just submitted this:
>>
>> http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt
>
> One general comment I have is that there seems to be a lot of overlap wit=
h
> features already in vCard or that could be defined as extensions to vCard=
. Let's
> take for example one example from the draft:
>
> =C2=A0 =C2=A0 
> =C2=A0 =C2=A0 
> =C2=A0 =C2=A0 =C2=A0 acct:bob@example.com
> =C2=A0 =C2=A0 =C2=A0  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 href=3D"http://example.com/bob/=
images/avatar.jpg"/>
> =C2=A0 =C2=A0 =C2=A0  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 href=3D"http://example.net/bob/=
blog/"/>
> =C2=A0 =C2=A0 =C2=A0  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 href=3D"http://example.com/bob/=
vcard.vcf"/>
> =C2=A0 =C2=A0 =C2=A0  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 href=3D"https://openid.example.=
com/bob"/>
> =C2=A0 =C2=A0 =C2=A0 
> =C2=A0 =C2=A0 =C2=A0  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 href=3D"http://example.com/bob/=
profile/"/>
> =C2=A0 =C2=A0 
>
> All of the  elements, except the one pointing to the vCard itself, =
could
> be contained inside the vCard.
>
> Did you look at vCard and find it inappropriate for your needs?
>
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.via=
genie.ca
> STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> htt=
p://numb.viagenie.ca
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From paulej@packetizer.com  Mon Nov 21 11:13:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0F221F8B6F for ; Mon, 21 Nov 2011 11:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level: 
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENZn4zt+rNaH for ; Mon, 21 Nov 2011 11:13:36 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EF12221F8B67 for ; Mon, 21 Nov 2011 11:13:35 -0800 (PST)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pALJDSFf031051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Nov 2011 14:13:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321902809; bh=UJBexzKjroGjaDUmyX5Jeq2Z/NEwnPGLzFXtNgFaxDM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QPKjLZLts26nW32NOMlxQ/0vLn9MCmssPVwyXS8kFzsafRyoYDReYKgnRvZVtgnzq DAyjw1Rd3KbWS7g0oojgJ80QOJzO8+dEmsE5Gw+JBwzIXHD9mGUCffX6+euNEZAA3r bb2QPw9YD3GMoPlGOqOAwsmxHjlmQQXAn3elF+Bo=
From: "Paul E. Jones" 
To: "'Simon Perreault'" 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <4ECA97FA.3040309@viagenie.ca>
In-Reply-To: <4ECA97FA.3040309@viagenie.ca>
Date: Mon, 21 Nov 2011 14:13:25 -0500
Message-ID: <076301cca881$a599cf30$f0cd6d90$@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: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJR8CDWlL7zQnA=
Content-Language: en-us
Cc: 'Joseph Smarr' , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 19:13:41 -0000

Simon,

There is certainly some overlap with the kinds of information Webfinger
provides and vcard provides.  However, Webfinger solves a problem vcard was
not designed to solve: finding the user's information in the first place.
If I already have a vcard in hand, that's great, but I usually do not.

You can imagine a point in the future where one may not even need to have an
address book containing anything more than email (er, "acct" URIs).  The
email client, phone application, web portal, etc. could grab all of the
other information as needed via Webfinger.  I would hope vcard would be a
part of that.

As Blane mentioned separately, some data that might be provided via
Webfinger (i.e., some link relations) may not be appropriate for a vcard.
For example, my list of identity providers may not be secret, but probably
not what I'd want to publish via a vcard.

We've had some discussion on whether link relations should be defined as a
part of the Webfinger spec or separately.  It seems most people are of the
opinion that they should be defined in a separate document.  Thus, I'd
invite you to work on the vcard link relation spec. This would be added to
the registry established by RFC 5988, I believe.

Paul

> -----Original Message-----
> From: Simon Perreault [mailto:simon.perreault@viagenie.ca]
> Sent: Monday, November 21, 2011 1:27 PM
> To: Paul E. Jones
> Cc: apps-discuss@ietf.org; Joseph Smarr; Gonzalo Salgueiro
> Subject: Re: [apps-discuss] Webfinger
> 
> Paul E. Jones wrote, on 10/24/2011 04:09 PM:
> > We just submitted this:
> >
> > http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.t
> > xt
> 
> One general comment I have is that there seems to be a lot of overlap
> with features already in vCard or that could be defined as extensions to
> vCard. Let's take for example one example from the draft:
> 
>      
>      
>        acct:bob@example.com
>                      href="http://example.com/bob/images/avatar.jpg"/>
>                      href="http://example.net/bob/blog/"/>
>                      href="http://example.com/bob/vcard.vcf"/>
>                      href="https://openid.example.com/bob"/>
>        
>                      href="http://example.com/bob/profile/"/>
>      
> 
> All of the  elements, except the one pointing to the vCard itself,
> could be contained inside the vCard.
> 
> Did you look at vCard and find it inappropriate for your needs?
> 
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca


From paul.bryan@forgerock.com  Mon Nov 21 11:24:45 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC81D1F0C85 for ; Mon, 21 Nov 2011 11:24:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 J8t06R6B-Kkk for ; Mon, 21 Nov 2011 11:24:41 -0800 (PST)
Received: from eu1sys200aog103.obsmtp.com (eu1sys200aog103.obsmtp.com [207.126.144.115]) by ietfa.amsl.com (Postfix) with SMTP id 217501F0C5A for ; Mon, 21 Nov 2011 11:24:40 -0800 (PST)
Received: from mail-qw0-f44.google.com ([209.85.216.44]) (using TLSv1) by eu1sys200aob103.postini.com ([207.126.147.11]) with SMTP ID DSNKTsqlarP8yRF9IdceJ8E1wKTF5j90BwfU@postini.com; Mon, 21 Nov 2011 19:24:41 UTC
Received: by mail-qw0-f44.google.com with SMTP id b14so505265qad.10 for ; Mon, 21 Nov 2011 11:24:26 -0800 (PST)
Received: by 10.224.98.8 with SMTP id o8mr6372711qan.79.1321903466321; Mon, 21 Nov 2011 11:24:26 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id t8sm11467778qaz.4.2011.11.21.11.24.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 11:24:25 -0800 (PST)
Message-ID: <1321903463.1990.16.camel@neutron>
From: "Paul C. Bryan" 
To: IETF Apps Discuss 
Date: Mon, 21 Nov 2011 11:24:23 -0800
In-Reply-To: <4ECA5C66.1040305@gmx.de>
References: <4ECA5C66.1040305@gmx.de>
Content-Type: multipart/alternative; boundary="=-m4Un/azgSRIwS7kWOAXI"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 19:24:45 -0000

--=-m4Un/azgSRIwS7kWOAXI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

RFC 3986 prescribes encoding characters in UTF-8 and percent-encoding
non-unreserved characters. Furthermore, JSON by definition uses Unicode
for all string values (most often encoding in UTF-8). Do these not
address the issue?

Paul

On Mon, 2011-11-21 at 15:12 +0100, Julian Reschke wrote:

> Hi there.
> 
> In 
>  
> we have:
> 
>     A JSON Pointer is a sequence of zero or more reference tokens, each
>     prefixed by a "/" (%x2F) character.  Each reference token is a
>     sequence of unreserved and/or percent-encoded characters, per
>     [RFC3986].
> 
>     json-pointer = *( "/" reference-token )
>     reference-token = *( unreserved / pct-encoded )
> 
>     Characters in reference tokens that are not unreserved SHOULD be
>     percent-encoded, per [RFC3986], and MUST be so encoded as "%2F" if
>     the character is "/" to avoid being interpreted as a reference token
>     prefix.
> 
>     It is an error condition if a JSON Pointer does not conform to this
>     syntax.
> 
> This doesn't seem to consider the case where the reference token 
> contains non-ASCII characters, which can happen with JSON.
> 
> There seem to be to obvious ways to address this:
> 
> (1) Allow non-ASCII characters in the pointer (which would make the 
> pointers be more IRI-like, and I think that's consistent with XPath), or
> 
> (2) Require UTF-8 encoding.
> 
> I believe (1) makes more sense here.
> 
> Best regards, Julian
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



--=-m4Un/azgSRIwS7kWOAXI
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


RFC 3986 prescribes encoding characters in UTF-8 and percent-encoding non-unreserved characters. Furthermore, JSON by definition uses Unicode for all string values (most often encoding in UTF-8). Do these not address the issue?



Paul



On Mon, 2011-11-21 at 15:12 +0100, Julian Reschke wrote:



Hi there.

In 
<https://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-02#section-3> 
we have:

    A JSON Pointer is a sequence of zero or more reference tokens, each
    prefixed by a "/" (%x2F) character.  Each reference token is a
    sequence of unreserved and/or percent-encoded characters, per
    [RFC3986].

    json-pointer = *( "/" reference-token )
    reference-token = *( unreserved / pct-encoded )

    Characters in reference tokens that are not unreserved SHOULD be
    percent-encoded, per [RFC3986], and MUST be so encoded as "%2F" if
    the character is "/" to avoid being interpreted as a reference token
    prefix.

    It is an error condition if a JSON Pointer does not conform to this
    syntax.

This doesn't seem to consider the case where the reference token 
contains non-ASCII characters, which can happen with JSON.

There seem to be to obvious ways to address this:

(1) Allow non-ASCII characters in the pointer (which would make the 
pointers be more IRI-like, and I think that's consistent with XPath), or

(2) Require UTF-8 encoding.

I believe (1) makes more sense here.

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









--=-m4Un/azgSRIwS7kWOAXI--


From derhoermi@gmx.net  Mon Nov 21 11:37:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CA11F0C62 for ; Mon, 21 Nov 2011 11:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.92
X-Spam-Level: 
X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=-0.321,  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 PTw9iCJj8wNP for ; Mon, 21 Nov 2011 11:37:02 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id F2CE31F0C79 for ; Mon, 21 Nov 2011 11:37:01 -0800 (PST)
Received: (qmail invoked by alias); 21 Nov 2011 19:36:59 -0000
Received: from dslb-094-222-145-118.pools.arcor-ip.net (EHLO HIVE) [94.222.145.118] by mail.gmx.net (mp061) with SMTP; 21 Nov 2011 20:36:59 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19fXHdPNgRf5OAR1d1OmclBLqpAECtyGDINOohNrd 3cn9jITJEJK4Lv
From: Bjoern Hoehrmann 
To: "Paul C. Bryan" 
Date: Mon, 21 Nov 2011 20:37:05 +0100
Message-ID: <2n9lc79c8or4de9dpvi4s1s8vd186mosj8@hive.bjoern.hoehrmann.de>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron>
In-Reply-To: <1321903463.1990.16.camel@neutron>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 19:37:07 -0000

* Paul C. Bryan wrote:
>RFC 3986 prescribes encoding characters in UTF-8 and percent-encoding
>non-unreserved characters. Furthermore, JSON by definition uses Unicode
>for all string values (most often encoding in UTF-8). Do these not
>address the issue?

RFC 3986 only defines the character encoding for the host component, in
other components it just defines that %C3 refers to the octet 0xC3. So,
if you want that %C3%B6 refers to an "ö", then you have to define that.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From julian.reschke@gmx.de  Mon Nov 21 11:44:05 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D37E1F0C79 for ; Mon, 21 Nov 2011 11:44:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.426
X-Spam-Level: 
X-Spam-Status: No, score=-104.426 tagged_above=-999 required=5 tests=[AWL=-1.827, 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 dfDLxNwKvjhK for ; Mon, 21 Nov 2011 11:44:04 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 49C6D1F0C62 for ; Mon, 21 Nov 2011 11:44:04 -0800 (PST)
Received: (qmail invoked by alias); 21 Nov 2011 19:44:02 -0000
Received: from p5DCC9581.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.149.129] by mail.gmx.net (mp070) with SMTP; 21 Nov 2011 20:44:02 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18hFDI6SdMhNKcbYQSzZujNqFmO3uqdj0q9eFBXSN voF3V1xlNc3qnp
Message-ID: <4ECAA9FE.6080802@gmx.de>
Date: Mon, 21 Nov 2011 20:43:58 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul C. Bryan" 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron>
In-Reply-To: <1321903463.1990.16.camel@neutron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 19:44:05 -0000

On 2011-11-21 20:24, Paul C. Bryan wrote:
> RFC 3986 prescribes encoding characters in UTF-8 and percent-encoding
> non-unreserved characters. Furthermore, JSON by definition uses Unicode
> for all string values (most often encoding in UTF-8). Do these not
> address the issue?
> ...

Not really -- RFC 3986 doesn't really require it; it just says it should 
be the default for new schemes.

So again, do you want the ability to use non-ASCII characters in JSON 
pointers without escaping? (I think that would be the right approach.)

Best regards, Julian

From julian.reschke@gmx.de  Mon Nov 21 11:54:43 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D976511E80DB for ; Mon, 21 Nov 2011 11:54:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.103
X-Spam-Level: 
X-Spam-Status: No, score=-104.103 tagged_above=-999 required=5 tests=[AWL=-2.104, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 8BR561kwJZyU for ; Mon, 21 Nov 2011 11:54:43 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1AD9511E8096 for ; Mon, 21 Nov 2011 11:54:42 -0800 (PST)
Received: (qmail invoked by alias); 21 Nov 2011 19:54:41 -0000
Received: from p5DCC9581.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.149.129] by mail.gmx.net (mp006) with SMTP; 21 Nov 2011 20:54:41 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/7kQEaFNv77c8DJa+eivVYvtnk9ggmQuaqyhAHC+ 7txhpJUpc+8brH
Message-ID: <4ECAAC7C.1020005@gmx.de>
Date: Mon, 21 Nov 2011 20:54:36 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Chris Lilley 
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <4EC6031F.7000002@it.aoyama.ac.jp> <7534F85A589E654EB1E44E5CFDC19E3D117FCD7382@wob-email-01.agfamonotype.org> <01O8KCG4WZZE00XBUL@mauve.mrochek.com> <210354501.20111121132215@w3.org>
In-Reply-To: <210354501.20111121132215@w3.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: David Singer , Ned Freed , "apps-discuss@ietf.org" , "Levantovsky, Vladimir" , "gadams@xfsi.com Adams" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 19:54:43 -0000

On 2011-11-21 13:22, Chris Lilley wrote:
> ...
> No, not yet, since that requires a stable document to reference,and changes are still possible as a result of Candidate Recommendation implementation experience.
> ...

Well, the (dated) CR is also stable, right?

I believe it would be better overall to register early, and then to 
update the registration later on.

Best regards, Julian

From paul.bryan@forgerock.com  Mon Nov 21 11:55:23 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B296411E80E1 for ; Mon, 21 Nov 2011 11:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.598
X-Spam-Level: 
X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=1.000,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 SVz4Mmrb5+Am for ; Mon, 21 Nov 2011 11:55:23 -0800 (PST)
Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) by ietfa.amsl.com (Postfix) with SMTP id 83CDD11E8096 for ; Mon, 21 Nov 2011 11:55:22 -0800 (PST)
Received: from mail-qw0-f54.google.com ([209.85.216.54]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKTsqslHpeB05hBOfPBH9PJ/Pqwb03/wr5@postini.com; Mon, 21 Nov 2011 19:55:22 UTC
Received: by mail-qw0-f54.google.com with SMTP id j40so641792qab.6 for ; Mon, 21 Nov 2011 11:55:00 -0800 (PST)
Received: by 10.224.27.18 with SMTP id g18mr6503634qac.59.1321905299935; Mon, 21 Nov 2011 11:54:59 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id ha3sm11569003qab.2.2011.11.21.11.54.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 11:54:59 -0800 (PST)
Message-ID: <1321905297.1990.20.camel@neutron>
From: "Paul C. Bryan" 
To: IETF Apps Discuss 
Date: Mon, 21 Nov 2011 11:54:57 -0800
In-Reply-To: <2n9lc79c8or4de9dpvi4s1s8vd186mosj8@hive.bjoern.hoehrmann.de>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <2n9lc79c8or4de9dpvi4s1s8vd186mosj8@hive.bjoern.hoehrmann.de>
Content-Type: multipart/alternative; boundary="=-+fcb1LLCL0Qr3DlpKTMm"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 19:55:23 -0000

--=-+fcb1LLCL0Qr3DlpKTMm
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

I'm interpreting section 2.5 of RFC 3896:


> When a new URI scheme defines a component that represents textual data
> consisting of characters from the Universal Character Set [UCS], the
> data should first be encoded as octets according to the UTF-8
> character encoding [STD63]; then only those octets that do not
> correspond to characters in the unreserved set should be
> percent-encoded.  For example, the character A would be represented as
> "A", the character LATIN CAPITAL LETTER A WITH GRAVE would be
> represented as "%C3%80", and the character KATAKANA LETTER A would be
> represented as "%E3%82%A2".


Is this not applicable?

Paul

On Mon, 2011-11-21 at 20:37 +0100, Bjoern Hoehrmann wrote:

> * Paul C. Bryan wrote:
> >RFC 3986 prescribes encoding characters in UTF-8 and percent-encoding
> >non-unreserved characters. Furthermore, JSON by definition uses Unicode
> >for all string values (most often encoding in UTF-8). Do these not
> >address the issue?
> 
> RFC 3986 only defines the character encoding for the host component, in
> other components it just defines that %C3 refers to the octet 0xC3. So,
> if you want that %C3%B6 refers to an "ö", then you have to define that.



--=-+fcb1LLCL0Qr3DlpKTMm
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


I'm interpreting section 2.5 of RFC 3896:





    When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent-encoded.  For example, the character A would be represented as "A", the character LATIN CAPITAL LETTER A WITH GRAVE would be represented as "%C3%80", and the character KATAKANA LETTER A would be represented as "%E3%82%A2".





Is this not applicable?



Paul



On Mon, 2011-11-21 at 20:37 +0100, Bjoern Hoehrmann wrote:



* Paul C. Bryan wrote:
>RFC 3986 prescribes encoding characters in UTF-8 and percent-encoding
>non-unreserved characters. Furthermore, JSON by definition uses Unicode
>for all string values (most often encoding in UTF-8). Do these not
>address the issue?

RFC 3986 only defines the character encoding for the host component, in
other components it just defines that %C3 refers to the octet 0xC3. So,
if you want that %C3%B6 refers to an "ö", then you have to define that.









--=-+fcb1LLCL0Qr3DlpKTMm--


From paul.bryan@forgerock.com  Mon Nov 21 12:00:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AD811E80EE for ; Mon, 21 Nov 2011 12:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.689
X-Spam-Level: 
X-Spam-Status: No, score=-6.689 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, 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 PoEFK8B5ZCyF for ; Mon, 21 Nov 2011 12:00:03 -0800 (PST)
Received: from eu1sys200aog101.obsmtp.com (eu1sys200aog101.obsmtp.com [207.126.144.111]) by ietfa.amsl.com (Postfix) with SMTP id 1217A1F0C3C for ; Mon, 21 Nov 2011 12:00:02 -0800 (PST)
Received: from mail-qw0-f46.google.com ([209.85.216.46]) (using TLSv1) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKTsqtwTYy5wFNrUmoCYjIiJdBCKlg+wAr@postini.com; Mon, 21 Nov 2011 20:00:03 UTC
Received: by mail-qw0-f46.google.com with SMTP id c14so539652qad.19 for ; Mon, 21 Nov 2011 12:00:01 -0800 (PST)
Received: by 10.224.27.11 with SMTP id g11mr6590096qac.51.1321905601781; Mon, 21 Nov 2011 12:00:01 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id ho10sm11572251qab.11.2011.11.21.12.00.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 12:00:00 -0800 (PST)
Message-ID: <1321905599.1990.23.camel@neutron>
From: "Paul C. Bryan" 
To: IETF Apps Discuss 
Date: Mon, 21 Nov 2011 11:59:59 -0800
In-Reply-To: <4ECAA9FE.6080802@gmx.de>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de>
Content-Type: multipart/alternative; boundary="=-YCROgOGwkXckC7iGeRw0"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 20:00:04 -0000

--=-YCROgOGwkXckC7iGeRw0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Mon, 2011-11-21 at 20:43 +0100, Julian Reschke wrote:


> Not really -- RFC 3986 doesn't really require it; it just says it should 
> be the default for new schemes.
> 
> So again, do you want the ability to use non-ASCII characters in JSON 
> pointers without escaping? (I think that would be the right approach.)


Presuming section 2.5 is not applicable (or cannot be made applicable by
reference), then we would need to explicitly specify an encoding. Since
JSON is Unicode by definition, following the recommendation set forth in
section 2.5 to encode as UTF-8 and percent-encode each non-unreserved
octet would seem most appropriate.

Paul

--=-YCROgOGwkXckC7iGeRw0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


On Mon, 2011-11-21 at 20:43 +0100, Julian Reschke wrote:






Not really -- RFC 3986 doesn't really require it; it just says it should 
be the default for new schemes.

So again, do you want the ability to use non-ASCII characters in JSON 
pointers without escaping? (I think that would be the right approach.)






Presuming section 2.5 is not applicable (or cannot be made applicable by reference), then we would need to explicitly specify an encoding. Since JSON is Unicode by definition, following the recommendation set forth in section 2.5 to encode as UTF-8 and percent-encode each non-unreserved octet would seem most appropriate.



Paul



--=-YCROgOGwkXckC7iGeRw0--


From julian.reschke@gmx.de  Mon Nov 21 12:02:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B3D1F0C62 for ; Mon, 21 Nov 2011 12:02:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.378
X-Spam-Level: 
X-Spam-Status: No, score=-105.378 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, GB_I_LETTER=-2, 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 GeE6Y9A6XTxh for ; Mon, 21 Nov 2011 12:02:07 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C3FE11F0C3C for ; Mon, 21 Nov 2011 12:02:06 -0800 (PST)
Received: (qmail invoked by alias); 21 Nov 2011 20:02:04 -0000
Received: from p5DCC9581.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.149.129] by mail.gmx.net (mp011) with SMTP; 21 Nov 2011 21:02:04 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+RF688S2iRR4hxsDgF5KX/hWEzh7EWxXpYeIN9sm NEcHKnDY+khNNX
Message-ID: <4ECAAE38.8050100@gmx.de>
Date: Mon, 21 Nov 2011 21:02:00 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul C. Bryan" 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <2n9lc79c8or4de9dpvi4s1s8vd186mosj8@hive.bjoern.hoehrmann.de> <1321905297.1990.20.camel@neutron>
In-Reply-To: <1321905297.1990.20.camel@neutron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 20:02:07 -0000

On 2011-11-21 20:54, Paul C. Bryan wrote:
> I'm interpreting section 2.5 of RFC 3896:
>
>> When a new URI scheme defines a component that represents textual data
>> consisting of characters from the Universal Character Set [UCS], the
>> data should first be encoded as octets according to the UTF-8
>> character encoding [STD63]; then only those octets that do not
>> correspond to characters in the unreserved set should be
>> percent-encoded. For example, the character A would be represented as
>> "A", the character LATIN CAPITAL LETTER A WITH GRAVE would be
>> represented as "%C3%80", and the character KATAKANA LETTER A would be
>> represented as "%E3%82%A2".
>
> Is this not applicable?

No.

For starters, we are not defining a URI scheme at all.

We're just re-using percent-encoding, and that is about mapping octets 
to characters. We still need to state what the octets are.

Best regards, Julian

From julian.reschke@gmx.de  Mon Nov 21 12:06:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B451F0C84 for ; Mon, 21 Nov 2011 12:06:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.369
X-Spam-Level: 
X-Spam-Status: No, score=-104.369 tagged_above=-999 required=5 tests=[AWL=-1.770, 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 VY3zb29yeYRo for ; Mon, 21 Nov 2011 12:06:25 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 306781F0C71 for ; Mon, 21 Nov 2011 12:06:23 -0800 (PST)
Received: (qmail invoked by alias); 21 Nov 2011 20:06:22 -0000
Received: from p5DCC9581.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.149.129] by mail.gmx.net (mp038) with SMTP; 21 Nov 2011 21:06:22 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19Jll5atZZJxh3r4txgET+l37tNRRC97LxwS5yv0W JIe6632roHlWmw
Message-ID: <4ECAAF39.8000702@gmx.de>
Date: Mon, 21 Nov 2011 21:06:17 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul C. Bryan" 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron>
In-Reply-To: <1321905599.1990.23.camel@neutron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 20:06:25 -0000

On 2011-11-21 20:59, Paul C. Bryan wrote:
> On Mon, 2011-11-21 at 20:43 +0100, Julian Reschke wrote:
>
>> Not really -- RFC 3986 doesn't really require it; it just says it should
>> be the default for new schemes.
>>
>> So again, do you want the ability to use non-ASCII characters in JSON
>> pointers without escaping? (I think that would be the right approach.)
>
> Presuming section 2.5 is not applicable (or cannot be made applicable by
> reference), then we would need to explicitly specify an encoding. Since
> JSON is Unicode by definition, following the recommendation set forth in
> section 2.5 to encode as UTF-8 and percent-encode each non-unreserved
> octet would seem most appropriate.
>
> Paul
> ...

Yes, that would work.

However, why encode those characters in the first place? Where does the 
requirement that the pointer needs to be all-ASCII come from?

Best regards, Julian

From derhoermi@gmx.net  Mon Nov 21 12:09:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED86F21F87FA for ; Mon, 21 Nov 2011 12:09:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.895
X-Spam-Level: 
X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[AWL=0.704,  BAYES_00=-2.599, GB_I_LETTER=-2]
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 khkNK013XwId for ; Mon, 21 Nov 2011 12:09:14 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 966D21F0C98 for ; Mon, 21 Nov 2011 12:09:13 -0800 (PST)
Received: (qmail invoked by alias); 21 Nov 2011 20:09:12 -0000
Received: from dslb-094-222-145-118.pools.arcor-ip.net (EHLO HIVE) [94.222.145.118] by mail.gmx.net (mp006) with SMTP; 21 Nov 2011 21:09:12 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/IfV415+bIGUTiSkw2iCjU30xcCQTJy65l8L9ujE 6enSanwQQpRI9X
From: Bjoern Hoehrmann 
To: "Paul C. Bryan" 
Date: Mon, 21 Nov 2011 21:09:18 +0100
Message-ID: 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <2n9lc79c8or4de9dpvi4s1s8vd186mosj8@hive.bjoern.hoehrmann.de> <1321905297.1990.20.camel@neutron>
In-Reply-To: <1321905297.1990.20.camel@neutron>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 20:09:19 -0000

* Paul C. Bryan wrote:
>I'm interpreting section 2.5 of RFC 3896:
>> When a new URI scheme defines a component that represents textual data
>> consisting of characters from the Universal Character Set [UCS], the
>> data should first be encoded as octets according to the UTF-8
>> character encoding [STD63]; then only those octets that do not
>> correspond to characters in the unreserved set should be
>> percent-encoded.  For example, the character A would be represented as
>> "A", the character LATIN CAPITAL LETTER A WITH GRAVE would be
>> represented as "%C3%80", and the character KATAKANA LETTER A would be
>> represented as "%E3%82%A2".
>
>Is this not applicable?

If I recommended "When writing a new crime novel, reveal the perpetrator
towards the end" then the author would still have to write the part, and
the reader would still have to read through the novel to find out where
the perpetrator is revealed, since the author might not be following the
recommendation. Besides, the draft does not define a new scheme. This is
just a matter of using the right incantation, but I don't know why, say,
"/Björn" isn't allowed, so I can't make a good suggestion at the moment.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From paul.bryan@forgerock.com  Mon Nov 21 12:09:55 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE9721F8A4E for ; Mon, 21 Nov 2011 12:09:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.682
X-Spam-Level: 
X-Spam-Status: No, score=-6.682 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, 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 RIKe1YPuOu3j for ; Mon, 21 Nov 2011 12:09:55 -0800 (PST)
Received: from eu1sys200aog111.obsmtp.com (eu1sys200aog111.obsmtp.com [207.126.144.131]) by ietfa.amsl.com (Postfix) with SMTP id 5757C21F89BA for ; Mon, 21 Nov 2011 12:09:54 -0800 (PST)
Received: from mail-gy0-f175.google.com ([209.85.160.175]) (using TLSv1) by eu1sys200aob111.postini.com ([207.126.147.11]) with SMTP ID DSNKTsqwEbw4crlKfmRynLlD9czczeuCSUmN@postini.com; Mon, 21 Nov 2011 20:09:54 UTC
Received: by ghy10 with SMTP id 10so3180614ghy.6 for ; Mon, 21 Nov 2011 12:09:52 -0800 (PST)
Received: by 10.42.156.9 with SMTP id x9mr14887059icw.42.1321906192541; Mon, 21 Nov 2011 12:09:52 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id dd36sm50104470ibb.7.2011.11.21.12.09.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 12:09:51 -0800 (PST)
Message-ID: <1321906189.1990.26.camel@neutron>
From: "Paul C. Bryan" 
To: IETF Apps Discuss 
Date: Mon, 21 Nov 2011 12:09:49 -0800
In-Reply-To: <4ECAAF39.8000702@gmx.de>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de>
Content-Type: multipart/alternative; boundary="=-ib3CyF6vNPll2VuP0bza"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 20:09:56 -0000

--=-ib3CyF6vNPll2VuP0bza
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

The intent is to allow a JSON Pointer to be expressed as a JSON string
value as well as a URI fragment identifier. The latter is the most
significant driver for URI percent-encoding.

Paul

On Mon, 2011-11-21 at 21:06 +0100, Julian Reschke wrote:

> On 2011-11-21 20:59, Paul C. Bryan wrote:
> > On Mon, 2011-11-21 at 20:43 +0100, Julian Reschke wrote:
> >
> >> Not really -- RFC 3986 doesn't really require it; it just says it should
> >> be the default for new schemes.
> >>
> >> So again, do you want the ability to use non-ASCII characters in JSON
> >> pointers without escaping? (I think that would be the right approach.)
> >
> > Presuming section 2.5 is not applicable (or cannot be made applicable by
> > reference), then we would need to explicitly specify an encoding. Since
> > JSON is Unicode by definition, following the recommendation set forth in
> > section 2.5 to encode as UTF-8 and percent-encode each non-unreserved
> > octet would seem most appropriate.
> >
> > Paul
> > ...
> 
> Yes, that would work.
> 
> However, why encode those characters in the first place? Where does the 
> requirement that the pointer needs to be all-ASCII come from?
> 
> Best regards, Julian



--=-ib3CyF6vNPll2VuP0bza
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


The intent is to allow a JSON Pointer to be expressed as a JSON string value as well as a URI fragment identifier. The latter is the most significant driver for URI percent-encoding.



Paul



On Mon, 2011-11-21 at 21:06 +0100, Julian Reschke wrote:



On 2011-11-21 20:59, Paul C. Bryan wrote:
> On Mon, 2011-11-21 at 20:43 +0100, Julian Reschke wrote:
>
>> Not really -- RFC 3986 doesn't really require it; it just says it should
>> be the default for new schemes.
>>
>> So again, do you want the ability to use non-ASCII characters in JSON
>> pointers without escaping? (I think that would be the right approach.)
>
> Presuming section 2.5 is not applicable (or cannot be made applicable by
> reference), then we would need to explicitly specify an encoding. Since
> JSON is Unicode by definition, following the recommendation set forth in
> section 2.5 to encode as UTF-8 and percent-encode each non-unreserved
> octet would seem most appropriate.
>
> Paul
> ...

Yes, that would work.

However, why encode those characters in the first place? Where does the 
requirement that the pointer needs to be all-ASCII come from?

Best regards, Julian









--=-ib3CyF6vNPll2VuP0bza--


From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Mon Nov 21 12:11:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F5B1F0C6C for ; Mon, 21 Nov 2011 12:11:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.914
X-Spam-Level: 
X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 K+1a8D8KFkDg for ; Mon, 21 Nov 2011 12:11:11 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE9E21F8997 for ; Mon, 21 Nov 2011 12:10:44 -0800 (PST)
Received: by wwe5 with SMTP id 5so8555115wwe.13 for ; Mon, 21 Nov 2011 12:10:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5zz6SxORoq2ovvHVrr0vcGWFI8ccyC3Ab5b5ShJ0ACE=; b=ksebIWIBklkcCeHS9w/ANDo/IqJ52CHfeWphZRap1QKxWoPaZxIYkvh3YEVeA5UnMT JWehVTJm89RnkU3nSdWa81LU4Egz0loAE8rD53uQ5wwVuC4Q3dsdsLNAhalHEsGIgAxZ TYS3Ncqn+6bQOby/QiNuTNONpfhQ6LGOEa5mU=
Received: by 10.216.132.82 with SMTP id n60mr2298846wei.60.1321906243677; Mon, 21 Nov 2011 12:10:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.184.147 with HTTP; Mon, 21 Nov 2011 12:10:02 -0800 (PST)
In-Reply-To: <4ECAAE38.8050100@gmx.de>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <2n9lc79c8or4de9dpvi4s1s8vd186mosj8@hive.bjoern.hoehrmann.de> <1321905297.1990.20.camel@neutron> <4ECAAE38.8050100@gmx.de>
From: Frank Ellermann 
Date: Mon, 21 Nov 2011 21:10:02 +0100
Message-ID: 
To: Julian Reschke 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 20:11:11 -0000

On 21 November 2011 21:02, Julian Reschke wrote:

> We're just re-using percent-encoding, and that is about mapping octets to
> characters. We still need to state what the octets are.

Maybe copy and paste the simple RFC 3987 idea, that gives you UTF-8 (outside
of DNS hostnames in IRIs).  Unless you want or need "raw" octets for other
purposes in this draft, but so far I think you don't.

-Frank

From ned.freed@mrochek.com  Mon Nov 21 12:12:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26E711E80EA for ; Mon, 21 Nov 2011 12:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.254
X-Spam-Level: 
X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_93=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 yk11mkDx7w8e for ; Mon, 21 Nov 2011 12:12:26 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBA011E80E7 for ; Mon, 21 Nov 2011 12:12:26 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8OJSKZBHS00YSKD@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 21 Nov 2011 12:12:18 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8M882P1K000RCTX@mauve.mrochek.com>; Mon, 21 Nov 2011 12:12:13 -0800 (PST)
Message-id: <01O8OJSHV7B000RCTX@mauve.mrochek.com>
Date: Mon, 21 Nov 2011 12:09:17 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 21 Nov 2011 20:54:36 +0100" <4ECAAC7C.1020005@gmx.de>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <4EC6031F.7000002@it.aoyama.ac.jp> <7534F85A589E654EB1E44E5CFDC19E3D117FCD7382@wob-email-01.agfamonotype.org> <01O8KCG4WZZE00XBUL@mauve.mrochek.com> <210354501.20111121132215@w3.org> <4ECAAC7C.1020005@gmx.de>
To: Julian Reschke 
Cc: Ned Freed , "apps-discuss@ietf.org" , "gadams@xfsi.com Adams" , Chris Lilley , "Levantovsky, Vladimir" , David Singer 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 20:12:27 -0000

> On 2011-11-21 13:22, Chris Lilley wrote:
> > ...
> > No, not yet, since that requires a stable document to reference,and changes are still possible as a result of Candidate Recommendation implementation experience.
> > ...

> Well, the (dated) CR is also stable, right?

> I believe it would be better overall to register early, and then to
> update the registration later on.

+1

And there is no need to change any rules to allow this. The decision of when to
register a type is entirely up to the standards body doing the the registering.

The word "stable" appears nowhere in RFC 4288.

				Ned

From julian.reschke@gmx.de  Mon Nov 21 12:12:50 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9321F8564 for ; Mon, 21 Nov 2011 12:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.348
X-Spam-Level: 
X-Spam-Status: No, score=-104.348 tagged_above=-999 required=5 tests=[AWL=-1.749, 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 AM1ZKdt82sIm for ; Mon, 21 Nov 2011 12:12:49 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5E39911E80E7 for ; Mon, 21 Nov 2011 12:12:49 -0800 (PST)
Received: (qmail invoked by alias); 21 Nov 2011 20:12:48 -0000
Received: from p5DCC9581.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.149.129] by mail.gmx.net (mp072) with SMTP; 21 Nov 2011 21:12:48 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/gS3Mqnx/ggwh13qivVhzIBso15MnF2XwG4vyEcF ndJFz79Ltzs+7Z
Message-ID: <4ECAB0BC.0@gmx.de>
Date: Mon, 21 Nov 2011 21:12:44 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul C. Bryan" 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron>
In-Reply-To: <1321906189.1990.26.camel@neutron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 20:12:50 -0000

On 2011-11-21 21:09, Paul C. Bryan wrote:
> The intent is to allow a JSON Pointer to be expressed as a JSON string
> value as well as a URI fragment identifier. The latter is the most
> significant driver for URI percent-encoding.
> ...

Well, you could use it as fragment identifier (or otherwise URI 
component) by UTF-8-percent-escaping.

The question is whether that use case requires them to be all ASCII 
every else, such as in a JSON patch document.

Best regards, Julian

From paul.bryan@forgerock.com  Mon Nov 21 12:14:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B3E11E80E1 for ; Mon, 21 Nov 2011 12:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.675
X-Spam-Level: 
X-Spam-Status: No, score=-6.675 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, 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 1jLBD2pK-dKk for ; Mon, 21 Nov 2011 12:14:25 -0800 (PST)
Received: from eu1sys200aog103.obsmtp.com (eu1sys200aog103.obsmtp.com [207.126.144.115]) by ietfa.amsl.com (Postfix) with SMTP id 1AC7811E80DF for ; Mon, 21 Nov 2011 12:14:24 -0800 (PST)
Received: from mail-yx0-f174.google.com ([209.85.213.174]) (using TLSv1) by eu1sys200aob103.postini.com ([207.126.147.11]) with SMTP ID DSNKTsqxIA/0fUtkTlTVLt7UenRRS2WtwYLU@postini.com; Mon, 21 Nov 2011 20:14:25 UTC
Received: by yenq3 with SMTP id q3so5121812yen.19 for ; Mon, 21 Nov 2011 12:14:23 -0800 (PST)
Received: by 10.50.217.195 with SMTP id pa3mr16019148igc.12.1321906463190; Mon, 21 Nov 2011 12:14:23 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id l28sm50191979ibc.3.2011.11.21.12.14.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 12:14:22 -0800 (PST)
Message-ID: <1321906460.1990.30.camel@neutron>
From: "Paul C. Bryan" 
To: IETF Apps Discuss 
Date: Mon, 21 Nov 2011 12:14:20 -0800
In-Reply-To: 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <2n9lc79c8or4de9dpvi4s1s8vd186mosj8@hive.bjoern.hoehrmann.de> <1321905297.1990.20.camel@neutron> 
Content-Type: multipart/alternative; boundary="=-xIU4Iyro7SwF46Gf9fqh"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 20:14:26 -0000

--=-xIU4Iyro7SwF46Gf9fqh
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

Point taken. The intent of SHOULD in the text was to allow "/Björn" as a
JSON Pointer in a JSON string. Sounds like I should have separate
sections for expressing a JSON Pointer in JSON string vs. URI fragment,
and have clearer rules regarding the encoding of such values.

Paul

On Mon, 2011-11-21 at 21:09 +0100, Bjoern Hoehrmann wrote:

> If I recommended "When writing a new crime novel, reveal the perpetrator
> towards the end" then the author would still have to write the part, and
> the reader would still have to read through the novel to find out where
> the perpetrator is revealed, since the author might not be following the
> recommendation. Besides, the draft does not define a new scheme. This is
> just a matter of using the right incantation, but I don't know why, say,
> "/Björn" isn't allowed, so I can't make a good suggestion at the moment.

--=-xIU4Iyro7SwF46Gf9fqh
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


Point taken. The intent of SHOULD in the text was to allow "/Björn" as a JSON Pointer in a JSON string. Sounds like I should have separate sections for expressing a JSON Pointer in JSON string vs. URI fragment, and have clearer rules regarding the encoding of such values.



Paul



On Mon, 2011-11-21 at 21:09 +0100, Bjoern Hoehrmann wrote:



If I recommended "When writing a new crime novel, reveal the perpetrator
towards the end" then the author would still have to write the part, and
the reader would still have to read through the novel to find out where
the perpetrator is revealed, since the author might not be following the
recommendation. Besides, the draft does not define a new scheme. This is
just a matter of using the right incantation, but I don't know why, say,
"/Björn" isn't allowed, so I can't make a good suggestion at the moment.







--=-xIU4Iyro7SwF46Gf9fqh--


From mnot@mnot.net  Mon Nov 21 12:56:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCE711E80F1 for ; Mon, 21 Nov 2011 12:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.386
X-Spam-Level: 
X-Spam-Status: No, score=-105.386 tagged_above=-999 required=5 tests=[AWL=-2.787, 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 RhGORp9JcNnQ for ; Mon, 21 Nov 2011 12:55:59 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 694B011E80BA for ; Mon, 21 Nov 2011 12:55:59 -0800 (PST)
Received: from mnot-mini.mnot.net (unknown [118.209.190.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E585950A6B; Mon, 21 Nov 2011 15:55:51 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: <4ECAB0BC.0@gmx.de>
Date: Tue, 22 Nov 2011 07:55:47 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de>
To: Julian Reschke 
X-Mailer: Apple Mail (2.1251.1)
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 20:56:04 -0000

+1 to Julian here -- there's no reason why non-ASCII chars need to be =
percent-encoded when they occur inside a JSON document, only when =
they're in a URI (or similar context).

Cheers,


On 22/11/2011, at 7:12 AM, Julian Reschke wrote:

> On 2011-11-21 21:09, Paul C. Bryan wrote:
>> The intent is to allow a JSON Pointer to be expressed as a JSON =
string
>> value as well as a URI fragment identifier. The latter is the most
>> significant driver for URI percent-encoding.
>> ...
>=20
> Well, you could use it as fragment identifier (or otherwise URI =
component) by UTF-8-percent-escaping.
>=20
> The question is whether that use case requires them to be all ASCII =
every else, such as in a JSON patch document.
>=20
> Best regards, Julian
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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




From gsalguei@cisco.com  Mon Nov 21 13:24:42 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B1711E80F4 for ; Mon, 21 Nov 2011 13:24:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 eYOhcCtZE8l6 for ; Mon, 21 Nov 2011 13:24:42 -0800 (PST)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id D29B711E80E8 for ; Mon, 21 Nov 2011 13:24:41 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pALLOe7s021862 for ; Mon, 21 Nov 2011 16:24:41 -0500 (EST)
Received: from rtp-gsalguei-8717.cisco.com (rtp-gsalguei-8717.cisco.com [10.116.61.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pALLOd6u000525; Mon, 21 Nov 2011 16:24:39 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-339-6095399
From: Gonzalo Salgueiro 
In-Reply-To: 
Date: Mon, 21 Nov 2011 16:24:38 -0500
Message-Id: 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com> 
To: Blaine Cook 
X-Mailer: Apple Mail (2.1084)
Cc: Joseph Smarr , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Nov 2011 21:24:42 -0000

--Apple-Mail-339-6095399
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 21, 2011, at 12:53 PM, Blaine Cook wrote:

> On 21 November 2011 15:49, Paul E. Jones  =
wrote:
>> 1)      You want to mandate use of JSON, which we also indicated in =
the
>> draft.  However, I would personally prefer to give both XML and JSON =
equal
>> weight and require both.
>=20
> Implementations of XML-based host-meta clients are significantly more
> complex than JSON implementations. To completely abandon XML-based
> host-meta would have been impossible, but JSON is vastly preferred. To
> lower the barrier for Webfinger adoption, +1 for JSON as a strong
> recommendation over XML. It's still early days, so existing
> implementations shouldn't be given undue weight.

I agree that XML should be retained, but JSON given preference.  This is =
a nice opportunity for a good old fashioned RFC 2119 'RECOMMENDED'.

--Gonzalo

>=20
>> 2)      You wanted to mandate HTTPS. I=92m not opposed, but host-meta =
does not
>> mandate it.  Shouldn=92t we Webfinger requirements on what is there?
>=20
> host-meta does not necessarily have security implications. Webfinger
> almost certainly does, and as such should mandate HTTPS.
>=20
> b.
>=20


--Apple-Mail-339-6095399
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On 21 November 2011 15:49, Paul E. Jones <paulej@packetizer.com> =
wrote:
1)      You =
want to mandate use of JSON, which we also indicated in =
the
draft.  However, I =
would personally prefer to give both XML and JSON =
equal
weight and require =
both.

Implementations of XML-based host-meta clients =
are significantly more
complex than JSON implementations. To =
completely abandon XML-based
host-meta would have been impossible, =
but JSON is vastly preferred. To
lower the barrier for Webfinger =
adoption, +1 for JSON as a strong
recommendation over XML. It's still =
early days, so existing
implementations shouldn't be given undue =
weight.

I agree that XML should be =
retained, but JSON given preference.  This is a nice opportunity =
for a good old fashioned RFC 2119 =
'RECOMMENDED'.
1.       =
Requi=
re the server to offer JRD, leave it to the client to pick one flavor.=

<=
span style=3D'mso-list:Ignore'>2.   &nbs=
p;   Expand every template in host-meta + level one LRDD=
 links (excluding templates in LRDD).
 
EHL
 
=

From: Paul E. Jones [mailto:paulej@packeti=
zer.com] 
Sent: Monday, November 21, 2011 7:49 AM
To: E=
ran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonz=
alo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfing=
er
 <=
/p>
Eran,
 <=
/span>
Thanks for you=
r feedback.  The editorial, structural, and behavioral items we’=
ll addressed (including adhering to host-meta section 4.2).
 <=
/span>
Let me ask abo=
ut specific comments:
 
<=
span style=3D'color:#1F497D'>1)      Y=
ou want to mandate use of JSON, which we also indicated in the draft. =
 However, I would personally prefer to give both XML and JSON equal weight =
and require both.
2)      You wanted=
 to mandate HTTPS. I’m not opposed, but host-meta does not mandate it=
.  Shouldn’t we Webfinger requirements on what is there?
3)=
      Regarding “resource” ex=
tension: if I query host-meta, there may be any number of templates.  =
Would we want the server to automatically expand every template it f=
inds?  Or would we only expand the ‘lrdd’ template?  =
(And how many levels of recursion might be possible?)
=

 =

Paul
 <=
/span>
From: Eran Hammer-Lahav =
[mailto:eran@hueniverse.com=
] 
Sent: Saturday, November 19, 2011 10:03 AM
To: P=
aul E. Jones; apps-discuss@ietf.or=
g
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subj=
ect: RE: [apps-discuss] Webfinger
 
This is a good start. Some feedback and nits:
 <=
/span>
1.&nbs=
p;      The protocol flow is incorrect =
and needs to be adjusted based on the final host-meta specification (RFC 64=
15). Namely, WebFinger must follow section 4.2 exactly as specified.
2.       WebFinger should focus exclu=
sively on JSON and mandate WebFinger providers to support the JRD format. T=
his does not preclude using XRD (XML) but it will ensure that every complia=
nt WebFinger implementation provides full JSON support which is much more l=
ikely to be adopted. This is something we could not do in host-meta due to =
the late stage it was in, but this is the right time to make the switch (wi=
thout taking away any existing functionality).
<=
![if !supportLists]>3.   &nb=
sp;   Are there reasons not to mandate HTTPS?=

4.&nb=
sp;      Section 3 should be a sub-secti=
on of the introduction and each example needs actual JRD code.
 
In addition=
, I would very much like to see WebFinger extend the host-meta endpoint by =
defining a ‘resource’ query parameter. Using the example in RFC=
 6415 section 1.1.1 (example not properly encoded to make it easier to read=
):
=
 
> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1=
.1
=
 
   {
      "subject":"http://example.com/xy",=

 
 &nb=
sp;    "properties":{
     &=
nbsp;  "http://spec.exa=
mple.net/color":"red"
      },
&=
nbsp;
&n=
bsp;     "links":[
     =
;   {
          "r=
el":"hub",
        &nbs=
p; "href":"http://example=
.com/hub",
        },=

  &=
nbsp;     {
<=
span style=3D'color:#1F497D'>       &nbs=
p;  "rel":"hub",
      =
    "href":"http://example.com/another/hub",
    &n=
bsp;   },
        {<=
/span>
  &n=
bsp;       "rel":"author"=
,
&=
nbsp;         "href":&quo=
t;http://example.com/john",
 =
;       },
      &=
nbsp; {
          "rel"=
:"author",
          &=
quot;template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.c=
om%2Fxy"
        }
   =
   ]
    }
=
 
The rules for this extension parameter ar=
e pretty simple:
 
1.       J=
SON is implied. If the server understands ‘?resource’ it MUST r=
eturn a JRD document.
2.       =
The subject must be set to the value of the ‘resource’ paramete=
r.
3.       If the server does =
not support that resource (wrong domain, etc.) it must return an empty JRD =
with the right subject.
4.       =
The client MUST verify the server supports ‘?resource’ by mak=
ing sure the response is both JRD and has the requested subject (this will =
ensure full compatibility with any other host-meta endpoint).
 
I would like=
 to see such endpoint extension required for WebFinger so that clients can =
make a single call and get the full WebFinger result in JSON. This would si=
gnificantly improve adoption and usability, and adds very little work to pr=
oviders.
 
EHL
 
 
From: apps-discuss=
-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E.=
 Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc:=
 Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinge=
r
 
Folks,
 =
;
We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-a=
ppsawg-webfinger-00.txt
 <=
/o:p>
The tools for Webfinger are now defined, but =
the procedures need to be clearer with respect to what most of us understan=
d as “webfinger”.  This is just a first stab at making tha=
t happen and we hope to progress this to publish an RFC in the application =
area.
 
We welcome any comments you have on the topic, either privately or =
publicly.
 
Paul
 
<=
/div>
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F00BP3PW5EX1MB01E_--

From duerst@it.aoyama.ac.jp  Tue Nov 22 01:09:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68D921F8C7F for ; Tue, 22 Nov 2011 01:09:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.643
X-Spam-Level: 
X-Spam-Status: No, score=-99.643 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj6og2vj2+F7 for ; Tue, 22 Nov 2011 01:09:16 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id DECA421F8C7E for ; Tue, 22 Nov 2011 01:09:15 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAM996fg027262 for ; Tue, 22 Nov 2011 18:09:06 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 305b_2de0_a11eea4c_14e9_11e1_85ad_001d096c5782; Tue, 22 Nov 2011 18:09:06 +0900
Received: from [IPv6:::1] ([133.2.210.1]:35374) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Tue, 22 Nov 2011 18:09:10 +0900
Message-ID: <4ECB66B0.6060102@it.aoyama.ac.jp>
Date: Tue, 22 Nov 2011 18:09:04 +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: Mark Nottingham 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron>	<4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron>	<4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron>	<4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>	<1321912269.1990.32.camel@neutron> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 09:09:17 -0000

On 2011/11/22 8:43, Mark Nottingham wrote:
> The usual approach to this sort of thing is to define the "canonical" way to do it; i.e., json pointers *are* unicode strings; then you can define encodings into various environments (like URIs).
>
> In this case, it'd probably be good enough to say that json pointers are unicode strings,

Up to here, this makes a ton of sense.

> but that when they need to be in ASCII environments (like URIs) they get UTF-8'ed and then percent-escaped.

This would mean that e.g. in a Java program that for some reason is kept 
in US-ASCII, I'd have to use %-encoding. This doesn't make sense to me 
at all.

So I'd say that json pointers are escaped according to the conventions 
of the substrate that carries them when needed (e.g. pure ASCII, or 
other kinds of encodings that can't handle the whole Unicode range).

Then for json pointers as fragment identifiers, I'd mention that where 
necessary (e.g. for URIs), the convention for converting from IRIs to 
URIs (see RFC 3987) applies.

By the way, I don't see a need to escape "/" at all in a fragment 
identifier. "/" is plain and simply allowed in fragment identifiers. 
Please see http://tools.ietf.org/html/rfc3986#section-3.5. Of course, 
it's not forbidden to escape "/", so software that is interpreting a 
fragment identifier has to make sure it does the right thing.

Regards,    Martin.


> Cheers,
>
>
> On 22/11/2011, at 8:51 AM, Paul C. Bryan wrote:
>
>> Okay, so I'll write-up separate sections for JSON string values and URI fragment identifiers. Any objections?
>>
>> Paul
>>
>> On Tue, 2011-11-22 at 07:55 +1100, Mark Nottingham wrote:
>>> +1 to Julian here -- there's no reason why non-ASCII chars need to be percent-encoded when they occur inside a JSON document, only when they're in a URI (or similar context).
>>>
>>> Cheers,
>>>
>>>
>>> On 22/11/2011, at 7:12 AM, Julian Reschke wrote:
>>>
>>>> On 2011-11-21 21:09, Paul C. Bryan wrote:
>>>>> The intent is to allow a JSON Pointer to be expressed as a JSON string
>>>>> value as well as a URI fragment identifier. The latter is the most
>>>>> significant driver for URI percent-encoding.
>>>>> ...
>>>>
>>>> Well, you could use it as fragment identifier (or otherwise URI component) by UTF-8-percent-escaping.
>>>>
>>>> The question is whether that use case requires them to be all ASCII every else, such as in a JSON patch document.
>>>>
>>>> Best regards, Julian
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>>>
>>> apps-discuss@ietf.org
>>>
>>>>
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>
>>>
>>> --
>>> Mark Nottingham
>>> http://www.mnot.net/
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From julian.reschke@gmx.de  Tue Nov 22 01:13:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6266421F8CA7 for ; Tue, 22 Nov 2011 01:13:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.177
X-Spam-Level: 
X-Spam-Status: No, score=-104.177 tagged_above=-999 required=5 tests=[AWL=-1.878, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 033QMZF25Pid for ; Tue, 22 Nov 2011 01:13:21 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 762F421F8CA6 for ; Tue, 22 Nov 2011 01:13:21 -0800 (PST)
Received: (qmail invoked by alias); 22 Nov 2011 09:13:19 -0000
Received: from p5DCC9581.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.149.129] by mail.gmx.net (mp058) with SMTP; 22 Nov 2011 10:13:19 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19rmcFomvpr3YgyW3jJ4zNSIss0mC6sed33sel8e9 It24XwhaUFjrnI
Message-ID: <4ECB67A8.5080005@gmx.de>
Date: Tue, 22 Nov 2011 10:13:12 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron>	<4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron>	<4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron>	<4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>	<1321912269.1990.32.camel@neutron>  <4ECB66B0.6060102@it.aoyama.ac.jp>
In-Reply-To: <4ECB66B0.6060102@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 09:13:22 -0000

On 2011-11-22 10:09, "Martin J. Dürst" wrote:
> On 2011/11/22 8:43, Mark Nottingham wrote:
>> The usual approach to this sort of thing is to define the "canonical"
>> way to do it; i.e., json pointers *are* unicode strings; then you can
>> define encodings into various environments (like URIs).
>>
>> In this case, it'd probably be good enough to say that json pointers
>> are unicode strings,
>
> Up to here, this makes a ton of sense.
>
>> but that when they need to be in ASCII environments (like URIs) they
>> get UTF-8'ed and then percent-escaped.
>
> This would mean that e.g. in a Java program that for some reason is kept
> in US-ASCII, I'd have to use %-encoding. This doesn't make sense to me
> at all.
>
> So I'd say that json pointers are escaped according to the conventions
> of the substrate that carries them when needed (e.g. pure ASCII, or
> other kinds of encodings that can't handle the whole Unicode range).
>
> Then for json pointers as fragment identifiers, I'd mention that where
> necessary (e.g. for URIs), the convention for converting from IRIs to
> URIs (see RFC 3987) applies.

+1 up to here.

> By the way, I don't see a need to escape "/" at all in a fragment
> identifier. "/" is plain and simply allowed in fragment identifiers.
> Please see http://tools.ietf.org/html/rfc3986#section-3.5. Of course,
> it's not forbidden to escape "/", so software that is interpreting a
> fragment identifier has to make sure it does the right thing.
>
> Regards, Martin.
> ...

The escaping of "/" refers to the fact that "/" is used as delimiter in 
the pointer syntax (so if you have "/" in a token you need to escape it).

Speaking of fragment identifiers -- sounds like somebody is working on a 
fragment identifier syntax for the JSON media type???

Best regards, Julian

From cabo@tzi.org  Tue Nov 22 01:33:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108B121F8CF9 for ; Tue, 22 Nov 2011 01:33:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.199
X-Spam-Level: 
X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Cn935cftjRpF for ; Tue, 22 Nov 2011 01:33:58 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1117221F8A7D for ; Tue, 22 Nov 2011 01:33:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAM9XnHg020632; Tue, 22 Nov 2011 10:33:49 +0100 (CET)
Received: from [192.168.217.112] (p54899DAB.dip.t-dialin.net [84.137.157.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B1A0EF18; Tue, 22 Nov 2011 10:33:48 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>
Date: Tue, 22 Nov 2011 10:33:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>
To: Mark Nottingham 
X-Mailer: Apple Mail (2.1251.1)
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 09:33:59 -0000

On Nov 21, 2011, at 21:55, Mark Nottingham wrote:

> +1 to Julian here -- there's no reason why non-ASCII chars need to be =
percent-encoded when they occur inside a JSON document, only when =
they're in a URI (or similar context).

OK, folks, let's see where that leads to.

JSON document:
{"Bj=F8rn/Carsten": "Fritz"}

JSON pointer:
"/Bj=F8rn%2FCarsten"

Multi-segment URI-encoded version of this JSON pointer:

/Bj%C3%B8rn%252FCarsten

(For reference: Plain URI-encoded version:

%2FBj%C3%B8rn%252FCarsten
)

If this is what you want, please document it thoroughly, clearly, =
painfully redundantly.
Dozens of examples, including examples that show how to do it wrong.

With this kind of dual-layer percent-encoding, we are deeply in quoting =
hell, and implementers will need all the help we can give them (and they =
will still get it wrong).

Gr=FC=DFe, Carsten


From GK@ninebynine.org  Tue Nov 22 03:50:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF8E21F8D13 for ; Tue, 22 Nov 2011 03:50:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.442
X-Spam-Level: 
X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 zsnZmHMlBfW9 for ; Tue, 22 Nov 2011 03:49:59 -0800 (PST)
Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id F14B121F8D08 for ; Tue, 22 Nov 2011 03:49:58 -0800 (PST)
Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RSorI-0000Ri-Ax; Tue, 22 Nov 2011 11:49:52 +0000
Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RSorI-0002iw-6y; Tue, 22 Nov 2011 11:49:52 +0000
Message-ID: <4ECB86D5.9080907@ninebynine.org>
Date: Tue, 22 Nov 2011 11:26:13 +0000
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron>	<4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron>	<4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron>	<4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>	<1321912269.1990.32.camel@neutron>  <4ECB66B0.6060102@it.aoyama.ac.jp>
In-Reply-To: <4ECB66B0.6060102@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 11:50:03 -0000

I spotted this discussion and was reminded that one of the older URI specs had 
some explicit discussion of characters and octets and encoding.  I recall a line 
that looked something like this:

   URI characters -> URI octets -> URI octets %-encoded to US-ASCII

but I can no longer find it (quickly).  But http://www.ietf.org/rfc/rfc3986.txt 
sections 1.2 and section 2 (esp. intro) address some of the issues.  The point 
being that character encoding to octets is a separate concern from %-encoding to 
URI (or IRI) on-the-wire characters.

#g
--

On 22/11/2011 09:09, "Martin J. Dürst" wrote:
> On 2011/11/22 8:43, Mark Nottingham wrote:
>> The usual approach to this sort of thing is to define the "canonical" way to
>> do it; i.e., json pointers *are* unicode strings; then you can define
>> encodings into various environments (like URIs).
>>
>> In this case, it'd probably be good enough to say that json pointers are
>> unicode strings,
>
> Up to here, this makes a ton of sense.
>
>> but that when they need to be in ASCII environments (like URIs) they get
>> UTF-8'ed and then percent-escaped.
>
> This would mean that e.g. in a Java program that for some reason is kept in
> US-ASCII, I'd have to use %-encoding. This doesn't make sense to me at all.
>
> So I'd say that json pointers are escaped according to the conventions of the
> substrate that carries them when needed (e.g. pure ASCII, or other kinds of
> encodings that can't handle the whole Unicode range).
>
> Then for json pointers as fragment identifiers, I'd mention that where necessary
> (e.g. for URIs), the convention for converting from IRIs to URIs (see RFC 3987)
> applies.
>
> By the way, I don't see a need to escape "/" at all in a fragment identifier.
> "/" is plain and simply allowed in fragment identifiers. Please see
> http://tools.ietf.org/html/rfc3986#section-3.5. Of course, it's not forbidden to
> escape "/", so software that is interpreting a fragment identifier has to make
> sure it does the right thing.
>
> Regards, Martin.
>
>
>> Cheers,
>>
>>
>> On 22/11/2011, at 8:51 AM, Paul C. Bryan wrote:
>>
>>> Okay, so I'll write-up separate sections for JSON string values and URI
>>> fragment identifiers. Any objections?
>>>
>>> Paul
>>>
>>> On Tue, 2011-11-22 at 07:55 +1100, Mark Nottingham wrote:
>>>> +1 to Julian here -- there's no reason why non-ASCII chars need to be
>>>> percent-encoded when they occur inside a JSON document, only when they're in
>>>> a URI (or similar context).
>>>>
>>>> Cheers,
>>>>
>>>>
>>>> On 22/11/2011, at 7:12 AM, Julian Reschke wrote:
>>>>
>>>>> On 2011-11-21 21:09, Paul C. Bryan wrote:
>>>>>> The intent is to allow a JSON Pointer to be expressed as a JSON string
>>>>>> value as well as a URI fragment identifier. The latter is the most
>>>>>> significant driver for URI percent-encoding.
>>>>>> ...
>>>>>
>>>>> Well, you could use it as fragment identifier (or otherwise URI component)
>>>>> by UTF-8-percent-escaping.
>>>>>
>>>>> The question is whether that use case requires them to be all ASCII every
>>>>> else, such as in a JSON patch document.
>>>>>
>>>>> Best regards, Julian
>>>>> _______________________________________________
>>>>> apps-discuss mailing list
>>>>>
>>>> apps-discuss@ietf.org
>>>>
>>>>>
>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>
>>>>
>>>> --
>>>> Mark Nottingham
>>>> http://www.mnot.net/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>> --
>> Mark Nottingham http://www.mnot.net/
>>
>>
>>
>> _______________________________________________
>> 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 julian.reschke@gmx.de  Tue Nov 22 04:32:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDBA21F8DA0 for ; Tue, 22 Nov 2011 04:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.807
X-Spam-Level: 
X-Spam-Status: No, score=-103.807 tagged_above=-999 required=5 tests=[AWL=-1.808, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 FGKP3O61aXa6 for ; Tue, 22 Nov 2011 04:32:28 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0CD6F21F8DD0 for ; Tue, 22 Nov 2011 04:32:27 -0800 (PST)
Received: (qmail invoked by alias); 22 Nov 2011 12:32:26 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp056) with SMTP; 22 Nov 2011 13:32:26 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19RCasBgY1RSUpurKNclnSUyCwiSpxodDDjo5BwZW MQ5+OMu2rLM24+
Message-ID: <4ECB9657.1030605@gmx.de>
Date: Tue, 22 Nov 2011 13:32:23 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Chris Lilley 
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <4EC6031F.7000002@it.aoyama.ac.jp> <7534F85A589E654EB1E44E5CFDC19E3D117FCD7382@wob-email-01.agfamonotype.org> <01O8KCG4WZZE00XBUL@mauve.mrochek.com> <210354501.20111121132215@w3.org> <4ECAAC7C.1020005@gmx.de> <255620579.20111122130613@w3.org>
In-Reply-To: <255620579.20111122130613@w3.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: David Singer , Ned Freed , "apps-discuss@ietf.org" , "Levantovsky, Vladimir" , "gadams@xfsi.com Adams" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 12:32:29 -0000

On 2011-11-22 13:06, Chris Lilley wrote:
> On Monday, November 21, 2011, 8:54:36 PM, Julian wrote:
>
> JR>  On 2011-11-21 13:22, Chris Lilley wrote:
>>> ...
>>> No, not yet, since that requires a stable document to reference,and changes are still possible as a result of Candidate Recommendation implementation experience.
>>> ...
>
> JR>  Well, the (dated) CR is also stable, right?
>
> All dated /TR documents are stable, in that sense.
>
> My understanding was that the IESG wanted a document that was final and would serve as a reference for some time. A CR might (hopefully,would be) be superceeded in 6 months.
> ...

Well, if it's 6 months that would be ok. However I have the impression 
that the time between implementations coming out an full rec usually is 
something taking many years; in which case not having the media type 
registered isn't helping anybody...

Best regards, Julian

From julian.reschke@gmx.de  Tue Nov 22 05:06:55 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DB021F8DFE for ; Tue, 22 Nov 2011 05:06:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.078
X-Spam-Level: 
X-Spam-Status: No, score=-104.078 tagged_above=-999 required=5 tests=[AWL=-1.479, 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 84nifPBSu5Pd for ; Tue, 22 Nov 2011 05:06:55 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4B7B421F8DEC for ; Tue, 22 Nov 2011 05:06:54 -0800 (PST)
Received: (qmail invoked by alias); 22 Nov 2011 13:06:52 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp061) with SMTP; 22 Nov 2011 14:06:52 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18OFPwnO3oOQPSO3JTXYsrAte6+zDEkyYN8BezXK/ aYEh1n/WIVVhxL
Message-ID: <4ECB9E69.8090505@gmx.de>
Date: Tue, 22 Nov 2011 14:06:49 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Carsten Bormann 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 13:06:55 -0000

On 2011-11-22 10:33, Carsten Bormann wrote:
> On Nov 21, 2011, at 21:55, Mark Nottingham wrote:
>
>> +1 to Julian here -- there's no reason why non-ASCII chars need to be percent-encoded when they occur inside a JSON document, only when they're in a URI (or similar context).
>
> OK, folks, let's see where that leads to.
>
> JSON document:
> {"Bjørn/Carsten": "Fritz"}
>
> JSON pointer:
> "/Bjørn%2FCarsten"
>
> Multi-segment URI-encoded version of this JSON pointer:
>
> /Bj%C3%B8rn%252FCarsten
>
> (For reference: Plain URI-encoded version:
>
> %2FBj%C3%B8rn%252FCarsten
> )
>
> If this is what you want, please document it thoroughly, clearly, painfully redundantly.
> Dozens of examples, including examples that show how to do it wrong.
>
> With this kind of dual-layer percent-encoding, we are deeply in quoting hell, and implementers will need all the help we can give them (and they will still get it wrong).
>
> Grüße, Carsten

Indeed.

To add to the coverage, we should also consider whitespace and non-BMP 
characters:

JSON document:
{"Bjørn/Carsten/foo \uD834\uDD1E": "Fritz"}

JSON pointer:
"/Bjørn%2FCarsten%2Ffoo(X)(Y)"

(X) right now would be %20. Should it? Why escape it here already? (this 
applies to all characters that are currently disallowed expect '/' and '%')

(Y) imho should be the Unicode code point U+1D11E 
( has this example

So yes, the fact that a JSON name can be anything a JSON string can take 
is indeed a problem, because it doesn't leave us any characters as 
delimiters (so this is very different from XML vs XPath).

Best regards, Julian

From julian.reschke@gmx.de  Tue Nov 22 08:05:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB601F0CA0 for ; Tue, 22 Nov 2011 08:05:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.054
X-Spam-Level: 
X-Spam-Status: No, score=-104.054 tagged_above=-999 required=5 tests=[AWL=-1.455, 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 4yz9VsWfrXgc for ; Tue, 22 Nov 2011 08:05:46 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 476B51F0CB2 for ; Tue, 22 Nov 2011 08:05:45 -0800 (PST)
Received: (qmail invoked by alias); 22 Nov 2011 16:05:44 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp056) with SMTP; 22 Nov 2011 17:05:44 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18xm/59F24x1xmHSg9xBXvZmCkJYuq6sXlON9tOOF PJPfcSvmMZPV1w
Message-ID: <4ECBC843.60900@gmx.de>
Date: Tue, 22 Nov 2011 17:05:23 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul C. Bryan" 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de>
In-Reply-To: <4EBBA0DD.9020605@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 16:05:46 -0000

On 2011-11-10 11:01, Julian Reschke wrote:
> On 2011-11-02 18:22, Paul C. Bryan wrote:
>> Thanks everyone for the feedback so far. Some replies:
>>
>> On Wed, 2011-11-02 at 13:39 +0000, Michael Dürig wrote:
>>> What is missing (wrt. to [2]) is a reorder operation.
>>
>> The ability to move items in an array has come up and seems
>> straightforward. A need (and semantics) of moving a value between two
>> arbitrary locations in a JSON document is not well understood.
>
> +1. So are you planning to add this? Would it make sense to make a
> concrete proposal?
> ...

OK, here's draft proposal:

4.4. move

    The "move" operation moves an existing array element. The "to" 
member indicates the array position as integer value. This operation is 
equivalent to removing the element identified by "move", an inserting it 
again at the position "to".


Example:

    An example target JSON document:

    {
        "foo": [ "bar", "qux", "baz" ]
    }

    A JSON Patch document:

    [
        { "move": "/foo/1", "to": 2}
    ]

    The resulting JSON document:

    {
        "foo": ["qux", "bar", "baz"]
    }

Q: is a special case like "end" needed?

Best regards, Julian

From chris@w3.org  Tue Nov 22 04:06:21 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4828921F8DC1 for ; Tue, 22 Nov 2011 04:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.954
X-Spam-Level: 
X-Spam-Status: No, score=-8.954 tagged_above=-999 required=5 tests=[AWL=1.045,  BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8]
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 z2WWdnkKlkd8 for ; Tue, 22 Nov 2011 04:06:20 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id B012821F8DAC for ; Tue, 22 Nov 2011 04:06:20 -0800 (PST)
Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtpa (Exim 4.69) (envelope-from ) id 1RSp78-0001AO-Hm; Tue, 22 Nov 2011 07:06:14 -0500
Date: Tue, 22 Nov 2011 13:06:13 +0100
From: Chris Lilley 
X-Mailer: The Bat! (v3.95.6) Home
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <255620579.20111122130613@w3.org>
To: Julian Reschke 
In-Reply-To: <4ECAAC7C.1020005@gmx.de>
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <4EC6031F.7000002@it.aoyama.ac.jp> <7534F85A589E654EB1E44E5CFDC19E3D117FCD7382@wob-email-01.agfamonotype.org> <01O8KCG4WZZE00XBUL@mauve.mrochek.com> <210354501.20111121132215@w3.org> <4ECAAC7C.1020005@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 22 Nov 2011 08:09:59 -0800
Cc: David Singer , Ned Freed , "apps-discuss@ietf.org" , "Levantovsky, Vladimir" , "gadams@xfsi.com Adams" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Chris Lilley 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 12:06:21 -0000

On Monday, November 21, 2011, 8:54:36 PM, Julian wrote:

JR> On 2011-11-21 13:22, Chris Lilley wrote:
>> ...
>> No, not yet, since that requires a stable document to reference,and changes are still possible as a result of Candidate Recommendation implementation experience.
>> ...

JR> Well, the (dated) CR is also stable, right?

All dated /TR documents are stable, in that sense.

My understanding was that the IESG wanted a document that was final and would serve as a reference for some time. A CR might (hopefully,would be) be superceeded in 6 months.

JR> I believe it would be better overall to register early, and then to 
JR> update the registration later on.

Ah, yes, I hadn't thought of updating the registration. I tend to agree that earlier is better than later. I will take this back to W3C team and suggest a modification to our media type registration policy.



-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups


From chris@w3.org  Tue Nov 22 04:08:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DE721F8CDE for ; Tue, 22 Nov 2011 04:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.777
X-Spam-Level: 
X-Spam-Status: No, score=-9.777 tagged_above=-999 required=5 tests=[AWL=0.822,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 d-Xn1WxZ8Iti for ; Tue, 22 Nov 2011 04:08:24 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 322A821F8CDB for ; Tue, 22 Nov 2011 04:08:24 -0800 (PST)
Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtpa (Exim 4.69) (envelope-from ) id 1RSp99-0001Rt-BU; Tue, 22 Nov 2011 07:08:19 -0500
Date: Tue, 22 Nov 2011 13:08:18 +0100
From: Chris Lilley 
X-Mailer: The Bat! (v3.95.6) Home
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <231397750.20111122130818@w3.org>
To: Ned Freed 
In-Reply-To: <01O8OJSHV7B000RCTX@mauve.mrochek.com>
References:  <4EC0C2C8.2010500@it.aoyama.ac.jp> <01O8EV98HXC800RCTX@mauve.mrochek.com> <99733F9E-CF97-40BD-B438-300E309D3BF4@apple.com> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6BF2@wob-email-01.agfamonotype.org> <4EC31D1D.1000509@stpeter.im> <7534F85A589E654EB1E44E5CFDC19E3D117FCD6ED2@wob-email-01.agfamonotype.org> <4EC6031F.7000002@it.aoyama.ac.jp> <7534F85A589E654EB1E44E5CFDC19E3D117FCD7382@wob-email-01.agfamonotype.org> <01O8KCG4WZZE00XBUL@mauve.mrochek.com> <210354501.20111121132215@w3.org> <4ECAAC7C.1020005@gmx.de> <01O8OJSHV7B000RCTX@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 22 Nov 2011 08:09:59 -0800
Cc: David Singer , "apps-discuss@ietf.org" , "Levantovsky, Vladimir" , "gadams@xfsi.com Adams" 
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Chris Lilley 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 12:08:24 -0000

On Monday, November 21, 2011, 9:09:17 PM, Ned wrote:

>> Julian wrote:
>> I believe it would be better overall to register early, and then to
>> update the registration later on.

NF> +1

NF> And there is no need to change any rules to allow this. The decision of when to
NF> register a type is entirely up to the standards body doing the the registering.

NF> The word "stable" appears nowhere in RFC 4288.

Thanks for the confirmation, Ned, that there is nothing in the RFC that would prevent W3C registering media types at the W3C Candidate Recommendation stage.




-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups


From paulej@packetizer.com  Tue Nov 22 09:27:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1325F21F8C49 for ; Tue, 22 Nov 2011 09:27:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Level: 
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.078,  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 aQPixiv6jZDQ for ; Tue, 22 Nov 2011 09:27:32 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 51F4D21F8C44 for ; Tue, 22 Nov 2011 09:27:32 -0800 (PST)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pAMHR7fF012200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Nov 2011 12:27:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321982830; bh=sEZncZoCJvN2SFFPakGXW0G0BS25xCK4A2K6rIe4jDw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=FjVWshPPm6NTdj6HZSw7PpM3rRUOQEh9al82TF7yVy5fREMJMglOIe24g/kHIxu3p bbMlyxez4Pb+XZtIlIDi4vyD0J1aHt+Ngq/Pbf0vtVz68E40vn/DKP2P3qqU7y4VMZ wdBT/UwXEiG4UiNWMA6AFzfaeaJAjiBBCQswT67g=
From: "Paul E. Jones" 
To: "'Eran Hammer-Lahav'" , 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Tue, 22 Nov 2011 12:27:03 -0500
Message-ID: <086001cca93b$f455cc90$dd0165b0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0861_01CCA912.0B843160"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnysAgBEW78CHWIk+ZSf7Bkw
Content-Language: en-us
Cc: 'Joseph Smarr' 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 17:27:36 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0861_01CCA912.0B843160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

A couple more questions on (3):

 

Why expand templates like this:

        {

          "rel":"author",

 
"template":"http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy"

        }

 

The requesting entity could expand the templates.  I can appreciate the
reasoning for having "?resource" query the LRDD URL and return back the
ordered list of links, but why have the server modify the discovered
templates like the one above?  It's no longer a template, really.  Should we
change "template" to be "href"?

 

If a server does not understand "?resource", it's likely to simply ignore
it.  But, if a client expects it to be processed, it will cause confusion.
Would it be better to introduce /.well-known/host-meta-resource?  If a 404
is returned, then that is a clear indicator to the client.  Other
suggestions?

 

Paul

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

 

1.       Require the server to offer JRD, leave it to the client to pick one
flavor.

2.       Host-meta dumps the decision on the applications. You need to
decide if WebFinger is an application or just syntactic sugar on top of
host-meta.

3.       Expand every template in host-meta + level one LRDD links
(excluding templates in LRDD).

 

EHL

 

From: Paul E. Jones [mailto:paulej@packetizer.com] 
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

 

Eran,

 

Thanks for your feedback.  The editorial, structural, and behavioral items
we'll addressed (including adhering to host-meta section 4.2).

 

Let me ask about specific comments:

 

1)      You want to mandate use of JSON, which we also indicated in the
draft.  However, I would personally prefer to give both XML and JSON equal
weight and require both.

2)      You wanted to mandate HTTPS. I'm not opposed, but host-meta does not
mandate it.  Shouldn't we Webfinger requirements on what is there?

3)      Regarding "resource" extension: if I query host-meta, there may be
any number of templates.  Would we want the server to automatically expand
every template it finds?  Or would we only expand the 'lrdd' template?  (And
how many levels of recursion might be possible?)

 

Paul

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

 

This is a good start. Some feedback and nits:

 

1.       The protocol flow is incorrect and needs to be adjusted based on
the final host-meta specification (RFC 6415). Namely, WebFinger must follow
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger
providers to support the JRD format. This does not preclude using XRD (XML)
but it will ensure that every compliant WebFinger implementation provides
full JSON support which is much more likely to be adopted. This is something
we could not do in host-meta due to the late stage it was in, but this is
the right time to make the switch (without taking away any existing
functionality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each
example needs actual JRD code.

 

In addition, I would very much like to see WebFinger extend the host-meta
endpoint by defining a 'resource' query parameter. Using the example in RFC
6415 section 1.1.1 (example not properly encoded to make it easier to read):

 

> GET /.well-known/host-meta?resource=http://example.com/xy HTTP/1.1

 

   {

      "subject":"http://example.com/xy",

 

      "properties":{

        "http://spec.example.net/color":"red"

      },

 

      "links":[

        {

          "rel":"hub",

          "href":"http://example.com/hub",

        },

        {

          "rel":"hub",

          "href":"http://example.com/another/hub",

        },

        {

          "rel":"author",

          "href":"http://example.com/john",

        },

        {

          "rel":"author",

 
"template":"http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy"

        }

      ]

    }

 

The rules for this extension parameter are pretty simple:

 

1.       JSON is implied. If the server understands '?resource' it MUST
return a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.)
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making
sure the response is both JRD and has the requested subject (this will
ensure full compatibility with any other host-meta endpoint).

 

I would like to see such endpoint extension required for WebFinger so that
clients can make a single call and get the full WebFinger result in JSON.
This would significantly improve adoption and usability, and adds very
little work to providers.

 

EHL

 

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

 

Folks,

 

We just submitted this:

http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

 

The tools for Webfinger are now defined, but the procedures need to be
clearer with respect to what most of us understand as "webfinger".  This is
just a first stab at making that happen and we hope to progress this to
publish an RFC in the application area.

 

We welcome any comments you have on the topic, either privately or publicly.

 

Paul

 


------=_NextPart_000_0861_01CCA912.0B843160
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


A couple more questions on =
(3):
 
Why expand templates =
like this:
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "template":"http=
://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"
        =
}
 
The requesting entity =
could expand the templates.  I can appreciate the reasoning for =
having “?resource” query the LRDD URL and return back the =
ordered list of links, but why have the server modify the discovered =
templates like the one above?  It’s no longer a template, =
really.  Should we change “template” to be =
“href”?
 
If a server does not =
understand “?resource”, it’s likely to simply ignore =
it.  But, if a client expects it to be processed, it will cause =
confusion.  Would it be better to introduce =
/.well-known/host-meta-resource?  If a 404 is returned, then that =
is a clear indicator to the client.  Other =
suggestions?
 
Paul
 
From:=
 =
Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Monday, =
November 21, 2011 9:52 PM
To: Paul E. Jones; =
apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; =
'Blaine Cook'
Subject: RE: [apps-discuss] =
Webfinger
 
1.       =
Require the =
server to offer JRD, leave it to the client to pick one =
flavor.
2.       =
Host-meta =
dumps the decision on the applications. You need to decide if WebFinger =
is an application or just syntactic sugar on top of =
host-meta.
3.       =
Expand =
every template in host-meta + level one LRDD links (excluding templates =
in LRDD).
 
EHL
 
From:=
 =
Paul E. Jones [mailto:paulej@packetizer.=
com] 
Sent: Monday, November 21, 2011 7:49 =
AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc:=
 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine =
Cook'
Subject: RE: [apps-discuss] =
Webfinger
 
Eran,
 
Thanks for your =
feedback.  The editorial, structural, and behavioral items =
we’ll addressed (including adhering to host-meta section =
4.2).
 
Let me ask about =
specific comments:
 
1)      =
You want to =
mandate use of JSON, which we also indicated in the draft.  =
However, I would personally prefer to give both XML and JSON equal =
weight and require both.
2)      =
You wanted =
to mandate HTTPS. I’m not opposed, but host-meta does not mandate =
it.  Shouldn’t we Webfinger requirements on what is =
there?
3)      =
Regarding =
“resource” extension: if I query host-meta, there may be any =
number of templates.  Would we want the server to automatically =
expand every template it finds?  Or would we only expand the =
‘lrdd’ template?  (And how many levels of recursion =
might be possible?)
 
Paul
 
From:=
 =
Eran Hammer-Lahav [mailto:eran@hueniverse.com]=
 
Sent: Saturday, November 19, 2011 10:03 AM
To: =
Paul E. Jones; apps-discuss@ietf.org
Cc:=
 Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: =
[apps-discuss] Webfinger
 
This is a good start. Some feedback and =
nits:
 
1.       =
The =
protocol flow is incorrect and needs to be adjusted based on the final =
host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.
2.       =
WebFinger =
should focus exclusively on JSON and mandate WebFinger providers to =
support the JRD format. This does not preclude using XRD (XML) but it =
will ensure that every compliant WebFinger implementation provides full =
JSON support which is much more likely to be adopted. This is something =
we could not do in host-meta due to the late stage it was in, but this =
is the right time to make the switch (without taking away any existing =
functionality).
3.       =
Are there =
reasons not to mandate HTTPS?
4.       =
Section 3 =
should be a sub-section of the introduction and each example needs =
actual JRD code.
 
In addition, I would =
very much like to see WebFinger extend the host-meta endpoint by =
defining a ‘resource’ query parameter. Using the example in =
RFC 6415 section 1.1.1 (example not properly encoded to make it easier =
to read):
 
> GET =
/.well-known/host-meta?resource=3Dhttp://example.com/xy =
HTTP/1.1
 
   =
{
      =
"subject":"http://example.com/xy",
 
      =
"properties":{
        =
"http://spec.example.net/color&=
quot;:"red"
      =
},
 
      =
"links":[
        =
{
        &=
nbsp; "rel":"hub",
        &=
nbsp; "href":"http://example.com/hub",
        =
},
        =
{
        &=
nbsp; "rel":"hub",
        &=
nbsp; "href":"http://example.com/another/hub",
        =
},
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "href":"http://example.com/john",<=
/o:p>
        =
},
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "template":"http=
://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"
        =
}
      =
]
    }
 
The rules for this =
extension parameter are pretty simple:
 
1.       =
JSON is =
implied. If the server understands ‘?resource’ it MUST =
return a JRD document.
2.       =
The subject =
must be set to the value of the ‘resource’ =
parameter.
3.       =
If the =
server does not support that resource (wrong domain, etc.) it must =
return an empty JRD with the right subject.
4.       =
The client =
MUST verify the server supports ‘?resource’ by making sure =
the response is both JRD and has the requested subject (this will ensure =
full compatibility with any other host-meta =
endpoint).
 
I would like to see such =
endpoint extension required for WebFinger so that clients can make a =
single call and get the full WebFinger result in JSON. This would =
significantly improve adoption and usability, and adds very little work =
to providers.
 
EHL
 
 
From:=
 =
apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] On Behalf Of Paul E. =
Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc:=
 Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] =
Webfinger
 
Folks,
 
We just =
submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinge=
r-00.txt
 
The tools for Webfinger are now defined, but the =
procedures need to be clearer with respect to what most of us understand =
as “webfinger”.  This is just a first stab at making =
that happen and we hope to progress this to publish an RFC in the =
application area.
 
We welcome =
any comments you have on the topic, either privately or =
publicly.
 
Paul
 

------=_NextPart_000_0861_01CCA912.0B843160--


From paul.bryan@forgerock.com  Tue Nov 22 10:25:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C11D21F8BFE for ; Tue, 22 Nov 2011 10:25:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.657
X-Spam-Level: 
X-Spam-Status: No, score=-6.657 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, 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 pxWm0Xrdc+hv for ; Tue, 22 Nov 2011 10:25:18 -0800 (PST)
Received: from eu1sys200aog103.obsmtp.com (eu1sys200aog103.obsmtp.com [207.126.144.115]) by ietfa.amsl.com (Postfix) with SMTP id 45CDB21F8BEF for ; Tue, 22 Nov 2011 10:25:18 -0800 (PST)
Received: from mail-qw0-f46.google.com ([209.85.216.46]) (using TLSv1) by eu1sys200aob103.postini.com ([207.126.147.11]) with SMTP ID DSNKTsvo/lr9ZycslNTDkdj2+HGPWDGo1+a6@postini.com; Tue, 22 Nov 2011 18:25:18 UTC
Received: by qadc14 with SMTP id c14so1932250qad.5 for ; Tue, 22 Nov 2011 10:25:01 -0800 (PST)
Received: by 10.224.198.10 with SMTP id em10mr9023200qab.44.1321986301157; Tue, 22 Nov 2011 10:25:01 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id ff9sm14776782qab.16.2011.11.22.10.24.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 10:24:59 -0800 (PST)
Message-ID: <1321986297.2091.1.camel@neutron>
From: "Paul C. Bryan" 
To: apps-discuss@ietf.org
Date: Tue, 22 Nov 2011 10:24:57 -0800
In-Reply-To: <4ECBC843.60900@gmx.de>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de>
Content-Type: multipart/alternative; boundary="=-kbkVB/AflXMz3dk5Dxdm"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 18:25:19 -0000

--=-kbkVB/AflXMz3dk5Dxdm
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

Looks good to me. I don't think "end" is needed, as the end index can be
explicitly specified.

Paul

On Tue, 2011-11-22 at 17:05 +0100, Julian Reschke wrote:

> On 2011-11-10 11:01, Julian Reschke wrote:
> > On 2011-11-02 18:22, Paul C. Bryan wrote:
> >> Thanks everyone for the feedback so far. Some replies:
> >>
> >> On Wed, 2011-11-02 at 13:39 +0000, Michael Dürig wrote:
> >>> What is missing (wrt. to [2]) is a reorder operation.
> >>
> >> The ability to move items in an array has come up and seems
> >> straightforward. A need (and semantics) of moving a value between two
> >> arbitrary locations in a JSON document is not well understood.
> >
> > +1. So are you planning to add this? Would it make sense to make a
> > concrete proposal?
> > ...
> 
> OK, here's draft proposal:
> 
> 4.4. move
> 
>     The "move" operation moves an existing array element. The "to" 
> member indicates the array position as integer value. This operation is 
> equivalent to removing the element identified by "move", an inserting it 
> again at the position "to".
> 
> 
> Example:
> 
>     An example target JSON document:
> 
>     {
>         "foo": [ "bar", "qux", "baz" ]
>     }
> 
>     A JSON Patch document:
> 
>     [
>         { "move": "/foo/1", "to": 2}
>     ]
> 
>     The resulting JSON document:
> 
>     {
>         "foo": ["qux", "bar", "baz"]
>     }
> 
> Q: is a special case like "end" needed?
> 
> Best regards, Julian



--=-kbkVB/AflXMz3dk5Dxdm
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


Looks good to me. I don't think "end" is needed, as the end index can be explicitly specified.



Paul



On Tue, 2011-11-22 at 17:05 +0100, Julian Reschke wrote:



On 2011-11-10 11:01, Julian Reschke wrote:
> On 2011-11-02 18:22, Paul C. Bryan wrote:
>> Thanks everyone for the feedback so far. Some replies:
>>
>> On Wed, 2011-11-02 at 13:39 +0000, Michael Dürig wrote:
>>> What is missing (wrt. to [2]) is a reorder operation.
>>
>> The ability to move items in an array has come up and seems
>> straightforward. A need (and semantics) of moving a value between two
>> arbitrary locations in a JSON document is not well understood.
>
> +1. So are you planning to add this? Would it make sense to make a
> concrete proposal?
> ...

OK, here's draft proposal:

4.4. move

    The "move" operation moves an existing array element. The "to" 
member indicates the array position as integer value. This operation is 
equivalent to removing the element identified by "move", an inserting it 
again at the position "to".


Example:

    An example target JSON document:

    {
        "foo": [ "bar", "qux", "baz" ]
    }

    A JSON Patch document:

    [
        { "move": "/foo/1", "to": 2}
    ]

    The resulting JSON document:

    {
        "foo": ["qux", "bar", "baz"]
    }

Q: is a special case like "end" needed?

Best regards, Julian









--=-kbkVB/AflXMz3dk5Dxdm--


From julian.reschke@gmx.de  Tue Nov 22 10:27:51 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3A021F8C0A for ; Tue, 22 Nov 2011 10:27:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.031
X-Spam-Level: 
X-Spam-Status: No, score=-104.031 tagged_above=-999 required=5 tests=[AWL=-1.432, 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 fwgNO0+hnEiy for ; Tue, 22 Nov 2011 10:27:51 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EAC1321F8C00 for ; Tue, 22 Nov 2011 10:27:50 -0800 (PST)
Received: (qmail invoked by alias); 22 Nov 2011 18:27:46 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp023) with SMTP; 22 Nov 2011 19:27:46 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/dOOI0aU/dMETCqxsw5tEsgAEwU1UV4KW9lhNeNX PH7u/z0Xnyu5hv
Message-ID: <4ECBE991.9040704@gmx.de>
Date: Tue, 22 Nov 2011 19:27:29 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul C. Bryan" 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <1321986297.2091.1.camel@neutron>
In-Reply-To: <1321986297.2091.1.camel@neutron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 18:27:52 -0000

On 2011-11-22 19:24, Paul C. Bryan wrote:
> Looks good to me. I don't think "end" is needed, as the end index can be
> explicitly specified.
> ...

It might make it easier to move something to the end when you don't know 
the whole array (for instance, because there may be race conditions)... 
Not sure how important that is for this use case, though...

Best regards, Julian

From eran@hueniverse.com  Tue Nov 22 10:36:06 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44DF21F8AB0 for ; Tue, 22 Nov 2011 10:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level: 
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.051,  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 6jeo7TJzHakK for ; Tue, 22 Nov 2011 10:36:03 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 9679F21F8AAF for ; Tue, 22 Nov 2011 10:36:02 -0800 (PST)
Received: (qmail 17088 invoked from network); 22 Nov 2011 18:32:58 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Nov 2011 18:32:57 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 22 Nov 2011 11:32:42 -0700
From: Eran Hammer-Lahav 
To: "Paul E. Jones" , "apps-discuss@ietf.org" 
Date: Tue, 22 Nov 2011 11:32:37 -0700
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnysAgBEW78CHWIk+ZSf7BkwgAAksVA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <086001cca93b$f455cc90$dd0165b0$@packetizer.com>
In-Reply-To: <086001cca93b$f455cc90$dd0165b0$@packetizer.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234526735F0DDP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: 'Joseph Smarr' 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 18:36:06 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F0DDP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes, it is no longer a template and must be converted to href.

As for testing support, just check for Subject. Pretty simple to do.

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Tuesday, November 22, 2011 9:27 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

A couple more questions on (3):

Why expand templates like this:
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }

The requesting entity could expand the templates.  I can appreciate the rea=
soning for having "?resource" query the LRDD URL and return back the ordere=
d list of links, but why have the server modify the discovered templates li=
ke the one above?  It's no longer a template, really.  Should we change "te=
mplate" to be "href"?

If a server does not understand "?resource", it's likely to simply ignore i=
t.  But, if a client expects it to be processed, it will cause confusion.  =
Would it be better to introduce /.well-known/host-meta-resource?  If a 404 =
is returned, then that is a clear indicator to the client.  Other suggestio=
ns?

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger


1.       Require the server to offer JRD, leave it to the client to pick on=
e flavor.

2.       Host-meta dumps the decision on the applications. You need to deci=
de if WebFinger is an application or just syntactic sugar on top of host-me=
ta.

3.       Expand every template in host-meta + level one LRDD links (excludi=
ng templates in LRDD).

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

Eran,

Thanks for your feedback.  The editorial, structural, and behavioral items =
we'll addressed (including adhering to host-meta section 4.2).

Let me ask about specific comments:


1)      You want to mandate use of JSON, which we also indicated in the dra=
ft.  However, I would personally prefer to give both XML and JSON equal wei=
ght and require both.

2)      You wanted to mandate HTTPS. I'm not opposed, but host-meta does no=
t mandate it.  Shouldn't we Webfinger requirements on what is there?

3)      Regarding "resource" extension: if I query host-meta, there may be =
any number of templates.  Would we want the server to automatically expand =
every template it finds?  Or would we only expand the 'lrdd' template?  (An=
d how many levels of recursion might be possible?)

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

This is a good start. Some feedback and nits:


1.       The protocol flow is incorrect and needs to be adjusted based on t=
he final host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger p=
roviders to support the JRD format. This does not preclude using XRD (XML) =
but it will ensure that every compliant WebFinger implementation provides f=
ull JSON support which is much more likely to be adopted. This is something=
 we could not do in host-meta due to the late stage it was in, but this is =
the right time to make the switch (without taking away any existing functio=
nality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each exa=
mple needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta e=
ndpoint by defining a 'resource' query parameter. Using the example in RFC =
6415 section 1.1.1 (example not properly encoded to make it easier to read)=
:

> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1

   {
      "subject":"http://example.com/xy",

      "properties":{
        "http://spec.example.net/color":"red"
      },

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/hub",
        },
        {
          "rel":"hub",
          "href":"http://example.com/another/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/john",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }
      ]
    }

The rules for this extension parameter are pretty simple:


1.       JSON is implied. If the server understands '?resource' it MUST ret=
urn a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.) =
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making s=
ure the response is both JRD and has the requested subject (this will ensur=
e full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that =
clients can make a single call and get the full WebFinger result in JSON. T=
his would significantly improve adoption and usability, and adds very littl=
e work to providers.

EHL


From: apps-discuss-bounces@ietf.org [=
mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

Folks,

We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

The tools for Webfinger are now defined, but the procedures need to be clea=
rer with respect to what most of us understand as "webfinger".  This is jus=
t a first stab at making that happen and we hope to progress this to publis=
h an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly=
.

Paul


--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F0DDP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Yes, it is no longer a template and must be converted to href=
.
<=
o:p> 
As for testing support, just check for Subject. Pretty simple to do.
&=
nbsp;
EH=
L
<=
o:p> 
From: Pa=
ul E. Jones [mailto:paulej@packetizer.com] 
Sent: Tuesday, Novemb=
er 22, 2011 9:27 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org<=
br>Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subj=
ect: RE: [apps-discuss] Webfinger
 
A couple more questions on (3):
 
Why expand templates like th=
is:
        {
     &n=
bsp;    "rel":"author",
   &=
nbsp;      "template":"http://example.=
com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"
    =
;    }
 
The requesting entity could expand the templates.&nb=
sp; I can appreciate the reasoning for having “?resource” query=
 the LRDD URL and return back the ordered list of links, but why have the s=
erver modify the discovered templates like the one above?  It’s =
no longer a template, really.  Should we change “template”=
 to be “href”?
 
If a server does not understand “?resourc=
e”, it’s likely to simply ignore it.  But, if a client exp=
ects it to be processed, it will cause confusion.  Would it be better =
to introduce /.well-known/host-meta-resource?  If a 404 is returned, t=
hen that is a clear indicator to the client.  Other suggestions?<=
/o:p>
&nb=
sp;
Paul=

 
From:=
 Era=
n Hammer-Lahav [mailto:eran=
@hueniverse.com] 
Sent: Monday, November 21, 2011 9:52 PM
=
To: Paul E. Jones; apps-dis=
cuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blain=
e Cook'
Subject: RE: [apps-discuss] Webfinger
 
1.     &nb=
sp; Require the server to offer JRD, leave it to the client to pic=
k one flavor.
2.       <=
/span>Host-m=
eta dumps the decision on the applications. You need to decide if WebFinger=
 is an application or just syntactic sugar on top of host-meta.<=
/span>
3.&nbs=
p;      Expand every template in host-m=
eta + level one LRDD links (excluding templates in LRDD).=

 
EHL
 
From: Paul E. Jones [mailto:paulej@packetizer.c=
om] 
Sent: Monday, November 21, 2011 7:49 AM
To: Er=
an Hammer-Lahav; apps-discuss@ietf=
.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'Subject: RE: [apps-discuss] Webfinger
<=
/div>
 
Eran,
 
=
Thanks for your feedback.  The editorial=
, structural, and behavioral items we’ll addressed (including adherin=
g to host-meta section 4.2).
 
=
Let me ask about specific comments:
 <=
/o:p>
1)You want to mandate use of JSON=
, which we also indicated in the draft.  However, I would personally p=
refer to give both XML and JSON equal weight and require both.
2) =
;     You wanted to mandate HTTPS. I’m n=
ot opposed, but host-meta does not mandate it.  Shouldn’t we Web=
finger requirements on what is there?
3)=
     =
 Regarding “resource” extension: if I query host-meta,=
 there may be any number of templates.  Would we want the server to au=
tomatically expand every template it finds?  Or would we only e=
xpand the ‘lrdd’ template?  (And how many levels of recurs=
ion might be possible?)
 
Paul
 
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Saturday=
, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smar=
r; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Web=
finger
 
This is a good st=
art. Some feedback and nits:
 
1.      =
; The protocol flow is incorrect and needs to be adjusted based on=
 the final host-meta specification (RFC 6415). Namely, WebFinger must follo=
w section 4.2 exactly as specified.
2.     &n=
bsp; WebFinger should focus exclusively on JSON and mandate WebFin=
ger providers to support the JRD format. This does not preclude using XRD (=
XML) but it will ensure that every compliant WebFinger implementation provi=
des full JSON support which is much more likely to be adopted. This is some=
thing we could not do in host-meta due to the late stage it was in, but thi=
s is the right time to make the switch (without taking away any existing fu=
nctionality).
3.       <=
/span>Are th=
ere reasons not to mandate HTTPS?
4.     &nbs=
p; Section 3 should be a sub-section of the introduction and each =
example needs actual JRD code.
 
In addition, I would very much like to see =
WebFinger extend the host-meta endpoint by defining a ‘resource’=
; query parameter. Using the example in RFC 6415 section 1.1.1 (example not=
 properly encoded to make it easier to read):
 
> GET /.well-known/host-m=
eta?resource=3Dhttp://example.com/xy HTTP/1.1
 
   {
  &nbs=
p;   "subject":"=
http://example.com/xy",
=
 
      "prop=
erties":{
        "http://spec.example.net/color":"r=
ed"
      },
 
      &=
quot;links":[
        {
   =
;       "rel":"hub",=

 &=
nbsp;        "href":"http://example.com/hub",=

  &=
nbsp;     },
=
        {<=
o:p>
&nb=
sp;         "rel":"h=
ub",
          "href&qu=
ot;:"http://example.com/ano=
ther/hub",
        },=

  &=
nbsp;     {
<=
span style=3D'color:#1F497D'>       &nbs=
p;  "rel":"author",
     &n=
bsp;    "href":"http://example.com/john",
      =
  },
        {
    &n=
bsp;     "rel":"author",=

  &=
nbsp;       "template":"http://ex=
ample.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"
   =
;     }
      ]=

    }=

 
The rules for this extension parameter are pretty simple:
 <=
/span>
1.&nbs=
p;      JSON is implied. If the server =
understands ‘?resource’ it MUST return a JRD document.
2.&=
nbsp;      The subject must be set to the=
 value of the ‘resource’ parameter.
=
3.   &n=
bsp;   If the server does not support that resource (wro=
ng domain, etc.) it must return an empty JRD with the right subject.
4.       The client MUST verify the s=
erver supports ‘?resource’ by making sure the response is both =
JRD and has the requested subject (this will ensure full compatibility with=
 any other host-meta endpoint).
<=
span style=3D'color:#1F497D'> 
I would like to see such endpoint extensio=
n required for WebFinger so that clients can make a single call and get the=
 full WebFinger result in JSON. This would significantly improve adoption a=
nd usability, and adds very little work to providers.
=

 =

EHL
 
 
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bou=
nces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday=
, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgue=
iro
Subject: [apps-discuss] Webfinger
=

 
Folks,=

 
We just submitted this:
htt=
p://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt
 
The tools for Webfinger are now defined, but the procedures need to be cle=
arer with respect to what most of us understand as “webfinger”.=
  This is just a first stab at making that happen and we hope to progr=
ess this to publish an RFC in the application area.
 
We welcome any comme=
nts you have on the topic, either privately or publicly.
 
Paul<=
/p>
 
=

=

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F0DDP3PW5EX1MB01E_--

From laurentwalter.goix@telecomitalia.it  Tue Nov 22 10:42:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25B511E8082 for ; Tue, 22 Nov 2011 10:42:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.039
X-Spam-Level: 
X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=0.679,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 unz80gXZawaD for ; Tue, 22 Nov 2011 10:42:05 -0800 (PST)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 11EE521F8B4A for ; Tue, 22 Nov 2011 10:42:03 -0800 (PST)
Content-Type: multipart/mixed; boundary="_7294c471-aea8-46ae-b3fb-650a059446cb_"
Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Nov 2011 19:41:59 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 22 Nov 2011 19:41:59 +0100
From: Goix Laurent Walter 
To: Eran Hammer-Lahav , "Paul E. Jones" , "apps-discuss@ietf.org" 
Date: Tue, 22 Nov 2011 19:41:55 +0100
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnysAgBEW78CHWIk+ZSf7BkwgAAksVCAAAGYgA==
Message-ID: 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <086001cca93b$f455cc90$dd0165b0$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US, it-IT
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, it-IT
MIME-Version: 1.0
Cc: 'Joseph Smarr' 
Subject: [apps-discuss] R:  Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 18:42:09 -0000

--_7294c471-aea8-46ae-b3fb-650a059446cb_
Content-Type: multipart/alternative;
	boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE4057006772GRFMBX704BA02_"

--_000_A09A9E0A4B9C654E8672D1DC003633AE4057006772GRFMBX704BA02_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I guess the discussion is moving from a pure descriptor (which may be stati=
c in most cases) to a sort of API, which could have endless parameters.

>From the current/original webfinger description, the host-meta would mostly=
 be static, which implies no API-like, and no parameter, but the lrdd link =
can typically be dynamic/API-like (to support the template mechanism). As s=
uch it could easily accommodate some more parameters as well (in a similar =
flavor than opensearch), e.g. to request specific link rels if we want.

What would be the scope of supporting uri parameters when accessing host-me=
ta? Does this intend to save an interaction step?

walter

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe=
r conto di Eran Hammer-Lahav
Inviato: marted=EC 22 novembre 2011 19.33
A: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Oggetto: Re: [apps-discuss] Webfinger

Yes, it is no longer a template and must be converted to href.

As for testing support, just check for Subject. Pretty simple to do.

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Tuesday, November 22, 2011 9:27 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

A couple more questions on (3):

Why expand templates like this:
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }

The requesting entity could expand the templates.  I can appreciate the rea=
soning for having "?resource" query the LRDD URL and return back the ordere=
d list of links, but why have the server modify the discovered templates li=
ke the one above?  It's no longer a template, really.  Should we change "te=
mplate" to be "href"?

If a server does not understand "?resource", it's likely to simply ignore i=
t.  But, if a client expects it to be processed, it will cause confusion.  =
Would it be better to introduce /.well-known/host-meta-resource?  If a 404 =
is returned, then that is a clear indicator to the client.  Other suggestio=
ns?

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger


1.       Require the server to offer JRD, leave it to the client to pick on=
e flavor.

2.       Host-meta dumps the decision on the applications. You need to deci=
de if WebFinger is an application or just syntactic sugar on top of host-me=
ta.

3.       Expand every template in host-meta + level one LRDD links (excludi=
ng templates in LRDD).

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

Eran,

Thanks for your feedback.  The editorial, structural, and behavioral items =
we'll addressed (including adhering to host-meta section 4.2).

Let me ask about specific comments:


1)      You want to mandate use of JSON, which we also indicated in the dra=
ft.  However, I would personally prefer to give both XML and JSON equal wei=
ght and require both.

2)      You wanted to mandate HTTPS. I'm not opposed, but host-meta does no=
t mandate it.  Shouldn't we Webfinger requirements on what is there?

3)      Regarding "resource" extension: if I query host-meta, there may be =
any number of templates.  Would we want the server to automatically expand =
every template it finds?  Or would we only expand the 'lrdd' template?  (An=
d how many levels of recursion might be possible?)

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

This is a good start. Some feedback and nits:


1.       The protocol flow is incorrect and needs to be adjusted based on t=
he final host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger p=
roviders to support the JRD format. This does not preclude using XRD (XML) =
but it will ensure that every compliant WebFinger implementation provides f=
ull JSON support which is much more likely to be adopted. This is something=
 we could not do in host-meta due to the late stage it was in, but this is =
the right time to make the switch (without taking away any existing functio=
nality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each exa=
mple needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta e=
ndpoint by defining a 'resource' query parameter. Using the example in RFC =
6415 section 1.1.1 (example not properly encoded to make it easier to read)=
:

> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1

   {
      "subject":"http://example.com/xy",

      "properties":{
        "http://spec.example.net/color":"red"
      },

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/hub",
        },
        {
          "rel":"hub",
          "href":"http://example.com/another/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/john",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }
      ]
    }

The rules for this extension parameter are pretty simple:


1.       JSON is implied. If the server understands '?resource' it MUST ret=
urn a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.) =
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making s=
ure the response is both JRD and has the requested subject (this will ensur=
e full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that =
clients can make a single call and get the full WebFinger result in JSON. T=
his would significantly improve adoption and usability, and adds very littl=
e work to providers.

EHL


From: apps-discuss-bounces@ietf.org [=
mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

Folks,

We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

The tools for Webfinger are now defined, but the procedures need to be clea=
rer with respect to what most of us understand as "webfinger".  This is jus=
t a first stab at making that happen and we hope to progress this to publis=
h an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly=
.

Paul

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:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No=
n stampare questa mail se non =E8 necessario.


--_000_A09A9E0A4B9C654E8672D1DC003633AE4057006772GRFMBX704BA02_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I guess=
 the discussion is moving from a pure descriptor (which may be static in mo=
st cases) to a sort of API, which could have endless parameters.=



&n=
bsp;


From th=
e current/original webfinger description, the host-meta would mostly be sta=
tic, which implies no API-like, and no parameter, but the lrdd link can typ=
ically be dynamic/API-like (to support
 the template mechanism). As such it could easily accommodate some more par=
ameters as well (in a similar flavor than opensearch), e.g. to request spec=
ific link rels if we want.


&n=
bsp;


What wo=
uld be the scope of supporting uri parameters when accessing host-meta? Doe=
s this intend to save an interaction step?


&n=
bsp;


walter<=
o:p>


 






Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounce=
s@ietf.org]
Per conto di Eran Hammer-Lahav

Inviato: marted=EC 22 novembre 2011 19.33

A: Paul E. Jones; apps-discuss@ietf.org

Cc: 'Joseph Smarr'

Oggetto: Re: [apps-discuss] Webfinger






 


Yes, it=
 is no longer a template and must be converted to href.

&n=
bsp;


As for =
testing support, just check for Subject. Pretty simple to do.


&n=
bsp;


EHL


&n=
bsp;








From: Paul E. Jones [mail=
to:paulej@packetizer.com]


Sent: Tuesday, November 22, 2011 9:27 AM

To: Eran Hammer-Lahav; apps-discuss@ietf.org

Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'

Subject: RE: [apps-discuss] Webfinger






 


A coupl=
e more questions on (3):


&n=
bsp;


Why exp=
and templates like this:


 &=
nbsp;      {


 &=
nbsp;        "rel":"autho=
r",


 &=
nbsp;        "template":"=
htt=
p://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"


 &=
nbsp;      }


&n=
bsp;


The req=
uesting entity could expand the templates.  I can appreciate the reaso=
ning for having “?resource” query the LRDD URL and return back =
the ordered list of links, but why have the server modify
 the discovered templates like the one above?  It’s no longer a =
template, really.  Should we change “template” to be ̶=
0;href”?


&n=
bsp;


If a se=
rver does not understand “?resource”, it’s likely to simp=
ly ignore it.  But, if a client expects it to be processed, it will ca=
use confusion.  Would it be better to introduce /.well-known/host-meta=
-resource? 
 If a 404 is returned, then that is a clear indicator to the client.  =
Other suggestions?


&n=
bsp;


Paul


&n=
bsp;








From: Eran Hammer-Lahav
[mailto:eran@hueniverse.com=
] 

Sent: Monday, November 21, 2011 9:52 PM

To: Paul E. Jones; apps-dis=
cuss@ietf.org

Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'

Subject: RE: [apps-discuss] Webfinger






 


=
1.      
Require the server to offer JRD, leave it to the client to pick one flavor=
.


=
2.      
Host-meta dumps the decision on the applications. You need to decide if We=
bFinger is an application or just syntactic sugar on top of host-meta.=



=
3.      
Expand every template in host-meta + level one LRDD links (excluding t=
emplates in LRDD).


&n=
bsp;


EHL


&n=
bsp;








From: Paul E. Jones
[mailto:paulej@packetizer=
.com]


Sent: Monday, November 21, 2011 7:49 AM

To: Eran Hammer-Lahav; apps=
-discuss@ietf.org

Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'

Subject: RE: [apps-discuss] Webfinger






 


Eran,


&n=
bsp;


Thanks =
for your feedback.  The editorial, structural, and behavioral items we=
’ll addressed (including adhering to host-meta section 4.2).


&n=
bsp;


Let me =
ask about specific comments:


&n=
bsp;


=
1)     
You want to mandate use of JSON, which we also indicated in the draft.&nbs=
p; However, I would personally prefer to give both XML and JSON equal weigh=
t and require both.


=
2)     
You wanted to mandate HTTPS. I’m not opposed, but host-meta does not=
 mandate it.  Shouldn’t we Webfinger requirements on what is the=
re?


=
3)     
Regarding “resource” extension: if I query host-meta, there ma=
y be any number of templates.  Would we want the server to automatical=
ly expand
every template it finds?  Or would we only expand the ‘lr=
dd’ template?  (And how many levels of recursion might be possib=
le?)


&n=
bsp;


Paul


&n=
bsp;








From: Eran Hammer-Lahav
[mailto:eran@hueniverse.com=
] 

Sent: Saturday, November 19, 2011 10:03 AM

To: Paul E. Jones; apps-dis=
cuss@ietf.org

Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook

Subject: RE: [apps-discuss] Webfinger






 


This is=
 a good start. Some feedback and nits:


&n=
bsp;


=
1.      
The protocol flow is incorrect and needs to be adjusted based on the final=
 host-meta specification (RFC 6415). Namely, WebFinger must follow section =
4.2 exactly as specified.


=
2.      
WebFinger should focus exclusively on JSON and mandate WebFinger providers=
 to support the JRD format. This does not preclude using XRD (XML) but it w=
ill ensure that every compliant WebFinger
 implementation provides full JSON support which is much more likely to be =
adopted. This is something we could not do in host-meta due to the late sta=
ge it was in, but this is the right time to make the switch (without taking=
 away any existing functionality).


=
3.      
Are there reasons not to mandate HTTPS?


=
4.      
Section 3 should be a sub-section of the introduction and each example nee=
ds actual JRD code.


&n=
bsp;


In addi=
tion, I would very much like to see WebFinger extend the host-meta endpoint=
 by defining a ‘resource’ query parameter. Using the example in=
 RFC 6415 section 1.1.1 (example not properly encoded
 to make it easier to read):


&n=
bsp;


> GE=
T /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1


&n=
bsp;


 &=
nbsp; {


 &=
nbsp;    "subject":"http://example.com/xy",


&n=
bsp;


 &=
nbsp;    "properties":{


 &=
nbsp;      "http://spec.example.net/color":"red"=



 &=
nbsp;    },


&n=
bsp;


 &=
nbsp;    "links":[


 &=
nbsp;      {


 &=
nbsp;        "rel":"hub&q=
uot;,


 &=
nbsp;        "href":"http://example.com/hub",=



 &=
nbsp;      },


 &=
nbsp;      {


 &=
nbsp;        "rel":"hub&q=
uot;,


 &=
nbsp;        "href":"http://example.com/another/hub&q=
uot;,


 &=
nbsp;      },


 &=
nbsp;      {


 &=
nbsp;        "rel":"autho=
r",


 &=
nbsp;        "href":"http://example.com/john",


 &=
nbsp;      },


 &=
nbsp;      {


 &=
nbsp;        "rel":"autho=
r",


 &=
nbsp;        "template":"=
htt=
p://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"


 &=
nbsp;      }


 &=
nbsp;    ]


 &=
nbsp;  }


&n=
bsp;


The rul=
es for this extension parameter are pretty simple:


&n=
bsp;


=
1.      
JSON is implied. If the server understands ‘?resource’ it MUST=
 return a JRD document.


=
2.      
The subject must be set to the value of the ‘resource’ paramet=
er.


=
3.      
If the server does not support that resource (wrong domain, etc.) it must =
return an empty JRD with the right subject.


=
4.      
The client MUST verify the server supports ‘?resource’ by maki=
ng sure the response is both JRD and has the requested subject (this will e=
nsure full compatibility with any other host-meta
 endpoint).


&n=
bsp;


I would=
 like to see such endpoint extension required for WebFinger so that clients=
 can make a single call and get the full WebFinger result in JSON. This wou=
ld significantly improve adoption and
 usability, and adds very little work to providers.


&n=
bsp;


EHL


&n=
bsp;


&n=
bsp;





 


Folks,


 


We just submitted this:


http://www.ietf.org/i=
nternet-drafts/draft-jones-appsawg-webfinger-00.txt

 


The tools for Webfinger are now=
 defined, but the procedures need to be clearer with respect to what most o=
f us understand as “webfinger”.  This is just a first stab=
 at making that happen and we hope to progress this to
 publish an RFC in the application area.


 


We welcome any comments you hav=
e on the topic, either privately or publicly.


 


Paul


 





















=
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_A09A9E0A4B9C654E8672D1DC003633AE4057006772GRFMBX704BA02_--

--_7294c471-aea8-46ae-b3fb-650a059446cb_
Content-Description: logo Ambiente_foglia.jpg
Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg"
Content-Disposition: inline; filename="logo Ambiente_foglia.jpg"
Content-Transfer-Encoding: base64
Content-ID: 00000000000000000000000000000001@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=

--_7294c471-aea8-46ae-b3fb-650a059446cb_--

From paulej@packetizer.com  Tue Nov 22 10:49:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA7521F8A56 for ; Tue, 22 Nov 2011 10:49:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076,  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 aYQ0hKEWgS9R for ; Tue, 22 Nov 2011 10:49:09 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 96A0421F89B8 for ; Tue, 22 Nov 2011 10:49:09 -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 pAMIn43D013764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Nov 2011 13:49:05 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321987745; bh=UWsutmI5Gx90z6pGJnbLkzjww5mz2m+1KYhwiMgmbs4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=JatPWj+iF/1FMdRq56yMyY1TkKKG2Tz+R6XGf08qQ1o74DbVuL7SbYSReyz9wK1t9 DG2n0bMJmHyWXhRW/lb0AeoTUoBesbAT6xFMINmhCCgQCKv38gpoZDTHw73zRaRrox MgO29Z8Qxxh7cbHwwp1FTnuQrzZYYFIKgL58sM1g=
From: "Paul E. Jones" 
To: "'Eran Hammer-Lahav'" , 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <086001cca93b$f455cc90$dd0165b0$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Tue, 22 Nov 2011 13:48:59 -0500
Message-ID: <08c601cca947$6630d430$32927c90$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_08C7_01CCA91D.7D5F8720"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnysAgBEW78CHWIk+QIu/EtFAjl3mf+UfNH0UA==
Content-Language: en-us
Cc: 'Joseph Smarr' 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 18:49:13 -0000

This is a multipart message in MIME format.

------=_NextPart_000_08C7_01CCA91D.7D5F8720
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ah. yes.  Missed that suggestion on Subject.  That would work.

 

Thanks,

Paul

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Tuesday, November 22, 2011 1:33 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

 

Yes, it is no longer a template and must be converted to href.

 

As for testing support, just check for Subject. Pretty simple to do.

 

EHL

 

From: Paul E. Jones [mailto:paulej@packetizer.com] 
Sent: Tuesday, November 22, 2011 9:27 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

 

A couple more questions on (3):

 

Why expand templates like this:

        {

          "rel":"author",

 
"template":"http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy"

        }

 

The requesting entity could expand the templates.  I can appreciate the
reasoning for having "?resource" query the LRDD URL and return back the
ordered list of links, but why have the server modify the discovered
templates like the one above?  It's no longer a template, really.  Should we
change "template" to be "href"?

 

If a server does not understand "?resource", it's likely to simply ignore
it.  But, if a client expects it to be processed, it will cause confusion.
Would it be better to introduce /.well-known/host-meta-resource?  If a 404
is returned, then that is a clear indicator to the client.  Other
suggestions?

 

Paul

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

 

1.       Require the server to offer JRD, leave it to the client to pick one
flavor.

2.       Host-meta dumps the decision on the applications. You need to
decide if WebFinger is an application or just syntactic sugar on top of
host-meta.

3.       Expand every template in host-meta + level one LRDD links
(excluding templates in LRDD).

 

EHL

 

From: Paul E. Jones [mailto:paulej@packetizer.com] 
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

 

Eran,

 

Thanks for your feedback.  The editorial, structural, and behavioral items
we'll addressed (including adhering to host-meta section 4.2).

 

Let me ask about specific comments:

 

1)      You want to mandate use of JSON, which we also indicated in the
draft.  However, I would personally prefer to give both XML and JSON equal
weight and require both.

2)      You wanted to mandate HTTPS. I'm not opposed, but host-meta does not
mandate it.  Shouldn't we Webfinger requirements on what is there?

3)      Regarding "resource" extension: if I query host-meta, there may be
any number of templates.  Would we want the server to automatically expand
every template it finds?  Or would we only expand the 'lrdd' template?  (And
how many levels of recursion might be possible?)

 

Paul

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

 

This is a good start. Some feedback and nits:

 

1.       The protocol flow is incorrect and needs to be adjusted based on
the final host-meta specification (RFC 6415). Namely, WebFinger must follow
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger
providers to support the JRD format. This does not preclude using XRD (XML)
but it will ensure that every compliant WebFinger implementation provides
full JSON support which is much more likely to be adopted. This is something
we could not do in host-meta due to the late stage it was in, but this is
the right time to make the switch (without taking away any existing
functionality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each
example needs actual JRD code.

 

In addition, I would very much like to see WebFinger extend the host-meta
endpoint by defining a 'resource' query parameter. Using the example in RFC
6415 section 1.1.1 (example not properly encoded to make it easier to read):

 

> GET /.well-known/host-meta?resource=http://example.com/xy HTTP/1.1

 

   {

      "subject":"http://example.com/xy",

 

      "properties":{

        "http://spec.example.net/color":"red"

      },

 

      "links":[

        {

          "rel":"hub",

          "href":"http://example.com/hub",

        },

        {

          "rel":"hub",

          "href":"http://example.com/another/hub",

        },

        {

          "rel":"author",

          "href":"http://example.com/john",

        },

        {

          "rel":"author",

 
"template":"http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy"

        }

      ]

    }

 

The rules for this extension parameter are pretty simple:

 

1.       JSON is implied. If the server understands '?resource' it MUST
return a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.)
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making
sure the response is both JRD and has the requested subject (this will
ensure full compatibility with any other host-meta endpoint).

 

I would like to see such endpoint extension required for WebFinger so that
clients can make a single call and get the full WebFinger result in JSON.
This would significantly improve adoption and usability, and adds very
little work to providers.

 

EHL

 

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

 

Folks,

 

We just submitted this:

http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

 

The tools for Webfinger are now defined, but the procedures need to be
clearer with respect to what most of us understand as "webfinger".  This is
just a first stab at making that happen and we hope to progress this to
publish an RFC in the application area.

 

We welcome any comments you have on the topic, either privately or publicly.

 

Paul

 


------=_NextPart_000_08C7_01CCA91D.7D5F8720
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Ah… yes.  Missed that suggestion on =
Subject.  That would work.
 
Thanks,
Paul
 
From:=
 =
Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Tuesday, =
November 22, 2011 1:33 PM
To: Paul E. Jones; =
apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; =
'Blaine Cook'
Subject: RE: [apps-discuss] =
Webfinger
 
Yes, it is no longer a template and must be =
converted to href.
 
As for testing support, =
just check for Subject. Pretty simple to do.
 
EHL
 
From:=
 =
Paul E. Jones [mailto:paulej@packetizer.=
com] 
Sent: Tuesday, November 22, 2011 9:27 =
AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc:=
 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine =
Cook'
Subject: RE: [apps-discuss] =
Webfinger
 
A couple more questions on =
(3):
 
Why expand templates =
like this:
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "template":"http=
://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"
        =
}
 
The requesting entity =
could expand the templates.  I can appreciate the reasoning for =
having “?resource” query the LRDD URL and return back the =
ordered list of links, but why have the server modify the discovered =
templates like the one above?  It’s no longer a template, =
really.  Should we change “template” to be =
“href”?
 
If a server does not =
understand “?resource”, it’s likely to simply ignore =
it.  But, if a client expects it to be processed, it will cause =
confusion.  Would it be better to introduce =
/.well-known/host-meta-resource?  If a 404 is returned, then that =
is a clear indicator to the client.  Other =
suggestions?
 
Paul
 
From:=
 =
Eran Hammer-Lahav [mailto:eran@hueniverse.com]=
 
Sent: Monday, November 21, 2011 9:52 PM
To: =
Paul E. Jones; apps-discuss@ietf.org
Cc:=
 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine =
Cook'
Subject: RE: [apps-discuss] =
Webfinger
 
1.       =
Require the =
server to offer JRD, leave it to the client to pick one =
flavor.
2.       =
Host-meta =
dumps the decision on the applications. You need to decide if WebFinger =
is an application or just syntactic sugar on top of =
host-meta.
3.       =
Expand =
every template in host-meta + level one LRDD links (excluding templates =
in LRDD).
 
EHL
 
From:=
 =
Paul E. Jones [mailto:paulej@packetizer.=
com] 
Sent: Monday, November 21, 2011 7:49 =
AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc:=
 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine =
Cook'
Subject: RE: [apps-discuss] =
Webfinger
 
Eran,
 
Thanks for your =
feedback.  The editorial, structural, and behavioral items =
we’ll addressed (including adhering to host-meta section =
4.2).
 
Let me ask about =
specific comments:
 
1)      =
You want to =
mandate use of JSON, which we also indicated in the draft.  =
However, I would personally prefer to give both XML and JSON equal =
weight and require both.
2)      =
You wanted =
to mandate HTTPS. I’m not opposed, but host-meta does not mandate =
it.  Shouldn’t we Webfinger requirements on what is =
there?
3)      =
Regarding =
“resource” extension: if I query host-meta, there may be any =
number of templates.  Would we want the server to automatically =
expand every template it finds?  Or would we only expand the =
‘lrdd’ template?  (And how many levels of recursion =
might be possible?)
 
Paul
 
From:=
 =
Eran Hammer-Lahav [mailto:eran@hueniverse.com]=
 
Sent: Saturday, November 19, 2011 10:03 AM
To: =
Paul E. Jones; apps-discuss@ietf.org
Cc:=
 Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: =
[apps-discuss] Webfinger
 
This is a good start. Some feedback and =
nits:
 
1.       =
The =
protocol flow is incorrect and needs to be adjusted based on the final =
host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.
2.       =
WebFinger =
should focus exclusively on JSON and mandate WebFinger providers to =
support the JRD format. This does not preclude using XRD (XML) but it =
will ensure that every compliant WebFinger implementation provides full =
JSON support which is much more likely to be adopted. This is something =
we could not do in host-meta due to the late stage it was in, but this =
is the right time to make the switch (without taking away any existing =
functionality).
3.       =
Are there =
reasons not to mandate HTTPS?
4.       =
Section 3 =
should be a sub-section of the introduction and each example needs =
actual JRD code.
 
In addition, I would =
very much like to see WebFinger extend the host-meta endpoint by =
defining a ‘resource’ query parameter. Using the example in =
RFC 6415 section 1.1.1 (example not properly encoded to make it easier =
to read):
 
> GET =
/.well-known/host-meta?resource=3Dhttp://example.com/xy =
HTTP/1.1
 
   =
{
      =
"subject":"http://example.com/xy",
 
      =
"properties":{
        =
"http://spec.example.net/color&=
quot;:"red"
      =
},
 
      =
"links":[
        =
{
        &=
nbsp; "rel":"hub",
        &=
nbsp; "href":"http://example.com/hub",
        =
},
        =
{
        &=
nbsp; "rel":"hub",
        &=
nbsp; "href":"http://example.com/another/hub",
        =
},
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "href":"http://example.com/john",<=
/o:p>
        =
},
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "template":"http=
://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"
        =
}
      =
]
    }
 
The rules for this =
extension parameter are pretty simple:
 
1.       =
JSON is =
implied. If the server understands ‘?resource’ it MUST =
return a JRD document.
2.       =
The subject =
must be set to the value of the ‘resource’ =
parameter.
3.       =
If the =
server does not support that resource (wrong domain, etc.) it must =
return an empty JRD with the right subject.
4.       =
The client =
MUST verify the server supports ‘?resource’ by making sure =
the response is both JRD and has the requested subject (this will ensure =
full compatibility with any other host-meta =
endpoint).
 
I would like to see such =
endpoint extension required for WebFinger so that clients can make a =
single call and get the full WebFinger result in JSON. This would =
significantly improve adoption and usability, and adds very little work =
to providers.
 
EHL
 
 
From:=
 =
apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] On Behalf Of Paul E. =
Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc:=
 Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] =
Webfinger
 
Folks,
 
We just =
submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinge=
r-00.txt
 
The tools for Webfinger are now defined, but the =
procedures need to be clearer with respect to what most of us understand =
as “webfinger”.  This is just a first stab at making =
that happen and we hope to progress this to publish an RFC in the =
application area.
 
We welcome =
any comments you have on the topic, either privately or =
publicly.
 
Paul
 

------=_NextPart_000_08C7_01CCA91D.7D5F8720--


From paulej@packetizer.com  Tue Nov 22 10:54:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E564111E80A6 for ; Tue, 22 Nov 2011 10:54:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.815
X-Spam-Level: 
X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=-0.637, 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 uJ0ScQLPDoDe for ; Tue, 22 Nov 2011 10:54:44 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A5A6511E8090 for ; Tue, 22 Nov 2011 10:54:43 -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 pAMIse8C013856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Nov 2011 13:54:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321988081; bh=DxSQtjZzvC12DpMCTbCfAjLnBlwUlICnJn9pOpb57o8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=FrtNYx87JbVEPslOdy8xlLA7sLnVU+XAMYlM/LukCN65DrNsReMeaeKHh9ReLDfgr /4dHcUNE2YewmQMn51d8FQ9hKwC+xy2xCniGgrDufFMmsn92/M1I7xpKYNZk8VKuHz 4zbzMzUQZOJcl8yLB+YF6eqlxhyd7M+JK+nhL0Z0=
From: "Paul E. Jones" 
To: "'Goix Laurent Walter'" , "'Eran Hammer-Lahav'" , 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>	<90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>	<06b001cca865$1d9ccb80$58d66280$@packetizer.com>	<90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET>	<086001cca93b$f455cc90$dd0165b0$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Date: Tue, 22 Nov 2011 13:54:35 -0500
Message-ID: <08dc01cca948$2e569f30$8b03dd90$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_08DD_01CCA91E.45879C10"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnysAgBEW78CHWIk+QIu/EtFAjl3mf8CNMDi15RrLE+w
Content-Language: en-us
Cc: 'Joseph Smarr' 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 18:54:49 -0000

This is a multipart message in MIME format.

------=_NextPart_000_08DD_01CCA91E.45879C10
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_08DE_01CCA91E.45879C10"


------=_NextPart_001_08DE_01CCA91E.45879C10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Walter,

=20

Including the =91resource=92 parameter could remove the need to further =
process
the templates on the client side and to perform a second query for the
=93lrdd=94 XRD/JRD document.  If the server implementation does not =
support the
=93resource=94 parameter, then the client would have to go about it as =
it would
today.

=20

I like the idea of reducing complexity on the client, but if resource is
optional, then we do not actually reduce the complexity at all.  It does
potentially reduce the time required to fetch the information by one
round-trip to the server.  Is that worth it?  Perhaps.  For most data, =
there
are three queries:

1)      host-meta

2)      LRDD

3)      Actual data sought (e.g., an avatar file)

=20

Introducing =93resource=94 means we do to queries:

1)      host-mesa?resource

2)      Actual data sought (e.g., an avatar file)

=20

That sounds good for a single piece of information.  However, if the =
client
needs to perform 10 queries for 10 links found, then that one additional
step is little savings.  I=92m on the fence over it.

=20

Paul

=20

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20
Sent: Tuesday, November 22, 2011 1:42 PM
To: Eran Hammer-Lahav; Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Subject: R: [apps-discuss] Webfinger

=20

I guess the discussion is moving from a pure descriptor (which may be =
static
in most cases) to a sort of API, which could have endless parameters.

=20

>From the current/original webfinger description, the host-meta would =
mostly
be static, which implies no API-like, and no parameter, but the lrdd =
link
can typically be dynamic/API-like (to support the template mechanism). =
As
such it could easily accommodate some more parameters as well (in a =
similar
flavor than opensearch), e.g. to request specific link rels if we want.

=20

What would be the scope of supporting uri parameters when accessing
host-meta? Does this intend to save an interaction step?

=20

walter

=20

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
Per
conto di Eran Hammer-Lahav
Inviato: marted=EC 22 novembre 2011 19.33
A: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Oggetto: Re: [apps-discuss] Webfinger

=20

Yes, it is no longer a template and must be converted to href.

=20

As for testing support, just check for Subject. Pretty simple to do.

=20

EHL

=20

From: Paul E. Jones [mailto:paulej@packetizer.com]=20
Sent: Tuesday, November 22, 2011 9:27 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

=20

A couple more questions on (3):

=20

Why expand templates like this:

        {

          "rel":"author",

=20
"template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"

        }

=20

The requesting entity could expand the templates.  I can appreciate the
reasoning for having =93?resource=94 query the LRDD URL and return back =
the
ordered list of links, but why have the server modify the discovered
templates like the one above?  It=92s no longer a template, really.  =
Should we
change =93template=94 to be =93href=94?

=20

If a server does not understand =93?resource=94, it=92s likely to simply =
ignore
it.  But, if a client expects it to be processed, it will cause =
confusion.
Would it be better to introduce /.well-known/host-meta-resource?  If a =
404
is returned, then that is a clear indicator to the client.  Other
suggestions?

=20

Paul

=20

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20
Sent: Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

=20

1.       Require the server to offer JRD, leave it to the client to pick =
one
flavor.

2.       Host-meta dumps the decision on the applications. You need to
decide if WebFinger is an application or just syntactic sugar on top of
host-meta.

3.       Expand every template in host-meta + level one LRDD links
(excluding templates in LRDD).

=20

EHL

=20

From: Paul E. Jones [mailto:paulej@packetizer.com]=20
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

=20

Eran,

=20

Thanks for your feedback.  The editorial, structural, and behavioral =
items
we=92ll addressed (including adhering to host-meta section 4.2).

=20

Let me ask about specific comments:

=20

1)      You want to mandate use of JSON, which we also indicated in the
draft.  However, I would personally prefer to give both XML and JSON =
equal
weight and require both.

2)      You wanted to mandate HTTPS. I=92m not opposed, but host-meta =
does not
mandate it.  Shouldn=92t we Webfinger requirements on what is there?

3)      Regarding =93resource=94 extension: if I query host-meta, there =
may be
any number of templates.  Would we want the server to automatically =
expand
every template it finds?  Or would we only expand the =91lrdd=92 =
template?  (And
how many levels of recursion might be possible?)

=20

Paul

=20

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

=20

This is a good start. Some feedback and nits:

=20

1.       The protocol flow is incorrect and needs to be adjusted based =
on
the final host-meta specification (RFC 6415). Namely, WebFinger must =
follow
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate =
WebFinger
providers to support the JRD format. This does not preclude using XRD =
(XML)
but it will ensure that every compliant WebFinger implementation =
provides
full JSON support which is much more likely to be adopted. This is =
something
we could not do in host-meta due to the late stage it was in, but this =
is
the right time to make the switch (without taking away any existing
functionality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each
example needs actual JRD code.

=20

In addition, I would very much like to see WebFinger extend the =
host-meta
endpoint by defining a =91resource=92 query parameter. Using the example =
in RFC
6415 section 1.1.1 (example not properly encoded to make it easier to =
read):

=20

> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1

=20

   {

      "subject":"http://example.com/xy",

=20

      "properties":{

        "http://spec.example.net/color":"red"

      },

=20

      "links":[

        {

          "rel":"hub",

          "href":"http://example.com/hub",

        },

        {

          "rel":"hub",

          "href":"http://example.com/another/hub",

        },

        {

          "rel":"author",

          "href":"http://example.com/john",

        },

        {

          "rel":"author",

=20
"template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"

        }

      ]

    }

=20

The rules for this extension parameter are pretty simple:

=20

1.       JSON is implied. If the server understands =91?resource=92 it =
MUST
return a JRD document.

2.       The subject must be set to the value of the =91resource=92 =
parameter.

3.       If the server does not support that resource (wrong domain, =
etc.)
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports =91?resource=92 by =
making
sure the response is both JRD and has the requested subject (this will
ensure full compatibility with any other host-meta endpoint).

=20

I would like to see such endpoint extension required for WebFinger so =
that
clients can make a single call and get the full WebFinger result in =
JSON.
This would significantly improve adoption and usability, and adds very
little work to providers.

=20

EHL

=20

=20

From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

=20

Folks,

=20

We just submitted this:

http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

=20

The tools for Webfinger are now defined, but the procedures need to be
clearer with respect to what most of us understand as =93webfinger=94.  =
This is
just a first stab at making that happen and we hope to progress this to
publish an RFC in the application area.

=20

We welcome any comments you have on the topic, either privately or =
publicly.

=20

Paul

=20


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_08DE_01CCA91E.45879C10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Walter,
 
Including the =
‘resource’ parameter could remove the need to further =
process the templates on the client side and to perform a second query =
for the “lrdd” XRD/JRD document.=A0 If the server =
implementation does not support the “resource” parameter, =
then the client would have to go about it as it would =
today.
 
I like the idea of =
reducing complexity on the client, but if resource is optional, then we =
do not actually reduce the complexity at all.=A0 It does potentially =
reduce the time required to fetch the information by one round-trip to =
the server.=A0 Is that worth it?=A0 Perhaps.=A0 For most data, there are =
three queries:
1)      =
host-meta
2)      =
LRDD
3)      =
Actual data =
sought (e.g., an avatar file)
 
Introducing =
“resource” means we do to queries:
1)      =
host-mesa?resource
2)      =
Actual data =
sought (e.g., an avatar file)
 
That sounds good for a =
single piece of information.=A0 However, if the client needs to perform =
10 queries for 10 links found, then that one additional step is little =
savings.=A0 I’m on the fence over it.
 
Paul
 
From:=
 =
Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] =

Sent: Tuesday, November 22, 2011 1:42 PM
To: Eran =
Hammer-Lahav; Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph =
Smarr'
Subject: R: [apps-discuss] =
Webfinger
 
I guess the discussion is moving from a pure =
descriptor (which may be static in most cases) to a sort of API, which =
could have endless parameters.
 
From the current/original webfinger description, =
the host-meta would mostly be static, which implies no API-like, and no =
parameter, but the lrdd link can typically be dynamic/API-like (to =
support the template mechanism). As such it could easily accommodate =
some more parameters as well (in a similar flavor than opensearch), e.g. =
to request specific link rels if we want.
 
What would be the scope of supporting uri =
parameters when accessing host-meta? Does this intend to save an =
interaction step?
 
walter
 
Da: apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] Per conto di Eran =
Hammer-Lahav
Inviato: marted=EC 22 novembre 2011 =
19.33
A: Paul E. Jones; apps-discuss@ietf.org
Cc:=
 'Joseph Smarr'
Oggetto: Re: [apps-discuss] =
Webfinger
 
Yes, it is no longer a =
template and must be converted to href.
 
As for testing support, just check for Subject. =
Pretty simple to do.
 
EHL
 
From:=
 =
Paul E. Jones [mailto:paulej@packetizer.=
com] 
Sent: Tuesday, November 22, 2011 9:27 =
AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc:=
 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine =
Cook'
Subject: RE: [apps-discuss] Webfinger
 
A couple more questions =
on (3):
 
Why expand templates like this:
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "template":"http=
://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"<=
span lang=3DFR>
        =
}
 
The requesting entity could expand the =
templates.  I can appreciate the reasoning for having =
“?resource” query the LRDD URL and return back the ordered =
list of links, but why have the server modify the discovered templates =
like the one above?  It’s no longer a template, really.  =
Should we change “template” to be =
“href”?
 
If a server does not understand =
“?resource”, it’s likely to simply ignore it.  =
But, if a client expects it to be processed, it will cause =
confusion.  Would it be better to introduce =
/.well-known/host-meta-resource?  If a 404 is returned, then that =
is a clear indicator to the client.  Other suggestions?
 
Paul
 
From:=
 =
Eran Hammer-Lahav [mailto:eran@hueniverse.com]=
 
Sent: Monday, November 21, 2011 9:52 PM
To: =
Paul E. Jones; apps-discuss@ietf.org
Cc:=
 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine =
Cook'
Subject: RE: [apps-discuss] Webfinger
 
1.       =
Require the =
server to offer JRD, leave it to the client to pick one =
flavor.
2.       =
Host-meta =
dumps the decision on the applications. You need to decide if WebFinger =
is an application or just syntactic sugar on top of =
host-meta.
3.       =
Expand =
every template in host-meta + level one LRDD links (excluding templates =
in LRDD).
 
EHL
 
From:=
 =
Paul E. Jones [mailto:paulej@packetizer.=
com] 
Sent: Monday, November 21, 2011 7:49 =
AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc:=
 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine =
Cook'
Subject: RE: [apps-discuss] Webfinger
 
Eran,
 
Thanks for your feedback.  The editorial, =
structural, and behavioral items we’ll addressed (including =
adhering to host-meta section 4.2).
 
Let me ask about specific comments:
 
1)      =
You want to =
mandate use of JSON, which we also indicated in the draft.  =
However, I would personally prefer to give both XML and JSON equal =
weight and require both.
2)      =
You wanted =
to mandate HTTPS. I’m not opposed, but host-meta does not mandate =
it.  Shouldn’t we Webfinger requirements on what is =
there?
3)      =
Regarding =
“resource” extension: if I query host-meta, there may be any =
number of templates.  Would we want the server to automatically =
expand every template it finds?  Or would we only expand the =
‘lrdd’ template?  (And how many levels of recursion =
might be possible?)
 
Paul
 
From:=
 =
Eran Hammer-Lahav [mailto:eran@hueniverse.com]=
 
Sent: Saturday, November 19, 2011 10:03 AM
To: =
Paul E. Jones; apps-discuss@ietf.org
Cc:=
 Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: =
[apps-discuss] Webfinger
 
This is a good start. =
Some feedback and nits:
 
1.       =
The =
protocol flow is incorrect and needs to be adjusted based on the final =
host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.
2.       =
WebFinger =
should focus exclusively on JSON and mandate WebFinger providers to =
support the JRD format. This does not preclude using XRD (XML) but it =
will ensure that every compliant WebFinger implementation provides full =
JSON support which is much more likely to be adopted. This is something =
we could not do in host-meta due to the late stage it was in, but this =
is the right time to make the switch (without taking away any existing =
functionality).
3.       =
Are there =
reasons not to mandate HTTPS?
4.       =
Section 3 =
should be a sub-section of the introduction and each example needs =
actual JRD code.
 
In addition, I would very much like to see =
WebFinger extend the host-meta endpoint by defining a =
‘resource’ query parameter. Using the example in RFC 6415 =
section 1.1.1 (example not properly encoded to make it easier to =
read):
 
> GET =
/.well-known/host-meta?resource=3Dhttp://example.com/xy =
HTTP/1.1
 
   {
      =
"subject":"http://example.com/xy",
 
      =
"properties":{
        =
"http://spec.example.net/color&=
quot;:"red"
      },
 
      =
"links":[
        =
{
        &=
nbsp; "rel":"hub",
        &=
nbsp; "href":"http://example.com/hub",<=
span lang=3DFR>
        =
},
        =
{
        &=
nbsp; "rel":"hub",
        &=
nbsp; "href":"http://example.com/another/hub",
        =
},
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "href":"http://example.com/john",
        =
},
        =
{
        &=
nbsp; "rel":"author",
        &=
nbsp; "template":"http=
://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"<=
span lang=3DFR>
        =
}
      ]
    }
 
The rules for this extension parameter are =
pretty simple:
 
1.       =
JSON is =
implied. If the server understands ‘?resource’ it MUST =
return a JRD document.
2.       =
The subject =
must be set to the value of the ‘resource’ =
parameter.
3.       =
If the =
server does not support that resource (wrong domain, etc.) it must =
return an empty JRD with the right subject.
4.       =
The client =
MUST verify the server supports ‘?resource’ by making sure =
the response is both JRD and has the requested subject (this will ensure =
full compatibility with any other host-meta endpoint).
 
I would like to see such endpoint extension =
required for WebFinger so that clients can make a single call and get =
the full WebFinger result in JSON. This would significantly improve =
adoption and usability, and adds very little work to =
providers.
 
EHL
 
 
From:=
 =
apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] On Behalf Of Paul E. =
Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc:=
 Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] =
Webfinger
 
Folks,
 
We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinge=
r-00.txt
 
The tools for Webfinger are now defined, but the =
procedures need to be clearer with respect to what most of us understand =
as “webfinger”.  This is just a first stab at making =
that happen and we hope to progress this to publish an RFC in the =
application area.
 
We welcome any comments you have on the topic, either =
privately or publicly.
 
Paul
 
=
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_08DE_01CCA91E.45879C10--

------=_NextPart_000_08DD_01CCA91E.45879C10
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_08DD_01CCA91E.45879C10--


From eran@hueniverse.com  Tue Nov 22 11:09:21 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B61921F8548 for ; Tue, 22 Nov 2011 11:09:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.338
X-Spam-Level: 
X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=-1.160, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 HustwDegD2fy for ; Tue, 22 Nov 2011 11:09:16 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 9326821F851A for ; Tue, 22 Nov 2011 11:09:15 -0800 (PST)
Received: (qmail 32008 invoked from network); 22 Nov 2011 19:09:09 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Nov 2011 19:09:08 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 22 Nov 2011 12:08:56 -0700
From: Eran Hammer-Lahav 
To: Goix Laurent Walter , "Paul E. Jones" , "apps-discuss@ietf.org" 
Date: Tue, 22 Nov 2011 12:08:49 -0700
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnysAgBEW78CHWIk+ZSf7BkwgAAksVCAAAGYgIAACKmw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234526735F10D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <086001cca93b$f455cc90$dd0165b0$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_004_90C41DD21FB7C64BB94121FBBC2E7234526735F10DP3PW5EX1MB01E_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: 'Joseph Smarr' 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 19:09:21 -0000

--_004_90C41DD21FB7C64BB94121FBBC2E7234526735F10DP3PW5EX1MB01E_
Content-Type: multipart/alternative;
	boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234526735F10DP3PW5EX1MB01E_"

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F10DP3PW5EX1MB01E_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Still very much static. The two parameters I proposed are purely filters on=
 the static data meant to make life easier for developers consuming this, g=
iven that 99% they just want one rel for one resource, and in JSON.

EHL

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]
Sent: Tuesday, November 22, 2011 10:42 AM
To: Eran Hammer-Lahav; Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Subject: R: [apps-discuss] Webfinger

I guess the discussion is moving from a pure descriptor (which may be stati=
c in most cases) to a sort of API, which could have endless parameters.

>From the current/original webfinger description, the host-meta would mostly=
 be static, which implies no API-like, and no parameter, but the lrdd link =
can typically be dynamic/API-like (to support the template mechanism). As s=
uch it could easily accommodate some more parameters as well (in a similar =
flavor than opensearch), e.g. to request specific link rels if we want.

What would be the scope of supporting uri parameters when accessing host-me=
ta? Does this intend to save an interaction step?

walter

Da: apps-discuss-bounces@ietf.org [ma=
ilto:apps-discuss-bounces@ietf.org] Per conto di Eran Hammer-Lahav
Inviato: marted=EC 22 novembre 2011 19.33
A: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Oggetto: Re: [apps-discuss] Webfinger

Yes, it is no longer a template and must be converted to href.

As for testing support, just check for Subject. Pretty simple to do.

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Tuesday, November 22, 2011 9:27 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

A couple more questions on (3):

Why expand templates like this:
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }

The requesting entity could expand the templates.  I can appreciate the rea=
soning for having "?resource" query the LRDD URL and return back the ordere=
d list of links, but why have the server modify the discovered templates li=
ke the one above?  It's no longer a template, really.  Should we change "te=
mplate" to be "href"?

If a server does not understand "?resource", it's likely to simply ignore i=
t.  But, if a client expects it to be processed, it will cause confusion.  =
Would it be better to introduce /.well-known/host-meta-resource?  If a 404 =
is returned, then that is a clear indicator to the client.  Other suggestio=
ns?

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger


1.       Require the server to offer JRD, leave it to the client to pick on=
e flavor.

2.       Host-meta dumps the decision on the applications. You need to deci=
de if WebFinger is an application or just syntactic sugar on top of host-me=
ta.

3.       Expand every template in host-meta + level one LRDD links (excludi=
ng templates in LRDD).

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

Eran,

Thanks for your feedback.  The editorial, structural, and behavioral items =
we'll addressed (including adhering to host-meta section 4.2).

Let me ask about specific comments:


1)      You want to mandate use of JSON, which we also indicated in the dra=
ft.  However, I would personally prefer to give both XML and JSON equal wei=
ght and require both.

2)      You wanted to mandate HTTPS. I'm not opposed, but host-meta does no=
t mandate it.  Shouldn't we Webfinger requirements on what is there?

3)      Regarding "resource" extension: if I query host-meta, there may be =
any number of templates.  Would we want the server to automatically expand =
every template it finds?  Or would we only expand the 'lrdd' template?  (An=
d how many levels of recursion might be possible?)

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

This is a good start. Some feedback and nits:


1.       The protocol flow is incorrect and needs to be adjusted based on t=
he final host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger p=
roviders to support the JRD format. This does not preclude using XRD (XML) =
but it will ensure that every compliant WebFinger implementation provides f=
ull JSON support which is much more likely to be adopted. This is something=
 we could not do in host-meta due to the late stage it was in, but this is =
the right time to make the switch (without taking away any existing functio=
nality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each exa=
mple needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta e=
ndpoint by defining a 'resource' query parameter. Using the example in RFC =
6415 section 1.1.1 (example not properly encoded to make it easier to read)=
:

> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1

   {
      "subject":"http://example.com/xy",

      "properties":{
        "http://spec.example.net/color":"red"
      },

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/hub",
        },
        {
          "rel":"hub",
          "href":"http://example.com/another/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/john",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }
      ]
    }

The rules for this extension parameter are pretty simple:


1.       JSON is implied. If the server understands '?resource' it MUST ret=
urn a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.) =
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making s=
ure the response is both JRD and has the requested subject (this will ensur=
e full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that =
clients can make a single call and get the full WebFinger result in JSON. T=
his would significantly improve adoption and usability, and adds very littl=
e work to providers.

EHL


From: apps-discuss-bounces@ietf.org [=
mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

Folks,

We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

The tools for Webfinger are now defined, but the procedures need to be clea=
rer with respect to what most of us understand as "webfinger".  This is jus=
t a first stab at making that happen and we hope to progress this to publis=
h an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly=
.

Paul

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:image001.gif@01CCA907.1CB1C7A0]Rispetta l'ambiente. Non stampare quest=
a mail se non =E8 necessario.



--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F10DP3PW5EX1MB01E_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Still very much static. The two parameters I proposed are pur=
ely filters on the static data meant to make life easier for developers con=
suming this, given that 99% they just want one rel for one resource, and in=
 JSON.
 
EHL
 
F=
rom: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] Sent: Tuesday, November 22, 2011 10:42 AM
To: Eran Hamme=
r-Lahav; Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'<=
br>Subject: R: [apps-discuss] Webfinger
<=
/div>
 
I guess the discussion is moving from a pure descrip=
tor (which may be static in most cases) to a sort of API, which could have =
endless parameters.
 <=
/o:p>
From the=
 current/original webfinger description, the host-meta would mostly be stat=
ic, which implies no API-like, and no parameter, but the lrdd link can typi=
cally be dynamic/API-like (to support the template mechanism). As such it c=
ould easily accommodate some more parameters as well (in a similar flavor t=
han opensearch), e.g. to request specific link rels if we want.
 
What would be the scope of supporting u=
ri parameters when accessing host-meta? Does this intend to save an interac=
tion step?
 
walter
 
 
Yes, it is no longer a template and must be con=
verted to href.
 
As for testi=
ng support, just check for Subject. Pretty simple to do.
 
EHL=

 
From: Paul E. Jones [mailto:p=
aulej@packetizer.com] 
Sent: Tuesday, November 22, 2011 9:27 =
AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueir=
o'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger
 <=
span lang=3DFR>
A couple more questions on (3):
 
Why expand templates like this:
&nbs=
p;       {<=
/span>
  &n=
bsp;       "rel":"author"=
,
         =
; "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexampl=
e.com%2Fxy"
     &n=
bsp;  }
 
The requesting =
entity could expand the templates.  I can appreciate the reasoning for=
 having “?resource” query the LRDD URL and return back the orde=
red list of links, but why have the server modify the discovered templates =
like the one above?  It’s no longer a template, really.  Sh=
ould we change “template” to be “href”?
 
If a server does not understand “=
?resource”, it’s likely to simply ignore it.  But, if a cl=
ient expects it to be processed, it will cause confusion.  Would it be=
 better to introduce /.well-known/host-meta-resource?  If a 404 is ret=
urned, then that is a clear indicator to the client.  Other suggestion=
s?
 
<=
p class=3DMsoNormal>Paul
=
 
<=
p class=3DMsoNormal>From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Monday, No=
vember 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; =
'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] We=
bfinger
 
1.       Req=
uire the server to offer JRD, leave it to the client to pick one flavor.
2.       Host-meta dumps=
 the decision on the applications. You need to decide if WebFinger is an ap=
plication or just syntactic sugar on top of host-meta.
3.&nbs=
p;      Expand every template in host-m=
eta + level one LRDD links (excluding templates in LRDD).
 
EHL=

 
From: Paul E. Jones [mailto:p=
aulej@packetizer.com] 
Sent: Monday, November 21, 2011 7:49 A=
M
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro=
'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger
 
Eran,
 
Thanks for=
 your feedback.  The editorial, structural, and behavioral items we=
217;ll addressed (including adhering to host-meta section 4.2).
 
Let me ask about specific comments:
 
1)      You want to mandate use of JSON, which we also indicated in the draf=
t.  However, I would personally prefer to give both XML and JSON equal=
 weight and require both.
2)      You wanted to mandate HTTPS. I’m not opposed, but host-meta do=
es not mandate it.  Shouldn’t we Webfinger requirements on what =
is there?
3)      Regarding=
 “resource” extension: if I query host-meta, there may be any n=
umber of templates.  Would we want the server to automatically expand =
every template it finds?  Or would we only expand the ‘lr=
dd’ template?  (And how many levels of recursion might be possib=
le?)
 
Paul
 
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Saturday=
, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smar=
r; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Web=
finger
 
<=
span style=3D'color:#1F497D'>This is a good start. Some feedback and nits:<=
/span>
 
1.     &n=
bsp; The protocol flow is incorrect and needs to be adjusted based=
 on the final host-meta specification (RFC 6415). Namely, WebFinger must fo=
llow section 4.2 exactly as specified.
2.   &n=
bsp;   WebFinger should focus exclusively on JSON and ma=
ndate WebFinger providers to support the JRD format. This does not preclude=
 using XRD (XML) but it will ensure that every compliant WebFinger implemen=
tation provides full JSON support which is much more likely to be adopted. =
This is something we could not do in host-meta due to the late stage it was=
 in, but this is the right time to make the switch (without taking away any=
 existing functionality).
3.     &nb=
sp; Are there reasons not to mandate HTTPS?=

4. =
      Section 3 should be a sub-section o=
f the introduction and each example needs actual JRD code.
 
In addition, I would very much like to see W=
ebFinger extend the host-meta endpoint by defining a ‘resource’=
 query parameter. Using the example in RFC 6415 section 1.1.1 (example not =
properly encoded to make it easier to read):
 
> GET /.well-known/host-meta?resource=3Dhttp://exampl=
e.com/xy HTTP/1.1
 
 &nbs=
p; {
      "subject"=
:"http://example.com/xy",
 
     =
; "properties":{
    &nbs=
p;   "http://spec.=
example.net/color":"red"
  =
;    },
 
 =
;     "links":[
 &nb=
sp;      {
   &=
nbsp;      "rel":"hub",=

          "=
href":"http://example.com/hub<=
/a>",
        }=
,
        {
          "re=
l":"hub",
     =
     "href":"http://example.com/another/hub",
        },
 =
;       {
  &nb=
sp;       "rel":"author",=

         =
 "href":"http://example.=
com/john",
      =
;  },
        {=

         =
 "rel":"author",
   =
       "template":"http://example=
.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"
        }
 &nb=
sp;    ]
    }
 
The rules for this extension parameter=
 are pretty simple:
 <=
/o:p>
1.  =
     JSON is implied. If the server understand=
s ‘?resource’ it MUST return a JRD document.
2.=
       The subject must be set to th=
e value of the ‘resource’ parameter.
3. &nbs=
p;     <=
/span>If the server does not support that res=
ource (wrong domain, etc.) it must return an empty JRD with the right subje=
ct.
=
4.       The clien=
t MUST verify the server supports ‘?resource’ by making sure th=
e response is both JRD and has the requested subject (this will ensure full=
 compatibility with any other host-meta endpoint).
&nbs=
p;
I would like to see such endpoint extension required=
 for WebFinger so that clients can make a single call and get the full WebF=
inger result in JSON. This would significantly improve adoption and usabili=
ty, and adds very little work to providers.
 
EHL
 <=
/o:p>
 
From: apps-discuss=
-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E.=
 Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc:=
 Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinge=
r
 
Folks,=

 
We just submitted this:
http://ww=
w.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt
 
The tools for Webfinger are now de=
fined, but the procedures need to be clearer with respect to what most of u=
s understand as “webfinger”.  This is just a first stab at=
 making that happen and we hope to progress this to publish an RFC in the a=
pplication area.
=
 
We welcome=
 any comments you have on the topic, either privately or publicly.
 
Paul
 
Questo messaggio e i=
 suoi allegati sono indirizzati esclusivamente alle persone indicate. La di=
ffusione, copia o qualsiasi altra azione derivante dalla conoscenza di ques=
te informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo=
 documento per errore siete cortesemente pregati di darne immediata comunic=
azione 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. Dis=
semination, copying, printing or use by anybody else is unauthorised. If yo=
u are not the intended recipient, please delete this message and any attach=
ments and advise the sender by return e-mail, Thanks. =

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

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F10DP3PW5EX1MB01E_--

--_004_90C41DD21FB7C64BB94121FBBC2E7234526735F10DP3PW5EX1MB01E_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=677;
	creation-date="Tue, 22 Nov 2011 19:08:54 GMT";
	modification-date="Tue, 22 Nov 2011 19:08:54 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

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=

--_004_90C41DD21FB7C64BB94121FBBC2E7234526735F10DP3PW5EX1MB01E_--

From eran@hueniverse.com  Tue Nov 22 11:10:31 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA6621F89BA for ; Tue, 22 Nov 2011 11:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.305
X-Spam-Level: 
X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[AWL=-1.127, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 qQnph7PmgO9S for ; Tue, 22 Nov 2011 11:10:25 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id BAC1D21F8A4E for ; Tue, 22 Nov 2011 11:10:21 -0800 (PST)
Received: (qmail 2914 invoked from network); 22 Nov 2011 19:10:21 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Nov 2011 19:10:21 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 22 Nov 2011 12:10:13 -0700
From: Eran Hammer-Lahav 
To: "Paul E. Jones" , 'Goix Laurent Walter' , "apps-discuss@ietf.org" 
Date: Tue, 22 Nov 2011 12:10:06 -0700
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnysAgBEW78CHWIk+QIu/EtFAjl3mf8CNMDi15RrLE+wgAAFgmA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234526735F10F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <086001cca93b$f455cc90$dd0165b0$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <08dc01cca948$2e569f30$8b03dd90$@packetizer.com>
In-Reply-To: <08dc01cca948$2e569f30$8b03dd90$@packetizer.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_004_90C41DD21FB7C64BB94121FBBC2E7234526735F10FP3PW5EX1MB01E_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: 'Joseph Smarr' 
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 19:10:31 -0000

--_004_90C41DD21FB7C64BB94121FBBC2E7234526735F10FP3PW5EX1MB01E_
Content-Type: multipart/alternative;
	boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234526735F10FP3PW5EX1MB01E_"

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F10FP3PW5EX1MB01E_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Not exactly. Resource gives all the links for that resource. Rel further re=
duces the selection. If you need 10, don't use rel, just resource.

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Tuesday, November 22, 2011 10:55 AM
To: 'Goix Laurent Walter'; Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Subject: RE: [apps-discuss] Webfinger

Walter,

Including the 'resource' parameter could remove the need to further process=
 the templates on the client side and to perform a second query for the "lr=
dd" XRD/JRD document.  If the server implementation does not support the "r=
esource" parameter, then the client would have to go about it as it would t=
oday.

I like the idea of reducing complexity on the client, but if resource is op=
tional, then we do not actually reduce the complexity at all.  It does pote=
ntially reduce the time required to fetch the information by one round-trip=
 to the server.  Is that worth it?  Perhaps.  For most data, there are thre=
e queries:

1)      host-meta

2)      LRDD

3)      Actual data sought (e.g., an avatar file)

Introducing "resource" means we do to queries:

1)      host-mesa?resource

2)      Actual data sought (e.g., an avatar file)

That sounds good for a single piece of information.  However, if the client=
 needs to perform 10 queries for 10 links found, then that one additional s=
tep is little savings.  I'm on the fence over it.

Paul

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]
Sent: Tuesday, November 22, 2011 1:42 PM
To: Eran Hammer-Lahav; Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Subject: R: [apps-discuss] Webfinger

I guess the discussion is moving from a pure descriptor (which may be stati=
c in most cases) to a sort of API, which could have endless parameters.

>From the current/original webfinger description, the host-meta would mostly=
 be static, which implies no API-like, and no parameter, but the lrdd link =
can typically be dynamic/API-like (to support the template mechanism). As s=
uch it could easily accommodate some more parameters as well (in a similar =
flavor than opensearch), e.g. to request specific link rels if we want.

What would be the scope of supporting uri parameters when accessing host-me=
ta? Does this intend to save an interaction step?

walter

Da: apps-discuss-bounces@ietf.org [ma=
ilto:apps-discuss-bounces@ietf.org] Per conto di Eran Hammer-Lahav
Inviato: marted=EC 22 novembre 2011 19.33
A: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Oggetto: Re: [apps-discuss] Webfinger

Yes, it is no longer a template and must be converted to href.

As for testing support, just check for Subject. Pretty simple to do.

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Tuesday, November 22, 2011 9:27 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

A couple more questions on (3):

Why expand templates like this:
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }

The requesting entity could expand the templates.  I can appreciate the rea=
soning for having "?resource" query the LRDD URL and return back the ordere=
d list of links, but why have the server modify the discovered templates li=
ke the one above?  It's no longer a template, really.  Should we change "te=
mplate" to be "href"?

If a server does not understand "?resource", it's likely to simply ignore i=
t.  But, if a client expects it to be processed, it will cause confusion.  =
Would it be better to introduce /.well-known/host-meta-resource?  If a 404 =
is returned, then that is a clear indicator to the client.  Other suggestio=
ns?

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger


1.       Require the server to offer JRD, leave it to the client to pick on=
e flavor.

2.       Host-meta dumps the decision on the applications. You need to deci=
de if WebFinger is an application or just syntactic sugar on top of host-me=
ta.

3.       Expand every template in host-meta + level one LRDD links (excludi=
ng templates in LRDD).

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

Eran,

Thanks for your feedback.  The editorial, structural, and behavioral items =
we'll addressed (including adhering to host-meta section 4.2).

Let me ask about specific comments:


1)      You want to mandate use of JSON, which we also indicated in the dra=
ft.  However, I would personally prefer to give both XML and JSON equal wei=
ght and require both.

2)      You wanted to mandate HTTPS. I'm not opposed, but host-meta does no=
t mandate it.  Shouldn't we Webfinger requirements on what is there?

3)      Regarding "resource" extension: if I query host-meta, there may be =
any number of templates.  Would we want the server to automatically expand =
every template it finds?  Or would we only expand the 'lrdd' template?  (An=
d how many levels of recursion might be possible?)

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

This is a good start. Some feedback and nits:


1.       The protocol flow is incorrect and needs to be adjusted based on t=
he final host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger p=
roviders to support the JRD format. This does not preclude using XRD (XML) =
but it will ensure that every compliant WebFinger implementation provides f=
ull JSON support which is much more likely to be adopted. This is something=
 we could not do in host-meta due to the late stage it was in, but this is =
the right time to make the switch (without taking away any existing functio=
nality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each exa=
mple needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta e=
ndpoint by defining a 'resource' query parameter. Using the example in RFC =
6415 section 1.1.1 (example not properly encoded to make it easier to read)=
:

> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1

   {
      "subject":"http://example.com/xy",

      "properties":{
        "http://spec.example.net/color":"red"
      },

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/hub",
        },
        {
          "rel":"hub",
          "href":"http://example.com/another/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/john",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }
      ]
    }

The rules for this extension parameter are pretty simple:


1.       JSON is implied. If the server understands '?resource' it MUST ret=
urn a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.) =
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making s=
ure the response is both JRD and has the requested subject (this will ensur=
e full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that =
clients can make a single call and get the full WebFinger result in JSON. T=
his would significantly improve adoption and usability, and adds very littl=
e work to providers.

EHL


From: apps-discuss-bounces@ietf.org [=
mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

Folks,

We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

The tools for Webfinger are now defined, but the procedures need to be clea=
rer with respect to what most of us understand as "webfinger".  This is jus=
t a first stab at making that happen and we hope to progress this to publis=
h an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly=
.

Paul

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:image001.gif@01CCA907.4A503F20]Rispetta l'ambiente. Non stampare quest=
a mail se non =E8 necessario.



--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F10FP3PW5EX1MB01E_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Not exactly. Resource gives all the links for that resource. =
Rel further reduces the selection. If you need 10, don’t use rel, jus=
t resource.
 
EHL
 
From: Paul E. Jones [mailto:paulej@packetizer.com] 
Sent: =
Tuesday, November 22, 2011 10:55 AM
To: 'Goix Laurent Walter'; Er=
an Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
S=
ubject: RE: [apps-discuss] Webfinger
<=
p class=3DMsoNormal> 
Walter,
 
Including the ‘resource’ parameter =
could remove the need to further process the templates on the client side a=
nd to perform a second query for the “lrdd” XRD/JRD document.&n=
bsp; If the server implementation does not support the “resource̶=
1; parameter, then the client would have to go about it as it would today.<=
o:p>
 
I like the idea of reducing complexity on the client, but if resource is o=
ptional, then we do not actually reduce the complexity at all.  It doe=
s potentially reduce the time required to fetch the information by one roun=
d-trip to the server.  Is that worth it?  Perhaps.  For most=
 data, there are three queries:
1)      host-meta
2)      =
LRDD
3)=
      Actual data sought (e.g., an avatar=
 file)
 
Introducing “resource” means we do to queries:
1)&=
nbsp;     host-mesa?resource=

2) &nbs=
p;    =
Actual data sought (e.g., an avatar file)
&=
nbsp;
Th=
at sounds good for a single piece of information.  However, if the cli=
ent needs to perform 10 queries for 10 links found, then that one additiona=
l step is little savings.  I’m on the fence over it.<=
/span>
 
Paul<=
/o:p>
&nb=
sp;
From: Goix Laur=
ent Walter =
[mailto:laurentwalter.goix@telecomitalia.it] 
Sent: Tuesday, =
November 22, 2011 1:42 PM
To: Eran Hammer-Lahav; Paul E. Jones; <=
a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org
Cc:=
 'Joseph Smarr'
Subject: R: [apps-discuss] Webfinger
 
I guess the discussion is moving=
 from a pure descriptor (which may be static in most cases) to a sort of AP=
I, which could have endless parameters.
 
From the current/original webfinger description, the host-meta =
would mostly be static, which implies no API-like, and no parameter, but th=
e lrdd link can typically be dynamic/API-like (to support the template mech=
anism). As such it could easily accommodate some more parameters as well (i=
n a similar flavor than opensearch), e.g. to request specific link rels if =
we want.
<=
span style=3D'color:#1F497D'> 
What would be the s=
cope of supporting uri parameters when accessing host-meta? Does this inten=
d to save an interaction step?
=

 
walter
 
Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per con=
to di Eran Hammer-Lahav
Inviato: marted=EC 22 novembre 2011 1=
9.33
A: Paul E. Jones; a=
pps-discuss@ietf.org
Cc: 'Joseph Smarr'
Oggetto: Re=
: [apps-discuss] Webfinger
 
Yes, it is no longer a tem=
plate and must be converted to href.
 
As for testing support, just check for Subject. Pretty simple to d=
o.
 
<=
p class=3DMsoNormal>EHL
&=
nbsp;
From: Paul E. Jones [mailto:paulej@packetizer.com] 
Sent: Tuesday, Nove=
mber 22, 2011 9:27 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'=
; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] =
Webfinger
 
A couple more questions on (3):
 
Why expand templates like this:=

        {
          "rel":=
"author",
      =
;    "template":"http://example.com/author?q=3Dh=
ttp%3A%2F%2Fexample.com%2Fxy"
  &nbs=
p;     }
 
The requesting entity could expand the templates.  I can appreciate t=
he reasoning for having “?resource” query the LRDD URL and retu=
rn back the ordered list of links, but why have the server modify the disco=
vered templates like the one above?  It’s no longer a template, =
really.  Should we change “template” to be “hrefR=
21;?
 
If a server does not un=
derstand “?resource”, it’s likely to simply ignore it.&nb=
sp; But, if a client expects it to be processed, it will cause confusion.&n=
bsp; Would it be better to introduce /.well-known/host-meta-resource? =
 If a 404 is returned, then that is a clear indicator to the client.  =
Other suggestions?
 
Paul
 
<=
div>
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent:<=
/b> Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: '=
Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [a=
pps-discuss] Webfinger
 
=
1.     &nbs=
p; Require the server to offer JRD, leave it to the client to pick=
 one flavor.
2.       =
Host-meta dumps the decision on the applications. You need to decide if Web=
Finger is an application or just syntactic sugar on top of host-meta.
3.       Expand every templ=
ate in host-meta + level one LRDD links (excluding templates in LRDD).
 
EHL<=
/o:p>
 
From: Paul E. Jones [mailto:paulej@packetizer.com] 
Sent: Monday, November 21,=
 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonza=
lo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinge=
r
 
Eran,
<=
p class=3DMsoNormal> 
Thanks for your feedback.  The editorial, structural, and behavior=
al items we’ll addressed (including adhering to host-meta section 4.2=
).
 
<=
p class=3DMsoNormal>Let me ask about specific=
 comments:
 
1)   &nb=
sp;  You want to mandate use of JSON, which we also indicated=
 in the draft.  However, I would personally prefer to give both XML an=
d JSON equal weight and require both.
2)   &nb=
sp;  You wanted to mandate HTTPS. I’m not opposed, but =
host-meta does not mandate it.  Shouldn’t we Webfinger requireme=
nts on what is there?
3)      Regarding “resource” extension: if I query host-meta, there=
 may be any number of templates.  Would we want the server to automati=
cally expand every template it finds?  Or would we only expand =
the ‘lrdd’ template?  (And how many levels of recursion mi=
ght be possible?)
 
Paul
 
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: =
Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-d=
iscuss] Webfinger
<=
p class=3DMsoNormal> 
This is a good start. Some feedback=
 and nits:
 
1.   &n=
bsp;   The protocol flow is incorrect and needs to be ad=
justed based on the final host-meta specification (RFC 6415). Namely, WebFi=
nger must follow section 4.2 exactly as specified.
2. &=
nbsp;     WebFinger should focus exclusively o=
n JSON and mandate WebFinger providers to support the JRD format. This does=
 not preclude using XRD (XML) but it will ensure that every compliant WebFi=
nger implementation provides full JSON support which is much more likely to=
 be adopted. This is something we could not do in host-meta due to the late=
 stage it was in, but this is the right time to make the switch (without ta=
king away any existing functionality).
3.   &=
nbsp;   Are there reasons not to mandate HTTPS?
4.       Section 3 should be=
 a sub-section of the introduction and each example needs actual JRD code.<=
/span>
 
In addition, I would very mu=
ch like to see WebFinger extend the host-meta endpoint by defining a ‘=
;resource’ query parameter. Using the example in RFC 6415 section 1.1=
.1 (example not properly encoded to make it easier to read):
 
> GET /.well-known/host-meta?resource=
=3Dhttp://example.com/xy HTTP/1.1<=
/p>
 
   {
      &=
quot;subject":"http://example.c=
om/xy",
 
  =
;    "properties":{
 &nbs=
p;      "http://spec.example.net/color":"red"
      },<=
/span>
 <=
span lang=3DFR>
      "links":[
        {
&=
nbsp;         "rel":"=
;hub",
       &=
nbsp;  "href":"http:=
//example.com/hub",
    &n=
bsp;   },
      =
;  {
=
       &nb=
sp;  "rel":"hub",
  =
        "href":"http://example.com/another/hub"=
;,
        },=

        {
          "rel":=
"author",
      =
;    "href":"http://example.com/john",
  &nbs=
p;     },
<=
p class=3DMsoNormal>    &=
nbsp;   {
      =
;    "rel":"author",
          "template"=
;:"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"<=
/span>
        }
      ]
  =
  }
<=
span style=3D'color:#1F497D'> 
The rules for this =
extension parameter are pretty simple:
 
1.       JSON is implied. If=
 the server understands ‘?resource’ it MUST return a JRD docume=
nt.
2.       The subj=
ect must be set to the value of the ‘resource’ parameter.
3.       If the server doe=
s not support that resource (wrong domain, etc.) it must return an empty JR=
D with the right subject.
4.     &n=
bsp; The client MUST verify the server supports ‘?resource&#=
8217; by making sure the response is both JRD and has the requested subject=
 (this will ensure full compatibility with any other host-meta endpoint).
 
I would like to see such endp=
oint extension required for WebFinger so that clients can make a single cal=
l and get the full WebFinger result in JSON. This would significantly impro=
ve adoption and usability, and adds very little work to providers.
 
EHL
 
 
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] O=
n Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10=
 PM
To: apps-discuss@iet=
f.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: =
[apps-discuss] Webfinger
=

 
Folks,
 
We =
just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfi=
nger-00.txt
&=
nbsp;
The tools f=
or Webfinger are now defined, but the procedures need to be clearer with re=
spect to what most of us understand as “webfinger”.  This =
is just a first stab at making that happen and we hope to progress this to =
publish an RFC in the application area.
 
We welcome any comments you have on the topic, either privatel=
y or publicly.
&n=
bsp;
Paul
 
<=
p class=3DMsoNormal style=3D'text-align:justify'><=
span style=3D'font-size:7.5pt;font-family:"Verdana","sans-serif";color:blac=
k'>Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle =
persone indicate. La diffusione, copia o qualsiasi altra azione derivante d=
alla 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 distruzi=
one, Grazie. 
This e-mail an=
d any attachments is confidential and may contain privileged info=
rmation intended for the addressee(s) only. Dissemination, copying, printin=
g or use by anybody else is unauthorised. If you are not the intended recip=
ient, please delete this message and any attachments and advise the sender =
by return e-mail, Thanks. 
3D"rispett=Rispetta l'ambiente. Non stampare questa mail se non =E8 nece=
ssario. 
 
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234526735F10FP3PW5EX1MB01E_--

--_004_90C41DD21FB7C64BB94121FBBC2E7234526735F10FP3PW5EX1MB01E_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=677;
	creation-date="Tue, 22 Nov 2011 19:10:11 GMT";
	modification-date="Tue, 22 Nov 2011 19:10:11 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

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=

--_004_90C41DD21FB7C64BB94121FBBC2E7234526735F10FP3PW5EX1MB01E_--

From martin.thomson@gmail.com  Tue Nov 22 15:10:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C58321F85CE for ; Tue, 22 Nov 2011 15:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovbj9jtCORzf for ; Tue, 22 Nov 2011 15:10:07 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F95821F85B8 for ; Tue, 22 Nov 2011 15:09:08 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so464640bkb.31 for ; Tue, 22 Nov 2011 15:09:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qnxYUo7njc+3HN50u+aOkrNunpXNU0hlyum7XLQvkRQ=; b=wjKlFlVRtp2d66xZqyEXjT88jhOAWucRtKwrB7ZJIu6H0ngSHBH/r/H/RfhfHC0+yz TWMs2kDzgjmrXJs7pf9I8Ut7+v+JaL1hY+w0RfC3RNU8yYuiiUad7/UKBjKIE2uW+i83 +lltKatcdthMywm2uNKZRH7NvFPZsicKhMGcI=
MIME-Version: 1.0
Received: by 10.204.14.208 with SMTP id h16mr20750243bka.2.1322003346618; Tue, 22 Nov 2011 15:09:06 -0800 (PST)
Received: by 10.204.72.210 with HTTP; Tue, 22 Nov 2011 15:09:06 -0800 (PST)
In-Reply-To: <4ECBE991.9040704@gmx.de>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <1321986297.2091.1.camel@neutron> <4ECBE991.9040704@gmx.de>
Date: Wed, 23 Nov 2011 10:09:06 +1100
Message-ID: 
From: Martin Thomson 
To: Julian Reschke 
Content-Type: text/plain; charset=UTF-8
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 23:10:26 -0000

On 23 November 2011 05:27, Julian Reschke  wrote:
> On 2011-11-22 19:24, Paul C. Bryan wrote:
>> Looks good to me. I don't think "end" is needed, as the end index can be
>> explicitly specified.

I don't see there being much value either.

> It might make it easier to move something to the end when you don't know the
> whole array (for instance, because there may be race conditions)... Not sure
> how important that is for this use case, though...

I don't like the idea that you could be designing for race conditions
like that. Use conditional requests (thinking HTTP) or some form of
locking if it really must be at the end.

--Martin

From martin.thomson@gmail.com  Tue Nov 22 15:17:27 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDAD11E80BA for ; Tue, 22 Nov 2011 15:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7jFK5R9ob4b for ; Tue, 22 Nov 2011 15:17:26 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F40011E80B3 for ; Tue, 22 Nov 2011 15:17:26 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so471040bkb.31 for ; Tue, 22 Nov 2011 15:17:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tJkg4C8QDb/bHcJrxMsnBOA1vuZCxSNoywF6iU2tpqU=; b=wplLnOnIl7C0X6mTSn44S+ScbQY7DeSQbKJyAApiq3+I3Qxj9wl6Q8pQDvFiZo28ya z/i+75wOQuPZQ5NiAkcVjuod4gkcH6mCGoi+lxeJUgbtmOMrvYNP4iedTj+iFhSBfUh+ zCQgG+ir8fviXm9FdPnucmRWe+/HcxR/BltIw=
MIME-Version: 1.0
Received: by 10.205.128.15 with SMTP id hc15mr20702309bkc.110.1322003845458; Tue, 22 Nov 2011 15:17:25 -0800 (PST)
Received: by 10.204.72.210 with HTTP; Tue, 22 Nov 2011 15:17:25 -0800 (PST)
In-Reply-To: <4ECB9E69.8090505@gmx.de>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>  <4ECB9E69.8090505@gmx.de>
Date: Wed, 23 Nov 2011 10:17:25 +1100
Message-ID: 
From: Martin Thomson 
To: Julian Reschke 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 23:17:27 -0000

> So yes, the fact that a JSON name can be anything a JSON string can take =
is
> indeed a problem, because it doesn't leave us any characters as delimiter=
s
> (so this is very different from XML vs XPath).

Maybe you could use a JSON string notation as your canonical form:

{ "Bj=C3=B8rn/Carsten/foo \uD834\uDD1E" : "Fritz" }
->
"/\"Bj=C3=B8rn/Carsten/foo \uD834\uDD1E\""

From James.H.Manger@team.telstra.com  Tue Nov 22 17:21:27 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987D721F85CE for ; Tue, 22 Nov 2011 17:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.828
X-Spam-Level: 
X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=-2.527, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_14=0.6, RELAY_IS_203=0.994]
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 aIvFsGH1tYJU for ; Tue, 22 Nov 2011 17:21:27 -0800 (PST)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id BF5BE21F85BB for ; Tue, 22 Nov 2011 17:21:26 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.69,556,1315144800"; d="scan'208";a="53155144"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 23 Nov 2011 12:21:19 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6538"; a="43308362"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 23 Nov 2011 12:21:19 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Wed, 23 Nov 2011 12:21:18 +1100
From: "Manger, James H" 
To: Julian Reschke , "Paul C. Bryan" 
Date: Wed, 23 Nov 2011 12:21:17 +1100
Thread-Topic: [apps-discuss] JSON Patch
Thread-Index: AcypMJurq5l2xMAhRPiWTwRsULnzfgASB5Cg
Message-ID: <255B9BB34FB7D647A506DC292726F6E113884047C4@WSMSG3153V.srv.dir.telstra.com>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de>
In-Reply-To: <4ECBC843.60900@gmx.de>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 01:21:27 -0000

JSON pointer array indices start at zero so the example patch document belo=
w actually moves "qux" to the end of the array, instead of "bar" to the mid=
dle.


On escaping: how about replacing every '/' in an object member's name with =
the Unicode REPLACEMENT CHARACTER U+FFFD when creating a JSON pointer.

It means a JSON pointer cannot reference an object member that actually has=
 a U+FFFD char in its name, but that seems so unlikely that it could be an =
acceptable restriction.
Escaping and unescaping is easy: eg in Java s.replace('/', '\uFFFD') to esc=
ape; s.replace('\uFFFD', '/') to unescape.
It should cause less confusion when another layer (eg URI, fragment...) add=
s escaping, such as %xx.


--
James Manger

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Julian Reschke
Sent: Wednesday, 23 November 2011 3:05 AM
To: Paul C. Bryan
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch

On 2011-11-10 11:01, Julian Reschke wrote:
> On 2011-11-02 18:22, Paul C. Bryan wrote:
>> Thanks everyone for the feedback so far. Some replies:
>>
>> On Wed, 2011-11-02 at 13:39 +0000, Michael D=FCrig wrote:
>>> What is missing (wrt. to [2]) is a reorder operation.
>>
>> The ability to move items in an array has come up and seems
>> straightforward. A need (and semantics) of moving a value between two
>> arbitrary locations in a JSON document is not well understood.
>
> +1. So are you planning to add this? Would it make sense to make a
> concrete proposal?
> ...

OK, here's draft proposal:

4.4. move

    The "move" operation moves an existing array element. The "to"=20
member indicates the array position as integer value. This operation is=20
equivalent to removing the element identified by "move", an inserting it=20
again at the position "to".


Example:

    An example target JSON document:

    {
        "foo": [ "bar", "qux", "baz" ]
    }

    A JSON Patch document:

    [
        { "move": "/foo/1", "to": 2}
    ]

    The resulting JSON document:

    {
        "foo": ["qux", "bar", "baz"]
    }

Q: is a special case like "end" needed?

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

From barryleiba.mailing.lists@gmail.com  Tue Nov 22 19:07:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71F31F0C59 for ; Tue, 22 Nov 2011 19:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.415
X-Spam-Level: 
X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 XS4aGbySZ3Rf for ; Tue, 22 Nov 2011 19:07:38 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 058551F0C52 for ; Tue, 22 Nov 2011 19:07:37 -0800 (PST)
Received: by ywt34 with SMTP id 34so1036600ywt.31 for ; Tue, 22 Nov 2011 19:07:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+T+xnNtCcmqATGceisqzdOQxH7cmhVmwo2poFewXdc0=; b=SxmsMPJH2xpmRrOTKlfyAGhW2/ELGYiJxM+euG0rTKc5Vf/4NY1NcCZ42edqm9MdWW PIm+nhqvMIyGYxzHvXXi0RraYa3f2mz3oZOQeWF0p+zOKERjiDjJvvK5vakjQl8nebwg /iymQrdT3mvW52As8vnBYfOK1npUrgkzjAsX8=
MIME-Version: 1.0
Received: by 10.182.2.225 with SMTP id 1mr8137912obx.30.1322017657529; Tue, 22 Nov 2011 19:07:37 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.182.13.134 with HTTP; Tue, 22 Nov 2011 19:07:37 -0800 (PST)
In-Reply-To: <4ECA3A2C.1010606@gmail.com>
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com> <4EC40EC3.9080304@gmail.com> <4EC8B870.7070105@isode.com> <4ECA3A2C.1010606@gmail.com>
Date: Tue, 22 Nov 2011 22:07:37 -0500
X-Google-Sender-Auth: KnpuLk9Anb_jLxdZL5EoYZfIheQ
Message-ID: 
From: Barry Leiba 
To: =?UTF-8?B?TXlreXRhIFlldnN0aWZleWV2ICjQnC4g0ITQstGB0YLRltGE0LXRlNCyKQ==?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 03:07:38 -0000

>>>> =A0 The 'about' URI MUST syntactically conform to the  rule
>>>> =A0 below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]=
:
>>>>
>>>> =A0 =A0 about-uri =A0 =3D "about:" about-token [ about-query ]
>>>> =A0 =A0 about-token =3D segment
>>>> =A0 =A0 about-query =3D "?" query
>>>> =A0 =A0 segment =A0 =A0 =3D 
>>>> =A0 =A0 query =A0 =A0 =A0 =3D 
>>>>
>>>> =A0 In terms of RFC 3986,  part corresponds to ,
>>>> =A0 and  to the query component of URI.
>>>>
>>>> s/query/ ? (I didn't check RFC 3986)
>>>
>>> 2.1. URI Scheme Syntax
>>>
>>>  doesn't include "?" - so query component.
>>
>> You misunderstood. You have "about-token" enclosed in <>, I think you ne=
ed
>> <> around "query" as well.
>
> The RFC 3986  production does not include "?" delimiter but only t=
he
> range of chars allowed in the query component while  stands =
for
> query itself and the delimiter. =A0That would be technically inaccurate i=
f I
> mentioned .

You still misunderstand what Alexey was getting at, so let me try to
explain (I misunderstood the first time as well, but I understand his
second explanation):  He's NOT talking about the ABNF.  He's talking
about this sentence after it:

> =A0 In terms of RFC 3986,  part corresponds to ,
> =A0 and  to the query component of URI.

He notes that you have put "" in angle-brackets,
"" in angle-brackets, and "" in
angle-brackets, but you have not done so with "query".  He suggests
that you should say, "to the  component of URI."

I think a better way to approach it would be to replace all the
angle-brackets with quotes, so:

NEW
 =A0 In terms of RFC 3986, the "about-token" part corresponds to "hier-part=
",
 =A0 and "about-query" to the query component of the URI.

(And I do not think that "query" needs to be in quotes here.)

>>> Yes, redirection needs clarification. =A0That is not HTTP sense here - =
I
>>> meant they can be replaced by some other URIs and than resolved to what
>>> these URIs refer to, and the latter of them needn't necessarily be 'htt=
p'
>>> URIs.
>>
>> I don't know of any better reference than RFC 2616. Conceptually one URI
>> is replaced with another, so even if a non HTTP URI is used, this should
>> work.
>
> I've added the following text:
>
>>
>> =A0 and MAY redirect such URIs, i.e. resolve it to a resource commonly
>> =A0 referred to by an other URI.

I had suggested text for this in my other note; what do you think of
it?  I like it (obviously):

NEW
 Any application resolving an "about" URI MAY
 choose the resource it is resolved to at its own discretion, with the
 exception of those defined below as 'special-purpose "about" URIs'.
 They MAY use internal redirection to accomplish this  (for
 instance, Opera redirects all "about" URIs except "about:blank"
 to its internal "opera" URIs).


>>> We still haven't had such a term as 'special-purpose about URI', and so
>>> we can't speak of common behavior. =A0IMO, taking into account the inte=
nded
>>> semantics of SPUs, if the meaning of query isn't defined, it must be ig=
nored
>>> not to eliminate the said semantics and their utility.
>>
>> It looks like the first part of the sentence is as a recommendation for
>> new SPU designers, the second part is a recommendation for developers. T=
his
>> adds to confusion and I suggest you reword this, for example:
>>
>> =A0 The SPT specification MAY define additional provisions on handling o=
f
>>  part in
>> =A0 the corresponding SPU. Unless specified otherwise, implementations M=
UST
>> ignore the 
>> =A0 part when processing SPUs.
>
> Agreed.

I provided a suggested revision of the whole section in my other note;
please consider that.  It gets rid of the "alphabet soup", which I
think makes things more confusing, and I think it reads much better.

>>> That is what HTML5 wants to define (actually, defines). =A0we had a
>>> discussion on this previously.
>>
>> I think that if the document wants to talk about these, it needs to
>> provide more details.
>
> What are such possible details?

As I said in my other note, I agree with Alexey here: I don't think
this part is appropriate.  (1) If it's here, it needs some text
explaining and justifying it, and (2) the goal here is to keep the
document simple, just doing what's necessary to get this stuff
registered.

>>>> =A0 An unrecognized 'about' URIs as a URI that may not be recognized b=
y
>>>> =A0 an application. =A0(Correspondingly, such categorization is per-
>>>> =A0 application, not per-fact.)
>>>>
>>>> I don't understand the comment in () and I don't think it adds any val=
ue
>>>> anyway.
>>>
>>> It means that 'about' URI can't be defined to be unrecognized - this al=
l
>>> depends on application.
>>
>> The first sentence quoted above already says that. Besides, I don't
>> understand the meaning of "per-fact" in this context.
>
> "per-fact" is meant to be predefined for some particular URI. =A0However,=
 if
> you insist, I don't object to removing that sentence.

"Per-fact" simply doesn't make sense in English.  That is, it's not an
idiom anyone uses, and I doubt anyone has seen it before.  While some
people might be able to make sense out of it (I think I know what you
mean, but I'm not sure), we shouldn't have to guess.

Mostly, see my other note for what I think you should do with section 2.2.2=
.

>> I suppose I should test browser behaviour in the 2 cases mentioned above=
.
>
> Case 1 (testing about:yevstifeyev):
> FF 7.0.1: a warning and about:blank
> IE8: tried to load the error page (res://ieframe.dll/navcancl.htm) but
> failed
> Chrome 15: redirected to chrome://yevstifeyev and displayed an error.
> Safari 3.2.1 for Win: about:blank.
>
> Conclusion: let's remove the recognized/unrecognized section at all, and
> leave this to app designers.

Cool.  I like that.

Barry

From GK@ninebynine.org  Tue Nov 22 23:11:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC8A1F0C57 for ; Tue, 22 Nov 2011 23:11:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.81
X-Spam-Level: 
X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=-0.280,  BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 Af8QoveeStKT for ; Tue, 22 Nov 2011 23:10:59 -0800 (PST)
Received: from relay9.mail.ox.ac.uk (relay9.mail.ox.ac.uk [163.1.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7860721F8A35 for ; Tue, 22 Nov 2011 23:10:58 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay9.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1RT6t4-0006DW-Th; Wed, 23 Nov 2011 07:04:54 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RT6t4-0005Pv-09; Wed, 23 Nov 2011 07:04:54 +0000
Message-ID: <4ECC0198.6040103@ninebynine.org>
Date: Tue, 22 Nov 2011 20:10:00 +0000
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Julian Reschke 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de>
In-Reply-To: <4ECBC843.60900@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 07:11:00 -0000

On 22/11/2011 16:05, Julian Reschke wrote:
> OK, here's draft proposal:
>
> 4.4. move
>
> The "move" operation moves an existing array element. The "to" member indicates
> the array position as integer value. This operation is equivalent to removing
> the element identified by "move", an inserting it again at the position "to".
>
>
> Example:
>
> An example target JSON document:
>
> {
> "foo": [ "bar", "qux", "baz" ]
> }
>
> A JSON Patch document:
>
> [
> { "move": "/foo/1", "to": 2}
> ]
>
> The resulting JSON document:
>
> {
> "foo": ["qux", "bar", "baz"]
> }

Er, aren't Javascript arrays 0-based?  I'd expect the same to apply to JSON.

I'd also suggest instead of
   "an inserting it again at the position "to"."
to say
   "and inserting it again so that it occupies position "to" in the resulting 
array."

This just avoids any ambiguity about whether or not "to" is specified with 
respect to the original array before removing the element to be moved.

#g

From laurentwalter.goix@telecomitalia.it  Wed Nov 23 00:46:02 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6FE21F8C26 for ; Wed, 23 Nov 2011 00:46:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.536
X-Spam-Level: 
X-Spam-Status: No, score=0.536 tagged_above=-999 required=5 tests=[AWL=-0.166,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 MPFPMDO7kEvJ for ; Wed, 23 Nov 2011 00:45:54 -0800 (PST)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 862FF21F8C20 for ; Wed, 23 Nov 2011 00:45:42 -0800 (PST)
Content-Type: multipart/mixed; boundary="_912a8741-c504-4f0e-bd24-29d2dd6a770c_"
Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 23 Nov 2011 09:45:28 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Wed, 23 Nov 2011 09:45:27 +0100
From: Goix Laurent Walter 
To: Eran Hammer-Lahav , "Paul E. Jones" , "apps-discuss@ietf.org" 
Date: Wed, 23 Nov 2011 09:45:24 +0100
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnysAgBEW78CHWIk+QIu/EtFAjl3mf8CNMDi15RrLE+wgAAFgmCAAOAD8A==
Message-ID: 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <086001cca93b$f455cc90$dd0165b0$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <08dc01cca948$2e569f30$8b03dd90$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F10F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234526735F10F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: 'Joseph Smarr' 
Subject: [apps-discuss] R:  Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 08:46:02 -0000

--_912a8741-c504-4f0e-bd24-29d2dd6a770c_
Content-Type: multipart/related;
	boundary="_004_A09A9E0A4B9C654E8672D1DC003633AE405700681DGRFMBX704BA02_";
	type="multipart/alternative"

--_004_A09A9E0A4B9C654E8672D1DC003633AE405700681DGRFMBX704BA02_
Content-Type: multipart/alternative;
	boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE405700681DGRFMBX704BA02_"

--_000_A09A9E0A4B9C654E8672D1DC003633AE405700681DGRFMBX704BA02_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All,





I am not sure that making the host-meta itself act as a proxy for resource-=
specific information is the best option.



There are probably different use cases we are thinking of:

- one is related to a server that wishes to interact with (multiple) users =
on another server.

- another (more unclear to me) is related to a web app directly requesting =
specific information about a remote user



For the first scenario the local server would probably retrieve the remote =
host-meta once, cache it and then perform queries for each user using the l=
rdd link template. Also typically this large amount of users may not be kno=
wn simultaneously, so no need for specifying a list of users (resources) in=
 the same query. However I would assume in most cases the urls/templates fo=
r the target rels in the single resource descriptor provided by the remote =
server may often be along the same pattern. This may call for an easier mec=
hanism for a server to discover/cache not only the lrdd template but the ot=
her rels it needs (avatar, profile-page, etc): I can understand this may no=
t always be feasible but at least it would save numerous queries.



In the second one the web app typically would ideally like a single request=
 (json) to get a specific info (1 or more rels) about a specific user (reso=
urce). This calls for some sort of standard API but I'm not sure it is host=
-meta responsibility to define it. In principle this would be like standard=
izing the lrdd endpoint and its parameters ('rel' and 'resource/uri').



Summarizing, what about rethinking the following:

1- standardize (under webfinger) the lrdd endpoint (e.g as ".well-known/lrd=
d[.json]") so that we can save one invocation from a web app

2- enable/suggest this same lrdd endpoint to provide back rels as templates=
 when no specific resource is requested. This may require the definition of=
 additional variables ({}) to refer to the username only for example (in ge=
neral to give more flexibility to the hosting server), whilst at the same t=
ime potentially enabling the requesting server to cache these templates and=
 use them to retrieve user information more easily/frequently



Probably in both cases the entity performing the invocation knows already w=
hich rels is needs, so filters here may be useful although not a must.





Here are some examples:



=D8  GET /.well-known/lrdd.json?resource=3Dacct:xy@example.com&rel=3Dhub&re=
l=3Dauthor HTTP/1.1

   {
      "subject":"acct:xy@example.com",

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/xy/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/xy",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dacct:xy%40example.com"
        }
      ]
    }



=D8  GET /.well-known/lrdd?rel=3Dhub&rel=3Dauthor HTTP/1.1


     
       example.com 
        
       
       
     

Thoughts?
walter

Da: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Inviato: marted=EC 22 novembre 2011 20.10
A: Paul E. Jones; Goix Laurent Walter; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Oggetto: RE: [apps-discuss] Webfinger

Not exactly. Resource gives all the links for that resource. Rel further re=
duces the selection. If you need 10, don't use rel, just resource.

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Tuesday, November 22, 2011 10:55 AM
To: 'Goix Laurent Walter'; Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Subject: RE: [apps-discuss] Webfinger

Walter,

Including the 'resource' parameter could remove the need to further process=
 the templates on the client side and to perform a second query for the "lr=
dd" XRD/JRD document.  If the server implementation does not support the "r=
esource" parameter, then the client would have to go about it as it would t=
oday.

I like the idea of reducing complexity on the client, but if resource is op=
tional, then we do not actually reduce the complexity at all.  It does pote=
ntially reduce the time required to fetch the information by one round-trip=
 to the server.  Is that worth it?  Perhaps.  For most data, there are thre=
e queries:

1)      host-meta

2)      LRDD

3)      Actual data sought (e.g., an avatar file)

Introducing "resource" means we do to queries:

1)      host-mesa?resource

2)      Actual data sought (e.g., an avatar file)

That sounds good for a single piece of information.  However, if the client=
 needs to perform 10 queries for 10 links found, then that one additional s=
tep is little savings.  I'm on the fence over it.

Paul

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]
Sent: Tuesday, November 22, 2011 1:42 PM
To: Eran Hammer-Lahav; Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Subject: R: [apps-discuss] Webfinger

I guess the discussion is moving from a pure descriptor (which may be stati=
c in most cases) to a sort of API, which could have endless parameters.

>From the current/original webfinger description, the host-meta would mostly=
 be static, which implies no API-like, and no parameter, but the lrdd link =
can typically be dynamic/API-like (to support the template mechanism). As s=
uch it could easily accommodate some more parameters as well (in a similar =
flavor than opensearch), e.g. to request specific link rels if we want.

What would be the scope of supporting uri parameters when accessing host-me=
ta? Does this intend to save an interaction step?

walter

Da: apps-discuss-bounces@ietf.org [ma=
ilto:apps-discuss-bounces@ietf.org] Per conto di Eran Hammer-Lahav
Inviato: marted=EC 22 novembre 2011 19.33
A: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Oggetto: Re: [apps-discuss] Webfinger

Yes, it is no longer a template and must be converted to href.

As for testing support, just check for Subject. Pretty simple to do.

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Tuesday, November 22, 2011 9:27 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

A couple more questions on (3):

Why expand templates like this:
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }

The requesting entity could expand the templates.  I can appreciate the rea=
soning for having "?resource" query the LRDD URL and return back the ordere=
d list of links, but why have the server modify the discovered templates li=
ke the one above?  It's no longer a template, really.  Should we change "te=
mplate" to be "href"?

If a server does not understand "?resource", it's likely to simply ignore i=
t.  But, if a client expects it to be processed, it will cause confusion.  =
Would it be better to introduce /.well-known/host-meta-resource?  If a 404 =
is returned, then that is a clear indicator to the client.  Other suggestio=
ns?

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger


1.       Require the server to offer JRD, leave it to the client to pick on=
e flavor.

2.       Host-meta dumps the decision on the applications. You need to deci=
de if WebFinger is an application or just syntactic sugar on top of host-me=
ta.

3.       Expand every template in host-meta + level one LRDD links (excludi=
ng templates in LRDD).

EHL

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

Eran,

Thanks for your feedback.  The editorial, structural, and behavioral items =
we'll addressed (including adhering to host-meta section 4.2).

Let me ask about specific comments:


1)      You want to mandate use of JSON, which we also indicated in the dra=
ft.  However, I would personally prefer to give both XML and JSON equal wei=
ght and require both.

2)      You wanted to mandate HTTPS. I'm not opposed, but host-meta does no=
t mandate it.  Shouldn't we Webfinger requirements on what is there?

3)      Regarding "resource" extension: if I query host-meta, there may be =
any number of templates.  Would we want the server to automatically expand =
every template it finds?  Or would we only expand the 'lrdd' template?  (An=
d how many levels of recursion might be possible?)

Paul

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

This is a good start. Some feedback and nits:


1.       The protocol flow is incorrect and needs to be adjusted based on t=
he final host-meta specification (RFC 6415). Namely, WebFinger must follow =
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger p=
roviders to support the JRD format. This does not preclude using XRD (XML) =
but it will ensure that every compliant WebFinger implementation provides f=
ull JSON support which is much more likely to be adopted. This is something=
 we could not do in host-meta due to the late stage it was in, but this is =
the right time to make the switch (without taking away any existing functio=
nality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each exa=
mple needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta e=
ndpoint by defining a 'resource' query parameter. Using the example in RFC =
6415 section 1.1.1 (example not properly encoded to make it easier to read)=
:

> GET /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1

   {
      "subject":"http://example.com/xy",

      "properties":{
        "http://spec.example.net/color":"red"
      },

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/hub",
        },
        {
          "rel":"hub",
          "href":"http://example.com/another/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/john",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=3Dhttp%3A%2F%2Fexample.co=
m%2Fxy"
        }
      ]
    }

The rules for this extension parameter are pretty simple:


1.       JSON is implied. If the server understands '?resource' it MUST ret=
urn a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.) =
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making s=
ure the response is both JRD and has the requested subject (this will ensur=
e full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that =
clients can make a single call and get the full WebFinger result in JSON. T=
his would significantly improve adoption and usability, and adds very littl=
e work to providers.

EHL


From: apps-discuss-bounces@ietf.org [=
mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

Folks,

We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

The tools for Webfinger are now defined, but the procedures need to be clea=
rer with respect to what most of us understand as "webfinger".  This is jus=
t a first stab at making that happen and we hope to progress this to publis=
h an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly=
.

Paul

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:image001.gif@01CCA9C3.DE931600]Rispetta l'ambiente. Non stampare quest=
a mail se non =E8 necessario.


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:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No=
n stampare questa mail se non =E8 necessario.


--_000_A09A9E0A4B9C654E8672D1DC003633AE405700681DGRFMBX704BA02_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











All,


 


 


I am not sure that making th=
e host-meta itself act as a proxy for resource-specific information is the =
best option.


 


There are probably different=
 use cases we are thinking of:


- one is related to a server=
 that wishes to interact with (multiple) users on another server.


- another (more unclear to m=
e) is related to a web app directly requesting specific information about a=
 remote user


 


For the first scenario the l=
ocal server would probably retrieve the remote host-meta once, cache it and=
 then perform queries for each user using the lrdd link template. Also typi=
cally this large amount of users may
 not be known simultaneously, so no need for specifying a list of users (re=
sources) in the same query. However I would assume in most cases the urls/t=
emplates for the target rels in the single resource descriptor provided by =
the remote server may often be along
 the same pattern. This may call for an easier mechanism for a server to di=
scover/cache not only the lrdd template but the other rels it needs (avatar=
, profile-page, etc): I can understand this may not always be feasible but =
at least it would save numerous
 queries.


 


In the second one the web ap=
p typically would ideally like a single request (json) to get a specific in=
fo (1 or more rels) about a specific user (resource). This calls for some s=
ort of standard API but I'm not sure
 it is host-meta responsibility to define it. In principle this would be li=
ke standardizing the lrdd endpoint and its parameters ('rel' and 'resource/=
uri').


 


Summarizing, what about reth=
inking the following:


1- standardize (under webfin=
ger) the lrdd endpoint (e.g as “.well-known/lrdd[.json]”) so th=
at we can save one invocation from a web app


2- enable/suggest this same =
lrdd endpoint to provide back rels as templates when no specific resource i=
s requested. This may require the definition of additional variables ({}) t=
o refer to the username only for example
 (in general to give more flexibility to the hosting server), whilst at the=
 same time potentially enabling the requesting server to cache these templa=
tes and use them to retrieve user information more easily/frequently



 


Probably in both cases the e=
ntity performing the invocation knows already which rels is needs, so filte=
rs here may be useful although not a must.


 


 


Here are some examples:=



 



=D8 
GET /.well-known/lrdd.json?resource=3Dacct:xy@example.com&rel=3Dhub&am=
p;rel=3Dauthor HTTP/1.1


 <=
/span>


 &=
nbsp; {


 &=
nbsp;    "subject":"acct:xy@example.com"=
,


 <=
/span>


 &=
nbsp;    "links":[


 &=
nbsp;      {


 &=
nbsp;        "rel":"hub&q=
uot;,


 &=
nbsp;        "href":"http://example.com/xy/hub",


 &=
nbsp;      },


 &=
nbsp;      {


 &=
nbsp;        "rel":"autho=
r",


 &=
nbsp;        "href":"http://example.com/xy",


 &=
nbsp;      },


 &=
nbsp;      {


 &=
nbsp;        "rel":"autho=
r",


 &=
nbsp;        "template":"=
http://example.com/author?q=3Dacct:xy%40example.com"


 &=
nbsp;      }


 &=
nbsp;    ]


 &=
nbsp;  }


 



=D8 
GET /.well-known/lrdd?rel=3Dhub&rel=3Dauthor HTTP/1.1


 <=
/span>


<?xml version=3D"1.0" encoding=
=3D"UTF-8"?>


     <XRD xmlns=3D&q=
uot;http://docs.oasis-open.org/ns/xri/xrd-1.0">

       <Su=
bject>example.com</Subject> <!-- host name here -->


       <Li=
nk rel=3D"hub"


       &=
nbsp;     template=3D"http://example.com/{username=
}/hub"/> <!-- {username} could be defined to refer to that part =
only of the URI. Works with acct: URI only… --><=
/p>

       <Li=
nk rel=3D"author" template=3D"http://example.com/{username}&=
quot;/>


       <Li=
nk rel=3D"author" template=3D"http://example.com/author?q=3D=
{uri}"/>


    
</XRD>


&n=
bsp;


Thoughts?


walter


 






Da: Eran Hammer-Lahav [mailto:eran@hueniverse.com]


Inviato: marted=EC 22 novembre 2011 20.10

A: Paul E. Jones; Goix Laurent Walter; apps-discuss@ietf.org

Cc: 'Joseph Smarr'

Oggetto: RE: [apps-discuss] Webfinger






 


Not exa=
ctly. Resource gives all the links for that resource. Rel further reduces t=
he selection. If you need 10, don’t use rel, just resource.


&n=
bsp;


EHL


&n=
bsp;








From: Paul E. Jones [mail=
to:paulej@packetizer.com]


Sent: Tuesday, November 22, 2011 10:55 AM

To: 'Goix Laurent Walter'; Eran Hammer-Lahav; apps-discuss@ietf.org<=
br>
Cc: 'Joseph Smarr'

Subject: RE: [apps-discuss] Webfinger






 


Walter,=



&n=
bsp;


Includi=
ng the ‘resource’ parameter could remove the need to further pr=
ocess the templates on the client side and to perform a second query for th=
e “lrdd” XRD/JRD document.  If the server implementation
 does not support the “resource” parameter, then the client wou=
ld have to go about it as it would today.


&n=
bsp;


I like =
the idea of reducing complexity on the client, but if resource is optional,=
 then we do not actually reduce the complexity at all.  It does potent=
ially reduce the time required to fetch the
 information by one round-trip to the server.  Is that worth it? =
 Perhaps.  For most data, there are three queries:

=
1)     
host-meta


=
2)     
LRDD


=
3)     
Actual data sought (e.g., an avatar file)


&n=
bsp;


Introdu=
cing “resource” means we do to queries:


=
1)     
host-mesa?resource


=
2)     
Actual data sought (e.g., an avatar file)


&n=
bsp;


That so=
unds good for a single piece of information.  However, if the client n=
eeds to perform 10 queries for 10 links found, then that one additional ste=
p is little savings.  I’m on the fence over
 it.


&n=
bsp;


Paul


&n=
bsp;








From: Goix Laurent Walter
[mailto:lau=
rentwalter.goix@telecomitalia.it]


Sent: Tuesday, November 22, 2011 1:42 PM

To: Eran Hammer-Lahav; Paul E. Jones; 
apps-discuss@ietf.org

Cc: 'Joseph Smarr'

Subject: R: [apps-discuss] Webfinger






 


I guess=
 the discussion is moving from a pure descriptor (which may be static in mo=
st cases) to a sort of API, which could have endless parameters.


 <=
/span>


From th=
e current/original webfinger description, the host-meta would mostly be sta=
tic, which implies no API-like, and no parameter, but the lrdd link can typ=
ically be dynamic/API-like (to support
 the template mechanism). As such it could easily accommodate some more par=
ameters as well (in a similar flavor than opensearch), e.g. to request spec=
ific link rels if we want.


 <=
/span>


What wo=
uld be the scope of supporting uri parameters when accessing host-meta? Doe=
s this intend to save an interaction step?


 <=
/span>


walter<=
/span>


 






Da:
apps-discuss-bounces@ietf.=
org 
[mailto:apps-discuss-bounces@ietf.org] Per conto di Eran Hammer-=
Lahav

Inviato: marted=EC 22 novembre 2011 19.33

A: Paul E. Jones; apps-disc=
uss@ietf.org

Cc: 'Joseph Smarr'

Oggetto: Re: [apps-discuss] Webfinger






 


Yes, it=
 is no longer a template and must be converted to href.

 <=
/span>


As for =
testing support, just check for Subject. Pretty simple to do.


 <=
/span>


EHL


 <=
/span>








From: Paul E. Jones
[mailto:paulej@packetizer=
.com]


Sent: Tuesday, November 22, 2011 9:27 AM

To: Eran Hammer-Lahav; apps=
-discuss@ietf.org

Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'

Subject: RE: [apps-discuss] Webfinger






 


A coupl=
e more questions on (3):


 <=
/span>


Why exp=
and templates like this:


 &=
nbsp;      {


 &=
nbsp;        "rel":"autho=
r",


 &=
nbsp;        "template":"=
htt=
p://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"


 &=
nbsp;      }


 <=
/span>


The req=
uesting entity could expand the templates.  I can appreciate the reaso=
ning for having “?resource” query the LRDD URL and return back =
the ordered list of links, but why have the server modify
 the discovered templates like the one above?  It’s no longer a =
template, really.  Should we change “template” to be ̶=
0;href”?


 <=
/span>


If a se=
rver does not understand “?resource”, it’s likely to simp=
ly ignore it.  But, if a client expects it to be processed, it will ca=
use confusion.  Would it be better to introduce /.well-known/host-meta=
-resource? 
 If a 404 is returned, then that is a clear indicator to the client.  =
Other suggestions?


 <=
/span>


Paul


 <=
/span>








From: Eran Hammer-Lahav
[mailto:eran@hueniverse.com=
] 

Sent: Monday, November 21, 2011 9:52 PM

To: Paul E. Jones; apps-dis=
cuss@ietf.org

Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'

Subject: RE: [apps-discuss] Webfinger






 


1.     &=
nbsp;
Requir=
e the server to offer JRD, leave it to the client to pick one flavor.


2.     &=
nbsp;
Host-m=
eta dumps the decision on the applications. You need to decide if WebFinger=
 is an application or just syntactic sugar on top of host-meta.=



3.     &=
nbsp;
Expand=
 every template in host-meta + level one LRDD links (excluding template=
s in LRDD).


 <=
/span>


EHL


 <=
/span>








From: Paul E. Jones
[mailto:paulej@packetizer=
.com]


Sent: Monday, November 21, 2011 7:49 AM

To: Eran Hammer-Lahav; apps=
-discuss@ietf.org

Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'

Subject: RE: [apps-discuss] Webfinger






 


Eran,


 <=
/span>


Thanks =
for your feedback.  The editorial, structural, and behavioral items we=
’ll addressed (including adhering to host-meta section 4.2).


 <=
/span>


Let me =
ask about specific comments:


 <=
/span>


1)     
You wa=
nt to mandate use of JSON, which we also indicated in the draft.  Howe=
ver, I would personally prefer to give both XML and JSON equal weight and r=
equire both.


2)     
You wa=
nted to mandate HTTPS. I’m not opposed, but host-meta does not mandat=
e it.  Shouldn’t we Webfinger requirements on what is there?


3)     
Regard=
ing “resource” extension: if I query host-meta, there may be an=
y number of templates.  Would we want the server to automatically expa=
nd
every template it finds?  Or would we only expand the ‘lr=
dd’ template?  (And how many levels of recursion might be possib=
le?)


 <=
/span>


Paul


 <=
/span>








From: Eran Hammer-Lahav
[mailto:eran@hueniverse.com=
] 

Sent: Saturday, November 19, 2011 10:03 AM

To: Paul E. Jones; apps-dis=
cuss@ietf.org

Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook

Subject: RE: [apps-discuss] Webfinger






 


This is=
 a good start. Some feedback and nits:


 <=
/span>



1.      
The pr=
otocol flow is incorrect and needs to be adjusted based on the final host-m=
eta specification (RFC 6415). Namely, WebFinger must follow section 4.2 exa=
ctly as specified.



2.      
WebFin=
ger should focus exclusively on JSON and mandate WebFinger providers to sup=
port the JRD format. This does not preclude using XRD (XML) but it will ens=
ure that every compliant WebFinger implementation
 provides full JSON support which is much more likely to be adopted. This i=
s something we could not do in host-meta due to the late stage it was in, b=
ut this is the right time to make the switch (without taking away any exist=
ing functionality).



3.      
Are th=
ere reasons not to mandate HTTPS?



4.      
Sectio=
n 3 should be a sub-section of the introduction and each example needs actu=
al JRD code.


 <=
/span>


In addi=
tion, I would very much like to see WebFinger extend the host-meta endpoint=
 by defining a ‘resource’ query parameter. Using the example in=
 RFC 6415 section 1.1.1 (example not properly encoded
 to make it easier to read):


 <=
/span>


> GE=
T /.well-known/host-meta?resource=3Dhttp://example.com/xy HTTP/1.1


 <=
/span>


 &=
nbsp; {


 &=
nbsp;    "subject":"http://example.com/xy",


 <=
/span>


 &=
nbsp;    "properties":{


 &=
nbsp;      "http://spec.example.net/color":"red"


 &=
nbsp;    },


 <=
/span>


 &=
nbsp;    "links":[


 &=
nbsp;      {


 &=
nbsp;        "rel":"hub&q=
uot;,


 &=
nbsp;        "href":"http://example.com/hub",


 &=
nbsp;      },


 &=
nbsp;      {


 &=
nbsp;        "rel":"hub&q=
uot;,


 &=
nbsp;        "href":"http://example.com/another/hub&q=
uot;,


 &=
nbsp;      },


 &=
nbsp;      {


 &=
nbsp;        "rel":"autho=
r",


 &=
nbsp;        "href":"http://example.com/john",


 &=
nbsp;      },


 &=
nbsp;      {


 &=
nbsp;        "rel":"autho=
r",


 &=
nbsp;        "template":"=
htt=
p://example.com/author?q=3Dhttp%3A%2F%2Fexample.com%2Fxy"


 &=
nbsp;      }


 &=
nbsp;    ]


 &=
nbsp;  }


 <=
/span>


The rul=
es for this extension parameter are pretty simple:


 <=
/span>



1.      
JSON i=
s implied. If the server understands ‘?resource’ it MUST return=
 a JRD document.



2.      
The su=
bject must be set to the value of the ‘resource’ parameter.



3.      
If the=
 server does not support that resource (wrong domain, etc.) it must return =
an empty JRD with the right subject.



4.      
The cl=
ient MUST verify the server supports ‘?resource’ by making sure=
 the response is both JRD and has the requested subject (this will ensure f=
ull compatibility with any other host-meta endpoint).


 <=
/span>


I would=
 like to see such endpoint extension required for WebFinger so that clients=
 can make a single call and get the full WebFinger result in JSON. This wou=
ld significantly improve adoption and
 usability, and adds very little work to providers.


 <=
/span>


EHL


 <=
/span>


 <=
/span>





 


Folks,


 


We just submitted this:<=
o:p>


http://www.ietf.org/i=
nternet-drafts/draft-jones-appsawg-webfinger-00.txt

 


The tools for Webfinger are now=
 defined, but the procedures need to be clearer with respect to what most o=
f us understand as “webfinger”.  This is just a first stab=
 at making that happen and we hope to progress this to
 publish an RFC in the application area.


 


We welcome any comments you hav=
e on the topic, either privately or publicly.


 


Paul


 




















Questo messaggio e i suoi allegati sono indiriz=
zati 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 mitte=
nte e di provvedere alla sua distruzione,
 Grazie. 




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



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









 















=
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_A09A9E0A4B9C654E8672D1DC003633AE405700681DGRFMBX704BA02_--

--_004_A09A9E0A4B9C654E8672D1DC003633AE405700681DGRFMBX704BA02_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=677;
	creation-date="Wed, 23 Nov 2011 09:45:25 GMT";
	modification-date="Wed, 23 Nov 2011 09:45:25 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

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=

--_004_A09A9E0A4B9C654E8672D1DC003633AE405700681DGRFMBX704BA02_--

--_912a8741-c504-4f0e-bd24-29d2dd6a770c_
Content-Description: logo Ambiente_foglia.jpg
Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg"
Content-Disposition: inline; filename="logo Ambiente_foglia.jpg"
Content-Transfer-Encoding: base64
Content-ID: 00000000000000000000000000000001@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=

--_912a8741-c504-4f0e-bd24-29d2dd6a770c_--

From julian.reschke@gmx.de  Wed Nov 23 01:12:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603BF21F8C41 for ; Wed, 23 Nov 2011 01:12:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.306
X-Spam-Level: 
X-Spam-Status: No, score=-104.306 tagged_above=-999 required=5 tests=[AWL=-1.707, 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 lR1ni57GC7-0 for ; Wed, 23 Nov 2011 01:12:37 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2B75721F8C40 for ; Wed, 23 Nov 2011 01:12:36 -0800 (PST)
Received: (qmail invoked by alias); 23 Nov 2011 09:12:34 -0000
Received: from p5DCC2ED4.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.46.212] by mail.gmx.net (mp011) with SMTP; 23 Nov 2011 10:12:34 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+aj1FxSW6aC/xnhnMl9eq8iC4Fkfl/4O6vek6+CM nujwrRywQUKJMJ
Message-ID: <4ECCB8FA.20804@gmx.de>
Date: Wed, 23 Nov 2011 10:12:26 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Martin Thomson 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>  <4ECB9E69.8090505@gmx.de> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 09:12:38 -0000

On 2011-11-23 00:17, Martin Thomson wrote:
>> So yes, the fact that a JSON name can be anything a JSON string can take is
>> indeed a problem, because it doesn't leave us any characters as delimiters
>> (so this is very different from XML vs XPath).
>
> Maybe you could use a JSON string notation as your canonical form:
>
> { "Bjørn/Carsten/foo \uD834\uDD1E" : "Fritz" }
> ->
> "/\"Bjørn/Carsten/foo \uD834\uDD1E\""

I like that.

Best regards, Julian


From julian.reschke@gmx.de  Wed Nov 23 04:38:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A9E21F8C5F for ; Wed, 23 Nov 2011 04:38:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.008
X-Spam-Level: 
X-Spam-Status: No, score=-104.008 tagged_above=-999 required=5 tests=[AWL=-1.409, 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 dRlw9Lza4ham for ; Wed, 23 Nov 2011 04:38:34 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 49BFD21F8C50 for ; Wed, 23 Nov 2011 04:38:26 -0800 (PST)
Received: (qmail invoked by alias); 23 Nov 2011 12:38:24 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 23 Nov 2011 13:38:24 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19w4RI9HxJwvUNWBhtDrzr1iwo5oJqOVMPVBFo4DN uZTO0XKYNHduu6
Message-ID: <4ECCE93C.406@gmx.de>
Date: Wed, 23 Nov 2011 13:38:20 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul C. Bryan" 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <1321986297.2091.1.camel@neutron>
In-Reply-To: <1321986297.2091.1.camel@neutron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 12:38:34 -0000

On 2011-11-22 19:24, Paul C. Bryan wrote:
> Looks good to me. I don't think "end" is needed, as the end index can be
> explicitly specified.
> ...

Ack.

Also, we may want to say that to="" currently only allows an array 
index; and that anything else is reserved for future use (such as moving 
things around in the tree).

Best regards, Julian

From julian.reschke@gmx.de  Wed Nov 23 05:17:51 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA41921F8CA4 for ; Wed, 23 Nov 2011 05:17:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.966
X-Spam-Level: 
X-Spam-Status: No, score=-103.966 tagged_above=-999 required=5 tests=[AWL=-1.367, 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 oDpUeXqQAx1t for ; Wed, 23 Nov 2011 05:17:51 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 02D1D21F8C85 for ; Wed, 23 Nov 2011 05:17:50 -0800 (PST)
Received: (qmail invoked by alias); 23 Nov 2011 13:17:49 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp016) with SMTP; 23 Nov 2011 14:17:49 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18IkzMNQGYIx+3+a/FVZuezf3W2sGqVwsKdfkWnuY tNN4MiSwSUm5UG
Message-ID: <4ECCF277.2030403@gmx.de>
Date: Wed, 23 Nov 2011 14:17:43 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: IETF Apps Discuss 
References: <4ECA5C66.1040305@gmx.de>
In-Reply-To: <4ECA5C66.1040305@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: draft-pbryan-zyp-json-pointer@tools.ietf.org
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 13:17:52 -0000

On 2011-11-21 15:12, Julian Reschke wrote:
> ...

Summarizing the open questions:

1) Which characters to *allow* in a JSON pointer (independently of where 
it appears)

1a) Allow non-ASCII (also, how to represent non-BMP characters)

1b) Allow ASCII characters that are reserved in URIs

2) What to use as delimiter, given the fact JSON identifiers allow 
anything that can occur in a JSON string (or: how to represent the "/")

3) How to map a JSON pointer to something that can be used inside a URI 
(path, query?, fragment identifier)


My two cents:

1a) yes, and represent a surrogate pair by the Unicode character it 
represents

1b) yes

2) I have no good idea; James suggested the Unicode replacement 
character, another idea would be a private use code point; using a 
JSON-escape ("\") has the drawback that it needs additional escaping in 
a URI, and that it may be hard to distinguish from the escaped variant 
when it appears in a JSON document, such as JSON-Patch)

3) encode-as-UTF8-then-percent-escape-everything-reserved-in-URI

Best regards, Julian

From paul.bryan@forgerock.com  Wed Nov 23 09:19:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C2621F8B27 for ; Wed, 23 Nov 2011 09:19:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.654
X-Spam-Level: 
X-Spam-Status: No, score=-6.654 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, 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 E2YBMZmEM9G2 for ; Wed, 23 Nov 2011 09:19:29 -0800 (PST)
Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) by ietfa.amsl.com (Postfix) with SMTP id D65CA1F0C3F for ; Wed, 23 Nov 2011 09:19:28 -0800 (PST)
Received: from mail-yw0-f47.google.com ([209.85.213.47]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKTs0rDvZcw9+2S8gh7NmaeQ/ushhwygVw@postini.com; Wed, 23 Nov 2011 17:19:29 UTC
Received: by mail-yw0-f47.google.com with SMTP id 20so1634609ywb.20 for ; Wed, 23 Nov 2011 09:19:10 -0800 (PST)
Received: by 10.236.129.244 with SMTP id h80mr36288519yhi.130.1322068750696; Wed, 23 Nov 2011 09:19:10 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id m29sm25960146yhi.20.2011.11.23.09.19.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 09:19:08 -0800 (PST)
Message-ID: <1322068744.6133.1.camel@neutron>
From: "Paul C. Bryan" 
To: apps-discuss@ietf.org
Date: Wed, 23 Nov 2011 09:19:04 -0800
In-Reply-To: <4ECCE93C.406@gmx.de>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <1321986297.2091.1.camel@neutron> <4ECCE93C.406@gmx.de>
Content-Type: multipart/alternative; boundary="=-rxW4rLNaKXEsVKQheAq7"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 17:19:30 -0000

--=-rxW4rLNaKXEsVKQheAq7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

I'm now inclined to simply make "to" a JSON pointer as well.
Semantically it's clear, It's easy to apply, and JSON diff
implementations can be smart if they want and notice something moved
from one node in the graph to another.

Paul  

On Wed, 2011-11-23 at 13:38 +0100, Julian Reschke wrote:

> On 2011-11-22 19:24, Paul C. Bryan wrote:
> > Looks good to me. I don't think "end" is needed, as the end index can be
> > explicitly specified.
> > ...
> 
> Ack.
> 
> Also, we may want to say that to="" currently only allows an array 
> index; and that anything else is reserved for future use (such as moving 
> things around in the tree).
> 
> Best regards, Julian



--=-rxW4rLNaKXEsVKQheAq7
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


I'm now inclined to simply make "to" a JSON pointer as well. Semantically it's clear, It's easy to apply, and JSON diff implementations can be smart if they want and notice something moved from one node in the graph to another.



Paul  



On Wed, 2011-11-23 at 13:38 +0100, Julian Reschke wrote:



On 2011-11-22 19:24, Paul C. Bryan wrote:
> Looks good to me. I don't think "end" is needed, as the end index can be
> explicitly specified.
> ...

Ack.

Also, we may want to say that to="" currently only allows an array 
index; and that anything else is reserved for future use (such as moving 
things around in the tree).

Best regards, Julian









--=-rxW4rLNaKXEsVKQheAq7--


From julian.reschke@gmx.de  Wed Nov 23 09:37:44 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F9111E80A5 for ; Wed, 23 Nov 2011 09:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.984
X-Spam-Level: 
X-Spam-Status: No, score=-103.984 tagged_above=-999 required=5 tests=[AWL=-1.385, 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 80RMS1dU8D2T for ; Wed, 23 Nov 2011 09:37:43 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CBA3411E80A3 for ; Wed, 23 Nov 2011 09:37:42 -0800 (PST)
Received: (qmail invoked by alias); 23 Nov 2011 17:37:40 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp007) with SMTP; 23 Nov 2011 18:37:40 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+4OFdSkxm4MOYwNc3ra0vYDjXguxJJEazMNEPg0m FVdo1nyGmXlEYM
Message-ID: <4ECD2F60.5080902@gmx.de>
Date: Wed, 23 Nov 2011 18:37:36 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul C. Bryan" 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <1321986297.2091.1.camel@neutron> <4ECCE93C.406@gmx.de> <1322068744.6133.1.camel@neutron>
In-Reply-To: <1322068744.6133.1.camel@neutron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 17:37:44 -0000

On 2011-11-23 18:19, Paul C. Bryan wrote:
> I'm now inclined to simply make "to" a JSON pointer as well.
> Semantically it's clear, It's easy to apply, and JSON diff
> implementations can be smart if they want and notice something moved
> from one node in the graph to another.

+1, except that I'm not convinced that leaving this optional is a good 
idea...


From paul.bryan@forgerock.com  Wed Nov 23 10:02:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218DA11E80FF for ; Wed, 23 Nov 2011 10:02:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.651
X-Spam-Level: 
X-Spam-Status: No, score=-6.651 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, 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 zNZ0YqcoRsiY for ; Wed, 23 Nov 2011 10:02:29 -0800 (PST)
Received: from eu1sys200aog111.obsmtp.com (eu1sys200aog111.obsmtp.com [207.126.144.131]) by ietfa.amsl.com (Postfix) with SMTP id A057011E8100 for ; Wed, 23 Nov 2011 10:02:28 -0800 (PST)
Received: from mail-gx0-f173.google.com ([209.85.161.173]) (using TLSv1) by eu1sys200aob111.postini.com ([207.126.147.11]) with SMTP ID DSNKTs01MUeipGS59/vo/FcDz7PUFqL30FN9@postini.com; Wed, 23 Nov 2011 18:02:28 UTC
Received: by mail-gx0-f173.google.com with SMTP id b1so1962439ggn.4 for ; Wed, 23 Nov 2011 10:02:25 -0800 (PST)
Received: by 10.236.154.3 with SMTP id g3mr38444106yhk.119.1322071344951; Wed, 23 Nov 2011 10:02:24 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id 4sm5484252ano.9.2011.11.23.10.02.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 10:02:24 -0800 (PST)
Message-ID: <1322071342.6133.14.camel@neutron>
From: "Paul C. Bryan" 
To: apps-discuss@ietf.org
Date: Wed, 23 Nov 2011 10:02:22 -0800
In-Reply-To: <4ECD2F60.5080902@gmx.de>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <1321986297.2091.1.camel@neutron> <4ECCE93C.406@gmx.de> <1322068744.6133.1.camel@neutron> <4ECD2F60.5080902@gmx.de>
Content-Type: multipart/alternative; boundary="=-K9VWghtkXs+PRItISSjD"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 18:02:30 -0000

--=-K9VWghtkXs+PRItISSjD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Wed, 2011-11-23 at 18:37 +0100, Julian Reschke wrote:

> On 2011-11-23 18:19, Paul C. Bryan wrote:
> > I'm now inclined to simply make "to" a JSON pointer as well.
> > Semantically it's clear, It's easy to apply, and JSON diff
> > implementations can be smart if they want and notice something moved
> > from one node in the graph to another.
> 
> +1, except that I'm not convinced that leaving this optional is a good 
> idea...



I'd say if JSON pointer is adopted for "to", it should only be JSON
pointer.

Paul

--=-K9VWghtkXs+PRItISSjD
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


On Wed, 2011-11-23 at 18:37 +0100, Julian Reschke wrote:



On 2011-11-23 18:19, Paul C. Bryan wrote:
> I'm now inclined to simply make "to" a JSON pointer as well.
> Semantically it's clear, It's easy to apply, and JSON diff
> implementations can be smart if they want and notice something moved
> from one node in the graph to another.

+1, except that I'm not convinced that leaving this optional is a good 
idea...








I'd say if JSON pointer is adopted for "to", it should only be JSON pointer.



Paul



--=-K9VWghtkXs+PRItISSjD--


From julian.reschke@gmx.de  Wed Nov 23 10:06:45 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31C621F8B86 for ; Wed, 23 Nov 2011 10:06:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.964
X-Spam-Level: 
X-Spam-Status: No, score=-103.964 tagged_above=-999 required=5 tests=[AWL=-1.365, 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 Z8oDMcIrv5-h for ; Wed, 23 Nov 2011 10:06:44 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0F39221F8B85 for ; Wed, 23 Nov 2011 10:06:43 -0800 (PST)
Received: (qmail invoked by alias); 23 Nov 2011 18:06:39 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp045) with SMTP; 23 Nov 2011 19:06:39 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/YdsEzGvvYBhMqj3V2pvTHtN9z5523i7xLkt2G9f O+uG78XEUmz2Nv
Message-ID: <4ECD3627.702@gmx.de>
Date: Wed, 23 Nov 2011 19:06:31 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Paul C. Bryan" 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <1321986297.2091.1.camel@neutron> <4ECCE93C.406@gmx.de> <1322068744.6133.1.camel@neutron> <4ECD2F60.5080902@gmx.de> <1322071342.6133.14.camel@neutron>
In-Reply-To: <1322071342.6133.14.camel@neutron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 18:06:45 -0000

On 2011-11-23 19:02, Paul C. Bryan wrote:
> On Wed, 2011-11-23 at 18:37 +0100, Julian Reschke wrote:
>> On 2011-11-23 18:19, Paul C. Bryan wrote:
>> >  I'm now inclined to simply make"to"  a JSON pointer as well.
>> >  Semantically it's clear, It's easy to apply, and JSON diff
>> >  implementations can be smart if they want and notice something moved
>> >  from one node in the graph to another.
>>
>> +1, except that I'm not convinced that leaving this optional is a good
>> idea...
>
> I'd say if JSON pointer is adopted for "to", it should only be JSON pointer.
>
> Paul

Works for me.

(What I had in mind was to consider something not starting with / as 
relative pointer...)

Best regards, Julian

From paul.bryan@forgerock.com  Wed Nov 23 10:12:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA18F21F8B5C for ; Wed, 23 Nov 2011 10:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.648
X-Spam-Level: 
X-Spam-Status: No, score=-6.648 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, 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 IVlFPjWVK-0u for ; Wed, 23 Nov 2011 10:12:10 -0800 (PST)
Received: from eu1sys200aog113.obsmtp.com (eu1sys200aog113.obsmtp.com [207.126.144.135]) by ietfa.amsl.com (Postfix) with SMTP id 00F5A21F8B46 for ; Wed, 23 Nov 2011 10:12:09 -0800 (PST)
Received: from mail-yx0-f180.google.com ([209.85.213.180]) (using TLSv1) by eu1sys200aob113.postini.com ([207.126.147.11]) with SMTP ID DSNKTs03eWhrLmO/qUHqkWgr4Dbh+2Ir8cUe@postini.com; Wed, 23 Nov 2011 18:12:10 UTC
Received: by mail-yx0-f180.google.com with SMTP id l7so933431yen.11 for ; Wed, 23 Nov 2011 10:12:09 -0800 (PST)
Received: by 10.101.115.1 with SMTP id s1mr5542858anm.164.1322071928853; Wed, 23 Nov 2011 10:12:08 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id m33sm50705640ann.4.2011.11.23.10.12.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 10:12:07 -0800 (PST)
Message-ID: <1322071926.6133.20.camel@neutron>
From: "Paul C. Bryan" 
To: apps-discuss@ietf.org
Date: Wed, 23 Nov 2011 10:12:06 -0800
In-Reply-To: <4ECCB8FA.20804@gmx.de>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>  <4ECB9E69.8090505@gmx.de>  <4ECCB8FA.20804@gmx.de>
Content-Type: multipart/alternative; boundary="=-vHnBBPWbRaxPTfRnKUmA"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 18:12:12 -0000

--=-vHnBBPWbRaxPTfRnKUmA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

So far I can't say I like it very much. Is the suggestion that every
member name in a JSON pointer reference must contain \" ... \"? This
makes for one ugly pointer in JSON, and absolutely guarantees that a
fragment identifier will contain multiple percent-encoded values, even
if there are no members that contain path delimiters.

#/a/b/c ↠intuitive
#/%5C%22a%5C%22/%5C%22b%5C%22/%5C%22c%5C%22 ↠not!  

Paul

On Wed, 2011-11-23 at 10:12 +0100, Julian Reschke wrote:

> On 2011-11-23 00:17, Martin Thomson wrote:
> >> So yes, the fact that a JSON name can be anything a JSON string can take is
> >> indeed a problem, because it doesn't leave us any characters as delimiters
> >> (so this is very different from XML vs XPath).
> >
> > Maybe you could use a JSON string notation as your canonical form:
> >
> > { "Bjørn/Carsten/foo \uD834\uDD1E" : "Fritz" }
> > ->
> > "/\"Bjørn/Carsten/foo \uD834\uDD1E\""
> 
> I like that.
> 
> Best regards, Julian
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



--=-vHnBBPWbRaxPTfRnKUmA
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


So far I can't say I like it very much. Is the suggestion that every member name in a JSON pointer reference must contain \" ... \"? This makes for one ugly pointer in JSON, and absolutely guarantees that a fragment identifier will contain multiple percent-encoded values, even if there are no members that contain path delimiters.



#/a/b/c ← intuitive

#/%5C%22a%5C%22/%5C%22b%5C%22/%5C%22c%5C%22 ← not!  



Paul



On Wed, 2011-11-23 at 10:12 +0100, Julian Reschke wrote:



On 2011-11-23 00:17, Martin Thomson wrote:
>> So yes, the fact that a JSON name can be anything a JSON string can take is
>> indeed a problem, because it doesn't leave us any characters as delimiters
>> (so this is very different from XML vs XPath).
>
> Maybe you could use a JSON string notation as your canonical form:
>
> { "Bjørn/Carsten/foo \uD834\uDD1E" : "Fritz" }
> ->
> "/\"Bjørn/Carsten/foo \uD834\uDD1E\""

I like that.

Best regards, Julian

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









--=-vHnBBPWbRaxPTfRnKUmA--


From cabo@tzi.org  Wed Nov 23 13:37:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6719C21F8480 for ; Wed, 23 Nov 2011 13:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.069
X-Spam-Level: 
X-Spam-Status: No, score=-106.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 L-S0Ud-EJqlr for ; Wed, 23 Nov 2011 13:37:52 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9715E1F0C36 for ; Wed, 23 Nov 2011 13:37:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pANLbcKV005537; Wed, 23 Nov 2011 22:37:38 +0100 (CET)
Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AB6F1A84; Wed, 23 Nov 2011 22:37:37 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=utf-8
From: Carsten Bormann 
In-Reply-To: <1322071926.6133.20.camel@neutron>
Date: Wed, 23 Nov 2011 22:37:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>  <4ECB9E69.8090505@gmx.de>  <4ECCB8FA.20804@gmx.de> <1322071926.6133.20.camel@neutron>
To: "Paul C. Bryan" 
X-Mailer: Apple Mail (2.1251.1)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 21:37:52 -0000

On Nov 23, 2011, at 19:12, Paul C. Bryan wrote:

> #/a/b/c =E2=86=90 intuitive
> #/%5C%22a%5C%22/%5C%22b%5C%22/%5C%22c%5C%22 =E2=86=90 not! =20

As usual, the guiding principle is that easy things should be easy, and =
that hard things should be possible.
Complicating the usual case (the only one that many people seem to have =
thought about yet) is indeed a big no-no.

Gr=C3=BC=C3=9Fe, Carsten


From martin.thomson@gmail.com  Wed Nov 23 17:59:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2291F0C3C for ; Wed, 23 Nov 2011 17:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGwpHa6Lkr5T for ; Wed, 23 Nov 2011 17:59:25 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5E351F0C35 for ; Wed, 23 Nov 2011 17:59:19 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so2178487bkb.31 for ; Wed, 23 Nov 2011 17:59:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JxPdzCzu89hShx08CYVV3Idt6LZPFzQQnBq5iUsUP10=; b=kG+jQK8IMLA6t6lDT2mimGGexppWCXA4cF/Ddxe6WwlgE6RgMVLp1zamqhkS3Xgjhm X7iB7Trps2JNBynq0LnZJ9avX4rXysE96LuM8ondN6PXZfvUCtaHy8bsA5dGR0gPZk2k TM8GOt/vlgjp8mQ0UPCS99Svj2WGkb1LYQHiA=
MIME-Version: 1.0
Received: by 10.204.154.6 with SMTP id m6mr27338353bkw.20.1322099958731; Wed, 23 Nov 2011 17:59:18 -0800 (PST)
Received: by 10.204.72.210 with HTTP; Wed, 23 Nov 2011 17:59:18 -0800 (PST)
In-Reply-To: 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>  <4ECB9E69.8090505@gmx.de>  <4ECCB8FA.20804@gmx.de> <1322071926.6133.20.camel@neutron> 
Date: Thu, 24 Nov 2011 12:59:18 +1100
Message-ID: 
From: Martin Thomson 
To: Carsten Bormann 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 01:59:26 -0000

On 24 November 2011 08:37, Carsten Bormann  wrote:
> As usual, the guiding principle is that easy things should be easy, and t=
hat hard things should be possible.
> Complicating the usual case (the only one that many people seem to have t=
hought about yet) is indeed a big no-no.
>
> Gr=C3=BC=C3=9Fe, Carsten

A reasonable suggestion.  Maybe just drop the quotes and force an
escape for / instead of ":

  /Bj=C3=B8rn\/Carsten\/foo \uD834\uDD1E

From martin.thomson@gmail.com  Wed Nov 23 18:03:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D6311E8098 for ; Wed, 23 Nov 2011 18:03:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL8iacsRUtYB for ; Wed, 23 Nov 2011 18:03:08 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C137D11E80B5 for ; Wed, 23 Nov 2011 18:03:07 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so2182323bkb.31 for ; Wed, 23 Nov 2011 18:03:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=S6Dyjs8LVbGyOlxtHlX/KLxkXDeAHH3N6VhpRyhHru8=; b=e3gsqcWEwslm+LzDZAPbEn85T9qMdcYj2eDtDCkay3dfkmgTTwZlEJ/Yiw7wxnrTB0 4arSUQjFMMMUDXHJH9CwNlR4+KGstS8JJBResxBBWX1CVGQ6IUK7jG8TLiYG6DeYAwAu hO5z/VtWc0L67NogyXVHRPqXesp/2WeceYlp4=
MIME-Version: 1.0
Received: by 10.204.152.4 with SMTP id e4mr26345085bkw.56.1322100186762; Wed, 23 Nov 2011 18:03:06 -0800 (PST)
Received: by 10.204.72.210 with HTTP; Wed, 23 Nov 2011 18:03:06 -0800 (PST)
In-Reply-To: <4ECBC843.60900@gmx.de>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de>
Date: Thu, 24 Nov 2011 13:03:06 +1100
Message-ID: 
From: Martin Thomson 
To: Julian Reschke 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 02:03:09 -0000

On 23 November 2011 03:05, Julian Reschke  wrote:
> =C2=A0 The "move" operation moves an existing array element. The "to" mem=
ber
> indicates the array position as integer value. This operation is equivale=
nt
> to removing the element identified by "move", an inserting it again at th=
e
> position "to".
> =C2=A0 A JSON Patch document:
>
> =C2=A0 [
> =C2=A0 =C2=A0 =C2=A0 { "move": "/foo/1", "to": 2}
> =C2=A0 ]

A thought occurred.  What about this?

[
  { "move" : "/foo/1", "to": "/foo/2" }
]

And allow for movement anywhere in the document.

From martin.thomson@gmail.com  Wed Nov 23 18:08:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0499C21F86C3 for ; Wed, 23 Nov 2011 18:08:32 -0800 (PST)
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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 EIReHlHRtp7n for ; Wed, 23 Nov 2011 18:08:31 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 380CF21F8783 for ; Wed, 23 Nov 2011 18:08:31 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so2188062bkb.31 for ; Wed, 23 Nov 2011 18:08:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R1Ayp3cjqxgVuU0YpCwyaAPxUyDItaQDSQjNayX0xok=; b=yECTPJ+Tp9dRgxz1Dgv23QtmF7a0lo+3JWl5KSuSr0HSnaYDUU73Cc+eiSp0RNu1Vw ib90PlDRLw3KyOTDdHcE+5QWdkZM+15yvOr2l6A4kNcRqOxCM17bv1wyjkyjF2YFZVGl +KWuJLqUeDYNz+rt7e3SIHkfE7+Egy2Yy4V0c=
MIME-Version: 1.0
Received: by 10.205.133.16 with SMTP id hw16mr25953162bkc.128.1322100510257; Wed, 23 Nov 2011 18:08:30 -0800 (PST)
Received: by 10.204.72.210 with HTTP; Wed, 23 Nov 2011 18:08:30 -0800 (PST)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E113884047C4@WSMSG3153V.srv.dir.telstra.com>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <255B9BB34FB7D647A506DC292726F6E113884047C4@WSMSG3153V.srv.dir.telstra.com>
Date: Thu, 24 Nov 2011 13:08:30 +1100
Message-ID: 
From: Martin Thomson 
To: "Manger, James H" 
Content-Type: text/plain; charset=UTF-8
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 02:08:32 -0000

On 23 November 2011 12:21, Manger, James H
 wrote:
> On escaping: how about replacing every '/' in an object member's name with the Unicode REPLACEMENT CHARACTER U+FFFD when creating a JSON pointer.

Interesting that you choose U+FFFD in the same way that backslash was
chosen as an escape character in the first place.  I'm not a big fan
of that approach.  It also results in a nine character escape sequence
for a URI if you UTF-8 and %-encode.

> It means a JSON pointer cannot reference an object member that actually has a U+FFFD char in its name [...]

I might just start using that if you decide to prohibit it now.

--Martin

From tony@att.com  Wed Nov 23 18:19:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D7611E80A4 for ; Wed, 23 Nov 2011 18:19:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.171
X-Spam-Level: 
X-Spam-Status: No, score=-106.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, 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 gSJDj65C+ksY for ; Wed, 23 Nov 2011 18:19:30 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id CE1C711E8098 for ; Wed, 23 Nov 2011 18:19:29 -0800 (PST)
X-Env-Sender: tony@att.com
X-Msg-Ref: server-9.tower-119.messagelabs.com!1322101167!2588382!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20055 invoked from network); 24 Nov 2011 02:19:27 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Nov 2011 02:19:27 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAO2JtOG013125 for ; Wed, 23 Nov 2011 21:19:55 -0500
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAO2JnZn012841 for ; Wed, 23 Nov 2011 21:19:50 -0500
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pAO2JKYm006175 for ; Wed, 23 Nov 2011 21:19:20 -0500
Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pAO2JFOH005918 for ; Wed, 23 Nov 2011 21:19:15 -0500
Received: from [135.70.245.180] (vpn-135-70-245-180.vpn.east.att.com[135.70.245.180]) by maillennium.att.com (mailgw1) with ESMTP id <20111124021810gw100e4lu5e> (Authid: tony); Thu, 24 Nov 2011 02:18:10 +0000
X-Originating-IP: [135.70.245.180]
Message-ID: <4ECDA9A2.7010502@att.com>
Date: Wed, 23 Nov 2011 21:19:14 -0500
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <1321986297.2091.1.camel@neutron> <4ECCE93C.406@gmx.de> <1322068744.6133.1.camel@neutron> <4ECD2F60.5080902@gmx.de> <1322071342.6133.14.camel@neutron> <4ECD3627.702@gmx.de>
In-Reply-To: <4ECD3627.702@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 02:19:30 -0000

On 11/23/2011 1:06 PM, Julian Reschke wrote:
> On 2011-11-23 19:02, Paul C. Bryan wrote:
>> On Wed, 2011-11-23 at 18:37 +0100, Julian Reschke wrote:
>>> On 2011-11-23 18:19, Paul C. Bryan wrote:
>>> >  I'm now inclined to simply make"to"  a JSON pointer as well.
>>> >  Semantically it's clear, It's easy to apply, and JSON diff
>>> >  implementations can be smart if they want and notice something moved
>>> >  from one node in the graph to another.
>>>
>>> +1, except that I'm not convinced that leaving this optional is a good
>>> idea...
>>
>> I'd say if JSON pointer is adopted for "to", it should only be JSON 
>> pointer.
>>
>> Paul
>
> Works for me.
>
> (What I had in mind was to consider something not starting with / as 
> relative pointer...)

If you introduce relative pointers, you also need the concept of .. to 
move up the path, and have to define semantics for moving past the 
beginning of the path, and the concept of normalizing a path, and 
probably a dozen other things that are normally part of relative pathing.

In thinking about the example, I find "/foo/2" much clearer than just 
"2" as the target.

Given that Javascript uses 0-based arrays, should we also be using 
0-based paths here? Or has that horse already left the barn?

     Tony Hansen

From derhoermi@gmx.net  Wed Nov 23 19:34:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16861F0C3B for ; Wed, 23 Nov 2011 19:34:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.945
X-Spam-Level: 
X-Spam-Status: No, score=-2.945 tagged_above=-999 required=5 tests=[AWL=-0.346, 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 6XbmQnTZc-7Z for ; Wed, 23 Nov 2011 19:34:46 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8F91A1F0C3C for ; Wed, 23 Nov 2011 19:34:45 -0800 (PST)
Received: (qmail invoked by alias); 24 Nov 2011 03:34:43 -0000
Received: from dslb-094-222-149-170.pools.arcor-ip.net (EHLO HIVE) [94.222.149.170] by mail.gmx.net (mp064) with SMTP; 24 Nov 2011 04:34:43 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+Rz+Udjo2RayDYcz29SSha/c0OJYA2Bp02D9kjYI 13deF1FkGMxhxf
From: Bjoern Hoehrmann 
To: "Paul E. Jones" 
Date: Thu, 24 Nov 2011 04:34:42 +0100
Message-ID: 
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>
In-Reply-To: <032101cc9288$e3a06910$aae13b30$@packetizer.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Joseph Smarr , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 03:34:47 -0000

* Paul E. Jones wrote:
>http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

There:

   Suppose you meet somebody at a party and they provide you with their
   email address.  After the party, you decide to visit your new
   friend's blog to learn more about them.  How do you find it?  You
   could search for your friend's name on the Internet or on various
   social networking sites, but sometimes it is very hard to locate a
   person or information about a person with merely an email address or
   a name.

I believe the technical term for that is "cyberstalking". What are you
planning to do to ensure the draft properly addresses security, privacy,
and netiquette issues? Right now the document seems to omit the reasons
for why the finger protocol did not gain traction, which revolve around
privacy and social engineering security issues, does not discuss neti-
quette at all, just has a "if you don't like it, don't use it" remark
in the Security Considerations, and has an ironic "Author's Addresses"
section.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From mnot@mnot.net  Wed Nov 23 22:21:49 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4C811E8091; Wed, 23 Nov 2011 22:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.307
X-Spam-Level: 
X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[AWL=-2.708, 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 PT0FfYnWYJ61; Wed, 23 Nov 2011 22:21:48 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6A49311E80D4; Wed, 23 Nov 2011 22:21:48 -0800 (PST)
Received: from mnot-mini.mnot.net (unknown [118.209.80.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C919850A5D; Thu, 24 Nov 2011 01:21:41 -0500 (EST)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 24 Nov 2011 17:21:35 +1100
Message-Id: <380D90BE-FAAE-4BF4-BDC4-B177E2A73205@mnot.net>
To: IETF Apps Discuss , draft-ietf-oauth-v2-bearer.all@ietf.org
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Cc: The IESG 
Subject: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 06:21:49 -0000

I have been selected as the Applications Area Review Team reviewer for =
this draft (for background on apps-review, please see =
).

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-oauth-v2-bearer-14
Title: OAuth 2.0 Bearer Tokens
Reviewer: Mark Nottingham
Review Date: 24/11/2011

Summary: This draft is almost ready for publication as a Proposed =
Standard, but has a few issues that should be fixed.

Major Issues
------------

* Section 2.3 URI Query Parameter

This section effectively reserves a URI query parameter for the draft's =
use. This should not be done lightly, since this would be a precedent =
for the IETF encroaching upon a server's URIs (done previously in =
RFC5785, but in a much more limited fashion, as a tactic to prevent =
further, uncontrolled encroachment).

Given that the draft already discourages the use of this mechanism, I'd =
recommend dropping it altogether. If the Working Group wishes it to =
remain, this issues should be vetted both through the APPS area and the =
W3C liaison.

(The same criticism could be leveled at Section 2.2 Form-Encoded Body =
Parameter, but that at least isn't surfaced in an identifier)

* Section 3 The WWW-Authenticate Response Header Field

The draft references the quoted-string ABNF from HTTP, but changes its =
processing in a later paragraph:

"""In all these cases, no character quoting will occur, as senders are =
prohibited from using the %5C ('\') character."""

This is at best surprising (as many readers will reasonably surmise that =
using the quoted-string ABNF implies that the same code can be used). =
Please either use quoted-string as defined (i.e., with escaping).


Minor Issues
------------

* Section 1: Introduction

The introduction explains oauth, but it doesn't fully explain the =
relationship of this specification to OAuth 2.0. E.g., can it be used =
independently from the rest of OAuth? Likewise, the overview (section =
1.3) seems more specific to the OAuth specification than this document. =
As I read it, this mechanism could be used for ANY bearer token, not =
just one generated through OAuth flows.=20

If it is indeed more general, I'd recommend minimising the discussion of =
OAuth, perhaps even removing it from the document title.

* Section 3 The WWW-Authenticate Response Header Field

The difference between a realm and a scope is not explained. Are the =
functionally equivalent, just a single value vs. a list?=20

Do you really intend to disallow *all* extension parameters on the =
challenge?

Also, the scope, error, error_description and error_uri parameters all =
specify only a quoted-string serialisation. HTTPbis strongly suggests =
that new schemes allow both forms, because implementation experience has =
shown that implementations will likely support both, no matter how =
defined; this improves interoperability (see p7 2.3.1).=20

Finally, the error_description parameter can carry only ASCII =
characters. While I understand a tradeoff has been made here (and, in my =
judgement, an appropriate one), it's appropriate to highlight this in =
review.

* General

The draft currently doesn't mention whether Bearer is suitable for use =
as a proxy authentication scheme. I suspect it *may*; it would be worth =
discussing this with some proxy implementers to gauge their interest =
(e.g., Squid).=20


Nits
----

* Section 2.1 Authorization Request Header Field

"simplicity reasons" --> "simplicity"

"If additional parameters are desired in the future, a different scheme =
could be defined." --> "If additional parameters are needed in the =
future, a different scheme would need to be defined."

* Section 3 The WWW-Authenticate Response Header Field

The requirement that a resource server MUST include the HTTP =
WWW-Authenticate response header field is odd; really this is at the =
discretion of the server. Is it really necessary to use a conformance =
requirement here?

URI-reference --> URI-Reference

* Section 3.1 Error Codes

405 belongs in the list of typically appropriate status codes as well.


Kind regards,

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




From duerst@it.aoyama.ac.jp  Wed Nov 23 23:14:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453051F0C47 for ; Wed, 23 Nov 2011 23:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.43
X-Spam-Level: 
X-Spam-Status: No, score=-99.43 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, 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 sD5BTPptQi2x for ; Wed, 23 Nov 2011 23:14:23 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 874EB21F86FF for ; Wed, 23 Nov 2011 23:14:22 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAO7ED6D030614 for ; Thu, 24 Nov 2011 16:14:17 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6723_7c8f_e9acd7fa_166b_11e1_afe4_001d096c5782; Thu, 24 Nov 2011 16:14:13 +0900
Received: from [IPv6:::1] ([133.2.210.1]:59958) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 24 Nov 2011 16:14:17 +0900
Message-ID: <4ECDEEC4.3050007@it.aoyama.ac.jp>
Date: Thu, 24 Nov 2011 16:14:12 +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: Martin Thomson 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de>	<1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de>	<4ECBC843.60900@gmx.de>	<255B9BB34FB7D647A506DC292726F6E113884047C4@WSMSG3153V.srv.dir.telstra.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 07:14:24 -0000

On 2011/11/24 11:08, Martin Thomson wrote:
> On 23 November 2011 12:21, Manger, James H
>   wrote:
>> On escaping: how about replacing every '/' in an object member's name with the Unicode REPLACEMENT CHARACTER U+FFFD when creating a JSON pointer.
>
> Interesting that you choose U+FFFD in the same way that backslash was
> chosen as an escape character in the first place.  I'm not a big fan
> of that approach.

Yes, please don't. The semantics of U+FFFD is mostly a character that 
wasn't successfully converted from some other encoding. Overloading that 
with "escaping a slash" is a bad idea.

Regards,    Martin.


> It also results in a nine character escape sequence
> for a URI if you UTF-8 and %-encode.
>
>> It means a JSON pointer cannot reference an object member that actually has a U+FFFD char in its name [...]
>
> I might just start using that if you decide to prohibit it now.
>
> --Martin
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From duerst@it.aoyama.ac.jp  Wed Nov 23 23:16:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997071F0C4F for ; Wed, 23 Nov 2011 23:16:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.726
X-Spam-Level: 
X-Spam-Status: No, score=-99.726 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ux-PGmsVicp for ; Wed, 23 Nov 2011 23:16:10 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id EC0DE1F0C49 for ; Wed, 23 Nov 2011 23:16:02 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAO7G2At032417 for ; Thu, 24 Nov 2011 16:16:02 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6715_5950_2a79f9c0_166c_11e1_afe4_001d096c5782; Thu, 24 Nov 2011 16:16:02 +0900
Received: from [IPv6:::1] ([133.2.210.1]:49012) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 24 Nov 2011 16:16:05 +0900
Message-ID: <4ECDEF31.9040801@it.aoyama.ac.jp>
Date: Thu, 24 Nov 2011 16:16:01 +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: Martin Thomson 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de>	<1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de>	<4ECBC843.60900@gmx.de> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 07:16:10 -0000

On 2011/11/24 11:03, Martin Thomson wrote:
> On 23 November 2011 03:05, Julian Reschke  wrote:
>>    The "move" operation moves an existing array element. The "to" member
>> indicates the array position as integer value. This operation is equivalent
>> to removing the element identified by "move", an inserting it again at the
>> position "to".
>>    A JSON Patch document:
>>
>>    [
>>        { "move": "/foo/1", "to": 2}
>>    ]
>
> A thought occurred.  What about this?
>
> [
>    { "move" : "/foo/1", "to": "/foo/2" }
> ]

The syntax looks good. But what is /foo/2 in the "to" part exactly 
referring to? Is is array position 2 after /foo/1 has been removed? Or 
before?

Regards,    Martin.

From duerst@it.aoyama.ac.jp  Wed Nov 23 23:43:01 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED5C21F84DA for ; Wed, 23 Nov 2011 23:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.727
X-Spam-Level: 
X-Spam-Status: No, score=-99.727 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-mEld-JghOj for ; Wed, 23 Nov 2011 23:43:01 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id D759521F84D4 for ; Wed, 23 Nov 2011 23:43:00 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAO7gxuM020803 for ; Thu, 24 Nov 2011 16:42:59 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6725_5f90_eeacf740_166f_11e1_afe4_001d096c5782; Thu, 24 Nov 2011 16:42:59 +0900
Received: from [IPv6:::1] ([133.2.210.1]:42384) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 24 Nov 2011 16:43:03 +0900
Message-ID: <4ECDF582.1070703@it.aoyama.ac.jp>
Date: Thu, 24 Nov 2011 16:42:58 +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: Martin Thomson 
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron>	<4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron>	<4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron>	<4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net>		<4ECB9E69.8090505@gmx.de>		<4ECCB8FA.20804@gmx.de> <1322071926.6133.20.camel@neutron>	 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 07:43:01 -0000

On 2011/11/24 10:59, Martin Thomson wrote:
> On 24 November 2011 08:37, Carsten Bormann  wrote:
>> As usual, the guiding principle is that easy things should be easy, and that hard things should be possible.
>> Complicating the usual case (the only one that many people seem to have thought about yet) is indeed a big no-no.
>>
>> Grüße, Carsten
>
> A reasonable suggestion.  Maybe just drop the quotes and force an
> escape for / instead of ":
>
>    /Bjørn\/Carsten\/foo \uD834\uDD1E

For the moment, cutting off the surrogate pair at the end, and adding 
something to keep the space visible:

     /Bjørn\/Carsten\/foo bar


Yes indeed. So when defining json pointers, use '\/' to escape a '/' 
(and use '\\' to escape '\') that's part of a string rather than a 
hierarchy delimiter:

     /Bjørn\/Carsten\/foo bar

Then when using that as a fragment identifier, you have to escape the 
'\' (not allowed in URIs/IRIs), and of course the space, but not the '/':

     #/Bjørn%5C/Carsten%5C/foo%20bar

Now I really have no clue why surrogate pairs have to be escaped. Why 
not just use the character? This one didn't show in my mailer or 
browser, but one would assume that mostly the ones that actually show, 
at least in some places, will get used. So the actual pointer would be:

     /Bjørn\/Carsten\/foo ğ„

In a fragment (IRI), that would look like:

     #/Bjørn%5C/Carsten%5C/foo%20ğ„

If an URI fragment is needed, use UTF-8 and %-encoding:

     #/Bj%C3%B8rn%5C/Carsten%5C/foo%20%F0%9D%84%9E

Regards,    Martin.

From paul.bryan@forgerock.com  Wed Nov 23 23:55:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E3021F8AF5 for ; Wed, 23 Nov 2011 23:55:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.646
X-Spam-Level: 
X-Spam-Status: No, score=-6.646 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, 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 P78u5qjMO+7K for ; Wed, 23 Nov 2011 23:55:06 -0800 (PST)
Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) by ietfa.amsl.com (Postfix) with SMTP id 337E721F8A96 for ; Wed, 23 Nov 2011 23:55:06 -0800 (PST)
Received: from mail-gx0-f169.google.com ([209.85.161.169]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKTs34RrGCqIeogpMvaYcHtu0xFi/Fuwow@postini.com; Thu, 24 Nov 2011 07:55:06 UTC
Received: by ggnq1 with SMTP id q1so2795431ggn.0 for ; Wed, 23 Nov 2011 23:54:45 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr39525036yhm.19.1322121285195; Wed, 23 Nov 2011 23:54:45 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id q5sm29483544yhm.7.2011.11.23.23.54.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 23:54:44 -0800 (PST)
Message-ID: <1322121282.2439.5.camel@neutron>
From: "Paul C. Bryan" 
To: apps-discuss@ietf.org
Date: Wed, 23 Nov 2011 23:54:42 -0800
In-Reply-To: <4ECDEF31.9040801@it.aoyama.ac.jp>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de>  <4ECDEF31.9040801@it.aoyama.ac.jp>
Content-Type: multipart/alternative; boundary="=-DvbNhoxv9sIse3vBrZSQ"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 07:55:07 -0000

--=-DvbNhoxv9sIse3vBrZSQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

After.

On Thu, 2011-11-24 at 16:16 +0900, "Martin J. Dürst" wrote:

> 
> On 2011/11/24 11:03, Martin Thomson wrote:
> > On 23 November 2011 03:05, Julian Reschke  wrote:
> >>    The "move" operation moves an existing array element. The "to" member
> >> indicates the array position as integer value. This operation is equivalent
> >> to removing the element identified by "move", an inserting it again at the
> >> position "to".
> >>    A JSON Patch document:
> >>
> >>    [
> >>        { "move": "/foo/1", "to": 2}
> >>    ]
> >
> > A thought occurred.  What about this?
> >
> > [
> >    { "move" : "/foo/1", "to": "/foo/2" }
> > ]
> 
> The syntax looks good. But what is /foo/2 in the "to" part exactly 
> referring to? Is is array position 2 after /foo/1 has been removed? Or 
> before?
> 
> Regards,    Martin.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



--=-DvbNhoxv9sIse3vBrZSQ
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


After.



On Thu, 2011-11-24 at 16:16 +0900, "Martin J. Dürst" wrote:




On 2011/11/24 11:03, Martin Thomson wrote:
> On 23 November 2011 03:05, Julian Reschke<julian.reschke@gmx.de>  wrote:
>>    The "move" operation moves an existing array element. The "to" member
>> indicates the array position as integer value. This operation is equivalent
>> to removing the element identified by "move", an inserting it again at the
>> position "to".
>>    A JSON Patch document:
>>
>>    [
>>        { "move": "/foo/1", "to": 2}
>>    ]
>
> A thought occurred.  What about this?
>
> [
>    { "move" : "/foo/1", "to": "/foo/2" }
> ]

The syntax looks good. But what is /foo/2 in the "to" part exactly 
referring to? Is is array position 2 after /foo/1 has been removed? Or 
before?

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









--=-DvbNhoxv9sIse3vBrZSQ--


From julian.reschke@gmx.de  Thu Nov 24 00:45:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B340F21F8B3C for ; Thu, 24 Nov 2011 00:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.162
X-Spam-Level: 
X-Spam-Status: No, score=-104.162 tagged_above=-999 required=5 tests=[AWL=-1.863, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 FMrVQPnF59bD for ; Thu, 24 Nov 2011 00:45:13 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BE7BA21F8B36 for ; Thu, 24 Nov 2011 00:45:12 -0800 (PST)
Received: (qmail invoked by alias); 24 Nov 2011 08:45:08 -0000
Received: from p5DCC3232.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.50.50] by mail.gmx.net (mp072) with SMTP; 24 Nov 2011 09:45:08 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19v3+VmA7pvp02uaIOjFz7XXkeWC0STficBssOX6i rynkD0bc6drDsX
Message-ID: <4ECE0405.9050103@gmx.de>
Date: Thu, 24 Nov 2011 09:44:53 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de>	<1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de>	<4ECBC843.60900@gmx.de>  <4ECDEF31.9040801@it.aoyama.ac.jp>
In-Reply-To: <4ECDEF31.9040801@it.aoyama.ac.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 08:45:13 -0000

On 2011-11-24 08:16, "Martin J. Dürst" wrote:
>
>
> On 2011/11/24 11:03, Martin Thomson wrote:
>> On 23 November 2011 03:05, Julian Reschke wrote:
>>> The "move" operation moves an existing array element. The "to" member
>>> indicates the array position as integer value. This operation is
>>> equivalent
>>> to removing the element identified by "move", an inserting it again
>>> at the
>>> position "to".
>>> A JSON Patch document:
>>>
>>> [
>>> { "move": "/foo/1", "to": 2}
>>> ]
>>
>> A thought occurred. What about this?
>>
>> [
>> { "move" : "/foo/1", "to": "/foo/2" }
>> ]
>
> The syntax looks good. But what is /foo/2 in the "to" part exactly
> referring to? Is is array position 2 after /foo/1 has been removed? Or
> before?

*After*. See the definition.

Best regards, Julian

From paul.bryan@forgerock.com  Thu Nov 24 09:18:57 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B427D21F8A6C for ; Thu, 24 Nov 2011 09:18:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.644
X-Spam-Level: 
X-Spam-Status: No, score=-6.644 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, 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 4rnqmFpfGkHd for ; Thu, 24 Nov 2011 09:18:56 -0800 (PST)
Received: from eu1sys200aog120.obsmtp.com (eu1sys200aog120.obsmtp.com [207.126.144.149]) by ietfa.amsl.com (Postfix) with SMTP id 1725321F8A57 for ; Thu, 24 Nov 2011 09:18:54 -0800 (PST)
Received: from mail-iy0-f181.google.com ([209.85.210.181]) (using TLSv1) by eu1sys200aob120.postini.com ([207.126.147.11]) with SMTP ID DSNKTs58alomYQaP6q8J5NYR5CSO/hDiZWQ9@postini.com; Thu, 24 Nov 2011 17:18:55 UTC
Received: by iaen33 with SMTP id n33so3816400iae.40 for ; Thu, 24 Nov 2011 09:18:33 -0800 (PST)
Received: by 10.50.12.227 with SMTP id b3mr33868398igc.24.1322155112073; Thu, 24 Nov 2011 09:18:32 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id e2sm89518467ibe.0.2011.11.24.09.18.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Nov 2011 09:18:30 -0800 (PST)
Message-ID: <1322155108.2439.10.camel@neutron>
From: "Paul C. Bryan" 
To: apps-discuss@ietf.org
Date: Thu, 24 Nov 2011 09:18:28 -0800
In-Reply-To: <4ECDF582.1070703@it.aoyama.ac.jp>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net> 	<4ECB9E69.8090505@gmx.de>  <4ECCB8FA.20804@gmx.de> <1322071926.6133.20.camel@neutron>   <4ECDF582.1070703@it.aoyama.ac.jp>
Content-Type: multipart/alternative; boundary="=-B5Do/lMCIJX5bYKIEjCb"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 17:18:57 -0000

--=-B5Do/lMCIJX5bYKIEjCb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

I don't think this will work because every JSON parser I've used so far
processes "\/" as solidus "/". By the time it's parsed, there is no
escaping left. Or did I misinterpret, and in actual fact the backslash
would be doubled in actual JSON expression (e.g. "/Bjørn\\/Carsten\\/foo
bar")? That could work. 

Paul

On Thu, 2011-11-24 at 16:42 +0900, "Martin J. Dürst" wrote:

> On 2011/11/24 10:59, Martin Thomson wrote:
> > On 24 November 2011 08:37, Carsten Bormann  wrote:
> >> As usual, the guiding principle is that easy things should be easy, and that hard things should be possible.
> >> Complicating the usual case (the only one that many people seem to have thought about yet) is indeed a big no-no.
> >>
> >> Grüße, Carsten
> >
> > A reasonable suggestion.  Maybe just drop the quotes and force an
> > escape for / instead of ":
> >
> >    /Bjørn\/Carsten\/foo \uD834\uDD1E
> 
> For the moment, cutting off the surrogate pair at the end, and adding 
> something to keep the space visible:
> 
>      /Bjørn\/Carsten\/foo bar
> 
> 
> Yes indeed. So when defining json pointers, use '\/' to escape a '/' 
> (and use '\\' to escape '\') that's part of a string rather than a 
> hierarchy delimiter:
> 
>      /Bjørn\/Carsten\/foo bar
> 
> Then when using that as a fragment identifier, you have to escape the 
> '\' (not allowed in URIs/IRIs), and of course the space, but not the '/':
> 
>      #/Bjørn%5C/Carsten%5C/foo%20bar
> 
> Now I really have no clue why surrogate pairs have to be escaped. Why 
> not just use the character? This one didn't show in my mailer or 
> browser, but one would assume that mostly the ones that actually show, 
> at least in some places, will get used. So the actual pointer would be:
> 
>      /Bjørn\/Carsten\/foo ğ„
> 
> In a fragment (IRI), that would look like:
> 
>      #/Bjørn%5C/Carsten%5C/foo%20ğ„
> 
> If an URI fragment is needed, use UTF-8 and %-encoding:
> 
>      #/Bj%C3%B8rn%5C/Carsten%5C/foo%20%F0%9D%84%9E
> 
> Regards,    Martin.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



--=-B5Do/lMCIJX5bYKIEjCb
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


I don't think this will work because every JSON parser I've used so far processes "\/" as solidus "/". By the time it's parsed, there is no escaping left. Or did I misinterpret, and in actual fact the backslash would be doubled in actual JSON expression (e.g. "/Bjørn\\/Carsten\\/foo bar")? That could work. 



Paul



On Thu, 2011-11-24 at 16:42 +0900, "Martin J. Dürst" wrote:



On 2011/11/24 10:59, Martin Thomson wrote:
> On 24 November 2011 08:37, Carsten Bormann<cabo@tzi.org>  wrote:
>> As usual, the guiding principle is that easy things should be easy, and that hard things should be possible.
>> Complicating the usual case (the only one that many people seem to have thought about yet) is indeed a big no-no.
>>
>> Grüße, Carsten
>
> A reasonable suggestion.  Maybe just drop the quotes and force an
> escape for / instead of ":
>
>    /Bjørn\/Carsten\/foo \uD834\uDD1E

For the moment, cutting off the surrogate pair at the end, and adding 
something to keep the space visible:

     /Bjørn\/Carsten\/foo bar


Yes indeed. So when defining json pointers, use '\/' to escape a '/' 
(and use '\\' to escape '\') that's part of a string rather than a 
hierarchy delimiter:

     /Bjørn\/Carsten\/foo bar

Then when using that as a fragment identifier, you have to escape the 
'\' (not allowed in URIs/IRIs), and of course the space, but not the '/':

     #/Bjørn%5C/Carsten%5C/foo%20bar

Now I really have no clue why surrogate pairs have to be escaped. Why 
not just use the character? This one didn't show in my mailer or 
browser, but one would assume that mostly the ones that actually show, 
at least in some places, will get used. So the actual pointer would be:

     /Bjørn\/Carsten\/foo 𝄞

In a fragment (IRI), that would look like:

     #/Bjørn%5C/Carsten%5C/foo%20𝄞

If an URI fragment is needed, use UTF-8 and %-encoding:

     #/Bj%C3%B8rn%5C/Carsten%5C/foo%20%F0%9D%84%9E

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









--=-B5Do/lMCIJX5bYKIEjCb--


From ietfc@btconnect.com  Thu Nov 24 10:16:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1D21F8B5E for ; Thu, 24 Nov 2011 10:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.329
X-Spam-Level: 
X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270,  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 1l4R4CMyyKy0 for ; Thu, 24 Nov 2011 10:16:18 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8A09E21F8B53 for ; Thu, 24 Nov 2011 10:16:16 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2bthomr14.btconnect.com with SMTP id FGY85532; Thu, 24 Nov 2011 18:13:36 +0000 (GMT)
Message-ID: <092801ccaacc$ada7b000$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "apps-discuss" 
Date: Thu, 24 Nov 2011 18:15:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4ECE894F.005C, actions=tag
X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.11.24.173314:17:9.535, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, TO_IN_SUBJECT, __ANY_URI, __CP_URI_IN_BODY, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4ECE89EF.01B4,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Subject: [apps-discuss] Fw: draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 18:16:19 -0000

 ---- Original Message -----
 From: "Graham Klyne" 
 To: "Martin J. Dürst" 
 Cc: "Mark Nottingham" ; "IETF Apps Discuss"
 
 Sent: Tuesday, November 22, 2011 12:26 PM

> I spotted this discussion and was reminded that one of the older URI specs had
> some explicit discussion of characters and octets and encoding.  I recall a
line
> that looked something like this:
>
>    URI characters -> URI octets -> URI octets %-encoded to US-ASCII
>
> but I can no longer find it (quickly).  But
http://www.ietf.org/rfc/rfc3986.txt
> sections 1.2 and section 2 (esp. intro) address some of the issues.  The point
> being that character encoding to octets is a separate concern from %-encoding
to
> URI (or IRI) on-the-wire characters.
>

 My bible for this is RFC2130 which gives

 character->coded character set->character encoding scheme->transfer encoding
 syntax

 which Unicode seemed to get spot on, but HTML and URIs ... um

 Tom Petch


>
> #g
> --
>
> On 22/11/2011 09:09, "Martin J. Dürst" wrote:
> > On 2011/11/22 8:43, Mark Nottingham wrote:
> >> The usual approach to this sort of thing is to define the "canonical" way
to
> >> do it; i.e., json pointers *are* unicode strings; then you can define
> >> encodings into various environments (like URIs).
> >>
> >> In this case, it'd probably be good enough to say that json pointers are
> >> unicode strings,
> >
> > Up to here, this makes a ton of sense.
> >
> >> but that when they need to be in ASCII environments (like URIs) they get
> >> UTF-8'ed and then percent-escaped.
> >
> > This would mean that e.g. in a Java program that for some reason is kept in
> > US-ASCII, I'd have to use %-encoding. This doesn't make sense to me at all.
> >
> > So I'd say that json pointers are escaped according to the conventions of
the
> > substrate that carries them when needed (e.g. pure ASCII, or other kinds of
> > encodings that can't handle the whole Unicode range).
> >
> > Then for json pointers as fragment identifiers, I'd mention that where
> necessary
> > (e.g. for URIs), the convention for converting from IRIs to URIs (see RFC
> 3987)
> > applies.
> >
> > By the way, I don't see a need to escape "/" at all in a fragment
identifier.
> > "/" is plain and simply allowed in fragment identifiers. Please see
> > http://tools.ietf.org/html/rfc3986#section-3.5. Of course, it's not
forbidden
> to
> > escape "/", so software that is interpreting a fragment identifier has to
make
> > sure it does the right thing.
> >
> > Regards, Martin.
> >
> >
> >> Cheers,
> >>
> >>
> >> On 22/11/2011, at 8:51 AM, Paul C. Bryan wrote:
> >>
> >>> Okay, so I'll write-up separate sections for JSON string values and URI
> >>> fragment identifiers. Any objections?
> >>>
> >>> Paul
> >>>
> >>> On Tue, 2011-11-22 at 07:55 +1100, Mark Nottingham wrote:
> >>>> +1 to Julian here -- there's no reason why non-ASCII chars need to be
> >>>> percent-encoded when they occur inside a JSON document, only when they're
> in
> >>>> a URI (or similar context).
> >>>>
> >>>> Cheers,
> >>>>
> >>>>
> >>>> On 22/11/2011, at 7:12 AM, Julian Reschke wrote:
> >>>>
> >>>>> On 2011-11-21 21:09, Paul C. Bryan wrote:
> >>>>>> The intent is to allow a JSON Pointer to be expressed as a JSON string
> >>>>>> value as well as a URI fragment identifier. The latter is the most
> >>>>>> significant driver for URI percent-encoding.
> >>>>>> ...
> >>>>>
> >>>>> Well, you could use it as fragment identifier (or otherwise URI
component)
> >>>>> by UTF-8-percent-escaping.
> >>>>>
> >>>>> The question is whether that use case requires them to be all ASCII
every
> >>>>> else, such as in a JSON patch document.
> >>>>>
> >>>>> Best regards, Julian
> >>>>> _______________________________________________
> >>>>> apps-discuss mailing list
> >>>>>
> >>>> apps-discuss@ietf.org
> >>>>
> >>>>>
> >>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>
> >>>>
> >>>> --
> >>>> Mark Nottingham
> >>>> http://www.mnot.net/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> apps-discuss mailing list
> >>> apps-discuss@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>
> >> --
> >> Mark Nottingham http://www.mnot.net/
> >>
> >>
> >>
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>


From James.H.Manger@team.telstra.com  Thu Nov 24 17:58:44 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F317E21F8549 for ; Thu, 24 Nov 2011 17:58:43 -0800 (PST)
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=-2.467, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RELAY_IS_203=0.994]
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 djoFDDEF+1DS for ; Thu, 24 Nov 2011 17:58:43 -0800 (PST)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id ED60E21F8548 for ; Thu, 24 Nov 2011 17:58:41 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.69,568,1315144800"; d="scan'208";a="57769702"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 25 Nov 2011 12:58:39 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6540"; a="43578273"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipccni.tcif.telstra.com.au with ESMTP; 25 Nov 2011 12:58:39 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 25 Nov 2011 12:58:38 +1100
From: "Manger, James H" 
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Martin Thomson 
Date: Fri, 25 Nov 2011 12:58:37 +1100
Thread-Topic: [apps-discuss] JSON Patch
Thread-Index: AcyqeK61EdldVFNhQn2VEHzqx3rt4wAj5tQw
Message-ID: <255B9BB34FB7D647A506DC292726F6E113885C474E@WSMSG3153V.srv.dir.telstra.com>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <255B9BB34FB7D647A506DC292726F6E113884047C4@WSMSG3153V.srv.dir.telstra.com>  <4ECDEEC4.3050007@it.aoyama.ac.jp>
In-Reply-To: <4ECDEEC4.3050007@it.aoyama.ac.jp>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Nov 2011 01:58:44 -0000

Pj4gPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+ICB3cm90ZToNCj4+PiBPbiBlc2Nh
cGluZzogaG93IGFib3V0IHJlcGxhY2luZyBldmVyeSAnLycgaW4gYW4gb2JqZWN0IG1lbWJlcidz
IG5hbWUgd2l0aCB0aGUgVW5pY29kZSBSRVBMQUNFTUVOVCBDSEFSQUNURVIgVStGRkZEIHdoZW4g
Y3JlYXRpbmcgYSBKU09OIHBvaW50ZXIuDQoNCj5PbiAyMDExLzExLzI0IDExOjA4LCBNYXJ0aW4g
VGhvbXNvbiB3cm90ZToNCj4+IEludGVyZXN0aW5nIHRoYXQgeW91IGNob29zZSBVK0ZGRkQgaW4g
dGhlIHNhbWUgd2F5IHRoYXQgYmFja3NsYXNoIHdhcw0KPj4gY2hvc2VuIGFzIGFuIGVzY2FwZSBj
aGFyYWN0ZXIgaW4gdGhlIGZpcnN0IHBsYWNlLiAgSSdtIG5vdCBhIGJpZyBmYW4NCj4+IG9mIHRo
YXQgYXBwcm9hY2guDQoNCk9uIDIwMTEvMTEvMjQsIE1hcnRpbiBKLiBEw7xyc3Qgd3JvdGU6DQo+
IFllcywgcGxlYXNlIGRvbid0LiBUaGUgc2VtYW50aWNzIG9mIFUrRkZGRCBpcyBtb3N0bHkgYSBj
aGFyYWN0ZXIgdGhhdCANCj4gd2Fzbid0IHN1Y2Nlc3NmdWxseSBjb252ZXJ0ZWQgZnJvbSBzb21l
IG90aGVyIGVuY29kaW5nLiBPdmVybG9hZGluZyB0aGF0IA0KPiB3aXRoICJlc2NhcGluZyBhIHNs
YXNoIiBpcyBhIGJhZCBpZGVhLg0KDQpKU09OIHBvaW50ZXIgdGhlb3JldGljYWxseSBuZWVkcyBh
IHByb3BlciBlc2NhcGluZyBtZWNoYW5pc20gc2luY2UgaXQgcmVzZXJ2ZXMgMSBjaGFyIGFzIGEg
ZGVsaW1pdGVyLiBIb3dldmVyLCBjaG9vc2luZyAxIGNoYXIgbm90IHRvIHN1cHBvcnQgYXZvaWRz
IGEgZmFpciBhbW91bnQgb2YgaW5ldml0YWJsZSBjb25mdXNpb24gYW5kIGNvbXBsZXhpdHkuIEkg
Y2hvc2UgVStGRkZEIFJFUExBQ0VNRU5UIENIQVJBQ1RFUi4gSWYgeW91IGRvbuKAmXQgbGlrZSB0
aGF0IGNob2ljZSwgaG93IGFib3V0IFUrMDAxRiBJTkZPTUFUSU9OIFNFUEFSQVRPUiBPTkUuDQoN
Ck5vdCBzdXBwb3J0aW5nIHBvaW50ZXJzIGZvciBuYW1lcyB3aXRoLCBzYXksIGEgVStGRkZEIGNo
YXIgaXMgbm90IGlkZWFsIGJ1dCBoaW5kZXJzIGFsbW9zdCBubyBwcmFjdGljYWwgdXNlcy4NCkVz
Y2FwaW5nICcvJyB3aXRoICdcLycgY291bGQgYmUgd29yc2UuIEl0IHNlZW1zIGNlcnRhaW4gdG8g
Y2F1c2Ugc2lnbmlmaWNhbnQgY29uZnVzaW9uLiBZb3UgY2FuIG5vIGxvbmdlciBzaW1wbHkgc3Bs
aXQgYSBwb2ludGVyIG9uICcvJyBjaGFyYWN0ZXJzLCBidXQgbmVlZCB0byB1c2UsIHNheSwgYSBy
ZWd1bGFyIGV4cHJlc3Npb24gdG8gcGFyc2UgYSBwb2ludGVyLiBBIC8gY2FuIGJlIGxlZ2l0aW1h
dGVseSBlc2NhcGVkIGluIGEgSlNPTiBzdHJpbmcgYXMgIlwvIiwgYW5kIGFwcGFyZW50bHkgb2Z0
ZW4gaXMgW2h0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9xdWVzdGlvbnMvMTU4MDY0Ny9qc29uLXdo
eS1hcmUtZm9yd2FyZC1zbGFzaGVzLWVzY2FwZWRdIHNvIGRldmVsb3BlcnMgd2lsbCByZWFkIGFu
ZCB3cml0ZSAwLCAxLCAyLCBvciAzIGJhY2tzbGFzaGVzIChidXQgb25seSAxICUyRiksIHdoZW4g
dGhleSBhcmUgZGVhbGluZyB3aXRoIGEgbmFtZSB3aXRoIGEgJy8nLCBvciBhICdcJy4gV2lsbCAi
XHgiIGJlIHVuZGVmaW5lZCB3aGVuIHggaXNu4oCZdCBcIG9yIC8/DQogDQpPYmplY3QgbWVtYmVy
IG5hbWU6DQpMb2dpY2FsbHk6ICBCasO4cm4vQ2Fyc3RlbiBhbmQgYmFyDQpJbiBKU09OICA6ICJC
asO4cm4vQ2Fyc3RlbiIgYW5kICJiYXIiDQogICAgICBPciA6ICJCasO4cm5cL0NhcnN0ZW4iIGFu
ZCAiYmFyIg0KDQpKU09OIHBvaW50ZXI6DQpMb2dpY2FsbHk6ICBCasO4cm5cL0NhcnN0ZW4vYmFy
DQpJbiBKU09OICA6ICJCasO4cm5cXC9DYXJzdGVuL2JhciINCiAgICAgIE9yIDogIkJqw7hyblxc
XC9DYXJzdGVuXC9iYXIiDQpJbiBJUkkgICA6ICBCasO4cm4lMkYvQ2Fyc3Rlbi9iYXINCg0KDQot
LQ0KSmFtZXMgTWFuZ2VyDQo=

From cathryn@infc.ulst.ac.uk  Fri Nov 25 02:49:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC8521F8C4E for ; Fri, 25 Nov 2011 02:49:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.238
X-Spam-Level: 
X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361,  BAYES_00=-2.599, 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 60MVAdEwyctm for ; Fri, 25 Nov 2011 02:49:19 -0800 (PST)
Received: from e4.ulster.ac.uk (e4.ulster.ac.uk [194.80.87.111]) by ietfa.amsl.com (Postfix) with ESMTP id 71BFC21F8C17 for ; Fri, 25 Nov 2011 02:49:18 -0800 (PST)
Received: from m0.ulster.ac.uk (m0.ulster.ac.uk [194.80.87.153]) by e4.ulster.ac.uk (UU/BC) with ESMTP id pAPA8pDj012911 for ; Fri, 25 Nov 2011 10:08:51 GMT
Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by m0.ulster.ac.uk (UU/BC) with ESMTP id pAPA8pIH023613 for ; Fri, 25 Nov 2011 10:08:51 GMT (envelope-from cathryn@infc.ulst.ac.uk)
Received: from localhost (localhost.localdomain [127.0.0.1]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id AEC8B3D06B2 for ; Fri, 25 Nov 2011 10:08:51 +0000 (GMT)
X-Virus-Scanned: amavisd-new at martello.infc.ulst.ac.uk
Received: from martello.infc.ulst.ac.uk ([127.0.0.1]) by localhost (martello.infc.ulst.ac.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPCZE12JRDpb for ; Fri, 25 Nov 2011 10:08:51 +0000 (GMT)
Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id 905053D05BC for ; Fri, 25 Nov 2011 10:08:51 +0000 (GMT)
Date: Fri, 25 Nov 2011 10:08:51 +0000 (GMT)
From: "Peoples, Cathryn" 
To: apps-discuss@ietf.org
Message-ID: <1880162421.1691322215731555.JavaMail.root@martello.infc.ulst.ac.uk>
In-Reply-To: <89399976.1221322215007669.JavaMail.root@martello.infc.ulst.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [193.61.166.86]
X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraWebClient - SAF3 (Win)/5.0.18_GA_3011.RHEL5_64)
Subject: [apps-discuss] [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Hawaii, USA
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Nov 2011 10:49:19 -0000

-----------------------------------------------------------------------------------------------------
 Please accept our apologies if you receive multiple copies of this CfP
-----------------------------------------------------------------------------------------------------

IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) 
==================================================================================
16 April 2012
Maui, Hawaii, USA
http://www.manfi.org


CALL FOR PAPERS
---------------
The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM).
It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner.
In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic.

Topics of interest
------------------
Authors are invited to submit papers that fall into or are related to the topic areas listed below:
- Architectural Issues
   * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet
   * Separation of data, control, and management planes
   * Design of architectural building blocks for managing the Future Internet
   * Advances in measurement, management, security, accounting, mobility, and other functions
   * Virtualization of resources and services
   * Dynamic composition of management and operational functionality
   * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet
   * Implications of social network success on the Future Internet architecture
- Design and Implementation Issues
   * Abstractions for programmable network elements
   * Accommodating context-awareness in management
   * Applying  situation awareness to network management
   * Federation between administrative domains and support of all constituencies
   * The role of models, ontologies, and other knowledge abstractions in the Future Internet
   * Uncertainty and probabilistic approaches to management of the Future Internet
   * Approaches for the organization of management data, data analytics and visualization
   * Experience reports from Future Internet experimental facilities set-up and results
- Economic Issues
   * Economic aspects driving the deployment of Future Internet management technology
   * Economic opportunities and challenges for management technology
   * Experience reports from management in test beds

Paper submission
----------------
Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/).

Proceedings
-----------
Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review.

Workshop Co-Chairs
------------------
- Prof. James Won-Ki Hong, POSTECH, Korea
- Prof. Filip De Turck, Ghent University - IBBT, Belgium
- Dr. Yoshiaki Kiriha, NEC, Japan
- Dr. Sven van der Meer, Ericsson LM, Ireland

Publicity Co-Chairs
-------------------
- Leonidas Lymberopoulos, National Technical University of Athens, Greece 
- Cathryn Peoples, University of Ulster, UK 
 
Important dates
---------------
- Abstract registration deadline: December 14, 2011
- Paper submission: December 20, 2011
- Notification of acceptance: January 31, 2012
- Final version of papers due: February 15, 2012
- Workshop date: April 16, 2012

For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org

From julian.reschke@gmx.de  Fri Nov 25 05:05:12 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB66A21F8C11 for ; Fri, 25 Nov 2011 05:05:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.645
X-Spam-Level: 
X-Spam-Status: No, score=-103.645 tagged_above=-999 required=5 tests=[AWL=-1.646, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 JigR8Lxptm9f for ; Fri, 25 Nov 2011 05:05:12 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E482921F8C08 for ; Fri, 25 Nov 2011 05:05:06 -0800 (PST)
Received: (qmail invoked by alias); 25 Nov 2011 13:05:05 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp064) with SMTP; 25 Nov 2011 14:05:05 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19aCKNcFHla2LV0m3Cw4eOihr3QztRsPOXzKRP0+t TcHF2dNPOwA31R
Message-ID: <4ECF927D.4070809@gmx.de>
Date: Fri, 25 Nov 2011 14:05:01 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Manger, James H" 
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <255B9BB34FB7D647A506DC292726F6E113884047C4@WSMSG3153V.srv.dir.telstra.com>  <4ECDEEC4.3050007@it.aoyama.ac.jp> <255B9BB34FB7D647A506DC292726F6E113885C474E@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E113885C474E@WSMSG3153V.srv.dir.telstra.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Nov 2011 13:05:12 -0000

On 2011-11-25 02:58, Manger, James H wrote:
>>>    wrote:
>>>> On escaping: how about replacing every '/' in an object member's name with the Unicode REPLACEMENT CHARACTER U+FFFD when creating a JSON pointer.
>
>> On 2011/11/24 11:08, Martin Thomson wrote:
>>> Interesting that you choose U+FFFD in the same way that backslash was
>>> chosen as an escape character in the first place.  I'm not a big fan
>>> of that approach.
>
> On 2011/11/24, Martin J. Dürst wrote:
>> Yes, please don't. The semantics of U+FFFD is mostly a character that
>> wasn't successfully converted from some other encoding. Overloading that
>> with "escaping a slash" is a bad idea.
>
> JSON pointer theoretically needs a proper escaping mechanism since it reserves 1 char as a delimiter. However, choosing 1 char not to support avoids a fair amount of inevitable confusion and complexity. I chose U+FFFD REPLACEMENT CHARACTER. If you don’t like that choice, how about U+001F INFOMATION SEPARATOR ONE.

I like that; it avoids adding a whole new escaping sequence, and I think 
it's ok to sacrifice compatibility with identifiers that contain control 
characters.

> Not supporting pointers for names with, say, a U+FFFD char is not ideal but hinders almost no practical uses.
> Escaping '/' with '\/' could be worse. It seems certain to cause significant confusion. You can no longer simply split a pointer on '/' characters, but need to use, say, a regular expression to parse a pointer. A / can be legitimately escaped in a JSON string as "\/", and apparently often is [http://stackoverflow.com/questions/1580647/json-why-are-forward-slashes-escaped] so developers will read and write 0, 1, 2, or 3 backslashes (but only 1 %2F), when they are dealing with a name with a '/', or a '\'. Will "\x" be undefined when x isn’t \ or /?
>
> Object member name:
> Logically:  Bjørn/Carsten and bar
> In JSON  : "Bjørn/Carsten" and "bar"
>        Or : "Bjørn\/Carsten" and "bar"
>
> JSON pointer:
> Logically:  Bjørn\/Carsten/bar
> In JSON  : "Bjørn\\/Carsten/bar"
>        Or : "Bjørn\\\/Carsten\/bar"
> In IRI   :  Bjørn%2F/Carsten/bar
> ...

Not sure I get the example.

So, the member name is

   Bjørn/Carsten and bar

in JSON, that's

   "Bjørn/Carsten and bar"

no?

In JSON pointer with 0x1f-substution we get (serialized as JSON):

   "/Bjørn\u001fCarsten and bar"

In an IRI, we'd have:

   /Bjørn%1FCarsten%20and%20bar

and, in a URI:

   /Bj%C3%B8rn%1FCarsten%20and%20bar

Best regards, Julian

From sm@resistor.net  Fri Nov 25 07:18:45 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62EE21F8B27 for ; Fri, 25 Nov 2011 07:18:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level: 
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 4lHjlMkoo7Vj for ; Fri, 25 Nov 2011 07:18:45 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AA421F8593 for ; Fri, 25 Nov 2011 07:18:45 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pAPFIZKh018640; Fri, 25 Nov 2011 07:18:39 -0800 (PST)
Message-Id: <6.2.5.6.2.20111125064850.096de158@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 25 Nov 2011 07:18:12 -0800
To: "Peoples, Cathryn" 
From: SM 
In-Reply-To: <1880162421.1691322215731555.JavaMail.root@martello.infc.ul st.ac.uk>
References: <89399976.1221322215007669.JavaMail.root@martello.infc.ulst.ac.uk> <1880162421.1691322215731555.JavaMail.root@martello.infc.ulst.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: tpcchairs@manfi2012.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 -  Hawaii, USA
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Nov 2011 15:18:45 -0000

At 02:08 25-11-2011, Peoples, Cathryn wrote:
>  Please accept our apologies if you receive multiple copies of this CfP

Your message has been posted to several IETF mailing lists.  As it is 
unrelated to any IETF activity, it may be considered as spam.

Regards,
-sm 


From msk@cloudmark.com  Fri Nov 25 22:13:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E4621F84B3; Fri, 25 Nov 2011 22:13:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.813
X-Spam-Level: 
X-Spam-Status: No, score=-102.813 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 L-E3jsoGL7Oz; Fri, 25 Nov 2011 22:13:08 -0800 (PST)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 811A921F848E; Fri, 25 Nov 2011 22:13:08 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 25 Nov 2011 22:13:07 -0800
From: "Murray S. Kucherawy" 
To: "Peoples, Cathryn" , "apps-discuss@ietf.org" , "ietf@ietf.org" 
Date: Fri, 25 Nov 2011 22:13:08 -0800
Thread-Topic: IEEE spam (was [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Hawaii, USA)
Thread-Index: AcyrX/vnbwJIVhe6Sv23OxjLf1XgkgAobdvA
Message-ID: 
References: <89399976.1221322215007669.JavaMail.root@martello.infc.ulst.ac.uk> <1880162421.1691322215731555.JavaMail.root@martello.infc.ulst.ac.uk>
In-Reply-To: <1880162421.1691322215731555.JavaMail.root@martello.infc.ulst.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [apps-discuss] IEEE spam (was [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Hawaii, USA)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Nov 2011 06:13:09 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Peoples, Cathryn
> Sent: Friday, November 25, 2011 2:09 AM
> To: apps-discuss@ietf.org
> Subject: [apps-discuss] [CfP] IEEE/IFIP International Workshop on
> Management of the Future Internet (ManFI 2012) - April 16, 2012 -
> Hawaii, USA
>=20
> -----------------------------------------------------------------------
> ------------------------------
>  Please accept our apologies if you receive multiple copies of this CfP
> -----------------------------------------------------------------------
> ------------------------------
>=20
> IEEE/IFIP International Workshop on Management of the Future Internet
> (ManFI 2012)

As this was blasted to a lot of IETF lists (three that I watch, at least), =
I suspect this might have been better handled, i.e., in a less irritating m=
anner, by using the IEEE-IETF Liaison position.  Such a role does exist, as=
 shown at http://www.ietf.org/liaison/managers.html.  That person could hav=
e posted the CfP in a single conspicuous place within the IETF on behalf of=
 IEEE.

In any case, a single posting to ietf@ietf.org would have been more than su=
fficient.

I note that on at least one list I watch, the IEEE poster has been blocked =
from further postings as a result.



From msk@cloudmark.com  Sat Nov 26 01:03:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CEE21F8AE9; Sat, 26 Nov 2011 01:03:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.431
X-Spam-Level: 
X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, MISSING_SUBJECT=1.762, 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 OUCFleMGWzq4; Sat, 26 Nov 2011 01:03:09 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id D3B0721F8ABB; Sat, 26 Nov 2011 01:03:09 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 26 Nov 2011 01:03:09 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" , "draft-ietf-v6ops-happy-eyeballs.all@tools.ietf.org" 
Date: Sat, 26 Nov 2011 01:03:10 -0800
Thread-Index: AcysGjhKwoFtniEmQ3y9gC5warTOdg==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IESG 
Subject: [apps-discuss] (no subject)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Nov 2011 09:03:10 -0000

I have been selected as the Applications Area Review Team reviewer for this=
 draft (for background on apps-review, please see http://www.apps.ietf.org/=
content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you m=
ay receive.  Please wait for direction from your document shepherd or AD be=
fore posting a new version of the draft.

Document: draft-ietf-v6ops-happy-eyeballs
Title: Happy Eyeballs: Success with Dual-Stack Hosts
Reviewer: Murray S. Kucherawy
Review Date: November 25-26, 2011
IETF Last Call Date: completed November 10, 2011
IESG Telechat Date: December 1, 2011

Overview: This document provides a basic framework for algorithms to improv=
e user experience when, in a dual-stack environment, the IPv6 version of a =
service becomes unavailable.

Summary: This draft is almost ready for publication as an RFC but has a few=
 issues that should be fixed before publication.

Major Issues:
1) As Wesley Eddy has already noted in a DISCUSS, this document's scope is =
limited to applications that use TCP for communication.  It should either d=
isclaim this up-front, or should spend some time talking about stateless tr=
ansport, even if the algorithms are the same (and if they're not, spend som=
e time talking about how they're different).

2) Certainly the IESG is the arbiter of such choices, but I'm not seeing wh=
y this document is appropriate for the Standards Track.  It doesn't introdu=
ce anything new that creates new interoperability concerns; everything it d=
escribes is local to the machine seeking to make a connection to a service.=
  It could certainly be the case that my understanding of what's appropriat=
e on the various tracks simply needs adjustment.  :-)

Minor Issues:
1) Section 4.2 talks about "Such an implementation MUST occasionally make c=
onnection attempts using the host's preferred address family..."  Is that d=
uring an existing session, or when establishing new ones?  I can't tell her=
e if the goal is to change to the preferred address family within a session=
 (if it is detected that such is now possible) or on the next connection at=
tempt.

2) It is unclear from a general reading of this where the Happy Eyeballs al=
gorithm is meant to be implemented.  It seems that this could be a layer of=
 application-level logic, and that is probably the intent, but a piece of n=
etworking equipment that implements some of these algorithms could declare =
a connection failed right away if it has observed a history of that family,=
 prefix, or address failing in the recent past.  Thus, the state of Happy E=
yeballs is maintained in the hardware rather than in a new application laye=
r.  Or there might be a co-operation between the two.  (You later allude to=
 this in Section 5.9, specifically talking about OS implementations, which =
is one of a couple of possible placements.  Maybe Section 5.9 could talk ab=
out putting this stuff in hardware too.)

3) Section 5.1 claims there is minimal impact ("small detriment") of Happy =
Eyeballs implementation.  Has this actually been measured, especially at sc=
ale?  If so, a reference to or a description of that work (perhaps in an ap=
pendix) would be nice.  If not, this strikes me as speculative, and it shou=
ld probably say so.

4) Section 5.3 might also suggest (via MAY/OPTIONAL) that, for troubleshoot=
ing and debugging purposes, a Happy Eyeballs implementation make available =
its cache of what connections are working and which are being "de-preferred=
" because of detected connection difficulties.

5) The recommendations of Section 5.7 seem (admittedly having read none of =
the history of this document) somewhat arbitrary.  The last sentence rescue=
s it somewhat, but I wonder in what context 150-250ms makes sense.

6) Section 5.8 makes a direct reference to work in the WEBSEC working group=
, correctly acknowledging the concerns of their Same Origin work.  Has anyo=
ne from that working group (perhaps the authors of the referenced draft) re=
viewed this one?

7) In Section 6, some discussion or even an sample implementation of the ca=
ching of results described in Section 4.2 would help to complete the illust=
ration.

8) I anticipate SecDir will request a better treatment of Section 7 (Securi=
ty Considerations) than this draft currently includes.  At a minimum, I sug=
gest moving the security-specific details to Section 7 and making forward r=
eferences to them.

Nits:
1) In the last sentence of Section 5.1, "server" should be "servers".

2) In Section 5.5, "an DNS" should be "a DNS".

3) Is Section 5.6 necessary?  If A6 records were already busted to Experime=
ntal, it seems like this gives them needless attention.  To that end, perha=
ps this document (or a different one from v6ops) should declare A6 Historic=
.


From msk@cloudmark.com  Sat Nov 26 01:06:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBB121F8C4E; Sat, 26 Nov 2011 01:06:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.308
X-Spam-Level: 
X-Spam-Status: No, score=-103.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 g93zqQzuD+Fq; Sat, 26 Nov 2011 01:06:25 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id B01A121F8C49; Sat, 26 Nov 2011 01:06:25 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 26 Nov 2011 01:06:25 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" , "draft-ietf-v6ops-happy-eyeballs.all@tools.ietf.org" 
Date: Sat, 26 Nov 2011 01:06:25 -0800
Thread-Topic: APPS Area review: draft-ietf-v6ops-happy-eyeballs
Thread-Index: AcysGq0P7yyINz+YSNW7aruikiQ7Ug==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15242EXCHC2corpclo_"
MIME-Version: 1.0
Cc: IESG 
Subject: [apps-discuss] APPS Area review: draft-ietf-v6ops-happy-eyeballs
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Nov 2011 09:06:26 -0000

--_000_F5833273385BB34F99288B3648C4F06F19C6C15242EXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[re-sending with an actual Subject: field to allow a meaningful thread to d=
evelop]



I have been selected as the Applications Area Review Team reviewer for this=
 draft (for background on apps-review, please see http://www.apps.ietf.org/=
content/applications-area-review-team).



Please resolve these comments along with any other Last Call comments you m=
ay receive.  Please wait for direction from your document shepherd or AD be=
fore posting a new version of the draft.



Document: draft-ietf-v6ops-happy-eyeballs

Title: Happy Eyeballs: Success with Dual-Stack Hosts

Reviewer: Murray S. Kucherawy

Review Date: November 25-26, 2011

IETF Last Call Date: completed November 10, 2011 IESG Telechat Date: Decemb=
er 1, 2011



Overview: This document provides a basic framework for algorithms to improv=
e user experience when, in a dual-stack environment, the IPv6 version of a =
service becomes unavailable.



Summary: This draft is almost ready for publication as an RFC but has a few=
 issues that should be fixed before publication.



Major Issues:

1) As Wesley Eddy has already noted in a DISCUSS, this document's scope is =
limited to applications that use TCP for communication.  It should either d=
isclaim this up-front, or should spend some time talking about stateless tr=
ansport, even if the algorithms are the same (and if they're not, spend som=
e time talking about how they're different).



2) Certainly the IESG is the arbiter of such choices, but I'm not seeing wh=
y this document is appropriate for the Standards Track.  It doesn't introdu=
ce anything new that creates new interoperability concerns; everything it d=
escribes is local to the machine seeking to make a connection to a service.=
  It could certainly be the case that my understanding of what's appropriat=
e on the various tracks simply needs adjustment.  :-)



Minor Issues:

1) Section 4.2 talks about "Such an implementation MUST occasionally make c=
onnection attempts using the host's preferred address family..."  Is that d=
uring an existing session, or when establishing new ones?  I can't tell her=
e if the goal is to change to the preferred address family within a session=
 (if it is detected that such is now possible) or on the next connection at=
tempt.



2) It is unclear from a general reading of this where the Happy Eyeballs al=
gorithm is meant to be implemented.  It seems that this could be a layer of=
 application-level logic, and that is probably the intent, but a piece of n=
etworking equipment that implements some of these algorithms could declare =
a connection failed right away if it has observed a history of that family,=
 prefix, or address failing in the recent past.  Thus, the state of Happy E=
yeballs is maintained in the hardware rather than in a new application laye=
r.  Or there might be a co-operation between the two.  (You later allude to=
 this in Section 5.9, specifically talking about OS implementations, which =
is one of a couple of possible placements.  Maybe Section 5.9 could talk ab=
out putting this stuff in hardware too.)



3) Section 5.1 claims there is minimal impact ("small detriment") of Happy =
Eyeballs implementation.  Has this actually been measured, especially at sc=
ale?  If so, a reference to or a description of that work (perhaps in an ap=
pendix) would be nice.  If not, this strikes me as speculative, and it shou=
ld probably say so.



4) Section 5.3 might also suggest (via MAY/OPTIONAL) that, for troubleshoot=
ing and debugging purposes, a Happy Eyeballs implementation make available =
its cache of what connections are working and which are being "de-preferred=
" because of detected connection difficulties.



5) The recommendations of Section 5.7 seem (admittedly having read none of =
the history of this document) somewhat arbitrary.  The last sentence rescue=
s it somewhat, but I wonder in what context 150-250ms makes sense.



6) Section 5.8 makes a direct reference to work in the WEBSEC working group=
, correctly acknowledging the concerns of their Same Origin work.  Has anyo=
ne from that working group (perhaps the authors of the referenced draft) re=
viewed this one?



7) In Section 6, some discussion or even an sample implementation of the ca=
ching of results described in Section 4.2 would help to complete the illust=
ration.



8) I anticipate SecDir will request a better treatment of Section 7 (Securi=
ty Considerations) than this draft currently includes.  At a minimum, I sug=
gest moving the security-specific details to Section 7 and making forward r=
eferences to them.



Nits:

1) In the last sentence of Section 5.1, "server" should be "servers".



2) In Section 5.5, "an DNS" should be "a DNS".



3) Is Section 5.6 necessary?  If A6 records were already busted to Experime=
ntal, it seems like this gives them needless attention.  To that end, perha=
ps this document (or a different one from v6ops) should declare A6 Historic=
.


--_000_F5833273385BB34F99288B3648C4F06F19C6C15242EXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


[re-sending w=
ith an actual Subject: field to allow a meaningful thread to develop]<=
/o:p>
 
I have been selected as the Applications Area Review Team reviewer for t=
his draft (for background on apps-review, please see http://www.apps.ietf.o=
rg/content/applications-area-review-team).
 
Please resolve these=
 comments along with any other Last Call comments you may receive.  Pl=
ease wait for direction from your document shepherd or AD before posting a =
new version of the draft.
 =

Document: draft-ietf-v6ops-happy-eyeballs=

Title: Happy Eyeballs: Success with =
Dual-Stack Hosts
Reviewer: Murray S. =
Kucherawy
Review Date: November 25-26=
, 2011
IETF Last Call Date: completed=
 November 10, 2011 IESG Telechat Date: December 1, 2011
 
Overview: T=
his document provides a basic framework for algorithms to improve user expe=
rience when, in a dual-stack environment, the IPv6 version of a service bec=
omes unavailable.
 
Summary: This draft is almost ready for publicati=
on as an RFC but has a few issues that should be fixed before publication.<=
o:p>
 
Major Issues:
1) As Wesley Ed=
dy has already noted in a DISCUSS, this document's scope is limited to appl=
ications that use TCP for communication.  It should either disclaim th=
is up-front, or should spend some time talking about stateless transport, e=
ven if the algorithms are the same (and if they're not, spend some time tal=
king about how they're different).
 
2) Certainly the IESG is the arb=
iter of such choices, but I'm not seeing why this document is appropriate f=
or the Standards Track.  It doesn't introduce anything new that create=
s new interoperability concerns; everything it describes is local to the ma=
chine seeking to make a connection to a service.  It could certainly b=
e the case that my understanding of what's appropriate on the various track=
s simply needs adjustment.  :-)
=
 
Minor Issues:
1) Section 4.2 talks about "Such an implementati=
on MUST occasionally make connection attempts using the host's preferred ad=
dress family..."  Is that during an existing session, or when est=
ablishing new ones?  I can't tell here if the goal is to change to the=
 preferred address family within a session (if it is detected that such is =
now possible) or on the next connection attempt.
 
2) It is unclear f=
rom a general reading of this where the Happy Eyeballs algorithm is meant t=
o be implemented.  It seems that this could be a layer of application-=
level logic, and that is probably the intent, but a piece of networking equ=
ipment that implements some of these algorithms could declare a connection =
failed right away if it has observed a history of that family, prefix, or a=
ddress failing in the recent past.  Thus, the state of Happy Eyeballs =
is maintained in the hardware rather than in a new application layer. =
 Or there might be a co-operation between the two.  (You later allude =
to this in Section 5.9, specifically talking about OS implementations, whic=
h is one of a couple of possible placements.  Maybe Section 5.9 could =
talk about putting this stuff in hardware too.)
 
3) Section 5.1 clai=
ms there is minimal impact ("small detriment") of Happy Eyeballs =
implementation.  Has this actually been measured, especially at scale?=
  If so, a reference to or a description of that work (perhaps in an a=
ppendix) would be nice.  If not, this strikes me as speculative, and i=
t should probably say so.
 =

4) Section 5.3 might also suggest (via MA=
Y/OPTIONAL) that, for troubleshooting and debugging purposes, a Happy Eyeba=
lls implementation make available its cache of what connections are working=
 and which are being "de-preferred" because of detected connectio=
n difficulties.
 
=

5) The recommendations of Section 5.7 seem (admitte=
dly having read none of the history of this document) somewhat arbitrary.&n=
bsp; The last sentence rescues it somewhat, but I wonder in what context 15=
0-250ms makes sense.
 
6) Section 5.8 makes a direct reference to wor=
k in the WEBSEC working group, correctly acknowledging the concerns of thei=
r Same Origin work.  Has anyone from that working group (perhaps the a=
uthors of the referenced draft) reviewed this one?
 
7) In Section =
6, some discussion or even an sample implementation of the caching of resul=
ts described in Section 4.2 would help to complete the illustration.
 
8) I anticipate SecDir will request a better treatment of Section 7 (Secu=
rity Considerations) than this draft currently includes.  At a minimum=
, I suggest moving the security-specific details to Section 7 and making fo=
rward references to them.
 =

Nits:
1) In the last sentence of Section 5.1, "server" should be &qu=
ot;servers".
 
2) In Section 5.5, "an DNS" should be &=
quot;a DNS".
 
3) Is Section 5.6 necessary?  If A6 records =
were already busted to Experimental, it seems like this gives them needless=
 attention.  To that end, perhaps this document (or a different one fr=
om v6ops) should declare A6 Historic.
 
=

--_000_F5833273385BB34F99288B3648C4F06F19C6C15242EXCHC2corpclo_--

From stpeter@stpeter.im  Sat Nov 26 10:28:47 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D34721F8B65; Sat, 26 Nov 2011 10:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSK0QQISSuDK; Sat, 26 Nov 2011 10:28:46 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A631C21F8A56; Sat, 26 Nov 2011 10:28:46 -0800 (PST)
Received: from squire.local (unknown [216.17.140.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4A4F9421BB; Sat, 26 Nov 2011 11:35:27 -0700 (MST)
Message-ID: <4ED12FD8.9080003@stpeter.im>
Date: Sat, 26 Nov 2011 11:28:40 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" ,  IETF Security Area Advisory Group , jose@ietf.org, IETF WebSec WG 
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] W3C Web Cryptography Working Group Charter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Nov 2011 18:28:47 -0000

Of interest to apps and security folks at the IETF...

http://www.w3.org/2011/11/webcryptography-charter.html

Provide comments on the public-identity@w3.org list (subscribe by
emailing public-identity-request@w3.org with subject "subscribe").

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From derhoermi@gmx.net  Sat Nov 26 11:00:57 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D6321F8BCB for ; Sat, 26 Nov 2011 11:00:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level: 
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112,  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 Cl11ZhlzM69P for ; Sat, 26 Nov 2011 11:00:55 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8BCA721F8BB3 for ; Sat, 26 Nov 2011 11:00:54 -0800 (PST)
Received: (qmail invoked by alias); 26 Nov 2011 19:00:52 -0000
Received: from dslb-094-223-192-167.pools.arcor-ip.net (EHLO HIVE) [94.223.192.167] by mail.gmx.net (mp051) with SMTP; 26 Nov 2011 20:00:52 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19xFdEUk8FxEdaIsJ1LvqRcRsetv6EtN3ii5vpZB2 X8ws5FzaaQeGdA
From: Bjoern Hoehrmann 
To: Peter Saint-Andre 
Date: Sat, 26 Nov 2011 20:00:55 +0100
Message-ID: 
References: <4ED12FD8.9080003@stpeter.im>
In-Reply-To: <4ED12FD8.9080003@stpeter.im>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: IETF WebSec WG , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] W3C Web Cryptography Working Group Charter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Nov 2011 19:00:57 -0000

* Peter Saint-Andre wrote:
>Of interest to apps and security folks at the IETF...
>
>http://www.w3.org/2011/11/webcryptography-charter.html

Test suite is optional, I note in passing.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From James.H.Manger@team.telstra.com  Sun Nov 27 14:50:29 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F9A21F8C3A for ; Sun, 27 Nov 2011 14:50:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.428
X-Spam-Level: 
X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-2.127, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_14=0.6, RELAY_IS_203=0.994]
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 V5Sw8c-OkK2U for ; Sun, 27 Nov 2011 14:50:28 -0800 (PST)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE6A21F8C39 for ; Sun, 27 Nov 2011 14:50:28 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.69,579,1315144800"; d="scan'208";a="55469919"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 28 Nov 2011 09:50:25 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6543"; a="43536354"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbvi.tcif.telstra.com.au with ESMTP; 28 Nov 2011 09:50:25 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 28 Nov 2011 09:50:25 +1100
From: "Manger, James H" 
To: Julian Reschke 
Date: Mon, 28 Nov 2011 09:50:25 +1100
Thread-Topic: [apps-discuss] JSON Patch
Thread-Index: Acyrct3D1DZ3usldS5mC8VX3ZowDygB4J88w
Message-ID: <255B9BB34FB7D647A506DC292726F6E11389A699D1@WSMSG3153V.srv.dir.telstra.com>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <255B9BB34FB7D647A506DC292726F6E113884047C4@WSMSG3153V.srv.dir.telstra.com>  <4ECDEEC4.3050007@it.aoyama.ac.jp> <255B9BB34FB7D647A506DC292726F6E113885C474E@WSMSG3153V.srv.dir.telstra.com> <4ECF927D.4070809@gmx.de>
In-Reply-To: <4ECF927D.4070809@gmx.de>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] JSON Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Nov 2011 22:50:29 -0000

Pj4gSlNPTiBwb2ludGVyIHRoZW9yZXRpY2FsbHkgbmVlZHMgYSBwcm9wZXIgZXNjYXBpbmcgbWVj
aGFuaXNtIHNpbmNlIGl0IHJlc2VydmVzIDEgY2hhciBhcyBhIGRlbGltaXRlci4gSG93ZXZlciwg
Y2hvb3NpbmcgMSBjaGFyIG5vdCB0byBzdXBwb3J0IGF2b2lkcyBhIGZhaXIgYW1vdW50IG9mIGlu
ZXZpdGFibGUgY29uZnVzaW9uIGFuZCBjb21wbGV4aXR5LiBJIGNob3NlIFUrRkZGRCBSRVBMQUNF
TUVOVCBDSEFSQUNURVIuIElmIHlvdSBkb27igJl0IGxpa2UgdGhhdCBjaG9pY2UsIGhvdyBhYm91
dCBVKzAwMUYgSU5GT01BVElPTiBTRVBBUkFUT1IgT05FLg0KDQo+IEkgbGlrZSB0aGF0OyBpdCBh
dm9pZHMgYWRkaW5nIGEgd2hvbGUgbmV3IGVzY2FwaW5nIHNlcXVlbmNlLCBhbmQgSSB0aGluayBp
dCdzIG9rIHRvIHNhY3JpZmljZSBjb21wYXRpYmlsaXR5IHdpdGggaWRlbnRpZmllcnMgdGhhdCBj
b250YWluIGNvbnRyb2wgY2hhcmFjdGVycy4NCg0KPj4gTm90IHN1cHBvcnRpbmcgcG9pbnRlcnMg
Zm9yIG5hbWVzIHdpdGgsIHNheSwgYSBVK0ZGRkQgY2hhciBpcyBub3QgaWRlYWwgYnV0IGhpbmRl
cnMgYWxtb3N0IG5vIHByYWN0aWNhbCB1c2VzLg0KPj4gRXNjYXBpbmcgJy8nIHdpdGggJ1wvJyBj
b3VsZCBiZSB3b3JzZS4gSXQgc2VlbXMgY2VydGFpbiB0byBjYXVzZSBzaWduaWZpY2FudCBjb25m
dXNpb24uIFlvdSBjYW4gbm8gbG9uZ2VyIHNpbXBseSBzcGxpdCBhIHBvaW50ZXIgb24gJy8nIGNo
YXJhY3RlcnMsIGJ1dCBuZWVkIHRvIHVzZSwgc2F5LCBhIHJlZ3VsYXIgZXhwcmVzc2lvbiB0byBw
YXJzZSBhIHBvaW50ZXIuIEEgLyBjYW4gYmUgbGVnaXRpbWF0ZWx5IGVzY2FwZWQgaW4gYSBKU09O
IHN0cmluZyBhcyAiXC8iLCBhbmQgYXBwYXJlbnRseSBvZnRlbiBpcyBbaHR0cDovL3N0YWNrb3Zl
cmZsb3cuY29tL3F1ZXN0aW9ucy8xNTgwNjQ3L2pzb24td2h5LWFyZS1mb3J3YXJkLXNsYXNoZXMt
ZXNjYXBlZF0gc28gZGV2ZWxvcGVycyB3aWxsIHJlYWQgYW5kIHdyaXRlIDAsIDEsIDIsIG9yIDMg
YmFja3NsYXNoZXMgKGJ1dCBvbmx5IDEgJTJGKSwgd2hlbiB0aGV5IGFyZSBkZWFsaW5nIHdpdGgg
YSBuYW1lIHdpdGggYSAnLycsIG9yIGEgJ1wnLiBXaWxsICJceCIgYmUgdW5kZWZpbmVkIHdoZW4g
eCBpc27igJl0IFwgb3IgLz8NCj4+DQo+PiBPYmplY3QgbWVtYmVyIG5hbWU6DQo+PiBMb2dpY2Fs
bHk6ICBCasO4cm4vQ2Fyc3RlbiBhbmQgYmFyDQo+PiBJbiBKU09OICA6ICJCasO4cm4vQ2Fyc3Rl
biIgYW5kICJiYXIiDQo+PiAgICAgICBPciA6ICJCasO4cm5cL0NhcnN0ZW4iIGFuZCAiYmFyIg0K
Pj4NCj4+IEpTT04gcG9pbnRlcjoNCj4+IExvZ2ljYWxseTogIEJqw7hyblwvQ2Fyc3Rlbi9iYXIN
Cj4+IEluIEpTT04gIDogIkJqw7hyblxcL0NhcnN0ZW4vYmFyIg0KPj4gICAgICAgT3IgOiAiQmrD
uHJuXFxcL0NhcnN0ZW5cL2JhciINCj4+IEluIElSSSAgIDogIEJqw7hybiUyRi9DYXJzdGVuL2Jh
cg0KPj4gLi4uDQoNCj4gTm90IHN1cmUgSSBnZXQgdGhlIGV4YW1wbGUuDQoNCg0KU29ycnkgZm9y
IHRoZSBjb25mdXNpbmcgZXhhbXBsZSwgSnVsaWFuLg0KSSBtZWFudCB0byBzaG93IGEgSlNPTiBw
b2ludGVyIHdpdGggMiByZWZlcmVuY2VzLg0KRWcgYSBwb2ludGVyIHRvIHRoZSB2YWx1ZSAzIGlu
IHRoaXMgSlNPTiBleGFtcGxlOg0KeyJCasO4cm4vQ2Fyc3RlbiI6eyJiYXIiOjN9fQ0KSSBkaWRu
J3QgZ2V0IGl0IHF1aXRlIHJpZ2h0IGFzIEkgb21pdHRlZCB0aGUgbGVhZGluZyAiLyIgdGhhdCBh
bGwgcG9pbnRlcnMgc3RhcnQgd2l0aC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K

From duerst@it.aoyama.ac.jp  Mon Nov 28 03:23:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBD321F8C95 for ; Mon, 28 Nov 2011 03:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.89
X-Spam-Level: 
X-Spam-Status: No, score=-96.89 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 YkkPXtCJWOYu for ; Mon, 28 Nov 2011 03:23:15 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 320C121F8C5E for ; Mon, 28 Nov 2011 03:23:14 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pASBMwYE019336 for ; Mon, 28 Nov 2011 20:23:01 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 06ab_3794_53243f12_19b3_11e1_b92c_001d096c566a; Mon, 28 Nov 2011 20:22:58 +0900
Received: from [IPv6:::1] ([133.2.210.1]:43977) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 28 Nov 2011 20:22:59 +0900
Message-ID: <4ED36F0D.7070009@it.aoyama.ac.jp>
Date: Mon, 28 Nov 2011 20:22:53 +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: "t.petch" 
References: <092801ccaacc$ada7b000$4001a8c0@gateway.2wire.net>
In-Reply-To: <092801ccaacc$ada7b000$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss 
Subject: Re: [apps-discuss] Fw: draft-pbryan-zyp-json-pointer: name syntax for	non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2011 11:23:16 -0000

On 2011/11/25 2:15, t.petch wrote:
>   ---- Original Message -----
>   From: "Graham Klyne"

>> I spotted this discussion and was reminded that one of the older URI specs had
>> some explicit discussion of characters and octets and encoding.  I recall a
> line
>> that looked something like this:
>>
>>     URI characters ->  URI octets ->  URI octets %-encoded to US-ASCII
>>
>> but I can no longer find it (quickly).  But
> http://www.ietf.org/rfc/rfc3986.txt
>> sections 1.2 and section 2 (esp. intro) address some of the issues.  The point
>> being that character encoding to octets is a separate concern from %-encoding
> to
>> URI (or IRI) on-the-wire characters.
 >
>   My bible for this is RFC2130 which gives
>
>   character->coded character set->character encoding scheme->transfer encoding
>   syntax
>
>   which Unicode seemed to get spot on,

Of course, because Unicode is a character encoding.

> but HTML and URIs ... um

They are not character encodings, but work on a higher level. HTML 
pretty well conforms to http://www.w3.org/TR/charmod/#sec-RefProcModel, 
the Reference Processing Model of the Character Model for the World Wide 
Web. See also RFC 2070.

For URIs, the situation is indeed murky, because escaping (%-encoding) 
is on the octet level, rather than on the character level, and depending 
on the component, the character->octet mapping is undefined. But for new 
stuff, such as the syntax discussed in this thread, the character->octet 
mapping just has to be fixed to UTF-8, which brings that part of an URI 
mostly in line with the above model.

Regards,    Martin.

From evnikita2@gmail.com  Mon Nov 28 07:16:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2283521F8CEE for ; Mon, 28 Nov 2011 07:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_55=0.6, 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 5pTS-HWbALc6 for ; Mon, 28 Nov 2011 07:16:53 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3E9221F85FF for ; Mon, 28 Nov 2011 07:16:52 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so9405753bkb.31 for ; Mon, 28 Nov 2011 07:16:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C6HqBKkGVYQlmzmrObDUFsFif0dpBOoerpy5qGg5bIM=; b=s32f0ljf8lsqwUP3O8uPEbhahNkpuGMfDnaz5Vqx2XTRZCZWv0EdlmkIZDkkgY6jAx qSpVZhNRjkGbOzEUMOubANITW2/fJlpYgnVTj1k04s3GR8+iYsBAedOHjG/RKy+Zu2aC H45aw/RT7MWYvuH+kANRQ+XMamQTSoJafzEn8=
Received: by 10.205.130.1 with SMTP id hk1mr45390742bkc.68.1322493411713; Mon, 28 Nov 2011 07:16:51 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id hy13sm30263531bkc.0.2011.11.28.07.16.48 (version=SSLv3 cipher=OTHER); Mon, 28 Nov 2011 07:16:49 -0800 (PST)
Message-ID: <4ED3A616.5030600@gmail.com>
Date: Mon, 28 Nov 2011 17:17:42 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Barry Leiba 
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com> <4EC40EC3.9080304@gmail.com> <4EC8B870.7070105@isode.com> <4ECA3A2C.1010606@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2011 15:16:54 -0000

23.11.2011 5:07, Barry Leiba wrote:
>>>>>    The 'about' URI MUST syntactically conform to the  rule
>>>>>    below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]:
>>>>>
>>>>>      about-uri   = "about:" about-token [ about-query ]
>>>>>      about-token = segment
>>>>>      about-query = "?" query
>>>>>      segment     =
>>>>>      query       =
>>>>>
>>>>>    In terms of RFC 3986,  part corresponds to,
>>>>>    and  to the query component of URI.
>>>>>
>>>>> s/query/  ? (I didn't check RFC 3986)
>>>> 2.1. URI Scheme Syntax
>>>>
>>>>   doesn't include "?" - so query component.
>>> You misunderstood. You have "about-token" enclosed in<>, I think you need
>>> <>  around "query" as well.
>> The RFC 3986  production does not include "?" delimiter but only the
>> range of chars allowed in the query component while  stands for
>> query itself and the delimiter.  That would be technically inaccurate if I
>> mentioned.
> You still misunderstand what Alexey was getting at, so let me try to
> explain (I misunderstood the first time as well, but I understand his
> second explanation):  He's NOT talking about the ABNF.  He's talking
> about this sentence after it:
>
>>    In terms of RFC 3986,  part corresponds to,
>>    and  to the query component of URI.
> He notes that you have put "" in angle-brackets,
> "" in angle-brackets, and"" in
> angle-brackets, but you have not done so with "query".  He suggests
> that you should say, "to the  component of URI."

And this wouldn't be right, as we have separate terms:  ABNF 
production and query component of URI.  I mean the latter here.

>
> I think a better way to approach it would be to replace all the
> angle-brackets with quotes, so:
>
> NEW
>     In terms of RFC 3986, the "about-token" part corresponds to "hier-part",
>     and "about-query" to the query component of the URI.

I'm following the recommendation of RFC 5234:

>     Unlike original BNF, angle brackets ("<",">") are not required.
>     However, angle brackets may be used around a rule name whenever their
>     presence facilitates in discerning the use of a rule name.

... so I think no change is needed.

>
> (And I do not think that "query" needs to be in quotes here.)
>
>>>> Yes, redirection needs clarification.  That is not HTTP sense here - I
>>>> meant they can be replaced by some other URIs and than resolved to what
>>>> these URIs refer to, and the latter of them needn't necessarily be 'http'
>>>> URIs.
>>> I don't know of any better reference than RFC 2616. Conceptually one URI
>>> is replaced with another, so even if a non HTTP URI is used, this should
>>> work.
>> I've added the following text:
>>
>>>    and MAY redirect such URIs, i.e. resolve it to a resource commonly
>>>    referred to by an other URI.
> I had suggested text for this in my other note; what do you think of
> it?  I like it (obviously):
>
> NEW
>   Any application resolving an "about" URI MAY
>   choose the resource it is resolved to at its own discretion, with the
>   exception of those defined below as 'special-purpose "about" URIs'.
>   They MAY use internal redirection to accomplish this  (for
>   instance, Opera redirects all "about" URIs except "about:blank"
>   to its internal "opera" URIs).

Agreed - so I'll change the text.

>
>
>>>> We still haven't had such a term as 'special-purpose about URI', and so
>>>> we can't speak of common behavior.  IMO, taking into account the intended
>>>> semantics of SPUs, if the meaning of query isn't defined, it must be ignored
>>>> not to eliminate the said semantics and their utility.
>>> It looks like the first part of the sentence is as a recommendation for
>>> new SPU designers, the second part is a recommendation for developers. This
>>> adds to confusion and I suggest you reword this, for example:
>>>
>>>    The SPT specification MAY define additional provisions on handling of
>>>   part in
>>>    the corresponding SPU. Unless specified otherwise, implementations MUST
>>> ignore the
>>>    part when processing SPUs.
>> Agreed.
> I provided a suggested revision of the whole section in my other note;
> please consider that.  It gets rid of the "alphabet soup", which I
> think makes things more confusing, and I think it reads much better.

I'll look again at your note and notify then.

>
>>>> That is what HTML5 wants to define (actually, defines).  we had a
>>>> discussion on this previously.
>>> I think that if the document wants to talk about these, it needs to
>>> provide more details.
>> What are such possible details?
> As I said in my other note, I agree with Alexey here: I don't think
> this part is appropriate.  (1) If it's here, it needs some text
> explaining and justifying it, and (2) the goal here is to keep the
> document simple, just doing what's necessary to get this stuff
> registered.

Sp you propose removing this paragraph?

>
>>>>>    An unrecognized 'about' URIs as a URI that may not be recognized by
>>>>>    an application.  (Correspondingly, such categorization is per-
>>>>>    application, not per-fact.)
>>>>>
>>>>> I don't understand the comment in () and I don't think it adds any value
>>>>> anyway.
>>>> It means that 'about' URI can't be defined to be unrecognized - this all
>>>> depends on application.
>>> The first sentence quoted above already says that. Besides, I don't
>>> understand the meaning of "per-fact" in this context.
>> "per-fact" is meant to be predefined for some particular URI.  However, if
>> you insist, I don't object to removing that sentence.
> "Per-fact" simply doesn't make sense in English.  That is, it's not an
> idiom anyone uses, and I doubt anyone has seen it before.  While some
> people might be able to make sense out of it (I think I know what you
> mean, but I'm not sure), we shouldn't have to guess.

I've removed that sentence.

>
> Mostly, see my other note for what I think you should do with section 2.2.2.

I'll have a look.

>
>>> I suppose I should test browser behaviour in the 2 cases mentioned above.
>> Case 1 (testing about:yevstifeyev):
>> FF 7.0.1: a warning and about:blank
>> IE8: tried to load the error page (res://ieframe.dll/navcancl.htm) but
>> failed
>> Chrome 15: redirected to chrome://yevstifeyev and displayed an error.
>> Safari 3.2.1 for Win: about:blank.
>>
>> Conclusion: let's remove the recognized/unrecognized section at all, and
>> leave this to app designers.
> Cool.  I like that.

Thanks.  I've removed this section.

Mykyta Yevstifeyev

>
> Barry
>


From barryleiba.mailing.lists@gmail.com  Mon Nov 28 09:38:56 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B14D21F8AC3 for ; Mon, 28 Nov 2011 09:38:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.677
X-Spam-Level: 
X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 RlAU3sdR26Mc for ; Mon, 28 Nov 2011 09:38:56 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2D1121F891D for ; Mon, 28 Nov 2011 09:38:55 -0800 (PST)
Received: by yenq1 with SMTP id q1so1454070yen.31 for ; Mon, 28 Nov 2011 09:38:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Jbyt6THKuPSEBlUYGNmEMAMvuO6yuXOjCihQNiIAJhQ=; b=GuqKtLQv0W19QKy5hBAz+O6uzOTl7shgAC6jUTrFX6+wV3LdqbwoWGQrDJa8PHr9yi 3nheRqbeBo7/0hODOD3GsRb8bOhtNGQbF3d5k+TkpbDHKORRedfx4FQ2WMhg8LbdwReD PZxNLFKeQ8Cb8biRx7eJsN7DZq2HJJ89NEIs8=
MIME-Version: 1.0
Received: by 10.236.181.234 with SMTP id l70mr63600407yhm.49.1322501935338; Mon, 28 Nov 2011 09:38:55 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.107.9 with HTTP; Mon, 28 Nov 2011 09:38:54 -0800 (PST)
In-Reply-To: <4ED3A616.5030600@gmail.com>
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com> <4EC40EC3.9080304@gmail.com> <4EC8B870.7070105@isode.com> <4ECA3A2C.1010606@gmail.com>  <4ED3A616.5030600@gmail.com>
Date: Mon, 28 Nov 2011 12:38:54 -0500
X-Google-Sender-Auth: sCfYjB1RlJ6ajEihY7TxBhpolXA
Message-ID: 
From: Barry Leiba 
To: =?UTF-8?B?TXlreXRhIFlldnN0aWZleWV2ICjQnC4g0ITQstGB0YLRltGE0LXRlNCyKQ==?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2011 17:38:56 -0000

>> I think a better way to approach it would be to replace all the
>> angle-brackets with quotes, so:
>>
>> NEW
>> =A0 =A0In terms of RFC 3986, the "about-token" part corresponds to
>> "hier-part",
>> =A0 =A0and "about-query" to the query component of the URI.
>
> I'm following the recommendation of RFC 5234:
>
>> =A0 =A0Unlike original BNF, angle brackets ("<",">") are not required.
>> =A0 =A0However, angle brackets may be used around a rule name whenever t=
heir
>> =A0 =A0presence facilitates in discerning the use of a rule name.
>
> ... so I think no change is needed.

I think it's clearer to the reader with quotation marks than with
angle-brackets, and clarity is what's most important.  But I'm not
going to argue this further -- it's not a big deal, and if you prefer
the brackets, that's OK.

>> As I said in my other note, I agree with Alexey here: I don't think
>> this part is appropriate. =A0(1) If it's here, it needs some text
>> explaining and justifying it, and (2) the goal here is to keep the
>> document simple, just doing what's necessary to get this stuff
>> registered.
>
> Sp you propose removing this paragraph?

Yes, I think that's the best approach.

Barry

From msk@cloudmark.com  Mon Nov 28 14:49:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDAC11E80B0 for ; Mon, 28 Nov 2011 14:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 8iQGz6KSAKFu for ; Mon, 28 Nov 2011 14:49:06 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id CFEA311E8087 for ; Mon, 28 Nov 2011 14:49:06 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 28 Nov 2011 14:49:06 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Mon, 28 Nov 2011 14:49:05 -0800
Thread-Topic: Welcome to the "spfbis" mailing list
Thread-Index: AcyuFjflVU2REdRrTM6iU1elAmTzTwACX6dgAAAMv3A=
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [apps-discuss] FW: Welcome to the "spfbis" mailing list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2011 22:49:07 -0000

This mailing list is now available.  If you would like to participate in th=
e work, including:

- hammering out the charter for the proposed working group
- reviewing documents
- editing documents
- implementing
- co-chairing the working group

...please subscribe to that list.  I'll post the current charter text there=
 later this week to get things going.

Thanks,
-MSK

-----Original Message-----
From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of=
 spfbis-request@ietf.org
Sent: Monday, November 28, 2011 1:39 PM
To: Murray S. Kucherawy
Subject: Welcome to the "spfbis" mailing list

Welcome to the spfbis@ietf.org mailing list! Note Well

Any submission to the IETF intended by the Contributor for publication as a=
ll or part of an IETF Internet-Draft or RFC and any statement made within t=
he context of an IETF activity is considered an "IETF Contribution". Such s=
tatements include oral statements in IETF sessions, as well as written and =
electronic communications made at any time or place, which are addressed to=
:

    The IETF plenary session
    The IESG, or any member thereof on behalf of the IESG
    Any IETF mailing list, including the IETF list itself, any working grou=
p or design team list, or any other list functioning under IETF auspices
    Any IETF working group or portion thereof
    Any Birds of a Feather (BOF) session
    The IAB or any member thereof on behalf of the IAB
    The RFC Editor or the Internet-Drafts function

All IETF Contributions are subject to the rules of RFC 5378 and RFC
3979 (updated by RFC 4879).

Statements made outside of an IETF session, mailing list or other function,=
 that are clearly not intended to be input to an IETF activity, group or fu=
nction, are not IETF Contributions in the context of this notice.

Please consult RFC 5378 and RFC 3979 for details.

A participant in any IETF activity is deemed to accept all IETF rules of pr=
ocess, as documented in Best Current Practices RFCs and IESG Statements.

A participant in any IETF activity acknowledges that written, audio and vid=
eo records of meetings may be made and may be available to the public.=20



To post to this list, send your email to:

  spfbis@ietf.org

General information about the mailing list is at:

  https://www.ietf.org/mailman/listinfo/spfbis

If you ever want to unsubscribe or change your options (eg, switch to or fr=
om digest mode, change your password, etc.), visit your subscription page a=
t:

  https://www.ietf.org/mailman/options/spfbis/msk%40cloudmark.com

You can also make such adjustments via email by sending a message to:

  spfbis-request@ietf.org

with the word `help' in the subject or body (don't include the quotes), and=
 you will get back a message with instructions.

You must know your password to change your options (including changing the =
password, itself) or to unsubscribe.  It is:

  Znd/9tqF

Normally, Mailman will remind you of your ietf.org mailing list passwords o=
nce every month, although you can disable this if you prefer.  This reminde=
r will also include instructions on how to unsubscribe or change your accou=
nt options.  There is also a button on your options page that will email yo=
ur current password to you.

From msk@cloudmark.com  Mon Nov 28 14:52:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5684C21F8B61 for ; Mon, 28 Nov 2011 14:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qqfYbnnfjgQo for ; Mon, 28 Nov 2011 14:52:47 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id EF13921F8C74 for ; Mon, 28 Nov 2011 14:52:46 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 28 Nov 2011 14:52:46 -0800
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Mon, 28 Nov 2011 14:52:45 -0800
Thread-Topic: Welcome to the "spfbis" mailing list
Thread-Index: AcyuFjflVU2REdRrTM6iU1elAmTzTwACX6dgAAAMv3AAAB4PUA==
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Welcome to the "spfbis" mailing list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2011 22:52:48 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Murray S. Kucherawy
> Sent: Monday, November 28, 2011 2:49 PM
> To: apps-discuss@ietf.org
> Subject: [apps-discuss] FW: Welcome to the "spfbis" mailing list
>=20
> You must know your password to change your options (including changing
> the password, itself) or to unsubscribe.  It is:
>=20
>   Znd/9tqF

Don't worry, I've already changed this.

Embarrasedly yours,
-MSK

From wmills@yahoo-inc.com  Mon Nov 28 22:24:55 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7475611E809A for ; Mon, 28 Nov 2011 22:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.392
X-Spam-Level: 
X-Spam-Status: No, score=-16.392 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
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 1V1QEpoupmrn for ; Mon, 28 Nov 2011 22:24:54 -0800 (PST)
Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by ietfa.amsl.com (Postfix) with SMTP id 8977621F8B6D for ; Mon, 28 Nov 2011 22:24:54 -0800 (PST)
Received: from [98.139.91.65] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 29 Nov 2011 06:24:51 -0000
Received: from [98.139.91.57] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 29 Nov 2011 06:24:51 -0000
Received: from [127.0.0.1] by omp1057.mail.sp2.yahoo.com with NNFMP; 29 Nov 2011 06:24:51 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 860996.96753.bm@omp1057.mail.sp2.yahoo.com
Received: (qmail 26413 invoked by uid 60001); 29 Nov 2011 06:24:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1322547891; bh=NNkHqIZGSr14NpbQ7g1UMCG/5GgGEXftkQraqomPZ+0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BGzQR4JEoRclMU34nBM8NRSeIcf/1ziI3m1t4NKyORqFQ/2Q6yDNgpLb1gZzf/GLk4DrS6+/BqWY/bonVpV6FJJISDHUKdDiRFPesk/qt6rpMEGwVe+3FXm8zXCSUCNi0TaDxFM2s0JBqdIRkILTsoddHfHDiKgYPgwyiS3DaMo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nx/Kffth5avxdJsmMyr+VKofeEBmvSnvj66TCah7scFGKHbQ9b7lCYT8PBUioLNi0eYHfjiS8sK5NKsSQlVzTLx1waSq3uWfekgo4TiFoHTZI9ZXNVIZd6zF43+C+7XPPOZar0Hmqp3mij7MgBKhCK9HxLqof0FNFfWxWIqd9sM=;
X-YMail-OSG: oAfbI.EVM1l9LOQRTNENR97qWFXKO58mX2NX43bpfbivd_J 1r5IgT5zyRYVkOLD20qB9UMSKGGJCeDfSRV4U8jO73gdEtUXPCI1m3PhNj0c FgAjntANwKJ8uQLG8MWMbNnhdO0JWMbPvaFwKKuMJiPGPHoKJlEgVK4PjRTv MSfdISIKV9rzn04yjYzBH7dEdrPN35KIfnXpBXMBAIvU9QrMpfq6ziK5dhts SZNVyuEBoevz6tntPqB5VhEHzKGUpYd6Y6L3RVMH_HYcdK.WojE3ropQ0e2j o1AhsjVRXFI_ztYHIAfZZt5hYxmlehIHlI3ESt_PPsZ9vj6ZEknZIwko2CJh gAJpEqvUoGd6bCxkhgoGw2WZKcNmpQNajI8YLRDplQNNAbaWnrnjEIr7kMcz s.akoGvGyYSxN3b5W9BdiVwIjbtoAcT9KM0yTVlXzSSMD_VJY4Jje.kFhXBK AI5BieRavDY4Y0CK2XiXzz7ar1Spo2zJAY5DWFGBmN3BPtqb.lZPVZF8TiQS yDfv_A6A-
Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Mon, 28 Nov 2011 22:24:51 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.116.331537
Message-ID: <1322547891.26139.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Mon, 28 Nov 2011 22:24:51 -0800 (PST)
From: William Mills 
To: "apps-discuss@ietf.org" , "draft-ietf-kitten-sasl-openid.all@tools.ietf.org" 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "kitten@ietf.org" , "iesg@ietf.org" 
Subject: [apps-discuss] [APPS-REVIEW] review of draft-ietf-kitten-sasl-openid-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2011 06:24:55 -0000

I have been selected as the Applications Area Review Team reviewer for this=
 draft (for background on apps-review, please see http://www.apps.ietf.org/=
content/applications-area-review-team). =0A=0APlease resolve these comments=
 along with any other Last Call comments you may receive. Please wait for d=
irection from your document shepherd or AD before posting a new version of =
the draft.=0A=0ADocument: draft-ietf-kitten-sasl-openid-07=0AReviewer: Will=
iam J. Mills=0AReview Date: November 28, 2011=0AIETF Last Call Date:=A0 Oct=
ober 25, 2011=0A=0AReview Summary:=0A=0AThis draft is almost ready for publ=
ication as a Proposed Standard, but should address the three major issues b=
elow before proceeding.=A0 Some minor issues and nits are also noted.=0A=0A=
Document Summary:=0A=0AThis document defines a pure SASL mechanism for Open=
ID, but it conforms to the new bridge between SASL and the GSS-API called G=
S2 [RFC5801], so it defines both a SASL and a GSS-API mechanism.=0A.=0A=0AM=
ajor Issues:=0A=0ASection=A0 1.2.=A0=A0Applicability:=A0 This section requi=
res TLS but channel binding is not supported by the mechanism.=A0 OpenID it=
self does not require TLS for client to relying party interactions, as inte=
grity can be assured with a MAC signature and replayability is dealt with i=
n the OpenID nonce.=A0 Requiring TLS does not appear to be based on the und=
erlying security profile of OpenID.=A0 If TLS is ot be required channel bin=
ding should be supported.=A0 If TLS is not required then there is the possi=
bility of a DOS against the return_to entrypoint returned to the user, send=
ing a false failure message.=0A=0A=0ASection 3.2 Authentication Request:=A0=
 In the second full paragraph defining transaction id, the language here pr=
obably isn't strong enough.=A0=A0=A0 What it says now is =0A=0A=A0=A0 The f=
orm of this transaction is left to the RP to decide, but =0A=A0=A0 SHOULD b=
e large enough to be resistant to being guessed or attacked.=0A=0A(Nit: At =
the very least "transaction" needs to be "transaction id") I think it would=
 be better if the current text is replaced with=0A=0A=A0=A0 The form of thi=
s transaction id is left to the implementer, but it=0A=A0=A0 MUST be resist=
ant to being guessed or attacked.=0A=0AI think MUST is justified here becau=
se the RP is possibly open to a DOS if the value is guessable.=A0 A paragra=
ph in the security considerations section might be warranted to talk about =
how to pick good unguessable values, although this has been done many times=
 in many different specs.=A0 Side comment: maybe we need an RFC just for th=
is and then everyone can cite it.=0A=0A3.3.=A0=A0Server Response=0A=0AThe p=
roblem I see here is that the result sent to the server that is "used to se=
t state in the server accordingly" is not guaranteed to provide a username=
=A0 that will be useful to the SASL endpoint.=A0 The RP might get a full em=
ail address, or might get a bare username.=A0 In the case of an IMAP server=
 supporting multiple domains this may be significant.=A0 The spec really sh=
ould define how the SASL identities are determined from the response from t=
he OP.=0A=0AIt's possible that this could be solved by moving 6.1 and makin=
g it 3.3.1.=A0 Identity mapping seems to fit better here than in security c=
onsiderations.=0A=0A=0AMinor issues:=0A=0AUser confusion on names: The prob=
lem I see is one of confusion for the user of an OpenID enabled SASL client=
 for Mail.=A0 Some endpoint will need to be given usrename, some will be gi=
ven an dOpenID endpoint.=A0 Clarifying language might be useful to guide th=
e client implementer.=A0 Is there a disocvery method that the client can us=
e ot go from a username/domain to the OpenID endpoint ot send to the RP?=0A=
=0AMore examples:=A0 I'd prefer to see an example of a failure flow include=
d.=A0 I tend to like examples though, and find them helpful in parsing the =
normative text.=0A=0A3.3.=A0=A0Server Response & 3.4.=A0=A0Error Handling &=
 5. Example=0A=0AThere's an inconsistency here I think could be better.=A0=
=A0In the Exmaple we have a success case where the client returns and empty=
 client message in order to prompt the server to finalize the SASL negotiat=
ion.=A0 In the error handling case we have an explicit continuation from th=
e client sending "=3D".=A0=A0 Is the "=3D" sign after the error return actu=
ally required or can this simply be an empty client message.=A0 This means =
if the client knows the negotiation is complete and has not gotten a result=
 it just always sends the empty message.=0A=0A=0ANits:=0A=0ASection 1, 4th =
para, first sentence:=A0 I would change "As currently envisioned, this mech=
anism is to allow" to "This mechanism allows".=0A=0ASection 1, 5th para, 2n=
d sentence: "will continued to be" change continued to continue.

From internet-drafts@ietf.org  Tue Nov 29 13:12:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DB611E80BA; Tue, 29 Nov 2011 13:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 S2ACsrxeFNEM; Tue, 29 Nov 2011 13:12:29 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B4C21F8AF1; Tue, 29 Nov 2011 13:12:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64
Message-ID: <20111129211229.22583.58326.idtracker@ietfa.amsl.com>
Date: Tue, 29 Nov 2011 13:12:29 -0800
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-03.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2011 21:12:33 -0000

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

	Title           : The Multipart/Report Media Type for the Reporting of Mai=
l System Administrative Messages
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc3462bis-03.txt
	Pages           : 18
	Date            : 2011-11-29

   The multipart/report Multipurpose Internet Mail Extensions (MIME)
   media type is a general "family" or "container" type for electronic
   mail reports of any kind.  Although this memo defines only the use of
   the multipart/report media type with respect to delivery status
   reports, mail processing programs will benefit if a single media type
   is used for all kinds of reports.

   This memo obsoletes RFC3462.  The IESG is also requested to mark
   RFC1892 and RFC3462 as "historic".


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3462bis-03.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3462bis-03.txt


From McQuilWP@pobox.com  Tue Nov 29 15:34:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C890A21F8BE4 for ; Tue, 29 Nov 2011 15:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 N93i8d7ZFpJu for ; Tue, 29 Nov 2011 15:34:09 -0800 (PST)
Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 09A8021F8BDB for ; Tue, 29 Nov 2011 15:34:07 -0800 (PST)
Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 5F4556114; Tue, 29 Nov 2011 18:34:04 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=jzt1ThlnUYSt r8JsqL8DZiLy3GM=; b=ZLMhM3pCZYm7wN3hC54KFgbnfsaF4caUi1xDpeu0urDe YqB08NP2PmsrXdGuP8gj4qqrVfmzKivDFDAwTxAk9tWFR8LP2w3a/YH8ug4nL643 mhfRiABXLR5TD496Lx7b5RugzL1oM3UvAi/Uxa0+F8VxLvd+FURvQ4fkQvt3gZA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=hId/LA 5lGBLbRZQAAKwyIBdeRFDKyNpGe/56P/cHbqdH2lxhYg0xPng+XH9pqDKX2CT2pT 5Ho2UtShxAOQ7NefKG5S1oogvIrKDHO9CW/YhJVI9h781GBf2QU2t3CAwK068DZI vFlIxxUvzT79YCgvkmTMD/Xt/frSw4YdL41mI=
Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 562D86112; Tue, 29 Nov 2011 18:34:04 -0500 (EST)
Received: from BQ07NB (unknown [68.107.110.211]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id D1174610E; Tue, 29 Nov 2011 18:34:03 -0500 (EST)
Date: Tue, 29 Nov 2011 15:34:02 -0800
From: Bill McQuillan 
X-Priority: 3 (Normal)
Message-ID: <11474880.20111129153402@pobox.com>
To: Apps-Discusssion 
In-Reply-To: <20111129211229.22583.58326.idtracker@ietfa.amsl.com>
References: <20111129211229.22583.58326.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 9F9CEC06-1AE2-11E1-89A5-9DB42E706CDE-02871704!b-pb-sasl-quonix.pobox.com
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-03.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2011 23:34:09 -0000

Looking at the document, I noticed in the second paragraph of the 
Introduction a missing word: "overly" what?

-- 
Bill McQuillan 


From msk@cloudmark.com  Tue Nov 29 15:39:50 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0941F0C73 for ; Tue, 29 Nov 2011 15:39:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.956
X-Spam-Level: 
X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.357, 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 LME6dzUPAkoQ for ; Tue, 29 Nov 2011 15:39:50 -0800 (PST)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 312321F0C51 for ; Tue, 29 Nov 2011 15:39:50 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 29 Nov 2011 15:39:49 -0800
From: "Murray S. Kucherawy" 
To: Apps-Discusssion 
Date: Tue, 29 Nov 2011 15:39:49 -0800
Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-03.txt
Thread-Index: Acyu72mxtCu4WvlFRJeVPMzks0F7VgAAKvaA
Message-ID: 
References: <20111129211229.22583.58326.idtracker@ietfa.amsl.com> <11474880.20111129153402@pobox.com>
In-Reply-To: <11474880.20111129153402@pobox.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-03.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2011 23:39:50 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Bill McQuillan
> Sent: Tuesday, November 29, 2011 3:34 PM
> To: Apps-Discusssion
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-03.=
txt
>=20
> Looking at the document, I noticed in the second paragraph of the
> Introduction a missing word: "overly" what?

Ah right, and Stephen Farrell had commented about that in the last round of=
 IESG evaluation as well, and it got away from me.  Thanks for the reminder=
.

-04, coming right up.


From internet-drafts@ietf.org  Tue Nov 29 15:42:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDE421F8C07; Tue, 29 Nov 2011 15:42:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.593
X-Spam-Level: 
X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 ElBWV6qqQIli; Tue, 29 Nov 2011 15:42:24 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9594D21F85C7; Tue, 29 Nov 2011 15:42:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64
Message-ID: <20111129234224.14240.4207.idtracker@ietfa.amsl.com>
Date: Tue, 29 Nov 2011 15:42:24 -0800
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-04.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2011 23:42:25 -0000

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

	Title           : The Multipart/Report Media Type for the Reporting of Mai=
l System Administrative Messages
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc3462bis-04.txt
	Pages           : 18
	Date            : 2011-11-29

   The multipart/report Multipurpose Internet Mail Extensions (MIME)
   media type is a general "family" or "container" type for electronic
   mail reports of any kind.  Although this memo defines only the use of
   the multipart/report media type with respect to delivery status
   reports, mail processing programs will benefit if a single media type
   is used for all kinds of reports.

   This memo obsoletes RFC3462.  The IESG is also requested to mark
   RFC1892 and RFC3462 as "historic".


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3462bis-04.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3462bis-04.txt


From sm@elandsys.com  Wed Nov 30 01:50:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E4321F8663 for ; Wed, 30 Nov 2011 01:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx5zqKUpydVQ for ; Wed, 30 Nov 2011 01:50:16 -0800 (PST)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id CA97621F8557 for ; Wed, 30 Nov 2011 01:50:16 -0800 (PST)
Received: from SUBMAN.elandsys.com ([41.136.237.142]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id pAU9o8A3025900 for ; Wed, 30 Nov 2011 01:50:13 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1322646615; bh=AbZClFimJKkW31Iegz7RKO7s2kk=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type: Content-Transfer-Encoding; b=zLx0aWV7bNWxqSIrpRVXA/lVdSsBXASO+FRVThtLumRNOiO3Z7mjWK5xQbaHwZ5T7 TTKjGqwTRUnvwgskM3uD2RnbYF54xqV3AE7t8bUzUiNv96XCLqhyjXU/Vdpl5A69se 2gC7GXiq/9hmvGbxJiOK/Rzn4X4JdwsFgNkz4K8E=
Message-Id: <6.2.5.6.2.20111129224036.0acba060@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 30 Nov 2011 01:48:19 -0800
To: apps-discuss@ietf.org
From: S Moonesamy 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: [apps-discuss] Apps Area Review Team Report for November 2011
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2011 09:50:19 -0000

Hello,

The Applications Area Review Team provides=20
semi-formal reviews of Internet-Drafts as a way=20
to improve the quality of IETF=20
specifications.  The members of the team are=20
selected from the IETF community, especially from=20
among active participants and recognized experts in the Applications Area.

The following reviews were performed in November 2011:

    Reviewer             I-D

  Mark Nottingham      draft-ietf-oauth-v2-bearer-14
  Murray S. Kucherawy  draft-ietf-v6ops-happy-eyeballs-05
  William J. Mills     draft-ietf-kitten-sasl-openid-07

The Apps Area Review Team currently comprises 33=20
members, including one member currently on=20
leave.  The team performed 30 reviews since the beginning of the year.

This is the last report from the Apps Area Review=20
Team.  Thanks to Ned Freed and Eric Burger for=20
their contribution to the Apps Area Review Team=20
over the years and to the Application Area=20
Directors, Lisa Dusseault, Alexey Melnikov, Peter=20
Saint-Andre and Pete Resnick.  And a special thanks to the following=
 reviewers:

  Ted Hardie
  Yves Lafon
  Eliot Lear
  Martin J. D=FCrst
  Joshua Bell
  Carsten Bormann
  Tim Bray
  Joseph Yee
  Julian Reschke
  Larry Masinter
  Xiaodong Lee
  Dave Crocker
  Murray S. Kucherawy
  Henry S. Thompson
  Barry Leiba
  Mark Nottingham
  William J. Mills

Regards,
S. Moonesamy
On behalf of the Apps Review Team
http://www.apps.ietf.org/content/applications-area-review-team


From julian.reschke@gmx.de  Wed Nov 30 07:22:37 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A17321F8B44 for ; Wed, 30 Nov 2011 07:22:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 urNnA+sHz3Lc for ; Wed, 30 Nov 2011 07:22:37 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B3F3121F8B4D for ; Wed, 30 Nov 2011 07:22:36 -0800 (PST)
Received: (qmail invoked by alias); 30 Nov 2011 15:22:23 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 30 Nov 2011 16:22:23 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/0eygzGh/0e60rJ90ZP9p+gCh5V7Oy0JPuZ83/8X zVFYzGuD9o/PsM
Message-ID: <4ED64A26.5030003@gmx.de>
Date: Wed, 30 Nov 2011 16:22:14 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: IETF Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Subject: [apps-discuss] JSON patch: "test" operation
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2011 15:22:37 -0000

Hi,

this came up during discussions of patch formats on the Apache 
jackrabbit-dev mailing list:

Would it make sense to add a "test" operation that allows checking the 
state of the JSON object to be modified?

It would be consistent with other diff formats that use context 
information in order to check whether the patch "cleanly applies".

An example would be:

    [
          { "test": "/vsn", "value" : 17 },
          { "replace": "/vsn", "value" : 18 },
          { "replace": "/balance", "value": 1234 }
    ]

And yes, concurrency control can also be achieved using conditional HTTP 
methods, but that doesn't mean that they don't make sense in the patch 
format as well.

Best regards, Julian

From paul.bryan@forgerock.com  Wed Nov 30 09:09:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E8221F8BB9 for ; Wed, 30 Nov 2011 09:09:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+xb7g5Plh9I for ; Wed, 30 Nov 2011 09:09:28 -0800 (PST)
Received: from eu1sys200aog115.obsmtp.com (eu1sys200aog115.obsmtp.com [207.126.144.139]) by ietfa.amsl.com (Postfix) with SMTP id A05D421F8BB7 for ; Wed, 30 Nov 2011 09:09:27 -0800 (PST)
Received: from mail-iy0-f171.google.com ([209.85.210.171]) (using TLSv1) by eu1sys200aob115.postini.com ([207.126.147.11]) with SMTP ID DSNKTtZjPNthNL/ewprrafMKgsz+N2arWz5u@postini.com; Wed, 30 Nov 2011 17:09:27 UTC
Received: by mail-iy0-f171.google.com with SMTP id n33so617171iae.2 for ; Wed, 30 Nov 2011 09:09:16 -0800 (PST)
Received: by 10.42.72.135 with SMTP id o7mr3985164icj.45.1322672956117; Wed, 30 Nov 2011 09:09:16 -0800 (PST)
Received: from [192.168.1.3] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id el2sm10089761ibb.10.2011.11.30.09.09.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Nov 2011 09:09:14 -0800 (PST)
Message-ID: <1322672952.2050.8.camel@neutron>
From: "Paul C. Bryan" 
To: IETF Apps Discuss 
Date: Wed, 30 Nov 2011 09:09:12 -0800
In-Reply-To: <4ED64A26.5030003@gmx.de>
References: <4ED64A26.5030003@gmx.de>
Content-Type: multipart/alternative; boundary="=-ukWJvETsZiKtRFvk50e/"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Subject: Re: [apps-discuss] JSON patch: "test" operation
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2011 17:09:28 -0000

--=-ukWJvETsZiKtRFvk50e/
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Yes, assert/equals/test has been mentioned in the past. As you point
out, HTTP preconditions to handle this to some extent. I've avoided
adding it thus far mostly because I haven't had a single concrete use
case outside of HTTP. Given at least the pattern of multiple requests
wanting to test a value for equality, I think I have enough data to add
it to the next revision of the spec. Consider it added.

Paul 

On Wed, 2011-11-30 at 16:22 +0100, Julian Reschke wrote:

> Hi,
> 
> this came up during discussions of patch formats on the Apache 
> jackrabbit-dev mailing list:
> 
> Would it make sense to add a "test" operation that allows checking the 
> state of the JSON object to be modified?
> 
> It would be consistent with other diff formats that use context 
> information in order to check whether the patch "cleanly applies".
> 
> An example would be:
> 
>     [
>           { "test": "/vsn", "value" : 17 },
>           { "replace": "/vsn", "value" : 18 },
>           { "replace": "/balance", "value": 1234 }
>     ]
> 
> And yes, concurrency control can also be achieved using conditional HTTP 
> methods, but that doesn't mean that they don't make sense in the patch 
> format as well.
> 
> Best regards, Julian
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



--=-ukWJvETsZiKtRFvk50e/
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


Yes, assert/equals/test has been mentioned in the past. As you point out, HTTP preconditions to handle this to some extent. I've avoided adding it thus far mostly because I haven't had a single concrete use case outside of HTTP. Given at least the pattern of multiple requests wanting to test a value for equality, I think I have enough data to add it to the next revision of the spec. Consider it added.



Paul 



On Wed, 2011-11-30 at 16:22 +0100, Julian Reschke wrote:



Hi,

this came up during discussions of patch formats on the Apache 
jackrabbit-dev mailing list:

Would it make sense to add a "test" operation that allows checking the 
state of the JSON object to be modified?

It would be consistent with other diff formats that use context 
information in order to check whether the patch "cleanly applies".

An example would be:

    [
          { "test": "/vsn", "value" : 17 },
          { "replace": "/vsn", "value" : 18 },
          { "replace": "/balance", "value": 1234 }
    ]

And yes, concurrency control can also be achieved using conditional HTTP 
methods, but that doesn't mean that they don't make sense in the patch 
format as well.

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









--=-ukWJvETsZiKtRFvk50e/--


From mca@amundsen.com  Wed Nov 30 09:27:17 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B43921F8BCB for ; Wed, 30 Nov 2011 09:27:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.679
X-Spam-Level: 
X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, 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 Ta+RwZq3jBfd for ; Wed, 30 Nov 2011 09:27:16 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA4E21F8BBD for ; Wed, 30 Nov 2011 09:27:16 -0800 (PST)
Received: by ywm13 with SMTP id 13so1064849ywm.31 for ; Wed, 30 Nov 2011 09:27:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.38.106 with SMTP id f10mr9073363pbk.37.1322674030410; Wed, 30 Nov 2011 09:27:10 -0800 (PST)
Sender: mca@amundsen.com
Received: by 10.142.196.20 with HTTP; Wed, 30 Nov 2011 09:27:10 -0800 (PST)
In-Reply-To: <1322672952.2050.8.camel@neutron>
References: <4ED64A26.5030003@gmx.de> <1322672952.2050.8.camel@neutron>
Date: Wed, 30 Nov 2011 12:27:10 -0500
X-Google-Sender-Auth: MNXOrlWWVi5Dyv27OOe0Hqhnnlo
Message-ID: 
From: mike amundsen 
To: "Paul C. Bryan" 
Content-Type: multipart/alternative; boundary=bcaec51dde39bc7c4d04b2f70bc9
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] JSON patch: "test" operation
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2011 17:27:17 -0000

--bcaec51dde39bc7c4d04b2f70bc9
Content-Type: text/plain; charset=ISO-8859-1

Julian:

Is the thinking that _clients_ should tell servers to test an
insert/update?  IOW, clients would want to see test results?  A "dry run"
scenario?

Also, was there any talk about how servers would handle failed tests (HTTP
Response code, etc.)? If one or more tests fail, would the server have the
option of making the changes and then returning a list of success/fail
information?


mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me




On Wed, Nov 30, 2011 at 12:09, Paul C. Bryan wrote:

> **
> Yes, assert/equals/test has been mentioned in the past. As you point out,
> HTTP preconditions to handle this to some extent. I've avoided adding it
> thus far mostly because I haven't had a single concrete use case outside of
> HTTP. Given at least the pattern of multiple requests wanting to test a
> value for equality, I think I have enough data to add it to the next
> revision of the spec. Consider it added.
>
> Paul
>
> On Wed, 2011-11-30 at 16:22 +0100, Julian Reschke wrote:
>
> Hi,
>
> this came up during discussions of patch formats on the Apache
> jackrabbit-dev mailing list:
>
> Would it make sense to add a "test" operation that allows checking the
> state of the JSON object to be modified?
>
> It would be consistent with other diff formats that use context
> information in order to check whether the patch "cleanly applies".
>
> An example would be:
>
>     [
>           { "test": "/vsn", "value" : 17 },
>           { "replace": "/vsn", "value" : 18 },
>           { "replace": "/balance", "value": 1234 }
>     ]
>
> And yes, concurrency control can also be achieved using conditional HTTP
> methods, but that doesn't mean that they don't make sense in the patch
> format as well.
>
> Best regards, Julian
> _______________________________________________
> apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--bcaec51dde39bc7c4d04b2f70bc9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Julian:

Is the thinking that _clients_ should tell serve=
rs to test an insert/update? =A0IOW, clients would want to see test results=
? =A0A "dry run" scenario?

Also, was the=
re any talk about how servers would handle failed tests (HTTP Response code=
, etc.)? If one or more tests fail, would the server have the option of mak=
ing the changes and then returning a list of success/fail information?=A0



mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf=
.rdf#me






On Wed, Nov 30, 2011 at 12:09, Paul C. B=
ryan <paul=
.bryan@forgerock.com> wrote:




 =20
 =20



Yes, assert/equals/test has been mentioned in the past. As you point out, H=
TTP preconditions to handle this to some extent. I've avoided adding it=
 thus far mostly because I haven't had a single concrete use case outsi=
de of HTTP. Given at least the pattern of multiple requests wanting to test=
 a value for equality, I think I have enough data to add it to the next rev=
ision of the spec. Consider it added.




Paul 



On Wed, 2011-11-30 at 16:22 +0100, Julian Reschke wrote:



Hi,

this came up during discussions of patch formats on the Apache=20
jackrabbit-dev mailing list:

Would it make sense to add a "test" operation that allows checkin=
g the=20
state of the JSON object to be modified?

It would be consistent with other diff formats that use context=20
information in order to check whether the patch "cleanly applies"=
.

An example would be:

    [
          { "test": "/vsn", "value" : 17 },
          { "replace": "/vsn", "value" : 18 }=
,
          { "replace": "/balance", "value": 1=
234 }
    ]

And yes, concurrency control can also be achieved using conditional HTTP=20
methods, but that doesn't mean that they don't make sense in the pa=
tch=20
format as well.

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










_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





--bcaec51dde39bc7c4d04b2f70bc9--

From presnick@qualcomm.com  Wed Nov 30 10:51:20 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEBD21F853A for ; Wed, 30 Nov 2011 10:51:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 UWIQoyv5fUZt for ; Wed, 30 Nov 2011 10:51:20 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6295A21F8538 for ; Wed, 30 Nov 2011 10:51:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1322679080; x=1354215080; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4ED67B02.8000903@qualcomm.com>|Date:=20We d,=2030=20Nov=202011=2012:50:42=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20S=20Moonesamy=20|CC:=20|Subject:=20Re:=20[ apps-discuss]=20Apps=20Area=20Review=20Team=20Report=20fo r=20November=202011|References:=20<6.2.5.6.2.201111292240 36.0acba060@elandnews.com>|In-Reply-To:=20<6.2.5.6.2.2011 1129224036.0acba060@elandnews.com>|Content-Type:=20text/p lain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=VEXFzJtyQYMJM5WiUmC3wTKc9XqEcGQO7pqCaGPNh7s=; b=lz0ts7hwo7gOORyFbXGP4Sp3f+m9blr7+P8el2ue7TY4LbPEAw69kFif PhQbXKlrd5P5gNHF0cmz+dK7nk1YYHcRlwo5ObREKMvEfId3M3eUap4lO 3amvOL02T/9jv4M96wzkQ70liJ8wn3FXOVt7PDPjxEnPns5o+U6gEYhun o=;
X-IronPort-AV: E=McAfee;i="5400,1158,6546"; a="142346243"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 30 Nov 2011 10:51:18 -0800
X-IronPort-AV: E=Sophos;i="4.69,597,1315206000"; d="scan'208";a="156574024"
Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 30 Nov 2011 10:51:17 -0800
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 30 Nov 2011 10:50:44 -0800
Message-ID: <4ED67B02.8000903@qualcomm.com>
Date: Wed, 30 Nov 2011 12:50:42 -0600
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: S Moonesamy 
References: <6.2.5.6.2.20111129224036.0acba060@elandnews.com>
In-Reply-To: <6.2.5.6.2.20111129224036.0acba060@elandnews.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps Area Review Team Report for November 2011
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2011 18:51:21 -0000

On 11/30/11 3:48 AM, S Moonesamy wrote:
> This is the last report from the Apps Area Review Team.

Just to clarify: Though we are shutting down the review team, we are 
reconstituting as an Apps Directorate. Reviews are not going away.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From dhc@dcrocker.net  Wed Nov 30 11:22:14 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A7921F8A71 for ; Wed, 30 Nov 2011 11:22:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.539
X-Spam-Level: 
X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, 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 qyouDlNyJmoy for ; Wed, 30 Nov 2011 11:22:14 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B599E11E808C for ; Wed, 30 Nov 2011 11:22:10 -0800 (PST)
Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAUJM0hg002915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2011 11:22:06 -0800
Message-ID: <4ED6824C.3040305@dcrocker.net>
Date: Wed, 30 Nov 2011 11:21:48 -0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Pete Resnick 
References: <6.2.5.6.2.20111129224036.0acba060@elandnews.com> <4ED67B02.8000903@qualcomm.com>
In-Reply-To: <4ED67B02.8000903@qualcomm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 30 Nov 2011 11:22:07 -0800 (PST)
Cc: S Moonesamy , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps Area Review Team Report for November 2011
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2011 19:22:14 -0000

On 11/30/2011 10:50 AM, Pete Resnick wrote:
> On 11/30/11 3:48 AM, S Moonesamy wrote:
>> This is the last report from the Apps Area Review Team.
>
> Just to clarify: Though we are shutting down the review team, we are
> reconstituting as an Apps Directorate. Reviews are not going away.


I suggest slightly different wording, to help avoid this misunderstanding.

> This is the last report from the Apps Area Review Team.

->

    The Apps Area Review Team has been re-cast as the Apps Directorate.  This is 
the last report under the old title.  Future reviews will be labeled as from the 
Apps Directorate.


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From sm@elandsys.com  Wed Nov 30 13:20:57 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6602311E80C0 for ; Wed, 30 Nov 2011 13:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sVlbv6K1bX0 for ; Wed, 30 Nov 2011 13:20:54 -0800 (PST)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5860D11E80AF for ; Wed, 30 Nov 2011 13:20:54 -0800 (PST)
Received: from SUBMAN.elandsys.com ([41.136.232.170]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id pAULKeeQ027964 for ; Wed, 30 Nov 2011 13:20:49 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1322688051; bh=3MbuQPqyih/kLqNeeg5AcoJTSUo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=XRAkVZE1SMlhxVwh+nhSC62bcI9ZbpB+VZRt91gA4SUrw+jzFcAmpMe7QCM3re8ao xQh6AedEEJL794PsMisQChOngInmo8exg5GM4rPISGKPTBN8UV9S/TqOCFeYZJiu6P KKZpyoKQziFPN9a0R165SoM5pxfSzXeQN1oDY1Jw=
Message-Id: <6.2.5.6.2.20111130124511.09e20708@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 30 Nov 2011 13:03:10 -0800
To: apps-discuss@ietf.org
From: S Moonesamy 
In-Reply-To: <4ED67B02.8000903@qualcomm.com>
References: <6.2.5.6.2.20111129224036.0acba060@elandnews.com> <4ED67B02.8000903@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [apps-discuss] Apps Area Review Team Report for November  2011
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2011 21:20:57 -0000

At 10:50 30-11-2011, Pete Resnick wrote:
>Just to clarify: Though we are shutting down the review team, we are 
>reconstituting as an Apps Directorate. Reviews are not going away.

Please note that the reviews will still be semi-formal.

I would like to get some feedback from authors and other subscribers 
about the previous reviews.  Please send me your comments 
off-list.  I would like to know what you didn't like, what could be 
improved, etc.

Regards,
S. Moonesamy 


From stpeter@stpeter.im  Wed Nov 30 14:10:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C119221F8922 for ; Wed, 30 Nov 2011 14:10:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level: 
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 MlPDcuZKvMdm for ; Wed, 30 Nov 2011 14:10:32 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5BE21F8A6C for ; Wed, 30 Nov 2011 14:10:31 -0800 (PST)
Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E1592422DB; Wed, 30 Nov 2011 15:17:28 -0700 (MST)
Message-ID: <4ED6A9D5.8030508@stpeter.im>
Date: Wed, 30 Nov 2011 15:10:29 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: S Moonesamy 
References: <6.2.5.6.2.20111129224036.0acba060@elandnews.com> <4ED67B02.8000903@qualcomm.com> <6.2.5.6.2.20111130124511.09e20708@elandnews.com>
In-Reply-To: <6.2.5.6.2.20111130124511.09e20708@elandnews.com>
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps Area Review Team Report for November  2011
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2011 22:10:32 -0000

On 11/30/11 2:03 PM, S Moonesamy wrote:
> At 10:50 30-11-2011, Pete Resnick wrote:
>> Just to clarify: Though we are shutting down the review team, we are
>> reconstituting as an Apps Directorate. Reviews are not going away.
> 
> Please note that the reviews will still be semi-formal.
> 
> I would like to get some feedback from authors and other subscribers
> about the previous reviews.  Please send me your comments off-list.  I
> would like to know what you didn't like, what could be improved, etc.

To choose the most recent example, Bill's review of
draft-ietf-kitten-sasl-openid was very helpful to me -- in my IESG
ballot position I could simply reference it (I'm completing my own
further review, too, but it was great to have a strong review to point
at). I would expect that if IETF folks do future work with OpenID, we'll
be able to build upon his comments as needed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From tianlinyi@huawei.com  Wed Nov 30 23:19:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4990511E80A6 for ; Wed, 30 Nov 2011 23:19:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 93mMovOMAiUg for ; Wed, 30 Nov 2011 23:19:32 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D110011E8080 for ; Wed, 30 Nov 2011 23:19:31 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVI0060XK9UEB@szxga05-in.huawei.com> for apps-discuss@ietf.org; Thu, 01 Dec 2011 15:17:55 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVI007WMK9TRF@szxga05-in.huawei.com> for apps-discuss@ietf.org; Thu, 01 Dec 2011 15:17:54 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFL93546; Thu, 01 Dec 2011 15:17:24 +0800
Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 01 Dec 2011 15:17:19 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0218.012; Thu, 01 Dec 2011 15:17:15 +0800
Date: Thu, 01 Dec 2011 07:17:13 +0000
From: TianLinyi 
In-reply-to: 
X-Originating-IP: [10.70.109.57]
To: mike amundsen , "Paul C. Bryan" 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA1820A0A1@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_3byUGIe21Z7jU4mPqwgyLg)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: [apps-discuss] JSON patch: "test" operation
Thread-index: AQHMr3PqiS1xzTn7t0aU/VYqf7sfw5XFIIsAgAAFBQCAAW1hgA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4ED64A26.5030003@gmx.de> <1322672952.2050.8.camel@neutron> 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] JSON patch: "test" operation
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 07:19:33 -0000

--Boundary_(ID_3byUGIe21Z7jU4mPqwgyLg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi, All

I think test would make it complicated. The test could result in <, >, <=, >=, = conditions.

If we want something like HTTP If-Match mechanism, I would think it should not be in the JSON patch. We should keep JSON patch simple. The status code is better to be delivered in the protocol layer who delivers the JSON patch document.

Cheers,
Linyi

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of mike amundsen
Sent: Thursday, December 01, 2011 1:27 AM
To: Paul C. Bryan
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] JSON patch: "test" operation

Julian:

Is the thinking that _clients_ should tell servers to test an insert/update?  IOW, clients would want to see test results?  A "dry run" scenario?

Also, was there any talk about how servers would handle failed tests (HTTP Response code, etc.)? If one or more tests fail, would the server have the option of making the changes and then returning a list of success/fail information?


mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me



On Wed, Nov 30, 2011 at 12:09, Paul C. Bryan > wrote:
Yes, assert/equals/test has been mentioned in the past. As you point out, HTTP preconditions to handle this to some extent. I've avoided adding it thus far mostly because I haven't had a single concrete use case outside of HTTP. Given at least the pattern of multiple requests wanting to test a value for equality, I think I have enough data to add it to the next revision of the spec. Consider it added.

Paul

On Wed, 2011-11-30 at 16:22 +0100, Julian Reschke wrote:

Hi,



this came up during discussions of patch formats on the Apache

jackrabbit-dev mailing list:



Would it make sense to add a "test" operation that allows checking the

state of the JSON object to be modified?



It would be consistent with other diff formats that use context

information in order to check whether the patch "cleanly applies".



An example would be:



    [

          { "test": "/vsn", "value" : 17 },

          { "replace": "/vsn", "value" : 18 },

          { "replace": "/balance", "value": 1234 }

    ]



And yes, concurrency control can also be achieved using conditional HTTP

methods, but that doesn't mean that they don't make sense in the patch

format as well.



Best regards, Julian

_______________________________________________

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


--Boundary_(ID_3byUGIe21Z7jU4mPqwgyLg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT











Hi, All


 


I think test would make it complicated. The test could result in <, >, <=, >=, = conditions.


 


If we want something like HTTP If-Match mechanism, I would think it should not be in the JSON patch. We should keep JSON patch simple. The status
 code is better to be delivered in the protocol layer who delivers the JSON patch document.



 


Cheers,


Linyi


 




From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of mike amundsen

Sent: Thursday, December 01, 2011 1:27 AM

To: Paul C. Bryan

Cc: IETF Apps Discuss

Subject: Re: [apps-discuss] JSON patch: "test" operation




 


Julian:




 






Is the thinking that _clients_ should tell servers to test an insert/update?  IOW, clients would want to see test results?  A "dry run" scenario?






 






Also, was there any talk about how servers would handle failed tests (HTTP Response code, etc.)? If one or more tests fail, would the server have the option of making the changes and then returning a list of success/fail
 information? 






 








mca

http://amundsen.com/blog/

http://twitter.com@mamund

http://mamund.com/foaf.rdf#me












On Wed, Nov 30, 2011 at 12:09, Paul C. Bryan <paul.bryan@forgerock.com> wrote:




Yes, assert/equals/test has been mentioned in the past. As you point out, HTTP preconditions to handle this to some extent. I've avoided adding it thus far mostly because I haven't had a single concrete use case outside
 of HTTP. Given at least the pattern of multiple requests wanting to test a value for equality, I think I have enough data to add it to the next revision of the spec. Consider it added.



Paul 








On Wed, 2011-11-30 at 16:22 +0100, Julian Reschke wrote: 


Hi,


 


this came up during discussions of patch formats on the Apache 


jackrabbit-dev mailing list:


 


Would it make sense to add a "test" operation that allows checking the 


state of the JSON object to be modified?


 


It would be consistent with other diff formats that use context 


information in order to check whether the patch "cleanly applies".


 


An example would be:


 


    [


          { "test": "/vsn", "value" : 17 },


          { "replace": "/vsn", "value" : 18 },


          { "replace": "/balance", "value": 1234 }


    ]


 


And yes, concurrency control can also be achieved using conditional HTTP 


methods, but that doesn't mean that they don't make sense in the patch 


format as well.


 


Best regards, Julian


_______________________________________________


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




 








--Boundary_(ID_3byUGIe21Z7jU4mPqwgyLg)--