From apps-discuss-bounces@ietf.org Tue Sep 2 01:47:37 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 9DDE73A6BAF; Tue, 2 Sep 2008 01:47:37 -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 17A8E3A6BAF for ; Tue, 2 Sep 2008 01:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.077 X-Spam-Level: ** X-Spam-Status: No, score=2.077 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_34=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTGmYc3V73Pr for ; Tue, 2 Sep 2008 01:47:34 -0700 (PDT) Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by core3.amsl.com (Postfix) with ESMTP id 76E6B28C160 for ; Tue, 2 Sep 2008 01:46:25 -0700 (PDT) Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 2 Sep 2008 09:46:27 +0100 Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <9235.1220345185.781391@peirce.dave.cridland.net> Date: Tue, 02 Sep 2008 09:46:25 +0100 From: Dave Cridland To: Anthony Bryan Cc: general discussion of application-layer protocols , xml-dev@lists.xml.org, ietf-http-wg@w3.org, Applications Review List 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 On Mon Sep 1 06:44:23 2008, Anthony Bryan wrote: > 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. 1) I'm not mad keen on namespaces pointing to privately owned domain names. You have a different one in the examples as is specified in section 1.2, by the way. 2) The type attribute of the hash element ought to have values selected from the IANA registry of textual hash names; http://www.iana.org/assignments/hash-function-text-names/ - section 4.1.6.1 & 4.2.4.1. 3) Awesome: """ For convenience, this data format may be referred to as "Metalink 3.0". This specification uses "Metalink" internally. """ Yeah, so you use a longer, more formal name for *convenience*? And then in the specification itself, use a short-hand for, what, inconvenience? :-) 4) Notational convention defines a different convention than is used in the examples. 5) Section 2, "Metalink Documents MUST be well-formed XML." - and presumably "namespace well-formed", as specified in [XML-NAMES]? Or not? 6) Section 2: I'd personally kick out xml:base - I don't see it solving anything here. 7) Section 4.1.3.1: I'm deeply unconvinced about this "name" attribute actually containing a path - I don't see this being needed at all. A filename, sure. But otherwise, someone somewhere will inadvertantly allow /etc/passwd to be overwritten, or something equally hideous. Just ban '/'. 8) Section 4.1.4: "MUST contain one [good] and SHOULD contain more than one" - you mean if my download is only available from one location then this may provide a cause of poor interoperability? I don't think this is what you mean. I think you mean: "MUST contain at least one". 9) Section 4.2.3: I'm personally wary of doing this on two grounds. Firstly, people invariably use them for advertising, rather than debugging. Whilst not all marketing is, in fact, evil, I'm never truly keen on adding a bunch of octets for no good reason. Secondly, I'd live in perpetual fear that processors will change behaviour dependent on the agent's foibles. 10) Section 4.2.13: I had to read this twice to figure out it referred to a digital signature of the file to be downloaded. It might be as well to define a term for that in section 2, and use it throughout. I suspect the nice security people might have something to say about specifying PGP-only detatched signatures. 11) Section 4.2.17: Does that "type" attribute totally suck? Of course, you have to have it because every man, his dog, and his pet hampster has decided that only HTTP is allowed, these days, for absolutely everything, leading to a totally useless URI scheme which essentially fails to describe the actual resource it's supposedly a locator for. Okay, rant over, back to the review. 12) Section 4.2.17.1: Perhaps preference and weight? See SRV. 13) Section 4.2.17.2: Hang on, maybe this is a bit too far - I can see the need for type, sure, but I don't see the need to be able to specify "Use FTP to retrieve this HTTP URI", because that's just introducing a silly state. 14) Section 5 - I'd personally just ditch the entire thing, you effectively say all that's needed in Section 8.4. 15) I'm sure a lot of Section 6.1~6.3 could be summed up as "Ignore any markup you don't understand, whether from the metalink namespace or not." Of course, I'm not really an XML expert, so if this language is really needed, that's all fine and good. Hope this helps, somewhat. Feel free to ignore the bits you disagree with. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Tue Sep 2 02:35:17 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 DB05F3A6B87; Tue, 2 Sep 2008 02:35:17 -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 93C123A69B9 for ; Tue, 2 Sep 2008 02:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.747 X-Spam-Level: X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[AWL=-2.748, 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 K4agXgWoUkZB for ; Tue, 2 Sep 2008 02:35:15 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3ACA73A6BB3 for ; Tue, 2 Sep 2008 02:35:14 -0700 (PDT) Received: (qmail invoked by alias); 02 Sep 2008 09:35:19 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp045) with SMTP; 02 Sep 2008 11:35:19 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18kEItn4kskuIptqQbOxRRX5tCewa961UFh4Z8AXK mZwcPMA8yAqdNu Message-ID: <48BD08D5.1070206@gmx.de> Date: Tue, 02 Sep 2008 11:35:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Dave Cridland Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) References: <9235.1220345185.781391@peirce.dave.cridland.net> In-Reply-To: <9235.1220345185.781391@peirce.dave.cridland.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Cc: general discussion of application-layer protocols , xml-dev@lists.xml.org, ietf-http-wg@w3.org, Applications Review List 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 Dave Cridland wrote: > ... > 11) Section 4.2.17: Does that "type" attribute totally suck? Of course, > you have to have it because every man, his dog, and his pet hampster has > decided that only HTTP is allowed, these days, for absolutely > everything, leading to a totally useless URI scheme which essentially > fails to describe the actual resource it's supposedly a locator for. > Okay, rant over, back to the review. > ... "4.2.17. The "metalink:url" Element The "metalink:url" element contains the IRI of a file. All IRIs should lead to identical files, except in the case of type "bittorrent" where the IRI should lead to a .torrent file." Actually, don't do that. Don't make the meaning of an element totally dependent on an attribute on it. If torrent files are a special case (can there be more...?), then define a separate element. BR, Julian _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Tue Sep 2 13:59:56 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 D15A828C1A2; Tue, 2 Sep 2008 13:59:56 -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 B112C28C18A for ; Tue, 2 Sep 2008 13:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.797, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQr1sDUZBZuW for ; Tue, 2 Sep 2008 13:59:54 -0700 (PDT) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by core3.amsl.com (Postfix) with ESMTP id 3263428C171 for ; Tue, 2 Sep 2008 13:59:54 -0700 (PDT) Received: from gateout01.mbox.net (gwsmtp.usa.net [165.212.65.102]) by gateout01.mbox.net (Postfix) with ESMTP id 64C05CCE83; Tue, 2 Sep 2008 20:59:59 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.45S) with ESMTP id XID302miBu889701Xo1; Tue, 02 Sep 2008 20:59:59 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID302miBu889701Xo1 Received: from [10.1.1.130] ([157.22.41.236]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 14:59:55 -0600 Message-Id: From: Lisa Dusseault To: Lisa Dusseault's Chairs , Apps Discuss Subject: Lisa's Apps Area Acivity Report for July and August Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 2 Sep 2008 13:59:54 -0700 X-Mailer: Apple Mail (2.928.1) X-OriginalArrivalTime: 02 Sep 2008 20:59:55.0584 (UTC) FILETIME=[DA263400:01C90D3E] 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: multipart/mixed; boundary="===============1497855363==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1497855363== Content-Type: multipart/alternative; boundary=Apple-Mail-2--583657884 --Apple-Mail-2--583657884 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit News, updates This report covers July and August activity. Potential WGs: ALTO: the p2pi@ietf.org list is discussing charter text for a proposed WG called ALTO, for Application Layer Transport Optimization (I think). ESDS: esds@ietf.org list is discussing a second BOF on discovery services for arbitrary identifiers. Document Status and Progress Active Documents: my action - draft-irtf-asrg-dnsbl (Proposed Standard, aka PS): Publication Requested. Did AD review. Discussing issues with author. - draft-ietf-sieve-refuse-reject (PS): Last Call completed, so I need to put this on the agenda for IESG Evaluation. Stalled, in review, waiting on other: - draft-ietf-calsify-rfc2445bis (PS): Revised ID needed after AD evaluation - draft-ietf-calsify-rfc2446bis (PS): Revised ID needed after AD evaluation - draft-ietf-lemonade-msgevent (PS): Revised ID needed after IESG evaluation - draft-snell-atompub-bidi (PS): A couple changes needed after IESG Evaluation. - draft-ietf-sieve-notify-mailto (PS): Finished IETF Last Call, IANA has issues - draft-ietf-usefor-usepro (PS): In IETF Last Call. - draft-sanchez-webdav-current-principal (PS): Finished last Call. Now I'm waiting to hear back from authors on next steps. Finished Processing -- new in RFC Ed queue and new RFCs - draft-resnick-2822upd (Draft Standard): Now in RFC queue - draft-klensin-rfc2821bis (Draft Standard): Now in RFC queue. - draft-adolf-dvb-urn (Informational): Now in RFC queue - draft-ietf-eai-dsn (Experimental): Now in RFC queue - RFC 5293, PS "Sieve Email Filtering: Editheader Extension" - RFC 5260, PS "Sieve Email Filtering: Date and Index Extensions" - RFC 5279, Informational "A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)" WG Status CALSIFY: WG a little quiet over the summer. HTTPBIS: Met in Dublin. Discussing fun stuff like range unit extensions. New drafts issued Aug 29. IDNABIS: Met in Dublin. Discussing scope, rationale document and terminology SIEVE: Met in Dublin. Recharter just approved. USEFOR: Was given deadline to finish usepro document. --Apple-Mail-2--583657884 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

News, = updates

This report covers July and August = activity.

Potential WGs:
ALTO: = the p2pi@ietf.org list is = discussing charter text for a proposed WG called ALTO, for Application = Layer Transport Optimization (I think).
ESDS: esds@ietf.org list is discussing a = second BOF on discovery services for arbitrary = identifiers.

Document Status and = Progress

Active Documents: my action
 - draft-ietf-sieve-refuse-reject (PS): =  Last Call completed, so I need to put this on the agenda for IESG = Evaluation.

Stalled, = in review, waiting on other:
 - = draft-ietf-calsify-rfc2446bis (PS): Revised ID = needed after AD evaluation
 - = draft-ietf-sieve-notify-mailto (PS):  Finished IETF Last Call, IANA = has issues
 - draft-ietf-usefor-usepro = (PS): In IETF Last Call. 
 - = draft-sanchez-webdav-current-principal (PS): Finished last Call. Now I'm = waiting to hear back from authors on next steps.

Finished = Processing -- new in RFC Ed queue and new RFCs
 - draft-adolf-dvb-urn = (Informational): Now in RFC queue
 - RFC 5293, PS
= "Sieve Email Filtering: Editheader Extension"
"Sieve Email Filtering: Date and = Index Extensions"
 - RFC 5279, Informational
         "A Uniform = Resource Name (URN) Namespace
for the = 3rd Generation Partnership Project (3GPP)"
WG Status
  CALSIFY: WG a little quiet over the = summer.
  HTTPBIS:  Met = in Dublin.  Discussing fun stuff like range unit extensions. =  New drafts issued Aug 29.
  USEFOR:  Was = given deadline to finish usepro document.
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 83EEE3A6918; Tue, 2 Sep 2008 14:13:53 -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 84D9E3A687D for ; Tue, 2 Sep 2008 14:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=-2.602, 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 8UENRPwJHvB1 for ; Tue, 2 Sep 2008 14:13:51 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 47F9A3A6918 for ; Tue, 2 Sep 2008 14:13:50 -0700 (PDT) Received: (qmail invoked by alias); 02 Sep 2008 21:13:30 -0000 Received: from p508FE792.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.231.146] by mail.gmx.net (mp015) with SMTP; 02 Sep 2008 23:13:30 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19ad7I6IbJal1t4wfXR8oAxgUgHWvWe3PN5aq42Tg ZLnx2HIUEhJ4jU Message-ID: <48BDAC76.9040209@gmx.de> Date: Tue, 02 Sep 2008 23:13:26 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Brian Smith Subject: Re: XML namespace URIs for IETF specifications (was RE: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)) References: <9235.1220345185.781391@peirce.dave.cridland.net> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: 'Applications Review List' , xml-dev@lists.xml.org, 'general discussion of application-layer protocols' , ietf-http-wg@w3.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Brian Smith wrote: > Dave Cridland wrote: >> 1) I'm not mad keen on namespaces pointing to privately owned >> domain names. You have a different one in the examples as is >> specified in section 1.2, by the way. > > What namespace URI namespace should IETF specifications use? > urn:ietf:params:xml:ns:? > > http://tools.ietf.org/html/rfc3553 > http://tools.ietf.org/html/rfc3688 That's one possible choice. Another one is to keep using HTTP URIs, but to move them to a more neutral location (purl.org has been used in the past, so has www.w3.org). BR, Julian _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Tue Sep 2 16:37:41 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 A5F623A6B31; Tue, 2 Sep 2008 16:37:41 -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 2405B3A68E5 for ; Tue, 2 Sep 2008 16:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr6BQ0dSXUPF for ; Tue, 2 Sep 2008 16:37:38 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id DCC863A6A77 for ; Tue, 2 Sep 2008 16:36:22 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2596343wfc.22 for ; Tue, 02 Sep 2008 16:36:29 -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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HZ4b/rrfd1W0W0wDKWfEQ1YTNERZxSXwBk2iran1HP0=; b=cBQ7btCwTpa4N5+OzfPYWlMBaJF8J3hBnYgU2Z3OcWCtE1c8FivYE9s9BZhN9gr9qs 6yVdTMKJusIUXZ2b2wzGXF+vV3Y1fUcz+O29Ia5fUbZkIdvpS5pcysMgOAYjYJlpqG79 C3rfX9g2VjD+yI0E/ksBlCXhb7ud0Lz207wOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BfxF5jvjHk0tbQmRYKmvITciAtDIB8oBSyOalqQ4PS08Xs99xNfDyqDhybq+xfbB0/ uV+kqIF1Ttpd9vAMZyfvagpZr54kNE8FPhaOl/1mbxqoaebJVPYpFTibUiNnFcf9nY1h Zxb3YZ4LeZv31LK4k/d02lO+ExZGjI/XqU8us= Received: by 10.142.203.19 with SMTP id a19mr2761328wfg.179.1220398589517; Tue, 02 Sep 2008 16:36:29 -0700 (PDT) Received: by 10.142.246.18 with HTTP; Tue, 2 Sep 2008 16:36:29 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 19:36:29 -0400 From: "Anthony Bryan" To: "Dave Cridland" Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) In-Reply-To: <9235.1220345185.781391@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Disposition: inline References: <9235.1220345185.781391@peirce.dave.cridland.net> Cc: general discussion of application-layer protocols , xml-dev@lists.xml.org, ietf-http-wg@w3.org, Applications Review List 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 Dave, thank you for these comments! You caught some issues that needed to be addressed & that has improved this draft IMO. Changes are in SVN. On Tue, Sep 2, 2008 at 4:46 AM, Dave Cridland wrote: > On Mon Sep 1 06:44:23 2008, Anthony Bryan wrote: >> >> 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. > > 1) I'm not mad keen on namespaces pointing to privately owned domain names. > You have a different one in the examples as is specified in section 1.2, by > the way. I understand & feel the same thing. The draft didn't seem like the right place to put this, but I want the IETF to change the namespace to whatever is appropriate. I don't know if this is something that should be changed late or early in the process, that I change, or the RFC editor changes? The Atom namespace is "http://www.w3.org/2005/Atom". I don't know the history behind it, but it doesn't seem my place to suggest something like "http://www.w3.org/2008/Metalink" for Metalink. If that or something similar is correct, perfect! I do not want the namespace pointing to a domain name I own. More responsibility than I need. :) That was an error in the example, thanks for catching that! > 2) The type attribute of the hash element ought to have values selected from > the IANA registry of textual hash names; > http://www.iana.org/assignments/hash-function-text-names/ - section 4.1.6.1 > & 4.2.4.1. Wow, thank you so much! I didn't know about that. Should I list the same hash types, or just have this: The IANA registry named "Hash Function Textual Names" defines values for hash types. > 3) Awesome: > > """ > For convenience, this data format may be referred to as "Metalink > 3.0". This specification uses "Metalink" internally. > """ > > Yeah, so you use a longer, more formal name for *convenience*? And then in > the specification itself, use a short-hand for, what, inconvenience? :-) HAH! Glad you enjoyed that, an inside semi-joke :) Pretty ridiculous. I've changed it to: For convenience, this data format may be referred to as "Metalink", which this specification uses internally. > 4) Notational convention defines a different convention than is used in the > examples. The RELAX NG Compact schema doesn't match the rest of the spec? Or something else? I'm still working on that, & if anyone wants to help out please do because I don't have much experience. > 5) Section 2, "Metalink Documents MUST be well-formed > XML." - and presumably "namespace well-formed", as specified in > [XML-NAMES]? Or not? Yes. Is this something I need to add to the draft, or are you mentioning it because of internal inconsistencies in the examples? > 6) Section 2: I'd personally kick out xml:base - I don't see it solving > anything here. To be honest, most of the XML boilerplate, "Securing Metalink Documents", and "Extending Metalink" sections are stolen directly from the Atom RFC. xml:base hasn't been used in Metalink. Could it be useful? I found this blog about it http://feedblog.org/2005/12/05/xmlbase-was-a-bad-addition-to-atom/ > 7) Section 4.1.3.1: I'm deeply unconvinced about this "name" attribute > actually containing a path - I don't see this being needed at all. A > filename, sure. But otherwise, someone somewhere will inadvertantly allow > /etc/passwd to be overwritten, or something equally hideous. Just ban '/'. I think it's potentially useful to be able to create a sub-directory structure. For instance, this is done with jigdo or torrents. Clients have security holes, I agree, but they should be warned about the possibilities so they can be fixed. > 8) Section 4.1.4: "MUST contain one [good] and SHOULD contain more than one" > - you mean if my download is only available from one location then this may > provide a cause of poor interoperability? I don't think this is what you > mean. I think you mean: "MUST contain at least one". Exactly, that was an error. metalink:resources element MUST contain at least one metalink:url element and SHOULD contain more than one metalink:url elements. > 9) Section 4.2.3: I'm personally wary of doing this on two grounds. Firstly, > people invariably use them for advertising, rather than debugging. Whilst > not all marketing is, in fact, evil, I'm never truly keen on adding a bunch > of octets for no good reason. Secondly, I'd live in perpetual fear that > processors will change behaviour dependent on the agent's foibles. This is the same as the Atom RFC. Has this been a problem in the real world? (I don't know, just asking). > 10) Section 4.2.13: I had to read this twice to figure out it referred to a > digital signature of the file to be downloaded. It might be as well to > define a term for that in section 2, and use it throughout. I suspect the > nice security people might have something to say about specifying PGP-only > detatched signatures. Can you suggest wording that is more clear? I've changed it to: The "metalink:signature" element is a Text construct that conveys a digital signature for a file described in a Metalink Document. I hope some security people will have criticism (& additions) for this section. It describes how Metalink functions now, but we don't want to be PGP specific. I am not familiar enough with other options to write about it :) > 11) Section 4.2.17: Does that "type" attribute totally suck? Of course, you > have to have it because every man, his dog, and his pet hampster has decided > that only HTTP is allowed, these days, for absolutely everything, leading to > a totally useless URI scheme which essentially fails to describe the actual > resource it's supposedly a locator for. Okay, rant over, back to the review. Do you suggest removing the "type" attribute & having a new separate element as Julian suggested? > 12) Section 4.2.17.1: Perhaps preference and weight? See SRV. I'm not against that if others think that it is necessary/useful, but I haven't added it. > 13) Section 4.2.17.2: Hang on, maybe this is a bit too far - I can see the > need for type, sure, but I don't see the need to be able to specify "Use FTP > to retrieve this HTTP URI", because that's just introducing a silly state. > > 14) Section 5 - I'd personally just ditch the entire thing, you effectively > say all that's needed in Section 8.4. This is taken from the Atom RFC. If it needed to be there, does it need to be in this draft as well? > 15) I'm sure a lot of Section 6.1~6.3 could be summed up as "Ignore any > markup you don't understand, whether from the metalink namespace or not." Of > course, I'm not really an XML expert, so if this language is really needed, > that's all fine and good. Same as above. I'm not an XML expert either, so I'll defer to others. :) > Hope this helps, somewhat. Feel free to ignore the bits you disagree with. It helps a lot! Very nice of you to take the time to offer a helpful critique! -- (( 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 From apps-discuss-bounces@ietf.org Tue Sep 2 16:41:42 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 2A43D3A6A59; Tue, 2 Sep 2008 16:41:42 -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 9C8283A6857 for ; Tue, 2 Sep 2008 16:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 3xTdeIHInOhq for ; Tue, 2 Sep 2008 16:41:39 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 0E1C73A6A0A for ; Tue, 2 Sep 2008 16:41:19 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2597964wfc.22 for ; Tue, 02 Sep 2008 16:41:25 -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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=h9i621BWYkakIQIp3b0jr0Rqr7ZEQSnY2FR90K01xC4=; b=Tpg2wn+vvQ/pd/VSl+IRXT4Eh/BL4IztO5gzeagYAcjNJHod+kHHyDfxKDzpQj47yF zvl74uoR14nJq/eSPtt5SC8tLS1acVA3f8IsVudvDYPJ+Fdm1Gf8zIZn3DE/UdgWf55e NsWMDpEx0METrTs4kHmmpek1mrHL0gPEoVPkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=NDRPCGPgl2zUMf90hXsIYfKL4nCKuOtcFs1fuiosK+Qc/cXhO2LYdwEcugtq5re7UO LZpLPTDTmS2ld/2/dScGR+PW2UAHpaRvAoooS/Ry7fNjxeZlSN5vj3sOSaRSJgVfkHQs 5XK+xHaVozo46mgx+FPhDiW7Be85gI7gkDkAM= Received: by 10.142.188.4 with SMTP id l4mr2764742wff.183.1220398885831; Tue, 02 Sep 2008 16:41:25 -0700 (PDT) Received: by 10.142.246.18 with HTTP; Tue, 2 Sep 2008 16:41:25 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 19:41:25 -0400 From: "Anthony Bryan" To: "Julian Reschke" Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) In-Reply-To: <48BD08D5.1070206@gmx.de> MIME-Version: 1.0 Content-Disposition: inline References: <9235.1220345185.781391@peirce.dave.cridland.net> <48BD08D5.1070206@gmx.de> Cc: general discussion of application-layer protocols , xml-dev@lists.xml.org, Applications Review List , ietf-http-wg@w3.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Tue, Sep 2, 2008 at 5:35 AM, Julian Reschke wrote: > Dave Cridland wrote: >> >> ... >> 11) Section 4.2.17: Does that "type" attribute totally suck? Of course, >> you have to have it because every man, his dog, and his pet hampster has >> decided that only HTTP is allowed, these days, for absolutely everything, >> leading to a totally useless URI scheme which essentially fails to describe >> the actual resource it's supposedly a locator for. Okay, rant over, back to >> the review. >> ... > > "4.2.17. The "metalink:url" Element > > > The "metalink:url" element contains the IRI of a file. All IRIs > should lead to identical files, except in the case of type > "bittorrent" where the IRI should lead to a .torrent file." > > Actually, don't do that. Don't make the meaning of an element totally > dependent on an attribute on it. If torrent files are a special case (can > there be more...?), then define a separate element. I'm sure there COULD be more, but I don't know of any other right now. Do you suggest a torrent specific element, or something generic? Thanks Julian. -- (( 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 From apps-discuss-bounces@ietf.org Tue Sep 2 17:05:07 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 9552F28C1F1; Tue, 2 Sep 2008 17:05:07 -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 E5B7C3A6B34 for ; Tue, 2 Sep 2008 17:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_83=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPhPonEgZf5i for ; Tue, 2 Sep 2008 17:05:05 -0700 (PDT) Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by core3.amsl.com (Postfix) with ESMTP id 712713A6BAE for ; Tue, 2 Sep 2008 17:05:05 -0700 (PDT) Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Wed, 3 Sep 2008 01:05:03 +0100 Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) References: <9235.1220345185.781391@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <9235.1220400302.213551@peirce.dave.cridland.net> Date: Wed, 03 Sep 2008 01:05:02 +0100 From: Dave Cridland To: Anthony Bryan Cc: general discussion of application-layer protocols , xml-dev@lists.xml.org, ietf-http-wg@w3.org, Applications Review List 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 On Wed Sep 3 00:36:29 2008, Anthony Bryan wrote: > > 2) The type attribute of the hash element ought to have values > selected from > > the IANA registry of textual hash names; > > http://www.iana.org/assignments/hash-function-text-names/ - > section 4.1.6.1 > > & 4.2.4.1. > > Wow, thank you so much! I didn't know about that. Should I list the > same hash types, or just have this: > > The IANA registry named "Hash Function Textual Names" defines > values > for hash types. > > The latter - just point to the registry. > > 4) Notational convention defines a different convention than is > used in the > > examples. > > The RELAX NG Compact schema doesn't match the rest of the spec? Or > something else? I'm still working on that, & if anyone wants to help > out please do because I don't have much experience. > > No, your conventions state you'll use a prefix of "metalink", but your examples don't. There might have been something else, I forget now. > > 5) Section 2, "Metalink Documents MUST be well-formed > > XML." - and presumably "namespace well-formed", as specified in > > [XML-NAMES]? Or not? > > Yes. > Is this something I need to add to the draft, or are you mentioning > it > because of internal inconsistencies in the examples? > > No inconsistency, I simply thought that might be what you meant. > > 8) Section 4.1.4: "MUST contain one [good] and SHOULD contain > more than one" > > - you mean if my download is only available from one location > then this may > > provide a cause of poor interoperability? I don't think this is > what you > > mean. I think you mean: "MUST contain at least one". > > Exactly, that was an error. > > metalink:resources element MUST contain at least one > metalink:url > element and SHOULD contain more than one metalink:url > elements. > > No, not what I meant. That "SHOULD" is wrong - it can be a "MAY", but "SHOULD" has a particular meaning - it means that if you only list one URL here, you risk an interop failure. RFC 2119 is an addictive drug, but like most strong medicine, best used sparingly. I suspect what you want to write is: The metalink:resources element MUST contain at least one metalink:url element. Typically, such elements contain more than one metalink:url element to provide multiple download sources. > > 10) Section 4.2.13: I had to read this twice to figure out it > referred to a > > digital signature of the file to be downloaded. It might be as > well to > > define a term for that in section 2, and use it throughout. I > suspect the > > nice security people might have something to say about specifying > PGP-only > > detatched signatures. > > Can you suggest wording that is more clear? I've changed it to: > > The "metalink:signature" element is a Text construct that > conveys a > digital signature for a file described in a Metalink Document. > > Much more obvious. > I hope some security people will have criticism (& additions) for > this > section. It describes how Metalink functions now, but we don't want > to > be PGP specific. I am not familiar enough with other options to > write > about it :) > > I'm sure the security people will chip in. > Do you suggest removing the "type" attribute & having a new separate > element as Julian suggested? > > Julian knows a lot more about XML than I do, I'd go along with what he says. > > 12) Section 4.2.17.1: Perhaps preference and weight? See SRV. > > I'm not against that if others think that it is necessary/useful, > but > I haven't added it. > > Might be worth discussing, at least - I've actually no opinion on the subject, I just note that SRV, for one, opted for both, presumably based on experience with MX. > > 14) Section 5 - I'd personally just ditch the entire thing, you > effectively > > say all that's needed in Section 8.4. > > This is taken from the Atom RFC. If it needed to be there, does it > need to be in this draft as well? > > I'm not convinced it needs to be there either. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Tue Sep 2 19:25:44 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 5D23E28C170; Tue, 2 Sep 2008 19:25:44 -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 9A29328C170 for ; Tue, 2 Sep 2008 19:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Midt8I7hmdqC for ; Tue, 2 Sep 2008 19:25:42 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 77D0A28C103 for ; Tue, 2 Sep 2008 19:25:42 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2652065wfc.22 for ; Tue, 02 Sep 2008 19:25:46 -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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=48UVPEu378Ke0+zG9HXznI2MudyQ3DEqCXwsfy9W3p8=; b=DKOv7Bpt0K5mGNFvL6IGjHQod/ojbAmQDapE3OQhNlmtEbzZWIcXQauI+UyVJlZsr+ Ujm76Y38lUVgkiNsc82TacU/nMa1zNIyv1dyxGTf+V8nfnvC2+zmcv31vnspRbWUwuZC BenK81JTZeJr/gYJ6JprXJxUIbRUL2p8nx2Fw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=H+ElJh7x3W6ED4EKtN1f+imD/rRSBsaFOup13qpACyicu4ZGtdsAhmP10quVNpTne1 dVr+aSBBGRETYlmYwSUUVOh4IsW70erisQgAwwIMi0b1RbpTHcAu+dYAMjJ6ja2qk0DV E8iMBQf4NvHpM+1LBJDIQnJxI/fUROr2mu+BM= Received: by 10.143.42.3 with SMTP id u3mr2815693wfj.148.1220408745915; Tue, 02 Sep 2008 19:25:45 -0700 (PDT) Received: by 10.142.246.18 with HTTP; Tue, 2 Sep 2008 19:25:45 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 22:25:45 -0400 From: "Anthony Bryan" To: "Dave Cridland" Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) In-Reply-To: <9235.1220400302.213551@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Disposition: inline References: <9235.1220345185.781391@peirce.dave.cridland.net> <9235.1220400302.213551@peirce.dave.cridland.net> Cc: general discussion of application-layer protocols , xml-dev@lists.xml.org, ietf-http-wg@w3.org, Applications Review List 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 On Tue, Sep 2, 2008 at 8:05 PM, Dave Cridland wrote: > On Wed Sep 3 00:36:29 2008, Anthony Bryan wrote: >> >> > 2) The type attribute of the hash element ought to have values selected >> > from >> > the IANA registry of textual hash names; >> > http://www.iana.org/assignments/hash-function-text-names/ - section >> > 4.1.6.1 >> > & 4.2.4.1. >> >> Wow, thank you so much! I didn't know about that. Should I list the >> same hash types, or just have this: >> >> The IANA registry named "Hash Function Textual Names" defines values >> for hash types. >> >> > The latter - just point to the registry. Done. Thanks again, that seems to mesh well. I've changed the schema to just metalinkTextConstruct instead of the individual hash types too. >> > 4) Notational convention defines a different convention than is used in >> > the >> > examples. >> >> The RELAX NG Compact schema doesn't match the rest of the spec? Or >> something else? I'm still working on that, & if anyone wants to help >> out please do because I don't have much experience. >> >> > No, your conventions state you'll use a prefix of "metalink", but your > examples don't. There might have been something else, I forget now. I see, the schema at the end. I've fixed it. >> > 5) Section 2, "Metalink Documents MUST be well-formed >> > XML." - and presumably "namespace well-formed", as specified in >> > [XML-NAMES]? Or not? >> >> Yes. >> Is this something I need to add to the draft, or are you mentioning it >> because of internal inconsistencies in the examples? >> >> > No inconsistency, I simply thought that might be what you meant. I'm just asking if this is something that needs to be added, since it copies the Atom RFC text. Isn't it at least somewhat implied? I don't know enough here, so your (or others) input is appreciated. >> > 8) Section 4.1.4: "MUST contain one [good] and SHOULD contain more than >> > one" >> > - you mean if my download is only available from one location then this >> > may >> > provide a cause of poor interoperability? I don't think this is what you >> > mean. I think you mean: "MUST contain at least one". >> >> Exactly, that was an error. >> >> metalink:resources element MUST contain at least one metalink:url >> element and SHOULD contain more than one metalink:url elements. >> >> > No, not what I meant. That "SHOULD" is wrong - it can be a "MAY", but > "SHOULD" has a particular meaning - it means that if you only list one URL > here, you risk an interop failure. > > RFC 2119 is an addictive drug, but like most strong medicine, best used > sparingly. > > I suspect what you want to write is: > > The metalink:resources element MUST contain at least one metalink:url > element. Typically, such elements contain more than one metalink:url element > to provide multiple download sources. Yes, changed. >> > 10) Section 4.2.13: I had to read this twice to figure out it referred >> > to a >> > digital signature of the file to be downloaded. It might be as well to >> > define a term for that in section 2, and use it throughout. I suspect >> > the >> > nice security people might have something to say about specifying >> > PGP-only >> > detatched signatures. >> >> Can you suggest wording that is more clear? I've changed it to: >> >> The "metalink:signature" element is a Text construct that conveys a >> digital signature for a file described in a Metalink Document. >> >> > Much more obvious. Great. >> I hope some security people will have criticism (& additions) for this >> section. It describes how Metalink functions now, but we don't want to >> be PGP specific. I am not familiar enough with other options to write >> about it :) >> >> > I'm sure the security people will chip in. Looking forward to it. >> Do you suggest removing the "type" attribute & having a new separate >> element as Julian suggested? >> >> > Julian knows a lot more about XML than I do, I'd go along with what he says. Will do. >> > 12) Section 4.2.17.1: Perhaps preference and weight? See SRV. >> >> I'm not against that if others think that it is necessary/useful, but >> I haven't added it. >> >> > Might be worth discussing, at least - I've actually no opinion on the > subject, I just note that SRV, for one, opted for both, presumably based on > experience with MX. Good to have the input. >> > 14) Section 5 - I'd personally just ditch the entire thing, you >> > effectively >> > say all that's needed in Section 8.4. >> >> This is taken from the Atom RFC. If it needed to be there, does it >> need to be in this draft as well? >> >> > I'm not convinced it needs to be there either. I'll be conservative and leave it for now, depending on comments from others. Updated version at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ -- (( 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 From apps-discuss-bounces@ietf.org Tue Sep 2 22:35:00 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 E456A3A6BDA; Tue, 2 Sep 2008 22:35:00 -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 7B2E53A6BDA for ; Tue, 2 Sep 2008 22:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.798 X-Spam-Level: ** X-Spam-Status: No, score=2.798 tagged_above=-999 required=5 tests=[AWL=1.134, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=3.196, 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 TFZoWC6VzwIA for ; Tue, 2 Sep 2008 22:34:59 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by core3.amsl.com (Postfix) with ESMTP id 6E0F43A6B9D for ; Tue, 2 Sep 2008 22:34:58 -0700 (PDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Kal1D-0007hT-1B for apps-discuss@ietf.org; Wed, 03 Sep 2008 05:35:03 +0000 Received: from 212.82.251.162 ([212.82.251.162]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Sep 2008 05:35:03 +0000 Received: from hmdmhdfmhdjmzdtjmzdtzktdkztdjz by 212.82.251.162 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Sep 2008 05:35:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: apps-discuss@ietf.org From: "Frank Ellermann" Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format(draft-bryan-metalink-01) Date: Wed, 3 Sep 2008 07:37:09 +0200 Organization: Lines: 42 Message-ID: References: <9235.1220345185.781391@peirce.dave.cridland.net> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.162 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1933 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 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 Anthony Bryan wrote: > The Atom namespace is "http://www.w3.org/2005/Atom". I don't know > the history behind it, but it doesn't seem my place to suggest > something like "http://www.w3.org/2008/Metalink" for Metalink. > If that or something similar is correct, perfect! > I do not want the namespace pointing to a domain name I own. > More responsibility than I need. :) Please correct me if I'm wrong: Technically I think all that is required from a namespace is that it is a stable worldwide unique identifier. Tools have no business to ever look into the URL, if it is an URL. The IANA IETF URN example in another aricle is no URL, and there is no resolver. Tools either know and support a namespace, or they don't. From that point of view you could mint your own tag: URI and be done with it. BUT sometimes human users want to learn what an obscure namespace is about. For that purpose tag: URIs or IANA IETF URNs are less desirable, and a working http (or similar) URI would be better. IMO you should be able to use a stable URI for the (future) RFC as namespace. You could pick say (when RFC-editor fixes xxxx). If that's not okay I'd be curious why it's not okay. Just in case: http://purl.org/net/rfc/xxxx would redirect to the same rfc-editor.org URI, but it would be not the same namespace (net != org). Stability issue: These PURL redirections need maintainers. At the moment there are only three maintainers of net/rfc/xxxx, so if the RFC editor changes their URL in wild and wonderful ways *AND* these three maintainers are dead the redirection cannot be fixed without intervention of the PURL admins. OTOH human uses might figure out what .../net/rfc/xxxx is without the help of PURL. That is also important if PURL ever stops it services. IMHO you could also try , the stability and usability tradeoffs are slightly different. Frank _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Wed Sep 3 02:18:00 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 5D0C73A6C6E; Wed, 3 Sep 2008 02:18:00 -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 81BBB3A6C6E for ; Wed, 3 Sep 2008 02:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.059 X-Spam-Level: X-Spam-Status: No, score=-4.059 tagged_above=-999 required=5 tests=[AWL=-1.460, 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 ZGvC4GkYLGm1 for ; Wed, 3 Sep 2008 02:17:58 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 41A133A6C3F for ; Wed, 3 Sep 2008 02:17:57 -0700 (PDT) Received: (qmail invoked by alias); 03 Sep 2008 09:18:04 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp042) with SMTP; 03 Sep 2008 11:18:04 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18SvOchm/sSAIqEH9LBDbEFbGqFzFzr1aW/YFagWY 0EeNNf8CpB/CfA Message-ID: <48BE5645.70302@gmx.de> Date: Wed, 03 Sep 2008 11:17:57 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Anthony Bryan Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) References: <9235.1220345185.781391@peirce.dave.cridland.net> <48BD08D5.1070206@gmx.de> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Cc: general discussion of application-layer protocols , xml-dev@lists.xml.org, Applications Review List , ietf-http-wg@w3.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Anthony Bryan wrote: > On Tue, Sep 2, 2008 at 5:35 AM, Julian Reschke wrote: >> Dave Cridland wrote: >>> ... >>> 11) Section 4.2.17: Does that "type" attribute totally suck? Of course, >>> you have to have it because every man, his dog, and his pet hampster has >>> decided that only HTTP is allowed, these days, for absolutely everything, >>> leading to a totally useless URI scheme which essentially fails to describe >>> the actual resource it's supposedly a locator for. Okay, rant over, back to >>> the review. >>> ... >> "4.2.17. The "metalink:url" Element >> >> >> The "metalink:url" element contains the IRI of a file. All IRIs >> should lead to identical files, except in the case of type >> "bittorrent" where the IRI should lead to a .torrent file." >> >> Actually, don't do that. Don't make the meaning of an element totally >> dependent on an attribute on it. If torrent files are a special case (can >> there be more...?), then define a separate element. > > I'm sure there COULD be more, but I don't know of any other right now. > > Do you suggest a torrent specific element, or something generic? If it could be phrased as something more generic, and then state the current use case for torrent files, that probably would be best. So, in general, this would be for IRIs that do not identify a resource to download, but metadata about a resource to download? Strictly speaking, isn't metalink not yet another format for that? BR, Julian _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Wed Sep 3 05:50:26 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 9152D3A6A1D; Wed, 3 Sep 2008 05:50:26 -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 123683A6A1D for ; Wed, 3 Sep 2008 05:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRiiVDKS-yH7 for ; Wed, 3 Sep 2008 05:50:24 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 52BCD3A6A18 for ; Wed, 3 Sep 2008 05:50:21 -0700 (PDT) Received: from dialup-4.227.197.6.Dial1.Denver1.Level3.net (dialup-4.227.197.6.Dial1.Denver1.Level3.net [4.227.197.6]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 14BBD400BF; Wed, 3 Sep 2008 06:47:03 -0600 (MDT) Message-ID: <48BE880A.7060009@stpeter.im> Date: Wed, 03 Sep 2008 06:50:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.16) Gecko/20080707 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format(draft-bryan-metalink-01) References: <9235.1220345185.781391@peirce.dave.cridland.net> In-Reply-To: Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0742222593==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0742222593== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010106070401000807030105" This is a cryptographically signed message in MIME format. --------------ms010106070401000807030105 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > Tools either know and support a namespace, or they don't. From > that point of view you could mint your own tag: URI and be done > with it. BUT sometimes human users want to learn what an obscure > namespace is about. For that purpose tag: URIs or IANA IETF URNs > are less desirable, and a working http (or similar) URI would be > better. Why? If you come upon an unknown namespace that's an http: URI, you copy it into the address bar of your favorite browser; probably the resulting page has the information you need. One step. If you come upon an unknown namespace that's a URN, you copy it into the search bar of your favorite browser and get some search results; probably the top hit has the information you need. Two steps. I don't see a huge difference between one step and two steps for those curious human users (probably developers) who on occasion want to learn what an obscure namespace is about. Peter --------------ms010106070401000807030105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWZDCC BzswggYjoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wODA3MDIyMDQzMThaFw0wOTA3MDIyMDQzMThaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDBemNDejWS/iB/hQVbp2Gd5eYWYb+z1RSPbY4RQHW/apL4auhig1FhCOrN+eN+32iYp3tm K0kv/Rrhae9UzjFMzxc3QBcuj+H6kRudhawlrjeXMX7er9sqSIO0pDlaFvs7Kq0Lz7FFZL4e whqdPfK5MROPp1ucUtI5mMkYE2y6Sll04UKoCWVK4bLsTkJGMp0lnpNRG2LaMKjZldJYe7ci bkcTsnVPF4H4SVgwQbwkfw/wSS+HzOjtng3Nzz4z572WIMCwwJnfCVDJMXpdvssejkOaVl1/ +Ewqt80sjae67rD28v8sPAs7si+JIL5SYYqCw4djCSYfeMHO7R0qox3fAgMBAAGjggNuMIID ajAMBgNVHRMEBTADAgEAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwHQYDVR0OBBYEFFObPTX8kvCsGgtLWvPiSviKgJ51MIGoBgNVHSMEgaAwgZ2AFHuJ nJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEPMIIBRwYDVR0g BIIBPjCCATowggE2BgsrBgEEAYG1NwEBBTCCASUwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUFBwICMIGvMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBv bGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBj BgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3Js MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJNQdIoQBoFf8UslzTDD7ue89LppTEBJ w5Za9ddTSfI8MEdomLK52FfLPu1JWWlzDZrwV/MHqTNqBHeXrjUxqnrERmKIXVZpIO7tEJia cIGO2LYJoCMzXxOpIcAv2H9gVlAE0ibx3gOJ6XQGz7WUdOKouWUMf9aj1SCFJOChHTe6vSPl rPjbJufQG7mwjpTrkwUos1/rznZWDCGCTUVLWiMN5XNzg8SMOurICxPborHlERiiX/ilwmL6 JBanoCQcyL45L40cFFF923FOWCXCHY0XAj/7MmVWpMl83tNRnXaYtukNJwM2C3rSEo3GTClU IjB/0feH/9uWyMGPcF8WTxcwggc7MIIGI6ADAgECAgEpMA0GCSqGSIb3DQEBBQUAMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMDgwNzAyMjA0MzE4WhcNMDkwNzAy MjA0MzE4WjCBwjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZE ZW52ZXIxIjAgBgNVBAoTGVhNUFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0 YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWlu dC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXpjQ3o1kv4gf4UFW6dhneXmFmG/s9UUj22OEUB1v2qS +GroYoNRYQjqzfnjft9omKd7ZitJL/0a4WnvVM4xTM8XN0AXLo/h+pEbnYWsJa43lzF+3q/b KkiDtKQ5Whb7OyqtC8+xRWS+HsIanT3yuTETj6dbnFLSOZjJGBNsukpZdOFCqAllSuGy7E5C RjKdJZ6TURti2jCo2ZXSWHu3Im5HE7J1TxeB+ElYMEG8JH8P8Ekvh8zo7Z4Nzc8+M+e9liDA sMCZ3wlQyTF6Xb7LHo5DmlZdf/hMKrfNLI2nuu6w9vL/LDwLO7IviSC+UmGKgsOHYwkmH3jB zu0dKqMd3wIDAQABo4IDbjCCA2owDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRTmz01/JLwrBoLS1rz4kr4ioCe dTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAQUwggElMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIB FihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8BggrBgEFBQcC AjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0 aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0 dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Au c3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCTUHSK EAaBX/FLJc0ww+7nvPS6aUxAScOWWvXXU0nyPDBHaJiyudhXyz7tSVlpcw2a8FfzB6kzagR3 l641Map6xEZiiF1WaSDu7RCYmnCBjti2CaAjM18TqSHAL9h/YFZQBNIm8d4Diel0Bs+1lHTi qLllDH/Wo9UghSTgoR03ur0j5az42ybn0Bu5sI6U65MFKLNf6852Vgwhgk1FS1ojDeVzc4PE jDrqyAsT26Kx5REYol/4pcJi+iQWp6AkHMi+OS+NHBRRfdtxTlglwh2NFwI/+zJlVqTJfN7T UZ12mLbpDScDNgt60hKNxkwpVCIwf9H3h//blsjBj3BfFk8XMIIH4jCCBcqgAwIBAgIBDzAN BgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMzMyWhcNMTIx MDIyMjEwMzMyWjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuaNJbhI+IMqUCKe9V4tk5V8i2K4/VpEcvnfQTtBR z2JwLAvff48f4mzUcCHwKBYWXfiw7HHUUnJL8LhUs9GyoN8/vaO3MJVQAvQMDFnvCDNC8XPv HrWMbF+FiGphvX4884uRgFuREis8yDd0sR0qZchglhcMf6YH9X+Mujvf8pvuH+s2g2D+gcdK /kmiXK+nkhjZu19xMF9b+16UQWPmsNNfaO5O9ndCF/ddBflxrdDsDXTOtRX9xYk4nsXlGW1s QhpuhmZfkkFRvcWFSIB0Gi16EBfoNsM65igm1XGYah/oa5UZw+j3wrhMl/wUej5QD0Q5UOn9 bt8KopPixeT9eQIDAQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYD VR0OBBYEFHuJnJKXJKGERwLLdPwu9KzcMuXzMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mH MMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYB BQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5j cnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNy bC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENv bW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVh ZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0E QxZBU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFp bCBDZXJ0aWZpY2F0ZXMwDQYJKoZIhvcNAQEFBQADggIBAFKXBA3bChUQsRQcXEpvvKDE036U u322ZMVh8eXxw47wIGgUPqGNLZOMbWw+lcXh2I8SOt/oY/IyAp6nlVz3t+Abvl83pCJ9k5a5 zwkKGynUBdqedkIFLyMUlEXndI3AWggVdtg0imlKgzsw/08elUMu/M6W5V40R+zgCxP/h48y VZrKXZwVFLUDi2ID6PduMZMUduVQ3YLRBObwF2v4NqAnmYctGRDuDW4CGsgGAiXCUQ89IXQ9 gIXnOuSsOiwdze1VxI4kUef1qCsB/0LXkczyWxQ3NbKJqwKY5tnMoPuZ25tUR3hSM/hsV5bk az87b4TXG8tD7QI6sGNbcYuLFtEemST7mdg2df3c3JKBYcmYBcjl90hJDV1S5XY0853hSRZ1 Usw23O9tL6tfOI0e6WKCPfn+UCfemtIi8RABvEieWrgcFyP8NhZipsJnTLyfP9e/geLDAiEa 16w0Jdsc6VV4f0HJpOZ3/sPBxZqgExstTlAEG14GuwMkgFGmIb7xZOdLtGzuQ4lBsM6yTt06 8L2gthIuBBWgZiFYBu031OU2mmPSHCUgkOwBlGBN0RUkabCzqANw7MT+NmBEYEvzccNvfmKm bT6DtkD2zaSO8Zx1QnzQWm8d6AyH+N/JxX7/LKcOQUKgUmxBdYsyQOe3hOuAsx57e5QdtDhQ 9dWr2KKcMYIDvTCCA7kCAQEwgZIwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD QQIBKTAJBgUrDgMCGgUAoIIB/zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wODA5MDMxMjUwMThaMCMGCSqGSIb3DQEJBDEWBBThM4JpY6MlV3CIuXOgmNxe Xe0V/TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEADUb3dc1e7Qz9WXsrp418EwvVKiGAORF6VoeDjtZam9a/92M9hvU53uLXXWjy 7PrKEGzVEM4yfocTL2wlD2VuQGxJsyW1Stub8/7+J1J0piUisWEk9LEn8yiEYAXWBuK4Wp3I n87booFIJgvwBXxb18Mlcl3u4SfQuJOANKmfJZC/5HxqTj+m6RpbHpbW9PEEQ0OTvexz5DJ9 bIiPMIlX7VZHpTnI+wr1XQYERKWjDDVeOQZWDz27eEF/AgpCCAcMjFlXVmxYeJSlzfC9tAk4 Vh5IhNq4D8QONZAuvWdQwb6aSNV1O45R/hygj/5NW5UyLaYM/TUI3jOukWL2w6oHBgAAAAAA AA== --------------ms010106070401000807030105-- --===============0742222593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0742222593==-- From apps-discuss-bounces@ietf.org Wed Sep 3 06:12:28 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 F22603A6A18; Wed, 3 Sep 2008 06:12:27 -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 B19983A6A18 for ; Wed, 3 Sep 2008 06:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 WE-jCnHPpZ-m for ; Wed, 3 Sep 2008 06:12:25 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id CD1E73A68CB for ; Wed, 3 Sep 2008 06:12:25 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2868049wfc.22 for ; Wed, 03 Sep 2008 06:12:32 -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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SEnv1AnZtTzb6dQdpA1qMJftF5yuohpti4Vx2Xa2MOY=; b=aYwQv+rmCzK8SQ4Js5xsQJP0U/SfbqUWzqoM+lfVdaEuLOLOQTeT5JAeHnkf2Fr6nZ X3RTBsnWm2Vk2bDusL7BO5L73RnXuQyybWIczzl7YAGiO9ssmoctVaqYK1S6j4LifRan JPrBhzjqCTThU7ZQ3ke1EuJBc4L05UO38IwxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rjC76u5x4ZuNfVf0QzLnYWM+8u28lqX4VcCDZJh88YUpyZr6j61rJG61e6MJv8JDjO nUSvlX29XfXK3F5JtD00neghsNC3zDHvGeQikbYswNFzxFQhuCeNfxV+DyYXvPgbMyq7 Ud1yBj2Oc+PBzes7rjMKmWRhdRPC0nDGzwA3U= Received: by 10.142.194.1 with SMTP id r1mr3030964wff.192.1220447552167; Wed, 03 Sep 2008 06:12:32 -0700 (PDT) Received: by 10.142.242.5 with HTTP; Wed, 3 Sep 2008 06:12:32 -0700 (PDT) Message-ID: Date: Wed, 3 Sep 2008 09:12:32 -0400 From: "Anthony Bryan" To: "Julian Reschke" Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) In-Reply-To: <48BE5645.70302@gmx.de> MIME-Version: 1.0 Content-Disposition: inline References: <9235.1220345185.781391@peirce.dave.cridland.net> <48BD08D5.1070206@gmx.de> <48BE5645.70302@gmx.de> Cc: general discussion of application-layer protocols , xml-dev@lists.xml.org, Applications Review List , ietf-http-wg@w3.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Wed, Sep 3, 2008 at 5:17 AM, Julian Reschke wrote: > Anthony Bryan wrote: >> >> On Tue, Sep 2, 2008 at 5:35 AM, Julian Reschke >> wrote: >>> >>> Dave Cridland wrote: >>>> >>>> ... >>>> 11) Section 4.2.17: Does that "type" attribute totally suck? Of course, >>>> you have to have it because every man, his dog, and his pet hampster has >>>> decided that only HTTP is allowed, these days, for absolutely >>>> everything, >>>> leading to a totally useless URI scheme which essentially fails to >>>> describe >>>> the actual resource it's supposedly a locator for. Okay, rant over, back >>>> to >>>> the review. >>>> ... >>> >>> "4.2.17. The "metalink:url" Element >>> >>> >>> The "metalink:url" element contains the IRI of a file. All IRIs >>> should lead to identical files, except in the case of type >>> "bittorrent" where the IRI should lead to a .torrent file." >>> >>> Actually, don't do that. Don't make the meaning of an element totally >>> dependent on an attribute on it. If torrent files are a special case (can >>> there be more...?), then define a separate element. >> >> I'm sure there COULD be more, but I don't know of any other right now. >> >> Do you suggest a torrent specific element, or something generic? > > If it could be phrased as something more generic, and then state the current > use case for torrent files, that probably would be best. > > So, in general, this would be for IRIs that do not identify a resource to > download, but metadata about a resource to download? Strictly speaking, > isn't metalink not yet another format for that? Yes, it is. Do you think about a "metadata" element (a sub-element of "resources")with a required "type" attribute of MIME type is appropriately generic? This could then be used to describe Metalinks if needed, and other types that may come later. I don't think BitTorrent's MIME type is in the is listed in the IANA MIME Media Types. Would this be a problem? ftp://ftp.example.com/example.ext http://example.com/example.ext http://example.com/example.ext.torrent -- (( 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 From apps-discuss-bounces@ietf.org Wed Sep 3 06:22:36 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 A086A3A6983; Wed, 3 Sep 2008 06:22:36 -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 0F4CC3A6983 for ; Wed, 3 Sep 2008 06:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.036 X-Spam-Level: X-Spam-Status: No, score=-4.036 tagged_above=-999 required=5 tests=[AWL=-1.437, 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 FwMJT6WVh+7T for ; Wed, 3 Sep 2008 06:22:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8011B3A6905 for ; Wed, 3 Sep 2008 06:22:32 -0700 (PDT) Received: (qmail invoked by alias); 03 Sep 2008 13:22:34 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp030) with SMTP; 03 Sep 2008 15:22:34 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19mbQ9AwcdmJde4COzCi/gnsVO1sxm0vV85YrZbfd rdmzuBNJT+q0Xz Message-ID: <48BE8F96.2010404@gmx.de> Date: Wed, 03 Sep 2008 15:22:30 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Anthony Bryan Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) References: <9235.1220345185.781391@peirce.dave.cridland.net> <48BD08D5.1070206@gmx.de> <48BE5645.70302@gmx.de> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 Cc: general discussion of application-layer protocols , xml-dev@lists.xml.org, Applications Review List , ietf-http-wg@w3.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Anthony Bryan wrote: >> So, in general, this would be for IRIs that do not identify a resource to >> download, but metadata about a resource to download? Strictly speaking, >> isn't metalink not yet another format for that? > > Yes, it is. > > Do you think about a "metadata" element (a sub-element of > "resources")with a required "type" attribute of MIME type is > appropriately generic? Sounds good. > This could then be used to describe Metalinks if needed, and other > types that may come later. Right. > I don't think BitTorrent's MIME type is in the is listed in the IANA > MIME Media Types. Would this be a problem? > > > > > > > ftp://ftp.example.com/example.ext > http://example.com/example.ext > type="application/x-bittorrent">http://example.com/example.ext.torrent > > > > > One of these issues that regularly come up :-) One way out of that would by to "grab" special type names like "torrent", and hardwire them. That should be ok as long as they can't collide with registered names (thus no "/" allowed). BR, Julian _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Wed Sep 3 09:02:36 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 6DB0E3A6983; Wed, 3 Sep 2008 09:02:36 -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 DA25F3A6CA3 for ; Wed, 3 Sep 2008 09:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRkB4Gbdmwpk for ; Wed, 3 Sep 2008 09:02:34 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id B69853A6AD4 for ; Wed, 3 Sep 2008 09:02:34 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2927223wfc.22 for ; Wed, 03 Sep 2008 09:01:31 -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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=znI8lVJ78UQYqrBdMGd6Go167CUPnVOuzU1NmNfk1Yw=; b=xeC6y/oSGKphQKFKKtMR8Ej8UvEfVYDPjGXlrlbCbDcPnLKVtNa2qKGKJ2WDfDboL2 3jpD2PmE4Q42wOd8y4T7edgz0RzXVTuSaYjcXxYpOBVrA/4WU8qBKOk3U9iOk0I7lMTI nadMQ8tiN9prt72lCvwE7tnwZfi7JdanzHGEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=mct/Hih3ZaXt2Q1Sw6ygIgOEjzeJyhwyu22+u7BqtCZB8W3ODj5BnSoGTSCogSTVDU HQcdXlXf+eDZ6uzQwinAPWUs+NR4pE7rw/VbPyudJXM8aGpEQRkAi7uk6xrXIW57cB5W a9+hSpi/XSt/6gn8RWUqEdQmAC3Cv8H0d+ml4= Received: by 10.142.81.6 with SMTP id e6mr3097127wfb.205.1220457691545; Wed, 03 Sep 2008 09:01:31 -0700 (PDT) Received: by 10.142.242.5 with HTTP; Wed, 3 Sep 2008 09:01:31 -0700 (PDT) Message-ID: Date: Wed, 3 Sep 2008 12:01:31 -0400 From: "Anthony Bryan" To: "Julian Reschke" Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) In-Reply-To: <48BE8F96.2010404@gmx.de> MIME-Version: 1.0 Content-Disposition: inline References: <9235.1220345185.781391@peirce.dave.cridland.net> <48BD08D5.1070206@gmx.de> <48BE5645.70302@gmx.de> <48BE8F96.2010404@gmx.de> Cc: Applications Review List , xml-dev@lists.xml.org, general discussion of application-layer protocols , ietf-http-wg@w3.org, Ian Macfarlane 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 On Wed, Sep 3, 2008 at 9:22 AM, Julian Reschke wrote: > Anthony Bryan wrote: >>> >>> So, in general, this would be for IRIs that do not identify a resource to >>> download, but metadata about a resource to download? Strictly speaking, >>> isn't metalink not yet another format for that? >> >> Yes, it is. >> >> Do you think about a "metadata" element (a sub-element of >> "resources")with a required "type" attribute of MIME type is >> appropriately generic? > > Sounds good. > >> This could then be used to describe Metalinks if needed, and other >> types that may come later. > > Right. > >> I don't think BitTorrent's MIME type is in the is listed in the IANA >> MIME Media Types. Would this be a problem? >> >> >> >> >> >> >> ftp://ftp.example.com/example.ext >> http://example.com/example.ext >> > type="application/x-bittorrent">http://example.com/example.ext.torrent >> >> >> >> >> > > One of these issues that regularly come up :-) > > One way out of that would by to "grab" special type names like "torrent", > and hardwire them. That should be ok as long as they can't collide with > registered names (thus no "/" allowed). Great, thanks Julian! Thanks to the other people that mentioned this as well, it seems much cleaner & tightened up now. :) Do I need to explicitly state no "/" allowed, or just know any that ones I'm defining can't be "/" ? And would it be better to just allow the unofficial MIME type, instead of essentially creating an unofficial registry with one or a handful of entries? Or is MIME types plus hardwired entries better? Here is the changed text: 4.2.9. The "metalink:metadata" Element The "metalink:metadata" element contains the IRI of metadata about a resource to download. For example, this could be the IRI of a BitTorrent .torrent file or a Metalink Document. metalinkMetadata = element metalink:metadata { metalinkCommonAttributes, attribute preference { xsd:integer }?, attribute type { metalinkTextConstruct }, metalinkUri }+ 4.2.9.1. The "preference" Attribute metalink:metadata elements MAY have a preference attribute, whose value MUST be a number from 1 to 100 for priority, with 100 used first and 1 used last. See the "preference" attribute of the metalink:url element for more information. 4.2.9.2. The "type" Attribute metalink:metadata elements MUST have a "type" attribute that indicates the MIME type of the metadata available at the IRI. In the case of BitTorrent as specified in [BITTORRENT], the value "torrent" is required. Metalink Processors that do not support a specified type of metadata about a resource to download MUST ignore that metadata 4.2.18. The "metalink:url" Element The "metalink:url" element contains the IRI of a file. All IRIs MUST lead to identical files. -- (( 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 From apps-discuss-bounces@ietf.org Wed Sep 3 11:55:18 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 10A403A6CFD; Wed, 3 Sep 2008 11:55:18 -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 CC3673A6B22 for ; Wed, 3 Sep 2008 11:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.948 X-Spam-Level: X-Spam-Status: No, score=-4.948 tagged_above=-999 required=5 tests=[AWL=-2.349, 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 gGPNxXfku-cN for ; Wed, 3 Sep 2008 11:55:16 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 415003A6A01 for ; Wed, 3 Sep 2008 11:55:16 -0700 (PDT) Received: (qmail invoked by alias); 03 Sep 2008 18:54:36 -0000 Received: from p508FC108.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.193.8] by mail.gmx.net (mp005) with SMTP; 03 Sep 2008 20:54:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19OvjZkOwVOXlmGqe5hnWIZZ1tlcUu50UKn4SpM1R +6biIMSzU3Wm9j Message-ID: <48BEDD65.8060803@gmx.de> Date: Wed, 03 Sep 2008 20:54:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Anthony Bryan Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) References: <9235.1220345185.781391@peirce.dave.cridland.net> <48BD08D5.1070206@gmx.de> <48BE5645.70302@gmx.de> <48BE8F96.2010404@gmx.de> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 Cc: Applications Review List , xml-dev@lists.xml.org, general discussion of application-layer protocols , ietf-http-wg@w3.org, Ian Macfarlane 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 Anthony Bryan wrote: > ... >> One way out of that would by to "grab" special type names like "torrent", >> and hardwire them. That should be ok as long as they can't collide with >> registered names (thus no "/" allowed). > > Great, thanks Julian! Thanks to the other people that mentioned this > as well, it seems much cleaner & tightened up now. :) > > Do I need to explicitly state no "/" allowed, or just know any that > ones I'm defining can't be "/" ? I'd say that types without "/" are reserved, and the only reserved value for now is "torrent". > And would it be better to just allow the unofficial MIME type, instead > of essentially creating an unofficial registry with one or a handful > of entries? Or is MIME types plus hardwired entries better? > ... I think you'll see pushback once you start to make normative requirements related to unregistered mime types. So, you can also try to get a type registered, which of course would be the cleaner solution... BR, Julian _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Wed Sep 3 13:41:53 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 891223A6D5A; Wed, 3 Sep 2008 13:41:53 -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 7AC423A6973; Wed, 3 Sep 2008 13:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkm6+l9Qehn7; Wed, 3 Sep 2008 13:41:51 -0700 (PDT) Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by core3.amsl.com (Postfix) with ESMTP id 394913A6A90; Wed, 3 Sep 2008 13:41:42 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 89D5314220E; Wed, 3 Sep 2008 13:41:48 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRmrd+r3USrU; Wed, 3 Sep 2008 13:41:38 -0700 (PDT) Received: from [10.1.1.121] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 16CC914220C; Wed, 3 Sep 2008 13:41:38 -0700 (PDT) Message-Id: <47490048-25ED-403E-96B9-0D385F764292@osafoundation.org> From: Lisa Dusseault To: HTTP Working Group , secdir@mit.edu, saag@ietf.org, Apps Discuss Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Request for review and consensus -- draft-hartman-webauth-phishing Date: Wed, 3 Sep 2008 13:41:39 -0700 X-Mailer: Apple Mail (2.928.1) Cc: ietf-http-auth@osafoundation.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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org You may have seen this draft a year ago; Sam is back working on it and produced version -09 last month. http://tools.ietf.org/html/draft-hartman-webauth-phishing-09 If you've reviewed it before, please take a look at the changes. If you'd like to review it, please do. I'm the shepherd for this draft, so comments can be sent to me, to Sam as author, to ietf-http-auth@osafoundation.org , or to the IETF general list as appropriate. In addition to getting general input, I'd like to get a sense of whether we have consensus on a couple things. a). The statement including "IETF recommends", from section 1.1 of the draft: "In publishing this memo, the IETF recommends making available authentication mechanisms that meet the requirements outlined in Section 4 in HTTP user agents including web browsers. It is hoped that these mechanisms will prove a useful step in fighting phishing. However this memo does not restrict work either in the IETF or any other organization. In particular, new authentication efforts are not bound to meet the requirements posed in this memo unless the charter for those efforts chooses to make these binding requirements. Less formally, the IETF presents this memo as an option to pursue while acknowledging that there may be other promising paths both now and in the future." b) Whether the document should require mutual authentication (section 4.4). Thanks, Lisa D. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Sep 4 13:09:21 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 847473A6A7B; Thu, 4 Sep 2008 13:09:21 -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 224F03A6A7B for ; Thu, 4 Sep 2008 13:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=-0.313, 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 j-PQ+i1205Yf for ; Thu, 4 Sep 2008 13:09:19 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id E66433A67AE for ; Thu, 4 Sep 2008 13:09:18 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so98916wfc.22 for ; Thu, 04 Sep 2008 13:09:26 -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:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=8K6APWpxo9FBIKXaFV3i3UTqjyuhJx/SyL6AEvcyapg=; b=Ndr4CAnIDj0rWzyDVNFUBSZonyOWk1g4IsC3IkT/wrOqKF1bFIE6PT+2fDfErR0a9G TyDC8VZY3c9kXKayZDvsfwkGJTKyr3v8CrKGmxBE0dMwAA5F9RqJ7gfFwO88XkYpJ7z3 SSQPGFAMLzkcyckAX8t/Wb3Gez8fh9rIQui8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=ebG1DwBUR7AdRrpLcu/+K2vGsZepAi/E+UPeIzRpJPwxIIGK2PrnR8hlblfZN7bKGm BAAEdISzPRItCXZZ5xV344JdUevtKD3o4pIFRmzheNGFSQCC0twm0vct6tIR5tXv7cg/ inREKXhrZO3roq38YA4Juhew4CwaTWQjBqGeI= Received: by 10.142.81.7 with SMTP id e7mr3708783wfb.320.1220558966632; Thu, 04 Sep 2008 13:09:26 -0700 (PDT) Received: by 10.142.242.5 with HTTP; Thu, 4 Sep 2008 13:09:26 -0700 (PDT) Message-ID: Date: Thu, 4 Sep 2008 16:09:26 -0400 From: "Anthony Bryan" To: "Julian Reschke" Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-02) MIME-Version: 1.0 Content-Disposition: inline Cc: general discussion of application-layer protocols , xml-dev@lists.xml.org, Applications Review List , ietf-http-wg@w3.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Wed, Sep 3, 2008 at 2:54 PM, Julian Reschke wrote: > Anthony Bryan wrote: >> >> ... >>> >>> One way out of that would by to "grab" special type names like "torrent", >>> and hardwire them. That should be ok as long as they can't collide with >>> registered names (thus no "/" allowed). >> >> Great, thanks Julian! Thanks to the other people that mentioned this >> as well, it seems much cleaner & tightened up now. :) >> >> Do I need to explicitly state no "/" allowed, or just know any that >> ones I'm defining can't be "/" ? > > I'd say that types without "/" are reserved, and the only reserved value for > now is "torrent". Done. >> And would it be better to just allow the unofficial MIME type, instead >> of essentially creating an unofficial registry with one or a handful >> of entries? Or is MIME types plus hardwired entries better? >> ... > > I think you'll see pushback once you start to make normative requirements > related to unregistered mime types. So, you can also try to get a type > registered, which of course would be the cleaner solution... Understood. That would be nice if it already was registered. I've incorporated these comments into a new draft at http://tools.ietf.org/html/draft-bryan-metalink-02 There are some issues I would like help from people: - Inclusion of digital signatures other than PGP. - Ability to specify if a file is in one or multiple languages. - Ability to specify if a file is for one or more operating systems. Maybe using the IANA Operating System Names registry at http://www.iana.org/assignments/operating-system-names , but these seem quite outdated. Or possibly using http://nvd.nist.gov/schema/nvdcve.xsd ? -- (( 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 From apps-discuss-bounces@ietf.org Sat Sep 6 06:48:14 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 546993A697A; Sat, 6 Sep 2008 06:48:14 -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 487303A6B18; Thu, 4 Sep 2008 08:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.527 X-Spam-Level: X-Spam-Status: No, score=-4.527 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+oQgg0j2eSF; Thu, 4 Sep 2008 08:26:33 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 8D2A03A6BDD; Thu, 4 Sep 2008 08:26:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 769909CB42; Fri, 5 Sep 2008 03:26:12 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X1MTj5CId0G; Fri, 5 Sep 2008 03:26:12 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D313C9CB31; Fri, 5 Sep 2008 03:26:11 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id EA64DE0808A; Fri, 5 Sep 2008 03:26:10 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1KbGio-00037B-Q7; Fri, 05 Sep 2008 03:26:10 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: discuss@ietf.org, ietf-http-wg@w3.org, lisa@osafoundation.org, saag@ietf.org, secdir@mit.edu Subject: Re: [saag] Request for review and consensus -- draft-hartman-webauth-phishing In-Reply-To: <47490048-25ED-403E-96B9-0D385F764292@osafoundation.org> Message-Id: Date: Fri, 05 Sep 2008 03:26:10 +1200 X-Mailman-Approved-At: Sat, 06 Sep 2008 06:48:13 -0700 Cc: ietf-http-auth@osafoundation.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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Lisa Dusseault writes: >You may have seen this draft a year ago; Sam is back working on it and >produced version -09 last month. > >http://tools.ietf.org/html/draft-hartman-webauth-phishing-09 > >[...] > >b) Whether the document should require mutual authentication (section 4.4). Yes, absolutely! The whole reason why phishing works is that the site is never authenticated, without mutual auth (and specifically strong mutual auth, e.g. some form of cryptographic challenge-response mechanism rather than the pretend-auth of "do you recognise this image?" that some US banks have adopted) you've not really achieving much. Peter. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Sep 6 18:56:27 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 8E5E73A6A78; Sat, 6 Sep 2008 18:56:27 -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 7C9A73A6A88 for ; Sat, 6 Sep 2008 18:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.01 X-Spam-Level: **** X-Spam-Status: No, score=4.01 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=3.196, 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 n1bssarlhNBH for ; Sat, 6 Sep 2008 18:56:25 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by core3.amsl.com (Postfix) with ESMTP id 5967A3A6A1C for ; Sat, 6 Sep 2008 18:56:24 -0700 (PDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Kc9Vk-0003MO-JA for apps-discuss@ietf.org; Sun, 07 Sep 2008 01:56:20 +0000 Received: from 212.82.251.146 ([212.82.251.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Sep 2008 01:56:20 +0000 Received: from hmdmhdfmhdjmzdtjmzdtzktdkztdjz by 212.82.251.146 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Sep 2008 01:56:20 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: apps-discuss@ietf.org From: "Frank Ellermann" Subject: Re: [APPS-REVIEW] Metalink XML DownloadDescription Format(draft-bryan-metalink-01) Date: Sun, 7 Sep 2008 03:58:24 +0200 Organization: Lines: 24 Message-ID: References: <9235.1220345185.781391@peirce.dave.cridland.net> <48BE880A.7060009@stpeter.im> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.146 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1933 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 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 Peter Saint-Andre wrote: >> BUT sometimes human users want to learn what an obscure >> namespace is about. For that purpose tag: URIs or IANA >> IETF URNs are less desirable, and a working http (or >> similar) URI would be better. > Why? [skipping your "one step" proposal, as we agree on that] > If you come upon an unknown namespace that's a URN, you > copy it into the search bar of your favorite browser and > get some search results; probably the top hit has the > information you need. Two steps. Apparently folks don't say "google is your friend" anymore. Sure, after some time I often found what I was looking for. But I strongly prefer the "working one step" approach, and it might be trivial to arrange this for namespaces defined in RFCs. Frank _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Tue Sep 9 08:10:48 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 97F853A6D19; Tue, 9 Sep 2008 08:10:48 -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 9B2FF3A6CC4 for ; Tue, 9 Sep 2008 08:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u40eEl6pxVZi for ; Tue, 9 Sep 2008 08:10:41 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id DC1733A67B2 for ; Tue, 9 Sep 2008 08:10:40 -0700 (PDT) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Kd4ra-000M7p-4S; Tue, 09 Sep 2008 11:10:42 -0400 Date: Tue, 09 Sep 2008 11:10:41 -0400 From: John C Klensin To: "Alfred H?nes" Subject: Re: draft-klensin-ftp-registry-00 Message-ID: <69B4E1FBF401100E218946B8@p3.JCK.COM> In-Reply-To: <200809090852.KAA21968@TR-Sys.de> References: <200809090852.KAA21968@TR-Sys.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Alfred, Good point. I will try to clarify in the next version. FYI, the status of this is that a couple of us took an action item away from Dublin to create a charter for a new WG. I haven't gotten around to it, but hope to do so this month. I probably won't post an updated draft until after that charter is at least in the IESG's hands. best regards, john --On Tuesday, 09 September, 2008 10:52 +0200 "Alfred H?nes" wrote: > Hello, > I'd like to send a few comments on your recent I-D, > draft-klensin-ftp-registry-00. > > First of all, I appreciate this idea. > > The major problem with the proposal seems to be that it does > not distinguish between 'FTP Extension' names and FTP command > names. Quite a lot of proposals (and published extensions) > combine multiple new commands (and/or extensions to > preexisting commands) under the umbrella of a single 'FTP > Extension' (FEAT keyword). > > IMHO, the primary resource that needs to be coordinated via an > IANA registry is the name space of command names; extension > names are more or less some kind of by-product needing > coordination as well. > > Defining an FTP command name registry also would serve a > similar role as, e.g., the message header field registry, > documenting the 'command verb thesaurus' of a full-fledged FTP > implementation. > > Alternatively, an integrated, hierarchically structured > registry listing the base protocol with the command names it > defined, and then the various extensions with the command > names they define (comparable in structure to the RSVP class / > object registry) could be envisioned. > > > Regarding [[anchor7]], I'm in support of the "RFC Required" > registration policy, since wide-spread interoperability > and stability are major goals for this important protocol; > these goals are hopefully furthered by IETF discussion. > Thus, even "IETF Review" might be appropriate. > > > Footnote: a single nit in the current (-00) draft: > Section 1, 2nd line: period missing after "[RFC0959]". > > > Kind regards, > Alfred H?nes. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Tue Sep 9 15:11:29 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 F27B23A6B22; Tue, 9 Sep 2008 15:11:28 -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 C4D4A28C199 for ; Tue, 9 Sep 2008 01:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.002 X-Spam-Level: ** X-Spam-Status: No, score=2.002 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s41eOjAmrSJR for ; Tue, 9 Sep 2008 01:53:45 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id BF04028C17A for ; Tue, 9 Sep 2008 01:53:43 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA034390356; Tue, 9 Sep 2008 10:52:36 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA21968; Tue, 9 Sep 2008 10:52:29 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200809090852.KAA21968@TR-Sys.de> Subject: draft-klensin-ftp-registry-00 To: john+ietf@jck.com Date: Tue, 9 Sep 2008 10:52:29 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 X-Mailman-Approved-At: Tue, 09 Sep 2008 15:11:27 -0700 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org SGVsbG8sCkknZCBsaWtlIHRvIHNlbmQgYSBmZXcgY29tbWVudHMgb24geW91ciByZWNlbnQgSS1E LAogICAgICAgZHJhZnQta2xlbnNpbi1mdHAtcmVnaXN0cnktMDAuCgpGaXJzdCBvZiBhbGwsIEkg YXBwcmVjaWF0ZSB0aGlzIGlkZWEuCgpUaGUgbWFqb3IgcHJvYmxlbSB3aXRoIHRoZSBwcm9wb3Nh bCBzZWVtcyB0byBiZSB0aGF0IGl0IGRvZXMgbm90CmRpc3Rpbmd1aXNoIGJldHdlZW4gJ0ZUUCBF eHRlbnNpb24nIG5hbWVzIGFuZCBGVFAgY29tbWFuZCBuYW1lcy4KUXVpdGUgYSBsb3Qgb2YgcHJv cG9zYWxzIChhbmQgcHVibGlzaGVkIGV4dGVuc2lvbnMpIGNvbWJpbmUKbXVsdGlwbGUgbmV3IGNv bW1hbmRzIChhbmQvb3IgZXh0ZW5zaW9ucyB0byBwcmVleGlzdGluZyBjb21tYW5kcykKdW5kZXIg dGhlIHVtYnJlbGxhIG9mIGEgc2luZ2xlICdGVFAgRXh0ZW5zaW9uJyAoRkVBVCBrZXl3b3JkKS4K CklNSE8sIHRoZSBwcmltYXJ5IHJlc291cmNlIHRoYXQgbmVlZHMgdG8gYmUgY29vcmRpbmF0ZWQg dmlhIGFuCklBTkEgcmVnaXN0cnkgaXMgdGhlIG5hbWUgc3BhY2Ugb2YgY29tbWFuZCBuYW1lczsg ZXh0ZW5zaW9uIG5hbWVzCmFyZSBtb3JlIG9yIGxlc3Mgc29tZSBraW5kIG9mIGJ5LXByb2R1Y3Qg bmVlZGluZyBjb29yZGluYXRpb24gYXMKd2VsbC4KCkRlZmluaW5nIGFuIEZUUCBjb21tYW5kIG5h bWUgcmVnaXN0cnkgYWxzbyB3b3VsZCBzZXJ2ZSBhIHNpbWlsYXIKcm9sZSBhcywgZS5nLiwgdGhl IG1lc3NhZ2UgaGVhZGVyIGZpZWxkIHJlZ2lzdHJ5LCBkb2N1bWVudGluZyB0aGUKJ2NvbW1hbmQg dmVyYiB0aGVzYXVydXMnIG9mIGEgZnVsbC1mbGVkZ2VkIEZUUCBpbXBsZW1lbnRhdGlvbi4KCkFs dGVybmF0aXZlbHksIGFuIGludGVncmF0ZWQsIGhpZXJhcmNoaWNhbGx5IHN0cnVjdHVyZWQgcmVn aXN0cnkKbGlzdGluZyB0aGUgYmFzZSBwcm90b2NvbCB3aXRoIHRoZSBjb21tYW5kIG5hbWVzIGl0 IGRlZmluZWQsIGFuZAp0aGVuIHRoZSB2YXJpb3VzIGV4dGVuc2lvbnMgd2l0aCB0aGUgY29tbWFu ZCBuYW1lcyB0aGV5IGRlZmluZQooY29tcGFyYWJsZSBpbiBzdHJ1Y3R1cmUgdG8gdGhlIFJTVlAg Y2xhc3MgLyBvYmplY3QgcmVnaXN0cnkpCmNvdWxkIGJlIGVudmlzaW9uZWQuCgoKUmVnYXJkaW5n IFtbYW5jaG9yN11dLCBJJ20gaW4gc3VwcG9ydCBvZiB0aGUgIlJGQyBSZXF1aXJlZCIKcmVnaXN0 cmF0aW9uIHBvbGljeSwgc2luY2Ugd2lkZS1zcHJlYWQgaW50ZXJvcGVyYWJpbGl0eQphbmQgc3Rh YmlsaXR5IGFyZSBtYWpvciBnb2FscyBmb3IgdGhpcyBpbXBvcnRhbnQgcHJvdG9jb2w7CnRoZXNl IGdvYWxzIGFyZSBob3BlZnVsbHkgZnVydGhlcmVkIGJ5IElFVEYgZGlzY3Vzc2lvbi4KVGh1cywg ZXZlbiAiSUVURiBSZXZpZXciIG1pZ2h0IGJlIGFwcHJvcHJpYXRlLgoKCkZvb3Rub3RlOiBhIHNp bmdsZSBuaXQgaW4gdGhlIGN1cnJlbnQgKC0wMCkgZHJhZnQ6ClNlY3Rpb24gMSwgMm5kIGxpbmU6 ICBwZXJpb2QgbWlzc2luZyBhZnRlciAiW1JGQzA5NTldIi4KCgpLaW5kIHJlZ2FyZHMsCiAgQWxm cmVkIEjObmVzLgoKLS0gCgorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwp8IFRSLVN5cyBBbGZyZWQgSG9lbmVzICAg fCAgQWxmcmVkIEhvZW5lcyAgIERpcGwuLU1hdGguLCBEaXBsLi1QaHlzLiAgfAp8IEdlcmxpbmdl ciBTdHJhc3NlIDEyICAgfCAgUGhvbmU6ICgrNDkpNzE1Ni85NjM1LTAsIEZheDogLTE4ICAgICAg ICAgfAp8IEQtNzEyNTQgIERpdHppbmdlbiAgICAgfCAgRS1NYWlsOiAgYWhAVFItU3lzLmRlICAg ICAgICAgICAgICAgICAgICAgfAorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KQXBwcy1EaXNjdXNzIG1haWxpbmcgbGlzdApBcHBz LURpc2N1c3NAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h cHBzLWRpc2N1c3MK From apps-discuss-bounces@ietf.org Thu Sep 11 03:08:37 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 2C2803A6A6E; Thu, 11 Sep 2008 03:08:37 -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 6BCB73A6A6E for ; Thu, 11 Sep 2008 03:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDguWIIcV7a2 for ; Thu, 11 Sep 2008 03:08:35 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 41C0E3A6A6A for ; Thu, 11 Sep 2008 03:08:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D7FA020E91C9 for ; Thu, 11 Sep 2008 12:07:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCkIYLdQQxHW for ; Thu, 11 Sep 2008 12:07:18 +0200 (CEST) Received: from [172.16.35.206] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 3076620E91A9 for ; Thu, 11 Sep 2008 12:07:18 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: apps-discuss@ietf.org Mime-Version: 1.0 (Apple Message framework v928.1) Subject: ETSI defining ASN.1 (with derived XML schema) Date: Thu, 11 Sep 2008 12:07:17 +0200 X-Mailer: Apple Mail (2.928.1) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Is anyone working with the ETSI standard for how to transfer data between providers of services and law enforcement agencies when talking about data retention? They are defining an ASN.1 format of the data, and then they have the intention (as it seems) to derive an XML schema from it. When talking with ETSI, they are interested in getting help from IETF, and if someone is interested in helping, please help. I can help with contacts if you do not have any. Patrik _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Sep 11 06:35:27 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 4386C3A6910; Thu, 11 Sep 2008 06:35:27 -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 B35373A679C for ; Thu, 11 Sep 2008 06:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.861 X-Spam-Level: X-Spam-Status: No, score=-4.861 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, URIBL_PH_SURBL=1.787] 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 6o2SaAus9XiD for ; Thu, 11 Sep 2008 06:35:25 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 7BD043A68F9 for ; Thu, 11 Sep 2008 06:35:25 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 0C1501C0172; Thu, 11 Sep 2008 15:35:27 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0676C1C016C; Thu, 11 Sep 2008 15:35:27 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0437C6C0674; Thu, 11 Sep 2008 15:35:27 +0200 (CEST) Date: Thu, 11 Sep 2008 15:35:27 +0200 From: Stephane Bortzmeyer To: Lisa Dusseault , HTTP Working Group , Apps Discuss Subject: Re: Request for review and consensus -- draft-hartman-webauth-phishing Message-ID: <20080911133527.GA13697@nic.fr> References: <47490048-25ED-403E-96B9-0D385F764292@osafoundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <47490048-25ED-403E-96B9-0D385F764292@osafoundation.org> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) 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 On Wed, Sep 03, 2008 at 01:41:39PM -0700, Lisa Dusseault wrote a message of 39 lines which said: > If you'd like to review it, please do. I was skeptical at the origin of this work because phishing mitigation is 50 % UI design and 50 % psychology, two domains where the IETF has no expertise or legitimacy (which does not prevent some people to use the fear of phishing for advancing their ideas, as we saw for the IDN protocol). But I find the draft quite good because it is modest, it stays in IETF waters, network protocols. I agree with the general idea (using new authentication protocols to reduce the incentive for phishing). A few remarks: Section 3, the sentence "As a consequence of this assumption, users will likely be fooled by strings either in website names or certificates that look visually similar but that are composed of different code points." should be deleted. It is exactly the sort of thing (psychology of users) that we should stay away from. Moreover, it does not reflect the reality of phishing: very few phishers take the trouble to fake the domain name (that's why the whole issue of phishing for IDN is a red herring). Most of the phishing Web sites have an unrelated domain name (smith.example.com) or even an IP address. The few that try to fake the domain name use tricks like a dash instead of a dot (secure-paypal.com) and do not rely on visual confusability. Section 4.5 says "Assuming that only certificates from trusted CAs are accepted". I would delete it too. One of the big problems with X.509 is precisely that there is never an informed decision by the user to trust or not a CA. The user typically blindly accepts what's in the browser list of CA, list which was compiled on many criteria, trust being only one of them. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Sep 11 07:54:43 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 21A253A69AC; Thu, 11 Sep 2008 07:54:43 -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 D690A3A6986 for ; Thu, 11 Sep 2008 07:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w80jJQ3JanLv for ; Thu, 11 Sep 2008 07:54:40 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id BEDAF3A6A2B for ; Thu, 11 Sep 2008 07:54:39 -0700 (PDT) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KdnZE-0004t8-PS; Thu, 11 Sep 2008 10:54:45 -0400 Date: Thu, 11 Sep 2008 10:54:42 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Subject: Re: ETSI defining ASN.1 (with derived XML schema) Message-ID: <79721BC6592A523331B68181@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Cc: jon.peterson@neustar.biz, 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-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org CgotLU9uIFRodXJzZGF5LCAxMSBTZXB0ZW1iZXIsIDIwMDggMTI6MDcgKzAyMDAgUGF0cmlrIEbD pGx0c3Ryw7ZtCjxwYXRyaWtAZnJvYmJpdC5zZT4gd3JvdGU6Cgo+IElzIGFueW9uZSB3b3JraW5n IHdpdGggdGhlIEVUU0kgc3RhbmRhcmQgZm9yIGhvdyB0byB0cmFuc2Zlcgo+IGRhdGEgICBiZXR3 ZWVuIHByb3ZpZGVycyBvZiBzZXJ2aWNlcyBhbmQgbGF3IGVuZm9yY2VtZW50Cj4gYWdlbmNpZXMg d2hlbiAgIHRhbGtpbmcgYWJvdXQgZGF0YSByZXRlbnRpb24/Cj4gCj4gVGhleSBhcmUgZGVmaW5p bmcgYW4gQVNOLjEgZm9ybWF0IG9mIHRoZSBkYXRhLCBhbmQgdGhlbiB0aGV5Cj4gaGF2ZSB0aGUg ICBpbnRlbnRpb24gKGFzIGl0IHNlZW1zKSB0byBkZXJpdmUgYW4gWE1MIHNjaGVtYQo+IGZyb20g aXQuIFdoZW4gdGFsa2luZyAgIHdpdGggRVRTSSwgdGhleSBhcmUgaW50ZXJlc3RlZCBpbgo+IGdl dHRpbmcgaGVscCBmcm9tIElFVEYsIGFuZCBpZiAgIHNvbWVvbmUgaXMgaW50ZXJlc3RlZCBpbgo+ IGhlbHBpbmcsIHBsZWFzZSBoZWxwLiBJIGNhbiBoZWxwIHdpdGggICBjb250YWN0cyBpZiB5b3Ug ZG8gbm90Cj4gaGF2ZSBhbnkuCj4gCj4gPGh0dHA6Ly93d3cuM2dwcC5vcmcvZnRwL1RTR19TQS9X RzNfU2VjdXJpdHkvVFNHUzNfTEkvMjAwN18yNl8KPiBLZXlXZXN0L0RvY3MvU0EzTEkwN18wODBf RFRTLUxJLTAwMDMzX1YwLjQuMC5fUkRfSE8uZG9jICA+CgpQYXRyaWssCgpEaWQgeW91IGFsc28g Zm9yd2FyZCB0aGlzIHRvIHRoZSBFQ1JJVCBmb2xrcyAoYW5kIEZyZWQpPyAgSWYKbm90LCBwbGVh c2UgZG8gc28gLS0gaXQgd291bGQgc2VlbSB0byBtZSwgYXQgbGVhc3QgaW4gbXkKaWdub3JhbmNl LCB0aGF0IHJpZ2h0IHdheSB0byBhcHByb2FjaCB0aGlzIHByb2JsZW0gd291bGQgYmUgdG8KZXh0 ZW5kIHRoZSBFQ1JJVCBtb2RlbCB0byBkZWFsIHdpdGggdGhpcyB0eXBlIG9mIG1lc3NhZ2UsIHJh dGhlcgp0aGFuIHJlaW52ZW50aW5nIHRoZSB3aGVlbCwgbXVjaCBsZXNzIGJ5IHVzaW5nIEFTTi4x IGFzIGEKc3RhcnRpbmcgcG9pbnQuICBBbmQgdGhlcmUgaXMgYWxyZWFkeSBzdXBwb3NlZCB0byBi ZSBhIGNsb3NlCmxpYWlzb24gcmVsYXRpb25zaGlwIGJldHdlZW4gRUNSSVQgYW5kIEVUU0kuCgog ICBqb2huCgoKPiAKPiAgICAgUGF0cmlrCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPiBBcHBzLURpc2N1c3MgbWFpbGluZyBsaXN0Cj4gQXBwcy1E aXNjdXNzQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h cHBzLWRpc2N1c3MKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCkFwcHMtRGlzY3VzcyBtYWlsaW5nIGxpc3QKQXBwcy1EaXNjdXNzQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzCg== From apps-discuss-bounces@ietf.org Thu Sep 11 08:01: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 198E03A68B2; Thu, 11 Sep 2008 08:01: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 1A1FE3A68B2 for ; Thu, 11 Sep 2008 08:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnCKv91R1xpt for ; Thu, 11 Sep 2008 08:01:50 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 1AD613A67A7 for ; Thu, 11 Sep 2008 08:01:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id ABCFF20F6015; Thu, 11 Sep 2008 17:01:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a2jlACwZxIY; Thu, 11 Sep 2008 17:01:26 +0200 (CEST) Received: from [172.16.35.222] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 3A92120F600A; Thu, 11 Sep 2008 17:01:26 +0200 (CEST) Message-Id: <3730A1AA-6D62-49DB-B4F5-D3138293390E@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: John C Klensin In-Reply-To: <79721BC6592A523331B68181@p3.JCK.COM> Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: ETSI defining ASN.1 (with derived XML schema) Date: Thu, 11 Sep 2008 17:01:19 +0200 References: <79721BC6592A523331B68181@p3.JCK.COM> X-Mailer: Apple Mail (2.928.1) Cc: jon.peterson@neustar.biz, 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On 11 sep 2008, at 16.54, John C Klensin wrote: > Did you also forward this to the ECRIT folks (and Fred)? If > not, please do so -- it would seem to me, at least in my > ignorance, that right way to approach this problem would be to > extend the ECRIT model to deal with this type of message, rather > than reinventing the wheel, much less by using ASN.1 as a > starting point. And there is already supposed to be a close > liaison relationship between ECRIT and ETSI. Ok, good point. Let me send to them as well. Patrik _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Sep 11 08:13:44 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 999023A6B4D; Thu, 11 Sep 2008 08:13:44 -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 9B9053A6B4A for ; Thu, 11 Sep 2008 08:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.039 X-Spam-Level: X-Spam-Status: No, score=-5.039 tagged_above=-999 required=5 tests=[AWL=1.560, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JynoW2mQvcgm for ; Thu, 11 Sep 2008 08:13:39 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 714803A6A1E for ; Thu, 11 Sep 2008 08:13:38 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Cc:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=pcR3ec/knJ4aj+LFALjG06fe/Z7UzPCm72HCFwREx3JsFVjAdYB4R/GT 2wc50VHESGI9FtKEZIqWUpyMgUH3xMGxR0vuOtv1NMxEvX8W6j8g9EFdo W+mWqlc8pr0IQ65; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1221146026; x=1252682026; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20ETSI =20defining=20ASN.1=20(with=20derived=20XML=20schema) |Date:=20Thu,=2011=20Sep=202008=2016:13:36=20+0100 |Message-ID:=20|To:=20John=20C=20Klensin =20|Cc:=20apps-discuss@ietf.org,=0D=0A=09jo n.peterson@neustar.biz|MIME-Version:=201.0|In-Reply-To: =20<79721BC6592A523331B68181@p3.JCK.COM>; bh=W4xwOyllgJg3Xjd+3DVjvLybSJJxDrOSWhACDPgCFZ0=; b=6O16k/+1bopqoLX+hZuG7NB39PsbqdnhnirxRJloho0LnJfx9H+XTq+A s5d+OMmF3+mF9Yxha7WwMyonkZk17P0tYwnqQ+LpIeJJWIL98TwtaISkn m6td/fMiL5vMKXP; X-IronPort-AV: E=Sophos;i="4.32,380,1217804400"; d="scan'208";a="5500792" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 11 Sep 2008 16:13:38 +0100 In-Reply-To: <79721BC6592A523331B68181@p3.JCK.COM> To: John C Klensin Subject: Re: ETSI defining ASN.1 (with derived XML schema) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 11 Sep 2008 16:13:36 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 11/09/2008 04:13:38 PM, Serialize complete at 11/09/2008 04:13:38 PM Cc: jon.peterson@neustar.biz, 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org > Did you also forward this to the ECRIT folks (and Fred)? If > not, please do so -- it would seem to me, at least in my > ignorance, that right way to approach this problem would be to > extend the ECRIT model to deal with this type of message, rather > than reinventing the wheel, much less by using ASN.1 as a > starting point. John, Thus far, as I understand it, there has been a complete seperation between the need to place a call in real-time to the emergency services, and the potential requirements of the law enforcement agencies for retrospective access to logs and location information. This is also the case at NICC in the UK where we've been working on the architecture for determining the location of VoIP callers. I humbly suggest therefore that ECRIT is _not_ the place for this work. kind regards, Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Sep 11 08:16:43 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 E976C3A6BCF; Thu, 11 Sep 2008 08:16:43 -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 C5F9C3A6BCF for ; Thu, 11 Sep 2008 08:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTcuAwlm6esl for ; Thu, 11 Sep 2008 08:16:39 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id D78623A6B08 for ; Thu, 11 Sep 2008 08:16:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 4D80E20F6A0C; Thu, 11 Sep 2008 17:16:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6k028E2wCuJ; Thu, 11 Sep 2008 17:16:21 +0200 (CEST) Received: from [172.16.35.222] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id B15B520F69F5; Thu, 11 Sep 2008 17:16:20 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Ray.Bellis@nominet.org.uk In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: ETSI defining ASN.1 (with derived XML schema) Date: Thu, 11 Sep 2008 17:16:19 +0200 References: X-Mailer: Apple Mail (2.928.1) Cc: John C Klensin , apps-discuss@ietf.org, jon.peterson@neustar.biz 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 On 11 sep 2008, at 17.13, Ray.Bellis@nominet.org.uk wrote: > I humbly suggest therefore that ECRIT is _not_ the place for this > work. The work is already done at ETSI, it is only me being nervous the work MIGHT be done without whatever help might be needed from IETF, given the experience IETF has with designing similar protocols. I am trying to understand the landscape. Patrik _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Sep 11 08:35:15 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 AF6723A6A10; Thu, 11 Sep 2008 08:35:15 -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 09B583A693C for ; Thu, 11 Sep 2008 08:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 b-qRIAesArY3 for ; Thu, 11 Sep 2008 08:35:12 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id A0F2D3A6896 for ; Thu, 11 Sep 2008 08:35:12 -0700 (PDT) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KdoBO-0007Ce-P4; Thu, 11 Sep 2008 11:34:11 -0400 Date: Thu, 11 Sep 2008 11:34:08 -0400 From: John C Klensin To: Ray.Bellis@nominet.org.uk Subject: Re: ETSI defining ASN.1 (with derived XML schema) Message-ID: <6C8203B25EDEE32DCA060A02@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Cc: jon.peterson@neustar.biz, 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --On Thursday, 11 September, 2008 16:13 +0100 Ray.Bellis@nominet.org.uk wrote: >> Did you also forward this to the ECRIT folks (and Fred)? If >> not, please do so -- it would seem to me, at least in my >> ignorance, that right way to approach this problem would be to >> extend the ECRIT model to deal with this type of message, >> rather than reinventing the wheel, much less by using ASN.1 >> as a starting point. > > John, > > Thus far, as I understand it, there has been a complete > seperation between the need to place a call in real-time to > the emergency services, and the potential requirements of the > law enforcement agencies for retrospective access to logs and > location information. > > This is also the case at NICC in the UK where we've been > working on the architecture for determining the location of > VoIP callers. > > I humbly suggest therefore that ECRIT is _not_ the place for > this work. Ray, Let me make a distinction that may not have been clear in my note to Patrik. >From his note, these people are designing a format for transmitting messages from law enforcement agencies and providers. Presumably, they are also addressing the other issues associated with such messages and their implications and processing. ECRIT deals with a different class of messages, but its work includes a format that the law enforcement agencies and providers are, among others, going to need to support. The WG has, I understand, been concerned about integrity and authentication of those messages. I dislike reinvention of the wheel. I think that having two uses for the same basic formats tends to strengthen, and promote deployment of, both applications. Conversely, I don't believe that encouraging law enforcement to use unique formats for their messages (and requests and/or demands) will deter them from sending such messages. If unique formats accomplish anything at all, it is to increase costs to taxpayers and to make it easier to hide the tracks associated with questionable investigations. Consequently, if ETSI is headed down this path, I think that ECRIT _formats_ (and maybe other work) would be a better starting point than ASN.1, a clean sheet of paper, and the intent to create an XML representation of the ASN.1 I did not, in any way, intend to suggest that the ECRIT WG get involved in this particular piece of work except, if needed, to advise them on compatibility of formats. best, john _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Sep 14 18:04:53 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 6D0123A6833; Sun, 14 Sep 2008 18:04:53 -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 B587F3A68AB for ; Sun, 14 Sep 2008 18:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 V1Ws1LBQUUGI for ; Sun, 14 Sep 2008 18:04:51 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id BBFAE3A67F9 for ; Sun, 14 Sep 2008 18:04:51 -0700 (PDT) Received: from [75.68.119.237] (port=61749 helo=[192.168.15.104]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Kf2WK-0001E1-56 for apps-discuss@ietf.org; Sun, 14 Sep 2008 18:04:52 -0700 Message-Id: <65185207-F48B-4C17-B87C-FD0CA0C23C99@standardstrack.com> From: Eric Burger To: apps-discuss@ietf.org In-Reply-To: <6C8203B25EDEE32DCA060A02@p3.JCK.COM> Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: ETSI defining ASN.1 (with derived XML schema) Date: Sun, 14 Sep 2008 21:04:57 -0400 References: <6C8203B25EDEE32DCA060A02@p3.JCK.COM> X-Mailer: Apple Mail (2.926) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: 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: multipart/mixed; boundary="===============1748755613==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1748755613== Content-Type: multipart/signed; boundary=Apple-Mail-101-467845232; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-101-467845232 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Pardon my ignorance, but is there something here more than X.693? On Sep 11, 2008, at 11:34 AM, John C Klensin wrote: > > > --On Thursday, 11 September, 2008 16:13 +0100 > Ray.Bellis@nominet.org.uk wrote: > >>> Did you also forward this to the ECRIT folks (and Fred)? If >>> not, please do so -- it would seem to me, at least in my >>> ignorance, that right way to approach this problem would be to >>> extend the ECRIT model to deal with this type of message, >>> rather than reinventing the wheel, much less by using ASN.1 >>> as a starting point. >> >> John, >> >> Thus far, as I understand it, there has been a complete >> seperation between the need to place a call in real-time to >> the emergency services, and the potential requirements of the >> law enforcement agencies for retrospective access to logs and >> location information. >> >> This is also the case at NICC in the UK where we've been >> working on the architecture for determining the location of >> VoIP callers. >> >> I humbly suggest therefore that ECRIT is _not_ the place for >> this work. > > Ray, > > Let me make a distinction that may not have been clear in my > note to Patrik. > >> From his note, these people are designing a format for > transmitting messages from law enforcement agencies and > providers. Presumably, they are also addressing the other > issues associated with such messages and their implications and > processing. > > ECRIT deals with a different class of messages, but its work > includes a format that the law enforcement agencies and > providers are, among others, going to need to support. The WG > has, I understand, been concerned about integrity and > authentication of those messages. > > I dislike reinvention of the wheel. I think that having two > uses for the same basic formats tends to strengthen, and promote > deployment of, both applications. Conversely, I don't believe > that encouraging law enforcement to use unique formats for their > messages (and requests and/or demands) will deter them from > sending such messages. If unique formats accomplish anything at > all, it is to increase costs to taxpayers and to make it easier > to hide the tracks associated with questionable investigations. > > Consequently, if ETSI is headed down this path, I think that > ECRIT _formats_ (and maybe other work) would be a better > starting point than ASN.1, a clean sheet of paper, and the > intent to create an XML representation of the ASN.1 I did not, > in any way, intend to suggest that the ECRIT WG get involved in > this particular piece of work except, if needed, to advise them > on compatibility of formats. > > best, > john > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-101-467845232 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA5MTUwMTA0NTdaMCMGCSqGSIb3 DQEJBDEWBBTcZXp955lu5M8FelIf0WimdztgczCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQB0kq7teT0lqf/z+6SYY/V6CDJlq5N5g3AfTdiOQUu61I3P A77bXANyhMw4312tKIktiTW7D37KTJ1Gz0AYDd0VCmh3oqZbifUXv1UNYZDJD9nuch30kjO/phWL /oVaiCGB0h6LsJ+15oa3TI2+2z8nBqv+ONQe77EqBAIxNydQe39m3lGTzv7dLQyYMrOusX7Dzq1r uH6GXj45BuTiZdfVCgaM+NRDOYcV0STDnkf4ivipaXrWrd5mY/LZu7q1e3VmM0LMvIiHvxl5vBTB hqh4PwKY+Cr/nBNm/OiSaiNNJk3kx5kTq/qBnlq9SaY+i+FzG6NBU85UgKCaIZ4T0zrlAAAAAAAA --Apple-Mail-101-467845232-- --===============1748755613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1748755613==-- From apps-discuss-bounces@ietf.org Sun Sep 14 21:10:34 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 71E203A6863; Sun, 14 Sep 2008 21:10:34 -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 CB32F3A67F4 for ; Sun, 14 Sep 2008 21:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKRtruylAfGH for ; Sun, 14 Sep 2008 21:10:31 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id ECDD03A6863 for ; Sun, 14 Sep 2008 21:10:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 3FF5921A2BE8; Mon, 15 Sep 2008 06:10:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOSSnzLE1nsI; Mon, 15 Sep 2008 06:10:37 +0200 (CEST) Received: from [192.165.72.13] (unknown [192.165.72.13]) by srv01.frobbit.se (Postfix) with ESMTP id BB2D121A2BD7; Mon, 15 Sep 2008 06:10:37 +0200 (CEST) Message-Id: <9F221F51-F934-4B0B-9299-78FFE89861B4@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Eric Burger In-Reply-To: <65185207-F48B-4C17-B87C-FD0CA0C23C99@standardstrack.com> Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: ETSI defining ASN.1 (with derived XML schema) Date: Mon, 15 Sep 2008 06:10:37 +0200 References: <6C8203B25EDEE32DCA060A02@p3.JCK.COM> <65185207-F48B-4C17-B87C-FD0CA0C23C99@standardstrack.com> X-Mailer: Apple Mail (2.928.1) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Not if the original format really is a valid good ASN.1, no. And if I now understand correctly it is defined in ASN.1 because LI handover protocol(s) are defined using ASN.1. They have now added XML (via X. 693 I hope, I will check) just so people can choose XML if they want. Or rather, it is the other way around. They wanted to have XML format only, but people working with LI that uses ASN.1 and ber wanted to use the same base protocols for data retention. But my overall question was whether anyone in IETF was _also_ working with this ETSI standard, or if I am the closest individual (that only passively watch what ETSI is doing). Patrik On 15 sep 2008, at 03.04, Eric Burger wrote: > Pardon my ignorance, but is there something here more than X.693? > > On Sep 11, 2008, at 11:34 AM, John C Klensin wrote: > >> >> >> --On Thursday, 11 September, 2008 16:13 +0100 >> Ray.Bellis@nominet.org.uk wrote: >> >>>> Did you also forward this to the ECRIT folks (and Fred)? If >>>> not, please do so -- it would seem to me, at least in my >>>> ignorance, that right way to approach this problem would be to >>>> extend the ECRIT model to deal with this type of message, >>>> rather than reinventing the wheel, much less by using ASN.1 >>>> as a starting point. >>> >>> John, >>> >>> Thus far, as I understand it, there has been a complete >>> seperation between the need to place a call in real-time to >>> the emergency services, and the potential requirements of the >>> law enforcement agencies for retrospective access to logs and >>> location information. >>> >>> This is also the case at NICC in the UK where we've been >>> working on the architecture for determining the location of >>> VoIP callers. >>> >>> I humbly suggest therefore that ECRIT is _not_ the place for >>> this work. >> >> Ray, >> >> Let me make a distinction that may not have been clear in my >> note to Patrik. >> >>> From his note, these people are designing a format for >> transmitting messages from law enforcement agencies and >> providers. Presumably, they are also addressing the other >> issues associated with such messages and their implications and >> processing. >> >> ECRIT deals with a different class of messages, but its work >> includes a format that the law enforcement agencies and >> providers are, among others, going to need to support. The WG >> has, I understand, been concerned about integrity and >> authentication of those messages. >> >> I dislike reinvention of the wheel. I think that having two >> uses for the same basic formats tends to strengthen, and promote >> deployment of, both applications. Conversely, I don't believe >> that encouraging law enforcement to use unique formats for their >> messages (and requests and/or demands) will deter them from >> sending such messages. If unique formats accomplish anything at >> all, it is to increase costs to taxpayers and to make it easier >> to hide the tracks associated with questionable investigations. >> >> Consequently, if ETSI is headed down this path, I think that >> ECRIT _formats_ (and maybe other work) would be a better >> starting point than ASN.1, a clean sheet of paper, and the >> intent to create an XML representation of the ASN.1 I did not, >> in any way, intend to suggest that the ECRIT WG get involved in >> this particular piece of work except, if needed, to advise them >> on compatibility of formats. >> >> best, >> john >> >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Mon Sep 15 10:37:56 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 B20CA3A6BB4; Mon, 15 Sep 2008 10:37:56 -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 5D0823A6BA1; Mon, 15 Sep 2008 10:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.689 X-Spam-Level: X-Spam-Status: No, score=-106.689 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5Veu9BHwsr3; Mon, 15 Sep 2008 10:37:55 -0700 (PDT) Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by core3.amsl.com (Postfix) with ESMTP id AFB323A6BB4; Mon, 15 Sep 2008 10:37:55 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A4F4214221E; Mon, 15 Sep 2008 10:38:05 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dd5Tdkk5Y4aI; Mon, 15 Sep 2008 10:37:59 -0700 (PDT) Received: from [10.1.1.130] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 81E31142217; Mon, 15 Sep 2008 10:37:59 -0700 (PDT) Message-Id: From: Lisa Dusseault To: apps-discuss@ietf.org, APPS-REVIEW@ietf.org Mime-Version: 1.0 (Apple Message framework v928.1) Subject: HTML5 for email client implementors Date: Mon, 15 Sep 2008 10:38:00 -0700 X-Mailer: Apple Mail (2.928.1) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org I've been looking at HTML5 (http://www.w3.org/html/wg/html5/) and its gigantic spec, and discussing a bit with the W3C and IETF liaisons. It's a drastic new approach to HTML. One of the aspects I'd like to see get IETF input, is the expansion in scope of requirements. Can an email client be compliant with HTML5 -- is that a reasonable expectation? What about other software applications that use HTML but are not browsers? If you can take a look and answer this question, the HTML5 WG does of course encourage direct input to its mailing list (specified in doc linked above). A volunteer aka victim for that would be best, if not several. But if you can reply off-the-cuff to me or this group, that alone would be a good thing. thx, Lisa _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Mon Sep 15 12:46:05 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 B69AC3A68A0; Mon, 15 Sep 2008 12:46:05 -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 CF45F3A68A0; Mon, 15 Sep 2008 12:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQI9sKTpJUDz; Mon, 15 Sep 2008 12:46:02 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A08BB3A6885; Mon, 15 Sep 2008 12:46:01 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8FJk9Ue077538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 12:46:10 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 15 Sep 2008 12:46:07 -0700 To: Lisa Dusseault , apps-discuss@ietf.org, APPS-REVIEW@ietf.org From: Paul Hoffman Subject: Re: HTML5 for email client implementors 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 At 10:38 AM -0700 9/15/08, Lisa Dusseault wrote: >I've been looking at HTML5 (http://www.w3.org/html/wg/html5/) and its >gigantic spec, and discussing a bit with the W3C and IETF liaisons. >It's a drastic new approach to HTML. One of the aspects I'd like to >see get IETF input, is the expansion in scope of requirements. > >Can an email client be compliant with HTML5 -- is that a reasonable >expectation? What about other software applications that use HTML but >are not browsers? > >If you can take a look and answer this question, the HTML5 WG does of >course encourage direct input to its mailing list (specified in doc >linked above). A volunteer aka victim for that would be best, if not >several. But if you can reply off-the-cuff to me or this group, that >alone would be a good thing. A bit of history. The Internet Mail Consortium talked about HTML compliance about eight years ago and walked away from it. There was a strong user expectation that an HTML-encoded message would appear in the MUA the same as it would appear if opened in their favorite browser. At the time, there was not nearly as much renderer-sharing across applications as there is now. Because of that, some MUA vendors (including Microsoft) didn't show things the same as IE/Netscape did. The world renders differently now. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Wed Sep 17 06:21:06 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 C607B28C148; Wed, 17 Sep 2008 06:21:06 -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 C040E3A67C0 for ; Wed, 17 Sep 2008 06:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw6zlP0GpAiH for ; Wed, 17 Sep 2008 06:21:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3518D3A6A42 for ; Wed, 17 Sep 2008 06:21:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,415,1217808000"; d="scan'208,217";a="20042288" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Sep 2008 13:21:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8HDLG8U006761; Wed, 17 Sep 2008 15:21:16 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8HDLGMg004169; Wed, 17 Sep 2008 13:21:16 GMT Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Sep 2008 15:21:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: 6coexist and draft-wing-app-6coexist-00 Date: Wed, 17 Sep 2008 15:18:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6coexist and draft-wing-app-6coexist-00 Thread-Index: AckYx+d75RfmkcN9QA2fdkP7aOanIg== From: "Eric Vyncke (evyncke)" To: "Dan Wing (dwing)" , , X-OriginalArrivalTime: 17 Sep 2008 13:21:15.0888 (UTC) FILETIME=[43541700:01C918C8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6127; t=1221657676; x=1222521676; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evyncke@cisco.com; z=From:=20=22Eric=20Vyncke=20(evyncke)=22=20 |Subject:=206coexist=20and=20draft-wing-app-6coexist-00 |Sender:=20; bh=pYqR1N1mAzK8Dlql35+740KtDFiSt3itylWq672bgW4=; b=pRNonQbNhxHLm86TuQxvFI5jB+yUwmGYPBM40AhUIIzdKdPxWKjSjkQ7H+ KH/6N4bRlknwkT1CEaRGRYw/05p4pPOKwwdBwCSopj/jV7mEBRubRQUGb92+ GwPJvWt5zN; Authentication-Results: ams-dkim-1; header.From=evyncke@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 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: multipart/mixed; boundary="===============0034520720==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============0034520720== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C918C8.4322ABD0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C918C8.4322ABD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dan and Iljitsch, =20 I've read with interest your I-D, some quick comments: =20 - frankly, stating that 'IPv6 connectivity is poor' (in the intro) would = benefit from current data points (I'm afraid that IETF is shooting in = its foot if we continue to write such statements :)) - starting several connections to the same web server over several = networks (v4, v6, tunnels, translation) will probably not ease the task = of all 6to4 relays, Teredo servers in the transition period - not sure whether content provider will be happy to be bombarded by = several connections from the same client (specially as the server has = little clue to see that the requests come from same physical client) - you may want to do more than simply opening a TCP connection (small = packets), you may want to send more than 1,500 bytes in order to check = whether Path MTU discovery works - at least teredo requires a couple of RTT to get the first IPv6 packets = going through it, so, you may want to move Teredo to the top of your = connectivity check - in its essence, it is looks like an asymmetric ICE =20 Regarding the question of whether to have www.example.com and = ipv6.example.com and _WHICH_ party (server vs. client) decides, I've = recently played with some JavaScript to verify whether IPv6 connectivity is there and if IPv6 connectivity is reliable, = the JS redirects immediately the browser to ipv6.example.com. This is = actually the reverse of your I-D as it is the server which decides. =20 See also draft-vyncke-http-server-64aware-00 = = which describes further the technique. No rocket science as you'll see = ;-) =20 Hope this helps =20 -=E9ric =20 ------_=_NextPart_001_01C918C8.4322ABD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dan = and=20 Iljitsch,
 
I've = read with=20 interest your I-D, some quick comments:
 
-=20 frankly, stating that 'IPv6 connectivity is poor' (in the = intro) would=20 benefit from current data points (I'm afraid that IETF is shooting = in its=20 foot if we continue to write such statements :))
- = starting several=20 connections to the same web server over several networks (v4, v6, = tunnels,=20 translation) will probably not ease the task of all 6to4 relays, Teredo = servers=20 in the transition period
- not = sure whether=20 content provider will be happy to be bombarded by several connections = from the=20 same client (specially as the server has little clue to see that the = requests=20 come from same physical client)
- you = may want to do=20 more than simply opening a TCP connection (small packets), you may want = to send=20 more than 1,500 bytes in order to check whether Path MTU discovery=20 works
- at least teredo requires a couple of RTT to = get the=20 first IPv6 packets going through it, so, you may want to move Teredo to = the top=20 of your connectivity check
- in = its essence, it=20 is looks like an asymmetric ICE
 
Regarding the=20 question of whether to have www.example.com=20 and ipv6.example.com and _WHICH_ party (server vs. client) decides, I've = recently played with some JavaScript to verify
whether IPv6=20 connectivity is there and if IPv6 connectivity is reliable, the JS = redirects=20 immediately the browser to ipv6.example.com. This is actually = the reverse=20 of your I-D as it is the server which decides.
 
See also=20 draft-vyncke-http-server-64aware-00 which describes further the technique. No = rocket science=20 as you'll see ;-)
 
Hope = this=20 helps
 
-=E9ric
 
------_=_NextPart_001_01C918C8.4322ABD0-- --===============0034520720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0034520720==-- From apps-discuss-bounces@ietf.org Wed Sep 17 17:31:34 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 EB11F3A69BC; Wed, 17 Sep 2008 17:31:34 -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 AFBE23A69BC for ; Wed, 17 Sep 2008 17:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=-0.299, 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 r19Pv-Zdu6Ax for ; Wed, 17 Sep 2008 17:31:32 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 104E83A682E for ; Wed, 17 Sep 2008 17:31:32 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so3193685wfc.22 for ; Wed, 17 Sep 2008 17:31:45 -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:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=VEu9h5n0tZ4sTCzN3WvJud+dJ+qLtMRA120peUIOOf8=; b=KZeuyNjvS7WT+uhgDgnWWd3UPsMONkdwEPHC6eqVvBReVcB8U/NrTuTtC7+gMJDSfW i6xR81x4oRluSb0yAPEzZMhcfDoWURuc9OTNKeQ0SaylnNs2QX/LiBvsA3/I5DsvR8cg 3BZuLIi9xI+U5KQrr3ecH9yPcroyxS+qZysMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=BPEgL3WzyHUUZoA63RYHQ05sSUsZCJJ/wn9yd1hCXMn/XxXwnjQt9BGBQBF0phYo99 TLN7uU3gUCwdhE19DZs0CRc6fe5y5a/Xdo/4qwjF4wcmjdCbZljddx2NROOpPG8jO6OM o5mmlEkNVCE0VPvD4PjQFmGe4MLQHgnqG67nA= Received: by 10.142.139.19 with SMTP id m19mr1143875wfd.154.1221697905139; Wed, 17 Sep 2008 17:31:45 -0700 (PDT) Received: by 10.142.242.5 with HTTP; Wed, 17 Sep 2008 17:31:45 -0700 (PDT) Message-ID: Date: Wed, 17 Sep 2008 20:31:45 -0400 From: "Anthony Bryan" To: "Nathan Myers" Subject: Re: Metalink XML Download Description Format (draft-bryan-metalink-02) MIME-Version: 1.0 Content-Disposition: inline Cc: Nathan Myers , general discussion of application-layer protocols 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 On Tue, Sep 9, 2008 at 7:27 PM, Nathan Myers wrote: > On Tue, Sep 09, 2008 at 06:11:35PM -0400, Anthony Bryan wrote: >> On Tue, Sep 9, 2008 at 5:29 PM, Nathan Myers wrote: >> > Anthony, >> > >> > I have skimmed the Metalink draft. >> >> Hi Nathan. Thanks for taking the time to do so. Do you mind ccing >> discuss@apps.ietf.org or allowing me to? Public comments are good. :) > > You may cc with whatever bits of sense remain after you've > eviscerated me enough. It's all friendly discussion, sorry for the delay! >> > My first concern is that there probably should be a sparse hash >> > defined, for cases where hashing the whole file is prohibitively >> > expensive. One practical approach is to do a regular checksum >> > (md5, sha) on a fixed-size subset of the file, distributed in >> > chunks throughout. This could be implemented with attributes, >> > e.g. "sparsechunksize=" and "numsparsechunks". The spacing >> > between chunks would need to be defined rigorously, particularly >> > near EOF, such that the beginning and end of the file always >> > get summed, and for small files, so that it degenerates cleanly >> > to a regular full-file checksum. >> >> I haven't heard of this before, is it used elsewhere? > > I know it only from proprietary products. > >> If I understand correctly, would it be enough to use the already >> defined chunk/piece checksums and just omit some from the file? >> >> Here's what this looks like now, minus most of the chunks. >> >> >> 579be26a5dd7957394c4d69e72e0127d >> 0156e8d36971ae2bae50dfc14c96ac47675ee5a6 >> c65613b5bf9853773b68e2498616e1499fc0b9e41f73a5726c95a8fe55f44650 >> >> cdc92a8fd1477850e9fd466334769e040ba313bb >> 2828c06d1034949787f4606bd73435551606fd4f >> 0527ddda2ae716cf56ac8a55f5bec1489e6f1b18 >> 46e433a1fc5d067ffe82c930f9a2dc9607560f4c >> 42c92d20fdc9c05a147be910c6f0840c5c4fbc86 >> ac23f5f017e5ba53456129c661285025f6366a22 >> >> > > Let's see if I understand this... Your fragment above has md5, sha-1, > and sha-256 hashes for the whole file, and then an sha-1 hash for each > range of bytes (0 to 2097151), (16*2097152 to 17*2097152-1), etc., > correct? I suppose the difference in what I had suggested was to > provide a way to deduce the list of pieces programmatically, along > with a summation of all the individual piece hashes, so the pieces > need not all be listed severally. Yes, all the hashes are optional, whether full file hashes or just for the chunks. I hadn't heard of that before, but I suppose you could just include the hashes for some chunks. The full file hashes aren't required if you don't want them or have the time to compute them. > My employer uses this to determine whether to send a file that might > already exist at the destination. When the files are 300GB, time > spent summing a whole file that will not actually be sent can be > prohibitively expensive. Would including only some of the chunk checksums be sufficient for your purposes? >> > I suspect it will be important to allow names for pieces. >> > It seems the natural way to implement file forks/streams. >> >> You mean being able to mix & match named parts of different files, or >> something else? > > Perhaps I am misunderstanding what pieces are about. > > On "modern" operating systems (including MSWin, Macosix, and Linux) > a file may contain not just bytes, but act as a sort of subdirectory > containing what amount to additional, oddly-named files. On MSWin, > these are called "streams". Apple calls them "forks". They record > additional bytes that a call "read(open(fname,0),buf,~0)" would not > reveal. The regular file contents amount to a default stream/fork, > one of potentially many. To copy such a file correctly, you must copy > its regular data, and also all its associated sub-files. > > For your purposes, it might suffice to list the names and metadata > of the sub-files as separate files, using their odd names, but the > odd names and delimiters aren't portable in the way "/" is. > Furthermore, most of the metadata for the sub-files is shared with > the parent file. > > This also suggests a need for more checksums; the present that > record the output of "cat f | md5sum" etc., and more that sum > the contents of all the file and subfile components. You're the first to mention this. Perhaps it can be dealt with as an extension to metalink? Unless other people feel that it should be dealt with in the metalink "core". >> > I wonder, idly, why to bother offering DES3 in-this-day-and-age. >> > Is it for uses that have hardware support for DES, but not AES, >> > or is it just a general policy that everything IETF should >> > support DES3? >> >> Where is DES3 mentioned? It's not in the Metalink Draft, so in the >> references? I'm trying to use references that mesh w/ IETF documents. >> If there is a more recently updated one, please let me know. >> Otherwise, I don't know about IETF policy enough. > > Maybe I'm misunderstanding section 5.2, Encryption: "Section 5.1 of > [REC-xmlenc-core] requires support of TripleDES, AES-128, and AES-256." I'm using the same references as the Atom XML format (RFC 4287). I don't see an updated version or replacement for [REC-xmlenc-core]. -- (( 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 From apps-discuss-bounces@ietf.org Fri Sep 19 08:17:36 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 EC9173A6873; Fri, 19 Sep 2008 08:17:36 -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 BFF2E3A6873 for ; Fri, 19 Sep 2008 08:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+KPSq-9knVK for ; Fri, 19 Sep 2008 08:17:34 -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 646B93A63CB for ; Fri, 19 Sep 2008 08:17:34 -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 m8JFHZ69028156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 19 Sep 2008 15:17:42 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: <20F2FA39-23DA-4D63-8DBB-B8BAAD93F343@Isode.com> From: Kurt Zeilenga To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v929.2) Subject: LDAP BOF requested Date: Fri, 19 Sep 2008 08:17:32 -0700 X-Mailer: Apple Mail (2.929.2) 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 FYI, an BOF has been requested to discuss the formation of a new WG to undertake LDAP standardization tasks, including revision of existing specifications and engineering of new LDAP extensions. A BOF description is available at: http://www.openldap.org/lists/ietf-ldapbis/200809/msg00004.html This BOF is being discussed on ldapext@ietf.org (primary) and ietf-ldapbis@openldap.org lists. Those interested in participating in the BOF (if approved), and a new LDAP WG (if approved) are encouraged to express their interest. -- Kurt _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Sep 20 16:26:08 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 683843A69AD; Sat, 20 Sep 2008 16:26:08 -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 2830F3A69BE for ; Sat, 20 Sep 2008 16:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=-0.287, 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 5gCEM9uRhF3w for ; Sat, 20 Sep 2008 16:26:06 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 32D003A69B4 for ; Sat, 20 Sep 2008 16:26:06 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so1058949wfc.22 for ; Sat, 20 Sep 2008 16:26:22 -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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fi3ecPgR00CyH7xGz+B9IDg9Lc+44un6mkWijm/wYkQ=; b=ZGHKQhZeZwJFJ+jLGCj2GuxqSIMh/4HEDQ1DzgOrkYVt2z7MIeApgir2o4uqqWdL38 ceobGepX2ojoBr1vsnajjhbecFs/dvDY6933atPrA6Ms1PlKiHSkUAIOWr2PVapZH3XE q27+Fr2hmYXI3dFe2UqesuTASOTOVpxvmXR/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aKHva7aFsWeYwdESq4RTInwjNg1r/XbZK2m+Os0vnmIqpG/KBlF0ybGsNCumerV+aj a7PR/gu+bns/SYfFfI1+VpT/6DtFGaJzjWpLspVa1kt8RJTzRifTDnktef/hQs0fJSB0 086UHAhye4og7VBHang6Tg5Yx+2mHybtT7g0I= Received: by 10.142.154.20 with SMTP id b20mr711094wfe.59.1221953182863; Sat, 20 Sep 2008 16:26:22 -0700 (PDT) Received: by 10.142.242.5 with HTTP; Sat, 20 Sep 2008 16:26:22 -0700 (PDT) Message-ID: Date: Sat, 20 Sep 2008 19:26:22 -0400 From: "Anthony Bryan" To: "general discussion of application-layer protocols" , "Applications Review List" , xml-dev@lists.xml.org, ietf-http-wg@w3.org Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <9235.1220345185.781391@peirce.dave.cridland.net> <48BD08D5.1070206@gmx.de> <48BE5645.70302@gmx.de> <48BE8F96.2010404@gmx.de> 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, An updated Internet Draft for Metalink is available at http://tools.ietf.org/html/draft-bryan-metalink-03 with interim revisions at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ . We're looking for review and public comments. 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. This updated version incorporates comments: - urn:ietf:params:xml:ns:metalink namespace & registration. - IANA "Operating System Names" registry for listing the OS that a file listed in a metalink is for. This registry would need to be updated to be useful. - new "Client Implementation Considerations" . Currently, this section mentions transparent content negotiation. Issues: - Inclusion of digital signatures other than PGP of files listed in the Metalink. (Only PGP is currently supported). What do we need to add and how might we need to restructure this for other digital signatures to be included/used? - Proxies. If a file listed in a metalink is already in a cache, but a different URI is used then I assume it won't be recognized and will be requested again since it seems to be an uncached file. I'm wondering if the checksums in a metalink or something else could be used to see if the file is the same or not. 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 From apps-discuss-bounces@ietf.org Sat Sep 20 16:29:33 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 C9E8F3A6892; Sat, 20 Sep 2008 16:29:33 -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 A2A133A6892 for ; Sat, 20 Sep 2008 16:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_UNSUB31=0.464] 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 lnxaPFPeOzqR for ; Sat, 20 Sep 2008 16:29:32 -0700 (PDT) Received: from zeus.hq.tvw.net (hq.tvw.net [195.137.32.199]) by core3.amsl.com (Postfix) with ESMTP id 14F273A6830 for ; Sat, 20 Sep 2008 16:29:31 -0700 (PDT) Received: from mail pickup service by zeus.hq.tvw.net with Microsoft SMTPSVC; Sun, 21 Sep 2008 00:28:40 +0100 x-endofinjectedxheaders: 5589 Received: from ms01.oasis-open.org [66.151.238.137] by thesitedoctor.co.uk with ESMTP (SMTPD-9.21) id A6DA02C8; Sun, 21 Sep 2008 00:27:22 +0100 Received: from [10.1.1.2] (helo=mail.oasis-open.org) by ms01.oasis-open.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) id 1KhBr7-0006bb-1e for asp@tvw.net; Sat, 20 Sep 2008 19:27:13 -0400 Received: (qmail 19579 invoked by uid 60909); 20 Sep 2008 23:24:33 -0000 Mailing-List: contact xml-dev-help@lists.xml.org; run by ezmlm Precedence: bulk Delivered-To: mailing list xml-dev@lists.xml.org Received: (qmail 19535 invoked by uid 0); 20 Sep 2008 23:24:33 -0000 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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fi3ecPgR00CyH7xGz+B9IDg9Lc+44un6mkWijm/wYkQ=; b=ZGHKQhZeZwJFJ+jLGCj2GuxqSIMh/4HEDQ1DzgOrkYVt2z7MIeApgir2o4uqqWdL38 ceobGepX2ojoBr1vsnajjhbecFs/dvDY6933atPrA6Ms1PlKiHSkUAIOWr2PVapZH3XE q27+Fr2hmYXI3dFe2UqesuTASOTOVpxvmXR/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aKHva7aFsWeYwdESq4RTInwjNg1r/XbZK2m+Os0vnmIqpG/KBlF0ybGsNCumerV+aj a7PR/gu+bns/SYfFfI1+VpT/6DtFGaJzjWpLspVa1kt8RJTzRifTDnktef/hQs0fJSB0 086UHAhye4og7VBHang6Tg5Yx+2mHybtT7g0I= Message-ID: Date: Sat, 20 Sep 2008 19:26:22 -0400 From: "Anthony Bryan" To: "general discussion of application-layer protocols" , "Applications Review List" , , In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <9235.1220345185.781391@peirce.dave.cridland.net> <48BD08D5.1070206@gmx.de> <48BE5645.70302@gmx.de> <48BE8F96.2010404@gmx.de> X-Antivirus-Scanner: ClamAV at OASIS detected no problems Subject: [xml-dev] Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01) X-RCPT-TO: Status: X-UIDL: 521453677 X-IMail-ThreadID: 86da01be0000c693 X-GFI-P2E: ZEUS X-OriginalArrivalTime: 20 Sep 2008 23:28:40.0594 (UTC) FILETIME=[9D4E2720:01C91B78] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, An updated Internet Draft for Metalink is available at http://tools.ietf.org/html/draft-bryan-metalink-03 with interim revisions at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ . We're looking for review and public comments. 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. This updated version incorporates comments: - urn:ietf:params:xml:ns:metalink namespace & registration. - IANA "Operating System Names" registry for listing the OS that a file listed in a metalink is for. This registry would need to be updated to be useful. - new "Client Implementation Considerations" . Currently, this section mentions transparent content negotiation. Issues: - Inclusion of digital signatures other than PGP of files listed in the Metalink. (Only PGP is currently supported). What do we need to add and how might we need to restructure this for other digital signatures to be included/used? - Proxies. If a file listed in a metalink is already in a cache, but a different URI is used then I assume it won't be recognized and will be requested again since it seems to be an uncached file. I'm wondering if the checksums in a metalink or something else could be used to see if the file is the same or not. Thank you, -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Mon Sep 29 08:05:43 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 9DDF63A68C6; Mon, 29 Sep 2008 08:05:43 -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 3FE6B3A68B3 for ; Sat, 27 Sep 2008 06:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG7T9Hgr7EBh for ; Sat, 27 Sep 2008 06:24:35 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 765C83A67F8 for ; Sat, 27 Sep 2008 06:24:35 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1254469rvf.49 for ; Sat, 27 Sep 2008 06:24:15 -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; bh=ut+3IXJcV3+C0DY6270qbu2V1g3MInGCyxxuFOi97zo=; b=kkrf4dLbc5aoI4Pe/dPcZ/lhQ8Di8C+d+3TfVWg70X1PScvnzJtq8WMpt3x4rcmZgj 53bRkWPN+4vHLzgMawRfayHYUzuOmlOsi81g2ojy/3kbkvjn9wrMc/U5AyCoKnEZL0Rg lkntsgQnkiav4fK1OzvfSyPudB5lGod3rEPwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=I7UjyySmB5bRz50uhqQ6R4VsoJunNt2FL+qsoi5y3exkfVSTrPz3dmMSxForpaACCZ ERyt2f+6NS9TaXdFj2GxBQ6UqvJ6fBfeuxLI7dPhSNeWibB8iyV0oYbdFa4g8LHZeoxV QyLawXNnr+3/BmtNMCGah2hokja+59Y/OyMrY= Received: by 10.142.12.14 with SMTP id 14mr1151339wfl.308.1222521855879; Sat, 27 Sep 2008 06:24:15 -0700 (PDT) Received: by 10.142.169.19 with HTTP; Sat, 27 Sep 2008 06:24:15 -0700 (PDT) Message-ID: <99e9ee830809270624q555d7227xee30c9864b15ea15@mail.gmail.com> Date: Sat, 27 Sep 2008 22:24:15 +0900 From: "Sumit Aggarwal" To: apps-discuss@ietf.org Subject: MPEG2 Streaming Over internet MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 29 Sep 2008 08:05:42 -0700 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: multipart/mixed; boundary="===============1588527165==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1588527165== Content-Type: multipart/alternative; boundary="----=_Part_19418_23962069.1222521855867" ------=_Part_19418_23962069.1222521855867 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, i want to know, if i want to stream MPEG2 TS over internet(unicast/brodcast) using RTP and receive it on TV, what are the fields in TS i should update by streaming server. i mean what are the fields in TS should be updated before streaming (Like PCR, PTS ..DTS) so that my TV decoder can understand the stream properly. Is there any global standard followed which is accepted by all the TVs. May be this is very basic question, but the problem i am facing is when i stream using RTP with out modifying any field in TS, TV decoder is not able to display it properly. But when i stream the TS using VLC, TV is able to display the picture perfectly. Regards Sumit ------=_Part_19418_23962069.1222521855867 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
i want to know, if i want to stream MPEG2 TS over internet(unicast/brodcast) using RTP and receive it on TV, what are the fields in TS i should update by streaming server.
i mean what are the fields in TS should be updated before streaming (Like PCR, PTS ..DTS) so that my TV decoder can understand the stream properly.
Is there any global standard followed which is accepted by all the TVs.
May be this is very basic question, but the problem i am facing is when i stream using RTP with out modifying any field in TS, TV decoder is not able to display it properly. But when i stream the TS using VLC, TV is able to display the picture perfectly.
Regards
Sumit
------=_Part_19418_23962069.1222521855867-- --===============1588527165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1588527165==-- From apps-discuss-bounces@ietf.org Tue Sep 30 03:52:14 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 2F0B13A6974; Tue, 30 Sep 2008 03:52:14 -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 686113A6951; Tue, 30 Sep 2008 03:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JliDd2d+ElD; Tue, 30 Sep 2008 03:52:12 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 5B4D33A67B4; Tue, 30 Sep 2008 03:52:12 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m8UApbPb019913; Tue, 30 Sep 2008 13:51:58 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Sep 2008 13:51:54 +0300 Received: from net.118.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Sep 2008 13:51:53 +0300 Message-Id: From: Lars Eggert To: ext Sumit Aggarwal In-Reply-To: <99e9ee830809270624q555d7227xee30c9864b15ea15@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: MPEG2 Streaming Over internet Date: Tue, 30 Sep 2008 13:51:50 +0300 References: <99e9ee830809270624q555d7227xee30c9864b15ea15@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 30 Sep 2008 10:51:54.0003 (UTC) FILETIME=[8CFFB630:01C922EA] X-Nokia-AV: Clean Cc: AVT Lista , 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-Type: multipart/mixed; boundary="===============1290339127==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1290339127== Content-Type: multipart/signed; boundary=Apple-Mail-5--348424809; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-5--348424809 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit This question is more in scope for the AVT list (CC'ed.) Lars On 2008-9-27, at 16:24, ext Sumit Aggarwal wrote: > Hi All, > i want to know, if i want to stream MPEG2 TS over internet(unicast/ > brodcast) > using RTP and receive it on TV, what are the fields in TS i should > update by > streaming server. > i mean what are the fields in TS should be updated before streaming > (Like > PCR, PTS ..DTS) so that my TV decoder can understand the stream > properly. > Is there any global standard followed which is accepted by all the > TVs. > May be this is very basic question, but the problem i am facing is > when i > stream using RTP with out modifying any field in TS, TV decoder is > not able > to display it properly. But when i stream the TS using VLC, TV is > able to > display the picture perfectly. > Regards > Sumit > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-5--348424809 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDkzMDEwNTE1MVowIwYJKoZI hvcNAQkEMRYEFGp68eN7NoCdKT6maJJfaJ2urXUcMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQC2fkS/EekfC6dlL8lnYTaEtCjP 3Mk6A/ghtS1OdZ+yO12WTnFHBJzDV+WOXa3CiK88DfD6vSdXBqZE17YXbVNl7awSerlUOvLMMxPc 0QZ0oz8RcypgXeDsFyOeuluZsU4GHY/rgGT4DDE8qMOPGeCPNqHFes0EEP8iddh+cxQKkX/3yC/D qHjWTGhSDpF8cdZg0+HoW9KgQgvPjhqnSPUlLiXJDycimJLeLWu6nofu82tAtAp5ruRG6RQf/sF+ XK7hyhrOjorRfS4Qi7O2/J5V4ST/JX6uaSOsJHuj0riFpFgiZOCjp5tQdsqbGZ2Ni8VacNaEJ5VQ Si3D3XvjmpahAAAAAAAA --Apple-Mail-5--348424809-- --===============1290339127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1290339127==--