From apps-discuss-bounces@ietf.org Fri Aug 1 12:29:55 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930643A68B2; Fri, 1 Aug 2008 12:29:55 -0700 (PDT) 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 9D4ED3A68B2 for ; Fri, 1 Aug 2008 12:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 pzn-ruxnDk06 for ; Fri, 1 Aug 2008 12:25:16 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by core3.amsl.com (Postfix) with ESMTP id 639C33A6827 for ; Fri, 1 Aug 2008 12:25:15 -0700 (PDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KP0Fq-0006nj-7a for apps-discuss@ietf.org; Fri, 01 Aug 2008 19:25:34 +0000 Received: from 212.82.251.150 ([212.82.251.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2008 19:25:34 +0000 Received: from hmdmhdfmhdjmzdtjmzdtzktdkztdjz by 212.82.251.150 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2008 19:25:34 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: apps-discuss@ietf.org From: "Frank Ellermann" Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt Date: Fri, 1 Aug 2008 21:26:25 +0200 Organization: Lines: 95 Message-ID: References: <20080714184503.5761D28C158@core3.amsl.com><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <5DC27857-D46B-4446-A838-FCBE43A6AE6D@Isode.com> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.150 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Cc: ietf-sasl@imc.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Frank Ellermann List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Kurt Zeilenga wrote on the SASL list: > 1) revise the CRAM-MD5 specification, resolving known technical > issues, such that it is suitable for progression (eventually all > the way to Internet Standard) on the Standards Track, > 2) seek a waiver from the IESG of certain requirements placed upon > SASL mechanism specifications (such as RFC 4422 requirement that > mechanism specifications detail how character data inputs to > cryptographic functions be precisely specified to ensure > interoperability), or > 3) documenting existing CRAM-MD5 practice in an Informational > document, noting the known technical issues. > Consensus has been, and continued to be, that fixing known technical > issues would be too disruptive to existing deployments (which as you > note are quite significant). With this consensus, the third path > seems quite appropriate as seems to make no sense to progress a > document on the standard track that you wouldn't put on the standards > track if considered anew. Objection: There are various protocols such as SMTP and HTTP that would be not "put on the standards track if considered anew" as is, where they disagree with RFC 2277 and UTF-8. HTTP has a charming default Latin-1, while at it overriding MIME text/* in weird ways. This is a red herring. RFC 2026 demands maturity, IMO it does not ask "would you do this again exactly as is now, six years later ?". RFC 2195 uses an RFC 822 Message-ID as challenge, that is US-ASCII. If implementations do something that is not specified it is their problem. If they ignored RFC 2277 and didn't pick UTF-8 for their choice of "something" they also own the pieces of whatever breaks. Actually it is now eleven years later, but CRAM-MD5 drafts spent five years in SASL deliberations, that is no problem in RFC 2195. > given the WG consensus not to disruptive to deployments of > CRAM-MD5, the intent seems to be never to revise the > specification to met the requirements. [quoting the Charter] | This group will deliver revised Technical Specifications suitable for | consideration as Draft Standards for the following SASL mechanisms: | ANONYMOUS, PLAIN, CRAM-MD5, DIGEST-MD5, and EXTERNAL. This work will | be based upon RFC 2195, RFC 2222, RFC 2831, draft-zeilenga-sasl-anon, | draft-zeilenga-sasl-plain, draft-nerenberg-sasl-crammd5 and | draft-melnikov-rfc2831bis, and draft-myers-saslrev-xx.txt. CRAM-MD5 is about as simple as it can get, and as RFC 2195 does not mention what to do with the 8th bit the normal approach in RFC 2277 "let's take UTF-8" will work as expected. Limiting it to whatever other SASL mechanisms do (at the moment *in theory* SASLprep) is no issue, US-ASCII is a proper subset of SASLprep. In practice RFC 5198 might be a better approach, and once again US-ASCII is a proper subset of Net-UTF8 (NFC with minor twists). > It seems inappropriate to keep such a specification on the > standards track. 2026bis is fortunately no deliverable of the SASL WG, what it's supposed to deliver is a DS for CRAM-MD5. If the SASL WG does not more wish to do what it was chartered to do, or maybe never intended to do what it was chartered to do, the existing draft can be promoted outside of a WG (2821bis + 2822upd just pulled that, it is not impossible). After five years the draft has reached its own kind of maturity. I have implemented its i18n example four years ago. The draft is mentioned in a CRAM-MD5 implementation and interop report, now also some years old. In the request sent to IANA to fix the erroneous or intentional lie listing of CRAM-MD5 as "limited use" mechanism instead of "common" I've added a fresher reference. > Another challenge is that the RFC 2026 specifically warns > deployments of Proposed Standard specifications of the > likelihood that subsequent revision will be disruptive to > deployers Yes, if some implementation insists on say KOI8-R instead of an appropriate style of UTF-8 it owns the pieces, see above. This was not specified, above a broad hint at RFC 822, and there is no KOI8-R in RFC 822. > I do believe there are other requirements. I doubt it. CRAM-MD5 is at a similar level of complexity as PLAIN adding HMAC. Being better than "pseudo-PLAIN" (PLAIN outside of SSL), or APOP, or "LOGIN" is the whole purpose of CRAM-MD5. That CRAM-MD5 is also "better" than DIGEST-MD5 in a certain sense was no design goal, it just happened as side effect of KISS. Frank _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Mon Aug 11 19:52:55 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80493A6E8B; Mon, 11 Aug 2008 19:52:55 -0700 (PDT) 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 8C8143A67B6 for ; Mon, 11 Aug 2008 19:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.516, 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 hyVH4K3IX8+H for ; Mon, 11 Aug 2008 19:52:53 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 257FA3A6D5D for ; Mon, 11 Aug 2008 19:52:53 -0700 (PDT) Received: from [192.168.1.100] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 12 Aug 2008 03:52:47 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <960B0910-8FDA-4449-82C7-C8EC89FF80A7@Isode.com> From: Kurt Zeilenga To: "Frank Ellermann" In-Reply-To: Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt Date: Mon, 11 Aug 2008 19:52:44 -0700 References: <20080714184503.5761D28C158@core3.amsl.com><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <5DC27857-D46B-4446-A838-FCBE43A6AE6D@Isode.com> X-Mailer: Apple Mail (2.924) MIME-Version: 1.0 Cc: ietf-sasl@imc.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On 1 Aug 2008, at 12:26 PM, Frank Ellermann wrote: > This is a red herring. RFC 2026 demands maturity, IMO it does not > ask "would you do this again exactly as is now, six years later ?". I would argue that what RFC 2026 demands specifications which developers can independently produce interoperable implementations from. When I said "considered anew", I didn't mean "would we do this again exactly as we before". What I mean was that a document shouldn't get a bye from currently in place requirements simply because it was originally engineered before those requirements were in place. And while we do now have a "use UTF-8" requirement in IETF protocols, that doesn't necessarily mean that non-UTF-8 character data fields in fields should be respecified as carrying UTF-8 character data. There are other approaches for providing internationalization in existing protocols (such as taken in IDN), and then there is the approach of replacing the old protocol with a new protocol that has adequate internationalization. While my discussion above utilizes i18n issues, the I-Ds failure to met requirements placed upon it are not believed to be limited to i18n issues. > RFC 2195 uses an RFC 822 Message-ID as challenge, that is US-ASCII. > If implementations do something that is not specified it is their > problem. If they ignored RFC 2277 and didn't pick UTF-8 for their > choice of "something" they also own the pieces of whatever breaks. I see reason why an implementor of RFC 2195 would read RFC 2277, and if they did, why they would take its statements as imparting any requirement upon implementations of any protocol. RFC 2277 discussions requirements upon technical specifications produced by the IETF, not requirements upon implementors of IETF produced technical specifications. > Actually it is now eleven years later, but CRAM-MD5 drafts spent > five years in SASL deliberations, that is no problem in RFC 2195. I believe the WG consensus is that there are significant problems with RFC 2195. > >> It seems inappropriate to keep such a specification on the >> standards track. > > 2026bis is fortunately no deliverable of the SASL WG, what it's > supposed to deliver is a DS for CRAM-MD5. That's what it was chartered to delivered. The WG consensus seems not to attempt to met all the requirements for draft standard here. One could argue given this, the WG should simply abandon its work to date. However, it seems quite reasonable for the WG to offer what it has done to date for publication on the track it finds most suitable. -- Kurt _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Mon Aug 11 20:18:31 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D703A6E1C; Mon, 11 Aug 2008 20:18:31 -0700 (PDT) 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 B72CF3A6E1C for ; Mon, 11 Aug 2008 20:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.432, 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 DTXOPeySBOFg for ; Mon, 11 Aug 2008 20:18:30 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9D3493A6AF3 for ; Mon, 11 Aug 2008 20:18:29 -0700 (PDT) Received: from [192.168.1.100] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 12 Aug 2008 04:18:31 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <7A8C3E00-1ABB-4916-9DF5-F6E6258FA38E@Isode.com> From: Kurt Zeilenga To: Kurt Zeilenga In-Reply-To: <960B0910-8FDA-4449-82C7-C8EC89FF80A7@Isode.com> Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt Date: Mon, 11 Aug 2008 20:18:28 -0700 References: <20080714184503.5761D28C158@core3.amsl.com><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <5DC27857-D46B-4446-A838-FCBE43A6AE6D@Isode.com> <960B0910-8FDA-4449-82C7-C8EC89FF80A7@Isode.com> X-Mailer: Apple Mail (2.924) MIME-Version: 1.0 Cc: Frank Ellermann , ietf-sasl@imc.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On 11 Aug 2008, at 7:52 PM, Kurt Zeilenga wrote: >> >> RFC 2195 uses an RFC 822 Message-ID as challenge, that is US-ASCII. >> If implementations do something that is not specified it is their >> problem. If they ignored RFC 2277 and didn't pick UTF-8 for their >> choice of "something" they also own the pieces of whatever breaks. > > I see reason why an implementor of RFC 2195 would read RFC 2277, and > if they did, why they would take its statements as imparting any > requirement upon implementations of any protocol. RFC 2277 > discussions requirements upon technical specifications produced by > the IETF, not requirements upon implementors of IETF produced > technical specifications. s/see/see no/ Sorry, Kurt _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Aug 21 16:10:45 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793F63A695E; Thu, 21 Aug 2008 16:10:45 -0700 (PDT) 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 DD48D3A6AFC for ; Thu, 21 Aug 2008 16:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 K6cmdsJwAgQ0 for ; Thu, 21 Aug 2008 16:08:56 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:2e0:18ff:fe02:efec]) by core3.amsl.com (Postfix) with ESMTP id DE51E3A6AE5 for ; Thu, 21 Aug 2008 16:08:55 -0700 (PDT) Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7LN90Cd006104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Aug 2008 23:09:02 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: <1157928D-A2CB-4BE9-BD59-2E7E84578FE7@Isode.com> From: Kurt Zeilenga To: Russ Housley In-Reply-To: <20080805213633.90CBA3A67C1@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Proposed Experiment: More Meeting Time on Friday for IETF 73 Date: Thu, 21 Aug 2008 16:09:00 -0700 References: <20080717213322.6B3F63A68B0@core3.amsl.com> <019501c8ec0d$5d60e3e0$0600a8c0@china.huawei.com> <20080805213633.90CBA3A67C1@core3.amsl.com> X-Mailer: Apple Mail (2.928.1) Cc: discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Given http://www.ietf.org/meetings/73/ says: > IETF Meetings start Monday morning and run through Friday lunchtime, > with late scheduling changes. Newcomers' training and technical > tutorials take place the previous Sunday afternoon. Participants > should plan their travel accordingly. I assume this proposed experiment will not be taking place. -- Kurt _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Aug 31 22:51:13 2008 Return-Path: X-Original-To: apps-discuss-archive@ietf.org Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40D43A6978; Sun, 31 Aug 2008 22:51:13 -0700 (PDT) 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 E26D93A68EF for ; Sun, 31 Aug 2008 22:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=-0.310, 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 ssq6S8DYTJxy for ; Sun, 31 Aug 2008 22:51:12 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id C24863A67DD for ; Sun, 31 Aug 2008 22:51:12 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k22so1203614waf.20 for ; Sun, 31 Aug 2008 22:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=z9GeQUbKAgc5fEP9r66SROK0LabNXlI0h4WuytEbxZM=; b=BUMNsu1IjMDWbYdToktgiAE2JulCLeoCUk02Um+il157YAP1gG5qlP+WxDqXMaxq+r mOI7YVMkeudkEt7VJPEPDI9QMlG99cokKty/VHLSme26+CDfwHsGPtgVgoVbmCjcL84B UuQXqjfHpT2gS1CGbh2JK9ssXUAgVY4w/ULLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=EuwujxH53fd3W7rWrcgFwVtCxEyCfBwEbhiZdjwaeR2NsmNgBQmhb9N+QE+JJsyp/c 3azPcql//koVOB2fi+zyQ00VPimVamU1WLOJocVzlV8lFBhYqi8vdAYCQr77h8lo8FwO CUVMqaPONvttgHm9rlBYI0Ah5JLGgCbrRTtkc= Received: by 10.114.201.1 with SMTP id y1mr5011213waf.93.1220247863259; Sun, 31 Aug 2008 22:44:23 -0700 (PDT) Received: by 10.114.80.3 with HTTP; Sun, 31 Aug 2008 22:44:23 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2008 01:44:23 -0400 From: "Anthony Bryan" To: discuss@apps.ietf.org, apps-review@ietf.org, xml-dev@lists.xml.org, ietf-http-wg@w3.org Subject: Metalink XML Download Description Format (draft-bryan-metalink-01) MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Greetings, Here is the Internet Draft for Metalink, available at http://tools.ietf.org/html/draft-bryan-metalink-01 with interim revisions at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ . We're looking for review and public comments. Metalink is currently supported by some 35 applications and used by projects such as OpenOffice.org, openSUSE, Ubuntu, cURL, and others. Metalink is an XML-based document format that describes a file or lists of files to be added to a download queue. Lists are composed of a number of files, each with an extensible set of attached metadata. For example, each file can have a description, checksum, and list of URIs that it is available from. The primary use case that Metalink addresses is the description of downloadable content in a format so download agents can act intelligently and recover from common errors with little or no user interaction necessary. These errors can include multiple servers going down and data corrupted in transmission. Thank you, -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss