From discuss-bounces@apps.ietf.org Mon Jul 02 19:24:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5VFj-0002Ny-L9; Mon, 02 Jul 2007 19:24:19 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I5VFi-0002Ns-5i for discuss-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 19:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5VFh-0002Nk-Rn for discuss@apps.ietf.org; Mon, 02 Jul 2007 19:24:17 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5VFc-0006vN-1N for discuss@apps.ietf.org; Mon, 02 Jul 2007 19:24:17 -0400 Received: by nf-out-0910.google.com with SMTP id c10so59189nfd for ; Mon, 02 Jul 2007 16:24:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=b8gazorv+m+BycTYVM81fhY6LZ2iyYsbqW/ksuJavnGLWXo+GxnlxKedkuOW4g4vWdZqiJ5k6wPKgIByxJvVBYVVpRiM+5+SJ9Hzpnh0c41n6dDtAJ0VGvD0OLghi2tZmHtwXlCFHn37NQBtasXLTXyQe3hZNBeGTm3FxEL1AB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=dS3oIr9rz4GeH5N8/CT9c4p/tPnarRgnq8kGLsvxn0UbldWdET6f4hMGpWd7S9KjmEjz4TckF/WowZZbxeDT5cQSMTYijakigQxKrWxBgRX8lPGkvNgjqkW7FOMb7jCQ0lICCxjMhmNRH3Nwifxa/E8iuePI6WpPyJL2btIZw+c= Received: by 10.82.186.5 with SMTP id j5mr13982269buf.1183418650586; Mon, 02 Jul 2007 16:24:10 -0700 (PDT) Received: by 10.82.164.16 with HTTP; Mon, 2 Jul 2007 16:24:10 -0700 (PDT) Message-ID: Date: Mon, 2 Jul 2007 16:24:10 -0700 From: "Edward Lee" To: discuss@apps.ietf.org Subject: Standardizing Firefox's Implementation of Link Fingerprints MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: d09846643233b52e X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org For Firefox 3, there are patches [1] that implement Link Fingerprints, which provide automatic resource verification for URIs that look like http://site.com/file#hash(sha256:abc123) so that link providers can be sure that end users download the exact file that the provider intended (and not a trojaned download). The fragment identifier portion of the URI is used for backwards compatibility with existing clients while allowing for extended usage across protocols (e.g., http, ftp) and resource contexts (e.g., a href, img src). Additionally, fragment identifiers are not sent as part of a HTTP request, so the network and servers do not need to be changed. With the backwards compatibility, incremental deployment is feasible with some clients supporting Link Fingerprints, and end users don't need to do anything unless there's a fingerprint failure. An initial draft to standardize Link Fingerprints is available online.. https://people.mozilla.com/~edilee/draft-lee-uri-linkfingerprints-00.txt Feedback is welcome about the design, syntax, supported hashes, failure cases, etc. Ed [1] https://bugzilla.mozilla.org/show_bug.cgi?id=377245 From discuss-bounces@apps.ietf.org Mon Jul 02 20:45:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5WVl-0008V6-EE; Mon, 02 Jul 2007 20:44:57 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I5WVk-0008Pj-7m for discuss-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 20:44:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5WVj-0008Pb-UQ for discuss@apps.ietf.org; Mon, 02 Jul 2007 20:44:55 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5WVc-0006eI-Ov for discuss@apps.ietf.org; Mon, 02 Jul 2007 20:44:55 -0400 Received: from [192.168.0.3] (adsl-67-127-58-184.dsl.pltn13.pacbell.net [67.127.58.184]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l630iUv2024106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 17:44:33 -0700 Message-ID: <46899BA5.4000401@dcrocker.net> Date: Mon, 02 Jul 2007 17:43:17 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Edward Lee Subject: Re: Standardizing Firefox's Implementation of Link Fingerprints References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Edward Lee wrote: > For Firefox 3, there are patches [1] that implement Link Fingerprints, > which provide automatic resource verification for URIs that look like > http://site.com/file#hash(sha256:abc123) so that link providers can be > sure that end users download the exact file that the provider intended > (and not a trojaned download). Although this sounds like an entirely reasonable option to add to URLs, I'm curious just how much of a problem there is with downloads that are trojaned using the correct domain name? For this hashing to be useful, it means that either my client needs to land on a surrogate machine or the correct machine needs to be compromised. In either case, the hashing would seem to be useful, on the theory that the hash value is vetted when it is developed and is then distributed through an uncompromised path. I'm merely curious how big a problem any of this currently is? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Mon Jul 02 20:57:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5WiM-0002hS-3l; Mon, 02 Jul 2007 20:57:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I5WiK-0002bg-H1 for discuss-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 20:57:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5WiK-0002aU-6R for discuss@apps.ietf.org; Mon, 02 Jul 2007 20:57:56 -0400 Received: from mu-out-0910.google.com ([209.85.134.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5WiE-0000jm-5P for discuss@apps.ietf.org; Mon, 02 Jul 2007 20:57:56 -0400 Received: by mu-out-0910.google.com with SMTP id w1so1935863mue for ; Mon, 02 Jul 2007 17:57:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TYlty2iffEGhYi27bOW4HcR3YmbzjECePJtOfp1XThI8W0c9WMYRyHzN4wt1ZzUSstr/EnlMoqaO0I/hRwfUAM/RLY86pD+YLfJBPCoBlEdPkmGUagyRJqla27nLrxAZVsal/tCIiXQvH986U89RXOOqggNtq/hCfB6Ob+Fmp2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=SrWEy6KjPGgqWL+i0TETWBTD+E+MzmHouofEGOGDMQObLGTg0x5+6a1iyTuWAg6qg1FnTA52Q3RrVwUpz60zJH+h3AbzM1qhbekaBWKyW+RT5ShcAF9ziaWT1jA8XoOrNoUuD8MJ7HHfFThU3D/PUe2TY9JZGsTwo1tInw1nAMw= Received: by 10.82.170.2 with SMTP id s2mr14167494bue.1183424267485; Mon, 02 Jul 2007 17:57:47 -0700 (PDT) Received: by 10.82.164.16 with HTTP; Mon, 2 Jul 2007 17:57:47 -0700 (PDT) Message-ID: Date: Mon, 2 Jul 2007 17:57:47 -0700 From: "Edward Lee" To: dcrocker@bbiw.net Subject: Re: Standardizing Firefox's Implementation of Link Fingerprints In-Reply-To: <46899BA5.4000401@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46899BA5.4000401@dcrocker.net> X-Google-Sender-Auth: eb8d93cfe105beb6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 7/2/07, Dave Crocker wrote: > Although this sounds like an entirely reasonable option to add to URLs, I'm > curious just how much of a problem there is with downloads that are trojaned > using the correct domain name? One main use case of Link Fingerprints is for file mirroring networks. The portal server with high security can link to 3rd party mirrors that may or may not have the correct file that is being distributed. With just some clients supporting Link Fingerprints, the users that see the problem can report to the site administrator to quickly resolve the problem. For a recent example, WordPress announced on March 2, 2007 that some copies of version 2.1.1 was hijacked. "It was determined that a cracker had gained user-level access to one of the servers that powers wordpress.org, and had used that access to modify the download file. We have locked down that server for further forensics, but at this time it appears that the 2.1.1 download was the only thing touched by the attack. They modified two files in WP to include code that would allow for remote PHP execution." [1] Ed [1] http://wordpress.org/development/2007/03/upgrade-212/ From discuss-bounces@apps.ietf.org Mon Jul 02 21:07:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5WrC-0006oy-8t; Mon, 02 Jul 2007 21:07:06 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I5WmP-00073W-2D for discuss-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 21:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5WmO-00073M-7k for discuss@apps.ietf.org; Mon, 02 Jul 2007 21:02:08 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5WmJ-0001vd-RU for discuss@apps.ietf.org; Mon, 02 Jul 2007 21:02:08 -0400 Received: from [192.168.0.3] (adsl-67-127-58-184.dsl.pltn13.pacbell.net [67.127.58.184]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6311hF5027280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 18:01:43 -0700 Message-ID: <46899FAD.6060704@bbiw.net> Date: Mon, 02 Jul 2007 18:00:29 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Edward Lee Subject: Re: Standardizing Firefox's Implementation of Link Fingerprints References: <46899BA5.4000401@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dcrocker@bbiw.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Mon, 02 Jul 2007 21:07:04 -0400 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Edward Lee wrote: > For a recent example, WordPress announced on March 2, 2007 that some > copies of version 2.1.1 was hijacked. > > "It was determined that a cracker had gained user-level access to one > of the servers that powers wordpress.org, and had used that access to > modify the download file. We have locked down that server for further Thanks. d/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Mon Jul 02 22:43:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5YMC-0004od-9h; Mon, 02 Jul 2007 22:43:12 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I5YMA-0004jC-TG for discuss-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 22:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5YMA-0004gO-75 for discuss@apps.ietf.org; Mon, 02 Jul 2007 22:43:10 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5YLJ-0001x1-9O for discuss@apps.ietf.org; Mon, 02 Jul 2007 22:43:10 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id D549C1EE23D; Mon, 2 Jul 2007 22:42:16 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3oUx-+5SaBW; Mon, 2 Jul 2007 22:42:16 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 92EAB1EE202; Mon, 2 Jul 2007 22:42:15 -0400 (EDT) Message-ID: <4689B786.6050008@cs.utk.edu> Date: Mon, 02 Jul 2007 22:42:14 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Edward Lee Subject: Re: Standardizing Firefox's Implementation of Link Fingerprints References: In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org great idea in principle, but somehow, using fragment identifiers for this seems like it's incompatible with the normal use of fragment identifiers. I guess I see little danger that these will collide with "real" fragment IDs, but somewhat more danger that a browser or other parser will look at a document containing such URIs and do something reasonable with it. > For Firefox 3, there are patches [1] that implement Link Fingerprints, > which provide automatic resource verification for URIs that look like > http://site.com/file#hash(sha256:abc123) so that link providers can be > sure that end users download the exact file that the provider intended > (and not a trojaned download). > > The fragment identifier portion of the URI is used for backwards > compatibility with existing clients while allowing for extended usage > across protocols (e.g., http, ftp) and resource contexts (e.g., a > href, img src). Additionally, fragment identifiers are not sent as > part of a HTTP request, so the network and servers do not need to be > changed. With the backwards compatibility, incremental deployment is > feasible with some clients supporting Link Fingerprints, and end users > don't need to do anything unless there's a fingerprint failure. > > An initial draft to standardize Link Fingerprints is available online.. > > https://people.mozilla.com/~edilee/draft-lee-uri-linkfingerprints-00.txt > > Feedback is welcome about the design, syntax, supported hashes, > failure cases, etc. > > Ed > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=377245 > > From discuss-bounces@apps.ietf.org Mon Jul 02 23:22:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Yyb-00026h-M2; Mon, 02 Jul 2007 23:22:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I5Yya-00024w-Di for discuss-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 23:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Yya-00024o-3o for discuss@apps.ietf.org; Mon, 02 Jul 2007 23:22:52 -0400 Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5YyT-0005v0-G8 for discuss@apps.ietf.org; Mon, 02 Jul 2007 23:22:52 -0400 Received: from [10.201.0.49] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l633PLBM002082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 20:25:27 -0700 X-DKIM: Sendmail DKIM Filter v1.0.0 foon.sendmail.com l633PLBM002082 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1183433129; bh=0vM3JkZvBp16FJ9wq34BnkRuUiYgaZvvGjvAAD VggGc=; h=X-DomainKeys:DomainKey-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:MIME-Version: Content-Type; b=OILVUPX5Hzrd237odJXmgQ+Rbzu4SK1qfT/JP8ejGwguDw91GF zLku4h/KUDyB+3tpOhB6BW60qz7R2AJ5e9VVl2Jr7ynwBN1DZIAdG8HQRsKdP7XUmVn V5hDkFZAoOuWviEGy6ONd6sPsmpIiFsgZqrDfxEIS8GGCK4b2IOx8o= X-DomainKeys: Sendmail DomainKeys Filter v0.6.0 foon.sendmail.com l633PLBM002082 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=M2aPN/1tjmQ6rZm9RrubABByMCbJ7b+C9R7ZchJvTUITfl/hNT9KdVNwG7RnykSya Qtyzw5U2Wh5ofiFw4pyXANb9pFBFTr9Ae18J4AULF28ZBMNjm32B4btX5vXvU2X6BS/ 9+HPa82Y+eWuAWtWov6Y/mO+QM5xCOkc2fDfIYU= Date: Mon, 2 Jul 2007 21:22:32 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Edward Lee Subject: Re: Standardizing Firefox's Implementation of Link Fingerprints In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 2 Jul 2007, Edward Lee wrote: > For Firefox 3, there are patches [1] that implement Link Fingerprints, > which provide automatic resource verification for URIs that look like > http://site.com/file#hash(sha256:abc123) so that link providers can be > sure that end users download the exact file that the provider intended > (and not a trojaned download). This sounds a lot like the hash-scheme for making text fragment identifiers robust that's proposed in http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-06.txt The goals are not quite parallel as the above doesn't support hashing without also specifying a position, while your draft pictures a general syntax for schema and content-type independent signing. The overlap does seem considerably though, if just because a content-type independent method would render the text/plain specific one obsolete. Putting general object metadata in the fragment seems contorted though. For the hash-scheme stuff in draft-wilde-text-fragment there's at least a tenuous association with positioning information, but even then it's a stretch. (Is there any normal textual representation for an http URL plus an etag or other identity verifier? imap URLs put the mailbox UIDVALIDITY, which is an identity verifier for the mailbox as an object, in the path part.) Philip Guenther Sendmail, Inc. From discuss-bounces@apps.ietf.org Tue Jul 03 05:13:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5eSH-0000wj-Lw; Tue, 03 Jul 2007 05:13:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I5eSG-0000wX-0T for discuss-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 05:13:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5eSF-0000wJ-JK for discuss@apps.ietf.org; Tue, 03 Jul 2007 05:13:51 -0400 Received: from vinyl.extundo.com ([83.241.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5eSB-0006SL-3p for discuss@apps.ietf.org; Tue, 03 Jul 2007 05:13:51 -0400 Received: from mocca.josefsson.org (38.177.241.83.in-addr.dgcsystems.net [83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l639DPCf006031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jul 2007 11:13:32 +0200 From: Simon Josefsson To: "Edward Lee" Subject: Re: Standardizing Firefox's Implementation of Link Fingerprints References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070703:edilee@mozilla.com::6Cc9mLZA5U7KBMY2:2vmd X-Hashcash: 1:22:070703:discuss@apps.ietf.org::sqgWrJw/klUBHRg3:3Sth Date: Tue, 03 Jul 2007 11:13:25 +0200 In-Reply-To: (Edward Lee's message of "Mon, 2 Jul 2007 16:24:10 -0700") Message-ID: <871wfp3l56.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org "Edward Lee" writes: > https://people.mozilla.com/~edilee/draft-lee-uri-linkfingerprints-00.txt I believe standardizing this would be useful. There is another use case for this idea: referencing X.509 certificates. Some protocols -- TLS client_certificate_url extension, and the DNS CERT resource record -- already have support for something similar, where a URL needs to be accompanied with a hash in order to be useful. Placing the hash value in the URL itself is a simple improvement, and will simplify future protocols that want to do similar things as TLS/CERT. These future protocols can have only a URL field, and require that the URL contains a linkfingerprint. An origin of the hash-value-in-URL idea is the WTLS, if you can find a reference to it, it may be useful to add a informative reference to it. There may be other similar examples too, but I don't know of any earlier one. /Simon From discuss-bounces@apps.ietf.org Wed Jul 04 05:35:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61Gl-0006Sw-Qv; Wed, 04 Jul 2007 05:35:31 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I61Gl-0006Sr-H6 for discuss-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 05:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61Gl-0006Si-7H for discuss@apps.ietf.org; Wed, 04 Jul 2007 05:35:31 -0400 Received: from mail93.messagelabs.com ([194.106.220.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I61Gh-0006cC-NU for discuss@apps.ietf.org; Wed, 04 Jul 2007 05:35:31 -0400 X-VirusChecked: Checked X-Env-Sender: oskar.vandeventer@tno.nl X-Msg-Ref: server-8.tower-93.messagelabs.com!1183541724!9104402!1 X-StarScan-Version: 5.5.12.11; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 28411 invoked from network); 4 Jul 2007 09:35:24 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-8.tower-93.messagelabs.com with SMTP; 4 Jul 2007 09:35:24 -0000 Received: from ms-dt01thalia.tsn.tno.nl (ms-dt01thalia.tno.nl [134.221.225.157]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id l649ZNx06055 for ; Wed, 4 Jul 2007 11:35:24 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: ETSI TISPAN interest in tv:URI Date: Wed, 4 Jul 2007 11:35:22 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56019F7C94@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56D38E21@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ETSI TISPAN interest in tv:URI Thread-Index: AcboWEdyz2u14ulLQmOOXlEqwqG1OQDJhFfwNKOJfCA= From: "Deventer, M.O. (Oskar) van" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org All, The=20issue=20of=20identification=20of=20television=20channels=20has=20bee= n=20discussed=20in the=20ETSI=20TISPAN=2014bis=20meeting=20of=20last=20week.=20The=20applicat= ion=20of=20this identification=20is=20IPTV=20Presence:=20a=20presentity=20can=20publish=20= which=20TV channel=20he=20is=20watching.=20The=20fact=20that=20ETSI=20TISPAN=20has=20= requirements related=20to=20the=20identification=20of=20TV=20channels=20(e.g.=20tv:URI)= =20is=20reflected in=20the=20recent=20update=20of=20our=20internet=20draft http://www.ietf.org/internet-drafts/draft-keesmaat-tvreg-01.txt. TISPAN=20WG1=20(services)=20and=20WG2=20(architecture)=20have=20defined=20= the=20following requirements,=20relevant=20to=20our=20IETF=20APPS=20mailing=20list=20discu= ssions=20on=20the tv:URI=20last=20October. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20Start=20of=20TISPAN=20requirements=20=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D WI01044=20(Draft=20TS=20181=20016): "Users'=20presence=20information=20may=20be=20related=20to,=20e.g.,=20thei= r=20connection status,=20location=20information,=20channel=20currently=20accessed=20or=20= acceptable communication=20means.=20Presence=20information=20on=20channel=20currently= =20accessed may=20be=20used=20by=20another=20user=20to=20instruct=20his=20set-top=20bo= x=20with=20a=20single click=20to=20switch=20to=20the=20identified=20channel,=20or=20to=20instruc= t=20his=20set-top box=20to=20keep=20following=20identified=20channel=20changes.=20There=20ma= y=20be significant=20delays=20in=20this=20following,=20depending=20on=20the=20upd= ate=20speed=20of the=20presence=20service. Any=20published=20presence=20information=20should=20only=20be=20disseminat= ed=20other users=20that=20are=20authorised=20to=20receiving=20this=20presence=20infor= mation according=20to=20the=20presentity=20policies Users=20can=20also=20define=20a=20set=20of=20access=20rules=20to=20control= =20access=20to=20their presence=20information. 6.2.1.1=09=09It=20must=20be=20possible=20to=20define=20presence=20informat= ion related=20to=20the=20IPTV=20experience,=20e.g.=20channel=20currently=20acc= essed.=20The identification=20of=20the=20channel=20currently=20accessed=20shall=20be machine-readable.=20Language=20dependent=20information=20may=20also=20be=20= made available=20to=20watchers." WI02048=20(Draft=20TS=20182=20027): "The=20following=20specific=20IPTV=20attributes=20may=20also=20be=20suppor= ted: channel=20currently=20accessed, program=20currently=20watched,=20when=20available. content=20currently=20accessed. If=20the=20IPTV=20presence=20attribute=20"channel=20currently=20accessed"=20= is supported,=20then=20the=20machine-readable=20part=20of=20the=20identificat= ion=20of=20the channel=20shall=20be=20globally=20unique.=20The=20term=20globally=20unique= =20here=20means that=20there=20is=20no=20ambiguity=20in=20the=20identification=20of=20the=20= channel=20if presentity=20and=20watcher=20(for=20terminology,=20see=20in=20ETSI=20182=20= 008)=20are=20with different=20network=20operators=20and/or=20in=20different=20countries." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20End=20of=20TISPAN=20requirements=20=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D TISPAN=20WG4=20(identifiers)=20has=20allocated=20a=20session=20in=20next=20= TISPAN=20meeting dedicated=20to=20"Tv=20URI=20identifier=20and=20resolution".=20The=20meeti= ng=20details=20for this=20session=20are=20as=20follows. Meeting:=20ETSI=20TISPAN=2014ter Location:=20ETSI=20Headquarters,=20Sophia=20Antipolis Dates:=203-7=20September=202007 WG4=20session=20on=20tv:URI:=20Wednesday=205=20September,=2011:15-13:00 With=20this=20email,=20I=20would=20like=20to=20invite=20interested=20parti= es=20to participate=20and/or=20contribute=20to=20this=20WG4=20session. Best=20regards, Oskar=20 -----Original=20Message----- From:=20Keesmaat,=20N.W.=20(Iko)=20 Sent:=20maandag=209=20oktober=202006=2013:25 To:=20discuss@apps.ietf.org Cc:=20Clive=20D.W.=20Feather;=20Zigmond,=20Dan Subject:=20RE:=20Reigistry=20for=20tv:URI's [...=20previous=20mail=20thread=20...] This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html From discuss-bounces@apps.ietf.org Fri Jul 06 13:09:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6rIp-00066H-1R; Fri, 06 Jul 2007 13:09:07 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I6rIn-00066B-Kx for discuss-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 13:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6rIn-000663-Aw for discuss@apps.ietf.org; Fri, 06 Jul 2007 13:09:05 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6rIi-0004mQ-UB for discuss@apps.ietf.org; Fri, 06 Jul 2007 13:09:05 -0400 Received: from [192.168.0.3] (adsl-68-122-42-129.dsl.pltn13.pacbell.net [68.122.42.129]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l66H8eUM013553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 10:08:40 -0700 Message-ID: <468E76CB.8000007@dcrocker.net> Date: Fri, 06 Jul 2007 10:07:23 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Testers for new ID submission tool References: <46658D85.7050101@spaghetti.zurich.ibm.com> In-Reply-To: <46658D85.7050101@spaghetti.zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Jeroen Massar wrote: > Lisa Dusseault wrote: >> Anybody interested in testing the new ID submission tool? Russ asked >> for 10 names, let me know if you're going to be updating a draft or >> submitting a new draft and I'll pass the first ten names on to Russ. > > Does it accept .xml's ? :) I don't recall seeing a response to this question. At this point, I tend to submitt .txt, .pdf and .xml versions together, so that the IETF repository has all 3. I was surprised and quite please to see that the PDF version is made public. So, what does the submission tool accept? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Fri Jul 06 13:21:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6rV9-0000U5-2s; Fri, 06 Jul 2007 13:21:51 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I6rV8-0000Tz-8U for discuss-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 13:21:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6rV7-0000Tr-Uv for discuss@apps.ietf.org; Fri, 06 Jul 2007 13:21:49 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6rV3-0005ac-Ju for discuss@apps.ietf.org; Fri, 06 Jul 2007 13:21:49 -0400 Received: from [192.168.0.3] (adsl-68-122-42-129.dsl.pltn13.pacbell.net [68.122.42.129]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l66HLSNv016891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 10:21:28 -0700 Message-ID: <468E79CB.7000205@bbiw.net> Date: Fri, 06 Jul 2007 10:20:11 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Testers for new ID submission tool References: <46658D85.7050101@spaghetti.zurich.ibm.com> <468E76CB.8000007@dcrocker.net> <468E78BE.40505@isode.com> In-Reply-To: <468E78BE.40505@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dcrocker@bbiw.net X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Alexey Melnikov wrote: > It accepts .xml, .pdf and .ps together with .txt. But .txt is required. Very cool. The Tool Team Rocks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Fri Jul 06 14:33:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sc1-0002W6-4s; Fri, 06 Jul 2007 14:33:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I6sby-0002Vr-AN for discuss-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 14:33:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sbx-0002Vi-S9 for discuss@apps.ietf.org; Fri, 06 Jul 2007 14:32:57 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6sbx-0003vE-Fm for discuss@apps.ietf.org; Fri, 06 Jul 2007 14:32:57 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 0B742140C232; Fri, 6 Jul 2007 20:32:53 +0200 (CEST) Message-ID: <468E8AD5.8020904@spaghetti.zurich.ibm.com> Date: Fri, 06 Jul 2007 19:32:53 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dave Crocker Subject: Re: Testers for new ID submission tool References: <46658D85.7050101@spaghetti.zurich.ibm.com> <468E76CB.8000007@dcrocker.net> <468E78BE.40505@isode.com> <468E79CB.7000205@bbiw.net> In-Reply-To: <468E79CB.7000205@bbiw.net> X-Enigmail-Version: 0.95.2 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE33DE20BB6EF833C22EFFCA3" X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE33DE20BB6EF833C22EFFCA3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dave Crocker wrote: >=20 >=20 > Alexey Melnikov wrote: >> It accepts .xml, .pdf and .ps together with .txt. But .txt is required= =2E >=20 >=20 > Very cool. >=20 > The Tool Team Rocks! Indeed, that is very nice :) Though, what I have not uncovered yet is where the .xml/pdf/ps versions get published for download. Anyone got a hint on that? Greets, Jeroen --------------enigE33DE20BB6EF833C22EFFCA3 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.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaOitUuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I5ULAKCId6ObezOifmDuzqnHL3vmhlI6 WwCgt2BYuaKNtiSx537rGXZydG1q7b0= =ValC -----END PGP SIGNATURE----- --------------enigE33DE20BB6EF833C22EFFCA3-- From discuss-bounces@apps.ietf.org Fri Jul 06 17:59:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vpY-0000DL-N6; Fri, 06 Jul 2007 17:59:12 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I6vpW-00005y-Qa for discuss-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 17:59:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vpW-0008VH-Fg for discuss@apps.ietf.org; Fri, 06 Jul 2007 17:59:10 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6vpS-0005mi-4u for discuss@apps.ietf.org; Fri, 06 Jul 2007 17:59:10 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 06 Jul 2007 14:59:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAE9XjkarR7PDh2dsb2JhbACPOAEBCQ4s X-IronPort-AV: i="4.16,509,1175497200"; d="scan'208"; a="384123616:sNHT74199544" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l66Lx5gk025472; Fri, 6 Jul 2007 14:59:05 -0700 Received: from dwingwxp (dhcp-128-107-163-99.cisco.com [128.107.163.99]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l66Lx4mo020356; Fri, 6 Jul 2007 21:59:04 GMT From: "Dan Wing" To: "'Jeroen Massar'" , "'Dave Crocker'" Subject: RE: Testers for new ID submission tool Date: Fri, 6 Jul 2007 14:59:04 -0700 Message-ID: <143201c7c018$dea5bba0$e171150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Ace//CQAmQCj8jgJTE+Bx2fw0gWqfQAHLX6g In-Reply-To: <468E8AD5.8020904@spaghetti.zurich.ibm.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=182; t=1183759145; x=1184623145; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Testers=20for=20new=20ID=20submission=20tool |Sender:=20; bh=Jvf0J+4mgLPon+z4oiV9RXXG9R89HKrNF4iXNL1G7r0=; b=D/KBASQLZz0GykI8bl93HprFziZOguI9nxk9ghnHZmPL6htDn6pnZIzxP5XO0X3MKwWjsPLN GuzCULZE6HzT+JrW/OKE7Ew+Tb/xsieVdaN/0UHSpYZ8qluTaXdMl2yy; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Though, what I have not uncovered yet is where the > .xml/pdf/ps versions > get published for download. Anyone got a hint on that? ftp://ftp.ietf.org/internet-drafts/ -d From discuss-bounces@apps.ietf.org Fri Jul 06 18:47:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wa6-0005zj-KH; Fri, 06 Jul 2007 18:47:18 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I6wa5-0005vc-Nf for discuss-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 18:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wa5-0005vU-E6 for discuss@apps.ietf.org; Fri, 06 Jul 2007 18:47:17 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6wa4-0003nd-0R for discuss@apps.ietf.org; Fri, 06 Jul 2007 18:47:17 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 755F7140C287; Sat, 7 Jul 2007 00:47:14 +0200 (CEST) Message-ID: <468EC66F.9080304@spaghetti.zurich.ibm.com> Date: Fri, 06 Jul 2007 23:47:11 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dan Wing Subject: Re: Testers for new ID submission tool References: <143201c7c018$dea5bba0$e171150a@amer.cisco.com> In-Reply-To: <143201c7c018$dea5bba0$e171150a@amer.cisco.com> X-Enigmail-Version: 0.95.2 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E1EC6940F5EE1F7074FBB9F" X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'Apps Discuss' , 'Dave Crocker' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E1EC6940F5EE1F7074FBB9F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dan Wing wrote: >> Though, what I have not uncovered yet is where the=20 >> .xml/pdf/ps versions >> get published for download. Anyone got a hint on that? >=20 > ftp://ftp.ietf.org/internet-drafts/ Cool, thanks, last time I looked there they where not there but it seems they definitely are getting published now. Greets, Jeroen --------------enig6E1EC6940F5EE1F7074FBB9F 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.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaOxnMuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I/HhAJ9eCMvmkWbr2duuyMRBAUeqwek/ kACeOUH/Hy1pdG9MTxjpKvqcHMCuhTI= =ZDXD -----END PGP SIGNATURE----- --------------enig6E1EC6940F5EE1F7074FBB9F-- From discuss-bounces@apps.ietf.org Sat Jul 07 11:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7CcB-0001BI-Fy; Sat, 07 Jul 2007 11:54:31 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I6rR2-0006oK-7M for discuss-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 13:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6rQz-0006oA-M9 for discuss@apps.ietf.org; Fri, 06 Jul 2007 13:17:34 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6rQv-0005AM-9G for discuss@apps.ietf.org; Fri, 06 Jul 2007 13:17:33 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 6 Jul 2007 18:17:26 +0100 Message-ID: <468E78BE.40505@isode.com> Date: Fri, 06 Jul 2007 18:15:42 +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: dcrocker@bbiw.net Subject: Re: Testers for new ID submission tool References: <46658D85.7050101@spaghetti.zurich.ibm.com> <468E76CB.8000007@dcrocker.net> In-Reply-To: <468E76CB.8000007@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Sat, 07 Jul 2007 11:54:30 -0400 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Dave Crocker wrote: > Jeroen Massar wrote: > >> Lisa Dusseault wrote: >> >>> Anybody interested in testing the new ID submission tool? Russ asked >>> for 10 names, let me know if you're going to be updating a draft or >>> submitting a new draft and I'll pass the first ten names on to Russ. >> >> Does it accept .xml's ? :) > > I don't recall seeing a response to this question. > > At this point, I tend to submitt .txt, .pdf and .xml versions > together, so that the IETF repository has all 3. I was surprised and > quite please to see that the PDF version is made public. > > So, what does the submission tool accept? It accepts .xml, .pdf and .ps together with .txt. But .txt is required. From discuss-bounces@apps.ietf.org Tue Jul 10 13:25:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JSz-0008AA-J7; Tue, 10 Jul 2007 13:25:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I8JSy-0008A4-68 for discuss-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 13:25:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JSx-00089w-SK for discuss@apps.ietf.org; Tue, 10 Jul 2007 13:25:35 -0400 Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8JSx-0004Nu-AA for discuss@apps.ietf.org; Tue, 10 Jul 2007 13:25:35 -0400 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 3CF231E34; Tue, 10 Jul 2007 17:25:34 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID209LgJRZI0261Xo2; Tue, 10 Jul 2007 17:25:34 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID209LgJRZI0261Xo2 Received: from [192.168.1.101] ([74.95.2.169]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 11:23:45 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <265F54F2-C0DD-440B-A30D-8DA4A927341C@commerce.net> Content-Type: multipart/alternative; boundary=Apple-Mail-5--377304554 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's Apps area activity for June 2007 From: Lisa Dusseault Date: Tue, 10 Jul 2007 10:25:25 -0700 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Jul 2007 17:23:45.0832 (UTC) FILETIME=[12141A80:01C7C317] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-5--377304554 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed APP area Meetings in Chicago Mon APPArea -- App area open meeting -- accepting agenda suggestions Lemonade -- no agenda yet Tue HTTPBis BOF -- agenda mostly geared towards developing WG charter http://www3.ietf.org/proceedings/07jul/agenda/httpbis.txt Read: draft-lafon-rfc2616bis-03.txt, draft-sayre-http-security- variance-00.txt Sieve -- agenda includes many active documents (not listed here) http://www3.ietf.org/proceedings/07jul/agenda/sieve.txt Lemonade cont. Wed geopriv (not apps area but I'm advisor to this group) Thu EAI -- no agenda yet CALSIFY -- agenda is about completing work items http://www3.ietf.org/proceedings/07jul/agenda/calsify.txt Read: draft-ietf-calsify-2446bis-03, draft-ietf-calsify- rfc2445bis-07.txt VCARDDAV BOF -- agenda introduces proposed work then proceeds to charter bashing http://www3.ietf.org/proceedings/07jul/agenda/vcarddav.txt Read: draft-daboo-carddav-02 Fri BIFF BOF -- Notifications from Mail Stores -- no agenda yet. Document Status and Progress Active Documents: my action - draft-ietf-atompub-protocol: IESG Evaluation phase, work with Sam Hartman and Paul Hoffman (doc shepherd) on security questions - draft-ietf-sieve-3028bis: IESG Evaluation phase, work with Cullen and doc shepherd on multiple redirect issues - draft-montemurro-gsma-imei-urn: IESG Evaluation phase, work with authors on Informational status and how many URNs to register Stalled or waiting on other - draft-crispin-collation-unicasemap: Finished IETF Last Call, waiting for revision and/or doc shepherd writeup (Alexey) - draft-hartman-webauth-phishing: Finished IETF Last Call, waiting for doc shepherd writeup (Alexey) - draft-ietf-sieve-body: Finished IETF Last Call, waiting for revision and/or doc shepherd writeup (Alexey/Cyrus). NOTE: IANA has questions... - draft-ietf-lemonade-rfc2192bis: finished IETF Last Call, waiting for authors and shepherd decision on code license - draft-ietf-imapext-sort: Still stalled waiting on unicasemap document - draft-crocker-rfc4234bis: Finished IESG Evaluation, waiting for author to resolve LWSP issue raised in IETF Last Call and IESG Evaluation - draft-ietf-widex-requirements: Finished IESG Evaluation, waiting for revision with more security considerations or alternatively a disclaimer. Finished processing - RFC queue mostly - draft-nottingham-atompub-feed-history-11.txt : IESG Evaluation completed, will enter RFC queue shortly. - draft-friend-oftp2: NOT an IETF document -- reviewed and processed for suitability as independent RFC. - draft-kunze-rfc2413bis: Entered RFC queue as Informational WG quick status WIDEX: Will be closed -- inactive. USEFOR: trundling along on USEPRO issues SIEVE: processing several active documents IMAPEXT: Quiescent, waiting on busy authors. ATOMPUB: Finishing Atom Publishing Protocol -- latest and possibly last version just published CALSIFY: Finishing RFC2445bis and a little work on other two documents --Apple-Mail-5--377304554 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

APP area Meetings in = Chicago
Mon APPArea -- App area open meeting = -- accepting agenda suggestions
Lemonade -- no agenda = yet
Tue= HTTPBis BOF -- agenda mostly geared towards = developing WG charter
= Read:=A0draft-lafon-rfc2616bis-03.txt,=A0draft-sayre-http-security-= variance-00.txt=A0
Sieve -- agenda includes = many active documents (not listed here)
= Lemonade cont.
Wed=A0 geopriv (not apps area but I'm = advisor to this group)
Thu EAI -- no agenda = yet
= CALSIFY -- agenda is about completing work items
= Read:=A0draft-ietf-calsify-2446bis-03,=A0draft-ietf-calsify-rfc2445= bis-07.txt
VCARDDAV BOF -- agenda = introduces proposed work then proceeds to charter = bashing
= Read:=A0draft-daboo-carddav-02
Fri = BIFF BOF -- Notifications from Mail Stores -- no agenda = yet.

=
Document Status and Progress

Active Documents: my = action
- draft-ietf-atompub-protocol:=A0 IESG Evaluation = phase, work with Sam Hartman and Paul Hoffman (doc shepherd) on security = questions
-=A0draft-ietf-sieve-3028bis:=A0IESG Evaluation = phase,=A0 work with Cullen and doc shepherd on multiple redirect = issues
=A0-=A0draft-montemurro-gsma-imei-urn:=A0IESG = Evaluation phase,=A0 work with authors on Informational status and how = many URNs to register

Stalled or waiting on = other
-=A0draft-crispin-collation-unicasemap:=A0Finished = IETF Last Call, waiting for revision and/or doc shepherd writeup = (Alexey)=A0
-=A0draft-hartman-webauth-phishing: Finished IETF = Last Call, waiting for doc shepherd writeup = (Alexey)
=A0-=A0draft-ietf-sieve-body: Finished IETF Last = Call, waiting for revision and/or doc shepherd writeup (Alexey/Cyrus).=A0 = NOTE: IANA has questions...
=A0- = draft-ietf-lemonade-rfc2192bis:=A0 finished IETF Last Call, waiting for = authors and shepherd decision on code license
=A0- = draft-ietf-imapext-sort:=A0 Still stalled waiting on unicasemap = document
=A0- draft-crocker-rfc4234bis: Finished IESG = Evaluation, waiting for author to resolve LWSP issue raised in IETF Last = Call and IESG Evaluation
=A0- draft-ietf-widex-requirements: = Finished IESG Evaluation, waiting for revision with more security = considerations or alternatively a disclaimer.

Finished processing - = RFC queue mostly
=A0- = draft-nottingham-atompub-feed-history-11.txt=A0:=A0 IESG Evaluation = completed, will enter RFC queue shortly.
=A0- = draft-friend-oftp2:=A0 NOT an IETF document -- reviewed and processed = for suitability as independent RFC.
=A0-=A0draft-kunze-rfc2413bi= s: Entered RFC queue as Informational

WG quick = status
WIDEX: Will be closed -- = inactive.
USEFOR: trundling along on USEPRO = issues
SIEVE: processing several active = documents
IMAPEXT: Quiescent, waiting on busy = authors.
ATOMPUB: Finishing Atom Publishing Protocol -- latest = and possibly last version just published
CALSIFY: Finishing = RFC2445bis and a little work on other two documents


= --Apple-Mail-5--377304554-- From discuss-bounces@apps.ietf.org Thu Jul 12 21:00:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I99WR-0002aa-19; Thu, 12 Jul 2007 21:00:39 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I99WP-0002WO-DR for discuss-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 21:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I99WP-0002VJ-3I for discuss@apps.ietf.org; Thu, 12 Jul 2007 21:00:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I99WL-00039W-MT for discuss@apps.ietf.org; Thu, 12 Jul 2007 21:00:37 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6D10WTX090179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Jul 2007 18:00:33 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 12 Jul 2007 18:00:28 -0700 To: Apps Discuss From: Paul Hoffman Subject: Fwd: Last Call: draft-duerst-archived-at (The Archived-At Message Header Field) to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This seems like a good place to alert people about this IETF Last call. >The IESG has received a request from an individual submitter to consider >the following document: > >- 'The Archived-At Message Header Field ' > 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 2007-08-09. 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-duerst-archived-at-07.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11469&rfc_flag=0 From discuss-bounces@apps.ietf.org Fri Jul 13 09:59:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LgF-00067h-3p; Fri, 13 Jul 2007 09:59:35 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I9LgD-00067Y-O2 for discuss-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 09:59:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LgC-00067K-Pb for discuss@apps.ietf.org; Fri, 13 Jul 2007 09:59:32 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Lg8-0008FU-DR for discuss@apps.ietf.org; Fri, 13 Jul 2007 09:59:32 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 965E02DC3; Fri, 13 Jul 2007 16:59:25 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id D0AB92DAF; Fri, 13 Jul 2007 16:59:24 +0300 (EEST) Date: Fri, 13 Jul 2007 16:59:24 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Gonzalo Camarillo X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, this a new version of the APIs for HIP and other related protocols. I updated it according to the comments I received from this list while ago on this thread. Please, feel free to comment again either here or hipsec: https://www1.ietf.org/mailman/listinfo/hipsec A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Native Application Programming Interfaces for SHIM APIs Author(s) : M. Komu Filename : draft-ietf-hip-native-api-02.txt Pages : 12 Date : 2007-7-8 This document defines extensions to the current networking APIs for protocols based on identifier/locator split. Currently, the document focuses on HIP, but the extensions can be used also by other protocols implementing identifier locator split. Using the API extensions, new SHIM aware applications can configure manually mappings between upper layer identifiers and the corresponding locators. Also, the API describes how to handle outbound connection establishment where an application is unaware of the peer identifier but knows the peer locator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Tue Jul 24 01:07:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDCcL-0001yE-QV; Tue, 24 Jul 2007 01:07:29 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IDCcK-0001y7-98 for discuss-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 01:07:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDCcJ-0001xy-VJ for discuss@apps.ietf.org; Tue, 24 Jul 2007 01:07:27 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDCcI-0004Z7-F1 for discuss@apps.ietf.org; Tue, 24 Jul 2007 01:07:27 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BCDB2596C1; Tue, 24 Jul 2007 07:07:25 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11173-10; Tue, 24 Jul 2007 07:07:17 +0200 (CEST) Received: from htat43p-no.corp.google.com (unknown [67.97.210.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51823258100; Tue, 24 Jul 2007 07:07:17 +0200 (CEST) Date: Tue, 24 Jul 2007 00:06:01 -0500 From: Harald Tveit Alvestrand To: Edward Lee , discuss@apps.ietf.org Subject: Re: Standardizing Firefox's Implementation of Link Fingerprints Message-ID: <5F9B1A4FEC49CCD7194121B7@[172.28.172.61]> In-Reply-To: References: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Why is this scheme better than an HTML extension ? --On 2. juli 2007 16:24 -0700 Edward Lee wrote: > For Firefox 3, there are patches [1] that implement Link Fingerprints, > which provide automatic resource verification for URIs that look like > http://site.com/file#hash(sha256:abc123) so that link providers can be > sure that end users download the exact file that the provider intended > (and not a trojaned download). > > The fragment identifier portion of the URI is used for backwards > compatibility with existing clients while allowing for extended usage > across protocols (e.g., http, ftp) and resource contexts (e.g., a > href, img src). Additionally, fragment identifiers are not sent as > part of a HTTP request, so the network and servers do not need to be > changed. With the backwards compatibility, incremental deployment is > feasible with some clients supporting Link Fingerprints, and end users > don't need to do anything unless there's a fingerprint failure. > > An initial draft to standardize Link Fingerprints is available online.. > > https://people.mozilla.com/~edilee/draft-lee-uri-linkfingerprints-00.txt > > Feedback is welcome about the design, syntax, supported hashes, > failure cases, etc. > > Ed > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=377245 > > > From discuss-bounces@apps.ietf.org Tue Jul 24 08:29:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJVX-0007Nw-Ot; Tue, 24 Jul 2007 08:28:55 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ICzT7-0007yh-NG for discuss-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 11:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzT7-0007yZ-DX for discuss@apps.ietf.org; Mon, 23 Jul 2007 11:05:05 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICzT6-0000EB-7i for discuss@apps.ietf.org; Mon, 23 Jul 2007 11:05:05 -0400 Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 750614F0FB; Mon, 23 Jul 2007 11:05:03 -0400 (EDT) Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66) (envelope-from ) id 1ICzT4-0003Cb-4D; Mon, 23 Jul 2007 17:05:02 +0200 Date: Mon, 23 Jul 2007 17:05:02 +0200 From: Thomas Roessler To: discuss@apps.ietf.org Subject: FYI: W3C Workshop on Next Steps for XML Signature and Encryption Message-ID: <20070723150502.GG17587@raktajino.does-not-exist.org> Mail-Followup-To: discuss@apps.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-07-04) X-Spam-Score: -0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Tue, 24 Jul 2007 08:28:54 -0400 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org FYI, W3C is planning to hold a workshop on next steps for XML Signature and Encryption on 25/26 September in Mountain View, California. We'd like to hear about experiences, requirements, and lessons learned from the existing specifications, and on next steps that the community might be interested in taking. Participants must submit position papers (1-5 pages) by 14 August. Call for participation: http://www.w3.org/2007/xmlsec/ws/cfp Slides from today's apparea meeting: http://www.w3.org/2007/xmlsec/tlr-ietf-chicago.pdf Regards, -- Thomas Roessler From discuss-bounces@apps.ietf.org Tue Jul 24 19:34:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTu2-0007ya-Mw; Tue, 24 Jul 2007 19:34:54 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IDTu2-0007yB-4C for discuss-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 19:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTu1-0007y3-Ps for discuss@apps.ietf.org; Tue, 24 Jul 2007 19:34:53 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDTu1-0005mQ-AE for discuss@apps.ietf.org; Tue, 24 Jul 2007 19:34:53 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6ONYpjv021009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Jul 2007 16:34:52 -0700 Received: from [130.129.20.116] (vpn-10-50-0-40.qualcomm.com [10.50.0.40]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6ONYoYd015474; Tue, 24 Jul 2007 16:34:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Tue, 24 Jul 2007 18:34:51 -0500 To: ietf@ietf.org, discuss@apps.ietf.org From: Ted Hardie Subject: Last Call comment: draft-rosenberg-sip-app-media-tag-01.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org During the discussion of this draft in today's sipping meeting, Jonathan's description of the document made me realize that the problem this describes is more general than the solution described. A broader solution that encompasses other potential uses of content negotiation seems to me in order. I would be willing to review and contribute to such a generalization. I've cc'ed this to the APPs discuss list, to see if there are others on that list who similarly believe that this problem is larger and the solution could be as well. I also encourage the APPs ADs to request review from APPs review team members with a background in content negotiation. regards, Ted Hardie From discuss-bounces@apps.ietf.org Wed Jul 25 10:50:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiBt-00087R-Os; Wed, 25 Jul 2007 10:50:17 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IDiBs-00087L-JI for discuss-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 10:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiBs-00087D-9Y for discuss@apps.ietf.org; Wed, 25 Jul 2007 10:50:16 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDiBq-0000dL-Ot for discuss@apps.ietf.org; Wed, 25 Jul 2007 10:50:16 -0400 Received: from [172.28.168.109] ([67.97.210.2]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6PEnZ5t006159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 07:49:37 -0700 Message-ID: <46A76314.4040103@dcrocker.net> Date: Wed, 25 Jul 2007 09:49:56 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Ted Hardie Subject: Re: Last Call comment: draft-rosenberg-sip-app-media-tag-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: discuss@apps.ietf.org, ietf@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ted Hardie wrote: > A broader solution that encompasses other potential > uses of content negotiation seems to me in order. Other than probably looking for an interaction mechanism, rather than one through email, does this have any relationship to: Content Negotiation for Messaging Services based on Email ? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Wed Jul 25 11:01:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiMU-0007f1-3K; Wed, 25 Jul 2007 11:01:14 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IDiMS-0007ei-4Y for discuss-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 11:01:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiMR-0007ea-R8 for discuss@apps.ietf.org; Wed, 25 Jul 2007 11:01:11 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDiMQ-0000pi-Cn for discuss@apps.ietf.org; Wed, 25 Jul 2007 11:01:11 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6PF18ph023309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jul 2007 08:01:09 -0700 Received: from [130.129.17.237] (vpn-10-50-16-124.qualcomm.com [10.50.16.124]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6PF16cw029640; Wed, 25 Jul 2007 08:01:07 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <46A76314.4040103@dcrocker.net> References: <46A76314.4040103@dcrocker.net> Date: Wed, 25 Jul 2007 10:01:09 -0500 To: dcrocker@bbiw.net From: Ted Hardie Subject: Re: Last Call comment: draft-rosenberg-sip-app-media-tag-01.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: discuss@apps.ietf.org, Dave Crocker , ietf@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 9:49 AM -0500 7/25/07, Dave Crocker wrote: >Ted Hardie wrote: >> A broader solution that encompasses other potential >>uses of content negotiation seems to me in order. > >Other than probably looking for an interaction mechanism, rather than one through email, does this have any relationship to: > > Content Negotiation for Messaging Services based on Email > ? > >d/ >-- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net The SIP preference/capabilities work broadly re-uses the CONNEG framework. This optimization treats a particular problem with "application" as a top-level type in the SIP context. Though there are application types in 3297 (application/pdf), using them in negotiation hits SIP in somewhat different ways. The question is whether generalizing the subtype content negotiation needed there would be useful for other content negotiation users. Ted From discuss-bounces@apps.ietf.org Wed Jul 25 11:14:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiZH-0008FX-Us; Wed, 25 Jul 2007 11:14:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IDiZG-0008Bm-MD for discuss-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 11:14:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiZG-0008Au-BM for discuss@apps.ietf.org; Wed, 25 Jul 2007 11:14:26 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDiZF-000143-Qa for discuss@apps.ietf.org; Wed, 25 Jul 2007 11:14:26 -0400 Received: from [172.28.168.109] ([67.97.210.2]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6PFDtaG011226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 08:13:56 -0700 Message-ID: <46A768C7.2090802@bbiw.net> Date: Wed, 25 Jul 2007 10:14:15 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Ted Hardie Subject: Re: Last Call comment: draft-rosenberg-sip-app-media-tag-01.txt References: <46A76314.4040103@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dcrocker@bbiw.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: discuss@apps.ietf.org, Dave Crocker , ietf@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ted Hardie wrote: > bbiw.net > > The SIP preference/capabilities work broadly re-uses the CONNEG framework. ack. > This optimization treats a particular problem with "application" as a top-level > type in the SIP context. Though there are application types in 3297 (application/pdf), > using them in negotiation hits SIP in somewhat different ways. The question is > whether generalizing the subtype content negotiation needed there would be > useful for other content negotiation users. At the risk of further showing that I haven't done enough homework, I'll nonetheless charge forward with another basic question: The draft seems to indicate that it's ok in some cases to indicate the ability to handle content based only on a top-level MIME type label. While it certainly can be ok to do that in some cases, it seems problematic to expect that to work. In other words, it seems less like the problem is adding the ability to specify sub-types under application, than to stop relying only on top-level. For example message/rfc822 vs. message/x400. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net