From lars.eggert@nokia.com Thu Jul 1 01:43:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4007C3A67C3; Thu, 1 Jul 2010 01:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSzMhrzmONEc; Thu, 1 Jul 2010 01:43:01 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A3FC03A67BD; Thu, 1 Jul 2010 01:43:00 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o618gquO019847; Thu, 1 Jul 2010 11:43:09 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 11:43:08 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 11:43:08 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o618h7Jp022030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jul 2010 11:43:07 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-4--981131304; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <201006301801.UAA26017@TR-Sys.de> Date: Thu, 1 Jul 2010 09:42:59 +0100 Message-Id: <398CC265-20E3-4E97-8A36-E8CED3B6E0B8@nokia.com> References: <201006301801.UAA26017@TR-Sys.de> To: ah@tr-sys.de X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Thu, 01 Jul 2010 11:43:00 +0300 (EEST) X-OriginalArrivalTime: 01 Jul 2010 08:43:08.0240 (UTC) FILETIME=[6E0C1500:01CB18F9] X-Nokia-AV: Clean Cc: namedroppers@ops.ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG, tsvwg@ietf.org, apps-discuss@ietf.org, Joe Touch Subject: Re: [apps-discuss] [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 08:43:02 -0000 --Apple-Mail-4--981131304 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-6-30, at 19:01, ah@tr-sys.de wrote: > Please do not neglect the criticism spelled out repeatedly for > draft-ietf-tsvwg-iana-ports but rejected by your team. This > draft tries to accommodate the restrictions imposed by that memo. > Yet, to be useful for aligning previous RFCs now deemed non- > conformant with these rules and recent/ongoing work specifically > calling for multi-label hierarchical Service Prefixes, this > draft needs to show a uniform path that can be recommended > to the authors / WGs where these RFCs are originating from. >=20 > Thus, as a replacement mechanism for specifications using > Service Prefixes with non-transport protocol Protocol Labels > and/or more than two labels, the non-normative extension > mechanism proposed is an essential part of this memo. >=20 > Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports > on the lenght of Service Names and the one-servie-name-per- > application rule are being relaxed substantially, this extension > mechanism will remain in this document. OK, I'm confused. We had a lunch meeting in Anaheim where Olafur was = present, and we went down the list of planned changes to iana-ports to = explicitly make sure the two documents are aligned. If they now are not aligned, there are basically two possibilities: = Either we we messed things up when updating iana-ports, but I at least = don't know where we did. Or draft-gudmundsson changed or is planned to = change in ways that are different than what we agreed on. Can we pencil in a time for a Webex call in order to make progress here? Lars PS: Let's please try to take the heat out of this discussion. It's = unhelpful.= --Apple-Mail-4--981131304 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcwMTA4 NDI1OVowIwYJKoZIhvcNAQkEMRYEFBaGI6qTPFuPIqkElNDZm8CgKWx8MIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAC8Q438JYZKqHpomGFQ5F3yrBKliGyft6KlntH/SJ/hn87aPSCYS mXe6OPgT8RCv2EER/6T20usyKS4jhk5GIhw2MOL4DMOIhH9Cbo179BHtNTXFiX82n9LD5PcQ5DFi kcDhi/2Sd1QN+bBUuj8kRlu5KBZqiEBcGkYe1YILf0a0oA5urqmePbgKEYMd0GDl+HDXLfXmBLW/ aOZPitLVSYTXkaGUQloh05hRygyfKyS9HPvoUBAdn9jBOqqpxnaqrUhrdC8tZmohnMWCtmq6tg13 FSHv8exGSy8TH26jEJ3rQ2hpSj5/xvPdf0GH5bpLDh2mIX0BuTgZ2MR0M5KpOswAAAAAAAA= --Apple-Mail-4--981131304-- From fweimer@bfk.de Thu Jul 1 00:22:48 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 5511E3A6800; Thu, 1 Jul 2010 00:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.823 X-Spam-Level: X-Spam-Status: No, score=0.823 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_40=-0.185, HELO_EQ_DE=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 w5EGzgkOFIrj; Thu, 1 Jul 2010 00:22:47 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 321953A67A5; Thu, 1 Jul 2010 00:22:45 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OUE6l-00038h-IP; Thu, 01 Jul 2010 07:22:51 +0000 Received: by bfk.de with local id 1OUE6h-0006QG-1C; Thu, 01 Jul 2010 07:22:47 +0000 To: Alfred =?us-ascii?Q?=3D=3Fhp-roman8=3FB=3FSM5uZXM=3D=3F=3D?= References: <201006301816.UAA26126@TR-Sys.de> From: Florian Weimer Date: Thu, 01 Jul 2010 07:22:46 +0000 In-Reply-To: <201006301816.UAA26126@TR-Sys.de> (Alfred's message of "Wed\, 30 Jun 2010 20\:16\:20 +0200 \(MESZ\)") Message-ID: <82fx031xa1.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Jul 2010 08:11:45 -0700 Cc: namedroppers@ops.ietf.org, dnsop@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [dnsext] New Version Notification - draft-gudmundsson-dnsext-srv-clarify-01.txt (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 07:22:48 -0000 * Alfred: > My apologies for cross-posting, > but this is inherently a cross-wg and cross-area topic: > > The revised draft contains clarifications for DNS service discovery > using SRV RRs and suggests methods to deal with the restrictions > imposed by draft-ietf-tsvwg-iana-ports. It is intended that both > drafts will eventually be published in a coordinated manner. > > > Abstract > > The DNS SRV record has been specified in RFC 2052 and RFC 2782 for > use in dynamic service discovery for a domain. These two RFCs did > not clearly specify an IANA registry for the names of the services > and their underlying protocols. This document clarifies RFC 2782 > regarding the formation and use of the Service Prefix in the owner > name of SRV records, based on the unified IANA registry for "Service > Names and Transport Protocol Port Numbers". Wouldn't it be better to put that effort into a SRV successor which focuses on cryptographic binding and the introduction of (generic, cross-application) transports above TCP/UDP? Right now, we've got many protocols which can run over HTTP(S) and home-grown pseudo-transport layers, and with SRV records, it is not possible to figure out if HTTP is to be used or not. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From stpeter@stpeter.im Thu Jul 1 09:17: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 C891D3A684D for ; Thu, 1 Jul 2010 09:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 XnD+uwG1bLBh for ; Thu, 1 Jul 2010 09:17:34 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AD67C3A6838 for ; Thu, 1 Jul 2010 09:17:34 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E74E040E57 for ; Thu, 1 Jul 2010 10:17:45 -0600 (MDT) Message-ID: <4C2CBFA8.10001@stpeter.im> Date: Thu, 01 Jul 2010 10:17:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020303050602000305030709" Subject: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 01 Jul 2010 16:17:36 -0000 This is a cryptographically signed message in MIME format. --------------ms020303050602000305030709 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI. -------- Original Message -------- Subject: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard Date: Fri, 25 Jun 2010 05:30:41 -0700 (PDT) From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Web Host Metadata ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-07-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hammer-hostmeta-13.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D19329&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------ms020303050602000305030709 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 hvcNAQkFMQ8XDTEwMDcwMTE2MTc0NFowIwYJKoZIhvcNAQkEMRYEFGUbjv6QKrFDLkkP0TIz eqzbKsJIMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAgTsZnvxdBvy/RFKJlfTpTLvk+QtDDb4FlGZM837Q BS2E129ijjyOLqBsOOZH20z1T/uF4/ytATCGlnSQgxFgmQm0jDnUliVZHMHFbdbXX9ICryoK zl13+AU/1S3ySDhfJ+uMTaayCHb1q4xHWI7TWTz+otrcU+GQ6AOt8Sco0E/u+FxQNwSXJO5S dk/41BlnJTW7/GzDwOr6Qc+LjKA4/lPOd11l/snyOhoj7z35Em3pKw4S8T+nS8PuPffandsz 8BP+tyXHuiTMkgwYe9eF/Tamw5nXIzJzFEDieolAkila/55vf6fz1VzggdxCt8wvs13xP6Mc BOfU3+v5l6wkjwAAAAAAAA== --------------ms020303050602000305030709-- From stpeter@stpeter.im Thu Jul 1 09:52: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 66A8A3A684D; Thu, 1 Jul 2010 09:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 dfmQsJ0QinTi; Thu, 1 Jul 2010 09:52:11 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 51C553A6781; Thu, 1 Jul 2010 09:52:10 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E380240E4D; Thu, 1 Jul 2010 10:52:20 -0600 (MDT) Message-ID: <4C2CC7C3.2020005@stpeter.im> Date: Thu, 01 Jul 2010 10:52: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: Joe Touch References: <201006302006.WAA26281@TR-Sys.de> <4C2BBEA8.6070904@isi.edu> In-Reply-To: <4C2BBEA8.6070904@isi.edu> 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="------------ms080709030704090406070500" Cc: Ben Campbell , =?UTF-8?B?QWxmcmVkIO+/vQ==?= , tsvwg@ietf.org, apps-discuss@ietf.org, namedroppers@ops.ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: Re: [apps-discuss] [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 16:52:12 -0000 This is a cryptographically signed message in MIME format. --------------ms080709030704090406070500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A point of clarification... On 6/30/10 4:01 PM, Joe Touch wrote: > "xmpp" is does not have an Assigned Number, and is not being used 'loca= lly', and > was never registered with the SRV registry either. Yes, there appear to= be a few > other uses of SRV records other than for the kind of services indicated= in the > IANA ports tale or the SRV registry. XMPP does have two registered ports (5222 and 5269) but the XMPP WG has been waiting for the service registry issue to be settled before adding the appropriate service name registration to the IANA considerations for draft-ietf-xmpp-3920bis, which is currently in WGLC. See for instance: http://www.ietf.org/mail-archive/web/xmpp/current/msg00313.html Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080709030704090406070500 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 hvcNAQkFMQ8XDTEwMDcwMTE2NTIxOVowIwYJKoZIhvcNAQkEMRYEFE1q/DA4e9063Jk9APkN SHoAb4WtMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEABiCK1fudhWidylyT75z+F+Ax04RVujEcKuItrn06 ZoUqNB2Y36PRWlaPvUkepebamak65TPbzHiERrFq1MdL/y+KbwGxpB92qd/plDlzdSf+sA81 nIfmJhQRdCMnOqoZ0ECwjU8uF2rCkRfXkGgb6qVkVTOIkrWlb5IXPFhJAmIY5M3G2Iun+Yw/ b/y5eoW+0WfpMV2VWQ7Z2AcJ8Rf3ZFNsCQNLb3nl2qN7ZnUf58llGXyf8Kp1lGU48Cas1QWI Nah2LhYmr37FZlRgHsBP89jCVzk9RBp6g9aEksNkqUFWY5nBug9WefoZE8XUZRPVPpVB+LLr fhPwe6MtPAWLnwAAAAAAAA== --------------ms080709030704090406070500-- From touch@isi.edu Thu Jul 1 10:02: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 87ECC3A6895; Thu, 1 Jul 2010 10:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGd7x5DCM98N; Thu, 1 Jul 2010 10:02:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id AA9353A6850; Thu, 1 Jul 2010 10:02:55 -0700 (PDT) Received: from [75.214.235.123] (123.sub-75-214-235.myvzw.com [75.214.235.123]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o61H1gf8014934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jul 2010 10:01:53 -0700 (PDT) Message-ID: <4C2CC9F6.8010503@isi.edu> Date: Thu, 01 Jul 2010 10:01:42 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <201006302006.WAA26281@TR-Sys.de> <4C2BBEA8.6070904@isi.edu> <4C2CC7C3.2020005@stpeter.im> In-Reply-To: <4C2CC7C3.2020005@stpeter.im> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3E0482C82727BB735E186D13" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ben Campbell , =?UTF-8?B?QWxmcmVkIO+/vQ==?= , tsvwg@ietf.org, apps-discuss@ietf.org, namedroppers@ops.ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: Re: [apps-discuss] [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:02:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3E0482C82727BB735E186D13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter Saint-Andre wrote: > A point of clarification... >=20 > On 6/30/10 4:01 PM, Joe Touch wrote: >=20 >> "xmpp" is does not have an Assigned Number, and is not being used 'loc= ally', and >> was never registered with the SRV registry either. Yes, there appear t= o be a few >> other uses of SRV records other than for the kind of services indicate= d in the >> IANA ports tale or the SRV registry. >=20 > XMPP does have two registered ports (5222 and 5269) Agreed - neither is listed as "xmpp", though. "xmpp-client" and "xmpp-server" are both listed in IANA ports and in the = DNS SRV registry, though. The point above is about using "xmpp" as the service string. > but the XMPP WG has > been waiting for the service registry issue to be settled before adding= > the appropriate service name registration to the IANA considerations fo= r > draft-ietf-xmpp-3920bis, which is currently in WGLC. >=20 > See for instance: >=20 > http://www.ietf.org/mail-archive/web/xmpp/current/msg00313.html >=20 > Peter >=20 --------------enig3E0482C82727BB735E186D13 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) iEYEARECAAYFAkwsyfYACgkQE5f5cImnZrtk2QCgg3TyZZ8s1zK6OjOIahWoJ8Av a7YAnisG/9PmEkiUN2niddiP1gcvYi2J =V0cA -----END PGP SIGNATURE----- --------------enig3E0482C82727BB735E186D13-- From stpeter@stpeter.im Thu Jul 1 10:25:50 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 B3D7C3A684A; Thu, 1 Jul 2010 10:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 i4OQoj-ZBW-N; Thu, 1 Jul 2010 10:25:49 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CC0F53A659A; Thu, 1 Jul 2010 10:25:49 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6097140E26; Thu, 1 Jul 2010 11:26:00 -0600 (MDT) Message-ID: <4C2CCFA7.7030000@stpeter.im> Date: Thu, 01 Jul 2010 11:25:59 -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: Joe Touch References: <201006302006.WAA26281@TR-Sys.de> <4C2BBEA8.6070904@isi.edu> <4C2CC7C3.2020005@stpeter.im> <4C2CC9F6.8010503@isi.edu> In-Reply-To: <4C2CC9F6.8010503@isi.edu> 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="------------ms030309030007060700090606" Cc: Ben Campbell , =?UTF-8?B?QWxmcmVkIO+/vQ==?= , tsvwg@ietf.org, apps-discuss@ietf.org, namedroppers@ops.ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: Re: [apps-discuss] [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:25:50 -0000 This is a cryptographically signed message in MIME format. --------------ms030309030007060700090606 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/1/10 11:01 AM, Joe Touch wrote: >=20 > Peter Saint-Andre wrote: >> A point of clarification... >> >> On 6/30/10 4:01 PM, Joe Touch wrote: >> >>> "xmpp" is does not have an Assigned Number, and is not being used 'lo= cally', and Could you clarify what it means to use something "locally"? >>> was never registered with the SRV registry either. Yes, there appear = to be a few >>> other uses of SRV records other than for the kind of services indicat= ed in the >>> IANA ports tale or the SRV registry. >> >> XMPP does have two registered ports (5222 and 5269) >=20 > Agreed - neither is listed as "xmpp", though. Correct. > "xmpp-client" and "xmpp-server" are both listed in IANA ports and in th= e DNS SRV > registry, though. >=20 > The point above is about using "xmpp" as the service string. Is this a reference to the IM and presence SRV label registries called for by RFC 3861? http://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml http://www.iana.org/assignments/pres-srv-labels/pres-srv-labels.xhtml Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030309030007060700090606 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 hvcNAQkFMQ8XDTEwMDcwMTE3MjU1OVowIwYJKoZIhvcNAQkEMRYEFFNOa08i58qGuBF6JGex G95DSMgyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEASHjMfGMHSrYP+wKChpaz7P1b1tfRKLw/VZ54ggeM MOM7IhFKXYr8OWImFjyNCFTVsRYuQ1WYvrcfP/NWym8GbHP9PSsjb9IdN61Qyja5FT6Bczpg wOpaOStwrpoWn+jCuGrde9HKnKr9MZFr8bZCxSqBvK6Wmqs+j3+61m4cFio+ElvVfSqskeX7 Mz7Dduw6PnjW1bTV2+aXcpRnfsQ+P+CNb1TUhAvwhl/xQEIlGk2OuBT+xpyPKkzprrobuz8g RuDqm5aPkEhw8YzGyZ4qFYhEhqc8qRXQ6qzHm9fAduGlbcm00wmOZ4QwS6ErWWY7WaSQJef/ RaXpJYAY3/8ywwAAAAAAAA== --------------ms030309030007060700090606-- From stpeter@stpeter.im Thu Jul 1 10:42: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 6245B3A68B6 for ; Thu, 1 Jul 2010 10:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 Wpu6jdcN8ZcL for ; Thu, 1 Jul 2010 10:42:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BB9183A67A3 for ; Thu, 1 Jul 2010 10:42:25 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E657C40E5A for ; Thu, 1 Jul 2010 11:42:36 -0600 (MDT) Message-ID: <4C2CD38B.8010005@stpeter.im> Date: Thu, 01 Jul 2010 11:42:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080903040203040008030004" Subject: [apps-discuss] proposals for AppsArea session in Maastricht 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, 01 Jul 2010 17:42:27 -0000 This is a cryptographically signed message in MIME format. --------------ms080903040203040008030004 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, if you are interested in presenting about an I-D or other topic during the AppsArea general session at IETF 78, please post to this list or contact Alexey and me off-list. Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080903040203040008030004 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 hvcNAQkFMQ8XDTEwMDcwMTE3NDIzNVowIwYJKoZIhvcNAQkEMRYEFLaMF6uhIL5ZVnY5xD1i 2LSUYSS1MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEABxM+7Mlo68y3ubRT6YUWuVpg5uKAc9++htkgCiBc yvKLAkYMecJ7vdhUTFPUf6JVd5ktloBFstpGgoEfd3oHyyiW/AhXJlBKBnI03u+eFxIltcjc 4ZeFRjvWTzRpzcxjp6Rp9RUiupqg1vbKU6CUoo7TS1OKHHs7C5e784cYWwT7rq6tVIIZwmbJ PTaKwVTQhGJ8+NonZqnY4Nqqab/CLEtjNnwZZn7VkFUUaoDu2hPk/KmP9LKNOixwHsr447l4 DVy9+NoPaNLuSffPdbDyWa6Hz3jerjsjtti165YMo6kaUE+VOkgmexRi36COkcV511CkPj0+ rSY08iqw+hRk8AAAAAAAAA== --------------ms080903040203040008030004-- From touch@isi.edu Thu Jul 1 11:12:57 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958C13A67B6; Thu, 1 Jul 2010 11:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 DDP1hKWcadDi; Thu, 1 Jul 2010 11:12:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D7BF73A6988; Thu, 1 Jul 2010 11:12:54 -0700 (PDT) Received: from [75.215.102.184] (184.sub-75-215-102.myvzw.com [75.215.102.184]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o61ICHZr004009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jul 2010 11:12:28 -0700 (PDT) Message-ID: <4C2CDA80.50109@isi.edu> Date: Thu, 01 Jul 2010 11:12:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <201006302006.WAA26281@TR-Sys.de> <4C2BBEA8.6070904@isi.edu> <4C2CC7C3.2020005@stpeter.im> <4C2CC9F6.8010503@isi.edu> <4C2CCFA7.7030000@stpeter.im> In-Reply-To: <4C2CCFA7.7030000@stpeter.im> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBB6CAE19B4FCCC9113CEC694" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ben Campbell , =?UTF-8?B?QWxmcmVkIO+/vQ==?= , tsvwg@ietf.org, apps-discuss@ietf.org, namedroppers@ops.ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: Re: [apps-discuss] [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:12:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBB6CAE19B4FCCC9113CEC694 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter Saint-Andre wrote: > On 7/1/10 11:01 AM, Joe Touch wrote: >> Peter Saint-Andre wrote: >>> A point of clarification... >>> >>> On 6/30/10 4:01 PM, Joe Touch wrote: >>> >>>> "xmpp" is does not have an Assigned Number, and is not being used 'l= ocally', and >=20 > Could you clarify what it means to use something "locally"? That's the text RFC 2782; I presume it means "has meaning at the two endp= oints, rather than in an IANA registry". >>>> was never registered with the SRV registry either. Yes, there appear= to be a few >>>> other uses of SRV records other than for the kind of services indica= ted in the >>>> IANA ports tale or the SRV registry. >>> XMPP does have two registered ports (5222 and 5269) >> >> Agreed - neither is listed as "xmpp", though. >=20 > Correct. >=20 >> "xmpp-client" and "xmpp-server" are both listed in IANA ports and in t= he DNS SRV >> registry, though. >> >> The point above is about using "xmpp" as the service string. >=20 > Is this a reference to the IM and presence SRV label registries called > for by RFC 3861? Yes. Those seem like they would need to be in the SRV registry, not a sep= arate registry, AFAICT. The problem is that RFC3861 is using these labels in a = way that seems a bit inconsistent with what is expected from RFC2782: _im._bip.example.com I.e., 2872 seems like it would expect, e.g., adding _im or _pres in front= of _bip in front of a transport protocol string: _im._bip._tcp.example.com (or for _udp) =09 _pres._bip._tcp.example.com (or for _udp) RFC3861 omits the transport protocol in that string. The example in RFC 3920 is consistent with RFC2782, IMO: _xmpp-client._tcp.example.com As is RFC 3263: _sip._tcp.example.com Joe > http://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml >=20 > http://www.iana.org/assignments/pres-srv-labels/pres-srv-labels.xhtml >=20 > Peter >=20 --------------enigBB6CAE19B4FCCC9113CEC694 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) iEYEARECAAYFAkws2oAACgkQE5f5cImnZrvW4wCg0Y0VWfulyqk5N86J7GYnNI2N 8AQAoMrnvSO2ldCyFT2OKrOcYMQbrGeJ =dnKa -----END PGP SIGNATURE----- --------------enigBB6CAE19B4FCCC9113CEC694-- From touch@isi.edu Thu Jul 1 11:18: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 447103A67F9; Thu, 1 Jul 2010 11:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 9MpmbcJiICgj; Thu, 1 Jul 2010 11:18:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 22DC23A67B6; Thu, 1 Jul 2010 11:18:56 -0700 (PDT) Received: from [75.215.102.184] (184.sub-75-215-102.myvzw.com [75.215.102.184]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o61ICHZr004009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jul 2010 11:12:28 -0700 (PDT) Message-ID: <4C2CDA80.50109@isi.edu> Date: Thu, 01 Jul 2010 11:12:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <201006302006.WAA26281@TR-Sys.de> <4C2BBEA8.6070904@isi.edu> <4C2CC7C3.2020005@stpeter.im> <4C2CC9F6.8010503@isi.edu> <4C2CCFA7.7030000@stpeter.im> In-Reply-To: <4C2CCFA7.7030000@stpeter.im> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBB6CAE19B4FCCC9113CEC694" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ben Campbell , =?UTF-8?B?QWxmcmVkIO+/vQ==?= , tsvwg@ietf.org, apps-discuss@ietf.org, namedroppers@ops.ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: Re: [apps-discuss] [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:18:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBB6CAE19B4FCCC9113CEC694 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter Saint-Andre wrote: > On 7/1/10 11:01 AM, Joe Touch wrote: >> Peter Saint-Andre wrote: >>> A point of clarification... >>> >>> On 6/30/10 4:01 PM, Joe Touch wrote: >>> >>>> "xmpp" is does not have an Assigned Number, and is not being used 'l= ocally', and >=20 > Could you clarify what it means to use something "locally"? That's the text RFC 2782; I presume it means "has meaning at the two endp= oints, rather than in an IANA registry". >>>> was never registered with the SRV registry either. Yes, there appear= to be a few >>>> other uses of SRV records other than for the kind of services indica= ted in the >>>> IANA ports tale or the SRV registry. >>> XMPP does have two registered ports (5222 and 5269) >> >> Agreed - neither is listed as "xmpp", though. >=20 > Correct. >=20 >> "xmpp-client" and "xmpp-server" are both listed in IANA ports and in t= he DNS SRV >> registry, though. >> >> The point above is about using "xmpp" as the service string. >=20 > Is this a reference to the IM and presence SRV label registries called > for by RFC 3861? Yes. Those seem like they would need to be in the SRV registry, not a sep= arate registry, AFAICT. The problem is that RFC3861 is using these labels in a = way that seems a bit inconsistent with what is expected from RFC2782: _im._bip.example.com I.e., 2872 seems like it would expect, e.g., adding _im or _pres in front= of _bip in front of a transport protocol string: _im._bip._tcp.example.com (or for _udp) =09 _pres._bip._tcp.example.com (or for _udp) RFC3861 omits the transport protocol in that string. The example in RFC 3920 is consistent with RFC2782, IMO: _xmpp-client._tcp.example.com As is RFC 3263: _sip._tcp.example.com Joe > http://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml >=20 > http://www.iana.org/assignments/pres-srv-labels/pres-srv-labels.xhtml >=20 > Peter >=20 --------------enigBB6CAE19B4FCCC9113CEC694 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) iEYEARECAAYFAkws2oAACgkQE5f5cImnZrvW4wCg0Y0VWfulyqk5N86J7GYnNI2N 8AQAoMrnvSO2ldCyFT2OKrOcYMQbrGeJ =dnKa -----END PGP SIGNATURE----- --------------enigBB6CAE19B4FCCC9113CEC694-- From stpeter@stpeter.im Fri Jul 2 08:36:42 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217AB3A6833 for ; Fri, 2 Jul 2010 08:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-1.306, BAYES_50=0.001, SARE_MILLIONSOF=0.315] 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 6Yibhm9JX3Z4 for ; Fri, 2 Jul 2010 08:36:41 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7B59F3A676A for ; Fri, 2 Jul 2010 08:36:39 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 281E540E5A for ; Fri, 2 Jul 2010 09:36:51 -0600 (MDT) Message-ID: <4C2E0792.2000008@stpeter.im> Date: Fri, 02 Jul 2010 09:36:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060706060600060800040800" Subject: [apps-discuss] FWD: Sending personal files between web applications 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, 02 Jul 2010 15:36:42 -0000 This is a cryptographically signed message in MIME format. --------------ms060706060600060800040800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Forwarding this on behalf of Pablo Salomon, who is having trouble sending to this list... /psa ### I would like your opinion on the following problem: Every day, millions of files are created, edited, stored and shared online through a wide variety of web applications. Those applications usually allows the users to upload files from his personal computer and to download them back but there is no standard way for users to move files from one web application to another without having to download them from one and upload them back to the other. For example, a users receives an email with a photo attachment using his favorite web email application (ie: Gmail), decides to edit it in his favorite online photo editing application (ie: Photoshop.com), then he wants to store the edited picture in his online storage (ie: Skydrive) and orders a printed copy from a photo printing service (ie: Kodak Galler= y). This scenario requires to the user to download and upload the photo file several times which is: * Inefficient: Twice the bandwidth is consumed over the internet for a download and upload vs. a direct server to server transfer between the involved services. * Time consuming: A server to server transfer is much faster than for the user to download and then upload the file. * Not user friendly: A dozen clicks or more are needed for the user to download a file from one service and then switch to the other service and upload it back again while it should be possible to do the same with just a couple of clicks in a direct way. * Sometimes impossible: If the user is in a mobile device or embedded browser in an appliance with limited bandwidth/storage it may not be possible to do so. Once a file is in "the cloud" it should be possible to create a standard for the user to move it between any web applications that complies with it without being forced to download it and upload it again. Best Regards, Pablo Salomon --------------ms060706060600060800040800 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 hvcNAQkFMQ8XDTEwMDcwMjE1MzY1MFowIwYJKoZIhvcNAQkEMRYEFPkQZH8X8SkAwBPOzffV E5I34khjMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAkwJmbbtGQ/15fy9hvRltr0zZWGCpDSP2EGBqC/7q gOMQ7Vzb1RQ+sx/w4dQkaSOzx/znTlY++z9UZYL59n8wqpJUgnNKyNMck5dGYRChWMXMlei4 3PtfB30ly2kWZeQJ3dFCE134jzaKfjOBCWJ7HXp5oQEQ7pS5D9+U8IhPMglZMuJfbrGwWvgV cXXP22jaGQkDA5fYmKjkdFRb6lUqKmzNMtb2eOfbufNcM4f0CLxd3FH4DwnTAt8UHEMWrw0w kg+igJh21hC7nmVEuKtxZPAtzHV3iP48QQ+ZgD/6SoROBrY80iAMwtiOYduj/3KNSG3E6Y+F cQwLZNXUq9yWmQAAAAAAAA== --------------ms060706060600060800040800-- From aaron@serendipity.cx Fri Jul 2 09:42:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6289E3A6910 for ; Fri, 2 Jul 2010 09:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.864 X-Spam-Level: X-Spam-Status: No, score=0.864 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 bQOYmy+b+IUS for ; Fri, 2 Jul 2010 09:42:48 -0700 (PDT) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by core3.amsl.com (Postfix) with ESMTP id 35DAB3A63D3 for ; Fri, 2 Jul 2010 09:42:48 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by slice.serendipity.cx (Postfix) with ESMTPSA id 11CBE110186 for ; Fri, 2 Jul 2010 09:42:55 -0700 (PDT) Received: by vws14 with SMTP id 14so2322083vws.31 for ; Fri, 02 Jul 2010 09:42:54 -0700 (PDT) Received: by 10.220.93.17 with SMTP id t17mr494263vcm.126.1278088974242; Fri, 02 Jul 2010 09:42:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.176.2 with HTTP; Fri, 2 Jul 2010 09:42:34 -0700 (PDT) In-Reply-To: <4C2E0792.2000008@stpeter.im> References: <4C2E0792.2000008@stpeter.im> From: Aaron Stone Date: Fri, 2 Jul 2010 09:42:34 -0700 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FWD: Sending personal files between web applications 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, 02 Jul 2010 16:42:51 -0000 Much of this can be achieved now with OAuth. Site A prepares an image, and presents the user with an url to it. Site B is told about this url, and attempts to fetch it. An OAuth exchange proceeds, wherein the user tells Site A to grant Site B access to the resource. Site B then fetches the resource with its newly granted authorization. There's a lot of hand-waving going on though. A further step is to attach this to HTML 5 drag-and-drop. The user agents may need to assist in some ways to mediate the necessary authorizations between the drag source and drop target sites. I haven't followed HTML 5 DnD to see if they're doing it in such a way as to permit this interaction to take place, rather than the user agents simply downloading the resource and uploading it to the other side. Imagine an icon in a file manager -- the icon itself is downloaded, but the file it represents has not been downloaded. When the drag event takes place, we don't want to upload the icon to the target, we want the url of the resource that the icon represents to be sent to the target, and have it figure out how to get that resource. At the end of the day, I don't see the need for a new protocol. Cheers, Aaron On Fri, Jul 2, 2010 at 8:36 AM, Peter Saint-Andre wrot= e: > Forwarding this on behalf of Pablo Salomon, who is having trouble > sending to this list... > > /psa > > ### > > I would like your opinion on the following problem: > > Every day, millions ofW files are created, edited, stored and shared > online through a wide variety of web applications. Those applications > usually allows the users to upload files from his personal computer and > to download them back but there is no standard way for users to move > files from one web application to another without having to download > them from one and upload them back to the other. > > For example, a users receives an email with a photo attachment using his > favorite web email application (ie: Gmail), decides to edit it in his > favorite online photo editing application (ie: Photoshop.com), then he > wants to store the edited picture in his online storage (ie: Skydrive) > and orders a printed copy from a photo printing service (ie: Kodak Galler= y). > > This scenario requires to the user to download and upload the photo file > several times which is: > > =A0 =A0* Inefficient: Twice the bandwidth is consumed over the internet f= or > a download and upload vs. a direct server to server transfer between the > involved services. > =A0 =A0* Time consuming: A server to server transfer is much faster than > for the user to download and then upload the file. > =A0 =A0* Not user friendly: A dozen clicks or more are needed for the use= r > to download a file from one service and then switch to the other service > and upload it back again while it should be possible to do the same with > just a couple of clicks in a direct way. > =A0 =A0* Sometimes impossible: If the user is in a mobile device or > embedded browser in an appliance with limited bandwidth/storage it may > not be possible to do so. > > Once a file is in "the cloud" it should be possible to create a standard > for the user to move it between any web applications that complies with > it without being forced to download it and upload it again. > > Best Regards, > > =A0 =A0 =A0 =A0 =A0 =A0Pablo Salomon > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From barryleiba.mailing.lists@gmail.com Fri Jul 2 11:34: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 AB12F3A67B6 for ; Fri, 2 Jul 2010 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 w++D4XPcFjYo for ; Fri, 2 Jul 2010 11:34:43 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id ED2F13A6813 for ; Fri, 2 Jul 2010 11:34:42 -0700 (PDT) Received: by pxi20 with SMTP id 20so1779214pxi.31 for ; Fri, 02 Jul 2010 11:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=DucdGUDdsGoLfR8lSCHaGqZd1TuE8wUHFjURp5hAorw=; b=joUFfWJ+W2fM65qv6J4oeWZihD9g6/3i3KcEnU66LcpJjm3aeLlhVBOT877qPZxKaQ 1Q21nFJqSuPpOp7n7iFhHZjv8xUn4a0bN+1ieJTkU0sDApkjnFeLOG7NyK7Nm6sXlZj8 LxL7vWp4+vs0OkXvyFqQu2dp/CvC6Oypk5xLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=UapMGoA72vR4nSuY7zdj3XHI3j3zAIeILE3paj7nwBnmXgz2yVvLwE/hz7H9xi8kyL F/eOXiYN9JehPxPYV9StEbWp2SPJEWbU0aftOXh0SvWQWLBhp+/FqPw+ZsszcXfpfxo1 UQjqmIKEOImA6w4obfaGU/aHCny6CxRZjw4S4= MIME-Version: 1.0 Received: by 10.142.144.16 with SMTP id r16mr1847037wfd.60.1278095673930; Fri, 02 Jul 2010 11:34:33 -0700 (PDT) Received: by 10.42.5.212 with HTTP; Fri, 2 Jul 2010 11:34:33 -0700 (PDT) In-Reply-To: <4C2E0792.2000008@stpeter.im> References: <4C2E0792.2000008@stpeter.im> Date: Fri, 2 Jul 2010 14:34:33 -0400 Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FWD: Sending personal files between web applications X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 18:34:44 -0000 > Once a file is in "the cloud" it should be possible to create a standard > for the user to move it between any web applications that complies with > it without being forced to download it and upload it again. Isn't this part of the problem that DECADE is looking to solve? Barry From stpeter@stpeter.im Fri Jul 2 14:32: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 B86363A68AC for ; Fri, 2 Jul 2010 14:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 IKV1-Io41QTz for ; Fri, 2 Jul 2010 14:32:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B7F3F3A67F5 for ; Fri, 2 Jul 2010 14:32:46 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7FD3D40E26 for ; Fri, 2 Jul 2010 15:32:57 -0600 (MDT) Message-ID: <4C2E5B08.70808@stpeter.im> Date: Fri, 02 Jul 2010 15:32:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090204090803030909040404" Subject: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 21:32:53 -0000 This is a cryptographically signed message in MIME format. --------------ms090204090803030909040404 Content-Type: multipart/mixed; boundary="------------090305040804090606040107" This is a multi-part message in MIME format. --------------090305040804090606040107 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI. Feedback is welcome. -------- Original Message -------- Subject: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt Date: Fri, 2 Jul 2010 14:15:05 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : "X-" Considered Harmful Author(s) : P. Saint-Andre Filename : draft-saintandre-xdash-considered-harmful-00.txt Pages : 5 Date : 2010-07-02 Many application protocols use named parameters to represent data (for example, header fields in Internet mail messages and HTTP requests). Historically, protocol designers and implementers have often differentiated between "official" and "unofficial" parameters by prefixing unofficial parameters with the string "X-". This document argues that on balance the "X-" convention has more costs than benefits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-xdash-considered-har= mful-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------090305040804090606040107 Content-Type: Message/External-body; name="draft-saintandre-xdash-considered-harmful-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-saintandre-xdash-considered-harmful-00.txt" Content-Type: text/plain Content-ID: <2010-07-02141357.I-D@ietf.org> --------------090305040804090606040107 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCg== --------------090305040804090606040107-- --------------ms090204090803030909040404 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 hvcNAQkFMQ8XDTEwMDcwMjIxMzI1NlowIwYJKoZIhvcNAQkEMRYEFAOMciG/ZXYJMBpuGK1V m9kpQBecMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAMtAbpQQlnu1YR8AEqeP7X9aT0DnaOtdjuF9BZRZR LxLB2UMzL3UF+eJRWIwB3oJ5xSJeCWXT28/taTJoBgBpJ+3eiVcF93WHGqnuceqdZ3cXTL1f DfN9SUZBYb1F7JCUJJecI5dzzZzrBNqcazCaQlcp2HwEX9rD+wgkax7HwUU+og9zJPhmvbdF UgfJatpsD9xkc+VOkIZzC5wtpXfT8O6zLLljHAzKDorhUSZeAAH8PmQuhKP2K8Su0KFAt22q IQUdSVTE0HMnVjJeqLYqe+lDQhLG0OLRvuZ5qpmpR6fXUR24ekw1uhGyhhRrlZRnQQHKDxuU h4s3+dWvqMqyWAAAAAAAAA== --------------ms090204090803030909040404-- From paul.hoffman@vpnc.org Fri Jul 2 16:00:21 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 DE0AE3A693F for ; Fri, 2 Jul 2010 16:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.65 X-Spam-Level: X-Spam-Status: No, score=0.65 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 oHhR0wJQIfCD for ; Fri, 2 Jul 2010 16:00:21 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 345163A68D5 for ; Fri, 2 Jul 2010 16:00:21 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o62N0VNY081006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jul 2010 16:00:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C2E5B08.70808@stpeter.im> References: <4C2E5B08.70808@stpeter.im> Date: Fri, 2 Jul 2010 16:00:29 -0700 To: Peter Saint-Andre , "apps-discuss@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 23:00:22 -0000 It feels like you undershot on this one. X- is probably "harmful", except in two case: - Where the namespace size is limited - Where the names have semantic value The first is why we have "RFC required" or "IETF approval" or "expert review" or whatever. I think it is non-controversial. The second is much more challenging. Would you automatically take a registration for a mail header called "Cisco-compatibility-mode" from a known troll? What about "High-priority" if there is already a registered header called "Priority"? This topic was beaten to death well over a decade ago, but the arguments are no different now. --Paul Hoffman, Director --VPN Consortium From john-ietf@jck.com Fri Jul 2 16:27: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 226CF3A68C7 for ; Fri, 2 Jul 2010 16:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.899, 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 SFzJhLyFEcw9 for ; Fri, 2 Jul 2010 16:27:28 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 36ED63A6880 for ; Fri, 2 Jul 2010 16:27:28 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OUpdr-000HxL-Po; Fri, 02 Jul 2010 19:27:31 -0400 Date: Fri, 02 Jul 2010 19:27:30 -0400 From: John C Klensin To: Paul Hoffman , Peter Saint-Andre , apps-discuss@ietf.org Message-ID: <91374EA58876293538BC836D@PST.JCK.COM> In-Reply-To: References: <4C2E5B08.70808@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 23:27:29 -0000 +1 --On Friday, July 02, 2010 16:00 -0700 Paul Hoffman wrote: > It feels like you undershot on this one. X- is probably > "harmful", except in two case: > > - Where the namespace size is limited > - Where the names have semantic value > > The first is why we have "RFC required" or "IETF approval" or > "expert review" or whatever. I think it is non-controversial. > > The second is much more challenging. Would you automatically > take a registration for a mail header called > "Cisco-compatibility-mode" from a known troll? What about > "High-priority" if there is already a registered header called > "Priority"? > > This topic was beaten to death well over a decade ago, but the > arguments are no different now. From dhc@dcrocker.net Fri Jul 2 17:07: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 EFE463A67B4 for ; Fri, 2 Jul 2010 17:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edlBqkunG2EZ for ; Fri, 2 Jul 2010 17:07:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id CC2973A6407 for ; Fri, 2 Jul 2010 17:07:47 -0700 (PDT) Received: from [192.168.1.50] (ppp-68-122-72-44.dsl.pltn13.pacbell.net [68.122.72.44]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o6307sfQ019673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Jul 2010 17:07:59 -0700 Message-ID: <4C2E7F55.3070302@dcrocker.net> Date: Fri, 02 Jul 2010 17:07:49 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4C2E5B08.70808@stpeter.im> In-Reply-To: <4C2E5B08.70808@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 02 Jul 2010 17:08:00 -0700 (PDT) Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 00:07:49 -0000 Peter, We created the X- convention in 1977, for RFC 733, the predecessor to RFC 822. It became popular and entrenched, very quickly. It's premise was to permit private conventions that would not be stepped on by later standards efforts. By 'private', I mean ad hoc and unregistered. Even the lowest-overhead registration process is still significant overhead. So the goal was zero overhead avoidance of private and public name usage. (It did nothing about private vs. private name collision, of course.) It was an entirely reasonable idea, but I've long felt it suffers a fundamental flaw: Private conventions become publicly successful and they cannot then be standardized. The name is fixed on this 'private' string. So I think the problem is a bit different from the one you cite, but related. Both of us are expressing a concern about a cross-over between private and standardized. As for concerns about namespace limitation, X- is used for variable length text names. Namespace limitations aren't an issue. As for a name having 'semantic' value, essentially any string used in this realm has semantic value. I don't see how that's relevant here, either. As you note, names are cheap. Collisions aren't impossible -- there is a human tendency that tends to restrict choices to relatively more common strings that have some semantic appeal. At this point, it's pretty easy to argue that an automated name registry should instead be used. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From randy_presuhn@mindspring.com Fri Jul 2 17:54:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DFBC3A68BD for ; Fri, 2 Jul 2010 17:54:15 -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 WjiRgRQN1X+e for ; Fri, 2 Jul 2010 17:54:14 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 7BE883A68AF for ; Fri, 2 Jul 2010 17:54:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HAvcEd8RiiwBOzBgFtWmGKI/itnJVzT31IjUJkAfxxBPVncpDCrFHn2ZPEq387tY; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.225.101] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OUqzx-0007b1-S6 for apps-discuss@ietf.org; Fri, 02 Jul 2010 20:54:26 -0400 Message-ID: <005001cb1a4a$910f6b40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4C2E5B08.70808@stpeter.im> Date: Fri, 2 Jul 2010 17:56:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc7205327803578f64f94176600226ac9526304de712a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.225.101 Subject: Re: [apps-discuss] Fwd: I-DAction:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 00:54:15 -0000 Hi - > From: "Peter Saint-Andre" > To: > Sent: Friday, July 02, 2010 2:32 PM > Subject: [apps-discuss] Fwd: I-DAction:draft-saintandre-xdash-considered-harmful-00.txt > > FYI. Feedback is welcome. Was this intended to apply to the BCP 47 mechanism of using x- to introduce private-use subtags? FWIW, RFC 5646 says about private use subtags: ... Private use subtags have no meaning outside the private agreement between the parties that intend to use or exchange language tags that employ them. The same subtags MAY be used with a different meaning under a separate private agreement. They SHOULD NOT be used where alternatives exist and SHOULD NOT be used in content or protocols intended for general use. Private use subtags are simply useless for information exchange without prior arrangement. The value and semantic meaning of private use tags and of the subtags used within such a language tag are not defined by this document. (Historical note: the ltru WG seriously considered changing the "SHOULD NOT" into "MUST NOT".) Randy From psalomon@interactiveni.com Fri Jul 2 20:15: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 CD0553A683F for ; Fri, 2 Jul 2010 20:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 oyV2-KrtYrsr for ; Fri, 2 Jul 2010 20:15:37 -0700 (PDT) Received: from server8.imserver.net (server8.imserver.net [66.135.39.98]) by core3.amsl.com (Postfix) with ESMTP id 6705D3A659B for ; Fri, 2 Jul 2010 20:15:37 -0700 (PDT) Received: from psalomonvaio ([186.48.209.231]) by server8.imserver.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 22:15:36 -0500 From: "Pablo Salomon" To: Date: Sat, 3 Jul 2010 00:15:36 -0300 Message-ID: <005b01cb1a5e$03d4b230$0b7e1690$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01CB1A44.DE877A30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsaXgF/HlttR2AORtygTWC7BAYlSQ== Content-Language: en-us X-OriginalArrivalTime: 03 Jul 2010 03:15:37.0081 (UTC) FILETIME=[01DEAE90:01CB1A5E] Subject: Re: [apps-discuss] FWD: Sending personal files between web applications 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, 03 Jul 2010 03:15:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005C_01CB1A44.DE877A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Aaron, Oauth by itself does not allows a website to send a file to any existing or future website that complies with Oauth. Oauth focuses on securely granting my authorization to another website's API but Website A needs to implement the specific Website B's API for uploading a file which can be different from Websites C,D,E, etc. The focus of my proposal is that there should be a common way (or API) for such a basic task which is sending a file to another website. Another difference is that in Oauth typical scenarios the main interaction of the user remains with a single Website to which I give access to other Website's APIs. In order to give this access I may be redirected to the other Websites but after the authentication the user continues to interact with the original Website. In the scenario I described in my original post, the user switches to a new Website when he sends the file to it. There are a couple of parallelism with the "Open with" feature on the popup menu of a file on Windows Explorer: 1. When Microsoft designed this feature it didn't anticipate all the applications that could be listed in the "Open with" submenu and the user can even select any executable file as an open with target. In the scenario I described, when the user selects the attachment in Gmail he may be presented with a list of popular "open with" or "send to" target websites but the user should have the option to select any website (that complies with this new standard) by typing its URL. 2. When a user selects an application using the "open with" feature, that application opens up and becomes the foreground application which is what the user expects as he wants to keep working on the file with the selected application. The same is true for the sample scenario I described when the user sends his Gmail attachment to photoshop.com in order to edit it. Best Regards, Pablo ------=_NextPart_000_005C_01CB1A44.DE877A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Aaron,

 

Oauth by itself does not allows a website to send a = file to any existing or future website that complies with Oauth. Oauth focuses = on securely granting my authorization to another website’s API but Website A = needs to implement the specific Website B’s API for uploading a file which = can be different from Websites C,D,E, etc. The focus of my proposal is that there should = be a common way (or API) for such a basic task which is sending a file to = another website.

 

Another difference is that in Oauth typical = scenarios the main interaction of the user remains with a single Website to which I = give access to other Website’s APIs. In order to give this access I may = be redirected to the other Websites but after the authentication the user continues to interact with the original Website.

 

In the scenario I described in my original post, = the user switches to a new Website when he sends the file to it.

 

There are a couple of parallelism with the = “Open with” feature on the popup menu of a file on Windows Explorer:

1. When Microsoft designed this feature it = didn’t anticipate all the applications that could be listed in the “Open = with” submenu and the user can even select any executable file as an open with = target. In the scenario I described, when the user selects the attachment in = Gmail he may be presented with a list of popular “open with” or = “send to” target websites but the user should have the option to select = any website (that complies with this new standard) by typing its URL.

2. When a user selects an application using the = “open with” feature, that application opens up and becomes the = foreground application which is what the user expects as he wants to keep working = on the file with the selected application. The same is true for the sample scenario = I described when the user sends his Gmail attachment to photoshop.com in = order to edit it.

 

Best Regards,

         &= nbsp;      Pablo

 

------=_NextPart_000_005C_01CB1A44.DE877A30-- From duerst@it.aoyama.ac.jp Sat Jul 3 00:41: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 323513A6974 for ; Sat, 3 Jul 2010 00:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.022 X-Spam-Level: ** X-Spam-Status: No, score=2.022 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdhJs5P0RdPc for ; Sat, 3 Jul 2010 00:41:07 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id AE94A3A6976 for ; Sat, 3 Jul 2010 00:41:05 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id o637fCAv025405 for ; Sat, 3 Jul 2010 16:41:12 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2440_26f3_5a655968_8676_11df_82ef_001d096c566a; Sat, 03 Jul 2010 16:41:12 +0900 Received: from [IPv6:::1] ([133.2.210.1]:53502) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 3 Jul 2010 16:41:13 +0900 Message-ID: <4C2EE983.1020809@it.aoyama.ac.jp> Date: Sat, 03 Jul 2010 16:40:51 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: Pablo Salomon References: <005b01cb1a5e$03d4b230$0b7e1690$@com> In-Reply-To: <005b01cb1a5e$03d4b230$0b7e1690$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] FWD: Sending personal files between web applications 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, 03 Jul 2010 07:41:08 -0000 On 2010/07/03 12:15, Pablo Salomon wrote: > Hi Aaron, > > > > Oauth by itself does not allows a website to send a file to any existing or > future website that complies with Oauth. Oauth focuses on securely granting > my authorization to another website's API but Website A needs to implement > the specific Website B's API for uploading a file which can be different > from Websites C,D,E, etc. The focus of my proposal is that there should be a > common way (or API) for such a basic task which is sending a file to another > website. There may be no simple API to send (i.e. push) a file from one server to another. There is however an API to get (i.e. pull) a file from one server to another, indeed there are several, in particular HTTP and FTP. Website A only needs to make the file available at a specific URI (/IRI). Website B then simply gets it from there. The whole thing can be expressed with a simple URI (/IRI) without any additional information. There may still be some missing pieces, but as a general guideline, wherever you can pull, prefer it over push. Regards, Martin. > Another difference is that in Oauth typical scenarios the main interaction > of the user remains with a single Website to which I give access to other > Website's APIs. In order to give this access I may be redirected to the > other Websites but after the authentication the user continues to interact > with the original Website. > > > > In the scenario I described in my original post, the user switches to a new > Website when he sends the file to it. > > > > There are a couple of parallelism with the "Open with" feature on the popup > menu of a file on Windows Explorer: > > 1. When Microsoft designed this feature it didn't anticipate all the > applications that could be listed in the "Open with" submenu and the user > can even select any executable file as an open with target. In the scenario > I described, when the user selects the attachment in Gmail he may be > presented with a list of popular "open with" or "send to" target websites > but the user should have the option to select any website (that complies > with this new standard) by typing its URL. > > 2. When a user selects an application using the "open with" feature, that > application opens up and becomes the foreground application which is what > the user expects as he wants to keep working on the file with the selected > application. The same is true for the sample scenario I described when the > user sends his Gmail attachment to photoshop.com in order to edit it. > > > > Best Regards, > > Pablo > > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From john-ietf@jck.com Sat Jul 3 06:09:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9BD03A6805 for ; Sat, 3 Jul 2010 06:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yECT9yI+xDH for ; Sat, 3 Jul 2010 06:09:22 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id CD29C3A6800 for ; Sat, 3 Jul 2010 06:09:21 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OV2TE-000Boy-La; Sat, 03 Jul 2010 09:09:24 -0400 Date: Sat, 03 Jul 2010 09:09:23 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Pablo Salomon Message-ID: <78AF1978C44AB0ED828B61C4@PST.JCK.COM> In-Reply-To: <4C2EE983.1020809@it.aoyama.ac.jp> References: <005b01cb1a5e$03d4b230$0b7e1690$@com> <4C2EE983.1020809@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] FWD: Sending personal files between web applications 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, 03 Jul 2010 13:09:22 -0000 --On Saturday, July 03, 2010 16:40 +0900 "\"Martin J. = D=C3=BCrst\"" wrote: >... > There may be no simple API to send (i.e. push) a file from one > server to another. There is however an API to get (i.e. pull) > a file from one server to another, indeed there are several, > in particular HTTP and FTP. > Website A only needs to make the file available at a specific > URI (/IRI). Website B then simply gets it from there. The > whole thing can be expressed with a simple URI (/IRI) without > any additional information. >=20 > There may still be some missing pieces, but as a general > guideline, wherever you can pull, prefer it over push. Of course FTP is symmetric: given sufficient authentication to meet whatever requirements the server is configured to impose, push ("send") and pull ("get") are equally feasible and convenient. Those who are interested in real or imagined "missing pieces" should participate in the FTPEXT2 BOF in Maastricht. john From dhc@dcrocker.net Sat Jul 3 06:40:44 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 CF2BC3A68A4 for ; Sat, 3 Jul 2010 06:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAgQ3+zuA731 for ; Sat, 3 Jul 2010 06:40:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 5FFAE3A6864 for ; Sat, 3 Jul 2010 06:40:39 -0700 (PDT) Received: from [192.168.1.50] (ppp-68-122-72-44.dsl.pltn13.pacbell.net [68.122.72.44]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o63Dekn8015029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 3 Jul 2010 06:40:51 -0700 Message-ID: <4C2F3DD8.7050802@dcrocker.net> Date: Sat, 03 Jul 2010 06:40:40 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4C2E5B08.70808@stpeter.im> <4C2E7F55.3070302@dcrocker.net> In-Reply-To: <4C2E7F55.3070302@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 03 Jul 2010 06:40:51 -0700 (PDT) Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 13:40:44 -0000 On 7/2/2010 5:07 PM, Dave CROCKER wrote: > Peter, > > We created the X- convention in 1977, for RFC 733, the predecessor to RFC 822. > It became popular and entrenched, very quickly. One of the problems with having a bad memory is that I forget I have a bad memory and should check things. X- was introduced in RFC 822, not RFC 733. So, 1982, not 1977. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ietf@adambarth.com Sat Jul 3 16:22:09 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52793A68E7 for ; Sat, 3 Jul 2010 16:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 Qn6OipRI2QP0 for ; Sat, 3 Jul 2010 16:22:02 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id F08703A68A0 for ; Sat, 3 Jul 2010 16:22:01 -0700 (PDT) Received: by iwn10 with SMTP id 10so2164398iwn.31 for ; Sat, 03 Jul 2010 16:22:01 -0700 (PDT) Received: by 10.231.167.80 with SMTP id p16mr1103780iby.94.1278199321448; Sat, 03 Jul 2010 16:22:01 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id 34sm10303544ibi.12.2010.07.03.16.21.59 (version=SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 16:22:00 -0700 (PDT) Received: by iwn10 with SMTP id 10so2164386iwn.31 for ; Sat, 03 Jul 2010 16:21:59 -0700 (PDT) Received: by 10.231.167.80 with SMTP id p16mr1103754iby.94.1278199319132; Sat, 03 Jul 2010 16:21:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.145.84 with HTTP; Sat, 3 Jul 2010 16:21:39 -0700 (PDT) In-Reply-To: <4C2F3DD8.7050802@dcrocker.net> References: <4C2E5B08.70808@stpeter.im> <4C2E7F55.3070302@dcrocker.net> <4C2F3DD8.7050802@dcrocker.net> From: Adam Barth Date: Sat, 3 Jul 2010 16:21:39 -0700 Message-ID: To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 23:22:09 -0000 I'm not sure how much you all follow the goings on higher up in the stack, but vendor prefixes for CSS (cascading style sheets) has been very successful. For example, -webkit-border-radius is the vendor-specific CSS attribute that generates rounded corners. Vendor prefixes let folks experiment in a "private" namespace, and a number of these extensions have gone on to be part of the core CSS language without their vendor prefix. Of course, the situation with CSS is quite different than with HTTP. For example, there are only a handful of vendors innovating in CSS and the vendor prefixes are quite "well-known" in some unofficial sense. Adam On Sat, Jul 3, 2010 at 6:40 AM, Dave CROCKER wrote: > > > On 7/2/2010 5:07 PM, Dave CROCKER wrote: >> >> Peter, >> >> We created the X- convention in 1977, for RFC 733, the predecessor to RF= C >> 822. >> It became popular and entrenched, very quickly. > > > One of the problems with having a bad memory is that I forget I have a ba= d > memory and should check things. > > X- was introduced in RFC 822, not RFC 733. =A0So, 1982, not 1977. > > d/ > > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From dhc@dcrocker.net Sat Jul 3 17:11: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 55C473A6924 for ; Sat, 3 Jul 2010 17:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4hpM09ZzhKd for ; Sat, 3 Jul 2010 17:11:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 0842D3A6922 for ; Sat, 3 Jul 2010 17:11:43 -0700 (PDT) Received: from [192.168.1.50] (ppp-68-122-72-44.dsl.pltn13.pacbell.net [68.122.72.44]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o640BZm4022419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Jul 2010 17:11:41 -0700 Message-ID: <4C2FD1B2.7010904@dcrocker.net> Date: Sat, 03 Jul 2010 17:11:30 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Adam Barth References: <4C2E5B08.70808@stpeter.im> <4C2E7F55.3070302@dcrocker.net> <4C2F3DD8.7050802@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 03 Jul 2010 17:11:41 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 00:11:49 -0000 On 7/3/2010 4:21 PM, Adam Barth wrote: > Vendor > prefixes let folks experiment in a "private" namespace, and a number > of these extensions have gone on to be part of the core CSS language > without their vendor prefix. My point was not that it is bad to have privately-initiated names, but that it is problematic to have a separate name space for them. The private names develop an installed base and it is a hassle to force that base to migrate over to using new names. It would therefore be better to have names remain stable. This requires assigning private names and public (ie, standards-based) names out of the same pool. And I think this is the premise of Peter's draft, too. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From ietf@adambarth.com Sat Jul 3 20:55:44 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 D015C3A689F for ; Sat, 3 Jul 2010 20:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 LbI4qw3pAqLV for ; Sat, 3 Jul 2010 20:55:44 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 257953A6880 for ; Sat, 3 Jul 2010 20:55:44 -0700 (PDT) Received: by iwn10 with SMTP id 10so2271764iwn.31 for ; Sat, 03 Jul 2010 20:55:44 -0700 (PDT) Received: by 10.231.158.203 with SMTP id g11mr916318ibx.24.1278215743828; Sat, 03 Jul 2010 20:55:43 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id e8sm8939828ibb.2.2010.07.03.20.55.41 (version=SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 20:55:42 -0700 (PDT) Received: by iwn10 with SMTP id 10so2271752iwn.31 for ; Sat, 03 Jul 2010 20:55:41 -0700 (PDT) Received: by 10.231.167.80 with SMTP id p16mr1326788iby.94.1278215741116; Sat, 03 Jul 2010 20:55:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.145.84 with HTTP; Sat, 3 Jul 2010 20:55:21 -0700 (PDT) In-Reply-To: <4C2FD1B2.7010904@dcrocker.net> References: <4C2E5B08.70808@stpeter.im> <4C2E7F55.3070302@dcrocker.net> <4C2F3DD8.7050802@dcrocker.net> <4C2FD1B2.7010904@dcrocker.net> From: Adam Barth Date: Sat, 3 Jul 2010 20:55:21 -0700 Message-ID: To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 03:55:44 -0000 On Sat, Jul 3, 2010 at 5:11 PM, Dave CROCKER wrote: > On 7/3/2010 4:21 PM, Adam Barth wrote: >> =A0 =A0 =A0Vendor >> prefixes let folks experiment in a "private" namespace, and a number >> of these extensions have gone on to be part of the core CSS language >> without their vendor prefix. > > My point was not that it is bad to have privately-initiated names, but th= at > it is problematic to have a separate name space for them. =A0The private = names > develop an installed base and it is a hassle to force that base to migrat= e > over to using new names. > > It would therefore be better to have names remain stable. =A0This require= s > assigning private names and public (ie, standards-based) names out of the > same pool. > > And I think this is the premise of Peter's draft, too. Oh, I understand your point. I was just mentioning a situation where the opposite has worked out quite well for folks. There's lots different between the two situations (HTTP headers and CSS attributes). It might be worth thinking about those difference to develop a more nuanced understanding of when using separate namespaces works out well and when it works out less well. Adam From GK@ninebynine.org Mon Jul 5 03:40:13 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 97EA83A68E1 for ; Mon, 5 Jul 2010 03:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAzotQs1C7ls for ; Mon, 5 Jul 2010 03:40:12 -0700 (PDT) Received: from relay7.mail.ox.ac.uk (relay7.mail.ox.ac.uk [129.67.1.167]) by core3.amsl.com (Postfix) with ESMTP id C047A3A68AD for ; Mon, 5 Jul 2010 03:40:12 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay7.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1OVj5v-0000iw-Ob; Mon, 05 Jul 2010 11:40:11 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OVj5v-0008QC-1W; Mon, 05 Jul 2010 11:40:11 +0100 Message-ID: <4C31A20D.7040101@ninebynine.org> Date: Mon, 05 Jul 2010 10:12:45 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Paul Hoffman References: <4C2E5B08.70808@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 10:40:13 -0000 Paul Hoffman wrote: > This topic was beaten to death well over a decade ago, but the arguments are no different now. Well, in the case of message header fields, this is exactly the problem that RFC 3846 (http://tools.ietf.org/html/bcp90) was designed to address. The registry has been quietly ticking over for some time now. So I think things have moved on a little. #g -- From duerst@it.aoyama.ac.jp Mon Jul 5 04:09: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 982A23A6834 for ; Mon, 5 Jul 2010 04:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.81 X-Spam-Level: ** X-Spam-Status: No, score=2.81 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqOG9Mxpe5ET for ; Mon, 5 Jul 2010 04:09:46 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 46E5E3A67C0 for ; Mon, 5 Jul 2010 04:09:45 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id o65B9bjF006717 for ; Mon, 5 Jul 2010 20:09:37 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 7799_32f6_ccfd798c_8825_11df_80cf_001d096c566a; Mon, 05 Jul 2010 20:09:37 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41219) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 5 Jul 2010 20:09:38 +0900 Message-ID: <4C31BD58.7060607@it.aoyama.ac.jp> Date: Mon, 05 Jul 2010 20:09:12 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: Adam Barth References: <4C2E5B08.70808@stpeter.im> <4C2E7F55.3070302@dcrocker.net> <4C2F3DD8.7050802@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 11:09:47 -0000 Hello Adam, others, On 2010/07/04 8:21, Adam Barth wrote: > I'm not sure how much you all follow the goings on higher up in the > stack, but vendor prefixes for CSS (cascading style sheets) has been > very successful. For example, -webkit-border-radius is the > vendor-specific CSS attribute that generates rounded corners. Vendor > prefixes let folks experiment in a "private" namespace, and a number > of these extensions have gone on to be part of the core CSS language > without their vendor prefix. > > Of course, the situation with CSS is quite different than with HTTP. > For example, there are only a handful of vendors innovating in CSS and > the vendor prefixes are quite "well-known" in some unofficial sense. Yes, and the vendors watch each other closely. Also, an important difference might be that in the end, the CSS properties have to end up in the standard, not just in some registry. Mail headers can just be registered, which at first sight should make it easier to get rid of prefixes, but apparently also makes it easier to ignore (why register if X- already works). Another important difference seems to be that a vendor prefix in the browser world isn't something some other vendor will copy (e.g. it would be strange for Microsoft to implement -webkit-border-radius; if they implement it, they call it -ms-border-radius). With X-, it's much easier for a competitor to just also implement the X-, which means there is less pressure to get rid of the X-. Yet another difference in my view is that the CSS user space (i.e. designers and others using CSS) may be less fragmented than the mail header user space. As an example, if some browser implements rounded corners, many designers, and therefore all browsers, want rounded corners. On the other hand (to take an example in which I was personally involved but which may not necessarily be very representative), if some people come up with the idea for mailing list archives to add an (X-)Archived-At header (http://tools.ietf.org/html/rfc5064) to mails, there are some people who like that a lot and use it a lot, and others who couldn't care less, or even claim that it's impossible to be of any use. Also, related to the above, CSS properties are to the most part used in a single group of applications. Mail headers, on the other hand, may be very specific to one or two pieces of a very diversified toolchain. To again use Archived-At as an example, it's added by mailing list expanders in connection with mailing list archives, and it should just be shown by MUAs and is used directly by users. MUAs don't have to do any processing on it, and mail servers of various kinds just have to forward it, which they do anyway. The above example (Archived-At) is actually very unrepresentative because I put in the effort to get it to an RFC, and the deployments in the X- stage were concentrated in two places (W3C and http://gmane.org/), so it was easy to remove the X-es. Regards, Martin. P.S.: I wish the IETF mailing list archives would also provide Archived-At headers. They are invaluable to quickly point others to past discussions on a mailing list, or to summarize such a discussion as a chair, or to provide links to mails from other places such as issue trackers and the like. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From ajs@shinkuro.com Mon Jul 5 11:39:54 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E993A67EE for ; Mon, 5 Jul 2010 11:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.324 X-Spam-Level: X-Spam-Status: No, score=0.324 tagged_above=-999 required=5 tests=[AWL=1.434, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5FoHSLpr2fg for ; Mon, 5 Jul 2010 11:39:54 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id DC5913A676A for ; Mon, 5 Jul 2010 11:39:53 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0D0D01ECB408; Mon, 5 Jul 2010 18:39:55 +0000 (UTC) Date: Mon, 5 Jul 2010 14:39:53 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20100705183953.GK49823@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dnsext-chairs@tools.ietf.org Subject: [apps-discuss] DNSEXT session on aliasing at IETF 78 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, 05 Jul 2010 18:39:54 -0000 Dear colleagues, I just sent a somewhat formal note to the IETF list about this topic, but I wanted to draw the special attention of people in the applications area to a session we are planning for Maastricht. We have set aside an hour on Wednesday morning to discuss the topic of aliasing in the DNS. I made a short presentation in the appsarea meeting in Anaheim about this topic, and we devoted a significant chunk of the DNSEXT meeting to this as well. This time, we have a session devoted just to this topic, so that we make sure we at least know what the use cases are. It is possible that we will not be able to accommodate all use cases realistically, but we want to try to get a realistic outline of what people would like, anyway. Here is the current (draft) agenda for the Wed morning session: SESSION II 2010-07-28 10:30-11:30 This session is intended to get as much input as possible from the IETF community. A. Aliasing: what we have and what we are planning to do (10 mins) B. Aliasing: the problems we are trying to solve. (10 mins) 1. CNAME can't redirect below. 2. DNAME can't redirect name itself a. effects for mail 3. Provisioning tools not up to the job of fixing above C. Aliasing: what we might not be able to address. (10 mins) 1. Most servers need to know their own name. 2. More possible names -> more ways to fool people 3. DNSSEC assertions from aliasA to aliasB 4. "Second class citizen" problem D. Input time: please raise your issues. Note: it is out of order, in this session, for anyone to say, "That can't be done." This session is to try to get the Big Giant List of Everything Anyone Wants. We really want your participation. If you have a conflict and can't make this session, but have strong views or preferences, please feel free to send them to us (dnsext-chairs@tools.ietf.org) so we can try to express them in the session. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From alexey.melnikov@isode.com Mon Jul 5 11:40:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801783A69F7 for ; Mon, 5 Jul 2010 11:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbHM9cMPkqNz for ; Mon, 5 Jul 2010 11:40:30 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 971353A69F6 for ; Mon, 5 Jul 2010 11:40:26 -0700 (PDT) Received: from [172.16.2.155] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 5 Jul 2010 19:40:27 +0100 Message-ID: <4C3226FE.10108@isode.com> Date: Mon, 05 Jul 2010 19:39: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@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------060008000000080601060903" Subject: [apps-discuss] [Fwd: DNS aliasing at IETF 78: call for participation] 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, 05 Jul 2010 18:40:31 -0000 This is a multi-part message in MIME format. --------------060008000000080601060903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI. --------------060008000000080601060903 Content-Type: message/rfc822; name="DNS aliasing at IETF 78: call for participation" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="DNS aliasing at IETF 78: call for participation" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.6a3) with LMTP; Mon, 05 Jul 2010 19:31:08 +0100 (BST) Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Mon, 5 Jul 2010 19:31:07 +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 93A5128C0D8; Mon, 5 Jul 2010 11:30:09 -0700 (PDT) X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66A928C0CF for ; Mon, 5 Jul 2010 11:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.055 X-Spam-Level: * X-Spam-Status: No, score=1.055 tagged_above=-999 required=5 tests=[AWL=1.054, 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 3Yjj+vgW6V7y for ; Mon, 5 Jul 2010 11:30:06 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D889F28C0D6 for ; Mon, 5 Jul 2010 11:30:06 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A56671ECB408 for ; Mon, 5 Jul 2010 18:30:07 +0000 (UTC) Date: Mon, 5 Jul 2010 14:30:05 -0400 From: Andrew Sullivan To: ietf@ietf.org Subject: DNS aliasing at IETF 78: call for participation Message-ID: <20100705183005.GJ49823@shinkuro.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Dear colleagues, This is an update on the DNS Extensions (DNSEXT) efforts on aliasing in the DNS, and a call for participation. Prior to IETF 77, we posted some background and a call for participation. You can find that in the archives at At IETF 77 in Anaheim, DNSEXT undertook two things: 1. We made a short presentation at the apparea meeting in an effort to encourage interest in this topic among users of the DNS. 2. We devoted a significant chunk of our WG meeting to the topic of what people seem to want from aliasing in the DNS. The upshot of the Anaheim discussions, as well as subsequent discussion over on namedroppers@ops.ietf.org, has led the chairs to propose that we adopt the topic of expanded aliasing support in the DNS as part of a new DNSEXT charter. In Maastricht, we will have two sessions for DNSEXT. One of these sessions is devoted entirely to the topic of aliasing in the DNS from the point of view of the rest of the IETF. That session, currently scheduled for Wednesday morning (10:30-11:30, 0.4 Brussels), is aimed at making sure we really understand the problem we are trying to solve, that we have a complete picture of what needs people think they have, and that people who think their problem is going to be solved understand the limitations of what we are proposing to do (to the extent anyone fully understands that). This session will not be about the details of how the mechanisms work, but will instead focus just on what the mechanisms could or could not be used to accomplish. The goal here is to make sure that we are not overlooking serious use cases that people have. We expect that this will be the last such session we will run prior to the WG commencing detailed work on this topic (unless, of course, we find some showstopper as a result of this discussion). We would appreciate very much any participation from anyone in the IETF about this topic. If you cannot make the session on Wednesday morning, mail either directly to us (the DNSEXT chairs: dnsext-chairs@tools.ietf.org) or to the namedroppers mailing list will also be welcome. Best regards, Olafur Gudmundsson Andrew Sullivan (DNSEXT co-chairs) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --------------060008000000080601060903-- From aaron@serendipity.cx Tue Jul 6 11:06:25 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 19B0D3A679C for ; Tue, 6 Jul 2010 11:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.257 X-Spam-Level: * X-Spam-Status: No, score=1.257 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+LLwi+Yu0ZC for ; Tue, 6 Jul 2010 11:06:23 -0700 (PDT) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by core3.amsl.com (Postfix) with ESMTP id B529C3A67A4 for ; Tue, 6 Jul 2010 11:06:23 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by slice.serendipity.cx (Postfix) with ESMTPSA id D1CB6110188 for ; Tue, 6 Jul 2010 11:06:15 -0700 (PDT) Received: by vws14 with SMTP id 14so6350667vws.31 for ; Tue, 06 Jul 2010 11:06:15 -0700 (PDT) Received: by 10.220.95.199 with SMTP id e7mr2570926vcn.278.1278439575194; Tue, 06 Jul 2010 11:06:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.202.202 with HTTP; Tue, 6 Jul 2010 11:05:55 -0700 (PDT) In-Reply-To: <4C2EE983.1020809@it.aoyama.ac.jp> References: <005b01cb1a5e$03d4b230$0b7e1690$@com> <4C2EE983.1020809@it.aoyama.ac.jp> From: Aaron Stone Date: Tue, 6 Jul 2010 11:05:55 -0700 Message-ID: To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Pablo Salomon Subject: Re: [apps-discuss] FWD: Sending personal files between web applications 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, 06 Jul 2010 18:06:25 -0000 On Sat, Jul 3, 2010 at 12:40 AM, "Martin J. D=FCrst" wrote: > On 2010/07/03 12:15, Pablo Salomon wrote: >> >> Hi Aaron, >> >> >> >> Oauth by itself does not allows a website to send a file to any existing >> or >> future website that complies with Oauth. Oauth focuses on securely >> granting >> my authorization to another website's API but Website A needs to impleme= nt >> the specific Website B's API for uploading a file which can be different >> from Websites C,D,E, etc. The focus of my proposal is that there should = be >> a >> common way (or API) for such a basic task which is sending a file to >> another >> website. The semantics of what it means to push a file from Site A to Site B are necessarily defined by the two sites. Any protocol that's meant to carry the file needs to be plugged into some code that implements the semantics of what the site will do with that file. WebDAV provides the semantics of "I want File X to appear at URL Y". Web APIs provide deeper semantics like, "I want File X to become my account profile icon." I have no idea how you'd standardize that. > There may be no simple API to send (i.e. push) a file from one server to > another. There is however an API to get (i.e. pull) a file from one serve= r > to another, indeed there are several, in particular HTTP and FTP. > Website A only needs to make the file available at a specific URI (/IRI). > Website B then simply gets it from there. The whole thing can be expresse= d > with a simple URI (/IRI) without any additional information. WebDAV provides a push API. I haven't been following OAuth closely enough to know if someone is looking at how WebDAV would work with OAuth. Off the cuff, I believe that it's as simple as publishing an appropriate Authenticate / WWW-Authenticate header on a Not Authorized response. http://oauth.net/core/1.0/#auth_header and letting the HTTP bits sort themselves out. > There may still be some missing pieces, but as a general guideline, where= ver > you can pull, prefer it over push. > > Regards, =A0 =A0Martin. > >> Another difference is that in Oauth typical scenarios the main interacti= on >> of the user remains with a single Website to which I give access to othe= r >> Website's APIs. In order to give this access I may be redirected to the >> other Websites but after the authentication the user continues to intera= ct >> with the original Website. >> >> >> >> In the scenario I described in my original post, the user switches to a >> new >> Website when he sends the file to it. >> >> >> >> There are a couple of parallelism with the "Open with" feature on the >> popup >> menu of a file on Windows Explorer: >> >> 1. When Microsoft designed this feature it didn't anticipate all the >> applications that could be listed in the "Open with" submenu and the use= r >> can even select any executable file as an open with target. In the >> scenario >> I described, when the user selects the attachment in Gmail he may be >> presented with a list of popular "open with" or "send to" target website= s >> but the user should have the option to select any website (that complies >> with this new standard) by typing its URL. >> >> 2. When a user selects an application using the "open with" feature, tha= t >> application opens up and becomes the foreground application which is wha= t >> the user expects as he wants to keep working on the file with the select= ed >> application. The same is true for the sample scenario I described when t= he >> user sends his Gmail attachment to photoshop.com in order to edit it. (Responding to Pablo) Oh! Ok, in this very limited use case, I definitely get where an "open with" URL makes sense. The right layer for this might be a microformat, or well-known-uri. http://microformats.org/ http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml The underlying protocols would absolutely be HTTP and OAuth -- for example: http://spreadsheets.example.com/openwith?uri=3Dhttp://mysite.example.com/my= doc.csv You'd log into spreadsheets.example.com, then it looks at the openwith arguments and pulls the file into the spreadsheet editor. If the file is not protected, it loads right away. If the file is protected, the OAuth dance proceeds. Cheers, Aaron From barryleiba.mailing.lists@gmail.com Tue Jul 6 19:53:25 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 E4FC53A68F1 for ; Tue, 6 Jul 2010 19:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUIHxQJ0oAO6 for ; Tue, 6 Jul 2010 19:53:25 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E2B443A6359 for ; Tue, 6 Jul 2010 19:53:24 -0700 (PDT) Received: by iwn38 with SMTP id 38so1747250iwn.31 for ; Tue, 06 Jul 2010 19:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=BWGjcew2xxBjIDPE2jwtoTnlLUBzldZ3IZWO7PR6EQA=; b=T6dtkaTveCbXcKcVjfTHzwIroUyYpkKbUs9JLyRcdV2PtVxlBnaWikdKlaKhf0OzIP QIDxvucatrbINjtwSjDdcX9XnSSPHxBdSguyOIrg5Dnym5uDr8cQP6K8GwaNlcyyEpne K0W3vgH0VUXLWM2Y9K/u/VIEqLfVj9ScuE4ZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=OhE1/rCg3YND+RXSm66sXtveJztfi9D/q8s9bzvMfXOnrfHKHdxe2Lzyy80OaUjR3P WNzK++r3/UVlimcnOnILAHQiujMMQAU1Y1JL9S47bzvoqJSBFY9GPC6Mjw3tOhlY9AvY 7PqMfsd93lB3qTsGXbCAmUQaNLN5YX4tCRGBg= MIME-Version: 1.0 Received: by 10.42.2.18 with SMTP id 18mr1819044ici.24.1278471207249; Tue, 06 Jul 2010 19:53:27 -0700 (PDT) Received: by 10.42.5.212 with HTTP; Tue, 6 Jul 2010 19:53:27 -0700 (PDT) In-Reply-To: <4C31A20D.7040101@ninebynine.org> References: <4C2E5B08.70808@stpeter.im> <4C31A20D.7040101@ninebynine.org> Date: Tue, 6 Jul 2010 22:53:27 -0400 Message-ID: From: Barry Leiba To: Graham Klyne Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 02:53:26 -0000 On Mon, Jul 5, 2010 at 5:12 AM, Graham Klyne wrote: > Well, in the case of message header fields, this is exactly the problem that > RFC 3846 (http://tools.ietf.org/html/bcp90) was designed to address. That'd be "3864", in case anyone else tried to look it up by RFC number. Barry From josh@lindenlab.com Wed Jul 7 12:29: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 EE7A63A686E for ; Wed, 7 Jul 2010 12:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.183 X-Spam-Level: X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 VSz6adE4dHS9 for ; Wed, 7 Jul 2010 12:29:33 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3E8E73A686B for ; Wed, 7 Jul 2010 12:29:33 -0700 (PDT) Received: by vws14 with SMTP id 14so28444vws.31 for ; Wed, 07 Jul 2010 12:29:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.88.68 with SMTP id z4mr3525929vcl.145.1278530970315; Wed, 07 Jul 2010 12:29:30 -0700 (PDT) Received: by 10.220.181.132 with HTTP; Wed, 7 Jul 2010 12:29:30 -0700 (PDT) Date: Wed, 7 Jul 2010 12:29:30 -0700 Message-ID: From: Joshua Bell To: apps-discuss@ietf.org, draft-ietf-ecrit-lost-servicelistboundary@tools.ietf.org, Marc Linsner , Richard Barnes Content-Type: multipart/alternative; boundary=0016e6471b2e51eb99048ad130f1 Subject: [apps-discuss] apps-team review of draft-ietf-ecrit-lost-servicelistboundary-03 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, 07 Jul 2010 19:29:35 -0000 --0016e6471b2e51eb99048ad130f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Richard Barnes (ECRIT co-chair) requested a review of draft-ietf-ecrit-lost-servicelistboundary-03 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ecrit-lost-servicelistboundary-03 Reviewer: Joshua Bell Review Date: 2010-07-07 Summary: This draft is not ready for publication as a Proposed Standard; inconsistencies in the XML examples and normative RelaxNG schema must be addressed before publication. Major Issues: The Relax NG schema in section 5.1 appears to be invalid. (Caveat: I=E2=80= =99m new to RelaxNG) Validation of samples was attempted using xmllint ("using libxm= l version 20627"), and using lost.rng from http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/RelaxNG/lost.rngref= erenced in RFC5222 The grammar element of the schema must specify xmlns=3D" http://relaxng.org/ns/structure/1.0" rather than xmlns=3D"urn:ietf:params:xml:ns:lost1"; it should target the lost namespace via the ns attribute i.e.: Per http://www.relaxng.org/spec-20011203.html the value of the name attribute of a ref element must be a NCName, so the use of an XML namespace prefix is invalid in ref: A definition for an element named serviceListBoundary itself is not defined= ; this is used in examples (e.g. Section 3.1, first response) but not in the RelaxNG Schema. The schema defines: I suspect that usage of serviceListBoundary (without a suffix) is an older construction that was replaced by serviceListBoundaryResponse and serviceListBoundaryReference when reference responses were added. While the intent of the schema and examples are clear, I believe a further review must be performed after these issues are corrected, the schema can b= e tested and the examples can be validated. Minor Issues: Section 3.3 "The server may return... " - should be MAY "...but has to use at least one ..." - should be MUST Section 3.4.1 Much of this section is overly casual and thus confusingly worded; while apparently not normative, they distract from the readability of the document. * "Probably for some countries..." * "So a reasonable trade-off..." * "So when moving..." ...and generally in the draft, any sentence with "has to" could stand to be reworded for clarity, even if not normative Section 3.4.2 ".. the client must perform ..." - is this a MUST in the RFC 2119 sense? If so, capitalize and make it clear that this is normative. Otherwise, reword. Nits: Section 3.4.1 * Typo ("disrict" --> "district"). --0016e6471b2e51eb99048ad130f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Richard Barnes (ECRIT co-chair) requested a review of=C2=A0draft-ietf-= ecrit-lost-servicelistboundary-03

I have been sele= cted as the Applications Area Review Team reviewer for this draft (for back= ground on apps-review, please see http://www.apps.ietf.org/content/applicat= ions-area-review-team).
Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd or A= D before posting a new version of the draft.

Docum= ent: draft-ietf-ecrit-lost-servicelistboundary-03
Reviewer: Joshua Bell
Review Date: 2010-07-07

=
Summary:=C2=A0

This draft is not ready = for publication as a Proposed Standard; inconsistencies in the XML examples= and normative RelaxNG schema must be addressed before publication.

Major Issues:

The Relax NG sch= ema in section 5.1 appears to be invalid. (Caveat: I=E2=80=99m new to Relax= NG) Validation of samples was attempted using xmllint ("using libxml v= ersion 20627"), and using lost.rng from http://www.tschofeni= g.priv.at/svn/draft-ietf-ecrit-lost/RelaxNG/lost.rng referenced in RFC5= 222
<ref name=3D"slb:serviceListBoundaryResponse"/>
<= div>
The grammar element of the schema must specify xmlns=3D&= quot;http://relaxng.org/ns/= structure/1.0" rather than=C2=A0xmlns=3D"urn:ietf:params:xml:= ns:lost1"; it should target the lost namespace via the ns attribute i.= e.:=C2=A0

<grammar ns=3D"urn:ietf:params:xml:ns:lost= 1"=C2=A0xmlns=3D"= http://relaxng.org/ns/structure/1.0"=C2=A0xmlns:slb=3D"urn:ie= tf:params:xml:ns:lost1:slb">

Per http://www.relaxng.org/spec-20011203.html the value of the nam= e attribute of a ref element must be a NCName, so the use of an XML namespa= ce prefix is invalid in ref:

&= lt;ref name=3D"slb:serviceListBoundary"/>

=
A definition for an element named serviceListBoundary itself is not de= fined; this is used in examples =C2=A0(e.g. Section 3.1, first response) bu= t not in the RelaxNG Schema. The schema defines:

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<choice><= /div>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <ref name=3D&q= uot;slb:serviceListBoundaryResponse"/>
=C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <ref name=3D"slb:serviceListBoundar= yReference"/>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </choice>
I suspect that usage of serviceListBoundary (without a suffix) = is an older construction that was replaced by serviceListBoundaryResponse a= nd serviceListBoundaryReference when reference responses were added.

While the intent of the schema and examples are clear, = I believe a further review must be performed after these issues are correct= ed, the schema can be tested and the examples can be validated.

Minor Issues:=C2=A0

Section 3.3

"The server may return... " - should be MAY=
"...but has to use at least one ..." - should be MUST<= /div>

Section 3.4.1

Much of this sec= tion is overly casual and thus confusingly worded; while apparently not nor= mative, they distract from the readability of the document.=C2=A0

* "Probably for some countries..."
* &qu= ot;So a reasonable trade-off..."
* "So when moving...&q= uot;
...and generally in the draft, any sentence with "has t= o" could stand to be reworded for clarity, even if not normative

Section 3.4.2

".. the cli= ent must perform ..." - is this a MUST in the RFC 2119 sense? If so, c= apitalize and make it clear that this is normative. Otherwise, reword.

Nits:=C2=A0

Section 3.4.1
* Typo ("disrict" --> "district").=C2=A0
=

--0016e6471b2e51eb99048ad130f1-- From alexey.melnikov@isode.com Wed Jul 7 14:05:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE103A69A6; Wed, 7 Jul 2010 14:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 VynfEgnNDaT5; Wed, 7 Jul 2010 14:05:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2EB653A68BB; Wed, 7 Jul 2010 14:05:27 -0700 (PDT) Received: from [172.16.2.122] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 7 Jul 2010 22:05:29 +0100 Message-ID: <4C34EBE2.5030907@isode.com> Date: Wed, 07 Jul 2010 22:04:34 +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: ltru@ietf.org, Apps-Discuss@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000604090601050604080709" Subject: [apps-discuss] [Fwd: Last Call: draft-davis-u-langtag-ext (BCP 47 Extension U) to Informational RFC] 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, 07 Jul 2010 21:05:28 -0000 This is a multi-part message in MIME format. --------------000604090601050604080709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI. --------------000604090601050604080709 Content-Type: message/rfc822; name="Last Call: draft-davis-u-langtag-ext (BCP 47 Extension U) to InformationalRFC" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Last Call: draft-davis-u-langtag-ext (BCP 47 Extension U) to InformationalRFC" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.6a3) with LMTP; Wed, 07 Jul 2010 22:03:16 +0100 (BST) Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Wed, 7 Jul 2010 22:03:15 +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 60C033A69B4; Wed, 7 Jul 2010 14:02:49 -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 8C2443A69B0; Wed, 7 Jul 2010 14:02:40 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-davis-u-langtag-ext (BCP 47 Extension U) to Informational RFC Message-Id: <20100707210242.8C2443A69B0@core3.amsl.com> Date: Wed, 7 Jul 2010 14:02:40 -0700 (PDT) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org 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 received a request from an individual submitter to consider the following document: - 'BCP 47 Extension U ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-08-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-davis-u-langtag-ext-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19525&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------000604090601050604080709-- From alexey.melnikov@isode.com Wed Jul 7 14:06: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 548283A69A6 for ; Wed, 7 Jul 2010 14:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.513, 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 oHCDHsfHUc1a for ; Wed, 7 Jul 2010 14:06:37 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CED3F3A69A5 for ; Wed, 7 Jul 2010 14:06:36 -0700 (PDT) Received: from [172.16.2.122] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 7 Jul 2010 22:06:38 +0100 Message-ID: <4C34EC2A.3060901@isode.com> Date: Wed, 07 Jul 2010 22:05:46 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------030205060203020105040106" Subject: [apps-discuss] [Fwd: Last Call: draft-presuhn-rfc2482-historic (Deprecating Unicode Language Tag Characters: RFC 2482 is Historic) to Informational RFC] 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, 07 Jul 2010 21:06:39 -0000 This is a multi-part message in MIME format. --------------030205060203020105040106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As per recent discussion about deprecating language tagging in Unicode. --------------030205060203020105040106 Content-Type: message/rfc822; name="Last Call: draft-presuhn-rfc2482-historic (Deprecating Unicode Language TagCharacters: RFC 2482 is Historic) to Informational RFC" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Last Call: draft-presuhn-rfc2482-historic (Deprecating Unicode Language TagCharacters: RFC 2482 is Historic) to Informational RFC" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.6a3) with LMTP; Wed, 07 Jul 2010 22:04:32 +0100 (BST) Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Wed, 7 Jul 2010 22:04:32 +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 6C04E3A69D3; Wed, 7 Jul 2010 14:03:15 -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 5C6633A69A6; Wed, 7 Jul 2010 14:03:11 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-presuhn-rfc2482-historic (Deprecating Unicode Language Tag Characters: RFC 2482 is Historic) to Informational RFC Message-Id: <20100707210312.5C6633A69A6@core3.amsl.com> Date: Wed, 7 Jul 2010 14:03:11 -0700 (PDT) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org 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 received a request from an individual submitter to consider the following document: - 'Deprecating Unicode Language Tag Characters: RFC 2482 is Historic ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-08-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-presuhn-rfc2482-historic-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=20085&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------030205060203020105040106-- From alexey.melnikov@isode.com Wed Jul 7 14:17: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 AC5F43A6973 for ; Wed, 7 Jul 2010 14:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 i7q65zaFrxXp for ; Wed, 7 Jul 2010 14:17:55 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id F1EDC3A6925 for ; Wed, 7 Jul 2010 14:17:54 -0700 (PDT) Received: from [172.16.2.122] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 7 Jul 2010 22:17:56 +0100 Message-ID: <4C34EECF.4000608@isode.com> Date: Wed, 07 Jul 2010 22:17:03 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Presentation about IETF datatracker during Apps Area meeting? 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, 07 Jul 2010 21:17:55 -0000 Greetings, It occurred to me that many people might not be familiar with IETF datatracker, how IESG is using it and what kind of useful information can be found there. Are people interested in a 5-10 minutes demonstration during the Apps Area meeting? Regards, Alexey From aaron@serendipity.cx Wed Jul 7 15:53:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69D83A69A1 for ; Wed, 7 Jul 2010 15:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 3Ibo+NJN0s9U for ; Wed, 7 Jul 2010 15:53:51 -0700 (PDT) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by core3.amsl.com (Postfix) with ESMTP id 29CF73A695D for ; Wed, 7 Jul 2010 15:53:51 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by slice.serendipity.cx (Postfix) with ESMTPSA id D06FF110187 for ; Wed, 7 Jul 2010 15:53:49 -0700 (PDT) Received: by vws14 with SMTP id 14so244503vws.31 for ; Wed, 07 Jul 2010 15:53:49 -0700 (PDT) Received: by 10.220.157.139 with SMTP id b11mr3803444vcx.40.1278543229077; Wed, 07 Jul 2010 15:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.202.202 with HTTP; Wed, 7 Jul 2010 15:53:29 -0700 (PDT) In-Reply-To: <4C34EECF.4000608@isode.com> References: <4C34EECF.4000608@isode.com> From: Aaron Stone Date: Wed, 7 Jul 2010 15:53:29 -0700 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps-Discuss@ietf.org Subject: Re: [apps-discuss] Presentation about IETF datatracker during Apps Area meeting? 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, 07 Jul 2010 22:53:51 -0000 Yes, please! On Wed, Jul 7, 2010 at 2:17 PM, Alexey Melnikov wrote: > Greetings, > It occurred to me that many people might not be familiar with IETF > datatracker, how IESG is using it and what kind of useful information can be > found there. > Are people interested in a 5-10 minutes demonstration during the Apps Area > meeting? > > Regards, > Alexey > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From dhc@dcrocker.net Wed Jul 7 16:23:57 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82EB23A69D8 for ; Wed, 7 Jul 2010 16:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do4T9dgYAe42 for ; Wed, 7 Jul 2010 16:23:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 99BB43A69BD for ; Wed, 7 Jul 2010 16:23:56 -0700 (PDT) Received: from [192.168.1.102] (ppp-68-122-72-44.dsl.pltn13.pacbell.net [68.122.72.44]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o67NNshC022068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 16:23:59 -0700 Message-ID: <4C350C84.4040206@dcrocker.net> Date: Wed, 07 Jul 2010 16:23:48 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4C34EECF.4000608@isode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 07 Jul 2010 16:24:00 -0700 (PDT) Cc: Apps-Discuss@ietf.org Subject: Re: [apps-discuss] Presentation about IETF datatracker during Apps Area meeting? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 23:23:57 -0000 On 7/7/2010 3:53 PM, Aaron Stone wrote: > Yes, please! +1. Especially with the major changes that have been done. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Wed Jul 7 16:35:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7463A68D3 for ; Wed, 7 Jul 2010 16:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19hUw2KBZToG for ; Wed, 7 Jul 2010 16:35:22 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 26AF93A68FB for ; Wed, 7 Jul 2010 16:35:22 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 7 Jul 2010 16:35:25 -0700 From: "Murray S. Kucherawy" To: "dcrocker@bbiw.net" , Alexey Melnikov Date: Wed, 7 Jul 2010 16:35:24 -0700 Thread-Topic: [apps-discuss] Presentation about IETF datatracker during Apps Area meeting? Thread-Index: AcseK30XeoG36rtLQAW7NQj5rGliJAAAY4kg Message-ID: References: <4C34EECF.4000608@isode.com> <4C350C84.4040206@dcrocker.net> In-Reply-To: <4C350C84.4040206@dcrocker.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: "Apps-Discuss@ietf.org" Subject: Re: [apps-discuss] Presentation about IETF datatracker during Apps Area meeting? 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, 07 Jul 2010 23:35:23 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Dave CROCKER > Sent: Wednesday, July 07, 2010 4:24 PM > To: Alexey Melnikov > Cc: Apps-Discuss@ietf.org > Subject: Re: [apps-discuss] Presentation about IETF datatracker during > Apps Area meeting? >=20 > On 7/7/2010 3:53 PM, Aaron Stone wrote: > > Yes, please! >=20 > +1. >=20 > Especially with the major changes that have been done. +1, same reason. From ajs@shinkuro.com Wed Jul 7 21:56:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3631A3A68AF for ; Wed, 7 Jul 2010 21:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.107 X-Spam-Level: X-Spam-Status: No, score=0.107 tagged_above=-999 required=5 tests=[AWL=2.707, 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 CUHSW30xhzX4 for ; Wed, 7 Jul 2010 21:56:27 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 631ED3A6870 for ; Wed, 7 Jul 2010 21:56:27 -0700 (PDT) Received: from crankycanuck.ca (72-255-3-211.client.stsn.net [72.255.3.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 19C421ECB408 for ; Thu, 8 Jul 2010 04:56:27 +0000 (UTC) Date: Thu, 8 Jul 2010 00:56:20 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20100708045619.GC61335@shinkuro.com> References: <4C34EECF.4000608@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C34EECF.4000608@isode.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [apps-discuss] Presentation about IETF datatracker during Apps Area meeting? 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, 08 Jul 2010 04:56:28 -0000 On Wed, Jul 07, 2010 at 10:17:03PM +0100, Alexey Melnikov wrote: > Are people interested in a 5-10 minutes demonstration during the Apps > Area meeting? I would be. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jyee@ca.afilias.info Thu Jul 8 07:52: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 AC2B13A6AED for ; Thu, 8 Jul 2010 07:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aey-8Ri+zKSL for ; Thu, 8 Jul 2010 07:52:02 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id D05FC3A6AE4 for ; Thu, 8 Jul 2010 07:52:02 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OWsSM-0004SD-86 for Apps-Discuss@ietf.org; Thu, 08 Jul 2010 14:52:06 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OWsSM-0000Fu-7Y; Thu, 08 Jul 2010 14:52:06 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: Date: Thu, 8 Jul 2010 10:52:05 -0400 Content-Transfer-Encoding: 7bit Message-Id: <192A5F0C-A09C-46B1-A465-1BEE73B3AB71@ca.afilias.info> References: <4C34EECF.4000608@isode.com> <4C350C84.4040206@dcrocker.net> To: Apps-Discuss@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [apps-discuss] Presentation about IETF datatracker during Apps Area meeting? 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, 08 Jul 2010 14:52:03 -0000 On 2010-07-07, at 7:35 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Dave CROCKER >> Sent: Wednesday, July 07, 2010 4:24 PM >> To: Alexey Melnikov >> Cc: Apps-Discuss@ietf.org >> Subject: Re: [apps-discuss] Presentation about IETF datatracker during >> Apps Area meeting? >> >> On 7/7/2010 3:53 PM, Aaron Stone wrote: >>> Yes, please! >> >> +1. >> >> Especially with the major changes that have been done. > > +1, same reason. +1, look forward to it. Joseph > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From karlheinz.wolf@nic.at Thu Jul 8 03:17: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 CE5A43A6970 for ; Thu, 8 Jul 2010 03:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.03 X-Spam-Level: * X-Spam-Status: No, score=1.03 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 QkAlZ8g6ayrs for ; Thu, 8 Jul 2010 03:16:53 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id E78843A69C2 for ; Thu, 8 Jul 2010 03:16:51 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.45 ; Thu, 8 Jul 2010 12:16:54 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.694.0; Thu, 8 Jul 2010 12:16:52 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1E86.AEED22A7" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 Jul 2010 12:16:50 +0200 Message-ID: <8BC845943058D844ABFC73D2220D4665093ABD0E@nics-mail.sbg.nic.at> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: apps-team review of draft-ietf-ecrit-lost-servicelistboundary-03 Thread-Index: AcseCsb3X6zF7gUkS+CstyC9ZWFoGAAe3F0A References: From: Karl Heinz Wolf To: Joshua Bell , , , Marc Linsner , Richard Barnes X-XWALL-BCKS: auto X-Mailman-Approved-At: Thu, 08 Jul 2010 08:11:45 -0700 Subject: Re: [apps-discuss] apps-team review of draft-ietf-ecrit-lost-servicelistboundary-03 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, 08 Jul 2010 10:17:00 -0000 ------_=_NextPart_001_01CB1E86.AEED22A7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joshua, =20 thank you for your detailed review - I appreaciate your comments. Right now I'm struggeling with getting the namespace issue correct. How do I reference to the xmlns:slb=3D"urn:ietf:params:xml:ns:lost1:slb" namespace, when I cannot use slb: in name attribute of the ref element? Your help would be appricated! Thank you, Karl ________________________________ Von: Joshua Bell [mailto:josh@lindenlab.com]=20 Gesendet: Mittwoch, 07. Juli 2010 21:30 An: apps-discuss@ietf.org; draft-ietf-ecrit-lost-servicelistboundary@tools.ietf.org; Marc Linsner; Richard Barnes Betreff: apps-team review of draft-ietf-ecrit-lost-servicelistboundary-03 =09 =09 Richard Barnes (ECRIT co-chair) requested a review of draft-ietf-ecrit-lost-servicelistboundary-03 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ecrit-lost-servicelistboundary-03 Reviewer: Joshua Bell Review Date: 2010-07-07 Summary:=20 This draft is not ready for publication as a Proposed Standard; inconsistencies in the XML examples and normative RelaxNG schema must be addressed before publication. Major Issues: The Relax NG schema in section 5.1 appears to be invalid. (Caveat: I'm new to RelaxNG) Validation of samples was attempted using xmllint ("using libxml version 20627"), and using lost.rng from http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/RelaxNG/lost.rng referenced in RFC5222 The grammar element of the schema must specify xmlns=3D"http://relaxng.org/ns/structure/1.0" rather than xmlns=3D"urn:ietf:params:xml:ns:lost1"; it should target the lost namespace via the ns attribute i.e.:=20 Per http://www.relaxng.org/spec-20011203.html the value of the name attribute of a ref element must be a NCName, so the use of an XML namespace prefix is invalid in ref: =09 =09 A definition for an element named serviceListBoundary itself is not defined; this is used in examples (e.g. Section 3.1, first response) but not in the RelaxNG Schema. The schema defines: I suspect that usage of serviceListBoundary (without a suffix) is an older construction that was replaced by serviceListBoundaryResponse and serviceListBoundaryReference when reference responses were added. While the intent of the schema and examples are clear, I believe a further review must be performed after these issues are corrected, the schema can be tested and the examples can be validated. Minor Issues:=20 Section 3.3 "The server may return... " - should be MAY "...but has to use at least one ..." - should be MUST Section 3.4.1 Much of this section is overly casual and thus confusingly worded; while apparently not normative, they distract from the readability of the document.=20 * "Probably for some countries..." * "So a reasonable trade-off..." * "So when moving..." ...and generally in the draft, any sentence with "has to" could stand to be reworded for clarity, even if not normative Section 3.4.2 ".. the client must perform ..." - is this a MUST in the RFC 2119 sense? If so, capitalize and make it clear that this is normative. Otherwise, reword. Nits:=20 Section 3.4.1 * Typo ("disrict" --> "district").=20 ------_=_NextPart_001_01CB1E86.AEED22A7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Joshua,
 
thank you for your=20 detailed review - I appreaciate your comments.
Right now=20 I'm struggeling with getting the namespace issue correct. How do = I=20 reference to the xmlns:slb=3D"urn:ietf:params:xml:ns:lost1:slb" = namespace, when I=20 cannot use slb: in name = attribute of=20 the ref element?
Your help would be appricated!
Thank=20 you,
Karl

Von: Joshua Bell = [mailto:josh@lindenlab.com]=20
Gesendet: Mittwoch, 07. Juli 2010 21:30
An:=20 apps-discuss@ietf.org;=20 draft-ietf-ecrit-lost-servicelistboundary@tools.ietf.org; Marc = Linsner;=20 Richard Barnes
Betreff: apps-team review of=20 draft-ietf-ecrit-lost-servicelistboundary-03

Richard Barnes (ECRIT co-chair) requested a review=20 of draft-ietf-ecrit-lost-servicelistboundary-03

I have been selected as the Applications Area Review Team = reviewer for=20 this draft (for background on apps-review, please see h= ttp://www.apps.ietf.org/content/applications-area-review-team).
=
Please resolve these comments along with any other Last Call = comments you=20 may receive. Please wait for direction from your document shepherd or = AD=20 before posting a new version of the draft.

Document: draft-ietf-ecrit-lost-servicelistboundary-03
Reviewer: Joshua Bell
Review Date: 2010-07-07

Summary: 

This draft is not ready for publication as a Proposed Standard;=20 inconsistencies in the XML examples and normative RelaxNG schema must = be=20 addressed before publication.

Major Issues:

The Relax NG schema in section 5.1 appears to be invalid. = (Caveat: I’m=20 new to RelaxNG) Validation of samples was attempted using xmllint = ("using=20 libxml version 20627"), and using lost.rng from http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/RelaxNG/= lost.rng=20 referenced in RFC5222
<ref name=3D"slb:serviceListBoundaryResponse"/>

The grammar element of the schema must specify xmlns=3D"http://relaxng.org/ns/struct= ure/1.0"=20 rather than xmlns=3D"urn:ietf:params:xml:ns:lost1"; it should = target the=20 lost namespace via the ns attribute i.e.: 

<grammar ns=3D"urn:ietf:params:xml:ns:lost1" xmlns=3D"http://relaxng.org/ns/struct= ure/1.0" xmlns:slb=3D"urn:ietf:params:xml:ns:lost1:slb">

Per http://www.relaxng.org= /spec-20011203.html=20 the value of the name attribute of a ref element must be a NCName, so = the use=20 of an XML namespace prefix is invalid in ref:

<ref=20 name=3D"slb:serviceListBoundary"/>

A definition for an element named serviceListBoundary itself is = not=20 defined; this is used in examples  (e.g. Section 3.1, first = response) but=20 not in the RelaxNG Schema. The schema defines:

          <choice>
             <ref=20 name=3D"slb:serviceListBoundaryResponse"/>
             <ref=20 name=3D"slb:serviceListBoundaryReference"/>
           </choice>

I suspect that usage of serviceListBoundary (without a suffix) is = an=20 older construction that was replaced by serviceListBoundaryResponse = and=20 serviceListBoundaryReference when reference responses were = added.

While the intent of the schema and examples are clear, I believe = a=20 further review must be performed after these issues are corrected, the = schema=20 can be tested and the examples can be validated.

Minor Issues: 

Section 3.3

"The server may return... " - should be MAY
"...but has to use at least one ..." - should be MUST

Section 3.4.1

Much of this section is overly casual and thus confusingly = worded; while=20 apparently not normative, they distract from the readability of the=20 document. 

* "Probably for some countries..."
* "So a reasonable trade-off..."
* "So when moving..."
...and generally in the draft, any sentence with "has to" could = stand to=20 be reworded for clarity, even if not normative

Section 3.4.2

".. the client must perform ..." - is this a MUST in the RFC 2119 = sense?=20 If so, capitalize and make it clear that this is normative. Otherwise, = reword.

Nits: 

Section 3.4.1
* Typo ("disrict" --> "district"). 

------_=_NextPart_001_01CB1E86.AEED22A7-- From alexey.melnikov@isode.com Sun Jul 11 13:07: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 B4A623A6A01 for ; Sun, 11 Jul 2010 13:07:40 -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=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u8y2Eh7AAfB for ; Sun, 11 Jul 2010 13:07:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 62B823A6800 for ; Sun, 11 Jul 2010 13:07:38 -0700 (PDT) Received: from [188.28.62.104] (188.28.62.104.threembb.co.uk [188.28.62.104]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 11 Jul 2010 21:07:43 +0100 Message-ID: <4C3A2486.9@isode.com> Date: Sun, 11 Jul 2010 21:07:34 +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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: alexey-melnikov-chairs@tools.ietf.org Subject: [apps-discuss] Alexey's Apps Area Activity Report for June 2010-July 11th 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, 11 Jul 2010 20:07:40 -0000 Document Status and Progress: Active documents, my action: - draft-saintandre-tls-server-id-check (Proposed Standard) - need to review the latest version - 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 - rfc4049 (Experimental --> Proposed Standard) - past IESG review, I need to followup on some RFC Editor notes - draft-denenberg-mods-etc-media-types (Proposed Standard) - need to help the author address DISCUSSes from IESG Active documents, waiting on others: - draft-ietf-eai-mailinglist (Experimental) - waiting for document write-up. I am hoping to have this in IESG review next week. - draft-loreto-http-bidirectional-02 (Informational) - performed AD review, new revision is needed - draft-hethmon-mcmurray-ftp-hosts (Proposed Standard) - waiting till after FTPEXT2 BOF in Maastricht before deciding how to proceed with this document - 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 (since 2009-12-17!) - draft-burnett-pronunciation-alphabet-registry (None) - waiting for authors to address comments from a Language Tag expert reviewer (Doug Ewell). Assuming the document is dead. Active documents in IETF LC or IESG review: - draft-davis-u-langtag-ext (Informational) - in IETF LC - draft-presuhn-rfc2482-historic (Informational) - in IETF LC - draft-daboo-srv-caldav-03 (Proposed Standard) - in IETF LC - draft-elie-nntp-list-additions (Proposed Standard) - in IETF LC In RFC Editor's queue: - draft-duerst-mailto-bis (Proposed Standard) - draft-daboo-srv-email (Proposed Standard) - draft-kucherawy-authres-header-b (Proposed Standard) - draft-freed-sieve-notary (Proposed Standard) - draft-santoni-media-type-tsd (Informational) - draft-altman-tls-channel-bindings (Proposed Standard) - in AUTH48 - draft-ietf-marf-base (Proposed Standard) - draft-reschke-webdav-post (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: None this month List of DISCUSSes I am currently holding: Really Old: draft-drage-sipping-service-identification-03.txt draft-ietf-dhc-dhcpv4-vendor-message-01.txt - also took over Pasi's DISCUSS draft-ietf-dhc-dhcpv6-vendor-message-01.txt Old: draft-ietf-sipping-config-framework-17.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-mext-flow-binding-06.txt draft-ietf-keyprov-symmetrickeyformat-08.txt draft-ietf-keyprov-dskpp-11.txt draft-ietf-keyprov-pskc-06.txt New or recently updated (last 4 weeks): draft-gennai-smime-cnipa-pec-06.txt (some recent discussions with authors on proposed changes) draft-ietf-enum-enumservices-guide-20.txt draft-ogud-iana-protocol-maintenance-words-03.txt Cleared DISCUSSes: draft-ietf-netmod-yang-12.txt draft-lawrence-sipforum-user-agent-config-01.txt draft-ietf-csi-send-cert-03.txt draft-ietf-dhc-dhcpv6-opt-netboot-08.txt draft-ietf-sipcore-info-events-08.txt draft-ietf-enum-3761bis-09.txt draft-ietf-enum-enumservices-transition-06.txt draft-ietf-hip-hiccups-02.txt Other activities/actions: Done: - Sorting out Maastricht Agenda conflicts was a major undertaking this time. Both Peter and I spent lots of time on this. Ongoing: - verified/rejected several errata items (some of them incorrectly, as it turned out) - 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) - lots of discussions on standardization process in YAM WG and in IESG From alexey.melnikov@isode.com Tue Jul 13 03:10:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E6F3A67C3 for ; Tue, 13 Jul 2010 03:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3-09B1ncF-v for ; Tue, 13 Jul 2010 03:10:20 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 192FB3A68E8 for ; Tue, 13 Jul 2010 03:10:18 -0700 (PDT) Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 13 Jul 2010 11:10:25 +0100 Message-ID: <4C3C3B87.3040601@isode.com> Date: Tue, 13 Jul 2010 11:10:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020608010507060704030608" Subject: [apps-discuss] [Fwd: RFC 5802 on Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms] 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, 13 Jul 2010 10:10:24 -0000 This is a multi-part message in MIME format. --------------020608010507060704030608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Now, if we can deprecate Digest/DIGEST-MD5... --------------020608010507060704030608 Content-Type: message/rfc822; name="RFC 5802 on Salted Challenge Response Authentication Mechanism (SCRAM) SASLand GSS-API Mechanisms" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RFC 5802 on Salted Challenge Response Authentication Mechanism (SCRAM) SASLand GSS-API Mechanisms" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.6a3) with LMTP; Tue, 13 Jul 2010 05:26:01 +0100 (BST) Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Tue, 13 Jul 2010 05:26:00 +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 681513A6A1E; Mon, 12 Jul 2010 21:24:48 -0700 (PDT) X-Original-To: ietf-announce@core3.amsl.com Delivered-To: ietf-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26B13A6A21; Mon, 12 Jul 2010 21:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 OtLN6sFyCNc5; Mon, 12 Jul 2010 21:24:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 041D33A6A1D; Mon, 12 Jul 2010 21:24:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B1788E06C4; Mon, 12 Jul 2010 21:24:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5802 on Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms From: rfc-editor@rfc-editor.org Message-Id: <20100713042454.B1788E06C4@rfc-editor.org> Date: Mon, 12 Jul 2010 21:24:54 -0700 (PDT) Cc: sasl@ietf.org, rfc-editor@rfc-editor.org 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 A new Request for Comments is now available in online RFC libraries. RFC 5802 Title: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms Author: C. Newman, A. Menon-Sen, A. Melnikov, N. Williams Status: Standards Track Stream: IETF Date: July 2010 Mailbox: chris.newman@oracle.com, ams@toroid.org, Alexey.Melnikov@isode.com, Nicolas.Williams@oracle.com Pages: 28 Characters: 59049 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sasl-scram-11.txt URL: http://www.rfc-editor.org/rfc/rfc5802.txt The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS TRACK] This document is a product of the Simple Authentication and Security Layer Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------020608010507060704030608-- From yoshiro.yoneya@jprs.co.jp Thu Jul 15 07:26:25 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 270AF3A6A4A for ; Thu, 15 Jul 2010 07:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.813 X-Spam-Level: * X-Spam-Status: No, score=1.813 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 N1nHQMCSZYce for ; Thu, 15 Jul 2010 07:26:24 -0700 (PDT) Received: from send12.jprs.co.jp (send12.jprs.co.jp [202.11.17.106]) by core3.amsl.com (Postfix) with ESMTP id E631B3A6A10 for ; Thu, 15 Jul 2010 07:26:23 -0700 (PDT) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id o6FEQHwU000877; Thu, 15 Jul 2010 23:26:18 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id ED0533350; Thu, 15 Jul 2010 23:26:16 +0900 (JST) X-AuditID: ca0b1172-0000000700000914-88-4c3f1a882e20 Received: from NOTE233 (bxx0214.jprs.co.jp [172.18.4.44]) by sendsms12.jprs.co.jp (Symantec Mail Security) with SMTP id 51ED3334F; Thu, 15 Jul 2010 23:26:16 +0900 (JST) Date: Thu, 15 Jul 2010 23:26:14 +0900 From: Yoshiro YONEYA To: discuss@ietf.org, idna-update@alvestrand.no Message-Id: <20100715232614.1f7e9dea.yoshiro.yoneya@jprs.co.jp> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [apps-discuss] idnkit-2.0 released 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, 15 Jul 2010 14:26:25 -0000 Dear all, I'm very pleased to announce that JPRS has released idnkit-2.0 which is an implementation of IDNA2008, and it provides features IDN encoding conversion tool and APIs for application software. The idnkit-2.0 is available from following URL: The idnkit-2.0 implements IDNA2008 RFCs to be published as RFC 5890-5894, and also mapping methods specified by draft-resman-idna2008-mappings and Unicode Technical Report #46. I hope that the idnkit-2.0 is useful for IDN zone administrators, IDN site administrators, and IDNA2008 protocol designers. Please feel free to give your comments about the idnkit-2.0 to following e-mail address: Regards, -- Yoshiro YONEYA From alexey.melnikov@isode.com Thu Jul 15 16:20: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 2769B3A693F for ; Thu, 15 Jul 2010 16:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 z9QpefcWb7z3 for ; Thu, 15 Jul 2010 16:20:35 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E6B233A6A97 for ; Thu, 15 Jul 2010 16:20:34 -0700 (PDT) Received: from [172.16.2.135] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 16 Jul 2010 00:20:44 +0100 Message-ID: <4C3F97B9.7050101@isode.com> Date: Fri, 16 Jul 2010 00:20: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-Discuss@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070500010209000200090706" Subject: [apps-discuss] [Fwd: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard] 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, 15 Jul 2010 23:20:37 -0000 This is a multi-part message in MIME format. --------------070500010209000200090706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've decided to initiated IETF LC on the document, because I think the document is nearly done and outstanding issues can be addressed after IETF LC. --------------070500010209000200090706 Content-Type: message/rfc822; name="Last Call: draft-saintandre-tls-server-id-check (Representation and Verificationof Domain-Based Application Service Identity in Certificates Used with TransportLayer Security) to Proposed Standard" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Last Call: draft-saintandre-tls-server-id-check (Representation and Verificationof Domain-Based Application Service Identity in Certificates Used with TransportLayer Security) to Proposed Standard" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.6a3) with LMTP; Fri, 16 Jul 2010 00:08:46 +0100 (BST) Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Fri, 16 Jul 2010 00:08:46 +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 B88123A6BB4; Thu, 15 Jul 2010 16:08:23 -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 5B1583A6B94; Thu, 15 Jul 2010 16:08:22 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard Message-Id: <20100715230822.5B1583A6B94@core3.amsl.com> Date: Thu, 15 Jul 2010 16:08:22 -0700 (PDT) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org 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 received a request from an individual submitter to consider the following document: - 'Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-08-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18634&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------070500010209000200090706-- From eburger@standardstrack.com Fri Jul 16 14:20: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 158F13A6857 for ; Fri, 16 Jul 2010 14:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=-0.514, 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 TRXSnujYDyG4 for ; Fri, 16 Jul 2010 14:20:47 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id AE8BD3A6AD2 for ; Fri, 16 Jul 2010 14:20:47 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.187]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OZsKh-00026t-07; Fri, 16 Jul 2010 14:20:35 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Eric Burger In-Reply-To: Date: Fri, 16 Jul 2010 17:20:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <005b01cb1a5e$03d4b230$0b7e1690$@com> <4C2EE983.1020809@it.aoyama.ac.jp> To: Pablo Salomon X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Discuss IETF Apps Subject: Re: [apps-discuss] FWD: Sending personal files between web applications 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, 16 Jul 2010 21:20:49 -0000 This does sound a bit related to the problem solved by URLAUTH: the = ability to send a secure, time-limited reference to a remote object. On Jul 6, 2010, at 2:05 PM, Aaron Stone wrote: > On Sat, Jul 3, 2010 at 12:40 AM, "Martin J. D=FCrst" > wrote: >> On 2010/07/03 12:15, Pablo Salomon wrote: >>>=20 >>> Hi Aaron, >>>=20 >>>=20 >>>=20 >>> Oauth by itself does not allows a website to send a file to any = existing >>> or >>> future website that complies with Oauth. Oauth focuses on securely >>> granting >>> my authorization to another website's API but Website A needs to = implement >>> the specific Website B's API for uploading a file which can be = different >>> from Websites C,D,E, etc. The focus of my proposal is that there = should be >>> a >>> common way (or API) for such a basic task which is sending a file to >>> another >>> website. >=20 > The semantics of what it means to push a file from Site A to Site B > are necessarily defined by the two sites. Any protocol that's meant to > carry the file needs to be plugged into some code that implements the > semantics of what the site will do with that file. >=20 > WebDAV provides the semantics of "I want File X to appear at URL Y". > Web APIs provide deeper semantics like, "I want File X to become my > account profile icon." I have no idea how you'd standardize that. >=20 >> There may be no simple API to send (i.e. push) a file from one server = to >> another. There is however an API to get (i.e. pull) a file from one = server >> to another, indeed there are several, in particular HTTP and FTP. >> Website A only needs to make the file available at a specific URI = (/IRI). >> Website B then simply gets it from there. The whole thing can be = expressed >> with a simple URI (/IRI) without any additional information. >=20 > WebDAV provides a push API. I haven't been following OAuth closely > enough to know if someone is looking at how WebDAV would work with > OAuth. Off the cuff, I believe that it's as simple as publishing an > appropriate Authenticate / WWW-Authenticate header on a Not Authorized > response. http://oauth.net/core/1.0/#auth_header and letting the HTTP > bits sort themselves out. >=20 >> There may still be some missing pieces, but as a general guideline, = wherever >> you can pull, prefer it over push. >>=20 >> Regards, Martin. >>=20 >>> Another difference is that in Oauth typical scenarios the main = interaction >>> of the user remains with a single Website to which I give access to = other >>> Website's APIs. In order to give this access I may be redirected to = the >>> other Websites but after the authentication the user continues to = interact >>> with the original Website. >>>=20 >>>=20 >>>=20 >>> In the scenario I described in my original post, the user switches = to a >>> new >>> Website when he sends the file to it. >>>=20 >>>=20 >>>=20 >>> There are a couple of parallelism with the "Open with" feature on = the >>> popup >>> menu of a file on Windows Explorer: >>>=20 >>> 1. When Microsoft designed this feature it didn't anticipate all the >>> applications that could be listed in the "Open with" submenu and the = user >>> can even select any executable file as an open with target. In the >>> scenario >>> I described, when the user selects the attachment in Gmail he may be >>> presented with a list of popular "open with" or "send to" target = websites >>> but the user should have the option to select any website (that = complies >>> with this new standard) by typing its URL. >>>=20 >>> 2. When a user selects an application using the "open with" feature, = that >>> application opens up and becomes the foreground application which is = what >>> the user expects as he wants to keep working on the file with the = selected >>> application. The same is true for the sample scenario I described = when the >>> user sends his Gmail attachment to photoshop.com in order to edit = it. >=20 > (Responding to Pablo) >=20 > Oh! Ok, in this very limited use case, I definitely get where an "open > with" URL makes sense. The right layer for this might be a > microformat, or well-known-uri. >=20 > http://microformats.org/ >=20 > http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml >=20 > The underlying protocols would absolutely be HTTP and OAuth -- for = example: >=20 > = http://spreadsheets.example.com/openwith?uri=3Dhttp://mysite.example.com/m= ydoc.csv >=20 > You'd log into spreadsheets.example.com, then it looks at the openwith > arguments and pulls the file into the spreadsheet editor. If the file > is not protected, it loads right away. If the file is protected, the > OAuth dance proceeds. >=20 > Cheers, > Aaron > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Sat Jul 17 21:18: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 112EA3A687A for ; Sat, 17 Jul 2010 21:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-1.043, 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 lkkJmj9j3q1P for ; Sat, 17 Jul 2010 21:18:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4BA733A67B3 for ; Sat, 17 Jul 2010 21:18:26 -0700 (PDT) Received: from squire.local (dsl-228-115.dynamic-dsl.frii.net [216.17.228.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8E31D40E26 for ; Sat, 17 Jul 2010 22:18:38 -0600 (MDT) Message-ID: <4C42809C.5060007@stpeter.im> Date: Sat, 17 Jul 2010 22:18:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Peter's Apps Report #3 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, 18 Jul 2010 04:18:29 -0000 This is my third report as co-director (with Alexey Melnikov) of the IETF Applications Area. My apologies for the delay since my last report. This one covers June 4 through July 16, 2010. My next report will come out a week or two after IETF 78 in Maastricht. 1. WORKING GROUP STATUS Here are reports on the 9 working groups that I currently advise (Alexey advises the other 8 Apps Area WGs). 1.1. ALTO (Application-Layer Traffic Optimization) Chairs: Vijay Gurbani, Enrico Marocco, & Jon Peterson Website: http://tools.ietf.org/wg/alto/ Abstract: The ALTO WG is designing a technology for Application-Layer Traffic Optimization (ALTO), which will enable peer-to-peer applications to perform better-than-random initial peer selection. Report... New versions of both the requirements document and the protocol spec have been published since my last report: https://datatracker.ietf.org/doc/draft-ietf-alto-reqs/ https://datatracker.ietf.org/doc/draft-ietf-alto-protocol/ The group held a virtual interim meeting on June 16, which was a productive way to maintain the momentum between IETF 77 and IETF 78. Minutes are here: http://trac.tools.ietf.org/wg/alto/trac/wiki/Interim20100616 In other ALTO-related news: - WG co-chair Enrico Marocco authored an article for the IETF Journal (with P2PSIP WG co-chair David Bryan) on "The Peer-to-Peer Invasion" to bring more attention to the range of peer-to-peer work happening within the IETF. Visit http://www.isoc.org/tools/blogs/ietfjournal/?p=1746 for all the details. - The chairs have begun discussions about rechartering. I'll ping the chairs about that to see if we can present proposed text at IETF 78. - I've reviewed draft-irtf-p2prg-alto-survey ("A Survey on Research on the Application-Layer Traffic Optimization Problem") in accordance with the rules in RFC 5742 ("IESG Procedures for Handling of Independent and IRTF Stream Submissions"). The IESG did not find any conflicts between that document and IETF work, so it should go into the RFC Editor queue before too long. - The mailing list has been active with discussion about several of the non-WG items as well, including draft-song-alto-server-discovery and draft-lee-alto-chinatelecom-trial. - The authors of draft-stiemerling-alto-deployments will make a presentation to the Operations & Management Area Open Meeting as a way of getting feedback about ALTO deployment issues. The ALTO WG will be meeting in Maastricht, and the draft agenda is here: http://www.ietf.org/proceedings/78/agenda/alto.html 1.2. CALSIFY (Calendaring and Scheduling Standards Simplification) Chair: Eliot Lear Website: http://tools.ietf.org/wg/calsify/ Abstract: The CALSIFY WG is revising the Calendaring and Scheduling standards defined in RFC's 2445, 2446, and 2447. Report... As I mentioned last time, the only remaining work item is the iMIP draft: https://datatracker.ietf.org/doc/draft-ietf-calsify-rfc2447bis/ Alexey Melnikov has completed some edits based on my AD review and now we're waiting for input from other folks on the list. If you provided comments on this draft in the past, please check to make sure that it has been addressed so that the WG can finish the only remaining item on its charter. The CALSIFY WG won't meet in Maastricht. 1.3. CORE (Constrained RESTful Environments) Chairs: Carsten Bormann & Cullen Jennings Website: http://tools.ietf.org/wg/core/ Abstract: The CORE WG is defining a REST-style protocol for the manipulation of simple resources over constrained IP networks such as those used for sensor monitoring and device management applications. Report... The group has accepted one of the many CORE-related drafts as an official WG item: https://datatracker.ietf.org/doc/draft-ietf-core-coap/ List discussion has been quite lively and the group has been making good use of the issue tracker: http://trac.tools.ietf.org/wg/core/trac/report/6 True to the IETF philosophy of running code, some interested developers will hold a "plugfest" on the Sunday before the IETF meeting (July 25th) for testing and code debugging. Details here: http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest The CORE WG will be meeting in Maastricht, and the draft agenda is here: http://www.ietf.org/proceedings/78/agenda/core.txt 1.4. HTTPSTATE (HTTP State Management Mechanism) Chair: Jeff Hodges Website: http://tools.ietf.org/wg/httpstate/ Abstract: The HTTPSTATE WG is canonically specifying how cookies are actually used in existing HTTP implementations and deployments, thus obsoleting RFC 2109 and updating RFC 2965. Report... Since my last report, the group has completed a Working Group Last Call regarding the one spec on its current charter: https://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ All of the submitted issues have been closed but there was quite a bit of feedback during the WGLC (which continues in current mailing list threads), so I'd expect to see a revised I-D after IETF 78. The HTTPSTATE WG will be meeting in Maastricht, and the draft agenda is here: http://www.ietf.org/proceedings/78/agenda/httpstate.txt Notice that the agenda includes discussion about possible future work items, such as: - https://datatracker.ietf.org/doc/draft-pettersen-cookie-v2/ - https://datatracker.ietf.org/doc/draft-pettersen-cookie-origin/ - https://datatracker.ietf.org/doc/draft-pettersen-subtld-structure/ - https://datatracker.ietf.org/doc/draft-salgueiro-secure-state-management/ 1.5. IRI (Internationalized Resource Identifiers) Chairs: Marc Blanchet & Addison Philipps Website: http://tools.ietf.org/wg/iri/ Abstract: The IRI WG is revising the definition of Internationalized Resource Identifiers from RFC 3987. Report... The mailing list has been quiet but the IRI WG will meet in Maastricht. The chairs are working to identity the remaining issues and assign owners for those issues. Based on my conversations with the chairs, I would say that the issues are few but somewhat thorny, so expect some interesting discussions at IETF 78. The IRI WG will be meeting in Maastricht. Expect an agenda in the next few days. 1.6. OAUTH (Open Authentication Protocol) Chairs: Blaine Cook & Hannes Tschofenig Website: http://tools.ietf.org/wg/oauth/ Abstract: The OAUTH WG is defining the second iteration of an open protocol for delegating access to protected resources over the web. Report... Following up on the interim meeting held on May 20th, document editor Eran Hammer-Lahav has cranked out five subsequent versions of the group's core spec: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ List discussion has been extremely active, even overwhelming at times, but the group has been making good progress. The OAUTH WG will be meeting in Maastricht. Expect an agenda in the next few days. 1.7. PRECIS (Preparation and Comparison of Internationalized Strings) Chairs: Marc Blanchet & Yoshiro Yoneya Website: http://tools.ietf.org/wg/precis/ Abstract: The PRECIS WG is assessing whether a new method based on the IDNA2008 algorithmic approach is the appropriate path forward for existing stringprep (RFC 3454) usages as well as for other application protocols requiring internationalized strings. Report... This group formed based on strong consensus in the NEWPREP BoF at IETF 77 that the IETF needs to define more modern methods for the preparation and comparison of internationlized strings in application protocols. To jump-start discussion, WG co-chair Marc Blanchet has published two drafts: https://datatracker.ietf.org/doc/draft-blanchet-precis-problem-statement/ https://datatracker.ietf.org/doc/draft-blanchet-precis-framework/ Because it's never a good idea for the primary author to be chair of the WG, Marc, Yoneya-san, and I are actively seeking out editors for those specifications (and for the other deliverables on the group's charter). The PRECIS WG will hold its first meeting in Maastricht. Expect an agenda in the next few days. 1.8. VCARDDAV (vCard and CardDAV) Chairs: Marc Blanchet & Kurt Zeilenga Website: http://tools.ietf.org/wg/vcarddav/ Abstract: The VCARDDAV WG is revising the vCard standard from RFC 2426 and defining an XML representation of vCards. Report... The group has completed Working Group Last Call on its two remaining deliverables: - https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardrev/ - https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardxml/ Comments continue to trickle in and several open issues will be discussed at IETF 78. After that I would expect the authors to submit revised I-Ds and the chairs (at their discretion) to issue a second WGLC. The VCARDDAV WG will be meeting in Maastricht, and the draft agenda is here: http://www.ietf.org/proceedings/78/agenda/vcarddav.txt The final item on the agenda is discussion about whether to recharter the WG or to declare success and close down the WG. 1.9. VWRAP (Virtual World Region Agent Protocol) Chairs: Joshua Bell & Barry Leiba Website: http://tools.ietf.org/wg/vwrap/ Abstract: The VWRAP WG is defining a protocol that enables users to interact as digital representations in collaborative 3-dimensional virtual environments. Report... The group recently accepted 5 specs as WG items: https://datatracker.ietf.org/doc/draft-ietf-vwrap-authentication https://datatracker.ietf.org/doc/draft-ietf-vwrap-foundation https://datatracker.ietf.org/doc/draft-ietf-vwrap-intro https://datatracker.ietf.org/doc/draft-ietf-vwrap-launch https://datatracker.ietf.org/doc/draft-ietf-vwrap-type-system Unfortunately, Linden Lab, the prime mover behind the VWRAP effort, has cut back a bit on its standardization efforts: http://www.ietf.org/mail-archive/web/vwrap/current/msg00171.html However, other WG participants have maintained their involvement, as have several folks from Linden in their spare time (including co-chair Joshua Bell). And the mailing list has been active of late, too. So progress continues. The VWRAP WG will not be meeting in Maastricht. 2. BIRDS-OF-A-FEATHER (BOF) SESSIONS I'm the sponsoring AD for two BoFs at IETF 78: HASMAT and URNBIS. Given the amount of thought and energy that have gone into preparations for these BoFs, I'm confident that both of them will be quite successful. The HASMAT organizers held a pre-BoF conference call last week, which I thought was a productive way to introduce people to the topics that will be discussed in Maastricht. 3. INDIVIDUAL DRAFTS In addition to the WG items listed above, I'm also monitoring the following individual drafts: https://datatracker.ietf.org/doc/draft-desruisseaux-ischedule (I'll seek out the authors in Maastricht for further discussion) https://datatracker.ietf.org/doc/draft-giralt-schac-ns (I've pinged the authors several times about a revised I-D, but I haven't received a response yet) https://datatracker.ietf.org/doc/draft-hammer-hostmeta (this one is in IETF Last Call, and a security directorate review has been completed) https://datatracker.ietf.org/doc/draft-oiwa-http-mutualauth (I am still slowly providing comments to the authors) https://datatracker.ietf.org/doc/draft-rosen-urn-nena (a revised I-D will be submitted after the blackout period, after which I'll work with the author and document shepherd to move this forward) https://datatracker.ietf.org/doc/draft-snell-atompub-link-extensions/ (the author is working to find a document shepherd) https://datatracker.ietf.org/doc/draft-snell-atompub-tombstones/ (the author is working to find a document shepherd) 4. MY DRAFTS Now that I'm an area director I understand why ADs don't write many specs during their term of duty -- they're too busy! However, I have a few Internet-Drafts to finish up, and they're taking quite a bit of time and energy. Specifically: https://datatracker.ietf.org/doc/draft-ietf-xmpp-3920bis/ has undergone a WGLC within the XMPP WG in the RAI area, and I processed a lot of issues: http://trac.tools.ietf.org/wg/xmpp/trac/report/6 A second WGLC is underway to make sure that all feedback has been addressed. https://datatracker.ietf.org/doc/draft-ietf-xmpp-address/ has undergone a WGLC as well (it goes along with 3920bis) and I still have a few comments to process. https://datatracker.ietf.org/doc/draft-ietf-xmpp-3921bis/ is currently in WGLC, too. No feedback yet on the xmpp@ietf.org list, but I'm sure it's on the way. https://datatracker.ietf.org/doc/draft-saintandre-tls-server-id-check/ is currently in IETF Last Call and I know that Jeff Hodges and I have a few issues to address for that one. Both draft-ietf-xmpp-3920bis and draft-daboo-srv-email depend on the server-id-check document, so Jeff and I want to finish it as soon as possible. Finally I recently wrote two short specs to spark some discussion in the applications area: - https://datatracker.ietf.org/doc/draft-saintandre-xdash-considered-harmful/ - https://datatracker.ietf.org/doc/draft-barnes-hard-problem/ (with Richard Barnes) That's way too many I-Ds for me to process with everything else I have going on (and two of them are over 100 pages long!), so I'm working to finish them off as quickly as possible to free up more time and energy for my Area Director responsibilities. 5. IESG ACTIVITIES I posted DISCUSSes on the following documents during IESG review: draft-freed-sieve-notary draft-ietf-bmwg-protection-term draft-ietf-eai-mailinglist draft-ietf-enum-enumservices-guide draft-ietf-hip-hiccups draft-ietf-netconf-monitoring draft-ietf-pkix-certimage draft-keromytis-tls-authz-keynote draft-kucherawy-authres-header I also posted COMMENTs on: draft-hoffman-tls-master-secret-input draft-ietf-dnsext-dns-tcp-requirements draft-ietf-nsis-tunnel draft-ietf-sipping-rtcp-summary draft-ietf-smime-cms-rsa-kem draft-josefsson-kerberos5-starttls I still have unresolved DISCUSSes lodged against the following I-Ds: draft-ietf-eai-mailinglist draft-ietf-enum-enumservices-guide draft-ietf-keyprov-dskpp draft-ietf-mediactrl-ivr-control-package draft-ietf-mediactrl-mixer-control-package draft-ietf-mediactrl-sip-control-framework draft-ietf-pkix-certimage draft-ietf-sipcore-info-events draft-ietf-sipping-config-framework Hopefully we can get some of those resolved at IETF 78 (or before). 6. UPCOMING EVENTS The only upcoming event of note is IETF 78, July 25-30 in Maastricht, The Netherlands. I'll be arriving on Saturday the 24th and departing on Sunday August 1st along with the rest of the IESG and IAB for a one-day management meeting with the ITU-T in Geneva on August 2nd. If you have any questions or concerns about the working groups I advise, specific Internet-Drafts, DISCUSSes I've lodged, possible future BoFs, coordination with other standards development organizations, or any other topic of interest, feel free to seek me out in Maastricht during the "Hallway WG" or to contact me beforehand so we can arrange a time to chat. See you in Maastricht! Peter -- Peter Saint-Andre https://stpeter.im/ From alexey.melnikov@isode.com Sun Jul 18 11:06:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBC13A6925 for ; Sun, 18 Jul 2010 11:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.391, 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 yGTqAJzj+YX6 for ; Sun, 18 Jul 2010 11:06:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 55C203A6890 for ; Sun, 18 Jul 2010 11:06:14 -0700 (PDT) Received: from [188.28.56.135] (188.28.56.135.threembb.co.uk [188.28.56.135]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 18 Jul 2010 19:06:25 +0100 Message-ID: <4C43427F.1020106@isode.com> Date: Sun, 18 Jul 2010 19:05:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Missing Agendas for Maastricht WG/BOF meetings 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, 18 Jul 2010 18:06:15 -0000 IRI OAUTH SIEVE YAM URNBIS (BOF) From alexey.melnikov@isode.com Mon Jul 19 08:37:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359413A688F for ; Mon, 19 Jul 2010 08:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 tGCTRK1+DAd5 for ; Mon, 19 Jul 2010 08:37:13 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4B3623A6842 for ; Mon, 19 Jul 2010 08:37:13 -0700 (PDT) Received: from [172.16.2.180] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 19 Jul 2010 16:37:04 +0100 Message-ID: <4C4470FC.6060308@isode.com> Date: Mon, 19 Jul 2010 16:36:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050109020806090504030601" Subject: [apps-discuss] Proposal to form an Apps Area-wide Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:37:15 -0000 This is a multi-part message in MIME format. --------------050109020806090504030601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Your Applications Area Directors have been thinking about the possibility of forming an area-wide working group similar to those for the internet (INTAREA), routing (RTGWG), transport (TSVWG), and operations (OPSAWG) areas. Here is our motivation for doing that: Problem Statement: Applications ADs receive a big number of individual submissions not related to any of the Apps WG or explicitly out of scope for them. In many cases documents would benefit from wider review, however creation of new WGs might be too heavyweight to deal with such documents. Also, historically sponsoring an individual submissions caused more troubles for sponsoring ADs (and thus consumed more AD time as a result) than sponsoring WG documents. This is partially due to the time spent finding the right reviewers and dealing with IETF LC feedback in presence of "lack of consensus" claims. So Apps ADs are basically stuck between asking for a BOF/WG creation (i.e. pushing all work for the authors/editors), refusing to sponsor publication of a document and sponsoring individual submissions. Your Applications AD are thinking that it would be useful to have another tool in our toolbox, such as the Area-wide WG. Note, that there is no intention to deprecate use of individual submissions, or to require that all individual submissions go through this new WG. At the IESG retreat in May we received input from our fellow ADs regarding best practices for such groups, and as a result we have created a draft charter for discussion in Maastricht. We realize that forming an area-wide working group is not a step to be taken lightly, so we would appreciate it if folks on this list could review and think about the draft charter between now and IETF 78, then come to the Apps Area Open Meeting on Monday morning with your ideas, criticisms, and suggestions for improvement. We would appreciate if people delay posting comments on this subject until after the Apps Area meeting in Maastricht (on July 26th). But private comments to Peter and myself about whether you think this is a stupid or a good idea would always be appreciated. Best Regards, Peter and Alexey --------------050109020806090504030601 Content-Type: text/plain; name="appsawg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="appsawg.txt" Applications Area Working Group (APPSAWG) The Applications Area sometimes receives proposals for the development of specifications dealing with application-related topics that are not in scope for an existing working group and do not justify the formation of a new working group. The Applications Area Working Group (APPSAWG) serves as a forum for such work in the IETF. The APPSAWG accepts work items in accordance with the consensus of the group and the best judgment of the Applications Area Directors, who are responsible for updating the working group milestones as needed. The working group meets if there are active proposals that require intensive discussion. Work items that are appropriate for the APPSAWG mostly fall under the following topics: (A) Well-defined security issues that are relevant to multiple application technologies (e.g., draft-saintandre-tls-server-id-check). (B) Small-scale additions to the protocol stack for HTTP and other application technologies, mostly related to service discovery and meta-data (e.g., RFC 5785, draft-nottingham-http-link-header, and draft-hammer-hostmeta). (C) Selected other work items addressing topics that historically fall within the Applications Area, such as calendaring, date and time formats, FTP, HTTP, internationalization, language tags, MIME, URIs, URNs, and XML. When considering whether to accept a proposed work item, the APPSAWG and the Applications Area Directors shall take into account the following factors, among others: (1) Whether the WG has consensus on the suitability, importance, and projected quality of the proposed work item. (2) Whether there is core team of WG participants with sufficient energy and expertise to advance the proposed work item according to the proposed schedule. (3) Whether there are enough WG participants who are willing to review the work produced by the document authors or editors. (4) Whether the Area Directors judge that wider input is needed before accepting the proposed work item (e.g., from the IESG, IAB, or another standards development organization). --------------050109020806090504030601-- From alexey.melnikov@isode.com Mon Jul 19 08:42:38 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08C83A6937 for ; Mon, 19 Jul 2010 08:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 EyDytVBUR2y5 for ; Mon, 19 Jul 2010 08:42:37 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5CFAB3A6922 for ; Mon, 19 Jul 2010 08:42:37 -0700 (PDT) Received: from [172.16.2.180] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 19 Jul 2010 16:42:51 +0100 Message-ID: <4C447257.6090700@isode.com> Date: Mon, 19 Jul 2010 16:42:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Draft agenda for the Apps Area Open Meeting 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, 19 Jul 2010 15:42:38 -0000 Applications Area Open Meeting, Monday, 26 July, 2010 9:00 to 11:30 CET (8:00 to 10:30 UTC) 0:00-0:02 Agenda bashing (all) 0:02-0:05 NomCom announcement (3 mins) 0:05-0:15 Quick demonstration of IETF datatracker (10 mins) 0:15-0:25 Errata processing for Apps Area RFCs (10 mins) 0:25-0:40 BOF announcements (5 mins each) HASMAT URNBIS FTPEXT2 0:40-0:45 "IDNA2008 implementation" [Yoshiro Yoneya] (5 mins) 0:45-1:00 "HTTP Timeouts" [Martin Thomson] (15 mins) [1] 1:00-1:15 Presentation about Email privacy (15 mins) 1:15-1:35 "Name Based Sockets" [Javier Ubillos] (20 mins) [2] 1:35-1:45 "Deprecating Unicode Language Tag Characters: RFC 2482 is Historic" [John Klensin] (10 mins) [3] 1:45-2:15 APPSAWG charter discussion (30 mins) Any other business (time permitting) [1] http://www.ietf.org/id/draft-loreto-http-timeout-00.txt [2] http://www.ietf.org/id/draft-ubillos-name-based-sockets-01.txt [3] http://www.ietf.org/id/draft-presuhn-rfc2482-historic-02.txt From alexey.melnikov@isode.com Mon Jul 19 09:27: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 446BA3A68C5 for ; Mon, 19 Jul 2010 09:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 OMTmwnssLiPM for ; Mon, 19 Jul 2010 09:27:42 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 394EB3A693E for ; Mon, 19 Jul 2010 09:27:42 -0700 (PDT) Received: from [172.16.2.180] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 19 Jul 2010 17:27:56 +0100 Message-ID: <4C447CE2.7090609@isode.com> Date: Mon, 19 Jul 2010 17:27:14 +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 References: <4C4470FC.6060308@isode.com> In-Reply-To: <4C4470FC.6060308@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Proposal to form an Apps Area-wide Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:27:43 -0000 I wasn't quite clear on the fact that neither Peter not I have any intent to chair this proposed WG. From patrik@frobbit.se Thu Jul 22 01:10:38 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98D13A63D3 for ; Thu, 22 Jul 2010 01:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkPqsP5XteIR for ; Thu, 22 Jul 2010 01:10:37 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 6B1D13A681F for ; Thu, 22 Jul 2010 01:10:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 61676CBCB06E; Thu, 22 Jul 2010 10:10:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjGoghknIYcP; Thu, 22 Jul 2010 10:10:52 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 094AFCBCB064; Thu, 22 Jul 2010 10:10:52 +0200 (CEST) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-320-831340575" Content-Transfer-Encoding: 7bit Date: Thu, 22 Jul 2010 10:10:51 +0200 Message-Id: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v1081) X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: IAB IAB Subject: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 22 Jul 2010 08:10:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-320-831340575 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 IETF has received the following liaison: https://datatracker.ietf.org/liaison/903/ We need someone that can write a response to the liaison. I can help = with formalities. Patrik F=E4ltstr=F6m Liaison from IETF to ITU-T P.S. My personal very quick reading of the liaison and related documents = together with Olaf Kolkman (as IAB chair) gave: Patrik wrote: > Olaf wrote: >> I've skimmed the doc. >>=20 >> - I observe slightly different RCODE semantics in 5.2.6 >> - I also observe that the service name chosen doesn't seem to = followhttp://tools.ietf.org/html/rfc4848#section-4.5 but I may be = misreading something here? >>=20 >>=20 >> The higher level question is what is the IETF action here? Any IANA = registration needed? Do we need to review DDDS formally? >=20 > Yes, some action is needed. And the way I read the documents, an RFC = is needed: > http://tools.ietf.org/html/rfc3958#section-7 >=20 > At least one that references the ITU-T document according to the = normal referencing mechanisms agreed upon. >=20 >> Who takes has the token for determining next actions? >=20 > I think IAB should try to find someone that can do a more detailed = review than what I here has done. >=20 >> 6.2.1 These requirements are placed on the .oid-res.org = operational agency (and recursively on all DNS zone files in the = .oid-res.org domain. >=20 > If this is an ISO/ITU "formal" namespace "thing", I think the domain = should go in .ARPA. >=20 >> 6.3.1.3 >> The DNAME resource record shall be preceded by: >> a) the Unicode label on the arc to that child transformed as = specified in IETF RFC 3490, section 4.1, including case folding (see = IETF RFC 3454) and punycode encoding (see IETF RFC 3492) using the = Compatibility Decomposition followed by Canonical Composition (NFKC) = specified by Unicode 5.2, Annex 15; then >=20 > They should do something new here, following the newprep work in the = IETF. 3490 etc are (on their way to be) obsolete. >=20 > Patrik --Apple-Mail-320-831340575 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMR/0LrMabGguI180RAotzAJ4mSz+4Y6MXKSJsz032YO7jRE6qdQCfeYIe 19+K8HiTZ2AgATv41Z8TN0w= =R4qa -----END PGP SIGNATURE----- --Apple-Mail-320-831340575-- From paf@frobbit.se Thu Jul 22 01:20:41 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 E075A3A677C for ; Thu, 22 Jul 2010 01:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeabQHNKmGWr for ; Thu, 22 Jul 2010 01:20:41 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 6F21A3A69CF for ; Thu, 22 Jul 2010 01:20:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id F19ACCBCC8E8 for ; Thu, 22 Jul 2010 10:20:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT+rMObc5c8l for ; Thu, 22 Jul 2010 10:20:56 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id AE4F3CBCC8DF for ; Thu, 22 Jul 2010 10:20:56 +0200 (CEST) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-321-831945623" Content-Transfer-Encoding: 7bit Date: Thu, 22 Jul 2010 10:20:56 +0200 Message-Id: To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v1081) X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Thu, 22 Jul 2010 08:26:37 -0700 Subject: [apps-discuss] How to find a service? 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, 22 Jul 2010 08:20:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-321-831945623 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We have had various discussions during the years on "how to find a = service". And we have many ways of doing it at the moment. For example: - Just use a well known algorithm - Look up A or AAAA record, and then use well known port number - Look up MX, and then A/AAAA and use well known port number - Look up SRV record, and use that hostname and port number - Use a DDDS algorithm as defined somewhere - Use mdns like services to "broadcast" information (or respond to = broadcast queries) - : - : ...and many more... Now we have other ways as well, like the two currently proposed = mechanisms that some people have seen discussed on the IETF list: - What is described in draft-daboo-srv-caldav, which I in a sloppy way = describe as "use SRV records and then a well known path that should = result in an HTTP redirect" - What is described in draft-faltstrom-uri, which I in a sloppy way = describe as "use URI records like we use SRV records, but get a full URI = back" As we are so close to Maastricht, I do not find we have time for a = doodle regarding interested parties that want to talk about this. I have therefore decided we meet on Wednesday July 28 at 08:00 (yes, for = a breakfast meeting). It will be by the IETF registration/announcement = board, OR, where a note on that very same announcement board says. I = guess it will be near or even where breakfast is served... I am deliberately sending this only to Apps Discuss as I think we should = start this discussion from the point of view of "the need applications = has". That said, please spread the word to other interested parties. It = is not supposed to be a "secret cabal meeting". I envision a mailing list discussion after this first meeting. Patrik --Apple-Mail-321-831945623 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMR/9orMabGguI180RAtyIAJ0XuUa7nviX/77QmigF+hAp4FAINQCfdd5M YBgEZ6hX4Qv8Y/276AZwQBE= =ckbc -----END PGP SIGNATURE----- --Apple-Mail-321-831945623-- From patrik@frobbit.se Thu Jul 22 08:44:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD0C3A6BA2 for ; Thu, 22 Jul 2010 08:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxr+vwkfL72Y for ; Thu, 22 Jul 2010 08:44:45 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 5AF013A6814 for ; Thu, 22 Jul 2010 08:44:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 2C630CBE5216 for ; Thu, 22 Jul 2010 17:44:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3jbmJlUVK8S for ; Thu, 22 Jul 2010 17:44:57 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id D6D62CBE520E for ; Thu, 22 Jul 2010 17:44:57 +0200 (CEST) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-346-858586825" Mime-Version: 1.0 (Apple Message framework v1081) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Thu, 22 Jul 2010 17:44:57 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3FA99C66-4175-4A70-8EFB-AF2D8DEA5F74@frobbit.se> References: To: Apps Discuss X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Subject: Re: [apps-discuss] How to find a service? 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, 22 Jul 2010 15:44:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-346-858586825 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ok, there is a confusion regarding the breakfast...no breakfast at the = MECC says the hotel info, but on the agenda I saw: > 0800-0900 Beverages - Trajectum Lobby I interpreted that as "breakfast". My call is still to have the meeting 8-9AM Wednesday, but there will not = be breakfast... Patrik On 22 jul 2010, at 10.20, Patrik F=E4ltstr=F6m wrote: > We have had various discussions during the years on "how to find a = service". And we have many ways of doing it at the moment. For example: >=20 > - Just use a well known algorithm > - Look up A or AAAA record, and then use well known port number > - Look up MX, and then A/AAAA and use well known port number > - Look up SRV record, and use that hostname and port number > - Use a DDDS algorithm as defined somewhere > - Use mdns like services to "broadcast" information (or respond to = broadcast queries) > - : > - : >=20 > ...and many more... >=20 > Now we have other ways as well, like the two currently proposed = mechanisms that some people have seen discussed on the IETF list: >=20 > - What is described in draft-daboo-srv-caldav, which I in a sloppy way = describe as "use SRV records and then a well known path that should = result in an HTTP redirect" >=20 > - What is described in draft-faltstrom-uri, which I in a sloppy way = describe as "use URI records like we use SRV records, but get a full URI = back" >=20 >=20 > As we are so close to Maastricht, I do not find we have time for a = doodle regarding interested parties that want to talk about this. >=20 > I have therefore decided we meet on Wednesday July 28 at 08:00 (yes, = for a breakfast meeting). It will be by the IETF = registration/announcement board, OR, where a note on that very same = announcement board says. I guess it will be near or even where breakfast = is served... >=20 > I am deliberately sending this only to Apps Discuss as I think we = should start this discussion from the point of view of "the need = applications has". That said, please spread the word to other interested = parties. It is not supposed to be a "secret cabal meeting". >=20 > I envision a mailing list discussion after this first meeting. >=20 > Patrik >=20 --Apple-Mail-346-858586825 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMSGd5rMabGguI180RAmNGAJ46/MIy1XSWAZXgP8Wc/3fzpUEsGACfRV7z XEw+oidGjAvhSAf4JSnlDJ0= =mWS3 -----END PGP SIGNATURE----- --Apple-Mail-346-858586825-- From randy_presuhn@mindspring.com Thu Jul 22 19:20:41 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 02D493A68DF; Thu, 22 Jul 2010 19:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[AWL=-1.032, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nKOtbLZpvQB; Thu, 22 Jul 2010 19:20:40 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2EC703A6888; Thu, 22 Jul 2010 19:20:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Iv5e6rRy3KIuj1ZvdDkKdmt/1wIyIM15URjMATNrROPqKmXaDKDVWT3BfolSp0UN; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.27.167] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Oc7sf-0004tj-50; Thu, 22 Jul 2010 22:20:57 -0400 Message-ID: <006001cb2a0e$10f82e00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Apps Discuss" References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> Date: Thu, 22 Jul 2010 19:23:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035d00b711b586872a361095411ecdd331c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.27.167 Cc: IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 23 Jul 2010 02:20:41 -0000 Hi - > From: "Patrik Fältström" > To: "Apps Discuss" > Cc: "IAB IAB" > Sent: Thursday, July 22, 2010 1:10 AM > Subject: [apps-discuss] Review of liaison from ITU-T regarding OIDs --volunteer needed! ... Has anyone thought through how this would (not) work for OIDs as they are (ab)used in SNMP-land? Those OIDs aren't defined in ASN.1 modules (though the SMI notation is historically related to ASN.1, it is most emphatically NOT ASN.1) and SNMP generates things with OBJECT IDENTIFIER syntax which won't appear in a definition anywhere. (Think how table indexing looks on the wire.) Randy From patrik@frobbit.se Thu Jul 22 19:24: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 605A63A6985 for ; Thu, 22 Jul 2010 19:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKN9WauKLBzr for ; Thu, 22 Jul 2010 19:24:51 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id BF1CA3A6924 for ; Thu, 22 Jul 2010 19:24:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 3CE78CC07DFC; Fri, 23 Jul 2010 04:25:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZF9-1MqSUlH2; Fri, 23 Jul 2010 04:25:06 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id CE52BCC07DF1; Fri, 23 Jul 2010 04:25:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-364-896995749" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Priority: 3 In-Reply-To: <006001cb2a0e$10f82e00$6801a8c0@oemcomputer> Date: Fri, 23 Jul 2010 04:25:06 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2433243F-CF35-4872-843C-0E38F6396306@frobbit.se> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <006001cb2a0e$10f82e00$6801a8c0@oemcomputer> To: Randy Presuhn X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 23 Jul 2010 02:24:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-364-896995749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 23 jul 2010, at 04.23, Randy Presuhn wrote: > Hi - >=20 >> From: "Patrik F=E4ltstr=F6m" >> To: "Apps Discuss" >> Cc: "IAB IAB" >> Sent: Thursday, July 22, 2010 1:10 AM >> Subject: [apps-discuss] Review of liaison from ITU-T regarding OIDs = --volunteer needed! > ... >=20 > Has anyone thought through how this would (not) work for OIDs > as they are (ab)used in SNMP-land? No. We need help here as you understand, and you might obviously be one that = helps...at least with a fraction of text. Patrik > Those OIDs aren't defined in ASN.1 modules (though the SMI notation > is historically related to ASN.1, it is most emphatically NOT ASN.1) = and > SNMP generates things with OBJECT IDENTIFIER syntax which > won't appear in a definition anywhere. (Think how table indexing > looks on the wire.) >=20 > Randy >=20 >=20 >=20 --Apple-Mail-364-896995749 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMSP2CrMabGguI180RAh0BAKCEif/xhSQ0h/0cckGNd+XhkMwd/gCaA8Mz c6Q+pM7fpAkLQqWKGmiGXTk= =M5YU -----END PGP SIGNATURE----- --Apple-Mail-364-896995749-- From Nicolas.Williams@oracle.com Thu Jul 22 21:47:41 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 447563A68A5 for ; Thu, 22 Jul 2010 21:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJWLJxH8T9Jz for ; Thu, 22 Jul 2010 21:47:40 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 291123A67FE for ; Thu, 22 Jul 2010 21:47:40 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6N4luxh016544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Jul 2010 04:47:57 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6MCt2S6012812; Fri, 23 Jul 2010 04:47:54 GMT Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 429780781279860367; Thu, 22 Jul 2010 21:46:07 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 21:46:06 -0700 Date: Thu, 22 Jul 2010 23:46:47 -0500 From: Nicolas Williams To: Randy Presuhn Message-ID: <20100723044646.GH27130@oracle.com> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <006001cb2a0e$10f82e00$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006001cb2a0e$10f82e00$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C491EFB.011D:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 23 Jul 2010 04:47:41 -0000 On Thu, Jul 22, 2010 at 07:23:39PM -0700, Randy Presuhn wrote: > Has anyone thought through how this would (not) work for OIDs > as they are (ab)used in SNMP-land? > > Those OIDs aren't defined in ASN.1 modules (though the SMI notation > is historically related to ASN.1, it is most emphatically NOT ASN.1) and > SNMP generates things with OBJECT IDENTIFIER syntax which > won't appear in a definition anywhere. (Think how table indexing > looks on the wire.) SNMP is hardly the only place where we use OIDs that don't get defined in ASN.1 modules. The smi-numbers registry is full of such OIDs. I don't think the problem lies in having OIDs not defined in ASN.1 modules. If an OID is not useable in an ASN.1 module (e.g., GSS-API mechanism OIDs) then having an ASN.1 module just to define it would add little value, except, perhaps, as a structured registration entry documentation format for IANA. Which brings me to... What would be really nice is a DNS-like method of resolving OIDs, so that then IANA can participate in a more structured way. Failing that, or even besides that, maybe an IANA API would be nice. Nico -- From patrik@frobbit.se Thu Jul 22 22:58:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A792A3A68B1 for ; Thu, 22 Jul 2010 22:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRxiY9a83z7c for ; Thu, 22 Jul 2010 22:58:19 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 30B753A6843 for ; Thu, 22 Jul 2010 22:58:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id E7E83CC11061; Fri, 23 Jul 2010 07:58:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duJ26FDnUqi9; Fri, 23 Jul 2010 07:58:35 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id A6F2ACC11059; Fri, 23 Jul 2010 07:58:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-375-909804474" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100723044646.GH27130@oracle.com> Date: Fri, 23 Jul 2010 07:58:34 +0200 Content-Transfer-Encoding: 7bit Message-Id: <43A2952C-20A3-47AC-9AE6-0F8D24FC505B@frobbit.se> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <006001cb2a0e$10f82e00$6801a8c0@oemcomputer> <20100723044646.GH27130@oracle.com> To: Nicolas Williams X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 23 Jul 2010 05:58:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-375-909804474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 jul 2010, at 06.46, Nicolas Williams wrote: > Which brings me to... What would be really nice is a DNS-like method = of > resolving OIDs, so that then IANA can participate in a more structured > way. Failing that, or even besides that, maybe an IANA API would be > nice. That is basically what they want to do, right? In IETF we have the DDDS algorithm that is in use for E.164 numbers, and = similar mechanism is used for RFID tags by ONS that ECDS has defined. So yes, that could be interesting. And I think we IETF can do something = here. And because of that, yes, they might walk into "our turf". But the question is what to tell ITU. 1. That they of course can work with this 2. That IETF thought OIDs in reality is an ISO thing, not ITU thing 3. That IETF is the SDO where DNS, and DNS like mechanisms are discussed 4. That we have a history of good cooperation between ITU and IETF = regarding for example ENUM 5. That IETF is happy to do (is doing?) a resolution mechanism from OIDs = to something else using DNS. The trouble is maybe how to formulate 5? Patrik --Apple-Mail-375-909804474 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMSS+LrMabGguI180RAuZrAJ9rU0st6o4nVYMWQg6uODBP+OLTLACcCFnI IdDoZCngFsv05A9sS/EDmU4= =loIK -----END PGP SIGNATURE----- --Apple-Mail-375-909804474-- From klensin@jck.com Fri Jul 23 02:55: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 736A33A6A17; Fri, 23 Jul 2010 02:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuFEpUP7upqD; Fri, 23 Jul 2010 02:55:15 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 100C43A6784; Fri, 23 Jul 2010 02:55:15 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OcEyV-000As4-96; Fri, 23 Jul 2010 05:55:27 -0400 Date: Fri, 23 Jul 2010 05:55:26 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Nicolas Williams Message-ID: <3E488AEAD1F240B208BF745E@PST.JCK.COM> In-Reply-To: <43A2952C-20A3-47AC-9AE6-0F8D24FC505B@frobbit.se> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <006001cb2a0e$10f82e00$6801a8c0@oemcomputer> <20100723044646.GH27130@oracle.com> <43A2952C-20A3-47AC-9AE6-0F8D24FC505B@frobbit.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 23 Jul 2010 09:55:16 -0000 --On Friday, July 23, 2010 07:58 +0200 Patrik = F=C3=A4ltstr=C3=B6m wrote: > That is basically what they want to do, right? >=20 > In IETF we have the DDDS algorithm that is in use for E.164 > numbers, and similar mechanism is used for RFID tags by ONS > that ECDS has defined. >=20 > So yes, that could be interesting. And I think we IETF can do > something here. And because of that, yes, they might walk into > "our turf". >=20 > But the question is what to tell ITU. >=20 > 1. That they of course can work with this >=20 > 2. That IETF thought OIDs in reality is an ISO thing, not ITU > thing Clarification: OIDs came out of one of the "ISO/IEC - ITU Joint Development Agreement" projects. The relevant standards have both ISO/IEC [JTC1] numbers and ISO numbers. And there are allocation arcs, separately, for both. Indeed, one of the questions we would have to sort out with ITU is whether ISO is on board or whether this is really a proposal about the ITU arc only. =20 > 3. That IETF is the SDO where DNS, and DNS like mechanisms are > discussed >=20 > 4. That we have a history of good cooperation between ITU and > IETF regarding for example ENUM Well... :-( > 5. That IETF is happy to do (is doing?) a resolution mechanism > from OIDs to something else using DNS. Wouldn't one set of sub-arcs of OIDs be more accurate here? > The trouble is maybe how to formulate 5? john From patrik@frobbit.se Fri Jul 23 03:06:04 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FCA3A6A10 for ; Fri, 23 Jul 2010 03:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTwcDVLofdgd for ; Fri, 23 Jul 2010 03:06:03 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id BFF3C3A6A56 for ; Fri, 23 Jul 2010 03:06:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id AB7DCCC20A1A; Fri, 23 Jul 2010 12:06:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltRabAbqJQUh; Fri, 23 Jul 2010 12:06:19 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 2BBE3CC20A0E; Fri, 23 Jul 2010 12:06:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-390-924667893" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <3E488AEAD1F240B208BF745E@PST.JCK.COM> Date: Fri, 23 Jul 2010 12:06:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: <762BF59D-C133-45A8-86D1-784DFD875AD5@frobbit.se> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <006001cb2a0e$10f82e00$6801a8c0@oemcomputer> <20100723044646.GH27130@oracle.com> <43A2952C-20A3-47AC-9AE6-0F8D24FC505B@frobbit.se> <3E488AEAD1F240B208BF745E@PST.JCK.COM> To: John C Klensin X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 23 Jul 2010 10:06:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-390-924667893 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 23 jul 2010, at 11.55, John C Klensin wrote: >> 5. That IETF is happy to do (is doing?) a resolution mechanism >> from OIDs to something else using DNS. > > Wouldn't one set of sub-arcs of OIDs be more accurate here? Maybe, but why have IETF do something that can take care of the whole tree? Only a sub-arc might be populated. Something like this Harald has already today: http://www.alvestrand.no/objectid/ Patrik --Apple-Mail-390-924667893 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMSWmarMabGguI180RAn5zAJ9dW+lCGZ7LFrni0C11rA/xSBQV1gCggYT6 8dz5aacss3ITx7qHURXXpqk= =nKRw -----END PGP SIGNATURE----- --Apple-Mail-390-924667893-- From romeda@gmail.com Fri Jul 23 07:37:41 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 93CC73A68B6 for ; Fri, 23 Jul 2010 07:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvlWykdmBgje for ; Fri, 23 Jul 2010 07:37:40 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 7218A3A682F for ; Fri, 23 Jul 2010 07:37:40 -0700 (PDT) Received: by qwe5 with SMTP id 5so331933qwe.31 for ; Fri, 23 Jul 2010 07:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=MnwzZ068HpMJPrXHOjdNh+olI65wNx68uS8Yd3YOZ0M=; b=uGwgWw/Y3zwVaYPcOlDVXTMoNK7rglH3FVzblU+DnEdDfDKbX/Aed413GGnVevSu7o 69GgH97p0LpxMeA5dRMfS+AO8Yo7FHo78gYfqIvj6/iOY2bI1pDE2OlhASyfMxkE721W eE/kFIUyLYUCDV/mh+PuxV9kP1QKXIENGkf9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=bO/gIbUBFIJQK1vxw/JDhp4LkRAZYHQ7zLJtmlw9xhOIfihJnQd1CNQibrhYEVKCue GoIJ1g3NOq1KCuiCzaoM7x9Dk73mi0AYApP31v752nOPSaZO9emEQpFHWKTuVNCypRRk lULhrVkN0B3+W0mRipZ3P3h4xetw0DM9oZpOk= Received: by 10.224.29.1 with SMTP id o1mr499513qac.202.1279895877383; Fri, 23 Jul 2010 07:37:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.38.132 with HTTP; Fri, 23 Jul 2010 07:37:36 -0700 (PDT) In-Reply-To: <4C2CBFA8.10001@stpeter.im> References: <4C2CBFA8.10001@stpeter.im> From: Blaine Cook Date: Fri, 23 Jul 2010 15:37:36 +0100 Message-ID: To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 23 Jul 2010 14:37:41 -0000 Sneaking in under the wire with these comments, which I'm sure will exact punishment from Eran at some later point (though I have made these comments unofficially in other venues). I strongly disagree with the processing model for LRDD proposed in Section 4.2 of draft-hammer-hostmeta-13. The model amounts to a client-side approach to template processing. I believe this will lead to inconsistent (i.e., non-interoperable) results across client implementations, is harder to implement for client developers, and adds complexity for server administrators and implementors. By way of comparison, HTML *could* have client-side include operators (indeed, it does - the tag can be used to include other HTML documents), but the web at large has spoken - server-side templating has totally won. What is the justification for doing client-side includes here? My alternate proposal: 1. All s present in the host-meta document apply to the host unless the link is a template. 2. If the is a template, the semantics of that template are defined by the rel type. 3. The "lrdd" rel type means "a template URL providing arbitrary metadata about the substituted entity in XRD format" (perhaps "meta" would be a better rel than "lrdd", since it's host-meta, not host-lrdd). As for link inclusion, I would argue that any ordering outside of a document-level ordering is completely impossible to enforce. Metadata resolution and inclusion should happen by descent only, and then only within the context of a single entity (i.e., a template URL marks the boundary between host-meta and a host-bound URL; links discovered in host-meta do not apply to links discovered in the template URL). If site owners want a link to apply across all hosted profiles, they can include that link in the document served up at the template URL. I believe this approach simplifies the host-meta draft, as well as the processing rules, while not removing any functionality. b. On 1 July 2010 17:17, Peter Saint-Andre wrote: > FYI. > > -------- Original Message -------- > Subject: Last Call: draft-hammer-hostmeta (Web Host Metadata) to > Proposed =C2=A0 =C2=A0 =C2=A0 =C2=A0Standard > Date: Fri, 25 Jun 2010 05:30:41 -0700 (PDT) > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Web Host Metadata ' > =C2=A0 as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. =C2=A0Please send substantive comments to = the > ietf@ietf.org mailing lists by 2010-07-23. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-hammer-hostmeta-13.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D19329&rfc_flag=3D0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From Nicolas.Williams@oracle.com Fri Jul 23 09:19:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BCB3A67D1 for ; Fri, 23 Jul 2010 09:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, J_BACKHAIR_57=1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL2MroApzrKz for ; Fri, 23 Jul 2010 09:19:27 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AF2443A6359 for ; Fri, 23 Jul 2010 09:19:27 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6NGJhaH007852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Jul 2010 16:19:45 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6MFsXCs026649; Fri, 23 Jul 2010 16:19:34 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 431563111279901968; Fri, 23 Jul 2010 09:19:28 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Jul 2010 09:19:27 -0700 Date: Fri, 23 Jul 2010 11:20:35 -0500 From: Nicolas Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20100723162034.GJ27130@oracle.com> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <006001cb2a0e$10f82e00$6801a8c0@oemcomputer> <20100723044646.GH27130@oracle.com> <43A2952C-20A3-47AC-9AE6-0F8D24FC505B@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <43A2952C-20A3-47AC-9AE6-0F8D24FC505B@frobbit.se> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C49C118.0064:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 23 Jul 2010 16:19:28 -0000 On Fri, Jul 23, 2010 at 07:58:34AM +0200, Patrik Fältström wrote: > On 23 jul 2010, at 06.46, Nicolas Williams wrote: > > > Which brings me to... What would be really nice is a DNS-like method of > > resolving OIDs, so that then IANA can participate in a more structured > > way. Failing that, or even besides that, maybe an IANA API would be > > nice. > > That is basically what they want to do, right? If so, that context was lacking :) But I'd still like to see an actual IANA API. There are a lot of things that IANA registers that are not OIDs. > In IETF we have the DDDS algorithm that is in use for E.164 numbers, > and similar mechanism is used for RFID tags by ONS that ECDS has > defined. > > So yes, that could be interesting. And I think we IETF can do > something here. And because of that, yes, they might walk into "our > turf". I don't much care for turf fights, particularly when the proposed work is a good idea. > But the question is what to tell ITU. If anything. > 1. That they of course can work with this > > 2. That IETF thought OIDs in reality is an ISO thing, not ITU thing > > 3. That IETF is the SDO where DNS, and DNS like mechanisms are > discussed I don't believe (3) is an appropriate answer. (2) wouldn't be relevant. > 4. That we have a history of good cooperation between ITU and IETF > regarding for example ENUM > > 5. That IETF is happy to do (is doing?) a resolution mechanism from > OIDs to something else using DNS. I'm for (5). Resolve OID arc names<->numbers using DNS. A and PTR RRs will do, in a pinch, provided some conventions not unlike the in-addr.arpa. affix for IP->name PTR RRs. Though I'd like a new RR type, or at least TXT RR conventions for documenting registration information (e.g., document whence a registration, owner, registration rules for arcs below, ...). I think the best arguments for doing this in the IETF are: a) we already have a protocol designed for delegating namespaces, so let's re-use it; (An extension of (a): if you want OID arc owners/delegatees to publish arcs/delegations below it would help if they didn't have to deploy [much] new software.) b) many OID arc delegations line up well with existing DNS delegations, so this is natural; I think the best argument for not doing this with DNS, and possibly not at the IETF at all would be: "DNS, ew, time to try a new protocol". Not a terribly convincing argument, IMO. First we should figure out if we have the desire and energy to do this at the IETF. Then we should figure out what to tell the ITU. Nico -- From eran@hueniverse.com Fri Jul 23 13:12: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 382E23A67C2 for ; Fri, 23 Jul 2010 13:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 KvCM9iCH-069 for ; Fri, 23 Jul 2010 13:12:06 -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 C558F3A6874 for ; Fri, 23 Jul 2010 13:12:05 -0700 (PDT) Received: (qmail 30648 invoked from network); 23 Jul 2010 20:12:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 23 Jul 2010 20:12:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 23 Jul 2010 13:12:22 -0700 From: Eran Hammer-Lahav To: Blaine Cook , "apps-discuss@ietf.org" Date: Fri, 23 Jul 2010 13:12:15 -0700 Thread-Topic: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard Thread-Index: AcsqdK4fA+xjIZhQQnaExOhs6pdcXAAGuQFQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2CBFA8.10001@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 23 Jul 2010 20:12:07 -0000 SG9zdC1tZXRhIGluY2x1ZGVzIHR3byBkaXNjb3ZlcnkgbWVjaGFuaXNtczoNCg0KLSBob3N0LXdp ZGUgLSBtZXRhZGF0YSBhYm91dCB0aGUgImhvc3QiIGluIGdlbmVyYWwNCi0gcmVzb3VyY2Utc3Bl Y2lmaWMgLSBtZXRhZGF0YSBhYm91dCBhbiBpbmRpdmlkdWFsIHJlc291cmNlIHVuZGVyIHRoZSBj b250cm9sIG9mIHRoZSAiaG9zdCINCg0KVG8gYWNjb21wbGlzaCB0aGlzLCBob3N0LW1ldGEgZGVm aW5lcyBjbGVhciBzZW1hbnRpYyBtZWFuaW5ncyB0byBsaW5rczoNCg0KLSA8TGluaz4gZWxlbWVu dHMgd2l0aCBhbiAnaHJlZicgYXR0cmlidXRlIGFyZSBob3N0LXdpZGUNCi0gPExpbms+IGVsZW1l bnRzIHdpdGggYSAndGVtcGxhdGUnIGF0dHJpYnV0ZSBhcmUgcmVzb3VyY2Utc3BlY2lmaWMNCg0K SW4gYWRkaXRpb24sIHNpbmNlIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSByZXNvdXJjZS1zcGVjaWZp YyBpbmZvcm1hdGlvbiBjYW5ub3QgYmUgZXhwcmVzc2VkIHVzaW5nIGEgdGVtcGxhdGUsIGhvc3Qt bWV0YSBwcm92aWRlcyBhIGxpbmsgcmVsYXRpb24gdHlwZSAnbHJkZCcgd2hpY2ggbWVhbnMgJ2Fk ZGl0aW9uYWwgbGlua3MgYW5kIG1ldGFkYXRhIGF2YWlsYWJsZSBoZXJlJy4gQmVjYXVzZSBsaW5r IHRlbXBsYXRlcyBpbiBob3N0LW1ldGEgaGF2ZSB0aGUgc2FtZSBjb250ZXh0LVVSSSBhcyBsaW5r cyBpbiBhIExSREQgZG9jdW1lbnQgKG9idGFpbmVkIHVzaW5nIHRoZSBzYW1lIHJlc291cmNlIFVS SSksIHRoZXkgYXJlIHNlbWFudGljYWxseSBlcXVpdmFsZW50Lg0KDQpJbiBhZGRpdGlvbiwgWFJE IGRvY3VtZW50cyByZXF1aXJlIHByb2Nlc3NpbmcgbGlua3MgaW4gZG9jdW1lbnQgb3JkZXIuDQoN ClRoZSBwcm9jZXNzaW5nIHJ1bGVzIGRlZmluZWQgaW4gc2VjdGlvbiA0IGRvIG5vdGhpbmcgbW9y ZSB0aGFuIGFwcGx5IHRoaXMgdG8gcHJvdmlkZSBhIHVuaWZvcm0gYW5kIGNsZWFybHkgc3RhdGVk IGNsaWVudCBiZWhhdmlvcjoNCg0KLSBTaW5jZSBsaW5rIHRlbXBsYXRlcyBpbiBob3N0LW1ldGEg YXJlIGVxdWl2YWxlbnQgdG8gdGhvc2UgaW4gTFJERCBkb2N1bWVudHMsIExSREQgZG9jdW1lbnRz IGFyZSB0cmVhdGVkIGFzIGFuICdpbmNsdWRlJyBkaXJlY3RpdmUgd2hlbiBwcm9jZXNzaW5nIGhv c3QtbWV0YS4NCi0gU2luY2UgWFJEIGRvY3VtZW50cyBoYXZlIGEgcHJlc2NyaWJlZCBvcmRlciwg YW5kICdscmRkJyBsaW5rIHRlbXBsYXRlcyBhcmUgdHJlYXRlZCBqdXN0IGxpa2UgYW55IG90aGVy IGxpbmsgKGluIHRlcm1zIG9mIHByaW9yaXR5KSwgY29uc3RydWN0aW5nIGEgZnVsbCByZXNvdXJj ZSBkZXNjcmlwdG9yIHJlcXVpcmVzIGNvbWJpbmluZyBsaW5rcyBmcm9tIG11bHRpcGxlIHNvdXJj ZSBpbiBvcmRlci4NCg0KU2VjdGlvbiA0LjIgaXMgd3JpdHRlbiBmb3IgY2xpZW50cyBsb29raW5n IGZvciB0aGUgY29tcGxldGUgcmVzb3VyY2UgZGVzY3JpcHRvciwgY29sbGVjdGVkIGZyb20gcG90 ZW50aWFsbHkgbXVsdGlwbGUgZG9jdW1lbnRzIChob3N0LW1ldGEgYW5kIG9uZSBvciBtb3JlIExS REQgZG9jdW1lbnRzKS4gSG93ZXZlciwgdGhlIGludHJvZHVjdGlvbiBpbiBzZWN0aW9uIDQgY2xl YXJseSBzdGF0ZXM6DQoNCiAgIENsaWVudHMgdXN1YWxseSBsb29rIGZvciBhIGxpbmsgd2l0aCBh IHNwZWNpZmljIHJlbGF0aW9uIHR5cGUgb3INCiAgIG90aGVyIGF0dHJpYnV0ZXMuICBJbiBzdWNo IGNhc2VzLCB0aGUgY2xpZW50IGRvZXMgbm90IG5lZWQgdG8gcHJvY2Vzcw0KICAgdGhlIGVudGly ZSBob3N0LW1ldGEgZG9jdW1lbnQgYW5kIGFsbCBsaW5rZWQgTFJERCBkb2N1bWVudHMsIGJ1dA0K ICAgaW5zdGVhZCwgcHJvY2VzcyB0aGUgdmFyaW91cyBkb2N1bWVudHMgaW4gdGhlaXIgcHJlc2Ny aWJlZCBvcmRlcg0KICAgdW50aWwgdGhlIGRlc2lyZWQgaW5mb3JtYXRpb24gaXMgZm91bmQuDQoN CldoaWNoIG1lYW5zIGNsaWVudHMgYXJlIG5vdCByZXF1aXJlZCB0byBjb25zdHJ1Y3QgYSBjb21w bGV0ZSByZXNvdXJjZSBkZXNjcmlwdG9yIHdoZW4gdGhleSBhcmUgbG9va2luZyBmb3IgYSBzaW5n bGUgbGluayAodGhlIG1vc3QgY29tbW9uIHVzZSBjYXNlKS4gVGhpcyBzaWduaWZpY2FudGx5IHNp bXBsaWZpZXMgdGhlIHByb2Nlc3NpbmcuDQoNCioqIElmIHRoaXMgaXMgbm90IGNsZWFyLCBJIGFt IGhhcHB5IHRvIG1ha2UgaXQgbW9yZSBleHBsaWNpdCBpbiBzZWN0aW9uIDQuMiwgaW5jbHVkaW5n IGFkZGluZyBhIGZ1bGwgcHJvY2VkdXJlIGZvciBjbGllbnRzIGxvb2tpbmcgZm9yIGEgc3BlY2lm aWMgbGluay4NCg0KVGhlIGN1cnJlbnQgcHJvY2Vzc2luZyBydWxlcyBvZiBzZWN0aW9uIDQuMiBh cmUgbm90aGluZyBtb3JlIHRoYW4gc3RhdGluZyB0aGUgbG9naWNhbCBjb25jbHVzaW9uIGRlcml2 ZWQgZnJvbSB0aGUgcnVsZXMgc2V0IGJ5IGhvc3QtbWV0YSBhbmQgWFJEIChhcyBleHBsYWluZWQg YWJvdmUpLg0KDQpIb3dldmVyLCBpZiBwZW9wbGUgd291bGQgbGlrZSB0byBzaW1wbGlmeSB0aGlz IGEgYml0LCBJIGFtIG9wZW4gdG8gKGJ1dCBub3QgZXhjaXRlZCBhYm91dCkgbWFraW5nIGEgc21h bGwgY2hhbmdlIGluIHdoaWNoIGNsaWVudHMgd2lsbCBmaXJzdCBsb29rIGZvciAoYW55KSAnbHJk ZCcgbGluayB0ZW1wbGF0ZXMsIHByb2Nlc3MgdGhlbSwgYW5kIG9ubHkgdGhlbiBsb29rIGZvciBv dGhlciBsaW5rLXRlbXBsYXRlcyBpbiBob3N0LW1ldGEuIFRoaXMgZXhjZXB0aW9uIHdpbGwgZGV2 aWF0ZSBmcm9tIHRoZSBub3JtYWwgWFJEIHByb2Nlc3NpbmcgcnVsZXMgb2YgZG9jdW1lbnQgb3Jk ZXIsIGJ1dCB3aWxsIG1vdmUgZnJvbSBhIHBvdGVudGlhbCBjb21wbGV4IG1peCBmcm9tIGxpbmsg c291cmNlcyB0byBhIHR3byBzdGFnZSBwcm9jZWR1cmUgKExSREQgbGlua3MsIHRoZW4gaG9zdC1t ZXRhIGxpbmsgdGVtcGxhdGVzKS4gTm90ZSB0aGF0IHRoaXMgZG9lcyBub3Qgc29sdmUgdGhlIGJh c2ljIHJlcXVpcmVtZW50IHRvIGNvbnN0cnVjdCB0aGUgZnVsbCByZXNvdXJjZSBkZXNjcmlwdG9y IGZyb20gbXVsdGlwbGUgbG9jYXRpb24sIG9ubHkgdGhlIG9yZGVyIGluIHdoaWNoIHRoYXQgaXMg ZG9uZS4NCg0KRUhMDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLQ0KPiBi b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmxhaW5lIENvb2sNCj4gU2VudDogRnJpZGF5 LCBKdWx5IDIzLCAyMDEwIDc6MzggQU0NCj4gVG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gRndkOiBMYXN0IENhbGw6IGRyYWZ0LWhhbW1lci1o b3N0bWV0YSAoV2ViDQo+IEhvc3QgTWV0YWRhdGEpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0K PiBTbmVha2luZyBpbiB1bmRlciB0aGUgd2lyZSB3aXRoIHRoZXNlIGNvbW1lbnRzLCB3aGljaCBJ J20gc3VyZSB3aWxsIGV4YWN0DQo+IHB1bmlzaG1lbnQgZnJvbSBFcmFuIGF0IHNvbWUgbGF0ZXIg cG9pbnQgKHRob3VnaCBJIGhhdmUgbWFkZSB0aGVzZQ0KPiBjb21tZW50cyB1bm9mZmljaWFsbHkg aW4gb3RoZXIgdmVudWVzKS4NCj4gDQo+IEkgc3Ryb25nbHkgZGlzYWdyZWUgd2l0aCB0aGUgcHJv Y2Vzc2luZyBtb2RlbCBmb3IgTFJERCBwcm9wb3NlZCBpbiBTZWN0aW9uDQo+IDQuMiBvZiBkcmFm dC1oYW1tZXItaG9zdG1ldGEtMTMuIFRoZSBtb2RlbCBhbW91bnRzIHRvIGEgY2xpZW50LXNpZGUN Cj4gYXBwcm9hY2ggdG8gdGVtcGxhdGUgcHJvY2Vzc2luZy4gSSBiZWxpZXZlIHRoaXMgd2lsbCBs ZWFkIHRvIGluY29uc2lzdGVudCAoaS5lLiwNCj4gbm9uLWludGVyb3BlcmFibGUpIHJlc3VsdHMg YWNyb3NzIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMsIGlzIGhhcmRlciB0bw0KPiBpbXBsZW1lbnQg Zm9yIGNsaWVudCBkZXZlbG9wZXJzLCBhbmQgYWRkcyBjb21wbGV4aXR5IGZvciBzZXJ2ZXINCj4g YWRtaW5pc3RyYXRvcnMgYW5kIGltcGxlbWVudG9ycy4NCj4gDQo+IEJ5IHdheSBvZiBjb21wYXJp c29uLCBIVE1MICpjb3VsZCogaGF2ZSBjbGllbnQtc2lkZSBpbmNsdWRlIG9wZXJhdG9ycw0KPiAo aW5kZWVkLCBpdCBkb2VzIC0gdGhlIDxvYmplY3Q+IHRhZyBjYW4gYmUgdXNlZCB0byBpbmNsdWRl IG90aGVyIEhUTUwNCj4gZG9jdW1lbnRzKSwgYnV0IHRoZSB3ZWIgYXQgbGFyZ2UgaGFzIHNwb2tl biAtIHNlcnZlci1zaWRlIHRlbXBsYXRpbmcgaGFzDQo+IHRvdGFsbHkgd29uLiBXaGF0IGlzIHRo ZSBqdXN0aWZpY2F0aW9uIGZvciBkb2luZyBjbGllbnQtc2lkZSBpbmNsdWRlcyBoZXJlPw0KPiAN Cj4gTXkgYWx0ZXJuYXRlIHByb3Bvc2FsOg0KPiANCj4gMS4gQWxsIDxsaW5rPnMgcHJlc2VudCBp biB0aGUgaG9zdC1tZXRhIGRvY3VtZW50IGFwcGx5IHRvIHRoZSBob3N0IHVubGVzcyB0aGUNCj4g bGluayBpcyBhIHRlbXBsYXRlLg0KPiAyLiBJZiB0aGUgPGxpbms+IGlzIGEgdGVtcGxhdGUsIHRo ZSBzZW1hbnRpY3Mgb2YgdGhhdCB0ZW1wbGF0ZSBhcmUgZGVmaW5lZCBieQ0KPiB0aGUgcmVsIHR5 cGUuDQo+IDMuIFRoZSAibHJkZCIgcmVsIHR5cGUgbWVhbnMgImEgdGVtcGxhdGUgVVJMIHByb3Zp ZGluZyBhcmJpdHJhcnkgbWV0YWRhdGENCj4gYWJvdXQgdGhlIHN1YnN0aXR1dGVkIGVudGl0eSBp biBYUkQgZm9ybWF0IiAocGVyaGFwcyAibWV0YSINCj4gd291bGQgYmUgYSBiZXR0ZXIgcmVsIHRo YW4gImxyZGQiLCBzaW5jZSBpdCdzIGhvc3QtbWV0YSwgbm90IGhvc3QtbHJkZCkuDQo+IA0KPiBB cyBmb3IgbGluayBpbmNsdXNpb24sIEkgd291bGQgYXJndWUgdGhhdCBhbnkgb3JkZXJpbmcgb3V0 c2lkZSBvZiBhIGRvY3VtZW50LQ0KPiBsZXZlbCBvcmRlcmluZyBpcyBjb21wbGV0ZWx5IGltcG9z c2libGUgdG8gZW5mb3JjZS4gTWV0YWRhdGEgcmVzb2x1dGlvbiBhbmQNCj4gaW5jbHVzaW9uIHNo b3VsZCBoYXBwZW4gYnkgZGVzY2VudCBvbmx5LCBhbmQgdGhlbiBvbmx5IHdpdGhpbiB0aGUgY29u dGV4dCBvZg0KPiBhIHNpbmdsZSBlbnRpdHkgKGkuZS4sIGEgdGVtcGxhdGUgVVJMIG1hcmtzIHRo ZSBib3VuZGFyeSBiZXR3ZWVuIGhvc3QtbWV0YQ0KPiBhbmQgYSBob3N0LWJvdW5kIFVSTDsgbGlu a3MgZGlzY292ZXJlZCBpbiBob3N0LW1ldGEgZG8gbm90IGFwcGx5IHRvIGxpbmtzDQo+IGRpc2Nv dmVyZWQgaW4gdGhlIHRlbXBsYXRlIFVSTCkuDQo+IA0KPiBJZiBzaXRlIG93bmVycyB3YW50IGEg bGluayB0byBhcHBseSBhY3Jvc3MgYWxsIGhvc3RlZCBwcm9maWxlcywgdGhleSBjYW4gaW5jbHVk ZQ0KPiB0aGF0IGxpbmsgaW4gdGhlIGRvY3VtZW50IHNlcnZlZCB1cCBhdCB0aGUgdGVtcGxhdGUg VVJMLg0KPiANCj4gSSBiZWxpZXZlIHRoaXMgYXBwcm9hY2ggc2ltcGxpZmllcyB0aGUgaG9zdC1t ZXRhIGRyYWZ0LCBhcyB3ZWxsIGFzIHRoZQ0KPiBwcm9jZXNzaW5nIHJ1bGVzLCB3aGlsZSBub3Qg cmVtb3ZpbmcgYW55IGZ1bmN0aW9uYWxpdHkuDQo+IA0KPiBiLg0KPiANCj4gT24gMSBKdWx5IDIw MTAgMTc6MTcsIFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW0+IHdyb3RlOg0K PiA+IEZZSS4NCj4gPg0KPiA+IC0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NCj4g PiBTdWJqZWN0OiBMYXN0IENhbGw6IGRyYWZ0LWhhbW1lci1ob3N0bWV0YSAoV2ViIEhvc3QgTWV0 YWRhdGEpIHRvDQo+ID4gUHJvcG9zZWQgwqAgwqAgwqAgwqBTdGFuZGFyZA0KPiA+IERhdGU6IEZy aSwgMjUgSnVuIDIwMTAgMDU6MzA6NDEgLTA3MDAgKFBEVCkNCj4gPiBGcm9tOiBUaGUgSUVTRyA8 aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+DQo+ID4gUmVwbHktVG86IGlldGZAaWV0Zi5vcmcNCj4g PiBUbzogSUVURi1Bbm5vdW5jZSA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCj4gPg0KPiA+IFRo ZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSBhbiBpbmRpdmlkdWFsIHN1Ym1pdHRl ciB0bw0KPiA+IGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6DQo+ID4NCj4gPiAtICdX ZWIgSG9zdCBNZXRhZGF0YSAnDQo+ID4gwqAgPGRyYWZ0LWhhbW1lci1ob3N0bWV0YS0xMy50eHQ+ IGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQNCj4gPg0KPiA+IFRoZSBJRVNHIHBsYW5zIHRvIG1ha2Ug YSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0cw0KPiA+IGZpbmFs IGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiDCoFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1l bnRzIHRvDQo+ID4gdGhlIGlldGZAaWV0Zi5vcmcgbWFpbGluZyBsaXN0cyBieSAyMDEwLTA3LTIz LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cw0KPiA+IG1heSBiZSBzZW50IHRvIGllc2dAaWV0Zi5v cmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4NCj4gPiB0aGUgYmVnaW5u aW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQo+ID4N Cj4gPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+ID4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGFtbWVyLWhvc3RtZXRhLTEzLnR4dA0KPiA+DQo+ID4N Cj4gPiBJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+ID4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9wdWJsaWMvcGlkdHJhY2tlci5jZ2k/Y29tbWFuZD12aWV3X2lkJmRU YQ0KPiA+IGc9MTkzMjkmcmZjX2ZsYWc9MA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBJRVRGLUFubm91bmNlIG1haWxpbmcgbGlz dA0KPiA+IElFVEYtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBhcHBzLWRpc2N1c3MgbWFp bGluZyBsaXN0DQo+ID4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCj4gPg0KPiA+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFwcHMtZGlzY3VzcyBt YWlsaW5nIGxpc3QNCj4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo= From Joe.Hildebrand@webex.com Fri Jul 23 14:37: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 B53D63A67EB for ; Fri, 23 Jul 2010 14:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.743 X-Spam-Level: X-Spam-Status: No, score=-102.743 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 MkfpfxRtvFDs for ; Fri, 23 Jul 2010 14:37:36 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id 722F63A67A1 for ; Fri, 23 Jul 2010 14:37:35 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 14:37:53 -0700 Received: from 66.114.169.7 ([66.114.169.7]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.12]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Jul 2010 21:28:08 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 23 Jul 2010 15:28:07 -0600 From: Joe Hildebrand To: Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?= , Apps Discuss Message-ID: Thread-Topic: [apps-discuss] How to find a service? Thread-Index: AcsqrfDttWoUHRCCPUCnCVm0mdQn0A== In-Reply-To: <3FA99C66-4175-4A70-8EFB-AF2D8DEA5F74@frobbit.se> IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 23 Jul 2010 21:37:53.0981 (UTC) FILETIME=[4ECBBED0:01CB2AAF] Subject: Re: [apps-discuss] How to find a service? 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, 23 Jul 2010 21:37:37 -0000 Sounds like an interesting conversation. Here's another pattern that I've seen: - Look up a TXT record containing the URI. Example: http://xmpp.org/extensions/xep-0156.html Same basic idea as your URI I-D, with all of the TXT trade-offs. On 7/22/10 8:44 AM, "Patrik F=E4ltstr=F6m" wrote: > Ok, there is a confusion regarding the breakfast...no breakfast at the ME= CC > says the hotel info, but on the agenda I saw: >=20 >> 0800-0900 Beverages - Trajectum Lobby >=20 > I interpreted that as "breakfast". >=20 > My call is still to have the meeting 8-9AM Wednesday, but there will not = be > breakfast... >=20 > Patrik >=20 > On 22 jul 2010, at 10.20, Patrik F=E4ltstr=F6m wrote: >=20 >> We have had various discussions during the years on "how to find a servi= ce". >> And we have many ways of doing it at the moment. For example: >>=20 >> - Just use a well known algorithm >> - Look up A or AAAA record, and then use well known port number >> - Look up MX, and then A/AAAA and use well known port number >> - Look up SRV record, and use that hostname and port number >> - Use a DDDS algorithm as defined somewhere >> - Use mdns like services to "broadcast" information (or respond to broad= cast >> queries) >> - : >> - : >>=20 >> ...and many more... >>=20 >> Now we have other ways as well, like the two currently proposed mechanis= ms >> that some people have seen discussed on the IETF list: >>=20 >> - What is described in draft-daboo-srv-caldav, which I in a sloppy way >> describe as "use SRV records and then a well known path that should resu= lt in >> an HTTP redirect" >>=20 >> - What is described in draft-faltstrom-uri, which I in a sloppy way desc= ribe >> as "use URI records like we use SRV records, but get a full URI back" >>=20 >>=20 >> As we are so close to Maastricht, I do not find we have time for a doodl= e >> regarding interested parties that want to talk about this. >>=20 >> I have therefore decided we meet on Wednesday July 28 at 08:00 (yes, for= a >> breakfast meeting). It will be by the IETF registration/announcement boa= rd, >> OR, where a note on that very same announcement board says. I guess it w= ill >> be near or even where breakfast is served... >>=20 >> I am deliberately sending this only to Apps Discuss as I think we should >> start this discussion from the point of view of "the need applications h= as". >> That said, please spread the word to other interested parties. It is not >> supposed to be a "secret cabal meeting". >>=20 >> I envision a mailing list discussion after this first meeting. >>=20 >> Patrik >>=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=20 Joe Hildebrand From romeda@gmail.com Fri Jul 23 17:09:13 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 5EFF93A68F3 for ; Fri, 23 Jul 2010 17:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+nfStpYjAEZ for ; Fri, 23 Jul 2010 17:09:12 -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 E5CB33A688C for ; Fri, 23 Jul 2010 17:09:11 -0700 (PDT) Received: by gyf2 with SMTP id 2so366907gyf.22 for ; Fri, 23 Jul 2010 17:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=SZCAlumJHRjEp8H4OYs4WM7orAAkFN0ZiYOubqeU7DM=; b=tRmFZxm84+X49SYvptiIgOb+1T9D+JcZsOdXhgTuTGgNhIrTMYjk3HkImid7ge4uqz L3DDxVFhW2mspQalhh00vC0a+JHmfgh/3Vn076/eWERL7mLzpZR5+lMvlnaj8exr0D2S JM/8wAJetFyVnd0gxW4ZU0a0Scu3Y/XIOv3X8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=kvkDEM2IOWOdxxlpB3BH6aJXuhpcZ5k41A1/tjREbHDuBsWf9ja0zEqU15CyMxVAK3 QHmUbWiI4FfPK1Aq9XrYttBdmvEurwLxoZYfXh4KEiikccfombBfBhvQAOEyZSOSBiWK Y84MIfuFdzHmzAwFsZi7zTE5H72JuPnGOfN44= Received: by 10.151.87.3 with SMTP id p3mr6369171ybl.448.1279930170155; Fri, 23 Jul 2010 17:09:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.7 with HTTP; Fri, 23 Jul 2010 17:09:10 -0700 (PDT) In-Reply-To: References: <3FA99C66-4175-4A70-8EFB-AF2D8DEA5F74@frobbit.se> From: Blaine Cook Date: Sat, 24 Jul 2010 01:09:10 +0100 Message-ID: To: Joe Hildebrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] How to find a service? 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, 24 Jul 2010 00:09:13 -0000 I won't be able to make the Wednesday meeting, but many of us implementing stuff are using draft-hammer-hostmeta, FWIW. Webfinger (a related higher-level approach that is more pattern and less spec) is often described as "DNS for People". Those considering DNS-based solutions are well-advised to consider the relative programmability of the deployed HTTP and DNS infrastructures, and the ever-increasing need for new record types. Also, consider that browser-based JavaScript environments are unable to make DNS requests without a suitable proxy, but that they are absolutely able to make HTTP requests. b. 2010/7/23 Joe Hildebrand : > Sounds like an interesting conversation. =C2=A0Here's another pattern tha= t I've > seen: > > - Look up a TXT record containing the URI. =C2=A0Example: > http://xmpp.org/extensions/xep-0156.html > > Same basic idea as your URI I-D, with all of the TXT trade-offs. > > > On 7/22/10 8:44 AM, "Patrik F=C3=A4ltstr=C3=B6m" wrot= e: > >> Ok, there is a confusion regarding the breakfast...no breakfast at the M= ECC >> says the hotel info, but on the agenda I saw: >> >>> 0800-0900 Beverages - Trajectum Lobby >> >> I interpreted that as "breakfast". >> >> My call is still to have the meeting 8-9AM Wednesday, but there will not= be >> breakfast... >> >> =C2=A0 =C2=A0Patrik >> >> On 22 jul 2010, at 10.20, Patrik F=C3=A4ltstr=C3=B6m wrote: >> >>> We have had various discussions during the years on "how to find a serv= ice". >>> And we have many ways of doing it at the moment. For example: >>> >>> - Just use a well known algorithm >>> - Look up A or AAAA record, and then use well known port number >>> - Look up MX, and then A/AAAA and use well known port number >>> - Look up SRV record, and use that hostname and port number >>> - Use a DDDS algorithm as defined somewhere >>> - Use mdns like services to "broadcast" information (or respond to broa= dcast >>> queries) >>> - : >>> - : >>> >>> ...and many more... >>> >>> Now we have other ways as well, like the two currently proposed mechani= sms >>> that some people have seen discussed on the IETF list: >>> >>> - What is described in draft-daboo-srv-caldav, which I in a sloppy way >>> describe as "use SRV records and then a well known path that should res= ult in >>> an HTTP redirect" >>> >>> - What is described in draft-faltstrom-uri, which I in a sloppy way des= cribe >>> as "use URI records like we use SRV records, but get a full URI back" >>> >>> >>> As we are so close to Maastricht, I do not find we have time for a dood= le >>> regarding interested parties that want to talk about this. >>> >>> I have therefore decided we meet on Wednesday July 28 at 08:00 (yes, fo= r a >>> breakfast meeting). It will be by the IETF registration/announcement bo= ard, >>> OR, where a note on that very same announcement board says. I guess it = will >>> be near or even where breakfast is served... >>> >>> I am deliberately sending this only to Apps Discuss as I think we shoul= d >>> start this discussion from the point of view of "the need applications = has". >>> That said, please spread the word to other interested parties. It is no= t >>> supposed to be a "secret cabal meeting". >>> >>> I envision a mailing list discussion after this first meeting. >>> >>> =C2=A0 =C2=A0Patrik >>> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Joe Hildebrand > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From romeda@gmail.com Fri Jul 23 17:15:50 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 8241D3A6891 for ; Fri, 23 Jul 2010 17:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEUOwQZ3JuxI for ; Fri, 23 Jul 2010 17:15:49 -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 7C6DE3A659C for ; Fri, 23 Jul 2010 17:15:49 -0700 (PDT) Received: by gyg8 with SMTP id 8so406843gyg.31 for ; Fri, 23 Jul 2010 17:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=vweLZlTAJvYZF8rqaahximLz4+eHU4+b4pjfiNWCntg=; b=KnnAXwDugSPQ8x3VdUzLKi9ut95SGCAQ+IuTnNFIks7hk2Xik7gfOKF8mZfpNahzzT +81kw/2t3ZJD67O0ENgSdJ6VshtMFBBAyR3RNGvIc7GqgUzKGnnOe2czw0ddn2bSdE6r dDxKgtv/gf/4WNz5FBK9JqEfiS9+eT4rxnZdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=InyN+X5rUlcaZ5OxlJ9vkw8yhzpCpMCGk9Nha3xRBcliRSK6oIka0ZcYkAIMCx9izc /MqvTqjofX2msm2wmul5EI7xKBp1OKyPAEcMmTpHg5TfYpjvnj2L3q0lwRim7b+juhef VyapOvkABcvLx0fHLm/KRC2OxaWxwHGL7tVPQ= Received: by 10.150.62.21 with SMTP id k21mr1820869yba.66.1279930567183; Fri, 23 Jul 2010 17:16:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.7 with HTTP; Fri, 23 Jul 2010 17:15:47 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2CBFA8.10001@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Sat, 24 Jul 2010 01:15:47 +0100 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 24 Jul 2010 00:15:50 -0000 On 23 July 2010 21:12, Eran Hammer-Lahav wrote: > ** If this is not clear, I am happy to make it more explicit in section 4= .2, including adding a full procedure for clients looking for a specific li= nk. +1 - In my reading of 4.2, I had overlooked the sentence in 4 that describes stopping whenever a suitable link relation is found. With that processing rule in place, the semantic is clear and simple. > However, if people would like to simplify this a bit, I am open to (but n= ot excited about) making a small change in which clients will first look fo= r (any) 'lrdd' link templates, process them, and only then look for other l= ink-templates in host-meta. This exception will deviate from the normal XRD= processing rules of document order, but will move from a potential complex= mix from link sources to a two stage procedure (LRDD links, then host-meta= link templates). Note that this does not solve the basic requirement to co= nstruct the full resource descriptor from multiple location, only the order= in which that is done. I'm not sure what others think about this, but I personally prefer this approach (LRDD-first, followed by host-level templates). The reasoning is that this gives LRDD profiles the ability to over-ride host-level decisions, whereas strictly following document ordering means that hosts could potentially force all users to use a single URL for a given rel value. The challenge is not so much that the hosts could force this (because a "malicious" host could over-write the rel value in ever user's LRDD document), but that interop becomes more challenging since any parser that does LRDD-first *might* disagree with a strictly ordered parser (an example where this is a real possibility: three parsers, one SAX-based, one XPath based, and one DOM-based, may come up with very different results if we rely on document ordering alone). b. From jpanzer@google.com Fri Jul 23 18:36:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E033A67FA for ; Fri, 23 Jul 2010 18:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.177 X-Spam-Level: X-Spam-Status: No, score=-104.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, 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 jHViq8QPYKef for ; Fri, 23 Jul 2010 18:36:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4D2E53A6767 for ; Fri, 23 Jul 2010 18:36:15 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o6O1aY17011981 for ; Fri, 23 Jul 2010 18:36:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279935394; bh=fGz2nK6AgAHX2ST/YpuJve2lXmc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=XUlafN+XPiXKIgM3lerpj1kuKgGWs+UtXbDg6jJn33tR2W1NqCpyv8d4Q01VDqIUO Ujy1kLthk7+iExtyrht3A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=capMYQ0WBZwGOQ23Q17ujPwygwfzSm5TgsMOLuvL6MZcOV0l55prHpm5YTu5mrHme IHh+B9Uvr3DoY5UMCHPqQ== Received: from gxk26 (gxk26.prod.google.com [10.202.11.26]) by wpaz37.hot.corp.google.com with ESMTP id o6O1aWK9004029 for ; Fri, 23 Jul 2010 18:36:33 -0700 Received: by gxk26 with SMTP id 26so526115gxk.24 for ; Fri, 23 Jul 2010 18:36:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.228.13 with SMTP id a13mr4876030anh.46.1279935392021; Fri, 23 Jul 2010 18:36:32 -0700 (PDT) Received: by 10.101.138.5 with HTTP; Fri, 23 Jul 2010 18:36:31 -0700 (PDT) In-Reply-To: References: <4C2CBFA8.10001@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 23 Jul 2010 18:36:31 -0700 Message-ID: From: John Panzer To: Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 24 Jul 2010 01:36:24 -0000 That's also why I don't see "stop when you see the rel you're looking for" as a big help - you actually are looking for a collection where rel=3Dx in the general case (think rel=3Dalternate for a common example from other formats). So you have to get the set of links in some context, which could be the host-meta document or the target of the lrdd template. But in general I agree with Blaine's primary objection; this adds an include model that has not been proven and which forces clients to provision for a nearly arbitrary number of worst-case http fetches. Query: Is it at least possible for a server to automatically merge multiple rel=3Dlrdd targets and serve up a single composite rel=3Dlrdd target resource to clients without impacting semantics? It's not clear to me from the spec. On Friday, July 23, 2010, Blaine Cook wrote: > On 23 July 2010 21:12, Eran Hammer-Lahav wrote: >> ** If this is not clear, I am happy to make it more explicit in section = 4.2, including adding a full procedure for clients looking for a specific l= ink. > > +1 - In my reading of 4.2, I had overlooked the sentence in 4 that > describes stopping whenever a suitable link relation is found. With > that processing rule in place, the semantic is clear and simple. > >> However, if people would like to simplify this a bit, I am open to (but = not excited about) making a small change in which clients will first look f= or (any) 'lrdd' link templates, process them, and only then look for other = link-templates in host-meta. This exception will deviate from the normal XR= D processing rules of document order, but will move from a potential comple= x mix from link sources to a two stage procedure (LRDD links, then host-met= a link templates). Note that this does not solve the basic requirement to c= onstruct the full resource descriptor from multiple location, only the orde= r in which that is done. > > I'm not sure what others think about this, but I personally prefer > this approach (LRDD-first, followed by host-level templates). The > reasoning is that this gives LRDD profiles the ability to over-ride > host-level decisions, whereas strictly following document ordering > means that hosts could potentially force all users to use a single URL > for a given rel value. > > The challenge is not so much that the hosts could force this (because > a "malicious" host could over-write the rel value in ever user's LRDD > document), but that interop becomes more challenging since any parser > that does LRDD-first *might* disagree with a strictly ordered parser > (an example where this is a real possibility: three parsers, one > SAX-based, one XPath based, and one DOM-based, may come up with very > different results if we rely on document ordering alone). > > b. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From patrik@frobbit.se Fri Jul 23 21:20: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 E5C883A67F9 for ; Fri, 23 Jul 2010 21:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HshSa4TEqiSN for ; Fri, 23 Jul 2010 21:20:34 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 5C4103A67E7 for ; Fri, 23 Jul 2010 21:20:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 9925CCC582D5; Sat, 24 Jul 2010 06:20:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MUxinp-2oI2; Sat, 24 Jul 2010 06:20:39 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 30746CC57EA5; Sat, 24 Jul 2010 06:16:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-403-989748329" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Sat, 24 Jul 2010 06:10:58 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Joe Hildebrand X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss Subject: Re: [apps-discuss] How to find a service? 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, 24 Jul 2010 04:20:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-403-989748329 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes, have seen those as well... Patrik On 23 jul 2010, at 23.28, Joe Hildebrand wrote: > Sounds like an interesting conversation. Here's another pattern that = I've > seen: >=20 > - Look up a TXT record containing the URI. Example: > http://xmpp.org/extensions/xep-0156.html >=20 > Same basic idea as your URI I-D, with all of the TXT trade-offs. >=20 >=20 > On 7/22/10 8:44 AM, "Patrik F=E4ltstr=F6m" wrote: >=20 >> Ok, there is a confusion regarding the breakfast...no breakfast at = the MECC >> says the hotel info, but on the agenda I saw: >>=20 >>> 0800-0900 Beverages - Trajectum Lobby >>=20 >> I interpreted that as "breakfast". >>=20 >> My call is still to have the meeting 8-9AM Wednesday, but there will = not be >> breakfast... >>=20 >> Patrik >>=20 >> On 22 jul 2010, at 10.20, Patrik F=E4ltstr=F6m wrote: >>=20 >>> We have had various discussions during the years on "how to find a = service". >>> And we have many ways of doing it at the moment. For example: >>>=20 >>> - Just use a well known algorithm >>> - Look up A or AAAA record, and then use well known port number >>> - Look up MX, and then A/AAAA and use well known port number >>> - Look up SRV record, and use that hostname and port number >>> - Use a DDDS algorithm as defined somewhere >>> - Use mdns like services to "broadcast" information (or respond to = broadcast >>> queries) >>> - : >>> - : >>>=20 >>> ...and many more... >>>=20 >>> Now we have other ways as well, like the two currently proposed = mechanisms >>> that some people have seen discussed on the IETF list: >>>=20 >>> - What is described in draft-daboo-srv-caldav, which I in a sloppy = way >>> describe as "use SRV records and then a well known path that should = result in >>> an HTTP redirect" >>>=20 >>> - What is described in draft-faltstrom-uri, which I in a sloppy way = describe >>> as "use URI records like we use SRV records, but get a full URI = back" >>>=20 >>>=20 >>> As we are so close to Maastricht, I do not find we have time for a = doodle >>> regarding interested parties that want to talk about this. >>>=20 >>> I have therefore decided we meet on Wednesday July 28 at 08:00 (yes, = for a >>> breakfast meeting). It will be by the IETF registration/announcement = board, >>> OR, where a note on that very same announcement board says. I guess = it will >>> be near or even where breakfast is served... >>>=20 >>> I am deliberately sending this only to Apps Discuss as I think we = should >>> start this discussion from the point of view of "the need = applications has". >>> That said, please spread the word to other interested parties. It is = not >>> supposed to be a "secret cabal meeting". >>>=20 >>> I envision a mailing list discussion after this first meeting. >>>=20 >>> Patrik >>>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > --=20 > Joe Hildebrand >=20 >=20 --Apple-Mail-403-989748329 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMSmfSrMabGguI180RAkuPAJ4iARKETkvX8EzH6ozjBgpOkgo44wCfRvPk 86kT5vhWUrI/V3LUGqjeVqI= =NUwk -----END PGP SIGNATURE----- --Apple-Mail-403-989748329-- From patrik@frobbit.se Fri Jul 23 21:20:38 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1B33A6966 for ; Fri, 23 Jul 2010 21:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ukk-10j6KwiU for ; Fri, 23 Jul 2010 21:20:37 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id B49DC3A67E7 for ; Fri, 23 Jul 2010 21:20:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id EDE29CC58353; Sat, 24 Jul 2010 06:20:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBmeRghcig2I; Sat, 24 Jul 2010 06:20:52 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 4BD09CC57F2C; Sat, 24 Jul 2010 06:17:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-404-989860176" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Sat, 24 Jul 2010 06:12:50 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <3FA99C66-4175-4A70-8EFB-AF2D8DEA5F74@frobbit.se> To: Blaine Cook X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss Subject: Re: [apps-discuss] How to find a service? 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, 24 Jul 2010 04:20:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-404-989860176 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24 jul 2010, at 02.09, Blaine Cook wrote: > Those considering DNS-based solutions are well-advised to consider the > relative programmability of the deployed HTTP and DNS infrastructures, > and the ever-increasing need for new record types. I want people to remember that there is a difference between thinking of = good architecture (that drives how libraries etc are designed) and how = people might do things based on how an existing library might be = written. Patrik --Apple-Mail-404-989860176 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMSmhCrMabGguI180RAkBFAKCZIOg6sPbS34KaV9kIVXWtOXOWdQCeOBlp tQ/4h14AyK3ZQlfRpv6nY2M= =90D3 -----END PGP SIGNATURE----- --Apple-Mail-404-989860176-- From eran@hueniverse.com Fri Jul 23 23:31:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1453A6888 for ; Fri, 23 Jul 2010 23:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcX7PLgXIimm for ; Fri, 23 Jul 2010 23:31:28 -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 F06033A6862 for ; Fri, 23 Jul 2010 23:31:27 -0700 (PDT) Received: (qmail 25053 invoked from network); 24 Jul 2010 06:31:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 Jul 2010 06:31:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 23 Jul 2010 23:31:44 -0700 From: Eran Hammer-Lahav To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Blaine Cook Date: Fri, 23 Jul 2010 23:31:39 -0700 Thread-Topic: [apps-discuss] How to find a service? Thread-Index: Acsq56E0e8DFN/tHQKyPaCtnyHqDaAAERoIA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FD88@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3FA99C66-4175-4A70-8EFB-AF2D8DEA5F74@frobbit.se> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] How to find a service? 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, 24 Jul 2010 06:31:31 -0000 SRV and NAPTR records are a great example of where standards fails when it = comes to practical deployment. In many cases, we need to discover a service= endpoint, not just a service host (and port). SRV excels in its simplicity= but because it cannot store a URI, it fails to cover these use cases. This= leaves the problem largely unsolved (leading to the use of a complimentary= TXT record or well-known URI). NAPTR is supposed to solve this by allowing a more complex value, but it su= ffers from being overly complicated and generally unavailable in most hosti= ng environments. When it comes to social web protocols, we are forced to use what's practica= l, not what is architecturally correct - or fail to gain any meaningful ado= ption. So while I agree with you when it comes to developing protocols like= OAuth, where it is legitimate to raise the bar beyond what existing code c= an do, it is not when dealing with web protocols that largely live on a pre= tty limited/restrictive environment. EHL > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Patrik F=E4ltstr=F6m > Sent: Friday, July 23, 2010 9:13 PM > To: Blaine Cook > Cc: Apps Discuss > Subject: Re: [apps-discuss] How to find a service? >=20 >=20 > On 24 jul 2010, at 02.09, Blaine Cook wrote: >=20 > > Those considering DNS-based solutions are well-advised to consider the > > relative programmability of the deployed HTTP and DNS infrastructures, > > and the ever-increasing need for new record types. >=20 > I want people to remember that there is a difference between thinking of > good architecture (that drives how libraries etc are designed) and how > people might do things based on how an existing library might be written. >=20 > Patrik From eran@hueniverse.com Sat Jul 24 00:18:44 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 709D73A6869 for ; Sat, 24 Jul 2010 00:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=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 d1VNjRpO7T2O for ; Sat, 24 Jul 2010 00:18:43 -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 2CB6F3A6843 for ; Sat, 24 Jul 2010 00:18:42 -0700 (PDT) Received: (qmail 2309 invoked from network); 24 Jul 2010 07:19:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Jul 2010 07:19:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 24 Jul 2010 00:19:00 -0700 From: Eran Hammer-Lahav To: John Panzer , Blaine Cook Date: Sat, 24 Jul 2010 00:18:54 -0700 Thread-Topic: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard Thread-Index: Acsq/2aG9Q3H3Wx/Q0aBa9YNzRUyCg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FD8C@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: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 24 Jul 2010 07:18:44 -0000 > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Friday, July 23, 2010 6:37 PM > To: Blaine Cook > Cc: Eran Hammer-Lahav; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web > Host Metadata) to Proposed Standard >=20 > That's also why I don't see "stop when you see the rel you're looking for= " as a > big help - you actually are looking for a collection where rel=3Dx in the= general > case (think rel=3Dalternate for a common example from other formats). So= you > have to get the set of links in some context, which could be the host-met= a > document or the target of the lrdd template. The only way to avoid this is to forbid using link templates for anything o= ther than a single 'lrdd' link template, or even remove templates completel= y and using a single link (non template) with relation 'lrdd' and a pre-def= ined way to include the context URI as a parameter. Otherwise, link templat= es at the host-meta level are semantically equivalent to those in a LRDD do= cument, not matter how much you try to pretend they are to be ignored. Can you offer some useful and predictable guidelines when a client should u= se link templates in host-meta and when it should not? When it should only = look for a single 'lrdd' document for all its metadata needs? How should an= application developer decide where to put resource-specific links, if we f= ollow your approach and treat the two sets (link templates in host-meta, an= d links in a LRDD document) differently? For your approach to work, we need to be able to solve these questions beca= use semantically, all these links share the same context URI. We created a = mechanism using link templates and defined it well. The processing rules in= 4.2 are just the logical implementation of this framework. =20 > But in general I agree with Blaine's primary objection; this adds an incl= ude > model that has not been proven and which forces clients to provision for = a > nearly arbitrary number of worst-case http fetches. Servers can always do stupid things, like use too many redirections which r= equires the same kind of handling. From a code perspective, processing link= s from both host-meta and LRDD isn't that much more work - you already have= to process both. The ability to link to more than one LRDD document is som= ething that keeps coming up again and again when people want to reuse a des= criptor document available elsewhere. 'lrdd' links have a very limited include semantic by limiting it to one lev= el. > Query: Is it at least possible for a server to automatically merge multi= ple > rel=3Dlrdd targets and serve up a single composite rel=3Dlrdd target reso= urce to > clients without impacting semantics? It's not clear to me from the spec. No idea what you mean. > On Friday, July 23, 2010, Blaine Cook wrote: > > On 23 July 2010 21:12, Eran Hammer-Lahav > wrote: > >> ** If this is not clear, I am happy to make it more explicit in sectio= n 4.2, > including adding a full procedure for clients looking for a specific link= . > > > > +1 - In my reading of 4.2, I had overlooked the sentence in 4 that > > describes stopping whenever a suitable link relation is found. With > > that processing rule in place, the semantic is clear and simple. > > > >> However, if people would like to simplify this a bit, I am open to (bu= t not > excited about) making a small change in which clients will first look for= (any) > 'lrdd' link templates, process them, and only then look for other link- > templates in host-meta. This exception will deviate from the normal XRD > processing rules of document order, but will move from a potential comple= x > mix from link sources to a two stage procedure (LRDD links, then host-met= a > link templates). Note that this does not solve the basic requirement to > construct the full resource descriptor from multiple location, only the o= rder in > which that is done. > > > > I'm not sure what others think about this, but I personally prefer > > this approach (LRDD-first, followed by host-level templates). The > > reasoning is that this gives LRDD profiles the ability to over-ride > > host-level decisions, whereas strictly following document ordering > > means that hosts could potentially force all users to use a single URL > > for a given rel value. > > > > The challenge is not so much that the hosts could force this (because > > a "malicious" host could over-write the rel value in ever user's LRDD > > document), but that interop becomes more challenging since any parser > > that does LRDD-first *might* disagree with a strictly ordered parser > > (an example where this is a real possibility: three parsers, one > > SAX-based, one XPath based, and one DOM-based, may come up with very > > different results if we rely on document ordering alone). > > > > b. > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > >=20 > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer From algermissen1971@mac.com Sat Jul 24 02:12:59 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 7927B3A67B2 for ; Sat, 24 Jul 2010 02:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bKOUafbCmQc for ; Sat, 24 Jul 2010 02:12:58 -0700 (PDT) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by core3.amsl.com (Postfix) with ESMTP id 2291E3A63D3 for ; Sat, 24 Jul 2010 02:12:58 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from [10.0.1.5] ([84.75.182.201]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L6200CPS1L9GD40@asmtp015.mac.com> for discuss@apps.ietf.org; Sat, 24 Jul 2010 02:12:49 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007240023 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-07-24_01:2010-07-24, 2010-07-24, 1970-01-01 signatures=0 From: Jan Algermissen In-reply-to: <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FD88@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 24 Jul 2010 11:12:44 +0200 Content-transfer-encoding: quoted-printable Message-id: <057374F5-65D3-449D-AF2E-A9EDBEEE62F0@mac.com> References: <3FA99C66-4175-4A70-8EFB-AF2D8DEA5F74@frobbit.se> <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FD88@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss Subject: Re: [apps-discuss] How to find a service? 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, 24 Jul 2010 09:12:59 -0000 On Jul 24, 2010, at 8:31 AM, Eran Hammer-Lahav wrote: > SRV and NAPTR records are a great example of where standards fails = when it comes to practical deployment. In many cases, we need to = discover a service endpoint, not just a service host (and port). SRV = excels in its simplicity but because it cannot store a URI, it fails to = cover these use cases. This leaves the problem largely unsolved (leading = to the use of a complimentary TXT record or well-known URI). Maybe this is of interest in this context: = http://www.infoq.com/articles/rest-discovery-dns Jan >=20 > NAPTR is supposed to solve this by allowing a more complex value, but = it suffers from being overly complicated and generally unavailable in = most hosting environments. >=20 > When it comes to social web protocols, we are forced to use what's = practical, not what is architecturally correct - or fail to gain any = meaningful adoption. So while I agree with you when it comes to = developing protocols like OAuth, where it is legitimate to raise the bar = beyond what existing code can do, it is not when dealing with web = protocols that largely live on a pretty limited/restrictive environment. >=20 > EHL >=20 >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Patrik F=E4ltstr=F6m >> Sent: Friday, July 23, 2010 9:13 PM >> To: Blaine Cook >> Cc: Apps Discuss >> Subject: Re: [apps-discuss] How to find a service? >>=20 >>=20 >> On 24 jul 2010, at 02.09, Blaine Cook wrote: >>=20 >>> Those considering DNS-based solutions are well-advised to consider = the >>> relative programmability of the deployed HTTP and DNS = infrastructures, >>> and the ever-increasing need for new record types. >>=20 >> I want people to remember that there is a difference between thinking = of >> good architecture (that drives how libraries etc are designed) and = how >> people might do things based on how an existing library might be = written. >>=20 >> Patrik >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss ----------------------------------- Jan Algermissen, Consultant NORD Software Consulting Mail: algermissen@acm.org Blog: http://www.nordsc.com/blog/ Work: http://www.nordsc.com/ ----------------------------------- From ietfc@btconnect.com Sat Jul 24 04:36:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F283A6847 for ; Sat, 24 Jul 2010 04:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNACrmqEMXcL for ; Sat, 24 Jul 2010 04:35:59 -0700 (PDT) Received: from c2bthomr14.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id E74183A68BD for ; Sat, 24 Jul 2010 04:35:58 -0700 (PDT) Received: from pc6 (host86-145-196-228.range86-145.btcentralplus.com [86.145.196.228]) by c2bthomr14.btconnect.com with SMTP id FTT28777; Sat, 24 Jul 2010 12:36:02 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C4AD021.037C, actions=tag Message-ID: <00d501cb2b1b$6c68a5e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "John C Klensin" References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> Date: Sat, 24 Jul 2010 12:31:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0204.4C4AD027.0071,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: Apps Discuss Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 24 Jul 2010 11:36:01 -0000 Has anyone actually read this liaison? I ask because every day, I click on the link, my browser spins its little icon for five minutes, after which I move on to something more productive:-( Tom Petch ----- Original Message ----- From: "John C Klensin" ; "John C Klensin" To: "Patrik Fältström" ; "Nicolas Williams" ; "Patrik Fltstr m" ; "Nicolas Williams" Cc: "Apps Discuss" ; "IAB IAB" ; "Apps Discuss" ; "IAB IAB" Sent: Friday, July 23, 2010 11:55 AM Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! > --On Friday, July 23, 2010 07:58 +0200 Patrik Fltstr m > wrote: > > { https://datatracker.ietf.org/liaison/903/ } > > > That is basically what they want to do, right? > > > > In IETF we have the DDDS algorithm that is in use for E.164 > > numbers, and similar mechanism is used for RFID tags by ONS > > that ECDS has defined. > > > > So yes, that could be interesting. And I think we IETF can do > > something here. And because of that, yes, they might walk into > > "our turf". > > > > But the question is what to tell ITU. > > > > 1. That they of course can work with this > > > > 2. That IETF thought OIDs in reality is an ISO thing, not ITU > > thing > > Clarification: OIDs came out of one of the "ISO/IEC - ITU Joint > Development Agreement" projects. The relevant standards have > both ISO/IEC [JTC1] numbers and ISO numbers. And there are > allocation arcs, separately, for both. Indeed, one of the > questions we would have to sort out with ITU is whether ISO is > on board or whether this is really a proposal about the ITU arc > only. > > > > 3. That IETF is the SDO where DNS, and DNS like mechanisms are > > discussed > > > > 4. That we have a history of good cooperation between ITU and > > IETF regarding for example ENUM > > Well... :-( > > > 5. That IETF is happy to do (is doing?) a resolution mechanism > > from OIDs to something else using DNS. > > Wouldn't one set of sub-arcs of OIDs be more accurate here? > > > The trouble is maybe how to formulate 5? > > john From patrik@frobbit.se Sun Jul 25 00:21:44 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 44D683A6859 for ; Sun, 25 Jul 2010 00:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R2-2VpB1yNO for ; Sun, 25 Jul 2010 00:21:24 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id BAAFA3A6864 for ; Sun, 25 Jul 2010 00:21:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 96778CCA585E; Sun, 25 Jul 2010 09:21:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2kq0RwSkeup; Sun, 25 Jul 2010 09:21:42 +0200 (CEST) Received: from dhcp-65f8.meeting.ietf.org (dhcp-65f8.meeting.ietf.org [130.129.101.248]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id F2A52CCA5853; Sun, 25 Jul 2010 09:21:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-407--1059884241" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Priority: 3 In-Reply-To: <00d501cb2b1b$6c68a5e0$4001a8c0@gateway.2wire.net> Date: Sun, 25 Jul 2010 09:21:49 +0200 Content-Transfer-Encoding: 7bit Message-Id: <67B58D1A-56E9-4843-8C32-A543CC61238A@frobbit.se> References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> <00d501cb2b1b$6c68a5e0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss , John C Klensin Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 25 Jul 2010 07:21:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-407--1059884241 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I read it when it arrived, and not from the Liaison page, but I now = checked, and the two files are (which I reach by "clicking on the link" = when being at the IETF in Maastricht): https://datatracker.ietf.org/documents/LIAISON/file1036.pdf https://datatracker.ietf.org/documents/LIAISON/file1037.pdf If you have problems reaching the files, let me know and I will unicast = them. Patrik On 24 jul 2010, at 12.31, t.petch wrote: > Has anyone actually read this liaison? I ask because every day, I = click on the > link, my browser spins its little icon for five minutes, after which I = move on > to something more productive:-( >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "John C Klensin" ; "John C Klensin" = > To: "Patrik F=E4ltstr=F6m" ; "Nicolas Williams" > ; "Patrik Fltstr m" ; = "Nicolas > Williams" > Cc: "Apps Discuss" ; "IAB IAB" ; = "Apps > Discuss" ; "IAB IAB" > Sent: Friday, July 23, 2010 11:55 AM > Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T = regarding > OIDs --volunteer needed! >=20 >=20 >> --On Friday, July 23, 2010 07:58 +0200 Patrik Fltstr m >> wrote: >>=20 >> { https://datatracker.ietf.org/liaison/903/ } >>=20 >>> That is basically what they want to do, right? >>>=20 >>> In IETF we have the DDDS algorithm that is in use for E.164 >>> numbers, and similar mechanism is used for RFID tags by ONS >>> that ECDS has defined. >>>=20 >>> So yes, that could be interesting. And I think we IETF can do >>> something here. And because of that, yes, they might walk into >>> "our turf". >>>=20 >>> But the question is what to tell ITU. >>>=20 >>> 1. That they of course can work with this >>>=20 >>> 2. That IETF thought OIDs in reality is an ISO thing, not ITU >>> thing >>=20 >> Clarification: OIDs came out of one of the "ISO/IEC - ITU Joint >> Development Agreement" projects. The relevant standards have >> both ISO/IEC [JTC1] numbers and ISO numbers. And there are >> allocation arcs, separately, for both. Indeed, one of the >> questions we would have to sort out with ITU is whether ISO is >> on board or whether this is really a proposal about the ITU arc >> only. >>=20 >>=20 >>> 3. That IETF is the SDO where DNS, and DNS like mechanisms are >>> discussed >>>=20 >>> 4. That we have a history of good cooperation between ITU and >>> IETF regarding for example ENUM >>=20 >> Well... :-( >>=20 >>> 5. That IETF is happy to do (is doing?) a resolution mechanism >>> from OIDs to something else using DNS. >>=20 >> Wouldn't one set of sub-arcs of OIDs be more accurate here? >>=20 >>> The trouble is maybe how to formulate 5? >>=20 >> john >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-407--1059884241 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMS+YOrMabGguI180RAh6KAKCCOaF3SHNl7NSfnaCRQ1iSKviytACcCUrY 3s71F2SIJ8NPOD5l3WCoe1o= =DGM0 -----END PGP SIGNATURE----- --Apple-Mail-407--1059884241-- From James.H.Manger@team.telstra.com Sun Jul 25 06:51: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 098D33A698C for ; Sun, 25 Jul 2010 06:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.206 X-Spam-Level: * X-Spam-Status: No, score=1.206 tagged_above=-999 required=5 tests=[AWL=-2.107, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, RELAY_IS_203=0.994] 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 gdJl2uKu3jQj for ; Sun, 25 Jul 2010 06:51:39 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id B1AA63A6973 for ; Sun, 25 Jul 2010 06:51:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,257,1278252000"; d="scan'208";a="6652093" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 25 Jul 2010 23:51:55 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6053"; a="4819701" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcavi.tcif.telstra.com.au with ESMTP; 25 Jul 2010 23:51:57 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Sun, 25 Jul 2010 23:51:57 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , John Panzer , Blaine Cook Date: Sun, 25 Jul 2010 23:51:56 +1000 Thread-Topic: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard Thread-Index: Acsq/2aG9Q3H3Wx/Q0aBa9YNzRUyCgA/ZRa8 Message-ID: <255B9BB34FB7D647A506DC292726F6E112677D3D8A@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FD8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FD8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 25 Jul 2010 13:51:43 -0000 I don't think "lrdd-first followed by host-meta templates" is a better appr= oach than the current host-meta rules (host-meta templates and 'lrdd' includes in doc= ument order). The "lrdd-first" proposal means a client always has to make the extra reque= st to get an lrdd (when present), even when the required link is already in the host-meta that the client alr= eady has. host-meta is a mechanism where the host is in charge (ahead of resources). "lrdd-first" would confuse that. A host would be in charge while it doesn't put a 'lrdd' link in host-meta, = but as soon as it includes such a link all the host's other link templates can be overridden. That is a bad choice to force a host to make. I don't think SAX-based, XPath-based, or DOM-based parsers make that much d= ifference here. The current host-meta requires looping through link templates in document o= rder. All parser varieties can do that. It isn't much (if any) harder than separa= tely finding 'lrdd' templates and templates for a specific rel value. Adding a rule that "host-meta can have, at most, a single 'lrdd' link" woul= d reduce the risk that lots of hosts include lots of 'lrdd's without consider= ing the performance impact on clients. I doubt this is that helpful, however. A host can be slow (bandwidth, redir= ects, no caching...) even with 0 or 1 'lrdd' links. Other hosts can be tuned for performance. I recommend keeping the current host-meta rules. P.S. One minor typo: section 4.2, item 3.2, change "The client adds any link found" to "The client adds any links found" -- James Manger ________________________________________ From: apps-discuss-bounces@ietf.org [apps-discuss-bounces@ietf.org] On Beha= lf Of Eran Hammer-Lahav [eran@hueniverse.com] Sent: 24 July 2010 17:18 To: John Panzer; Blaine Cook Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host= Metadata) to Proposed Standard > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Friday, July 23, 2010 6:37 PM > To: Blaine Cook > Cc: Eran Hammer-Lahav; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web > Host Metadata) to Proposed Standard > > That's also why I don't see "stop when you see the rel you're looking for= " as a > big help - you actually are looking for a collection where rel=3Dx in the= general > case (think rel=3Dalternate for a common example from other formats). So= you > have to get the set of links in some context, which could be the host-met= a > document or the target of the lrdd template. The only way to avoid this is to forbid using link templates for anything o= ther than a single 'lrdd' link template, or even remove templates completel= y and using a single link (non template) with relation 'lrdd' and a pre-def= ined way to include the context URI as a parameter. Otherwise, link templat= es at the host-meta level are semantically equivalent to those in a LRDD do= cument, not matter how much you try to pretend they are to be ignored. Can you offer some useful and predictable guidelines when a client should u= se link templates in host-meta and when it should not? When it should only = look for a single 'lrdd' document for all its metadata needs? How should an= application developer decide where to put resource-specific links, if we f= ollow your approach and treat the two sets (link templates in host-meta, an= d links in a LRDD document) differently? For your approach to work, we need to be able to solve these questions beca= use semantically, all these links share the same context URI. We created a = mechanism using link templates and defined it well. The processing rules in= 4.2 are just the logical implementation of this framework. > But in general I agree with Blaine's primary objection; this adds an incl= ude > model that has not been proven and which forces clients to provision for = a > nearly arbitrary number of worst-case http fetches. Servers can always do stupid things, like use too many redirections which r= equires the same kind of handling. From a code perspective, processing link= s from both host-meta and LRDD isn't that much more work - you already have= to process both. The ability to link to more than one LRDD document is som= ething that keeps coming up again and again when people want to reuse a des= criptor document available elsewhere. 'lrdd' links have a very limited include semantic by limiting it to one lev= el. > Query: Is it at least possible for a server to automatically merge multi= ple > rel=3Dlrdd targets and serve up a single composite rel=3Dlrdd target reso= urce to > clients without impacting semantics? It's not clear to me from the spec. No idea what you mean. > On Friday, July 23, 2010, Blaine Cook wrote: > > On 23 July 2010 21:12, Eran Hammer-Lahav > wrote: > >> ** If this is not clear, I am happy to make it more explicit in sectio= n 4.2, > including adding a full procedure for clients looking for a specific link= . > > > > +1 - In my reading of 4.2, I had overlooked the sentence in 4 that > > describes stopping whenever a suitable link relation is found. With > > that processing rule in place, the semantic is clear and simple. > > > >> However, if people would like to simplify this a bit, I am open to (bu= t not > excited about) making a small change in which clients will first look for= (any) > 'lrdd' link templates, process them, and only then look for other link- > templates in host-meta. This exception will deviate from the normal XRD > processing rules of document order, but will move from a potential comple= x > mix from link sources to a two stage procedure (LRDD links, then host-met= a > link templates). Note that this does not solve the basic requirement to > construct the full resource descriptor from multiple location, only the o= rder in > which that is done. > > > > I'm not sure what others think about this, but I personally prefer > > this approach (LRDD-first, followed by host-level templates). The > > reasoning is that this gives LRDD profiles the ability to over-ride > > host-level decisions, whereas strictly following document ordering > > means that hosts could potentially force all users to use a single URL > > for a given rel value. > > > > The challenge is not so much that the hosts could force this (because > > a "malicious" host could over-write the rel value in ever user's LRDD > > document), but that interop becomes more challenging since any parser > > that does LRDD-first *might* disagree with a strictly ordered parser > > (an example where this is a real possibility: three parsers, one > > SAX-based, one XPath based, and one DOM-based, may come up with very > > different results if we rely on document ordering alone). > > > > b. > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From Jeff.Hodges@KingsMountain.com Sun Jul 25 23:20: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 BD5813A69B9 for ; Sun, 25 Jul 2010 23:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 7zrpdpDJ2IQt for ; Sun, 25 Jul 2010 23:20:39 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 026E13A69E2 for ; Sun, 25 Jul 2010 23:20:38 -0700 (PDT) Received: (qmail 7189 invoked by uid 0); 26 Jul 2010 06:20:59 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 26 Jul 2010 06:20:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Hl7A+YCehmVE7PukiABntllCpM/RK18tBlQPZQxfJauCtKFrEo7pUkS4KEMfIh+YXAHVrO67rNvLnjGzA0Lk4VG4liMqxpFX+079reJeKxQcANVyAI1yqI8kYGcfN6hg; Received: from [87.213.214.66] (helo=[192.168.1.61]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OdH3a-0007ly-Ux for apps-discuss@ietf.org; Mon, 26 Jul 2010 00:20:59 -0600 Message-ID: <4C4D2947.8010904@KingsMountain.com> Date: Sun, 25 Jul 2010 23:20:55 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 87.213.214.66 authed with jeff.hodges+kingsmountain.com} Subject: [apps-discuss] HASMAT BoF - HTTP Application Security Minus Authentication and Transport 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, 26 Jul 2010 06:20:40 -0000 Hi, We will be hosting the "HTTP Application Security Minus Authentication and Transport (HASMAT)" Birds-of-a-Feather (BoF) session at IETF-78 in Maastricht on TUESDAY, July 27, 2010 @1300h in 0.1 London (see [0] for mailing list). The purpose of IETF BoFs is to determine whether there is a problem worth solving, and whether the IETF is the right group to solve it. To that end, the problem statement is summarized below in the Draft HASMAT Working Group Charter, and is drawn from this paper [1]. Various facets of this work are already underway, as outlined below in the draft WG charter, e.g. Strict Transport Security (STS) [2]. Of course the scope of "HTTP application security" is quite broad (as outlined in [1]), thus the intent is to coordinate this work closely with related work likely to land in the W3C (and possibly other orgs), e.g. Content Security Policy (CSP) [3]. We have created a public mailing list [0] for pre-BoF discussion -- hasmat@ietf.org -- to which you can freely subscribe here: We encourage all interested parties to join the hasmat@ mailing list and engage in the on-going discussion there, as well as attend the BoF if you're in Maastricht. thanks, =JeffH (current IETF HTTPstate WG chair) Peter Saint-Andre (IETF Applications Area Director) Hannes Tschofenig (IAB, IETF WG chair) ---------------------------------------------------- [0] HASMAT mailing list. https://www.ietf.org/mailman/listinfo/hasmat [1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy Framework", W2SP position paper, 2010. http://w2spconf.com/2010/papers/p11.pdf [2] Hodges, Jackson, and Barth, "Strict Transport Security (STS)" http://tools.ietf.org/html/draft-hodges-strict-transport-sec see also: http://en.wikipedia.org/wiki/Strict_Transport_Security [3] Sterne and Stamm, "Content Security Policy (CSP)". https://wiki.mozilla.org/Security/CSP/Specification see also: http://people.mozilla.org/~bsterne/content-security-policy/ https://wiki.mozilla.org/Security/CSP/Design_Considerations ### HTTP Application Security Minus Authentication and Transport BOF ================================================================ TUESDAY, July 27, 2010 1300-1500 Afternoon Session I Room: 0.1 London Chairs: Hannes Tschofenig and Jeff Hodges 5 min Agenda bashing (Chairs) 15 min Problem space description (Jeff) 15 min Related Work (Adam) 20 min Proposed Documents: Short summary by the authors http://tools.ietf.org/html/draft-abarth-mime-sniff-05 http://tools.ietf.org/html/draft-hodges-strict-transport-sec-02 http://tools.ietf.org/html/draft-abarth-origin-07 15 min Presentation of charter text (Chairs) 40 min Discussion of charter text and choice of the initial specifications (All) 10 min Conclusion (Chairs/ADs) ### Draft Charter for HASMAT: HTTP Application Security Minus Authentication and Transport WG Problem Statement Although modern Web applications are built on top of HTTP, they provide rich functionality and have requirements beyond the original vision of static web pages. HTTP, and the applications built on it, have evolved organically. Over the past few years, we have seen a proliferation of AJAX-based web applications (AJAX being shorthand for asynchronous JavaScript and XML), as well as Rich Internet Applications (RIAs), based on so-called Web 2.0 technologies. These applications bring both luscious eye-candy and convenient functionality, e.g. social networking, to their users, making them quite compelling. At the same time, we are seeing an increase in attacks against these applications and their underlying technologies. The list of attacks is long and includes Cross-Site-Request Forgery (CSRF)-based attacks, content-sniffing cross-site-scripting (XSS) attacks, attacks against browsers supporting anti-XSS policies, clickjacking attacks, malvertising attacks, as well as man-in-the-middle (MITM) attacks against "secure" (e.g. Transport Layer Security (TLS/SSL)-based) web sites along with distribution of the tools to carry out such attacks (e.g. sslstrip). Objectives and Scope With the arrival of new attacks the introduction of new web security indicators, security techniques, and policy communication mechanisms have sprinkled throughout the various layers of the Web and HTTP. The goal of this working group is to standardize a small number of selected specifications that have proven to improve security of Internet Web applications. The requirements guiding the work will be taken from the Web application and Web security communities. Initial work will be limited to the following topics: - Same origin policy, as discussed in draft-abarth-origin - Strict transport security, as discussed in draft-hodges-strict-transport-sec - Media type sniffing, as discussed in draft-abarth-mime-sniff In addition, this working group will consider the overall topic of HTTP application security and compose a "problem statement and requirements" document that can be used to guide further work. This working group will work closely with IETF Apps Area WGs (such as HYBI, HTTPstate, and HTTPbis), as well as W3C WebApps working group(s). Out of Scope As noted in this working group's title, this working group's scope does not include working on HTTP Authentication nor underlying transport (secure or not) topics. So, for example, these items are out-of-scope for this WG: - Replacements for BASIC and DIGEST authentication - New transports (e.g. SCTP and the like) Deliverables 1. A document illustrating the security problems Web applications are facing and listing design requirements. This document shall be Informational. 2. A selected set of technical specifications documenting deployed HTTP-based Web security solutions. These documents shall be Standards Track. Goals and Milestones Oct 2010 Submit "HTTP Application Security Problem Statement and Requirements" as initial WG item. Oct 2010 Submit "Media Type Sniffing" as initial WG item. Oct 2010 Submit "Web Origin Concept" as initial WG item. Oct 2010 Submit "Strict Transport Security" as initial WG item. Feb 2011 Submit "HTTP Application Security Problem Statement and Requirements" to the IESG for consideration as an Informational RFC. Mar 2011 Submit "Media Type Sniffing" to the IESG for consideration as a Standards Track RFC. Mar 2011 Submit "Web Origin Concept" to the IESG for consideration as a Standards Track RFC. Mar 2011 Submit "Strict Transport Security" to the IESG for consideration as a Standards Track RFC. Apr 2011 Possible re-chartering ### From alexey.melnikov@isode.com Mon Jul 26 01:29:25 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 DDE983A683A for ; Mon, 26 Jul 2010 01:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_50=0.001, 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 l3pfhdGvRSVD for ; Mon, 26 Jul 2010 01:29:24 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id ED0243A687D for ; Mon, 26 Jul 2010 01:29:23 -0700 (PDT) Received: from [130.129.119.237] (dhcp-77ed.meeting.ietf.org [130.129.119.237]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Jul 2010 09:29:44 +0100 Message-ID: <4C4D40E9.4030409@isode.com> Date: Mon, 26 Jul 2010 10:01:45 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: "apps-discuss@ietf.org" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080206000500050201050409" Subject: [apps-discuss] Applications Area Errata 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, 26 Jul 2010 08:29:26 -0000 This is a multi-part message in MIME format. --------------080206000500050201050409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings, IESG has agreed to reduce the number of reported but unresolved errata. Please review Errata for various Applications Area RFCs to see if you can help with any of them. Peter and I will also be sending some specific requests to relevant WGs. Best Regards, Peter and Alexey --------------080206000500050201050409 Content-Type: text/html; charset=ISO-8859-1; name="Errata for the Applications Area RFCs.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Errata for the Applications Area RFCs.html" Errata for the Applications Area RFCs
RFC Number
(Errata ID)		 Section Type Source of RFC Responsible WG/BOF/person
 Submitted By
RFC2157 (1387) 6.2 Editorial mixer (app)
Frank Ellermann
RFC2288 (775) - Technical urn (app) URNBIS BOF
 Alfred Hoenes
RFC2426 (868) 4 Technical asid (app) VCARDDAV
 Javier Godoy
RFC2426 (869) 4 Technical asid (app)
Javier Godoy
RFC2426 (870) 4 Technical asid (app)
Javier Godoy
RFC2426 (872) 7 Technical asid (app)
Javier Godoy
RFC2426 (1550) 4 Technical asid (app)
Markus Lorenz
RFC2616 (411) 14.3 Technical http (app) HTTPBIS
 WooJin Chung
RFC2617 (1649) 5 Technical http (app)
Ganga Mahesh Siddem
RFC2617 (1914) 3.2.2.1 Technical http (app)
Larry Westrick
RFC2821 (374) 4.2.5 Technical drums (app) YAM
 Mathias Koerber
RFC2821 (375) 4.2.5 Technical drums (app)
Jochen Topf
RFC3659 (901) 7.5.4 Technical ftpext (app) FTPEXT2 BOF
 Alfred Hoenes
RFC3659 (1500) 7.7.4 Technical ftpext (app)
Maik Reiß (Reiss)
RFC3977 (2003) GLOBAL Technical nntpext (app)
Julien Élie
RFC3977 (2004) GLOBAL Technical nntpext (app)
Julien Élie
RFC3982 (1305) 4 Technical crisp (app)
Marcos Sanz
RFC4992 (1009) - Technical crisp (app)
Alfred Hoenes
RFC4512 (2281) A.3 Editorial ldapbis (app)
Alfred Hoenes
RFC4519 (1761) 3.10 Technical ldapbis (app)
Fotis Georgatos
RFC4823 (2282) 7.4.4 Technical ediint (app)
Alfred Hoenes
RFC4823 (2283) 9 Technical ediint (app)
Alfred Hoenes
RFC4918 (1207) 9.10.1 Technical webdav (app)
Julian Reschke
RFC4918 (1519) 8.3 Technical webdav (app)
Manfred Baedke
RFC4918 (1371) 9.2 Editorial webdav (app)
Julian Reschke
RFC5162 (1365) 1. (ff.) Technical lemonade (app) Lemonade/MORG
 Alfred Hoenes
RFC5465 (2318) 3.1 Technical lemonade (app)
David Woodhouse
RFC5546 (2331) 3.4. Technical calsify (app) CALSIFY
 Filip Navara












RFC3798 (691)


YAM
RFC3798 (692)




RFC4409 (98)




RFC4409 (2393)




RFC5321 (1543)




RFC5321 (1851)




RFC5322 (1905)




RFC5322 (1906)




RFC5322 (2104)




RFC5119 (1324)


URNBIS
RFC5134 (1325)




RFC5134 (1328)




RFC5279 (1516)




RFC4229 (161)


HTTPBIS
RFC4229 (837)




RFC4521 (69)


LDAP
RFC4524 (68)




RFC4526 (67)




RFC4529 (66)




RFC4529 (853)




RFC4532 (65)




RFC4234 (159)


ABNF
RFC4234 (777)




RFC4234 (778)




RFC4234 (783)




RFC4234 (866)




RFC5234 (1423)




RFC5234 (1424)




 
--------------080206000500050201050409-- From jav@sics.se Mon Jul 26 02:30: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 363B63A6AD3 for ; Mon, 26 Jul 2010 02:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oSUT8fGc+po for ; Mon, 26 Jul 2010 02:30:13 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 2AAA43A6AA1 for ; Mon, 26 Jul 2010 02:30:12 -0700 (PDT) Received: from [130.129.113.249] (dhcp-71f9.meeting.ietf.org [130.129.113.249]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id B8EF040127; Mon, 26 Jul 2010 11:30:31 +0200 (CEST) From: Javier Ubillos To: "apps-discuss@ietf.org" In-Reply-To: <4C4D40E9.4030409@isode.com> References: <4C4D40E9.4030409@isode.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-2Hh7dLendVj6Q2d388pG" Date: Mon, 26 Jul 2010 11:30:31 +0200 Message-ID: <1280136631.9738.9.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Subject: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 09:30:21 -0000 --=-2Hh7dLendVj6Q2d388pG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As being discussed right now in apparea, here's an individual submisison. Name Based Sockets Draft: http://www.ietf.org/id/draft-ubillos-name-based-sockets-01.txt Presentation: http://www.sics.se/~jav/ietf78/namebasedsockets-IETF78-apps.pdf Consider it a real "request for comments", because I do want comments :) The question to apps-discuss is, what features are wanted/important to application developers? What should we do next? What would make this fly? // Javier Ubillos --=-2Hh7dLendVj6Q2d388pG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxNVbUACgkQGBo5FLRz4gqAGACeJGeiWl7XoAKoERlLQhRE2HL4 QDUAnifMIlfLGHD1OY+LyaXpRhnLDpQ4 =K4YP -----END PGP SIGNATURE----- --=-2Hh7dLendVj6Q2d388pG-- From stpeter@stpeter.im Mon Jul 26 02:49: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 4A4D23A6A58; Mon, 26 Jul 2010 02:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 hhPrKO6EZ8n9; Mon, 26 Jul 2010 02:49:22 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2E29B3A6885; Mon, 26 Jul 2010 02:49:22 -0700 (PDT) Received: from dhcp-65ef.meeting.ietf.org (dhcp-65ef.meeting.ietf.org [130.129.101.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E81C840074; Mon, 26 Jul 2010 03:49:32 -0600 (MDT) Message-ID: <4C4D5A28.4080703@stpeter.im> Date: Mon, 26 Jul 2010 11:49:28 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: 78attendees@ietf.org, "apps-discuss@ietf.org" X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] lost items from Apps Area meeting 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, 26 Jul 2010 09:49:23 -0000 Two items were lost in 2.1 Colorado (Apps Area General Meeting) just now: a cell phone and a small one-time password generator. Please go to the IETF registration desk to retrieve your item(s). Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From dave@cridland.net Mon Jul 26 03:44:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A6D3A6AC1 for ; Mon, 26 Jul 2010 03:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 WvTl8+tUsrGz for ; Mon, 26 Jul 2010 03:44:43 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id BA60A3A68C3 for ; Mon, 26 Jul 2010 03:44:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 01254116809F; Mon, 26 Jul 2010 11:45:03 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (localhost.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eop80IyJwX3c; Mon, 26 Jul 2010 11:45:00 +0100 (BST) Received: from puncture (puncture [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id EB732116809E; Mon, 26 Jul 2010 11:45:00 +0100 (BST) References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> In-Reply-To: <1280136631.9738.9.camel@bit> MIME-Version: 1.0 Message-Id: <2378.1280141100.936023@puncture> Date: Mon, 26 Jul 2010 11:45:00 +0100 From: Dave Cridland To: Javier Ubillos , General discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 10:44:46 -0000 On Mon Jul 26 10:30:31 2010, Javier Ubillos wrote: > The question to apps-discuss is, what features are wanted/important > to > application developers? > What should we do next? > What would make this fly? I looked at this with some interest. As some initial comments, I'm a little concerned about section 4 - mostly in as much as not understanding the implications. I'm also disappointed to see that the port remains a number - I would have thought a string (or at least the option for one) would be useful here, allowing SRV record lookup, for example. I suspect that a series of socket options for controlling the almost bottomless options here would be useful, too. I suspect that if this could be made to handle non-blocking, single-attempt, SRV lookup, host lookup, and connection, then it would be very interesting to application developers. If it handled connection timeouts and retries transparently, all the more so. This would give application developers a reason to use this even when SHIM6, etc, is not widely deployed. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From jav@sics.se Mon Jul 26 04:04:25 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 0F7183A6836 for ; Mon, 26 Jul 2010 04:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwfdeGuyfw+L for ; Mon, 26 Jul 2010 04:04:24 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 159FF3A6834 for ; Mon, 26 Jul 2010 04:04:24 -0700 (PDT) Received: from [130.129.113.249] (dhcp-71f9.meeting.ietf.org [130.129.113.249]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 4DD9A400D7; Mon, 26 Jul 2010 13:04:44 +0200 (CEST) From: Javier Ubillos To: Dave Cridland In-Reply-To: <2378.1280141100.936023@puncture> References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-0TH5WCI6EHtEoGSvrO0e" Date: Mon, 26 Jul 2010 13:04:40 +0200 Message-ID: <1280142280.9738.34.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 11:04:25 -0000 --=-0TH5WCI6EHtEoGSvrO0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2010-07-26 at 11:45 +0100, Dave Cridland wrote: > As some initial comments, I'm a little concerned about section 4 - =20 > mostly in as much as not understanding the implications. >=20 > I'm also disappointed to see that the port remains a number - I would =20 > have thought a string (or at least the option for one) would be =20 > useful here, allowing SRV record lookup, for example. About portnumbers, we are still discussing what to do about them. In Christian Vogts article, the port number syntax is kept, but both port fields are rather used as a flow identifier. Instead, the socket has a "service" field, to denote which service one is looking for [ http://tinyurl.com/2c3sndy ]. Personally, I'd like to explore ways of making the port fields both be more router/firewall friendly and working as a kind of flow-identifiers. E.g., that the port facing the "server" is a well known one, and that the sender port is used as a flow identifier. We're still exploring :) > I suspect that a series of socket options for controlling the almost =20 > bottomless options here would be useful, too. I agree totally, some ioctl() or, in abstractions some way of passing on paramers to shut of (or turn on) certain features is a must. If not for certain applications, definitely for development and debugging. =20 > I suspect that if this could be made to handle non-blocking, =20 > single-attempt, SRV lookup, host lookup, and connection, then it =20 > would be very interesting to application developers. If it handled =20 > connection timeouts and retries transparently, all the more so. I want to say "yes", but I'm gong to have to read up on it more in detail. But I can't see why this would be a problem. SRV in conjunction (or replacing) the service field would be a cool thing. When you talk about timeouts and retries, are you referring to some particular protocol(s) or in general? // Javier --=-0TH5WCI6EHtEoGSvrO0e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxNa8cACgkQGBo5FLRz4goB5QCfYUkS9HYazdeFFzeRD9E7iVMt VYAAn2RjB4Vk7gUeReouZX5xaN4BYp9j =ZcAj -----END PGP SIGNATURE----- --=-0TH5WCI6EHtEoGSvrO0e-- From GK@ninebynine.org Mon Jul 26 04:06: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 9C2DE3A69EE for ; Mon, 26 Jul 2010 04:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHAU1WuOHnOz for ; Mon, 26 Jul 2010 04:06:13 -0700 (PDT) Received: from relay6.mail.ox.ac.uk (relay6.mail.ox.ac.uk [163.1.2.167]) by core3.amsl.com (Postfix) with ESMTP id E9D273A6836 for ; Mon, 26 Jul 2010 04:06:12 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay6.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1OdLVx-0002M0-Jo; Mon, 26 Jul 2010 12:06:33 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OdLVx-0006xx-3R; Mon, 26 Jul 2010 12:06:33 +0100 Message-ID: <4C4D6A66.20207@ninebynine.org> Date: Mon, 26 Jul 2010 11:58:46 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Javier Ubillos , "apps-discuss@ietf.org" References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> In-Reply-To: <1280136631.9738.9.camel@bit> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 11:06:14 -0000 This sounds to me like a potentially useful idea, especially as it seems it can be deployed (initially) over existing protocols. Some thoughts on reading through the draft, from the perspective of web application development: Sect 2. Mention of locators as accessing *hosts* - isn't the real problem here to access *services* (e.g. a replicated service)? Sect 3.3. Paras 2 and 3 are losing me. Section 3.4 does better - maybe some merging/reordering here would help. Sect 4. Now I'm seeing this is taking place at the IP level, wondering if this is too low-down to benefit (some, many?) application requirements (cf. mention of service access per above). I'm also wondering how or if name based sockets can help the initial service rendezvous - the protocol as described seems to focus on parties announcing their own names ... it's not clear that it helps for them to initially locate Section 4.1. Use of nonce, maybe could usefully be described a little further. I _think_ the idea is to allow a session to be started, and move to a different location while the session is in progress, rather than just breaking the session. (e.g. mobile apps?) Section 6. Until this point, I was expecting the proposal to address a wide range of issues where name->IP translation is less fixed than one might like, but in this section, it seems that mobility is the main target. Which I think explains some of my previous responses. Section 10.3. I guess this is a placeholder, though I'm not sure what for. It has occurred to me that, especially for web applications, a way to embed these names in URIs is needed (since URIs are the starting point for many web app resource addresses/identifiers). But I'm not sure if it makes sense for this to be done separately from the protocol (URI scheme) involved. Suppose I'm using HTTP to access a replicated service: how can I name the service in an http: URI to access that service. The URI authority section seems to be the logical place, bug given that name based sockets are based on FQDN and other forms, do the socket names fit cleanly and compatibly into the URI authority structure? ... Above are my comments from a quick skim of the draft. I started this email to try and describe what I'd like to see as an application developer, but thought I should at least first skim the proposal. So what I'd like to see is a library/libraries that I can deploy on common systems (Linux, MacOS, Linux) and access from a range of programming languages (Java, Python, etc.), and including including browser Javascript and use with minimal change to allow endpoint replication/rehoming/rendezvous for existing applications with minimal code changes. This sounds to me like a big ask - as I write this, I'm trying (and not succeeding) [**] to think if there's a smaller, simpler step that could allow this exploration to take place. What I can say is that just implementing a new feature (i.e. the address family) at the socket API level isn't going to help my kind of application development. [**] maybe a combination of an Apache module and a tweak to the Python libraries would allow some experimentation with Python client/Apache-based web services? This isn't something I've thought through clearly. An area I can see benefiting from this kind of framework (or what I imagine it might be :) is web browser AJAX clients talking to replicated web services, so being able to have Browser AJAX apps play with the protocols would be an important step in this case. I imagine something similar would apply for mobile apps running in mobile browsers. #g -- Javier Ubillos wrote: > As being discussed right now in apparea, here's an individual > submisison. > > Name Based Sockets > Draft: http://www.ietf.org/id/draft-ubillos-name-based-sockets-01.txt > Presentation: > http://www.sics.se/~jav/ietf78/namebasedsockets-IETF78-apps.pdf > > Consider it a real "request for comments", because I do want comments :) > > The question to apps-discuss is, what features are wanted/important to > application developers? > What should we do next? > What would make this fly? > > // Javier Ubillos > > > ------------------------------------------------------------------------ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From dave@cridland.net Mon Jul 26 04:18:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB023A67B2 for ; Mon, 26 Jul 2010 04:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 S-O7QsIP4kHC for ; Mon, 26 Jul 2010 04:18:14 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id D238D3A679F for ; Mon, 26 Jul 2010 04:18:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 23787116809F; Mon, 26 Jul 2010 12:18:34 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (localhost.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bN4rwM6eYPs; Mon, 26 Jul 2010 12:18:32 +0100 (BST) Received: from puncture (puncture [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 0803B116809E; Mon, 26 Jul 2010 12:18:32 +0100 (BST) References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> In-Reply-To: <1280142280.9738.34.camel@bit> MIME-Version: 1.0 Message-Id: <2378.1280143112.004312@puncture> Date: Mon, 26 Jul 2010 12:18:32 +0100 From: Dave Cridland To: Javier Ubillos , General discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 11:18:15 -0000 On Mon Jul 26 12:04:40 2010, Javier Ubillos wrote: > On Mon, 2010-07-26 at 11:45 +0100, Dave Cridland wrote: > > I suspect that if this could be made to handle non-blocking, > > single-attempt, SRV lookup, host lookup, and connection, then it > > would be very interesting to application developers. If it handled > > connection timeouts and retries transparently, all the more so. > > I want to say "yes", but I'm gong to have to read up on it more in > detail. But I can't see why this would be a problem. > SRV in conjunction (or replacing) the service field would be a cool > thing. > When you talk about timeouts and retries, are you referring to some > particular protocol(s) or in general? To connect to an XMPP service for example.com as a client, you: Lookup SRV for xmpp-client at example.com. While there exist records: For each priority: While there exist records at this priority: Perform random weighted selection of record. Remove record. Lookup address records. For each address record: If connect succeeds, EXIT. Perform address record lookup of example.com For each address record: If connect (to fixed port 5269, found via getservname()) succeeds, EXIT FAIL None of that is XMPP specific, it's normal SRV lookup with a fallback. If you can do all that with the API, or do it in two steps (SRV then fallback) at least, and do it non-blocking, application developers will want to be your friend and buy you beer. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From simon.perreault@viagenie.ca Mon Jul 26 04:26:50 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 1C7753A69F3 for ; Mon, 26 Jul 2010 04:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKWdQm+s+8Un for ; Mon, 26 Jul 2010 04:26:49 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id EC0A53A680A for ; Mon, 26 Jul 2010 04:26:48 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2001:df8:0:7:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 36E0420D36 for ; Mon, 26 Jul 2010 07:27:09 -0400 (EDT) Message-ID: <4C4D710D.50708@viagenie.ca> Date: Mon, 26 Jul 2010 13:27:09 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> <2378.1280143112.004312@puncture> In-Reply-To: <2378.1280143112.004312@puncture> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 11:26:50 -0000 Dave Cridland wrote, on 07/26/2010 01:18 PM: > Lookup SRV for xmpp-client at example.com. > While there exist records: > For each priority: > While there exist records at this priority: > Perform random weighted selection of record. > Remove record. > Lookup address records. > For each address record: > If connect succeeds, EXIT. > Perform address record lookup of example.com > For each address record: > If connect (to fixed port 5269, found via getservname()) succeeds, EXIT > FAIL The problem with this is that nothing guarantees that the SRV name and what's in getservname()'s database (i.e. the port-numbers registry) are the same. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dave@cridland.net Mon Jul 26 04:35:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63CF3A680A for ; Mon, 26 Jul 2010 04:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 HH6hCvMADWlj for ; Mon, 26 Jul 2010 04:35:21 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 415763A679F for ; Mon, 26 Jul 2010 04:35:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id A6507116809F; Mon, 26 Jul 2010 12:35:41 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (localhost.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+1pHpfa+d1u; Mon, 26 Jul 2010 12:35:40 +0100 (BST) Received: from puncture (puncture [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 49F7D116809E; Mon, 26 Jul 2010 12:35:40 +0100 (BST) References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> <2378.1280143112.004312@puncture> <4C4D710D.50708@viagenie.ca> In-Reply-To: <4C4D710D.50708@viagenie.ca> MIME-Version: 1.0 Message-Id: <2378.1280144140.289984@puncture> Date: Mon, 26 Jul 2010 12:35:40 +0100 From: Dave Cridland To: Simon Perreault , General discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 11:35:22 -0000 On Mon Jul 26 12:27:09 2010, Simon Perreault wrote: > Dave Cridland wrote, on 07/26/2010 01:18 PM: > > Lookup SRV for xmpp-client at example.com. > > While there exist records: > > For each priority: > > While there exist records at this priority: > > Perform random weighted selection of record. > > Remove record. > > Lookup address records. > > For each address record: > > If connect succeeds, EXIT. > > Perform address record lookup of example.com > > For each address record: > > If connect (to fixed port 5269, found via getservname()) > succeeds, EXIT > > FAIL > > The problem with this is that nothing guarantees that the SRV name > and what's in > getservname()'s database (i.e. the port-numbers registry) are the > same. Sure, which is why I'm saying we might want to split this. One problem is that there's a distinction in this model (that I really didn't make very clear) between "There were no SRV records" and "None of the SRV records worked". In the former case, you do the fallback, and in the latter case, you don't - meaning you need to be able to distinguish between "The name lookup failed" and "The name lookup worked, but the connect failed". I think given errno values, that's possible, but it's certainly a requirement. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From simon.perreault@viagenie.ca Mon Jul 26 04:52:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49AD93A6802 for ; Mon, 26 Jul 2010 04:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyH5m4rJvN5w for ; Mon, 26 Jul 2010 04:52:18 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id C14C43A680A for ; Mon, 26 Jul 2010 04:52:17 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2001:df8:0:7:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C9A4121C40; Mon, 26 Jul 2010 07:52:37 -0400 (EDT) Message-ID: <4C4D7705.5080702@viagenie.ca> Date: Mon, 26 Jul 2010 13:52:37 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1 MIME-Version: 1.0 To: Dave Cridland References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> <2378.1280143112.004312@puncture> <4C4D710D.50708@viagenie.ca> <2378.1280144140.289984@puncture> In-Reply-To: <2378.1280144140.289984@puncture> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 11:52:19 -0000 Dave Cridland wrote, on 07/26/2010 01:35 PM: > Sure, which is why I'm saying we might want to split this. If I understand you correctly, you are suggesting to replace the name_sock member in struct sockaddr_name with two char * members, one of them for the SRV lookup and another to be passed to getservname()? Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dave@cridland.net Mon Jul 26 05:02:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0023A682E for ; Mon, 26 Jul 2010 05:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 fFcaDuwk860d for ; Mon, 26 Jul 2010 05:02:25 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id CEA043A6802 for ; Mon, 26 Jul 2010 05:02:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 1484C116809F; Mon, 26 Jul 2010 13:02:45 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (localhost.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bkCdYYRtfYt; Mon, 26 Jul 2010 13:02:43 +0100 (BST) Received: from puncture (puncture [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 5BDC0116809E; Mon, 26 Jul 2010 13:02:43 +0100 (BST) References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> <2378.1280143112.004312@puncture> <4C4D710D.50708@viagenie.ca> <2378.1280144140.289984@puncture> <4C4D7705.5080702@viagenie.ca> In-Reply-To: <4C4D7705.5080702@viagenie.ca> MIME-Version: 1.0 Message-Id: <2378.1280145763.372609@puncture> Date: Mon, 26 Jul 2010 13:02:43 +0100 From: Dave Cridland To: Simon Perreault , General discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 12:02:28 -0000 On Mon Jul 26 12:52:37 2010, Simon Perreault wrote: > Dave Cridland wrote, on 07/26/2010 01:35 PM: > > Sure, which is why I'm saying we might want to split this. > > If I understand you correctly, you are suggesting to replace the > name_sock > member in struct sockaddr_name with two char * members, one of them > for the SRV > lookup and another to be passed to getservname()? I'm not quite that mad. I'm thinking the API would either do SRV, or to known port, so application developers do: fd = socket(PF_INET, AF_NAME, SOCK_STREAM); if (connect(fd, {xmpp_domain, "xmpp-client"}) != 0) { if (errno == EADDRNOTAVAIL) { /* Failed due to name lookup; try address lookup */ if (connect(fd, {xmpp_domain, 5269}) != 0) { throw Failure; } } else { /* Something else, give up now. */ throw Failure; } } [...] I'm probably badly abusing errno values there, but does this make sense? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From cyrus@daboo.name Mon Jul 26 05:10: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 309403A6B80 for ; Mon, 26 Jul 2010 05:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_03_06=0.274] 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 eSkFiFJhTocB for ; Mon, 26 Jul 2010 05:10:25 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 3ED3F3A6A8C for ; Mon, 26 Jul 2010 05:10:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 92A0F18B204E6; Mon, 26 Jul 2010 08:10:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-VzJnuA+69u; Mon, 26 Jul 2010 08:10:18 -0400 (EDT) Received: from dhcp-63f1.meeting.ietf.org (dhcp-63f1.meeting.ietf.org [130.129.99.241]) by daboo.name (Postfix) with ESMTPSA id F1E8118B204DE; Mon, 26 Jul 2010 08:10:16 -0400 (EDT) Date: Mon, 26 Jul 2010 14:10:14 -0400 From: Cyrus Daboo To: Dave Cridland , Simon Perreault , General discussion of application-layer protocols Message-ID: In-Reply-To: <2378.1280145763.372609@puncture> References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> <2378.1280143112.004312@puncture> <4C4D710D.50708@viagenie.ca> <2378.1280144140.289984@puncture> <4C4D7705.5080702@viagenie.ca> <2378.1280145763.372609@puncture> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1483 Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 12:10:35 -0000 Hi Dave, --On July 26, 2010 1:02:43 PM +0100 Dave Cridland wrote: > > I'm thinking the API would either do SRV, or to known port, so > application developers do: > > fd = socket(PF_INET, AF_NAME, SOCK_STREAM); > > if (connect(fd, {xmpp_domain, "xmpp-client"}) != 0) { > if (errno == EADDRNOTAVAIL) { > /* Failed due to name lookup; try address lookup */ > if (connect(fd, {xmpp_domain, 5269}) != 0) { > throw Failure; > } > } else { > /* Something else, give up now. */ > throw Failure; > } > } > > [...] > > I'm probably badly abusing errno values there, but does this make sense? That is not a complete example as it does not show the SRV lookup. With your previous pseudo-code example you showed the various nested loops needed to do SRV. Wouldn't it make sense for named sockets to take care of all that too? i.e. how about adding an AF_SERVICE option where the "address" is the service type and domain. Then the new api takes care of doing the SRV lookup (with all the proper priority/weight handling) and uses the host/port from that for the actual connection. Another important aspect of this spec is what information is available to the clients about the sockets that are bound. In particular application layer operations such as certificate verification will need access to some underlying information from the "named" socket that the client would otherwise have known with the current way of doing things. -- Cyrus Daboo From msk@cloudmark.com Mon Jul 26 05:11:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE263A686E for ; Mon, 26 Jul 2010 05:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=-0.862, 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 69EmL1GZx1qK for ; Mon, 26 Jul 2010 05:11:48 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 505DA3A68D4 for ; Mon, 26 Jul 2010 05:11:48 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 26 Jul 2010 05:12:09 -0700 From: "Murray S. Kucherawy" To: Dave Cridland , Javier Ubillos , General discussion of application-layer protocols Date: Mon, 26 Jul 2010 05:12:08 -0700 Thread-Topic: [apps-discuss] Name based sockets - Making individual submissions know Thread-Index: Acssr57DWgkw55pdQOK+zxQaRPIBSgAC+fTQ Message-ID: References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> In-Reply-To: <2378.1280141100.936023@puncture> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 12:11:51 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Dave Cridland > Sent: Monday, July 26, 2010 3:45 AM > To: Javier Ubillos; General discussion of application-layer protocols > Subject: Re: [apps-discuss] Name based sockets - Making individual > submissions know >=20 > I'm also disappointed to see that the port remains a number - I would > have thought a string (or at least the option for one) would be > useful here, allowing SRV record lookup, for example. This got me thinking about MX records. If I want to talk to a mail server = for example.com, there's not only a specific port, but a specific set of ho= sts that should be tried and even in a particular order. And if there is n= o MX record, there's an implicit one at the A record. Seems to me there might be some other exceptional cases this would have to = accommodate as well. From jav@sics.se Mon Jul 26 05:24: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 9003A3A6BCE for ; Mon, 26 Jul 2010 05:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JuH6Crfo9zk for ; Mon, 26 Jul 2010 05:24:13 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id D35013A6A09 for ; Mon, 26 Jul 2010 05:24:12 -0700 (PDT) Received: from [130.129.113.249] (dhcp-71f9.meeting.ietf.org [130.129.113.249]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 18A95400D7; Mon, 26 Jul 2010 14:24:33 +0200 (CEST) From: Javier Ubillos To: Graham Klyne In-Reply-To: <4C4D6A66.20207@ninebynine.org> References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <4C4D6A66.20207@ninebynine.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+q/FRrBWXp8o5+Zc/eVl" Date: Mon, 26 Jul 2010 14:24:32 +0200 Message-ID: <1280147072.9738.71.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 12:24:14 -0000 --=-+q/FRrBWXp8o5+Zc/eVl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2010-07-26 at 11:58 +0100, Graham Klyne wrote: Thanks for the comments on the draft. I'll make sure things are clearer. > Sect 4. Now I'm seeing this is taking place at the IP level, wondering i= f this=20 > is too low-down to benefit (some, many?) application requirements (cf. me= ntion=20 > of service access per above). >=20 > I'm also wondering how or if name based sockets can help the initial serv= ice=20 > rendezvous - the protocol as described seems to focus on parties announci= ng=20 > their own names ... it's not clear that it helps for them to initially lo= cate I don't think I understand. To get a hold of your friend, you need some way of saying "I want to talk t= o X". What alternatives are there for X? Being a "name" is one option... > Section 4.1. Use of nonce, maybe could usefully be described a little fu= rther.=20 > I _think_ the idea is to allow a session to be started, and move to a=20 > different location while the session is in progress, rather than just bre= aking=20 > the session. (e.g. mobile apps?) >=20 > Section 6. Until this point, I was expecting the proposal to address a wi= de=20 > range of issues where name->IP translation is less fixed than one might l= ike,=20 > but in this section, it seems that mobility is the main target. Which I = think=20 > explains some of my previous responses. As name based sockets grow, and more features become integrated, I see this section (and the corresponding for other features) moving out to their own drafts. The reason why this is the only thing we address in this draft is because it's what we have right now. > Section 10.3. I guess this is a placeholder, though I'm not sure what for= . It=20 > has occurred to me that, especially for web applications, a way to embed = these=20 > names in URIs is needed (since URIs are the starting point for many web a= pp=20 > resource addresses/identifiers). But I'm not sure if it makes sense for = this to=20 > be done separately from the protocol (URI scheme) involved. Suppose I'm = using=20 > HTTP to access a replicated service: how can I name the service in an ht= tp: URI=20 > to access that service. The URI authority section seems to be the logica= l=20 > place, bug given that name based sockets are based on FQDN and other form= s, do=20 > the socket names fit cleanly and compatibly into the URI authority struct= ure? Yes, section 10.3 is broken. Are you thinking of putting: "protocol://hostname.net/path/to/service" Into a socket? Perhaps that's not an entierly crazy idea :) Where (regex) #(.**)://([^/]*)/(.*)# would be protocol, host, service >=20 > So what I'd like to see is a library/libraries that I can deploy on commo= n=20 > systems (Linux, MacOS, Linux) and access from a range of programming lang= uages=20 > (Java, Python, etc.), and including including browser Javascript and use = with=20 > minimal change to allow endpoint replication/rehoming/rendezvous for exis= ting=20 > applications with minimal code changes. >=20 > This sounds to me like a big ask - as I write this, I'm trying (and not=20 > succeeding) [**] to think if there's a smaller, simpler step that could a= llow=20 > this exploration to take place. What I can say is that just implementing= a new=20 > feature (i.e. the address family) at the socket API level isn't going to = help my=20 > kind of application development. >=20 > [**] maybe a combination of an Apache module and a tweak to the Python li= braries=20 > would allow some experimentation with Python client/Apache-based web serv= ices?=20 > This isn't something I've thought through clearly. The way I see it is that by having a socket level API solution, the different socket abstractions will start picking it up. Starting with an open (GPL) C implementation helps (I think). // Javier --=-+q/FRrBWXp8o5+Zc/eVl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxNfn4ACgkQGBo5FLRz4gqFcwCfb4RIvdzU61lXyXT3KaASFwDq OjwAnRRitmDPKpLk2AfxFzIeo4F31q6q =SLuK -----END PGP SIGNATURE----- --=-+q/FRrBWXp8o5+Zc/eVl-- From GK@ninebynine.org Mon Jul 26 05:37: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 043CF3A682E for ; Mon, 26 Jul 2010 05:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydIFT7dvs5JL for ; Mon, 26 Jul 2010 05:37:35 -0700 (PDT) Received: from relay6.mail.ox.ac.uk (relay6.mail.ox.ac.uk [163.1.2.167]) by core3.amsl.com (Postfix) with ESMTP id 640A53A6802 for ; Mon, 26 Jul 2010 05:37:35 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay6.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1OdMwN-0007TC-MI; Mon, 26 Jul 2010 13:37:55 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OdMwN-0002ca-1y; Mon, 26 Jul 2010 13:37:55 +0100 Message-ID: <4C4D814C.9000401@ninebynine.org> Date: Mon, 26 Jul 2010 13:36:28 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Javier Ubillos References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> In-Reply-To: <1280136631.9738.9.camel@bit> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 12:37:37 -0000 Reflecting further since my initial response... What really appealed to me about the proposal was this from the abstract: "Applications are thus relieved of re-implementing features such as multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and address management in general." This implies that what we're talking about is something that applications *can* do for themselves, but shouldn't have to. On this premise, it seems to me that the first step shouldn't be to creating new protocol elements and kernel modules, as they're clearly not necessary, but to create a common library that applications can use to handle these common requirements (if indeed, they are common requirements). This offers a relatively low-cost way to explore the requirements space. Later, as application requirements are better understood, it may make sense to migrate some of the functionality into operating system and/or protocol elements. So, in summary, I fear the current proposal may be putting the cart before the horse [1]. But I think the goals are apposite and the topic is worth investigating. #g -- [1] Maybe a somewhat British-English idiom, meaning to "reverse the accepted order of things" -- http://www.phrases.org.uk/meanings/put-the-cart-before-the-horse.html Javier Ubillos wrote: > As being discussed right now in apparea, here's an individual > submisison. > > Name Based Sockets > Draft: http://www.ietf.org/id/draft-ubillos-name-based-sockets-01.txt > Presentation: > http://www.sics.se/~jav/ietf78/namebasedsockets-IETF78-apps.pdf > > Consider it a real "request for comments", because I do want comments :) > > The question to apps-discuss is, what features are wanted/important to > application developers? > What should we do next? > What would make this fly? > > // Javier Ubillos > > > ------------------------------------------------------------------------ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From msk@cloudmark.com Mon Jul 26 05:43:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158653A6802 for ; Mon, 26 Jul 2010 05:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.404 X-Spam-Level: X-Spam-Status: No, score=-3.404 tagged_above=-999 required=5 tests=[AWL=-0.805, 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 D51q4y5uiTlz for ; Mon, 26 Jul 2010 05:43:08 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id DFBE33A6A09 for ; Mon, 26 Jul 2010 05:43:07 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 26 Jul 2010 05:43:28 -0700 From: "Murray S. Kucherawy" To: Graham Klyne , Javier Ubillos Date: Mon, 26 Jul 2010 05:43:26 -0700 Thread-Topic: [apps-discuss] Name based sockets - Making individual submissions know Thread-Index: Acssv2I5eUXfDql9RLOq6mEo+1yIUAAAIt+Q Message-ID: References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <4C4D814C.9000401@ninebynine.org> In-Reply-To: <4C4D814C.9000401@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 12:43:10 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Graham Klyne > Sent: Monday, July 26, 2010 5:36 AM > To: Javier Ubillos > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Name based sockets - Making individual > submissions know >=20 > Reflecting further since my initial response... >=20 > What really appealed to me about the proposal was this from the > abstract: > "Applications are thus relieved of re-implementing features such as > multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and > address > management in general." Actually, are these things something in the application layer has to think = about in general? It seems to me the stuff we're talking about, namely IP = address and port resolution, don't know anything about most of the things i= n that list. I've never written an application that can tell, or cares, wh= ether or not it's on a multi-homed box, a mobile device, or behind a NAT. From GK@ninebynine.org Mon Jul 26 06:01:48 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 A313C3A6907 for ; Mon, 26 Jul 2010 06:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.997 X-Spam-Level: X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogcfzW6DpBTi for ; Mon, 26 Jul 2010 06:01:47 -0700 (PDT) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by core3.amsl.com (Postfix) with ESMTP id D3FB63A68F0 for ; Mon, 26 Jul 2010 06:01:46 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1OdNJm-0004HA-2i; Mon, 26 Jul 2010 14:02:06 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OdNJm-0002Z8-81; Mon, 26 Jul 2010 14:02:06 +0100 Message-ID: <4C4D8715.6050502@ninebynine.org> Date: Mon, 26 Jul 2010 14:01:09 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Javier Ubillos References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <4C4D6A66.20207@ninebynine.org> <1280147072.9738.71.camel@bit> In-Reply-To: <1280147072.9738.71.camel@bit> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 13:01:48 -0000 Javier Ubillos wrote: >> I'm also wondering how or if name based sockets can help the initial service >> rendezvous - the protocol as described seems to focus on parties announcing >> their own names ... it's not clear that it helps for them to initially locate > > I don't think I understand. > To get a hold of your friend, you need some way of saying "I want to talk to X". Yes, that's what I'm asking about ... > What alternatives are there for X? > Being a "name" is one option... ... but I couldn't see how that would work. What "name" does the client ask for? What does the protocol do with this name, given that at initiation, no information or acknowledgement of named-based-socket support has been received in the other direction. >> Section 4.1. Use of nonce, maybe could usefully be described a little further. >> I _think_ the idea is to allow a session to be started, and move to a >> different location while the session is in progress, rather than just breaking >> the session. (e.g. mobile apps?) >> >> Section 6. Until this point, I was expecting the proposal to address a wide >> range of issues where name->IP translation is less fixed than one might like, >> but in this section, it seems that mobility is the main target. Which I think >> explains some of my previous responses. > As name based sockets grow, and more features become integrated, I see > this section (and the corresponding for other features) moving out to > their own drafts. The reason why this is the only thing we address in > this draft is because it's what we have right now. If development is to proceed at this level, I think a (small) range of use-cases should be considered. A use-case I have in mind is web client applications (very many instances thereof) accessing a replicated read-only query service (imagine, say, an API for Google-style search, or a replicated service for SPARQL [1] queries against dbpedia [2]). So I want to name the service without fixing the particular endpoint. Maybe you regard this kind of thing as out of scope - in which case I think the scope needs more careful articulation. [1] http://www.w3.org/TR/rdf-sparql-query/ [2] http://dbpedia.org/About >> Section 10.3. I guess this is a placeholder, though I'm not sure what for. It >> has occurred to me that, especially for web applications, a way to embed these >> names in URIs is needed (since URIs are the starting point for many web app >> resource addresses/identifiers). But I'm not sure if it makes sense for this to >> be done separately from the protocol (URI scheme) involved. Suppose I'm using >> HTTP to access a replicated service: how can I name the service in an http: URI >> to access that service. The URI authority section seems to be the logical >> place, bug given that name based sockets are based on FQDN and other forms, do >> the socket names fit cleanly and compatibly into the URI authority structure? > > Yes, section 10.3 is broken. > > Are you thinking of putting: > "protocol://hostname.net/path/to/service" > Into a socket? > Perhaps that's not an entierly crazy idea :) > Where (regex) #(.**)://([^/]*)/(.*)# would be > protocol, host, service Actually, no, though that did cross my mind. The half-baked notion I had was that one might be able to write: http://[[name]]/path/to/service where "[[name]]" is some construct that might confirm to the current structure of URI "authority" elements: [[ authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) host = IP-literal / IPv4address / reg-name port = *DIGIT : reg-name = *( unreserved / pct-encoded / sub-delims ) ]] -- http://www.apps.ietf.org/rfc/rfc3986.html (Appendix A) There's quite a lot of scope here for using alternative naming structures. But in the first instance, I'd expect something that looks like and behaves rather like a FQDN would be needed, as anything else would break all sorts of current software systems. > > >> So what I'd like to see is a library/libraries that I can deploy on common >> systems (Linux, MacOS, Linux) and access from a range of programming languages >> (Java, Python, etc.), and including including browser Javascript and use with >> minimal change to allow endpoint replication/rehoming/rendezvous for existing >> applications with minimal code changes. >> >> This sounds to me like a big ask - as I write this, I'm trying (and not >> succeeding) [**] to think if there's a smaller, simpler step that could allow >> this exploration to take place. What I can say is that just implementing a new >> feature (i.e. the address family) at the socket API level isn't going to help my >> kind of application development. >> >> [**] maybe a combination of an Apache module and a tweak to the Python libraries >> would allow some experimentation with Python client/Apache-based web services? >> This isn't something I've thought through clearly. > > The way I see it is that by having a socket level API solution, the > different socket abstractions will start picking it up. Starting with an > open (GPL) C implementation helps (I think). Hmmm... see my later message. But yes, an open implementation helps (though maybe not GPL, as I know that could put off a fair number of potential adopters). A C library would be a reasonable starting point, as many language systems have mechanisms for interfacing to these. But if application developers have to wait for other parts of the system to take up use of some arcane underlying element, we could be back into similar territory as IPv6 deployment, but with less urgency to succeed. #g From GK@ninebynine.org Mon Jul 26 06:15: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 709E73A6BB0 for ; Mon, 26 Jul 2010 06:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rmn37qZulOCT for ; Mon, 26 Jul 2010 06:15:50 -0700 (PDT) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by core3.amsl.com (Postfix) with ESMTP id 638273A6BB7 for ; Mon, 26 Jul 2010 06:15:49 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1OdNXL-0002uO-4y; Mon, 26 Jul 2010 14:16:07 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OdNXL-0000Ur-46; Mon, 26 Jul 2010 14:16:07 +0100 Message-ID: <4C4D8A88.508@ninebynine.org> Date: Mon, 26 Jul 2010 14:15:52 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <4C4D814C.9000401@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 13:15:55 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Graham Klyne >> Sent: Monday, July 26, 2010 5:36 AM >> To: Javier Ubillos >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Name based sockets - Making individual >> submissions know >> >> Reflecting further since my initial response... >> >> What really appealed to me about the proposal was this from the >> abstract: >> "Applications are thus relieved of re-implementing features such as >> multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and >> address >> management in general." > > Actually, are these things something in the application layer has to think about in general? It seems to me the stuff we're talking about, namely IP address and port resolution, don't know anything about most of the things in that list. I've never written an application that can tell, or cares, whether or not it's on a multi-homed box, a mobile device, or behind a NAT. You have a good point - I guess it comes down to the intended scope. If the goal is to make current applications just work when IP addresses change under the hood, then I agree. In other messages, I've used an example of a replicated web service. Attempting to show this isn't an isolated use-case, another application design where I've contemplated a maybe-similar requirement is seamless handover in replicated systems, for resilience. (I'm noodling here about real-time control/monitoring systems using a pub-sub information propagation model where two or more "controllers" are maintaining synchronized state, and either (or both) can respond appropriately to any request.) I'm quite prepared to be told these are out of scope. And I'm beginning to think they maybe should be out of scope, as solving the problem of movable session endpoints could be a big enough step up. #g From msk@cloudmark.com Mon Jul 26 06:40: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 110B43A6952 for ; Mon, 26 Jul 2010 06:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[AWL=-0.763, 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 r4u87GwhPQqz for ; Mon, 26 Jul 2010 06:40:45 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id A46D73A693E for ; Mon, 26 Jul 2010 06:40:45 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 26 Jul 2010 06:41:06 -0700 From: "Murray S. Kucherawy" To: Graham Klyne Date: Mon, 26 Jul 2010 06:41:03 -0700 Thread-Topic: [apps-discuss] Name based sockets - Making individual submissions know Thread-Index: AcssxLZXgr+9Bu3tTe6aceg3wZ2p1wAAz/BQ Message-ID: References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <4C4D814C.9000401@ninebynine.org> <4C4D8A88.508@ninebynine.org> In-Reply-To: <4C4D8A88.508@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 13:40:47 -0000 > -----Original Message----- > From: Graham Klyne [mailto:GK@ninebynine.org] > Sent: Monday, July 26, 2010 6:16 AM > To: Murray S. Kucherawy > Cc: Javier Ubillos; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Name based sockets - Making individual > submissions know >=20 > > Actually, are these things something in the application layer has to > think about in general? It seems to me the stuff we're talking about, > namely IP address and port resolution, don't know anything about most > of the things in that list. I've never written an application that can > tell, or cares, whether or not it's on a multi-homed box, a mobile > device, or behind a NAT. >=20 > You have a good point - I guess it comes down to the intended scope. Indeed. Independent of the actual details, it seems to me things like mult= i-homing, mobile and NAT are completely off-topic (i.e. if you're trying to= obscure name resolution, you're certainly trying to hide details like that= ... but fortunately they're actually already hidden anyway.). From jav@sics.se Mon Jul 26 07:14:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6643A6A40 for ; Mon, 26 Jul 2010 07:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396] 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 lY+EX-QvyokX for ; Mon, 26 Jul 2010 07:14:48 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 5FF9A3A6982 for ; Mon, 26 Jul 2010 07:14:48 -0700 (PDT) Received: from [130.129.113.249] (dhcp-71f9.meeting.ietf.org [130.129.113.249]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id A2750400D7; Mon, 26 Jul 2010 16:15:08 +0200 (CEST) From: Javier Ubillos To: Graham Klyne In-Reply-To: <4C4D814C.9000401@ninebynine.org> References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <4C4D814C.9000401@ninebynine.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-nC2rZPkBhnIeH++sdr5K" Date: Mon, 26 Jul 2010 16:15:08 +0200 Message-ID: <1280153708.9738.74.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 26 Jul 2010 14:14:51 -0000 --=-nC2rZPkBhnIeH++sdr5K Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2010-07-26 at 13:36 +0100, Graham Klyne wrote: > Reflecting further since my initial response... >=20 > What really appealed to me about the proposal was this from the abstract:= =20 > "Applications are thus relieved of re-implementing features such as=20 > multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and add= ress=20 > management in general." >=20 > This implies that what we're talking about is something that applications= *can*=20 > do for themselves, but shouldn't have to. On this premise, it seems to m= e that=20 > the first step shouldn't be to creating new protocol elements and kernel=20 > modules, as they're clearly not necessary, but to create a common library= that=20 > applications can use to handle these common requirements (if indeed, they= are=20 > common requirements). This offers a relatively low-cost way to explore t= he=20 > requirements space. >=20 > Later, as application requirements are better understood, it may make sen= se to=20 > migrate some of the functionality into operating system and/or protocol e= lements. I'm happy to hear you describe it this way. This reflects my view perfectly. This should be distributed as an userspace library at first, so that applications can make sure they do get what they want, independent of what is supported under the hood. As the library matures, it will start to "sink in" into the OS. However, the current implementation is, for practical reasons, far more kernel close ;) // Javier --=-nC2rZPkBhnIeH++sdr5K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxNmGoACgkQGBo5FLRz4gppdACgrMwQldDFXbarcZeocEwC7nuq +CcAni0kH0bBfFtDHR7rBD34ewphMeCD =wHVb -----END PGP SIGNATURE----- --=-nC2rZPkBhnIeH++sdr5K-- From jpanzer@google.com Mon Jul 26 13:22: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 62CB93A699F for ; Mon, 26 Jul 2010 13:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.717 X-Spam-Level: X-Spam-Status: No, score=-97.717 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_47=0.6, 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 hUB+UziEpTPg for ; Mon, 26 Jul 2010 13:22:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id DB0453A698C for ; Mon, 26 Jul 2010 13:22:52 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6QKNCDP019993 for ; Mon, 26 Jul 2010 13:23:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280175793; bh=KgsRkGw1rcJptiMbReU40OoNAuo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=yL1FNagCoY4nj1O8/2LWcRmkaPYK+63Qhus74Znkm+pYNA9WdTksykOz+lXicup0n onRMv73bI+Dpv1Z5qqbng== 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=EUk3fNoLDySYVLUE+OSF4RrVaC1Gw0Et2wtIjGZp3XA5+enfUL9UOXOfe6PTTMprG QEepne/f/aTgAOUrwuTeA== Received: from gxk27 (gxk27.prod.google.com [10.202.11.27]) by kpbe17.cbf.corp.google.com with ESMTP id o6QKNBNJ025021 for ; Mon, 26 Jul 2010 13:23:11 -0700 Received: by gxk27 with SMTP id 27so1171744gxk.8 for ; Mon, 26 Jul 2010 13:23:10 -0700 (PDT) Received: by 10.100.109.13 with SMTP id h13mr8337425anc.193.1280175790665; Mon, 26 Jul 2010 13:23:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.138.5 with HTTP; Mon, 26 Jul 2010 13:22:33 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FD8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FD8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Mon, 26 Jul 2010 13:22:33 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e644b99e40b0ec048c5027ca X-System-Of-Record: true Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 26 Jul 2010 20:22:55 -0000 --0016e644b99e40b0ec048c5027ca Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 24, 2010 at 12:18 AM, Eran Hammer-Lahav wrote: > > > > -----Original Message----- > > From: John Panzer [mailto:jpanzer@google.com] > > Sent: Friday, July 23, 2010 6:37 PM > > To: Blaine Cook > > Cc: Eran Hammer-Lahav; apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web > > Host Metadata) to Proposed Standard > > > > That's also why I don't see "stop when you see the rel you're looking > for" as a > > big help - you actually are looking for a collection where rel=x in the > general > > case (think rel=alternate for a common example from other formats). So > you > > have to get the set of links in some context, which could be the > host-meta > > document or the target of the lrdd template. > > The only way to avoid this is to forbid using link templates for anything > other than a single 'lrdd' link template, or even remove templates > completely and using a single link (non template) with relation 'lrdd' and a > pre-defined way to include the context URI as a parameter. Otherwise, link > templates at the host-meta level are semantically equivalent to those in a > LRDD document, not matter how much you try to pretend they are to be > ignored. > > Can you offer some useful and predictable guidelines when a client should > use link templates in host-meta and when it should not? When it should only > look for a single 'lrdd' document for all its metadata needs? How should an > application developer decide where to put resource-specific links, if we > follow your approach and treat the two sets (link templates in host-meta, > and links in a LRDD document) differently? > > For your approach to work, we need to be able to solve these questions > because semantically, all these links share the same context URI. We created > a mechanism using link templates and defined it well. The processing rules > in 4.2 are just the logical implementation of this framework. > > > But in general I agree with Blaine's primary objection; this adds an > include > > model that has not been proven and which forces clients to provision for > a > > nearly arbitrary number of worst-case http fetches. > > Servers can always do stupid things, like use too many redirections which > requires the same kind of handling. From a code perspective, processing > links from both host-meta and LRDD isn't that much more work - you already > have to process both. The ability to link to more than one LRDD document is > something that keeps coming up again and again when people want to reuse a > descriptor document available elsewhere. > > 'lrdd' links have a very limited include semantic by limiting it to one > level. > > > Query: Is it at least possible for a server to automatically merge > multiple > > rel=lrdd targets and serve up a single composite rel=lrdd target resource > to > > clients without impacting semantics? It's not clear to me from the spec. > > No idea what you mean. > If I have a host-meta file to which a user has added, say, 5 rel='lrdd' templates, is it possible for me to replace all 5 with a single composite (generated) document and a single (generated) rel='lrdd' link to same, without breaking semantics? Why one might want to do this: Performance, for the same reason that web servers do things like dynamic spriting of images by combining multiple images into one larger image for delivery over the wire. And XRDs are things that you typically won't be loading lazily as you would images -- things are going to block on pulling this information down. I don't think this is possible in the presence of XRD signatures. Those appear to have been shelved though. I am also not really a fan of "stop when you see what you want" because I think it will make things harder to code and will lead to user surprises. For example, if a user _removes_ a single link, they may suddenly see dozens of links _added_ that were hidden or "shadowed" before. In the meantime, the code itself already has to handle multiple links to work correctly (think rel="alternate"). If it can just build up one dictionary (multi-valued) per subject this isn't too bad, but if you also add in multiple "domains" with priority ordering between them this makes the code much more complicated and bug-prone. The slight gain in performance isn't really worth it compared to just advising people not to do that. I wish we could prevent them from doing it, is all. I'm also not a big fan of relying on document ordering, as it's inherently fragile. The Atom working group rejected using it as a primary ordering criteria (in favor of atom:updated by default). It will also cause problems for the mooted XRD JSON serialization. The most natural JSON serialization is a map from relvalue strings to link record lists (see discussions on activity streams mailing list for details on why this is so). While JSON clearly does have a textual layout order for these maps, that information is typically totally lost by most (all?) current JSON parsers. So you're faced with a Hobson's choice of using an unnatural JSOn serialization (a list) which is annoying and difficult for JSON users, or adding additional annoying and difficult priority fields. Since at the end of the day you're interested in getting a set of links, and the relative ordering of the links within a relvalue is almost _never_ relevant, I think this spec should follow the lead of the Atom specification and ignore the document ordering. > > > On Friday, July 23, 2010, Blaine Cook wrote: > > > On 23 July 2010 21:12, Eran Hammer-Lahav > > wrote: > > >> ** If this is not clear, I am happy to make it more explicit in > section 4.2, > > including adding a full procedure for clients looking for a specific > link. > > > > > > +1 - In my reading of 4.2, I had overlooked the sentence in 4 that > > > describes stopping whenever a suitable link relation is found. With > > > that processing rule in place, the semantic is clear and simple. > > > > > >> However, if people would like to simplify this a bit, I am open to > (but not > > excited about) making a small change in which clients will first look for > (any) > > 'lrdd' link templates, process them, and only then look for other link- > > templates in host-meta. This exception will deviate from the normal XRD > > processing rules of document order, but will move from a potential > complex > > mix from link sources to a two stage procedure (LRDD links, then > host-meta > > link templates). Note that this does not solve the basic requirement to > > construct the full resource descriptor from multiple location, only the > order in > > which that is done. > > > > > > I'm not sure what others think about this, but I personally prefer > > > this approach (LRDD-first, followed by host-level templates). The > > > reasoning is that this gives LRDD profiles the ability to over-ride > > > host-level decisions, whereas strictly following document ordering > > > means that hosts could potentially force all users to use a single URL > > > for a given rel value. > > > > > > The challenge is not so much that the hosts could force this (because > > > a "malicious" host could over-write the rel value in ever user's LRDD > > > document), but that interop becomes more challenging since any parser > > > that does LRDD-first *might* disagree with a strictly ordered parser > > > (an example where this is a real possibility: three parsers, one > > > SAX-based, one XPath based, and one DOM-based, may come up with very > > > different results if we rely on document ordering alone). > > > > > > b. > > > _______________________________________________ > > > apps-discuss mailing list > > > apps-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > -- > > -- > > John Panzer / Google > > jpanzer@google.com / abstractioneer.org / @jpanzer > --0016e644b99e40b0ec048c5027ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 24, 2010 at 12:18 AM, Eran Hammer-La= hav <eran@hueni= verse.com> wrote:


> -----Original Message-----
> From: John Panzer [mailto:jpanze= r@google.com]
> Sent: Friday, July 23, 2010 6:37 PM
> To: Blaine Cook
> Cc: Eran Hammer-Lahav; apps-d= iscuss@ietf.org
> Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web=
> Host Metadata) to Proposed Standard
>
> That's also why I don't see "stop= when you see the rel you're looking for" as a
> big help - you actually are looking for a collection where rel=3Dx in = the general
> case (think rel=3Dalternate for a common example from other formats). = =A0So you
> have to get the set of links in some context, which could be the host-= meta
> document or the target of the lrdd template.

The only way to avoid this is to forbid using link templates for anyt= hing other than a single 'lrdd' link template, or even remove templ= ates completely and using a single link (non template) with relation 'l= rdd' and a pre-defined way to include the context URI as a parameter. O= therwise, link templates at the host-meta level are semantically equivalent= to those in a LRDD document, not matter how much you try to pretend they a= re to be ignored.

Can you offer some useful and predictable guidelines when a client should u= se link templates in host-meta and when it should not? When it should only = look for a single 'lrdd' document for all its metadata needs? How s= hould an application developer decide where to put resource-specific links,= if we follow your approach and treat the two sets (link templates in host-= meta, and links in a LRDD document) differently?

For your approach to work, we need to be able to solve these questions beca= use semantically, all these links share the same context URI. We created a = mechanism using link templates and defined it well. The processing rules in= 4.2 are just the logical implementation of this framework.

> But in general I agree with Blaine's primary objection; this adds = an include
> model that has not been proven and which forces clients to provision f= or a
> nearly arbitrary number of worst-case http fetches.

Servers can always do stupid things, like use too many redirections w= hich requires the same kind of handling. From a code perspective, processin= g links from both host-meta and LRDD isn't that much more work - you al= ready have to process both. The ability to link to more than one LRDD docum= ent is something that keeps coming up again and again when people want to r= euse a descriptor document available elsewhere.

'lrdd' links have a very limited include semantic by limiting it to= one level.

> Query: =A0Is it at least possible for a server to automatically merge = multiple
> rel=3Dlrdd targets and serve up a single composite rel=3Dlrdd target r= esource to
> clients without impacting semantics? =A0It's not clear to me from = the spec.

No idea what you mean.

If I have = a host-meta file to which a user has added, say, 5 rel=3D'lrdd' tem= plates, is it possible for me to replace all 5 with a single composite (gen= erated) document and a single (generated) rel=3D'lrdd' link to same= , without breaking semantics? =A0

Why one might want to do this: =A0Performance, for the = same reason that web servers do things like dynamic spriting of images by c= ombining multiple images into one larger image for delivery over the wire. = =A0And XRDs are things that you typically won't be loading lazily as yo= u would images -- things are going to block on pulling this information dow= n.

I don't think this is possible in the presence of X= RD signatures. =A0Those appear to have been shelved though.

<= /div>
I am also not really a fan of "stop when you see what you wa= nt" because I think it will make things harder to code and will lead t= o user surprises. =A0For example, if a user _removes_ a single link, they m= ay suddenly see dozens of links _added_ that were hidden or "shadowed&= quot; before. =A0In the meantime, the code itself already has to handle mul= tiple links to work correctly (think rel=3D"alternate"). =A0If it= can just build up one dictionary (multi-valued) per subject this isn't= too bad, but if you also add in multiple "domains" with priority= ordering between them this makes the code much more complicated and bug-pr= one. =A0The slight gain in performance isn't really worth it compared t= o just advising people not to do that. =A0I wish we could prevent them from= doing it, is all.

I'm also not a big fan of relying on document order= ing, as it's inherently fragile. =A0The Atom working group rejected usi= ng it as a primary ordering criteria (in favor of atom:updated by default).= =A0It will also cause problems for the mooted XRD=A0JSON serialization. = =A0The most natural JSON serialization is a map from relvalue strings to li= nk record lists (see discussions on activity streams mailing list for detai= ls on why this is so). =A0While JSON clearly does have a textual layout ord= er for these maps, that information is typically totally lost by most (all?= ) current JSON parsers. =A0So you're faced with a Hobson's choice o= f using an unnatural JSOn serialization (a list) which is annoying and diff= icult for JSON users, or adding additional annoying and difficult priority = fields.

Since at the end of the day you're interested in ge= tting a set of links, and the relative ordering of the links within a relva= lue is almost _never_ relevant, I think this spec should follow the lead of= the Atom specification and ignore the document ordering.
=A0=A0
=A0

> On Friday, July 23, 2010, Blaine Cook <romeda@gmail.com> wrote:
> > On 23 July 2010 21:12, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> >> ** If this is not clear, I am happy to make it more explicit = in section 4.2,
> including adding a full procedure for clients looking for a specific l= ink.
> >
> > +1 - In my reading of 4.2, I had overlooked the sentence in 4 tha= t
> > describes stopping whenever a suitable link relation is found. Wi= th
> > that processing rule in place, the semantic is clear and simple.<= br> > >
> >> However, if people would like to simplify this a bit, I am op= en to (but not
> excited about) making a small change in which clients will first look = for (any)
> 'lrdd' link templates, process them, and only then look for ot= her link-
> templates in host-meta. This exception will deviate from the normal XR= D
> processing rules of document order, but will move from a potential com= plex
> mix from link sources to a two stage procedure (LRDD links, then host-= meta
> link templates). Note that this does not solve the basic requirement t= o
> construct the full resource descriptor from multiple location, only th= e order in
> which that is done.
> >
> > I'm not sure what others think about this, but I personally p= refer
> > this approach (LRDD-first, followed by host-level templates). The=
> > reasoning is that this gives LRDD profiles the ability to over-ri= de
> > host-level decisions, whereas strictly following document orderin= g
> > means that hosts could potentially force all users to use a singl= e URL
> > for a given rel value.
> >
> > The challenge is not so much that the hosts could force this (bec= ause
> > a "malicious" host could over-write the rel value in ev= er user's LRDD
> > document), but that interop becomes more challenging since any pa= rser
> > that does LRDD-first *might* disagree with a strictly ordered par= ser
> > (an example where this is a real possibility: three parsers, one<= br> > > SAX-based, one XPath based, and one DOM-based, may come up with v= ery
> > different results if we rely on document ordering alone).
> >
> > b.
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
>
> --
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @= jpanzer

--0016e644b99e40b0ec048c5027ca-- From eran@hueniverse.com Mon Jul 26 14:03:13 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 3D1673A698C for ; Mon, 26 Jul 2010 14:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[AWL=-2.389, BAYES_50=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_47=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 sTIOAaxiZZ1h for ; Mon, 26 Jul 2010 14:03:11 -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 C67F63A6839 for ; Mon, 26 Jul 2010 14:03:11 -0700 (PDT) Received: (qmail 17817 invoked from network); 26 Jul 2010 21:03:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jul 2010 21:03:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 26 Jul 2010 14:03:24 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Mon, 26 Jul 2010 14:03:27 -0700 Thread-Topic: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard Thread-Index: AcstAGCov2lakXTqRWm3EbPQfvzzjQABLKGE Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EF900A9@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 26 Jul 2010 21:03:13 -0000 On 7/26/10 1:22 PM, "John Panzer" wrote: > On Sat, Jul 24, 2010 at 12:18 AM, Eran Hammer-Lahav > wrote: >> >> >>> -----Original Message----- >>> From: John Panzer >>> Sent: Friday, July 23, 2010 6:37 PM >>> To: Blaine Cook >>> Cc: Eran Hammer-Lahav; apps-discuss@ietf.org >>> Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web >>> Host Metadata) to Proposed Standard >>> >>> That's also why I don't see "stop when you see the rel you're looking f= or" >>> as a >>> big help - you actually are looking for a collection where rel=3Dx in t= he >>> general >>> case (think rel=3Dalternate for a common example from other formats). = So you >>> have to get the set of links in some context, which could be the host-m= eta >>> document or the target of the lrdd template. >> >> The only way to avoid this is to forbid using link templates for anythin= g >> other than a single 'lrdd' link template, or even remove templates compl= etely >> and using a single link (non template) with relation 'lrdd' and a pre-de= fined >> way to include the context URI as a parameter. Otherwise, link templates= at >> the host-meta level are semantically equivalent to those in a LRDD docum= ent, >> not matter how much you try to pretend they are to be ignored. >> >> Can you offer some useful and predictable guidelines when a client shoul= d use >> link templates in host-meta and when it should not? When it should only = look >> for a single 'lrdd' document for all its metadata needs? How should an >> application developer decide where to put resource-specific links, if we >> follow your approach and treat the two sets (link templates in host-meta= , and >> links in a LRDD document) differently? What should I conclude from your silence on this? >> For your approach to work, we need to be able to solve these questions >> because semantically, all these links share the same context URI. We cre= ated >> a mechanism using link templates and defined it well. The processing rul= es in >> 4.2 are just the logical implementation of this framework. >> >>> But in general I agree with Blaine's primary objection; this adds an in= clude >>> model that has not been proven and which forces clients to provision fo= r a >>> nearly arbitrary number of worst-case http fetches. >> >> Servers can always do stupid things, like use too many redirections whic= h >> requires the same kind of handling. From a code perspective, processing = links >> from both host-meta and LRDD isn't that much more work - you already hav= e to >> process both. The ability to link to more than one LRDD document is some= thing >> that keeps coming up again and again when people want to reuse a descrip= tor >> document available elsewhere. >> >> 'lrdd' links have a very limited include semantic by limiting it to one >> level. >> >>> Query: Is it at least possible for a server to automatically merge mul= tiple >>> rel=3Dlrdd targets and serve up a single composite rel=3Dlrdd target re= source to >>> clients without impacting semantics? It's not clear to me from the spe= c. >> >> No idea what you mean. > > If I have a host-meta file to which a user has added, say, 5 rel=3D'lrdd' > templates, is it possible for me to replace all 5 with a single composite > (generated) document and a single (generated) rel=3D'lrdd' link to same, = without > breaking semantics? I don't understand how the "user" can "add" link templates to your host-met= a document. Who is this user and what is her relation to the host? Either way, multiple XRD documents can be easily combined into a single document (assuming you resolve the relationships between conflicting s, demoting some to es is there are conflicts). XRD documents resolve into a set of links, where the XRD subject is the context URI of the link. Therefore, semantically, it is trivial to take links from multiple XRD with the same subject and combine them (ideally, maintaining the order of links across documents). > Why one might want to do this: Performance, for the same reason that web > servers do things like dynamic spriting of images by combining multiple i= mages > into one larger image for delivery over the wire. And XRDs are things th= at > you typically won't be loading lazily as you would images -- things are g= oing > to block on pulling this information down. > > I don't think this is possible in the presence of XRD signatures. Those > appear to have been shelved though. Well, it depends who published the documents and who is the authority for signing them. > I am also not really a fan of "stop when you see what you want" That's reality. In practice, clients either look for the first matching lin= k and ignore everything else, or they collect all matching links and use them in some UI where a human selects a link. Do you have actual examples of cases where clients seek multiple links of the same type and choose one based on some external criteria (i.e. not document order or other link attributes that would narrow the selection back to one)? > because I > think it will make things harder to code and will lead to user surprises.= For > example, if a user _removes_ a single link, they may suddenly see dozens = of > links _added_ that were hidden or "shadowed" before. That's always the came when you pick one link out of many, and that link goes away. The only way to avoid it is to only allow one and break on any errors. > In the meantime, the > code itself already has to handle multiple links to work correctly (think > rel=3D"alternate"). Can you give real world examples where 'alternate' or other relation types are used to provide multiple links with the same relation type for a single resource? How does the client decide which link to use? > If it can just build up one dictionary (multi-valued) per > subject this isn't too bad, but if you also add in multiple "domains" wit= h > priority ordering between them this makes the code much more complicated = and > bug-prone. You end up with one collection of links which you can implement as a dictionary of ordered lists for each relation type (assuming you only care about the relation type as key). This is true no matter how many link templates are in host-meta, or how many LRDD documents are linked to. I don't know what you mean by 'multiple "domains"' > The slight gain in performance isn't really worth it compared to > just advising people not to do that. I wish we could prevent them from d= oing > it, is all. What gain in performance? I'm happy to include a note about servers SHOULD consolidate links as much as possible to make client processing faster. > I'm also not a big fan of relying on document ordering, as it's inherentl= y > fragile. The Atom working group rejected using it as a primary ordering > criteria (in favor of atom:updated by default). It will also cause probl= ems > for the mooted XRD JSON serialization. The most natural JSON serializati= on is > a map from relvalue strings to link record lists (see discussions on acti= vity > streams mailing list for details on why this is so). While JSON clearly = does > have a textual layout order for these maps, that information is typically > totally lost by most (all?) current JSON parsers. So you're faced with a > Hobson's choice of using an unnatural JSOn serialization (a list) which i= s > annoying and difficult for JSON users, or adding additional annoying and > difficult priority fields. We used to have a 'priority' attribute in XRD but the feedback was to drop it in favor of document ordering. It is very useful to be able to express precedence when dealing with an otherwise flat list of links. At the end of the day, if the client ends up with multiple qualifying links, it needs to know how to pick one. If you need multiple clients to pick the same one for consistency, you need to come up with rules. > Since at the end of the day you're interested in getting a set of links, = and > the relative ordering of the links within a relvalue is almost _never_ > relevant, I think this spec should follow the lead of the Atom specificat= ion > and ignore the document ordering. Applications can do that. But as a general rule, I think document order expresses some intend and can help clients make a better, more relevant decision. For example, get the first link and try it - if it doesn't work move on to the next, is a very common strategy. I am still not sure what actual changes you are proposing for the draft. EHL > >> >>> On Friday, July 23, 2010, Blaine Cook wrote: >>>> On 23 July 2010 21:12, Eran Hammer-Lahav >>> wrote: >>>>> ** If this is not clear, I am happy to make it more explicit in secti= on >>>>> 4.2, >>> including adding a full procedure for clients looking for a specific li= nk. >>>> >>>> +1 - In my reading of 4.2, I had overlooked the sentence in 4 that >>>> describes stopping whenever a suitable link relation is found. With >>>> that processing rule in place, the semantic is clear and simple. >>>> >>>>> However, if people would like to simplify this a bit, I am open to (b= ut >>>>> not >>> excited about) making a small change in which clients will first look f= or >>> (any) >>> 'lrdd' link templates, process them, and only then look for other link- >>> templates in host-meta. This exception will deviate from the normal XRD >>> processing rules of document order, but will move from a potential comp= lex >>> mix from link sources to a two stage procedure (LRDD links, then host-m= eta >>> link templates). Note that this does not solve the basic requirement to >>> construct the full resource descriptor from multiple location, only the >>> order in >>> which that is done. >>>> >>>> I'm not sure what others think about this, but I personally prefer >>>> this approach (LRDD-first, followed by host-level templates). The >>>> reasoning is that this gives LRDD profiles the ability to over-ride >>>> host-level decisions, whereas strictly following document ordering >>>> means that hosts could potentially force all users to use a single URL >>>> for a given rel value. >>>> >>>> The challenge is not so much that the hosts could force this (because >>>> a "malicious" host could over-write the rel value in ever user's LRDD >>>> document), but that interop becomes more challenging since any parser >>>> that does LRDD-first *might* disagree with a strictly ordered parser >>>> (an example where this is a real possibility: three parsers, one >>>> SAX-based, one XPath based, and one DOM-based, may come up with very >>>> different results if we rely on document ordering alone). >>>> >>>> b. > From James.H.Manger@team.telstra.com Mon Jul 26 18:25:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C3D3A672E for ; Mon, 26 Jul 2010 18:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.107 X-Spam-Level: X-Spam-Status: No, score=0.107 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 SbvQstNdF-RN for ; Mon, 26 Jul 2010 18:25:18 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 06AA83A63EC for ; Mon, 26 Jul 2010 18:25:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,264,1278252000"; d="scan'208,217";a="6611433" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 27 Jul 2010 11:25:33 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6055"; a="5077671" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccni.tcif.telstra.com.au with ESMTP; 27 Jul 2010 11:25:36 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Tue, 27 Jul 2010 11:25:35 +1000 From: "Manger, James H" To: John Panzer Date: Tue, 27 Jul 2010 11:25:34 +1000 Thread-Topic: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard Thread-Index: AcstAGUnkTECZ/MQRUKBQEZmvJ7gIwAI+AKg Message-ID: <255B9BB34FB7D647A506DC292726F6E11267BEDFC1@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EF8FD8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11267BEDFC1WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 27 Jul 2010 01:25:22 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11267BEDFC1WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, > If I have a host-meta file to which a user has added, say, > 5 rel=3D'lrdd' templates, is it possible for me to replace all 5 with > a single composite (generated) document and a single (generated) rel=3D'l= rdd' link > to same, without breaking semantics? Yes. You could make host-meta consist solely of a single rel=3D'lrdd' template (= and indicate that host-meta can be cached for a year) and serve one XRD for= each resource combining links from all 5. > ...the relative ordering of the links within a relvalue is almost _never_= relevant, Except when you are only expecting (or interested in) 1 link. The link (wit= hin a relvalue) that comes first does matter. Controlling which link comes first and ignoring the ordering of the rest is= no easier to implement than controlling the order of all links. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E11267BEDFC1WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

 

> If I have a host-meta file to which a user has added, say,

> 5 rel=3D'lrdd' templates, is it possible for me to replace all 5 with

> a single composite (generated) document and a single (ge= nerated) rel=3D'lrdd' link<= /p>

> to same, without breaking semantics?

 

Yes.

You could make host-meta consist solely of a single rel=3D&#= 8217;lrdd’ template (and indicate that host-meta can be cached for a = year) and serve one XRD for each resource combining links from all 5.

 

 

> …the relative ordering of the links within a relva= lue is almost _never_ relevant,

 

Except when you are on= ly expecting (or interested in) 1 link. The link (within a relvalue) that c= omes first does matter.

Controlling which link= comes first and ignoring the ordering of the rest is no easier to implemen= t than controlling the order of all links.

 

--

James Manger

--_000_255B9BB34FB7D647A506DC292726F6E11267BEDFC1WSMSG3153Vsrv_-- From jpanzer@google.com Mon Jul 26 20:53:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291853A681C for ; Mon, 26 Jul 2010 20:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.347 X-Spam-Level: X-Spam-Status: No, score=-97.347 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_47=0.6, 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 o540cGFG+sVy for ; Mon, 26 Jul 2010 20:53:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id ED4EC3A6817 for ; Mon, 26 Jul 2010 20:53:10 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o6R3rVJb024641 for ; Mon, 26 Jul 2010 20:53:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280202811; bh=g9tJYiNN0uY/FDZeGmYvyG57K+M=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Lidl7JKwb04TY4GFAhhMtYXtBR6VzWcjceS8tvWFPsoJWHa32AEWbdCLFJabSH/DA 9STJXr5MDKW1x/0K/u46Q== 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=GX3Ki88AdkrZ0tIJbctQ2pftjNP4QBE9Yz5OFdnRyCRNAiYj0Utew7adVAWGidSe+ rsSuKjPorqodw4Nmu/CmQ== Received: from ywa8 (ywa8.prod.google.com [10.192.1.8]) by hpaq1.eem.corp.google.com with ESMTP id o6R3rT6l027798 for ; Mon, 26 Jul 2010 20:53:30 -0700 Received: by ywa8 with SMTP id 8so626316ywa.31 for ; Mon, 26 Jul 2010 20:53:29 -0700 (PDT) Received: by 10.101.154.15 with SMTP id g15mr8771981ano.222.1280202809129; Mon, 26 Jul 2010 20:53:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.138.5 with HTTP; Mon, 26 Jul 2010 20:53:09 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EF900A9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EF900A9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Mon, 26 Jul 2010 20:53:09 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e68ef43eadb982048c56711a X-System-Of-Record: true Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard 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, 27 Jul 2010 03:53:15 -0000 --0016e68ef43eadb982048c56711a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 26, 2010 at 2:03 PM, Eran Hammer-Lahav wrote: > > > > On 7/26/10 1:22 PM, "John Panzer" wrote: > > > On Sat, Jul 24, 2010 at 12:18 AM, Eran Hammer-Lahav > > > wrote: > >> > >> > >>> -----Original Message----- > >>> From: John Panzer > >>> Sent: Friday, July 23, 2010 6:37 PM > >>> To: Blaine Cook > >>> Cc: Eran Hammer-Lahav; apps-discuss@ietf.org > >>> Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web > >>> Host Metadata) to Proposed Standard > >>> > >>> That's also why I don't see "stop when you see the rel you're looking > for" > >>> as a > >>> big help - you actually are looking for a collection where rel=x in the > >>> general > >>> case (think rel=alternate for a common example from other formats). So > you > >>> have to get the set of links in some context, which could be the > host-meta > >>> document or the target of the lrdd template. > >> > >> The only way to avoid this is to forbid using link templates for > anything > >> other than a single 'lrdd' link template, or even remove templates > completely > >> and using a single link (non template) with relation 'lrdd' and a > pre-defined > >> way to include the context URI as a parameter. Otherwise, link templates > at > >> the host-meta level are semantically equivalent to those in a LRDD > document, > >> not matter how much you try to pretend they are to be ignored. > >> > >> Can you offer some useful and predictable guidelines when a client > should use > >> link templates in host-meta and when it should not? When it should only > look > >> for a single 'lrdd' document for all its metadata needs? How should an > >> application developer decide where to put resource-specific links, if we > >> follow your approach and treat the two sets (link templates in > host-meta, and > >> links in a LRDD document) differently? > > What should I conclude from your silence on this? > Mostly, that I have a day job :). I'm not sure what the rationale behind link templates in host-meta are exactly. If I knew that I might be able to answer better. > > >> For your approach to work, we need to be able to solve these questions > >> because semantically, all these links share the same context URI. We > created > >> a mechanism using link templates and defined it well. The processing > rules in > >> 4.2 are just the logical implementation of this framework. > >> > >>> But in general I agree with Blaine's primary objection; this adds an > include > >>> model that has not been proven and which forces clients to provision > for a > >>> nearly arbitrary number of worst-case http fetches. > >> > >> Servers can always do stupid things, like use too many redirections > which > >> requires the same kind of handling. From a code perspective, processing > links > >> from both host-meta and LRDD isn't that much more work - you already > have to > >> process both. The ability to link to more than one LRDD document is > something > >> that keeps coming up again and again when people want to reuse a > descriptor > >> document available elsewhere. > >> > >> 'lrdd' links have a very limited include semantic by limiting it to one > >> level. > >> > >>> Query: Is it at least possible for a server to automatically merge > multiple > >>> rel=lrdd targets and serve up a single composite rel=lrdd target > resource to > >>> clients without impacting semantics? It's not clear to me from the > spec. > >> > >> No idea what you mean. > > > > If I have a host-meta file to which a user has added, say, 5 rel='lrdd' > > templates, is it possible for me to replace all 5 with a single composite > > (generated) document and a single (generated) rel='lrdd' link to same, > without > > breaking semantics? > > I don't understand how the "user" can "add" link templates to your > host-meta > document. Who is this user and what is her relation to the host? > The user would control the host-meta file for the host, which might be a third level hostname (x.appspot.com for example). > > Either way, multiple XRD documents can be easily combined into a single > document (assuming you resolve the relationships between conflicting > s, demoting some to es is there are conflicts). > > XRD documents resolve into a set of links, where the XRD subject is the > context URI of the link. Therefore, semantically, it is trivial to take > links from multiple XRD with the same subject and combine them (ideally, > maintaining the order of links across documents). > Great! > > > Why one might want to do this: Performance, for the same reason that web > > servers do things like dynamic spriting of images by combining multiple > images > > into one larger image for delivery over the wire. And XRDs are things > that > > you typically won't be loading lazily as you would images -- things are > going > > to block on pulling this information down. > > > > I don't think this is possible in the presence of XRD signatures. Those > > appear to have been shelved though. > > Well, it depends who published the documents and who is the authority for > signing them. > > > I am also not really a fan of "stop when you see what you want" > > That's reality. In practice, clients either look for the first matching > link > and ignore everything else, or they collect all matching links and use them > in some UI where a human selects a link. Do you have actual examples of > cases where clients seek multiple links of the same type and choose one > based on some external criteria (i.e. not document order or other link > attributes that would narrow the selection back to one)? > Since this isn't deployed, it's hard to come up with actual examples in the wild. Do you mean in analogous systems? Sure, link rel="alternate" type="appication/atom+xml" title=$TITLE. Decent feed readers show the list of $TITLEs to a user attempting to subscribe to a 'web page' and ask them which variant they want. > > > because I > > think it will make things harder to code and will lead to user surprises. > For > > example, if a user _removes_ a single link, they may suddenly see dozens > of > > links _added_ that were hidden or "shadowed" before. > > That's always the came when you pick one link out of many, and that link > goes away. The only way to avoid it is to only allow one and break on any > errors. > If the cardinality of the link is always 1, I'd suggest it would be a good idea to tell the user they've got something misconfigured if they supply more than 1, rather than guessing what they meant. Or at least, leave the decision up to higher level pieces of code that have an opportunity to talk to the user if appropriate/necessary. If the cardinality is N, I suggest that it is a very bad idea to pick the set you're going to pay attention to at random. > > > In the meantime, the > > code itself already has to handle multiple links to work correctly (think > > rel="alternate"). > > Can you give real world examples where 'alternate' or other relation types > are used to provide multiple links with the same relation type for a single > resource? How does the client decide which link to use? > See above. Also, consider rel="me" today with the Social Graph API. > > > If it can just build up one dictionary (multi-valued) per > > subject this isn't too bad, but if you also add in multiple "domains" > with > > priority ordering between them this makes the code much more complicated > and > > bug-prone. > > You end up with one collection of links which you can implement as a > dictionary of ordered lists for each relation type (assuming you only care > about the relation type as key). This is true no matter how many link > templates are in host-meta, or how many LRDD documents are linked to. > > This is not true. If I am building up a global view of _all_ links for $SUBJECT, then I need to keep track of where the links came from & keep them properly ordered under at least some of these proposals. E.g., if link A came from host-meta and preceded link B which came indirectly from link rel="lrdd", then I need to correctly separate A and B when queried later on. > I don't know what you mean by 'multiple "domains"' > > > The slight gain in performance isn't really worth it compared to > > just advising people not to do that. I wish we could prevent them from > doing > > it, is all. > > What gain in performance? I'm happy to include a note about servers SHOULD > consolidate links as much as possible to make client processing faster. > > > I'm also not a big fan of relying on document ordering, as it's > inherently > > fragile. The Atom working group rejected using it as a primary ordering > > criteria (in favor of atom:updated by default). It will also cause > problems > > for the mooted XRD JSON serialization. The most natural JSON > serialization is > > a map from relvalue strings to link record lists (see discussions on > activity > > streams mailing list for details on why this is so). While JSON clearly > does > > have a textual layout order for these maps, that information is typically > > totally lost by most (all?) current JSON parsers. So you're faced with a > > Hobson's choice of using an unnatural JSOn serialization (a list) which > is > > annoying and difficult for JSON users, or adding additional annoying and > > difficult priority fields. > > We used to have a 'priority' attribute in XRD but the feedback was to drop > it in favor of document ordering. Note that this feedback was considering only the XML format. > It is very useful to be able to express > precedence when dealing with an otherwise flat list of links. At the end of > the day, if the client ends up with multiple qualifying links, it needs to > know how to pick one. If you need multiple clients to pick the same one for > consistency, you need to come up with rules. > > > Since at the end of the day you're interested in getting a set of links, > and > > the relative ordering of the links within a relvalue is almost _never_ > > relevant, I think this spec should follow the lead of the Atom > specification > > and ignore the document ordering. > > Applications can do that. But as a general rule, I think document order > expresses some intend and can help clients make a better, more relevant > decision. For example, get the first link and try it - if it doesn't work > move on to the next, is a very common strategy. > > I am still not sure what actual changes you are proposing for the draft. > I'd like at least a note about minimizing and consolidating LRDD external references wherever possible. > > EHL > > > > >> > >>> On Friday, July 23, 2010, Blaine Cook wrote: > >>>> On 23 July 2010 21:12, Eran Hammer-Lahav > >>> wrote: > >>>>> ** If this is not clear, I am happy to make it more explicit in > section > >>>>> 4.2, > >>> including adding a full procedure for clients looking for a specific > link. > >>>> > >>>> +1 - In my reading of 4.2, I had overlooked the sentence in 4 that > >>>> describes stopping whenever a suitable link relation is found. With > >>>> that processing rule in place, the semantic is clear and simple. > >>>> > >>>>> However, if people would like to simplify this a bit, I am open to > (but > >>>>> not > >>> excited about) making a small change in which clients will first look > for > >>> (any) > >>> 'lrdd' link templates, process them, and only then look for other link- > >>> templates in host-meta. This exception will deviate from the normal XRD > >>> processing rules of document order, but will move from a potential > complex > >>> mix from link sources to a two stage procedure (LRDD links, then > host-meta > >>> link templates). Note that this does not solve the basic requirement to > >>> construct the full resource descriptor from multiple location, only the > >>> order in > >>> which that is done. > >>>> > >>>> I'm not sure what others think about this, but I personally prefer > >>>> this approach (LRDD-first, followed by host-level templates). The > >>>> reasoning is that this gives LRDD profiles the ability to over-ride > >>>> host-level decisions, whereas strictly following document ordering > >>>> means that hosts could potentially force all users to use a single URL > >>>> for a given rel value. > >>>> > >>>> The challenge is not so much that the hosts could force this (because > >>>> a "malicious" host could over-write the rel value in ever user's LRDD > >>>> document), but that interop becomes more challenging since any parser > >>>> that does LRDD-first *might* disagree with a strictly ordered parser > >>>> (an example where this is a real possibility: three parsers, one > >>>> SAX-based, one XPath based, and one DOM-based, may come up with very > >>>> different results if we rely on document ordering alone). > >>>> > >>>> b. > > > > --0016e68ef43eadb982048c56711a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 26, 2010 at 2:03 PM, Eran Hammer-Lah= av <eran@hueniv= erse.com> wrote:



On 7/26/10 1:22 PM, "John Panzer" <jpanzer@google.com> wrote:

> On Sat, Jul 24, 2010 at 12:18 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>>
>>
>>> -----Original Message-----
>>> From: John Panzer
>>> Sent: Friday, July 23,= 2010 6:37 PM
>>> To: Blaine Cook
>>> Cc: Eran Hammer-Lahav; apps-discuss@ietf.org
>>> Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostm= eta (Web
>>> Host Metadata) to Proposed Standard
>>>
>>> That's also why I don't see "stop when you see th= e rel you're looking for"
>>> as a
>>> big help - you actually are looking for a collection where rel= =3Dx in the
>>> general
>>> case (think rel=3Dalternate for a common example from other fo= rmats). =A0So you
>>> have to get the set of links in some context, which could be t= he host-meta
>>> document or the target of the lrdd template.
>>
>> The only way to avoid this is to forbid using link templates for a= nything
>> other than a single 'lrdd' link template, or even remove t= emplates completely
>> and using a single link (non template) with relation 'lrdd'= ; and a pre-defined
>> way to include the context URI as a parameter. Otherwise, link tem= plates at
>> the host-meta level are semantically equivalent to those in a LRDD= document,
>> not matter how much you try to pretend they are to be ignored.
>>
>> Can you offer some useful and predictable guidelines when a client= should use
>> link templates in host-meta and when it should not? When it should= only look
>> for a single 'lrdd' document for all its metadata needs? H= ow should an
>> application developer decide where to put resource-specific links,= if we
>> follow your approach and treat the two sets (link templates in hos= t-meta, and
>> links in a LRDD document) differently?

What should I conclude from your silence on this?

Mostly, that I have a day job :). =A0I'm not sur= e what the rationale behind link templates in host-meta are exactly. =A0If = I knew that I might be able to answer better.
=A0

>> For your approach to work, we need to be able to solve these quest= ions
>> because semantically, all these links share the same context URI. = We created
>> a mechanism using link templates and defined it well. The processi= ng rules in
>> 4.2 are just the logical implementation of this framework.
>>
>>> But in general I agree with Blaine's primary objection; th= is adds an include
>>> model that has not been proven and which forces clients to pro= vision for a
>>> nearly arbitrary number of worst-case http fetches.
>>
>> Servers can always do stupid things, like use too many redirection= s which
>> requires the same kind of handling. From a code perspective, proce= ssing links
>> from both host-meta and LRDD isn't that much more work - you a= lready have to
>> process both. The ability to link to more than one LRDD document i= s something
>> that keeps coming up again and again when people want to reuse a d= escriptor
>> document available elsewhere.
>>
>> 'lrdd' links have a very limited include semantic by limit= ing it to one
>> level.
>>
>>> Query: =A0Is it at least possible for a server to automaticall= y merge multiple
>>> rel=3Dlrdd targets and serve up a single composite rel=3Dlrdd = target resource to
>>> clients without impacting semantics? =A0It's not clear to = me from the spec.
>>
>> No idea what you mean.
>
> If I have a host-meta file to which a user has added, say, 5 rel=3D= 9;lrdd'
> templates, is it possible for me to replace all 5 with a single compos= ite
> (generated) document and a single (generated) rel=3D'lrdd' lin= k to same, without
> breaking semantics?

I don't understand how the "user" can "add" l= ink templates to your host-meta
document. Who is this user and what is her relation to the host?

The user would control the host-meta file for the= host, which might be a third level hostname (x.appspot.com for example).
=A0

Either way, multiple XRD documents can be easily combined into a single
document (assuming you resolve the relationships between conflicting
<Subject>s, demoting some to <Alias>es is there are conflicts).=

XRD documents resolve into a set of links, where the XRD subject is the
context URI of the link. Therefore, semantically, it is trivial to take
links from multiple XRD with the same subject and combine them (ideally, maintaining the order of links across documents).

=
Great!
=A0

> Why one might want to do this: =A0Performance, for the same reason tha= t web
> servers do things like dynamic spriting of images by combining multipl= e images
> into one larger image for delivery over the wire. =A0And XRDs are thin= gs that
> you typically won't be loading lazily as you would images -- thing= s are going
> to block on pulling this information down.
>
> I don't think this is possible in the presence of XRD signatures. = =A0Those
> appear to have been shelved though.

Well, it depends who published the documents and who is the authority= for
signing them.

> I am also not really a fan of "stop when you see what you want&qu= ot;

That's reality. In practice, clients either look for the first ma= tching link
and ignore everything else, or they collect all matching links and use them=
in some UI where a human selects a link. Do you have actual examples of
cases where clients seek multiple links of the same type and choose one
based on some external criteria (i.e. not document order or other link
attributes that would narrow the selection back to one)?

Since this isn't deployed, it's hard to come up w= ith actual examples in the wild. =A0Do you mean in analogous systems? =A0Su= re, link rel=3D"alternate" type=3D"appication/atom+xml"= title=3D$TITLE. =A0Decent feed readers show the list of $TITLEs to a user = attempting to subscribe to a 'web page' and ask them which variant = they want.
=A0

> because I
> think it will make things harder to code and will lead to user surpris= es. =A0For
> example, if a user _removes_ a single link, they may suddenly see doze= ns of
> links _added_ that were hidden or "shadowed" before.

That's always the came when you pick one link out of many, and th= at link
goes away. The only way to avoid it is to only allow one and break on any errors.

If the cardinality of the link = is always 1, I'd suggest it would be a good idea to tell the user they&= #39;ve got something misconfigured if they supply more than 1, rather than = guessing what they meant. =A0Or at least, leave the decision up to higher l= evel pieces of code that have an opportunity to talk to the user if appropr= iate/necessary.

If the cardinality is N, I suggest that it is a very ba= d idea to pick the set you're going to pay attention to at random.
=A0

> In the meantime, the
> code itself already has to handle multiple links to work correctly (th= ink
> rel=3D"alternate").

Can you give real world examples where 'alternate' or other r= elation types
are used to provide multiple links with the same relation type for a single=
resource? How does the client decide which link to use?

See above. =A0Also, consider rel=3D"me" today wi= th the Social Graph API.
=A0

> If it can just build up one dictionary (multi-valued) per
> subject this isn't too bad, but if you also add in multiple "= domains" with
> priority ordering between them this makes the code much more complicat= ed and
> bug-prone.

You end up with one collection of links which you can implement as a<= br> dictionary of ordered lists for each relation type (assuming you only care<= br> about the relation type as key). This is true no matter how many link
templates are in host-meta, or how many LRDD documents are linked to.


This is not true. =A0If I am building = up a global view of _all_ links for $SUBJECT, then I need to keep track of = where the links came from & keep them properly ordered under at least s= ome of these proposals. =A0E.g., if link A came from host-meta and preceded= link B which came indirectly from link rel=3D"lrdd", then I need= to correctly separate A and B when queried later on.
=A0
I don't know what you mean by 'multiple "domains"'

> The slight gain in performance isn't really worth it compared to > just advising people not to do that. =A0I wish we could prevent them f= rom doing
> it, is all.

What gain in performance? I'm happy to include a note about serve= rs SHOULD
consolidate links as much as possible to make client processing faster.

> I'm also not a big fan of relying on document ordering, as it'= s inherently
> fragile. =A0The Atom working group rejected using it as a primary orde= ring
> criteria (in favor of atom:updated by default). =A0It will also cause = problems
> for the mooted XRD JSON serialization. =A0The most natural JSON serial= ization is
> a map from relvalue strings to link record lists (see discussions on a= ctivity
> streams mailing list for details on why this is so). =A0While JSON cle= arly does
> have a textual layout order for these maps, that information is typica= lly
> totally lost by most (all?) current JSON parsers. =A0So you're fac= ed with a
> Hobson's choice of using an unnatural JSOn serialization (a list) = which is
> annoying and difficult for JSON users, or adding additional annoying a= nd
> difficult priority fields.

We used to have a 'priority' attribute in XRD but the feedbac= k was to drop
it in favor of document ordering.

Note that= this feedback was considering only the XML format.
=A0
It is very useful to be able to express
precedence when dealing with an otherwise flat list of links. At the end of=
the day, if the client ends up with multiple qualifying links, it needs to<= br> know how to pick one. If you need multiple clients to pick the same one for=
consistency, you need to come up with rules.

> Since at the end of the day you're interested in getting a set of = links, and
> the relative ordering of the links within a relvalue is almost _never_=
> relevant, I think this spec should follow the lead of the Atom specifi= cation
> and ignore the document ordering.

Applications can do that. But as a general rule, I think document ord= er
expresses some intend and can help clients make a better, more relevant
decision. For example, get the first link and try it - if it doesn't wo= rk
move on to the next, is a very common strategy.

I am still not sure what actual changes you are proposing for the draft.

I'd like at least a note about minimi= zing and consolidating LRDD external references wherever possible.
=A0

EHL

>
>>
>>> On Friday, July 23, 2010, Blaine Cook <romeda@gmail.com> wrote:
>>>> On 23 July 2010 21:12, Eran Hammer-Lahav <eran@hueniverse.com>
>>> wrote:
>>>>> ** If this is not clear, I am happy to make it more ex= plicit in section
>>>>> 4.2,
>>> including adding a full procedure for clients looking for a sp= ecific link.
>>>>
>>>> +1 - In my reading of 4.2, I had overlooked the sentence i= n 4 that
>>>> describes stopping whenever a suitable link relation is fo= und. With
>>>> that processing rule in place, the semantic is clear and s= imple.
>>>>
>>>>> However, if people would like to simplify this a bit, = I am open to (but
>>>>> not
>>> excited about) making a small change in which clients will fir= st look for
>>> (any)
>>> 'lrdd' link templates, process them, and only then loo= k for other link-
>>> templates in host-meta. This exception will deviate from the n= ormal XRD
>>> processing rules of document order, but will move from a poten= tial complex
>>> mix from link sources to a two stage procedure (LRDD links, th= en host-meta
>>> link templates). Note that this does not solve the basic requi= rement to
>>> construct the full resource descriptor from multiple location,= only the
>>> order in
>>> which that is done.
>>>>
>>>> I'm not sure what others think about this, but I perso= nally prefer
>>>> this approach (LRDD-first, followed by host-level template= s). The
>>>> reasoning is that this gives LRDD profiles the ability to = over-ride
>>>> host-level decisions, whereas strictly following document = ordering
>>>> means that hosts could potentially force all users to use = a single URL
>>>> for a given rel value.
>>>>
>>>> The challenge is not so much that the hosts could force th= is (because
>>>> a "malicious" host could over-write the rel valu= e in ever user's LRDD
>>>> document), but that interop becomes more challenging since= any parser
>>>> that does LRDD-first *might* disagree with a strictly orde= red parser
>>>> (an example where this is a real possibility: three parser= s, one
>>>> SAX-based, one XPath based, and one DOM-based, may come up= with very
>>>> different results if we rely on document ordering alone).<= br> >>>>
>>>> b.
>


--0016e68ef43eadb982048c56711a-- From ietfc@btconnect.com Tue Jul 27 03:39:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBB93A6AF9 for ; Tue, 27 Jul 2010 03:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_50=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIccwcbI8MMH for ; Tue, 27 Jul 2010 03:39:23 -0700 (PDT) Received: from c2beaomr05.btconnect.com (c2beaomr05.btconnect.com [213.123.26.183]) by core3.amsl.com (Postfix) with ESMTP id 7A5D13A68B0 for ; Tue, 27 Jul 2010 03:39:22 -0700 (PDT) Received: from pc6 (host86-145-196-228.range86-145.btcentralplus.com [86.145.196.228]) by c2beaomr05.btconnect.com with SMTP id FEH79093; Tue, 27 Jul 2010 11:39:29 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C4EB761.00E1, actions=tag Message-ID: <003201cb2d6f$05062660$4001a8c0@gateway.2wire.net> From: "t.petch" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> <00d501cb2b1b$6c68a5e0$4001a8c0@gateway.2wire.net> <67B58D1A-56E9-4843-8C32-A543CC61238A@frobbit.se> Date: Tue, 27 Jul 2010 11:35:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr05.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0203.4C4EB76E.0299,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: Apps Discuss Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 27 Jul 2010 10:39:25 -0000 Patrik Yes, thanks, those links work fine (and the original still fails:-( Tom Petch ----- Original Message ----- From: "Patrik Fältström" To: "t.petch" Cc: "John C Klensin" ; "Apps Discuss" Sent: Sunday, July 25, 2010 9:21 AM Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! > I read it when it arrived, and not from the Liaison page, but I now = > checked, and the two files are (which I reach by "clicking on the link" = > when being at the IETF in Maastricht): > > https://datatracker.ietf.org/documents/LIAISON/file1036.pdf > https://datatracker.ietf.org/documents/LIAISON/file1037.pdf > > If you have problems reaching the files, let me know and I will unicast = > them. > > Patrik > > On 24 jul 2010, at 12.31, t.petch wrote: > > > Has anyone actually read this liaison? I ask because every day, I = > click on the > > link, my browser spins its little icon for five minutes, after which I = > move on > > to something more productive:-( > >=20 > > Tom Petch > >=20 > > ----- Original Message ----- > > From: "John C Klensin" ; "John C Klensin" = > > > To: "Patrik F=E4ltstr=F6m" ; "Nicolas Williams" > > ; "Patrik Fltstr m" ; = > "Nicolas > > Williams" > > Cc: "Apps Discuss" ; "IAB IAB" ; = > "Apps > > Discuss" ; "IAB IAB" > > Sent: Friday, July 23, 2010 11:55 AM > > Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T = > regarding > > OIDs --volunteer needed! > >=20 > >=20 > >> --On Friday, July 23, 2010 07:58 +0200 Patrik Fltstr m > >> wrote: > >>=20 > >> { https://datatracker.ietf.org/liaison/903/ } > >>=20 > >>> That is basically what they want to do, right? > >>>=20 > >>> In IETF we have the DDDS algorithm that is in use for E.164 > >>> numbers, and similar mechanism is used for RFID tags by ONS > >>> that ECDS has defined. > >>>=20 > >>> So yes, that could be interesting. And I think we IETF can do > >>> something here. And because of that, yes, they might walk into > >>> "our turf". > >>>=20 > >>> But the question is what to tell ITU. > >>>=20 > >>> 1. That they of course can work with this > >>>=20 > >>> 2. That IETF thought OIDs in reality is an ISO thing, not ITU > >>> thing > >>=20 > >> Clarification: OIDs came out of one of the "ISO/IEC - ITU Joint > >> Development Agreement" projects. The relevant standards have > >> both ISO/IEC [JTC1] numbers and ISO numbers. And there are > >> allocation arcs, separately, for both. Indeed, one of the > >> questions we would have to sort out with ITU is whether ISO is > >> on board or whether this is really a proposal about the ITU arc > >> only. > >>=20 > >>=20 > >>> 3. That IETF is the SDO where DNS, and DNS like mechanisms are > >>> discussed > >>>=20 > >>> 4. That we have a history of good cooperation between ITU and > >>> IETF regarding for example ENUM > >>=20 > >> Well... :-( > >>=20 > >>> 5. That IETF is happy to do (is doing?) a resolution mechanism > >>> from OIDs to something else using DNS. > >>=20 > >> Wouldn't one set of sub-arcs of OIDs be more accurate here? > >>=20 > >>> The trouble is maybe how to formulate 5? > >>=20 > >> john > >=20 > From ietfc@btconnect.com Tue Jul 27 03:41:25 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 6A4123A6B87 for ; Tue, 27 Jul 2010 03:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.133 X-Spam-Level: X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[AWL=0.318, 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 a76aGPCbcQk7 for ; Tue, 27 Jul 2010 03:41:22 -0700 (PDT) Received: from c2beaomr05.btconnect.com (c2beaomr05.btconnect.com [213.123.26.183]) by core3.amsl.com (Postfix) with ESMTP id 6F4DE3A68B0 for ; Tue, 27 Jul 2010 03:41:22 -0700 (PDT) Received: from pc6 (host86-145-196-228.range86-145.btcentralplus.com [86.145.196.228]) by c2beaomr05.btconnect.com with SMTP id FEH79715; Tue, 27 Jul 2010 11:41:34 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C4EB7DE.01F4, actions=tag Message-ID: <003e01cb2d6f$4b47af40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Javier Ubillos" , References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> Date: Tue, 27 Jul 2010 11:37:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr05.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0204.4C4EB7E6.02A7,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 27 Jul 2010 10:41:25 -0000 How does this relate to http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf as discussed and critiqued on the RRG list? Tom Petch ----- Original Message ----- From: "Javier Ubillos" To: Sent: Monday, July 26, 2010 11:30 AM Subject: [apps-discuss] Name based sockets - Making individual submissionsknow > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From skissane@gmail.com Tue Jul 27 03:50:04 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2239A3A6B9D for ; Tue, 27 Jul 2010 03:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F01crJk1WHfk for ; Tue, 27 Jul 2010 03:50:02 -0700 (PDT) Received: from mail-vw0-f49.google.com (mail-vw0-f49.google.com [209.85.212.49]) by core3.amsl.com (Postfix) with ESMTP id D29183A6AEB for ; Tue, 27 Jul 2010 03:50:01 -0700 (PDT) Received: by vws11 with SMTP id 11so3111505vws.22 for ; Tue, 27 Jul 2010 03:50:23 -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=45p0cnejnJcm3KxhSOMqbDU+FQTmJg0fTaJUgl5JWq8=; b=YXmpDPMlClf+mOEYJqsw803qo/CML0c1Orgb8+h7TsO0TEkXlGNDSmkGoSJslpSUnT 8MImB+mPcsKWcMvZ3vxD0YIBh1x2DeAi1ZIObOj8lmP/6aeRXUoP34Wqw7HuG+PbgTPc tsuBzYc+w6sT3brl5pGzjNHRzPsD0SLQ4ZFVA= 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=L6vbiiJsLD5vmV/hR30BomDbOu+bNleIfehaQojhijBWHT1t3AshzlHhohPnFK4+/r WXPEfDGSjaljwY5Qxn+uVJXP86sr/bQJEU8bfNwKS9csPr5t4cYDQRuRkicC5MJk+nwG bzlKEspq9J6rMpwCs1CX2R+Nr60p090W0lQ68= MIME-Version: 1.0 Received: by 10.220.62.136 with SMTP id x8mr4863514vch.37.1280227823249; Tue, 27 Jul 2010 03:50:23 -0700 (PDT) Received: by 10.220.186.198 with HTTP; Tue, 27 Jul 2010 03:50:23 -0700 (PDT) In-Reply-To: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> Date: Tue, 27 Jul 2010 20:50:23 +1000 Message-ID: From: SJ Kissane To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 27 Jul 2010 10:50:04 -0000 Hi Looking at section 6 of the document, they define an .oid-res.org domain. Not that it really matters, but wouldn't that be better as .oid-res.arpa? Also, section 6 is defined in terms of the contents of DNS zone files. I don't think it should be using the phrase "zone file", it carries the implication that a DNS implementation must store its DNS records in a zone file, rather than some other format (e.g. relational database, LDAP entries, etc...) When really, their standard is not about the storage of DNS records in some file, its a standard about how a DNS server responds to certain queries [even if all that is needed to make the server so respond is to change the data in it, rather than any change to the code of the DNS implementation] Regards Simon 2010/7/22 Patrik F=E4ltstr=F6m : > IETF has received the following liaison: > > https://datatracker.ietf.org/liaison/903/ > > We need someone that can write a response to the liaison. I can help with= formalities. > > =A0 Patrik F=E4ltstr=F6m > =A0 Liaison from IETF to ITU-T > > P.S. My personal very quick reading of the liaison and related documents = together with Olaf Kolkman (as IAB chair) gave: From jav@sics.se Tue Jul 27 04:06:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8250C3A6A67 for ; Tue, 27 Jul 2010 04:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=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 dDx4mF2CXByY for ; Tue, 27 Jul 2010 04:06:27 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 52EE13A6AE6 for ; Tue, 27 Jul 2010 04:06:27 -0700 (PDT) Received: from [130.129.113.249] (dhcp-71f9.meeting.ietf.org [130.129.113.249]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id BB600400D2; Tue, 27 Jul 2010 13:06:47 +0200 (CEST) From: Javier Ubillos To: "t.petch" In-Reply-To: <003e01cb2d6f$4b47af40$4001a8c0@gateway.2wire.net> References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <003e01cb2d6f$4b47af40$4001a8c0@gateway.2wire.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-EoFoqsONDRYOzaVpWR1M" Date: Tue, 27 Jul 2010 13:06:47 +0200 Message-ID: <1280228807.9738.152.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 27 Jul 2010 11:06:28 -0000 --=-EoFoqsONDRYOzaVpWR1M Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It relates very much :) It's the continuation of what was proposed in that article. // Javier On Tue, 2010-07-27 at 11:37 +0200, t.petch wrote: > How does this relate to=20 > http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf > as discussed and critiqued on the RRG list? >=20 > Tom Petch >=20 >=20 > ----- Original Message -----=20 > From: "Javier Ubillos" > To: > Sent: Monday, July 26, 2010 11:30 AM > Subject: [apps-discuss] Name based sockets - Making individual submission= sknow >=20 >=20 > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > >=20 --=-EoFoqsONDRYOzaVpWR1M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxOvcUACgkQGBo5FLRz4gppmQCfSII99+StW76W7rt01CPtwTlw 7scAmwWptkEoNIL4BUyp/I+MmLTzb5hs =70VY -----END PGP SIGNATURE----- --=-EoFoqsONDRYOzaVpWR1M-- From patrik@frobbit.se Tue Jul 27 04:08: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 56D3E3A6AB9 for ; Tue, 27 Jul 2010 04:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISjiIhri7W8v for ; Tue, 27 Jul 2010 04:08:52 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 71F423A63D3 for ; Tue, 27 Jul 2010 04:08:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 9FB9CCD5BC36; Tue, 27 Jul 2010 13:09:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf3FxXpBvB+V; Tue, 27 Jul 2010 13:09:12 +0200 (CEST) Received: from [IPv6:2001:df8::96:226:bbff:fe15:8d13] (unknown [IPv6:2001:df8::96:226:bbff:fe15:8d13]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 2FDA9CD5BC2B; Tue, 27 Jul 2010 13:09:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-507--873442866" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Priority: 3 In-Reply-To: <003201cb2d6f$05062660$4001a8c0@gateway.2wire.net> Date: Tue, 27 Jul 2010 13:09:11 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> <00d501cb2b1b$6c68a5e0$4001a8c0@gateway.2wire.net> <67B58D1A-56E9-4843-8C32-A543CC61238A@frobbit.se> <003201cb2d6f$05062660$4001a8c0@gateway.2wire.net> To: t.petch X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 27 Jul 2010 11:08:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-507--873442866 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Weird, are you really trying = ? I.e. that URL works for me = (that's how I found the links I sent you). Anyway, you now have the documents. Patrik On 27 jul 2010, at 11.35, t.petch wrote: > Patrik >=20 > Yes, thanks, those links work fine (and the original still fails:-( >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Patrik F=E4ltstr=F6m" > To: "t.petch" > Cc: "John C Klensin" ; "Apps Discuss" = > Sent: Sunday, July 25, 2010 9:21 AM > Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T = regarding > OIDs --volunteer needed! >=20 >=20 >> I read it when it arrived, and not from the Liaison page, but I now =3D= >> checked, and the two files are (which I reach by "clicking on the = link" =3D >> when being at the IETF in Maastricht): >>=20 >> https://datatracker.ietf.org/documents/LIAISON/file1036.pdf >> https://datatracker.ietf.org/documents/LIAISON/file1037.pdf >>=20 >> If you have problems reaching the files, let me know and I will = unicast =3D >> them. >>=20 >> Patrik >>=20 >> On 24 jul 2010, at 12.31, t.petch wrote: >>=20 >>> Has anyone actually read this liaison? I ask because every day, I = =3D >> click on the >>> link, my browser spins its little icon for five minutes, after which = I =3D >> move on >>> to something more productive:-( >>> =3D20 >>> Tom Petch >>> =3D20 >>> ----- Original Message ----- >>> From: "John C Klensin" ; "John C Klensin" =3D >> >>> To: "Patrik F=3DE4ltstr=3DF6m" ; "Nicolas = Williams" >>> ; "Patrik Fltstr m" = ; =3D >> "Nicolas >>> Williams" >>> Cc: "Apps Discuss" ; "IAB IAB" ; = =3D >> "Apps >>> Discuss" ; "IAB IAB" >>> Sent: Friday, July 23, 2010 11:55 AM >>> Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T =3D >> regarding >>> OIDs --volunteer needed! >>> =3D20 >>> =3D20 >>>> --On Friday, July 23, 2010 07:58 +0200 Patrik Fltstr m >>>> wrote: >>>> =3D20 >>>> { https://datatracker.ietf.org/liaison/903/ } >>>> =3D20 >>>>> That is basically what they want to do, right? >>>>> =3D20 >>>>> In IETF we have the DDDS algorithm that is in use for E.164 >>>>> numbers, and similar mechanism is used for RFID tags by ONS >>>>> that ECDS has defined. >>>>> =3D20 >>>>> So yes, that could be interesting. And I think we IETF can do >>>>> something here. And because of that, yes, they might walk into >>>>> "our turf". >>>>> =3D20 >>>>> But the question is what to tell ITU. >>>>> =3D20 >>>>> 1. That they of course can work with this >>>>> =3D20 >>>>> 2. That IETF thought OIDs in reality is an ISO thing, not ITU >>>>> thing >>>> =3D20 >>>> Clarification: OIDs came out of one of the "ISO/IEC - ITU Joint >>>> Development Agreement" projects. The relevant standards have >>>> both ISO/IEC [JTC1] numbers and ISO numbers. And there are >>>> allocation arcs, separately, for both. Indeed, one of the >>>> questions we would have to sort out with ITU is whether ISO is >>>> on board or whether this is really a proposal about the ITU arc >>>> only. >>>> =3D20 >>>> =3D20 >>>>> 3. That IETF is the SDO where DNS, and DNS like mechanisms are >>>>> discussed >>>>> =3D20 >>>>> 4. That we have a history of good cooperation between ITU and >>>>> IETF regarding for example ENUM >>>> =3D20 >>>> Well... :-( >>>> =3D20 >>>>> 5. That IETF is happy to do (is doing?) a resolution mechanism >>>>> from OIDs to something else using DNS. >>>> =3D20 >>>> Wouldn't one set of sub-arcs of OIDs be more accurate here? >>>> =3D20 >>>>> The trouble is maybe how to formulate 5? >>>> =3D20 >>>> john >>> =3D20 >>=20 >=20 >=20 --Apple-Mail-507--873442866 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMTr5XrMabGguI180RAs7xAJ9oGnc6Iu7EvlRRXE45Do2C5eT4xACfdGmP e2xYyM/ZEhF1RJ4dSmXidGw= =NBN7 -----END PGP SIGNATURE----- --Apple-Mail-507--873442866-- From jaap@bartok.nlnetlabs.nl Tue Jul 27 04:30:38 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967C43A6AD0 for ; Tue, 27 Jul 2010 04:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEt9sbF4dqos for ; Tue, 27 Jul 2010 04:30:37 -0700 (PDT) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id 481AA3A6AA9 for ; Tue, 27 Jul 2010 04:30:35 -0700 (PDT) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id o6RBUtvQ024810; Tue, 27 Jul 2010 13:30:55 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <201007271130.o6RBUtvQ024810@bartok.nlnetlabs.nl> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-reply-to: References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> <00d501cb2b1b$6c68a5e0$4001a8c0@gateway.2wire.net> <67B58D1A-56E9-4843-8C32-A543CC61238A@frobbit.se> <003201cb2d6f$05062660$4001a8c0@gateway.2wire.net> Comments: In-reply-to =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= message dated "Tue, 27 Jul 2010 13:09:11 +0200." Date: Tue, 27 Jul 2010 13:30:55 +0200 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.5 (bartok.nlnetlabs.nl [127.0.0.1]); Tue, 27 Jul 2010 13:30:55 +0200 (CEST) Cc: Apps Discuss Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 27 Jul 2010 11:30:38 -0000 Weird, are you really trying ? I.e. that URL works for me (that's how I found the links I sent you). To confirm, that also works for me jaap From marc.blanchet@viagenie.ca Tue Jul 27 04:49:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89D23A6AD0 for ; Tue, 27 Jul 2010 04:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x89MZ8YbPAKz for ; Tue, 27 Jul 2010 04:49:21 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 89B0B3A690F for ; Tue, 27 Jul 2010 04:49:21 -0700 (PDT) Received: from dhcp-22ea.meeting.ietf.org (unknown [IPv6:2001:df8:0:32:5ab0:35ff:fe6a:294a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DF17321C27 for ; Tue, 27 Jul 2010 07:49:42 -0400 (EDT) Message-ID: <4C4EC7D4.8070702@viagenie.ca> Date: Tue, 27 Jul 2010 13:49:40 +0200 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] iri meeting cancelled 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, 27 Jul 2010 11:49:22 -0000 hello, just to inform you that we have cancelled the IRI meeting this week. it was scheduled wednesday 13h00 0.2 Berlin. The secretariat has been informed. (hint: a room in a good timeslot is now available...) Marc. -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From patrik@frobbit.se Tue Jul 27 05:21:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4B43A6BE7 for ; Tue, 27 Jul 2010 05:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XddnssOiqvYM for ; Tue, 27 Jul 2010 05:21:19 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id E799F3A6BE5 for ; Tue, 27 Jul 2010 05:21:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 2686DCD612F0 for ; Tue, 27 Jul 2010 14:21:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-yEfHSX7FPF for ; Tue, 27 Jul 2010 14:21:39 +0200 (CEST) Received: from [IPv6:2001:df8::96:226:bbff:fe15:8d13] (unknown [IPv6:2001:df8::96:226:bbff:fe15:8d13]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 9FB48CD612E5 for ; Tue, 27 Jul 2010 14:21:39 +0200 (CEST) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-514--869095275" Mime-Version: 1.0 (Apple Message framework v1081) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Tue, 27 Jul 2010 14:21:38 +0200 Content-Transfer-Encoding: 7bit Message-Id: <32D2B52F-A1AC-45D3-A6D0-C0F7106E585E@frobbit.se> References: To: Apps Discuss X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Subject: Re: [apps-discuss] How to find a service? 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, 27 Jul 2010 12:21:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-514--869095275 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 In the land of Dijkstra, and with the topic of "how to find a service", = I first asked myself whether I had to announce the room name, but, here = it is anyway: The meeting will be held in room 2.1. Patrik On 22 jul 2010, at 10.20, Patrik F=E4ltstr=F6m wrote: > We have had various discussions during the years on "how to find a = service". And we have many ways of doing it at the moment. For example: >=20 > - Just use a well known algorithm > - Look up A or AAAA record, and then use well known port number > - Look up MX, and then A/AAAA and use well known port number > - Look up SRV record, and use that hostname and port number > - Use a DDDS algorithm as defined somewhere > - Use mdns like services to "broadcast" information (or respond to = broadcast queries) > - : > - : >=20 > ...and many more... >=20 > Now we have other ways as well, like the two currently proposed = mechanisms that some people have seen discussed on the IETF list: >=20 > - What is described in draft-daboo-srv-caldav, which I in a sloppy way = describe as "use SRV records and then a well known path that should = result in an HTTP redirect" >=20 > - What is described in draft-faltstrom-uri, which I in a sloppy way = describe as "use URI records like we use SRV records, but get a full URI = back" >=20 >=20 > As we are so close to Maastricht, I do not find we have time for a = doodle regarding interested parties that want to talk about this. >=20 > I have therefore decided we meet on Wednesday July 28 at 08:00 (yes, = for a breakfast meeting). It will be by the IETF = registration/announcement board, OR, where a note on that very same = announcement board says. I guess it will be near or even where breakfast = is served... >=20 > I am deliberately sending this only to Apps Discuss as I think we = should start this discussion from the point of view of "the need = applications has". That said, please spread the word to other interested = parties. It is not supposed to be a "secret cabal meeting". >=20 > I envision a mailing list discussion after this first meeting. >=20 > Patrik >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-514--869095275 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMTs9TrMabGguI180RAszWAJwK6JcE9lItu+sKk0DHpSFBsmiB0gCeOKSz R4yKzX+El6EIkiC4wHWqemk= =NVf6 -----END PGP SIGNATURE----- --Apple-Mail-514--869095275-- From ietfc@btconnect.com Tue Jul 27 06:27:32 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 E17383A69D2 for ; Tue, 27 Jul 2010 06:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRj6Spj-FbyC for ; Tue, 27 Jul 2010 06:27:31 -0700 (PDT) Received: from c2beaomr08.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by core3.amsl.com (Postfix) with ESMTP id 6F29C3A6959 for ; Tue, 27 Jul 2010 06:27:31 -0700 (PDT) Received: from pc6 (host86-145-196-228.range86-145.btcentralplus.com [86.145.196.228]) by c2beaomr08.btconnect.com with SMTP id FCO29572; Tue, 27 Jul 2010 14:27:38 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C4EDECA.0257, actions=tag Message-ID: <013e01cb2d86$815092c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Jaap Akkerhuis" References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> <00d501cb2b1b$6c68a5e0$4001a8c0@gateway.2wire.net> <67B58D1A-56E9-4843-8C32-A543CC61238A@frobbit.se> <003201cb2d6f$05062660$4001a8c0@gateway.2wire.net> <201007271130.o6RBUtvQ024810@bartok.nlnetlabs.nl> Date: Tue, 27 Jul 2010 14:23:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0201.4C4EDED5.013A,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: Apps Discuss Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 27 Jul 2010 13:27:33 -0000 Yes, I really am clicking on the URL in the e-mail:-) Dredging up something from a deep, dark past, I tried it without the trailing solidus on the URL; and that works, so now all I have to do is to remember why that is so significant (apart from the obvious that one is a directory and the other is a file - and this is Windows Internet Explorer 6 which I am sure is significant). Subscribing to the MPLS-TP list, I do see ITU-T liaisons most weeks and those I can click on and retrieve without any difficulty. Tom Petch ----- Original Message ----- From: "Jaap Akkerhuis" To: "Patrik Fältström" Cc: "t.petch" ; "Apps Discuss" Sent: Tuesday, July 27, 2010 1:30 PM Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! > > > Weird, are you really trying > ? I.e. that URL works > for me (that's how I found the links I sent you). > > To confirm, that also works for me > > jaap From ietfc@btconnect.com Tue Jul 27 06:41: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 9B0033A690F for ; Tue, 27 Jul 2010 06:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FAKE_REPLY_C=2.012, J_CHICKENPOX_15=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 pBYWNO2ncdLF for ; Tue, 27 Jul 2010 06:41:52 -0700 (PDT) Received: from c2beaomr06.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id 6FD4E3A6994 for ; Tue, 27 Jul 2010 06:41:52 -0700 (PDT) Received: from pc6 (host86-145-196-228.range86-145.btcentralplus.com [86.145.196.228]) by c2beaomr06.btconnect.com with SMTP id DDA05230; Tue, 27 Jul 2010 14:42:01 +0100 (BST) Message-ID: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Javier Ubillos" Date: Tue, 27 Jul 2010 14:37:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0201.4C4EE234.023F,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 27 Jul 2010 13:41:53 -0000 > ----- Original Message ----- > From: "Javier Ubillos" > To: "t.petch" > Cc: ; > Sent: Tuesday, July 27, 2010 1:06 PM > Subject: Re: [apps-discuss] Name based sockets - Making individual > submissionsknow > > > It relates very much :) > It's the continuation of what was proposed in that article. > In which case, the critiques in draft-irtf-rrg-recommendation seem appropriate > // Javier > > On Tue, 2010-07-27 at 11:37 +0200, t.petch wrote: > > How does this relate to > > http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf > > as discussed and critiqued on the RRG list? > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Javier Ubillos" > > To: > > Sent: Monday, July 26, 2010 11:30 AM > > Subject: [apps-discuss] Name based sockets - Making individual submissionsknow > > From ietfc@btconnect.com Tue Jul 27 08:23: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 118783A6969 for ; Tue, 27 Jul 2010 08:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jV6iJJFw1hUC for ; Tue, 27 Jul 2010 08:23:36 -0700 (PDT) Received: from c2beaomr10.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id D3A473A689F for ; Tue, 27 Jul 2010 08:23:34 -0700 (PDT) Received: from pc6 (host86-145-196-228.range86-145.btcentralplus.com [86.145.196.228]) by c2beaomr10.btconnect.com with SMTP id EYD67106; Tue, 27 Jul 2010 16:21:51 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C4EF98F.0041, actions=tag Message-ID: <01ca01cb2d96$81941120$4001a8c0@gateway.2wire.net> From: "t.petch" To: "John C Klensin" , =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , "Nicolas Williams" References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> Date: Tue, 27 Jul 2010 16:16:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B020A.4C4EF9B5.023C,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: Apps Discuss Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 27 Jul 2010 15:23:37 -0000 Having read, marked, learnt and inwardly digested, ----- Original Message ----- From: "John C Klensin" ; "John C Klensin" To: "Patrik Fältström" ; "Nicolas Williams" ; "Patrik Fltstr m" ; "Nicolas Williams" Cc: "Apps Discuss" ; "IAB IAB" ; "Apps Discuss" ; "IAB IAB" Sent: Friday, July 23, 2010 11:55 AM > --On Friday, July 23, 2010 07:58 +0200 Patrik Fltstr m > wrote: > > { https://datatracker.ietf.org/liaison/903 trailing solidus elided} > > > That is basically what they want to do, right? > > > > In IETF we have the DDDS algorithm that is in use for E.164 > > numbers, and similar mechanism is used for RFID tags by ONS > > that ECDS has defined. > > > > So yes, that could be interesting. And I think we IETF can do > > something here. And because of that, yes, they might walk into > > "our turf". For me, the biggest bit of our turf is DNS, something critical to Internet operation and yet somewhat fragile, judging by my memory of the reaction to previous proposals to enhance it on the main IETF list ie they should not be using it unless the IETF DNS community says ok (e-mail security et al?) In practical terms, the basic idea would have been great had it appeared in 1976, but trying to retrofit it to all our existing SMI (not exactly ASN.1) definitions in ASCII (definitely not XSD/XML) documents is .. well, misguided. Yet I have my own hand-maintained list of nodes under mib-2 to RFC index which is one of those things I always have to hand for any practical work on SNMP, so having an online mechanism, at least down to the first arc from mib-2, would be most useful; just not the way it is specified here. I note that they are requesting comments on DNS and not really on any other aspect of their system. And the liaison is explicit, ITU-T SG17 and ISO. ..SC6, so yes, both would seem to be on board Tom Petch > > But the question is what to tell ITU. > > > > 1. That they of course can work with this > > > > 2. That IETF thought OIDs in reality is an ISO thing, not ITU > > thing > > Clarification: OIDs came out of one of the "ISO/IEC - ITU Joint > Development Agreement" projects. The relevant standards have > both ISO/IEC [JTC1] numbers and ISO numbers. And there are > allocation arcs, separately, for both. Indeed, one of the > questions we would have to sort out with ITU is whether ISO is > on board or whether this is really a proposal about the ITU arc > only. > > > 3. That IETF is the SDO where DNS, and DNS like mechanisms are > > discussed > > > > 4. That we have a history of good cooperation between ITU and > > IETF regarding for example ENUM > > Well... :-( > > > 5. That IETF is happy to do (is doing?) a resolution mechanism > > from OIDs to something else using DNS. > > Wouldn't one set of sub-arcs of OIDs be more accurate here? > > > The trouble is maybe how to formulate 5? > > john From Nicolas.Williams@oracle.com Tue Jul 27 09:27:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AEBA3A6A90 for ; Tue, 27 Jul 2010 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf8xsb6mJ2b1 for ; Tue, 27 Jul 2010 09:27:09 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2371D3A6880 for ; Tue, 27 Jul 2010 09:27:09 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6RGRTCd024096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Jul 2010 16:27:30 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6RG4Xnv018985; Tue, 27 Jul 2010 16:27:27 GMT Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 441175291280247977; Tue, 27 Jul 2010 09:26:17 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Jul 2010 09:26:16 -0700 Date: Tue, 27 Jul 2010 11:26:42 -0500 From: Nicolas Williams To: SJ Kissane Message-ID: <20100727162642.GD566@oracle.com> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C4F08F0.027E:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 27 Jul 2010 16:27:11 -0000 On Tue, Jul 27, 2010 at 08:50:23PM +1000, SJ Kissane wrote: > Looking at section 6 of the document, they define an .oid-res.org > domain. Not that it really matters, but wouldn't that be better as > .oid-res.arpa? Does it really matter? > Also, section 6 is defined in terms of the contents of DNS zone files. > I don't think it should be using the phrase "zone file", it carries > the implication that a DNS implementation must store its DNS records > in a zone file, rather than some other format (e.g. relational > database, LDAP entries, etc...) When really, their standard is not > about the storage of DNS records in some file, its a standard about > how a DNS server responds to certain queries [even if all that is > needed to make the server so respond is to change the data in it, > rather than any change to the code of the DNS implementation] This is standard DNS terminology. Zone file does not, in fact, imply a flat text file edited by hand, and it is certainly not taken to imply that. I understand why some people might think that it does, but that's a cultural problem. Nico -- From GK@ninebynine.org Tue Jul 27 09:30:59 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 4DF553A6AE9 for ; Tue, 27 Jul 2010 09:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99L7OX4CNaMm for ; Tue, 27 Jul 2010 09:30:57 -0700 (PDT) Received: from relay7.mail.ox.ac.uk (relay7.mail.ox.ac.uk [129.67.1.167]) by core3.amsl.com (Postfix) with ESMTP id 8728E3A680B for ; Tue, 27 Jul 2010 09:30:57 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay7.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1Odn3l-0004D9-N4; Tue, 27 Jul 2010 17:31:17 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Odn3k-0005U2-30; Tue, 27 Jul 2010 17:31:17 +0100 Message-ID: <4C4F08D6.8020802@ninebynine.org> Date: Tue, 27 Jul 2010 17:27:02 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "t.petch" References: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> In-Reply-To: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 27 Jul 2010 16:30:59 -0000 Writing as an interested onlooker rather than a proponent, I find it hard to see the relevance here. The scenario there that seems to come nearest is NOL (section 6), for which "At the edge network, we introduce a new type of gateway NTR (Name Transfer Relay)", which is not (AFAICT) in contention for named sockets. I understand the named socket approach is handled entirely by the application host, so there's no change to the IP routing structures that I can imagine. Generally, I'd say that if the document you cite wants to gain attention outside the routing community, it needs to be somewhat more clearly written. It seems to be riddled with acronyms whose meaning is hard to determine or not given (what's "CEE" and/or "CES"?). #g -- t.petch wrote: >> ----- Original Message ----- >> From: "Javier Ubillos" >> To: "t.petch" >> Cc: ; >> Sent: Tuesday, July 27, 2010 1:06 PM >> Subject: Re: [apps-discuss] Name based sockets - Making individual >> submissionsknow >> >> >> It relates very much :) >> It's the continuation of what was proposed in that article. >> > > In which case, the critiques in > draft-irtf-rrg-recommendation > seem appropriate > > > >> // Javier >> >> On Tue, 2010-07-27 at 11:37 +0200, t.petch wrote: >>> How does this relate to >>> http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf >>> as discussed and critiqued on the RRG list? >>> >>> Tom Petch >>> >>> >>> ----- Original Message ----- >>> From: "Javier Ubillos" >>> To: >>> Sent: Monday, July 26, 2010 11:30 AM >>> Subject: [apps-discuss] Name based sockets - Making individual > submissionsknow > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From Nicolas.Williams@oracle.com Tue Jul 27 09:49:38 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2ED03A69D9 for ; Tue, 27 Jul 2010 09:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnWTTrMLJQ43 for ; Tue, 27 Jul 2010 09:49:37 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id B0A6C3A688D for ; Tue, 27 Jul 2010 09:49:37 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6RGnvWu025057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Jul 2010 16:49:59 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6RGnrO6005870; Tue, 27 Jul 2010 16:49:54 GMT Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 461785981280249290; Tue, 27 Jul 2010 09:48:10 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Jul 2010 09:48:10 -0700 Date: Tue, 27 Jul 2010 11:48:37 -0500 From: Nicolas Williams To: "t.petch" Message-ID: <20100727164836.GE566@oracle.com> References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> <01ca01cb2d96$81941120$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ca01cb2d96$81941120$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4C4F0E34.00D1:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss , John C Klensin Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 27 Jul 2010 16:49:39 -0000 On Tue, Jul 27, 2010 at 04:16:22PM +0200, t.petch wrote: > > > So yes, that could be interesting. And I think we IETF can do > > > something here. And because of that, yes, they might walk into > > > "our turf". > > For me, the biggest bit of our turf is DNS, something critical to Internet > operation and yet somewhat fragile, judging by my memory of the reaction > to previous proposals to enhance it on the main IETF list ie they should not > be using it unless the IETF DNS community says ok (e-mail security et al?) Some kinds of enhancements to the DNS clearly belong firmly in IETF hands, and specifically in whatever WG(s) is(are) currently chartered to maintain and/or extend DNS. However, it is not remotely true that making innovative uses of DNS requires IETF approval -- plenty of people make use of SRV and TXT RRs in ways never approved by the IETF. (For example, Windows / Active Directory makes extensive use of SRV RRs. And people use all sorts of TXT RR naming and RDATA conventions in intranets all the time. Sure, some folks might complain that some such uses should be standardized, and that some such uses should be replaced by new RR types, but complain is all they can do.) I've not read the ITU-T proposal in detail, but a cursory look indicates that it involves a straightforward mapping of OID arc names and numbers onto the DNS using NAPTR RRs. That's not necessarily how I'd have done it, but it isn't exactly "wrong" either. Moreover, the use of a specific domain (oid-res.org) to host the root of the OID resolution name space that there's zero chance of any conflicts between the ORS and the rest of the DNS. It's possible I'll find something to dislike about this proposal, but unlikely that I'll be able to argue convincingly that the IETF has any kind of veto power over this specific proposal. I don't oppose the ITU-T's use of DNS in this way. I would oppose any proposal from the ITU-T to, say, add DNS RR types outside the IETF, but the ITU-T is making no such proposal. > In practical terms, the basic idea would have been great had it appeared in > 1976, but trying to retrofit it to all our existing SMI (not exactly ASN.1) > definitions in ASCII (definitely not XSD/XML) documents is .. > well, misguided. Really? Why? The DNS did not exist in 1976, incidentally. Can you expand on why any of this is misguided? Nico -- From ietfc@btconnect.com Tue Jul 27 10:13:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219AB3A6952 for ; Tue, 27 Jul 2010 10:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.944, 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 bieaGkSmHKqV for ; Tue, 27 Jul 2010 10:13:26 -0700 (PDT) Received: from c2bthomr06.btconnect.com (c2bthomr06.btconnect.com [213.123.20.124]) by core3.amsl.com (Postfix) with ESMTP id EE9DD3A6907 for ; Tue, 27 Jul 2010 10:13:25 -0700 (PDT) Received: from pc6 (host86-145-196-228.range86-145.btcentralplus.com [86.145.196.228]) by c2bthomr06.btconnect.com with SMTP id FWM87892; Tue, 27 Jul 2010 18:13:29 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C4F13B8.034A, actions=tag Message-ID: <002801cb2da6$1327fd40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Nicolas Williams" References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> <01ca01cb2d96$81941120$4001a8c0@gateway.2wire.net> <20100727164836.GE566@oracle.com> Date: Tue, 27 Jul 2010 18:02:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2bthomr06.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0202.4C4F13C8.008B,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: Apps Discuss Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 27 Jul 2010 17:13:28 -0000 ----- Original Message ----- From: "Nicolas Williams" To: "t.petch" Cc: "John C Klensin" ; "Patrik Fältström" ; "Apps Discuss" Sent: Tuesday, July 27, 2010 6:48 PM > I don't oppose the ITU-T's use of DNS in this way. I would oppose any > proposal from the ITU-T to, say, add DNS RR types outside the IETF, but > the ITU-T is making no such proposal. > > > In practical terms, the basic idea would have been great had it appeared in > > 1976, but trying to retrofit it to all our existing SMI (not exactly ASN.1) > > definitions in ASCII (definitely not XSD/XML) documents is .. > > well, misguided. > > Really? Why? The DNS did not exist in 1976, incidentally. Can you > expand on why any of this is misguided? Yup, 1976 was when ASN.1 came into my orbit. What I am saying is that if you want to build an index, a database to allow ready access to a vast range of instances, then the time to do it is when you start, not trying to retrofit it later. SMI is ASN.1 frozen in time, seeing no good reason to come up to date in ASN.1 terms. Likewise our ASCII RFC represent a way of doing things that was leading edge 30 years ago; itstill serves us well and I resist a change to eg XML. So this ISO/ITU-T proposal is using current technology that I do not see retrofitting well to our aarchives of usage of the ISO/ITU-T object tree; like I said, I maintain an index hand-written on paper. Tom Petch > Nico > -- From ietfc@btconnect.com Tue Jul 27 10:13:42 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4F53A6A67 for ; Tue, 27 Jul 2010 10:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, J_CHICKENPOX_15=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 6N6RjjyIT4uJ for ; Tue, 27 Jul 2010 10:13:39 -0700 (PDT) Received: from c2bthomr06.btconnect.com (c2bthomr06.btconnect.com [213.123.20.124]) by core3.amsl.com (Postfix) with ESMTP id D96AD3A6880 for ; Tue, 27 Jul 2010 10:13:38 -0700 (PDT) Received: from pc6 (host86-145-196-228.range86-145.btcentralplus.com [86.145.196.228]) by c2bthomr06.btconnect.com with SMTP id FWM87920; Tue, 27 Jul 2010 18:13:43 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C4F13B8.034A, actions=tag Message-ID: <002901cb2da6$1ad85f80$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Graham Klyne" References: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> <4C4F08D6.8020802@ninebynine.org> Date: Tue, 27 Jul 2010 18:09:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2bthomr06.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0204.4C4F13D5.014F,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 27 Jul 2010 17:13:42 -0000 ----- Original Message ----- From: "Graham Klyne" To: "t.petch" Cc: "Javier Ubillos" ; Sent: Tuesday, July 27, 2010 6:27 PM > Writing as an interested onlooker rather than a proponent, I find it hard to see > the relevance here. > > The scenario there that seems to come nearest is NOL (section 6), for which "At > the edge network, we introduce a new type of gateway NTR (Name Transfer Relay)", > which is not (AFAICT) in contention for named sockets. I understand the named > socket approach is handled entirely by the application host, so there's no > change to the IP routing structures that I can imagine. > > Generally, I'd say that if the document you cite wants to gain attention outside > the routing community, it needs to be somewhat more clearly written. It seems > to be riddled with acronyms whose meaning is hard to determine or not given > (what's "CEE" and/or "CES"?). It is section 15 that I had in mind, which is based on Christian Vogt's paper which Javier says has evolved into this I-D. There is a summary and critique there but I had forgotten that the better critique made it to the mailing list but not to the rrg I-D. The aim of all the proposals in the rrg I-D is to support such as "Applications are thus relieved of re-implementing features such as multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and address management in general." Murray queried why that was there; well, that was what I saw as the purpose of name based sockets in the first instance. Tom Petch > > #g > -- > > t.petch wrote: > >> ----- Original Message ----- > >> From: "Javier Ubillos" > >> To: "t.petch" > >> Cc: ; > >> Sent: Tuesday, July 27, 2010 1:06 PM > >> Subject: Re: [apps-discuss] Name based sockets - Making individual > >> submissionsknow > >> > >> > >> It relates very much :) > >> It's the continuation of what was proposed in that article. > >> > > > > In which case, the critiques in > > draft-irtf-rrg-recommendation > > seem appropriate > > > > > > > >> // Javier > >> > >> On Tue, 2010-07-27 at 11:37 +0200, t.petch wrote: > >>> How does this relate to > >>> http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf > >>> as discussed and critiqued on the RRG list? > >>> > >>> Tom Petch > >>> > >>> > >>> ----- Original Message ----- > >>> From: "Javier Ubillos" > >>> To: > >>> Sent: Monday, July 26, 2010 11:30 AM > >>> Subject: [apps-discuss] Name based sockets - Making individual > > submissionsknow > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > From Nicolas.Williams@oracle.com Tue Jul 27 10:16: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 5EBF43A68D5 for ; Tue, 27 Jul 2010 10:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv-IyKEcABO0 for ; Tue, 27 Jul 2010 10:16:06 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8C3F23A6880 for ; Tue, 27 Jul 2010 10:16:06 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6RHGRWa002427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Jul 2010 17:16:28 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6RHGPRl015530; Tue, 27 Jul 2010 17:16:26 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 441347701280250983; Tue, 27 Jul 2010 10:16:23 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Jul 2010 10:16:23 -0700 Date: Tue, 27 Jul 2010 12:16:49 -0500 From: Nicolas Williams To: "t.petch" Message-ID: <20100727171649.GH566@oracle.com> References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> <01ca01cb2d96$81941120$4001a8c0@gateway.2wire.net> <20100727164836.GE566@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100727164836.GE566@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C4F146B.00AB:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss , John C Klensin Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 27 Jul 2010 17:16:07 -0000 If I've any problem with the ITU-T it's likely to be around IDNA (it seems to refer to IDNA2003; it'd be better to make it IDNA2008), and security (it really should RECOMMEND that DNSSEC be used and discuss the consequences of not using DNSSEC). Also, I think the IANA should look at the RINF (registration information) module and see what else they might want to be added to it, if anything. Nico -- From Nicolas.Williams@oracle.com Tue Jul 27 10:38:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCBB3A6BD9 for ; Tue, 27 Jul 2010 10:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPa5CivBRiGl for ; Tue, 27 Jul 2010 10:37:44 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 827AC3A6BCC for ; Tue, 27 Jul 2010 10:32:43 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6RHWWBt017776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Jul 2010 17:32:34 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6R9wMhH015346; Tue, 27 Jul 2010 17:32:23 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 441394221280251937; Tue, 27 Jul 2010 10:32:17 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Jul 2010 10:32:17 -0700 Date: Tue, 27 Jul 2010 12:32:45 -0500 From: Nicolas Williams To: "t.petch" Message-ID: <20100727173245.GI566@oracle.com> References: <3E488AEAD1F240B208BF745E@PST.JCK.COM> <01ca01cb2d96$81941120$4001a8c0@gateway.2wire.net> <20100727164836.GE566@oracle.com> <002801cb2da6$1327fd40$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002801cb2da6$1327fd40$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C4F182C.025F:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs --volunteer needed! 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, 27 Jul 2010 17:38:10 -0000 On Tue, Jul 27, 2010 at 06:02:09PM +0200, t.petch wrote: > > Really? Why? The DNS did not exist in 1976, incidentally. Can you > > expand on why any of this is misguided? > > Yup, 1976 was when ASN.1 came into my orbit. What I am saying is that > if you want to build an index, a database to allow ready access to a vast range > of instances, then the time to do it is when you start, not trying to > retrofit it later. SMI is ASN.1 frozen in time, seeing no good reason to come > up to date in ASN.1 terms. [...] What a silly argument! The Internet didn't have a DNS before 1986, so why did anyone bother inventing the DNS then? Why didn't they say "hey, there was no DNS in 1981, and that's when it should have been done, so now it's too late, sorry, no DNS ever because they screwed up! now we're all stuck with hand-edited hosts files forever". Like it or not, the OID namespace is based on delegations of child node registration of authority, and like it or not anyone can produce a protocol to enable delegation-based name resolution of OIDs, at any time. If the ASN.1 had had such a thing back in 1976, we would still be free to replace it, just as we are free to create it now. And since the OID namespace is so well matched to the DNS, using DNS for OID resolution is just too obvious. > [...]. Likewise our ASCII RFC represent a way of > doing things that was leading edge 30 years ago; itstill serves us well and I > resist a change to eg XML. So this ISO/ITU-T proposal is using current > technology that I do not see retrofitting well to our aarchives of usage of > the ISO/ITU-T object tree; like I said, I maintain an index hand-written on > paper. You can stay in the stone age if you like, but you can't keep the rest of us there with you :) Nico -- From GK@ninebynine.org Tue Jul 27 12:16:32 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 F17223A68C2 for ; Tue, 27 Jul 2010 12:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOSToP0klMHx for ; Tue, 27 Jul 2010 12:16:30 -0700 (PDT) Received: from relay4.mail.ox.ac.uk (relay4.mail.ox.ac.uk [129.67.1.163]) by core3.amsl.com (Postfix) with ESMTP id 7BB023A687B for ; Tue, 27 Jul 2010 12:16:30 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay4.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1Odpdz-0006k9-Fh; Tue, 27 Jul 2010 20:16:51 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Odpdz-0002FK-54; Tue, 27 Jul 2010 20:16:51 +0100 Message-ID: <4C4F2E30.7040107@ninebynine.org> Date: Tue, 27 Jul 2010 20:06:24 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "t.petch" References: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> <4C4F08D6.8020802@ninebynine.org> <002901cb2da6$1ad85f80$4001a8c0@gateway.2wire.net> In-Reply-To: <002901cb2da6$1ad85f80$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 27 Jul 2010 19:16:32 -0000 Thanks - for some reason I missed that, thinking I'd got to the end. Oh well. FWIW, I think the named sockets draft acknowledges what I see as the substantive point in the critique (not applicable to all protocols). And I think I (initially) saw the purpose of named sockets in the way you mention. #g -- t.petch wrote: > ----- Original Message ----- > From: "Graham Klyne" > To: "t.petch" > Cc: "Javier Ubillos" ; > Sent: Tuesday, July 27, 2010 6:27 PM > >> Writing as an interested onlooker rather than a proponent, I find it hard to > see >> the relevance here. >> >> The scenario there that seems to come nearest is NOL (section 6), for which > "At >> the edge network, we introduce a new type of gateway NTR (Name Transfer > Relay)", >> which is not (AFAICT) in contention for named sockets. I understand the named >> socket approach is handled entirely by the application host, so there's no >> change to the IP routing structures that I can imagine. >> >> Generally, I'd say that if the document you cite wants to gain attention > outside >> the routing community, it needs to be somewhat more clearly written. It seems >> to be riddled with acronyms whose meaning is hard to determine or not given >> (what's "CEE" and/or "CES"?). > > It is section 15 that I had in mind, which is based on Christian Vogt's paper > which Javier says has evolved into this I-D. There is a summary and critique > there but I had forgotten that the better critique made it to the mailing list > but not to the rrg I-D. The aim of all the proposals in the rrg I-D is to > support such as > > "Applications are thus relieved of re-implementing features such as > multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and > address management in general." > > Murray queried why that was there; well, that was what I saw as the purpose of > name based sockets in the first instance. > > Tom Petch > > >> #g >> -- >> >> t.petch wrote: >>>> ----- Original Message ----- >>>> From: "Javier Ubillos" >>>> To: "t.petch" >>>> Cc: ; >>>> Sent: Tuesday, July 27, 2010 1:06 PM >>>> Subject: Re: [apps-discuss] Name based sockets - Making individual >>>> submissionsknow >>>> >>>> >>>> It relates very much :) >>>> It's the continuation of what was proposed in that article. >>>> >>> >>> In which case, the critiques in >>> draft-irtf-rrg-recommendation >>> seem appropriate >>> >>> >>> >>>> // Javier >>>> >>>> On Tue, 2010-07-27 at 11:37 +0200, t.petch wrote: >>>>> How does this relate to >>>>> http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf >>>>> as discussed and critiqued on the RRG list? >>>>> >>>>> Tom Petch >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Javier Ubillos" >>>>> To: >>>>> Sent: Monday, July 26, 2010 11:30 AM >>>>> Subject: [apps-discuss] Name based sockets - Making individual >>> submissionsknow >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From patrik@frobbit.se Tue Jul 27 21:36: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 4FE733A6869 for ; Tue, 27 Jul 2010 21:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po0LYHtT9gRp for ; Tue, 27 Jul 2010 21:36:39 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id CF82A3A67C2 for ; Tue, 27 Jul 2010 21:36:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 4F5EECD95A78; Wed, 28 Jul 2010 06:37:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqMgN0fVJdGu; Wed, 28 Jul 2010 06:37:00 +0200 (CEST) Received: from dhcp-10-55-80-132.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id DF894CD95A70; Wed, 28 Jul 2010 06:36:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-540--810573658" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100727162642.GD566@oracle.com> Date: Wed, 28 Jul 2010 06:37:00 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <20100727162642.GD566@oracle.com> To: Nicolas Williams X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 28 Jul 2010 04:36:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-540--810573658 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 27 jul 2010, at 18.26, Nicolas Williams wrote: > On Tue, Jul 27, 2010 at 08:50:23PM +1000, SJ Kissane wrote: >> Looking at section 6 of the document, they define an .oid-res.org >> domain. Not that it really matters, but wouldn't that be better as >> .oid-res.arpa? > > Does it really matter? Yes it does. .ARPA is explicitly under control of IAB. Patrik --Apple-Mail-540--810573658 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMT7PsrMabGguI180RAi6HAJ9WC8cHTY0wqGWzP8u+B350yzO2XgCfQhZo JnW+2hGQSQXsLqWzApMzehY= =UB3q -----END PGP SIGNATURE----- --Apple-Mail-540--810573658-- From patrik@frobbit.se Tue Jul 27 21:46: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 66A553A69C2 for ; Tue, 27 Jul 2010 21:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3U06bSn41Kj for ; Tue, 27 Jul 2010 21:46:07 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 6EE343A69B5 for ; Tue, 27 Jul 2010 21:46:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 777E6CD95D06; Wed, 28 Jul 2010 06:46:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB-HFztawGWG; Wed, 28 Jul 2010 06:46:25 +0200 (CEST) Received: from dhcp-10-55-80-132.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id BDE59CD95CFB; Wed, 28 Jul 2010 06:46:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-541--810009069" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> Date: Wed, 28 Jul 2010 06:46:25 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <20100727162642.GD566@oracle.com> <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> To: Apps Discuss X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 28 Jul 2010 04:46:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-541--810009069 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To go back to my original question, do we have anyone wanting to hold = the pen regarding writing a 1-page response, or maybe 2? I.e. not much = text is needed, not a review of their "stuff". More a note in the form = of "thank, we do this plase, remember that we exist". Nicolas? Patrik --Apple-Mail-541--810009069 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD4DBQFMT7YhrMabGguI180RAu/BAJ40fJ6GnUiN0yeAbZo68hWq4Efl6wCVFgCa 4dX0NQ/flRNCL+S0Ih1iHQ== =zdET -----END PGP SIGNATURE----- --Apple-Mail-541--810009069-- From Nicolas.Williams@oracle.com Tue Jul 27 21:53:44 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 4CDAF3A6863 for ; Tue, 27 Jul 2010 21:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYKMG8q1j0LS for ; Tue, 27 Jul 2010 21:53:43 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6C0DE3A67E7 for ; Tue, 27 Jul 2010 21:53:43 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6S4s3i0029256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jul 2010 04:54:05 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6RJAuK4024451; Wed, 28 Jul 2010 04:53:59 GMT Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 442973821280292810; Tue, 27 Jul 2010 21:53:30 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Jul 2010 21:53:29 -0700 Date: Tue, 27 Jul 2010 23:53:24 -0500 From: Nicolas Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20100728045324.GV566@oracle.com> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <20100727162642.GD566@oracle.com> <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C4FB7EB.0026:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 28 Jul 2010 04:53:44 -0000 On Wed, Jul 28, 2010 at 06:37:00AM +0200, Patrik Fältström wrote: > On 27 jul 2010, at 18.26, Nicolas Williams wrote: > > > On Tue, Jul 27, 2010 at 08:50:23PM +1000, SJ Kissane wrote: > >> Looking at section 6 of the document, they define an .oid-res.org > >> domain. Not that it really matters, but wouldn't that be better as > >> .oid-res.arpa? > > > > Does it really matter? > > Yes it does. .ARPA is explicitly under control of IAB. That's.. not what I meant. What I meant: Q: Is there any reason why it must be .something.arpa. instead of .oid-res.org.? I shall answer myself: A: Yes, it does matter for the simple reason that we already have a root for URN lookups, and it's .urn.arpa. [RFC3403] [RFC3404]. The correct affix should be .oid.urn.arpa. (Note that the IAB would not have to approve of .oid.urn.arpa.) In fact, is there any reason to think that DDDS is not enough? I'd like to see a discussion of that first. Nico -- From Nicolas.Williams@oracle.com Tue Jul 27 21:59: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 BE7933A6782 for ; Tue, 27 Jul 2010 21:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82TkQml+AFQQ for ; Tue, 27 Jul 2010 21:59:26 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BD4013A6824 for ; Tue, 27 Jul 2010 21:59:26 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6S4xlOX007097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jul 2010 04:59:48 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6S4IYcJ006547; Wed, 28 Jul 2010 04:59:46 GMT Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 463255241280293176; Tue, 27 Jul 2010 21:59:36 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Jul 2010 21:59:36 -0700 Date: Tue, 27 Jul 2010 23:59:31 -0500 From: Nicolas Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20100728045931.GW566@oracle.com> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <20100727162642.GD566@oracle.com> <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C4FB942.01D3:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 28 Jul 2010 04:59:27 -0000 On Wed, Jul 28, 2010 at 06:46:25AM +0200, Patrik Fältström wrote: > To go back to my original question, do we have anyone wanting to hold > the pen regarding writing a 1-page response, or maybe 2? I.e. not much > text is needed, not a review of their "stuff". More a note in the form > of "thank, we do this plase, remember that we exist". I could write it, but I know nothing about the ITU-T other than how to find such things as x.680, x.690 and friends. I think an expert in DDDS would be much more appropriate, or at least I'd like to see a review from a DDDS expert. I'm not sufficiently familiar with DDDS to know whether it can be leveraged to create an OID resolution mechanism without any additional specifications (at first glance it sure seems that way!). Of course, the schemas for documents to be found via DDDS, such as those introduced in the ITU-T proposal, do need to be specified, but the resolution mechanism is provided for by DDDS already, no? > Nicolas? Volunteer and opinion, get volunteered for the job. I get it. :( :) Well, like I said, I think someone with DDDS experience should look at this first. Nico -- From patrik@frobbit.se Tue Jul 27 22:20:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA803A69BD for ; Tue, 27 Jul 2010 22:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55ZnlkoAlJcD for ; Tue, 27 Jul 2010 22:19:59 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 6BDBB3A6915 for ; Tue, 27 Jul 2010 22:19:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D4E8CCD97FD5; Wed, 28 Jul 2010 07:20:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptDGrG6iqph6; Wed, 28 Jul 2010 07:20:19 +0200 (CEST) Received: from dhcp-10-55-80-132.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 5F916CD97FCD; Wed, 28 Jul 2010 07:20:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-546--807975566" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100728045324.GV566@oracle.com> Date: Wed, 28 Jul 2010 07:20:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2EB5DB06-1935-4BF7-84DF-1D45EE713391@frobbit.se> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <20100727162642.GD566@oracle.com> <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> <20100728045324.GV566@oracle.com> To: Nicolas Williams X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 28 Jul 2010 05:20:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-546--807975566 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 28 jul 2010, at 06.53, Nicolas Williams wrote: > That's.. not what I meant. What I meant: > > Q: Is there any reason why it must be .something.arpa. instead of > .oid-res.org.? I shall answer myself: > > A: Yes, it does matter for the simple reason that we already have a root > for URN lookups, and it's .urn.arpa. [RFC3403] [RFC3404]. The > correct affix should be .oid.urn.arpa. > > (Note that the IAB would not have to approve of .oid.urn.arpa.) > > In fact, is there any reason to think that DDDS is not enough? I'd like > to see a discussion of that first. I completely agree. That as well. I see you already start writing a response to the liaison ;-) Go for it! Patrik --Apple-Mail-546--807975566 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMT74SrMabGguI180RAvdaAJ9pD2ExwU3JSHrECG4rvjuWhPmI3gCgj3hs eK/a3d5tg4q5ikAjCDgY3/c= =/vz0 -----END PGP SIGNATURE----- --Apple-Mail-546--807975566-- From patrik@frobbit.se Tue Jul 27 22:25: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 95FD73A69B5 for ; Tue, 27 Jul 2010 22:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN-i1Pi45krS for ; Tue, 27 Jul 2010 22:25:10 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id B731E3A6824 for ; Tue, 27 Jul 2010 22:25:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id CC5FDCD9814F; Wed, 28 Jul 2010 07:25:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pgh7dc7dXpv; Wed, 28 Jul 2010 07:25:28 +0200 (CEST) Received: from dhcp-10-55-80-132.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 83554CD98147; Wed, 28 Jul 2010 07:25:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-547--807666502" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100728045931.GW566@oracle.com> Date: Wed, 28 Jul 2010 07:25:27 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <20100727162642.GD566@oracle.com> <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> <20100728045931.GW566@oracle.com> To: Nicolas Williams X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 28 Jul 2010 05:25:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-547--807666502 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 28 jul 2010, at 06.59, Nicolas Williams wrote: > Well, like I said, I think someone with DDDS experience should look at > this first. It will happen in parallell. (Happens...) You can bravely say you think DDDS is a good choice ;-) Patrik --Apple-Mail-547--807666502 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMT79HrMabGguI180RAkdLAJwLxyXRxj/Vt4jCWCwUrGA6AdtvAgCdEWy4 R70wsmuFA33dU6ia8GmVS8Q= =e7od -----END PGP SIGNATURE----- --Apple-Mail-547--807666502-- From Nicolas.Williams@oracle.com Tue Jul 27 22:33:06 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 1A91E3A69CC for ; Tue, 27 Jul 2010 22:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.346 X-Spam-Level: X-Spam-Status: No, score=-6.346 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPLhNOu5RgdE for ; Tue, 27 Jul 2010 22:33:03 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id B40083A69A4 for ; Tue, 27 Jul 2010 22:33:02 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6S5XOBB008830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jul 2010 05:33:25 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6S2HItD011258; Wed, 28 Jul 2010 05:33:23 GMT Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 463323091280295161; Tue, 27 Jul 2010 22:32:41 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Jul 2010 22:32:41 -0700 Date: Wed, 28 Jul 2010 00:32:35 -0500 From: Nicolas Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20100728053234.GZ566@oracle.com> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <20100727162642.GD566@oracle.com> <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> <20100728045931.GW566@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C4FC123.02AB:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 28 Jul 2010 05:33:06 -0000 On Wed, Jul 28, 2010 at 07:25:27AM +0200, Patrik Fältström wrote: > > On 28 jul 2010, at 06.59, Nicolas Williams wrote: > > > Well, like I said, I think someone with DDDS experience should look at > > this first. > > It will happen in parallell. (Happens...) > > You can bravely say you think DDDS is a good choice ;-) Heh. Well, in that case the correct response might well be: Dear ITU-T, Have you considered using DDDS [RFC 3401, 3402, 3403 and 3404] for OID URN resolution? It seems very likely that DDDS should be usable for OID URN resolution right now, without further ado (other than to define the schemas for documents to be found via DDDS resolution of OID URNs, which you've already done). Separately, have you inquired with the IANA (and any other similar registrars that deal with OIDs) about what other items might be desirable in the RINF schema. Thanks, IETF-ITU-T Liason Yes? If so, whoever would be the liason, please review, edit to your liking, and send the above to the relevant ITU-T working group. Nico -- From Nicolas.Williams@oracle.com Tue Jul 27 22:51:57 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD633A6841 for ; Tue, 27 Jul 2010 22:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGGzHQH33dgP for ; Tue, 27 Jul 2010 22:51:54 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CE7163A69BE for ; Tue, 27 Jul 2010 22:51:52 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6S5qEgW017732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jul 2010 05:52:15 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6S5qCBT011155; Wed, 28 Jul 2010 05:52:12 GMT Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 463353631280296320; Tue, 27 Jul 2010 22:52:00 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Jul 2010 22:52:00 -0700 Date: Wed, 28 Jul 2010 00:51:55 -0500 From: Nicolas Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20100728055155.GC566@oracle.com> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <20100727162642.GD566@oracle.com> <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> <20100728045931.GW566@oracle.com> <20100728053234.GZ566@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100728053234.GZ566@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B020B.4C4FC58D.01FA:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 28 Jul 2010 05:51:57 -0000 On Wed, Jul 28, 2010 at 12:32:35AM -0500, Nicolas Williams wrote: > On Wed, Jul 28, 2010 at 07:25:27AM +0200, Patrik Fältström wrote: > > You can bravely say you think DDDS is a good choice ;-) > > Heh. Well, in that case the correct response might well be: > > Dear ITU-T, > > Have you considered using DDDS [RFC 3401, 3402, 3403 and 3404] for > OID URN resolution? It seems very likely that DDDS should be usable > for OID URN resolution right now, without further ado (other than to > define the schemas for documents to be found via DDDS resolution of > OID URNs, which you've already done). > > Separately, have you inquired with the IANA (and any other similar > registrars that deal with OIDs) about what other items might be > desirable in the RINF schema. > > Thanks, > > > > IETF-ITU-T Liason I think one might want to point out that implementations of DDDS may exist that can handle OID URN resolution _now_, or could, if the necessary RRs existed. Also, if DDDS is applicable, then I think we'd have a very strong architectural argument for requesting that the ITU-T make use of it. Letting the ITU-T know right away that DDDS exists will save time -- the ITU-T SG 17 and IETF participants can then review, in parallel, the applicability of DDDS to OID URN resolution. Besides the sooner the ITU-T finds out that they've [potentially] made a mistak, the better. Nico -- From msk@cloudmark.com Tue Jul 27 22:57: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 993FB3A69C0 for ; Tue, 27 Jul 2010 22:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599, J_CHICKENPOX_15=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 qYwDIDdFQWgW for ; Tue, 27 Jul 2010 22:56:59 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 8C32C3A69BD for ; Tue, 27 Jul 2010 22:56:59 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Tue, 27 Jul 2010 22:57:22 -0700 From: "Murray S. Kucherawy" To: t.petch , Graham Klyne Date: Tue, 27 Jul 2010 22:57:20 -0700 Thread-Topic: [apps-discuss] Name based sockets - Making individual submissionsknow Thread-Index: Acstrx5i57tyDQ4wT/Sr3Ok5t7izLQAad7mw Message-ID: References: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> <4C4F08D6.8020802@ninebynine.org> <002901cb2da6$1ad85f80$4001a8c0@gateway.2wire.net> In-Reply-To: <002901cb2da6$1ad85f80$4001a8c0@gateway.2wire.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: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 28 Jul 2010 05:57:00 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of t.petch > Sent: Tuesday, July 27, 2010 9:09 AM > To: Graham Klyne > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Name based sockets - Making individual submis= sionsknow >=20 > "Applications are thus relieved of re-implementing features such as > multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and > address management in general." >=20 > Murray queried why that was there; well, that was what I saw as the > purpose of > name based sockets in the first instance. My point is that I can't imagine how a client application wanting to reach = some other service needs to be aware that it's on a mobile device or behind= a NAT, for example, and behave differently. I get the utility of being able to say "I want to connect to X on port Y" a= nd not having to deal with all the DNS work that might be involved, but the= stated premise for the work isn't a pain point I've ever heard of. From john-ietf@jck.com Tue Jul 27 23:45:13 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 5A3813A67E6; Tue, 27 Jul 2010 23:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ihBQhuNpFIB; Tue, 27 Jul 2010 23:45:12 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 6C1B23A67F9; Tue, 27 Jul 2010 23:45:12 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Oe0OS-0009of-0w; Wed, 28 Jul 2010 02:45:32 -0400 Date: Wed, 28 Jul 2010 02:45:30 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Nicolas Williams Message-ID: In-Reply-To: <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> References: <828A6079-FEC7-4173-A611-BFCB20BAAC2F@frobbit.se> <20100727162642.GD566@oracle.com> <2C540EA8-D9BF-4301-A3B1-4A08144EC524@frobbit.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Apps Discuss , IAB IAB Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding OIDs -- volunteer needed! 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, 28 Jul 2010 06:45:13 -0000 --On Wednesday, 28 July, 2010 06:37 +0200 Patrik = F=C3=A4ltstr=C3=B6m wrote: > On 27 jul 2010, at 18.26, Nicolas Williams wrote: >=20 >> On Tue, Jul 27, 2010 at 08:50:23PM +1000, SJ Kissane wrote: >>> Looking at section 6 of the document, they define an >>> .oid-res.org domain. Not that it really matters, but >>> wouldn't that be better as .oid-res.arpa? >>=20 >> Does it really matter? >=20 > Yes it does. .ARPA is explicitly under control of IAB. Yes. Also remember that the last time something like this came up, we wasted a few years of everyone's time in a debate about demands for a TLD linked to the particular function and under ITU control. Part (but only part) of the reason was that .ARPA was under IAB control. So, while .ARPA is the right answer, we should remember that willingness to do it in .ORG is progress. john From patrik@frobbit.se Tue Jul 27 23:51:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF0E3A67E6 for ; Tue, 27 Jul 2010 23:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg327mqf8yZ7 for ; Tue, 27 Jul 2010 23:51:30 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id E7BCE3A68B5 for ; Tue, 27 Jul 2010 23:51:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 71946CD9BCC7 for ; Wed, 28 Jul 2010 08:51:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKa-zvxcrhM4 for ; Wed, 28 Jul 2010 08:51:50 +0200 (CEST) Received: from [IPv6:2001:df8::96:226:bbff:fe15:8d13] (unknown [IPv6:2001:df8::96:226:bbff:fe15:8d13]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id E15D6CD9BCB7 for ; Wed, 28 Jul 2010 08:51:49 +0200 (CEST) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-549--802485111" Mime-Version: 1.0 (Apple Message framework v1081) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 28 Jul 2010 08:51:49 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Apps Discuss X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Subject: [apps-discuss] Notes from BOF: How to find a service? 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, 28 Jul 2010 06:51:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-549--802485111 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Problems with unknown resource record types. Service discovery is one piece. Service provisioning is what the apps people want. ACAP did not work. 1. Do not end up with an arbitrary number of these objects -- makes = things more complicated 2. You want to retrieve a single blob from somewhere and then use it, = instead of retrieving large number of records from DNS repeatedly 3. We do not want a lot of repeated lookups for similar things in the = same zone 4. We do not want to be forced to pull to see if there have been changes There are a number of requirements that we should understand... --- Stewart from Apple give short explanation of what Apple is doing: 2 Layers Service discovery, regardless of transport Uses DNS records, either in a dns server, or multicast dns in a p2p = fashion Uses PTR records using the SRV prefix syntax, to get the SRV record SRV + TXT record in the next step (same owner for the two) Asynchronous queries ("tell me if the answer changes") - subscriptions --- Desire of creation of a "marketplace" of similar services, and the user = then chooses/selects which one of the services to use. First and later = "lookups" could create different responses (later responses could = "remember" what selection was done the first time). What is "service"? One example: Humans think "ink on paper" is a service, but computers = think "printers using a specific protocol (and paper size etc)" is a = service? Are we now ("where is my fragments of data?") now talking about resource = discovery instead of service discovery? We have some data inbound in the protocol, and some data outbound. = Depends a lot on what protocol you have on what you can do inbound and = what you have to do outbound. We do not want overlap between you do in the discovery part of the = resolution and what you can negotiate inbound. Bootstrap might be hard (specifically for DNS dynamic updates) due to = lack of tools/applications for new users (i.e. key management). Slightly different topic, how do one know whether a service works? How = do we know whether something is running? UDP and TCP combinations, where = UDP is only used for "I am alive" systems. Not very optimal. "Who do I talk with?" "What port do I use?" Discussion about distribution of the bonjour code, which Apple said was = under Apache license from Apple, and GPL from others. Lightweight protocol needed to find services, so we do not use unique = port numbers for each service (we must decrease the consumption of = ports). What we need is: Code to implement the whole thing Application registering in some shared port/service Protocol to query whether service is there HTTP based services are doing lookups etc over http, because possibility = to use DNS in new ways is indeed hard (and other new non-existing lookup = protocols). Having the local printer is one thing, but the hard thing might be to = know what to query for. Can I get the Alto server in a specific = environment? Patrik On 22 jul 2010, at 10.20, Patrik F=E4ltstr=F6m wrote: > We have had various discussions during the years on "how to find a = service". And we have many ways of doing it at the moment. For example: >=20 > - Just use a well known algorithm > - Look up A or AAAA record, and then use well known port number > - Look up MX, and then A/AAAA and use well known port number > - Look up SRV record, and use that hostname and port number > - Use a DDDS algorithm as defined somewhere > - Use mdns like services to "broadcast" information (or respond to = broadcast queries) > - : > - : >=20 > ...and many more... >=20 > Now we have other ways as well, like the two currently proposed = mechanisms that some people have seen discussed on the IETF list: >=20 > - What is described in draft-daboo-srv-caldav, which I in a sloppy way = describe as "use SRV records and then a well known path that should = result in an HTTP redirect" >=20 > - What is described in draft-faltstrom-uri, which I in a sloppy way = describe as "use URI records like we use SRV records, but get a full URI = back" >=20 >=20 > As we are so close to Maastricht, I do not find we have time for a = doodle regarding interested parties that want to talk about this. >=20 > I have therefore decided we meet on Wednesday July 28 at 08:00 (yes, = for a breakfast meeting). It will be by the IETF = registration/announcement board, OR, where a note on that very same = announcement board says. I guess it will be near or even where breakfast = is served... >=20 > I am deliberately sending this only to Apps Discuss as I think we = should start this discussion from the point of view of "the need = applications has". That said, please spread the word to other interested = parties. It is not supposed to be a "secret cabal meeting". >=20 > I envision a mailing list discussion after this first meeting. >=20 > Patrik >=20 --Apple-Mail-549--802485111 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMT9OFrMabGguI180RAhTPAJ9PhOadl5m/z2h6E3yrjKJ5XYMnpACfSnwc mQbRUhPVcD6N7GlTPRCtXO0= =2umO -----END PGP SIGNATURE----- --Apple-Mail-549--802485111-- From Nicolas.Williams@oracle.com Wed Jul 28 00:15: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 47C073A68D6 for ; Wed, 28 Jul 2010 00:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E04Uy4JGb5BY for ; Wed, 28 Jul 2010 00:15:26 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 19F853A63C9 for ; Wed, 28 Jul 2010 00:15:26 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6S7FlWG024685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jul 2010 07:15:48 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6S7FiCO023752; Wed, 28 Jul 2010 07:15:45 GMT Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 463524191280301315; Wed, 28 Jul 2010 00:15:15 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Jul 2010 00:15:15 -0700 Date: Wed, 28 Jul 2010 02:15:10 -0500 From: Nicolas Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20100728071509.GF566@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C4FD922.0236:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss Subject: Re: [apps-discuss] Notes from BOF: How to find a service? 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, 28 Jul 2010 07:15:34 -0000 On Wed, Jul 28, 2010 at 08:51:49AM +0200, Patrik Fältström wrote: > Lightweight protocol needed to find services, so we do not use unique > port numbers for each service (we must decrease the consumption of > ports). Nice thought. Guess what? NFS doesn't work across overzealous packet firewalls because of the use of dynamic ports. :( (Linux has options to run all the relevant services on registered port numbers; port squatting ensues.) And yet there is a well-known service registration/discovery protocol for ONC RPC (on which NFS is built), and there have been firewalls that know how to use it. But as we see, that's not good enough because firewalls get built that without regard to dynamic port registration. Some of us are looking at making NFS more firewall-friendly by using a combination of registered ports and indirect RPC calls (i.e., via the portmapper). Indirect RPC calls are not always appropriate, though they are an interesting pattern to consider (though one runs the risk of inviting firewalls to filter indirection services, and/or do deep inspection). (Some Apple engineers might remember NetInfo, an ONC RPC-based protocol that made extensive use of indirect RPC calls.) Indirection is nothing new... Remember TCP port 1, tcpmux? The problem is meddling middle boxes. The solution is...? In short, good luck, Nico PS: While researching the NFS problem mentioned above I discovered at least one port number conflict with an IANA registration that might well be obsolete. I can't find a procedure for obsoleting port number registrations, something one might think would be desirable. From Nicolas.Williams@oracle.com Wed Jul 28 00:18:25 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 6C95F28C0EE for ; Wed, 28 Jul 2010 00:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koFtB1VUpkA9 for ; Wed, 28 Jul 2010 00:18:24 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C15593A699C for ; Wed, 28 Jul 2010 00:18:13 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6S7IYnR032158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jul 2010 07:18:36 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6RKaoMQ003440; Wed, 28 Jul 2010 07:18:33 GMT Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 443306721280301496; Wed, 28 Jul 2010 00:18:16 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Jul 2010 00:18:16 -0700 Date: Wed, 28 Jul 2010 02:18:11 -0500 From: Nicolas Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20100728071811.GG566@oracle.com> References: <20100728071509.GF566@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100728071509.GF566@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C4FD9CA.0021:SCFMA4539814,ss=1,fgs=0 Cc: Apps Discuss Subject: Re: [apps-discuss] Notes from BOF: How to find a service? 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, 28 Jul 2010 07:18:25 -0000 On Wed, Jul 28, 2010 at 02:15:10AM -0500, Nicolas Williams wrote: > The problem is meddling middle boxes. The solution is...? ...always to tunnel everything through HTTP, or port 80. From jav@sics.se Wed Jul 28 01:05: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 B5C993A69E7 for ; Wed, 28 Jul 2010 01:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=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 aDP-5lzn8OA5 for ; Wed, 28 Jul 2010 01:05:08 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id E3B333A69DD for ; Wed, 28 Jul 2010 01:05:05 -0700 (PDT) Received: from [130.129.113.249] (dhcp-71f9.meeting.ietf.org [130.129.113.249]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 9195840005; Wed, 28 Jul 2010 10:05:27 +0200 (CEST) From: Javier Ubillos To: "Murray S. Kucherawy" In-Reply-To: References: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> <4C4F08D6.8020802@ninebynine.org> <002901cb2da6$1ad85f80$4001a8c0@gateway.2wire.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-8ap9mlpFuvrI0o6PFf0i" Date: Wed, 28 Jul 2010 10:05:26 +0200 Message-ID: <1280304326.2059.46.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 28 Jul 2010 08:05:11 -0000 --=-8ap9mlpFuvrI0o6PFf0i Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2010-07-27 at 22:57 -0700, Murray S. Kucherawy wrote: > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.o= rg] On Behalf Of t.petch > > Sent: Tuesday, July 27, 2010 9:09 AM > > To: Graham Klyne > > Cc: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Name based sockets - Making individual subm= issionsknow > >=20 > > "Applications are thus relieved of re-implementing features such as > > multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and > > address management in general." > >=20 > > Murray queried why that was there; well, that was what I saw as the > > purpose of > > name based sockets in the first instance. >=20 > My point is that I can't imagine how a client application wanting to reac= h some other service needs to be aware that it's on a mobile device or behi= nd a NAT, for example, and behave differently. >=20 > I get the utility of being able to say "I want to connect to X on port Y"= and not having to deal with all the DNS work that might be involved, but t= he stated premise for the work isn't a pain point I've ever heard of. I'm not sure I'm understanding where this is going. Do I get the point correctly if we are all agreeing that: Applications should not need to care about network issues, that should be solved "underneath".=20 Mobility, NAT, IPv4&6 and all other ugly network things should be dealt with by this other "underneath" thing. Or is some one trying to make a different point that I am completely missing? The purpose of name based sockets _is_ to solve all these things, but also to give the application a receipt that those things _are_ dealt with, as opposed to shimming-layers, where you get the features "for free" but the application is just never aware of whether or not th cool stuff is there or not. // Javier=20 --=-8ap9mlpFuvrI0o6PFf0i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxP5MMACgkQGBo5FLRz4gpdzgCfR+j0oe79Wvus8eWVUG7afe8E 9fUAoJQashtq31Zki6c4dKbxBTgD4Gom =+Tol -----END PGP SIGNATURE----- --=-8ap9mlpFuvrI0o6PFf0i-- From msk@cloudmark.com Wed Jul 28 02:13:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB233A69F7 for ; Wed, 28 Jul 2010 02:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=-0.467, 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 SW8BV1SKiyLw for ; Wed, 28 Jul 2010 02:13:13 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 5A7983A687D for ; Wed, 28 Jul 2010 02:13:13 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 28 Jul 2010 02:13:35 -0700 From: "Murray S. Kucherawy" To: Javier Ubillos Date: Wed, 28 Jul 2010 02:13:33 -0700 Thread-Topic: [apps-discuss] Name based sockets - Making individual submissionsknow Thread-Index: AcsuK6VgLVOn5vj5RcGCpj8GhNrU/AAB6lNg Message-ID: References: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> <4C4F08D6.8020802@ninebynine.org> <002901cb2da6$1ad85f80$4001a8c0@gateway.2wire.net> <1280304326.2059.46.camel@bit> In-Reply-To: <1280304326.2059.46.camel@bit> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 28 Jul 2010 09:13:15 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYXZpZXIgVWJpbGxvcyBbbWFp bHRvOmphdkBzaWNzLnNlXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjgsIDIwMTAgMTowNSBB TQ0KPiBUbzogTXVycmF5IFMuIEt1Y2hlcmF3eQ0KPiBDYzogamF2QHNpY3Muc2U7IHQucGV0Y2g7 IEdyYWhhbSBLbHluZTsgYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbYXBw cy1kaXNjdXNzXSBOYW1lIGJhc2VkIHNvY2tldHMgLSBNYWtpbmcgaW5kaXZpZHVhbA0KPiBzdWJt aXNzaW9uc2tub3cNCj4gDQo+IEknbSBub3Qgc3VyZSBJJ20gdW5kZXJzdGFuZGluZyB3aGVyZSB0 aGlzIGlzIGdvaW5nLg0KPiBEbyBJIGdldCB0aGUgcG9pbnQgY29ycmVjdGx5IGlmIHdlIGFyZSBh bGwgYWdyZWVpbmcgdGhhdDoNCj4gQXBwbGljYXRpb25zIHNob3VsZCBub3QgbmVlZCB0byBjYXJl IGFib3V0IG5ldHdvcmsgaXNzdWVzLCB0aGF0IHNob3VsZA0KPiBiZSBzb2x2ZWQgInVuZGVybmVh dGgiLg0KPiBNb2JpbGl0eSwgTkFULCBJUHY0JjYgYW5kIGFsbCBvdGhlciB1Z2x5IG5ldHdvcmsg dGhpbmdzIHNob3VsZCBiZSBkZWFsdA0KPiB3aXRoIGJ5IHRoaXMgb3RoZXIgInVuZGVybmVhdGgi IHRoaW5nLg0KDQpJIGJlbGlldmUgbW9zdCB0aGluZ3MgaW4gYXBwbGljYXRpb24gc3BhY2UgYWxy ZWFkeSBjb25zaWRlciBldmVyeXRoaW5nIHlvdSBsaXN0ZWQgYXMgInVuZGVybmVhdGgiLCBleGNl cHQgcGVyaGFwcyBmb3Iga25vd2luZyB3aGF0IHByb3RvY29sIGZhbWlseSB0aGV5J3JlIHRyeWlu ZyB0byB1c2UuICBFdmVyeXRoaW5nIGVsc2UgeW91J3ZlIGxpc3RlZCBhbHJlYWR5IGxpdmVzIGlu IG90aGVyIGxheWVycywgbW9zdGx5IHRyYW5zcG9ydC4NCg0KVGhlIGlkZWEgb2YgbW92aW5nIERO UyByZXNvbHV0aW9uIG91dCBvZiB0aGUgc29ja2V0IEFQSSBpcyBwb3NzaWJseSBhbiBhcHBsaWNh dGlvbiBhcmVhIGNvbnNpZGVyYXRpb24sIGJ1dCBpdCBkb2Vzbid0IGhhdmUgYW55dGhpbmcgdG8g ZG8gd2l0aCB0aGUgdGhpbmdzIHlvdSBsaXN0ZWQgYWJvdmUsIGFuZCBjb3VsZCBwcm9iYWJseSBz b2x2ZWQgd2l0aCBhbiBBUEkgbGF5ZXIgKGEgaGVscGVyIGxpYnJhcnkpIHJhdGhlciB0aGFuIGEg d2hvbGUgbmV3IHNvY2tldCBhYnN0cmFjdGlvbi4NCg0KU28gbXkgcG9pbnQgaXMgdGhhdCB0aGUg dGhpbmdzIHlvdSdyZSBzYXlpbmcgdGhpcyBzb2x2ZXMgYXJlIGFjdHVhbGx5IGFscmVhZHkgc29s dmVkIGJ5IHRoZSBleGlzdGluZyBhYnN0cmFjdGlvbiBvZiB0aGUgc29ja2V0IGxheWVyLiAgSSB0 aGluayB5b3VyIHByb2JsZW0gc3RhdGVtZW50IGRvZXNuJ3QgbWF0Y2ggd2hhdCB5b3UncmUgYWN0 dWFsbHkgZG9pbmcuDQoNClNlY3Rpb24gNSBvZiB5b3VyIGRvY3VtZW50IHNob3dzIGFuIGV4YW1w bGUgdXNlLiAgRXNzZW50aWFsbHkgd2hhdCBpdCBkb2VzLCB0aG91Z2gsIGlzIG9idmlhdGUgdGhl IG5lZWQgdG8gY2FsbCBnZXRob3N0YnluYW1lKCkgb3Igc2ltaWxhci4gIFRoZXJlJ3Mgbm90aGlu ZyBpbiB0aGVyZSBhYm91dCB0aGUgInVuZGVybmVhdGgiIHRyYW5zcG9ydCBzdHVmZi4gIENvbXBh cmluZyB0aGF0IHRvIGEgY3VycmVudCBpbXBsZW1lbnRhdGlvbiwgeW91IGNhbid0IHNlZSBhbnkg b2J2aW91cyBldmlkZW5jZSwgb3RoZXIgdGhhbiB0aGUgcHJvdG9jb2wgZmFtaWx5LCB0aGF0IHRo ZSBhcHBsaWNhdGlvbiBrbm93cyBhbnl0aGluZyBhYm91dCB0aGUgInVuZGVybmVhdGgiIHN0dWZm IGluIHRoZSBmaXJzdCBwbGFjZS4gIFRoZXJlZm9yZSwgSSBkb24ndCB0aGluayB5b3UncmUgYWN0 dWFsbHkgYWRkcmVzc2luZyBhIHByb2JsZW0gdGhhdCBJIGNhbiBzZWUgaW4gdGhpcyBjb250ZXh0 Lg0KDQpUaGUgZG9jdW1lbnQgZWl0aGVyIG5lZWRzIGEgbW9yZSBjb21wZWxsaW5nIHN0YXRlbWVu dCBvZiB0aGUgcHJvYmxlbSBpdCdzIHNvbHZpbmcsIG9yIHNvbWUgZXhhbXBsZXMgb2YgY29kZSAo b3IgcGVyaGFwcyBqdXN0IHBzZXVkby1jb2RlKSB0aGF0IHNob3dzIHRoZSBjb21wbGljYXRpb24g dGhhdCB3b3VsZCBiZSBhbGxldmlhdGVkLg0KDQpJJ20gYWxzbyB2YWd1ZWx5IHdvbmRlcmluZyBp ZiB0aGlzIChBUEkgZGVmaW5pdGlvbikgaXMgdGhlIGtpbmQgb2YgdGhpbmcgdGhlIElFVEYgc2hv dWxkIGRvIGluIGdlbmVyYWwsIGJ1dCBJIHN1c3BlY3QgSSdtIHVwIGFnYWluc3QgYW4gb3Bwb3Np dGUgcHJlY2VkZW50IG9uIHRoYXQgaXNzdWUuDQoNCg== From jav@sics.se Wed Jul 28 08:29:54 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CA33A68C5 for ; Wed, 28 Jul 2010 08:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81SBAGUZ0rTC for ; Wed, 28 Jul 2010 08:29:53 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 2E1303A687C for ; Wed, 28 Jul 2010 08:29:53 -0700 (PDT) Received: from [212.238.50.120] (ip212-238-50-120.hotspotsvankpn.com [212.238.50.120]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 3A919400CE; Wed, 28 Jul 2010 17:30:15 +0200 (CEST) From: Javier Ubillos To: "Murray S. Kucherawy" In-Reply-To: References: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> <4C4F08D6.8020802@ninebynine.org> <002901cb2da6$1ad85f80$4001a8c0@gateway.2wire.net> <1280304326.2059.46.camel@bit> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UCVxwvLFz1GxiPYwl9gq" Date: Wed, 28 Jul 2010 17:30:14 +0200 Message-ID: <1280331014.2059.97.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 28 Jul 2010 15:29:55 -0000 --=-UCVxwvLFz1GxiPYwl9gq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, please see responses in-line. On Wed, 2010-07-28 at 02:13 -0700, Murray S. Kucherawy wrote: > > -----Original Message----- > > From: Javier Ubillos [mailto:jav@sics.se] > > Sent: Wednesday, July 28, 2010 1:05 AM > > To: Murray S. Kucherawy > > Cc: jav@sics.se; t.petch; Graham Klyne; apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Name based sockets - Making individual > > submissionsknow > >=20 > > I'm not sure I'm understanding where this is going. > > Do I get the point correctly if we are all agreeing that: > > Applications should not need to care about network issues, that should > > be solved "underneath". > > Mobility, NAT, IPv4&6 and all other ugly network things should be dealt > > with by this other "underneath" thing. >=20 > I believe most things in application space already consider everything yo= u listed as "underneath", except perhaps for knowing what protocol family t= hey're trying to use. Everything else you've listed already lives in other= layers, mostly transport. >=20 > The idea of moving DNS resolution out of the socket API is possibly an ap= plication area consideration, but it doesn't have anything to do with the t= hings you listed above, and could probably solved with an API layer (a help= er library) rather than a whole new socket abstraction. I think I agree with you. The socket() interface is not the only interface apps work with. In fact, most applications "out there" already use higher socket abstractions. Abstractions that do DNS resolution, and usualy provide a few more features particular to which ever application/protocol it tries to cater to. I too think that an helper library is the way to go deployment wize, whenever the stuff is mature enough, it will "sink in" to the OS and become a natural part of it. Consider the socket() API we show an implementation example. I presume that most other languages/frameworks at some point use a socket() call. So attacking the problem with a first implementation at that level seems appropriate to me, more reusable code. > So my point is that the things you're saying this solves are actually alr= eady solved by the existing abstraction of the socket layer. I think your = problem statement doesn't match what you're actually doing. I partly disagree. Yes, there are socket abstractions out there, but I have not met one yet that is bilateral in some sense. The ones I have come across have been very specialized. > The document either needs a more compelling statement of the problem it's= solving, or some examples of code (or perhaps just pseudo-code) that shows= the complication that would be alleviated. I think you are right, I'll try to address these things in upcoming drafts.=20 --=-UCVxwvLFz1GxiPYwl9gq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxQTQMACgkQGBo5FLRz4grhvACfRrnU+LhBNi6qDLQ9LkNEEWn6 aA8AnjM5mMv72VMr1rPTKP83RTFlIRF5 =axYL -----END PGP SIGNATURE----- --=-UCVxwvLFz1GxiPYwl9gq-- From erik.nordmark@oracle.com Thu Jul 29 01:58:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39213A6893 for ; Thu, 29 Jul 2010 01:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjVoaeAH0JhY for ; Thu, 29 Jul 2010 01:58:18 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BB7E13A6891 for ; Thu, 29 Jul 2010 01:58:18 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6T8we1Q018786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 08:58:41 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6T6gtvZ025412; Thu, 29 Jul 2010 08:58:39 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 467096001280393835; Thu, 29 Jul 2010 01:57:15 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 01:57:15 -0700 Message-ID: <4C514268.4080201@oracle.com> Date: Thu, 29 Jul 2010 01:57:12 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Javier Ubillos References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> In-Reply-To: <1280142280.9738.34.camel@bit> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C5142C0.0014:SCFMA4539814,ss=1,fgs=0 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 29 Jul 2010 08:58:19 -0000 On 07/26/10 04:04 AM, Javier Ubillos wrote: >> I suspect that if this could be made to handle non-blocking, >> single-attempt, SRV lookup, host lookup, and connection, then it >> would be very interesting to application developers. If it handled >> connection timeouts and retries transparently, all the more so. > > I want to say "yes", but I'm gong to have to read up on it more in > detail. But I can't see why this would be a problem. > SRV in conjunction (or replacing) the service field would be a cool > thing. > When you talk about timeouts and retries, are you referring to some > particular protocol(s) or in general? FWIW Stuart Cheshire made the point in an IETF plenary around IPv4 and IPv6 that there are benefits in doing things in parallel (both the DNS lookup of A/AAAA records and the connect on IPv4/IPv6). See http://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf If we are going to provide a new API for applications (whether it is initially just a library or a new socket protocol family) I think it makes sense allowing the implementation do to things in parallel. Perhaps the application should be able to choose between serial and parallel. Erik From marc.blanchet@viagenie.ca Thu Jul 29 03:01:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64BAC3A67A5 for ; Thu, 29 Jul 2010 03:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEfNo9sQ-vje for ; Thu, 29 Jul 2010 03:01:00 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0D7283A63C9 for ; Thu, 29 Jul 2010 03:01:00 -0700 (PDT) Received: from mbl.local (unknown [IPv6:2001:df8:0:7:5ab0:35ff:fe6a:294a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2566221B94 for ; Thu, 29 Jul 2010 06:01:23 -0400 (EDT) Message-ID: <4C515172.2040606@viagenie.ca> Date: Thu, 29 Jul 2010 12:01:22 +0200 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> <4C514268.4080201@oracle.com> In-Reply-To: <4C514268.4080201@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 29 Jul 2010 10:01:01 -0000 agree with Erik. with the additional comment: default is parallel, serial has to be specified if wanting to do serial. Marc. Le 10-07-29 10:57, Erik Nordmark a écrit : > On 07/26/10 04:04 AM, Javier Ubillos wrote: > >>> I suspect that if this could be made to handle non-blocking, >>> single-attempt, SRV lookup, host lookup, and connection, then it >>> would be very interesting to application developers. If it handled >>> connection timeouts and retries transparently, all the more so. >> >> I want to say "yes", but I'm gong to have to read up on it more in >> detail. But I can't see why this would be a problem. >> SRV in conjunction (or replacing) the service field would be a cool >> thing. >> When you talk about timeouts and retries, are you referring to some >> particular protocol(s) or in general? > > FWIW Stuart Cheshire made the point in an IETF plenary around IPv4 and > IPv6 that there are benefits in doing things in parallel (both the DNS > lookup of A/AAAA records and the connect on IPv4/IPv6). See > http://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf > > If we are going to provide a new API for applications (whether it is > initially just a library or a new socket protocol family) I think it > makes sense allowing the implementation do to things in parallel. > Perhaps the application should be able to choose between serial and > parallel. > > Erik > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From jav@sics.se Thu Jul 29 05:16: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 4A04728C0FF for ; Thu, 29 Jul 2010 05:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, 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 LpqjN3xVwGeX for ; Thu, 29 Jul 2010 05:16:11 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 66E333A6836 for ; Thu, 29 Jul 2010 05:16:07 -0700 (PDT) Received: from [130.129.113.249] (dhcp-71f9.meeting.ietf.org [130.129.113.249]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 4B202400DA; Thu, 29 Jul 2010 14:16:30 +0200 (CEST) From: Javier Ubillos To: Marc Blanchet In-Reply-To: <4C515172.2040606@viagenie.ca> References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> <4C514268.4080201@oracle.com> <4C515172.2040606@viagenie.ca> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-stIcfqv6+OrbaWsUC00O" Date: Thu, 29 Jul 2010 14:16:29 +0200 Message-ID: <1280405789.2059.105.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 29 Jul 2010 12:16:12 -0000 --=-stIcfqv6+OrbaWsUC00O Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just out of curiosity, can some one come up with a reason _not_ to do a parallel lookup? I can imagine a few debugging scenarios, but even those are a bit forced. // Javier=20 On Thu, 2010-07-29 at 12:01 +0200, Marc Blanchet wrote: > agree with Erik. with the additional comment: default is parallel,=20 > serial has to be specified if wanting to do serial. >=20 > Marc. >=20 > Le 10-07-29 10:57, Erik Nordmark a =C3=A9crit : > > On 07/26/10 04:04 AM, Javier Ubillos wrote: > > > >>> I suspect that if this could be made to handle non-blocking, > >>> single-attempt, SRV lookup, host lookup, and connection, then it > >>> would be very interesting to application developers. If it handled > >>> connection timeouts and retries transparently, all the more so. > >> > >> I want to say "yes", but I'm gong to have to read up on it more in > >> detail. But I can't see why this would be a problem. > >> SRV in conjunction (or replacing) the service field would be a cool > >> thing. > >> When you talk about timeouts and retries, are you referring to some > >> particular protocol(s) or in general? > > > > FWIW Stuart Cheshire made the point in an IETF plenary around IPv4 and > > IPv6 that there are benefits in doing things in parallel (both the DNS > > lookup of A/AAAA records and the connect on IPv4/IPv6). See > > http://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf > > > > If we are going to provide a new API for applications (whether it is > > initially just a library or a new socket protocol family) I think it > > makes sense allowing the implementation do to things in parallel. > > Perhaps the application should be able to choose between serial and > > parallel. > > > > Erik > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 --=-stIcfqv6+OrbaWsUC00O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxRcRwACgkQGBo5FLRz4gq7jACfVcQRA+8wE92+n616oiSfMl2w UvkAoLeEc/ByK+tY11CMzvPdxqrKYsk3 =CSNB -----END PGP SIGNATURE----- --=-stIcfqv6+OrbaWsUC00O-- From erik.nordmark@oracle.com Thu Jul 29 05:38: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 C886528C0FF for ; Thu, 29 Jul 2010 05:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.319 X-Spam-Level: X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yllHuCDKHAxQ for ; Thu, 29 Jul 2010 05:38:55 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7BB0D3A69F7 for ; Thu, 29 Jul 2010 05:38:55 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6TCcr80031597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 12:38:55 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6TC0u8W030751; Thu, 29 Jul 2010 12:38:51 GMT Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 467640891280407128; Thu, 29 Jul 2010 05:38:48 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 05:38:47 -0700 Message-ID: <4C517654.7090708@oracle.com> Date: Thu, 29 Jul 2010 05:38:44 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Javier Ubillos References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> <4C514268.4080201@oracle.com> <4C515172.2040606@viagenie.ca> <1280405789.2059.105.camel@bit> In-Reply-To: <1280405789.2059.105.camel@bit> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C51765C.0193:SCFMA4539814,ss=1,fgs=0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 29 Jul 2010 12:38:56 -0000 On 07/29/10 05:16 AM, Javier Ubillos wrote: > Just out of curiosity, can some one come up with a reason _not_ to do a > parallel lookup? There is a performance issue when you e.g., do SRV lookup and the result has N results at the highest priority, and then there are M A/AAAA records for each of those, resulting in N*M IPv* addresses that you could try to connect to. If N*M is two then it is probably OK to always do it in parallel, but if it is 100, then I think some sequencing should be applied. Erik > I can imagine a few debugging scenarios, but even those are a bit > forced. > > // Javier > > On Thu, 2010-07-29 at 12:01 +0200, Marc Blanchet wrote: >> agree with Erik. with the additional comment: default is parallel, >> serial has to be specified if wanting to do serial. >> >> Marc. >> >> Le 10-07-29 10:57, Erik Nordmark a écrit : >>> On 07/26/10 04:04 AM, Javier Ubillos wrote: >>> >>>>> I suspect that if this could be made to handle non-blocking, >>>>> single-attempt, SRV lookup, host lookup, and connection, then it >>>>> would be very interesting to application developers. If it handled >>>>> connection timeouts and retries transparently, all the more so. >>>> >>>> I want to say "yes", but I'm gong to have to read up on it more in >>>> detail. But I can't see why this would be a problem. >>>> SRV in conjunction (or replacing) the service field would be a cool >>>> thing. >>>> When you talk about timeouts and retries, are you referring to some >>>> particular protocol(s) or in general? >>> >>> FWIW Stuart Cheshire made the point in an IETF plenary around IPv4 and >>> IPv6 that there are benefits in doing things in parallel (both the DNS >>> lookup of A/AAAA records and the connect on IPv4/IPv6). See >>> http://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf >>> >>> If we are going to provide a new API for applications (whether it is >>> initially just a library or a new socket protocol family) I think it >>> makes sense allowing the implementation do to things in parallel. >>> Perhaps the application should be able to choose between serial and >>> parallel. >>> >>> Erik >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jav@sics.se Thu Jul 29 05:41: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 8572F28C1E8 for ; Thu, 29 Jul 2010 05:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, 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 4E2f3upAGGqP for ; Thu, 29 Jul 2010 05:41:49 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 49C9D3A69F7 for ; Thu, 29 Jul 2010 05:41:45 -0700 (PDT) Received: from [130.129.113.249] (dhcp-71f9.meeting.ietf.org [130.129.113.249]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 30803400DA; Thu, 29 Jul 2010 14:41:50 +0200 (CEST) From: Javier Ubillos To: Erik Nordmark In-Reply-To: <4C517654.7090708@oracle.com> References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> <4C514268.4080201@oracle.com> <4C515172.2040606@viagenie.ca> <1280405789.2059.105.camel@bit> <4C517654.7090708@oracle.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Qf4O57436JIqJtgSqTkQ" Date: Thu, 29 Jul 2010 14:41:49 +0200 Message-ID: <1280407309.2059.107.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 29 Jul 2010 12:41:53 -0000 --=-Qf4O57436JIqJtgSqTkQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2010-07-29 at 05:38 -0700, Erik Nordmark wrote: > If N*M is two then it is probably OK to always do it in parallel, but > if=20 > it is 100, then I think some sequencing should be applied. >=20 >=20 Ok, that makes sense. Thanks. So perhaps a maximum of concurrent connections... Either way, thanks, I see the point. // Javier --=-Qf4O57436JIqJtgSqTkQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxRdwsACgkQGBo5FLRz4gq/owCfdbUWRXRa/lzJfZZwb0fhmkuZ SuYAoLPHmWbNTXnypJvYBUUs6bSAfmA0 =x3Y+ -----END PGP SIGNATURE----- --=-Qf4O57436JIqJtgSqTkQ-- From dwing@cisco.com Thu Jul 29 05:46:32 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 73BCA28C15A for ; Thu, 29 Jul 2010 05:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, 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 Kbg3nvMa+mfB for ; Thu, 29 Jul 2010 05:46:31 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9712028C12B for ; Thu, 29 Jul 2010 05:46:31 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2010 12:46:55 +0000 Received: from dwingWS ([10.21.79.43]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6TCksna012321; Thu, 29 Jul 2010 12:46:54 GMT From: "Dan Wing" To: "'Erik Nordmark'" , "'Javier Ubillos'" References: <4C4D40E9.4030409@isode.com> <1280136631.9738.9.camel@bit> <2378.1280141100.936023@puncture> <1280142280.9738.34.camel@bit> <4C514268.4080201@oracle.com> In-Reply-To: <4C514268.4080201@oracle.com> Date: Thu, 29 Jul 2010 14:46:53 +0200 Message-ID: <126201cb2f1c$20194d70$604be850$@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: Acsu/ES8tq7eJ2p7RhmqV3JQxa4rjgAH3Bcw Content-Language: en-us Cc: 'General discussion of application-layer protocols' Subject: Re: [apps-discuss] Name based sockets - Making individual submissions know 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, 29 Jul 2010 12:46:32 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Erik Nordmark > Sent: Thursday, July 29, 2010 10:57 AM > To: Javier Ubillos > Cc: General discussion of application-layer protocols > Subject: Re: [apps-discuss] Name based sockets - Making individual > submissions know > > On 07/26/10 04:04 AM, Javier Ubillos wrote: > > >> I suspect that if this could be made to handle non-blocking, > >> single-attempt, SRV lookup, host lookup, and connection, then it > >> would be very interesting to application developers. If it handled > >> connection timeouts and retries transparently, all the more so. > > > > I want to say "yes", but I'm gong to have to read up on it more in > > detail. But I can't see why this would be a problem. > > SRV in conjunction (or replacing) the service field would be a cool > > thing. > > When you talk about timeouts and retries, are you referring to some > > particular protocol(s) or in general? > > FWIW Stuart Cheshire made the point in an IETF plenary around IPv4 and > IPv6 that there are benefits in doing things in parallel (both the DNS > lookup of A/AAAA records and the connect on IPv4/IPv6). See > http://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf Andrew and I wrote it up as "Happy Eyeballs" for IPv4, IPv6, SCTP, and TCP. We added a suggestion to 'trend' towards IPv4/IPv6/TCP/SCTP based on the previous success of using the address family or transport. The idea is that if IPv6 has not been successful (due to firewall configuration, broken tunnel endpoint, or whatever), it makes no sense to continue annoying the user with connection attempts that will only timeout and fall back to IPv4 (or fall back to TCP). http://tools.ietf.org/html/draft-wing-http-new-tech-00 -d > If we are going to provide a new API for applications (whether it is > initially just a library or a new socket protocol family) I think it > makes sense allowing the implementation do to things in parallel. > Perhaps the application should be able to choose between serial and > parallel. > > Erik > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ietfc@btconnect.com Fri Jul 30 04:15: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 BBB8F3A685E for ; Fri, 30 Jul 2010 04:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.781 X-Spam-Level: X-Spam-Status: No, score=0.781 tagged_above=-999 required=5 tests=[AWL=0.780, 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 30SvhcJfq4ER for ; Fri, 30 Jul 2010 04:15:48 -0700 (PDT) Received: from c2bthomr06.btconnect.com (c2bthomr06.btconnect.com [213.123.20.124]) by core3.amsl.com (Postfix) with ESMTP id 7230E3A6899 for ; Fri, 30 Jul 2010 04:15:47 -0700 (PDT) Received: from pc6 (host81-156-71-186.range81-156.btcentralplus.com [81.156.71.186]) by c2bthomr06.btconnect.com with SMTP id FWY86549; Fri, 30 Jul 2010 12:15:24 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=0001.0A0B0302.4C52B44B.02E9, actions=tag Message-ID: <013401cb2fcf$9818f7e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Murray S. Kucherawy" , "Javier Ubillos" References: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> <4C4F08D6.8020802@ninebynine.org> <002901cb2da6$1ad85f80$4001a8c0@gateway.2wire.net> <1280304326.2059.46.camel@bit> Date: Fri, 30 Jul 2010 12:09:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2bthomr06.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0207.4C52B476.0183,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 30 Jul 2010 11:15:53 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" To: "Javier Ubillos" Sent: Wednesday, July 28, 2010 11:13 AM > > -----Original Message----- > > From: Javier Ubillos [mailto:jav@sics.se] > > Sent: Wednesday, July 28, 2010 1:05 AM > > To: Murray S. Kucherawy > > > > I'm not sure I'm understanding where this is going. > > Do I get the point correctly if we are all agreeing that: > > Applications should not need to care about network issues, that should > > be solved "underneath". > > Mobility, NAT, IPv4&6 and all other ugly network things should be dealt > > with by this other "underneath" thing. > > I believe most things in application space already consider everything you listed as "underneath", except perhaps for knowing what protocol family they're trying to use. Everything else you've listed already lives in other layers, mostly transport. > If only. The trouble is that application space does deal in things that it never should, namely the network address, IPv4 or IPv6, stores it, hands it on ... so when the lower layers, the only ones that should be privy to it, want to change it, for resilience, recovery, load balancing or any one of a hundred good reasons, they can't because that pesky application space has taken note of something that it never should have had knowledge of. I grew up with international networks where the application API was totally name based and, when I came to TCP/IP, wondered how a network address sensitive API could ever work; well, sticking plaster and string has kept it going for a while, but eventually it stops working, which is what RRG and its various products are about. Had name-based APIs been the norm in TCP/IP, then we would never have had a problem So I like the idea of a name-based API but it needs name-based referrals to make it of value. Tom Petch > The idea of moving DNS resolution out of the socket API is possibly an application area consideration, but it doesn't have anything to do with the things you listed above, and could probably solved with an API layer (a helper library) rather than a whole new socket abstraction. > > So my point is that the things you're saying this solves are actually already solved by the existing abstraction of the socket layer. I think your problem statement doesn't match what you're actually doing. > > Section 5 of your document shows an example use. Essentially what it does, though, is obviate the need to call gethostbyname() or similar. There's nothing in there about the "underneath" transport stuff. Comparing that to a current implementation, you can't see any obvious evidence, other than the protocol family, that the application knows anything about the "underneath" stuff in the first place. Therefore, I don't think you're actually addressing a problem that I can see in this context. > > The document either needs a more compelling statement of the problem it's solving, or some examples of code (or perhaps just pseudo-code) that shows the complication that would be alleviated. > > I'm also vaguely wondering if this (API definition) is the kind of thing the IETF should do in general, but I suspect I'm up against an opposite precedent on that issue. > > From jav@sics.se Fri Jul 30 06:25:41 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 25F273A69DB for ; Fri, 30 Jul 2010 06:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_42=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 qytGmkSy8MPX for ; Fri, 30 Jul 2010 06:25:38 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id E2F8D3A69A0 for ; Fri, 30 Jul 2010 06:25:27 -0700 (PDT) Received: from [212.238.51.52] (ip212-238-51-52.hotspotsvankpn.com [212.238.51.52]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id D1B1A3FFFF; Fri, 30 Jul 2010 15:25:50 +0200 (CEST) From: Javier Ubillos To: "t.petch" In-Reply-To: <013401cb2fcf$9818f7e0$4001a8c0@gateway.2wire.net> References: <018101cb2d88$808e4240$4001a8c0@gateway.2wire.net> <4C4F08D6.8020802@ninebynine.org> <002901cb2da6$1ad85f80$4001a8c0@gateway.2wire.net> <1280304326.2059.46.camel@bit> <013401cb2fcf$9818f7e0$4001a8c0@gateway.2wire.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5mHQaWVkfJ2kf0Fe0NfE" Date: Fri, 30 Jul 2010 15:25:52 +0200 Message-ID: <1280496352.31644.10.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 30 Jul 2010 13:25:41 -0000 --=-5mHQaWVkfJ2kf0Fe0NfE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2010-07-30 at 12:09 +0200, t.petch wrote: >=20 > So I like the idea of a name-based API but it needs name-based > referrals to make > it of value.=20 Could you please motivate a little ? Why and what kind of referral? The kind being spec:ed in "Generic referral object"? http://tools.ietf.org/html/draft-carpenter-behave-referral-object-01 To _some_ extent, a DNS record denotes scope (A, AAAA, SRV and so on). But maybe that dosen't scratch the right itch... // Javier --=-5mHQaWVkfJ2kf0Fe0NfE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxS0t4ACgkQGBo5FLRz4gqwkACgno5yTvcvKOUxMm6T5BA3iV2U 0ikAn1Rzqn3XaD0ZoZWAbZZZS2sAaMuo =9hlE -----END PGP SIGNATURE----- --=-5mHQaWVkfJ2kf0Fe0NfE-- From ietfc@btconnect.com Fri Jul 30 08:37: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 E09D23A69F2 for ; Fri, 30 Jul 2010 08:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_42=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 QucJcR8P9DNa for ; Fri, 30 Jul 2010 08:37:16 -0700 (PDT) Received: from c2beaomr03.btconnect.com (c2beaomr03.btconnect.com [213.123.26.181]) by core3.amsl.com (Postfix) with ESMTP id D4DF43A68F9 for ; Fri, 30 Jul 2010 08:37:15 -0700 (PDT) Received: from pc6 (host81-156-71-186.range81-156.btcentralplus.com [81.156.71.186]) by c2beaomr03.btconnect.com with SMTP id MHC31267; Fri, 30 Jul 2010 16:37:18 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C52F1AD.032A, actions=tag Message-ID: <003e01cb2ff4$20dbea00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Javier Ubillos" References: <1280496352.31644.10.camel@bit> Date: Fri, 30 Jul 2010 16:32:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr03.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0204.4C52F1BF.0341,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow 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, 30 Jul 2010 15:37:17 -0000 ----- Original Message ----- From: "Javier Ubillos" To: "t.petch" Sent: Friday, July 30, 2010 3:25 PM On Fri, 2010-07-30 at 12:09 +0200, t.petch wrote: > > So I like the idea of a name-based API but it needs name-based > referrals to make > it of value. Could you please motivate a little ? Why and what kind of referral? The kind being spec:ed in "Generic referral object"? http://tools.ietf.org/html/draft-carpenter-behave-referral-object-01 Yes or in draft-carpenter-referral-ps-00 FTP is the classic use case, a control channel that needs to transfer information about the end points of an associated data channel. Harking back to the name based sockets work of the RRG, a different approach is to split the 128 bits of an IPv6 address and make the lower 64 a stable identifier using the upper 64 for traffic routing, changing as network conditions change. This also needs a new API to go with it. To _some_ extent, a DNS record denotes scope (A, AAAA, SRV and so on). But maybe that dosen't scratch the right itch... // Javier