From stpeter@stpeter.im Tue Jun 1 13:01:33 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301663A67FB for ; Tue, 1 Jun 2010 13:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUZPrkHA47Iz for ; Tue, 1 Jun 2010 13:01:32 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3810E3A6A69 for ; Tue, 1 Jun 2010 13:01:32 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CBC9940E16 for ; Tue, 1 Jun 2010 14:01:19 -0600 (MDT) Message-ID: <4C05670E.9040103@stpeter.im> Date: Tue, 01 Jun 2010 14:01:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: Fwd: RFC 5854 on The Metalink Download Description Format X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030402080109040001040307" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 20:01:33 -0000 This is a cryptographically signed message in MIME format. --------------ms030402080109040001040307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI. -------- Original Message -------- Subject: RFC 5854 on The Metalink Download Description Format Date: Tue, 1 Jun 2010 12:38:32 -0700 (PDT) From: rfc-editor@rfc-editor.org 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 5854 Title: The Metalink Download Description Format Author: A. Bryan, T. Tsujikawa, N. McNab, P. Poeml Status: Standards Track Stream: IETF Date: June 2010 Mailbox: anthonybryan@gmail.com, tatsuhiro.t@gmail.com, neil@nabber.org, peter@poeml.de Pages: 39 Characters: 72641 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-bryan-metalink-28.txt URL: http://www.rfc-editor.org/rfc/rfc5854.txt This document specifies Metalink, an XML-based download description format. Metalink describes download locations (mirrors), cryptographic hashes, and other information. Clients can transparently use this information to reliably transfer files. [STANDARDS TRACK] 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 suggestio= ns 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.htm= l. 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------ms030402080109040001040307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMTIwMDExOFowIwYJKoZIhvcNAQkEMRYEFENf7dERaGQXgHLNpqdQ Lv2VtiurMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAAsWr1C3ag90P19UotqToM1b/Qn+8OjoEjBKI1SuX DrI5eNnJRkm4moVfCT8a4ro6PgFlC6akauOkPMVoS05eZiPCwrd7xTYyjTCVHth29X6/cmkP VG7gA0fcH5o2D9wTph42vfvjw6/g2e4mLC0ipzcH0O0zRrRJF2Yy/8+LSVJhbdwrNhS7fxW5 9GqOcYQxm8/58kTKZD+UfpU7PkzsCav4YCnZ6xBfGPDf8zZmaiqWaHPlhEpgQqHd1Q19yRW8 +jAhSDvMKVnyh6kmh4JPS1dbDj/9dqF8Beew+5c8N9+ysVJG4KF2zquhFJbkBHeU7eTExlOo 8OlE88h9lv3hpQAAAAAAAA== --------------ms030402080109040001040307-- From stpeter@stpeter.im Wed Jun 2 07:12:04 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5C13A67E5; Wed, 2 Jun 2010 07:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7m2KiZ2I2MG; Wed, 2 Jun 2010 07:12:00 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0BD153A6883; Wed, 2 Jun 2010 07:12:00 -0700 (PDT) Received: from squire.local (dsl-251-206.dynamic-dsl.frii.net [216.17.251.206]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 320D440E14; Wed, 2 Jun 2010 08:11:46 -0600 (MDT) Message-ID: <4C0666A1.8070308@stpeter.im> Date: Wed, 02 Jun 2010 08:11:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: HTTP Application Security (HAS) BoF X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080102010707040804060601" X-Mailman-Approved-At: Wed, 02 Jun 2010 07:12:53 -0700 Cc: "hybi@ietf.org" , "Adam Barth \(abarth@eecs.berkeley.edu\)" , Discuss HTTP State Management Mechanism , Collin Jackson , Andy Steingruebl , Hannes Tschofenig , =JeffH , Brandon Sterne , Sid Stamm , "ietf-http-wg@w3.org Group" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 14:12:05 -0000 This is a cryptographically signed message in MIME format. --------------ms080102010707040804060601 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've received a proposal to hold a birds of a feather (BoF) session at IETF 78 in Maastricht on the topic of HTTP Application Security. A draft charter and agenda can be found below. Please discuss on the apps-discuss@ietf.org list: https://www.ietf.org/mailman/listinfo/apps-discuss /psa ### Charter for HTTP Application Security (HAS) WG Problem Statement Although modern Web applications are built on top of HTTP, they provide rich functionality and have requirements beyond the original vision of static web pages. HTTP, and the applications built on it, have evolved organically. Over the past few years, we have seen a proliferation of AJAX-based web applications (AJAX being shorthand for asynchronous JavaScript and XML), as well as Rich Internet Applications (RIAs), based on so-called Web 2.0 technologies. These applications bring both luscious eye-candy and convenient functionality, e.g. social networking, to their users, making them quite compelling. At the same time, we are seeing an increase in attacks against these applications and their underlying technologies. The list of attacks is long and includes Cross-Site-Request Forgery (CSRF)-based attacks, content-sniffing cross-site-scripting (XSS) attacks, attacks against browsers supporting anti-XSS policies, clickjacking attacks, malvertising attacks, as well as man-in-the-middle (MITM) attacks against "secure" (e.g. Transport Layer Security (TLS/SSL)-based) web sites along with distribution of the tools to carry out such attacks (e.g. sslstrip). Objectives With the arrival of new attacks the introduction of new web security indicators, security techniques, and policy communication mechanisms have sprinkled throughout the various layers of the Web and HTTP. The goal of this working group is to standardize a small number of selected specifications that have proven to improve security of Internet Web applications. The requirements guiding the work will be taken from the Web application and Web security communities. Initial work will be limited to the following topics: - Media type sniffing, as discussed in draft-abarth-mime-sniff - Same origin policy, as discussed in draft-abarth-origin (expired) - Strict transport security, as discussed in draft-hodges-stricttransportsec (to be submitted shortly) This working group will work closely with IETF Apps Area WGs (such as HYBI, HTTPstate, and HTTPbis), as well as W3C WebApps working group(s). Deliverables 1. A document illustrating the security problems Web applications are facing and listing design requirements. This document shall be Informational. 2. A selected set of technical specifications documenting deployed HTTP-based Web security solutions. These documents shall be Standards Track. Goals and Milestones Oct 2010 Submit "HTTP Application Security Problem Statement and Requirements" as initial WG item. Oct 2010 Submit "Media Type Sniffing" as initial WG item. Oct 2010 Submit "Web Origin Concept" as initial WG item. Oct 2010 Submit "Strict Transport Security" as initial WG item. Feb 2011 Submit "HTTP Application Security Problem Statement and Requirements" to the IESG for consideration as an Informational RFC. Mar 2011 Submit "Media Type Sniffing" to the IESG for consideration as a Standards Track RFC. Mar 2011 Submit "Web Origin Concept" to the IESG for consideration as a Standards Track RFC. Mar 2011 Submit "Strict Transport Security" to the IESG for consideration as a Standards Track RFC. Apr 2011 Possible re-chartering ### Agenda for HTTP Application Security (HAS) BoF, IETF 78 Chairs: Hannes Tschofenig and Jeff Hodges (to be finalized) 5 min Agenda bashing (Chairs) 10 min Description of the problem space (TBD) 20 min Motivation for standardizing (TBD) draft-abarth-mime-sniff draft-abarth-origin draft-hodges-stricttransportsec 15 min Presentation of charter text (TBD) 60 min Discussion of charter text and choice of the initial specifications (All) 10 min Conclusion (Chairs/ADs) ### --------------ms080102010707040804060601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMjE0MTE0NVowIwYJKoZIhvcNAQkEMRYEFCDFNIm05EDtj+Eu1Qm2 6dJr28h8MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAh14U4eZpKUdQ3pmdnozUdrktDY9IuING8Qd0GZu9 691oswbUNV7I+y/77uoJg9vYmSRrm0gqR9Nl2fD+Ssgw74Jf/wTTV5b8LwcZdGVIlhXFo7TO axkisffomLGeJISHUinO0BLCDy+GqP2WH10n+TdkRvgHJAYckFV91/TycjwHhpclmueWxUL3 e3MaCsi7Q4lR6nZwKdinbjmGt752obsYAqSArrPBXkh49XLPqHVQG8X/ZV8LHynmt+O2AzyC QnlB6xJ+4lKQcicTVG7uYooQFb3LRQTQka7f20i5qnLMQ7bT+gvfYQwSDzVb4cXjC32gIMCQ DcWF9MOSi8ZKOgAAAAAAAA== --------------ms080102010707040804060601-- From ted.ietf@gmail.com Wed Jun 2 12:14:35 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2322E3A6A36 for ; Wed, 2 Jun 2010 12:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 545k5Z-v7UGw for ; Wed, 2 Jun 2010 12:14:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id AB62A3A6A33 for ; Wed, 2 Jun 2010 12:14:29 -0700 (PDT) Received: by vws11 with SMTP id 11so3022000vws.31 for ; Wed, 02 Jun 2010 12:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=qvW/BUbZl0KjL+5EM+7aiBTftC1G3YlKohtp4rbGfrQ=; b=ul/vzhaBPzwC3kfDBmmvWOSoW3P8uwqymlzrPTrxJ7gtk9Ikrxpa4yH2RJq5V5GySr RzRkMRVFqyp1/hU0yt09zNC+Q4pIkcY2hQrA+8a42epEOOh/b8NCXOOfOPg37K+4rqR5 87ltI2HFPyqkx/lDse1p9aSkX/CF0AppAY4a8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=p71YPvTD2T9GaME9WVdIBp5+fVt7KCSPW6wDYR7m2dV+YPryzqFKtqksSwEEFzVE95 Gdo1hY/M4Xq7Iq2PtaUlruj1wQ3UcMsNRdlnJqTCQm+l390FgmxEgSz5gJo1krPDeYQR tvAfpgmW+ZTjgYYDfYZuWbk0SRbOvEjMGQXys= MIME-Version: 1.0 Received: by 10.220.62.135 with SMTP id x7mr5992182vch.147.1275506054238; Wed, 02 Jun 2010 12:14:14 -0700 (PDT) Received: by 10.220.102.130 with HTTP; Wed, 2 Jun 2010 12:14:14 -0700 (PDT) Date: Wed, 2 Jun 2010 12:14:14 -0700 Message-ID: Subject: HTTP 30x response code for bulk redirect From: Ted Hardie To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 19:14:35 -0000 In discussions on the namedroppers list a side-issue on HTTP redirection has cropped up. The core of the question is how to support redirection for a flock of resources that are all being redirected. Client requests http://foo.example/resource1, gets a redirect to http://bar.example/resource1 and so on for resource1-resource51. My faulty memory is telling me that a 30x that said "This resources and all other resources at this host have moved" was not done earlier for security reasons--why allow someone controlling http://foo.example/resource1 to say anything about http://foo.example/resource2, since they might be associated with a different entity (http://foo.example/~user1 and http://foo.example/~user2 being the classic example). Is there more to this, or is there a way around the security issue using something like a policy in .well-known? E.g. allow a new 30x on a full-host basis, provided a policy in .well-known permitted it? regards, Ted From cyrus@daboo.name Wed Jun 2 12:37:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049F628C127 for ; Wed, 2 Jun 2010 12:37:28 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPMK94RgCAWJ for ; Wed, 2 Jun 2010 12:37:27 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id DD7D828C11B for ; Wed, 2 Jun 2010 12:37:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4699E16CBAFA5; Wed, 2 Jun 2010 15:37:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So-N5asPepzH; Wed, 2 Jun 2010 15:37:13 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 19AB116CBAF9A; Wed, 2 Jun 2010 15:37:11 -0400 (EDT) Date: Wed, 02 Jun 2010 15:37:08 -0400 From: Cyrus Daboo To: Ted Hardie , Apps Discuss Subject: Re: HTTP 30x response code for bulk redirect Message-ID: In-Reply-To: References: 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=1487 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 19:37:28 -0000 Hi Ted, --On June 2, 2010 12:14:14 PM -0700 Ted Hardie wrote: > In discussions on the namedroppers list a side-issue on HTTP > redirection has cropped up. > The core of the question is how to support redirection for a flock of > resources that are all > being redirected. Client requests http://foo.example/resource1, gets a > redirect to > http://bar.example/resource1 and so on for resource1-resource51. My > faulty memory > is telling me that a 30x that said "This resources and all other > resources at this host > have moved" was not done earlier for security reasons--why allow > someone controlling > http://foo.example/resource1 to say anything about > http://foo.example/resource2, since they might be associated with a > different entity > (http://foo.example/~user1 > and http://foo.example/~user2 being the classic example). Is there > more to this, > or is there a way around the security issue using something like a > policy in .well-known? > E.g. allow a new 30x on a full-host basis, provided a policy in > .well-known permitted it? There is also a similar issue with child resources (collections in WebDAV). Can a client assume that a redirect for /resource1, also applies to /resource1/child1? This has come up in the context of CalDAV where a client needs to be told that a user's calendar-home (containing all their calendars) previously located in one place has moved to another (including moved to another server). -- Cyrus Daboo From eran@hueniverse.com Wed Jun 2 13:23:42 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9429128C177 for ; Wed, 2 Jun 2010 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWVU2tHXs-0N for ; Wed, 2 Jun 2010 13:23:41 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9D8A228C11B for ; Wed, 2 Jun 2010 13:23:35 -0700 (PDT) Received: (qmail 16924 invoked from network); 2 Jun 2010 20:23:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Jun 2010 20:23:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 2 Jun 2010 13:23:20 -0700 From: Eran Hammer-Lahav To: Ted Hardie , Apps Discuss Date: Wed, 2 Jun 2010 13:23:15 -0700 Subject: Re: HTTP 30x response code for bulk redirect Thread-Topic: HTTP 30x response code for bulk redirect Thread-Index: AcsCh9HTxFX8sqHbT62cng6Vvx8/kwACZw6A Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C82C0BC334F9Feranhueniversecom_" MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 20:23:42 -0000 --_000_C82C0BC334F9Feranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You can host-meta with a special redirection relation type and a template t= o express this. The tricky part is how to tie it to the HTTP response. EHL On 6/2/10 12:14 PM, "Ted Hardie" wrote: In discussions on the namedroppers list a side-issue on HTTP redirection has cropped up. The core of the question is how to support redirection for a flock of resources that are all being redirected. Client requests http://foo.example/resource1, gets a redirect to http://bar.example/resource1 and so on for resource1-resource51. My faulty memory is telling me that a 30x that said "This resources and all other resources at this host have moved" was not done earlier for security reasons--why allow someone controlling http://foo.example/resource1 to say anything about http://foo.example/resou= rce2, since they might be associated with a different entity (http://foo.example/~user1 and http://foo.example/~user2 being the classic example). Is there more to this, or is there a way around the security issue using something like a policy in .well-known? E.g. allow a new 30x on a full-host basis, provided a policy in .well-known permitted it? regards, Ted _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_C82C0BC334F9Feranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: HTTP 30x response code for bulk redirect You can host-meta with a special redirection relation type and a temp= late to express this. The tricky part is how to tie it to the HTTP response= .

EHL


On 6/2/10 12:14 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:

In discussions on the namedroppers list a s= ide-issue on HTTP
redirection has cropped up.
The core of the question is how to support redirection for a flock of
resources that are all
being redirected. Client requests = http://foo.example/resource1, gets a
redirect to
http://bar.example/resource1 a= nd so on for resource1-resource51.   My
faulty memory
is telling me that a 30x that said "This resources and all other
resources at this host
have moved" was not done earlier for security reasons--why allow
someone controlling
http://foo.example/resource1 t= o say anything about http://foo.ex= ample/resource2,
since they might be associated with a different entity
(http://foo.example/~user1
and http://foo.example/~user2 bei= ng the classic example).  Is there
more to this,
or is there a way around the security issue using something like a
policy in .well-known?
E.g. allow a new 30x on a full-host basis, provided a policy in
.well-known permitted it?

regards,

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

--_000_C82C0BC334F9Feranhueniversecom_-- From stpeter@stpeter.im Thu Jun 3 09:24:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C681B3A6843 for ; Thu, 3 Jun 2010 09:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSK4rxZaWm+x for ; Thu, 3 Jun 2010 09:24:42 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AC15B3A6826 for ; Thu, 3 Jun 2010 09:24:42 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F0A2740E4D for ; Thu, 3 Jun 2010 10:24:28 -0600 (MDT) Message-ID: <4C07D73A.3090301@stpeter.im> Date: Thu, 03 Jun 2010 10:24:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: AD nits X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050201050701040706010400" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 16:24:43 -0000 This is a cryptographically signed message in MIME format. --------------ms050201050701040706010400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alexey and I have been working on a set of "AD nits" that come up again and again during our IESG reviews of various Internet-Drafts. We'd welcome feedback from folks in the Applications Area. You can find the list here: http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050201050701040706010400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMzE2MjQyNlowIwYJKoZIhvcNAQkEMRYEFMRSc26JbLZEcDrf+NxD JXBpX+UWMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAB9LzG1q0ykhLvy8yP38c8KeWjUYJeiGeXJTeelEK 35eXq8AfPa0Hd+np9i2jCY1jJlmzIVoukBYFANNO+NtuYte/JqG3vMbUqv8fUHQ4MXHiJ3ww C6dgnpGLE76FhYwVI7VynbevgK/VmvOINDWkkiEw60cSgW0Xloc+Z4PVWIdS1se+l5v8Tdcx cVqV62sye09i3kWj9GpmoA+0CWVXRUsRUe/TWD//pGfCOBKcl2SgYJVHSYK72OJ3UtJEPvfl koPQHuc5L+CUofVS+KRICZJTGEm2pk+CMq8C6JbQ1Q4wbo27V/3cQsOcKL7JvTSrp/xTkHc2 TrpXBbfTQgyWIAAAAAAAAA== --------------ms050201050701040706010400-- From julian.reschke@gmx.de Thu Jun 3 10:23:39 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEEDC3A69E4 for ; Thu, 3 Jun 2010 10:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=-2.391, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaHEwJewvCRw for ; Thu, 3 Jun 2010 10:23:36 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BF5383A6892 for ; Thu, 3 Jun 2010 10:23:35 -0700 (PDT) Received: (qmail invoked by alias); 03 Jun 2010 17:23:21 -0000 Received: from p508FC31F.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.195.31] by mail.gmx.net (mp027) with SMTP; 03 Jun 2010 19:23:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18wSrJRPLMwikPW1CgdlFkyssUOMFbxx01mlSINYq wVo6yfxNbKLRce Message-ID: <4C07E4FB.3090800@gmx.de> Date: Thu, 03 Jun 2010 19:23:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: HTTP 30x response code for bulk redirect References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 17:23:39 -0000 On 02.06.2010 21:37, Cyrus Daboo wrote: > ... > There is also a similar issue with child resources (collections in > WebDAV). Can a client assume that a redirect for /resource1, also > applies to /resource1/child1? This has come up in the context of CalDAV > where a client needs to be told that a user's calendar-home (containing > all their calendars) previously located in one place has moved to > another (including moved to another server). > ... If /resource1 previously identified WebDAV collection, then it would be a safe assumption that all member resources (recursively) have moved as well. Best regards, Julian From stpeter@stpeter.im Thu Jun 3 11:14:35 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2E928C122 for ; Thu, 3 Jun 2010 11:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YUjFzs60MvO for ; Thu, 3 Jun 2010 11:14:33 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 464633A6781 for ; Thu, 3 Jun 2010 11:14:28 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1B7ED40E14 for ; Thu, 3 Jun 2010 12:14:15 -0600 (MDT) Message-ID: <4C07F0F5.9010708@stpeter.im> Date: Thu, 03 Jun 2010 12:14:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: Re: HTTP Application Security (HAS) BoF References: <4C0666A1.8070308@stpeter.im> In-Reply-To: <4C0666A1.8070308@stpeter.im> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050306030606010508060404" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 18:14:35 -0000 This is a cryptographically signed message in MIME format. --------------ms050306030606010508060404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We now have a dedicated list for this BoF: https://www.ietf.org/mailman/listinfo/hasmat Please discuss further on that list. I'll be blasting various lists and individuals regarding the BoF. On 6/2/10 8:11 AM, Peter Saint-Andre wrote: > I've received a proposal to hold a birds of a feather (BoF) session at > IETF 78 in Maastricht on the topic of HTTP Application Security. A > draft charter and agenda can be found below. Please discuss on the > apps-discuss@ietf.org list: >=20 > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > /psa >=20 > ### >=20 > Charter for HTTP Application Security (HAS) WG >=20 > Problem Statement >=20 > Although modern Web applications are built on top of HTTP, they provide= > rich functionality and have requirements beyond the original vision of > static web pages. HTTP, and the applications built on it, have evolved= > organically. Over the past few years, we have seen a proliferation of > AJAX-based web applications (AJAX being shorthand for asynchronous > JavaScript and XML), as well as Rich Internet Applications (RIAs), base= d > on so-called Web 2.0 technologies. These applications bring both > luscious eye-candy and convenient functionality, e.g. social networking= , > to their users, making them quite compelling. At the same time, we are= > seeing an increase in attacks against these applications and their > underlying technologies. >=20 > The list of attacks is long and includes Cross-Site-Request Forgery > (CSRF)-based attacks, content-sniffing cross-site-scripting (XSS) > attacks, attacks against browsers supporting anti-XSS policies, > clickjacking attacks, malvertising attacks, as well as man-in-the-middl= e > (MITM) attacks against "secure" (e.g. Transport Layer Security > (TLS/SSL)-based) web sites along with distribution of the tools to carr= y > out such attacks (e.g. sslstrip). >=20 > Objectives >=20 > With the arrival of new attacks the introduction of new web security > indicators, security techniques, and policy communication mechanisms > have sprinkled throughout the various layers of the Web and HTTP. >=20 > The goal of this working group is to standardize a small number of > selected specifications that have proven to improve security of Interne= t > Web applications. The requirements guiding the work will be taken from > the Web application and Web security communities. Initial work will be= > limited to the following topics: >=20 > - Media type sniffing, as discussed in draft-abarth-mime-sniff > - Same origin policy, as discussed in draft-abarth-origin (expired) > - Strict transport security, as discussed in > draft-hodges-stricttransportsec (to be submitted shortly) >=20 > This working group will work closely with IETF Apps Area WGs (such as > HYBI, HTTPstate, and HTTPbis), as well as W3C WebApps working group(s).= >=20 > Deliverables >=20 > 1. A document illustrating the security problems Web applications are > facing and listing design requirements. This document shall be > Informational. >=20 > 2. A selected set of technical specifications documenting deployed > HTTP-based Web security solutions. > These documents shall be Standards Track. >=20 > Goals and Milestones >=20 > Oct 2010 Submit "HTTP Application Security Problem Statement and > Requirements" as initial WG item. > Oct 2010 Submit "Media Type Sniffing" as initial WG item. > Oct 2010 Submit "Web Origin Concept" as initial WG item. > Oct 2010 Submit "Strict Transport Security" as initial WG item. > Feb 2011 Submit "HTTP Application Security Problem Statement and > Requirements" to the IESG for consideration as an > Informational RFC. > Mar 2011 Submit "Media Type Sniffing" to the IESG for consideration > as a Standards Track RFC. > Mar 2011 Submit "Web Origin Concept" to the IESG for consideration a= s > a Standards Track RFC. > Mar 2011 Submit "Strict Transport Security" to the IESG for > consideration as a Standards Track RFC. > Apr 2011 Possible re-chartering >=20 > ### >=20 > Agenda for HTTP Application Security (HAS) BoF, IETF 78 >=20 > Chairs: Hannes Tschofenig and Jeff Hodges (to be finalized) >=20 > 5 min Agenda bashing (Chairs) >=20 > 10 min Description of the problem space (TBD) >=20 > 20 min Motivation for standardizing (TBD) > draft-abarth-mime-sniff > draft-abarth-origin > draft-hodges-stricttransportsec >=20 > 15 min Presentation of charter text (TBD) >=20 > 60 min Discussion of charter text and choice of the initial > specifications (All) >=20 > 10 min Conclusion (Chairs/ADs) >=20 > ### >=20 >=20 --------------ms050306030606010508060404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMzE4MTQxM1owIwYJKoZIhvcNAQkEMRYEFFpilcIP+CAd7r9srDae AyWKZJ/yMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAUgJjHvPKExGGz59JTayBELKLChorMZg89+WV1W86 DRLFOr3kDNYSHpibUw5f5Y5eC00YOd7l2TrnVc8PSvLXLrmSc1yB/5M7u7AYbBsO20gal5Ty cbP7Rb36G4Ez1dKapgLsgbwyU6ps8YSrmo3pPTY71GsY4omEh0aW3M4uta6TOh+9vWa7isXc 47ZLe7D/prhES16zJCbSBocFaSHKqcA1LqOqOFg1Fwgbiqo35EHWXoYyPBCTvOI5FZqxEvRx dL88WhfqTB893+lWcnUo+S8/hid+XVfikF+PDOGtLK/UDj1E4YFUc9Nx/79gROh/69MKvMNL Z5yGuPeF37xpogAAAAAAAA== --------------ms050306030606010508060404-- From marc.blanchet@viagenie.ca Thu Jun 3 12:02:33 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6013A67A4 for ; Thu, 3 Jun 2010 12:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zlj+FLcERcsW for ; Thu, 3 Jun 2010 12:02:32 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by core3.amsl.com (Postfix) with ESMTP id A28F428C117 for ; Thu, 3 Jun 2010 12:02:31 -0700 (PDT) Received: from mbl.lan (modemcable144.164-201-24.mc.videotron.ca [24.201.164.144]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 532B820D1B for ; Thu, 3 Jun 2010 15:02:18 -0400 (EDT) Message-ID: <4C07FC39.6060702@viagenie.ca> Date: Thu, 03 Jun 2010 15:02:17 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: AD nits References: <4C07D73A.3090301@stpeter.im> In-Reply-To: <4C07D73A.3090301@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 19:02:33 -0000 Le 10-06-03 12:24, Peter Saint-Andre a écrit : > Alexey and I have been working on a set of "AD nits" that come up again > and again during our IESG reviews of various Internet-Drafts. We'd > welcome feedback from folks in the Applications Area. You can find the > list here: > > http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues > interesting and good idea. no comment/info on the stringprep/nameprep/newprep needs for protocol identifiers? ie. should I care about this and if yes, what should I do. Marc. > Thanks! > > Peter > > > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From barryleiba.mailing.lists@gmail.com Thu Jun 3 13:54:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780973A6A29 for ; Thu, 3 Jun 2010 13:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=-1.441, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCUFqebAdLoT for ; Thu, 3 Jun 2010 13:54:19 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 317983A6A14 for ; Thu, 3 Jun 2010 13:54:19 -0700 (PDT) Received: by fxm6 with SMTP id 6so417769fxm.31 for ; Thu, 03 Jun 2010 13:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=NlatwEh12kjOir6d+qaioJOZAan22Fj5p2AkT2mE8E4=; b=K5YwzFO3vHHYdT8top+KlYvMim7cII6/zo2HEXseTs8cB6CWaDsFNfrKsXmaGhIgEr fdsGLs5jOOdBvFOpSvEehbAgUkJJKAlLa8SlgylkJLDk09e1wtAM1sXdRHMQENNgTOj7 dTlA0BrIHnXd13jzksulDjCYGKTWvUD+ZuCAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=M628tJ/8EPZtmpZyOftdCcLecddrZ/8kPXXEeB7yiJxWXzP4uGDduvNA+ZnsKzzZlw NacZgBhebTeCrdpDMAh+EQOPCR5XMi+d0LEWVVXw663A6yclVCIvWwqV/vjKSXv8h+1P xr4ue4fBmI2zXrADjwJp7+Rhbuyq5YjlKT3aA= MIME-Version: 1.0 Received: by 10.223.18.154 with SMTP id w26mr10900025faa.39.1275598440086; Thu, 03 Jun 2010 13:54:00 -0700 (PDT) Received: by 10.223.122.141 with HTTP; Thu, 3 Jun 2010 13:54:00 -0700 (PDT) In-Reply-To: <4C07D73A.3090301@stpeter.im> References: <4C07D73A.3090301@stpeter.im> Date: Thu, 3 Jun 2010 16:54:00 -0400 Message-ID: Subject: Re: AD nits From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 20:54:20 -0000 > http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues In "Dates and Times", we should probably say more about time zones, particularly time-zone names. vCards have an issue with how to name time zones, which prompted this now-expired draft: https://datatracker.ietf.org/doc/draft-leiba-tzregistry/ More recently, Cyrus had tried to kick something off, which is why I abandoned the tzregistry draft, but I can't find a reference to it. Barry From stpeter@stpeter.im Thu Jun 3 16:25:47 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14FC43A67FB for ; Thu, 3 Jun 2010 16:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8PoFb3CXv3x for ; Thu, 3 Jun 2010 16:25:45 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D65203A67ED for ; Thu, 3 Jun 2010 16:25:44 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 27E2140E26 for ; Thu, 3 Jun 2010 17:25:31 -0600 (MDT) Message-ID: <4C0839E9.6030609@stpeter.im> Date: Thu, 03 Jun 2010 17:25:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: Peter's Apps Report #2 X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010702000504080304010109" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 23:25:47 -0000 This is a cryptographically signed message in MIME format. --------------ms010702000504080304010109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is my second report as Applications Area AD. This report covers May 7 through June 3, 2010. 1. WORKING GROUP STATUS ALTO Application-Layer Traffic Optimization http://tools.ietf.org/wg/alto/ A new version of draft-ietf-alto-protocol was published on May 31: https://datatracker.ietf.org/doc/draft-ietf-alto-protocol/ The ALTO WG will hold a virtual interim meeting on June 16, 2010. See http://www.ietf.org/mail-archive/web/alto/current/msg00659.html for details, and send your agenda requests to Enrico Marocco. CALSIFY Calendaring and Scheduling Standards Simplification http://tools.ietf.org/wg/calsify/ The only remaining work item is the iMIP draft, edited by Alexey Melnikov= : https://datatracker.ietf.org/doc/draft-ietf-calsify-rfc2447bis/ I completed an AD review of that spec on May 12: http://lists.osafoundation.org/pipermail/ietf-calsify/2010-May/002245.htm= l When Alexey returns from his current holidays I'll ping him and chair Eliot Lear about moving the I-D forward so that we can close down the WG in the relatively near future. CORE Constrained RESTful Environments http://tools.ietf.org/wg/core/ An update was made to one of the key I-Ds under consideration: https://datatracker.ietf.org/doc/draft-shelby-core-coap/ On May 8, WG co-chair Carsten Bormann put out a call for accepting that document as the initial version of a WG item, leading to much discussion:= http://www.ietf.org/mail-archive/web/core/current/msg00139.html It's unclear whether there was consensus to accept that document as a WG item (the disussion quickly widened into more fundamental issues), so I'll ping the CORE chairs about that soon. The group has also had active list discussion about TCP vs. UDP, subscribe/notify methods, and security. HTTPSTATE HTTP State Management Mechanism http://tools.ietf.org/wg/httpstate/ On May 11, WG chair Jeff Hodges issued a last call for comments within the WG on draft-ietf-httpstate-cookie: https://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ The WGLC call has led to quite a bit of productive feedback on the list, so hopefully Adam Barth will be able to incorporate it all into that I-D in the near future. IRI Internationalized Resource Identifiers http://tools.ietf.org/wg/iri/ Addison Philipps has graciously agreed to replace Ted Hardie as co-chair (along with Marc Blanchet). I'm expecting faster progress in the near future, because I know that everyone interested in this work would like it to proceed with all due speed. :) OAUTH Open Authentication Protocol http://tools.ietf.org/wg/oauth/ The OAuth WG held a productive interim meeting in Mountain View, CA on May 20 (thanks to Yahoo for hosting). About 40 people attended (by my count), and we went over the core spec in great detail: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ In fact we filled a huge whiteboard with spec issues, which the chairs and document author are sifting through even as we speak. The list has been busy, as well. Despite a bit of a rocky start, this WG is making good progress and I'm looking forward to the next few versions of the spe= c. VCARDDAV vCard and CardDAV http://tools.ietf.org/wg/vcarddav/ More WG last calls, this time issued by co-chair Marc Blanchet on May 18:= http://www.ietf.org/mail-archive/web/vcarddav/current/msg01490.html This WGLC covers both draft-ietf-vcarddav-vcardrev (vCard 4.0) and draft-ietf-vcarddav-vcardxml (the XML representation of vCard): https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardrev/ https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardxml/ As expected, last call feedback has been pouring in. It's good to see that folks still care about vCards. :) Once this work is done, the group will have a conversation about shutting down or, potentially, recharting. VWRAP Virtual World Region Agent Protocol http://tools.ietf.org/wg/vwrap/ This group does not yet have any official WG items, but co-chair Barry Leiba has started a conversation about changing that by asking for feedback about moving startup documents (various individual drafts) into the working group: http://www.ietf.org/mail-archive/web/vwrap/current/msg00149.html Hopefully one or more of the individual drafts will be accepted as working group documents in the near future so that they can receive proper treatment (consensus calls and the like) in preparation for submission to the IESG. 2. WG FORMATION & BOFS NEWPREP (Stringprep after IDNA2008) After a successful BoF at IETF 77, the "newprep" WG is close to being established. I need to coordinate with Alexey on a few, small issues before the group is officially formed, but the IESG has approved it. URNBIS (updates to Uniform Resource Names) The IESG has approved a BoF at IETF 78 on potential updates to the core specs for Uniform Resource Names (URNs). A proposed charter has been under discussion on the urn@ietf.org list, and there are several relevant individual drafts to consider: https://datatracker.ietf.org/doc/draft-ah-rfc2141bis-urn/ https://datatracker.ietf.org/doc/draft-hakala-rfc3187bis-isbn-urn/ https://datatracker.ietf.org/doc/draft-hakala-rfc3188bis-nbn-urn/ Sign up at https://www.ietf.org/mailman/listinfo/urn if you wish to participate in these conversations. HASMAT (HTTP Application Security Minus Authentication and Transport) Two weeks ago at the Internet Identity Workshop and OAuth WG interim meeting, I got to talking with IAB member Hannes Tschofenig about a possible BoF on web security. I quickly made arrangements to drive from Mountain View to Oakland after the OAuth meeting so that I could have dinner with Thomas Roessler of the W3C, HTTPSTATE chair Jeff Hodges, and several other interested parties who were at the Web 2.0 Security and Privacy conference. Hannes, Jeff, Thomas, and I banged out a proposed charter in the days that followed, and it, too, was approved by the IESG in the June 3 telechat. The basic focus for the BoF is discussion of several security topics related to web applications, especially same origin policy, MIME content sniffing, and an HTTP header for enforcement of transport security. Additional topics will surely include a clearer division of responsibilities between the IETF and W3C on this important problem domain. I'll be actively working with Thomas, W3C liaison Mark Nottingham, and other relevant individuals leading up to the BoF. For more details, see the charter and join the mailing list: http://www.ietf.org/mail-archive/web/hasmat/current/msg00000.html https://www.ietf.org/mailman/listinfo/hasmat 3. INDIVIDUAL DRAFTS I'm watching the following documents: http://tools.ietf.org/html/draft-desruisseaux-ischedule (I still haven't made time to review this) http://tools.ietf.org/html/draft-giralt-schac-ns (authors pinged about a revised I-D) http://tools.ietf.org/html/draft-hammer-hostmeta (lots of discussion on the apps-discuss@ietf.org list, and several updates to the I-D) http://tools.ietf.org/html/draft-rosen-urn-nena (author pinged about a revised I-D) http://tools.ietf.org/html/draft-oiwa-http-mutualauth (slowly providing a review to the authors) 4. MY DRAFTS Just today, Jeff Hodges and I posted version -05 of our proposed BCP on server identities, which we're pushing to finish before IETF 78: https://datatracker.ietf.org/doc/draft-saintandre-tls-server-id-check/ I posted version -08 of draft-ietf-xmpp-3920bis on May 7, and XMPP WG co-chair Ben Campbell issued a WGLC on May 13. The WGLC has been extended to gather more feedback (the spec is 175 pages long!), but so far no major issues have cropped up. I'm still hoping this can be submitted to the IESG over the summer. https://datatracker.ietf.org/doc/draft-ietf-xmpp-3920bis/ Also in the XMPP WG, I am completing my final "editor's review" of draft-ietf-xmpp-3921bis ("only" ~100 pages long) and I expect to publish version -07 in the next week. https://datatracker.ietf.org/doc/draft-ietf-xmpp-3921bis/ Alexey and I have also been talking about publishing an I-D entitled "X- Considered Harmful" but I've not made much progress on that one yet. Finally, Richard Barnes and I plan to write an I-D defining a problem statement on what we're calling High Assurance Re-Direction ("HARD"). More on that in my next report. 5. IESG ACTIVITIES The IESG held its annual retreat on May 25-26 at my alma mater (Columbia University). It was good to get to know my fellow IESG members better, and to coordinate on a number of AppsArea topics with Alexey. Plus, a conversation with Gonzalo Camarillo sparked me to get serious about my personal productivity habits again; as a result, my processing of work items has already become more efficient. As usual I filed discusses and comments on a number of I-Ds under review by the IESG. You can see a complete list of discusses here: https://datatracker.ietf.org/iesg/discusses/ I'm working to clear my discusses faster (since they block forward progress on an I-D), so if I have any open discusses on a draft of yours feel free to ping me via email or IM for faster service. Did I mention that I'm interrupt-driven? 6. UPCOMING EVENTS The ALTO WG will hold a virtual interim meeting on June 16, 2010. See http://www.ietf.org/mail-archive/web/alto/current/msg00659.html for details, and send your agenda requests to Enrico Marocco. Preparation has started in earnest for IETF 78 in Maastricht, The Netherlands, July 25-30. Visit http://www.ietf.org/meeting/78/ for complete information. I'll be pinging chairs for the WGs I advise regarding agendas and such, as well as the now-traditional appsarea lunch= =2E Thanks for reading, see you next time! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010702000504080304010109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMzIzMjUyOVowIwYJKoZIhvcNAQkEMRYEFCBfRAl/24lNwDOgfO92 wUjpkwvYMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAYDaf/JwUr7nfhKck7QFW6wEgOCUMqi/BiqfZLrXs iSOtB9Q3SHtArSvAUV8TaoSqOPmsW0KGwpCzqyZjhsrDeHECPboZbn+N16SFD9a1f8bNKnoI NlWxD9+JAmy56ZmFqGeTqFfutIW2UgxMa7J4g93rQveAhWqeeMzoVeC96QxdAcK10GyJMedF P3SS+a2y/75JD9JlN0kTzfIQomkggSUsqjbGDTpsbpho5iZXw18Z9lwA1hgbTgDMtiSrTRIF g/9RGoQMlZqjRlWbBUWsNu0QiEedgT5GO5mezJT5hGWta7hEG8V/cULNyOr2ygdptKK0AvHh MHT4H5nbvp/VtQAAAAAAAA== --------------ms010702000504080304010109-- From marc.blanchet@viagenie.ca Thu Jun 3 16:45:30 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183673A680B for ; Thu, 3 Jun 2010 16:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG+XeJYjKT0R for ; Thu, 3 Jun 2010 16:45:28 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by core3.amsl.com (Postfix) with ESMTP id 7663D3A67AF for ; Thu, 3 Jun 2010 16:45:28 -0700 (PDT) Received: from mbl.lan (modemcable144.164-201-24.mc.videotron.ca [24.201.164.144]) by jazz.viagenie.ca (Postfix) with ESMTPSA id F089E21B9D for ; Thu, 3 Jun 2010 19:45:14 -0400 (EDT) Message-ID: <4C083E8A.4020102@viagenie.ca> Date: Thu, 03 Jun 2010 19:45:14 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: vcardrev/xml wg last call (was: Peter's Apps Report #2) References: <4C0839E9.6030609@stpeter.im> In-Reply-To: <4C0839E9.6030609@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 23:45:30 -0000 using Peter's excellent report as a segway to ask the apps area to review the vcardrev and vcardxml drafts which are in WGLC (well, deadline is past, but the new versions of drafts are not yet out, so... Please review and comment (on vcarddav mailing list please): Marc, vcarddav co-chair. > VCARDDAV > vCard and CardDAV > http://tools.ietf.org/wg/vcarddav/ > > More WG last calls, this time issued by co-chair Marc Blanchet on May 18: > > http://www.ietf.org/mail-archive/web/vcarddav/current/msg01490.html > > This WGLC covers both draft-ietf-vcarddav-vcardrev (vCard 4.0) and > draft-ietf-vcarddav-vcardxml (the XML representation of vCard): > > https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardrev/ > > https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardxml/ > > As expected, last call feedback has been pouring in. It's good to see > that folks still care about vCards. :) > > Once this work is done, the group will have a conversation about > shutting down or, potentially, recharting. > > -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From Martin.Thomson@andrew.com Thu Jun 3 17:57:56 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E993A6880 for ; Thu, 3 Jun 2010 17:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKlSY986dQCU for ; Thu, 3 Jun 2010 17:57:53 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 0867D3A67F9 for ; Thu, 3 Jun 2010 17:57:52 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:64977 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S289249Ab0FDA5j (ORCPT ); Thu, 3 Jun 2010 19:57:39 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 3 Jun 2010 19:57:39 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 4 Jun 2010 08:57:36 +0800 From: "Thomson, Martin" To: Peter Saint-Andre , "apps-discuss@ietf.org" Date: Fri, 4 Jun 2010 08:59:25 +0800 Subject: RE: AD nits Thread-Topic: AD nits Thread-Index: AcsDOUH7JN5qbDB6RRuagDVZCouIKAAR4Afw Message-ID: <8B0A9FCBB9832F43971E38010638454F03E7F1F4C3@SISPE7MB1.commscope.com> References: <4C07D73A.3090301@stpeter.im> In-Reply-To: <4C07D73A.3090301@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 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 00:57:56 -0000 SFRUUDogIEJDUCA1NiBjb250YWlucyBzb21lIGdvb2QgYWR2aWNlLCBzb21lIGRhbmdlcm91cyBh ZHZpY2UuICBBZGVxdWF0ZSB3YXJuaW5nIHNpZ25zIGZvciB0aGUgdW5pbml0aWF0ZWQgbWlnaHQg aGVscC4NCg0KSSBrbm93IHRoYXQgTGlzYSBoYWQgc29tZSB1cGRhdGVkIGFkdmljZSBvbiB0aGUg dXNlIG9mIEhUVFAuICBNYXliZSB5b3UgY2FuIGdldCB5b3VyIGhhbmRzIG9uIHRoYXQgYW5kIHNo YXJlIGl0Lg0KDQotLU1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLQ0K PiBib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGV0ZXIgU2FpbnQtQW5kcmUNCj4gU2Vu dDogRnJpZGF5LCA0IEp1bmUgMjAxMCAyOjI0IEFNDQo+IFRvOiBhcHBzLWRpc2N1c3NAaWV0Zi5v cmcNCj4gU3ViamVjdDogQUQgbml0cw0KPiANCj4gQWxleGV5IGFuZCBJIGhhdmUgYmVlbiB3b3Jr aW5nIG9uIGEgc2V0IG9mICJBRCBuaXRzIiB0aGF0IGNvbWUgdXAgYWdhaW4NCj4gYW5kIGFnYWlu IGR1cmluZyBvdXIgSUVTRyByZXZpZXdzIG9mIHZhcmlvdXMgSW50ZXJuZXQtRHJhZnRzLiBXZSdk DQo+IHdlbGNvbWUgZmVlZGJhY2sgZnJvbSBmb2xrcyBpbiB0aGUgQXBwbGljYXRpb25zIEFyZWEu IFlvdSBjYW4gZmluZCB0aGUNCj4gbGlzdCBoZXJlOg0KPiANCj4gaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvVHlwaWNhbEFwcHNBcmVhSXNzdWVzDQo+IA0K PiBUaGFua3MhDQo+IA0KPiBQZXRlcg0KPiANCj4gLS0NCj4gUGV0ZXIgU2FpbnQtQW5kcmUNCj4g aHR0cHM6Ly9zdHBldGVyLmltLw0KPiANCj4gDQoNCg== From john-ietf@jck.com Thu Jun 3 18:31:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A573A6405 for ; Thu, 3 Jun 2010 18:31:51 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIhHDkMp09Bu for ; Thu, 3 Jun 2010 18:31:49 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id E8DF43A680D for ; Thu, 3 Jun 2010 18:31:48 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OKLkz-000HI0-O5; Thu, 03 Jun 2010 21:31:34 -0400 Date: Thu, 03 Jun 2010 21:31:32 -0400 From: John C Klensin To: Peter Saint-Andre , apps-discuss@ietf.org Subject: Re: AD nits Message-ID: <6765C175B8789B331C1F14C7@PST.JCK.COM> In-Reply-To: <4C07D73A.3090301@stpeter.im> References: <4C07D73A.3090301@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 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 01:31:51 -0000 --On Thursday, June 03, 2010 10:24 -0600 Peter Saint-Andre wrote: > Alexey and I have been working on a set of "AD nits" that come > up again and again during our IESG reviews of various > Internet-Drafts. We'd welcome feedback from folks in the > Applications Area. You can find the list here: > > http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAre > aIssues Peter, Nice start and a worthwhile effort. General observation: This document is a mixture of "issues we have found in reviewing documents" and "protocol design considerations". The latter overlap with other work (not necessarily a bad thing) but are issues that WGs should be dealing with lots earlier than submitting documents for review. If they aren't spotted and dealt with until the review process, someone or something is in big trouble, IMO. More specific observations: (1) The i18n stuff is pretty weak, IMO. I think that many of us have come to the conclusion that RFC 2277 (BCP 18) is badly outdated (not wrong, just inadequate) and that "use UTF-8" is not an adequate story. That is a lot of the reason RFC 5198 was done. It should be seen as a "be sure you are clear about this in designs and documents" spec rather than a "do this" one, but the issues are no less important. "Unicode normalization", which you have put into a separate subtopic, is really just one of those 5198 issues that 2277 does not address. Another important one is how Unicode is profiled wrt the characters that are acceptable for use in a given protocol: "use Unicode" is rarely a satisfactory answer, normalization doesn't cover all of the issues, and a decision to permit, e.g., symbols, line-drawing and other rendering characters, etc., is actually a pretty big deal. It gets to be an especially big deal if one starts including mechanisms for character input (whether a character can be typed given a given keyboard and input method mechanism) and so on... and protocol designers should probably be considering those issues. (2) I don't know quite what a "binary password" is, but, if that is actually what you mean, it doesn't belong under "Internationalization". On the other hand, if one is going to do localization of any sort, specifications should be clear about how one identifies locales and how one gets from one locale to another. (3) As a substantive point, RFC 2482 notwithstanding, recent versions of Unicode have very strongly discouraged the use of language tags. See TUS 5.x, Section 16.9. While TUS 5.0 identifies this section simply as "Tag Characters", it worth nothing that 5.2 goes so far as to rename it as "Deprecated Tag Characters" and the text has changed from "strongly discouraged" (in 5.0) to "deprecated, and should not be used" in 5.2. See http://www.unicode.org/versions/Unicode5.2.0/ch16.pdf for the latter. The conventional wisdom today (reinforced by the referenced sections of The Unicode Standard and other work) is that, if language/script tagging is needed embedded in text (i.e., not via out of band mechanisms like language or charset tagging in headers), the application should probably be using XML or some other markup context. I note that 2482 justifies itself largely on the basis of the needs of ACAP. ACAP is (sadly IMO) nearly dead these days; if we were to create a new protocol with the same functionality, I assume it would use some sort of XML schema which could, in turn, identify script or language elements as needed. Our experience of the last decade or so is that most, or all, protocols that "didn't have language tags originally" need rather careful rethinking, not some handwaving involving a story like "UTF-8 is just a superset of ASCII and we can use language tagging". Note, too, the TUS discussion about how infrequently language tagging is actually needed in Section 5.10 (see http://www.unicode.org/versions/Unicode5.2.0/ch05.pdf). While reasonable people might disagree with the conclusions there, one should at least carefully consider it. In any event, I suggest that it may be time to consult the authors and then move 2482 to Historic. In no event is it wise for you to be recommending it. (4) I suggest also that RFC 5646 is inappropriate as a citation without a profile about how it is to be used and what is to be specified. Without that, its many elements and terms are a recipe for interoperability failures. (5) The MIME "content-language" header might be worth mentioning as another way to supply whole-document language tagging. (6) Given our fairly disastrous experience with the famous "MIME-Version: 1.0" and, more controversially, some issues with evolution of HTTP, the "Versioning" section may need some expansion. Statements equivalent to "Protocol versions happen, so it's usually important to define a version field of some kind" are exactly what got us into the MIME-version mess. Design of any extension model requires an lot of analysis and effort to get right, not just assignment of a few numbers. I know that you know that and the material in RFC 3920 appears to reflect just that sort of analysis, but the current statement in the draft and suggestions about reuse of 3920 text seem to encourage underestimating the complexities of working out a versioning design in favor of saying something that might get past AD review. best, john From randy_presuhn@mindspring.com Thu Jun 3 21:09:38 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346EB3A6877 for ; Thu, 3 Jun 2010 21:09:38 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q47n9PfyGhnJ for ; Thu, 3 Jun 2010 21:09:33 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 908703A63EB for ; Thu, 3 Jun 2010 21:09:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PccImw9Y37K5QNlyBEBfk5ouAmE2ezi5pFQ0UbRdiEnfWxa1e/CEuYxrZr9yIjRR; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.5.61] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OKODf-0001vo-Tl for apps-discuss@ietf.org; Fri, 04 Jun 2010 00:09:20 -0400 Message-ID: <000601cb039b$d793e840$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4C07D73A.3090301@stpeter.im> <6765C175B8789B331C1F14C7@PST.JCK.COM> Subject: Re: AD nits Date: Thu, 3 Jun 2010 21:10:16 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780354f163d003fee22720955ae79b721919d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.61 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 04:09:38 -0000 Hi - > From: "John C Klensin" > To: "Peter Saint-Andre" ; > Sent: Thursday, June 03, 2010 6:31 PM > Subject: Re: AD nits ... > (3) As a substantive point, RFC 2482 notwithstanding, recent > versions of Unicode have very strongly discouraged the use of > language tags. See TUS 5.x, Section 16.9. While TUS 5.0 > identifies this section simply as "Tag Characters", it worth > nothing that 5.2 goes so far as to rename it as "Deprecated Tag > Characters" and the text has changed from "strongly discouraged" > (in 5.0) to "deprecated, and should not be used" in 5.2. ... I know you know better than to confuse "language tags" (BCP 47) with the (rightly) deprecated "tag characters" from Unicode. Randy From john@jck.com Thu Jun 3 21:47:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C21C93A68FC for ; Thu, 3 Jun 2010 21:47:41 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62jBgno6Uw8V for ; Thu, 3 Jun 2010 21:47:35 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id C0F933A6900 for ; Thu, 3 Jun 2010 21:47:34 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OKOoR-000NrZ-An; Fri, 04 Jun 2010 00:47:19 -0400 Date: Fri, 04 Jun 2010 00:47:18 -0400 From: John C Klensin To: Randy Presuhn , apps-discuss@ietf.org Subject: Re: AD nits Message-ID: In-Reply-To: <000601cb039b$d793e840$6801a8c0@oemcomputer> References: <4C07D73A.3090301@stpeter.im> <6765C175B8789B331C1F14C7@PST.JCK.COM> <000601cb039b$d793e840$6801a8c0@oemcomputer> 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 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 04:47:43 -0000 --On Thursday, June 03, 2010 21:10 -0700 Randy Presuhn wrote: > Hi - > >> From: "John C Klensin" >> To: "Peter Saint-Andre" ; >> Sent: Thursday, June 03, 2010 6:31 PM >> Subject: Re: AD nits > ... >> (3) As a substantive point, RFC 2482 notwithstanding, recent >> versions of Unicode have very strongly discouraged the use of >> language tags. See TUS 5.x, Section 16.9. While TUS 5.0 >> identifies this section simply as "Tag Characters", it worth >> nothing that 5.2 goes so far as to rename it as "Deprecated >> Tag Characters" and the text has changed from "strongly >> discouraged" (in 5.0) to "deprecated, and should not be used" >> in 5.2. > ... > > I know you know better than to confuse "language tags" > (BCP 47) with the (rightly) deprecated "tag characters" > from Unicode. Of course. That said, it has been a long week, it is hot, anything could happen, and the terms "language tagging" and "language tag identification character" appear in both TUS Section 16.9 and RFC 2482. From a terminology standpoint, the fact that one implements "language tagging" by using a "language identification character" followed by a "language tag" spelled out in "special-use tag characters" whose only permitted "special" use is for writing "language tags" is, at best, a trap for the unwary. The Unicode "tag characters" explicitly include language tagging and are the subject of RFC 2482. The nits draft recommends using RFC 2482 "tag characters" to identify languages, which is part of what I was commenting on and suggesting be removed. The language tags and "tag characters" are nonetheless tied together. Both 2482 and TUS Section 16.9 point to BCP 47 (RFC 5646 and 4647; formerly 4646 (referenced in TUS 5.0 Section 16.9), RFC 3066, and RFC 1766 (referenced from 2482 itself)). Put differently, one thing (really the only thing) one could do with the [deprecated] tag characters is to invoke language tagging strings as specified in BCP 47. So I don't think I'm confused at all. I do believe that any protocol that uses BCP 47 language tags (presumably independently of anything having to do with those Unicode in-line "tag characters", which we agree were a bad idea) should be explicit about the level of detail expected in those tags when they are used. If that is not done and there are wide variations in how much detail is specified, the protocol needs to establish matching rules (possibly by explicit invocation of RFC 4647) as to how the relationships are to be handled. Whether such a protocol specifies level of detail or matching rules (via 4647 or otherwise), its doing so explicitly is what I was referring to when I made the comment about a profile of RFC 5646. We might disagree about that "profile" conclusion, in which case we may need to have a separate discussion sometime, but I don't think I'm confused on that subject either. If you think I'm confused about any of that, please explain. If anyone else finds the discussion above confusing, I'm sure that the Unicode Consortium would welcome constructive suggestions about how to improve the terminology. best, john From mnot@mnot.net Thu Jun 3 23:23:58 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8C73A692D for ; Thu, 3 Jun 2010 23:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.082 X-Spam-Level: X-Spam-Status: No, score=-5.082 tagged_above=-999 required=5 tests=[AWL=-3.972, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsLpv1WTP78e for ; Thu, 3 Jun 2010 23:23:57 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 6DD003A6A39 for ; Thu, 3 Jun 2010 23:23:57 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.66.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 618A7509DD; Fri, 4 Jun 2010 02:23:36 -0400 (EDT) Subject: Re: HTTP 30x response code for bulk redirect Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Fri, 4 Jun 2010 16:24:54 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <700E1343-5C0D-4E29-91FD-2AD4DA51ADB7@mnot.net> References: To: Ted Hardie X-Mailer: Apple Mail (2.1078) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 06:23:58 -0000 Personally, I think something in .well-known should be allowed to say = this, but I agree it's an area you need to step carefully in. I'd also point out that *many* other mechanisms on the Web align policy = on a "site" basis (with acknowledgement that this is a fuzzy concept); = e.g., cookie scoping, some authentication mechanisms, cache = invalidations, robot policy, privacy policy, etc. Cheers, On 03/06/2010, at 5:14 AM, Ted Hardie wrote: > In discussions on the namedroppers list a side-issue on HTTP > redirection has cropped up. > The core of the question is how to support redirection for a flock of > resources that are all > being redirected. Client requests http://foo.example/resource1, gets a > redirect to > http://bar.example/resource1 and so on for resource1-resource51. My > faulty memory > is telling me that a 30x that said "This resources and all other > resources at this host > have moved" was not done earlier for security reasons--why allow > someone controlling > http://foo.example/resource1 to say anything about = http://foo.example/resource2, > since they might be associated with a different entity > (http://foo.example/~user1 > and http://foo.example/~user2 being the classic example). Is there > more to this, > or is there a way around the security issue using something like a > policy in .well-known? > E.g. allow a new 30x on a full-host basis, provided a policy in > .well-known permitted it? >=20 > regards, >=20 > Ted > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From duerst@it.aoyama.ac.jp Thu Jun 3 23:53:47 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14BC3A6A20 for ; Thu, 3 Jun 2010 23:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.81 X-Spam-Level: ** X-Spam-Status: No, score=2.81 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFM9zYg0Yu4I for ; Thu, 3 Jun 2010 23:53:46 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 7A1F03A695A for ; Thu, 3 Jun 2010 23:53:45 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id o546rSkv017048 for ; Fri, 4 Jun 2010 15:53:28 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 7d87_e804_97ff1120_6fa5_11df_9698_001d096c566a; Fri, 04 Jun 2010 15:51:25 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41889) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 4 Jun 2010 15:25:49 +0900 Message-ID: <4C089C64.60509@it.aoyama.ac.jp> Date: Fri, 04 Jun 2010 15:25:40 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: barryleiba@computer.org Subject: Re: AD nits References: <4C07D73A.3090301@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 06:53:47 -0000 Regarding time zones, you may also want to consult or point to http://www.w3.org/TR/2005/NOTE-timezone-20051013/. Regards, Martin. On 2010/06/04 5:54, Barry Leiba wrote: >> http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues > > In "Dates and Times", we should probably say more about time zones, > particularly time-zone names. vCards have an issue with how to name > time zones, which prompted this now-expired draft: > https://datatracker.ietf.org/doc/draft-leiba-tzregistry/ > > More recently, Cyrus had tried to kick something off, which is why I > abandoned the tzregistry draft, but I can't find a reference to it. > > Barry > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Fri Jun 4 00:01:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D325A3A68C0 for ; Fri, 4 Jun 2010 00:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.81 X-Spam-Level: ** X-Spam-Status: No, score=2.81 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxq5LDKjmhGI for ; Fri, 4 Jun 2010 00:01:20 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id CF94C3A6A1F for ; Fri, 4 Jun 2010 00:01:19 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id o54711wa027239 for ; Fri, 4 Jun 2010 16:01:02 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 0ae5_101b_ef6b6746_6fa6_11df_a47d_001d096c5782; Fri, 04 Jun 2010 16:01:01 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41889) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 4 Jun 2010 15:25:49 +0900 Message-ID: <4C089C64.60509@it.aoyama.ac.jp> Date: Fri, 04 Jun 2010 15:25:40 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: barryleiba@computer.org Subject: Re: AD nits References: <4C07D73A.3090301@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 07:01:21 -0000 Regarding time zones, you may also want to consult or point to http://www.w3.org/TR/2005/NOTE-timezone-20051013/. Regards, Martin. On 2010/06/04 5:54, Barry Leiba wrote: >> http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues > > In "Dates and Times", we should probably say more about time zones, > particularly time-zone names. vCards have an issue with how to name > time zones, which prompted this now-expired draft: > https://datatracker.ietf.org/doc/draft-leiba-tzregistry/ > > More recently, Cyrus had tried to kick something off, which is why I > abandoned the tzregistry draft, but I can't find a reference to it. > > Barry > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From vkg@bell-labs.com Thu Jun 3 10:23:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF353A68A0 for ; Thu, 3 Jun 2010 10:23:01 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X2ARV1Ulq-k for ; Thu, 3 Jun 2010 10:23:00 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 2D11A3A6892 for ; Thu, 3 Jun 2010 10:23:00 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o53HMd8i014544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jun 2010 12:22:41 -0500 (CDT) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o53HMdaT002729; Thu, 3 Jun 2010 12:22:39 -0500 (CDT) Message-ID: <4C07E539.7010007@bell-labs.com> Date: Thu, 03 Jun 2010 12:24:09 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: AD nits References: <4C07D73A.3090301@stpeter.im> In-Reply-To: <4C07D73A.3090301@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Fri, 04 Jun 2010 08:22:28 -0700 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 17:23:01 -0000 On 06/03/2010 11:24 AM, Peter Saint-Andre wrote: > Alexey and I have been working on a set of "AD nits" that come up again > and again during our IESG reviews of various Internet-Drafts. We'd > welcome feedback from folks in the Applications Area. You can find the > list here: > > http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues Peter: Looks good. A couple of quick comments. 1) You may want to refer to Narten and Alvestrand [1] on writing IANA consideration section in RFCs. The MIME/Media Types section can probably be titled "IANA" or something along those lines. 2) You may want to refer to Rescorla and Korver [2] on writing security consideration section in RFCs. [1] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," RFC5226 (also BCP0026). [2] E. Rescorla and B. Korver, "Guidelines for Writing RFC Text on Security Considerations," RFC3552 (also BCP0072). Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From randy_presuhn@mindspring.com Fri Jun 4 14:27:14 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559F33A6895 for ; Fri, 4 Jun 2010 14:27:14 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lJoK-vH6jBS for ; Fri, 4 Jun 2010 14:27:13 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 0F1DE3A6818 for ; Fri, 4 Jun 2010 14:27:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SxNzzRWKOtmqyL3zvMND14h56upeWucO4Ls/wAuuNAA8bT6ULi6oR5ZVyw5+zKAb; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.172.199] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OKePr-0005vJ-1Q for apps-discuss@ietf.org; Fri, 04 Jun 2010 17:26:59 -0400 Message-ID: <001d01cb042c$cd61c540$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4C07D73A.3090301@stpeter.im> <6765C175B8789B331C1F14C7@PST.JCK.COM> <000601cb039b$d793e840$6801a8c0@oemcomputer> Subject: Re: AD nits Date: Fri, 4 Jun 2010 14:27:56 -0700 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.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035566db0e7894b03bfaad54ee14fdb8648350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.172.199 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 21:27:14 -0000 Hi - I think the problem at hand is simpler than all that. Something constructed using the deprecated Unicode "language tagging characters" couldn't possibly be a language tag. The grammar of language tags (RFC 5646 pages 5-6) makes it quite impossible. They were simply designed to be easily mappable into language tags. The deprecated "language tagging characters" were an idea whose time never came, and should be forgotten ASAP, IMO. To that extent, I agree that if RFC 2482 is to be referened at all, it should be in the form of a "don't do that". FWIW, what would it take to declare 2482 "Historic"? Randy ----- Original Message ----- > From: "John C Klensin" > To: "Randy Presuhn" ; > Sent: Thursday, June 03, 2010 9:47 PM > Subject: Re: AD nits > > > > --On Thursday, June 03, 2010 21:10 -0700 Randy Presuhn > wrote: > > > Hi - > > > >> From: "John C Klensin" > >> To: "Peter Saint-Andre" ; > >> Sent: Thursday, June 03, 2010 6:31 PM > >> Subject: Re: AD nits > > ... > >> (3) As a substantive point, RFC 2482 notwithstanding, recent > >> versions of Unicode have very strongly discouraged the use of > >> language tags. See TUS 5.x, Section 16.9. While TUS 5.0 > >> identifies this section simply as "Tag Characters", it worth > >> nothing that 5.2 goes so far as to rename it as "Deprecated > >> Tag Characters" and the text has changed from "strongly > >> discouraged" (in 5.0) to "deprecated, and should not be used" > >> in 5.2. > > ... > > > > I know you know better than to confuse "language tags" > > (BCP 47) with the (rightly) deprecated "tag characters" > > from Unicode. > > Of course. That said, it has been a long week, it is hot, > anything could happen, and the terms "language tagging" and > "language tag identification character" appear in both TUS > Section 16.9 and RFC 2482. From a terminology standpoint, the > fact that one implements "language tagging" by using a "language > identification character" followed by a "language tag" spelled > out in "special-use tag characters" whose only permitted > "special" use is for writing "language tags" is, at best, a trap > for the unwary. > > The Unicode "tag characters" explicitly include language tagging > and are the subject of RFC 2482. The nits draft recommends > using RFC 2482 "tag characters" to identify languages, which is > part of what I was commenting on and suggesting be removed. > > The language tags and "tag characters" are nonetheless tied > together. Both 2482 and TUS Section 16.9 point to BCP 47 (RFC > 5646 and 4647; formerly 4646 (referenced in TUS 5.0 Section > 16.9), RFC 3066, and RFC 1766 (referenced from 2482 itself)). > Put differently, one thing (really the only thing) one could do > with the [deprecated] tag characters is to invoke language > tagging strings as specified in BCP 47. > > So I don't think I'm confused at all. > > I do believe that any protocol that uses BCP 47 language tags > (presumably independently of anything having to do with those > Unicode in-line "tag characters", which we agree were a bad > idea) should be explicit about the level of detail expected in > those tags when they are used. If that is not done and there > are wide variations in how much detail is specified, the > protocol needs to establish matching rules (possibly by explicit > invocation of RFC 4647) as to how the relationships are to be > handled. Whether such a protocol specifies level of detail or > matching rules (via 4647 or otherwise), its doing so explicitly > is what I was referring to when I made the comment about a > profile of RFC 5646. > > We might disagree about that "profile" conclusion, in which case > we may need to have a separate discussion sometime, but I don't > think I'm confused on that subject either. > > If you think I'm confused about any of that, please explain. > > If anyone else finds the discussion above confusing, I'm sure > that the Unicode Consortium would welcome constructive > suggestions about how to improve the terminology. > > best, > john > From john-ietf@jck.com Fri Jun 4 17:18:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8969328C0EA for ; Fri, 4 Jun 2010 17:18:22 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt2Pjg8DwVtM for ; Fri, 4 Jun 2010 17:18:21 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 4D6A128C0DE for ; Fri, 4 Jun 2010 17:18:21 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OKh5K-000HLu-Q3; Fri, 04 Jun 2010 20:17:59 -0400 Date: Fri, 04 Jun 2010 20:17:57 -0400 From: John C Klensin To: Randy Presuhn , apps-discuss@ietf.org Subject: Re: AD nits Message-ID: <75DB88F530C5B3C9771B0DE8@PST.JCK.COM> In-Reply-To: <001d01cb042c$cd61c540$6801a8c0@oemcomputer> References: <4C07D73A.3090301@stpeter.im> <6765C175B8789B331C1F14C7@PST.JCK.COM> <000601cb039b$d793e840$6801a8c0@oemcomputer> <001d01cb042c$cd61c540$6801a8c0@oemcomputer> 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 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jun 2010 00:18:22 -0000 Randy, To avoid complicating the discussion unnecessarily: (1) the "nits" draft had not explicitly recommended the possibility of using 2482, I would not have raised these issues at all and probably wouldn't have noticed them. 2482 slipped off my radar long ago, probably about the time it was written. (2) If the "nits" draft is changed to either say "don't even think about using that" about 2482 or even to drop all mention of it, I think we are back to where we should be. (3) At least in recent years, getting a document moved to historic usually requires that someone generate an I-D that says "move X to historic" and, ideally, explains why. I think "an idea whose time never came, and should be forgotten ASAP" would about cover the explanation. I think it would be courteous and appropriate to ask Ken and Glenn if they have inputs or objections but then it ought to be easy to generate the I-D and, the AD's willing, push it through the system. I'd be willing to do a little work to generate the I-D if that would help. It isn't as if those tagging characters have a huge installed base :-( john --On Friday, June 04, 2010 14:27 -0700 Randy Presuhn wrote: > Hi - > > I think the problem at hand is simpler than all that. > > Something constructed using the deprecated Unicode > "language tagging characters" couldn't possibly be > a language tag. The grammar of language tags > (RFC 5646 pages 5-6) makes it quite impossible. > They were simply designed to be easily mappable into > language tags. > > The deprecated "language tagging characters" were > an idea whose time never came, and should be forgotten ASAP, > IMO. To that extent, I agree that if RFC 2482 is to be > referened at all, it should be in the form of a "don't do > that". > > FWIW, what would it take to declare 2482 "Historic"? From duerst@it.aoyama.ac.jp Mon Jun 7 09:45:55 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632B63A6CC4 for ; Mon, 7 Jun 2010 09:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.81 X-Spam-Level: ** X-Spam-Status: No, score=2.81 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDTPyxbQxLTg for ; Mon, 7 Jun 2010 09:45:54 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id A93B528C926 for ; Mon, 7 Jun 2010 04:10:43 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id o57BAesJ024076 for ; Mon, 7 Jun 2010 20:10:40 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5cb9_02d2_3b206878_7225_11df_a297_001d096c566a; Mon, 07 Jun 2010 20:10:07 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36879) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 7 Jun 2010 18:41:51 +0900 Message-ID: <4C0CBED2.6070402@it.aoyama.ac.jp> Date: Mon, 07 Jun 2010 18:41:38 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: John C Klensin Subject: Re: AD nits References: <4C07D73A.3090301@stpeter.im> <6765C175B8789B331C1F14C7@PST.JCK.COM> <000601cb039b$d793e840$6801a8c0@oemcomputer> <001d01cb042c$cd61c540$6801a8c0@oemcomputer> <75DB88F530C5B3C9771B0DE8@PST.JCK.COM> In-Reply-To: <75DB88F530C5B3C9771B0DE8@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Kenneth Whistler , apps-discuss@ietf.org, "Glenn A. Adams" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Jun 2010 16:45:55 -0000 Hello John, On 2010/06/05 9:17, John C Klensin wrote: > Randy, > > To avoid complicating the discussion unnecessarily: > > (1) the "nits" draft had not explicitly recommended the > possibility of using 2482, I would not have raised these issues > at all and probably wouldn't have noticed them. 2482 slipped > off my radar long ago, probably about the time it was written. > > (2) If the "nits" draft is changed to either say "don't even > think about using that" about 2482 or even to drop all mention > of it, I think we are back to where we should be. > > (3) At least in recent years, getting a document moved to > historic usually requires that someone generate an I-D that says > "move X to historic" and, ideally, explains why. I think "an > idea whose time never came, and should be forgotten ASAP" would > about cover the explanation. I think it would be courteous and > appropriate to ask Ken and Glenn if they have inputs or > objections but then it ought to be easy to generate the I-D and, > the AD's willing, push it through the system. I have added the two gentlemen to the cc list. In my recollection, http://tools.ietf.org/html/rfc2482 and the scheme it describes was only invented to prevent even worse, in particular the proposal in http://tools.ietf.org/html/draft-ietf-acap-mlsf-01, which messed around with UTF-8 in a very uncomfortable way. (I was also involved in a counterproposal, please see http://tools.ietf.org/html/draft-ietf-acap-langtag-00.) Given this background, and the fact that Unicode itself has depreciated the "language tag characters", I have no doubts that the two gentlemen will be very glad to help obsolete RFC 2482. But I'll let them speak for themselves. > I'd be willing to > do a little work to generate the I-D if that would help. It > isn't as if those tagging characters have a huge installed base > :-( It isn't, and I'm glad it isn't. However, some conversion libraries (in particular libiconv) go to the trouble to remove these (rather than just throw a "not convertable" error) when converting to encodings that only cover a subset of Unicode (e.g. iso-8859-1,...). So some of this stuff might actually float around out there :-(. Regards, Martin. > john > > > > > --On Friday, June 04, 2010 14:27 -0700 Randy Presuhn > wrote: > >> Hi - >> >> I think the problem at hand is simpler than all that. >> >> Something constructed using the deprecated Unicode >> "language tagging characters" couldn't possibly be >> a language tag. The grammar of language tags >> (RFC 5646 pages 5-6) makes it quite impossible. >> They were simply designed to be easily mappable into >> language tags. >> >> The deprecated "language tagging characters" were >> an idea whose time never came, and should be forgotten ASAP, >> IMO. To that extent, I agree that if RFC 2482 is to be >> referened at all, it should be in the form of a "don't do >> that". >> >> FWIW, what would it take to declare 2482 "Historic"? > > > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From alexey.melnikov@isode.com Tue Jun 8 11:33:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6523A68D9 for ; Tue, 8 Jun 2010 11:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82corZLphZH6 for ; Tue, 8 Jun 2010 11:33:01 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 68E3A3A68D3 for ; Tue, 8 Jun 2010 11:33:01 -0700 (PDT) Received: from [92.40.82.53] (92.40.82.53.sub.mbb.three.co.uk [92.40.82.53]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 8 Jun 2010 19:33:01 +0100 Message-ID: <4C0CB991.2070105@isode.com> Date: Mon, 07 Jun 2010 10:19:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Marc Blanchet References: <4C07D73A.3090301@stpeter.im> <4C07FC39.6060702@viagenie.ca> In-Reply-To: <4C07FC39.6060702@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] AD nits X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 18:33:02 -0000 Marc Blanchet wrote: > Le 10-06-03 12:24, Peter Saint-Andre a =C3=A9crit : >> Alexey and I have been working on a set of "AD nits" that come up again >> and again during our IESG reviews of various Internet-Drafts. We'd >> welcome feedback from folks in the Applications Area. You can find the >> list here: >> >> http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues > interesting and good idea. no comment/info on the=20 > stringprep/nameprep/newprep needs for protocol identifiers? ie. should=20 > I care about this and if yes, what should I do. I don't think we have a good answer to this in Apps. Once we do, this=20 should definitely be added. From alexey.melnikov@isode.com Tue Jun 8 11:35:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE433A677C for ; Tue, 8 Jun 2010 11:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_20=-0.74, DATE_IN_PAST_24_48=1.219, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s5gz+0IYEdL for ; Tue, 8 Jun 2010 11:35:26 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5D1D03A6890 for ; Tue, 8 Jun 2010 11:35:26 -0700 (PDT) Received: from [92.40.82.53] (92.40.82.53.sub.mbb.three.co.uk [92.40.82.53]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 8 Jun 2010 19:34:14 +0100 Message-ID: <4C0CBADE.7080606@isode.com> Date: Mon, 07 Jun 2010 10:24:46 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <4C07D73A.3090301@stpeter.im> <4C089C64.60509@it.aoyama.ac.jp> In-Reply-To: <4C089C64.60509@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: barryleiba@computer.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AD nits X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 18:35:27 -0000 Martin J. D=FCrst wrote: > Regarding time zones, you may also want to consult or point to > http://www.w3.org/TR/2005/NOTE-timezone-20051013/. Personally I don't like to block documents in IESG review on something=20 that has no IETF consensus (or even the Apps area wide agreement on the=20 best solution). > Regards, Martin. > > On 2010/06/04 5:54, Barry Leiba wrote: >>> http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues >> In "Dates and Times", we should probably say more about time zones, >> particularly time-zone names. vCards have an issue with how to name >> time zones, which prompted this now-expired draft: >> https://datatracker.ietf.org/doc/draft-leiba-tzregistry/ >> >> More recently, Cyrus had tried to kick something off, which is why I >> abandoned the tzregistry draft, but I can't find a reference to it. >> >> Barry >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > From Martin.Thomson@andrew.com Tue Jun 8 18:44:58 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB523A681F for ; Tue, 8 Jun 2010 18:44:58 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtNprkb-9oYJ for ; Tue, 8 Jun 2010 18:44:55 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 546CC3A6811 for ; Tue, 8 Jun 2010 18:44:55 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:56645 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S24192698Ab0FIBox (ORCPT ); Tue, 8 Jun 2010 20:44:53 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 8 Jun 2010 20:44:53 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 9 Jun 2010 09:44:49 +0800 From: "Thomson, Martin" To: "apps-discuss@ietf.org" , "psaintan@cisco.com" , "Jeff.Hodges@PayPal.com" Date: Wed, 9 Jun 2010 09:46:41 +0800 Thread-Topic: draft-saintandre-tls-server-id-check and user overrides Thread-Index: AcsHdZrRdGl33JD6TZ+kyVu+1LzB/w== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E7F1F8DD@SISPE7MB1.commscope.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [apps-discuss] draft-saintandre-tls-server-id-check and user overrides X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 01:44:58 -0000 SW4gZHJhZnQtc2FpbnRhbmRyZS10bHMtc2VydmVyLWlkLWNoZWNrLTA1LCBTZWN0aW9ucyAzLjYu MiBhbmQgMy42LjMuMSB0YWxrIGFib3V0IHVzZXIgY2hvaWNlIGluIGludGVyYWN0aXZlbHkgdHJ1 c3RpbmcgYSBjZXJ0aWZpY2F0ZS4gIA0KDQpXaGF0IGlzIG1pc3NpbmcgaXMgZGlzY3Vzc2lvbiBv biAid2h5IiB1c2VycyBtaWdodCBuZWVkIHRvIChvciB3YW50IHRvKSBvdmVycmlkZSB0aGUgZGVm YXVsdCBiZWhhdmlvdXIuICBVc2FnZSBwcmFjdGljZXMgYXJlbid0IG9idmlvdXMsIHNvIHRoaXMg c2VlbXMgbGlrZSBhIGdvb2QgcGxhY2UgdG8gZXhwYW5kIG9uIHRoaXMuDQoNCkl0IHdvdWxkIGJl IGdvb2QgaWYgdGhpcyBkZXNjcmliZWQgd2hhdCBhcmUgYWNjZXB0YWJsZSB0eXBlcyBvZiBjZXJ0 aWZpY2F0ZSB2YWxpZGF0aW9uIGZhaWx1cmUgYW5kIHdoYXQgYXJlbid0LiAgQ29tbW9uIHJlYXNv bnMgdGhhdCBhcmUgcG90ZW50aWFsbHkgdmFsaWQgYXJlOg0KIC0gbm90IHRydXN0ZWQgKG5vIENB KQ0KIC0gZXhwaXJlZCBjZXJ0aWZpY2F0ZQ0KIC0gd3JvbmcgbmFtZQ0KIC0gcmV2b2tlZCBjZXJ0 aWZpY2F0ZQ0KDQpPYnZpb3VzbHksIHlvdSBhcmVuJ3QgZ29pbmcgdG8gYWNjZXB0IGEgY2VydGlm aWNhdGUgaWYgdGhlIGVudGl0eSBwcm92aWRpbmcgaXQgY291bGQgbm90IHByb3ZlIHRoYXQgdGhl eSBwb3NzZXNzIHRoZSBjb3JyZXNwb25kaW5nIHByaXZhdGUga2V5Lg0KDQpJdCBtaWdodCBoZWxw IHRvIGV4cGxhaW4gdGhlIHNpZ25pZmljYW5jZSBvZiBzdWNoIGFuIGFjdGlvbiAtIHRoZSB1c2Vy IGlzIHRydXN0aW5nIHRoZSBlbnRpdHkgdGhhdCBpcyBhYmxlIHRvIHByb29mIHBvc3Nlc3Npb24g b2YgdGhlIHByaXZhdGUga2V5IHRoYXQgY29ycmVzcG9uZHMgdG8gdGhlIHByaXZhdGUga2V5IGlu IHRoZSBjZXJ0aWZpY2F0ZS4gIEFsbCBvdGhlciBkYXRhIGluIHRoZSBjZXJ0aWZpY2F0ZSBiZWNv bWVzIGlycmVsZXZhbnQuDQoNCi0tTWFydGluDQoNCnAucy4gSSBkb24ndCBrbm93IHdoYXQgaGFw cGVucyBpbiBwcmFjdGljZSBpZiBhIGNlcnRpZmljYXRlIGlzIHBpbm5lZCBiZWZvcmUgZXhwaXJ5 IGFuZCB0aGVuIHN1YnNlcXVlbnRseSBleHBpcmVzLiAgU2FtZSBnb2VzIGZvciByZXZvY2F0aW9u LiAgSSdkIGJlIGludGVyZXN0ZWQgaW4gbGVhcm5pbmcgd2hhdCBwZW9wbGUgZG8uICBMb2dpYyBz dWdnZXN0cyB0aGF0IGlmIGEgY2VydGlmaWNhdGUgaXMgYWNjZXB0ZWQgZGVzcGl0ZSB2aW9sYXRp bmcgb25lIGNyaXRlcmlvbiwgaXQgZG9lcyBub3QgaW1wbHkgY29udGludWVkIGFjY2VwdGFuY2Ug d2hlbiBhbm90aGVyIGNyaXRlcmlhIGFyZSBzdWJzZXF1ZW50bHkgdmlvbGF0ZWQuDQo= From stpeter@stpeter.im Wed Jun 9 19:23:36 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8FB3A6867 for ; Wed, 9 Jun 2010 19:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZ7kHBu9aB1b for ; Wed, 9 Jun 2010 19:23:35 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 13F433A6843 for ; Wed, 9 Jun 2010 19:23:35 -0700 (PDT) Received: from squire.local (dsl-228-47.dynamic-dsl.frii.net [216.17.228.47]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4373640E3E; Wed, 9 Jun 2010 20:23:36 -0600 (MDT) Message-ID: <4C104C9E.9010403@stpeter.im> Date: Wed, 09 Jun 2010 20:23:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F03E7F1F8DD@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E7F1F8DD@SISPE7MB1.commscope.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090003050900030603000404" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-saintandre-tls-server-id-check and user overrides X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 02:23:36 -0000 This is a cryptographically signed message in MIME format. --------------ms090003050900030603000404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/8/10 7:46 PM, Thomson, Martin wrote: > In draft-saintandre-tls-server-id-check-05... The preferred (and quite active) venue for discussion of this I-D is the certid@ietf.org list: https://www.ietf.org/mailman/listinfo/certid I'm going to forward your message to that list and reply there. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090003050900030603000404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMDAyMjMyNlowIwYJKoZIhvcNAQkEMRYEFEMQHnETbb4fN2Vig+Fm cjfEr+b7MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAlzMfFxE36x2uG+jmrAIcwVCc1YloSYrqeHA7My49 2Nst87Dy0BNvCmEj0PrRdOPC2AheoZz6SNx6jZZfq8M3rwTD0I1p37FPKHRMrG3z5EMWZx7A +HpDTd8TqnLTgVztjdJGBxqjm89rtuLWhS7glanZcF+Y3Ag0D1OBL2/MB30Fos8rnNBdK/Y4 kGneRDEhA7okrWZIOMLrauZG2ARHFwspII3/ZzWKnIXC5r7IKrqSqDUUCdSPWOjfazKIXmum n9TBoDzIKaoPvrvxxC9PxWxF3EVUUEI6WFd05Iad6OB5g0CBLKlbJ+b/bYCFMRaxTIIiSvGd Ijjn0dttpcYwXwAAAAAAAA== --------------ms090003050900030603000404-- From alexey.melnikov@isode.com Thu Jun 10 10:57:57 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54BD428C10D for ; Thu, 10 Jun 2010 10:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xhpQSf1PmG6 for ; Thu, 10 Jun 2010 10:57:56 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 859E228C0DB for ; Thu, 10 Jun 2010 10:57:53 -0700 (PDT) Received: from [188.28.46.65] (188.28.46.65.threembb.co.uk [188.28.46.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 10 Jun 2010 18:57:53 +0100 Message-ID: <4C1127A0.5090503@isode.com> Date: Thu, 10 Jun 2010 18:57:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 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] FTPEXT BOF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 17:57:57 -0000 Peter and I received a request to hold FTPEXT BOF in Maastricht. I am the sponsoring AD for it: BOF Chairs: Barry Leiba Length of session: 1 hour Goal: See if there is enough interest and energy to form a WG Draft Charter, Goals: Mailing list: ftpext@ietf.org To subscribe: or Mailing list archive: Related Drafts: and (others might follow) From iljitsch@muada.com Fri Jun 11 05:52:47 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD7D3A657C for ; Fri, 11 Jun 2010 05:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4cDgMZcB0ii for ; Fri, 11 Jun 2010 05:52:47 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id A564F3A696F for ; Fri, 11 Jun 2010 05:52:46 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id o5BCqfSI016423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 11 Jun 2010 14:52:42 +0200 (CEST) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jun 2010 14:52:44 +0200 Message-Id: <8F6D7B98-0B6E-4094-8BDF-DF2A6D53DC41@muada.com> To: apps-discuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [apps-discuss] FTP64 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 12:52:47 -0000 Hi all, We're just finishing wg last call on the FTP64 document in BEHAVE: https://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/ I hope and trust this version addresses the comments I received from the = app community. Please let me know if you have any comments. Iljitsch= From alexey.melnikov@isode.com Fri Jun 11 09:16:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9D23A69F7 for ; Fri, 11 Jun 2010 09:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfDjVPvKy3kw for ; Fri, 11 Jun 2010 09:15:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9DD703A69FA for ; Fri, 11 Jun 2010 09:15:20 -0700 (PDT) Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 11 Jun 2010 17:15:22 +0100 Message-ID: <4C126113.1020000@isode.com> Date: Fri, 11 Jun 2010 17:15:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Iljitsch van Beijnum References: <8F6D7B98-0B6E-4094-8BDF-DF2A6D53DC41@muada.com> In-Reply-To: <8F6D7B98-0B6E-4094-8BDF-DF2A6D53DC41@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] FTP64 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 16:16:20 -0000 Iljitsch van Beijnum wrote: >Hi all, > Hi Iljitsch, >We're just finishing wg last call on the FTP64 document in BEHAVE: > >https://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/ > >I hope and trust this version addresses the comments I received from the app community. Please let me know if you have any comments. > Would it be possible to delay IETF LC (or IESG review) for this document till after the FTPEXT BOF in Maastricht? From stpeter@stpeter.im Fri Jun 11 15:02:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20B73A697D for ; Fri, 11 Jun 2010 15:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCmgLlOfbo3D for ; Fri, 11 Jun 2010 15:02:23 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8EB343A659A for ; Fri, 11 Jun 2010 15:02:23 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 94F6740E14 for ; Fri, 11 Jun 2010 16:02:25 -0600 (MDT) Message-ID: <4C12B270.1030700@stpeter.im> Date: Fri, 11 Jun 2010 16:02:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030604030508000304080004" Subject: [apps-discuss] reminder: IETF 78 meeting request deadline X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 22:02:25 -0000 This is a cryptographically signed message in MIME format. --------------ms030604030508000304080004 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The deadline for requesting a WG session at IETF 78 is Monday: http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78 According to my notes, the following Applications Area working groups have requested sessions: alto core eai httpbis hybi iri marf oauth precis (was newprep) sieve vcarddav (We also have BoFs scheduled for FTPEXT2, HASMAT, and URNBIS.) If your working group would like to hold a meeting at IETF 78 but you have not yet requested a session, please get organized in the next few days. :) If the foregoing information is in error, please let me know. Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030604030508000304080004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMTIyMDIyNFowIwYJKoZIhvcNAQkEMRYEFCPNtKktRY9ujT7d8bvC fHhbvpAGMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAam9R/X4Ft4v5pQwgCHhyhKphAhNbEs2mZzQwEb8C W8mduw/guRQO+/LPG38qH3iFB9kw9KmwZo3eCZFblICfqcdbHYB0lSDx3AFE4hh1UB2ji38P Th4Y3BDBkQ5oRjVPLmifLrYJt0acYGp2F7XK2XMOcZEqZfO9O1tgXbK6x2O9Q4Gr35P+d/23 24PtdSei7BiSDID7zW969OqaDfvIqt7kDCaM0x7HFthieC2iTydto9sdEZ7nF/ORBKX4/O6b jZJSMIR+Q6Fc8BNOwLFqkiYiX0r3Sp188Yd6ZujF1KplmNUoL0NWiKlP0HzqiaSmWq7UrRLb HzoIOhX+SpheQAAAAAAAAA== --------------ms030604030508000304080004-- From kenw@sybase.com Fri Jun 11 15:58:11 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4693928C0FA for ; Fri, 11 Jun 2010 15:58:11 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMkzwjmoiO7p for ; Fri, 11 Jun 2010 15:58:10 -0700 (PDT) Received: from inergen.sybase.com (inergen.sybase.com [192.138.151.43]) by core3.amsl.com (Postfix) with ESMTP id 5502B28C0ED for ; Fri, 11 Jun 2010 15:58:10 -0700 (PDT) Received: from smtp2.sybase.com (sybgate2 [10.22.97.85]) by inergen.sybase.com with ESMTP id o5BMwBq23231; Fri, 11 Jun 2010 15:58:11 -0700 (PDT) Received: from atlantis-new.sybase.com (localhost [127.0.0.1]) by smtp2.sybase.com with ESMTP id o5BMwA318515; Fri, 11 Jun 2010 15:58:10 -0700 (PDT) Received: from birdie.sybase.com (birdie.sybase.com [10.22.85.43]) by atlantis-new.sybase.com (8.13.7+Sun/8.13.7) with ESMTP id o5BMwAdt017495; Fri, 11 Jun 2010 15:58:10 -0700 (PDT) Received: from birdie (birdie [10.22.85.43]) by birdie.sybase.com (8.11.6+Sun/8.11.6) with SMTP id o5BMw8P02263; Fri, 11 Jun 2010 15:58:09 -0700 (PDT) Message-Id: <201006112258.o5BMw8P02263@birdie.sybase.com> Date: Fri, 11 Jun 2010 15:58:08 -0700 (PDT) From: Kenneth Whistler To: john-ietf@jck.com, duerst@it.aoyama.ac.jp MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FDsqsnigY+CQun5w9tkfIQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Cc: kenw@sybase.com, apps-discuss@ietf.org, glenn@xfsi.com Subject: Re: [apps-discuss] AD nits X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Kenneth Whistler List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 23:02:53 -0000 Martin, > > (3) At least in recent years, getting a document moved to > > historic usually requires that someone generate an I-D that says > > "move X to historic" and, ideally, explains why. I think "an > > idea whose time never came, and should be forgotten ASAP" would > > about cover the explanation. I think it would be courteous and > > appropriate to ask Ken and Glenn if they have inputs or > > objections but then it ought to be easy to generate the I-D and, > > the AD's willing, push it through the system. > > I have added the two gentlemen to the cc list. > In my recollection, http://tools.ietf.org/html/rfc2482 and the scheme it > describes was only invented to prevent even worse, in particular the > proposal in http://tools.ietf.org/html/draft-ietf-acap-mlsf-01, which > messed around with UTF-8 in a very uncomfortable way. (I was also > involved in a counterproposal, please see > http://tools.ietf.org/html/draft-ietf-acap-langtag-00.) > > Given this background, and the fact that Unicode itself has depreciated > the "language tag characters", I have no doubts that the two gentlemen > will be very glad to help obsolete RFC 2482. But I'll let them speak for > themselves. Speaking for myself, I have no objections to doing whatever it takes for the IETF to "move RFC 2482 to historic". As Martin notes, the language tag characters have been deprecated in the Unicode Standard. If the existence of RFC 2482 as informational is now causing problems for drafting of other documents, then by all means do what it takes to "deprecate" it as well at this point. --Ken From gadams@xfsi.com Fri Jun 11 16:53:30 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F053A67E7 for ; Fri, 11 Jun 2010 16:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eZ9rwpOJksF for ; Fri, 11 Jun 2010 16:53:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8EE8F3A67E9 for ; Fri, 11 Jun 2010 16:53:29 -0700 (PDT) Received: by vws9 with SMTP id 9so1739659vws.31 for ; Fri, 11 Jun 2010 16:53:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.43.197 with SMTP id x5mr1043316qae.127.1276300408996; Fri, 11 Jun 2010 16:53:28 -0700 (PDT) Received: by 10.229.100.21 with HTTP; Fri, 11 Jun 2010 16:53:28 -0700 (PDT) In-Reply-To: <201006112258.o5BMw8P02263@birdie.sybase.com> References: <201006112258.o5BMw8P02263@birdie.sybase.com> Date: Sat, 12 Jun 2010 07:53:28 +0800 Message-ID: From: Glenn Adams To: Kenneth Whistler Content-Type: multipart/alternative; boundary=00c09f88d3c28146b10488c9d8d0 X-Mailman-Approved-At: Sat, 12 Jun 2010 08:24:37 -0700 Cc: apps-discuss@ietf.org, glenn@xfsi.com Subject: Re: [apps-discuss] AD nits X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 23:54:28 -0000 --00c09f88d3c28146b10488c9d8d0 Content-Type: text/plain; charset=UTF-8 no objections on my part regards, glenn On Sat, Jun 12, 2010 at 6:58 AM, Kenneth Whistler wrote: > Martin, > > > > (3) At least in recent years, getting a document moved to > > > historic usually requires that someone generate an I-D that says > > > "move X to historic" and, ideally, explains why. I think "an > > > idea whose time never came, and should be forgotten ASAP" would > > > about cover the explanation. I think it would be courteous and > > > appropriate to ask Ken and Glenn if they have inputs or > > > objections but then it ought to be easy to generate the I-D and, > > > the AD's willing, push it through the system. > > > > I have added the two gentlemen to the cc list. > > > In my recollection, http://tools.ietf.org/html/rfc2482 and the scheme it > > describes was only invented to prevent even worse, in particular the > > proposal in http://tools.ietf.org/html/draft-ietf-acap-mlsf-01, which > > messed around with UTF-8 in a very uncomfortable way. (I was also > > involved in a counterproposal, please see > > http://tools.ietf.org/html/draft-ietf-acap-langtag-00.) > > > > Given this background, and the fact that Unicode itself has depreciated > > the "language tag characters", I have no doubts that the two gentlemen > > will be very glad to help obsolete RFC 2482. But I'll let them speak for > > themselves. > > Speaking for myself, I have no objections to doing whatever > it takes for the IETF to "move RFC 2482 to historic". > As Martin notes, the language tag characters have been > deprecated in the Unicode Standard. If the existence of > RFC 2482 as informational is now causing problems for > drafting of other documents, then by all means do what > it takes to "deprecate" it as well at this point. > > --Ken > > --00c09f88d3c28146b10488c9d8d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable no objections on my part

regards, glenn

On Sat, Jun 12, 2010 at 6:58 AM, Kenneth Whistler <kenw@sybase.com> wrote:
Martin,

> > (3) At least in recent years, getting a document moved to
> > historic usually requires that someone generate an I-D that says<= br> > > "move X to historic" and, ideally, explains why. =C2=A0= I think "an
> > idea whose time never came, and should be forgotten ASAP" wo= uld
> > about cover the explanation. =C2=A0I think it would be courteous = and
> > appropriate to ask Ken and Glenn if they have inputs or
> > objections but then it ought to be easy to generate the I-D and,<= br> > > the AD's willing, push it through the system.
>
> I have added the two gentlemen to the cc list.

> In my recollection, http://tools.ietf.org/html/rfc2482 and the scheme it
> describes was only invented to prevent even worse, in particular the > proposal in http://tools.ietf.org/html/draft-ietf-acap-mlsf-01, which
> messed around with UTF-8 in a very uncomfortable way. (I was also
> involved in a counterproposal, please see
> http://tools.ietf.org/html/draft-ietf-acap-langtag-00.) >
> Given this background, and the fact that Unicode itself has depreciate= d
> the "language tag characters", I have no doubts that the two= gentlemen
> will be very glad to help obsolete RFC 2482. But I'll let them spe= ak for
> themselves.

Speaking for myself, I have no objections to doing whatever
it takes for the IETF to "move RFC 2482 to historic".
As Martin notes, the language tag characters have been
deprecated in the Unicode Standard. If the existence of
RFC 2482 as informational is now causing problems for
drafting of other documents, then by all means do what
it takes to "deprecate" it as well at this point.

--Ken


--00c09f88d3c28146b10488c9d8d0-- From dwing@cisco.com Sat Jun 12 09:08:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF1E3A6974 for ; Sat, 12 Jun 2010 09:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.554 X-Spam-Level: X-Spam-Status: No, score=-8.554 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F9p5G09wVB1 for ; Sat, 12 Jun 2010 09:08:45 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 87A673A6921 for ; Sat, 12 Jun 2010 09:08:45 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYKAPtNE0xAZnwN/2dsb2JhbACHY4EUlgxxpHmZRIUaBINN X-IronPort-AV: E=Sophos;i="4.53,408,1272844800"; d="scan'208";a="121015176" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Jun 2010 16:08:45 +0000 Received: from dwingwxp01 ([10.32.240.194]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5CG8hfd006539; Sat, 12 Jun 2010 16:08:44 GMT From: "Dan Wing" To: "'Alexey Melnikov'" , "'Iljitsch van Beijnum'" References: <8F6D7B98-0B6E-4094-8BDF-DF2A6D53DC41@muada.com> <4C126113.1020000@isode.com> Date: Sat, 12 Jun 2010 09:08:40 -0700 Message-ID: <01e301cb0a49$86d5ccc0$7844150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsJgbAYqe97gMu6RM+jOMPTfqnKfAAxrnyg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4C126113.1020000@isode.com> Cc: 'Behave Chairs' , apps-discuss@ietf.org Subject: Re: [apps-discuss] FTP64 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 16:08:46 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: Friday, June 11, 2010 9:15 AM > To: Iljitsch van Beijnum > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] FTP64 > > Iljitsch van Beijnum wrote: > > >Hi all, > > > Hi Iljitsch, > > >We're just finishing wg last call on the FTP64 document in BEHAVE: > > > >https://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/ > > > >I hope and trust this version addresses the comments I > received from the app community. Please let me know if you > have any comments. > > > Would it be possible to delay IETF LC (or IESG review) for > this document > till after the FTPEXT BOF in Maastricht? As BEHAVE co-chair, We planned to solicit reviews on FTPEXT (the mailing list), but don't see a need to delay until IETF78 to progress the document. I just sent a request a minute ago; I was waiting until people had time to subscribe to FTPEXT. However, a related document which encourages IPv6 FTP clients to support having their traffic translated and work on more than 70% of IPv4 FTP servers is something FTPEXT2 might consider placing on its agenda, draft-liu-behave-ftp64. -d From stpeter@stpeter.im Sat Jun 12 20:00:03 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277523A67B6 for ; Sat, 12 Jun 2010 20:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSdMsANAi3SR for ; Sat, 12 Jun 2010 20:00:02 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 450263A67A3 for ; Sat, 12 Jun 2010 20:00:02 -0700 (PDT) Received: from squire.local (dsl-228-47.dynamic-dsl.frii.net [216.17.228.47]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E368240E14; Sat, 12 Jun 2010 21:00:02 -0600 (MDT) Message-ID: <4C1449A7.50603@stpeter.im> Date: Sat, 12 Jun 2010 20:59:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dan Wing References: <8F6D7B98-0B6E-4094-8BDF-DF2A6D53DC41@muada.com> <4C126113.1020000@isode.com> <01e301cb0a49$86d5ccc0$7844150a@cisco.com> In-Reply-To: <01e301cb0a49$86d5ccc0$7844150a@cisco.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070406060709060300090706" Cc: apps-discuss@ietf.org, liudapeng@chinamobile.com, caozhen@chinamobile.com, 'Behave Chairs' Subject: Re: [apps-discuss] FTP64 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 03:00:03 -0000 This is a cryptographically signed message in MIME format. --------------ms070406060709060300090706 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/12/10 10:08 AM, Dan Wing wrote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org=20 >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alexey Melnikov >> Sent: Friday, June 11, 2010 9:15 AM >> To: Iljitsch van Beijnum >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] FTP64 >> >> Iljitsch van Beijnum wrote: >> >>> Hi all, >>> >> Hi Iljitsch, >> >>> We're just finishing wg last call on the FTP64 document in BEHAVE: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/ >>> >>> I hope and trust this version addresses the comments I=20 >> received from the app community. Please let me know if you=20 >> have any comments. >>> >> Would it be possible to delay IETF LC (or IESG review) for=20 >> this document=20 >> till after the FTPEXT BOF in Maastricht? >=20 > As BEHAVE co-chair, >=20 > We planned to solicit reviews on FTPEXT (the mailing list), > but don't see a need to delay until IETF78 to progress the=20 > document. =20 Agreed. > I just sent a request a minute ago; I was waiting > until people had time to subscribe to FTPEXT. >=20 > However, a related document which encourages IPv6 FTP clients=20 > to support having their traffic translated and work on more than=20 > 70% of IPv4 FTP servers is something FTPEXT2 might consider=20 > placing on its agenda, draft-liu-behave-ftp64. Yes, the FTPEXT effort might be an appropriate place for discussion of draft-liu-behave-ftp64. I've cc'd the authors of that expired I-D to encourage them to post about it on the new ftpext list: https://www.ietf.org/mailman/listinfo/ftpext Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms070406060709060300090706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMzAyNTk1MVowIwYJKoZIhvcNAQkEMRYEFGLcazXF8xk7ezMUXD/Q q67UpRpSMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEASyFbat9K9MtqETm5GAKqMX3sTTEgawyhnoGonJQv cCME4ZZC80ftostmWQTIvJsM8nkBIdAnwcGxmDYzSzE2qz3up1/lv0kkq5mRovzJO1k6YXIp S4uRkWs/kuDhMDwycCBLfALV+uivrO3R4yaClm7WPbP3087Ajvjj0L+IwXTPVDtiRLi/w5te NH7lzfZ6bT8OyJKp8sMxM4jo0lO0Weyi8oSEn19RZhepKsxHfPfp76m7oft7On4V6Adxr+fb ijXWIYLC6RUZvSZTTXlBPrzQOVt70O3/VjTejSeOBCVIjD1/+FImE7JPeheGahlXtj/qEMWQ pdHLaV1ozTfx1wAAAAAAAA== --------------ms070406060709060300090706-- From alexey.melnikov@isode.com Mon Jun 14 04:50:45 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03343A68A9 for ; Mon, 14 Jun 2010 04:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2brk4OKiCDyl for ; Mon, 14 Jun 2010 04:50:45 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B21A63A6875 for ; Mon, 14 Jun 2010 04:50:44 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 14 Jun 2010 12:50:47 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4C16178D.7040804@isode.com> Date: Mon, 14 Jun 2010 12:50:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre References: <8F6D7B98-0B6E-4094-8BDF-DF2A6D53DC41@muada.com> <4C126113.1020000@isode.com> <01e301cb0a49$86d5ccc0$7844150a@cisco.com> <4C1449A7.50603@stpeter.im> In-Reply-To: <4C1449A7.50603@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, liudapeng@chinamobile.com, caozhen@chinamobile.com, 'Behave Chairs' Subject: Re: [apps-discuss] FTP64 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Jun 2010 11:50:45 -0000 Peter Saint-Andre wrote: >On 6/12/10 10:08 AM, Dan Wing wrote: > > >>>-----Original Message----- >>>From: apps-discuss-bounces@ietf.org >>>[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alexey Melnikov >>>Sent: Friday, June 11, 2010 9:15 AM >>>To: Iljitsch van Beijnum >>>Cc: apps-discuss@ietf.org >>>Subject: Re: [apps-discuss] FTP64 >>> >>>Iljitsch van Beijnum wrote: >>> >>> >>>>Hi all, >>>> >>>> >>>Hi Iljitsch, >>> >>> >>>>We're just finishing wg last call on the FTP64 document in BEHAVE: >>>> >>>>https://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/ >>>> >>>>I hope and trust this version addresses the comments I >>>> >>>> >>>received from the app community. Please let me know if you >>>have any comments. >>> >>> >>>Would it be possible to delay IETF LC (or IESG review) for >>>this document >>>till after the FTPEXT BOF in Maastricht? >>> >>> >>As BEHAVE co-chair, >> >>We planned to solicit reviews on FTPEXT (the mailing list), >>but don't see a need to delay until IETF78 to progress the >>document. >> >> >Agreed. > > Note that I deliberately said "IETF LC" in my original reply. So I certainly don't see a reason to delay WGLC. However I would ask the [to-be-decided] sponsoring RAI AD to delay IETF LC, or possibly IESG review till after the FTPEXT BOF. >>I just sent a request a minute ago; I was waiting >>until people had time to subscribe to FTPEXT. >> >>However, a related document which encourages IPv6 FTP clients >>to support having their traffic translated and work on more than >>70% of IPv4 FTP servers is something FTPEXT2 might consider >>placing on its agenda, draft-liu-behave-ftp64. >> >> >Yes, the FTPEXT effort might be an appropriate place for discussion of >draft-liu-behave-ftp64. I've cc'd the authors of that expired I-D to >encourage them to post about it on the new ftpext list: > >https://www.ietf.org/mailman/listinfo/ftpext > > Thanks, Peter. From randy_presuhn@mindspring.com Mon Jun 14 11:54:55 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789E33A68A3 for ; Mon, 14 Jun 2010 11:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qClROeMMnXdX for ; Mon, 14 Jun 2010 11:54:54 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 74CC93A67A2 for ; Mon, 14 Jun 2010 11:54:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gforBAu26XUqW460g3w1H/SWlsITYdkaPopXst1N9BCWhVN7C/Tk01RdrzTXTdNK; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.95.141] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OOEoE-0007fd-5n for apps-discuss@ietf.org; Mon, 14 Jun 2010 14:54:58 -0400 Message-ID: <008501cb0bf3$47072480$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Mon, 14 Jun 2010 11:56:19 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780352883811fad3a0ea1d805bd00259c8fd6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.95.141 Subject: [apps-discuss] Fw: I-D Action:draft-presuhn-rfc2482-historic-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Jun 2010 18:54:55 -0000 Hi - Please let me know if you have any comments on this I-D. I suggest the ltru@ietf.org mailing list would be a suitable venue for discussion. Randy > From: > To: > Sent: Monday, June 14, 2010 11:45 AM > Subject: I-D Action:draft-presuhn-rfc2482-historic-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Deprecating Language Tag Characters: RFC 2482 is Historic > Author(s) : K. Whistler, et al. > Filename : draft-presuhn-rfc2482-historic-00.txt > Pages : 5 > Date : 2010-06-14 > > RFC 2482, Language Tagging in Unicode Plain Text, described a > mechanism for using special Unicode language tag characters to > identify languages when needed without more general markup such as > that provided by XML. The Unicode Consortium has deprecated that > facility and strongly recommends against its use. RFC 2482 should be > moved to Historic to reduce the possibility that Internet > implementers would consider that system an appropriate mechanism for > identifying languages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-presuhn-rfc2482-historic-00.txt ... From randy_presuhn@mindspring.com Mon Jun 14 20:15:54 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFEE3A67F3; Mon, 14 Jun 2010 20:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlswRLzR1aF4; Mon, 14 Jun 2010 20:15:53 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id D5A3B3A679C; Mon, 14 Jun 2010 20:15:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pfLkj3W6mrK5hMeA9Lk8xnsPiSdwHy+DdShWA82qc4yG5rzNpg3p2k2gK3CJD/II; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.92.23] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OOMd3-0000rq-QI; Mon, 14 Jun 2010 23:15:58 -0400 Message-ID: <002501cb0c39$4084b820$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" , Date: Mon, 14 Jun 2010 20:17:11 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035253385b4d71bbc94937fea419bade722350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.92.23 Subject: [apps-discuss] Fw: I-D Action:draft-presuhn-rfc2482-historic-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 03:15:55 -0000 Hi - I've submitted a draft incorporating all the feedback received. If there is no additional feedback in the next couple of days, I'll assume it's ready show to the IESG. Randy > From: > To: > Sent: Monday, June 14, 2010 8:00 PM > Subject: I-D Action:draft-presuhn-rfc2482-historic-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Deprecating Language Tag Characters: RFC 2482 is Historic > Author(s) : K. Whistler, et al. > Filename : draft-presuhn-rfc2482-historic-01.txt > Pages : 5 > Date : 2010-06-14 > > RFC 2482, Language Tagging in Unicode Plain Text, described a > mechanism for using special Unicode language tag characters to > identify languages when needed without more general markup such as > that provided by XML. The Unicode Consortium has deprecated that > facility and strongly recommends against its use. RFC 2482 should be > moved to Historic to reduce the possibility that Internet > implementers would consider that system an appropriate mechanism for > identifying languages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-presuhn-rfc2482-historic-01.txt ... From alexey.melnikov@isode.com Tue Jun 15 12:02:55 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BE6D3A6974 for ; Tue, 15 Jun 2010 12:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oTO1JztloZY for ; Tue, 15 Jun 2010 12:02:52 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2CA563A6817 for ; Tue, 15 Jun 2010 12:02:52 -0700 (PDT) Received: from [172.16.2.177] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 15 Jun 2010 20:02:56 +0100 Message-ID: <4C17CE4D.8040000@isode.com> Date: Tue, 15 Jun 2010 20:02:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Publication of NNTP extensions on the Standards Tracks X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 19:02:55 -0000 Hi, I hope this discussion doesn't degenerate into another flame war, like the discussion about FTP extensions. I received a request to publish some NNTP extensions on Standards Track. The author claims (and I haven't checked that yet) that all extensions listed in the document are already implemented by at least one implementation. My question is: do people think I should be sponsoring any NNTP extensions on the Standards Tracks, should I sponsor them as Informational, or should I refuse to sponsor them? Best Regards, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From msk@cloudmark.com Tue Jun 15 12:07:39 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7753A6817 for ; Tue, 15 Jun 2010 12:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymAtmxEp3C7C for ; Tue, 15 Jun 2010 12:07:37 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 2F7B33A6974 for ; Tue, 15 Jun 2010 12:07:36 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Tue, 15 Jun 2010 12:07:40 -0700 From: "Murray S. Kucherawy" To: Alexey Melnikov , "Apps-Discuss@ietf.org" Date: Tue, 15 Jun 2010 12:07:39 -0700 Thread-Topic: [apps-discuss] Publication of NNTP extensions on the Standards Tracks Thread-Index: AcsMvWDW9EnRXeSlSGyCNn3ILfXYdAAAIeEw Message-ID: References: <4C17CE4D.8040000@isode.com> In-Reply-To: <4C17CE4D.8040000@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 19:07:39 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: Tuesday, June 15, 2010 12:03 PM > To: Apps-Discuss@ietf.org > Subject: [apps-discuss] Publication of NNTP extensions on the Standards > Tracks >=20 > Hi, > I hope this discussion doesn't degenerate into another flame war, like > the discussion about FTP extensions. > I received a request to publish some NNTP extensions on Standards > Track. > The author claims (and I haven't checked that yet) that all extensions > listed in the document are already implemented by at least one > implementation. My question is: do people think I should be sponsoring > any NNTP extensions on the Standards Tracks, should I sponsor them as > Informational, or should I refuse to sponsor them? Perhaps I'm missing some context to ask this question, so feel free to clob= ber me with some history if so... NNTP is still in use, so what's the argument for not admitting them to stan= dards track? From alexey.melnikov@isode.com Tue Jun 15 12:11:04 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314E83A6983 for ; Tue, 15 Jun 2010 12:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQL8TKXwm2Jo for ; Tue, 15 Jun 2010 12:11:02 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 050B23A6942 for ; Tue, 15 Jun 2010 12:11:02 -0700 (PDT) Received: from [172.16.2.177] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 15 Jun 2010 20:11:05 +0100 Message-ID: <4C17D037.9080309@isode.com> Date: Tue, 15 Jun 2010 20:10:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Murray S. Kucherawy" References: <4C17CE4D.8040000@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Apps-Discuss@ietf.org" Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 19:11:04 -0000 Hi Murray, Murray S. Kucherawy wrote: >>-----Original Message----- >>From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >>bounces@ietf.org] On Behalf Of Alexey Melnikov >>Sent: Tuesday, June 15, 2010 12:03 PM >>To: Apps-Discuss@ietf.org >>Subject: [apps-discuss] Publication of NNTP extensions on the Standards >>Tracks >> >>Hi, >>I hope this discussion doesn't degenerate into another flame war, like >>the discussion about FTP extensions. >>I received a request to publish some NNTP extensions on Standards >>Track. >>The author claims (and I haven't checked that yet) that all extensions >>listed in the document are already implemented by at least one >>implementation. My question is: do people think I should be sponsoring >>any NNTP extensions on the Standards Tracks, should I sponsor them as >>Informational, or should I refuse to sponsor them? >> >> >Perhaps I'm missing some context to ask this question, so feel free to clobber me with some history if so... > >NNTP is still in use, so what's the argument for not admitting them to standards track? > > I am concerned about the number of users of the technology in general and experts/reviewers in particular. Some Area Directors have much higher bar for sponsoring documents than I do, yet I am still trying to decide if investing my AD time in NNTP is a good way of spending time. From msk@cloudmark.com Tue Jun 15 12:20:57 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195503A67A2 for ; Tue, 15 Jun 2010 12:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3qQO94g9rb9 for ; Tue, 15 Jun 2010 12:20:55 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 09EC13A6817 for ; Tue, 15 Jun 2010 12:20:55 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Tue, 15 Jun 2010 12:20:59 -0700 From: "Murray S. Kucherawy" To: Alexey Melnikov Date: Tue, 15 Jun 2010 12:20:58 -0700 Thread-Topic: [apps-discuss] Publication of NNTP extensions on the Standards Tracks Thread-Index: AcsMvoLMXmlUDLwKR2OJ84nPsNDUZwAAGu+A Message-ID: References: <4C17CE4D.8040000@isode.com> <4C17D037.9080309@isode.com> In-Reply-To: <4C17D037.9080309@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Apps-Discuss@ietf.org" Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 19:20:57 -0000 > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Tuesday, June 15, 2010 12:11 PM > To: Murray S. Kucherawy > Cc: Apps-Discuss@ietf.org > Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standar= ds Tracks >=20 > I am concerned about the number of users of the technology in general > and experts/reviewers in particular. Some Area Directors have much > higher bar for sponsoring documents than I do, yet I am still trying to > decide if investing my AD time in NNTP is a good way of spending time. Unfortunately I don't think NNTP specs fit into another area. And my under= standing is that a non-experimental specification defining a protocol that = traverses ADMD boundaries has to be standards track. But the issue of the absence of expertise in the IETF to conduct meaningful= reviews is an interesting one, as is the presumably dwindling user base. = Perhaps those are reasons to do them as informational or experimental until= there's evidence of the opposite. In my view, the risk here is precedent; forcing these to some other track s= ets the bar higher for other proposals in niche areas that might otherwise = merit standards track processing. Then again, perhaps that's an appropriate precedent to have. From Nicolas.Williams@oracle.com Tue Jun 15 13:37:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E15F3A694D for ; Tue, 15 Jun 2010 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KLVOdM7-KSE for ; Tue, 15 Jun 2010 13:37:08 -0700 (PDT) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id 1E33A3A67F6 for ; Tue, 15 Jun 2010 13:37:08 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o5FKb9HF015561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Jun 2010 20:37:11 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5FKb2H1024560; Tue, 15 Jun 2010 20:37:02 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 347911641276634169; Tue, 15 Jun 2010 13:36:09 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Jun 2010 13:36:08 -0700 Date: Tue, 15 Jun 2010 15:36:04 -0500 From: Nicolas Williams To: "Murray S. Kucherawy" Message-ID: <20100615203603.GL24077@oracle.com> References: <4C17CE4D.8040000@isode.com> <4C17D037.9080309@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C17E475.005D:SCFMA4539814,ss=1,fgs=0 Cc: "Apps-Discuss@ietf.org" Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 20:37:10 -0000 On Tue, Jun 15, 2010 at 12:20:58PM -0700, Murray S. Kucherawy wrote: > > -----Original Message----- > > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > > Sent: Tuesday, June 15, 2010 12:11 PM > > To: Murray S. Kucherawy > > Cc: Apps-Discuss@ietf.org > > Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks > > > > I am concerned about the number of users of the technology in general > > and experts/reviewers in particular. Some Area Directors have much > > higher bar for sponsoring documents than I do, yet I am still trying to > > decide if investing my AD time in NNTP is a good way of spending time. > > Unfortunately I don't think NNTP specs fit into another area. And my > understanding is that a non-experimental specification defining a > protocol that traverses ADMD boundaries has to be standards track. > > But the issue of the absence of expertise in the IETF to conduct > meaningful reviews is an interesting one, as is the presumably > dwindling user base. Perhaps those are reasons to do them as > informational or experimental until there's evidence of the opposite. +1 Over time these documents could trivially be promoted to the Standards Track. Consider this approach similar to a very, very long IETF Last Call on these documents. > In my view, the risk here is precedent; forcing these to some other > track sets the bar higher for other proposals in niche areas that > might otherwise merit standards track processing. > > Then again, perhaps that's an appropriate precedent to have. I don't see why making these extensions Informational or Experimental would set a precedent: how exactly would one AD's actions set a precedent? Unless it be an informal precedent, I don't see how. One of the issues here is limited AD time relative to the importance of the work in question, which surely will vary too much over time to be worth setting a precedent over. If the only issues were the lack of a significant user base and the lack of expert reviewers, then you might speak of precedent. And even then, you could still say all similar cases should be handled on a case-by-case basis. Nico -- From wmaton@ryouko.imsb.nrc.ca Tue Jun 15 14:22:17 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0AA3A697A for ; Tue, 15 Jun 2010 14:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nSwjJ9PMrol for ; Tue, 15 Jun 2010 14:22:16 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2001:410:9000:127::10]) by core3.amsl.com (Postfix) with ESMTP id ACD013A6976 for ; Tue, 15 Jun 2010 14:22:15 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.4/8.14.4) with ESMTP id o5FLMDiT002908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jun 2010 17:22:18 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.4/8.14.3/Submit) with ESMTP id o5FLMDFJ002904; Tue, 15 Jun 2010 17:22:13 -0400 Date: Tue, 15 Jun 2010 17:22:13 -0400 (EDT) From: "William F. Maton Sotomayor" To: Russ Allbery In-Reply-To: <87zkywqbr6.fsf@windlord.stanford.edu> Message-ID: References: <87zkywqbr6.fsf@windlord.stanford.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: inn-workers@isc.org, Apps-Discuss@ietf.org Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 21:22:17 -0000 On Tue, 15 Jun 2010, Russ Allbery wrote: > What the NNTP community is mostly missing for IETF standardization > discussions, I think, are active participants who are also IETF attendees. > While I follow some IETF work, I'm not involved in enough of it at this > point to be able to justify the meeting attendance. +1, although I am sometimes able to go thanks to having a couple of off-the-rails drafts in dnsops. wfms From julien@trigofacile.com Tue Jun 15 15:09:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2693A68CC for ; Tue, 15 Jun 2010 15:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaMprVqsXMqd for ; Tue, 15 Jun 2010 15:09:50 -0700 (PDT) Received: from 6.mail-out.ovh.net (6.mail-out.ovh.net [91.121.25.210]) by core3.amsl.com (Postfix) with SMTP id 4C5F43A635F for ; Tue, 15 Jun 2010 15:09:49 -0700 (PDT) Received: (qmail 1802 invoked by uid 503); 15 Jun 2010 21:22:31 -0000 Received: from b3.ovh.net (HELO mail419.ha.ovh.net) (213.186.33.53) by 6.mail-out.ovh.net with SMTP; 15 Jun 2010 21:22:31 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 15 Jun 2010 23:09:51 +0200 Received: from aaubervilliers-151-1-23-182.w83-114.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@83.114.142.182) by ns0.ovh.net with SMTP; 15 Jun 2010 23:09:51 +0200 Message-ID: From: =?iso-8859-1?Q?Julien_=C9LIE?= To: , , References: <87zkywqbr6.fsf@windlord.stanford.edu> In-Reply-To: <87zkywqbr6.fsf@windlord.stanford.edu> Date: Tue, 15 Jun 2010 23:09:46 +0200 Organization: TrigoFACILE -- http://www.trigofacile.com/ MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 X-Ovh-Tracer-Id: 17014317918196071815 X-Ovh-Remote: 83.114.142.182 (aaubervilliers-151-1-23-182.w83-114.abo.wanadoo.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N X-Mailman-Approved-At: Wed, 16 Jun 2010 09:16:01 -0700 Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 22:09:51 -0000 Hi all, Quoting Alexey Melnikov, Murray S. Kucherawy and Russ Allbery: >>> -----Original Message----- >>> From: Alexey Melnikov >>> Sent: Tuesday, June 15, 2010 12:11 PM >>> To: Murray S. Kucherawy >>> Cc: Apps-Discuss@ietf.org >>> Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks >>> >>> I am concerned about the number of users of the technology in general >>> and experts/reviewers in particular. Some Area Directors have much >>> higher bar for sponsoring documents than I do, yet I am still trying to >>> decide if investing my AD time in NNTP is a good way of spending time. >> >> Unfortunately I don't think NNTP specs fit into another area. And my >> understanding is that a non-experimental specification defining a >> protocol that traverses ADMD boundaries has to be standards track. >> >> But the issue of the absence of expertise in the IETF to conduct >> meaningful reviews is an interesting one, as is the presumably dwindling >> user base. Perhaps those are reasons to do them as informational or >> experimental until there's evidence of the opposite. > > If it helps, I'm happy to do expert review of any NNTP-related protocol, > and there are several other people on the ietf-nntp mailing list who would > also be happy to do the same. > > What the NNTP community is mostly missing for IETF standardization > discussions, I think, are active participants who are also IETF attendees. > While I follow some IETF work, I'm not involved in enough of it at this > point to be able to justify the meeting attendance. I would also be happy to provide help and review about the NNTP protocol. (Though in this specific case of draft-elie-nntp-list-additions, obviously people other than me should review it.) -- Julien ÉLIE « La perfection est atteinte non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. » (Saint-Exupéry) From eagle@windlord.stanford.edu Tue Jun 15 13:31:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A363A6876 for ; Tue, 15 Jun 2010 13:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAPoAWYeVFaQ for ; Tue, 15 Jun 2010 13:30:58 -0700 (PDT) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by core3.amsl.com (Postfix) with ESMTP id 7C0C43A69DA for ; Tue, 15 Jun 2010 13:30:50 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 14F541A10B9; Tue, 15 Jun 2010 13:30:55 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id A97851A10AA; Tue, 15 Jun 2010 13:30:53 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 9B99D2F4A7; Tue, 15 Jun 2010 13:30:53 -0700 (PDT) From: Russ Allbery To: inn-workers@isc.org, Alexey Melnikov , Apps-Discuss@ietf.org In-Reply-To: (William F. Maton Sotomayor's message of "Tue, 15 Jun 2010 15:27:16 -0400 (EDT)") Organization: The Eyrie References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Date: Tue, 15 Jun 2010 13:30:53 -0700 Message-ID: <87zkywqbr6.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 16 Jun 2010 18:17:22 -0700 Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 20:31:27 -0000 > ---------- Forwarded message ---------- > Date: Tue, 15 Jun 2010 12:20:58 -0700 > From: Murray S. Kucherawy > To: Alexey Melnikov > Cc: "Apps-Discuss@ietf.org" > Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards > Tracks >> -----Original Message----- >> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >> Sent: Tuesday, June 15, 2010 12:11 PM >> To: Murray S. Kucherawy >> Cc: Apps-Discuss@ietf.org >> Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks >> >> I am concerned about the number of users of the technology in general >> and experts/reviewers in particular. Some Area Directors have much >> higher bar for sponsoring documents than I do, yet I am still trying to >> decide if investing my AD time in NNTP is a good way of spending time. > Unfortunately I don't think NNTP specs fit into another area. And my > understanding is that a non-experimental specification defining a > protocol that traverses ADMD boundaries has to be standards track. > But the issue of the absence of expertise in the IETF to conduct > meaningful reviews is an interesting one, as is the presumably dwindling > user base. Perhaps those are reasons to do them as informational or > experimental until there's evidence of the opposite. If it helps, I'm happy to do expert review of any NNTP-related protocol, and there are several other people on the ietf-nntp mailing list who would also be happy to do the same. What the NNTP community is mostly missing for IETF standardization discussions, I think, are active participants who are also IETF attendees. While I follow some IETF work, I'm not involved in enough of it at this point to be able to justify the meeting attendance. -- Russ Allbery (rra@stanford.edu) Please send questions to the list rather than mailing me directly. explains why. From ajs@shinkuro.com Thu Jun 17 08:25:09 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30993A68C1 for ; Thu, 17 Jun 2010 08:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.975 X-Spam-Level: X-Spam-Status: No, score=0.975 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QlPjB3LU2T3 for ; Thu, 17 Jun 2010 08:25:08 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A3D523A6855 for ; Thu, 17 Jun 2010 08:25:08 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0B62F1ECB41F for ; Thu, 17 Jun 2010 15:25:12 +0000 (UTC) Date: Thu, 17 Jun 2010 11:25:11 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20100617152511.GD82966@shinkuro.com> References: <87zkywqbr6.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zkywqbr6.fsf@windlord.stanford.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [apps-discuss] Publication of NNTP extensions on the Standards Tracks (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 15:25:09 -0000 On Tue, Jun 15, 2010 at 01:30:53PM -0700, Russ Allbery wrote: > What the NNTP community is mostly missing for IETF standardization > discussions, I think, are active participants who are also IETF attendees. > While I follow some IETF work, I'm not involved in enough of it at this > point to be able to justify the meeting attendance. There's no actual requirement, AFAIK, that anyone attend IETF meetings in order to get work done in the IETF. So if there is an active community of reviewers willing to do that in enagagement with the rest of the IETF, there's no reason the work can't be done without any face to face meetings. It's harder, but not impossible. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From A.Hoenes@TR-Sys.de Wed Jun 30 11:03:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85173A690B; Wed, 30 Jun 2010 11:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.324 X-Spam-Level: X-Spam-Status: No, score=-95.324 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgisZJT7K94Y; Wed, 30 Jun 2010 11:03:29 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 2E2843A6999; Wed, 30 Jun 2010 11:03:24 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA055580922; Wed, 30 Jun 2010 20:02:02 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA26017; Wed, 30 Jun 2010 20:01:51 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006301801.UAA26017@TR-Sys.de> To: touch@ISI.EDU Date: Wed, 30 Jun 2010 20:01:51 +0200 (MESZ) In-Reply-To: <4B6DF12D.9070808@isi.edu> from Joe Touch at Feb "6, " 2010 "02:46:05" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, tsvwg@ietf.org, apps-discuss@ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: Re: [apps-discuss] [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 18:03:31 -0000 At Sat, 06 Feb 2010 14:46:05 -0800, Joe Touch wrote: > > Hi, all, > > I completely agree with the abstract and the first bullet of section > 1.1, and section 1.2 EXCEPT in proposing the extension (appendix A). > > I don't think adding an extension "clarifies"; this doc ought to focus > on the clarification issue, and would be useful if doing so. > > Specific comments below, though IMO the structural issues are worth > addressing *before* the specific comments indicated. > > Joe Joe and all, my apologies for the delayed response. Thanks to Joe for the detailed comments. Summary response (please see more inline below): Please do not neglect the criticism spelled out repeatedly for draft-ietf-tsvwg-iana-ports but rejected by your team. This draft tries to accommodate the restrictions imposed by that memo. Yet, to be useful for aligning previous RFCs now deemed non- conformant with these rules and recent/ongoing work specifically calling for multi-label hierarchical Service Prefixes, this draft needs to show a uniform path that can be recommended to the authors / WGs where these RFCs are originating from. Thus, as a replacement mechanism for specifications using Service Prefixes with non-transport protocol Protocol Labels and/or more than two labels, the non-normative extension mechanism proposed is an essential part of this memo. Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports on the lenght of Service Names and the one-servie-name-per- application rule are being relaxed substantially, this extension mechanism will remain in this document. NOTE: A slightly revised update to draft-gudmundsson-dnsext-srv-clarify has just been submitted: draft-gudmundsson-dnsext-srv-clarify-01. Due to time constraints, this version however does not yet contain all the edits planned. >> ... >> >> 1.1. Problem Statement >> >> RFC 2782 says that the source of names for "Service" and "Proto" is >> "Assigned Numbers" (STD2) or a locally defined repository. >> >> However, upon reflection, both alternatives do not seem to make >> particular sense: >> >> o The STD2 series of documents was obsoleted by RFC 3232 [RFC3232] >> and IANA registration publication was handed over to on-line >> registries maintained by IANA. Unfortunately it is not explicitly >> explained in RFC 2782 which section of STD2 it is referring to, >> nor does RFC 3232 help. By common knowledge, RFC 2782 referred to >> the Keyword columns of the "Protocol Numbers" and "Port Numbers" >> IANA registries, respectively. >> >> As SRV records contain the port where each server provides the >> service, the outmost utility of SRV RRs is for services that do >> not have a registered port number. > > or where they are provided on ports other than the registered one. The draft says "outmost utility" for this specific case. For brevity in this part of the introduction, not all "important" use cases are listed. >> Also, the number of ports >> available is small compared to the possible number of service >> names that could be registered. Therefore, the "Port Number" >> registry needs a more strict registration policy and is not the >> proper place for registering service names for use with SRV >> resource records. > > This implies that service names with assigned ports would not be used > with SRVs; this is not required by the SRV spec. It also implies that > SRV names are somehow independent of the port number registry, but the > IANA ports doc ID formalizes the unification of these two namespaces. Please note that this historical perspective is presenting the "state of the art" after publication of RFC 2782 and *before* the current effort with this memo and tsvwg-iana-ports. Thus, it refers to the pre-RFC 3232 situation and its evolution by current practice in the past. Will be clarified in the leading text above the bullets. >> o Having locally defined lists of service and/or protocol names >> would equally allow to list the full service information in such >> local databases and thus make the usage of SRV records redundant. > > This language is awkward, and the logic is backwards. It's like saying > "you don't need the DNS because you can have hosts.txt". SRV can replace > /etc/services (with the appropriate changes to standards); the converse > is not true, so "equal" may be misleading. Again, these bullets describe the consequences of literally following RFC 2782 text. Thus, it is correct that "locally defined lists" of service and/or protocol names (which indeed would be similar in content to the "/etc/services" and "/etc/protocols" POSIX database files) would "equally allow to list the full service information". If such local lists (as suggested by RFC 2782) could contain all the information contained in the SRV RDATA as well, they indeed would -- at first glance, and for local users -- make "SRV records redundant". >> In any case, this scenario is not applicable for publicly >> available services where potential clients are not under the >> control of the authority offering the services, and hence most >> probably would have no access to the proper "locally provided" >> information. The reader is reminded that locally maintained >> database solutions generally scale very poorly, and that this once >> was the major momentum for the deployment of the Domain Name > replace 'momentum' with 'impetus' (or motivation?) >> System. > > As above, confusing and may need rewording. I'm not sure what you're > primary point is. The primary point is to show that literally following the idea spelled out in RFC 2782, to have service and/or protocol names listed in a local repository, would be a step backward. >> 1.2. Objective for this Document and its Companions > > I completely agree with this section, but subsequent sections diverge > from this objective IMO. > > ... >> 2. General Considerations for SRV Service Prefixes >> >> SRV Service Prefixes SHOULD consist of exactly two labels. > > When do they not? Is it even possible they do not? Of course, some documents describe such use cases for SRV. We are not the Internet police and do not want to obsolete prior art, nor interfere with work in progress in various WGs. Thus, it does not make sense to impose a "MUST" on human behavior that connot be controlled. If a WG insists on using hierarchical, multi-label Service Prefixes for a specific application (as it e.g. currently is discusssed seriously for mass storage access protocols), we cannot enforce the two-label rule with this document. Pretending otherwise would IMO be foolish. > >> If the specification of a particular application/service indicates >> that this service is to be provided at a specific registered port >> number and does not mention DNS SRV based service discovery, >> prospective clients SHOULD NOT assume the existence of SRV records > > I'd go with "MUST NOT" assume (isn't that in the SRV spec?) Again, implementation practice can diverge from written specifications. So, although the specs of an application do not mention the use of SRV records, implementation and deployment practice may have evolved to actually make use of them where they are available. In particular, a revised specification could be in progress. That would be reasons for escaping the "SHOULD NOT", isn't it? Therefore, "MUST NOT" would not make sense and could not be enforced. The "SHOULD NOT" above is rephrased literally from the "Applicability Statement" on page 2 of RFC 2782. > >> for this application, unless the client has hints available that >> indicate otherwise -- for instance by means of configuration. In >> this case, only the rules of Sections 3 and 4 apply. > > No need for the rest of the sentence (unless...); in that case, there is > no assumption. A good "SHOULD NOT" needs to indicate what the possible exceptional cases are. Therefore, the "unless ..." clause is appropriate. The last sentence is necessary as well, because we want the rules in Sections 3 and 4 act as the "default specification" in such case; and other parts of your comment indicate that you also prefer these rules in favor of ad-hoc rules specific to such application or implementation. >> ... >> > > ******** > > From here down (see trailing ********, i.e., all of the rest of section > 3), the discussion diverges from the main point of this doc, and > introduces a new concept of layered services. That may be a useful > concept to explore, but belongs in a separate document, and IMO is > premature. This concept is neither new nor introduced by this draft. It can be found in various RFCs and other documents -- please refer to the expired draft-gudmundsson-dns-srv-iana-registry for a list of related RFCs (look for "overlay protocols"). In Hiroshima it has been decided that using the Protocol Label to indicate layered services is not the way to go, and we have agreed to this point of view because otherwise the port number in such SRV RDATA would be ambiguous or meaningless. Therefore, when saying "no no!" and thus "closing a road", we regard it as a duty to the community to point out an alternative road leading to such goals. >> Some services can be carried equivalently in different encapsulations >> using higher-level "substrate" protocols like HTTP, BEEP, SOAP, SIP, >> XMPP, some of which in turn can be carried over different transport >> protocols. In this case, it is possible that certain servers for an >> application only support specific protocol stacks, or that a Service >> Domain provides a different set of servers for each protocol stack. >> Consequently, there occasionally is a need to specify such details in >> the SRV Service Prefix. Since the Protocol Label is intentionally >> restricted (Section 3), this information has to be carried in the >> Service Label for this application. > > Interesting idea, but currently SRVs and port numbers are assigned to > the entirety of layers 5-7 (and any shims therein). > > This proposes a completely new structure for services that should be > considered as a separate issue, and IMO is far too premature to consider > for deployment. That's part of the problem to be solved. We admit these rules and present a method to maintain the restrictions on Service Names, by suggesting a syntax that unambiguously allows to recover the Service Name from the Service Label, by using a separator character not allowed in Service Names. Again, we believe that a document that essentially makes other work non-conformant after the fact would be ill-advised if not presenting one or more alternate solutions. > >> There are two possibilities to achieve this goal: >> >> a. If there is only a small number of "substrate" protocols to >> distinguish, it is RECOMMENDED that the application designers >> register multiple Service Names with IANA in the "Service Names >> and Port Numbers" registry [RFCyyyy], which usually will start >> with the same characters and contain a suffix attached with a >> hyphen embedded in the name. > > The 15-char limit doesn't support this option. ... The 15-char limit is artificial; the legacy IANA registry for Protocols and Well-Known Services (for the DNS WKS RR) had a 40-char limit. > ... There are far too many > current names that do not have this sort of syntax. There are some service names following this model, and there are very few existing service names using the hyphen for other purposes. Thus it looks like that idea is not new and already adopted by various communities. > > Finally, any structure in the service layering should be supported in > the SRV system, not in the syntax of the namespace. But that's another way that you are opposing to. Any changes to the SRV RDATA format would make it a new RR type. Further, the IAB "Design Choices When Expanding the DNS" document (RFC 5507) strongly recommends against selectors embedded within the RDATA of new DNS RRs; you apparently are advocating to the contrary. Example: A mass storage application looking for a read/write instance of a network based file system over a particular kind of secure channel should not have to deal with the bulk of SRV RRs for read-only copies of the same file system or those only supporting another security layer, and vice versa. This can easily be accommodated by the naming scheme, but not by embedded selectors. > >> One disadvantage of this solution is the length limitation >> imposed on the Service Name by [RFCyyyy] (15 characters, see >> Section 4). Also, [RFCyyyy] recommends that -- notwithstanding >> some very popular, and mostly legacy cases -- each service ought >> to be represented by a *single* Service Name. If the service is >> the same and only the substrate used is different, this solution >> arguably is in conflict with [RFCyyyy]. >> >> b. If the number of substrate stacks to be supported is larger, or >> if the 'canonical' labels that the application designers prefer >> would result in exceeding the maximum length of Service Names, or >> if multi-layer substrates shall be represented, or if the "unique >> Service Name per service" argument is deemed important, an >> extension scheme is needed for the construction of Service Labels >> for such exceptional services. > > This goes outside the scope of the IANA ports doc; service names are 15 > chars in that doc, and that doc doesn't address extension services. This > is premature. We now accept the 15-char limitation in the IANA ports doc, and we do not expect it to support sub-layer information. We also support the deprecation of non-transport protocol names in the Protocol Labels. Therefore, have to (at least) indicate a method pointing forward for the specifications affected by these restrictions. The method specified in the Appendix is non-normative, but it is intended to guide authors of replacement specifications for the affected applications as well as developers of ne application specifications that want to incorporate it and normatively fill in the details in a manner suitable for their context. > >> The non-normative Appendix A proposes a scheme for extended >> Service Labels that does not pollute the namespace of Service >> Names and hence adheres to the uniqueness and collision-freeness >> requirements of [RFCyyyy]. The basic Service Name can be easily >> extracted from these extended Service Labels, as they employ a >> separator character not allowed in Service Names to attach >> qualifier(s) to a 'basic' Service Label as specified in >> Section 4. >> >> Application designers who want to make use of that scheme MUST >> independently and unambiguously specify the application of that >> scheme for their service and ensure that a reference to the >> document containing this specification (if different from the >> document specifying the basic service) is added to the entry for >> that service in the "Service Names and Port Numbers" IANA >> registry, following the registration procedures of [RFCyyyy]. >> >> To re-iterate, absent such explicit, registered specification, >> the rules of Section 4 (and, of course, Section 3 as well) still >> apply in these cases. >> >> Application protocol designers ought to keep service discovery >> simple. The fewer alternatives a prospective client has to consider >> and the fewer choices he has to find suitable SRV records, the faster >> the service discovery can be performed, because it needs fewer DNS >> queries on average and thus incurs less latency. If alternative >> transports and/or variations of the service are really needed to be >> distinguished by service discovery, to foster interoperablity there >> SHOULD always be defined a default version supported by all clients >> and servers, and configured in the DNS, thus allowing an orderly >> fallback in case client preferences cannot be accommodated. > > Fallback is a property of a protocol; each service has different > requirements for such backward compatibility. Fallback rules are also common elements in service discovery procedures. (Recall the MX to A RR fallback for [E]SMTP!) > If such a default or > fallback is assumed, then the SRV system should have a flag indicating > that. The fallback rule has to deal with the lack of specific DNS RRs. (There are lots of reasons, ranging from inappropriate provisioning systems and business rules down to human error.) It does not make sense to expect the information on what to do in the absence of DNS records being stored in such records! > Port numbers are not intended to have any hierarchy or alternates > of services, so such a fallback is not appropriate to indicate there. The IANA registered port numbers have always been the default port numbers for a particular service; users/deployments have always been free to use alternate ports. For instance the URI standard explicitly specifies that the absence of a port number in a URI (of a scheme supporting host names and port numbers) is to be interpreted as an indication of the default port number as registered at IANA. Why should SRV usage introduce a different model? > (each service group can do this, but it's not realistic to write a > SHOULD unless you know when it is violated and can enforce it; there's > no requirement to explain when protocols are grouped or have defaults, > so requiring application designers to do this begs the question of how). Is a strong call for simplicity and specification of a working default actually too much burden? IIRC, that's what IAB statements have been calling for over and over again. Above, you have called for stronger "MUST" requirements for documents specifying SRV usage for some application. Why would the "SHOULD" here be too strong then? > > ******** (i.e., to end of section 3) Ooops! Section 3 is essential! > ... >> 4. Standard Service Labels >> >> Absent a normative document specifying otherwise, the SRV Service >> Label for a specific service/application SHOULD be in the form of a >> "Standard SRV Servcie Label" as specified in this section. >> >> Standard SRV Service Labels MUST be formed by prepending an >> underscore character ("_") to the Service Name of an application >> protocol registered in the IANA "Service Names and Port Numbers" >> registry [RFCyyyy]. >> >> Note that in order to make use of DNS based service discovery using >> SRV records, the application/service does *not* need an IANA-assigned >> port number (which would also be filed in the IANA "Service Names and >> Port Numbers" registry). >> >> The port numbers carried in the RDATA portion of the SRV records are >> locally assigned within the Service Domain; in case the service >> indeed has an IANA-assigned (default) port number, the locally > > IANA-assigned is not indicated as "default". There's no mechanism that > specifies it as a default. Defaults -- that's what they are! We have a Full Standard saying so (see the remark on URIs above). > >> assigned port number MAY coincide with that default port number, >> unless the documentation of the service specifies otherwise (it may >> say "MUST", "SHOULD", or recommend *against* using the default). There have been instances of protocol specifications changing the recommendations over time, during their evolution! >> >> As all domain name labels, SRV Service Labels are matched in a case- >> insensitive manner. >> >> [RFCyyyy] restricts IANA-registered Service Names to 15 characters in >> "ldh-syntax", informally: > > The rest of this section should be dropped. Just cite the IANA doc. > If/when the IANA spec changes, so should this. It's a bad idea to copy > requirements into a separate doc. This has been written when the IANA ports draft was not clear with respect to formal syntax. Will be modified as the latter contains an ABNF that is consistent with the prose. > ... >> Appendix A offers a scheme for "Extended SRV Service Labels" that can >> be adopted by service specifications that cannot contend with these >> restrictions, and which seek for a versatile naming scheme not >> violating the provisions of [RFCyyyy]. > > IMO this appendix should be offered and its necessity argued in a > separate document. As stated repeatedly above, we would regard it as very poor service to the community to have a document that makes existing RFCs non- conformant and does not (at least) suggest n alternative. However, if you agree to make a normative reference to such document in the IANA ports draft to ensure coordinated publication of all these drafts and the ADs agree having to deal with yet another I-D in the IESG, that could be done, but it would simply be more work for all and increase the delays. > >> 5. Service Discovery Client Considerations >> >> Implementations making use of dynamic service discovery based on DNS >> SRV records for a particular application/service will construct a >> prioritized list of applicable Service Prefixes, following the >> guidelines in the two subsections below. > > This appears to be describing new user-side requirements for the use of > SRVs. This needs further discussion in the WG; I don't think such a > prioritized list should be required. This is observed behavior and documented in many specifications (both published and work-in-progress). It is the recommended way to deal with service discovery in the APP area. This is not a new requirement, and there's no RFC 2119 language here. > --- > > I don't understand why the remainder of this section (below) is needed; > you're just restating how to use SRVs, and the SRV spec should have said > that. Didn't it? RFC 2782 did discuss some aspects,; the material here is largely supplementary, and it contains corrections for errata in RFC 2782. Your words seem to indicate that this actually is necessary text for a clarification document. We have introduced clarifying terminology and want to provide a decription of the process in these terms. >> To form the QNAME(s) for DNS SRV lookup, each Service Prefix is >> concatenated (with a period as the label separator character) to the >> FQDN of the Service Domain the application is interested in. >> >> Depending on application strategy and perhaps local policy >> (configuration), the DNS queries with QCLASS=IN and QTYPE=SRV can be >> performed serially or in parallel -- to decrease the latency in the >> case higher priority queries do not succeed in finding matching SRV >> record(s). Delays by non-use of parallel DNS lookup are frequent complaints (cf. recent threads on the DNSOP list!), and so emphasis on this possibility seems very appropriate too. >> >> The answers obtained are processed as specified in RFC 2782 >> [RFC2782], subject to the preferences of the service client for >> transport and/or "substrate" protocols. If necessary, the Target >> domain names obtained are then queried for address records (i.e., at >> the time of this writing, A and/or AAAA RRs) to determine the network >> layer addresses to be contacted over the corresponding transport >> protocol using the port number contained in the 'Port' element of the >> respective SRV record. >> >> Note: RFC 2782 [RFC2782] on page 7 imprecisely indicates the client >> "[SHOULD] ... try to connect to the (protocol, address, service)" >> tuple. Since at the transport layer the port number needs to be >> used, not the service (name?), and to let the order of the tuple >> components follow the protocol layers, it should refer to >> "(address, protocol, port)" tuples. >> >> 5.1. Protocol Label Selection >> >> Some services are defined to operate over only one transport >> protocol. In this case the application MUST use the appropriate >> transport label in forming the Service Prefix for SRV record lookup. >> >> If a service can operate over multiple transport protocols, then the >> specification of the service might indicate an order of preference, >> or local policy may supply it. Any service can provide a specific >> order in the Notes section of the "Service Names and Port Numbers" >> registry, during registration or via registration update [RFCyyyy]. > > I don't agree; prioritization should be a property of the SRV records, > not in the notes. This seems like an extension of the protocol. No. All prioritization given inside DNS RRs is always local, i.e. relative to the RRset, not global in nature. (See the DDDS specifications for more details.) So there cannot be any assumed relationship between preference values in SRV RRs for, say, TCP and SCTP because they have distinct owner names. > >> Absent such information, the following priority order SHOULD be used > > Absent what information? The "notes" aren't in the SRV records, so as The "Notes" in the Service Names & Port Numbers registry that implementers should follow ... -- as explained in the preceding paragraph of our draft you have quoted above. > such they ought to always be absent at the endpoint - so the rest of > this is the only real recommendation here, and it's a tautology > (endpoints should use only what they can use). ... including the knowlegde built into the service discovery code by their implementors, which in turn should be based on public records (specification documents and the IANA registry), for maximum interoperability. > >> as appropriate, based on what transports are defined and registered >> for the service, and supported by the client: _udp, _tcp, _sctp, >> _dccp. >> >> 5.2. Service Label Selection >> >> Absent service specific documentation saying otherwise or hints >> available to the client (e.g., by configuration), the following >> recommendations SHOULD be followed. >> >> If an application/service has a single registered Service Name, a >> prospective client uses the Standard Service Label derived from it >> according to Section 4. >> >> Contrary to the strong recommendation in RFC 2782 [RFC2782], several >> legacy services have been assigned more than one Service Name in the >> past. For instance, the well-know "systat" service is also referred >> to as "users" service, the DNS service, "domain", is also referred to >> as "nameserver" or "dns", "rlp" is also denoted as "resource", the >> WhoIs service is identified by "whois" and "nicname", the web service >> uses "http" or "www", "kerberos" is also indicated by "kdc", and the >> PCMail service has been assigned the equivalent Service Names >> "pcmail-srv" and "pcmail". >> In all these cases, the "Service Names and Port Numbers" registry >> will clearly indicate which name is the primary one and which names >> are considered aliases. > > I don't see why this should be expected or is necessary, except for the > deprecated names whose syntax needed to change based on the IANA ports > doc. Please explain. RFC 2782 said that aliases for Service Names "SHOULD NOT" be used. The distinction can only be made and this "SHOULD NOT" be followed in practice iff the tsvwg-iana-ports registry indeed contains this (primary/alias) information. Unless you have a specified primary name, SRV RRs would have to be entered in the DNS for all possible combinations in the Service Prefix. Having an explictly marked 'canonical' name allows to restrict the wealth and to implement fallback to it in the discovery code, even if the service discovery documentation for a particular application makes an exemption to the "SHOULD NOT" quoted above. Note that this distinction is a common practice in the context of the DNS; for instance MX RRs expect 'canonical' host names in their target, not alias names introduced into the DNS via CNAME RRs. These rules help to reduce to combinatorial explosion in the DNS and to contain the effort needed for service discovery. As the draft states ... >> Unless a prospective client has specific hints available (e.g., by >> configuration) indicating that a specific alias name ought to be >> tried preferentially, the primary Service Name SHOULD be used, and >> it also SHOULD be tried if the lookup of an alias name fails. > > I don't see what this accomplishes. It seems an unnecessarily restriction. Again, as above, a good default to make success much more likely in such scenarios (if there are SRV RRs present at all, of course!). As indicated above, RFC 2782 was even more restrictive. > The rest of this section should be moved to the separate doc arguing for > extended names... See above. >> If a service/application supports different well marked instances >> identified by different Service Names or a related specification has >> introduced the usage of extended Service Labels for discovery of this >> service (e.g., making use of the scheme specified in Appendix A), the >> specifications SHOULD always also define a single default service >> instance, and hence a default Service Label or Service Name (that can >> be used to construct the the corresponding Standard Service Label). >> Prospective clients MAY follow any service instance selection policy >> desired (by implementation, deployment, or configuration), but SHOULD >> be prepared to fall back to the default service instance if the SRV >> record lookup for preferred service instance(s) fails. >> >> >> 6. Provisioning of SRV records >> >> DNS zone administrators SHOULD support (and encourage) the >> provisioning of SRV records related to the basic domains they manage. >> Dynamic DNS Update ([RFC2136], [RFC3007]) is an option, but this is >> out of scope for this document. > > IMO, SRV provisioning ought to be outside the scope of this doc > entirely. The rest of this section is not related to the indicated focus > of this doc, and if needed should be in another (third) document. > ... No. Deficiencies in the provisioning paths are among the most painful hurdles in the use of "new" RRs (those not specified in RFCs 1034/1035). If we did not spell out such considerations, SRV-based service discovery would lag behind for many more years. Application designers and users have called for RFC text they can point to if DNS operators refuse to load valid DNS RRs. A document elaborating on SRV RRs is a splendid opportunity to supply such text. Further, these deliberations are kinda "management considerations" -- as strongly encouraged by the OPS ADs. >> 7. Security Considerations >> >> This document does not have any specific security implications. > > Agreed. > >> However it is hoped that the more orderly, and more frequent use of >> SRV-based dynamic service discovery, based on the rules clarified in >> this documents and the establishment of a unified service registry, >> will provide valuable information for administrators and security >> policy makers, to the benefit of the overall security of the >> Internet. > > I have no idea why this should be true; can you explain? Having documented rules gives justification to their deployment. This avoids ad-hoc hacks to circumvent stubbornness. Regular and uniform use of SRV RRs should foster operational practices to derive filtering rules (for a service domain) from the SRV RRs of that domain. This in turn should promote use of native services and help to reduce inappropriate application-layer tunneling practices. > > The rest of this section can be omitted; it does not add to the first > sentence of this entire section, which says it all IMO. It is common practice to point to security considerations in closely related documents, and SecDir reviews and the IESG regularly seem to call for such practice. So we'll keep these short paragraphs unless SecDir/IESG statements to the contrary will be received. > >> ... > AH: Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Wed Jun 30 11:17:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFFAC3A6ABB; Wed, 30 Jun 2010 11:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.253 X-Spam-Level: X-Spam-Status: No, score=-96.253 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbHcrY47ghmz; Wed, 30 Jun 2010 11:17:15 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id C35E13A67F5; Wed, 30 Jun 2010 11:17:13 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA055681782; Wed, 30 Jun 2010 20:16:22 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA26126; Wed, 30 Jun 2010 20:16:21 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006301816.UAA26126@TR-Sys.de> To: namedroppers@ops.ietf.org, dnsop@ietf.org, apps-discuss@ietf.org Date: Wed, 30 Jun 2010 20:16:20 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [apps-discuss] New Version Notification - draft-gudmundsson-dnsext-srv-clarify-01.txt (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 18:17:15 -0000 My apologies for cross-posting, but this is inherently a cross-wg and cross-area topic: The revised draft contains clarifications for DNS service discovery using SRV RRs and suggests methods to deal with the restrictions imposed by draft-ietf-tsvwg-iana-ports. It is intended that both drafts will eventually be published in a coordinated manner. Abstract The DNS SRV record has been specified in RFC 2052 and RFC 2782 for use in dynamic service discovery for a domain. These two RFCs did not clearly specify an IANA registry for the names of the services and their underlying protocols. This document clarifies RFC 2782 regarding the formation and use of the Service Prefix in the owner name of SRV records, based on the unified IANA registry for "Service Names and Transport Protocol Port Numbers". Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- Forwarded message from Internet-Draft@ietf.org ----- > From: Internet-Draft@ietf.org > Message-Id: <20100630180001.DEC133A6A84@core3.amsl.com> > Date: Wed, 30 Jun 2010 11:00:01 -0700 (PDT) > Subject: New Version Notification - > draft-gudmundsson-dnsext-srv-clarify-01.txt > New version (-01) has been submitted for > draft-gudmundsson-dnsext-srv-clarify-01.txt. > > http://www.ietf.org/internet-drafts/draft-gudmundsson-dnsext-srv-clarify-01.txt > > > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=draft-gudmundsson-dnsext-srv-clarify-01 > > IETF Secretariat. > ----- End of forwarded message from Internet-Draft@ietf.org ----- From touch@isi.edu Wed Jun 30 11:47:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CA028C0FD; Wed, 30 Jun 2010 11:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh3cNm3VIY37; Wed, 30 Jun 2010 11:47:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 090173A6A82; Wed, 30 Jun 2010 11:47:23 -0700 (PDT) Received: from [75.212.107.9] (9.sub-75-212-107.myvzw.com [75.212.107.9]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5UIidLH022615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jun 2010 11:44:50 -0700 (PDT) Message-ID: <4C2B9097.4060009@isi.edu> Date: Wed, 30 Jun 2010 11:44:39 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alfred_=3F?= References: <201006301801.UAA26017@TR-Sys.de> In-Reply-To: <201006301801.UAA26017@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig11C26585775D6B3276946C7B" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: namedroppers@ops.ietf.org, tsvwg@ietf.org, apps-discuss@ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: Re: [apps-discuss] [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 18:47:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig11C26585775D6B3276946C7B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Alfred, Alfred ? wrote: =2E.. > Please do not neglect the criticism spelled out repeatedly for > draft-ietf-tsvwg-iana-ports but rejected by your team. This > draft tries to accommodate the restrictions imposed by that memo. > Yet, to be useful for aligning previous RFCs now deemed non- > conformant with these rules and recent/ongoing work specifically > calling for multi-label hierarchical Service Prefixes, this > draft needs to show a uniform path that can be recommended > to the authors / WGs where these RFCs are originating from. >=20 > Thus, as a replacement mechanism for specifications using > Service Prefixes with non-transport protocol Protocol Labels > and/or more than two labels, the non-normative extension > mechanism proposed is an essential part of this memo. >=20 > Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports > on the lenght of Service Names and the one-servie-name-per- > application rule are being relaxed substantially, this extension > mechanism will remain in this document. I don't understand this position. Sec 5 of that doc allows aliases. The o= nly constraint is that one be designated primary so that reverse lookups can determine when aliasing occurs. draft-ietf-tsvwg-iana-ports is updating the length of service names. Havi= ng this document concurrently undermine that update, especially in a "non-normati= ve" appendix seems inconsistent at best. I'd expect that a substantive change to the specification of SRV names - = i.e., introducing a hierarchical namespace - would require a standards-track do= cument whose main body focused on the changes proposed, and that they need to be= coordinated with draft-ietf-tsvwg-iana-ports. Can you clarify? Joe --------------enig11C26585775D6B3276946C7B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwrkJcACgkQE5f5cImnZrsQAgCgjZzZyltk1ACWtltxbYPW2xX5 y34AnAoVdL+G3tDzkAM6FUAWHgvI3ZfB =3qtd -----END PGP SIGNATURE----- --------------enig11C26585775D6B3276946C7B-- From A.Hoenes@TR-Sys.de Wed Jun 30 13:07:34 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B493A68F3; Wed, 30 Jun 2010 13:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.946 X-Spam-Level: X-Spam-Status: No, score=-95.946 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYHMy46DcUOG; Wed, 30 Jun 2010 13:07:33 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 788DF3A68B3; Wed, 30 Jun 2010 13:07:31 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA056088378; Wed, 30 Jun 2010 22:06:18 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA26281; Wed, 30 Jun 2010 22:06:16 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006302006.WAA26281@TR-Sys.de> To: touch@isi.edu Date: Wed, 30 Jun 2010 22:06:16 +0200 (MESZ) In-Reply-To: <4C2B9097.4060009@isi.edu> from Joe Touch at Jun "30, " 2010 "11:44:39" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org, tsvwg@ietf.org, apps-discuss@ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: Re: [apps-discuss] [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 20:07:34 -0000 Joe Touch wrote: > Hi, Alfred, > > Alfred H=CEnes wrote: > ... >> Please do not neglect the criticism spelled out repeatedly for >> draft-ietf-tsvwg-iana-ports but rejected by your team. This >> draft tries to accommodate the restrictions imposed by that memo. >> Yet, to be useful for aligning previous RFCs now deemed non- >> conformant with these rules and recent/ongoing work specifically >> calling for multi-label hierarchical Service Prefixes, this >> draft needs to show a uniform path that can be recommended >> to the authors / WGs where these RFCs are originating from. >> >> Thus, as a replacement mechanism for specifications using >> Service Prefixes with non-transport protocol Protocol Labels >> and/or more than two labels, the non-normative extension >> mechanism proposed is an essential part of this memo. >> >> Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports >> on the lenght of Service Names and the one-service-name-per- >> application rule are being relaxed substantially, this extension >> mechanism will remain in this document. > > I don't understand this position. Sec 5 of that doc allows aliases. > The only constraint is that one be designated primary so that > reverse lookups can determine when aliasing occurs. Sorry Joe, the quote above is the summary I had prepended to my detailed response. You have silently cut off the pointer to in-depth inline responses. Do I have to conclude that you pushed out a response without having read either the details of my response nor the new draft version? I have no idea what reverse lookup has to do with the topic. RFC 2782 calls for a "primary" *service name* in the Service Label of an SRV RR. If the new registry does not contain this important tag to distinguish the primary service name from the aliases (if present) -- as we had requested repeatedly --, it cannot be used as a reasonable guide for users and admins. It looks like you once more deliberately mangle the "alias" topic with the "one-service-name-per-application" rule in your draft that recommends against assigning multiple service names to the instances of a particular service offered over different intermediate "substrate" layers (for instance HTTP, SIP, XMPP, etc.) or employing different security services. This all is discussed in detail in various sections of our draft -- interestingly just in those that you once have suggested to drop. Please read these sections; you might have skipped text prematurely. > > draft-ietf-tsvwg-iana-ports is updating the length of service names. > Having this document concurrently undermine that update, especially > in a "non-normative" appendix seems inconsistent at best. Don't bend facts, please. We accept the back-cutting of the maximum lenght for *service names* from 40 chars (RFC 952) to 15 chars (tsvwg-iana-ports). This has nothing to do with the canonical limit for DNS labels (63 char), but the latter gives room for extensions to service labels -- iff the related specification explicitly wants to do that. We purposely suggest to construct extended service labels in a manner that does not conflict with the definition of service names and the related restrictions in your draft, and that allows instantaneous recognition of the basic service name used to construct the service label. You still neglect the presence of RFCs 4386, 3921, 5026, 5509 et al. These are IETF specifications for service prefixes not conforming to the rules you want and the rules we have accepted to inforce in our draft for standard service prefixes. Unless you point out a workable solution of your own for a sensical revision of the various service prefixes defined in Standards Track RFCs like _im._sip, _pres.xmpp or _pkixrep._ocsp, you should stop to argue against our offered extended prefix system. The same document that accepts your restrictions needs to offer a solution. We are not protocol gods saying just *no* (as you apparently want) and now declaring a "sin" documents once approved by the IESG. When we introduce restrictions (negotiated as a compromise with you), we want to present a workaround as well, as an offer to document authors that want to revise affected RFCs (and other specifications) now becoming non-conformant, an offer that *can* be adopted on a case-by-case (per application spec) scenario. This offer is an integral part of our acceptance of the restrictions you want to impose. > > I'd expect that a substantive change to the specification of SRV > names - i.e., introducing a hierarchical namespace - would require > a standards-track document whose main body focused on the changes > proposed, and that they need to be coordinated with > draft-ietf-tsvwg-iana-ports. Please answer the related question I have posed in my response: Are you willing to make a *useful* alternate proposal or to refer normatively in tsvwg-iana-ports to such additional document, such that it is ascertained that the new restrictions will not be published without coordinated publication of a document showing a way out of the dilemma for several existing Standards Track RFCs? Or do you now intend to Obsolete with tsvwg-iana-ports all the RFCs once listed in draft-gudmundsson-dns-srv-iana-registry as references for service prefixes to be considered non-conformant in the future -- as per the agreement in Hiroshima? I strongly suspect that you will run into trouble in the IESG with such intent. > > Can you clarify? > > Joe I think my detailed responses and the revised draft submitted today (draft-gudmundsson-dnsext-srv-clarify-01) should contain enough clarification. Please read on. Due to time constraints (business needs and short vacation before IETF), I'll become unavailable for email discussion soon, and therefore I suggest that we discuss the topic in Maastricht. Kind regards, Alfred. From touch@isi.edu Wed Jun 30 15:01:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918823A69C6; Wed, 30 Jun 2010 15:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aBh1P7WPaLn; Wed, 30 Jun 2010 15:01:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6134A3A659C; Wed, 30 Jun 2010 15:01:42 -0700 (PDT) Received: from [75.212.107.9] (9.sub-75-212-107.myvzw.com [75.212.107.9]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5UM1CIT008132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jun 2010 15:01:22 -0700 (PDT) Message-ID: <4C2BBEA8.6070904@isi.edu> Date: Wed, 30 Jun 2010 15:01:12 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201006302006.WAA26281@TR-Sys.de> In-Reply-To: <201006302006.WAA26281@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF73847D2795F0A1F115B1358" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: namedroppers@ops.ietf.org, tsvwg@ietf.org, apps-discuss@ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: Re: [apps-discuss] [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jun 2010 22:01:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF73847D2795F0A1F115B1358 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alfred, Alfred =EF=BF=BD wrote: > Joe Touch wrote: >=20 >> Hi, Alfred, >> >> Alfred H=EF=BF=BDnes wrote: >> ... >>> Please do not neglect the criticism spelled out repeatedly for >>> draft-ietf-tsvwg-iana-ports but rejected by your team. This >>> draft tries to accommodate the restrictions imposed by that memo. >>> Yet, to be useful for aligning previous RFCs now deemed non- >>> conformant with these rules and recent/ongoing work specifically >>> calling for multi-label hierarchical Service Prefixes, this >>> draft needs to show a uniform path that can be recommended >>> to the authors / WGs where these RFCs are originating from. >>> >>> Thus, as a replacement mechanism for specifications using >>> Service Prefixes with non-transport protocol Protocol Labels >>> and/or more than two labels, the non-normative extension >>> mechanism proposed is an essential part of this memo. >>> >>> Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports >>> on the lenght of Service Names and the one-service-name-per- >>> application rule are being relaxed substantially, this extension >>> mechanism will remain in this document. >> I don't understand this position. Sec 5 of that doc allows aliases. >> The only constraint is that one be designated primary so that >> reverse lookups can determine when aliasing occurs. >=20 > Sorry Joe, > the quote above is the summary I had prepended to my detailed response.= > You have silently cut off the pointer to in-depth inline responses. That is because I am addressing the summary. If the summary does not accu= rately portray the remainder of the contents, you should address that. > I have no idea what reverse lookup has to do with the topic. > RFC 2782 calls for a "primary" *service name* in the Service Label > of an SRV RR. If the new registry does not contain this important > tag to distinguish the primary service name from the aliases (if > present) -- as we had requested repeatedly --, it cannot be used > as a reasonable guide for users and admins. The IANA draft already indicates that one name needs to be assigned as pr= imary (from Sec 5): ... In such cases, one of the service names SHOULD be designated primary, for use with mechanisms such as DNS SRV Records [RFC2782], and the others SHOULD be designated as aliases of the primary service name... > It looks like you once more deliberately mangle the "alias" topic > with the "one-service-name-per-application" rule in your draft > that recommends against assigning multiple service names to the > instances of a particular service offered over different intermediate > "substrate" layers (for instance HTTP, SIP, XMPP, etc.) or employing > different security services.=20 Draft-ietf-tsvwg-iana-ports states that: o IANA will allocate only one assigned port number for all versions of a service (e.g., running the service with or without a security mechanism, or for updated variants of a service) Versions means version 1, version 2, etc. This is to avoid allocating dif= ferent ports as was done with HTTP and HTTPS, esp. since TLS allows the negotiat= ion of optional security, where the goal is to allocate the secure version of th= e protocol and allow that protocol to negotiate when and whether security i= s required. The goal is to avoid allocating new ports where the service sho= uld be capable of negotiating in-band. However, it is currently common practice to allocate different ports for different "stacks", e.g., X over HTTP, X over SOAP - i.e., where such negotiation in-band is not possible. Layering info is included in the nam= e when multiple such requests are received concurrently, but not when a single r= equest is received (e.g., a control protocol that happens to use XML over HTTP d= oes not necessarily include either in the short name). In summary, what part of draft-ietf-tsvwg-iana-ports are you disagreeing = with? Also, with specific reference to your 01 doc, can you clarify whether it = is consistent with draft-ietf-tsvwg-iana-ports on the following point?: ...Any system that includes a service name inside a longer string is itself responsible for delineating the service name. Such systems MUST NOT rely on the syntax of a service name alone for such delineation. FWIW, this is the part where I think draft-ietf-tsvwg-iana-ports and your= draft disagree, as well as our section 5.2. > You still neglect the presence of RFCs 4386, 3921, 5026, 5509 et al. > These are IETF specifications for service prefixes not conforming > to the rules you want and the rules we have accepted to inforce > in our draft for standard service prefixes. > Unless you point out a workable solution of your own for a sensical > revision of the various service prefixes defined in Standards Track > RFCs like _im._sip, _pres.xmpp or _pkixrep._ocsp, you should stop > to argue against our offered extended prefix system. =46rom RFC 2782: Proto The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Proto is case insensitive. "xmpp" is does not have an Assigned Number, and is not being used 'locall= y', and was never registered with the SRV registry either. Yes, there appear to b= e a few other uses of SRV records other than for the kind of services indicated i= n the IANA ports tale or the SRV registry. It would be worthwhile indicating those exceptions, but AFAICT they are u= ses of DNS SRV records for discovery of capabilities outside the scope of the iana-ports document (i.e., NOT referring to "L7-L5 service stacks over a transport protocol", for lack of a better description). >> I'd expect that a substantive change to the specification of SRV >> names - i.e., introducing a hierarchical namespace - would require >> a standards-track document whose main body focused on the changes >> proposed, and that they need to be coordinated with >> draft-ietf-tsvwg-iana-ports. >=20 > Please answer the related question I have posed in my response: > Are you willing to make a *useful* alternate proposal or to refer > normatively in tsvwg-iana-ports to such additional document, > such that it is ascertained that the new restrictions will not > be published without coordinated publication of a document > showing a way out of the dilemma for several existing Standards > Track RFCs? If you want to propose an alternate structure, e.g., using either a diffe= rent record type, or somehow can be recognized as not supporting the current u= se (without *internal* parsing of the service name), then that might be a wa= y forward. Joe --------------enigF73847D2795F0A1F115B1358 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwrvqgACgkQE5f5cImnZrtAqACg9MbZI44zUypCnWIaq/WPtBFy flAAoIfln/vbgdiREuZpaFA0Oo8fO462 =ryai -----END PGP SIGNATURE----- --------------enigF73847D2795F0A1F115B1358--