From stpeter@stpeter.im Fri May 7 10:08: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 A0BE33A686D for ; Fri, 7 May 2010 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.307 X-Spam-Level: X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-2.312, BAYES_50=0.001, SARE_RMML_Stock10=0.13, STRONG_BUY=2.488] 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 ipJYhPA0ocn5 for ; Fri, 7 May 2010 10:08:34 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EFF913A65A6 for ; Fri, 7 May 2010 10:08:33 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2EB4D40E14 for ; Fri, 7 May 2010 11:08:21 -0600 (MDT) Message-ID: <4BE44903.8090207@stpeter.im> Date: Fri, 07 May 2010 11:08:19 -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 #1 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="------------ms080907060501090809000400" 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, 07 May 2010 17:08:35 -0000 This is a cryptographically signed message in MIME format. --------------ms080907060501090809000400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Under Lisa's tenure as Area Director, I always looked forward to her reports about activities in the Applications Area. This is my first step at maintaining that tradition, although I'm not yet sure how often I will provide reports (perhaps after each IESG formal telechat and after each IETF meeting). This report covers IETF 77 through the IESG telechat on May 6, 2010. 1. WORKING GROUP STATUS ALTO Application-Layer Traffic Optimization http://tools.ietf.org/wg/alto/ The group held a successful meeting at IETF 77, which unfortunately I was unable to attend because I needed to chair another WG session. The chairs report good progress on the two WG drafts: http://tools.ietf.org/html/draft-ietf-alto-protocol http://tools.ietf.org/html/draft-ietf-alto-reqs There is talk of holding a virtual interim meeting to maintain forward momentum, which I think is a great idea. CALSIFY Calendaring and Scheduling Standards Simplification http://tools.ietf.org/wg/calsify/ No meeting at IETF 77. This group has only one document left to publish: http://tools.ietf.org/html/draft-ietf-calsify-rfc2447bis It's on my list to complete an AD review of that document next week. Ideally we will work to close down this WG in the relatively near future, because we need to make way for new initiatives. :) CORE Constrained RESTful Environments http://tools.ietf.org/wg/core/ The former "6LOWAPP" team was renamed to CORE upon WG formation. The group held its first meeting at IETF 77, with plenty of discussion about wire formats (HTTP subset vs. a binary syntax that's HTTP-like) and underlying transports (UDP only or also TCP?). There is no official working group document yet, but the group had an April 2010 milestone to select a WG document as a starting point for work on the Constrained Application Protocol ("CoAP"). The primary candidate seems to be this one= : http://tools.ietf.org/html/draft-shelby-core-coap I'll poke the chairs about issuing a consensus call. :) See also the requirements document: http://tools.ietf.org/html/draft-shelby-core-coap-req HTTPSTATE HTTP State Management Mechanism http://tools.ietf.org/wg/httpstate/ Successful meeting at IETF 77. The group is dedicated solely to updating documentation of HTTP cookies: http://tools.ietf.org/html/draft-ietf-httpstate-cookie-08 Right before IETF 77, Eran Hammer-Lahav stepped down as co-chair because of other commitments, leaving only Jeff Hodges as chair. Given the limited scope of the WG and the great job being done by document editor Adam Barth, we'll probably stay with one chair unless Jeff asks for help.= BTW this WG had made good use of the issue tracker, and most of the WG session at IETF 77 was devoted to closing out open issues: http://trac.tools.ietf.org/wg/httpstate/trac/report/6 IRI Internationalized Resource Identifiers http://tools.ietf.org/wg/iri/ As with CORE, the IRI WG held its first WG session at IETF 77. As with HTTPSTATE, the IRI WG is dedicated to a single document, a revision of RFC 3987: http://tools.ietf.org/html/draft-ietf-iri-3987bis Ted Hardie volunteered to get the group off the ground on a temporary basis, and has now been replaced by the duo of Marc Blanchet and Addison Phillips (yes, it takes two people to replace Ted!). Expect quite a bit of activity from Marc, Addison, and the document editors in the near futu= re. OAUTH Open Authentication Protocol http://tools.ietf.org/wg/oauth/ I could write an entire report about the OAuth WG, which I co-chaired with Blaine Cook before Hannes Tschofenig took over for me. The WG was chartered about a year ago but held its first WG session at IETF 77, and during that time the market has changed quite a bit, leading to a desire for something closer to OAuth 2.0 than the OAuth 1.1 that was originally envisioned (along with consequent milestone slippage). The IETF 77 session and follow-up discussions have been a bit disorderly, but out of that seeming chaos has emerged a specification that appears to have strong buy-in from most of the WG participants: http://tools.ietf.org/html/draft-ietf-oauth-v2-02 The group will hold a one-day interim meeting on May 20, 2010, in Sunnyvale, California, for the purpose of working through open issues and coming to agreement on the path forward. Details are here: http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeeting VCARDDAV vCard and CardDAV http://tools.ietf.org/wg/vcarddav/ Successful meeting at IETF 77. The current working group items are an update to the core vCard format, as well as an XML representation of that format: http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml Based on discussions at IETF 77 and shortly thereafter, these documents seem to be well on the way to being ready for WGLC. It's probably time for the AD to ping the chairs about that. :) In addition, draft-ietf-vcarddav-carddav is in the RFC Editor queue, waiting on advancement of draft-ietf-vcarddav-vcardrev as a normative reference. VWRAP Virtual World Region Agent Protocol http://tools.ietf.org/wg/vwrap/ VWRAP is the working group formerly known as OGPX (and before that the MMOX BoF, for those who remember the broader topics discussed at IETF 74). The group held a good meeting at IETF 77. A number of individual drafts are under consideration, but there are no WG items as yet. I really need to read through the entire corpus one of these days... 2. WG FORMATION & LIKELY BOFS "NEWPREP" We held a successful BoF at IETF 77 about approaches for updating or replacing Stringprep in application protocols. An updated charter for a working group has passed IESG internal review and will soon be published for external review. Discussion here: https://www.ietf.org/mailman/listinfo/newprep "URNBIS" Because there is interest in holding a BoF at IETF 78 about possible updates to the core specifications for Uniform Resource Names (URNs), we have formed a new mailing list: https://www.ietf.org/mailman/listinfo/urn A first cut at a possible charter is here: http://www.ietf.org/mail-archive/web/urn/current/msg00002.html Join the list for discussion, but remember to post requests for URN namespace identifiers to the old urn-nid list: https://www.ietf.org/mailman/listinfo/urn-nid 3. INDIVIDUAL DRAFTS I'm watching the following documents: http://tools.ietf.org/html/draft-desruisseaux-ischedule (this one is a bit farther out on my schedule, but I will review it during May) http://tools.ietf.org/html/draft-giralt-schac-ns (authors pinged about a revised I-D) http://tools.ietf.org/html/draft-hammer-hostmeta (I'll complete an AD review next week) http://tools.ietf.org/html/draft-rosen-urn-nena (author pinged about a revised I-D) Also watching http://tools.ietf.org/html/draft-oiwa-http-mutualauth informally -- I met with the authors at IETF 77 and hope to provide them with more structured feedback in the next few weeks. 4. MY DRAFTS Jeff Hodges and I are working on a draft about "Representation and Verification of Application Server Identity in Certificates Used with Transport Layer Security", which we hope will serve as a set of best practices for application protocols. We submitted an updated version on April 30 and are actively seeking feedback from application developers, certification authorities, and service providers. http://tools.ietf.org/html/draft-saintandre-tls-server-id-check I'm also pushing to complete work on two documents for the XMPP WG, which was under Apps in its first instantiation (2002-2004) and is now under RAI. The XMPP WG has milestones to send rfc3920bis and rfc3921bis to the IESG in August, and once those are done I'll have even more time for my AD responsibilities. http://tools.ietf.org/html/draft-ietf-xmpp-3920bis http://tools.ietf.org/html/draft-ietf-xmpp-3920bis 5. IESG ACTIVITIES Now I know why area directors are so busy -- they need to review and comment on 500+ pages of Internet-Drafts every two weeks. Since joining the IESG at IETF 77, I have lodged DISCUSSes on the following I-Ds (and probably a few others I've forgotten): draft-ietf-mediactrl-sip-control-framework-11 draft-ietf-mediactrl-ivr-control-package-08 draft-ietf-mediactrl-mixer-control-package-11 draft-ietf-sipcore-info-events-07 draft-haberman-rpsl-reachable-test-03 draft-ietf-sipping-config-framework-17 draft-ietf-netmod-yang-12 draft-ietf-keyprov-symmetrickeyformat-08 draft-ietf-isms-dtls-tm-12 draft-josefsson-kerberos5-starttls-08 draft-ietf-keyprov-pskc-05 draft-ietf-keyprov-dskpp-10 draft-nottingham-http-link-header-09 Do let me know if you think I'm being too tough on I-D authors. ;) 6. UPCOMING EVENTS As mentioned, the OAuth WG will hold a one-day interim meeting in the Bay Area on May 20. I will be attending the IESG retreat in New York City on May 23+24. Planning has started for IETF 78 July 25-30, 2010, in Maastricht, the Netherlands. Working Group chairs, send in your meeting requests before June 14: https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi If you want to schedule a BoF, please contact me or Alexey as soon as possible. The deadline is June 1. Instructions are here: http://www.ietf.org/iesg/bof-procedures.html 7. CONTACT & COMMUNICATION In my humble opinion, communication is a key to success (maybe that's why I've worked on instant messaging protocols all these years). Before IETF 77 I attempted to have one-on-one phone conversations with chairs of all the working groups I advise, and I plan to reach out to those folks again in the next few weeks. However, if you have any questions or concerns or ideas for improvement, please feel free to contact me via email, IM, or phone -- my contact information is here: https://stpeter.im/index.php/contact/ I think that's it for now! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080907060501090809000400 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 hvcNAQkFMQ8XDTEwMDUwNzE3MDgxOVowIwYJKoZIhvcNAQkEMRYEFMWsrOjwBLopsONV7fKk xQPPeRF+MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEASbaOx6C91OPCfE5pMnXzPCF/YRoSHACxiBV0/CgA +jHr3Vm+6Ag1ckjyITr46E7S3iVBsX957A6St4I79H0wrsD9eq1msuc65iNiQh+OU+LIB6ae UlM60NEMPSTb4WfTSqVPMh57WMHhir03sEkPNhG1J9CJ6r/K08UaxQFrPc7zYDbIvdwiLXke 9GhFdrv2Znhjwg8u44DbUY+38KHGAC5fx2b4uJJZ5DLLbhqdaonyb6JPn3X3UxL/473q3HDn SadfLZgMuGHDkkLuOlGH7LoNBUgGl9LeKAD+aAWrrNDXlsBe8guPJLND0VYvQm2TaX0vpdWt XSJUyJbudDHBXwAAAAAAAA== --------------ms080907060501090809000400-- From robmcm@microsoft.com Fri May 7 15:05: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 AD5693A694A for ; Fri, 7 May 2010 15:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.574 X-Spam-Level: X-Spam-Status: No, score=-8.574 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_50=0.001, 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 nkgG2XuuooxY for ; Fri, 7 May 2010 15:05:26 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 60DB73A67A1 for ; Fri, 7 May 2010 15:05:26 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 7 May 2010 15:05:13 -0700 Received: from TK5EX14MBXC125.redmond.corp.microsoft.com ([169.254.5.139]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Fri, 7 May 2010 15:05:13 -0700 From: Robert McMurray To: 'Anthony Bryan' , Tim Kosse , "apps-discuss@ietf.org" Subject: draft-bryan-ftp-hash Thread-Topic: draft-bryan-ftp-hash Thread-Index: AcruMV1s5uMcLJj9TfSqnpMSrqNTSA== Date: Fri, 7 May 2010 22:05:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= 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, 07 May 2010 22:05:27 -0000 Anthony Bryan and I had been discussing draft-bryan-ftp-hash with Tim Kosse= in an offline conversation, but we should consolidate our discussions in a= more public forum. With that in mind, what I had proposed to Anthony was that you might specif= y the hash type as parameter of the client request and server response, the= reby allowing the server and client to continuously know which hashing algo= rithm is in use. For example: C> HASH SP S> 213 SP I had mentioned that might be optional as a HASH request paramet= er since the draft had already specified using the OPTS command to specify = a hash algorithm, but I recommended that the response should return the has= h algorithm. Anthony had expressed some interest in the response containing the , but Tim made an excellent point that it would be impossible to make the= optional as a HASH request parameter because there is no standa= rd for , therefore the server wouldn't know whether "HASH MD5 foo= " meant to hash the file "foo" using "MD5" or to hash the file "MD5 foo" us= ing the current algorithm that was specified with an earlier OPTS command. If was a mandatory parameter for both the client request and ser= ver response that would address Tim's point, but that would dramatically al= ter Anthony's original design. Setting aside the discussion for the HASH request parameter for the moment,= we could differentiate the from or even b= y defining the characters that the can contain by using ABNF lik= e the following: hashtype =3D let-dig [ldh-str] let-dig =3D ALPHA / DIGIT ldh-str =3D *( let-dig / "-" ) let-dig This syntax would allow for hashing algorithms like MD5, XCRC, CRC32, SHA-2= 56, etc., but I'll leave it open for debate if that would be too restrictiv= e. Robert McMurray US-IIS Product Unit Email: robmcm@microsoft.com From alexey.melnikov@isode.com Sat May 8 04:00: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 696C03A6A2C for ; Sat, 8 May 2010 04:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.551, 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 5qBcKKhwCGsv for ; Sat, 8 May 2010 04:00:10 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 690203A6A1D for ; Sat, 8 May 2010 04:00:07 -0700 (PDT) Received: from [92.40.114.76] (92.40.114.76.sub.mbb.three.co.uk [92.40.114.76]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 8 May 2010 11:59:53 +0100 Message-ID: <4BE54408.5030807@isode.com> Date: Sat, 08 May 2010 11:59:20 +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 Subject: [Fwd: Protocol Action: 'Web Linking' to Proposed Standard] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------060309060400050106030003" 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, 08 May 2010 11:00:11 -0000 This is a multi-part message in MIME format. --------------060309060400050106030003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI. --------------060309060400050106030003 Content-Type: message/rfc822; name="Protocol Action: 'Web Linking' to Proposed Standard" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Protocol Action: 'Web Linking' to Proposed Standard" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.6v0) with LMTP; Fri, 07 May 2010 20:58:26 +0100 (BST) Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Fri, 7 May 2010 20:58:25 +0100 X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1293A6980; Fri, 7 May 2010 12:58:25 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 448373A6924; Fri, 7 May 2010 12:58:23 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'Web Linking' to Proposed Standard Message-Id: <20100507195824.448373A6924@core3.amsl.com> Date: Fri, 7 May 2010 12:58:24 -0700 (PDT) Cc: Internet Architecture Board , RFC Editor X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org The IESG has approved the following document: - 'Web Linking ' as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-10.txt Technical Summary This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header-field. Working Group Summary This is not a WG document. However, it was well-reviewed on the HTTPBIS WG mailing list. Document Quality This document focuses on registration and review of HTTP Link relations, and has been reviewed by IANA. Personnel Julian Reschke is the document shepherd. Lisa Dusseault was the original responsible AD. Alexey Melnikov is the current responsible AD. RFC Editor Note In the Section 6.2.1, please replace "[TBD]@ietf.org" with "link-relations@ietf.org" and "[TBD-2]@ietf.org" with "link-relations-announce@ietf.org". _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------060309060400050106030003-- From daniel@haxx.se Sat May 8 13:59:07 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 4E3D53A68CD for ; Sat, 8 May 2010 13:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_50=0.001, HELO_EQ_SE=0.35] 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 P-lhQ-66IJKD for ; Sat, 8 May 2010 13:59:06 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by core3.amsl.com (Postfix) with ESMTP id D25163A67F6 for ; Sat, 8 May 2010 13:59:05 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with ESMTP id o48KwccW005355; Sat, 8 May 2010 22:58:38 +0200 Date: Sat, 8 May 2010 22:58:38 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Robert McMurray Subject: Re: draft-bryan-ftp-hash In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-15?Q?Alfred_H=CEnes?= , "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: Sat, 08 May 2010 20:59:07 -0000 On Fri, 7 May 2010, Robert McMurray wrote: > If was a mandatory parameter for both the client request and > server response that would address Tim's point, but that would dramatically > alter Anthony's original design. It would rather take it back to the original design (seen in draft-bryan-ftp-hash-00), as that first draft had in the HASH command. The reasoning for the removal of it and putting it into the OPTS command was, I believe, that it wasn't "FTPish" to take two different arguments like that in a single command. > Setting aside the discussion for the HASH request parameter for the moment, > we could differentiate the from or even by > defining the characters that the can contain by using ABNF like > the following: I would rather have it _either_ mandatory in the HASH command as the first argument _or_ only set with the OPTS command like draft-bryan-ftp-hash-02 says. I favour the -00 style slightly, but I don't feel strongly either way. -- / daniel.haxx.se From tim.kosse@filezilla-project.org Sun May 9 14:37:53 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 EB2543A6842 for ; Sun, 9 May 2010 14:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, 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 OwBV8lvh0aIz for ; Sun, 9 May 2010 14:37:53 -0700 (PDT) Received: from filezilla-project.org (cl-1464.dus-01.de.sixxs.net [IPv6:2a01:198:200:5b7::2]) by core3.amsl.com (Postfix) with ESMTP id D84893A67AD for ; Sun, 9 May 2010 14:37:52 -0700 (PDT) Received: from [2a01:198:458::59] by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OBEBp-0005fJ-EB; Sun, 09 May 2010 23:37:38 +0200 Message-ID: <4BE72B0E.5040305@filezilla-project.org> Date: Sun, 09 May 2010 23:37:18 +0200 From: Tim Kosse User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: draft-bryan-ftp-hash-02 experimental server implementation X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig817D0469F9FB0EFB782BC453" 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, 09 May 2010 21:37:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig817D0469F9FB0EFB782BC453 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have created an experimental build of FileZilla Server which implements draft-bryan-ftp-hash-02. The installer for Win32 can be downloaded from http://filezilla-project.org/codesquid/draft-bryan-ftp-hash/FileZilla_Ser= ver_draft-bryan-ftp-hash-02.exe Regards, Tim Kosse --------------enig817D0469F9FB0EFB782BC453 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) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvnKxkACgkQ8N9+lcqiUkV0pACg9l0mfKurwAc65vLWe7VN+rPD 7uoAoOyUv+EsfDtXL9mCEWUuB86aPcVx =7veh -----END PGP SIGNATURE----- --------------enig817D0469F9FB0EFB782BC453-- From alexey.melnikov@isode.com Mon May 10 11:02:40 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 CB7A23A6A2D; Mon, 10 May 2010 11:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=-0.594, 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 pbq+BkiBKQu4; Mon, 10 May 2010 11:02:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 657F33A69FC; Mon, 10 May 2010 11:02:27 -0700 (PDT) Received: from [172.16.2.198] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 10 May 2010 19:02:15 +0100 Message-ID: <4BE84A03.4090101@isode.com> Date: Mon, 10 May 2010 19:01:39 +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-review@ietf.org, Apps-Discuss@ietf.org Subject: Looking for a new Apps Review Team Leader MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; 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: Mon, 10 May 2010 18:02:40 -0000 Peter and I are looking for a new Apps Area Review Team Leader. The main task of the Team Leader is to find suitable reviewers from the apps-review team and to make sure that reviews are done in a timely manner. If you are interested, please reply directly to Peter and myself. Alexey, as Apps ADs. From eran@hueniverse.com Tue May 11 23:44: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 314563A6CA4 for ; Tue, 11 May 2010 23:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-1.133, 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 BFdGPuRougDf for ; Tue, 11 May 2010 23:44:33 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B98343A6C9A for ; Tue, 11 May 2010 23:44:32 -0700 (PDT) Received: (qmail 10391 invoked from network); 12 May 2010 06:44:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 May 2010 06:44:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 11 May 2010 23:44:21 -0700 From: Eran Hammer-Lahav To: "discuss@apps.ietf.org" Date: Tue, 11 May 2010 23:44:30 -0700 Subject: Update on resource descriptor discovery work Thread-Topic: Update on resource descriptor discovery work Thread-Index: AcrxnpKcHxKdQRGJRGmxdeIPs3YKVQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "www-tag@w3.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: Wed, 12 May 2010 06:44:34 -0000 Just a quick update on the status of the various parts of the discovery wor= k presented at the last IETF Apps meeting: - What started as site-meta and changed into Well-known URIs is now RFC 578= 5 [1]. - Web Linking [2] was approved for RFC publication with a new registry for = link relation types. - XRD 1.0 [3] is moving to Committee Standard next week (OASIS). - host-meta [4] is under review by the Apps area director and pending IETF = last call. - New draft available for LRDD [5], incorporating all the feedback received= (mostly editorial), and hopefully ready for last-call in a week. - First draft for 'acct' URI for accounts (as used by the WebFinger protoco= l [6]) is due shortly. I'm starting to see the light at the end of the tunnel... :-) If you care about any of this, it is critical to review the host-meta [4] a= nd LRDD [5] documents. They are both short and include plenty of detailed e= xamples. Feedback would be greatly appreciated on the Apps Discuss list. EHL [1] http://tools.ietf.org/html/rfc5785 [2] http://tools.ietf.org/html/draft-nottingham-http-link-header [3] http://www.oasis-open.org/committees/download.php/37692/xrd-1.0-wd16.ht= ml [4] http://tools.ietf.org/html/draft-hammer-hostmeta [5] http://tools.ietf.org/html/draft-hammer-discovery [6] http://hueniverse.com/2009/09/implementing-webfinger/ From williamstw@gmail.com Wed May 12 05:16: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 2D9613A6B7A for ; Wed, 12 May 2010 05:16:39 -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 zecRO7PY3glX for ; Wed, 12 May 2010 05:16:37 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 4880028C11C for ; Wed, 12 May 2010 05:15:19 -0700 (PDT) Received: by gyh4 with SMTP id 4so3478680gyh.31 for ; Wed, 12 May 2010 05:15:05 -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=VwE9GOAp7BlQZ11EE14dY6KmErQzwTDnXiwbQkEAYkw=; b=EAJLWqq9Xgn+9xf1Ow4J0hYoFAtS78dGrfWhouQEz691HdNzP1zjOIn3OqVkSk/RBv VbMSDoGI7OF8DowuGopyjmfTPxipH0AA1/0VUuZEn4oJSRGfugJJ8zPeTpdRvNEXVyIp Z7722mmuKWhS5hjJY8yxJMCdLlNL2UYZOG9Ww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rE612jdIFoxjvxSMyeME77FbZStrtnFgBr3dNw3mFyHNpLxYUm/fbXgqCQomCQk41g z+lySXWTFoU0EcuUFr2ZZOPLEjeY0AQGwY5mSUXv3N2H/yWz9AIjJ7F2JHjJC0wVI2CF wiOGnAZXJwvgSrKxQT8gHcNcIsqGFxOzyKMoo= MIME-Version: 1.0 Received: by 10.150.62.14 with SMTP id k14mr12194576yba.35.1273666090500; Wed, 12 May 2010 05:08:10 -0700 (PDT) Received: by 10.151.113.14 with HTTP; Wed, 12 May 2010 05:08:10 -0700 (PDT) Date: Wed, 12 May 2010 08:08:10 -0400 Message-ID: Subject: question on draft-hammer-hostmeta-08 From: Tim Williams To: apps-discuss@ietf.org 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, 12 May 2010 12:16:39 -0000 Regarding the subject memo, can someone say why regular HTTP headers aren't appropriate for this purpose? I realize that the well-known URI approach/compromise, might be necessary for the pragmatic purposes of publishers not being able to control their outbound headers, but in this case, host-meta applies to the whole host. So I wonder why the compromise is in order? As opposed to, for example, using an HTTP header with a link to a descriptive resource? A few other questions that pop up: o) Why is it necessary to prescribe a metadata format too - it seems like the 'how to find it' is a different problem than 'how is it represented'? I mean, why couldn't I just document my host metadata in HTML5 and use the same link relations described here (e.g. license, author)? o) Why can't the host be implied from the request? Is there a case where a metacard describing a host other than the one being contacted be desirable? Anyway, I'm following the comment instructions in the document, if there's a better place for such elementary questions, please let me know... Thanks, --tim From eran@hueniverse.com Wed May 12 08:39: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 61AE328C211 for ; Wed, 12 May 2010 08:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[AWL=-1.129, 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 A+VDeiJL73Tf for ; Wed, 12 May 2010 08:39:42 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 978323A6900 for ; Wed, 12 May 2010 08:28:54 -0700 (PDT) Received: (qmail 20269 invoked from network); 12 May 2010 15:28:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 May 2010 15:28:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 12 May 2010 08:28:41 -0700 From: Eran Hammer-Lahav To: Tim Williams , "apps-discuss@ietf.org" Date: Wed, 12 May 2010 08:28:51 -0700 Subject: RE: question on draft-hammer-hostmeta-08 Thread-Topic: question on draft-hammer-hostmeta-08 Thread-Index: AcrxzPZhNVmYkwjZRvioOS+8sU6CLAAGH9wQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB475AE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 12 May 2010 15:39:43 -0000 Hi Tim, > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Tim Williams > Sent: Wednesday, May 12, 2010 5:08 AM > To: apps-discuss@ietf.org > Subject: question on draft-hammer-hostmeta-08 >=20 > Regarding the subject memo, can someone say why regular HTTP headers > aren't appropriate for this purpose? I realize that the well-known URI > approach/compromise, might be necessary for the pragmatic purposes of > publishers not being able to control their outbound headers, but in this = case, > host-meta applies to the whole host. So I wonder why the compromise is i= n > order? As opposed to, for example, using an HTTP header with a link to a > descriptive resource? A link from where? Some protocols abuse the root resource and put a link th= ere, but that is wrong because the link's subject isn't the root resource b= ut something else - the host. When Yahoo! implemented OpenID (which requires such link on http://yahoo.co= m/) the company decided that adding an extra header to all responses (when = the number of clients actually interested in this header is miniscule) so t= hey hacked it in: the header only shows up when you do a HEAD but not a GET= , or when there is no user-agent header (meaning not a browser). The reason we created Well-Known (and not just a single host-meta document = which was the original proposal) was that it was clear that a single metada= ta document for all needs will never work. The same goes with this, which m= eans, the root resource is going to end up with a whole bunch of such heade= rs. > A few other questions that pop up: >=20 > o) Why is it necessary to prescribe a metadata format too - it seems like= the > 'how to find it' is a different problem than 'how is it represented'? I = mean, > why couldn't I just document my host metadata in HTML5 and use the same > link relations described here (e.g. license, author)? Because that fails to achieve interop. It is one thing to offer a set of su= pported formats but no format makes the whole thing useless. You already ha= ve RFC 5785 - if the format of host-meta isn't suitable for your needs (you= don't want to process XML or you need a more powerful schema like POWDER),= feel free to define something else and request to register it. There is currently a lot of interest in a JSON version of XRD which might e= nd up as an extension to host-meta (for example, requesting host-meta.json = will result in a JSON serialization of the same metadata). > o) Why can't the host be implied from the request? Is there a case where= a > metacard describing a host other than the one being contacted be desirabl= e? First, you have the example.com vs www.example.com case where most sites ha= ve an automatic redirect. This gets important when you perform trusted disc= overy - you need a way to make sure the document is about what you asked fo= r (XRD offers digital signatures). Second, using the well-known location is just one way to obtain the documen= t. XRD documents are self-contained and state what they are describing usin= g the element. Because there is not such URI for host [1], host-m= eta defines an element just for that. =20 > Anyway, I'm following the comment instructions in the document, if there'= s a > better place for such elementary questions, please let me know... This is the right place. EHL [1] http://lists.oasis-open.org/archives/xri-comment/200911/msg00021.html From alexey.melnikov@isode.com Wed May 12 13:25:12 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 A17633A6452; Wed, 12 May 2010 13:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, 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 MoR1fFquDusl; Wed, 12 May 2010 13:25:11 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 97DC33A6953; Wed, 12 May 2010 13:24:59 -0700 (PDT) Received: from [188.28.106.149] (188.28.106.149.threembb.co.uk [188.28.106.149]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 12 May 2010 21:24:48 +0100 Message-ID: <4BEB0E79.5080100@isode.com> Date: Wed, 12 May 2010 21:24:25 +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-review@ietf.org Subject: Re: Looking for a new Apps Review Team Leader References: <4BE84A03.4090101@isode.com> In-Reply-To: <4BE84A03.4090101@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 12 May 2010 20:25:12 -0000 Alexey Melnikov wrote: > Peter and I are looking for a new Apps Area Review Team Leader. The > main task of the Team Leader is to find suitable reviewers from the > apps-review team and to make sure that reviews are done in a timely > manner. > > If you are interested, please reply directly to Peter and myself. > > Alexey, as Apps ADs. After discussing people who volunteered, Peter and I are happy to announce that SM agreed to serve the Apps Review Team Leader. Thank you, SM! Peter and Alexey. From paulej@packetizer.com Wed May 12 19:56:29 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 AEC583A69F0 for ; Wed, 12 May 2010 19:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_50=0.001, J_CHICKENPOX_24=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 d2jJRAct5q20 for ; Wed, 12 May 2010 19:56:28 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 4D6E03A6862 for ; Wed, 12 May 2010 19:56:28 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o4D2uB85021868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 May 2010 22:56:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1273719378; bh=kTTrSBHe+mQH9TlJEsFXQsSS+twrPT24k/r7T0edfTQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mnmS0USsJRlrcUVb1IKdRP/ZSiPcW3DY9bQuIx73ae0Vi8ny/mTKe2TJn7lN1q15Z cdiqq4fbLZCqHUOYdL/RofVohHjQpZAKcKvTRFzk+D/q3DQiiNZrfftT10c+q80M1/ 5ylGlE2q80+ZHc2Tvg48iet0DuYkG47EqmUs94Ro= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o4D2uAC2032479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 May 2010 22:56:10 -0400 From: "Paul E. Jones" To: "'Eran Hammer-Lahav'" , References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Subject: RE: Update on resource descriptor discovery work Date: Wed, 12 May 2010 22:56:05 -0400 Message-ID: <004901caf247$d4d61480$7e823d80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxnpKcHxKdQRGJRGmxdeIPs3YKVQAqTLnQ Content-Language: en-us Cc: www-tag@w3.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, 13 May 2010 02:56:29 -0000 Eran, On host-meta: Section 2 suggests that there may be one and only one hm:Host element. Perhaps change the 'using the "hm:Host" element' to "using an "hm:Host" element'? In 3.1: "The parent "XRD" element MUST include one but MAY include more" Perhaps consider: "The parent "XRD" element MUST include one or more" In section 4: Is there a reason for recommending use of HTTPS then HTTP? Are there situations where you think that the contents of the host-meta document might need to be secured and would only be transmitted after mutual TLS authentication? In such a case, wouldn't a 3xx suffice? It seems a bit much to require use of HTTPS for what I believe is likely to be a public-facing document. You say that if the client receives a 3xx when trying to retrieve the host-meta document, it SHOULD follow the redirection. Can we make that a MUST? I think that would lend to better interoperability. That's also the behavior specified in the LRDD draft. References: Web Linking reference needs updating. On discovery (LRDD): Section 1: "...for the purpose of promoting interoperability and assist in interacting with unknown resources that support known interfaces." Change "purpose" to "purposes" (since you have more than one). Should "assist" be "assisting"? I think you'd agree that "for the purpose of assist in ..." is not right. Section 3, paragraph 3A: it is required to follow 3xx the first time it's encountered, but only a "SHOULD" is specified if there are further redirections. As before, I would prefer to make that a MUST. The warning about loop detection is reasonable, though should be understood for any kind of programmatic web service. Keep it there, but don't let that issue be a reason to not encourage following multiple redirections. There is clearly a limit of how many times a client might want to follow redirections, but I'd prefer that to be more than 2 or 3. (Same comment applies to 4.2 and 4.3.) In Section 4.3, it states that tags in document markup must be processed only on a 200? What about a 304? You want to exclude use of the local cache? References: first two normative references need to be updated. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Eran Hammer-Lahav > Sent: Wednesday, May 12, 2010 2:45 AM > To: discuss@apps.ietf.org > Cc: www-tag@w3.org > Subject: Update on resource descriptor discovery work > > Just a quick update on the status of the various parts of the discovery > work presented at the last IETF Apps meeting: > > - What started as site-meta and changed into Well-known URIs is now RFC > 5785 [1]. > - Web Linking [2] was approved for RFC publication with a new registry > for link relation types. > - XRD 1.0 [3] is moving to Committee Standard next week (OASIS). > - host-meta [4] is under review by the Apps area director and pending > IETF last call. > - New draft available for LRDD [5], incorporating all the feedback > received (mostly editorial), and hopefully ready for last-call in a > week. > - First draft for 'acct' URI for accounts (as used by the WebFinger > protocol [6]) is due shortly. > > I'm starting to see the light at the end of the tunnel... :-) > > If you care about any of this, it is critical to review the host-meta > [4] and LRDD [5] documents. They are both short and include plenty of > detailed examples. Feedback would be greatly appreciated on the Apps > Discuss list. > > EHL > > [1] http://tools.ietf.org/html/rfc5785 > [2] http://tools.ietf.org/html/draft-nottingham-http-link-header > [3] http://www.oasis-open.org/committees/download.php/37692/xrd-1.0- > wd16.html > [4] http://tools.ietf.org/html/draft-hammer-hostmeta > [5] http://tools.ietf.org/html/draft-hammer-discovery > [6] http://hueniverse.com/2009/09/implementing-webfinger/ > From anthonybryan@gmail.com Wed May 12 22:03: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 DFA6C3A6A34 for ; Wed, 12 May 2010 22:03:03 -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=[AWL=-0.110, 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 4CQx+3JZKK7d for ; Wed, 12 May 2010 22:03:02 -0700 (PDT) Received: from mail-gx0-f216.google.com (mail-gx0-f216.google.com [209.85.217.216]) by core3.amsl.com (Postfix) with ESMTP id 1F2C53A6866 for ; Wed, 12 May 2010 22:03:02 -0700 (PDT) Received: by gxk8 with SMTP id 8so338782gxk.9 for ; Wed, 12 May 2010 22:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=URnav2ZrE9xbk/haaHkwZ/gcnXspZXpCoTN1doghjgw=; b=IbbfM3KB7Zak3hvjPnd/EQn/idv9O8pQjwos9pxPh7yLyqTmoi03lvY6bStCHra58z d1PQu6w3b8RlK5SQt4V5NKsrl/aty5jgvHrge9YAVaalUu8hiqEppNEciHGh1lwx1jZX RRnuZgFBFCI0CgbDaTHJplcJRhdGpL8/SBMVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IxxL8Iomu1vY8fUfOW0bMRt4Xijy+2Ofj5/kIJRE8FIi6fELURTsjFxaD9/Bzf0AlH zAiaHtzu1DlYHOcece/7sW6yFGw3cfAOnzAOf9qMo0ZLMgNt6hPYqokab6KqDOaIzQYv Qjs0RHe7hQHm/bwLs1oq+gMgzWGfPTp6RY2DE= MIME-Version: 1.0 Received: by 10.101.105.3 with SMTP id h3mr5587256anm.160.1273726967793; Wed, 12 May 2010 22:02:47 -0700 (PDT) Received: by 10.100.92.10 with HTTP; Wed, 12 May 2010 22:02:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 May 2010 01:02:47 -0400 Message-ID: Subject: Re: draft-bryan-ftp-hash From: Anthony Bryan To: Robert McMurray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , "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, 13 May 2010 05:03:04 -0000 Robert, thanks for responding publicly... On Fri, May 7, 2010 at 6:05 PM, Robert McMurray wrot= e: > Anthony Bryan and I had been discussing draft-bryan-ftp-hash with Tim Kos= se in an offline conversation, but we should consolidate our discussions in= a more public forum. > > With that in mind, what I had proposed to Anthony was that you might spec= ify the hash type as parameter of the client request and server response, t= hereby allowing the server and client to continuously know which hashing al= gorithm is in use. For example: > > =A0 C> HASH SP > =A0 S> 213 SP > > I had mentioned that might be optional as a HASH request param= eter since the draft had already specified using the OPTS command to specif= y a hash algorithm, but I recommended that the response should return the h= ash algorithm. > > Anthony had expressed some interest in the response containing the , ... I think having the hashtype in the response makes it unambiguous. Not that I expect it to be common, but the client only knows the hashtype if it's already issued OPTS HASH/FEAT or the session hasn't been reinitialized. I wouldn't expect "blind" HASH requests but... :) > If was a mandatory parameter for both the client request and s= erver response that would address Tim's point, but that would dramatically = alter Anthony's original design. Daniel mentioned the history/reason already (-00 draft did it your way), and here's some of the previous discussion started by Alfred. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01387.html http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01436.html > This syntax would allow for hashing algorithms like MD5, XCRC, CRC32, SHA= -256, etc., but I'll leave it open for debate if that would be too restrict= ive. The current draft defines allowed algorithms from the IANA registry "Hash Function Textual Names" at http://www.iana.org/assignments/hash-function-text-names/hash-function-text= -names.xml The current values: md2, md5, sha-1, sha-224, sha-256, sha-384, sha-512. As you can see, CRC32 isn't listed. The non-standard XCRC command is one of the most implemented, as far as I can tell. (Note, there are algorithm specific non-standard commands for others: MD5, XMD5, XSHA, XSHA1, XSHA256, XSHA512). Should CRC32 be an option for the HASH command? Another question, should HASH optionally support requesting partial file hashes? Some of the non-standard commands (at least XCRC & XMD5 allow for this). --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From eran@hueniverse.com Wed May 12 22: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 AEDAC3A6A48 for ; Wed, 12 May 2010 22:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=-1.426, BAYES_50=0.001, J_CHICKENPOX_24=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 Zo0JqnAPWNbM for ; Wed, 12 May 2010 22:52:46 -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 A67013A6A63 for ; Wed, 12 May 2010 22:51:14 -0700 (PDT) Received: (qmail 5200 invoked from network); 13 May 2010 05:51:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 May 2010 05:51:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 12 May 2010 22:51:04 -0700 From: Eran Hammer-Lahav To: "Paul E. Jones" , "discuss@apps.ietf.org" Date: Wed, 12 May 2010 22:51:13 -0700 Subject: RE: Update on resource descriptor discovery work Thread-Topic: Update on resource descriptor discovery work Thread-Index: AcrxnpKcHxKdQRGJRGmxdeIPs3YKVQAqTLnQAAWMIJA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB477D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <004901caf247$d4d61480$7e823d80$@com> In-Reply-To: <004901caf247$d4d61480$7e823d80$@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 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, 13 May 2010 05:52:47 -0000 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Wednesday, May 12, 2010 7:56 PM > To: Eran Hammer-Lahav; discuss@apps.ietf.org > Cc: www-tag@w3.org > Subject: RE: Update on resource descriptor discovery work >=20 > Eran, >=20 > On host-meta: > Section 2 suggests that there may be one and only one hm:Host element. > Perhaps change the 'using the "hm:Host" element' to "using an "hm:Host" > element'? Section 2 starts by saying: "Each host-meta document describes one or more = hosts". I think that makes it clear enough (as well as the examples). > In 3.1: > "The parent "XRD" element MUST include one but MAY include more" > Perhaps consider: > "The parent "XRD" element MUST include one or more" Ok. > In section 4: > Is there a reason for recommending use of HTTPS then HTTP? Are there > situations where you think that the contents of the host-meta document > might need to be secured and would only be transmitted after mutual TLS > authentication? In such a case, wouldn't a 3xx suffice? It seems a bit = much > to require use of HTTPS for what I believe is likely to be a public-facin= g > document. It is a recommendation, not a requirement. Since this is a policy document = which is likely to be used in protocols where trust plays a role, it is bet= ter to get libraries to optimize for this and attempt getting the HTTPS doc= ument first. The previous draft didn't place any preference and the feedbac= k I got was that it would be better to define a preferred order. > You say that if the client receives a 3xx when trying to retrieve the hos= t-meta > document, it SHOULD follow the redirection. Can we make that a MUST? I > think that would lend to better interoperability. That's also the behavio= r > specified in the LRDD draft. LRDD doesn't mandate a MUST for host-meta, just for its own documents. But = I have no problem making this a MUST. Anyone has an objection? =20 > References: > Web Linking reference needs updating. Yep. It will point to the RFC. > On discovery (LRDD): >=20 > Section 1: > "...for the purpose of promoting interoperability and assist in interacti= ng with > unknown resources that support known interfaces." > Change "purpose" to "purposes" (since you have more than one). > Should "assist" be "assisting"? I think you'd agree that "for the purpos= e of > assist in ..." is not right. Yep. > Section 3, paragraph 3A: it is required to follow 3xx the first time it's > encountered, but only a "SHOULD" is specified if there are further > redirections. As before, I would prefer to make that a MUST. The warnin= g > about loop detection is reasonable, though should be understood for any > kind of programmatic web service. Keep it there, but don't let that issu= e be a > reason to not encourage following multiple redirections. There is clearl= y a > limit of how many times a client might want to follow redirections, but I= 'd > prefer that to be more than 2 or 3. (Same comment applies to 4.2 and 4.3= .) How would you describe such a MUST without requiring the client to follow, = say, 100 redirections? > In Section 4.3, it states that tags in document markup must be processed = only > on a 200? What about a 304? You want to exclude use of the local cache? Caching is allowed. A 304 just means the client can use a previously obtain= ed document with a 200 status code. The client doesn't need to request anyt= hing if they have a valid copy in their cache. I think this is implied. > References: first two normative references need to be updated. Yep. Thanks, EHL From paulej@packetizer.com Thu May 13 09:27:08 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 65E093A6C6E for ; Thu, 13 May 2010 09:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-0.770, 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 BArm470MvOeo for ; Thu, 13 May 2010 09:27:06 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 205883A6CC1 for ; Thu, 13 May 2010 09:24:53 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o4DGObam022537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 May 2010 12:24:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1273767883; bh=6FADI269DQDlV67BwhYd73k53InIV8TWSEvuGYp9Rlo=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=AquY+Gq7G2Gk0a45GWGCWzK0RjR1Qkeyvxv9HRWoD0xIi6IkBNOJdLeVZFdLymMok JXWyftzsA1w173Dgc7UtcjA8NFQUqr8ItHWb3pbEd+5Sor+H5WQe/ESjX2fBMcefSc 8Q6U+DbPmJ/lvDEQd3u948Z1zYyvZ/wh2fTN7xQ4= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o4DGOaBO002593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 May 2010 12:24:36 -0400 From: "Paul E. Jones" To: "'Eran Hammer-Lahav'" , References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <004901caf247$d4d61480$7e823d80$@com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB477D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB477D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Subject: RE: Update on resource descriptor discovery work Date: Thu, 13 May 2010 12:24:30 -0400 Message-ID: <012801caf2b8$c3c8ee30$4b5aca90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxnpKcHxKdQRGJRGmxdeIPs3YKVQAqTLnQAAWMIJAAFgR0oA== Content-Language: en-us 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, 13 May 2010 16:27:08 -0000 Eran, > > In section 4: > > Is there a reason for recommending use of HTTPS then HTTP? Are there > > situations where you think that the contents of the host-meta > document > > might need to be secured and would only be transmitted after mutual > TLS > > authentication? In such a case, wouldn't a 3xx suffice? It seems a > bit much > > to require use of HTTPS for what I believe is likely to be a public- > facing > > document. > > It is a recommendation, not a requirement. Since this is a policy > document which is likely to be used in protocols where trust plays a > role, it is better to get libraries to optimize for this and attempt > getting the HTTPS document first. The previous draft didn't place any > preference and the feedback I got was that it would be better to define > a preferred order. That makes sense. > > Section 3, paragraph 3A: it is required to follow 3xx the first time > it's > > encountered, but only a "SHOULD" is specified if there are further > > redirections. As before, I would prefer to make that a MUST. The > warning > > about loop detection is reasonable, though should be understood for > any > > kind of programmatic web service. Keep it there, but don't let that > issue be a > > reason to not encourage following multiple redirections. There is > clearly a > > limit of how many times a client might want to follow redirections, > but I'd > > prefer that to be more than 2 or 3. (Same comment applies to 4.2 and > 4.3.) > > How would you describe such a MUST without requiring the client to > follow, say, 100 redirections? Why would it be different? A 307 is a 307, right? Perhaps I'm missing the point. > > In Section 4.3, it states that tags in document markup must be > processed only > > on a 200? What about a 304? You want to exclude use of the local > cache? > > Caching is allowed. A 304 just means the client can use a previously > obtained document with a 200 status code. The client doesn't need to > request anything if they have a valid copy in their cache. I think this > is implied. It was implicit to me until I read that sentence. My impression was that you wanted to forbid use of the local cache for some reason. Paul From eran@hueniverse.com Thu May 13 09:42:23 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 B77BB3A6825 for ; Thu, 13 May 2010 09:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[AWL=-1.111, 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 qDXRlN8GDCWx for ; Thu, 13 May 2010 09:42:22 -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 90CE03A6877 for ; Thu, 13 May 2010 09:42:22 -0700 (PDT) Received: (qmail 26979 invoked from network); 13 May 2010 16:42:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 May 2010 16:42:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 13 May 2010 09:42:08 -0700 From: Eran Hammer-Lahav To: "Paul E. Jones" , "discuss@apps.ietf.org" Date: Thu, 13 May 2010 09:42:21 -0700 Subject: RE: Update on resource descriptor discovery work Thread-Topic: Update on resource descriptor discovery work Thread-Index: AcrxnpKcHxKdQRGJRGmxdeIPs3YKVQAqTLnQAAWMIJAAFgR0oAABIAeg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B6987EB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <004901caf247$d4d61480$7e823d80$@com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB477D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012801caf2b8$c3c8ee30$4b5aca90$@com> In-Reply-To: <012801caf2b8$c3c8ee30$4b5aca90$@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 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, 13 May 2010 16:42:23 -0000 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, May 13, 2010 9:25 AM > > > Section 3, paragraph 3A: it is required to follow 3xx the first time > > it's > > > encountered, but only a "SHOULD" is specified if there are further > > > redirections. As before, I would prefer to make that a MUST. The > > warning > > > about loop detection is reasonable, though should be understood for > > any > > > kind of programmatic web service. Keep it there, but don't let that > > issue be a > > > reason to not encourage following multiple redirections. There is > > clearly a > > > limit of how many times a client might want to follow redirections, > > but I'd > > > prefer that to be more than 2 or 3. (Same comment applies to 4.2 > > > and > > 4.3.) > > > > How would you describe such a MUST without requiring the client to > > follow, say, 100 redirections? >=20 > Why would it be different? A 307 is a 307, right? Perhaps I'm missing t= he > point. My concern is a MUST with potentially impractical repercussions (like follo= wing hundreds of redirections). In a browser this isn't an issue because th= ere is a person sitting there with its own limit (how long the user is will= ing to sit there and stare at the URI changing without getting results). Bu= t for a client performing discovery, especially in UI sensitive application= s, this can be a problem. It would be helpful to know how other specifications handle such a requirem= ent. Make it a MUST with a minimum number of redirections? Make it a MUST a= nd assume the client will exit the loop as it see fit? Make it a SHOULD? What's the best approach here in terms of language (since I think we agree = on substance)? > > > In Section 4.3, it states that tags in document markup must be > > processed only > > > on a 200? What about a 304? You want to exclude use of the local > > cache? > > > > Caching is allowed. A 304 just means the client can use a previously > > obtained document with a 200 status code. The client doesn't need to > > request anything if they have a valid copy in their cache. I think > > this is implied. >=20 > It was implicit to me until I read that sentence. My impression was that= you > wanted to forbid use of the local cache for some reason. What's the general approach in such cases? Should the spec explicitly call = out the use of caching? EHL From paulej@packetizer.com Thu May 13 10:51: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 6B6533A6C7B for ; Thu, 13 May 2010 10:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.756 X-Spam-Level: X-Spam-Status: No, score=-0.756 tagged_above=-999 required=5 tests=[AWL=-0.757, 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 7+YX8Jg2QS5I for ; Thu, 13 May 2010 10:51:13 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 3AB8D3A6C6F for ; Thu, 13 May 2010 10:51:12 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o4DHorC8029395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 May 2010 13:50:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1273773059; bh=vLMyjcBk+UOgSzDSMj+CgjaDLi9tQ/jMzeHqZAgT3oI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=EoJqvcM5rTwWPUKmEKy5/YF2xtAAVhq/AjRwXPRfVt604ij5c1Jht/9/eOR+kXER+ uTpeVtCdj5OjKjgCRC+gk8WTudG3593aX/OX49eQzMKDAm4+LF5pFWZlCODQdrPLS2 w+c3xKXLsZEtt0/kOYx8vxjSsczINcMDxadufbPs= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o4DHoma0002806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 May 2010 13:50:49 -0400 From: "Paul E. Jones" To: "'Eran Hammer-Lahav'" , References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <004901caf247$d4d61480$7e823d80$@com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB477D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012801caf2b8$c3c8ee30$4b5aca90$@com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6987EB@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B6987EB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Subject: RE: Update on resource descriptor discovery work Date: Thu, 13 May 2010 13:50:42 -0400 Message-ID: <013001caf2c4$d0d719b0$72854d10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxnpKcHxKdQRGJRGmxdeIPs3YKVQAqTLnQAAWMIJAAFgR0oAABIAegAAHnyIA= Content-Language: en-us 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, 13 May 2010 17:51:14 -0000 Eran, > My concern is a MUST with potentially impractical repercussions (like > following hundreds of redirections). In a browser this isn't an issue > because there is a person sitting there with its own limit (how long > the user is willing to sit there and stare at the URI changing without > getting results). But for a client performing discovery, especially in > UI sensitive applications, this can be a problem. > > It would be helpful to know how other specifications handle such a > requirement. Make it a MUST with a minimum number of redirections? Make > it a MUST and assume the client will exit the loop as it see fit? Make > it a SHOULD? > > What's the best approach here in terms of language (since I think we > agree on substance)? Good question. RFC 2616 said: Note: previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation. There appears to be no specified maximum now. It also says a client SHOULD detect infinite loops, which I think is unfortunate, as I would have made it a MUST. I, too, would like to know why 5 was specified and why no limit is now specified. I think it does at least hint that 5 might be too restrictive, but I don't know what general practice is. I just checked some code I wrote and, while it checks for loops, it imposed no limit on the number of redirections. How trusting I am ;-) > > > > In Section 4.3, it states that tags in document markup must be > > > processed only > > > > on a 200? What about a 304? You want to exclude use of the local > > > cache? > > > > > > Caching is allowed. A 304 just means the client can use a > previously > > > obtained document with a 200 status code. The client doesn't need > to > > > request anything if they have a valid copy in their cache. I think > > > this is implied. > > > > It was implicit to me until I read that sentence. My impression was > that you > > wanted to forbid use of the local cache for some reason. > > What's the general approach in such cases? Should the spec explicitly > call out the use of caching? Had you not written that sentence that said to process HTML document only if we receive a 200, I would have used the cached file if I received a 304. I'd suggest having a statement that says the cached copy must be used if a 304 is returned. Paul From apps-discuss@chsc.dk Fri May 14 12:45:26 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 9A9483A68C8 for ; Fri, 14 May 2010 12:45:26 -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 aAVRvCgWGbs3 for ; Fri, 14 May 2010 12:45:25 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0169.hostedemail.com [216.40.44.169]) by core3.amsl.com (Postfix) with ESMTP id E27313A6925 for ; Fri, 14 May 2010 12:45:23 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id 85EA6142C542 for ; Fri, 14 May 2010 19:45:13 +0000 (UTC) X-Panda: scanned! X-Session-Marker: 63687269737469616E407363686D6964742E6E6574 X-Filterd-Recvd-Size: 4158 Received: from [10.0.8.1] (0x573d84a6.cpe.ge-1-1-0-1101.vbrnqu1.customer.tele.dk [87.61.132.166]) (Authenticated sender: christian@schmidt.net) by omf06.hostedemail.com (Postfix) with ESMTP for ; Fri, 14 May 2010 19:45:12 +0000 (UTC) Message-ID: <4BEDA847.6090004@chsc.dk> Date: Fri, 14 May 2010 21:45:11 +0200 From: Christian Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: draft-hammer-hostmeta-08: HTTPS requirement Content-Type: text/plain; charset=ISO-8859-1; 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: Fri, 14 May 2010 19:57:54 -0000 Hi, I'm new to this list. I recently became aware of the host-meta draft while studying Google's description of OpenID discovery . I have a few comments on draft-hammer-hostmeta-08, section 4. > Clients obtain the host-meta document for a given host by making an > HTTPS [RFC2818] GET request to the host's port 443 for the > "/.well-known/host-meta" path. If the request fails to produce a > valid host-meta document, clients make an HTTP [RFC2616] GET request > to the host's port 80 for the "/.well-known/host-meta" path. In brief: Try fetching the host-meta file via HTTPS. If that fails, fall back to HTTP. I don't understand this requirement. The usual reason for preferring HTTPS over HTTP is the need for secrecy (using encryption) and/or identification of the server (using certificates signed by a trusted authority). AFAICT the host-meta is intended to published to everybody without any access control, so secrecy is not an issue. If identification of the server is considered important to the client, it should only accept a host-meta document fetched via HTTPS. If an adversary is able to make a man-in-the-middle attack against a HTTP connection, he would usually also be able to prevent a HTTPS connection from being made to the same host, so AFAICT HTTPS doesn't offer any additional security if the client may just fall back to HTTP. It's like a border patrol officer asking to see a traveler's passport, but if the traveler refuses to show a passport or shows one that has been tampered with, the officer just lets him pass anyway. If the client finds it acceptable to fetch the host-meta document via HTTP, it would seem easier and just a secure to simply try HTTP first and then possibly fall back to HTTPS. Or did I miss something? > If a representation is successfully obtained, but is not in the > format described above, clients should infer that the path is being > used for other purposes, and not process the response as a host-meta > document. There is no SHOULD/MUST/MAY in this sentence. Is "should" intended to mean "SHOULD", or is the client encouraged to be fault-tolerant against invalid or non-wellformed XML? > To aid in this process, authorities using this mechanism > SHOULD correctly label host-meta responses with the > "application/xrd+xml" internet media type. It is now explained how that aids in inferring that a path is used for other purposes than a host-meta document. What is a client expected to do, if the Content-Type is not application/xrd+xml, or if the Content-Type *is* application/xrd+xml, but the host-meta document itself is not in the described format? > If the server response indicates that the host-meta resource is > located elsewhere (a 301, 302, or 307 response status code), the > client SHOULD try to obtain the resource from the location provided > in the response. This means that the host-meta document for one host > MAY be retrieved from a another host. There seems to be a conflict between "SHOULD" and "MAY". "MAY" indicates that following a cross-host redirect is completely optional, but I assume this is not intended. The last sentence seems to be a clarification rather than a normative statement, so perhaps "MAY" should be replaced with just "may"? Christian From apps-discuss@chsc.dk Fri May 14 15:27:37 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 B3EDD3A6935 for ; Fri, 14 May 2010 15:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[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 jiOQ3GTZII24 for ; Fri, 14 May 2010 15:27:37 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0252.hostedemail.com [216.40.44.252]) by core3.amsl.com (Postfix) with ESMTP id 8CAEB3A68EE for ; Fri, 14 May 2010 15:27:37 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with SMTP id 80997260ED for ; Fri, 14 May 2010 22:27:27 +0000 (UTC) X-Panda: scanned! X-Session-Marker: 63687269737469616E407363686D6964742E6E6574 X-Filterd-Recvd-Size: 1713 Received: from [10.0.8.1] (0x573d84a6.cpe.ge-1-1-0-1101.vbrnqu1.customer.tele.dk [87.61.132.166]) (Authenticated sender: christian@schmidt.net) by omf04.hostedemail.com (Postfix) with ESMTP for ; Fri, 14 May 2010 22:27:26 +0000 (UTC) Message-ID: <4BEDCE4D.9080408@chsc.dk> Date: Sat, 15 May 2010 00:27:25 +0200 From: Christian Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: draft-hammer-hostmeta-08: HTTPS requirement References: <4BEDA847.6090004@chsc.dk> In-Reply-To: <4BEDA847.6090004@chsc.dk> Content-Type: text/plain; charset=ISO-8859-1; 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: Fri, 14 May 2010 22:27:37 -0000 I just noticed a few disturbing errors in my previous post: > If the client finds it acceptable to fetch the host-meta document via > HTTP, it would seem easier and just a secure to simply try HTTP first > and then possibly fall back to HTTPS. Or did I miss something? s/just a secure/just as secure/ >> To aid in this process, authorities using this mechanism >> SHOULD correctly label host-meta responses with the >> "application/xrd+xml" internet media type. > It is now explained how that aids in inferring that a path is used for s/now/not/ > There seems to be a conflict between "SHOULD" and "MAY". "MAY" indicates > that following a cross-host redirect is completely optional, but I > assume this is not intended. The last sentence seems to be a > clarification rather than a normative statement, so perhaps "MAY" should > be replaced with just "may"? s/normative statement/separate requirement/ Christian From jpanzer@google.com Fri May 14 16: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 624C43A65A6 for ; Fri, 14 May 2010 16:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.428 X-Spam-Level: X-Spam-Status: No, score=-100.428 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 quuiR+NkWX7P for ; Fri, 14 May 2010 16:44:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9C04F3A6837 for ; Fri, 14 May 2010 16:44:56 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o4ENiisj000316 for ; Fri, 14 May 2010 16:44:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273880685; bh=DDQIQ8YIZ9MgYEYF9sBYqZpt2XI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=DqiGRnAqQIJ24LWUeURTXgazHCr+I8yP2HCHmHv8jNF59HlBnoCIthSpi/HnJLrWF xJcbvhLuhDnhlMvqVUOqQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=sUAtzCvLPc4t79Wnk7w4iLQFG/8WO2vrJhWpfdnADZw5ykmWtzsnbHhrYLtK5EE4O y74jkZBkW8JWeN8i42OOA== Received: from ywh8 (ywh8.prod.google.com [10.192.8.8]) by wpaz9.hot.corp.google.com with ESMTP id o4ENiLKl025974 for ; Fri, 14 May 2010 16:44:43 -0700 Received: by ywh8 with SMTP id 8so1694977ywh.6 for ; Fri, 14 May 2010 16:44:43 -0700 (PDT) Received: by 10.90.204.19 with SMTP id b19mr1163256agg.139.1273880683248; Fri, 14 May 2010 16:44:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.211.18 with HTTP; Fri, 14 May 2010 16:44:23 -0700 (PDT) In-Reply-To: <4BEDA847.6090004@chsc.dk> References: <4BEDA847.6090004@chsc.dk> From: John Panzer Date: Fri, 14 May 2010 16:44:23 -0700 Message-ID: Subject: Re: draft-hammer-hostmeta-08: HTTPS requirement To: Christian Schmidt Content-Type: multipart/alternative; boundary=00163630f0599c7f560486967580 X-System-Of-Record: true 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, 14 May 2010 23:44:58 -0000 --00163630f0599c7f560486967580 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 14, 2010 at 12:45 PM, Christian Schmidt wrote: > Hi, > > I'm new to this list. I recently became aware of the host-meta draft while > studying Google's description of OpenID discovery < > http://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery>. I > have a few comments on draft-hammer-hostmeta-08, section 4. > > Clients obtain the host-meta document for a given host by making an >> HTTPS [RFC2818] GET request to the host's port 443 for the >> "/.well-known/host-meta" path. If the request fails to produce a >> valid host-meta document, clients make an HTTP [RFC2616] GET request >> to the host's port 80 for the "/.well-known/host-meta" path. >> > In brief: Try fetching the host-meta file via HTTPS. If that fails, fall > back to HTTP. I don't understand this requirement. > > The usual reason for preferring HTTPS over HTTP is the need for secrecy > (using encryption) and/or identification of the server (using certificates > signed by a trusted authority). AFAICT the host-meta is intended to > published to everybody without any access control, so secrecy is not an > issue. If identification of the server is considered important to the > client, it should only accept a host-meta document fetched via HTTPS. There are two ways to identify documents: Make sure every hop in the retrieval path used TLS, with appropriate server certificate vetting (checking CRLs, etc); or, if it is a signed XRD, implement XML-DSig verification (with appropriate certificate vetting etc.) If a library retrieves via http first, it presumably won't try https, so if the document has no signature the client is out of luck, even though it may well be verifiable if retrieved with TLS. If on the other hand you try TLS first, and that fails, you know there was no TLS available and the only recourse is to check document signatures. > If an adversary is able to make a man-in-the-middle attack against a HTTP > connection, he would usually also be able to prevent a HTTPS connection from > being made to the same host, so AFAICT HTTPS doesn't offer any additional > security if the client may just fall back to HTTP. It's like a border patrol > officer asking to see a traveler's passport, but if the traveler refuses to > show a passport or shows one that has been tampered with, the officer just > lets him pass anyway. > You'd either fail (because you don't know how to do XML-DSig) or you'd fail (because the MITM modified the DSig protected content too) or you'd succeed (because the MITM realized he can't modify DSig protected content). I think the only possibilities are total failure -- same as if the MITM blocked your access, which of course they can do no matter what -- and secure success. > > If the client finds it acceptable to fetch the host-meta document via HTTP, > it would seem easier and just a secure to simply try HTTP first and then > possibly fall back to HTTPS. Or did I miss something? > > > If a representation is successfully obtained, but is not in the >> format described above, clients should infer that the path is being >> used for other purposes, and not process the response as a host-meta >> document. >> > There is no SHOULD/MUST/MAY in this sentence. Is "should" intended to mean > "SHOULD", or is the client encouraged to be fault-tolerant against invalid > or non-wellformed XML? > > > To aid in this process, authorities using this mechanism >> SHOULD correctly label host-meta responses with the >> "application/xrd+xml" internet media type. >> > It is now explained how that aids in inferring that a path is used for > other purposes than a host-meta document. What is a client expected to do, > if the Content-Type is not application/xrd+xml, or if the Content-Type *is* > application/xrd+xml, but the host-meta document itself is not in the > described format? > > > If the server response indicates that the host-meta resource is >> located elsewhere (a 301, 302, or 307 response status code), the >> client SHOULD try to obtain the resource from the location provided >> in the response. This means that the host-meta document for one host >> MAY be retrieved from a another host. >> > There seems to be a conflict between "SHOULD" and "MAY". "MAY" indicates > that following a cross-host redirect is completely optional, but I assume > this is not intended. The last sentence seems to be a clarification rather > than a normative statement, so perhaps "MAY" should be replaced with just > "may"? > > > Christian > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --00163630f0599c7f560486967580 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 14, 2010 at 12:45 PM, Christian Schm= idt <apps-disc= uss@chsc.dk> wrote:
Hi,

I'm new to this list. I recently became aware of the host-meta draft wh= ile studying Google's description of OpenID discovery <http://sites.google.com/site/oauthgoog/fedlogininterp/openiddis= covery>. I have a few comments on draft-hammer-hostmeta-08, section = 4.

=A0 Clients obtain the host-meta document for a given host by making an =A0 HTTPS [RFC2818] GET request to the host's port 443 for the
=A0 "/.well-known/host-meta" path. =A0If the request fails to pr= oduce a
=A0 valid host-meta document, clients make an HTTP [RFC2616] GET request =A0 to the host's port 80 for the "/.well-known/host-meta" p= ath.
In brief: Try fetching the host-meta file via HTTPS. If that fails, fall ba= ck to HTTP. I don't understand this requirement.

The usual reason for preferring HTTPS over HTTP is the need for secrecy (us= ing encryption) and/or identification of the server (using certificates sig= ned by a trusted authority). AFAICT the host-meta is intended to published = to everybody without any access control, so secrecy is not an issue. If ide= ntification of the server is considered important to the client, it should = only accept a host-meta document fetched via HTTPS.

There are two ways to identify documents: =A0Make sure = every hop in the retrieval path used TLS, with appropriate server certifica= te vetting (checking CRLs, etc); or, if it is a signed XRD, implement XML-D= Sig verification (with appropriate certificate vetting etc.)=A0

If a library retrieves via http first, it presumably wo= n't try https, so if the document has no signature the client is out of= luck, even though it may well be verifiable if retrieved with TLS. =A0If o= n the other hand you try TLS first, and that fails, you know there was no T= LS available and the only recourse is to check document signatures.
=A0
If an adversary is able to m= ake a man-in-the-middle attack against a HTTP connection, he would usually = also be able to prevent a HTTPS connection from being made to the same host= , so AFAICT HTTPS doesn't offer any additional security if the client m= ay just fall back to HTTP. It's like a border patrol officer asking to = see a traveler's passport, but if the traveler refuses to show a passpo= rt or shows one that has been tampered with, the officer just lets him pass= anyway.

You'd either fail (because you don'= ;t know how to do XML-DSig) or you'd fail (because the MITM modified th= e DSig protected content too) or you'd succeed (because the MITM realiz= ed he can't modify DSig protected content). =A0I think the only possibi= lities are total failure -- same as if the MITM blocked your access, which = of course they can do no matter what -- and secure success.
=A0

If the client finds it acceptable to fetch the host-meta document via HTTP,= it would seem easier and just a secure to simply try HTTP first and then p= ossibly fall back to HTTPS. Or did I miss something?


=A0 If a representation is successfully obtained, but is not in the
=A0 format described above, clients should infer that the path is being =A0 used for other purposes, and not process the response as a host-meta =A0 document.
There is no SHOULD/MUST/MAY in this sentence. Is "should" intende= d to mean "SHOULD", or is the client encouraged to be fault-toler= ant against invalid or non-wellformed XML?


=A0 To aid in this process, authorities using this mechanism
=A0 SHOULD correctly label host-meta responses with the
=A0 "application/xrd+xml" internet media type.
It is now explained how that aids in inferring that a path is used for othe= r purposes than a host-meta document. What is a client expected to do, if t= he Content-Type is not application/xrd+xml, or if the Content-Type *is* app= lication/xrd+xml, but the host-meta document itself is not in the described= format?


=A0 If the server response indicates that the host-meta resource is
=A0 located elsewhere (a 301, 302, or 307 response status code), the
=A0 client SHOULD try to obtain the resource from the location provided =A0 in the response. =A0This means that the host-meta document for one hos= t
=A0 MAY be retrieved from a another host.
There seems to be a conflict between "SHOULD" and "MAY"= . "MAY" indicates that following a cross-host redirect is complet= ely optional, but I assume this is not intended. The last sentence seems to= be a clarification rather than a normative statement, so perhaps "MAY= " should be replaced with just "may"?


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

--00163630f0599c7f560486967580-- From jpanzer@google.com Fri May 14 16:45: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 D08B53A65A6 for ; Fri, 14 May 2010 16:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.012 X-Spam-Level: X-Spam-Status: No, score=-104.012 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 PYWQbsR09RFs for ; Fri, 14 May 2010 16:45:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0332C3A6896 for ; Fri, 14 May 2010 16:45:43 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o4ENjPN0006736 for ; Fri, 14 May 2010 16:45:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273880726; bh=NL5KANq9jOW8eiE8Xuo6LITcJek=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WrkS57meYAsqbTNihIv15wuxnMnioLLH8sWoZWx6YYAjYF86Dp1unJbtfm7PVYYGp uYpfNEEW2kzACgc+pwRLg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=sQg93eq2MpEU+KPvfoCVDvpaKM1JIz/3RGU83kUgyoBERABTOz/LibYAnnDQeF1X5 YOd8QsTqlJK14f6fYfMjQ== Received: from ywh33 (ywh33.prod.google.com [10.192.8.33]) by kpbe14.cbf.corp.google.com with ESMTP id o4ENj4vK015074 for ; Fri, 14 May 2010 16:45:24 -0700 Received: by ywh33 with SMTP id 33so1892375ywh.11 for ; Fri, 14 May 2010 16:45:24 -0700 (PDT) Received: by 10.90.198.19 with SMTP id v19mr1208501agf.100.1273880724156; Fri, 14 May 2010 16:45:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.211.18 with HTTP; Fri, 14 May 2010 16:45:04 -0700 (PDT) In-Reply-To: References: <4BEDA847.6090004@chsc.dk> From: John Panzer Date: Fri, 14 May 2010 16:45:04 -0700 Message-ID: Subject: Re: draft-hammer-hostmeta-08: HTTPS requirement To: Christian Schmidt Content-Type: multipart/alternative; boundary=0016362841da0cb6340486967815 X-System-Of-Record: true 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, 14 May 2010 23:45:45 -0000 --0016362841da0cb6340486967815 Content-Type: text/plain; charset=ISO-8859-1 s/identify documents/verify documents/ in my prior email. Thanks. On Fri, May 14, 2010 at 4:44 PM, John Panzer wrote: > On Fri, May 14, 2010 at 12:45 PM, Christian Schmidt wrote: > >> Hi, >> >> I'm new to this list. I recently became aware of the host-meta draft while >> studying Google's description of OpenID discovery < >> http://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery>. I >> have a few comments on draft-hammer-hostmeta-08, section 4. >> >> Clients obtain the host-meta document for a given host by making an >>> HTTPS [RFC2818] GET request to the host's port 443 for the >>> "/.well-known/host-meta" path. If the request fails to produce a >>> valid host-meta document, clients make an HTTP [RFC2616] GET request >>> to the host's port 80 for the "/.well-known/host-meta" path. >>> >> In brief: Try fetching the host-meta file via HTTPS. If that fails, fall >> back to HTTP. I don't understand this requirement. >> >> The usual reason for preferring HTTPS over HTTP is the need for secrecy >> (using encryption) and/or identification of the server (using certificates >> signed by a trusted authority). AFAICT the host-meta is intended to >> published to everybody without any access control, so secrecy is not an >> issue. If identification of the server is considered important to the >> client, it should only accept a host-meta document fetched via HTTPS. > > > There are two ways to identify documents: Make sure every hop in the > retrieval path used TLS, with appropriate server certificate vetting > (checking CRLs, etc); or, if it is a signed XRD, implement XML-DSig > verification (with appropriate certificate vetting etc.) > > If a library retrieves via http first, it presumably won't try https, so if > the document has no signature the client is out of luck, even though it may > well be verifiable if retrieved with TLS. If on the other hand you try TLS > first, and that fails, you know there was no TLS available and the only > recourse is to check document signatures. > > >> If an adversary is able to make a man-in-the-middle attack against a HTTP >> connection, he would usually also be able to prevent a HTTPS connection from >> being made to the same host, so AFAICT HTTPS doesn't offer any additional >> security if the client may just fall back to HTTP. It's like a border patrol >> officer asking to see a traveler's passport, but if the traveler refuses to >> show a passport or shows one that has been tampered with, the officer just >> lets him pass anyway. >> > > You'd either fail (because you don't know how to do XML-DSig) or you'd fail > (because the MITM modified the DSig protected content too) or you'd succeed > (because the MITM realized he can't modify DSig protected content). I think > the only possibilities are total failure -- same as if the MITM blocked your > access, which of course they can do no matter what -- and secure success. > > >> >> If the client finds it acceptable to fetch the host-meta document via >> HTTP, it would seem easier and just a secure to simply try HTTP first and >> then possibly fall back to HTTPS. Or did I miss something? >> >> >> If a representation is successfully obtained, but is not in the >>> format described above, clients should infer that the path is being >>> used for other purposes, and not process the response as a host-meta >>> document. >>> >> There is no SHOULD/MUST/MAY in this sentence. Is "should" intended to mean >> "SHOULD", or is the client encouraged to be fault-tolerant against invalid >> or non-wellformed XML? >> >> >> To aid in this process, authorities using this mechanism >>> SHOULD correctly label host-meta responses with the >>> "application/xrd+xml" internet media type. >>> >> It is now explained how that aids in inferring that a path is used for >> other purposes than a host-meta document. What is a client expected to do, >> if the Content-Type is not application/xrd+xml, or if the Content-Type *is* >> application/xrd+xml, but the host-meta document itself is not in the >> described format? >> >> >> If the server response indicates that the host-meta resource is >>> located elsewhere (a 301, 302, or 307 response status code), the >>> client SHOULD try to obtain the resource from the location provided >>> in the response. This means that the host-meta document for one host >>> MAY be retrieved from a another host. >>> >> There seems to be a conflict between "SHOULD" and "MAY". "MAY" indicates >> that following a cross-host redirect is completely optional, but I assume >> this is not intended. The last sentence seems to be a clarification rather >> than a normative statement, so perhaps "MAY" should be replaced with just >> "may"? >> >> >> Christian >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > --0016362841da0cb6340486967815 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable s/identify documents/verify documents/ in my prior email. =A0Thanks.
On Fri, May 14, 2010 at 4:44 PM, John Panzer <jpanzer@google.co= m> wrote:
On Fri, May 14, 2010 at 12:45 PM, Christian Schmidt <= ;apps-discuss@chs= c.dk> wrote:
Hi,

I'm new to this list. I recently became aware of the host-meta draft wh= ile studying Google's description of OpenID discovery <http://sites.google.com/site/oauthgoog/fedlogininterp/openiddis= covery>. I have a few comments on draft-hammer-hostmeta-08, section = 4.

=A0 Clients obtain the host-meta document for a given host by making an =A0 HTTPS [RFC2818] GET request to the host's port 443 for the
=A0 "/.well-known/host-meta" path. =A0If the request fails to pr= oduce a
=A0 valid host-meta document, clients make an HTTP [RFC2616] GET request =A0 to the host's port 80 for the "/.well-known/host-meta" p= ath.
In brief: Try fetching the host-meta file via HTTPS. If that fails, fall ba= ck to HTTP. I don't understand this requirement.

The usual reason for preferring HTTPS over HTTP is the need for secrecy (us= ing encryption) and/or identification of the server (using certificates sig= ned by a trusted authority). AFAICT the host-meta is intended to published = to everybody without any access control, so secrecy is not an issue. If ide= ntification of the server is considered important to the client, it should = only accept a host-meta document fetched via HTTPS.

There are two ways to identify documents: =A0Make= sure every hop in the retrieval path used TLS, with appropriate server cer= tificate vetting (checking CRLs, etc); or, if it is a signed XRD, implement= XML-DSig verification (with appropriate certificate vetting etc.)=A0

If a library retrieves via http first, it presumably wo= n't try https, so if the document has no signature the client is out of= luck, even though it may well be verifiable if retrieved with TLS. =A0If o= n the other hand you try TLS first, and that fails, you know there was no T= LS available and the only recourse is to check document signatures.
=A0
If an adversary is able to ma= ke a man-in-the-middle attack against a HTTP connection, he would usually a= lso be able to prevent a HTTPS connection from being made to the same host,= so AFAICT HTTPS doesn't offer any additional security if the client ma= y just fall back to HTTP. It's like a border patrol officer asking to s= ee a traveler's passport, but if the traveler refuses to show a passpor= t or shows one that has been tampered with, the officer just lets him pass = anyway.

You'd either fail (because you d= on't know how to do XML-DSig) or you'd fail (because the MITM modif= ied the DSig protected content too) or you'd succeed (because the MITM = realized he can't modify DSig protected content). =A0I think the only p= ossibilities are total failure -- same as if the MITM blocked your access, = which of course they can do no matter what -- and secure success.
=A0

If the client finds it acceptable to fetch the host-meta document via HTTP,= it would seem easier and just a secure to simply try HTTP first and then p= ossibly fall back to HTTPS. Or did I miss something?


=A0 If a representation is successfully obtained, but is not in the
=A0 format described above, clients should infer that the path is being =A0 used for other purposes, and not process the response as a host-meta =A0 document.
There is no SHOULD/MUST/MAY in this sentence. Is "should" intende= d to mean "SHOULD", or is the client encouraged to be fault-toler= ant against invalid or non-wellformed XML?


=A0 To aid in this process, authorities using this mechanism
=A0 SHOULD correctly label host-meta responses with the
=A0 "application/xrd+xml" internet media type.
It is now explained how that aids in inferring that a path is used for othe= r purposes than a host-meta document. What is a client expected to do, if t= he Content-Type is not application/xrd+xml, or if the Content-Type *is* app= lication/xrd+xml, but the host-meta document itself is not in the described= format?


=A0 If the server response indicates that the host-meta resource is
=A0 located elsewhere (a 301, 302, or 307 response status code), the
=A0 client SHOULD try to obtain the resource from the location provided =A0 in the response. =A0This means that the host-meta document for one hos= t
=A0 MAY be retrieved from a another host.
There seems to be a conflict between "SHOULD" and "MAY"= . "MAY" indicates that following a cross-host redirect is complet= ely optional, but I assume this is not intended. The last sentence seems to= be a clarification rather than a normative statement, so perhaps "MAY= " should be replaced with just "may"?


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


--0016362841da0cb6340486967815-- From tatsuhiro.t@gmail.com Fri May 14 18:43:00 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 47C633A6802 for ; Fri, 14 May 2010 18:43:00 -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 k-qKL0jMylyO for ; Fri, 14 May 2010 18:42:59 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 2F31D3A67FC for ; Fri, 14 May 2010 18:42:59 -0700 (PDT) Received: by pzk38 with SMTP id 38so294916pzk.31 for ; Fri, 14 May 2010 18:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=bN1Exr2mwrHoC6hZ3oW3q6lLhnhxNWQYZLWQtTEZh2U=; b=I1JYaqQpiRcmAEn35jgDhK1baqUfk8/D1zYANiWh+Rs3iNBdO1kZVc20Qp14rU827r sWVhv7DQURYH0GK1aUjBbQ8QyROOVMl+gek+lfSK2JeksBg58BEfdj28t/0gtCC5j6uU r63Y/YiETWhzhp4RpLSyxpzoBLMq2bxEBQmag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=NM+4kvAhOfwvofQNTMB5En7nBN0rkyYhmzKSbpRQFmu3FjoQEKSRs+P5mZlVlCdM1n ZeI0IBgORAddD162xVOC8FxOCApCC1cmq2kPmgutGuLutTXSdSbofNTJMJHr6bKelGTZ 2qxkt+MijV9vCJWhkvCQbL4y1si8ruqc4nhoQ= Received: by 10.142.120.26 with SMTP id s26mr1278951wfc.141.1273887767561; Fri, 14 May 2010 18:42:47 -0700 (PDT) Received: from [192.168.0.11] (kng29-p43.flets.hi-ho.ne.jp [121.102.202.43]) by mx.google.com with ESMTPS id 20sm2133938pzk.15.2010.05.14.18.42.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 18:42:46 -0700 (PDT) Message-ID: <4BEDFC14.1010008@gmail.com> Date: Sat, 15 May 2010 10:42:44 +0900 From: Tatsuhiro Tsujikawa User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100411 Icedove/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: draft-bryan-ftp-hash-02 experimental client implementation 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: Sat, 15 May 2010 01:43:00 -0000 Hi, I created client implementation of draft-bryan-ftp-hash-02 using aria2 codebase. I tested with Tim's experimental FileZilla Server build. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01481.html Svn repository: http://aria2.svn.sourceforge.net/viewvc/aria2/branches/draft-bryan-ftp-hash/ Source tar ball (Google docs): http://docs.google.com/leaf?id=0B8qYMk_Gn7y6NDllYWQ2MGItMzM3Zi00MjIzLWE4MGMtZmNlMWVmOGNiODc5&hl=en Win32 binary (Google docs): http://docs.google.com/leaf?id=0B8qYMk_Gn7y6NjhhMzNjNDgtMzY4NC00ODhmLTg5YTEtZGFiZmY2MThjOTI5&hl=en While I was implementing draft, I wonder whether there is long delay before the response of hash command, because of calculation of hash in server side. For clients, especially automated ones, have some kind of timeout and if timeout reaches while server does not respond, they assume that connection is lost or something bad happened and drop session. Since hash response only appears when hash is calculated, clients cannot know the difference of hash calculation delay or some other network problem. Best regards, Tatsuhiro Tsujikawa From daniel@haxx.se Sat May 15 12:19:29 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 6AFB43A6916 for ; Sat, 15 May 2010 12:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_50=0.001, HELO_EQ_SE=0.35] 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 812+1PD0MBFg for ; Sat, 15 May 2010 12:19:28 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by core3.amsl.com (Postfix) with ESMTP id A9CFC3A68FC for ; Sat, 15 May 2010 12:19:27 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with ESMTP id o4FJJAZk027911; Sat, 15 May 2010 21:19:10 +0200 Date: Sat, 15 May 2010 21:19:10 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Tatsuhiro Tsujikawa Subject: Re: draft-bryan-ftp-hash-02 experimental client implementation In-Reply-To: <4BEDFC14.1010008@gmail.com> Message-ID: References: <4BEDFC14.1010008@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Sat, 15 May 2010 19:19:29 -0000 On Sat, 15 May 2010, Tatsuhiro Tsujikawa wrote: > While I was implementing draft, I wonder whether there is long delay before > the response of hash command, because of calculation of hash in server side. > For clients, especially automated ones, have some kind of timeout and if > timeout reaches while server does not respond, they assume that connection > is lost or something bad happened and drop session. Since hash response only > appears when hash is calculated, clients cannot know the difference of hash > calculation delay or some other network problem. Surely any client will expect ocasional very long delays from ordinary commands just due to slow/loaded servers and huge network delays? Exactly what kind of delay are you talking about here? And BTW, there's nothing in the proposal that prevents a server from responding with a non-final "progress" line from the server informing the client that it is calculating the hash, is it? -- / daniel.haxx.se From tatsuhiro.t@gmail.com Sun May 16 02:23: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 4B2EF3A699E for ; Sun, 16 May 2010 02:23:56 -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 C31tMoer48fw for ; Sun, 16 May 2010 02:23:55 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id C0F3E3A6993 for ; Sun, 16 May 2010 02:23:07 -0700 (PDT) Received: by pvg11 with SMTP id 11so1272141pvg.31 for ; Sun, 16 May 2010 02:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=v+eA2hj1Act4Q1vxEmOeBPGzUcxk6ccO3UICGTG9a78=; b=kJILsLsxzaoiTS9r9mmd9MjY9mH8quMxjp8Cw1JTFVzvQ55RL7NIWWlSE07IAiDw7A ChgH6wn0yo8t6r0fAnXm26F06tBsekV8ymuQPNZ/HkvyfwDtSoqAvnlRPRn7wWN8PWeM UlFS3lVyEv6u3F6ctlCtyE1/DopMhBMdhErws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Otz222BPVSPHuk1H3RZSq01DVEnBFyurh4ksrsw0+HYt7dkVutI45HiqjIP30qLg/A cCp0Pwho1qZO16eZt6iaJWkMH15SF5GtK5l+vRYV1HBBR7NsgpNrVjC3OnpIdEcXEPIL f41ruVHN3CvoBEm9TPk0XZHU+1oJhmFnWfBvM= Received: by 10.142.208.12 with SMTP id f12mr2385924wfg.226.1274001775857; Sun, 16 May 2010 02:22:55 -0700 (PDT) Received: from [192.168.0.11] (kng30-p57.flets.hi-ho.ne.jp [121.102.203.57]) by mx.google.com with ESMTPS id 20sm3073856pzk.15.2010.05.16.02.22.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 May 2010 02:22:54 -0700 (PDT) Message-ID: <4BEFB96C.6040509@gmail.com> Date: Sun, 16 May 2010 18:22:52 +0900 From: Tatsuhiro Tsujikawa User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100411 Icedove/3.0.4 MIME-Version: 1.0 To: Daniel Stenberg Subject: Re: draft-bryan-ftp-hash-02 experimental client implementation References: <4BEDFC14.1010008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sun, 16 May 2010 09:23:56 -0000 Hi, (05/16/10 04:19), Daniel Stenberg wrote: > On Sat, 15 May 2010, Tatsuhiro Tsujikawa wrote: > >> While I was implementing draft, I wonder whether there is long delay >> before the response of hash command, because of calculation of hash in >> server side. For clients, especially automated ones, have some kind of >> timeout and if timeout reaches while server does not respond, they >> assume that connection is lost or something bad happened and drop >> session. Since hash response only appears when hash is calculated, >> clients cannot know the difference of hash calculation delay or some >> other network problem. > > Surely any client will expect ocasional very long delays from ordinary > commands just due to slow/loaded servers and huge network delays? > Exactly what kind of delay are you talking about here? > I mean the delay during hash calculation by the server. If client knows the delay is actually caused by calculation of hash, it can wait for the response of the server beyond of timeout. > And BTW, there's nothing in the proposal that prevents a server from > responding with a non-final "progress" line from the server informing > the client that it is calculating the hash, is it? > Ah, yes, "progress" line can help here. Best regards, Tatsuhiro Tsujikawa From iulian.radu.ietf@gmx.at Wed May 19 04:49:16 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 2434A3A6819 for ; Wed, 19 May 2010 04:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.606 X-Spam-Level: * X-Spam-Status: No, score=1.606 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DEAR_SOMETHING=1.605] 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 H-gTSaDsMHzB for ; Wed, 19 May 2010 04:49:15 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7B9AA3A6AFD for ; Wed, 19 May 2010 04:48:57 -0700 (PDT) Received: (qmail 16328 invoked by uid 0); 19 May 2010 11:48:49 -0000 Received: from 80.120.134.226 by www135.gmx.net with HTTP; Wed, 19 May 2010 13:48:46 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Wed, 19 May 2010 13:48:46 +0200 From: "Iulian Radu" Message-ID: <20100519114846.211790@gmx.net> MIME-Version: 1.0 Subject: New groupware internet draft - which WG? To: apps-discuss@ietf.org X-Authenticated: #65437573 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/iKcRWFVXiBfLXhhL1DQpIW6fS/GHx9ZsBY2ueXE srJ6meZqzzZUKU6nOb+cjlVivvKEeNY1EGgQ== Content-Transfer-Encoding: 8bit X-GMX-UID: LKrGI9A4ZDIrIOtMnGU2P+d5emhmY8F/ X-FuHaFi: 0.70999999999999996 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, 19 May 2010 12:50:05 -0000 Dear Madam or Sir, I posted an internet draft about a new communication protocol which allows to store and access groupware information from a server. I would like to know to which working group from IETF should I becomme affiliate. My intention is to make it acceptable for being promoted to RFC. The name of the draft is: draft-iulian-advanced-groupware-access-protocol-01 Looking forward for your replay, Dipl.-Ing. Iulian Radu -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser From sm@resistor.net Thu May 20 09:19:49 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 06E8A3A6AA7 for ; Thu, 20 May 2010 09:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.869, 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 o-XeFwtVYATa for ; Thu, 20 May 2010 09:19:46 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 5C26B3A69F6 for ; Thu, 20 May 2010 09:19:46 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o4KGIgVC014715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 09:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1274372375; x=1274458775; bh=L7ItagTkSHo6XBlIlE61oj33qg/hyJy981RXiiF5TPA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=HgHA6UB/qByyn9NuI+5/QyU81WyuSv4357yEOCM0K78VXrzvMb/VDuUOFhCaPWNHH uDC7LnNeIKhRKIYanF5pMTkXIjX9DYMfqoYwSQCpgat5QEhHESKj3wHSco51mDiFpO 49YVNAiaxVqdBl7BZONXUx2OFHJQd9101SIfIIsk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1274372375; x=1274458775; bh=L7ItagTkSHo6XBlIlE61oj33qg/hyJy981RXiiF5TPA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=GfFmzbzgBasOs0oAHMzlaiLgULgP7bkzFeEO1vfKuWzOgHsP3Lqbkwe+gbNpYDy/W 8Jx47YC6ThuBKJZ68Mg6auc08ANfijI9BUUEueSmty7J+ax9ysG9hMfZFpPCgr4Yi6 UoJK4pgkl5gnz/kmVtgqAS8iuGxFFcnAlehk6ZAM= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=GfVlx3qnxzqOAZvNRvOgBKrB22aXZ9rg/YjRoTaIgMSv0Rr/5zG5FU9EMJa0sQxbl DbICBuh/EwVC35MGuGSJTR806plkaTvR36b28+JS9VfxllvcZYdYAwXOpjMwnLa51T3 ZbXgdYn+4cPFb1z8kVN+pIEM1X93BaZ86JcHQJw= Message-Id: <6.2.5.6.2.20100520090153.0a83aec0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 20 May 2010 09:13:18 -0700 To: Iulian Radu From: SM Subject: Re: New groupware internet draft - which WG? In-Reply-To: <20100519114846.211790@gmx.net> References: <20100519114846.211790@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 20 May 2010 16:19:49 -0000 Hi Iulian, At 04:48 19-05-10, Iulian Radu wrote: >I posted an internet draft about a new communication protocol which >allows to store and access groupware information from a server. I >would like to know to which working group from IETF should I becomme >affiliate. My intention is to make it acceptable for being promoted to RFC. > >The name of the draft is: >draft-iulian-advanced-groupware-access-protocol-01 There isn't a specific IETF working group that covers that. You can find people involved in Calendaring and Scheduling in the CALSIFY working group. If there is enough interest in the work, it could be done by chartering a new working group [1]. Alternatively, the draft can be done as an Individual Submission. Regards, -sm 1. http://www.ietf.org/tao.html From alexey.melnikov@isode.com Fri May 21 11:32: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 050CA3A680A for ; Fri, 21 May 2010 11:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=-0.882, 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 ppkH7CwETzPS for ; Fri, 21 May 2010 11:32:25 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 75F6E28C3E5 for ; Fri, 21 May 2010 09:59:19 -0700 (PDT) Received: from [172.16.2.151] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 21 May 2010 17:59:12 +0100 Message-ID: <4BF6BBD2.9040304@isode.com> Date: Fri, 21 May 2010 17:58:58 +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 Subject: Alexey's Apps Area Activity Report for April-May 2010 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: alexey-melnikov-chairs@tools.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, 21 May 2010 18:32:27 -0000 May 25-26 - IESG retreat. Then holidays for about 10 days. Document Status and Progress: Peter took over shepherding of the following documents (inherited from Lisa) - draft-giralt-schac-ns (Informational) - new revision needed - draft-rosen-urn-nena (Informational) - new revision needed Active documents, my action: - draft-daboo-srv-email (Proposed Standard) - need to address one remaining issue from David Harrington - draft-duerst-mailto-bis - IESG review ended, no DISCUSSes on the document. I need to double check that all necessary changes were applied, then request document approval - draft-saintandre-tls-server-id-check (Proposed Standard) - need to review the latest version - draft-daboo-srv-caldav-03 (Proposed Standard) - need to perform AD review draft-loreto-http-bidirectional-02 (Informational) - need to perform AD review - draft-elie-nntp-list-additions-03.txt - need to perform AD review before deciding if I am going to sponsor this document - draft-hethmon-mcmurray-ftp-hosts (Proposed Standard) - need to review the latest version and IETF LC feedback - draft-denenberg-mods-etc-media-types (Proposed Standard) - need to help the author address DISCUSSes from IESG - draft-ietf-tsvwg-iana-ports (BCP) - need to re-review the latest changes, then TSVWG WGLC - draft-gudmundsson-dns-srv-iana-registry - need to re-review Active documents, waiting on others: - draft-ietf-eai-mailinglist (Experimental) - waiting for document write-up and a new revision - draft-larmouth-oid-iri (Proposed Standard) - took over the document from Lisa, new revision needed - draft-cridland-acap-vendor-registry (Proposed Standard) - New revision needed (since 2009-11-28!) - draft-desruisseaux-caldav-sched (Proposed Standard) - performed AD review, new revision needed (since 2009-10-11!) draft-zeilenga-ldap-dontusecopy (Proposed Standard) - performed AD review, new revision needed - draft-dawkins-ldapext-subnot - performed informal review - draft-burnett-pronunciation-alphabet-registry (None) - waiting for authors to address comments from a Language Tag expert reviewer (Doug Ewell) Active documents in IETF LC or IESG review: - draft-ietf-eai-mailinglist (Experimental) - in IETF LC - draft-kucherawy-authres-header-b (Proposed Standard) - in IETF LC - draft-freed-sieve-notary (Proposed Standard) - in Second IETF LC - some major changes after SecDir feedback - rfc4049 (Experimental --> Proposed Standard) - in IETF LC - draft-santoni-media-type-tsd (Informational) - in IETF LC In RFC Editor's queue: - draft-ietf-marf-base (Proposed Standard) - approved for publication - draft-reschke-webdav-post (Proposed Standard) - approved for publication - draft-altman-tls-channel-bindings (Proposed Standard) - draft-roach-sip-http-subscribe (Proposed Standard) - draft-nottingham-http-link-header (Proposed Standard) - draft-reschke-rfc2231-in-http (Proposed Standard) - draft-ietf-morg-sortdisplay (Proposed Standard) - draft-ietf-vcarddav-carddav (Proposed Standard) - blocked on a normative reference - draft-ietf-yam-rfc1652bis (Standard) - temporarily blocked on 5321bis/5322bis Published as RFCs: - draft-ietf-eai-downgraded-display (Experimental) - RFC 5825 - draft-gould-rfc4310bis (Proposed Standard) - RFC 5910 - draft-allbery-afs-srv-records (Proposed Standard) - RFC 5864 - draft-ietf-webdav-bind (Experimental) - RFC 5842 - draft-reschke-rfc2731bis (Informational) - RFC 5791 List of DISCUSSes I am currently holding: Old: draft-drage-sipping-service-identification-03.txt draft-gennai-smime-cnipa-pec-06.txt draft-ietf-dhc-dhcpv4-vendor-message-01.txt - also took over Pasi's DISCUSS draft-ietf-dhc-dhcpv6-vendor-message-01.txt New or recently updated (last 4 weeks): draft-lawrence-sipforum-user-agent-config-01.txt draft-ietf-keyprov-symmetrickeyformat-08.txt draft-ietf-sipping-config-framework-17.txt draft-ietf-netmod-yang-12.txt draft-ietf-sipcore-info-events-08.txt draft-ietf-mext-flow-binding-06.txt draft-ietf-mediactrl-sip-control-framework-11.txt draft-ietf-mediactrl-ivr-control-package-08.txt draft-ietf-mediactrl-mixer-control-package-11.txt draft-ietf-keyprov-dskpp-11.txt draft-ietf-csi-send-cert-03.txt draft-ietf-keyprov-pskc-06.txt draft-ietf-dhc-dhcpv6-opt-netboot-08.txt Cleared DISCUSSes: draft-ietf-geopriv-geo-uri-04.txt draft-ietf-pkix-new-asn1-07.txt draft-moriarty-post-inch-rid-10.txt draft-mraihi-inch-thraud-09.txt Other activities/actions: Done: - DECADE WG got chartered - Found new Apps Area Review Team Leader (together with Peter) - performed IESG review of independent submissions: draft-meadors-ediint-features-header-06.txt and draft-sharikov-idn-reg-04.txt - Pinged IANA regarding status of draft-ietf-idnabis-*. Documents are being finally edited by RFC Editor. Ongoing: - Need to finish iMIP draft [ietf-calsify-rfc2447bis] (my own document) - Sieve WG is being rechartered to take on more work - EAI WG is being rechartered to move various Experimental documents to Standard Track - Discussing NewPrep WG chartering with Peter (Peter is going to be the responsible AD) - verified/rejected several errata items (mostly EDIINT/crisp/email/LDAP/vcard related) - requested IESG pre-evaluation of draft-ietf-yam-5321bis-smtp-pre-evaluation - discussing FTPEXT BOF in Maastricht - discussing merger of SASL & Kitten WGs (Security Area) and the new charter of the combined WG (as in individual) - agreed to help with "X- prefixes considered harmful" document (together with Peter) - Pontificating about various IESG procedures inside IESG (mostly in discussions with new ADs) My action: - Need to review OAuth document regarding possible reuse of SCRAM - Need to post 4954bis (SMTP AUTH) in order to start moving it to Draft Standard - draft-ietf-sieve-external-lists (my own document) - updated once, but it needs another update before WGLC. Thanks to Barry Leiba for picking this up. - SIP Sieve notify (my own document) - needs refreshing Waiting for others: - Suggestion to move LMTP to Standard Track (Ned Freed agreed to update the document, then responded that John Myers is interested to do this himself. Chris Newman agreed to shepherd it) - Suggestion to convert MIME BNF to ABNF and publish as a separate draft (Ned Freed agreed to do this) WG status: - DECADE just got chartered - EAI - discussions about new WG charter - HTTPBIS - steady progress - working through issues on 2616bis. - MARF submitted the first document for IESG review, some discussions about my AD review of the document - MORG - quiet - HYBI - lots of discussions about requirements on the protocol, discussion about which version of the protocol draft to accept as -00, discussions about WG process (issue tracking, etc.) - YAM - 5321bis pre-evaluation document went to IESG for review. Some discussions about pre-evaluation documents for 5322bis, MIME. From eran@hueniverse.com Tue May 25 12:35: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 763F63A69E5 for ; Tue, 25 May 2010 12:35:55 -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 88rc1ODpmX8m for ; Tue, 25 May 2010 12:35:54 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C88EB3A69CC for ; Tue, 25 May 2010 12:35:53 -0700 (PDT) Received: (qmail 19055 invoked from network); 25 May 2010 19:35:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 May 2010 19:35:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 25 May 2010 12:35:38 -0700 From: Eran Hammer-Lahav To: "Apps Discuss (discuss@apps.ietf.org)" Date: Tue, 25 May 2010 12:35:20 -0700 Subject: FW: New Version Notification for draft-hammer-hostmeta-10 Thread-Topic: New Version Notification for draft-hammer-hostmeta-10 Thread-Index: Acr8P/SXb5OuiPwMS6qQFHDhfxJyQAAAHIOw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE215@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: Tue, 25 May 2010 19:35:55 -0000 QWZ0ZXIgcmVjZW50IGRpc2N1c3Npb25zIGF0IElJVyBhYm91dCB1c2UgY2FzZXMgZm9yIGJvdGgg aG9zdC1tZXRhIFsxXSBhbmQgTFJERCBbMl0sIEkgY2FtZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0 IHRoZXJlIGlzIGxpdHRsZSB2YWx1ZSBpbiB0aGUgbXVsdGktbGluay1zb3VyY2VzIGFwcHJvYWNo IChjb2xsZWN0aW5nIGxpbmtzIGZyb20gaG9zdC1tZXRhLCBIVFRQIGhlYWRlcnMsIGFuZCBIVE1M IGVsZW1lbnRzKS4gU2luY2UgdGhlIGxhdGVzdCBMUkREIGRyYWZ0IHJlcXVpcmVzIG9idGFpbmlu ZyBob3N0LW1ldGEgYXMgdGhlIGZpcnN0IHN0ZXAgYW55d2F5LCBpdCBzaWduaWZpY2FudGx5IHJl ZHVjZXMgdGhlIHZhbHVlIG9mIHVzaW5nIGxpbmtzIGVsc2V3aGVyZSAoZm9yIHRoaXMgcHVycG9z ZSkuDQoNClRoZSBuZXcgaG9zdC1tZXRhIGRyYWZ0IGluY29ycG9yYXRlcyB0aGUgaG9zdC1tZXRh IHBhcnRzIG9mIExSREQsIGluY2x1ZGluZyB0aGUgcmVnaXN0cmF0aW9uIG9mIHRoZSAnbHJkZCcg cmVsYXRpb24gdHlwZS4gTXkgaW50ZW50aW9uIGlzIHRvIGFiYW5kb24gdGhlIExSREQgcHJvcG9z YWwgYW5kIGZvY3VzIG9ubHkgb24gaG9zdC1tZXRhLiBUaG9zZSB1c2luZyBvbmx5IGhvc3QtbWV0 YSBhcmUgdW5hZmZlY3RlZCBieSB0aGlzIGNoYW5nZS4NCg0KRmVlZGJhY2sgb24gdGhlIGxhdGVz dCBob3N0LW1ldGEgZHJhZnQgaXMgcmVxdWVzdGVkLg0KDQpFSEwNCg0KWzFdIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhbW1lci1ob3N0bWV0YQ0KWzJdIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWhhbW1lci1kaXNjb3ZlcnkNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJt aXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIE1heSAyNSwgMjAxMCAxMjoyNSBQTQ0K VG86IEVyYW4gSGFtbWVyLUxhaGF2DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWhhbW1lci1ob3N0bWV0YS0xMCANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtaGFtbWVyLWhvc3RtZXRhLTEwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IEVyYW4gSGFtbWVyLUxhaGF2IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1oYW1tZXItaG9zdG1ldGENClJldmlzaW9uOgkgMTANClRp dGxlOgkJIFdlYiBIb3N0IE1ldGFkYXRhDQpDcmVhdGlvbl9kYXRlOgkgMjAxMC0wNS0yNQ0KV0cg SUQ6CQkgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KTnVtYmVyX29mX3BhZ2VzOiAxNQ0KDQpBYnN0 cmFjdDoNClRoaXMgbWVtbyBkZXNjcmliZXMgYSBtZXRob2QgZm9yIGxvY2F0aW5nIGhvc3QgbWV0 YWRhdGEgYXMgd2VsbCBhcyBpbmZvcm1hdGlvbiBhYm91dCBpbmRpdmlkdWFsIHJlc291cmNlcyBj b250cm9sbGVkIGJ5IHRoZSBob3N0Lg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg== From jpanzer@google.com Tue May 25 13:25:49 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 B7A423A6A81 for ; Tue, 25 May 2010 13:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.376 X-Spam-Level: X-Spam-Status: No, score=-103.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 cCpTI0SqCMHj for ; Tue, 25 May 2010 13:25:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id F26433A6A7D for ; Tue, 25 May 2010 13:25:47 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o4PKPdZj016445 for ; Tue, 25 May 2010 13:25:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274819139; bh=Y6Y/ZkLUIxzjjeDOKha+dyoa08A=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=FNgNNd0nQguG4Ikva6+setc09erEC6+zVikNoDYDUStXXfjnVuqgFXz6RIX3SafYy iqLvNbB3TRrkCjUaDpQgQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=tez6+6ztfW9spUA+eXp9OLBHyeFtn5kaUdSN7+7F5zP+SoUMk3wQjHx4BIHX2TUdL epe476cs/w4zNOarOgucw== Received: from vws20 (vws20.prod.google.com [10.241.21.148]) by wpaz5.hot.corp.google.com with ESMTP id o4PKPboi009434 for ; Tue, 25 May 2010 13:25:38 -0700 Received: by vws20 with SMTP id 20so3311177vws.20 for ; Tue, 25 May 2010 13:25:37 -0700 (PDT) Received: by 10.220.121.148 with SMTP id h20mr5403029vcr.14.1274819136126; Tue, 25 May 2010 13:25:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.61.142 with HTTP; Tue, 25 May 2010 13:25:16 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE215@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE215@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Tue, 25 May 2010 13:25:16 -0700 Message-ID: Subject: Re: FW: New Version Notification for draft-hammer-hostmeta-10 To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e68f9ca7c2fe62048770f522 X-System-Of-Record: true Cc: "Apps Discuss \(discuss@apps.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: Tue, 25 May 2010 20:25:49 -0000 --0016e68f9ca7c2fe62048770f522 Content-Type: text/plain; charset=ISO-8859-1 (As you know) like this approach much better, primarily because it reduces the complexity of implementation down to what we've already coded up for Webfinger, but allows non-acct: URIs as well. Thus Webfinger is just acct: + host-meta, done. Compared to the prior LRDD spec, this doesn't increase the number of required HTTP requests, actually reduces them in some cases (http URLs that would also require resolution at the resource level), and probably improves interop due to simplicity. NB: The one drawback is that resource owners who do not control /.well-known/host-meta are dependent on their hosting provider to implement LRDD links. This drawback is also a security feature, and hosting providers even with the prior spec were able to block per-resource LRDD if they wanted to. Note that this does not lock out individuals from implementing this themselves at all; at worst, they just need to control their own domain name and be able to copy /.well-known/host-meta to their host. This is a tiny speedbump, at last glance could be had for ~$30 per person, and I think is well worth the security and simplicity trade-offs. On Tue, May 25, 2010 at 12:35 PM, Eran Hammer-Lahav wrote: > After recent discussions at IIW about use cases for both host-meta [1] and > LRDD [2], I came to the conclusion that there is little value in the > multi-link-sources approach (collecting links from host-meta, HTTP headers, > and HTML elements). Since the latest LRDD draft requires obtaining host-meta > as the first step anyway, it significantly reduces the value of using links > elsewhere (for this purpose). > > The new host-meta draft incorporates the host-meta parts of LRDD, including > the registration of the 'lrdd' relation type. My intention is to abandon the > LRDD proposal and focus only on host-meta. Those using only host-meta are > unaffected by this change. > > Feedback on the latest host-meta draft is requested. > > EHL > > [1] http://tools.ietf.org/html/draft-hammer-hostmeta > [2] http://tools.ietf.org/html/draft-hammer-discovery > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, May 25, 2010 12:25 PM > To: Eran Hammer-Lahav > Subject: New Version Notification for draft-hammer-hostmeta-10 > > > A new version of I-D, draft-hammer-hostmeta-10.txt has been successfully > submitted by Eran Hammer-Lahav and posted to the IETF repository. > > Filename: draft-hammer-hostmeta > Revision: 10 > Title: Web Host Metadata > Creation_date: 2010-05-25 > WG ID: Independent Submission > Number_of_pages: 15 > > Abstract: > This memo describes a method for locating host metadata as well as > information about individual resources controlled by the host. > > > > The IETF Secretariat. > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --0016e68f9ca7c2fe62048770f522 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (As you know) like this approach much better, primarily because it reduces = the complexity of implementation down to what we've already coded up fo= r Webfinger, but allows non-acct: URIs as well. =A0Thus Webfinger is just a= cct: + host-meta, done.

Compared to the prior LRDD spec, this doesn't increase t= he number of required HTTP requests, actually reduces them in some cases (h= ttp URLs that would also require resolution at the resource level), and pro= bably improves interop due to simplicity.

NB: The one drawback is that resource owners who do not= control /.well-known/host-meta are dependent on their hosting provider to = implement LRDD links. =A0This drawback is also a security feature, and host= ing providers even with the prior spec were able to block per-resource LRDD= if they wanted to. =A0Note that this does not lock out individuals from im= plementing this themselves at all; at worst, they just need to control thei= r own domain name and be able to copy /.well-known/host-meta to their host.= =A0This is a tiny speedbump, at last glance could be had for ~$30 per pers= on, and I think is well worth the security and simplicity trade-offs.


On Tue, May 25, 2010 at 12:35 PM, E= ran Hammer-Lahav <eran@hueniverse.com> wrote:
After recent discussions at IIW about use cases for both host-meta [1] and = LRDD [2], I came to the conclusion that there is little value in the multi-= link-sources approach (collecting links from host-meta, HTTP headers, and H= TML elements). Since the latest LRDD draft requires obtaining host-meta as = the first step anyway, it significantly reduces the value of using links el= sewhere (for this purpose).

The new host-meta draft incorporates the host-meta parts of LRDD, including= the registration of the 'lrdd' relation type. My intention is to a= bandon the LRDD proposal and focus only on host-meta. Those using only host= -meta are unaffected by this change.

Feedback on the latest host-meta draft is requested.

EHL

[1] http://tools.ietf.org/html/draft-hammer-hostmeta
[2] http://tools.ietf.org/html/draft-hammer-discovery


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
Sent: Tuesday, May 25, 2010 12:25 PM
To: Eran Hammer-Lahav
Subject: New Version Notification for draft-hammer-hostmeta-10


A new version of I-D, draft-hammer-hostmeta-10.txt has been successfully su= bmitted by Eran Hammer-Lahav and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-hammer-hostmeta
Revision: =A0 =A0 =A0 =A010
Title: =A0 =A0 =A0 =A0 =A0 Web Host Metadata
Creation_date: =A0 2010-05-25
WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
Number_of_pages: 15

Abstract:
This memo describes a method for locating host metadata as well as informat= ion about individual resources controlled by the host.



The IETF Secretariat.


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

--0016e68f9ca7c2fe62048770f522-- From bobwyman@gmail.com Tue May 25 13:31:49 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 2E31A3A69DA for ; Tue, 25 May 2010 13:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.83 X-Spam-Level: X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[AWL=0.947, BAYES_20=-0.74, 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 aEP3lSiSFe9l for ; Tue, 25 May 2010 13:31:48 -0700 (PDT) Received: from mail-gy0-f177.google.com (mail-gy0-f177.google.com [209.85.160.177]) by core3.amsl.com (Postfix) with ESMTP id DCB2A3A6A48 for ; Tue, 25 May 2010 13:31:47 -0700 (PDT) Received: by gyb11 with SMTP id 11so2311101gyb.22 for ; Tue, 25 May 2010 13:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=WUtaCnc6E4dhg0OWNbDJMnRA/Enl97R+WP0z1LZkgKo=; b=olPldkXgVWro+VIgGkRqzvf+5iwTJebQoNr130k5IM/PnhnaEKtcIFguEMFYCa8XVQ lWUJdVH4yZqLaQw/NmXOg3vnDyGvIYZDg4mwqEiD9KD+z8R25i5O5ywn0ROoaTiM7lE7 IPF0bsrfeX37gng4d0lcrTBOO+WOY3RHlh3Xk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=nh4JqBGjaWqN3fTGwnZvXnv2l6qAvdZmXxlitjUMvqLJc6vK0MjexAghQHtBXm8NUp fXIvLH/ylJB8P+nTCWzlyecaKpIzHxjLpxCC0xrhCZCs9rPRuPhSQrWz+cQME+XlVF5s OTEXz54HpT1eXEu5M09ChYk2T+Igt/NRRwA2g= MIME-Version: 1.0 Received: by 10.101.135.31 with SMTP id m31mr8856543ann.164.1274819495532; Tue, 25 May 2010 13:31:35 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.100.154.20 with HTTP; Tue, 25 May 2010 13:31:35 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE215@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 25 May 2010 16:31:35 -0400 X-Google-Sender-Auth: 2RgpxNZjA1Q05NyLOMGWgnneruk Message-ID: Subject: Re: FW: New Version Notification for draft-hammer-hostmeta-10 From: Bob Wyman To: John Panzer Content-Type: multipart/alternative; boundary=001636c5c0422f20f50487710b5d Cc: "Apps Discuss \(discuss@apps.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: Tue, 25 May 2010 20:33:35 -0000 --001636c5c0422f20f50487710b5d Content-Type: text/plain; charset=ISO-8859-1 John Panzer wrote: > resource owners who do not control > /.well-known/host-meta are dependent > on their hosting provider This problem may be more wide-spread than folk may think. I'm rather miffed, for instance, that since *my* blog in on TypePad and since years ago I enabled the "multi-blog" support option, there is simply no way that I can put a .well-known file in a useful location on Typepad... bob wyman On Tue, May 25, 2010 at 4:25 PM, John Panzer wrote: > (As you know) like this approach much better, primarily because it reduces > the complexity of implementation down to what we've already coded up for > Webfinger, but allows non-acct: URIs as well. Thus Webfinger is just acct: > + host-meta, done. > > Compared to the prior LRDD spec, this doesn't increase the number of > required HTTP requests, actually reduces them in some cases (http URLs that > would also require resolution at the resource level), and probably improves > interop due to simplicity. > > NB: The one drawback is that resource owners who do not control > /.well-known/host-meta are dependent on their hosting provider to implement > LRDD links. This drawback is also a security feature, and hosting providers > even with the prior spec were able to block per-resource LRDD if they wanted > to. Note that this does not lock out individuals from implementing this > themselves at all; at worst, they just need to control their own domain name > and be able to copy /.well-known/host-meta to their host. This is a tiny > speedbump, at last glance could be had for ~$30 per person, and I think is > well worth the security and simplicity trade-offs. > > > On Tue, May 25, 2010 at 12:35 PM, Eran Hammer-Lahav wrote: > >> After recent discussions at IIW about use cases for both host-meta [1] and >> LRDD [2], I came to the conclusion that there is little value in the >> multi-link-sources approach (collecting links from host-meta, HTTP headers, >> and HTML elements). Since the latest LRDD draft requires obtaining host-meta >> as the first step anyway, it significantly reduces the value of using links >> elsewhere (for this purpose). >> >> The new host-meta draft incorporates the host-meta parts of LRDD, >> including the registration of the 'lrdd' relation type. My intention is to >> abandon the LRDD proposal and focus only on host-meta. Those using only >> host-meta are unaffected by this change. >> >> Feedback on the latest host-meta draft is requested. >> >> EHL >> >> [1] http://tools.ietf.org/html/draft-hammer-hostmeta >> [2] http://tools.ietf.org/html/draft-hammer-discovery >> >> >> -----Original Message----- >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Sent: Tuesday, May 25, 2010 12:25 PM >> To: Eran Hammer-Lahav >> Subject: New Version Notification for draft-hammer-hostmeta-10 >> >> >> A new version of I-D, draft-hammer-hostmeta-10.txt has been successfully >> submitted by Eran Hammer-Lahav and posted to the IETF repository. >> >> Filename: draft-hammer-hostmeta >> Revision: 10 >> Title: Web Host Metadata >> Creation_date: 2010-05-25 >> WG ID: Independent Submission >> Number_of_pages: 15 >> >> Abstract: >> This memo describes a method for locating host metadata as well as >> information about individual resources controlled by the host. >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --001636c5c0422f20f50487710b5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
John Panzer=A0<jpanzer@google.com>=A0wrote:
>=A0resource owners wh= o do not control=A0
> /.well-known/host-meta are dependent
> on their hosting p= rovider=A0

This problem may be more wide-spread than folk= may think. I'm rather miffed, for instance, that since my blog = in on TypePad and since years ago I enabled the "multi-blog" supp= ort option, there is simply no way that I can put a .well-known file in a u= seful location on Typepad...

bob wyman


On Tue, May 25, 2010 at 4:25 PM, John Panzer &= lt;jpanzer@google.com> = wrote:
(As you know) like this approach much bette= r, primarily because it reduces the complexity of implementation down to wh= at we've already coded up for Webfinger, but allows non-acct: URIs as w= ell. =A0Thus Webfinger is just acct: + host-meta, done.

Compared to the prior LRDD spec, this doesn't increase t= he number of required HTTP requests, actually reduces them in some cases (h= ttp URLs that would also require resolution at the resource level), and pro= bably improves interop due to simplicity.

NB: The one drawback is that resource owners who do not= control /.well-known/host-meta are dependent on their hosting provider to = implement LRDD links. =A0This drawback is also a security feature, and host= ing providers even with the prior spec were able to block per-resource LRDD= if they wanted to. =A0Note that this does not lock out individuals from im= plementing this themselves at all; at worst, they just need to control thei= r own domain name and be able to copy /.well-known/host-meta to their host.= =A0This is a tiny speedbump, at last glance could be had for ~$30 per pers= on, and I think is well worth the security and simplicity trade-offs.


On Tue, May 25, 2010 at 12:35 PM, E= ran Hammer-Lahav <eran@hueniverse.com> wrote:
After recent discussions at IIW about use cases for both host-meta [1] and = LRDD [2], I came to the conclusion that there is little value in the multi-= link-sources approach (collecting links from host-meta, HTTP headers, and H= TML elements). Since the latest LRDD draft requires obtaining host-meta as = the first step anyway, it significantly reduces the value of using links el= sewhere (for this purpose).

The new host-meta draft incorporates the host-meta parts of LRDD, including= the registration of the 'lrdd' relation type. My intention is to a= bandon the LRDD proposal and focus only on host-meta. Those using only host= -meta are unaffected by this change.

Feedback on the latest host-meta draft is requested.

EHL

[1] http://tools.ietf.org/html/draft-hammer-hostmeta
[2] http://tools.ietf.org/html/draft-hammer-discovery


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
Sent: Tuesday, May 25, 2010 12:25 PM
To: Eran Hammer-Lahav
Subject: New Version Notification for draft-hammer-hostmeta-10


A new version of I-D, draft-hammer-hostmeta-10.txt has been successfully su= bmitted by Eran Hammer-Lahav and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-hammer-hostmeta
Revision: =A0 =A0 =A0 =A010
Title: =A0 =A0 =A0 =A0 =A0 Web Host Metadata
Creation_date: =A0 2010-05-25
WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
Number_of_pages: 15

Abstract:
This memo describes a method for locating host metadata as well as informat= ion about individual resources controlled by the host.



The IETF Secretariat.


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


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


--001636c5c0422f20f50487710b5d-- From eran@hueniverse.com Tue May 25 13:34: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 070133A6A1F for ; Tue, 25 May 2010 13:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_40=-0.185, 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 lB43JT1+zhH5 for ; Tue, 25 May 2010 13:34:01 -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 7C88F3A69ED for ; Tue, 25 May 2010 13:34:01 -0700 (PDT) Received: (qmail 15164 invoked from network); 25 May 2010 20:33:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 May 2010 20:33:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 25 May 2010 13:33:52 -0700 From: Eran Hammer-Lahav To: Bob Wyman , John Panzer Date: Tue, 25 May 2010 13:33:34 -0700 Subject: RE: FW: New Version Notification for draft-hammer-hostmeta-10 Thread-Topic: FW: New Version Notification for draft-hammer-hostmeta-10 Thread-Index: Acr8SVBPKC6lCJNaSASX/9sdCBATlQAACUIw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE275@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE215@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3B8CE275P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "Apps Discuss \(discuss@apps.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: Tue, 25 May 2010 20:34:03 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B8CE275P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds like something you should bring up with Typepad. The ability of user= s to hack their blogging platform seems like a bad thing to enable. EHL From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Tuesday, May 25, 2010 1:32 PM To: John Panzer Cc: Eran Hammer-Lahav; Apps Discuss (discuss@apps.ietf.org) Subject: Re: FW: New Version Notification for draft-hammer-hostmeta-10 John Panzer > wrote: > resource owners who do not control > /.well-known/host-meta are dependent > on their hosting provider This problem may be more wide-spread than folk may think. I'm rather miffed= , for instance, that since my blog in on TypePad and since years ago I enab= led the "multi-blog" support option, there is simply no way that I can put = a .well-known file in a useful location on Typepad... bob wyman On Tue, May 25, 2010 at 4:25 PM, John Panzer > wrote: (As you know) like this approach much better, primarily because it reduces = the complexity of implementation down to what we've already coded up for We= bfinger, but allows non-acct: URIs as well. Thus Webfinger is just acct: += host-meta, done. Compared to the prior LRDD spec, this doesn't increase the number of requir= ed HTTP requests, actually reduces them in some cases (http URLs that would= also require resolution at the resource level), and probably improves inte= rop due to simplicity. NB: The one drawback is that resource owners who do not control /.well-know= n/host-meta are dependent on their hosting provider to implement LRDD links= . This drawback is also a security feature, and hosting providers even wit= h the prior spec were able to block per-resource LRDD if they wanted to. N= ote that this does not lock out individuals from implementing this themselv= es at all; at worst, they just need to control their own domain name and be= able to copy /.well-known/host-meta to their host. This is a tiny speedbu= mp, at last glance could be had for ~$30 per person, and I think is well wo= rth the security and simplicity trade-offs. On Tue, May 25, 2010 at 12:35 PM, Eran Hammer-Lahav > wrote: After recent discussions at IIW about use cases for both host-meta [1] and = LRDD [2], I came to the conclusion that there is little value in the multi-= link-sources approach (collecting links from host-meta, HTTP headers, and H= TML elements). Since the latest LRDD draft requires obtaining host-meta as = the first step anyway, it significantly reduces the value of using links el= sewhere (for this purpose). The new host-meta draft incorporates the host-meta parts of LRDD, including= the registration of the 'lrdd' relation type. My intention is to abandon t= he LRDD proposal and focus only on host-meta. Those using only host-meta ar= e unaffected by this change. Feedback on the latest host-meta draft is requested. EHL [1] http://tools.ietf.org/html/draft-hammer-hostmeta [2] http://tools.ietf.org/html/draft-hammer-discovery -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, May 25, 2010 12:25 PM To: Eran Hammer-Lahav Subject: New Version Notification for draft-hammer-hostmeta-10 A new version of I-D, draft-hammer-hostmeta-10.txt has been successfully su= bmitted by Eran Hammer-Lahav and posted to the IETF repository. Filename: draft-hammer-hostmeta Revision: 10 Title: Web Host Metadata Creation_date: 2010-05-25 WG ID: Independent Submission Number_of_pages: 15 Abstract: This memo describes a method for locating host metadata as well as informat= ion about individual resources controlled by the host. The IETF Secretariat. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B8CE275P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sounds li= ke something you should bring up with Typepad. The ability of users to hack= their blogging platform seems like a bad thing to enable.

 

EHL

&nb= sp;

 

From: bobwyman@gmail.com [mailto:b= obwyman@gmail.com] On Behalf Of Bob Wyman
Sent: Tuesday, M= ay 25, 2010 1:32 PM
To: John Panzer
Cc: Eran Hammer-Lah= av; Apps Discuss (discuss@apps.ietf.org)
Subject: Re: FW: New Ver= sion Notification for draft-hammer-hostmeta-10

<= /div>

 

Jo= hn Panzer <jpanzer@google.com= > wrote:

> res= ource owners who do not control 

> /.well-known/host-meta are dependent

> on their hosting provid= er 

This problem may be = more wide-spread than folk may think. I'm rather miffed, for instance, that= since my blog in on TypePad and since years ago I enabled the "= ;multi-blog" support option, there is simply no way that I can put a .= well-known file in a useful location on Typepad...

 

= bob wyman

 

 

On Tue, May 25, 2010 at 4:25 PM, John Panzer <jpanzer@google.com> wrote:

(As you know) like this approach much better, primarily becaus= e it reduces the complexity of implementation down to what we've already co= ded up for Webfinger, but allows non-acct: URIs as well.  Thus Webfing= er is just acct: + host-meta, done.

 

Compared to the prior= LRDD spec, this doesn't increase the number of required HTTP requests, act= ually reduces them in some cases (http URLs that would also require resolut= ion at the resource level), and probably improves interop due to simplicity= .

 

=

NB: The one drawback is that resource owners who = do not control /.well-known/host-meta are dependent on their hosting provid= er to implement LRDD links.  This drawback is also a security feature,= and hosting providers even with the prior spec were able to block per-reso= urce LRDD if they wanted to.  Note that this does not lock out individ= uals from implementing this themselves at all; at worst, they just need to = control their own domain name and be able to copy /.well-known/host-meta to= their host.  This is a tiny speedbump, at last glance could be had fo= r ~$30 per person, and I think is well worth the security and simplicity tr= ade-offs.

 

On Tue= , May 25, 2010 at 12:35 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

After recent discussions at IIW about use cases = for both host-meta [1] and LRDD [2], I came to the conclusion that there is= little value in the multi-link-sources approach (collecting links from hos= t-meta, HTTP headers, and HTML elements). Since the latest LRDD draft requi= res obtaining host-meta as the first step anyway, it significantly reduces = the value of using links elsewhere (for this purpose).

The new host-= meta draft incorporates the host-meta parts of LRDD, including the registra= tion of the 'lrdd' relation type. My intention is to abandon the LRDD propo= sal and focus only on host-meta. Those using only host-meta are unaffected = by this change.

Feedback on the latest host-meta draft is requested.=

EHL

[1] http://tools.ietf.org/html/draft-hammer-hostmeta=
[2] http://tools.ietf.org/html/draft-hammer-discovery
<= br>
-----Original Message-----
From: IETF I-D Submission Tool [mailto= :idsubmission@ie= tf.org]
Sent: Tuesday, May 25, 2010 12:25 PM
To: Eran Hammer-Laha= v
Subject: New Version Notification for draft-hammer-hostmeta-10

=
A new version of I-D, draft-hammer-hostmeta-10.txt has been successfull= y submitted by Eran Hammer-Lahav and posted to the IETF repository.

= Filename:        draft-hammer-hostmeta
Revision: &nb= sp;      10
Title:           Web= Host Metadata
Creation_date:   2010-05-25
WG ID:     =       Independent Submission
Number_of_pages: 15

A= bstract:
This memo describes a method for locating host metadata as well= as information about individual resources controlled by the host.

<= br>
The IETF Secretariat.


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

 


_____________________________________________= __
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/a= pps-discuss

 <= /p>

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B8CE275P3PW5EX1MB01E_-- From eran@hueniverse.com Tue May 25 13:37: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 8F08B3A6A7B for ; Tue, 25 May 2010 13:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 WZLe-vBlIj+H for ; Tue, 25 May 2010 13:37:16 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6E8A63A6A7A for ; Tue, 25 May 2010 13:37:16 -0700 (PDT) Received: (qmail 31409 invoked from network); 25 May 2010 20:37:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 May 2010 20:37:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 25 May 2010 13:37:07 -0700 From: Eran Hammer-Lahav To: "Paul E. Jones" , "discuss@apps.ietf.org" Date: Tue, 25 May 2010 13:36:52 -0700 Subject: RE: Update on resource descriptor discovery work Thread-Topic: Update on resource descriptor discovery work Thread-Index: AcrxnpKcHxKdQRGJRGmxdeIPs3YKVQAqTLnQAAWMIJAAFgR0oAABIAegAAHnyIACYeyh4A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE27B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <004901caf247$d4d61480$7e823d80$@com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB477D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012801caf2b8$c3c8ee30$4b5aca90$@com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6987EB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <013001caf2c4$d0d719b0$72854d10$@com> In-Reply-To: <013001caf2c4$d0d719b0$72854d10$@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 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, 25 May 2010 20:37:17 -0000 I removed the text about the extra redirection support. It just says you ha= ve to follow redirections and the rest is implied from 2616. As for 304, I = think by saying that a 304 response is allows, using the caches copy is cle= arly implied (since the client did something to trigger this). EHL > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, May 13, 2010 10:51 AM > To: Eran Hammer-Lahav; discuss@apps.ietf.org > Subject: RE: Update on resource descriptor discovery work >=20 > Eran, >=20 > > My concern is a MUST with potentially impractical repercussions (like > > following hundreds of redirections). In a browser this isn't an issue > > because there is a person sitting there with its own limit (how long > > the user is willing to sit there and stare at the URI changing without > > getting results). But for a client performing discovery, especially in > > UI sensitive applications, this can be a problem. > > > > It would be helpful to know how other specifications handle such a > > requirement. Make it a MUST with a minimum number of redirections? > > Make it a MUST and assume the client will exit the loop as it see fit? > > Make it a SHOULD? > > > > What's the best approach here in terms of language (since I think we > > agree on substance)? >=20 > Good question. RFC 2616 said: > Note: previous versions of this specification recommended a > maximum of five redirections. Content developers should be aware > that there might be clients that implement such a fixed > limitation. >=20 > There appears to be no specified maximum now. It also says a client SHOU= LD > detect infinite loops, which I think is unfortunate, as I would have made= it a > MUST. >=20 > I, too, would like to know why 5 was specified and why no limit is now > specified. I think it does at least hint that 5 might be too restrictive= , but I > don't know what general practice is. I just checked some code I wrote an= d, > while it checks for loops, it imposed no limit on the number of redirecti= ons. > How trusting I am ;-) >=20 > > > > > In Section 4.3, it states that tags in document markup must be > > > > processed only > > > > > on a 200? What about a 304? You want to exclude use of the > > > > > local > > > > cache? > > > > > > > > Caching is allowed. A 304 just means the client can use a > > previously > > > > obtained document with a 200 status code. The client doesn't need > > to > > > > request anything if they have a valid copy in their cache. I think > > > > this is implied. > > > > > > It was implicit to me until I read that sentence. My impression was > > that you > > > wanted to forbid use of the local cache for some reason. > > > > What's the general approach in such cases? Should the spec explicitly > > call out the use of caching? >=20 > Had you not written that sentence that said to process HTML document only > if we receive a 200, I would have used the cached file if I received a 30= 4. > I'd suggest having a statement that says the cached copy must be used if = a > 304 is returned. >=20 > Paul >=20 From eran@hueniverse.com Tue May 25 14:56:37 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 5A7F63A7A26 for ; Tue, 25 May 2010 14:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 rTGNTAdyCxqh for ; Tue, 25 May 2010 14:56:36 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 51EF33A74A0 for ; Tue, 25 May 2010 14:04:11 -0700 (PDT) Received: (qmail 17449 invoked from network); 25 May 2010 21:04:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 May 2010 21:04:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 25 May 2010 14:04:02 -0700 From: Eran Hammer-Lahav To: Christian Schmidt , "apps-discuss@ietf.org" Date: Tue, 25 May 2010 14:03:46 -0700 Subject: RE: draft-hammer-hostmeta-08: HTTPS requirement Thread-Topic: draft-hammer-hostmeta-08: HTTPS requirement Thread-Index: Acrzn7sF5S1e594jRU+3r1g7I+fIZAIqrsXA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE297@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BEDA847.6090004@chsc.dk> In-Reply-To: <4BEDA847.6090004@chsc.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-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, 25 May 2010 21:56:37 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Christian Schmidt > Sent: Friday, May 14, 2010 12:45 PM > > Clients obtain the host-meta document for a given host by making an > > HTTPS [RFC2818] GET request to the host's port 443 for the > > "/.well-known/host-meta" path. If the request fails to produce a > > valid host-meta document, clients make an HTTP [RFC2616] GET request > > to the host's port 80 for the "/.well-known/host-meta" path. > In brief: Try fetching the host-meta file via HTTPS. If that fails, fall = back to > HTTP. I don't understand this requirement. >=20 > The usual reason for preferring HTTPS over HTTP is the need for secrecy > (using encryption) and/or identification of the server (using certificate= s > signed by a trusted authority). AFAICT the host-meta is intended to > published to everybody without any access control, so secrecy is not an > issue. If identification of the server is considered important to the cli= ent, it > should only accept a host-meta document fetched via HTTPS. If an adversar= y > is able to make a man-in-the-middle attack against a HTTP connection, he > would usually also be able to prevent a HTTPS connection from being made > to the same host, so AFAICT HTTPS doesn't offer any additional security i= f the > client may just fall back to HTTP. It's like a border patrol officer aski= ng to see a > traveler's passport, but if the traveler refuses to show a passport or sh= ows > one that has been tampered with, the officer just lets him pass anyway. It is only used for server identification. Falling back to HTTP is a matter= of protocol policy. It depends on what you use the document for. Also, the= re might be other ways to identify the server (such as signed documents ove= r HTTP). The security consideration section includes this: "Protocols MAY restrict document retrieval to HTTPS based on their security= needs." If you think it is not enough, please suggest text. > If the client finds it acceptable to fetch the host-meta document via HTT= P, it > would seem easier and just a secure to simply try HTTP first and then pos= sibly > fall back to HTTPS. Or did I miss something? The two options are not to specify an order to preference, leaving it up to= each protocol to decide, or specify an order in which case HTTPS should co= me first. > > If a representation is successfully obtained, but is not in the > > format described above, clients should infer that the path is being > > used for other purposes, and not process the response as a host-meta > > document. > There is no SHOULD/MUST/MAY in this sentence. Is "should" intended to > mean "SHOULD", or is the client encouraged to be fault-tolerant against > invalid or non-wellformed XML? Changed to MUST NOT use invalid documents. =20 > > To aid in this process, authorities using this mechanism > > SHOULD correctly label host-meta responses with the > > "application/xrd+xml" internet media type. > It is now explained how that aids in inferring that a path is used for ot= her > purposes than a host-meta document. What is a client expected to do, if t= he > Content-Type is not application/xrd+xml, or if the Content-Type *is* > application/xrd+xml, but the host-meta document itself is not in the > described format? What matters is that the document is a valid XRD document obtained from tha= t location. This is just a suggestion to make things easier to spot faster.= If the media type is different, it is up to the client to decide what to d= o (for example, it might be another extension format the client understands= and knows how to convert into XRD). I think this is fine as is with the ab= ove change. > > If the server response indicates that the host-meta resource is > > located elsewhere (a 301, 302, or 307 response status code), the > > client SHOULD try to obtain the resource from the location provided > > in the response. This means that the host-meta document for one hos= t > > MAY be retrieved from a another host. > There seems to be a conflict between "SHOULD" and "MAY". "MAY" > indicates that following a cross-host redirect is completely optional, bu= t I > assume this is not intended. The last sentence seems to be a clarificatio= n > rather than a normative statement, so perhaps "MAY" should be replaced > with just "may"? First, if the host-meta response redirects elsewhere, the client SHOULD fol= low it. It is a SHOULD because there are security issues with crossing auth= ority lines. Server are allowed to do this, which is what the MAY is about. EHL From jpanzer@google.com Tue May 25 17:28: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 3D7B33A65A6 for ; Tue, 25 May 2010 17:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AA3BiJNBMHF for ; Tue, 25 May 2010 17:28:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D83373A6B2C for ; Tue, 25 May 2010 15:29:22 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o4PMT7lX016293 for ; Tue, 25 May 2010 15:29:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274826553; bh=8mrChvVvfjecahZMjkWcWTo4m7k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=T1ZMphR79+ysjMwfkTJNBJs032acDU857nZEN4ANzGez5Sqirrl4hOupSCDakEtQD aqqxKzkqNX0E2P/m0vVTQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=H9q7n/+UNAcFhtlCoaTwpXHh1cX0Kh9023yELnt/NI4b90kaS/YQaZ9zDdEtYMyqM dEm0//hUGySavxxjPu5+w== Received: from vws11 (vws11.prod.google.com [10.241.21.139]) by kpbe19.cbf.corp.google.com with ESMTP id o4PMT5Dx028096 for ; Tue, 25 May 2010 15:29:05 -0700 Received: by vws11 with SMTP id 11so2357323vws.37 for ; Tue, 25 May 2010 15:29:05 -0700 (PDT) Received: by 10.220.128.205 with SMTP id l13mr5513534vcs.168.1274826545111; Tue, 25 May 2010 15:29:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.61.142 with HTTP; Tue, 25 May 2010 15:28:45 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE275@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE215@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE275@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Tue, 25 May 2010 15:28:45 -0700 Message-ID: Subject: Re: FW: New Version Notification for draft-hammer-hostmeta-10 To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=e0cb4e8878495f262d048772afab X-System-Of-Record: true Cc: "Apps Discuss \(discuss@apps.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: Wed, 26 May 2010 00:28:35 -0000 --e0cb4e8878495f262d048772afab Content-Type: text/plain; charset=ISO-8859-1 This sounds like a quality of implementation issue, which is best brought up with Typepad. Note that if Typepad implements host-meta itself, things will Just Work. If Typepad decides not to implement host-meta, but also gives you no way to add your own /.well-known/host-meta on your own domain... well that's up to them, they're not forced to offer you a choice. Note: It's perfectly possible for specific protocols -- OpenID, say -- to say that in _addition_ to host-meta, you should also check for specific link tags or whatever else is desired. Since this would be for a specific protocol it can spec whether you check these first or last (what priority they should get) fairly easily. But this would be outside of the host-meta spec itself. On Tue, May 25, 2010 at 1:33 PM, Eran Hammer-Lahav wrote: > Sounds like something you should bring up with Typepad. The ability of > users to hack their blogging platform seems like a bad thing to enable. > > > > EHL > > > > > > *From:* bobwyman@gmail.com [mailto:bobwyman@gmail.com] *On Behalf Of *Bob > Wyman > *Sent:* Tuesday, May 25, 2010 1:32 PM > *To:* John Panzer > *Cc:* Eran Hammer-Lahav; Apps Discuss (discuss@apps.ietf.org) > *Subject:* Re: FW: New Version Notification for draft-hammer-hostmeta-10 > > > > John Panzer wrote: > > > resource owners who do not control > > > /.well-known/host-meta are dependent > > > on their hosting provider > > This problem may be more wide-spread than folk may think. I'm rather > miffed, for instance, that since *my* blog in on TypePad and since years > ago I enabled the "multi-blog" support option, there is simply no way that I > can put a .well-known file in a useful location on Typepad... > > > > bob wyman > > > > > > On Tue, May 25, 2010 at 4:25 PM, John Panzer wrote: > > (As you know) like this approach much better, primarily because it reduces > the complexity of implementation down to what we've already coded up for > Webfinger, but allows non-acct: URIs as well. Thus Webfinger is just acct: > + host-meta, done. > > > > Compared to the prior LRDD spec, this doesn't increase the number of > required HTTP requests, actually reduces them in some cases (http URLs that > would also require resolution at the resource level), and probably improves > interop due to simplicity. > > > > NB: The one drawback is that resource owners who do not control > /.well-known/host-meta are dependent on their hosting provider to implement > LRDD links. This drawback is also a security feature, and hosting providers > even with the prior spec were able to block per-resource LRDD if they wanted > to. Note that this does not lock out individuals from implementing this > themselves at all; at worst, they just need to control their own domain name > and be able to copy /.well-known/host-meta to their host. This is a tiny > speedbump, at last glance could be had for ~$30 per person, and I think is > well worth the security and simplicity trade-offs. > > > > On Tue, May 25, 2010 at 12:35 PM, Eran Hammer-Lahav > wrote: > > After recent discussions at IIW about use cases for both host-meta [1] and > LRDD [2], I came to the conclusion that there is little value in the > multi-link-sources approach (collecting links from host-meta, HTTP headers, > and HTML elements). Since the latest LRDD draft requires obtaining host-meta > as the first step anyway, it significantly reduces the value of using links > elsewhere (for this purpose). > > The new host-meta draft incorporates the host-meta parts of LRDD, including > the registration of the 'lrdd' relation type. My intention is to abandon the > LRDD proposal and focus only on host-meta. Those using only host-meta are > unaffected by this change. > > Feedback on the latest host-meta draft is requested. > > EHL > > [1] http://tools.ietf.org/html/draft-hammer-hostmeta > [2] http://tools.ietf.org/html/draft-hammer-discovery > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, May 25, 2010 12:25 PM > To: Eran Hammer-Lahav > Subject: New Version Notification for draft-hammer-hostmeta-10 > > > A new version of I-D, draft-hammer-hostmeta-10.txt has been successfully > submitted by Eran Hammer-Lahav and posted to the IETF repository. > > Filename: draft-hammer-hostmeta > Revision: 10 > Title: Web Host Metadata > Creation_date: 2010-05-25 > WG ID: Independent Submission > Number_of_pages: 15 > > Abstract: > This memo describes a method for locating host metadata as well as > information about individual resources controlled by the host. > > > > The IETF Secretariat. > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > --e0cb4e8878495f262d048772afab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This sounds like a quality of implementation issue, which is best brought u= p with Typepad.

Note that if Typepad implements host-met= a itself, things will Just Work. =A0If Typepad decides not to implement hos= t-meta, but also gives you no way to add your own /.well-known/host-meta on= your own domain... well that's up to them, they're not forced to o= ffer you a choice.

Note: It's perfectly possible for specific protocol= s -- OpenID, say -- to say that in _addition_ to host-meta, you should also= check for specific link tags or whatever else is desired. =A0Since this wo= uld be for a specific protocol it can spec whether you check these first or= last (what priority they should get) fairly easily. =A0But this would be o= utside of the host-meta spec itself.

On Tue, May 25, 2010 at 1:33 PM, Eran H= ammer-Lahav <er= an@hueniverse.com> wrote:

Sounds like something yo= u should bring up with Typepad. The ability of users to hack their blogging= platform seems like a bad thing to enable.

=A0

EHL

=A0

=A0

From:= bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Tuesday, May 25, 2010 1:32 PM
To: John Panzer
= Cc: Eran Hammer-Lahav; Apps Discuss (discuss@apps.ietf.org)
Subject: Re: = FW: New Version Notification for draft-hammer-hostmeta-10

=A0

John Panzer=A0<jpanzer@google.com>=A0wrote:

>=A0resource owners who do not control=A0

> /.well-known/host-meta are dependent

> on their hosting provider=A0

This problem may be more wide-spread than folk may t= hink. I'm rather miffed, for instance, that since my blog in on = TypePad and since years ago I enabled the "multi-blog" support op= tion, there is simply no way that I can put a .well-known file in a useful = location on Typepad...

=A0

= bob wyman

=A0

=A0

On Tue, May 25, 2010 at 4= :25 PM, John Panzer <jpanzer@google.com> wrote:

(As you know) like this approach much better, primar= ily because it reduces the complexity of implementation down to what we'= ;ve already coded up for Webfinger, but allows non-acct: URIs as well. =A0T= hus Webfinger is just acct: + host-meta, done.

=A0

Compar= ed to the prior LRDD spec, this doesn't increase the number of required= HTTP requests, actually reduces them in some cases (http URLs that would a= lso require resolution at the resource level), and probably improves intero= p due to simplicity.

=A0

= NB: The one drawback is that resource owners who do not control /.well-know= n/host-meta are dependent on their hosting provider to implement LRDD links= . =A0This drawback is also a security feature, and hosting providers even w= ith the prior spec were able to block per-resource LRDD if they wanted to. = =A0Note that this does not lock out individuals from implementing this them= selves at all; at worst, they just need to control their own domain name an= d be able to copy /.well-known/host-meta to their host. =A0This is a tiny s= peedbump, at last glance could be had for ~$30 per person, and I think is w= ell worth the security and simplicity trade-offs.

= =A0

On Tue, May 25, 2010 at 12:35 PM, Eran H= ammer-Lahav <er= an@hueniverse.com> wrote:

After recent discussions at IIW about use cases for = both host-meta [1] and LRDD [2], I came to the conclusion that there is lit= tle value in the multi-link-sources approach (collecting links from host-me= ta, HTTP headers, and HTML elements). Since the latest LRDD draft requires = obtaining host-meta as the first step anyway, it significantly reduces the = value of using links elsewhere (for this purpose).

The new host-meta draft incorporates the host-meta parts of LRDD, inclu= ding the registration of the 'lrdd' relation type. My intention is = to abandon the LRDD proposal and focus only on host-meta. Those using only = host-meta are unaffected by this change.

Feedback on the latest host-meta draft is requested.

EHL

= [1] http://tools.ietf.org/html/draft-hammer-hostmeta
[2] ht= tp://tools.ietf.org/html/draft-hammer-discovery


-----Original Message-----
From: IETF I-D Submission Tool [mailt= o:idsubmission@i= etf.org]
Sent: Tuesday, May 25, 2010 12:25 PM
To: Eran Hammer-Lah= av
Subject: New Version Notification for draft-hammer-hostmeta-10


A= new version of I-D, draft-hammer-hostmeta-10.txt has been successfully sub= mitted by Eran Hammer-Lahav and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-hammer-hostmeta
Revision: =A0 =A0 =A0 =A010
Title: =A0 =A0 =A0 =A0 =A0 Web Host Metadata=
Creation_date: =A0 2010-05-25
WG ID: =A0 =A0 =A0 =A0 =A0 Independent= Submission
Number_of_pages: 15

Abstract:
This memo describes = a method for locating host metadata as well as information about individual= resources controlled by the host.



The IETF Secretariat.


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

=A0


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

=A0

<= /div>
--e0cb4e8878495f262d048772afab-- From sm@elandsys.com Thu May 27 11:42:18 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 BC6CD3A684A; Thu, 27 May 2010 11:42:18 -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 5oCn7BmN8KPG; Thu, 27 May 2010 11:42:16 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id B88113A68CF; Thu, 27 May 2010 11:42:16 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.214]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id o4RIfpsB016123; Thu, 27 May 2010 11:42:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1274985726; bh=eLylx4exO6ujkNMdOu8Mwk+sY0k=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type: Content-Transfer-Encoding; b=pQPrFKSWomSK9bSfBGHMtMc91K18vTrJxzcIMuNweXHzc6fhygDqdnRl4AKfQKamM MEnN05E9q1c5sY69mog8PQ75+YulQ+AOCBM2GTNvoAjv0XyF1PihFo2w5yeQiJAf5F dL7+SkU071S69GdTNop+DS7YXmBGKc8e3Pg/OZb0= Message-Id: <6.2.5.6.2.20100527105111.0989c290@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 27 May 2010 11:39:56 -0700 To: apps-discuss@ietf.org From: S Moonesamy Subject: Applications Area Review Team Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable 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, 27 May 2010 18:42:18 -0000 Hello, There is an Applications Area Review Team that=20 assists the two Application Area Directors by=20 providing semi-formal reviews of Internet-Drafts=20 as a way to improve the quality of IETF=20 specifications. The team receives requests for=20 reviews from the Application Area Directors. The author of an Internet-Draft may also request=20 a review by contacting the Applications Area=20 Review Team Lead. It is advisable to have a=20 discussion of the proposal on an IETF mailing=20 list before making such a request. The members of the team are selected from the=20 IETF community and have expertise in areas such=20 as Messaging, Publishing, Internationalization,=20 Calendaring, Security, Social Networking,=20 Collaboration, Web architecture and web services,=20 Schemas, Directories, etc. The current members are: Claudio Allocchio Mark Baker Joshua Bell Marc Blanchet Eric Burger Dave Cridland Dave Crocker Martin D=FCrst Lisa Dusseault Vijay Gurbani Eran Hammer-Lahav Ted Hardie Joe Hildebrand John Klensin Murray S. Kucherawy Scott Lawrence Xiaodong Lee Eliot Lear Alexey Melnikov Enrico Marocco Mark Nottingham Glenn Parsons Julian Reschke Thomas Roessler Peter Saint-Andre Aaron Stone Henry S. Thompson Kurt Zeilenga You can find more information about the=20 Applications Area Review Team at=20 http://www.apps.ietf.org/content/applications-area-review-team Regards, S. Moonesamy On behalf of the Applications Area Review Team From A.Hoenes@TR-Sys.de Mon May 31 02:20:52 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 245103A69FE; Mon, 31 May 2010 02:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.149 X-Spam-Level: X-Spam-Status: No, score=-96.149 tagged_above=-999 required=5 tests=[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 b-6cdr36zdTa; Mon, 31 May 2010 02:20:51 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 8BE683A69EC; Mon, 31 May 2010 02:20:49 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA165417587; Mon, 31 May 2010 11:19:47 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA03229; Mon, 31 May 2010 11:19:45 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201005310919.LAA03229@TR-Sys.de> Subject: New Version Notification for draft-ah-rfc2141bis-urn-02 (fwd) To: urn@ietf.org, apps-discuss@ietf.org Date: Mon, 31 May 2010 11:19:45 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 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: Mon, 31 May 2010 09:20:52 -0000 Folks, the main reason for this update was adjusting the pointer for discussion: the draft now points to the uri AT ietf.org list. At this opportunity, a couple of clarifying remarks have been added, based on items appearing in the discussion on the draft charter of the proposed URNbis WG and the BoF proposal. There are no technical changes since -00, but numerous editorial improvements have been performed and the missing summary delta information from RFC 2141 is now supplied in Appendix D. Please note that -01 was erroneously submitted with a significant typo; please ignore it. The diff information from draft version -00 to -02 is available at: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ah-rfc2141bis-urn-00.txt&url2=draft-ah-rfc2141bis-urn-02.txt Kind regards, Alfred. ----- Forwarded message from IETF I-D Submission Tool ----- > From: IETF I-D Submission Tool > To: ah@.TR-Sys.de > Message-Id: <20100531090206.632E73A6A17@core3.amsl.com> > Date: Mon, 31 May 2010 02:02:06 -0700 (PDT) > Subject: New Version Notification for draft-ah-rfc2141bis-urn-02 > > A new version of I-D, draft-ah-rfc2141bis-urn-02.txt > has been successfully submitted by Alfred Hoenes and posted > to the IETF repository. > > Filename: draft-ah-rfc2141bis-urn > Revision: 02 > Title: Uniform Resource Name (URN) Syntax > Creation_date: 2010-05-31 > WG ID: Independent Submission > Number_of_pages: 21 > > Abstract: > > Uniform Resource Names (URNs) are intended to serve as persistent, > location-independent, resource identifiers. This document serves as > the foundation of the 'urn' URI Scheme according to RFC 3986 and sets > forward the canonical syntax for URNs, which subdivides URNs into > "namespaces". A discussion of both existing legacy and new > namespaces and requirements for URN presentation and transmission are > presented. Finally, there is a discussion of URN equivalence and how > to determine it. This document supersedes RFC 2141. > > The requirements and procedures for URN Namespace registration > documents are currently set forth in RFC 3406, which is also expected > to be updated by an independent, revised specification. > > Discussion > > This draft version has been obtained by importing the text from RFC > 2141 into modern tools and making a first round of updating steps. > It is intended to serve as one of the starting points for an effort > to bring URN RFCs in alignment with STD 63, STD 68, BCP 26, and the > requirements from emerging distributed national and international URN > resolution systems, and advance them on the IETF Standards Track. > > Comments are welcome on the uri@ietf.org mailing list (or sent to the > document editor). > > > > The IETF Secretariat. > ----- End of forwarded message from IETF I-D Submission Tool ----- From A.Hoenes@TR-Sys.de Mon May 31 10:06:07 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 4A1643A67FF; Mon, 31 May 2010 10:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.149 X-Spam-Level: X-Spam-Status: No, score=-96.149 tagged_above=-999 required=5 tests=[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 8I42ag7u8lue; Mon, 31 May 2010 10:06:06 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 4AE943A67A1; Mon, 31 May 2010 10:06:04 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA167135499; Mon, 31 May 2010 19:05:00 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA05428; Mon, 31 May 2010 19:04:58 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201005311704.TAA05428@TR-Sys.de> Subject: Re: New Version Notification for draft-ah-rfc2141bis-urn-02 (fwd) To: urn@ietf.org, apps-discuss@ietf.org Date: Mon, 31 May 2010 19:04:57 +0200 (MESZ) References: <201005310919.LAA03229@TR-Sys.de> X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 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: Mon, 31 May 2010 17:06:07 -0000 Correction: Of course, the final quotation in the announcement sent out earlier today should say (as corrected in the -02 draft version): vvvvvvvvvvvv | Comments are welcome on the urn@ietf.org mailing list (or sent to the | document editor). My apologies for possible confusion. Kind regards, Alfred.