From lisa.dusseault@gmail.com Thu Oct 1 16:38:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3513A63EC for ; Thu, 1 Oct 2009 16:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.878 X-Spam-Level: X-Spam-Status: No, score=-2.878 tagged_above=-999 required=5 tests=[AWL=-0.280, 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 J+xjmrtMPHFT for ; Thu, 1 Oct 2009 16:38:30 -0700 (PDT) Received: from mail-vw0-f185.google.com (mail-vw0-f185.google.com [209.85.212.185]) by core3.amsl.com (Postfix) with ESMTP id 631F13A67A7 for ; Thu, 1 Oct 2009 16:38:30 -0700 (PDT) Received: by vws15 with SMTP id 15so333920vws.5 for ; Thu, 01 Oct 2009 16:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=vp6VG9NwHEyWaxrmKexJl3h+x+xAhO9DVfWMY738Fys=; b=K9VE1J4EDRQc3ju1dsSrLNO6XvBY3hqfxJNMZp8c5pqBsYe4wY8Qs45Wltk6pN6f33 v9Cr1Qrg2pzpdmGH458BM3NutXQ546fYt3HHQOMNTpbpPacI+YHY4T6MQkt6cVeJ9oX/ KxrP+TnQe8vMwUWQgsfu9hdVJDUI18E1HM/OU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rX/yYLooeg51s5llvREUNpEnX22QCTOpgn/J2+VG8KH57QduhYOfTayLN47qZIbZov CRXPKPwFsmogWEvGBNUMrRi5eqbFKDUQpFwdh/vugfbUa0OBdnQrT7LpRWeKWj565IAD 3nyj0iZbeQDRxfzmZZJpjb8zGmLhLleuZijkc= MIME-Version: 1.0 Received: by 10.220.107.164 with SMTP id b36mr3306883vcp.87.1254440393688; Thu, 01 Oct 2009 16:39:53 -0700 (PDT) Date: Thu, 1 Oct 2009 16:39:53 -0700 Message-ID: Subject: Lisa's Apps Area Activity Report for Sept 2009 From: Lisa Dusseault To: discuss@ietf.org, lisa-dusseault-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=00c09f971e8c0ecc2e0474e82a43 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 23:38:31 -0000 --00c09f971e8c0ecc2e0474e82a43 Content-Type: text/plain; charset=ISO-8859-1 *News, Updates* IETF 76 Bar BoF planning: http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs IETF 76 BOFs: HYBI: Bidirectional HTTP; Web sockets and related technologies that reverse the HTTP client-server initiation role. IRIs: Fixing problems with internationalized locators GROBJ: Referral objects to pass in applications DECADE: Using caches in P2P applications 6LOWAPP: Using REST and doing device commissioning among low-power devices Note that HTTP-STATE and ARF (Abuse Reporting for email) are not meeting as BOFs in Hiroshima, but are continuing work on their email lists towards chartering WGs at some point. *Document Status and Progress *Active documents, my action: - draft-ietf-sieve-mime-loop (PS): Checking to see if authors are OK with proposed resolution to Tim Polk's DISCUSS - draft-hammer-oauth (Info): Publication Requested, now I need to do AD review - draft-nottingham-site-meta (PS): Publication Requested, now I need to do AD review Active documents, waiting on other: - draft-ietf-idnabis-bidi (PS): In IETF Last Call - draft-ietf-idnabis-protocol (PS): In IETF Last Call - draft-ietf-idnabis-defs (PS): In IETF Last Call - draft-ietf-idnabis-tables (PS): In IETF Last Call - draft-ietf-idnabis-rationale (Info): In IETF Last Call - draft-ietf-idnabis-mappings (Info): In IETF Last Call - draft-montemurro-gsma-imei-urn (Exp): New version of draft expected - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup - draft-ietf-calsify-2446bis (PS): Awaiting revision to clear DISCUSS issues - draft-wilde-sms-uri (PS): Waiting for ADs with DISCUSS issues to read & respond - draft-freed-sieve-in-xml (PS): Waiting for revision from authors & WG consensus on new format for comments - draft-nottingham-http-link-header (PS): Waiting for revision from authors Finished processing -- new in RFC Ed queue and new RFCs - draft-ietf-alto-problem-statement (Info): Approved, in RFC Ed queue WG Status ALTO: Some light discussions in the last month. CALSIFY: Not much discussion while RFC2446 completes publication. HTTPBIS: Tracker issue discussion, along with discussion of the Metalink draft for multiple download locations. IDNABIS: IETF Last Call has started for all WG documents. OAUTH: Good discussion of algorithm selection, constraints and other issues. Also note draft-hammer-oauth proposed for individual submission to Informational status document. SIEVE: WG Discussion of error handling. Note that most of these WGs are not meeting in Hiroshima; some are nearly finished (CALSIFY, IDNABIS), others don't have critical mass attendance (OAUTH, HTTPBIS, SIEVE). In contrast, see the list of APPS BOFs at top that are meeting. --00c09f971e8c0ecc2e0474e82a43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable News, Updates
IETF 76 Bar BoF planning: http://trac.tool= s.ietf.org/area/app/trac/wiki/BarBofs
IETF 76 BOFs:
=A0=A0=A0 HY= BI:=A0 Bidirectional HTTP; Web sockets and related technologies that revers= e the HTTP client-server initiation role.
=A0=A0=A0 IRIs: Fixing problems with internationalized locators
=A0=A0= =A0 GROBJ:=A0 Referral objects to pass in applications
=A0=A0=A0 DECADE:= Using caches in P2P applications
=A0=A0=A0 6LOWAPP:=A0 Using REST and d= oing device commissioning among low-power devices
=A0=A0=A0
Note that HTTP-STATE and ARF (Abuse Reporting for email) are = not meeting as BOFs in Hiroshima, but are continuing work on their email li= sts towards chartering WGs at some point.

Document Status and Pro= gress
Active documents, my action:
- draft-ietf-sieve-mime-loop (PS): Chec= king to see if authors are OK with proposed resolution to Tim Polk's DI= SCUSS
- draft-hammer-oauth (Info): Publication Requested, now I need to = do AD review
- draft-nottingham-site-meta (PS): Publication Requested, now I need to do = AD review

Active documents, waiting on other:
- draft-ietf-idnabi= s-bidi (PS): In IETF Last Call
- draft-ietf-idnabis-protocol (PS): In IE= TF Last Call
- draft-ietf-idnabis-defs (PS): In IETF Last Call
- draft-ietf-idnabis-t= ables (PS): In IETF Last Call
- draft-ietf-idnabis-rationale (Info): In = IETF Last Call
- draft-ietf-idnabis-mappings (Info): In IETF Last Call - draft-montemurro-gsma-imei-urn (Exp): New version of draft expected
- = draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and w= riteup
- draft-ietf-calsify-2446bis (PS): Awaiting revision to clear DISCUSS issue= s
- draft-wilde-sms-uri (PS): Waiting for ADs with DISCUSS issues to rea= d & respond
- draft-freed-sieve-in-xml (PS): Waiting for revision fr= om authors & WG consensus on new format for comments
- draft-nottingham-http-link-header (PS): Waiting for revision from authors=

Finished processing -- new in RFC Ed queue and new RFCs
- draft-= ietf-alto-problem-statement (Info):=A0 Approved, in RFC Ed queue


WG Status

ALTO: Some light discussions in the last month.
CALSIFY= : Not much discussion while RFC2446 completes publication.
HTTPBIS: Trac= ker issue discussion, along with discussion of the Metalink draft for multi= ple download locations.
IDNABIS:=A0 IETF Last Call has started for all WG documents.
OAUTH: Good= discussion of algorithm selection, constraints and other issues.=A0 Also n= ote draft-hammer-oauth proposed for individual submission to Informational = status document.
SIEVE:=A0 WG Discussion of error handling.

Note that most of these = WGs are not meeting in Hiroshima; some are nearly finished (CALSIFY, IDNABI= S), others don't have critical mass attendance (OAUTH, HTTPBIS, SIEVE).= =A0 In contrast, see the list of APPS BOFs at top that are meeting.


--00c09f971e8c0ecc2e0474e82a43-- From stpeter@stpeter.im Fri Oct 2 15:00:55 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9180E3A6912 for ; Fri, 2 Oct 2009 15:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtW8fZjjJ1Nr for ; Fri, 2 Oct 2009 15:00:54 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A3F523A68FB for ; Fri, 2 Oct 2009 15:00:54 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 15DE1400E8 for ; Fri, 2 Oct 2009 16:02:22 -0600 (MDT) Message-ID: <4AC6786E.2020101@stpeter.im> Date: Fri, 02 Oct 2009 16:02:22 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: Server Identity Verification in Application Protocols X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 22:00:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A new version of draft-saintandre-tls-server-id-check is available: http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt Other than the informational appendix, the diff from the -01 version is relatively minor. Feedback is welcome. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrGeG4ACgkQNL8k5A2w/vzsrQCgzyFjxSkoQBp3PVqUmC4/p741 0HgAniMwjH+eUXwpokRKU8ZXcIJlEDLu =7pso -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Sat Oct 3 11:29:43 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1AE828C0E1 for ; Sat, 3 Oct 2009 11:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=-1.261, 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 fhdFnXHa-6xY for ; Sat, 3 Oct 2009 11:29:43 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E0DE13A6905 for ; Sat, 3 Oct 2009 11:29:42 -0700 (PDT) Received: from [92.40.74.130] (92.40.74.130.sub.mbb.three.co.uk [92.40.74.130]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 3 Oct 2009 19:31:12 +0100 Message-ID: <4AC79842.20501@isode.com> Date: Sat, 03 Oct 2009 19:30:26 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "apps-discuss@ietf.org" Subject: Off-topic: social event in Hiroshima MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 18:29:43 -0000 Hi, Instead of emailing people directly, I thought it would be easier to ask on the mailing list. For people who are planning to attend the social event in Hiroshima, can you please let me know off-list about that. I am deciding about whether I should go to the social event, so a good company might help to decide in favor. Regards, Alexey From julian.reschke@gmx.de Sun Oct 4 02:06:53 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581443A681E for ; Sun, 4 Oct 2009 02:06:53 -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=-3.362, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM+bDk-VRQ0v for ; Sun, 4 Oct 2009 02:06:53 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B52FA3A6358 for ; Sun, 4 Oct 2009 02:06:52 -0700 (PDT) Received: (qmail invoked by alias); 04 Oct 2009 09:01:44 -0000 Received: from p508FF57B.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.245.123] by mail.gmx.net (mp044) with SMTP; 04 Oct 2009 11:01:44 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Tt/Ert1ATv9y3E9+rEPylf3S0S7w0Y+qQdY7yWC qUwQOsNKkCe0GT Message-ID: <4AC86475.50907@gmx.de> Date: Sun, 04 Oct 2009 11:01:41 +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: Calsify , CardDAV , Apps Discuss Subject: Re: Call for feedback on HTML5 spec on "predefined vocabularies" References: <4A8010B3.1050100@gmx.de> In-Reply-To: <4A8010B3.1050100@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 09:06:53 -0000 FYI: the predefined vocabularies are gone for now, see: BR, Julian Julian Reschke wrote: > Hi, > > (cross-posted to IETF apps-discuss, plus vcarddav and calsify mailing > lists) > > the W3C HTML Working Group is currently preparing a new Working Draft > for HTML5. This will be based on the current Editor's Draft at > ). > > A significant change since the last Working Draft is the introduction of > "microdata", a way to augment the markup with semantics, similar to and > competing with RDFa and microformats in general (see > ). > > As part of introducing microdata, the spec also defines several > "predefined vocabularies". Some of them are based on IETF formats (and > this is why I'm writing this particular email). > > One of these vocabularies is "vcard" (see > ). As far as I can > tell, the HTML spec more or less duplicates information from RFC 2426, > and while doing so also introduces specific compliance criteria. It does > *not* refer to > , so, as far > as I can tell, it would hardwire the vocabulary to a soon-to-be-outdated > version of the spec, and also removes the inherent extensibility model. > > Another predefined vocabulary is "vevent" (see > ), to which similar > observations apply. > > I have talked to this to many W3C and IETF people, and as far as I can > tell, almost all of them consider this to be a Bad Idea. In particular, > it seems that the author has not even tried to co-ordinate with the two > applicable IETF Working Groups (I just checked the mailing list > archives, and couldn't find anything, but maybe I'm missing something). > > I'm not sure whether the two working groups have considered this issue > yet. I encourage to look at the spec now > (), or as soon as a new > Working Draft is published. > > In case the Calsify and/or Vcarddav Working Groups want to comment on > this, I encourage the chairs to send feedback directly to the W3C HTML > WG, so that the feedback gets the proper attention. > > Best regards, Julian > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From cyrus@daboo.name Sun Oct 4 12:49:18 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16263A683C for ; Sun, 4 Oct 2009 12:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 YxwykNG5Y7cH for ; Sun, 4 Oct 2009 12:49:18 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 0C4733A6782 for ; Sun, 4 Oct 2009 12:49:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 87509220621; Sun, 4 Oct 2009 15:50:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gU8jDusfsmuS; Sun, 4 Oct 2009 15:50:49 -0400 (EDT) Received: from [10.0.128.19] (unknown [75.16.26.133]) by daboo.name (Postfix) with ESMTPSA id 33027220616; Sun, 4 Oct 2009 15:50:47 -0400 (EDT) Date: Sun, 04 Oct 2009 12:50:45 -0700 From: Cyrus Daboo To: Peter Saint-Andre , apps-discuss@ietf.org Subject: Re: Server Identity Verification in Application Protocols Message-ID: In-Reply-To: <4AC6786E.2020101@stpeter.im> References: <4AC6786E.2020101@stpeter.im> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=976 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 19:49:19 -0000 Hi Peter, --On October 2, 2009 4:02:22 PM -0600 Peter Saint-Andre wrote: > A new version of draft-saintandre-tls-server-id-check is available: > > http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt > > Other than the informational appendix, the diff from the -01 version is > relatively minor. Feedback is welcome. Given the recent debate on the email SRV spec (which finished last call and I need to follow up on) should there be more discussion of exactly how a client should verify a server when it uses SRV to look it up? It seems to me it is not clear what a client should verify. i.e., client looks up the server._tcp name first, then connects to the server on the returned hostname. Should both the SRV name and the hostname in the SRV be verified in the cert? I would much rather this server identity spec deals with this issue, and would prefer to reference it from the email SRV spec and CalDAV one. -- Cyrus Daboo From lars.eggert@nokia.com Mon Oct 5 01:21:30 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD2628C154 for ; Mon, 5 Oct 2009 01:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 TIfdRrc+B6du for ; Mon, 5 Oct 2009 01:21:29 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id E12B128C0EA for ; Mon, 5 Oct 2009 01:21:28 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n958MsYW013320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Oct 2009 11:22:55 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-55--601615821; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <200909291410.QAA19651@TR-Sys.de> Date: Mon, 5 Oct 2009 11:22:54 +0300 Message-Id: <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> References: <200909291410.QAA19651@TR-Sys.de> To: ah@tr-sys.de X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Mon, 05 Oct 2009 11:22:55 +0300 (EEST) Cc: Stuart Cheshire , tsvwg , apps-discuss@ietf.org, draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, port-srv-reg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 08:21:30 -0000 --Apple-Mail-55--601615821 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-9-29, at 17:10, ah@tr-sys.de wrote: > I have followed up and studied the revised Port Number registry > draft, draft-ietf-tsvwg-iana-ports-02. thank you! We've been waiting for community feedback. > (A.1) Intended expansion of the Port# registry to Service Names > > The -02 draft revision has proposed to expand the Port Number > registry to also cover "Service Names" -- independent of the > assignment of port numbers to applications/services. > > There are lots of reasons to not do that in the proposed form. > > After discussions with driving forces from the Applications Area, > draft-gudmundsson-dns-srv-iana-registry-03.txt has reinforced and > reconciled the proposal for a dedicated Service Prefix registry. > Please refer to that draft for distinguishing details. I'm sorry, but I see little argumentation in draft-gudmunsson on why a separate registry is preferable. Yes, the IANA rules for port numbers should be stricter than for service names, but that does *not* mean that a separate registry is needed - it just means that the rules should be different. The main reason to have one registry is to make it easy for IANA and applicants to figure out which names are registered and which aren't. > > Here are the primary aspects that come to mind regarding the nature > and implementation of registration services for Port Numbers and > Service Prefixes: > > (a) Since there is an established and IETF-documented practice > for the use of "overlay" / "substrate" SRV Protocol labels, > Service Labels making use of these should be registered > in a similar manner as others containing proper "transport" > Protocols, under the same procedural rules. The database > proposed in draft-tsvwg-iana-ports-02 is neither prepared to, > nor suitable for, also accepting the registration of such > Service Prefixes not related to IETF transport protocols. Why do you think that? The unified registry contains service names, and is fully agnostic on what protocols those service names are used with. > (b) Most legacy applications with registered port numbers are > not prepared to use SRV RRs (yet); it does not make sense > to proactively register myriads of labels without having > any documentation on the use of service discovery for that > service, and without consent and knowledge of the original > applicants for port number assignment. Those labels are *already* registered, in the "keyword" column in the current IANA ports registry, and we don't know which ones are used and which ones aren't. Which is why we're keeping them defined as they currently are (modulo some renaming in very few cases.) > (c) For compatibility with existing databases and APIs, > draft-tsvwg-iana-ports-02 essentially maintains the > 'classical' size restrictions for Service Names. > > APIs for (dynamic) service discovery will easily admit the use > of the common 63-character size for DNS labels (as established > by RFCs 1034/1035), for SRV Service labels as well. > > Applications making use of (dynamic) service discovery based > on DNS SRV have to be written to use such API, and if existing > applications previously bound to an assigned port number are > being upgraded to use service discovery, they need to be > modified to use such API anyway. > > Therefore, it makes sense to leave existing databases and APIs > for Service-Name-to-Port-Number lookup unchanged. I don't follow. Yes, we want to leave APIs and databases unchanged, which is why we're keeping the current size restriction. > (d) The imminent exhaustion of the port number space is recognized as > a reason to encourage the migration to service discovery for new > applications; draft-tsvwg-iana-ports-02 also acknowledges that. There is no danger of "imminent exhaustion" and if our draft leads you to believe that there is, we need to change it. System ports are somewhat scarce, but even there we have sufficient space left to last for years. > However, we believe that the procedures envisioned in that draft > are much too heavy-weight -- and too burdensome for IANA as > well -- for exerting a strong momentum towards service labels. First, let me point out that Michelle is co-authoring the draft *because* we want to make sure that these rules are easier for IANA to apply than what currently exists. Second, the purpose isn't to do an advertisement campaign that creates a strong momentum for service names - the purpose is to come up with clear and simple registry maintenance rules. If as a secondary effect that means that service names become more widely used, great, but that's not a primary driver for this draft. > The compound database needed for draft-tsvwg-iana-ports-02 and > the Expert Review process inadequately address the needs -- of > both the prospective applicants and the registry maintainers. The intent is that no expert review is involved for a service name allocation. Expert review only happens for a port number allocation, like it does currently. Under the new rules, a service name can be allocated FCFS without expert review. (I just realized that -02 does actually not yet contain this - we need to submit -03.) > (e) The Port Numbers registry and the SRV Service Prefix registry > serve very different purposes: > i) registration of and lookup of assigned port numbers > ii) registration of Service Prefixes actually defined for > service discovery. (ii) is *your* interpretation. In my reading, the SRV RR RFC makes it clear that any service name allocated in the ports registry should be usable with SRV RRs. > Due to the vastly different sice of the available namespace, > both registries need different assignment/registration policies. True. But that does *not* mean that we need two registries. It just means that we need two sets of procedures. > For the Service Prefixes (with the exception of the establishment > of new Protocol Labels), an extremely lightweight procedure is > needed where the role of the IANA is confined to checking > uniqueness (avoiding registry-internal collisions and collisions > of new Service Labels with Service Names already registered in > the Port Numbers registry for other services Correct. The intent is FCFS. > The Port Number registry is heavily constrained by the 16-bit > namespace available, with the additional pressure resulting > from the security critical need for client port randomization > to only assign as few as possible additional port numbers. Randomization doesn't come into play here, because it's used for the source ports, whereas the registry is for destination ports. > It is the basic nature of such restricted namespace that the > IANA registry for it needs to be under *assignment* paradigm. > The port number registry should be regarded as "almost closed" > (reserved for cases where service discovery is impossible), > and it needs rigid and tight management and strict IANA policy. No, this is MUCH to restrictive. We're NOT trying to make it harder to get a port number than it is currently. Port numbers remain the primary service identification method in the Internet. And yes, I agree that SRV RRs should be something that should be used more often. But making it harder to get port numbers only means more squatting. SRV RRs need to become attractive based on their own merits, and not because port number are hard to get. > Merging such different registries appears as a nightmare for IANA > and prospective applicants, and all 'consumers' of the registry. > The complicated amalgamated specification needed for the IANA > procedures for such registry is contrary to the principles of > clarity and simplicity. FUD. IANA seems to like our proposal. For port number registrants, nothing changes much (except that the rules are now documented.) For service name registrants, nothing changes much. > (f) The management of a narrow/scarce namespace (port numbers) > should not be conflated with the management of an ample > namespace; hence the need to have two independent registries, > with existing service names in the Port Numbers registry > implicitly reserved for use as Service Labels as well > (for all Protocols) for the same application. See above, you repeated this point for the third time now. > (g) New applications/services initially registering a SRV Service > Prefix but not applying for the assignment of a dedicated > port number are very unlikely to do that later. Maybe yes, maybe no. In our scheme, it's possible, which is nice because it leaves the option. I'm skipping your editorial comments for now. Thanks, Lars --Apple-Mail-55--601615821 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAwNTA4MjI1NVowIwYJKoZIhvcNAQkEMRYEFJnudbyy4bA5UgBv9DcGbVn4kGYuMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCFKNJ5WSKEdcErDzZucRvg5BvMOgbcq+ip2Xja/kUlYvxShtOka09P4DFPzkIMD3TBZjLa WU0/u0vPgM4IkG9Jq3fMQbgkzk9e8GRoocsR2jCMfjHELVs+/sRWbf+xra+FKC+FRKC/jrY6Og56 MCZYXRWaPIw00LeNwl2D8I61raL1DawB2lFsibt4jbnwdMV7ZqdR+/g1b905saD2+y8cXOwssWHJ Z8izM47Vjcpn5/x5RLS4c1V88nAz7g+50p3O9sr8e7+mE9l+MKO5nOsI2MLEkvzcpbgkrli1M9Ig qWPAOdwqbtLOCnGCInsGgGgQxNqQdpwSsraiwXzXFyRwAAAAAAAA --Apple-Mail-55--601615821-- From lars.eggert@nokia.com Mon Oct 5 02:19:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4DF28C142; Mon, 5 Oct 2009 02:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 rhEVKwR2KIk4; Mon, 5 Oct 2009 02:19:15 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 7C86A3A6918; Mon, 5 Oct 2009 02:19:15 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n959KYJ1016472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Oct 2009 12:20:34 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-60--598156442; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> Date: Mon, 5 Oct 2009 12:20:33 +0300 Message-Id: <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> To: Fernando Gont X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Mon, 05 Oct 2009 12:20:34 +0300 (EEST) Cc: Stuart Cheshire , "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 09:19:16 -0000 --Apple-Mail-60--598156442 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-10-5, at 12:15, Fernando Gont wrote: On Mon, Oct 5, 2009 at 5:22 AM, Lars Eggert wrote: > >>> The Port Number registry is heavily constrained by the 16-bit >>> namespace available, with the additional pressure resulting >>> from the security critical need for client port randomization >>> to only assign as few as possible additional port numbers. >> >> Randomization doesn't come into play here, because it's used for >> the source >> ports, whereas the registry is for destination ports. > > Ephemeral ports (and randomization) do come into play. ... > Therefore, these implementations of the > TCP API should enforce a stricter requirement for the allocation of > port numbers: port numbers that are in use by a TCP in the LISTEN or > CLOSED states should > not be allowed for allocation as ephemeral ports. Oh, I agree with excluding LISTEN/CLOSED. But Alfred's point was that we shouldn't be *allocating* port numbers; presumably because he believes that the act of allocation removes them from the randomization pool - which isn't the case. Lars --Apple-Mail-60--598156442 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAwNTA5MjAzNFowIwYJKoZIhvcNAQkEMRYEFFDtOD9biD64hR/wQz7uVhF2/YSwMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBgmxGHF/HYzJcWGALdxegwBHGv7oFZYpKZp1GSMM333hgel02g8KbyZmOJU6W+K7d/9cPo /wecdaPQY9OXu4qFNITQUKWAHB8AkQUpyHlSFKRgPuMmI/+oLjwpf/3IcXIYqadyLqgYJ6et0V8F 9PAJu7WwoS9gY8BgVrlKgHKry28iYtFu1CN9CZQqTI4fqaRE6IpKzu39GFa+wtTg+9/x7eqMM1Aq DlLqPddmSuumnm+ZACzqdokTfTiZjQmJW9Nr5GQxdJEmZcrBwGj+kN7m/yQ+9pLlky7EJ0RLV7hL dMpQIywwXjaetGGs9v9AxRPneGU5CSy3fb2ithEqwupgAAAAAAAA --Apple-Mail-60--598156442-- From fernando.gont.netbook@gmail.com Mon Oct 5 02:13:32 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FE428C159; Mon, 5 Oct 2009 02:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp0fg7NM4aoG; Mon, 5 Oct 2009 02:13:31 -0700 (PDT) Received: from mail-vw0-f117.google.com (mail-vw0-f117.google.com [209.85.212.117]) by core3.amsl.com (Postfix) with ESMTP id EEC8728C169; Mon, 5 Oct 2009 02:13:30 -0700 (PDT) Received: by vws15 with SMTP id 15so35353vws.5 for ; Mon, 05 Oct 2009 02:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=fiIarVzNpPQiYg4Kvw+Eq3qOBXxRGtcHucbBa/66DEc=; b=EZbPMyfVf3sSr8hkU1OSm3g2XyEpBrqsvWmdcKYaKB0dfSZKDc+ghsxje72EeYULnF P4GiVFnzJYvXZES5+8k5243bbxc2HuhXPXTYtAjkHKo0io12zFHRUR3DGr3MPMCgBMwM SXbZZNoQ36V7ObIbGpdTEfLoUXalYUoGBu8Fg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rAm/SukMKVBKw/k0kVlbHYcw67Zqha0gkdnWBYHg5TqVSu2tiYD0Q58eI61Op4KMLp ZG1E31DuPpBkSuog5mnTbTnMCiZEkP4f+L2DgqUXfT6oUqmkSaNKxivRa9xmAzYcWHjU 1UdvJu+neavGxVvw89OWvQ29PtdLKrDI8HvO8= MIME-Version: 1.0 Sender: fernando.gont.netbook@gmail.com Received: by 10.220.107.103 with SMTP id a39mr9510484vcp.6.1254734100759; Mon, 05 Oct 2009 02:15:00 -0700 (PDT) In-Reply-To: <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> Date: Mon, 5 Oct 2009 06:15:00 -0300 X-Google-Sender-Auth: 8617939776738471 Message-ID: <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02 From: Fernando Gont To: Lars Eggert Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 05 Oct 2009 09:56:23 -0700 Cc: Stuart Cheshire , ah@tr-sys.de, tsvwg , apps-discuss@ietf.org, draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org, port-srv-reg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 09:13:32 -0000 On Mon, Oct 5, 2009 at 5:22 AM, Lars Eggert wrote: >> =A0 The Port Number registry is heavily constrained by the 16-bit >> =A0 namespace available, with the additional pressure resulting >> =A0 from the security critical need for client port randomization >> =A0 to only assign as few as possible additional port numbers. > > Randomization doesn't come into play here, because it's used for the sour= ce > ports, whereas the registry is for destination ports. Ephemeral ports (and randomization) do come into play. See Section 10.2 of the d. ocument "Security Assessment of the Transmission Control Protocol (TCP)" (available at: http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf) published by UK CPNI (or its IETF I-D counterpart draft-gont-tcp-security). This is an excerpt of the aforementioned document, for your convenience: ---- begin excerpt ---- 10.2. Active opens and binding sockets As discussed in Section 10.1, the =93OPEN=94 command specified in Section 3.8 of RFC 793 [Postel, 1981c] can be used to perform active opens. In case of active opens, the parameter =93local port=94 will contain a so-called =93ephemeral port=94. While the o= nly requirement for such an ephemeral port is that the resulting connection-id is unique, port numbers that are currently in use by a TCP in the LISTEN state should not be allowed for use as ephemeral ports. If this rule is not complied, an attacker could potentially steal=94 an incoming connection to a local server application by issuing a connection request to the victim client at roughly the same time the client tries to connect to the victim server application. If the SYN segment corresponding to the attacker's connection request and the SYN segment corresponding to the victim client =93cross each other in the network=94, and provided the attacker is able to know or guess the ephemeral port used by the client, a TCP simultaneous open scenario would take place, and the incoming connection request sent by the client would be matched with the attacker's socket rather than with the victim server application's socket. As already noted, in order for this attack to succeed, the attacker should be able to guess or know (in advance) the ephemeral port selected by the victim client, and be able to know the right moment to issue a connection request to the victim client. While in many scenarios this may prove to be a difficult task, some factors such as an inadequate ephemeral port selection policy at the victim client could make this attack feasible. It should be noted that most applications based on popular implementations of TCP API (such as the Sockets API) perform =93passive opens=94 in three steps. Firstly, the application obtains a file descriptor to be used for inter-process communication (e.g., by issuing a socket() call). Secondly, the application binds the file descriptor to a local TCP port number (e.g., by issuing a bind() call), thus creating a TCP in the fictional CLOSED state. Thirdly, the aforementioned TCP is put in the LISTEN state (e.g., by issuing a listen() call). As a result, with such an implementation of the TCP API, even if port numbers in use for TCPs in the LISTEN state were not allowed for use as ephemeral ports, there is a window of time between the second and the third steps in which an attacker could be allowed to select a port number that would be later used for listening to incoming connections. Therefore, these implementations of the TCP API should enforce a stricter requirement for the allocation of port numbers: port numbers that are in use by a TCP in the LISTEN or CLOSED states should not be allowed for allocation as ephemeral ports. An implementation might choose to relax the aforementioned restriction when the process or system user requesting allocation of such a port number is the same that the process or system user controlling the TCP in the CLOSED or LISTEN states with the same port number. ---- end excerpt ---- Kind regards, --=20 Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook@gmail.com Mon Oct 5 02:52:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540073A6921; Mon, 5 Oct 2009 02:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdTzWBxwSUyy; Mon, 5 Oct 2009 02:52:15 -0700 (PDT) Received: from mail-vw0-f117.google.com (mail-vw0-f117.google.com [209.85.212.117]) by core3.amsl.com (Postfix) with ESMTP id 548973A68C9; Mon, 5 Oct 2009 02:52:15 -0700 (PDT) Received: by vws15 with SMTP id 15so35769vws.5 for ; Mon, 05 Oct 2009 02:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=QqyL/JDW1EWOn8YMsJlZ6jw0w4D3Pn4wTXMXm+S5rgQ=; b=ZwNyvyjGRvOWuhNYz1FHHoUQbHJ8sPPiMTUUO+l4m0zn2oGjVsL1Od6i8wnaGJcSiB P9FDjxYdRQzq+4SA67VITvrG3TdFTjYCsn/ViHfq65W6p5gKzcSXbCGDuKwhTnQFFa86 uCpzMM2sHpVuq3xrrl+XI0hL/FCZkhFeMHCOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=vR68ERh+7tQ99X2lGUSAyP1DNEqlbQVtBJ66OE7laR51LJ6bHXkxDrEa1WXTextVqP pPaSo8RMdo/lBHH6zdYRqPfj8GJx+GS7h9qav8JwiLEz7PHy5YyfonpeZvFcahYvbmEY 2Shk/BZ1vK3rJwr+Y4dSRNdyucFRN6zaqBXKY= MIME-Version: 1.0 Sender: fernando.gont.netbook@gmail.com Received: by 10.220.116.137 with SMTP id m9mr9365760vcq.65.1254736427283; Mon, 05 Oct 2009 02:53:47 -0700 (PDT) In-Reply-To: <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> Date: Mon, 5 Oct 2009 06:53:47 -0300 X-Google-Sender-Auth: 0434ec74ad2f1047 Message-ID: <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02 From: Fernando Gont To: Lars Eggert Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 05 Oct 2009 09:56:23 -0700 Cc: Stuart Cheshire , "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 09:52:16 -0000 Hello, Lars, Comments inline.... >> Therefore, these implementations of the >> TCP API should enforce a stricter requirement for the allocation of >> port numbers: port numbers that are in use by a TCP in the LISTEN or >> CLOSED states should >> not be allowed for allocation as ephemeral ports. > > Oh, I agree with excluding LISTEN/CLOSED. > > But Alfred's point was that we shouldn't be *allocating* port numbers; > presumably because he believes that the act of allocation removes them from > the randomization pool - which isn't the case. (assuming you're talking about "allocating" in terms of the IANA's administrative process) Well, the act of IANA allocating ports (i.e., the administrative process) doesn't preclude you from anything (obviously). However, one would expect that if a port is allocated by IANA, it is because some server app will use it. At that point, for the reasons stated in the CPNI document, you should avoid using that port for the ephemeral ports. Which means that the more ports you allocate, the fewer ports you are assured you can use for the ephemeral ports without the security implications described in Section 10.2 of the CPNI document. (Whether taking the risk of being vulnerable to the aforementioned issues is still acceptable (or not) for a particular system/environment is another issue....) Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From iljitsch@muada.com Mon Oct 5 10:46:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B5FE28C125; Mon, 5 Oct 2009 10:46:36 -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 FQMiCJT9i-Ir; Mon, 5 Oct 2009 10:46:35 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 42CA428C213; Mon, 5 Oct 2009 10:46:35 -0700 (PDT) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n95HlYNF028679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Oct 2009 19:47:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum In-Reply-To: <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> Date: Mon, 5 Oct 2009 19:47:48 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> To: Fernando Gont X-Mailer: Apple Mail (2.1076) Cc: Stuart Cheshire , "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 17:46:36 -0000 On 5 okt 2009, at 11:53, Fernando Gont wrote: > However, one > would expect that if a port is allocated by IANA, it is because some > server app will use it. At that point, for the reasons stated in the > CPNI document, you should avoid using that port for the ephemeral > ports. First of all, server apps may use unallocated ports, too. Second, how are TCP stacks supposed to know that a port has been allocated? As far as I know, there are no issues with the normal practice of not caring about this. From robmcm@microsoft.com Mon Oct 5 13:09:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C443A68D3 for ; Mon, 5 Oct 2009 13:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ8LfSH8Wo3b for ; Mon, 5 Oct 2009 13:09:14 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B0A7D3A6835 for ; Mon, 5 Oct 2009 13:08:59 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 5 Oct 2009 13:10:38 -0700 Received: from TK5EX14MBXC127.redmond.corp.microsoft.com ([169.254.6.18]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Mon, 5 Oct 2009 13:10:28 -0700 From: Robert McMurray To: "'ah@TR-Sys.de'" , "john+ietf@jck.com" Subject: RE: fodder for the proposed FTP feature/cmd registry Thread-Topic: fodder for the proposed FTP feature/cmd registry Thread-Index: AQHKPtvgRYpMR6Mu40mGaip3215Cs5D3cV9A Date: Mon, 5 Oct 2009 20:10:27 +0000 Message-ID: References: <200909251700.TAA11690@TR-Sys.de> In-Reply-To: <200909251700.TAA11690@TR-Sys.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="_002_A5FC996C3C37DC4DA5076F1046B5674C082F5114TK5EX14MBXC127r_" MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 20:09:15 -0000 --_002_A5FC996C3C37DC4DA5076F1046B5674C082F5114TK5EX14MBXC127r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure if the attached file helps, but I put it together some months = ago as a quick reference to the list of FTP commands, their syntax, and any= possible reply codes that I could find. The introduction lists the RFCs th= at I used to gather the information. Thanks! Robert McMurray US-IIS Product Unit Email: robmcm@microsoft.com -----Original Message----- From: ah@TR-Sys.de [mailto:ah@TR-Sys.de]=20 Sent: Friday, September 25, 2009 10:01 AM To: john+ietf@jck.com Cc: apps-discuss@ietf.org Subject: fodder for the proposed FTP feature/cmd registry John, as promised recently, I have performed some harvesting of RFCs and I-Ds to = collect material for the initial content of the IANA registry proposed in y= our I-D, draft-klensin-ftp-registry. Enclosed is a (still rough) tabulation of my results, listing all FTP comma= nds and FTP Features I found specified in RFCs (since roughly RFC 600, but = excluding gravestone dead FTP Mail stuff) and recent I-Ds. Kind regards, Alfred. --=20 +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ --_002_A5FC996C3C37DC4DA5076F1046B5674C082F5114TK5EX14MBXC127r_ Content-Type: application/pdf; name="FTP_Cheat_Sheet.pdf" Content-Description: FTP_Cheat_Sheet.pdf Content-Disposition: attachment; filename="FTP_Cheat_Sheet.pdf"; size=54470; creation-date="Mon, 05 Oct 2009 20:05:49 GMT"; modification-date="Mon, 05 Oct 2009 20:05:53 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcfsj6IKOCAwIG9iago8PC9MZW5ndGggOSAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nO2dSXPbNhzFp1d9Ct7qzFQoQYIg2FubpjOdSds00dGXxFk7cTY7Xb59qc2U Bo/WM03ZFPXsi/0TCf4JQHgPC4nPSWpslqTz3/UfZ+eTz5Pvn/rkzcXkcxJMPv9ZfLL599l58tOs Pqw+qTKVT2avJ6mpqpCWy1RsklU2yYMp68/OJyfTB7O/Jt6k1hZV/fHs5eQkiZGljmpLaxFNVn/g mnCqdTg2VImvSuPDIp5f5ifYwvisCqs0ZjF6EqMkRg9j9DZGr2L0PEaX1BWfdb0iQG1XXOSmddu5 6daFmzvjE18GsyzeRd4F46xP3ebNbaMXMXofo1cxSmL0MUavqRMfUml9iNElFSp34kVLqNMslKZy VTKtS2T+tdoujWyjKNb1Os0S70qTLev1r/OD6/9sXobNiLbRZYy+xOhjjF7G6GuMzqgrvqOuCKJP YnR6ErMXMfqPSozLCpD8OZUV4KjTB6syLlZlDGK0JkuzfEXMnOQmTYvSCQkJCQl1R/a2aS2a6NS4 Wpjtlk/Naxkvi62WfPvMxvO6a46argQiJNZuWbJQroxAkVlTbHmBb3Ybhzybn3NliLdlZxajJ5SA AtEDAgp0EKDnlCUAvuRit6Smxm9m+9AqpZCQkJCQ0IjRPXqvrGfv1dipHd7LusTb0ni3OPgx5Zfe xAgMoXy41vYMreyFhISEhISExoZG5Owas0Y4uzQzIdzO2YGjwETb5SqWa6eNQpq7QVQHISEhISEh ocNBI7JxjTPbbeOKEOZrIq+Wt+1cJMRNVV7E6HWMXlFXBHOvn6i4uOjBdCyICyzt4qInZmi16ElI SEjoiNB4/MaGhSD8RpmbzLUtxgJTfe8p4QUeAUj93S/ZPoBFYkP7YggJCQkJHaGVaNwBYSWKUId8 gwfCwAgEEGPQh+fEuE8rAZIHRugwDYdWpQsJCQnJJXRzCY3wEy7B5aZcjk78Rgk0mLoAogrGIIBA A8SJKkieWywDopdLEBISEhIaskvIe3YJjfATLiELJiwHHp5RagwUFKgxGEsAjgMMHHDvcPmR0n+A gNiDGwKh7nnYA9wjVxwgCFAcn3Y7Dq0kFhISOiA0IsluVJiQ7Plr+5ajAD93FSpwFLfakHt7Grdo 8O5XJYCjQFzcAztcqHfvGw5liEOGQ+hI0IiEqtGe3ULlqsos+6EPh9AmcW3l265X5LSFm8wenfAe gCgNrdEQErp/NB7patRo95szXXDGtY6KgjFK0ABxva5/qeYTtJVgTRe3FhwICejwgEFE7nkxLidA qOCGgAJxkqrGX0hISGhMhsD1bAgakSccga/Wm8v83qNacvOkoPcEBPQPKnkgjZ2fRgfvP+LWlXGO oLPreUrdI+hkAyvBTUhzAxxc3hNjp5lxqbvaHmloTYSQkNAABbToWUAbTSQEtHBmeSzYZQK0ldx6 HiA3YOemzo9S9ykkXGeWW8bcefOrPvcBuadBfc0qCgkJHZLwlj0L75WWEpOwLl2kRc/CgnYXoEHM Kj6i9JMbiOdsA9e9BXPItxs812vUhISEhI5N6Rv1JqQ+K4z12nNISEhISEhIaFRoRM6uMWuEs7N1 yNpySEhISEhISOhw0Yhc3JUx223i8qpY7zKpHYeuiUs7DgkJCQkJyW5s2Y0NC0H4jZCa0mvHof0u R72JBRnaF0NISEhI6AitROMOCCvhvbYbOjS3oY0EhISEhI7FIoSeLYKn/UFh1zsha68hWQQhISEh ocFZhKpni9AIP+EScm9yr72GdoWqvYaEhISEhoNGJNmNChOSXZ/jtdVQB0kFR2mroXsa4ZDfEDoS NCKdupIeQqZSv97yVlsN3Wwie3TCewCiNLRGQ0jo/tGIpKuRo7V2FVC7qjTJqmz9EuVkeWxWa5rb Sr9yG8d7v34j1GI1VjDO+nQd4ocYXcboS4w+xuhljL7G6Iy64jvqiiD6JEanJzF7EaP/qMS4rADJ n1NZAY46fdASWKvDmZe6C/OK1bIGj1NBIOtAsLleJDiRs0EgLWCDuBUDIHkQBDcMf/f7XYGjQKjg xM6vJeXi4pZEcuay8w4eXDXhnk4BDneo75u/3evZp3lV606tc1ObLzQFV/V7csPb6Lv9VgNQTtzj zlwjCW4I1LI+u0N/d61SINQ971/IFW2ffesjbS24unr97hRFe6g32J1iOn+blbf5ouUpfFtDzz0F AO6U8yncEMtQhwwMFSqQgz79U9vrX3dq+FAf8Ohc2lyhcYYQ5H3nrV/6bOvutd6vW57psgFJ6056 3WfeaEC45o1b/dtnF+YYviMgem5UGES/50rMZTTXhQEn/tO1AoCpXW6HKdAJAJMaoLX4oU2dc1sa l/rNL9dyeMub1Idqs7/QOZ40RmWMfIyKGHEOss9QKyoucNSeQ826ojCEUHMqrkHkKqiYjqo5dx8q +FptoKI979tCneYhM/mWee+zd9b53kEBgOywVA4tb9TawrgsagdX/z6eD65+u1uqOo87djZ9IO+5 GVnO9HGLqjk/xo0kdN5ot7N554YzOGnfs6ORwbwm+bswmHWDWJnCuU1jJJu5Rq0206bBZGl5rc1c 8T3bTICAndvzqGSfms9JITBXq5Ipc2Nzu1mfFx88miV/Tua//wM60G2FZW5kc3RyZWFtCmVuZG9i ago5IDAgb2JqCjE5NjkKZW5kb2JqCjI1IDAgb2JqCjw8L0xlbmd0aCAyNiAwIFIvRmlsdGVyIC9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nO1bXW/TMBR976/w43ioseM4sSWExGCTEAO2EUAI8TC12xis +54Qv4y/R/qldbqn61Xidk6X9WU6dZ0b59x7fa5vLoWSOhFq+Jn+0xt0LjuXwkkz/BtBs//3BmKz 6DzfL0d76TNRHHWU9N6pfPxzLRKvhXEyL78bdDa6z4pfnUwqra0vvy76nQ1BoYQ1at5cz/cTLXQq VXpnjk8n5nglMp9JMzZnezjeyVRnKp1MUVBol0KCQj0KnVNowIIOKHRGoT6FrueYWq6JFzq594ic mVmTzE/XZGc4PpdOp97N3sd96JhCJxQ6o9DEHJOU5sw8n4kpWjmRWTV6dqUt/yaD7WSwldYom92f Sk+nKu/PKjPlwufxtRNt8um1P1Foi0L7FBIUesGafpdCL6tOf0uhawodUuiKQmcUOqDQgDV95Rt6 zVr7HQpt842YYVo3KQniVCa62spsNKQOv8CjfcXiBICi4NcFixOAcgD6Q6FzFjH7a8KvMv/VJRhg E7gjABWREgywqceCAHVAMAQx7YZCXQqdsOY6qkppEEXBSgBTgV3gisDU5niMT6S2LpTHAPO/UuhN pO7Bi7+AJz/b/D5mkyrJ4k2g/A6sB8wBu0zAiTjXy+fSuGDpCnjHewp9aE66av2xEr8eFpo2LX0z rSc0wahbCt1QaLH2tEkmy6/ras89VqB4G9AXmh07gKlAmIP1AuEkpvV62BdSl0o7LroUlKxXFDqg EKiwXFPoiEKHrCsKCl2w7OJZP2DZBTyZZz1YicUhIM2sTOqXn0Am+sjiXKzpEGQ1oEZALYAnwkC2 5ckrMH3kGXJmx5ooqZLHLkh9acpyhU06wNG+sVwIpKYoPBR4wl+Wo4FNJvBQXmEGFPCat4eFHroc jQRYCG4I7B6joBwv3IOoDep3gF9gLvBDMH3L6PmMtplUzgdKOkDig20OKJzEGkSBBq/MiadNuYfF j8kzmaZ3p/ALz5JPKQRUABAsQHf0KAREBjAClB7mnXEvvCKYC+ghAPFkYJ9ClfSQsXkIPcST+Lxs GEWgaMuDdRNR2ONS3t6Kp8FbgrUEC0ewypv3R9TX9XeGoPYAvKNB8rr1x7j8ERAM2Aog4KJREIy3 6wcKAjSK8JpOTilUuT8GEB9Yf8waBRQ9b1W/r/w5xrp7iIdMXWONTHNb+r0ZnXdFTKkfTYml2pRr au1qD2B5O6Ao6M+jLCDF7+UGqBio4500eagCIDAVHMoDU2MNnO02L65tHo9gPCXWEmzdCLYUnbrJ IlPlANbsY3PeWQ6wvtX1rT9Wi/fgkLFt4l9XMs008QeIVoA671o2PUk2LaXDLuT7RSvfFyip8yRY cxMwDHRsV64hrL6012yHbEwpK0nKASYNRUMgDoGtLQ1bGi5uUvJO6vELGpNItqDnBrxnAbp8wJsK vC6fkD1KYHrQYbVWnUy5k65+IxNwbdA2HrJUvgpP2CrEXmf4+Q+++y+zZW5kc3RyZWFtCmVuZG9i agoyNiAwIG9iagoxMTA1CmVuZG9iagozOCAwIG9iago8PC9MZW5ndGggMzkgMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztWttuEzEQfd+v8GN5iGuv1zcJIbW0XCTKJV1eQDyUpLSg btu05YEv4/e6uZIyhzDaTYRD0rxEZ53x2HtmzozdgVBS50INP9MvvSobZAMRpBn+jaD5771K7JfZ brceHWV0ovySKRljUH78cy3yqIUJ0tfPqmyn86j8ljmptLaxflz2sx1BIcMa9Sdbu12Ti9qhmS9x 4opWQXjlpStGvvycDLaTwVZao6x7aEpPTelcWmWmEx0Pn3qZa+PDBCoptMcaJSj0kUKPKQSceEuh J6wZgflrCp1Q6I5C5xS6ZNmqKHTKWtCnpmt8SqEuhV5R6Bl/o+f42MnzeoApREdbWYfIcEwbGr6g Ux6y3Ac8SZWGtyzO3VDoK4uGZ/8ZwWqCBOVGBHOt+QWcAPxqnOYS2K/opQluWfH4hhUKYHNADPH2 axOCLyXm5LF+8Q8qnWAm5UVUwplC2nGlczQ2EXQRf9uTeeiWQj0KnVLoggWdUOiSZf6KQt9Z3gvW goD5igXxFtTnu7qwWHR1VshXUiy+ZGUFkGu3WSHFrPBLT3Ss2yMflyUor+mUQGN4spPmhs0JcPt6 BbgFihOwqc+3kbYekbZYf63105OGY5bOAW0COnfD0vI7Cv1gCeQeS64ABGQULAi4CmQUeA9+CGYE +gvWyHsdwAnwOq6baLk1YVqatckwIJ28Z2k5aNWTyDC8M5cehcApDzjSAUkHpCaQ5oBfHZb5ZZ4r pZT55np866QKS6sxAKUPWDrauMlfMaU/s0gBOAdI4ShUUKjPmhEoNxiVOA0XC3ARnXRhlGUPmsoO GAUEBYgAkGmgV2BGXmGwYoXkNeZnTdeYRBWwvkcBhfeyCK3LB5DmQIyCfi7VXAsuiUA3csVKhkDf Qd0BbIH0u9b6niup8mXJO3jb+yyafEiUcry3DZgDCk9QGQJJvmBxlddyA94D70FjDkaBSEuc5H+p HsyY8dXMnX+rFDwFO286I0/xwbH+JpRDa1wqaCfbXxoc0RgClwYgapPI0dsWbA0rBeA9qETB6Tnw fsvCTWKhn/1TU/s7HHDpCSi3TXwbR7nDUrzLhp97qqMFAWVuZHN0cmVhbQplbmRvYmoKMzkgMCBv YmoKODExCmVuZG9iago0MiAwIG9iago8PC9MZW5ndGggNDMgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJztW11P1EAUfd9f0UdM7ND56HwkxkQMJibGKOybaIIgiLIgH0Y0/ni7ZQm7 zun2MJRNWWB52Jxtb+/ce+fOuXemJ1khpMqK8efqy85ocDI4ybzQ478amv6+M8rWhoPVjerqIILN hnuDQoTgC3d5u8xUkJn2wlW/jQYr+ZPht4EVhZRlqH4e7g5Wshgy1FVNslY3lMykEYW5VieYiTqh yGywQl+qszm+3gsjbWEmIn7H0FEMncfQdgxdxFAWQ8cxtEfdCJ54GkP7MfQzhkYx9CXVEkBVMKAD 6omHMbQbQ2cNStSBWf1fx8FUGDgvvKnDoL5WaWGM8VkutShtLePZGHdCSe38tOlmobMY+hJDpzF0 FEPbMTSixD+PoctROVGU0k0gMCCg/Tml/QE1oH1e1VyWVoTa/tY3qfuDshkYFIB+xdAxNfTdZbd/ c/wDY+9QELAsmEtgBMAadebPSyecLNS0wpxN9lL9DqYisAdQGOgFnghUbfKVVMIqUy1z83zVv9Cq ZoMy/VfXSGFcUM2TFsT3Vyo2gPZNSsxCf6mrFq9qr/2YK1sKWdiWnLYIb5alCIWdIwuM9Dflc5BI QIIDNwKngGEDrgFkyRhSMeQpWS9iaDOGXsbQawoCT+wyALgFEtie44xgcoEBAVkXlF7gRsC4gPaT +eZMVTialvkGXLeRmhe5mQQIG5c938TQq5sse0FVVXEbp+JoBQiG76lRlLzwgWAA4vNeLwqyKvzK ijvduNC4byOVQXjtwh148x7xn76OcTlDLte6EIVuSXh99Uk9BG1ERRvNjVTl7Ah8AlT9HEOHqbTs fhObpx0yAI5L94J6AkIP+AsXAHouVM6SNy+F1m567nIlAvAm1+0BiQWITy437O0YAJiIIIq4gOeS NkgjfyjxyQwAzBTgJ0BQgXFuRz2p7iOIDhBp3HIIXAKSPdcYBOKTXXLHY+yFx0Fm52hCsjv6aolJ 6g26qhPloqM/11YU1s/Muv5YxXhhg57f4u6Ftlw0P6q6tKpOSp9SCutUyy5H50ntcRI/zHBTSgo/ 7rVW4TY+4tB3hWd7i11WbVx1BCotwLe5XiwoyIFeyV0BoD0olTh3cNVT8vbQ4ms/UOiVFHTVoBpn Z9NS+3V5RIDrYyVX/Vyh8ZayLddlHXYoC/RSJuWgNULKtk4iCFKQM8Cay9Xoi/cT6EABq32gFitQ CQBLcP33pZsjHzsM4vUH7LRclaGieDNnLO6R67guLScLbBZzTrljny9BIzPXSgkvXctykLwRBggK t7kBbgTimwyZOyVqbIqNLGLNsboqGQqbXT8VnGpIngfgMEeyrHet/GButQ2yVrIxe8EPwHZUsm3X OpR1Sx7HHevmSpLHY/X/eYDYWOlFCR0f654kp14U0m19jWt1H3sbC3IJ0AvwW65FAYzTZesEPBHc uLUSY6Df8SmGwEY/uHHrCbWsNY0y104LnbLocjHLnU0BcQaiESTgxhJmmoU1d9A7X0SmWNjSvMQB ag3u/SxgN3B+w1AZkqMO4Kq2122WZbnnTrWBnMXtrC+eFjfRz1mIo7JdUmyuM3S7Umh1Q4VMqpnX r/3l69n1i65Ky6v3nevr14fZ+8H48w+WtifKZW5kc3RyZWFtCmVuZG9iago0MyAwIG9iagoxMjEy CmVuZG9iago0NiAwIG9iago8PC9MZW5ndGggNDcgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJztnVtvHDUUx9/3U4x4IZVYd+4XIR6gFPFQWghBPFAeIGmh0NCmNyifnkmyUXbl/8z+ 5sSznQ3TVGrk2l77+Fz+52LvWRS7JI3i85+rX45PF2eLs6h22fmfi6b1349Poy+OFncP296Na8ro 6Okidk1Tx9Xl8CRKmyTKale1/3e6OFjeOfpjUbo4SYqm/e+jk8VB5DcVqFfXXHcP0yRKchfn18tp 8tVymjgqm8Zll8t5eN6/dnlSxvlqird+06nf9MRveuU3PfObjv2myG96hKY/sa5LfOIDtPrXftMb NP0Lv+kpGniI9vjSb3ruN71Hn3gPrZ7RXtBrxaKtwLR/r/lzxZ5Jkrk8KuvE1fkFhybn3SuXJllV r2YQTbHfdPE5rRTkaSt6a7Tc7PXEb3rtN73xm37xm16hgZHfdGqd/k+0ITFQLEL0EnO99Jue+03v /SbXsYhlUleuKOpo2Z58UXYdcGo98++tJHrnNz3zm47R9GZyCzY4QeQWnyhW/xcaKHqxJsbqbF1v kXAxce7kxTQvXFpe8mL7D+fFAvHil+iAmbIRtBW8+MJ6dIKQYnqxVHGabBFiQ2LbQtnsXpLEhoRe FIsQ2/4UfaIgtNi22KP4RCEQTwPakZHNJ9MWv/UKfbEh9FmdtoB+i/0RAs7sz1doC4KtmRkxU1v0 EipWTM/kQSATsQghbkwexFy/onUxM8IkUEw/srIQ0wslNtsUg8wzgMlk/h5ar4BCzBEQGxVcMLKc duP5tGl9tw0MxWgreu0RbcVAsS6mawS/i9UzV0wInZiLqR8GuAW9PrHaMqGumfIUYEKAHEEv8YnM jDBTyXQzsz+/I85h6xK9xFxriyi6ad+pGrKmdNWmqy+EnkV8mKsvFBdDTExsJgHImHAJJjbj+d1T VbC6mEuIs9AWE4p9pU3hqrIYLhDMVop4gxBqtnmG1BiXMS9795LUjWmK2lXxNrwozilD53TrfMQe cJi6Msu3gENByBwR8utx1QQDToIeokmQWwQtBljXzaZHfhPzJ4WmFUL9txWzMJ+ZcRnjfgaczJJk TiaYA2xmS34zSiyzNHdluq4DmTwwL8sc12MUEuCfoXPRSyiLkOFMYWmFPAglxhZh9l1Fr2VAY8M8 b7ZH5rKz2NbIoQSmzo96RbfoZqYu72+ZlXFrgZt1cR4ZBbNAB3NXzQZC6AEmXEzNiDM3E8dsPUNa PDFQ0MssECGPVrBvdyQiqVwel8NxKEv0PvR7fe43feM33bfCkN275GIusQgWrWNK8EcrXzPFJj5x 5HM0qz+zcDFkJJoYThG9WA5/JCbvCVJ2MbkyjIK2YlsMDYudCnILjmXQZGRzII6OMbE58cH4OuQe hYQzl16sXvgrLDHKEKzQT8w6i2Q505vdeDJOXVNtiI3Yg2Bi5u6EzFl1R6fi82LUbWG+uRSxh0kZ tBUazxzVYPLEAlY7wZ5pFrs6T7ZgTwZH94jLxEBhTQQbME1rDhaZK1xYTZ6Yi+GfW1N507PHB2h6 cY4sVG6uijFXia3R6wp7dkUel1mRubzaSP4JHSscKNHEGI8NZCCeuZIoETTI1M6V1jeWzUlUNLOY 836XQpvdGbOEC73I0B3zcLrjaWXlmlWCfBCmKZE4i6K/SWCHufj2xhCA3ck7QzbafJnPjB1YpMxc uSHYZBe2YZllias3rTMrzhSrYw4D0z8hszePD9D8Zr9UbPIfdMIhS31ZbeDIXLxHFtt82sFJqGTQ fOuF1SI8vjPA4tdlu6rCECurkMUXCRRzQTrzccwg4FvEy+YQMisdEusSaSnBGsLOsemV/hQxdxG0 EkpJDBSswwaKmks2UNQYioFCF7M9ioFij4OEMMsaF2+9ayMIwgLWPyCeNStbBuFHjv4wTcDsqNlt YxiJ7bE77hw3Lt2irwWrsFLzmVWGsYqwECzoyOpzmcn7NyBxBBAxl/kzX1XQi22bVa7swt1fZkns kmZDKpnfIOghOINh6pvVncOsqdAsrKaf5bNuJ39s3fYkOCNkaa3Z071hPiItS9dsy8kKHmbpiJ/8 XqLKRCQtRC9RCvwZUsfMKRFEEzFaIbohmf9nxGT9RdHDGPb/bIX2SMtsFO6ujM1UdQ3DTfsdV73p /dc4cU1dboEO5rd35txCz/QfKLewdaD5RRLmeO2Rtui5vXDtNXSjFSE2LPb6kd9LxDgZNBE3ckMW 1YulsjM31zyGP82kylySJetKUABN0cTqAUeOzIxcG797BcFy52atzi6PMrMtilpZLGhQ2LBIXV6n w9mTBQ6FNghJbmblmFEQqIDlpEaugDYHR1lAcwh6Y5zBAj+z09zDUpNwmpkRnSq+3iOXn5nPkD65 KGQW9EKX6FYI1XzZcfcQIOS7gEzHsssRgvFY+t78BtxUBWLkGJj56j27Vxfy5tHg7FyxhdDqXkLI 65WM1QWzmO/7hTxgc0kuM2ZCbFg0MOQjkuwcmZ8kQsdsqZN+nEUV5zHoO+eLxlDhc77ow9nKkI9Y mNMcIqrCNiT4fs0a9bwf0YUkFfQNiSeFemOBA8bX5tMM6QuaHyllJBzZ+O8+dzCypb81uq7onr67 Qst/DmaqGfIhFVoMrbDbeSEzDHM6YZgu2790wtpXbHXz4pzy79GO+53yN98rFyQMeY2H1cCwm1Tm Z+nMAURzPom5y4N5ouheKvp6iBVyFn7jrXsYJ+Q3x4ijE6sXvZiaGexA9VDCXK4ziZv/86tBu1UN Pgpn0RyzP8v0IvNKzFkBFoHZ/bvNZg+auTtsEZOIEDODzV6fn+o3FfQbu54YWWc+SfhczAoKF4WJ MwsyMD3AcnVsejGQPbnNpmdPcAqqDqsDurpYOgi1sVSIePqHCevHVprNX9g5MgAw8Nj9o+i7xfnP fwFhDmZlbmRzdHJlYW0KZW5kb2JqCjQ3IDAgb2JqCjIxNjUKZW5kb2JqCjUwIDAgb2JqCjw8L0xl bmd0aCA1MSAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO2dSZPbRBiG7/4VOk6q cEfdWhtugVDFhWXwMReYENYBhh1+PbLHoeTolf10uz1IGWVymOqRpa+/5f3Wlu+y3FiX5duf17/c 3K7uVndZa4rtv91S//eb2+zZZvX0urvaG19nm1er3Hjf5s39x23mvM2K1jTd325XV+snm+9Wtcmt rXz3583L1VU2XKrRVWP32lHT/f+PFr8nxdrClFmTe1O3O2rK7eWNcbZo2v0d3HCpHi7tnmNLU7pu X/dL7w+v+mm49CNa+mq4dDNc+m249G0sERl64g/o9r+iDb0cLr2H6BLb/mW49AXatiD1FaJePFGQ Koj4ErFQ3F5sm3HVjJC6dr7qzLLK1p1ZVPXuD8IgiuGSRQbxMSKY7UHwVohOMPIWPVHc/nekP0LA f6CrhKEK42L6Iz7I9ii0THyQMVrwS9xeYAojVWi/IEJ88GdEl7gXI1UwRywx9WWozxjd069qnIV/ B6BFmRfGd159ixZb96nRohou5QgtrhE/7hA/mJyiAVVIUzgNZuFM+wUOPHw8IK4S9xJEMHMWe/we 8UvQNabEh0sfXlZo8/Qg1Yk9rouqC6Kbg6jhxRXikZDK1+iqd6Zgg4JtQsICZwTIvngSALy2roy3 zYkwTQAvC9PmDbyTQMZJhPnvIlJZBidYKPYo7iWeyJInFpOxrEuIdkyOa9e2pqps37gmETGyPTD4 3MOIrTqzDw/fREFkQZElvgJEfITuJUQrdEI4d+bvhRzFVWzbjPdMVxm6CaEJm+9RX/XpWhdlbVx9 gG6COgF4zCBY4BQAxzGxVDQ0iNLQOHhW1pSt7zOSZbos+f0c7ZRppBDdX1Nw1CyIF1rGqnpiiZWA mYdgyRwrqLE9CjsXTxTG9U+sY2SovhkufYPoYnUxJkdhHXvEs40p87of5jD8Yd0OoQaCkQwXL2xv 0WVIsUfBHCFzFlgxuqaKA0InmH6lLHOzyjdL9c7MKoo67+wswjGy4sRjcIwpQyYWyrFAk7XOWKwV jU/RLGTbFqou4I9xgmmh2Pa4cbnS1C7ctljKzgYWHh5iU+bBwpAE9cJqWJk4pWKc28zPvYlQFdHd F6ryDEk8um+fslLEQjvmjYXaiaLDVKOXEKRxtjalLfphM9MfUUNcoObtgBrWYot20IIukVMIaTNx zCgSGvf/w/IdK9Cz4PqDWHaLq6JBcN4DkQyMUsKMaCxGOzNhIwxTogHkTyQhBg3RmBJdm/p0uCT6 Xp8Ml0TNbG/hhTd52Z4o0DOwYdp/Zr7vC9M03p4IFERUyQrhYmY02lJY/UNs/niHJUzhmQTG+w5F Y/KTKaBgN0sBLzyiy7pIzE+wAjzTjJRhTMpuX7S5XngaKiiTqLypfR2usSwTnWomET00wqLGhw92 mGaIUUVxFRsUYo0U1gObRIYjdELci3UUhAKM9cBOkiqYw/o0PeqrcXGEoEV/qDwILVjdYRJTSYuq z1vVj4gjyDG21hRFEx45i6uEqoth9uih8ZRnsi50qOWIvTFlYS1tRr2YoxNPVFPyrOIl2Co+yAZs plp+Z9SzTFg8MWjiXhxxYKbKTgpPwitF23jyIkgMHKWMO1NW59g4jfCWzIGmPC/AaosMTFmBnEEu y8pYDe/4iOcbs7Kt6/xzuM03yOaXvPXIB+edty74cTZ+TPUw9OiM2zwB73BbNm+Ny08lJI/0QPdy IugIC5cT10dIvfA7O8LPWr+GvPPOWnco2BifHwRIFz5xnVL9WbGLKZBAEJa9sg2lbKRFnz8Nypdd kZu2PDWnspxQ//88yYxOqLPBLdajZ35QBH5sMibaBQk3y7BBzM+EjBP0C1tBId9jOAT+GN7hMwkc YLHi8+GSOK7DfB6jK2Xb4+FOfL9h4cOBMvbmjpQvBrmwEqsQOGUzM7rOwBqQ0WNLQhkFW6PPIEer LKvxRItDbDt6TDl6uDKsfzRMlZibZTNQ83azk/CDS2UlLHhhZZTol62mFEdKdyfCbfGulZBjeoWv TVMd+GfRNI5+5y575Q4zZxF2XHgmYxLNqGhgY46XHQALeTGrc10y5w7q+EylUh4TFlrG8qnoUTjm IRgapFTilN1ZNhC+mPPbZM4ieGTmnHKAfjHnRYnPUOKn185n1h18IUh7/4UhNvN55srW1OXuKzh2 1z/fZJ+ttj//Ati0cjtlbmRzdHJlYW0KZW5kb2JqCjUxIDAgb2JqCjE2MjYKZW5kb2JqCjU0IDAg b2JqCjw8L0xlbmd0aCA1NSAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1aTVPb MBC9+1foSGcaoQ/Lto4thZnO0BaC206PQKClQyiU9tBf1r9XxUmG0H0OG9sJgYhwyLzI67X03mp3 5RuhpDZCjT7TL6fD5Ca5EYW0o78Kmv1+OhSvy2S7H0Z76TNRnidKel+ofHy5FsZrYQuZh9+GyVbv Rfk9yaTS2vnwczlItgSFctaoOlvbfaOFTqVK79zx6cQdr0TmvbRjdw5G4wuZ6kylExM/KHTLgi4o dEKhSwqdUUhQqM+68Jp1R+AqsAWeEfgFnvEP68I9CpUUAisEbO2w1nHIgo4pdEWhQY1fgXxeaHNP C4WdIV9upuSrnM5loVNfzDp9H7piQWcUOqXQLwpdNHVCUGiXQrcsJ44pdEKhS5b34I7fKDRkTSF4 bOD9ZN1DCAz/dxFnZs2dk6qo1lyPLzfa5tPLDYUUhV5SSLBsPSHzKcs8mEKe8oyvtoSwCvss0n9l 8a1OGtt9iwmhAxUy5WXYIUe+/J0MdpPBTjqrXFbDrfB8TtnpdveRTsURhXYp1K+Zw54pZOGcFj1t ZXCiZgnscjkFzINRPPPAFoCypubdcicHmAe2lmweCG7Jeu5yaZdsHjzQ//Lv2aAqY/IgKlepftBO 9Qf0lq9YgQBAa6R6YKux6qMsW5sH8/WEVM+RpfFGald0JUugwR0WVEZZRlmuryypblwWyhlf6SZr LRsgiM8UelOrES2zVNtKI1lR91i8uY0sa63wJQf/1QcQ3nytXiNAEKAaBKki3VrqZbN6XkfZRNl0 JhtQ77yj0PuGGdlCsmnMjLiZRVU+jirnd1NTY6cdzMbdVDDqN4XqO+5zGqypSmXaur8K2qSgmfqW FVNqS7p4JLBWElx9+GP1KoySynTVqjikdwTJI+B1y1bFWiwdK7xZG+ZzHN5KGn9+UggcYYKTIXA4 eU4hcBIJ7ggOYK9ZfvG8552QguDM8x7MxANRXWthdSbbn5qBougDhUDs7z4t3NC8bV0TKxJ2dWGl rxa2i3qk8cHNp3bEA1C+mcTb0IJhXjrRntagpgbxFDSsQC69SDYR4+li5gE7ny+tO8iSwXb/hUIg qEdeR16vMa9BggGoDvJfUCNGXkdeL8rr+ZW3dl6m45dl98YmHngBE7wWDEpQUC2Donf170yDOwJb oBgHEK8HMaDQ4sW4KoROldRZ62ocVED7LAjkmI9Vja/+tZkY7J5IsFvW2SbvaIK31ddu4ptAvGdX 7Dd+jXKB08HdUhwmo88/TgienWVuZHN0cmVhbQplbmRvYmoKNTUgMCBvYmoKOTM4CmVuZG9iago1 OCAwIG9iago8PC9MZW5ndGggNTkgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzt XNuO0zAQfc9X+HFXol5f4sR+ZMUiEPcShJD2BXW1EoiCCvwbv0eapqjZmVSOY6cXZvtSnWSPXWeO z3hsZcUEl4qJ9Wf7ZbHMVtmKWa7Xfw20+32xZNdVdjWv73bcFay6zwR3zopy8++SKSeZtrysry2z i9ll9TUruJDSuPpydZddMAhZr7v6uK7mWrG6Q//64tquSGFZKUpe5E1f/rQ3m/Zmw40WpuhSyS2V VNwIvW3o/fpqyZXUpW2hCkJvIDSHUNPSTFlujZFsJjUvbHNBwnsVhAyEHvU00oUQeoRLhNLfXng1 iUBIk7eXod1ARgyBioj0MQcxTxsCfvTBg4PQI11FIsCPHuGanh4Zrx1609G4LkruhG40Xk80PYx6 aCOjn0DM8Bw8RKOfADJewfTISAQPjh99cHj6aTdm9CMDHXNwEHrkN8akR+56mEHUms25qjObmTR8 I9mD5A0fKG+gvIHyBsobKG+gvIHyhv8tb0DKBjdeqQTVGyhvoLwh2cwZc+z9XGs/fUjeQN5F3tX1 LqUEFyqSdb2EDT6HkN/C+EytizyDPCPlfHus0/kOvemnH7AMnGnruMnzXccjz5jEM2Recms3plGq 0a7xGjaJGEmoa7ShQa5BrkGuQa5BrnEmrvEYNvnWC0KKaWfqGlQmI/NKa160vXaE/k67d2eX/Oyh jxmYp5n2mH76AWlPJzNsS40RtwgdL0pj020RIovopxAaskV42hMXSf9spe8nQYQebn44xeXEqvQ7 A9i7Ikmc7SZOhsjvDyd6P/rgsT/WOQVaca0qpcpYdYgnsEmkwoAUtIfUIaZf45LVn4fqT0aWu14c QZaIGb+CECLeVoOSF7nUh3VeiuJjj+LE8x8UiSm4sC5SwooI4kWgRto1o59GStIIaeRENIJsIH0k jZBGUgdxzGOZyFbpNYRGvsHAb5cveJ8s8SYiqSaFatqwVK4Oy84rQ+zmlSKSOcFUM0c2r+loDwtb mbstxXcI3UPoB4R+QmgJoc8Q+g2hL14tIl1F6L9BiEFo4dUi8oP8fiPS1TsI/erp6t63riiheH05 wVtXPkFo5KFAvygOnrNoUkk4qewcLLKau+bBRqkc+MUU4qnxIy/42fnRBz87P/qYpWSqtBy7LA9Z xh+fIj+DLfpV8ZH14ZAUeXrRxzwJSrKJ72ZRV37IERAkrEO9bJqwPoq4Q35jw3VTsXfZ+vMXVpy1 E2VuZHN0cmVhbQplbmRvYmoKNTkgMCBvYmoKOTE2CmVuZG9iago2MiAwIG9iago8PC9MZW5ndGgg NjMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztWsmS0zAQvfsrdByqiEa7peNs LFUMS8ZcuFEZ1iJAWA58Gb+H49hUgl5Cl2wHJzi5pJ7lp5a7W/3UzoIJLhUTy2/zYzbPFtmCea6X nwpa/z2bs/MiO52WowMPjhWvM8FD8CJf3S6ZCpJpz/Py2jw7mdwp3meOCyltKC8Xt9kJi6FAGrWN 63SqFSsN+m1LqE2RwrNc5NyZypaf9WBbD7bcamHdJpVsqKTiVuhmoifLqzlXUue+hp7GUBFDNzFU zTRRnntrJZtIzZ2vLqh4rCBBd7dMsgmZGLIxJFPpARcwFdDXT16F8slvxJTXtSODYM7lPKjKj9cr Ci9NaCjexdDXGJrF0KsY+kCCXsbQRxL9pxj6TrKekRYE6OckiLagW7qpO9PSGc9d66wEyfWQlJVX lKwsjdhDVtLowaguszLZ+uSkT6bXpBn/jMCJ9JqHyrGWr/zaJvAexzOCCkErGv+qHCRHBq20AOu3 7/1rfhKm9E83XnoUz3cWQ8CX94/AS0PN3/1vbiA4SZLDWsHNSjrekEo7KMegtH8hyZdvMfSDpAnO SBUaQEA5gAUBU4FyANaDG8GMQHKANdLcAYwA7vicIl+slssDU1v9Anaj5yT98qCdfgE1FCQJLQcB V5f0Q91ButQvyfTgRkDf8+491NrTnSbRZVYplVeqJFetZQnI+kuSUgEbQcusBy7oMuuT6WmhAWYc ROTRsr7nh3OsablbsxmnmsJ8mapUwCigQYBuAMoOSBwwI01L9iyqaO2rN6lrHIRwPNyGmTGq6X+2 qT2g/3AeQ6Cv9oJSe4Z0JO65OBzd9rrvhpxSggvVUacHhPU0hkA/jiSphhTWPR9F3OEk5XiQGreU vwtCneumbl4MofjTRMnb1BlpIg68z/wfFO7hqj9tTQevS6/jHAKvSy+2lkTJnZF6vcuw/5MurfEw bss76He+G+2gvwUCCCgv8NrtHkWMjZF3pJHX/hQA/tUBooy0v9WSf4yyA4wyGj046XQp+Wn0YEEV 11XBnmXL7y/ll6d4ZW5kc3RyZWFtCmVuZG9iago2MyAwIG9iago3NzQKZW5kb2JqCjcgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDIyIDAgUgovRm9u dCAyMyAwIFIKPj4KL0NvbnRlbnRzIDggMCBSCj4+CmVuZG9iagoyNCAwIG9iago8PC9UeXBlL1Bh Z2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDM2IDAgUgo+PgovQ29udGVudHMgMjUgMCBS Cj4+CmVuZG9iagozNyAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQov Um90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9G b250IDQwIDAgUgo+PgovQ29udGVudHMgMzggMCBSCj4+CmVuZG9iago0MSAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDQ0IDAgUgo+PgovQ29udGVudHMgNDIg MCBSCj4+CmVuZG9iago0NSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzky XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9Gb250IDQ4IDAgUgo+PgovQ29udGVudHMgNDYgMCBSCj4+CmVuZG9iago0OSAwIG9iago8PC9U eXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDUyIDAgUgo+PgovQ29udGVudHMg NTAgMCBSCj4+CmVuZG9iago1MyAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIg NzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9Gb250IDU2IDAgUgo+PgovQ29udGVudHMgNTQgMCBSCj4+CmVuZG9iago1NyAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDYwIDAgUgo+PgovQ29udGVu dHMgNTggMCBSCj4+CmVuZG9iago2MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2 MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9Gb250IDY0IDAgUgo+PgovQ29udGVudHMgNjIgMCBSCj4+CmVuZG9iagozIDAgb2Jq Cjw8IC9UeXBlIC9QYWdlcyAvS2lkcyBbCjcgMCBSCjI0IDAgUgozNyAwIFIKNDEgMCBSCjQ1IDAg Ugo0OSAwIFIKNTMgMCBSCjU3IDAgUgo2MSAwIFIKXSAvQ291bnQgOQovUm90YXRlIDA+PgplbmRv YmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUgo+PgplbmRvYmoKNiAwIG9i ago8PC9UeXBlL0V4dEdTdGF0ZS9OYW1lL1I2L1RSL0lkZW50aXR5L0JHIDQgMCBSL1VDUiA1IDAg Ui9PUE0gMS9TTSAwLjAyPj4KZW5kb2JqCjIyIDAgb2JqCjw8L1I2CjYgMCBSPj4KZW5kb2JqCjIz IDAgb2JqCjw8L1IxNQoxNSAwIFIvUjE4CjE4IDAgUi9SMjEKMjEgMCBSL1IxMgoxMiAwIFI+Pgpl bmRvYmoKNSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL0Z1bmN0aW9uVHlwZSAwCi9Eb21h aW5bMAoxXQovUmFuZ2VbLTEKMV0KL0JpdHNQZXJTYW1wbGUgOAovU2l6ZVsyNTZdL0xlbmd0aCAx Mj4+c3RyZWFtCnica2gY2QAARMCAAQplbmRzdHJlYW0KZW5kb2JqCjQgMCBvYmoKPDwvRmlsdGVy L0ZsYXRlRGVjb2RlCi9GdW5jdGlvblR5cGUgMAovRG9tYWluWzAKMV0KL1JhbmdlWzAKMV0KL0Jp dHNQZXJTYW1wbGUgOAovU2l6ZVsyNTZdL0xlbmd0aCAxMj4+c3RyZWFtCnicY2AY2QAAAQAAAQpl bmRzdHJlYW0KZW5kb2JqCjM2IDAgb2JqCjw8L1IzNQozNSAwIFIvUjIxCjIxIDAgUi9SMjkKMjkg MCBSL1IxMgoxMiAwIFIvUjMyCjMyIDAgUj4+CmVuZG9iago0MCAwIG9iago8PC9SMzUKMzUgMCBS L1IyOQoyOSAwIFIvUjEyCjEyIDAgUi9SMzIKMzIgMCBSPj4KZW5kb2JqCjQ0IDAgb2JqCjw8L1Iy MQoyMSAwIFIvUjI5CjI5IDAgUi9SMTIKMTIgMCBSPj4KZW5kb2JqCjQ4IDAgb2JqCjw8L1IyMQoy MSAwIFIvUjEyCjEyIDAgUj4+CmVuZG9iago1MiAwIG9iago8PC9SMjkKMjkgMCBSL1IxMgoxMiAw IFI+PgplbmRvYmoKNTYgMCBvYmoKPDwvUjM1CjM1IDAgUi9SMjEKMjEgMCBSL1IyOQoyOSAwIFIv UjEyCjEyIDAgUi9SMzIKMzIgMCBSPj4KZW5kb2JqCjYwIDAgb2JqCjw8L1IzNQozNSAwIFIvUjI5 CjI5IDAgUi9SMTIKMTIgMCBSL1IzMgozMiAwIFI+PgplbmRvYmoKNjQgMCBvYmoKPDwvUjM1CjM1 IDAgUi9SMjkKMjkgMCBSL1IxMgoxMiAwIFIvUjMyCjMyIDAgUj4+CmVuZG9iagoxNyAwIG9iago8 PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1hQVENWSitUVDE1Q3QwMC9Gb250QkJveFsw IC0xOTMgNDc3IDYzMV0vRmxhZ3MgNAovQXNjZW50IDYzMQovQ2FwSGVpZ2h0IDYzMQovRGVzY2Vu dCAtMTkzCi9JdGFsaWNBbmdsZSAwCi9TdGVtViA3MQovTWlzc2luZ1dpZHRoIDUwNgovRm9udEZp bGUyIDE2IDAgUj4+CmVuZG9iagoxNiAwIG9iago8PC9MZW5ndGgxIDM2ODgwL0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggNjUgMCBSPj5zdHJlYW0KeJztnQd8FcX695/Z3XNOSAgJkNAC5IQQioAg AkZACJCEEkogHEhCSyf0XqQZaUIAC4KIioBdip4cG3ZUVBS7Yrnee+2KCor1qsDZ9zfz7ISTgMh9 7//93Pf/+WTlm98zs7Ozu7OzM8/MbCIJIoqkMjIpc1hWx86ktmvy8GNU4bT8mRy+GoiehfPnev03 H3gLgb8TuZqWzJw47ddfh9SG/RtRrSYTp15ewulnPCgPKC3OL/oyKXgZ8nsf4W6liIjcWy+VKCoG 4Zal0+YujKi9dz/CyUQ9B02dUZgvHvf6cfw+oubp0/IXzkzoZ24hyliJ9N7p+dOKnevriR8JM2fM meuE98n9M2cXz5xyvxFE+juQfTSR51ai4PUUumXSZJqD+y2j1bSBrqen6UMqoBWwttIOuovuJT89 Qy/Re/Q/uAUvd02j2uYj5Kb6RPYf9rHgXWCfq05IzPUI1be8p2PsaPu7anHfBa+3o4P73PUoXB0b abyF2J/EKfsPo7cM291k2LgKdpQ64gfPrcH7g3dXK4PhlEtjaCyNozzKx/0XUSlNQslMoak0jaar 0HTsm4ifJQhNQKpCpJL26VQzaCaYTXNpHs3HfzNhz3FCct8sFZ5HC/DfQrqcFtFiWkJLnZ8LVMwS 7FmkwgvBMroCT+ZKWq4srRyzglbSKjy1q2gNrT1naG2lVU7raD2e89V0zZ/aG6qErsV/19FG1IdN tJluoBtRL26mW6rFblHxN9GttB11Ru7bjJjtypJ7n6AX6CG6j+6nh1VZFqLUuER0uZSoMpyJMliC O1wRcsVcfgsqS2sZ7l3eW7lzpwsRvzzkiPlOOcqUK5CSc+HnIHNZWq0krsU9sH36jji0Wd3/6djQ UjlXrC6PW0JK5mYVklb12D+zb6BteAN34qcsVWndBput7coOjb+1Mu0OFb6d7qA78SzuVpZWjrkL 9t10D97tXbSb9uC/03aoxXof7VVPzk8VFKAH6EE8yYfpEdqn4s+172zxDzjxgcqYR+kxehw15Cna j5bmWfynY55E3NNO7AEVx+Fn6TmEZSoOvUAvooV6mQ7RK/Q6PY/Qa+rnQYTeoLfobXpPRMJ6k77G z1P0hutzqkN90E4/hnK+hcbT+JT+RRPGjxs7Jjcn2zcya8TwzGFDhwzOGDRwQP/0tNR+ffuk9O51 Wc8e3S9NvqRb144XdmjfplVSy8QW8Y1i6kZHRUaE1wrzuF2WaQhqn5aYnuf1t8rzW60SBwzoIMOJ +YjID4nI83sRlV41jd+bp5J5q6ZMQcqSailTOGVKZUoR7e1JPTu096Ylev2vpiZ694nc4dmwN6Qm 5nj9x5Q9RNlWKxWIRCAhAUd40xqVpnr9Is+b5k+fX1qelpeK/Coiwvsl9isO79CeKsIjYEbA8rdJ nFkh2vQSyjDapHWvMCgsUp7Wbyal5Rf5M4dnp6XGJSTkqDjqp/Lyu/v5PSov7yR5zbTOW9F+f/n6 fdFUkNeudlFiUf7YbL+Zj4PKzbTy8qv8ddv52yam+tsu+rwRbrnY3z4xNc3fLhGZZYyoPIHwu5Ki E73lvxAuPvHY0aox+U6MOyn6F5KmvMXKYsJ+bROuDVeI+0tIkNeybl8KFSDgLxuezWEvFcQFKKVj uxy/kSf37Nd7Yn1yT5neU3l4XmKCfFRpec6/+aWN/GUF3g7tUfrqXxL+Yb/Xb7bKKygslZpfXJ6Y msrlNjLbn5IKIyXfude0ik4dkT4/DzcxSRbD8Gx/x8SZ/pjEvpwAEV75DCZlZatDnMP8Mf38lFfo HOXvmJYqr8ubVp6Xyhco80ocnv0oXWx/XNHFG/fAxdSFcuR1+Bv0w0NplVaeXVTij8+LK0L9LPFm xyX4U3JQfDmJ2cU58iklRvvbfozTJagzqqNwb9VS68Tyzj1JYd5sI87MkU8LEd50/Ejs2xM7ovG4 VFA+0b49vdkijnQynMVJIa0q+SBgJvUbIHeZ8tB+A+ISchJ4O8clxTnX5Eryh4XkFY2Iymvi8/zp pXFqeUFtvWnFqSEXWCVTl3OBTm5nv05DloVzYhwRJh/nAL3LTMKbizgD2ago+RQbwTfM9GYnFifm JKIOpWRmy3uTZa2eb0ZWYsbw3Gz1tJ1aMrJKiPcnc8hPCditA0Y/1MH0dnH6sapwfxWuDA6otnug 3u0tD0vMyCqXmSc6GZIXbxBu2t1qYP665Hpd8Gqmo3VLTM9P9EZ708vz99llBeUVKSnlM9PySrvL PBIHFpUnZmX3jFPXOiJ7adwieap6lCEyRvbt0B5tT9+KRLFmeEWKWJOVm/0oHFzvmpHZAUMY/fL6 5lS0xL7sR71EKSrWkLEyUga8MiBzGoFAmEof92gKUZnaa6kIFS7cJ0jFhek4QYX7DI6L1nEG4iyO S1FxcsNDalSKIkZzm+Ytko9nSU5peV6OfLmoAR4l/gm/SOxFfiOxV4Uw3LX94YnFff0RiX1lfG8Z 35vj3TLeg4ohGggUjmyTyvMS0U6hQmVTnOCqaMosvftse2R2wqtxx3ISUNXGgtxsf612aPtdSYOQ rr8kD9H9/WWF+fI6yJctj/UkDSzMQbXVGSLJQH8t5FDLyQEp0tUxsjrioEI8GzxAdXwZAv6yHH9O O3nS7Ek5qjpH+2lAYnc8ds7T1UqeqGNOeb3EzurdxKsQnnSVlFq4NsrK5pg4BHGyHC4kT21ceWEi dhXmeVHaFhVmoapzWxoexzHFaBKtVsWK8DhnJ8nbMpMiIsP9tS5Ehvgn7YgL5SvpSvLk5PDFq9BV TgKcO9ofgStqFVKUzgEoHewaKK8F/67Cpcqkz8hshu+jEYkL0bLIi1Y5ebDbH5k0MB+NPx8fgZjE ZH1wmGwjIpw8DnCsR955bZS7mTRyn3134uUJIVuH9omyc5AVk+IeRcWmnPLqEf4x7Tq0D6seG6mi y8vDIs9+AJdXWGSlykhvGnoNJMSY2E1BEgfCd5z4448dtY7KmNAtyrTqnA6J14msnZR4vrjj7Fck Vi7tsVIp/6wcxb6jtMWyKU5iHqE9IM3RdIdCMAFc6cTvMffSHldtGlMd6yTyA64U8hoW7TEsexC0 DfRScBHIBMPAYsQ3B62tjUi3gTzGBvteqw2OB+Y4xZVmgWPPpKbWeNrjfg95X3AWPGAwFf4lwxj3 91RotcC5gKsAdjZsJksq7q+/QyxoVBn+Eg8lBFcL2nW+WOXUwtOcLquO1Zo6Ia/mZ/A09XBoovRn ij5fXGPtTyWWRTvNQzTtbFjFtBNMthZQZ4lZhrRluBZWr0N70Bb0deJ3mpk4bjlNPYOFiF9I661t lCKO0k5x1M6GNoYOAK2BD4wAsxBfFzSy4min0YvI6GWvN19C3sD4WHGV8aVjH8e1Haadbjfyv66S rWChskvALir5Sx5jkE+J+TzOBawK2MdgM2lKh9FAxv4F/FoZzqGmZo4dZEV93EDbwS2ObgHzHPsM zFOU4O5Fl1THfIW6mSvwzKoziVIdwpQeprHVaH6WOIW7I2N1oa14f3IdhoLROuyZQbnufwDBIG2e tR5MBl0o3zxB484HYxYluW+ipLDDlGTthn2zY/esxrBqOPHu+dVYWw0nvkr6WjhHv5C8V5zeZx1j XPUpydOGkswD1LU66l7PZKvVxd5r9bN/F+/SKvGuPR0aBc0FXjAbZIOJiK8Ltpr7aZXVnNaIb+zD DoXm7Yh3kGnABUZTpRniBDU1TtFWd5E8VxWGKr3N3qY0Gc+jKsPOiOvJuF9Rz07nk2e8TFsZ+3fo dDOBhjOotwn2KR123ccgr63iB6S/jxKMA0DqE9TK+pISrHnnB8o6wZOB+v3B+YHr3ASudnQ1GALW OvamUMxt1MK1j7pWx1yANmk7tTiDtpTj4FGaTLPNfCoyF6Ku7qFU4wuaagxVOsDYR/3FM9TS2IJn 9DVNFYWUL6bZ7yM8VYxHezYKab9UpKnjcIz4FdqJ+orPKFEeY6yiePN7am8sQx+3muKNS6ivMRLt 2TywSfbap8KITh4xRp0Zh+sjcwJQcSe3g4nV4raBScJG+CZwG7hHxReDPLMl8vsFcelgoorfAZaZ rREeCCZX5rHUrI1wFKir4vaAe43rcPyNYIeK+xp8asDHMJ4FDyHtM+AT+BzK+zg5AlwkXoMf8i54 jcG9DJHg3lZCFxlXKJ0v/kUrjYu0v2KvlT6ImYX+dSV1Zx8i+KLs09hfCN4q+2b2F4IYJtgjlB+w mVrq/h5lnMV9uN1AHYN+29wN34T7YfSXwelS3fVxTvSnbqJrXZk03pUZ/F33ibIvNE6oPiaxsi9D 2+r0WzutB6mE+y3c21F7pOqPPqG6ut8xr6LxlX3JQu4/zDGUofqDkLbbhZKS7borm66S/YuiHL6W JAXvaWfUx43o+zoh3Z2oo8A4iDZgMPZJ+qA9WkhuozNtMjrbR8EiEKXalQdxfyXQLajrBg0xTbw7 uk2YSm2sejQfx+fg+Y81G5Np+ehah6Wggasb+Vw9yIf7rue6lza5NlKRxFirnmU4ykk+626Gi7ZU 0hL13qbpEvU8h9Be9TxnOszHM2pNZojvmO8uxTlepgyX9K8cHH8wU/p6lf7WZ2S6/wDvsd/oMU/7 cdbv/Jyln6p9L9wnsw/twiZ+1q6mSPMLmE1z3T8ij+awv6UodyNoCiigcVY+FXjCYM+Cf2fj+B/h u6Fiq7rxHd2m/KQYh9Z43mVUJ8Qfau9aiD64jEZba7FvLd0ANjs+jk/6L7jXnRI8W6Hqy0LHJ7kX THbqivS7tB+xDXV2G3zujriPcK4v1tU4ZhLS/UHT3Inwd9IQnkANXSsQdwR8TlPM4/BfOsO20b9P oHirEOANRB8uVDz6f6sfykXWrcNo1w84HJZ9kJ0NP6+h7CdC+3Dk3ws+QYaVhbqXBZ8qC30a94Gz Zb9mPoz6BqxYauA2qL5rEk2w+qMfa+P0VReBC1T/s7rS55D9TGMKl32d0zY3Mt+iFlYQ8Wi7URe3 WherPrSv6x3a6goiPIjCXSMR9yxYh7q9Adf2AuxDlGxl2b/LvhnPu5E5HffmgLp6p8S4WYQbN9PT EvMhWgXGK/6Jup1Hx0CFWUSL0BdMQD2+QNZp8Lis367VdAPi1st4rXhGa0A7rU5cO+Nhmgv2a7Ua w+drjPfBUbMhCeMj9An3i3LzpLgP4QiEOxhz0IcA8yT8SeDpRZtDQdzv5kl6pvKdm0arwCJjLu5p LuUaK2kUmGekoF1NQfwg8oOJf5YOed0KFoCFYL7lpynWZfAHTtJkcJk4QOvMrrTOhT7Jhb7J8y+A fsPTk9W9l+6XYPxZ5rqDerv20BDcL+HY3tYDNBDxF8AeDZW+UzbsR8EghLOg01AW7WB3MX9CX70d 7+9TGD9uR7rt8NMSaGDYxWgrTqJ9/wx1vC41szbRBOMQ2uWjVACGo360MN+DdqNlZgA+Wze0B91Q t+vQAHAfmA0mAi8oBlNAIRih6Iey2UCNzSvRDs5Be7iHWpmluI5HUAYDqSPqRob5BI3A9WSCDaAY FIDuYKK65u2oP9tRX5HmjOtrc97X1+ls14f3Y4D4DT6EnzKMvdTH+JCSjLtQRz6iMeiXOxufIP4j +Cnf0HDocOMNGi2eoDyQ/Z8ca2yjZPELXWSMoJ7GQNTLQRRjpOOY4dTJSKYWxmjkNQR5n2+6CjvD rE+prgkAfamroaMXgizwEg1VTKT+rkfAbeBVau1aSmmw09C3S39uQNhQGoC4sZ6X8LxOol8/SYNB HmgHxjt2DsA7hGfF+31glKzPrq+pveWiru63aRKefb5xDP7fSQqT/ob0A2Sf6S5GWzySxlgNaBDe uZvADeAlRR2631NHdNcaPpRucidj7FZCbUQ5/IG/qX73P0S8UW2OpjGIBc2ccNMQVFzlfMsRjBWP 2EfA144ekXHoU2PBjnPOeWz6E/TcxAtnp8pcROX40n4cVIB9DMaUlXZl3NiQ/qWTecL+0OEDcEjG o39pJfuY02Ma+wj45rQibscZDFSqxwdvVbLe0XSpTn9jSEXfm4WyTz49N2I/CfY7etCJO1gVxGn/ sMw+Du4GO8Bt4GrEy7mLWmBTyPxCAmgRoiXW0T/BmRNwxVZyk6PzpLIfaf8g9bzq3TNU4moJv0ni ho9zPdpUyRJcP3wmOaaTPocct4aOyUPH3RhHNDW+oqtNN/ruDLrauAesRzgV4TF0tbgLHCKX8THi EbamYd88tJvz0Oe8r+xc9L2jjTJKR9tgwY8abXxGTaw0tBUPIe91YB9lwsc8JbFKbDsU8xkJ+pfa 0NqVasgxhETYth0K8qglMXbRcocbJRiTrAyJY67ANQM1XrqOVuI9PIX4GFBfjbcqwTnlOEuOn1R/ DG7isReRjTFbcDDOeYIJ9mZOPStxzhuD/FdAY8H1EvMmMZiP5/vm65ZjLanBR5zriJHnkuUg70Gf szqWoBhLiP4yN2OXTIuyeI3hMpPx6rwHJeYPdFDv1+M1xO8wK+S18vGesdTTM1ZqKNTb/YZtS2Cb DiniI+qk+Io6S+g3SpUYHvQJklo0WCK2Ic02FddZ4cSbDmKCwwhqpHiOGiieRh0FKP/hoaDsd5tP op40QRlIGpBQNKmGICMUeQ5ZDrhvVRZ496LU2CWFmqsxwTaMx2yKcy1T8YPRnk51JWFs9jLq/F77 XVcd9BXlqLeZGLe0gq+OMamnFtrGC7AP7aq7I47/HMfq+WKMR63ezrywHHvKOd++zjwuxkIyX/T9 pWG7aU9YLO1xy7FOf+T5CIjBe4v2HuOj7qrNPtv8cci8fuV8exuao9t55B8Wtpnzlvs8cgz9Do+f MQb/nvsT+xPc53SMs+VYbDCO66HGWtn207iP6ThPR3kueb1qHh9tCq55CMbfPXR/VL1/kf0D8v/A SrW/MsdRnPkl+oBNVGRNQdmmodwwjsd5bzV2kgdjnUKMcZqgHY9T9yPXJpitIesRVcA5VzosB13U OoSz/qDXGxzaSMV9dQOz9FoC2OGsJ3QFeaBEjjc1Z6wlVLs/vU4QskawoNoaQf9/Z31ArgOErgXI MWzlGsDTFFs57y/L8ln7ZoyT4uT51LOYhfN+imeRij5tL/yhhxA3mVo783+W+YAzl9tJzs3a37n7 8dygnDsw+lBr80G0IYMx3upFOSoe4zS06WreD/5SnJozk3W1BH5wKWV6ZHnth+/UHGkP0yiMCUer vrkLLQJrQkG/XoA02RI1/zzY/lTNud5O3XU/j7wvxJgyT+XLc7HI136afQakV75B8DWcpxh+wDF5 jPGyPcd4maKtLmgDutBVqm52ge/9Ku5T+tKDcc2Oz1F9vlT6AMZautH6luc43ddTnnsjzl2Afl2O UeX9oq7i2J5Giv0viZpHtVFWn8KPmK3GOrNlWvETxndt0X5sQR3DeFONtU/Pva6W496zzS1XmzPv refN9f07TAT1pV+De493yA2ZT56C/nutMwctyZFja03odSi4DE7PGzv7nfnhchCOcrVPzw8rTFUf 7nPmge+z35I4c7N9wGJnrna1uY1E6Nysmo/Vc7JtsY/nYEmmRR4vqDRyH8pM/EBZqi4eprbYd4NV iPv7EKTimGepG8qxh/Ed9TQbo572IB/qfJicowEx5iEaoMaXcs3qbRWfBX9stnUHlZjlVGpmwn9c TlMx7qxvdIbPctQOynk8d2e6zroO++CXuTbSdLxTYc5aT5aaw1uBsFzTqWD/DONEXoO5Fv7t9TTF vJF8ntdoZ5gP72Eu7cQYZo/7ddrpKcX7CH8R5+mvfL4NdMMZaz8ha3J6rQzXNEL7jjgH6bzlPrcP vlsB7VBzjj/bz7M/Cp+7jIaIo8E3cK6ZOK6ZOvaYfQfuowjnIXUuXK9ag7tezTmNNtfjHhx/tvp6 mPIz5b5D1BJtQGszx/7WvBRjXbkmuwHhU2gTyuAn9ELe69Q6WWscUxvn8Ml0eB/24BnvUe9DHh3T c6wO00PWGCVXOroZ13IBaAX6AAKDKtcU9VzsQroJeKWN+71AzrPp9UGwzFkjJNAGtJRzbpqQNUKm +n07a38h6369wHWn1/0UdHrNT9EINHae6eWOztNre6Hre2pNT6/rTSKXs46n7gV5hKs0Ttmrch+P 8cXzUFyL9TDSfM/z0qquZ6L92Ip47bf3dwhdV6vuzy93CF1T0+to57Gecz5rOHh3bzi9bqbm/HqY N59u/1RfAFxxGKvzmmOG1RX0QNvXh9tYxXDs20bx5hvwIS5W4zpup9A+oI37Sc6By3U04yv7buN3 GYf9q9HmFdImhWr77GfVcVk8H+lCH6jmtbuRD+1cYgjc/l1Nm0Ai3ulVCtm2f2MfNvravykttw+g /esj20C0K62t+egDfHStbu9UOzYc1yzbuLfBE2g/HqdRqh/ZROOV4p5dHpog52Bxz7nwhXLlnKnM G215a9m2qXJyjnHPQL/0DuV5GqNMfkL5HqAE1yKUdW08s/uQdhLK+HtqD2bifg9bQ+zD5rtoU6Ls z9DXFlj1kOchmgy/YKuVA1+iN9LPIJ8cYxtyPHMdxkfHqZOau5XlNBflfgi+jZyfvgdtYhuKcb+C eygN6avvQR6vo3+V9IYPMhnvZDFluF6kDHcRxjX/JK+7DspjGPU1O8IfkX0InqPxI47DPisTijxc HWkF+lAhx5jww0mOM40TuF49zryHMs9jnMljzQANkONNNdZ0xplqjCnX9vbwGp3Vzlnnc9b4FAsw LpVsoQvkOp9c46uyvjeUuil11voq1/c+hE8/itf5jEEUaTwFOx37VlAbsxj1awLGL3LdUK4LOuuB lWmQD9JkyjTuTajbj9t3W0/imYfbd7tvsb+wHoQf+BTe/RGgCdiG/i0K2tZ+Fs+/hynbUPgI7jXo i/E+GJNQF0vBh+CA4/MNh68CXwJ+ap4FH00cpynuK1S87u8nm4vRp/+B+oL6izamrdkTvt8S+C7v h/gnzjsq31lZZ1QffDHeyfdpkzmfMnAvU9S66XQQAAuor1w7BZ7K9dONGGPuUuuo05T9BdiE8GL0 9y3R547iMjfjUB+bQnF/srzNbihzuaY6zX5ffK7KnfDM2mPfdMUqZ111E7gLzIavJp/T11zm6jiU P0gyTLAOecs12dUULw7QSLMLjawyv4+xuhqvb6ViMFXPKVoZlCoxhtOPar1WruPClvMBypZxl+I9 upTnGc4617ALZSXH4Pkom/G8VqzWhuV5oumG6lijq4K4ftA/o2N1kF5qUnUQ3wR6BojvCz0b1a/j z9L1Pcd1nC2+FfQM/tPrOEe+idAzOMf1ZUDPxvlex5+Vc0voGZzjOoZCz0aV60DdKpAo31rOC8k1 qV1o4xk17yPnuGR9rZxTQzq11uXMkWmsFPtXiWnQjWrOS9JSzRGRpx69I1Htqmw/5fsm67H8ZuID 22bwfgO5dhwK0ckSSdW5Nc5b8WfxP1dDx7fmuS019/eBEw45vvp8aPV84EM8LFFjef7usZ9WjLnr WKOCB6WqOQWZZhw1d8GntW6jKJVOjv3lmj36H9BXrs1b79Fw90qMpeV6ez2Mm7j97KFVrbEvRJsv +9GtSPe8/L6HouS6vPQxrPlArh+h/3W+xxtQqWtRf9YGZyjNVN+ojcFYtLmLYI+D7/wh0slv13ba z1s7g+WgAHYL8ALsdSHhMpBddc3h3Me4iynRXWw/7y4OloMC2IizX4C9TofNI8Hj1pPB5WCRsp8J rnbsO8Bm62TwuOvN4HKwyJUT3HWW8B1gs/PtxznTuvdjnLU/eNyzObgcLPI0k3FVw4YVPG58EFwO Fhn5Zw3fATYblj0ULHINtt2uX4LL3bWDi5X9Y/AKtys41zU4+DrYY7UIHje/DG5yNcR11A8us7YH dyHcn+H1EFemOm6xOzK40LU1uKsyXDe4hMPIKzO4h79BOXdaTwyN98TYbs/DwcWeN4MLPeNknBM+ HFwiw5Xfj/w1uf9G2irH6W9RwDBHRzioeOf7lI3gGrApJLwxJCzJCbHPKz3eT2F0tleDFaAAYXLC kjwQbXQOvu7Y34PFoC2YBErP8s1cVfg9ne98C7PcYeVZwvVANCgL+XamD5glv6HR38v8v+Df+b73 3/oW+NG/xlnvGuhQ3V4cMi7/K2acTzp3z7+G19jsAofiM8N2tDga/Bpa5Hyztd6ZK8hy5kjO+T1w 5TyAHIvLtvZ/TO1fzLWgWnzlt2D/Q7jn/TXn0+afTzt8Pu3Y+fQd1dtz2EOqh89oD2OC+VXaQ4S1 /6F9DrVGFupPhNoh/kSl/1Cb/QKMDy7XuIaq78XC1beFJRjv9sG1Bvg7NutOZ+5/MsW5alOUWmut oD2eZGhj/l2K098iYtw0H2Ptt+A/3ERz5XdpYK/rV2ojkd/Bye/jrAk4tg6ZlesXSOfx8DqQXucx j1COXJOSON/UxVb5ri50naKABld+HyeZTbPkN5fyOzh1P6t4nQH32NU9ji5xN6PLrCZ0mSeKTLlW 5IqlMa4E3MPLlOuqheuagPH7RzzOlHMv5naM5ffzt2IoT/VNmPkt9vdHmc1CO/4+9v8AHYv+QvpB jSlcjTklAWoLHyjc/AY+837FVusgNZao789eRziBGsg5Emuk813YwzRBlpV5mC7UawoYn46qnFvi 79bC5PyLlUWbwZbK79GAuY6sKt8G76e28ls4+Y2Zup8KnrOWY2C3j/JcN+O+HqMMdzw1cGfiOtIo 07oS1yzn9dvh2u5R3+G1Vm1GDPQo7XS94XwX2JS//wOtcR0NrRuxT6AdW4D27jYqVr5dyHeiVn3q 5kqjpij/afJ7P7DTNYy8Evldofre0MaxuSRUm7nT+S6wo5wTPj2fLH8vQ+Yvcb5RNNUc8FraodDf IEo/83P1zeFp/kD6GJxrBd+P1dCZtzxCg1xrQA7NNt+n2ajHwt0Y17AG4/dU3EMZleIZC/ldcBjx 98FSjfuB/D0lH+IyoU+ArRTyS03230GSVQdjIaDez5P273JMbmbTGj1Wt+4A80U49p0w5mBM/h0N 07+vBB+9tfzGTM77uS4grycP9XuA+ubT6/pFrfXFyfcw7B7qbHW3g9ZySrACNMbaTF4c65V5yO/P gCyvL13b6Ev5fZFH0BPQAmuEeM8aQU9ZhLERiScZbdu/yvVf3PsY+T4jr1nWG9TdVUBzzZcoGte0 yepIE6xGeEdzKcuKwLvWh2aYrfC85PexDhib7Xc4qNhlr5dYH1OO52cK93xKMZ4b8U5OxbWiDXJF UEv33dCD5PP0xvvwMiXI75utfdQ0bKx693vItBJ5f67J1MLVRX1fGee6H1pGce4IvFNDqYH85td8 yz7gSUOdvoVy3X3RviC9rOPufTTN9RyecxbVw3u+E+dNxz3J/r+F+pb5Qmrh+YFKXFFU6vajLiK9 eQt4UY1LP8Rz2cDPODhc/q6aHHOKF/H85XxbhZ0RvoMetA7TRuMwrZDADkBnyvi/AuPJAVyHTjXU tany24iWIYSE5XxNZT/wpPreYb0rU3whv1HXaWUabOgR6BNwTP76XpX8zkH1rfJ60jlPNfaOcr7P T3f2DXC4jVHXOEGlvxXIr/hbOHYV/mQsUkcR6uvtO02oTxbiV82Af3KQQZo/8SdQznh7TzUBC8Aw ohNB8AeeA/25notTb0A7MSfsMzmpfy9hr6PgVJxDl2rkOcxxQG07NaEaVzAnd0Jn8Lc3J78HPzq/ JyG5zzlfiRPu6CDDE5xr/gE6DfoTdJZDhfM7GD84dOR7kGXFcx/O/lBQA05dDv0ncyqDOXkPo/K9 izn5GXSwg5Pu1DLEf3T6+JPXOL+TEcpGsMVhlMN1OHa5w0yHPxx0WV3ucI3DdIdFzMkTzKmHHe5x KHVwyqWyPDQjQSuHtg6tq9G1KqH5q3JId+jvYFRFlW2J8/szoex0+LP4S6qh68R2rhOnLubzVT9e 1VUjpM5Wy+fUk8xJvN0nb2dOvVmVk5Mlco4B44RDDDWR6/tnfD/grOupNvA/+091xFEthJei6Tny oKuOpo6E0qt7rW2jExeBWqZ3n7HywVqNxCAYK7SxXBtXaqNMG1doY5k2lmpjiTYWa2ORNi7XxkJt LNDGfG3M08ZcbczRxixtzNTGDG1M18Y0bUzVxhRtTNbGJG2UamOiNkq0UayNIm0UaqNAG/nayNPG BG2M18Y4bYzVxhht5GojRxvZ2hitjVHa8GljpDaytDFCG8O1kamNYdoYqo0h2hisjQxtDNLGQG0M 0EZ/baRrI00bqdrop42+2uijjRRt9NZGL21cpo2e2uihje7auFQbydq4RBvdtNFVG120cbE2Omvj Im100kZHbVyojQ7aaK+Ndtq4QBtttdFGG6210UobSdpoqY1EbbTQRoI2vNqI10ZzbTTTRlNtxGmj iTYaa6ORNhpqo4E2YrURo4362qinjbraiNZGlDbqaCNSG7W1EaGNcG3U0kaYNjzacGvDpQ1LG6Y2 DG0IbZBjCFsbQW2c0sZJbZzQxh/a+F0bv2njX9r4VRu/aONnbfykjR+18YM2jmvje218p41j2jiq jW+18Y02vtbGEW18pY0vtfGFNj7Xxmfa+FQbn2jjY218pI1/auMf2vi7Nj7Uxt+08YE23tfGe9p4 VxuHtfGONt7WxlvaeFMbb2jjdW28po1XtfGKNg5p42VtvKSNg9p4URsvaON5bRzQxnPaeFYbz2hj vzae1sZT2nhSG09o43FtPKaNR7WxTxuPaONhbTykjQe18YA2Atqo0IZfG/dr4z5t7NXGHm3s1sYu bdyrjXu0cbc27tLGndq4Qxu3a+M2bezUxg5tbNfGrdrYpo1btHGzNm7SxlZt3KiNLdq4QRubtbFJ G9drY6M2rtPGtdq4RhtXa2ODNtZrY502yrWxVhtrtHGVNlZrY5U2tNsjtNsjtNsjtNsjtNsjtNsj tNsjtNsjtNsjtNsjtNsjtNsjtNsjtNsjtNsjtNsjtNsjtNsjZmtD+z9C+z9C+z9C+z9C+z9C+z9C +z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C+z9C +z9C+z9C+z9C+z9C+z9C+z9C+z9Cuz1Cuz1Cuz1CeztCeztCeztCeztCeztCeztCeztCeztCezui 3wPSgNccaN4rHj5zoHksZDmHrgw07w4p49AVLMsCzWtDlnJoCctilkUslwea9YEsDDTrB1nAMp9l Hu+by6E5LLM5clagWV/ITJYZLNM5yTSWqSxTAk3TIJNZJrGUskxkKQk0TYUUc6iIpZClgCWfJY9l Ast4Pm4ch8ayjGHJZclhyWYZzTKKxccykiWLZQTLcJZMlmEsQ1mGsAxmyWAZFIgbCBnIMiAQNwjS nyU9EJcBSQvEDYaksvRj6cv7+vBxKSy9+bheLJex9OSUPVi68+GXsiSzXMLSjaUrZ9aF5WLOpTPL RSydOLOOLBfycR1Y2rO0Y7mApS1LG5bWnHUrliTOsyVLIksLzjqBxcvHxbM0Z2nG0pQljqVJoMlQ SGOWRoEmwyANWRpwZCxLDEfWZ6nHUpf3RbNEcWQdlkiW2rwvgiWcpRbvC2PxsLgDjTMhrkDj4RCL xeRIg0OChZQImyWokohTHDrJcoLlD973O4d+Y/kXy68svwQajYT8HGiUBfmJQz+y/MBynPd9z6Hv WI6xHOV937J8w5Ffsxxh+YrlS07yBYc+59BnHPqU5ROWj3nfRyz/5Mh/sPyd5UOWv3GSDzj0Pst7 gYajIe8GGo6CHGZ5hyPfZnmL5U2WNzjJ6yyvceSrLK+wHGJ5mZO8xHKQI19keYHleZYDLM9xymc5 9AzLfpaned9TLE9y5BMsj7M8xvIoyz5O+QiHHmZ5iOVBlgcCDXpDAoEGYyAVLH6W+1nuY9nLsodl N8uuQAO01+JezuUelrt5310sd7LcwXI7y20sO1l2sGznzG7lXLax3ML7bma5iWUry418wBYO3cCy mWUT77uec9nIch3vu5blGparWTawrOeU6zhUzrKWZQ3LVSyrA7H5kFWB2ALISpYVgdgSyHKWKwOx PkhZIBaNsbgiENsNsoxlKR++hI9bzLIoEFsEuZwPX8iygGU+yzyWuSxzOOvZfPgslpmB2ELIDM5s OqecxjKVZQrLZJZJfFwpy0S+shI+vJiliFMWshSw5LPksUxgGc83PY6vbCzLGL7pXM46h0+UzTKa L3cUn8jHuYxkyWIZwTI8EJMCyQzEyDMMC8TI6j00ELMCMiQQ0wEymJNksAwKxMAvEAM5NIClP0em B2KWQdICMVdBUgMxV0D6BWLKIH0D9dIhfVhSWHqz9ArUQ/8uLuNQz0DdHEgPlu6BurJqXMqSHKjb H3JJoG42pFugbi6kK+/rwnJxoG57SGdOeVGgrryxToG68t3syHIhH96Bz9CepR1ndgFLW86sDUtr llYsSYG6spRasiRyni04zwTOzMu5xLM05+OasTRliWNpwtI4ED0O0igQPR7SMBA9AdKAJZYlhqU+ Sz0+oC4fEM2RUSx1WCJZanPKCE4ZzpG1WMJYPCxuTunilBZHmiwGi2ChFDuqIF4SjCqMPxVVFH8S 9gnwB/gdcb8h7l/gV/AL+BnxP4Efse8HhI+D78F34Bjij4Jvse8bhL8GR8BX4Ms6E+O/qFMa/zn4 DHwKPkHcx9CPwD/BPxD+O/RD8DfwAXg/ckr8e5EXxb8LPRw5Nf6dyFbxb4O3YL8Z2S7+DfA6eA37 X0XcK5HT4g/Bfhn2S7APRk6OfzFyUvwLkaXxz0dOjD+AY59Dfs+CZ0CKvR8/nwZPgSdrz4p/ovbs +Mdrz4l/rPbc+EfBPvAI4h8GD2Hfg9j3AOICoAL4wf0Rl8ffF7Eofm/Ekvg9EUvjd0csi98F7gX3 gLvBXeDOiA7xd0BvB7fhmJ3QHRFT4rfDvhX2NnAL7JuR103IayvyuhFxW8ANYDPYBK4HG3Hcdcjv 2vCh8deED4u/Onxi/IbwO+PXh98dv8pMil9pJsevEMnxy31lvit3l/mu8C31Ldu91BexVEQsjVua sXTx0t1LP1yaUs8dvsS3yLd49yLf5b4FvoW7F/geM1ZTibEqpadv/u55PmtezLy588yf54nd80Tq PNFpnjBoXvQ87zyz9lzfbN+c3bN9NDtzdtls/2yrh3/2x7MNmi3C99n7H5gd1zwdmrJkdmR0+izf DN/M3TN800um+SbjAiclT/SV7p7oK0ku8hXvLvIVJhf48pPzfBOSx/nG7x7nG5uc6xuzO9eXk5zt G430o5JH+ny7R/qykof7Ruwe7huWPNQ3FPFDkjN8g3dn+AYlD/AN3D3A1z853ZeGm6em0U29Tc1o eQFDm+JKKE707RSXEvdx3PE4i+L8cfvjzHpRTeKbGG2jGot+wxqLGY2vaHxNYzOq0euNjJRGbdun RzV8veFHDb9vaNVPadj2wnRqEN3A28CMlffWYMjIdKW9U1kv6qrudUiDxFbpUbEiKjY+1kiLjxVU 9+O6x+uasU9Hvx5tREWJqCg7ykiJQvKoOvF1DPnDrmOm1LnokvSoyPhIQ/6wI80GKZGIkTm2rp05 Mj0qIj7C8PWOGBZhpET07peeEtGhUzqZwisEiWiIGSavQsTGp+O9fqCBcAn05xUjs9q1y9gXRiMy /GGZY/xijT8pS/5MGZ7rd6/xky93THaFEFfnVAij30h/jPwL0iq8asMG6tssw98sK9u/o1lOhr8M Roo0bBjUrKIB9c1pN37OvDnt2s0djx/j58xtp/4hJObJUDsZKf/NmYuw/G+eClO7c26cDDJhDra5 OnLuuY/6/30T/+0L+N+/VZD8o+d9bGMlFRkrwHJwJSgDV4BlYClYAhaDReBysBAsAPPBPDAXzAGz wEwwA0wH08BUMAVMBpNAKZgISkAxKAKFoADkq78gVmRMAOPBODAWjAG5IAdkg9FgFPCBkSALjADD QSYYBoaCIWAwyACDwEAwAPQH6SANpIJ+oC/oA1JAb9ALXAZ6gh6gO7gUJINLQDfQFXQBF4PO4CLQ CXQEF4IOoD1oBy4AbUEb0Bq0AkmgJUgELUAC8IJ40Bw0A01BHGgCGoNGoCFoAGJBDKgP6oG6IBpE gTogEtQGESAc1AJhwAPcwAWsPjZ+msAAAhAVCcSJIDgFToIT4A/wO/gN/Av8Cn4BP4OfwI/gB3Ac fA++A8dIfi9cJL4F34CvwRHwFfgSfAE+B5+BT8En4GPwEfgn+Af4O/gQ/A18AN4H74F3wWHwDngb vAXeBG+A18Fr4FXwCjgEXgYvgYPgRfACeB4cAM+BZ8EzYD94GjwFngRPgMfBY+BRsA88Ah4GD4EH wQMgACqAH9wP7gN7wR6wG+wC94J7wN3gLnAnuAPcDm4DO8EOsB3cCraBW8DN4CawFdwItoAbwGaw CVwPNoLrwLXgGnA12ADWg3WgHKwFa8BVYDVYRUV9ygTef4H3X+D9F3j/Bd5/gfdf4P0XeP8F3n+B 91/g/Rd4/wXef4H3X+D9F3j/Bd5/gfdfzAZoAwTaAIE2QKANEGgDBNoAgTZAoA0QaAME2gCBNkCg DRBoAwTaAIE2QKANEGgDBNoAgTZAoA0QaAME2gCBNkCgDRBoAwTaAIE2QKANEGgDBNoAgTZAoA0Q eP8F3n+B91/g3Rd49wXefYF3X+DdF3j3Bd59gXdf4N0XePf/2+3w//It5799Af/Lt0YTxp/5hWPN VrPVbDVbzVaz1Ww1W81Ws9VsNVvNVrPVbDVbzVaz1Ww1W81Ws9VsNVvNVrPVbDVbzVazkeH8IagY MqWIJsANw/xvXtT/B5ul/uKPJf8CB9FxIf/fVvwTYfmntUxl1UP5yT+u5aYoouzMkf1GDWo3cuRF XfvN7dSJVAoS15Lr//YijtNxu0qE/qNdf/V0ZDrXrfsq/Pc/NiGq5y/UOExFP/7tklekPt/ixkUn /ji1rtZRz8MI1lL3gO3/AO5e5gUKZW5kc3RyZWFtCmVuZG9iago2NSAwIG9iagoxMjcwMQplbmRv YmoKMzQgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9QV1VEVkorSGVsdmV0 aWNhL0ZvbnRCQm94Wy0xNzQgLTI4NSAxMDAxIDk1M10vRmxhZ3MgMzIKL0FzY2VudCA5NTMKL0Nh cEhlaWdodCA3NDEKL0Rlc2NlbnQgLTI4NQovSXRhbGljQW5nbGUgMAovU3RlbVYgMTA0Ci9NaXNz aW5nV2lkdGggMjc4Ci9YSGVpZ2h0IDUzOQovQ2hhclNldCgvc3BhY2UpCi9Gb250RmlsZTMgMzMg MCBSPj4KZW5kb2JqCjMzIDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggNjYgMCBSPj5zdHJlYW0KeJydUTFvUzEQtkMBCVKgrKXoJtSSKBJjxtKoAZSGp1Zp xei8d+/lJMe2bL+qGfgJlTowIhVlZEH8Gyok1ImBhbFWu9QvQQ2sSLZ0vu++77vzcbZUY5zzleRg 0Nl/03iF8hA9paJKPg+rPDyphbVbVy+vvl6+v9y5vcZ6H38uh6d1Ng2/HocfK+H7w/Dt0VzlmE/5 F/57fbB7sNFoNLe0mVgqRh5etNttGE7gDwIddFQoeBaDQ5TajFH5Fuwhgh8h5CQRtt4m7173u7De 7Q+giwqtkJCUQ0kp9ChF5XADcm1Bzh+QapWRJ61cCzYdCHAGU4okPErRVEATDNoxORdjIAeFFcpj Bl4DqVSWWWUf87lWHozVER9HJEol2nmXWjIeomPS2Z736EfCV76OIgw6j5WZTstqmhvMC1IOPB75 ymeIkJEzUkyib5QylmYtlI5UsXBvgsVC2Eyim+lWv7KYD/6aWhgjJzOunlXd+JN3KPNWn8bD0sGe iLQe7GJRSmH/SS629H97Y4xxiJfVOF+6e/H5QTx+Gj6dXuyc9qZ3zu6d3z87qdfPP9SXGbsGqSbY KQplbmRzdHJlYW0KZW5kb2JqCjY2IDAgb2JqCjQzMwplbmRvYmoKMjAgMCBvYmoKPDwvVHlwZS9G b250RGVzY3JpcHRvci9Gb250TmFtZS9ZWENEVkorQ291cmllci1Cb2xkT2JsaXF1ZS9Gb250QkJv eFstNjEgLTI3OCA4NDAgODcxXS9GbGFncyA5OAovQXNjZW50IDg3MQovQ2FwSGVpZ2h0IDU5Nwov RGVzY2VudCAtMjc4Ci9JdGFsaWNBbmdsZSAtMTIKL1N0ZW1WIDE1MwovTWlzc2luZ1dpZHRoIDYw MAovWEhlaWdodCA0NTEKL0NoYXJTZXQoL3NwYWNlL3BhcmVubGVmdC9wYXJlbnJpZ2h0L0MvRi9J L0wvTi9PL1AvUi9TL1QvYS9iL2MvZC9lL2YvZy9pL2wvbS9uL28vcC9yL3MvdC91L3gveSkKL0Zv bnRGaWxlMyAxOSAwIFI+PgplbmRvYmoKMTkgMCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCA2NyAwIFI+PnN0cmVhbQp4nJ1Xe1xTV7Y+EXI8OmpVTJtU5ySO bRVf6Fh/rW1ta6FSFBEVFIqP8ggQCElIwivvhPDckVdC3iE8lJeCiPjWWq3P2nHs1baj19t2xrEv O6U6dvbhHn+/e3cSgsZ67x/zX2Dvs9baa33ft9ZiYOHjMAaDMTM1JTpm85oF0eIiqYAvXfSOWJi1 PkMoKCzi+47nUzMZ1Kxx1O/DEujekVsjNPP3WLxnxmSKnIS1zJqhmj6yZtrIhGeo76YG7O1kdDGG GA/mJW/cErlgwcJosaRMKsjJlfOWrlixgpdRxhs94cXwZYIcEe8l9KOYLxRLCvgi+WLeJj6fJ8/l 87IFQj4ven1ialxCLG9ebEIyL5Yv4kvThbzEIhRcJi9ekMkXyfiRvGyxlCcM/MHLFIuyBHKBWCRb zFsl46XzZBJ+pgB9xC/N5Et8Bwt5Er60QCCTod88gYyXI00XyflZPLmYJxBlCouyfO7R/7PFIjlP IhWj8wJ0gkwlimVyWaZUIJHzkMfEmNWBGOW56XKfX5kAHfPE2ehmljizyPeasTN5ukAk48n5pXKf nww+L0sgkwjTy5BfZEoiFfhDKJIJRDmPvC/kSfk56dIsIV/mt+vLyqP38R57dbpEIizzfyv23xrz L5DL+MLsxQmCgowiGW+dWCTmxfN89eWNFjjk5FGp/r3iYRjGiy8TZYqzEqIl/PXZidKc1bKNcsGm oqQ4YXppQca8SB6GLcLex9ZjMVgi9i4Whb2AbcBWY0uwWGwptgl7D5uLJWHLsGRsDfYythlbjs3H 1mHvYKlYAhaNTcAmYgxsNgIZFo5pGbMZn4/LHTcYlhr2a7iF+QbTw3yAt46fP34/8RbxcMLgxK0T /+d3+ZOWTBqc/Ork/inTp5x8Rjk1eup/TVs0TT1NR/00hfoJDFMRwwz431QJ6yzeA5rrnDaH1eIB LuA2ODX15XVGUwkgaAGeD8prVFq11lAGlITIpRsiP8ZfexjB3Bg40ah1/hOxSztEUkJ8CCbVOU1m 0MhpU7jkSqVRrSH1+ipDpaQkik3n48g1nT5MtXgZsKqOtZLGmHNxITBU+10ogi5gHt4NbHUOm8Nm cQM3cAViKjeVAqIShzeohIH63R1gDyck2ihkSV+t1o6GVOhW7yEbcPo1WhYLZQdN3R1gHydoqsL3 wdKga/8HQGbXdlYRvuR44VfDed7p1Nr7z0UMwCEqjrXIbzt4lZC4Nf1kKq1nVgR9jkV/gIThj0fv 8rtsGHVZge+Ha5gRVz881+8+OvNklyLfWGusMXCz6dVSoEOGOI/n4e94F7CPGSI6FfZcchCuqXPt dAAX53riiWVJ2aptG0gUs3IYtgwzwL2wkXHUDFady9QAmogOtUNWrDEU68lc77bmTWAxeF2wfk1q snAVeA9saUsbLOgXn1FfB8Pgc89HA7s9zjbgJToUbrlWX1WuI9MEOfrXAfFCau8n/c7Bjh7uwJGT 7ZfBYdBnaFdaDfV6oADFpopGY1O5o8Lmw47ZZmturrc27iIeCwl+fi+MmkNtZi0BUZkb1m5NkawF Gwka/+YtOAO+AiPhc/BFGL78Bj2VlM9lfXlme/wry1a99GbSkU++uX39HhdZUg9DD7J0P2xk4Ug4 iyZ8dQuiUgUUFpW9ylxtqfUAwoUX0lNz+na4EgFnKYgRJaxL2SKMBrEgqX3Lgby94uPqC+AcOGS/ sK88lw0JBH2rL78h0PcXSonTabCetR90Gz3qzhKnEOQCoVogF+d8sLUoERArtx640uvoa+/i7jt0 rO0sCOCGOoCAbaFIFox5SDL/gd+nSnb5PXBGsRDCrmfRO/zs0gRK7kQl78fX0UfoaGoWk8afwJbv 2OkjX6H/3yFIgSwEFUe93RrKGP9TcnF/CqmoYYF3Orj3XMQS6jJ1gRVxdXdqnnnLTDoK0HPoKQL6 ZXUcu6qspgyUEfT0u6/CeXdu7jp+ltzdamsBLUR7mUeu0Vbq1GS+pBZojRL1B4ZtgHgx/sRNq8le Z+c6Lrc9+PYv9wDnCjgvqOHXlrJr5S5lRwAW9ubmOkvjbs/X7Ho3qEfQjFjiEwiFxqhQkAFRgOOH oXGYQV38JQwm/ol1KGtIgdIKl0MOnAD/AMet/A96yrptyvQN3OYjTD8GnkyOG1/0MIGpfBol3wlW +glBKQPEBhzWUmmsL07w12eIt2dIuAWlOfoMkA6EzUUtpR5tt2lX/c0vL/wEApi+ffsOCvJr+DbL PIiIiOjNgcSrX9DPIqGZS7PpSBr/OgbO+k9ItLYfIlutNg9oI9pULrlBU1OtIRfKRZU7wDKQ1qW7 QLTdZnWd+bT/c3ANfJjTkEwE64SgToXfD6PepH5gvQYWbo+NiXs3Yx6IIujnf5wLI7767vC1q+TV a4N3wV0Cshf+TM8gi+eybl2I+yP9HB1OT6MnvJ545Q5iVzicDsdz/XoP9cN/RYHj8A4LLggVqDHc FyNQzsebBsx7e1xnAacXHKnqN9pqLLWNgOjp7ult0dmKGrkFlnVNGYCeBJZvLIkqz2ZvQ63AENIk DpJHcZ86bgg2iUApUJNApfjQJ2r1jiBSnQbXI0ZwcX+sw8NwLYpVAbEwqIdbWf/AH4BLuz6+vP9g 60fgGPHD6nN0OEmrgzIwRp+DAX4wVaEQ8DcnKAgyxGppQY926l3aoN9I/BYVwYIT8XP7Cj94L2nr Si49MRAJrPs53zs9opUaj5oAPROXAmWVRjdmF0GrH73UwEz0x6LWhIAu5KW+PhDy0l44jxnx9hf/ Ot7ZO9MJLJU2jU1jqXQAore3t6d/0+Dm97NVCfO5AXJ8G1RAqpx6kZW/d7t7MzKymCZpDj2fxm6s gvipo86+01xtkm7LjryNgEMzAukJduiATIThcBz4+Wbbr1/CEbbrcVKEyh89AaeXLmddObYj/rUV by6L23r4k1tf/eWvo1Ca8zOcjaaHWljF+gavMdboarTAyCl2K9tcbrPdRqIeYGno7IBMdkMLMAEz 4R8GFOUaLWnQVxoqC2uM7FfwHjibCS24LsX/fQWn2IO+d5ntdvR9nbmxcw9cwH6YFwSX5pHYPSry Y4NDoMh5/ze45uFjPek6ZMJoGB5GieGnLHORzdAKnMAXuV+lOs0D7DqHyYJUqk3lKFIaKko0ZK4n 05yG8vL8nJila07mwyka7kcVrVVOo9vYrAVaQrqhKDY5075bTlb3aByFqFuUFOu3GfPY1apaI6gg 5G5Vh91cZ3GQ+0qP688hYXsBhl3/fqBsj9DLLXRlW99pXmepMGkbNA0Gn+eWUy1nDvYaStrJwECy fRguR5Qo8lGiEkpZd/FB1RWa0RtJ3Hhc+V1Ej6o5ndTgkj+Jj2cf+PHY8YvgS+LOu2fo8SQtC05z micaypO5DGAlMsRwEL5+zczFj6EY+uByJhp2zu6X8pNX7VjCDeS3cRg+72Uc+mcYHPRpTdxTtMYw CrI4vOV2vR8hnFGEaLW+cVFfWVi6jJ37lOGzH99G59foa8uBlgPyHeJ2ZXfJYe1h8Bm4236mp8Nu dSO17VC65Do0VZWRqfIUHSJKSqG1rdFk2WkZk8JbDxjUeh+lVwfw9RhLDpI3/OJFTwlVr0BS7v4/ nJ6M/0R5WUg65H9gwoljXZfx468w9dewkYlUF6vO4x/MWpVOWamuXKokC9rSrSno29n0hAU0kdGW 2SfndpX16C/rrmq8FS6NXd+kAWoiLTbr1TUbu/dVkzWdAFQ2GS0IKQGQbUdtu0Zbo0MgQwxsd1ka WlrJw4UnNacRyKLg+G/hlOOSoe2t3EKb2LzJ+pZTV6e2aZvLkQQSRy8e+OzSQUkmacoHoMHYZLBX 2ANUsFua682NXb6WpBmGX3kZ3Uh7hgMi6MeKbrQs4kBZsui18ckidSrgpEk8vWZT004z9zzsHWvU geuqgDK6cD69pkpZqwEKzqrz79/+uM9x7AKpT2P+gMCCZgmb0zeQuYndvoF3bFuhUtC2Ahl4yeJq Ta0hIDjtQcGpa2rsGoLJ7Id2PINOrtbW6tGFEo+izel+pCje79n/wlcgvK99WmNS4p0I746QEWoU qXH4oyhSURS/PL4zuUN6CX06dDPys+wXP8teehqgTj911fGbmjvq9Q3ktcQ3+K4ezaXKn3qgbFba q5qqrbUuQNzElz5849/CbIC14d9dQv0FMuCef4ZR7GfhhNFKPGWeVOCH4PY6m6kZ2DmfrT00JylS oRSQJQZNCSgi0MjXZnXsrHeTR60HG/cA4mynVlIBQG0Vt1Ke1VRQlw84L4LluZvjC4XqfCAi4j5N +/v5S45dH5G7YDgrXpCoSAIEX+RssZltLgd3z+4hxwnQB/ZV7TeOztizvQxqBURQiILjBn174F5O SLGi8ILArhbIEhJUuy4mlZ1yot3uQAuOb2l0jC1ki4OXR3dAh6a7+gHNYNNv0zNkNdoqjYqj01Wo gGY0l+P8efGXy1f5FqNZbv3bRfalBGF5sRRIOIFbT2yAu1X2AlPIZjng3yw1iE+LR2cVVaBiaLPs 82+W6QXSXJ8x7u3fLIEC8hBMR0tk30CbtWump9morq4trzFy4+jLiEFP3s7z3T64z23pBBwPsBhN GlABKmqM6Db7t7cF5DEo3mk1NaHint8xFJ+ZqxJkkUV7C1xZoAAUGTLExNhCRjnvh8ELwY1sjOSj o5jLj8inTuMEbu4/nDOgOQc4t8G1ngsXPzzVew38GZyRn8rcm9/1viMBbAApylQBAWelsvb9ZgfL /SCtaCMg3tiGdjB7X4dvBzvadi6wg/na+tWRSSwxKFFsjqXH05FbaBagSfByN00MrGvS2CoQXfb0 dO9pqG2otHHzb2ougasAzjoNp8Fn4Dynp8GKlLFd4ZL5pAemIoPwDDKYJxLlV5gqG3Tc3pWOeLRS 0uQWejIatheoyip1SNrkbmVHV6vnyikSLSwLT8LpAJLgbyJIZF8y2rWNSn98U0q8VJwXTvd6vfgv E+//7nvzpEkY9r9Mr84pCmVuZHN0cmVhbQplbmRvYmoKNjcgMCBvYmoKMzc0MgplbmRvYmoKMzEg MCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9PVEdFVkorU3ltYm9sL0ZvbnRC Qm94Wy0xODAgLTI5MyAxMDkwIDEwMTBdL0ZsYWdzIDQKL0FzY2VudCAxMDEwCi9DYXBIZWlnaHQg MTAxMAovRGVzY2VudCAtMjkzCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAxNjMKL01pc3NpbmdXaWR0 aCAyNTAKL0NoYXJTZXQoL2J1bGxldCkKL0ZvbnRGaWxlMyAzMCAwIFI+PgplbmRvYmoKMzAgMCBv YmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2OCAwIFI+PnN0 cmVhbQp4nI2RzU5TQRTHZwq6EKwfiSshHBdExaYJC2OAleGjahporGjcOb333PYk05nJzDRySdiy gbBhh1FMfAjDI/gCbuo7NK4YYePcNlqX7mbO/5z/73xwNllinPPy1qva+usXj5p5t6VlEVkId3mY KYWZictnl2cX3y/2r8yy+qcP18PsNDsO326HL7fC5xvh4002UVjs8kN+tv3yDTR15t8LixVY1Sa3 1O54WFxaegKtHKJehSYi+A5CRhJhdavx9vlmDR7UNrehhgqtkNDotSQlUKcElcOHkGkLcvSBRKuU PGnlqvDUgQBnMKFYhDsJmkKogEHbJefiG8hB2wrlMQWvgVQie2mBj/FMKw/G6qh3oxKtGtp5l1gy HiKxsbYx6tF3hC+4jqIMOouZqU56XYz1fzQvSDnwuOMLTgshJWekyCM3WhlLwxZ6jlR7TK+Axbaw qUQ39C22Mp4P/plaGCPzYa0eZv3lk3cos2rTC5VGJxgd0EF9vPz/OApjjH9lzLMS55P3zo/K4V3Y P+Xne+Hkzvzyyv35/vJg0O//HKz8WJgr/3p8evXg2sEUY78BGmjMZQplbmRzdHJlYW0KZW5kb2Jq CjY4IDAgb2JqCjQzNAplbmRvYmoKMTQgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250 TmFtZS9QWFZEVkorVGltZXMtUm9tYW4vRm9udEJCb3hbLTE2OCAtMjgxIDEwMDAgOTI0XS9GbGFn cyAzNAovQXNjZW50IDkyNAovQ2FwSGVpZ2h0IDY3NgovRGVzY2VudCAtMjgxCi9JdGFsaWNBbmds ZSAwCi9TdGVtViAxMTEKL01pc3NpbmdXaWR0aCAyNTAKL1hIZWlnaHQgNDYxCi9DaGFyU2V0KC9z cGFjZS9oeXBoZW4vcGVyaW9kL29uZS90d28vdGhyZWUvZm91ci9maXZlL3NldmVuL2VpZ2h0L25p bmUpCi9Gb250RmlsZTMgMTMgMCBSPj4KZW5kb2JqCjEzIDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFD L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjkgMCBSPj5zdHJlYW0KeJydUmtQE1cU3iUkWQVR SbcCanKnD18gIq2DUay1IihSxIgo7RQmhE3YkuyG3Q3PgAoOIlfFwaJWxSBCwVe1ighUHVRQi1aw qET68DHaOtOH1TpzNy4/usGOdqb/+u/c+51zvu875+CYrw+G47gmaXVKTEp8aDJto/jpBtZmZLzf oeJ4XJzgI05USNHSkefO5xHKiVhCrWKUqPXH6iYozwV6RowVn44WH4550Wgz3oS3454pKw2rpoaG hi1k7QUcbckSwEy9Xg8yCsA/CIiheNrCgElykEtZWbuNYoRwsIKigJBFATNtpcDCZUmpSxLjwJS4 xJUgjmIozmgFSY4MK20CCbSJYnhqKjCzHLC+eAATy2TSAs0yfDhYwAMj4O2UiZaLqHwTZfcCYcBO cTaa5+UY0DywcEZGoDKBwAKaMVkdmV56+d/MMgKwc6yM22REbpXE8gJv4mi7AGTGpJjYFxqFLKPg 5eVpGQasWc7MZE0Or5uXmGCkGR4IVL7g5cmgQCbN263GAplXbmXn6GEJDp5mLK/YwwBHWYxcppXi h/t6p/LKH/iXa6Pdbi0YrmWHs17y0wJPWc3hibQtw8GD4Z2CRFYPEoCBsjisRu6/yKt9/b8NYhjm 9867s0DU7On68JmRGPYaRmKvYzgWhAVjAVgINhoLxDSYv3wqmC+2CbuMf4AvwnPwZz6Ej8Nnq8+g IgJtCRArio+KP18KRM2DVP84TR+ajn4iL8L6jftLv3EcN8BYIsoQv8CeV73frLXVFlYXQkJwFudm tTquuwcbWzp0HS2N3fAaPFvUwRzM25e/I30vobnb19Fw7FzID0svzEhNL8y2aG12Z45j2a4NQS03 2g73QOJqW3qCxWnhOJ3NxjrjeELWAV1o8hVxnisQHb79nnuc5pFoRUXk2+LydJV0bWi5cik6Is1V a/50o7lPVNLiK6S0XoXWo1+VXg/HxK5BHN2+rkBLxO9JtFq1G1Zt3lL91YOg0mpn7rryXBgsUSoJ l9ZVboSVcGNweVXFtkMn1pe0aJHa3PkhnEKEJr4/L6+wep9Nm10v1ORCgilew1Ed/K07/V+cPaNr b6vrggOwP7899Uz6KUO9NLKOCBgeYJlLvHETF1d6ppFDKlWSNHlPWWtv7c7zMBjZVNJHQ4+UV1Uo y/PGsNAmT0BTIBxYdBOxfckD4zRu1CqqyT86vzwJe4kfF16aLOFzFkfE72WezdBqHkiY3mGNC5k2 GIeUyN/97VM3fVoa9VBb8BZ5Y9V+C1xBxKelxc9f3X3/yr6T3R1ajfu0m4zstrTDC0R3W0tPb2t6 rIFNM1Da8goIN1TIiu+hlB4cokrFcVRDJqDKHrUsC61rFX2bcPiL4qKDRL47z+/tPf3XwGU0BqLx BNLPQCMkUvKLnCSNlwL65yDs/MndLZ3aDClKUgApLIdAF5GHhHkbSteWsry5xAKJ+R/fQn5duy/V Ner2uBq2N0PiftssKVonj2ytC0djH5M2LsfKNHDNBxsbmg/mNNp03hvYJXZ+/p0Lf3JPgU55ZpPS 4ghlsXrH1u1VVZtrq/dU1UCi7jNntm4oVQ0/LROKSp2lxRXGSsKJmnepozcV1cCvCfE3ryM4INbf xNHlewqRRRPJkq1mQ0lpmnwFZSoUjWIePDo+AG8HP57jfjN5lcNk1mbTzuzCmLryoBO/Hz3UB4k7 XYaoeZ+ER0XqpFhpuXKNGKIOyHOJKS6U7FIdGHnX78A2f/+7tf6jMOxv0Q+CDgplbmRzdHJlYW0K ZW5kb2JqCjY5IDAgb2JqCjEzMTUKZW5kb2JqCjI4IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0 b3IvRm9udE5hbWUvQ1ZRRFZKK0NvdXJpZXItQm9sZC9Gb250QkJveFstNDMgLTI3OCA2ODEgODcx XS9GbGFncyAzNQovQXNjZW50IDg3MQovQ2FwSGVpZ2h0IDU5NwovRGVzY2VudCAtMjc4Ci9JdGFs aWNBbmdsZSAwCi9TdGVtViAxNTAKL0F2Z1dpZHRoIDYwMAovTWF4V2lkdGggNjAwCi9NaXNzaW5n V2lkdGggNjAwCi9YSGVpZ2h0IDQ1MQovQ2hhclNldCgvc3BhY2UvQS9DL0QvRS9GL0kvTC9NL1Mv VC9hL2IvYy9kL2UvZi9nL2gvaS9sL20vbi9vL3Avci9zL3QvdS95KQovRm9udEZpbGUzIDI3IDAg Uj4+CmVuZG9iagoyNyAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDcwIDAgUj4+c3RyZWFtCnicnVd7UFNXGr8RuLm1+ChpWi1tcu1DalWste5sp91VqqWL VURFrFJUCEFCQhKS8AgJgdwkIBx5NLkhhATCUxCCj6pVfLZWad22U7dru21X9+Vut91xNrR291zn Mjt7bkLCy+7u7MAfSc453/P3/b7v42HRszAej/fguowt6zM2LF2nKtbIpJrlL6sUudzvy5l4HvPo LOaxqL3swN2f3WVjHsM2tsXNYUSx2IFYXuejD56Ou/vTBxh2HvPb+SFZ9Twfz8+7/fT2rTuWLF26 bJ1KrdfI9uXryJUvvPACmaMnx0/I9VKtbJ+SXIw+lEgVKnWhVKlLJLdJpaQuX0rmyRRSct3mtJ0p qa+ST7+aup18VaqUarIVZFpxjkImITfKJFKlVrqEzFNpSEXoCylRKXNlOplKqU0kk7RkNqlVSyUy 9EhaJpGquYNlpFqqKZRptegzKdOS+zTZSp00l9SpSJlSoijO5dSj3/NUSh2p1qjQeSE6QaLSVFqd VqKRqXUk0pi2Pjlkoy4/W8fp1crQManKQzdzVZJizpvImS5bptSSOmmZjtOTIyVzZVq1IluP9CJR ao0saEKxVqbcN6F9GamR7svW5Cqk2qBcLioT/pGTvM5WqxX64FtV8FZEv0ynlSryElNlhTnFWnKT SqkiN5Jcbqf8MpGi/y9pGIaJNibplZJNqtx1aun6vFc0+5K1+TrZtuL0FEV2YQ6JYcuxx7Fd2GZs PZaIpWGvYE9iW7Bk7CnsVWwxtg37BZaApWMp2HZsA/Y8loGtxp7BNmEvY6nYOoyHiRGssGisiZfE +3ZWc9STUbejV0b/PsaIL8Or8X/xjxM19z193/Bsy/0/jcVivXPi59ycK5l7Z5563o35JQ8888An D3zK3J7L3AYBRhDgwXkBKA9EQZopFV7Gu0BzvaOplaa9wAs8llaT02y31KsBwRbgRcBaR9mMFFUO yoHBYWwx09bm2h5AXB4TbJ15Sjms7v1dgGAUMB0HPXW0jTa3Gmh0CIxWc4XVXEsBNbGClfODtlwJ wLU+f4DHPA+fE3ZtidHdQyJtde3vBgQU4x2gZaqdtNlB1asAm8mULmAVuDr01kwZwrY6rc7aXkD8 EmdXjAk0gELHC0OyiYLO8lMiuHCm0LDzOrzrSgzcGRCyK/GvYHoMMpjNDjDtPh6sbhCms1hMAq4F VC1VPcVaSzA6UI53Ahcn2El7QoIrkWBzfREgqnFYzqT6G9rbQP9C4LG2Vjip0MkK3AJqQVWtcn+5 HoVJ3qU/IWJjWS2LQ+2xAx1tYGDhFEkrceuk+0DVph+oIbjA+uDvAgW+uF9zWX5YcBruYFKEy6cI B/LO8rfqCNZs42uAZcIJo8PgopzjIY8ORyfiRCQ6NrgBF3xx4cygdzj+ap9ul5hN5ucW6+UorKfF f54SVWKwuC1XBDfwwUjZScmhgu6clt0gHciMmVmcsYYAbA/wQCCKOco8KBw2+gpKqqgSmyjXl+nc ijC49PEE9onUjozjEvG5zKslt8F18KHrhO9ER1cv6CX6dF3qSqrGQomKSqprymxaS061BL26L+3E zWPuI7294r7+o+4L4BQ4QvUaWqg3qUZ9U3G9zWFzWFptLcADWh3OFjtd70TCQvUh8ZX54j4IwOso dF/Ax5mFQjibbYz5GodRsDGGPZnPnwJSFLEI7OFDuA+0NtgbQxELec4I+KFkh3NHBWtrFs7Gs+dZ ETwfw/JwwekDdXWgNr4SlNRU70cY5kqmsF3v30+MCYKRDcJLTFtbgqkRTlHEocjkrAqlJh+fFFV4 DZX5e0yGkH2ajVnMLmAfgviTkPvDv4cPQSGL32EXiesShH+6lpa0NnnLc88lX/n8N9cufy1GQioC sC0o5ALKTt/daCFLTC5QAwd5V7jIPOx8fO/QG57NYA3YVpK1J2uPdgvYAFK6tw7vHt7zXsnnYAS8 1fLOESIfEvzplBMJiwFnG2Cj8DwYrOxX9WjcBWAfkFfINBqVWmbKBJlA1qI6qOmt8IMh4HcP9fT0 9fldZwERtJZZEZD54gDK27PMNuZ9oeBab3q+Y0c8m8jOZueyz4tT+OwyOJ+Ngj//9Sdtg6dEQ93t vaCLOIhAZKqsrqoSqVUAVNk0RollN0pR7M8/Cog/5P/w2RffDR2hjAdF/QanqUnbqK23OiwOi3sy fppBD/F7PqI8h40mBM+2UgZaH18OKm0mPRGiDsgPQGuAdzMAz6OcvPyx8KLklGGEY7bvv4bzoPCJ 2yy5KduQvUt8miX406llIs5jqQaOeKbQJKrZceJ5eRrxWIM1G6SLLThcwmQKTwA/1VvaX9KeBwqI VzbtXL0q9fyng+1H+ztEvT4/fRKEqvLWrb8gYj4D1wrf4kMRO2uUXcIuZqOfQhh6FPKWwhWfftfm Oy3qbm52Ax/RV9Kppipr91eKVmg1NVlgFcjo071PNNwStr47cuQ6Ktor+Z50ItKBUH31B6I+Cwil Or08WEIRaO/F/wTe7zp3cfhs91VwnTjDhyvZaDiHXSxi88McH+Jweaf+LVFgTCBkBHAW/x1wzHAo v1/m2QPeILL44HVTvkqhkBdUbgYhvdAc+CPqffNR9C/Cvwjh0hkcPdH5lh7F/Qc9lwfOVtuGRK5a Z92bgOjt6OzvMnrVdrGc3mjPRrfuT9q6QpyXxVfP7FoWVy1y5gxr3oJPpwsX6mkhujg/rYon84MY Dxn9xN/hokDcjQA0BX6GkM3ADFgj/IMVB9p6qomijV7KC1onsxiM4QMaNNTRNX36NjUwAqPFbBrv vNafwEXQtJOPHpubKKfRgx6PQ9hZ7wB9BHxmbDv/R5t+65jAGMbeRJsNs5/gB0YOl6G2X0tXT2/7 FqAidrA0P5yIVYG4LpiVgBy6BgdQd2Lj8XJQtt/GId4wrZkKPjj838LYEQrjtC6u4sIIE3DBs1/+ 7Vj3YLwbOKtbTeiw2g2Ig11dfW1WV4lXrOiVu/LBLiAtf3HzeK1+HWa+Q4j5EpmnhLn+TO92JO6R pxLYheyC7xLgIxffbh0aFqfzd+QVbBUhCr/H6DJek9E45N386h9ieNfz48yHuJUVrxZ++UHa2nUb 09as2TTy2fWrI78RT0IBD6GARugNI0BXX4UQUOE1RxDgrKfBwSACeursNicVTgKHAKq2CmhCCKBf 5wcfW2YgAD1eOib/3xBwj/4nDwN6pn8JE22pHc6CcjgrilkOPxK6it0USh/wOJwuZAKH4KN8NAbI jZS1zCLKbctx7OK4ePXWF18akUDSKH7X1lHjtXZYWiqAidBllL62PbulVymiDhncRcggBLcKSwju BfxQlTgNHksbaAGOhmb6eNkF82Wug347cnO46O093eJCr6R5rfM12nagosnwppkGNNF21nvhpJ8q 7ROFxymOtwtQ7HeE2uAUeubAOEHPL9nw6SMVCp9tYqRy34NzVNxI9Rp++VKn6wwYAO3V3gpvRWMl kBHsGm5EC2qbNNnStpapI9rMgNvgRjyw/uNFO3aX5khEoeC/GYCP+HijyI8CjgFTwgw46fX4FMGm 3MJBLwIRTbWWj4OIqkRxNYMiYtXMGSjSgQ6zcvwnn2ZA/OJX3q5zomNeVwvoRv2hS11lraXKRbt1 mVUZQApU9soWm72WBh0Rdr7xQxx8Fs5ejVjhG/g9xwrJqKos96BWpOdL1szO/fENBN6ewa0T7D4X F4xWMD4hO/txOBsPzw483x144E4U42b6hMh11Mgtbs71UkBZzJr8zj3Nr6O38xPXLN46kHFBKR7U D5o/qvqk0lPTUdVZ6S4FJcTeLQVJKRv7j5hFloMAWO0UbWqqCLEgR8FcAabwd3tKDnvsjT6v6FzR O6Z3ka2P/fVXdy6WnZAMihU9UvfznrXu6vpSZ3GzsQtF5+3z/l9ePauW0CK7HAB7cPBwTxQ8x9rI A1MANgRBivY6xh5i1Jl1SodztAHfka4x7QTEZlXXOTEcQBOHZnKklT26Q/XNBxZ40E2Q1r73eOGg 9qTpNLgEBt3nzxCZf+NPXg1Cg26kuYPAPwOQh0D2HdovIS+RYypzmKlCZONwHrBz7Wb7WAu7nT9+ HuxlU8jom3+OCTbcY97mZgUuyYYZfBNJcgo+se6+iGz5HtkyOm3X5XavMCYu/fiuOzomWDyj/Uxs ppfwU51ef1CYeFza4nHlLyHlaZxyjjWScU04IQagBwa70R0B89hL08E8hVf/M5hDtR3916uBOPAP aB3l2irDLHgI3hdkG/s9B224G/8m6RI7b2eSqTxTVIpIE+FX2VHcR7vrG72iYdfRJj8gPuw3ysQ6 fo5d0SAHz4Hkot07tWpjPlAQSTdS/z4y4u45KxL8cABGC9Nl28pRh9xb4O08dvXwJ0NHa6zHxZOW 0fcDMIr7f1hwDi5C+Eyc2EfLQBFQdOqPcfsoX1o8bSC8hc+EGszmC24MHWpvPhjf46xSidkPv50K yIHidil3a+iIh0as3EublcFLXKaQBKkYqvifb3tvbY7cKFOICv0FnlxQCEqpfBURWXzCk3qE8aeO 3JMY34BrptGUK8LQxGH84r7jphHwGXivY/jU8Onuy+Aj8LH2StaprFPbOtaCzeANw14ZAZfsFJ4N rj3dmlYZKACy8NrzBiBWpV76yu/29/SIuX3nXHCgnVvqY1J8MM7n8+Gjs0fv/8YRGzsaOwfD/g2p 7DGvCmVuZHN0cmVhbQplbmRvYmoKNzAgMCBvYmoKMzUxNQplbmRvYmoKMTEgMCBvYmoKPDwvVHlw ZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9VTktEVkorQ291cmllci9Gb250QkJveFstMTIgLTIz NyA2NTAgODExXS9GbGFncyAzNQovQXNjZW50IDgxMQovQ2FwSGVpZ2h0IDU3NgovRGVzY2VudCAt MjM3Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxNDgKL0F2Z1dpZHRoIDYwMAovTWF4V2lkdGggNjAw Ci9NaXNzaW5nV2lkdGggNjAwCi9YSGVpZ2h0IDQzMQovQ2hhclNldCgvc3BhY2UvcXVvdGVkYmwv cGFyZW5sZWZ0L3BhcmVucmlnaHQvY29tbWEvaHlwaGVuL3BlcmlvZC96ZXJvL29uZS90d28vdGhy ZWUvZm91ci9maXZlL3NpeC9zZXZlbi9laWdodC9uaW5lL2NvbG9uL3NlbWljb2xvbi9sZXNzL2Vx dWFsL2dyZWF0ZXIvQS9CL0MvRC9FL0YvRy9IL0kvSy9ML00vTi9PL1AvUS9SL1MvVC9VL1YvVy9Z L1ovYnJhY2tldGxlZnQvYnJhY2tldHJpZ2h0L2FzY2lpY2lyY3VtL2EvYi9jL2QvZS9mL2cvaC9p L2svbC9tL24vby9wL3Evci9zL3QvdS92L3cveC95L3ovYmFyL3F1b3Rlc2luZ2xlKQovRm9udEZp bGUzIDEwIDAgUj4+CmVuZG9iagoxMCAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDcxIDAgUj4+c3RyZWFtCnicnVkJWBTHtm6E6WmF4NI2i+j0uCJucY0L RkERRAVxwV0iwoAT2QRGWUTZhq3YGbYg4BYVFdw67mtcE5e4oEaj8UaM13i5CZqY074i73vVM8i0 9yb3ve99H6LVdarq1Dn/Oec/pQVl1YGysLDo7O8702PBjMFTI3XRWk209Gmo6GQh9uwg9rLciFPe qt6eUfSiZlV3/UBU2VC5Nhabe6qbur092/Wtc2fxQRfTNnkWWy32Wfwy0H/uQpfBg4dMjYyKj9aG ropVjxg/frx6Zby6bUbtoYnRhkaoB5B/rNWERUaFayJih6nnaTTq2FUadYg2TKOeOttvsbevl3qg l6+/2ksToYkODFP76VaGaYPUs7RBmogYjYs6JDJaHWYaqIMiI4K1sdrIiJhhavcYdaA6JkoTpCWL NHFBmihpYog6ShMdro2JIf9Wa2PUodGBEbGaYHVspFobERSmC5aOJ99DIiNi1VHRkWQ+nMyQrfwi Y2JjgqK1UbFqcqKfh6dJx9hVgbHSuTFaMq2ODCGSwZFBOuk27XOxgdqIGHWsJi5WOmelRh2sjYkK C4wn55KtoqK1RhV0MdqIUPPpQ9TRmtDA6OAwTYxxX8kq5vupZbcOjIoKizeujTRKtZ+vjY3RhIUM 89WGr9TFqH0iIyLVs9RzNaG6sMDo9z6avfT/8xtFUbNmucdHBPlMSYgMXuw7NUqzZLbHmhC/adGh czxjVs31itXOm66b7712tf+6sMAFM+PCVy6cNGrgaJcxSz9Sjx2yfNzQPgHjh01wHT5xRN36j0dS 1FCqD7WEmk15UMOovtRSyo+aRk2gPqT6UXMoT8qVGk71p+ZSXtQIagA1j5pOjaScqfmUNzWKGkj5 UzOo0ZQLtYAaQw2iFlKzqI+oRZQPNYUaSw2hFlO+1FRqHMVT3amOFEd1ouyoiZQ9ZUE5UB9QkyhH ypaypCZTPajOlBPVk+pK9aK6Uauo5ZSKYikfgnHKiihx3mKMxbkOozvss3S2XGW5y8rJKs/qF0Ws 4g09ky6knyndlZcYV6ayI9sxpZN1p2PWg6wf2Sy2afwg4oNrto62NzrP73y0i3WX+V12dR3ataDr z90GdzvEWrGoe6/up7nRXCnXZKezO2tvZx9of8uBcsh2yHW45vBPx56ORY4HHZ/16NFjS4+zPf7L aazTNqeWnqN7+vWM6lnfy1FsthWbkSDqBAvoLMDngiWsE2u4f9DVhuLKitTieB4n0fGp6RuSDOnV /D9adYPNI3EhLKer0w0bktJT41V4NP5cadwMnAU4JliIbuDHncfOisnmJTDcvHEIjReLNQq8QjZt Q2OvVp0iTPZpsHnFRPocOCugQODwRhooOKb4jCYnYl9hJfiKNkI31g0a7NjNHri/ArOyPZLMe8yg wSBWKyplF+xgljxH4zH4CR4HTxRnZBJKs0QVbbpjkxAldCt/tVKA7YI9exNcxTGcm1mMvVaPmwLo ONO4hgd783YBUETvEUrLPitj2L1bd+4qPeB0ENXot63bvrYiGoUzGGmVZt0tzAu1UEx/63VppIr1 80GhcXNmMkSXREG0ELS13YhO/ySafCt+KtpwK/f51/giBvcYPAQ74O4/fQj216/XNpzmd9Z8Vo3K mdJUQ0p6VnZammrhUp+YKUTSYtK936DD/XvQ4cntwAUFfF5CUXoFYiqKDdX8cyU7rsbk5zhVO16u CKItgctD+JiDEfBGUdKqc5fZ3EWmt6jbbh4503gYbsEjoEUx0Cy/vVWnfX91qVE+jncXdSU0jMJv FCbLJwqgESweSRjLJed3ETh/2cJL9PO7N5/cWHFibB1/ac/n+9Fp5rH714NUuEzuZQFrONDAOGXj +YA5Pr6ffMRjZ7ydg0RwUV5B9el74vbrtqxCoYzPvMUeqncetzAIsE+wFCOIr/FrEgnFqZWSgVRf QoESn8MvFKFip2Zle0jMw3VKOA8vFO/cZEEs14nofFacymF2gDPujLu2DAQWur36GWyBdf4Zd+dX Wv322LXPwLET+vUd9+hVy/ePfuWN66MFeCWAgyB5+i1BvK09e1LMEVu4IbKb4WR6ye05e92IR60H Sft3bh4A1jwbfQ9dbjh+ixn5UtnuCHa9P42j4BXX8sC1L8/udXad4OI8kRz58NHPZjdDAlH4HhRz 4AGbFdvoqrKSivKUkgQpbtrhfYjGLngdHgLrFAdkcWNp1mwbDV54swJr+8iwXWCW7UO3n0hce5NY OdtOrKk3a4tdzMfdbQ2i8UUxV9FbdvX3ATSI3lTattJNDKLhYmtumxuYWugkfCoFDPGFPdssRosF 3LKjs7d5o+nIb03A0hXLI6chX2acEjsBMSD0vHpl+7GTqs+3lW9CpUxZWsnG9MzstHSV/8xFazyJ oTs5vwYb/rYSrH9sBstn3y3wLVDlJhanlSOmUgofsFKyPdtBYUpY8KEAD6QUgsCW5BCRKPIC+hFc yZzJPjvXWu1Psy/Mt/I3G4x97kLsd8z7fPi3iIHOL/8uubkHWA99jrtMXhzluUDFLgHPL7mWb90H DXN1cxk48d7Lnx7e+9kEJpgiwCCSozfBUg4dy6pJ2hv6vevpweQ23Z2H4Q+w3e/9wOk52BxvKCOp IiMzOyOdD1o9ReeDMIVcbyb9xghW1X+/c7EZNaO7flXDmXbvVQtwnHhPbwczpEhIStJLxaE3vlGg hEfiCsVF/AqPUsaZQqdGBZ1gS5YSP2pdofBTmhxUbIyT0cY4aeQwARq2x+PxeCB/Aw+9wArsYQxM whTY4d4kXoD5O6ZxP9xrCFZiBaaHghLUoH5B/lLysnwFTwXLXwVODpMoGrgWsmEf/rwSeg8AK8yp cJRZoJ4WWnWcqIO+ynNo//qGVYdWbp+NFjBTlL1HuQz+N2e2R+ZDMRCauGXX59dNIjbtMmQ4tsbW Lz+Ezjzb+ACdrzt2ncEFLkq5Z9nbZt82kmE/sfqcku3T/nEIzS7DXlEkWo0OHej88b2XLx/c/YV/ l55gAInWrsRs20gFgDmyOJxzhT51tOH6loNZWTtUJ/QI5SGm3FBSXqov3pjPry7yLNYgZsTMBVN4 31FmnZpwk4vMVLfMEYU926rgXAHy23KxJYyHRI7UOaCf3X3xYtyd3jxOfy88/d+vyO/yO1bRkGgF +ST1Prw2z8tz6tzR/LtM/6T2N6Eb2b6/8LuwjsTIf5NDSJruH2DOvWBvTrgBuD/J6seIXYtTKyqN s3yru/IvlGDfigtgtIzBWOMbynfGDBO6EUIkVfZcKdszdEJK2sYNpWmb+Hu4abB5BDeJWUrKK4wZ 0QvW0OzwFujQsPWo0xZUm7wttjg9L6dYsrah3KAvSajk12zRGSLQIrQkcthY5t/x8+wdfmbBUy7g xoI6qTgrhg3FDGZeDAEFwcYddG73UYIfTunlP99LRXQz25WmT6H9mxr21+2p2I0EhoBo4L+DaGIU 97KRgMjNbdgwN5IV7t77SbI4VgrrBfE7SQ0SffZsHFwkDlUVvIHuCMYxMB53AHsSju8CsvcT3AXo aNWIGekZmXqU7rjRkFqWn5+bW6A6XH6jrA5tR1VZO1IYtiJlV1lWldMXX+2uLU81JGdm5mRl8mHr EtLXog0oLS/GwLBxZeGxBRFOa1FidrieOSk2cf97ULfhw8KID+huRGA7ONrcbwRH0gYzOG68D44F fwWOf0GoqQLXirSJaq07ClXC2qP27A7RQ+S4VbsDPpuLGJcpS2eEVYfvjOd3JuxMv5v2pX5H+udJ DFu3Y/2m6NgeC7yDR33kuf+YqlhZkWbYaMTcOCXr3Q7lMiVbF/LFqYRrTqD4/vz9hrj6sM386s0h Zb7Fowz6PF0lw+5YW568qarH4fN77t4/ExFQqMpLLE4vb+NpN5WsncTTNqQlJ7SRFiNjkCy0XTLP v5CF1prlplFpOgGyg/nCAVBCl1Wcu7pz03nkeAhtSd8at31dxRojNw2QJS17usbQviSffuR9aZhv YKzvorbDQwRCHqTDjxp9U8CRM+6vOuLfhD9iLpjTUxg9AXpH7p91+MWeYyfQNebJuDuEr+X+Ze6Y ZF7qRkOBFSTAUOWdG/6zZ7oudGkrb7MEGFgLHdvqvDVB8++k1mm4SrPGeIFsTx4PouetWZW2kERb v1HfQ0++UYku7bx6RDiw/yixwjN0Z2XBotyEojQZKbat0ZckGd2YpGTv7QuYX+3t5I3mxAYELl4a 5o48GHclHvmmP4z76np1/SWVSbNfBehWa/GKWMSXJBawVrZvgq3dlWaKg7fQbleW/vQ3oA/sKk0t TcnIyslIUwXHeiTMQ4znir2neaiFKDM/epe4Xv/aDVwvBRsJRaOUukbJrtkJN+HRsvEfMpCPptmW bPE7zq/vpXa4l5sMGH8EDgq6IxLc54iVXKAQUO2HmD4Tp48KrAneG8vX6fZtvLXx9sbN+m2JBO47 EzatXtXDfZr/sOHup69nqXKq9CUbECNdksdWJsSbInAXQfwy4VL0TSew+eFW8+nYw8Hb+PCayJJJ FT6l0SVrNhHER29K2rm7x/UrJx8/uBIw20St3jnhNUG8nFm1tweNAmwlLMSbJASc6C+DbG9zFVv+ XluCbeQ0WoO3gubcn8+SVqWtsyuVdlSbpfwhkX7H1ZuMhWuHsPKVPRsszrS7J6NucVrRhjSVMmdX 0uzR2fN9w6c7LQo6dIqHL4fIEhOZnXh24Xcq1uM6urLzy3MmsgV/1P4iMSVwFWACgdNdQeIpE6Yo Ew3J5ZVFJYRb0a3LMG3Od43g2qr7C/5t5vvSXo1iDQe8LFbuyGOlVYd52fiODER8e3tsAc/sYIJo oxBkVpRln29o0nI1KeJoPAiaFNdkZ8meGAQaJrbaKGQMx0SYJXD7wHTu2EGYjj0VkbQ8J5kbbRoH wQrSnNorjsuUsDNLbyGYx+7YWSFaywzOviCpkTCwFtmXlybHinojkZT6k0xio3rjtpVpRXHG/iRN n2QUv4t/pEdMmzZqpOetH1Xw4933upj41DapeiKF6R9GgwKsnj4F2gjgWtILWIg+dt8Ty9X8eSt1 ivbEjSOhRLGIHoNLpkKj4uyfC9bQT4jxTtPPoPw5LjdZUawhnpltdHELh0fKDNexteY/5IZ3sPZ4 14JeMhGVaHGs3Uta3lNCLX3b68ywkBkb4uarkjP16SiFSTakluYVSMzgwbadRfsQ03jq0yW8h9Kv KqxwOUm5Xcf4jebZ1MlfL3xx6/LnF66o2L1HrabP8o/xILkuoP7M13cOvzlyQp+6z4jTWjGHXKLW 7gINGrFGsdvkhNSieCmLx6W1XeABjf1bdYosGvuKOsW3MqHBZh/slredUpFawz1qfBl2ZHYj/sTx qfle82g3mB9yetAhiIYlDlUytHYyh/FRGu/FeQrIuydz+KT/Wx0zh81jiORgLIxQFP/5G9UJGvfC drgH2CmOyS4l83sxDWPxCDyLREaq7DxH835eNIkKF/gQuyhmyCQczBKp8ncu1BJ0CCZJPxIhtiJV RfbSw16px01amr3Z9mWT9GbVnmTZG1oCCLbhwoE92xuc6nevCubxTVlASLMHLtZtI5ho2P2phmSa 9yYb6EvLTs5Z+enaxcEq3YnVW1cghvULRBHx2qXMv7yKtDfS80kjLREddpFZx/mmiF7S/uVlE80e n3b8sraRlJ7mFugKXYY0Y1uePeyO5q1e7MGA51fcLw8m9HWZMH4Qzx4dOPFxi/QwIgOgrd3XNCjF fmDV2k9xlf6KQPEzmcsGyd5N6bmtUdhC7KnwobFVa895YpTihQxDsjbL+KIpbod6rnUMrM/Iz8jL Qo56pM/M0mdnOWRn5WShLJReoDdkAODFDpj8Ss3IzCDsG2XmZuVl5WY55OuLM4tQPirIK8yXjERI /QnSzbwQ4ohx/iZ2gkdcXm5ebi66vP3AGXSBeTr5hvPCxYnhwaq1iUnxJFpTCI8vyc8rL1Xtqj9Z ex4x315aMiMwMjgwnl+bkpizGDEJKe8Me7P5sffHkybPGD5vXs2+ZXx6YWaeHjEpqakpGyo27E3g z0Qe33ASMaD86XHLN8suf7zHaMArluIM4qMUlJ6eEOWBOwTjjsgZ9dvb9xus2BpiSClFTFmpoawg Jy+7kPeELmGv0O/o992/3gTbvMLcPFTAlJFGoq3idxfgDXHHNpKTbeBjDnefLCtxg+XPp92N+bqi 0vQoqRpL47hWB8UyJVnL4fU0BMMbxTbJAa+vWMJEomBySmpyZm52XgZ/C3etc5YeP9RhfT2xbXZG TjbKlPJaWWlx8Y5NqtvQ4SB0RL+g15/+5gVWsQdSDSnIZH0gPGCiYHFWgM0kxcwVL3Oglzm/gTC9 DSWpZYWFeUXlqi+2HCk7hJgnF31G9pk+1WWO/9YjS/n0YqNVk1NTkzdWrt+zlj/16anEs8Sq1n/7 EbqBldvj/p+EpK5dZOziughve0i8gDACclSzDJGqP8JAZR4Pok3qnRLAq7aSLDkovdzANMjgcmpy PkMGdHXTVzuPnLz38Ph9VIOqs0ozSjIKcgqJb0oMZTWhVStmzIhevoB3n7VqDMIMg6d+j22hU/P9 vwH1avKT4R7+QeNXqor8uW1Hyqo/q9qz79Dm/Yi5dcF74pi53u5ei44+ieKzDChXv1WyE/nJqRUF I6M5IlE38QsOj24tzcnM0aMsR6OlCwurClUwVqxSXGvtONn8iNQAR6TGHYKgPzcN55MlWSjTMbFi Q1VFSVFNqQr6Q7XCbBvoQq65ZxxnjNCkDUacqN6GkTavfdzcZpvaQ5AllbswqYMKMz4XWsN17va+ 3YfRFebHCfcGD57gNsJ3z4pboSr29RRt8ELvHoOeTHz9+snD5uvBZ6fsVbHNbrCJu395nscM34Vu k2efuX7r8vn7PPsa77f6/uu5k929Z7tOmHH53t2rFx9L/oMyUv+zoYxr91PrAHN6kAQGEGDW46L8 aENyNXKsRoay/O31UORwxu7PvkorzoqYw544Jj0tOxPpjbYsKcwvLVaBM6FRztinOKUwqwQ5lhkM ZYVZRfpi3nR7rQQOySHHD1qKWviDy43LXY9S0cwEn8hPlrhNXDYZxaH4/JTCtMLM3AwC0LTU5Lh9 iYevXdt+7Cx/9+uGHxAwDEwdB7a406DJH2Gq//2xz2+fO/RYUOnPcTGfJMevT1wdGrQ2BDHT5l5/ +MOF63e/OR0wdgefn4pyimKN8VNrASeA4YLDI0NC6iIO8qX0wbqdB/aH7ww2alkr9vwPEilwjnyP MH/ftX9/+C7jSrE3WRf6nxAzhXQPf7HYmFMly5DWVkyEXzkYNRkobIktJ2MKj1I5k87vPqbAEizv AwUjVfiHlxy6Wv1N3bEt9fU1X6AvUH3cFm3d8movNJMZqUQz473Cl+u02rhAFIi0Nbr68GPx36Cr kgXukGIgjsHrC7MKs/ORYxEqKsgvyst3yMvPLSBpviizKLUQAyx2APLLUFhQiEocUX5Ofjb545BZ pC8g8YMyszOyTH2DBWkYpNwgcthnTmJGhh4lO6aUphjySvIIPwOHLxStFZhXmhucO7IUYuT3kPwX CJT2PyRRy7uc1JUZn13++MjYgBgfOKS1c4XXBOA18FQGcD/Zfyr64X5/PmMiantJJXslhEiVDDoL XL7ywomvLz39AbrAB7W70CXm+ZhHLr7zIpeGqOJiNoSjeCaVUM+yoqLKAlXV5a+OfoOY+zd8PQPi Iod+yLu5u7pNmMLMVrI3RdW35ofAUKXtulpxTC1p1Gtr6cOdBOvDNjaCzQcU9T9or+svCmVuZHN0 cmVhbQplbmRvYmoKNzEgMCBvYmoKNTgzNAplbmRvYmoKMzUgMCBvYmoKPDwvU3VidHlwZS9UeXBl MS9CYXNlRm9udC9QV1VEVkorSGVsdmV0aWNhL1R5cGUvRm9udC9OYW1lL1IzNS9Gb250RGVzY3Jp cHRvciAzNCAwIFIvRmlyc3RDaGFyIDEvTGFzdENoYXIgMjU1L1dpZHRoc1sgMzMzIDMzMyAzMzMg Mjc4IDUwMCA1MDAgMTY3IDMzMyA1NTYgMjIyIDU4NCAzMzMgMzMzIDYxMSA1MDAKMjc4IDI3OCAy NzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4CjI3 OCAyNzggMzU1IDU1NiA1NTYgODg5IDY2NyAxOTEgMzMzIDMzMyAzODkgNTg0IDI3OCAzMzMgMjc4 IDI3OAo1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCA1ODQg NTg0IDU4NCA1NTYKMTAxNSA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1MDAg NjY3IDU1NiA4MzMgNzIyIDc3OAo2NjcgNzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2 NjcgNjExIDI3OCAyNzggMjc4IDQ2OSA1NTYKMzMzIDU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1 NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgzMyA1NTYgNTU2CjU1NiA1NTYgMzMzIDUwMCAyNzggNTU2 IDUwMCA3MjIgNTAwIDUwMCA1MDAgMzM0IDI2MCAzMzQgNTg0IDI3OAo1NTYgMjc4IDIyMiA1NTYg MzMzIDEwMDAgNTU2IDU1NiAzMzMgMTAwMCA2NjcgMzMzIDEwMDAgMjc4IDI3OCAyNzgKMjc4IDIy MiAyMjEgMzMzIDMzMyAzNTAgNTU2IDEwMDAgMzMzIDEwMDAgNTAwIDMzMyA5NDQgMjc4IDI3OCA2 NjcKMjc4IDMzMyA1NTYgNTU2IDU1NiA1NTYgMjYwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDI3 OCA3MzcgMzMzCjYwNiA1ODQgMzUxIDM1MSAzMzMgNTU2IDUzNyAyNzggMzMzIDM1MSAzNjUgNTU2 IDg2OSA4NjkgODY5IDYxMQo2NjcgNjY3IDY2NyA2NjcgNjY3IDY2NyAxMDAwIDcyMiA2NjcgNjY3 IDY2NyA2NjcgMjc4IDI3OCAyNzggMjc4CjcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQg Nzc4IDcyMiA3MjIgNzIyIDcyMiA2NjYgNjY2IDYxMQo1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA4 ODkgNTAwIDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDI3OCAyNzgKNTU2IDU1NiA1NTYgNTU2IDU1 NiA1NTYgNTU2IDU4NCA2MTEgNTU2IDU1NiA1NTYgNTU2IDUwMCA1NTUgNTAwXQo+PgplbmRvYmoK MTUgMCBvYmoKPDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9QWFZEVkorVGltZXMtUm9tYW4vVHlw ZS9Gb250L05hbWUvUjE1L0ZvbnREZXNjcmlwdG9yIDE0IDAgUi9GaXJzdENoYXIgMS9MYXN0Q2hh ciAyNTUvV2lkdGhzWyAzMzMgMzMzIDMzMyAyNzggNTU2IDU1NiAxNjcgMzMzIDYxMSAyNzggNTY0 IDMzMyAzMzMgNjExIDQ0NAoyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAg MjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAKMjUwIDMzMyA0MDggNTAwIDUwMCA4MzMgNzc4IDE4MCAz MzMgMzMzIDUwMCA1NjQgMjUwIDMzMyAyNTAgMjc4CjUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCAyNzggMjc4IDU2NCA1NjQgNTY0IDQ0NAo5MjEgNzIyIDY2NyA2NjcgNzIy IDYxMSA1NTYgNzIyIDcyMiAzMzMgMzg5IDcyMiA2MTEgODg5IDcyMiA3MjIKNTU2IDcyMiA2Njcg NTU2IDYxMSA3MjIgNzIyIDk0NCA3MjIgNzIyIDYxMSAzMzMgMjc4IDMzMyA0NjkgNTAwCjMzMyA0 NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzggNTAwIDI3OCA3NzggNTAwIDUw MAo1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDQ4MCAyMDAgNDgw IDU0MSAyNTAKNTAwIDI1MCAzMzMgNTAwIDQ0NCAxMDAwIDUwMCA1MDAgMzMzIDEwMDAgNTU2IDMz MyA4ODkgMjUwIDI1MCAyNTAKMjUwIDMzMyAzMzMgNDQ0IDQ0NCAzNTAgNTAwIDEwMDAgMzMzIDk4 MCAzODkgMzMzIDcyMiAyNTAgMjUwIDcyMgoyNTAgMzMzIDUwMCA1MDAgNTAwIDUwMCAyMDAgNTAw IDMzMyA3NjAgMjc2IDUwMCA1NjQgMjUwIDc2MCAzMzMKNDAwIDU2NCAzMDAgMzAwIDMzMyA1MDAg NDUzIDI1MCAzMzMgMzAwIDMxMCA1MDAgNzUwIDc1MCA3NTAgNDQ0CjcyMiA3MjIgNzIyIDcyMiA3 MjIgNzIyIDg4OSA2NjcgNjExIDYxMSA2MTEgNjExIDMzMyAzMzMgMzMzIDMzMwo3MjIgNzIyIDcy MiA3MjIgNzIyIDcyMiA3MjIgNTY0IDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDU1NiA1MDAKNDQ0 IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgNjY3IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgMjc4IDI3OCAyNzgg Mjc4CjUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1NjQgNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgNTAwIDUwMF0KPj4KZW5kb2JqCjE4IDAgb2JqCjw8L1N1YnR5cGUvVHJ1ZVR5cGUvQmFzZUZv bnQvWFBUQ1ZKK1RUMTVDdDAwL1R5cGUvRm9udC9OYW1lL1IxOC9Gb250RGVzY3JpcHRvciAxNyAw IFIvRmlyc3RDaGFyIDEvTGFzdENoYXIgMS9XaWR0aHNbIDIyNl0KPj4KZW5kb2JqCjIxIDAgb2Jq Cjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvWVhDRFZKK0NvdXJpZXItQm9sZE9ibGlxdWUvVHlw ZS9Gb250L05hbWUvUjIxL0ZvbnREZXNjcmlwdG9yIDIwIDAgUi9GaXJzdENoYXIgMS9MYXN0Q2hh ciAyNTUvV2lkdGhzWyA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMF0KPj4KZW5kb2JqCjI5IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvQ1ZR RFZKK0NvdXJpZXItQm9sZC9UeXBlL0ZvbnQvTmFtZS9SMjkvRm9udERlc2NyaXB0b3IgMjggMCBS L0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDI1NS9XaWR0aHNbIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAK NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwXQo+PgplbmRvYmoKMTIgMCBvYmoKPDwvU3VidHlw ZS9UeXBlMS9CYXNlRm9udC9VTktEVkorQ291cmllci9UeXBlL0ZvbnQvTmFtZS9SMTIvRm9udERl c2NyaXB0b3IgMTEgMCBSL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDI1NS9XaWR0aHNbIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwXQovRW5jb2RpbmcgNzIg MCBSPj4KZW5kb2JqCjcyIDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNbCjM5L3F1 b3Rlc2luZ2xlXT4+CmVuZG9iagozMiAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L09U R0VWSitTeW1ib2wvVHlwZS9Gb250L05hbWUvUjMyL0ZvbnREZXNjcmlwdG9yIDMxIDAgUi9GaXJz dENoYXIgMzIvTGFzdENoYXIgMjU0L1dpZHRoc1sKMjUwIDMzMyA3MTMgNTAwIDU0OSA4MzMgNzc4 IDQzOSAzMzMgMzMzIDUwMCA1NDkgMjUwIDU0OSAyNTAgMjc4CjUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDU0OSA1NDkgNTQ5IDQ0NAo1NDkgNzIyIDY2NyA3 MjIgNjEyIDYxMSA3NjMgNjAzIDcyMiAzMzMgNjMxIDcyMiA2ODYgODg5IDcyMiA3MjIKNzY4IDc0 MSA1NTYgNTkyIDYxMSA2OTAgNDM5IDc2OCA2NDUgNzk1IDYxMSAzMzMgODYzIDMzMyA2NTggNTAw CjUwMCA2MzEgNTQ5IDU0OSA0OTQgNDM5IDUyMSA0MTEgNjAzIDMyOSA2MDMgNTQ5IDU0OSA1NzYg NTIxIDU0OQo1NDkgNTIxIDU0OSA2MDMgNDM5IDU3NiA3MTMgNjg2IDQ5MyA2ODYgNDk0IDQ4MCAy MDAgNDgwIDU0OSAyNTAKMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1 MCAyNTAgMjUwIDI1MCAyNTAgMjUwCjI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUw IDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MAo3NjIgNjIwIDI0NyA1NDkgMTY3IDcxMyA1MDAg NzUzIDc1MyA3NTMgNzUzIDEwNDIgOTg3IDYwMyA5ODcgNjAzCjQwMCA1NDkgNDExIDU0OSA1NDkg NzEzIDQ5NCA0NjAgNTQ5IDU0OSA1NDkgNTQ5IDEwMDAgNjAzIDEwMDAgNjU4CjgyMyA2ODYgNzk1 IDk4NyA3NjggNzY4IDgyMyA3NjggNzY4IDcxMyA3MTMgNzEzIDcxMyA3MTMgNzEzIDcxMwo3Njgg NzEzIDc5MCA3OTAgODkwIDgyMyA1NDkgMjUwIDcxMyA2MDMgNjAzIDEwNDIgOTg3IDYwMyA5ODcg NjAzCjQ5NCAzMjkgNzkwIDc5MCA3ODYgNzEzIDM4NCAzODQgMzg0IDM4NCAzODQgMzg0IDQ5NCA0 OTQgNDk0IDQ5NAoyNTAgMzI5IDI3NCA2ODYgNjg2IDY4NiAzODQgMzg0IDM4NCAzODQgMzg0IDM4 NCA0OTQgNDk0IDQ5NF0KPj4KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoR05VIEdob3N0c2Ny aXB0IDcuMDYpCi9UaXRsZShNaWNyb3NvZnQgV29yZCAtIGZ0cF9jaGVhdF9zaGVldC5kb2MpCi9D cmVhdG9yKFBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yKQovQ3JlYXRpb25EYXRlKDEwLzUvMjAw OSAxMzo1OjUwKQovQXV0aG9yKHJvYm1jbSk+PmVuZG9iagp4cmVmCjAgNzMKMDAwMDAwMDAwMCA2 NTUzNSBmIAowMDAwMDEzNzk3IDAwMDAwIG4gCjAwMDAwNTI3NTAgMDAwMDAgbiAKMDAwMDAxMzY3 MyAwMDAwMCBuIAowMDAwMDE0MTc2IDAwMDAwIG4gCjAwMDAwMTQwMjggMDAwMDAgbiAKMDAwMDAx Mzg0NSAwMDAwMCBuIAowMDAwMDEyMzYxIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAw MDAwMjA1NCAwMDAwMCBuIAowMDAwMDM5NzQ5IDAwMDAwIG4gCjAwMDAwMzkyMDEgMDAwMDAgbiAK MDAwMDA1MDQ4NCAwMDAwMCBuIAowMDAwMDMzODMyIDAwMDAwIG4gCjAwMDAwMzM1MzcgMDAwMDAg biAKMDAwMDA0Njg1NCAwMDAwMCBuIAowMDAwMDE1MDExIDAwMDAwIG4gCjAwMDAwMTQ4MTAgMDAw MDAgbiAKMDAwMDA0ODAxNiAwMDAwMCBuIAowMDAwMDI4OTIzIDAwMDAwIG4gCjAwMDAwMjg1OTYg MDAwMDAgbiAKMDAwMDA0ODE1NyAwMDAwMCBuIAowMDAwMDEzOTMzIDAwMDAwIG4gCjAwMDAwMTM5 NjMgMDAwMDAgbiAKMDAwMDAxMjUyMSAwMDAwMCBuIAowMDAwMDAyMDc0IDAwMDAwIG4gCjAwMDAw MDMyNTEgMDAwMDAgbiAKMDAwMDAzNTU3OSAwMDAwMCBuIAowMDAwMDM1MjU0IDAwMDAwIG4gCjAw MDAwNDkzMjQgMDAwMDAgbiAKMDAwMDAzMjk5NyAwMDAwMCBuIAowMDAwMDMyNzcyIDAwMDAwIG4g CjAwMDAwNTE3MTkgMDAwMDAgbiAKMDAwMDAyODA1NyAwMDAwMCBuIAowMDAwMDI3ODE5IDAwMDAw IG4gCjAwMDAwNDU2OTAgMDAwMDAgbiAKMDAwMDAxNDMyMyAwMDAwMCBuIAowMDAwMDEyNjY1IDAw MDAwIG4gCjAwMDAwMDMyNzIgMDAwMDAgbiAKMDAwMDAwNDE1NSAwMDAwMCBuIAowMDAwMDE0Mzk5 IDAwMDAwIG4gCjAwMDAwMTI4MDkgMDAwMDAgbiAKMDAwMDAwNDE3NSAwMDAwMCBuIAowMDAwMDA1 NDU5IDAwMDAwIG4gCjAwMDAwMTQ0NjQgMDAwMDAgbiAKMDAwMDAxMjk1MyAwMDAwMCBuIAowMDAw MDA1NDgwIDAwMDAwIG4gCjAwMDAwMDc3MTcgMDAwMDAgbiAKMDAwMDAxNDUxOCAwMDAwMCBuIAow MDAwMDEzMDk3IDAwMDAwIG4gCjAwMDAwMDc3MzggMDAwMDAgbiAKMDAwMDAwOTQzNiAwMDAwMCBu IAowMDAwMDE0NTYxIDAwMDAwIG4gCjAwMDAwMTMyNDEgMDAwMDAgbiAKMDAwMDAwOTQ1NyAwMDAw MCBuIAowMDAwMDEwNDY3IDAwMDAwIG4gCjAwMDAwMTQ2MDQgMDAwMDAgbiAKMDAwMDAxMzM4NSAw MDAwMCBuIAowMDAwMDEwNDg3IDAwMDAwIG4gCjAwMDAwMTE0NzUgMDAwMDAgbiAKMDAwMDAxNDY4 MCAwMDAwMCBuIAowMDAwMDEzNTI5IDAwMDAwIG4gCjAwMDAwMTE0OTUgMDAwMDAgbiAKMDAwMDAx MjM0MSAwMDAwMCBuIAowMDAwMDE0NzQ1IDAwMDAwIG4gCjAwMDAwMjc3OTcgMDAwMDAgbiAKMDAw MDAyODU3NiAwMDAwMCBuIAowMDAwMDMyNzUxIDAwMDAwIG4gCjAwMDAwMzM1MTcgMDAwMDAgbiAK MDAwMDAzNTIzMyAwMDAwMCBuIAowMDAwMDM5MTgwIDAwMDAwIG4gCjAwMDAwNDU2NjkgMDAwMDAg biAKMDAwMDA1MTY1NSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDczIC9Sb290IDEgMCBSIC9J bmZvIDIgMCBSCj4+CnN0YXJ0eHJlZgo1MjkzMQolJUVPRgo= --_002_A5FC996C3C37DC4DA5076F1046B5674C082F5114TK5EX14MBXC127r_-- From salvatore.loreto@ericsson.com Tue Oct 6 02:39:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD7A28C11A; Tue, 6 Oct 2009 02:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.823 X-Spam-Level: X-Spam-Status: No, score=-5.823 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 1jwUMqiax+cd; Tue, 6 Oct 2009 02:39:14 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B5EF828C12E; Tue, 6 Oct 2009 02:39:00 -0700 (PDT) X-AuditID: c1b4fb3e-b7b81ae0000009d4-3e-4acb109334ea Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 16.A3.02516.3901BCA4; Tue, 6 Oct 2009 11:40:36 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 11:40:15 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 11:40:15 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0BA6224C0; Tue, 6 Oct 2009 12:40:15 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CA2E621A1F; Tue, 6 Oct 2009 12:40:14 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 705DA219D4; Tue, 6 Oct 2009 12:40:14 +0300 (EEST) Message-ID: <4ACB107E.6030209@ericsson.com> Date: Tue, 06 Oct 2009 12:40:14 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: "hybi@ietf.org" , apps-discuss@ietf.org, whatwg@lists.whatwg.org, whatwg@whatwg.org Subject: HyBi BoF: on Tuesday, November 10 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 06 Oct 2009 09:40:15.0189 (UTC) FILETIME=[01F60050:01CA4669] X-Brightmail-Tracker: AAAAAA== X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 09:39:16 -0000 Hi there, accordingly to the provisional IETF 76 agenda in Hiroshima (https://datatracker.ietf.org/meeting/76/agenda.html) the HyBi BoF will be on TUESDAY, November 10, 2009 at 1300-1500 during the Afternoon Session I We are now working on a clean version of the Charter Proposal that will be posted during the next days and on the Agenda so all the proposal and comments are welcome! cheers Salvatore Loreto www.sloreto.com * * From fernando.gont.netbook.win@gmail.com Mon Oct 5 15:07:59 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3C83A682A; Mon, 5 Oct 2009 15:07:59 -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 8SlSDgf2KhGC; Mon, 5 Oct 2009 15:07:58 -0700 (PDT) Received: from mail-yx0-f124.google.com (mail-yx0-f124.google.com [209.85.210.124]) by core3.amsl.com (Postfix) with ESMTP id 056FC3A67AB; Mon, 5 Oct 2009 15:07:57 -0700 (PDT) Received: by yxe30 with SMTP id 30so124344yxe.29 for ; Mon, 05 Oct 2009 15:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=hrN+KSW4VExT/2OcKH249+DeTPIOSExpSr2oP1VhlMc=; b=trHzbeUeq7wqxMIlFnGWH5EDmnU8FHEfiSUCw78n8QQq8L78FPkXqo+qyC/yiNlV/3 nY4OAJOmmyMD88WVE2WNpABvLaO2BUBIo1rq18kO4vyI+2G6Zg1g4SCT6W4VmSxZavFR bbNKONat3UboMhP1elq5o17U9bpO0DX2md7kU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=nJfUxUns6mVqsHvgapWALpR7fc/7xVz/6lCWvDAD6cDlTBX/2SwobUxEtTmGh3YPwZ 5203dawA2WxOc9vonG8l4ZOEKPEbI0GgL2YUfrzaTDrzz/G08q1vJ8umVwHvZsUytwEX tmpJjeZgfAghUpg/CiVI6fCrpXVlK+CW91LZ0= Received: by 10.150.210.8 with SMTP id i8mr972093ybg.41.1254780571275; Mon, 05 Oct 2009 15:09:31 -0700 (PDT) Received: from ?192.168.1.12? ([201.255.220.163]) by mx.google.com with ESMTPS id 20sm243133ywh.6.2009.10.05.15.09.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Oct 2009 15:09:29 -0700 (PDT) Sender: Fernando Gont Message-ID: <4ACA69C5.1060802@gont.com.ar> Date: Mon, 05 Oct 2009 18:48:53 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> In-Reply-To: <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 06 Oct 2009 08:02:31 -0700 Cc: Stuart Cheshire , "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 22:07:59 -0000 Iljitsch van Beijnum wrote: > First of all, server apps may use unallocated ports, too. If by "unallocated" you mean a port nor formally allocated by IANA, I agree. To some extent, the usefulness of allocation is in documenting its use, and in avoiding collisions. > Second, how are TCP stacks supposed to know that a port has been allocated? Not sure what you mean. Many implementations avoid using as ephemeral ports those port numbers that are used for specific services. I wrote the patch to expand the ephemeral port number range in FreeBSD, and the reason for which FreeBSD's ephemeral port range ended up being 10000-65535 (rather than 1024-65535) was to avoid using those port numbers used for X, http-proxy, etc. (This was a quick hack... a more clean approach is described in draft-ietf-tsvwg-port-randomization). -- OpenBSD does implement that approach. > As far as I know, there are no issues with the normal practice of not > caring about this. Normal practice does care about this... that's probably why there are no issues ;-) Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From cfinss@dial.pipex.com Tue Oct 6 10:43:05 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B4128C195 for ; Tue, 6 Oct 2009 10:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=-1.432, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069] 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 GVOnZm855851 for ; Tue, 6 Oct 2009 10:43:04 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 0EFDC3A67F4 for ; Tue, 6 Oct 2009 10:43:03 -0700 (PDT) X-Trace: 255102233/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.179/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.179 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAPsey0o+vGSz/2dsb2JhbABDgmGNVcMYCoIngXkEgVM X-IronPort-AV: E=Sophos;i="4.44,513,1249254000"; d="scan'208";a="255102233" X-IP-Direction: IN Received: from 1cust179.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.179]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Oct 2009 18:44:32 +0100 Message-ID: <001a01ca46a3$ff8377e0$0601a8c0@allison> From: "tom.petch" To: "Peter Saint-Andre" , References: <4AC6786E.2020101@stpeter.im> Subject: * was Re: Server Identity Verification in Application Protocols Date: Tue, 6 Oct 2009 12:05:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:43:05 -0000 This specification disallows the use of * to wildcard the reference identity. syslog over TLS not only uses this, but also allows the use of a wildcard where it would not be allowed in the subjectAltName. I would see this as quite common in networking scenarios, where the access is many to many, and so would like a less severe prescription against it. Tom Petch ----- Original Message ----- From: "Peter Saint-Andre" To: Sent: Saturday, October 03, 2009 12:02 AM Subject: Server Identity Verification in Application Protocols > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A new version of draft-saintandre-tls-server-id-check is available: > > http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt > > Other than the informational appendix, the diff from the -01 version is > relatively minor. Feedback is welcome. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrGeG4ACgkQNL8k5A2w/vzsrQCgzyFjxSkoQBp3PVqUmC4/p741 > 0HgAniMwjH+eUXwpokRKU8ZXcIJlEDLu > =7pso > -----END PGP SIGNATURE----- > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From cfinss@dial.pipex.com Tue Oct 6 10:43:06 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D103A67F4 for ; Tue, 6 Oct 2009 10:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=-1.414, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069] 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 MOKpmN3kB7e6 for ; Tue, 6 Oct 2009 10:43:05 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 2FF2828C12A for ; Tue, 6 Oct 2009 10:43:05 -0700 (PDT) X-Trace: 255102250/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.179/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.179 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAPsey0o+vGSz/2dsb2JhbABDgmGNVcMYCoIngXkEgVM X-IronPort-AV: E=Sophos;i="4.44,513,1249254000"; d="scan'208";a="255102250" X-IP-Direction: IN Received: from 1cust179.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.179]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Oct 2009 18:44:40 +0100 Message-ID: <001b01ca46a4$017b0220$0601a8c0@allison> From: "tom.petch" To: "Peter Saint-Andre" , References: <4AC6786E.2020101@stpeter.im> Subject: client was Re: Server Identity Verification in Application Protocols Date: Tue, 6 Oct 2009 12:09:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:43:06 -0000 This I-D is very hot on the fact that it is about Server Identity, yet technically, I see no reason why the logic does not also apply equally to client identity. In networking, with the networking box as server, and the client being the one that wants to change the configuration, then client identity is the one that matters, not server. I would like to add an initial paragraph to the effect that although the memo is written in terms of Server Identity, there is no technical reason why the processes described cannot be applied to verifying the Client Identity. Tom Petch ----- Original Message ----- From: "Peter Saint-Andre" To: Sent: Saturday, October 03, 2009 12:02 AM Subject: Server Identity Verification in Application Protocols > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A new version of draft-saintandre-tls-server-id-check is available: > > http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt > > Other than the informational appendix, the diff from the -01 version is > relatively minor. Feedback is welcome. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrGeG4ACgkQNL8k5A2w/vzsrQCgzyFjxSkoQBp3PVqUmC4/p741 > 0HgAniMwjH+eUXwpokRKU8ZXcIJlEDLu > =7pso > -----END PGP SIGNATURE----- > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From Martin.Thomson@andrew.com Tue Oct 6 15:13:06 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397E128C1DC for ; Tue, 6 Oct 2009 15:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, J_CHICKENPOX_35=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 lXWSL4JCD7+I for ; Tue, 6 Oct 2009 15:13:05 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3863C28C10F for ; Tue, 6 Oct 2009 15:13:04 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_10_06_17_38_35 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 06 Oct 2009 17:38:35 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 17:14:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: * was Re: Server Identity Verification in Application Protocols Date: Tue, 6 Oct 2009 17:15:02 -0500 Message-ID: In-Reply-To: <001a01ca46a3$ff8377e0$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: * was Re: Server Identity Verification in Application Protocols thread-index: AcpGrLNr20xqAZw4RbugEOywdgrR3QAI+NEw References: <4AC6786E.2020101@stpeter.im> <001a01ca46a3$ff8377e0$0601a8c0@allison> From: "Thomson, Martin" To: "tom.petch" , "Peter Saint-Andre" , X-OriginalArrivalTime: 06 Oct 2009 22:14:41.0709 (UTC) FILETIME=[66E8CDD0:01CA46D2] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 22:13:06 -0000 SSBlbmNvdW50ZXJlZCB0aGlzIGlzc3VlIG15c2VsZiB0aHJvdWdoIElFU0cgcmV2aWV3IG9mIG9u ZSBvZiBteSBkb2N1bWVudHMuICBJdCBtYXkgaGF2ZSBldmVuIGJlZW4gdGhlIGRvY3VtZW50IHRo YXQgdHJpZ2dlcmVkIHRoaXMgY2hhbmdlLg0KDQpNYW55IFJGQ3MgcmVmZXJlbmNlIEhUVFAgb3Zl ciBUTFMgW1JGQzI4MThdLCB3aGljaCBhbGxvd3MgdGhlICdmKicgd2lsZGNhcmQgcGF0dGVybi4g IEluIHByYWN0aWNlIChhdCBsZWFzdCBmb3IgSFRUUCksIHRoaXMgaXMgcmFyZWx5IHNlZW4uDQoN CkFyZSB5b3UgYXdhcmUgb2YgaW5zdGFuY2VzIHdoZXJlIHRoaXMgdHlwZSBvZiB3aWxkY2FyZCBo YXMgYmVlbiB1c2VmdWwgaW4gcHJhY3RpY2UgZm9yIHN5c2xvZz8NCg0KTm90IGJlaW5nIHByaXZ5 IHRvIHRoZSBJRVNHIGRpc2N1c3Npb24sIEkgY2FuIG9ubHkgc3BlY3VsYXRlIG9uIHRoZSByZWFz b25zLCBidXQgdGhleSBtYWtlIHNlbnNlLiAgQ29uc2lkZXIgY29tbW9uIHByYWN0aWNlIHdpdGgg cmVzcGVjdCB0byBkb21haW4gbmFtZSBhbGxvY2F0aW9ucyBvbiB0aGUgd2ViLiAgVGhlIHJlZ2lz dHJ5IGFsc28gZmlsbHMgdGhlIENBIHJvbGUgYW5kIHByb3ZpZGVzIGEgY2VydGlmaWNhdGUgYWxv bmcgd2l0aCBhIGRvbWFpbiBuYW1lIGFzc2lnbm1lbnQuICBEZWxlZ2F0aW5nICdmKicgaXMgbm90 IHBvc3NpYmxlIGluIEROUzsgJyonIGlzLg0KDQotLU1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86YXBwcy1kaXNjdXNzLQ0KPiBib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgdG9tLnBl dGNoDQo+IFNlbnQ6IFR1ZXNkYXksIDYgT2N0b2JlciAyMDA5IDk6MDYgUE0NCj4gVG86IFBldGVy IFNhaW50LUFuZHJlOyBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogKiB3YXMgUmU6 IFNlcnZlciBJZGVudGl0eSBWZXJpZmljYXRpb24gaW4gQXBwbGljYXRpb24NCj4gUHJvdG9jb2xz DQo+IA0KPiBUaGlzIHNwZWNpZmljYXRpb24gZGlzYWxsb3dzIHRoZSB1c2Ugb2YgKiB0byB3aWxk Y2FyZCB0aGUgcmVmZXJlbmNlDQo+IGlkZW50aXR5Lg0KPiANCj4gc3lzbG9nIG92ZXIgVExTIG5v dCBvbmx5IHVzZXMgdGhpcywgYnV0IGFsc28gYWxsb3dzIHRoZSB1c2Ugb2YgYQ0KPiB3aWxkY2Fy ZA0KPiB3aGVyZSBpdCB3b3VsZCBub3QgYmUgYWxsb3dlZCBpbiB0aGUgc3ViamVjdEFsdE5hbWUu DQo+IA0KPiBJIHdvdWxkIHNlZSB0aGlzIGFzIHF1aXRlIGNvbW1vbiBpbiBuZXR3b3JraW5nIHNj ZW5hcmlvcywgd2hlcmUgdGhlDQo+IGFjY2Vzcw0KPiBpcyBtYW55IHRvIG1hbnksIGFuZCBzbyB3 b3VsZCBsaWtlIGEgbGVzcyBzZXZlcmUgcHJlc2NyaXB0aW9uIGFnYWluc3QNCj4gaXQuDQo+IA0K PiBUb20gUGV0Y2gNCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTog IlBldGVyIFNhaW50LUFuZHJlIiA8c3RwZXRlckBzdHBldGVyLmltPg0KPiBUbzogPGFwcHMtZGlz Y3Vzc0BpZXRmLm9yZz4NCj4gU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMDMsIDIwMDkgMTI6MDIg QU0NCj4gU3ViamVjdDogU2VydmVyIElkZW50aXR5IFZlcmlmaWNhdGlvbiBpbiBBcHBsaWNhdGlv biBQcm90b2NvbHMNCj4gDQo+IA0KPiA+IC0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0t LS0NCj4gPiBIYXNoOiBTSEExDQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LXNhaW50 YW5kcmUtdGxzLXNlcnZlci1pZC1jaGVjayBpcyBhdmFpbGFibGU6DQo+ID4NCj4gPiBodHRwOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LXNhaW50YW5kcmUtdGxzLXNlcnZlci1pZC1jaGVjay0wMi50 eHQNCj4gPg0KPiA+IE90aGVyIHRoYW4gdGhlIGluZm9ybWF0aW9uYWwgYXBwZW5kaXgsIHRoZSBk aWZmIGZyb20gdGhlIC0wMSB2ZXJzaW9uDQo+IGlzDQo+ID4gcmVsYXRpdmVseSBtaW5vci4gRmVl ZGJhY2sgaXMgd2VsY29tZS4NCj4gPg0KPiA+IFBldGVyDQo+ID4NCj4gPiAtIC0tDQo+ID4gUGV0 ZXIgU2FpbnQtQW5kcmUNCj4gPiBodHRwczovL3N0cGV0ZXIuaW0vDQo+ID4NCj4gPg0KPiA+IC0t LS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+ID4gVmVyc2lvbjogR251UEcgdjEuNC44IChE YXJ3aW4pDQo+ID4gQ29tbWVudDogVXNpbmcgR251UEcgd2l0aCBNb3ppbGxhIC0gaHR0cDovL2Vu aWdtYWlsLm1vemRldi5vcmcvDQo+ID4NCj4gPiBpRVlFQVJFQ0FBWUZBa3JHZUc0QUNna1FOTDhr NUEydy92enNyUUNnenlGanhTa29RQnAzUFZxVW1DNC9wNzQxDQo+ID4gMEhnQW5pTXdqSCtlVVh3 cG9rUktVOFpYY0lKbEVETHUNCj4gPiA9N3Bzbw0KPiA+IC0tLS0tRU5EIFBHUCBTSUdOQVRVUkUt LS0tLQ0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gQXBwcy1EaXNjdXNzIG1haWxpbmcgbGlzdA0KPiA+IEFwcHMtRGlzY3Vzc0BpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNz DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFw cHMtRGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4gQXBwcy1EaXNjdXNzQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUg ZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHBy b3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRp YXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0K dGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpbbWYyXQ0K From klensin@jck.com Tue Oct 6 16:08:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6BA28C221 for ; Tue, 6 Oct 2009 16:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 9Gh6IMUW-6SQ for ; Tue, 6 Oct 2009 16:08:25 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id CB48028C201 for ; Tue, 6 Oct 2009 16:08:24 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MvJAO-000HSd-MC; Tue, 06 Oct 2009 19:10:00 -0400 Date: Tue, 06 Oct 2009 19:09:59 -0400 From: John C Klensin To: Robert McMurray , "William F. Maton Sotomayor" Subject: RE: fodder for the proposed FTP feature/cmd registry Message-ID: <9874732F8C66211E055AB03C@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "'ah@TR-Sys.de'" , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 23:08:25 -0000 --On Monday, October 05, 2009 20:10 +0000 Robert McMurray wrote: > I'm not sure if the attached file helps, but I put it together > some months ago as a quick reference to the list of FTP > commands, their syntax, and any possible reply codes that I > could find. The introduction lists the RFCs that I used to > gather the information. >... Robert, Alfred is still unable to get mail through to Microsoft (or Hotmail, etc.) servers. He has cross-checked your list against our working version of draft-klensin-ftp-registry-02, so it definitely helps. That working version contains an integrated version of the registry table along with a significant number of other changes (some from me, some from Alfred, some from Alexey, and some from others). --On Tuesday, October 06, 2009 18:11 -0400 "William F. Maton Sotomayor" wrote: > Hi Alfred, > > This looks pretty good. If John thinks this is a good > start, I can contribute the wu-ftpd variants as well. I have > an extremely basic command snapshot already to work with if > this is a go. William, Thanks. If you don't mind, and to save duplication of effort, please hold off until -02 appears and take a look at the documentation requirements that appear there for registrations. If you don't think they are reasonable, we should discuss that. If they are, then you will have a reference point for the wu-ftpd material as well as a somewhat-revised description of the registry contents. The state of -02 at the moment is that I'm studying some new material Alfred prepared (if it wasn't clear from the above, this has turned into a joint effort) and he may be reviewing some of mine. I hope to have it posted relatively soon. However, this isn't the highest priority for either of us so please be patient. best, john From Kurt.Zeilenga@Isode.com Wed Oct 7 00:12:48 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCAC728C265 for ; Wed, 7 Oct 2009 00:12:48 -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_35=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 N2EnvVSTqmqL for ; Wed, 7 Oct 2009 00:12:47 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 896523A67E5 for ; Wed, 7 Oct 2009 00:12:47 -0700 (PDT) Received: from [192.168.123.33] ((unknown) [93.82.233.138]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 7 Oct 2009 08:14:24 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: client was Re: Server Identity Verification in Application Protocols From: Kurt Zeilenga X-Priority: 3 In-Reply-To: <001b01ca46a4$017b0220$0601a8c0@allison> Date: Wed, 7 Oct 2009 09:14:09 +0200 Message-Id: <75930B09-C7DD-46D6-A336-B1A80ADF7CDF@Isode.com> References: <4AC6786E.2020101@stpeter.im> <001b01ca46a4$017b0220$0601a8c0@allison> To: "tom.petch" X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 07:12:48 -0000 On Oct 6, 2009, at 12:09 PM, tom.petch wrote: > This I-D is very hot on the fact that it is about Server Identity, yet > technically, I see no reason why the logic does not also apply equally > to client identity. > > In networking, with the networking box as server, and the client > being the one that wants to change the configuration, then client > identity is the one that matters, not server. > > I would like to add an initial paragraph to the effect that although > the memo is written in terms of Server Identity, there is no > technical reason why the processes described cannot be applied > to verifying the Client Identity. I'm not sure this makes sense. The connection model assumed in this document is that the user (directly or via configuration) specifies the name of the server which than the client connects to, and this document then specifies how to match the user specified name (or a secure derivation of that name) to the subject of the certificate the server provides. The technical reason why this cannot be applied to verifying the client identity is that server's operator has not specified any name to match up the subject in the client's certificate. Also, the client certificate is likely to that associated with a human, not a service. So the rules would differ significantly. Now, in certain "server to server" applications, the application server which initiates the TLS connection is the TLS "client" under this model and this document would seem to naturally apply. But this document doesn't not seem to naturally apply for the application server accepting the connection, the TLS "server", to verify the identity of the TLS "client". While it certainly could apply with some additional text, that text, I think would likely be application protocol specific. In short, I rather no confuse this document by noting that an application protocol could use this specification for "client Identity" checking. Instead, I rather leave this as something particular application protocols specifications could call for if and when appropriate. I see nothing in the I-D which precludes an application protocol specification from so doing. -- Kurt > > Tom Petch > > ----- Original Message ----- > From: "Peter Saint-Andre" > To: > Sent: Saturday, October 03, 2009 12:02 AM > Subject: Server Identity Verification in Application Protocols > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> A new version of draft-saintandre-tls-server-id-check is available: >> >> http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt >> >> Other than the informational appendix, the diff from the -01 >> version is >> relatively minor. Feedback is welcome. >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkrGeG4ACgkQNL8k5A2w/vzsrQCgzyFjxSkoQBp3PVqUmC4/p741 >> 0HgAniMwjH+eUXwpokRKU8ZXcIJlEDLu >> =7pso >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 wmaton@ryouko.imsb.nrc.ca Wed Oct 7 08:02:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBF33A6ABA for ; Wed, 7 Oct 2009 08:02:45 -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 xygM7gmXtR6o for ; Wed, 7 Oct 2009 08:02:45 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2001:410:9000:127::10]) by core3.amsl.com (Postfix) with ESMTP id 3E4573A6AB3 for ; Wed, 7 Oct 2009 08:02:44 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.3) with ESMTP id n96NGemd027096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Oct 2009 19:16:45 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.3/8.14.3/Submit) with ESMTP id n96NGdd4027093; Tue, 6 Oct 2009 19:16:39 -0400 Date: Tue, 6 Oct 2009 19:16:39 -0400 (EDT) From: "William F. Maton Sotomayor" To: John C Klensin Subject: RE: fodder for the proposed FTP feature/cmd registry In-Reply-To: <9874732F8C66211E055AB03C@PST.JCK.COM> Message-ID: References: <9874732F8C66211E055AB03C@PST.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "'ah@TR-Sys.de'" , Robert McMurray , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 15:02:45 -0000 On Tue, 6 Oct 2009, John C Klensin wrote: >> This looks pretty good. If John thinks this is a good >> start, I can contribute the wu-ftpd variants as well. I have >> an extremely basic command snapshot already to work with if >> this is a go. [snip] > > If you don't mind, and to save duplication of effort, please > hold off until -02 appears and take a look at the documentation > requirements that appear there for registrations. If you don't > think they are reasonable, we should discuss that. If they are, > then you will have a reference point for the wu-ftpd material as > well as a somewhat-revised description of the registry contents. Sounds good to me! wfms From cfinss@dial.pipex.com Wed Oct 7 11:03:09 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0E73A6872 for ; Wed, 7 Oct 2009 11:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_35=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 DWYnHTvltBXY for ; Wed, 7 Oct 2009 11:03:08 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 918CA3A68A8 for ; Wed, 7 Oct 2009 11:03:08 -0700 (PDT) X-Trace: 201263049/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.6/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEALV0zEo+vGQG/2dsb2JhbABDgmInG40Uxg4KgicNgWwEilU X-IronPort-AV: E=Sophos;i="4.44,520,1249254000"; d="scan'208";a="201263049" X-IP-Direction: IN Received: from 1cust6.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.6]) by smtp.pipex.tiscali.co.uk with SMTP; 07 Oct 2009 19:04:46 +0100 Message-ID: <000401ca476f$f93013e0$0601a8c0@allison> From: "tom.petch" To: "Kurt Zeilenga" References: <4AC6786E.2020101@stpeter.im> <001b01ca46a4$017b0220$0601a8c0@allison> <75930B09-C7DD-46D6-A336-B1A80ADF7CDF@Isode.com> Subject: Re: client was Re: Server Identity Verification in Application Protocols Date: Wed, 7 Oct 2009 16:09:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 18:03:09 -0000 ---- Original Message ----- From: "Kurt Zeilenga" Sent: Wednesday, October 07, 2009 9:14 AM > On Oct 6, 2009, at 12:09 PM, tom.petch wrote: > > > This I-D is very hot on the fact that it is about Server Identity, yet > > technically, I see no reason why the logic does not also apply equally > > to client identity. > > > > In networking, with the networking box as server, and the client > > being the one that wants to change the configuration, then client > > identity is the one that matters, not server. > > > > I would like to add an initial paragraph to the effect that although > > the memo is written in terms of Server Identity, there is no > > technical reason why the processes described cannot be applied > > to verifying the Client Identity. > > I'm not sure this makes sense. The connection model assumed in this > document is that the user (directly or via configuration) specifies > the name of the server which than the client connects to, and this > document then specifies how to match the user specified name (or a > secure derivation of that name) to the subject of the certificate the > server provides. > > The technical reason why this cannot be applied to verifying the > client identity is that server's operator has not specified any name > to match up the subject in the client's certificate. Also, the > client certificate is likely to that associated with a human, not a > service. So the rules would differ significantly. I part company with you here. In the field of Operations and Management, then the (network) box is the server and is configured with the identifiers of those who may access it eg to update the configuration, so yes, the reference identity is pre-configured in the server. This may be an IP address, a host name, an e-mail address etc etc. The latest I-D includes a quote from the syslog RFC but omits the earlier statement in that RFC " Both syslog transport sender (TLS client) and syslog transport receiver (TLS server) MUST implement certificate-based authentication. " so without rules for the server to follow, this I-D would be of no use to syslog (and similar operational applications). I would (still) suggest adding to Section 1 "This memo is written in terms of a client authenticating the identity of a server. Where the server is configured with reference identities for clients, and the client certificate contains an identity of the types described in section 3.2, then this process MAY be used by a server to authenticate the identity of a client." Tom Petch > Now, in certain "server to server" applications, the application > server which initiates the TLS connection is the TLS "client" under > this model and this document would seem to naturally apply. But this > document doesn't not seem to naturally apply for the application > server accepting the connection, the TLS "server", to verify the > identity of the TLS "client". While it certainly could apply with > some additional text, that text, I think would likely be application > protocol specific. > > In short, I rather no confuse this document by noting that an > application protocol could use this specification for "client > Identity" checking. Instead, I rather leave this as something > particular application protocols specifications could call for if and > when appropriate. I see nothing in the I-D which precludes an > application protocol specification from so doing. > > -- Kurt > > > > > Tom Petch From cfinss@dial.pipex.com Wed Oct 7 11:03:10 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3755D3A6872 for ; Wed, 7 Oct 2009 11:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=-1.131, BAYES_50=0.001, J_CHICKENPOX_35=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 VHvegXz86xz0 for ; Wed, 7 Oct 2009 11:03:09 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 3773C3A68F0 for ; Wed, 7 Oct 2009 11:03:09 -0700 (PDT) X-Trace: 201263058/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.6/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EALV0zEo+vGQG/2dsb2JhbACDJScbjRTGDgqCJ4F5BA X-IronPort-AV: E=Sophos;i="4.44,520,1249254000"; d="scan'208";a="201263058" X-IP-Direction: IN Received: from 1cust6.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.6]) by smtp.pipex.tiscali.co.uk with SMTP; 07 Oct 2009 19:04:47 +0100 Message-ID: <000501ca476f$fa337a20$0601a8c0@allison> From: "tom.petch" To: "Thomson, Martin" , "Peter Saint-Andre" , References: <4AC6786E.2020101@stpeter.im> <001a01ca46a3$ff8377e0$0601a8c0@allison> Subject: Re: * was Re: Server Identity Verification in Application Protocols Date: Wed, 7 Oct 2009 17:56:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 18:03:10 -0000 ----- Original Message ----- From: "Thomson, Martin" Sent: Wednesday, October 07, 2009 12:15 AM > I encountered this issue myself through IESG review of one of my documents. It may have even been the document that triggered this change. > > Many RFCs reference HTTP over TLS [RFC2818], which allows the 'f*' wildcard pattern. In practice (at least for HTTP), this is rarely seen. > > Are you aware of instances where this type of wildcard has been useful in practice for syslog? > > Not being privy to the IESG discussion, I can only speculate on the reasons, but they make sense. Consider common practice with respect to domain name allocations on the web. The registry also fills the CA role and provides a certificate along with a domain name assignment. Delegating 'f*' is not possible in DNS; '*' is. Martin I have no hard data but this was discussed on the syslog list in 2006. An alternative proposal, to cover the case of large numbers of syslog originators feeding through relays to collectors, was to give large numbers of boxes one and the same certificate, ie to have a group identity. This was not seen as terribly secure and so I see the wider use of wildcards as a counter to allowing these generic certificates. Tom Petch > --Martin > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of tom.petch > > Sent: Tuesday, 6 October 2009 9:06 PM > > To: Peter Saint-Andre; apps-discuss@ietf.org > > Subject: * was Re: Server Identity Verification in Application > > Protocols > > > > This specification disallows the use of * to wildcard the reference > > identity. > > > > syslog over TLS not only uses this, but also allows the use of a > > wildcard > > where it would not be allowed in the subjectAltName. > > > > I would see this as quite common in networking scenarios, where the > > access > > is many to many, and so would like a less severe prescription against > > it. > > > > Tom Petch > From Kurt.Zeilenga@Isode.com Wed Oct 7 23:28:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561173A6A2D for ; Wed, 7 Oct 2009 23:28:39 -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_35=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 RIT7VKWFgzOn for ; Wed, 7 Oct 2009 23:28:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CD1593A6A29 for ; Wed, 7 Oct 2009 23:28:37 -0700 (PDT) Received: from [192.168.123.33] ((unknown) [93.82.233.138]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 8 Oct 2009 07:30:18 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: client was Re: Server Identity Verification in Application Protocols From: Kurt Zeilenga X-Priority: 3 In-Reply-To: <000401ca476f$f93013e0$0601a8c0@allison> Date: Thu, 8 Oct 2009 08:30:06 +0200 Message-Id: References: <4AC6786E.2020101@stpeter.im> <001b01ca46a4$017b0220$0601a8c0@allison> <75930B09-C7DD-46D6-A336-B1A80ADF7CDF@Isode.com> <000401ca476f$f93013e0$0601a8c0@allison> To: "tom.petch" X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 06:28:39 -0000 On Oct 7, 2009, at 4:09 PM, tom.petch wrote: > ---- Original Message ----- > From: "Kurt Zeilenga" > Sent: Wednesday, October 07, 2009 9:14 AM > >> On Oct 6, 2009, at 12:09 PM, tom.petch wrote: >> >>> This I-D is very hot on the fact that it is about Server Identity, >>> yet >>> technically, I see no reason why the logic does not also apply >>> equally >>> to client identity. >>> >>> In networking, with the networking box as server, and the client >>> being the one that wants to change the configuration, then client >>> identity is the one that matters, not server. >>> >>> I would like to add an initial paragraph to the effect that although >>> the memo is written in terms of Server Identity, there is no >>> technical reason why the processes described cannot be applied >>> to verifying the Client Identity. >> >> I'm not sure this makes sense. The connection model assumed in this >> document is that the user (directly or via configuration) specifies >> the name of the server which than the client connects to, and this >> document then specifies how to match the user specified name (or a >> secure derivation of that name) to the subject of the certificate the >> server provides. >> >> The technical reason why this cannot be applied to verifying the >> client identity is that server's operator has not specified any name >> to match up the subject in the client's certificate. Also, the >> client certificate is likely to that associated with a human, not a >> service. So the rules would differ significantly. > > I part company with you here. > > In the field of Operations and Management, then the (network) > box is the server and is configured with the identifiers of those > who may access it eg to update the configuration, so yes, the > reference identity is pre-configured in the server. This may be > an IP address, a host name, an e-mail address etc etc. > > The latest I-D includes a quote from the syslog RFC but omits > the earlier statement in that RFC > > " Both syslog transport sender (TLS client) and syslog transport > receiver (TLS server) MUST implement certificate-based > authentication. " > > so without rules for the server to follow, this I-D would be of > no use to syslog (and similar operational applications). I disagree. A syslog document can provide the text necessary to describe how the process detailed in this I-D is applied to syslog. It has to do this anyways. The only think this text makes explicit is that the process defined by this I-D could be used for client identity verification. I don't see any reason why this actually needs to be said. I worry that saying it might lead to implementations using this process for client identity verification without fully considering the implications. I rather leave it to protocol specifications which make use of the verification process for client identity verification to discuss the implications, especially the security implications associated with one determines which reference identity to use as input to a client identity verification process. > > I would (still) suggest adding to Section 1 > > "This memo is written in terms of a client authenticating the identity > of a server. Where the server is configured with reference identities > for clients, and the client certificate contains an identity of the > types > described in section 3.2, then this process MAY be used by a > server to authenticate the identity of a client." How does the server determine which of the reference identities it has been configured with ought to be the one used to verify the certificate the client provided? Why is a "configuration" approach needed? Maybe the application protocol wants to just use the client IP address as the reference identity, or use a DNS-based reverse lookup of the client IP address, or some other approach. I think for the verification process defined by this I-D to be used for client identity verification, there must be additional text describing the process for determining which reference identity to use as input to client identity verification process. There will be security considerations specific to the process of determining the reference identity input which ought to be discussed. I see the determination process as being quite application protocol specific. That is, what process syslog might want to use might well be different from a process used in say XMPP server-to-server communications. I think it best to leave all of client identity verification, especially determination of the reference identity input, to protocol specifications calling for the use of process defined here for server identity verification for client identity verification. -- Kurt > > Tom Petch > >> Now, in certain "server to server" applications, the application >> server which initiates the TLS connection is the TLS "client" under >> this model and this document would seem to naturally apply. But this >> document doesn't not seem to naturally apply for the application >> server accepting the connection, the TLS "server", to verify the >> identity of the TLS "client". While it certainly could apply with >> some additional text, that text, I think would likely be application >> protocol specific. >> >> In short, I rather no confuse this document by noting that an >> application protocol could use this specification for "client >> Identity" checking. Instead, I rather leave this as something >> particular application protocols specifications could call for if and >> when appropriate. I see nothing in the I-D which precludes an >> application protocol specification from so doing. >> >> -- Kurt >> >>> >>> Tom Petch > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From alexey.melnikov@isode.com Thu Oct 8 13:54:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B553A6907 for ; Thu, 8 Oct 2009 13:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 GO6mbEmshozW for ; Thu, 8 Oct 2009 13:54:53 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 951A83A6831 for ; Thu, 8 Oct 2009 13:54:53 -0700 (PDT) Received: from [92.40.141.234] (92.40.141.234.sub.mbb.three.co.uk [92.40.141.234]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 8 Oct 2009 21:56:35 +0100 Message-ID: <4ACE51F6.1080609@isode.com> Date: Thu, 08 Oct 2009 21:56:22 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cyrus Daboo Subject: Re: Server Identity Verification in Application Protocols References: <4AC6786E.2020101@stpeter.im> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:54:54 -0000 Cyrus Daboo wrote: > Hi Peter, Hi Cyrus, > --On October 2, 2009 4:02:22 PM -0600 Peter Saint-Andre > wrote: > >> A new version of draft-saintandre-tls-server-id-check is available: >> >> http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt >> >> Other than the informational appendix, the diff from the -01 version is >> relatively minor. Feedback is welcome. > > Given the recent debate on the email SRV spec (which finished last > call and I need to follow up on) should there be more discussion of > exactly how a client should verify a server when it uses SRV to look > it up? It seems to me it is not clear what a client should verify. > i.e., client looks up the server._tcp name first, then connects to the > server on the returned hostname. Should both the SRV name and the > hostname in the SRV be verified in the cert? I tend to agree. > I would much rather this server identity spec deals with this issue, > and would prefer to reference it from the email SRV spec and CalDAV one. I think the email SRV spec needs to reference the IMAP STARTTLS/IMAPS spec, which should reference the server identity verification document. From guenther+ietf@sendmail.com Thu Oct 8 14:30:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D91E3A69AC for ; Thu, 8 Oct 2009 14:30:23 -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 fvzSmX0Id-WN for ; Thu, 8 Oct 2009 14:30:22 -0700 (PDT) Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by core3.amsl.com (Postfix) with ESMTP id ECA6A28C204 for ; Thu, 8 Oct 2009 14:30:18 -0700 (PDT) Received: from [10.210.202.29] ([10.210.202.29]) (authenticated bits=0) by fife.sendmail.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id n98LVucm030686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Oct 2009 14:31:57 -0700 X-DKIM: Sendmail DKIM Filter v2.5.6 fife.sendmail.com n98LVucm030686 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1255037519; bh=XO4Lw/EpSntT9iistjn6qE2s/iy8ubmOc7Nz5 SVzVjc=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID: References:MIME-Version:Content-Type; b=WG1v6BkU5S2oWT8OGddjj1GDzX U1bhTPfIbFneWcFYLHv6AlveGbSCXgNOrXX+nt72qiCqbH0cWIxVRGVV0w196J6Fsnu TsXX1bbVCBOycY2fO06KqF+WWEG/fGwicq6BBg+KHQNQmm1x8XekQmkSXFBmndUFGZU aKsa2JG2Kp8= X-DKIM: Sendmail DKIM Filter v2.5.6 fife.sendmail.com n98LVucm030686 Date: Thu, 8 Oct 2009 14:31:56 -0700 From: Philip Guenther X-X-Sender: guenther@vanye.sendmail.com To: Cyrus Daboo Subject: Re: Server Identity Verification in Application Protocols In-Reply-To: Message-ID: References: <4AC6786E.2020101@stpeter.im> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-LogiQ-ip: UNKNOWN/n98LVucm030686@fife.sendmail.com X-LogiQ-sender: UNKNOWN/n98LVucm030686@fife.sendmail.com Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 21:30:23 -0000 On Sun, 4 Oct 2009, Cyrus Daboo wrote: ... > Given the recent debate on the email SRV spec (which finished last call > and I need to follow up on) should there be more discussion of exactly > how a client should verify a server when it uses SRV to look it up? It > seems to me it is not clear what a client should verify. i.e., client > looks up the server._tcp name first, then connects to the server on the > returned hostname. Should both the SRV name and the hostname in the SRV > be verified in the cert? The client is 'connecting' to the SRV identifier; it's clearly necessary for the client to verify that the server's certificate lists that identifier to protect the SRV-specific parts of the lookup, but it really protects the entire notional 'connection' process of going from a name to TLS-protected stream. Now, I'm sure there are attacks involving certificate compromise that could be made ineffective if the client also checked whether the cert contained the hostname. If that's a concern, then why wouldn't we also specify checking of IP addresses in certs for the same reasons? Requiring the client to compare more than one value (SRV name, hostname, IP address) makes use of a compromised certificate more difficult at the cost of making it harder for the admin to actually use the flexability provided by the naming systems (SRV->host, host->IP). Or am I just missing the attack on the SRV-aware lookup TLS verification that *doesn't* involve certificate compromise but that is blocked by having the client also check for the host name in the cert? Philip Guenther From stpeter@stpeter.im Thu Oct 8 14:46:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4AB13A6979 for ; Thu, 8 Oct 2009 14:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=-0.132, 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 Rjp3vPhYCzW6 for ; Thu, 8 Oct 2009 14:46:49 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AE9B53A6835 for ; Thu, 8 Oct 2009 14:46:49 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6190240D1F; Thu, 8 Oct 2009 15:48:32 -0600 (MDT) Message-ID: <4ACE5E2F.3070204@stpeter.im> Date: Thu, 08 Oct 2009 15:48:31 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Server Identity Verification in Application Protocols References: <4AC6786E.2020101@stpeter.im> <4ACE51F6.1080609@isode.com> In-Reply-To: <4ACE51F6.1080609@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 21:46:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/8/09 2:56 PM, Alexey Melnikov wrote: > Cyrus Daboo wrote: > >> Hi Peter, > > Hi Cyrus, > >> --On October 2, 2009 4:02:22 PM -0600 Peter Saint-Andre >> wrote: >> >>> A new version of draft-saintandre-tls-server-id-check is available: >>> >>> http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt >>> >>> Other than the informational appendix, the diff from the -01 version is >>> relatively minor. Feedback is welcome. >> >> Given the recent debate on the email SRV spec (which finished last >> call and I need to follow up on) should there be more discussion of >> exactly how a client should verify a server when it uses SRV to look >> it up? It seems to me it is not clear what a client should verify. >> i.e., client looks up the server._tcp name first, then connects to the >> server on the returned hostname. Should both the SRV name and the >> hostname in the SRV be verified in the cert? > > I tend to agree. > >> I would much rather this server identity spec deals with this issue, >> and would prefer to reference it from the email SRV spec and CalDAV one. > > I think the email SRV spec needs to reference the IMAP STARTTLS/IMAPS > spec, which should reference the server identity verification document. That sounds right to me. I have not had time to update the identity verification document to reflect recent discussion, but I will try to do so by the end of next week. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrOXi8ACgkQNL8k5A2w/vy/cwCfVu+mj+OXkA4PDWCAXppgWhJx AwYAn0S+nGfVy+Jz8GxtW709kbbdjOBn =1A3w -----END PGP SIGNATURE----- From shuque@isc.upenn.edu Thu Oct 8 18:55:48 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AE028C0EF for ; Thu, 8 Oct 2009 18:55:48 -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 Wvq6g0ul27Ee for ; Thu, 8 Oct 2009 18:55:47 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 4532F28C0DD for ; Thu, 8 Oct 2009 18:55:47 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 669143656; Thu, 8 Oct 2009 21:57:30 -0400 (EDT) Date: Thu, 8 Oct 2009 21:57:30 -0400 From: Shumon Huque To: Philip Guenther Subject: Re: Server Identity Verification in Application Protocols Message-ID: <20091009015730.GA2701@isc.upenn.edu> References: <4AC6786E.2020101@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 01:55:48 -0000 On Thu, Oct 08, 2009 at 02:31:56PM -0700, Philip Guenther wrote: > On Sun, 4 Oct 2009, Cyrus Daboo wrote: > ... > > Given the recent debate on the email SRV spec (which finished last call > > and I need to follow up on) should there be more discussion of exactly > > how a client should verify a server when it uses SRV to look it up? It > > seems to me it is not clear what a client should verify. i.e., client > > looks up the server._tcp name first, then connects to the server on the > > returned hostname. Should both the SRV name and the hostname in the SRV > > be verified in the cert? > > The client is 'connecting' to the SRV identifier; it's clearly necessary > for the client to verify that the server's certificate lists that > identifier to protect the SRV-specific parts of the lookup, but it really > protects the entire notional 'connection' process of going from a name to > TLS-protected stream. > > Now, I'm sure there are attacks involving certificate compromise that > could be made ineffective if the client also checked whether the cert > contained the hostname. If that's a concern, then why wouldn't we also > specify checking of IP addresses in certs for the same reasons? > Requiring the client to compare more than one value (SRV name, hostname, > IP address) makes use of a compromised certificate more difficult at the > cost of making it harder for the admin to actually use the flexability > provided by the naming systems (SRV->host, host->IP). > > Or am I just missing the attack on the SRV-aware lookup TLS verification > that *doesn't* involve certificate compromise but that is blocked by > having the client also check for the host name in the cert? > > Philip Guenther I was assuming Cyrus meant "SRV name OR hostname" rather than AND, and I think hostname was referring to the "Name" portion of the SRV owner name rather than the hostname that is the target of the SRV record. But I'm sure he'll correct me. Most implementations declare success if they can match any of the identities presented in the certificate. And section 3.1 of draft-saintandre-tls-server-id-check recommends the same. But we also need to clearly state what certificate fields these names are expected to be found in. For application protocols that use SRV records to identify/locate servers, I think the recommendation should be to look for the following in preference order: 1. SRVName as specified in RFC 4985 2. The name portion of the SRV owner name in dNSName I don't particularly like (2) because it leaves open attacks I already described earlier on this list. But it may be a practical necessity if people are using CAs unwilling to issue certs with SRVName (perhaps I'm being too practical). There was a 3rd option proposed by Cyrus of putting the whole SRV owner name (_server._proto.Name) into dNSName. I think we were waiting for comments from security directorate folks about that. This would be a better option than 2. The potential case I see for matching both an SRV name AND a hostname would be for the hostname that is the target of the SRV record. In this case you could deploy a different certificate for each backend server tied to that server's name. And if one of the servers were compromised, could revoke and reissue the certificate for only that backend server without impacting the entire service. But this requires secure DNS (and application layer indicators of such) to securely obtain the SRV->hostname mapping. --Shumon From shuque@isc.upenn.edu Thu Oct 8 19:34:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0629E3A67DA for ; Thu, 8 Oct 2009 19:34:28 -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 kLRp2wflStz5 for ; Thu, 8 Oct 2009 19:34:27 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 2C5113A677E for ; Thu, 8 Oct 2009 19:34:27 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 5D6B03644; Thu, 8 Oct 2009 22:36:10 -0400 (EDT) Date: Thu, 8 Oct 2009 22:36:10 -0400 From: Shumon Huque To: Peter Saint-Andre Subject: Re: Server Identity Verification in Application Protocols Message-ID: <20091009023610.GA3682@isc.upenn.edu> References: <4AC6786E.2020101@stpeter.im> <4ACE51F6.1080609@isode.com> <4ACE5E2F.3070204@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ACE5E2F.3070204@stpeter.im> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 02:34:28 -0000 On Thu, Oct 08, 2009 at 03:48:31PM -0600, Peter Saint-Andre wrote: > On 10/8/09 2:56 PM, Alexey Melnikov wrote: > > Cyrus Daboo wrote: > > > >> I would much rather this server identity spec deals with this issue, > >> and would prefer to reference it from the email SRV spec and CalDAV one. > > > > I think the email SRV spec needs to reference the IMAP STARTTLS/IMAPS > > spec, which should reference the server identity verification document. > > That sounds right to me. I have not had time to update the identity > verification document to reflect recent discussion, but I will try to do > so by the end of next week. > > Peter That would be great. Some other quick comments on your draft: In Section 3.2.1, dNSName and SRVName are discussed without too much distinction being made about the rules for using them. RFC 4985 Section 2 says SRVName must only be used if the application protocol specifies the use of SRV records (or local policy allows it). It would probably help to re-state this restriction in the draft. Section 3.1, bullet item 5 mentions DNSSEC in passing for mapped names. I'd like to see some additional text around the need for an explicit mechanism (eg. an enhanced name resolution API) for the application to confirm that DNSSEC was used to authenticate a mapped name. Otherwise it can only guess. I discussed this briefly in: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00941.html Also, I've wondered this before, but are there any applications that use subjectAltName->uniformResourceIdentifier for server identity? A URI can specify an application protocol (scheme) and a service/host name, and it seems to me that this might be a more general purpose way of specifying service identities. --Shumon. From timur.shemsedinov@gmail.com Mon Oct 12 00:52:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D533A680D for ; Mon, 12 Oct 2009 00:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, GB_I_INVITATION=-2, 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 q15eT36kchoj for ; Mon, 12 Oct 2009 00:52:15 -0700 (PDT) Received: from mail-vw0-f199.google.com (mail-vw0-f199.google.com [209.85.212.199]) by core3.amsl.com (Postfix) with ESMTP id 440743A6781 for ; Mon, 12 Oct 2009 00:52:15 -0700 (PDT) Received: by vws37 with SMTP id 37so292210vws.22 for ; Mon, 12 Oct 2009 00:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jzjIQ++xHY7/8OaiCdmCw4M/OodldwHYBXP04CjUpMc=; b=qJCXJwlXX44aZzrdziTZ3xMtBVJ8DlAM0g69jgSvJuzfXsJXCeO/J9IcUUBe/ztHT9 xiH4DqrofL/ju/AYTQZhWp4U2RPjKBdi2lJ1+BZtbxm4KBRknRMq6KH/WbZ99mVMRFpS qy0p8Qf9Vr/4/3WD6aGAq8pJsaq8fi/sW3tGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SkUTaBRwdTNYsO/I8b6r46LsKkyHUELQkb8RIBlqwC/F3UxfziN9dBVo3uoj9GbUCR J3lH3NHMRFOJpWnDyUumAgalA6p2xRtZlO1BxBS3S4Qy1ApjaLDf3UHGWMWVA8gw2gU4 LSonP4KrFj6pg+XRMt5iCzs/ttD6QnZYuroMM= MIME-Version: 1.0 Received: by 10.220.17.37 with SMTP id q37mr1584763vca.111.1255333932335; Mon, 12 Oct 2009 00:52:12 -0700 (PDT) In-Reply-To: <8B62A039C620904E92F1233570534C9B0118DC469C8A@nambx04.corp.adobe.com> References: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <248bcd790908192318ta0b263g3f95060094a7b3ac@mail.gmail.com> <8B62A039C620904E92F1233570534C9B0118DC469C8A@nambx04.corp.adobe.com> Date: Mon, 12 Oct 2009 10:52:12 +0300 Message-ID: <248bcd790910120052k3e5e533cod221ebc6b6c020ca@mail.gmail.com> Subject: Re: Guidelines on usage of // in new URI schemes From: Timur Shemsedinov To: Larry Masinter Content-Type: multipart/alternative; boundary=00151757408c1c81dd0475b83538 Cc: "PUBLIC-IRI@W3.ORG" , Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 07:52:17 -0000 --00151757408c1c81dd0475b83538 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, There are many schemes used in software and hardware which have no "//" in their syntax and I think there are no way and no need to add "//" into existing schemes. Otherwise, it will require expensive changes in existing systems without any benefit. See schemes list: http://www.iana.org/assignments/uri-schemes.html I think that following: mailto:, tel: and urn: can't be changed. On Sun, Oct 11, 2009 at 10:09 PM, Larry Masinter wrote= : > This was discussed on apps-discuss and the URI list a while back, so I > have bcc=92d those lists, but I want to focus the discussion on the > public-iri@w3.org list, so please only reply there. > > > > In order to handle IDNs appropriately, I would like to make the rule that > any scheme that allows non-ASCII or pct-encoded values in the =93host=94 = field > in the generic syntax MUST allow or mandate that IRI -> URI processing > follow IDNa rules. That is, no matter what the scheme, if you have > > > > scheme://nonascii.name/path/here as an IRI, and want to translate it > to a URI, you MUST use IDNA to turn it into > > > > scheme://alabel.for.nonascii.name/ascii.for.path/ascii.for.here > > > > no matter what the scheme. This is what you have to do for almost all URI > schemes now anyway in order to function properly. > > > > This would change the guidelines on use of =93//=94 for new schemes, but = are > there any URI schemes in use for which this would actually be a problem i= n > practice? > > > > Larry > > -- > > http://larry.masinter.net > > > > *From:* apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] *On Behalf Of *Timur Shemsedinov > *Sent:* Thursday, August 20, 2009 7:44 AM > *To:* Eran Hammer-Lahav > *Cc:* URI; apps-discuss@ietf.org > *Subject:* [Moderator Action] Re: Guidelines on usage of // in new URI > schemes > > > > *Hello* > > See RFC 2718 - Guidelines for new URL Schemes > http://www.ietf.org/rfc/rfc2718.txt > > 2.1.2 Improper use of "//" following ":" > > Contrary to some examples set in past years, the use of double > slashes as the first component of the of a URL > is not simply an artistic indicator that what follows is a URL: > Double slashes are used ONLY when the syntax of the URL's specific-part> contains a hierarchical structure as described in RFC > 2396. In URLs from such schemes, the use of double slashes indicates > that what follows is the top hierarchical element for a naming > authority. (See section 3 of RFC 2396 for more details.) URL > schemes which do not contain a conformant hierarchical structure in > their should not use double slashes following > the ":" string. > > On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav > wrote: > > I am in the process of proposing a new URI scheme to identify user accoun= ts > [1]. This is part of the WebFinger protocol [2] effort. > > This email is *not* an invitation to debate the merits of this new URI > scheme (just yet). I am sure we will have many lively discussions about i= t > shortly but I would like to present a proposal before we have a public > debate about it here. > > The new scheme has two components, a local identifier (username, > screenname, handle, etc.) and a host (which can resolve and authenticate = the > local identifier). When looking at the URI specification (RFC 3986) and a= t > the new URI guidelines (BCP 35), it is hard to figure out what is an > appropriate use of // in new schemes. > > In this case, we have a requirement to keep the URI (the part after the > scheme:) looking as close to an RFC-822 identifier (username@host) and > that means two options: > > acct:username@host > acct://username@host > > The 'username@host' part seems to fit perfectly into the URI authority as > defined by RFC 3986. However, since the URI does not have a path, it does > not really contain a hierarchical structure (just the top level host). > > The benefit of using // in this case is that existing URI parsing code ca= n > be used unmodified to process the new URI. It is a simple profile which o= nly > allows the userinfo and host subcomponents of the authority component, an= d > no other URI components. Since the new scheme will be often used with URI > templates and other facilities often used with http: URIs, it is very > convenient to have a common structure (even if it is only a subset). I do= n't > see any down side to using // other than defying expectations established= by > the mailto: URI scheme. > > The benefit of not using // is that it makes the URI follow the well > establish pattern in mailto: and save two bytes. The down side is that it > requires spelling out how to break the URI path into sub components speci= fic > to this scheme. > > So far the feedback I received is focus on style which is perfectly valid= , > but I want to make sure I am not missing anything. My preference is to re= use > as much as possible and therefore include the //. > > Any suggestions? > > EHL > > [1] > http://www.hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-ac= ct-uri-scheme-for-accounts.html > [2] http://code.google.com/p/webfinger > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > --00151757408c1c81dd0475b83538 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello,

There are many schemes used in software and hardware which ha= ve no "//" in their syntax and I think there are no way and no ne= ed to add "//" into existing schemes. Otherwise, it will require = expensive changes in existing systems without any benefit. See schemes list= : http://www.i= ana.org/assignments/uri-schemes.html I think that following: mailto:, t= el: and urn: can't be changed.

On Sun, Oct 11, 2009 at 10:09 PM, Larry Masi= nter <masinter@a= dobe.com> wrote:

This was discussed on apps-discuss and the URI list a while back, so I have bcc=92d those lists, but I want to focus the discussion on the public-iri@w3.or= g list, so please only reply there.

=A0

In order to handle IDNs appropriately, I would like to make the rule that any scheme that allows non-ASCII or pct-encoded values in the =93= host=94 field in the generic syntax MUST allow or mandate that IRI -> URI proces= sing follow IDNa rules. That is, no matter what the scheme, if you have

=A0

scheme://nonascii.name/path/here=A0=A0=A0=A0 as an IRI, and want to translate it to a URI, you MUST use IDNA to turn it into

=A0

scheme://alabel.for.nonascii.name/ascii.for.path/asc= ii.for.here

=A0

no matter what the scheme. This is what you have to do for almost all URI schemes now anyway in order to function properly.

=A0

This would change the guidelines on use of =93//=94 for new schemes, but are there any URI schemes in use for which this would actu= ally be a problem in practice?

=A0

Larry

--

http://larry.= masinter.net

=A0

From:= apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Timur Shemsedinov
Sent: Thursday, August 20, 2009 7:44 AM
To: Eran Hammer-Lahav
Cc: URI; = apps-discuss@ietf.org
Subject: [Moderator Action] Re: Guidelines on usage of // in new URI schemes

=A0

Hello

See RFC 2718 - Guidelines for new URL Schemes
http://ww= w.ietf.org/rfc/rfc2718.txt

2.1.2 Improper use of "//" following "<scheme>:"<= br>
Contrary to some examples set in past years, the use of double
slashes as the first component of the <scheme-specific-part> of a URL=
is not simply an artistic indicator that what follows is a URL:
Double slashes are used ONLY when the syntax of the URL's <scheme- specific-part> contains a hierarchical structure as described in RFC
2396. In URLs from such schemes, the use of double slashes indicates
that what follows is the top hierarchical element for a naming
authority. (See section 3 of RFC 2396 for more details.) URL
schemes which do not contain a conformant hierarchical structure in
their <scheme-specific-part> should not use double slashes following<= br> the "<scheme>:" string.

On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav &= lt;eran@hueniverse= .com> wrote:

I am in the process of proposing a new URI scheme to identify user accounts [1]. This is part of the WebFinger protocol [2] effo= rt.

This email is *not* an invitation to debate the merits of this new URI sche= me (just yet). I am sure we will have many lively discussions about it shortly= but I would like to present a proposal before we have a public debate about it here.

The new scheme has two components, a local identifier (username, screenname= , handle, etc.) and a host (which can resolve and authenticate the local identifier). When looking at the URI specification (RFC 3986) and at the ne= w URI guidelines (BCP 35), it is hard to figure out what is an appropriate us= e of // in new schemes.

In this case, we have a requirement to keep the URI (the part after the scheme:) looking as close to an RFC-822 identifier (username@host) and that means two options:

acct:username@host
acct://username@host

The 'username@host' part seems to fit perfectly into the URI author= ity as defined by RFC 3986. However, since the URI does not have a path, it does n= ot really contain a hierarchical structure (just the top level host).

The benefit of using // in this case is that existing URI parsing code can = be used unmodified to process the new URI. It is a simple profile which only allows the userinfo and host subcomponents of the authority component, and = no other URI components. Since the new scheme will be often used with URI templates and other facilities often used with http: URIs, it is very convenient to have a common structure (even if it is only a subset). I don&= #39;t see any down side to using // other than defying expectations established b= y the mailto: URI scheme.

The benefit of not using // is that it makes the URI follow the well establ= ish pattern in mailto: and save two bytes. The down side is that it requires spelling out how to break the URI path into sub components specific to this scheme.

So far the feedback I received is focus on style which is perfectly valid, = but I want to make sure I am not missing anything. My preference is to reuse as much as possible and therefore include the //.

Any suggestions?

EHL

[1] http://www.= hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-acct-uri-scheme= -for-accounts.html
[2] http:/= /code.google.com/p/webfinger
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

=A0


--00151757408c1c81dd0475b83538-- From alexey.melnikov@isode.com Mon Oct 12 03:24:13 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00CC43A67AE for ; Mon, 12 Oct 2009 03:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, GB_I_INVITATION=-2, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6PUQ2rGAKYV for ; Mon, 12 Oct 2009 03:24:11 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0EC523A67C0 for ; Mon, 12 Oct 2009 03:24:11 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Oct 2009 11:24:10 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4AD303BA.2080400@isode.com> Date: Mon, 12 Oct 2009 11:23:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Timur Shemsedinov Subject: Re: Guidelines on usage of // in new URI schemes References: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <248bcd790908192318ta0b263g3f95060094a7b3ac@mail.gmail.com> <8B62A039C620904E92F1233570534C9B0118DC469C8A@nambx04.corp.adobe.com> <248bcd790910120052k3e5e533cod221ebc6b6c020ca@mail.gmail.com> In-Reply-To: <248bcd790910120052k3e5e533cod221ebc6b6c020ca@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Cc: "PUBLIC-IRI@W3.ORG" , Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 10:24:13 -0000 Timur Shemsedinov wrote: > Hello, Hi Timur, > There are many schemes used in software and hardware which have no=20 > "//" in their syntax and I think there are no way and no need to add=20 > "//" into existing schemes. Otherwise, it will require expensive=20 > changes in existing systems without any benefit. See schemes list:=20 > http://www.iana.org/assignments/uri-schemes.html I think that=20 > following: mailto:, tel: and urn: can't be changed. I think you've misunderstood what Larry was proposing. He is saying that=20 all current or future IRI scheme that contain "//" must use IDNA to=20 convert the hostname part, when converting them to URIs. This would not=20 affect mailto:, tel: or urn:. > On Sun, Oct 11, 2009 at 10:09 PM, Larry Masinter > wrote: > > This was discussed on apps-discuss and the URI list a while back, > so I have bcc=92d those lists, but I want to focus the discussion on > the public-iri@w3.org list, so please > only reply there. > > =20 > > In order to handle IDNs appropriately, I would like to make the > rule that any scheme that allows non-ASCII or pct-encoded values > in the =93host=94 field in the generic syntax MUST allow or mandate > that IRI -> URI processing follow IDNa rules. That is, no matter > what the scheme, if you have > > =20 > > scheme://nonascii.name/path/here > as an IRI, and want to > translate it to a URI, you MUST use IDNA to turn it into > > =20 > > scheme://alabel.for.nonascii.name/ascii.for.path/ascii.for.here > > > =20 > > no matter what the scheme. This is what you have to do for almost > all URI schemes now anyway in order to function properly. > > =20 > > This would change the guidelines on use of =93//=94 for new schemes, > but are there any URI schemes in use for which this would actually > be a problem in practice? > > =20 > > Larry > > -- > > http://larry.masinter.net > > =20 > > *From:* apps-discuss-bounces@ietf.org > > [mailto:apps-discuss-bounces@ietf.org > ] *On Behalf Of *Timur > Shemsedinov > *Sent:* Thursday, August 20, 2009 7:44 AM > *To:* Eran Hammer-Lahav > *Cc:* URI; apps-discuss@ietf.org > *Subject:* [Moderator Action] Re: Guidelines on usage of // in new > URI schemes > > =20 > > *Hello* > > See RFC 2718 - Guidelines for new URL Schemes > http://www.ietf.org/rfc/rfc2718.txt > > 2.1.2 Improper use of "//" following ":" > > Contrary to some examples set in past years, the use of double > slashes as the first component of the of a URL > is not simply an artistic indicator that what follows is a URL: > Double slashes are used ONLY when the syntax of the URL's specific-part> contains a hierarchical structure as described in RFC > 2396. In URLs from such schemes, the use of double slashes indicates > that what follows is the top hierarchical element for a naming > authority. (See section 3 of RFC 2396 for more details.) URL > schemes which do not contain a conformant hierarchical structure in > their should not use double slashes following > the ":" string. > > On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav > > wrote: > > I am in the process of proposing a new URI scheme to identify user > accounts [1]. This is part of the WebFinger protocol [2] effort. > > This email is *not* an invitation to debate the merits of this new > URI scheme (just yet). I am sure we will have many lively > discussions about it shortly but I would like to present a > proposal before we have a public debate about it here. > > The new scheme has two components, a local identifier (username, > screenname, handle, etc.) and a host (which can resolve and > authenticate the local identifier). When looking at the URI > specification (RFC 3986) and at the new URI guidelines (BCP 35), > it is hard to figure out what is an appropriate use of // in new > schemes. > > In this case, we have a requirement to keep the URI (the part > after the scheme:) looking as close to an RFC-822 identifier > (username@host) and that means two options: > > acct:username@host > acct://username@host > > The 'username@host' part seems to fit perfectly into the URI > authority as defined by RFC 3986. However, since the URI does not > have a path, it does not really contain a hierarchical structure > (just the top level host). > > The benefit of using // in this case is that existing URI parsing > code can be used unmodified to process the new URI. It is a simple > profile which only allows the userinfo and host subcomponents of > the authority component, and no other URI components. Since the > new scheme will be often used with URI templates and other > facilities often used with http: URIs, it is very convenient to > have a common structure (even if it is only a subset). I don't see > any down side to using // other than defying expectations > established by the mailto: URI scheme. > > The benefit of not using // is that it makes the URI follow the > well establish pattern in mailto: and save two bytes. The down > side is that it requires spelling out how to break the URI path > into sub components specific to this scheme. > > So far the feedback I received is focus on style which is > perfectly valid, but I want to make sure I am not missing > anything. My preference is to reuse as much as possible and > therefore include the //. > > Any suggestions? > > EHL > > [1] > http://www.hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new= -acct-uri-scheme-for-accounts.html > [2] http://code.google.com/p/webfinger > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > =20 > > >------------------------------------------------------------------------ > >_______________________________________________ >Apps-Discuss mailing list >Apps-Discuss@ietf.org >https://www.ietf.org/mailman/listinfo/apps-discuss > =20 > --=20 IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From masinter@adobe.com Sun Oct 11 12:10:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2163A6976 for ; Sun, 11 Oct 2009 12:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, 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 K4UzT3voXf1G for ; Sun, 11 Oct 2009 12:10:08 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by core3.amsl.com (Postfix) with ESMTP id 2C7D428C10B for ; Sun, 11 Oct 2009 12:10:06 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKStItcveigkYlXXvV5YqOr+Xss7Ia5QPX@postini.com; Sun, 11 Oct 2009 12:10:08 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9BJ9ZX3020268; Sun, 11 Oct 2009 12:09:35 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9BJ9Yiq018883; Sun, 11 Oct 2009 12:09:34 -0700 (PDT) Received: from nambx04.corp.adobe.com ([10.8.127.98]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Sun, 11 Oct 2009 12:09:34 -0700 From: Larry Masinter To: "PUBLIC-IRI@W3.ORG" Date: Sun, 11 Oct 2009 12:09:32 -0700 Subject: Re: Guidelines on usage of // in new URI schemes Thread-Topic: Guidelines on usage of // in new URI schemes Thread-Index: AcohpKAZ0n+boL4zSduY7HI3BcbXUQpAMkeg Message-ID: <8B62A039C620904E92F1233570534C9B0118DC469C8A@nambx04.corp.adobe.com> References: <90C41DD21FB7C64BB94121FBBC2E72343783606CBD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <248bcd790908192318ta0b263g3f95060094a7b3ac@mail.gmail.com> In-Reply-To: <248bcd790908192318ta0b263g3f95060094a7b3ac@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B62A039C620904E92F1233570534C9B0118DC469C8Anambx04corp_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 12 Oct 2009 08:04:41 -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: , X-List-Received-Date: Sun, 11 Oct 2009 19:10:16 -0000 --_000_8B62A039C620904E92F1233570534C9B0118DC469C8Anambx04corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This was discussed on apps-discuss and the URI list a while back, so I have= bcc'd those lists, but I want to focus the discussion on the public-iri@w3= .org list, so please only reply there. In order to handle IDNs appropriately, I would like to make the rule that a= ny scheme that allows non-ASCII or pct-encoded values in the "host" field i= n the generic syntax MUST allow or mandate that IRI -> URI processing follo= w IDNa rules. That is, no matter what the scheme, if you have scheme://nonascii.name/path/here as an IRI, and want to translate it to= a URI, you MUST use IDNA to turn it into scheme://alabel.for.nonascii.name/ascii.for.path/ascii.for.here no matter what the scheme. This is what you have to do for almost all URI s= chemes now anyway in order to function properly. This would change the guidelines on use of "//" for new schemes, but are th= ere any URI schemes in use for which this would actually be a problem in pr= actice? Larry -- http://larry.masinter.net From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Timur Shemsedinov Sent: Thursday, August 20, 2009 7:44 AM To: Eran Hammer-Lahav Cc: URI; apps-discuss@ietf.org Subject: [Moderator Action] Re: Guidelines on usage of // in new URI scheme= s Hello See RFC 2718 - Guidelines for new URL Schemes http://www.ietf.org/rfc/rfc2718.txt 2.1.2 Improper use of "//" following ":" Contrary to some examples set in past years, the use of double slashes as the first component of the of a URL is not simply an artistic indicator that what follows is a URL: Double slashes are used ONLY when the syntax of the URL's contains a hierarchical structure as described in RFC 2396. In URLs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See section 3 of RFC 2396 for more details.) URL schemes which do not contain a conformant hierarchical structure in their should not use double slashes following the ":" string. On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav > wrote: I am in the process of proposing a new URI scheme to identify user accounts= [1]. This is part of the WebFinger protocol [2] effort. This email is *not* an invitation to debate the merits of this new URI sche= me (just yet). I am sure we will have many lively discussions about it shor= tly but I would like to present a proposal before we have a public debate a= bout it here. The new scheme has two components, a local identifier (username, screenname= , handle, etc.) and a host (which can resolve and authenticate the local id= entifier). When looking at the URI specification (RFC 3986) and at the new = URI guidelines (BCP 35), it is hard to figure out what is an appropriate us= e of // in new schemes. In this case, we have a requirement to keep the URI (the part after the sch= eme:) looking as close to an RFC-822 identifier (username@host) and that me= ans two options: acct:username@host acct://username@host The 'username@host' part seems to fit perfectly into the URI authority as d= efined by RFC 3986. However, since the URI does not have a path, it does no= t really contain a hierarchical structure (just the top level host). The benefit of using // in this case is that existing URI parsing code can = be used unmodified to process the new URI. It is a simple profile which onl= y allows the userinfo and host subcomponents of the authority component, an= d no other URI components. Since the new scheme will be often used with URI= templates and other facilities often used with http: URIs, it is very conv= enient to have a common structure (even if it is only a subset). I don't se= e any down side to using // other than defying expectations established by = the mailto: URI scheme. The benefit of not using // is that it makes the URI follow the well establ= ish pattern in mailto: and save two bytes. The down side is that it require= s spelling out how to break the URI path into sub components specific to th= is scheme. So far the feedback I received is focus on style which is perfectly valid, = but I want to make sure I am not missing anything. My preference is to reus= e as much as possible and therefore include the //. Any suggestions? EHL [1] http://www.hueniverse.com/hueniverse/2009/08/making-the-case-for-a-new-= acct-uri-scheme-for-accounts.html [2] http://code.google.com/p/webfinger _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_8B62A039C620904E92F1233570534C9B0118DC469C8Anambx04corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This was discussed on apps-discuss and the URI list a while back, so I have bcc’d those lists, but I want to focus the discussion= on the public-iri@w3.org list, so please only reply there.

 

In order to handle IDNs appropriately, I would like to make = the rule that any scheme that allows non-ASCII or pct-encoded values in the = 220;host” field in the generic syntax MUST allow or mandate that IRI -> URI proces= sing follow IDNa rules. That is, no matter what the scheme, if you have

 

scheme://nonascii.name/path/here     as = an IRI, and want to translate it to a URI, you MUST use IDNA to turn it into

 

scheme://alabel.for.nonascii.name/ascii.for.path/ascii.for.h= ere

 

no matter what the scheme. This is what you have to do for almost all URI schemes now anyway in order to function properly.=

 

This would change the guidelines on use of “//” = for new schemes, but are there any URI schemes in use for which this would actu= ally be a problem in practice?

 

Larry

--

http://larry.masinter.net

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Timur Shemsedinov
Sent: Thursday, August 20, 2009 7:44 AM
To: Eran Hammer-Lahav
Cc: URI; apps-discuss@ietf.org
Subject: [Moderator Action] Re: Guidelines on usage of // in new URI schemes

 

Hello

See RFC 2718 - Guidelines for new URL Schemes
http://www.ietf.org/rfc/rfc= 2718.txt

2.1.2 Improper use of "//" following "<scheme>:"<= br>
Contrary to some examples set in past years, the use of double
slashes as the first component of the <scheme-specific-part> of a URL=
is not simply an artistic indicator that what follows is a URL:
Double slashes are used ONLY when the syntax of the URL's <scheme-
specific-part> contains a hierarchical structure as described in RFC
2396. In URLs from such schemes, the use of double slashes indicates
that what follows is the top hierarchical element for a naming
authority. (See section 3 of RFC 2396 for more details.) URL
schemes which do not contain a conformant hierarchical structure in
their <scheme-specific-part> should not use double slashes following<= br> the "<scheme>:" string.

On Thu, Aug 20, 2009 at 8:48 AM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:=

I am in the process of proposing a new URI scheme to identify user accounts [1]. This is part of the WebFinger protocol [2] effo= rt.

This email is *not* an invitation to debate the merits of this new URI sche= me (just yet). I am sure we will have many lively discussions about it shortly= but I would like to present a proposal before we have a public debate about it here.

The new scheme has two components, a local identifier (username, screenname= , handle, etc.) and a host (which can resolve and authenticate the local identifier). When looking at the URI specification (RFC 3986) and at the ne= w URI guidelines (BCP 35), it is hard to figure out what is an appropriate us= e of // in new schemes.

In this case, we have a requirement to keep the URI (the part after the scheme:) looking as close to an RFC-822 identifier (username@host) and that means two options:

acct:username@host
acct://username@host

The 'username@host' part seems to fit perfectly into the URI authority as defined by RFC 3986. However, since the URI does not have a path, it does n= ot really contain a hierarchical structure (just the top level host).

The benefit of using // in this case is that existing URI parsing code can = be used unmodified to process the new URI. It is a simple profile which only allows the userinfo and host subcomponents of the authority component, and = no other URI components. Since the new scheme will be often used with URI templates and other facilities often used with http: URIs, it is very convenient to have a common structure (even if it is only a subset). I don'= t see any down side to using // other than defying expectations established b= y the mailto: URI scheme.

The benefit of not using // is that it makes the URI follow the well establ= ish pattern in mailto: and save two bytes. The down side is that it requires spelling out how to break the URI path into sub components specific to this scheme.

So far the feedback I received is focus on style which is perfectly valid, = but I want to make sure I am not missing anything. My preference is to reuse as much as possible and therefore include the //.

Any suggestions?

EHL

[1] http://www.hueniverse.com/hueniverse/2009/08/making-the-c= ase-for-a-new-acct-uri-scheme-for-accounts.html
[2] http:/= /code.google.com/p/webfinger
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

 

--_000_8B62A039C620904E92F1233570534C9B0118DC469C8Anambx04corp_-- From paul.hoffman@vpnc.org Mon Oct 12 07:29:49 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9CD3A6814 for ; Mon, 12 Oct 2009 07:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.632 X-Spam-Level: X-Spam-Status: No, score=-103.632 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, 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 tksWNifZvT09 for ; Mon, 12 Oct 2009 07:29:49 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 08F7428C18A for ; Mon, 12 Oct 2009 07:29:48 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9CETlrF078720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Oct 2009 07:29:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 12 Oct 2009 07:29:33 -0700 To: discuss@apps.ietf.org From: The IESG (by way of Paul Hoffman) Subject: Last Call: draft-hammer-oauth (The OAuth Core 1.0 Protocol) to Informational RFC Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Mon, 12 Oct 2009 08:04:41 -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: , X-List-Received-Date: Mon, 12 Oct 2009 14:29:49 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'The OAuth Core 1.0 Protocol ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hammer-oauth-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17736&rfc_flag=0 From paul.hoffman@vpnc.org Mon Oct 12 07:29:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2423A67AA for ; Mon, 12 Oct 2009 07:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.839 X-Spam-Level: X-Spam-Status: No, score=-104.839 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 gsPWHyC1u2Wt for ; Mon, 12 Oct 2009 07:29:49 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 9FD363A672E for ; Mon, 12 Oct 2009 07:29:49 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9CETlrH078720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Oct 2009 07:29:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 12 Oct 2009 07:29:45 -0700 To: discuss@apps.ietf.org From: The IESG (by way of Paul Hoffman) Subject: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Mon, 12 Oct 2009 08:04:41 -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: , X-List-Received-Date: Mon, 12 Oct 2009 14:29:50 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'Defining Well-Known URIs ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17778&rfc_flag=0 From A.Hoenes@TR-Sys.de Tue Oct 13 02:30:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E683A67A6 for ; Tue, 13 Oct 2009 02:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.402 X-Spam-Level: ** X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[AWL=1.151, 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 yUpYJ3tNbTWe for ; Tue, 13 Oct 2009 02:30:24 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 18F783A6774 for ; Tue, 13 Oct 2009 02:30:22 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA223256179; Tue, 13 Oct 2009 11:29:39 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA22123; Tue, 13 Oct 2009 11:29:25 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910130929.LAA22123@TR-Sys.de> Subject: draft-nottingham-site-meta-03 To: mnot@mnot.net, eran@hueniverse.com, apps-discuss@ietf.org Date: Tue, 13 Oct 2009 11:29:25 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 09:30:25 -0000 Hello, I've taken a look at draft-nottingham-site-meta-03 and would like to submit a few comments, grouped into two topics. (Otherwise, the editorial quality of the draft is very good!) (1) Scope / Applicability Despite the motivation given in the Introduction, Appendix B.3 clarifies that the draft does not only target the 'http' and 'https' URI schemes, but Section 3 does not contain any indication regarding applicability. The proposal thus interferes with the specification of the majority of existing and in-progress URI scheme definitions, in particular those URI schemes that specify "actions" (like 'mailto', 'telnet', 'sip'/'sips', 'sms', 'go', etc.), are somehow transaction-oriented (like 'im', 'ipp', 'dict', 'mupdate', 'snmp', 'iris.*', 'aaa'/'aaas', 'msrp'/'msrps') or otherwise identify non-retrievable or even non- networked resources (like 'mid', cid', 'urn', 'doi', 'info', 'tel', 'fax'/'modem' [deprecated], 'tv'). Also, the protocols bound to many URI schemes do only allow the exchange of well-specified messages and not the retrieval of arbitrary media types, and as such are not amenable to the kind of information you have in mind for this proposal. Therefore, I would greatly appreciate if the scope of the proposal could be restricted and more clearly specified in the normative part of the draft. Here's a rough first attempt to capture what might be said better in the first paragraph of Section 3: OLD: | A well-known URI is a URI [RFC3986] whose path component begins with | the characters "/.well-known/". NEW: | A well-known URI is a URI [RFC3986] with a URI scheme that supports | retrieval of generic network-based resources like the 'ftp', 'http', | or 'https' scheme, and whose path component begins with the | characters "/.well-known/". The specific syntax requirements of | the URI scheme used MUST admit this form and instance of a path | component. [[ The three example URI schems are given in alphabetical order. :-) ]] However, I would prefer a definite list of allowed URI schemes here. Any new URI scheme definition (or update to an existing definition) that wants to admit/support this mechanism would then have to state that precisely -- which would be very good for clarity. Furthermore, following the spirit of B.3, I strongly suggest that, for clarity and precision, the registration template should include a specific, mandatory clause, "Applicable URI schemes:". This proposal slighrly changes the semantics of the affected URI schemes, part of which have been specified in Standars Track RFCs. Consequentially, the Intended Status and metadata of the draft should be reconsidered: it perhaps should formally 'Update' those RFCs and must try to go the Standards Track as well. (2) Terminology Please use precise terminology as established in the IETF and elsewhere. The colloquial sloppy truncation of the precise term, "header field[s]" to "header[s]" should be avoided in RFCs-to-be. Please adjust the 2nd paragraph in Section 1 accordingly. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From mnot@mnot.net Tue Oct 13 18:24:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3C928C17F for ; Tue, 13 Oct 2009 18:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQxJ1m7hBotJ for ; Tue, 13 Oct 2009 18:24:18 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 8DD3C3A6863 for ; Tue, 13 Oct 2009 18:24:18 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.5.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 03EC4509B3; Tue, 13 Oct 2009 21:24:12 -0400 (EDT) Subject: Re: draft-nottingham-site-meta-03 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: <200910130929.LAA22123@TR-Sys.de> Date: Wed, 14 Oct 2009 12:24:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <200910130929.LAA22123@TR-Sys.de> To: =?iso-8859-1?Q?Alfred_H=CEnes?= X-Mailer: Apple Mail (2.1076) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 01:24:19 -0000 Hello, Thanks for the feedback; responses below. On 13/10/2009, at 8:29 PM, Alfred H=CEnes wrote: > > (1) Scope / Applicability > > Despite the motivation given in the Introduction, Appendix B.3 > clarifies that the draft does not only target the 'http' and > 'https' URI schemes, but Section 3 does not contain any indication > regarding applicability. > > The proposal thus interferes with the specification of the majority > of existing and in-progress URI scheme definitions, in particular > those URI schemes that specify "actions" (like 'mailto', 'telnet', > 'sip'/'sips', 'sms', 'go', etc.), are somehow transaction-oriented > (like 'im', 'ipp', 'dict', 'mupdate', 'snmp', 'iris.*', 'aaa'/'aaas', > 'msrp'/'msrps') or otherwise identify non-retrievable or even non- > networked resources (like 'mid', cid', 'urn', 'doi', 'info', 'tel', > 'fax'/'modem' [deprecated], 'tv'). > Also, the protocols bound to many URI schemes do only allow the > exchange of well-specified messages and not the retrieval of > arbitrary media types, and as such are not amenable to the kind > of information you have in mind for this proposal. > > Therefore, I would greatly appreciate if the scope of the proposal > could be restricted and more clearly specified in the normative part > of the draft. > > Here's a rough first attempt to capture what might be said better > in the first paragraph of Section 3: > > OLD: > > | A well-known URI is a URI [RFC3986] whose path component begins =20 > with > | the characters "/.well-known/". > > NEW: > > | A well-known URI is a URI [RFC3986] with a URI scheme that supports > | retrieval of generic network-based resources like the 'ftp', =20 > 'http', > | or 'https' scheme, and whose path component begins with the > | characters "/.well-known/". The specific syntax requirements of > | the URI scheme used MUST admit this form and instance of a path > | component. > > [[ The three example URI schems are given in alphabetical =20 > order. :-) ]] The intent of "whose path component begins" was to have the effect of =20= restricting the URI schemes well-known is applicable, but a closer =20 reading of 3986 (and your comment, of course) shows that this isn't =20 the case. I'd very much like to use language and concepts from 3986 if possible, =20= rather than minting yet another classification of URIs (even though =20 the one you suggest is intuitive and obvious). Would 'hierarchical =20 paths' serve this purpose well enough? I suspect it may not, but it's =20= worth consideration. > However, I would prefer a definite list of allowed URI schemes here. > Any new URI scheme definition (or update to an existing definition) > that wants to admit/support this mechanism would then have to state > that precisely -- which would be very good for clarity. This would probably be simpler. Eran, your thoughts -- would it be =20 enough to just specify for FTP, HTTP and HTTPS, allowing other schemes =20= to opt into it if they desire to? > Furthermore, following the spirit of B.3, I strongly suggest that, > for clarity and precision, the registration template should include > a specific, mandatory clause, "Applicable URI schemes:". This gives me pause. Would someone be able to register "foo" for =20 protocol A, and someone else the same token for protocol B? Would they =20= have to update it for protocols that are added later? Won't the common =20= case be that registrations will want it to apply to all protocols =20 (indeed, will there be any other case)? > This proposal slighrly changes the semantics of the affected URI > schemes, part of which have been specified in Standars Track RFCs. > Consequentially, the Intended Status and metadata of the draft > should be reconsidered: it perhaps should formally 'Update' those > RFCs and must try to go the Standards Track as well. It is going attempting to go to Standards Track; see Lisa's last call =20= (ignore the in-document status) = . I agree it needs to update some documents; depending on how the above =20= discussion goes, it needs to update either 3986 or the specific =20 protocols in question. > (2) Terminology > > Please use precise terminology as established in the IETF and > elsewhere. The colloquial sloppy truncation of the precise term, > "header field[s]" to "header[s]" should be avoided in RFCs-to-be. > Please adjust the 2nd paragraph in Section 1 accordingly. Given that it's the introduction and non-normative, and that it's =20 clear to readers, I'm not inclined to change this. "Headers" is widely-=20= used (e.g., in 2616) and understood. Regards and thanks again, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Oct 13 18:26:06 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910083A6863 for ; Tue, 13 Oct 2009 18:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8Rq40qXk54T for ; Tue, 13 Oct 2009 18:26:05 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id B89AA28C18E for ; Tue, 13 Oct 2009 18:26:05 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.5.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 25601509DA; Tue, 13 Oct 2009 21:26:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) Subject: Fwd: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard From: Mark Nottingham Date: Wed, 14 Oct 2009 12:26:02 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <92D713CF-28C5-4CCB-8803-A03CDCDED61B@cs.cmu.edu> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1076) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 01:26:06 -0000 Forwarded with permission. Do people find this interesting? To specify it, we'd just need to describe a format (e.g., a space-separated list of tokens). Cheers, Begin forwarded message: > From: Lorrie Faith Cranor > Date: 13 October 2009 12:03:24 AM AEDT > To: Mark Nottingham > Subject: Re: Last Call: draft-nottingham-site-meta (Defining Well- > Known URIs) to Proposed Standard > > Hey Mark! > > I just saw this... wow an idea that's been kicking around a long > time since we introduced the well-known location in P3P. I'm not > involved in W3C stuff any more but lurk on some of these lists. It > occurs to me that if a lot of applications adopted this, it would be > useful to make one query to the .well-known directory to get a list > of all the files there so I don't have to play 20 questions with a > server to find out what it supports. Depending on how the server is > configured a query to http://example.com/.well-known/ might return > the list of files in that directory. It might be nice to actually > encourage that. The only downside I see is that it might make it > easier for an attacker to find out what you run and know what to > exploit, but without that the attacker could still play 20 questions > and find out. -- Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Tue Oct 13 18:43:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE7A3A6881 for ; Tue, 13 Oct 2009 18:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg90pqwJe6Uc for ; Tue, 13 Oct 2009 18:43:31 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 591DA3A6918 for ; Tue, 13 Oct 2009 18:43:21 -0700 (PDT) Received: (qmail 13745 invoked from network); 14 Oct 2009 01:43:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Oct 2009 01:43:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 13 Oct 2009 18:43:22 -0700 From: Eran Hammer-Lahav To: Mark Nottingham , =?iso-8859-1?Q?Alfred_H=CEnes?= Date: Tue, 13 Oct 2009 18:43:31 -0700 Subject: RE: draft-nottingham-site-meta-03 Thread-Topic: draft-nottingham-site-meta-03 Thread-Index: AcpMbQ7VdMiizubLSGS8KYK95tr6lQAAPK1Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784ECE4C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <200910130929.LAA22123@TR-Sys.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 01:43:31 -0000 > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Tuesday, October 13, 2009 6:24 PM > To: Alfred H=CEnes > Cc: Eran Hammer-Lahav; apps-discuss@ietf.org > Subject: Re: draft-nottingham-site-meta-03 >=20 > Hello, >=20 > Thanks for the feedback; responses below. >=20 > On 13/10/2009, at 8:29 PM, Alfred H=CEnes wrote: > > > > (1) Scope / Applicability > > > > Despite the motivation given in the Introduction, Appendix B.3 > > clarifies that the draft does not only target the 'http' and > > 'https' URI schemes, but Section 3 does not contain any indication > > regarding applicability. > > > > The proposal thus interferes with the specification of the majority > > of existing and in-progress URI scheme definitions, in particular > > those URI schemes that specify "actions" (like 'mailto', 'telnet', > > 'sip'/'sips', 'sms', 'go', etc.), are somehow transaction-oriented > > (like 'im', 'ipp', 'dict', 'mupdate', 'snmp', 'iris.*', 'aaa'/'aaas', > > 'msrp'/'msrps') or otherwise identify non-retrievable or even non- > > networked resources (like 'mid', cid', 'urn', 'doi', 'info', 'tel', > > 'fax'/'modem' [deprecated], 'tv'). > > Also, the protocols bound to many URI schemes do only allow the > > exchange of well-specified messages and not the retrieval of > > arbitrary media types, and as such are not amenable to the kind > > of information you have in mind for this proposal. > > > > Therefore, I would greatly appreciate if the scope of the proposal > > could be restricted and more clearly specified in the normative part > > of the draft. > > > > Here's a rough first attempt to capture what might be said better > > in the first paragraph of Section 3: > > > > OLD: > > > > | A well-known URI is a URI [RFC3986] whose path component begins > > with > > | the characters "/.well-known/". > > > > NEW: > > > > | A well-known URI is a URI [RFC3986] with a URI scheme that > supports > > | retrieval of generic network-based resources like the 'ftp', > > 'http', > > | or 'https' scheme, and whose path component begins with the > > | characters "/.well-known/". The specific syntax requirements of > > | the URI scheme used MUST admit this form and instance of a path > > | component. > > > > [[ The three example URI schems are given in alphabetical > > order. :-) ]] >=20 > The intent of "whose path component begins" was to have the effect of > restricting the URI schemes well-known is applicable, but a closer > reading of 3986 (and your comment, of course) shows that this isn't > the case. >=20 > I'd very much like to use language and concepts from 3986 if possible, > rather than minting yet another classification of URIs (even though > the one you suggest is intuitive and obvious). Would 'hierarchical > paths' serve this purpose well enough? I suspect it may not, but it's > worth consideration. This might not be needed if we limit to just a few schemes. But limiting to= schemes with an authority (per 3986) and a hierarchical path might also wo= rk. Are there examples where it doesn't? > > However, I would prefer a definite list of allowed URI schemes here. > > Any new URI scheme definition (or update to an existing definition) > > that wants to admit/support this mechanism would then have to state > > that precisely -- which would be very good for clarity. >=20 > This would probably be simpler. Eran, your thoughts -- would it be > enough to just specify for FTP, HTTP and HTTPS, allowing other schemes > to opt into it if they desire to? I don't have any use cases beyond HTTP and HTTPS and any registration for o= ne must also be applied to the other due to the way the two are often used = together. FTP seems reasonable but are there actual use cases for it? Not s= ure about others. Are there known cases of well-known locations used with s= chemes other than HTTP(S)? =20 > > Furthermore, following the spirit of B.3, I strongly suggest that, > > for clarity and precision, the registration template should include > > a specific, mandatory clause, "Applicable URI schemes:". >=20 > This gives me pause. Would someone be able to register "foo" for > protocol A, and someone else the same token for protocol B? Would they > have to update it for protocols that are added later? Won't the common > case be that registrations will want it to apply to all protocols > (indeed, will there be any other case)? If we end up with a limited set of applicable schemes, this might not be an= issue anymore. But given the wide namespace available within the well-know= n path, I would rather each protocol mint their own well-known prefix, even= if it is only used for a subset of the possible URI schemes. This seems to= be a safer approach, and if anything, will encourage better well-known pat= hs. =20 EHL From eran@hueniverse.com Tue Oct 13 18:53:46 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6EF3A691F for ; Tue, 13 Oct 2009 18:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.895, 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 QwVuUp+098Rq for ; Tue, 13 Oct 2009 18:53:45 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DD2DB3A686C for ; Tue, 13 Oct 2009 18:53:45 -0700 (PDT) Received: (qmail 19495 invoked from network); 14 Oct 2009 01:53:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Oct 2009 01:53:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 13 Oct 2009 18:53:46 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Tue, 13 Oct 2009 18:53:54 -0700 Subject: RE: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Thread-Topic: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Thread-Index: AcpMbU6Tg4Tqigj8RleKbaigohu6gAAAp0Fw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784ECE4CB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <92D713CF-28C5-4CCB-8803-A03CDCDED61B@cs.cmu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 01:53:46 -0000 I think it would be premature to define this before we have a few items in = the registry and see how it is used. It doesn't offer significant value (to= day) other than a small optimization for protocols looking for multiple wel= l-known documents. But if we find the registry popular and new applications make use of multip= le well-known documents, we can always just register a well-known document = to return the list such as: http://example.com/.well-known/content This has the advantage of being easier to deploy (returning a custom format= for a GET on a directory might be challenging in many environments) and re= place with better lists in the future (new well-known document). EHL > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Tuesday, October 13, 2009 6:26 PM > To: apps-discuss@ietf.org > Cc: Eran Hammer-Lahav > Subject: Fwd: Last Call: draft-nottingham-site-meta (Defining Well- > Known URIs) to Proposed Standard >=20 > Forwarded with permission. >=20 > Do people find this interesting? To specify it, we'd just need to > describe a format (e.g., a space-separated list of tokens). >=20 > Cheers, >=20 >=20 > Begin forwarded message: >=20 > > From: Lorrie Faith Cranor > > Date: 13 October 2009 12:03:24 AM AEDT > > To: Mark Nottingham > > Subject: Re: Last Call: draft-nottingham-site-meta (Defining Well- > > Known URIs) to Proposed Standard > > > > Hey Mark! > > > > I just saw this... wow an idea that's been kicking around a long > > time since we introduced the well-known location in P3P. I'm not > > involved in W3C stuff any more but lurk on some of these lists. It > > occurs to me that if a lot of applications adopted this, it would be > > useful to make one query to the .well-known directory to get a list > > of all the files there so I don't have to play 20 questions with a > > server to find out what it supports. Depending on how the server is > > configured a query to http://example.com/.well-known/ might return > > the list of files in that directory. It might be nice to actually > > encourage that. The only downside I see is that it might make it > > easier for an attacker to find out what you run and know what to > > exploit, but without that the attacker could still play 20 questions > > and find out. >=20 >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Oct 13 20:41:06 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04103A6951 for ; Tue, 13 Oct 2009 20:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=-0.962, 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 PnjgwJmgeBfP for ; Tue, 13 Oct 2009 20:41:03 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 7581B28C11F for ; Tue, 13 Oct 2009 20:41:03 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.5.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E6870509DB; Tue, 13 Oct 2009 23:41:02 -0400 (EDT) Subject: Re: draft-nottingham-site-meta-03 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784ECE4C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 14 Oct 2009 14:40:59 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5ABC2111-F261-460F-AE89-67BE866295E7@mnot.net> References: <200910130929.LAA22123@TR-Sys.de> <90C41DD21FB7C64BB94121FBBC2E72343784ECE4C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1076) Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 03:41:06 -0000 HTTP(S) works for me. On 14/10/2009, at 12:43 PM, Eran Hammer-Lahav wrote: > >> -----Original Message----- >> From: Mark Nottingham [mailto:mnot@mnot.net] >> Sent: Tuesday, October 13, 2009 6:24 PM >> To: Alfred H=CEnes >> Cc: Eran Hammer-Lahav; apps-discuss@ietf.org >> Subject: Re: draft-nottingham-site-meta-03 >> >> Hello, >> >> Thanks for the feedback; responses below. >> >> On 13/10/2009, at 8:29 PM, Alfred H=CEnes wrote: >>> >>> (1) Scope / Applicability >>> >>> Despite the motivation given in the Introduction, Appendix B.3 >>> clarifies that the draft does not only target the 'http' and >>> 'https' URI schemes, but Section 3 does not contain any indication >>> regarding applicability. >>> >>> The proposal thus interferes with the specification of the majority >>> of existing and in-progress URI scheme definitions, in particular >>> those URI schemes that specify "actions" (like 'mailto', 'telnet', >>> 'sip'/'sips', 'sms', 'go', etc.), are somehow transaction-oriented >>> (like 'im', 'ipp', 'dict', 'mupdate', 'snmp', 'iris.*', =20 >>> 'aaa'/'aaas', >>> 'msrp'/'msrps') or otherwise identify non-retrievable or even non- >>> networked resources (like 'mid', cid', 'urn', 'doi', 'info', 'tel', >>> 'fax'/'modem' [deprecated], 'tv'). >>> Also, the protocols bound to many URI schemes do only allow the >>> exchange of well-specified messages and not the retrieval of >>> arbitrary media types, and as such are not amenable to the kind >>> of information you have in mind for this proposal. >>> >>> Therefore, I would greatly appreciate if the scope of the proposal >>> could be restricted and more clearly specified in the normative part >>> of the draft. >>> >>> Here's a rough first attempt to capture what might be said better >>> in the first paragraph of Section 3: >>> >>> OLD: >>> >>> | A well-known URI is a URI [RFC3986] whose path component begins >>> with >>> | the characters "/.well-known/". >>> >>> NEW: >>> >>> | A well-known URI is a URI [RFC3986] with a URI scheme that >> supports >>> | retrieval of generic network-based resources like the 'ftp', >>> 'http', >>> | or 'https' scheme, and whose path component begins with the >>> | characters "/.well-known/". The specific syntax requirements of >>> | the URI scheme used MUST admit this form and instance of a path >>> | component. >>> >>> [[ The three example URI schems are given in alphabetical >>> order. :-) ]] >> >> The intent of "whose path component begins" was to have the effect of >> restricting the URI schemes well-known is applicable, but a closer >> reading of 3986 (and your comment, of course) shows that this isn't >> the case. >> >> I'd very much like to use language and concepts from 3986 if =20 >> possible, >> rather than minting yet another classification of URIs (even though >> the one you suggest is intuitive and obvious). Would 'hierarchical >> paths' serve this purpose well enough? I suspect it may not, but it's >> worth consideration. > > This might not be needed if we limit to just a few schemes. But =20 > limiting to schemes with an authority (per 3986) and a hierarchical =20= > path might also work. Are there examples where it doesn't? > >>> However, I would prefer a definite list of allowed URI schemes here. >>> Any new URI scheme definition (or update to an existing definition) >>> that wants to admit/support this mechanism would then have to state >>> that precisely -- which would be very good for clarity. >> >> This would probably be simpler. Eran, your thoughts -- would it be >> enough to just specify for FTP, HTTP and HTTPS, allowing other =20 >> schemes >> to opt into it if they desire to? > > I don't have any use cases beyond HTTP and HTTPS and any =20 > registration for one must also be applied to the other due to the =20 > way the two are often used together. FTP seems reasonable but are =20 > there actual use cases for it? Not sure about others. Are there =20 > known cases of well-known locations used with schemes other than HTTP=20= > (S)? > >>> Furthermore, following the spirit of B.3, I strongly suggest that, >>> for clarity and precision, the registration template should include >>> a specific, mandatory clause, "Applicable URI schemes:". >> >> This gives me pause. Would someone be able to register "foo" for >> protocol A, and someone else the same token for protocol B? Would =20 >> they >> have to update it for protocols that are added later? Won't the =20 >> common >> case be that registrations will want it to apply to all protocols >> (indeed, will there be any other case)? > > If we end up with a limited set of applicable schemes, this might =20 > not be an issue anymore. But given the wide namespace available =20 > within the well-known path, I would rather each protocol mint their =20= > own well-known prefix, even if it is only used for a subset of the =20 > possible URI schemes. This seems to be a safer approach, and if =20 > anything, will encourage better well-known paths. > > EHL > -- Mark Nottingham http://www.mnot.net/ From cfinss@dial.pipex.com Wed Oct 14 07:04:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BF128C103 for ; Wed, 14 Oct 2009 07:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.415 X-Spam-Level: X-Spam-Status: No, score=0.415 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_35=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 c7QRVakx2X3o for ; Wed, 14 Oct 2009 07:04:29 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 427553A68F4 for ; Wed, 14 Oct 2009 07:04:29 -0700 (PDT) X-Trace: 203313288/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.144/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.144 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEALd21Uo+vGmQ/2dsb2JhbACDJI1ZuGoHjzoKgigOgW4EixU X-IronPort-AV: E=Sophos;i="4.44,557,1249254000"; d="scan'208";a="203313288" X-IP-Direction: IN Received: from 1cust144.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.144]) by smtp.pipex.tiscali.co.uk with SMTP; 14 Oct 2009 15:04:28 +0100 Message-ID: <001501ca4cce$8b359900$0601a8c0@allison> From: "tom.petch" To: "Kurt Zeilenga" References: <4AC6786E.2020101@stpeter.im> <001b01ca46a4$017b0220$0601a8c0@allison> <75930B09-C7DD-46D6-A336-B1A80ADF7CDF@Isode.com> <000401ca476f$f93013e0$0601a8c0@allison> Subject: Re: client was Re: Server Identity Verification in Application Protocols Date: Wed, 14 Oct 2009 14:13:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 14:04:31 -0000 ----- Original Message ----- From: "Kurt Zeilenga" Sent: Thursday, October 08, 2009 8:30 AM > On Oct 7, 2009, at 4:09 PM, tom.petch wrote: > > > ---- Original Message ----- > > From: "Kurt Zeilenga" > > Sent: Wednesday, October 07, 2009 9:14 AM > > > >> On Oct 6, 2009, at 12:09 PM, tom.petch wrote: > >> > >>> This I-D is very hot on the fact that it is about Server Identity, > >>> yet > >>> technically, I see no reason why the logic does not also apply > >>> equally > >>> to client identity. > >>> > >>> In networking, with the networking box as server, and the client > >>> being the one that wants to change the configuration, then client > >>> identity is the one that matters, not server. > >>> > >>> I would like to add an initial paragraph to the effect that although > >>> the memo is written in terms of Server Identity, there is no > >>> technical reason why the processes described cannot be applied > >>> to verifying the Client Identity. > >> > >> I'm not sure this makes sense. The connection model assumed in this > >> document is that the user (directly or via configuration) specifies > >> the name of the server which than the client connects to, and this > >> document then specifies how to match the user specified name (or a > >> secure derivation of that name) to the subject of the certificate the > >> server provides. > >> > >> The technical reason why this cannot be applied to verifying the > >> client identity is that server's operator has not specified any name > >> to match up the subject in the client's certificate. Also, the > >> client certificate is likely to that associated with a human, not a > >> service. So the rules would differ significantly. > > > > I part company with you here. > > > > In the field of Operations and Management, then the (network) > > box is the server and is configured with the identifiers of those > > who may access it eg to update the configuration, so yes, the > > reference identity is pre-configured in the server. This may be > > an IP address, a host name, an e-mail address etc etc. > > > > The latest I-D includes a quote from the syslog RFC but omits > > the earlier statement in that RFC > > > > " Both syslog transport sender (TLS client) and syslog transport > > receiver (TLS server) MUST implement certificate-based > > authentication. " > > > > so without rules for the server to follow, this I-D would be of > > no use to syslog (and similar operational applications). > > I disagree. A syslog document can provide the text necessary to > describe how the process detailed in this I-D is applied to syslog. > It has to do this anyways. > > The only think this text makes explicit is that the process defined by > this I-D could be used for client identity verification. I don't see > any reason why this actually needs to be said. I worry that saying it > might lead to implementations using this process for client identity > verification without fully considering the implications. I rather > leave it to protocol specifications which make use of the verification > process for client identity verification to discuss the implications, > especially the security implications associated with one determines > which reference identity to use as input to a client identity > verification process. > > > I would (still) suggest adding to Section 1 > > > > "This memo is written in terms of a client authenticating the identity > > of a server. Where the server is configured with reference identities > > for clients, and the client certificate contains an identity of the > > types > > described in section 3.2, then this process MAY be used by a > > server to authenticate the identity of a client." > > How does the server determine which of the reference identities it has > been configured with ought to be the one used to verify the > certificate the client provided? > Why is a "configuration" approach needed? Maybe the application > protocol wants to just use the client IP address as the reference > identity, or use a DNS-based reverse lookup of the client IP address, > or some other approach. > > I think for the verification process defined by this I-D to be used > for client identity verification, there must be additional text > describing the process for determining which reference identity to use > as input to client identity verification process. There will be > security considerations specific to the process of determining the > reference identity input which ought to be discussed. My view of a server seems a little different, that is, a server is the end that supports multiple clients, so the server will have multiple valid values for security credentials, and the match can be with any of the security credentials that the server regards as valid. There is no way, in general, for a server to know which certificate to expect when it receives a particular TLS connection request (no equivalent of an SSH username) and that is ok because that is what a server does:-) I am not tied to the multiple reference identities being configured in the server - that is just the way I see it done. But I do see value in making it clear in this I-D that the steps described for matching a set of reference identities to a certificate are valid regardless of which end is doing it. Otherwise, every application trying to use this I-D for client authentication is likely to meet objections along the lines that this I-D does not cover the case. My focus is on OAM mostly (syslog, SNMP, netconf), but I note that SIP needs client authentication, XMPP describes its processes in terms of peer (not server) while the SMTP TLS RFC3207 notes that the server should authenticate the client (without giving any details - nowadays, given the amount of damage caused to the Internet by unauthenticated e-mail clients, I would expect such a specification to say much more). So, I see the checking of client certificates as a necessary function for us to cover. Tom Petch > > I see the determination process as being quite application protocol > specific. That is, what process syslog might want to use might well > be different from a process used in say XMPP server-to-server > communications. I think it best to leave all of client identity > verification, especially determination of the reference identity > input, to protocol specifications calling for the use of process > defined here for server identity verification for client identity > verification. > > -- Kurt > > > > > > > Tom Petch > > > >> Now, in certain "server to server" applications, the application > >> server which initiates the TLS connection is the TLS "client" under > >> this model and this document would seem to naturally apply. But this > >> document doesn't not seem to naturally apply for the application > >> server accepting the connection, the TLS "server", to verify the > >> identity of the TLS "client". While it certainly could apply with > >> some additional text, that text, I think would likely be application > >> protocol specific. > >> > >> In short, I rather no confuse this document by noting that an > >> application protocol could use this specification for "client > >> Identity" checking. Instead, I rather leave this as something > >> particular application protocols specifications could call for if and > >> when appropriate. I see nothing in the I-D which precludes an > >> application protocol specification from so doing. > >> > >> -- Kurt > >> > >>> > >>> Tom Petch > > > > > > _______________________________________________ > > Apps-Discuss mailing list > > Apps-Discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > From Kurt.Zeilenga@Isode.com Wed Oct 14 08:11:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4AAF28C183 for ; Wed, 14 Oct 2009 08:11:39 -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_35=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 rgU33v2AronF for ; Wed, 14 Oct 2009 08:11:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id F2ACE28C179 for ; Wed, 14 Oct 2009 08:11:37 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 14 Oct 2009 16:11:37 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: client was Re: Server Identity Verification in Application Protocols From: Kurt Zeilenga X-Priority: 3 In-Reply-To: <001501ca4cce$8b359900$0601a8c0@allison> Date: Wed, 14 Oct 2009 08:11:17 -0700 Message-Id: <05CEDCDF-97B5-41C0-9578-BA8030756312@Isode.com> References: <4AC6786E.2020101@stpeter.im> <001b01ca46a4$017b0220$0601a8c0@allison> <75930B09-C7DD-46D6-A336-B1A80ADF7CDF@Isode.com> <000401ca476f$f93013e0$0601a8c0@allison> <001501ca4cce$8b359900$0601a8c0@allison> To: "tom.petch" X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 15:11:40 -0000 On Oct 14, 2009, at 5:13 AM, tom.petch wrote: > ----- Original Message ----- > From: "Kurt Zeilenga" > Sent: Thursday, October 08, 2009 8:30 AM > >> On Oct 7, 2009, at 4:09 PM, tom.petch wrote: >> >>> ---- Original Message ----- >>> From: "Kurt Zeilenga" >>> Sent: Wednesday, October 07, 2009 9:14 AM >>> >>>> On Oct 6, 2009, at 12:09 PM, tom.petch wrote: >>>> >>>>> This I-D is very hot on the fact that it is about Server Identity, >>>>> yet >>>>> technically, I see no reason why the logic does not also apply >>>>> equally >>>>> to client identity. >>>>> >>>>> In networking, with the networking box as server, and the client >>>>> being the one that wants to change the configuration, then client >>>>> identity is the one that matters, not server. >>>>> >>>>> I would like to add an initial paragraph to the effect that >>>>> although >>>>> the memo is written in terms of Server Identity, there is no >>>>> technical reason why the processes described cannot be applied >>>>> to verifying the Client Identity. >>>> >>>> I'm not sure this makes sense. The connection model assumed in >>>> this >>>> document is that the user (directly or via configuration) specifies >>>> the name of the server which than the client connects to, and this >>>> document then specifies how to match the user specified name (or a >>>> secure derivation of that name) to the subject of the certificate >>>> the >>>> server provides. >>>> >>>> The technical reason why this cannot be applied to verifying the >>>> client identity is that server's operator has not specified any >>>> name >>>> to match up the subject in the client's certificate. Also, the >>>> client certificate is likely to that associated with a human, not a >>>> service. So the rules would differ significantly. >>> >>> I part company with you here. >>> >>> In the field of Operations and Management, then the (network) >>> box is the server and is configured with the identifiers of those >>> who may access it eg to update the configuration, so yes, the >>> reference identity is pre-configured in the server. This may be >>> an IP address, a host name, an e-mail address etc etc. >>> >>> The latest I-D includes a quote from the syslog RFC but omits >>> the earlier statement in that RFC >>> >>> " Both syslog transport sender (TLS client) and syslog transport >>> receiver (TLS server) MUST implement certificate-based >>> authentication. " >>> >>> so without rules for the server to follow, this I-D would be of >>> no use to syslog (and similar operational applications). >> >> I disagree. A syslog document can provide the text necessary to >> describe how the process detailed in this I-D is applied to syslog. >> It has to do this anyways. >> >> The only think this text makes explicit is that the process defined >> by >> this I-D could be used for client identity verification. I don't see >> any reason why this actually needs to be said. I worry that saying >> it >> might lead to implementations using this process for client identity >> verification without fully considering the implications. I rather >> leave it to protocol specifications which make use of the >> verification >> process for client identity verification to discuss the implications, >> especially the security implications associated with one determines >> which reference identity to use as input to a client identity >> verification process. >> >>> I would (still) suggest adding to Section 1 >>> >>> "This memo is written in terms of a client authenticating the >>> identity >>> of a server. Where the server is configured with reference >>> identities >>> for clients, and the client certificate contains an identity of the >>> types >>> described in section 3.2, then this process MAY be used by a >>> server to authenticate the identity of a client." >> >> How does the server determine which of the reference identities it >> has >> been configured with ought to be the one used to verify the >> certificate the client provided? >> Why is a "configuration" approach needed? Maybe the application >> protocol wants to just use the client IP address as the reference >> identity, or use a DNS-based reverse lookup of the client IP address, >> or some other approach. >> >> I think for the verification process defined by this I-D to be used >> for client identity verification, there must be additional text >> describing the process for determining which reference identity to >> use >> as input to client identity verification process. There will be >> security considerations specific to the process of determining the >> reference identity input which ought to be discussed. > > My view of a server seems a little different, that is, a server is the > end that supports multiple clients, so the server will have multiple > valid values for security credentials, and the match can be with > any of the security credentials that the server regards as valid. This sounds like normal TLS certificate verification, not client identity verification. > There is no way, in general, for a server to know which certificate > to expect when it receives a particular TLS connection request (no > equivalent > of an SSH username) and that is ok because that is what a server > does:-) > > I am not tied to the multiple reference identities being configured > in the server - that is just the way I see it done. How does the server select the client reference identity to verify from these multiple reference identities? > But I do see value > in making it clear in this I-D that the steps described for matching > a set of reference identities to a certificate are valid regardless of > which end is doing it. > Otherwise, every application trying to use > this I-D for client authentication is likely to meet objections along > the lines that this I-D does not cover the case. Well, it doesn't cover all of the problem. It doesn't discuss at all how a server would determine the reference identity to be checked. I would find it less objectionable for this I-D to simply say something like: "This document details a process for client verification of the server's identity. It is possibly that this process be used in server verification of a client's identity, however this document does not consider or detail how this might be done." > So, I see the checking of client certificates as a necessary function > for us to cover. > > Tom Petch > >> >> I see the determination process as being quite application protocol >> specific. That is, what process syslog might want to use might well >> be different from a process used in say XMPP server-to-server >> communications. I think it best to leave all of client identity >> verification, especially determination of the reference identity >> input, to protocol specifications calling for the use of process >> defined here for server identity verification for client identity >> verification. >> >> -- Kurt >> >> >> >>> >>> Tom Petch >>> >>>> Now, in certain "server to server" applications, the application >>>> server which initiates the TLS connection is the TLS "client" under >>>> this model and this document would seem to naturally apply. But >>>> this >>>> document doesn't not seem to naturally apply for the application >>>> server accepting the connection, the TLS "server", to verify the >>>> identity of the TLS "client". While it certainly could apply with >>>> some additional text, that text, I think would likely be >>>> application >>>> protocol specific. >>>> >>>> In short, I rather no confuse this document by noting that an >>>> application protocol could use this specification for "client >>>> Identity" checking. Instead, I rather leave this as something >>>> particular application protocols specifications could call for if >>>> and >>>> when appropriate. I see nothing in the I-D which precludes an >>>> application protocol specification from so doing. >>>> >>>> -- Kurt >>>> >>>>> >>>>> Tom Petch >>> >>> >>> _______________________________________________ >>> 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 A.Hoenes@TR-Sys.de Fri Oct 16 15:39:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94CC83A6405; Fri, 16 Oct 2009 15:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.269 X-Spam-Level: ** X-Spam-Status: No, score=2.269 tagged_above=-999 required=5 tests=[AWL=1.018, 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 kq6pyVWKaZh5; Fri, 16 Oct 2009 15:39:55 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 6E97A3A68C3; Fri, 16 Oct 2009 15:39:52 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA246312744; Sat, 17 Oct 2009 00:39:04 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA01756; Sat, 17 Oct 2009 00:38:54 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910162238.AAA01756@TR-Sys.de> Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02 To: lars.eggert@nokia.com Date: Sat, 17 Oct 2009 00:38:53 +0200 (MESZ) In-Reply-To: <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> from Lars Eggert at Oct "5, " 2009 "11:22:54" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: cheshire@apple.com, tsvwg@ietf.org, apps-discuss@ietf.org, port-srv-reg@ietf.org, draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, ah@WOTAN.TR-Sys.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: , X-List-Received-Date: Fri, 16 Oct 2009 22:39:57 -0000 Please find inline below detailed responses to the single feedback received so far for my review of draft-ietf-tsvwg-iana-ports-02, which contained a detailed critique of the incorporation of a registry for DNS SRV "service labels" (for dynamic service discovery), into the Port Number registry (for static port number assignments), as suggested by this draft. For those looking for an 'executive summary' - here it is: draft-gudmundsson-dns-srv-iana-registry-03 has proposed a distinct registry for DNS SRV Service Prefixes, the need for which apparently had been overlooked in RFC 2782 (the specification of the DNS SRV resource records). That registry is tailored for the needs of applications/services making use of any "transport" or "substrate" protocols (like HTTP) and use domain/server specific port numbers assigned under local authority (or dynamically) for the underlying transport, and which utilize DNS SRV based dynamic service discovery by the clients, or the SRV based "DNS database" of the Dynamic Delegation Discovery System (DDDS). That proposal is based on feedback and requests from application protocol designers which have a broader view of underlying protocols for their applications than the narrow "IETF Transport Protocol with an IANA assigned Protocol number" focus of the Port Numbers registry, which otherwise fulfills the needs for applications/services using the IETF Transport protocols (TCP, UDP, SCTP, DCCP) and fixed, globally uniwu, IANA-assigned server port numbers. draft-ietf-tsvwg-iana-ports has been extended in the -02 version to reclaim authority for the registration of many Service labels in the Port Numbers registry, which is incompatibel with the design of the former proposal and the differing requirements. At Mon, 5 Oct 2009 11:22:54 +0300, Lars Eggert wrote: > In-Reply-To: <200909291410.QAA19651@TR-Sys.de> > Message-Id: <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> > Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02 > > Hi, > > On 2009-9-29, at 17:10, ah@tr-sys.de wrote: >> I have followed up and studied the revised Port Number registry >> draft, draft-ietf-tsvwg-iana-ports-02. > > thank you! We've been waiting for community feedback. I apologize for the delay in responding, but in part I expected more discussion -- which didn't happen so far -- and wanted to sum up subsequently. > >> (A.1) Intended expansion of the Port# registry to Service Names >> >> The -02 draft revision has proposed to expand the Port Number >> registry to also cover "Service Names" -- independent of the >> assignment of port numbers to applications/services. >> >> There are lots of reasons to not do that in the proposed form. >> >> After discussions with driving forces from the Applications Area, >> draft-gudmundsson-dns-srv-iana-registry-03.txt has reinforced and >> reconciled the proposal for a dedicated Service Prefix registry. >> Please refer to that draft for distinguishing details. > > I'm sorry, but I see little argumentation in draft-gudmunsson on why a > separate registry is preferable. Yes, the IANA rules for port numbers > should be stricter than for service names, but that does *not* mean > that a separate registry is needed - it just means that the rules > should be different. Well, most part of draft-gudmunsson-dns-srv-iana-registry-02 have been written almost one year ago. It was out of reach of my influence that the -02 did not happen to get posted before, or at least around IETF 73, but only before IETF 75. Those days it could not be envisioned that draft-tsvwg-iana-ports would be expanded in the way it has been done now. Our -03 is only a fix-up of items that should have been fixed for the -02, but couldn't because I've been offline for a substantial time period. If you prefer, we can include a lot of rationale in the next revision of our draft, but, because you didn't either explain the reasons to expand the scope of your draft therein as well, we preferred to carry out the discussion 'out-of-band' of our draft. > > The main reason to have one registry is to make it easy for IANA and > applicants to figure out which names are registered and which aren't. I don't see a major hurdle there. `grep`ing 2 files isn't more complicated than `grep`ing a single. But would a protocol designers specifying service discovery for their application/service understand that they had to register their service prefix in the Port Number registry, although they do not want to apply for an assigned port at all? We have provisioned a leightweight procedure to ensure that collisions between the traditional, length-restricted service names and (potentially longer) SRV service labels will not occur. >> Here are the primary aspects that come to mind regarding the nature >> and implementation of registration services for Port Numbers and >> Service Prefixes: >> >> (a) Since there is an established and IETF-documented practice >> for the use of "overlay" / "substrate" SRV Protocol labels, >> Service Labels making use of these should be registered >> in a similar manner as others containing proper "transport" >> Protocols, under the same procedural rules. The database >> proposed in draft-tsvwg-iana-ports-02 is neither prepared to, >> nor suitable for, also accepting the registration of such >> Service Prefixes not related to IETF transport protocols. > > Why do you think that? The unified registry contains service names, > and is fully agnostic on what protocols those service names are used > with. That's one part of the problem. The Port Number registry deals with transport protocols that have port numbers as demultiplexing selectors, and only with these. In a similar way as IPSEC had (and still has) to discover that other kinds of selectors exist in other protocols and need to be supported, existing IETF standards have created a variety of SRV service prefixes that are not bound to the four transport protocols supported by the Port Number registry (TCP, UDP[-Lite], DCCP, and SCTP), for instance: _pkixrep._ldap _pres._sip _mip6._ipv6 The Protocol labels are significant there. You'll never have things like _telnet._sip ! But there are: _pkirep._ocsp _pres._xmpp The essential point is that service discovery is always bound to specific service/protocol combinations, and only those that are actually specified should be listed in a service prefix registry. It makes no sense from an application PoV to be "fully agnostic" on what protocol is going to be used with a particular service. > >> (b) Most legacy applications with registered port numbers are >> not prepared to use SRV RRs (yet); it does not make sense >> to proactively register myriads of labels without having >> any documentation on the use of service discovery for that >> service, and without consent and knowledge of the original >> applicants for port number assignment. > > Those labels are *already* registered, in the "keyword" column in the > current IANA ports registry, and we don't know which ones are used and > which ones aren't. Which is why we're keeping them defined as they > currently are (modulo some renaming in very few cases.) The renaming effort has our full support. It does not touch in any way the model of the Service Prefix registry because the initial content of that registry (as picked up by harvesting RFCs) is already 'clean' in their namespace usage and entirely unaffected by this step. However, most service _names_ currently registered in the Port Numbers registry have limited use. Those names (originating from the /etc/services file on POSIX systems) actually in somehow widespread used are those for the most well-known services, which traditionally have been bound to registered port numbers and will -- in their majority -- not have service discovery specified or in use, or have it being specified and used in the future. The majority of the service names are registered with ports for applications with limited deployment, and these service names most likely will not be listed in the majority of /etc/services files in the wild, because their presence would only slow down the lookup -- only locally deployed services are getting added in practice, and only when these applications are indeed bound to fixed (configured) port numbers and their users are not expected to perform dynamic service discovery, e.g. via DNS SRV RRs. As you can see from our draft, the SRV service prefix registry is designed for a peaceful coexistence with the Port Numbers registry, and is expected to grow up becoming mostly complementary to it; registrations are based on specifications of service discovery for an application/service, not on the specification of a 'basic', perhaps transport-agnostic, application protocol, which in turn would be the likely reference to be entered into the Port Number registry in case a dedicated port number were needed. Existing (and future) registrations in the Port Number registry are encouraged to be amended by a registration in the Service Prefix registry, if and when service discovery is specified for that application/service, but it is expected (based on feedback from vendors) that future Service Label registrations will more and more not be accompanied by Port Number assignment requests. You share the expectation of, and in fact also want to encourage, more widespread use of service discovery in the future. According to the principle of least surprise, application designers should not be confused by having to register in a Port Number registry in such case, even when it is renamed in "Port Numbers and ...". > >> (c) For compatibility with existing databases and APIs, >> draft-tsvwg-iana-ports-02 essentially maintains the >> 'classical' size restrictions for Service Names. >> >> APIs for (dynamic) service discovery will easily admit the use >> of the common 63-character size for DNS labels (as established >> by RFCs 1034/1035), for SRV Service labels as well. >> >> Applications making use of (dynamic) service discovery based >> on DNS SRV have to be written to use such API, and if existing >> applications previously bound to an assigned port number are >> being upgraded to use service discovery, they need to be >> modified to use such API anyway. >> >> Therefore, it makes sense to leave existing databases and APIs >> for Service-Name-to-Port-Number lookup unchanged. > > I don't follow. Yes, we want to leave APIs and databases unchanged, > which is why we're keeping the current size restriction. The main characteristic of (dynamic) service discovery is that it takes into account the destination (domain) as an input parameter as well. In contrast, the "service-to-port resolution" using service names is destination-independent, which is reflected in the traditional APIs for "service [name] to port number" resolution. High level APIs for service discovery are not yet standardized, AFAICT, but their interfaces will be different from those for the simple name-to-port resolution. The design of the Service Prefix registry accommodates the desire of application designers to use verbose, in part hierarchically structured service labels, which can quickly outgrow the traditional limits. > >> (d) The imminent exhaustion of the port number space is recognized as >> a reason to encourage the migration to service discovery for new >> applications; draft-tsvwg-iana-ports-02 also acknowledges that. > > There is no danger of "imminent exhaustion" and if our draft leads you > to believe that there is, we need to change it. System ports are > somewhat scarce, but even there we have sufficient space left to last > for years. Admittedly, the time scale can vary, but the available unassigned port number namesspace is decreasing steadily. Since reclaiming procedures are new and still will have to prove their efficacy, from a mathematical point of view, it's almost inevitable that the remaining namespace will become scarce. I did not attempt to forecast when, but absent incentives for not using assigned port numbers for new applications/services, this will inevitably happen within the expected lifetime of the current Internet technology. I have archived a few snapshots of the port-numbers file over time, and a rough extrapolation of their line counts indicates that this will perhaps take much less time. > >> However, we believe that the procedures envisioned in that draft >> are much too heavy-weight -- and too burdensome for IANA as >> well -- for exerting a strong momentum towards service labels. > > First, let me point out that Michelle is co-authoring the draft > *because* we want to make sure that these rules are easier for IANA > to apply than what currently exists. Admitted and appreciated. > Second, the purpose isn't to do an advertisement campaign that creates > a strong momentum for service names - the purpose is to come up with > clear and simple registry maintenance rules. If as a secondary effect > that means that service names become more widely used, great, but > that's not a primary driver for this draft. But then it seems illogical to reclaim authority over the entire namespace needed for service discovery as well. Keeping both registries visibly separated, but interrelated by the collision-avoidance rule seems more registrant-friendly and even better manageable for IANA. > >> The compound database needed for draft-tsvwg-iana-ports-02 and >> the Expert Review process inadequately address the needs -- of >> both the prospective applicants and the registry maintainers. > > The intent is that no expert review is involved for a service name > allocation. Expert review only happens for a port number allocation, > like it does currently. Under the new rules, a service name can be > allocated FCFS without expert review. > > (I just realized that -02 does actually not yet contain this - we need > to submit -03.) You will admit that I would have had difficulties reasoning about a not-yet-written draft version. :-) > >> (e) The Port Numbers registry and the SRV Service Prefix registry >> serve very different purposes: >> i) registration of and lookup of assigned port numbers >> ii) registration of Service Prefixes actually defined for >> service discovery. > > (ii) is *your* interpretation. In my reading, the SRV RR RFC makes it > clear that any service name allocated in the ports registry should be > usable with SRV RRs. I hope you admit that we manage the interpretation of our own targets. :-) 'Usable' does not mean that use is specified, and experience has shown that this has to be done carefully. Anyway, a lot of RFCs have assumed the existence of a distinct registry for Service Prefixes and tried to register there explicitly. Our proposed Service Prefix registry for that RFC does not preclude basing Service Labels on service names from the Port Number registry; actually, it *reserves* all service names listed there, with and without a prepended underscore character, as candidates for Service Label registrations with some Protocol Labels, for just that service that originally obtained the related assigned port number. The gap to be closed by registrants is the documentation for the use of service discovery with that application/service, and it's *that* specification that will be listed in the Service Prefix registry entries. Currently there are almost a dozen I-Ds on the table (anywhere between initial individual draft and RFC Editor queue) that discuss the use of service discovery via SRV RRs for specific applications / services, and this is really needed to obtain interoperable functionality, in particular when NAPTR RRs and/or other mechanisms are used jointly with the SRV RRs. In particular there's a need for guidance from an operational and management PoV. E.g., DNS Zone administrators will need to be convinced of the utility of the new RRs they are asked to host, and they will want to be presented with an analysis of the expected operational impact. Blindly putting lots of SRV RRs in various zones does not make sense. > >> Due to the vastly different size of the available namespace, >> both registries need different assignment/registration policies. > > True. But that does *not* mean that we need two registries. It just > means that we need two sets of procedures. But having entries with different syntax, different restrictions, and so much different procedures and IANA policy in a single registry is very unusual (at best), and most likely simply confusing. >> For the Service Prefixes (with the exception of the establishment >> of new Protocol Labels), an extremely lightweight procedure is >> needed where the role of the IANA is confined to checking >> uniqueness (avoiding registry-internal collisions and collisions >> of new Service Labels with Service Names already registered in >> the Port Numbers registry for other services > > Correct. The intent is FCFS. As above. I couldn't comment on unpublished intent. > >> The Port Number registry is heavily constrained by the 16-bit >> namespace available, with the additional pressure resulting >> from the security critical need for client port randomization >> to only assign as few as possible additional port numbers. > > Randomization doesn't come into play here, because it's used for the > source ports, whereas the registry is for destination ports. I'll exclude this topic; it as been discussed on the list already. > >> It is the basic nature of such restricted namespace that the >> IANA registry for it needs to be under *assignment* paradigm. >> The port number registry should be regarded as "almost closed" >> (reserved for cases where service discovery is impossible), >> and it needs rigid and tight management and strict IANA policy. > > No, this is MUCH to restrictive. We're NOT trying to make it harder > to get a port number than it is currently. Port numbers remain the > primary service identification method in the Internet. And yes, I This point of view apparently is not shared by all. For instance, IP address sharing as a component of a v6 transition path, is incompatible with such strategy. Since this is not the main point here, I simply would like to point out that apparently many folks would appreciate a decided pressure to shift that fixed-port-number-centric paradigm and would prefer to thus reduce the semantical overloading of port numbers, serving as (de-)multiplexing selectors and questionable service identifiers at once (there's no Internet police to enforce port number use), in order to reduce, in the long term, their role to a single purpose, namely serving as transport (de-)multiplexing selectors, which is their sole role already on the client side of client-server applications. > agree that SRV RRs should be something that should be used more often. +1 > But making it harder to get port numbers only means more squatting. It should serve as an incentive for application protocol designers to spend more thoughts on the intrinsic support of service discovery, to ensure interoperable implementations and manageable deployment of their appplications in the presence of emerging obstacles to fixed port number usage. This strategy should actually in fact off-load IANA and Review Experts. > SRV RRs need to become attractive based on their own merits, and not > because port number are hard to get. Slope (and the resulting moment) is the result of the difference in altitude between two points. > >> Merging such different registries appears as a nightmare for IANA >> and prospective applicants, and all 'consumers' of the registry. >> The complicated amalgamated specification needed for the IANA >> procedures for such registry is contrary to the principles of >> clarity and simplicity. > > FUD. IANA seems to like our proposal. For port number registrants, Well, I assume that the requirements a Service Prefix registry needs to fulfill have not been explained and discussed before in depth, and the deficiencies of the model had not been exposed yet. So I hope that after looking at the arguments, a re-evaluation will be granted. > nothing changes much (except that the rules are now documented.) We never intended to interfere with the details. > For service name registrants, nothing changes much. No. Many kinds of Service Prefixes could not be registered with that registry as laid out in tsvwg-iana-ports-02, as detailed above. (Where to enter hypothetical prefixes like _xzzzyx._https , _foobar._scvp , and _abc123._xmpp ? ) The most important information - actual support of service discovery by the application, and where it is documented, would be lacking. Having columns in the single table only to be filled in for certain kinds of registrations and other columns to be filled in only by other registrations isn't a clear and simple model, and makes processing rules unnecessarily complicated. > >> (f) The management of a narrow/scarce namespace (port numbers) >> should not be conflated with the management of an ample >> namespace; hence the need to have two independent registries, >> with existing service names in the Port Numbers registry >> implicitly reserved for use as Service Labels as well >> (for all Protocols) for the same application. > > See above, you repeated this point for the third time now. The emphasis has been different aspects: - IANA assignment of code points (port#) vs. mere registration of Service Labels / Prefixes; - mandatory service name (for name-to-port resolution) does not imply application support of service discovery (both client-side and from a provisioning PoV on the server side); - management aspects of IANA procedures; - presentation of the registries; - clarity for applicants; >> (g) New applications/services initially registering a SRV Service >> Prefix but not applying for the assignment of a dedicated >> port number are very unlikely to do that later. > > Maybe yes, maybe no. In our scheme, it's possible, which is nice > because it leaves the option. The collision avoidance procedures we propose aim at ensuring that this rare case remains an option as well. > > I'm skipping your editorial comments for now. Granted. > > Thanks, > Lars Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From touch@ISI.EDU Sun Oct 18 18:14:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27C23A67E2; Sun, 18 Oct 2009 18:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS8q-XZBlTKA; Sun, 18 Oct 2009 18:14:25 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id D37113A62C1; Sun, 18 Oct 2009 18:14:22 -0700 (PDT) Received: from [172.40.40.57] (rrcs-208-125-251-170.nys.biz.rr.com [208.125.251.170]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n9J1DRPU027086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Oct 2009 18:13:36 -0700 (PDT) Message-ID: <4ADBBD35.2090603@isi.edu> Date: Sun, 18 Oct 2009 18:13:25 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> In-Reply-To: <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n9J1DRPU027086 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Mon, 19 Oct 2009 08:05:45 -0700 Cc: "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 01:14:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: ... >...Which means that the more ports you allocate, the fewer ports > you are assured you can use for the ephemeral ports without the > security implications described in Section 10.2 of the CPNI document. The ephemeral port range is not affected by allocations in the non-ephemeral range. The issue above would occur only if the current non-ephemeral range were exhausted and we moved the boundary between the two to allow for more allocations. As Lars noted, we're in no danger of running out of ports. I presented a summary in TSVWG in IETF 73. We've been linear in allocations/year (around 400) from 2001 through 2008 (when I made that chart). At that rate, we have at least 85 years to go... 49152 - 1024 (omit all the system ports) - 5500 (remove allocations through 2008, rounded up a hundred) / 500/yr (20% more than we have been for the last 8) = 85 years. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrbvTUACgkQE5f5cImnZrsWrQCfSWsKu3btten8foipbi500zk1 YmIAnjPyxzrTFnZMFesti5GCJ8Pqn5rd =cEGy -----END PGP SIGNATURE----- From touch@ISI.EDU Sun Oct 18 18:16:13 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624B53A6811; Sun, 18 Oct 2009 18:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 YYITRmhdPrfI; Sun, 18 Oct 2009 18:16:12 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id B19783A62C1; Sun, 18 Oct 2009 18:16:12 -0700 (PDT) Received: from [172.40.40.57] (rrcs-208-125-251-170.nys.biz.rr.com [208.125.251.170]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n9J1FMKi027335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Oct 2009 18:15:27 -0700 (PDT) Message-ID: <4ADBBDA9.3090102@isi.edu> Date: Sun, 18 Oct 2009 18:15:21 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> <4ACA69C5.1060802@gont.com.ar> In-Reply-To: <4ACA69C5.1060802@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n9J1FMKi027335 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Mon, 19 Oct 2009 08:05:45 -0700 Cc: "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 01:16:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: ... > I wrote the patch to expand the ephemeral port number range in FreeBSD, > and the reason for which FreeBSD's ephemeral port range ended up being > 10000-65535 (rather than 1024-65535) was to avoid using those port > numbers used for X, http-proxy, etc. (This was a quick hack... a more > clean approach is described in draft-ietf-tsvwg-port-randomization). -- > OpenBSD does implement that approach. That technique doesn't expand the ephemeral range. It uses the reserved range as ephemeral, which will cause problems when ports in that range are allocated and you're already running a service on it. It's not clean at all, and should be avoided, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrbvakACgkQE5f5cImnZrtWJACdH//N8618FVm8jzCOsuxtS70u 28wAoKOpIiUDZoFFt+mJz28Jhk1QyB2F =SCmB -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Mon Oct 19 00:12:44 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA8128C0DF; Mon, 19 Oct 2009 00:12:44 -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 CRLezwoYpoUT; Mon, 19 Oct 2009 00:12:43 -0700 (PDT) Received: from mail-yw0-f136.google.com (mail-yw0-f136.google.com [209.85.211.136]) by core3.amsl.com (Postfix) with ESMTP id 8355828C0D0; Mon, 19 Oct 2009 00:12:43 -0700 (PDT) Received: by ywh42 with SMTP id 42so100714ywh.29 for ; Mon, 19 Oct 2009 00:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Sztln5CRgydr/BkFU4SCk9bbV3js2114iwbrC2t1GNI=; b=w8JXwRkOgV+szJaD+8hLiSq9sh9Z4/Nj9KTdDKWQgo+QMkEkcXK1vO5V4lznpDRbRB 2y8hgPkBAE+flUZgT+qAhj7v/fQ6g+D1gYI0y9hadaDnUggkRf7pZ6d5OxgI6/UrP+pt SoKz6RM/QTqxMFCDhfNkBID3U2ByY1Rm9qPfw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=Y4Hzla9I8UUAfdkQE0WZJLm8uU0Z1+sVmwWzphsu5H2rltbZmXeEN3uQjnTFVbN0vs DWm2IM70/vrbtT21wcpuVFtpkAnjyA4Tgvjf1KKLsi6q5bnYL91bP9AtRGycIZgFFZe1 6ikoS96PTQEMOmh9BBTw2X7YZnN6bAlTz7DuQ= Received: by 10.150.112.5 with SMTP id k5mr7398737ybc.348.1255936366052; Mon, 19 Oct 2009 00:12:46 -0700 (PDT) Received: from ?192.168.0.151? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 22sm2622472ywh.12.2009.10.19.00.12.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Oct 2009 00:12:44 -0700 (PDT) Sender: Fernando Gont Message-ID: <4ADC1165.6090207@gont.com.ar> Date: Mon, 19 Oct 2009 05:12:37 -0200 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch Subject: Re: [tsvwg] [port-srv-reg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> <4ACA69C5.1060802@gont.com.ar> <4ADBBDA9.3090102@isi.edu> In-Reply-To: <4ADBBDA9.3090102@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Oct 2009 08:05:45 -0700 Cc: "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 07:12:44 -0000 Joe Touch wrote: >> I wrote the patch to expand the ephemeral port number range in FreeBSD, >> and the reason for which FreeBSD's ephemeral port range ended up being >> 10000-65535 (rather than 1024-65535) was to avoid using those port >> numbers used for X, http-proxy, etc. (This was a quick hack... a more >> clean approach is described in draft-ietf-tsvwg-port-randomization). -- >> OpenBSD does implement that approach. > > That technique doesn't expand the ephemeral range. It uses the reserved > range as ephemeral, Did you mean "registered"? > which will cause problems when ports in that range > are allocated and you're already running a service on it. > > It's not clean at all, and should be avoided, IMO. Is this one of those "let's ignore the facts" speeches? The very same Windows box you're using probably uses the range 1024-4999 for the ephemeral ports. See the survey in the port-randomization I-D. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Mon Oct 19 01:59:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A92C3A68C4; Mon, 19 Oct 2009 01:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 3F6wRzV2QVkR; Mon, 19 Oct 2009 01:59:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 59DDD3A6783; Mon, 19 Oct 2009 01:59:27 -0700 (PDT) Received: from [172.40.40.57] (rrcs-208-125-251-170.nys.biz.rr.com [208.125.251.170]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n9J8wSiZ017999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Oct 2009 01:58:32 -0700 (PDT) Message-ID: <4ADC2A34.4000602@isi.edu> Date: Mon, 19 Oct 2009 01:58:28 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tsvwg] [port-srv-reg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> <4ACA69C5.1060802@gont.com.ar> <4ADBBDA9.3090102@isi.edu> <4ADC1165.6090207@gont.com.ar> In-Reply-To: <4ADC1165.6090207@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Mon, 19 Oct 2009 08:05:45 -0700 Cc: "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 08:59:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> I wrote the patch to expand the ephemeral port number range in FreeBSD, >>> and the reason for which FreeBSD's ephemeral port range ended up being >>> 10000-65535 (rather than 1024-65535) was to avoid using those port >>> numbers used for X, http-proxy, etc. (This was a quick hack... a more >>> clean approach is described in draft-ietf-tsvwg-port-randomization). -- >>> OpenBSD does implement that approach. >> That technique doesn't expand the ephemeral range. It uses the reserved >> range as ephemeral, > > Did you mean "registered"? Yes. >> which will cause problems when ports in that range >> are allocated and you're already running a service on it. >> >> It's not clean at all, and should be avoided, IMO. > > Is this one of those "let's ignore the facts" speeches? It's "let's fix the end with the bug, rather than create a new bug to be dealt with later" speech. > The very same Windows box you're using probably uses the range 1024-4999 > for the ephemeral ports. That would be a bug. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrcKjMACgkQE5f5cImnZrvj2ACfc8pij3la3pHNXEFb2HNI0yfp 5PIAoIU90pP/x+cxigSKg5NPiEwbyfl0 =S4X+ -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Mon Oct 19 03:26:33 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0C03A691D; Mon, 19 Oct 2009 03:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI8dR5Rkpikv; Mon, 19 Oct 2009 03:26:32 -0700 (PDT) Received: from mail-gx0-f179.google.com (mail-gx0-f179.google.com [209.85.217.179]) by core3.amsl.com (Postfix) with ESMTP id 6A6CB3A67AC; Mon, 19 Oct 2009 03:26:32 -0700 (PDT) Received: by gxk27 with SMTP id 27so156087gxk.9 for ; Mon, 19 Oct 2009 03:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=10oNzhg/FHWUhJ7a6cil/OeaUbMUZuiP5p0egmHlOgQ=; b=u8iStE/sc00m0ZoSRNXjac+TvDMaKj5Itnsx98mkFvH2wh2D8DMZyxsIboBUazVm6G hZSgJf7IdLob+SQjY/zzkhLTFde+NXO3Gzn3i+GGeBCVJWJMw3Wb/3oSrEvO/HI6B1TA FjyZPdNVZf+DXrCttW6WshVxfyp2g0wkqPmcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=NlfXSGszYYESQJHB8begxJ6co2wH5aH9cxr3ru+TBn5TXJVFndEe/tdpiqr4nl87DN dc5+prjjJLD0IIzTix0yjwmkTk/3VZ5vwAQo0jbQPBfzeC2RYqTaWruSzy2DQnaibIXR An6QojREdcrw8BrEOKVssrFlOMHwNX21C2BSE= Received: by 10.150.16.14 with SMTP id 14mr7745265ybp.246.1255947993996; Mon, 19 Oct 2009 03:26:33 -0700 (PDT) Received: from ?192.168.0.151? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 21sm2698125ywh.9.2009.10.19.03.26.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Oct 2009 03:26:33 -0700 (PDT) Sender: Fernando Gont Message-ID: <4ADC3ED2.3040708@gont.com.ar> Date: Mon, 19 Oct 2009 08:26:26 -0200 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch Subject: Re: [tsvwg] [port-srv-reg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> <4ACA69C5.1060802@gont.com.ar> <4ADBBDA9.3090102@isi.edu> <4ADC1165.6090207@gont.com.ar> <4ADC2A34.4000602@isi.edu> In-Reply-To: <4ADC2A34.4000602@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Oct 2009 08:05:45 -0700 Cc: "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 10:26:33 -0000 Joe Touch wrote: >>> which will cause problems when ports in that range >>> are allocated and you're already running a service on it. >>> >>> It's not clean at all, and should be avoided, IMO. >> Is this one of those "let's ignore the facts" speeches? > > It's "let's fix the end with the bug, rather than create a new bug to be > dealt with later" speech. I'd argue that for client systems, reducing the port number space used for outgoing connections (i.e. ~64K vs ~15K) is more likely to introduce problems. Also, in retrospective, with the "registered ports" thing you're wasting most of the port number space when you will probably use... what? a maximum of 10 or 20 ports of those 50K ports? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Mon Oct 19 03:35:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04AA28C14E; Mon, 19 Oct 2009 03:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 Qpk0uwhreYCH; Mon, 19 Oct 2009 03:35:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 25C4B3A691F; Mon, 19 Oct 2009 03:35:27 -0700 (PDT) Received: from [172.40.40.57] (rrcs-208-125-251-170.nys.biz.rr.com [208.125.251.170]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n9JAXk9i010308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Oct 2009 03:33:56 -0700 (PDT) Message-ID: <4ADC4089.6070404@isi.edu> Date: Mon, 19 Oct 2009 03:33:45 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tsvwg] [port-srv-reg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> <4ACA69C5.1060802@gont.com.ar> <4ADBBDA9.3090102@isi.edu> <4ADC1165.6090207@gont.com.ar> <4ADC2A34.4000602@isi.edu> <4ADC3ED2.3040708@gont.com.ar> In-Reply-To: <4ADC3ED2.3040708@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Mon, 19 Oct 2009 08:05:45 -0700 Cc: "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 10:35:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>>> which will cause problems when ports in that range >>>> are allocated and you're already running a service on it. >>>> >>>> It's not clean at all, and should be avoided, IMO. >>> Is this one of those "let's ignore the facts" speeches? >> It's "let's fix the end with the bug, rather than create a new bug to be >> dealt with later" speech. > > I'd argue that for client systems, reducing the port number space used > for outgoing connections (i.e. ~64K vs ~15K) is more likely to introduce > problems. It'd be useful to consider whether there are actually 15K connections and thus a real problem, or whether the hosts are incompletely implementing port reuse checks that prevent a port from being used for different IP addresses simultaneously. I.e., what's the greater impact 1/4 of the total space, or false positives due to implementation issues? > Also, in retrospective, with the "registered ports" thing you're wasting > most of the port number space when you will probably use... what? a > maximum of 10 or 20 ports of those 50K ports? And only 6,000 of those 50K are even assigned. Again, though, making the space even 4x larger has only a 4x impact on current issues - that's not all that much, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrcQIkACgkQE5f5cImnZruw2QCfQyiYdP7C5rKZAiSNlJUvvarO WyAAoKfHn9CZWWV00ld9cpVpvogZGqNZ =ajEx -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Mon Oct 19 03:53:07 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C503A67AC; Mon, 19 Oct 2009 03:53:07 -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 MD02cDPSRdWP; Mon, 19 Oct 2009 03:53:07 -0700 (PDT) Received: from mail-yw0-f136.google.com (mail-yw0-f136.google.com [209.85.211.136]) by core3.amsl.com (Postfix) with ESMTP id C2DE73A67E9; Mon, 19 Oct 2009 03:53:06 -0700 (PDT) Received: by ywh42 with SMTP id 42so105586ywh.29 for ; Mon, 19 Oct 2009 03:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=FJrXjubVHlWyZ7uGCy1/sJGL37K2dFPbSXXyuzPhVms=; b=NQN+c1N7jcuo1HUWMVXtO7ewdZH+T2vbh1rVNcdNQRCXCMiCaRGaavxCnSlYLVVs0A B2Q0FHGNI7jI8lSahri7L7F9T4uOEDLSkbKEqvJcrCXeCJbBrCmaYV0D3wLBuxgtJoaG ikDnDutXwK4BYjIxkmqy/+BHaMNeqDgzZ3rlw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=KaBG/tYVpu6xaXwKP+XOdf53UEgkPDvh1uG5fj7gxqchQZA2yUT6ws26IHA5zlbyfS X5X+4+VppbFaj3WObHIirEgqsUJUI7y0Mc0x+nBRAYwBi69AGmt6waowO7UmF0bC4ItD YbdXjRwOMA3do817sgBi3ki1w5pC+CnI3vVMw= Received: by 10.150.127.36 with SMTP id z36mr7757921ybc.326.1255949590031; Mon, 19 Oct 2009 03:53:10 -0700 (PDT) Received: from ?192.168.0.151? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 20sm2722427ywh.6.2009.10.19.03.53.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Oct 2009 03:53:09 -0700 (PDT) Sender: Fernando Gont Message-ID: <4ADC450F.6030302@gont.com.ar> Date: Mon, 19 Oct 2009 08:53:03 -0200 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch Subject: Re: [tsvwg] [port-srv-reg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> <4ACA69C5.1060802@gont.com.ar> <4ADBBDA9.3090102@isi.edu> <4ADC1165.6090207@gont.com.ar> <4ADC2A34.4000602@isi.edu> <4ADC3ED2.3040708@gont.com.ar> <4ADC4089.6070404@isi.edu> In-Reply-To: <4ADC4089.6070404@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Oct 2009 08:05:45 -0700 Cc: "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 10:53:07 -0000 Joe Touch wrote: > It'd be useful to consider whether there are actually 15K connections > and thus a real problem, file sharing (p2p) applications tend to create lots of connections. Although I wouldn't go as far as 15K (at least for *my* client systems). When it comes to e.g., a busy web-proxy server and similar systems, I guess the number of ongoing connections increases quite a bit. > or whether the hosts are incompletely > implementing port reuse checks that prevent a port from being used for > different IP addresses simultaneously. Unfortunately, you need to do this. See the API section in the CPNI TCP document (i.e., connection stealing). If we had socket(),bind(), and listen() combined in a single system call (and that was the only way to do things), then I'd agree that we could implement the checks you refer to. >> Also, in retrospective, with the "registered ports" thing you're wasting >> most of the port number space when you will probably use... what? a >> maximum of 10 or 20 ports of those 50K ports? > > And only 6,000 of those 50K are even assigned. Had not check the number of currently registered ports. -- interesting. > Again, though, making the > space even 4x larger has only a 4x impact on current issues - that's not > all that much, IMO. Not all that much... but certainly better than 1x. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Mon Oct 19 04:06:44 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891ED3A6840; Mon, 19 Oct 2009 04:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 6iFifk2oISv7; Mon, 19 Oct 2009 04:06:43 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BC2D13A681B; Mon, 19 Oct 2009 04:06:43 -0700 (PDT) Received: from [172.40.40.57] (rrcs-208-125-251-170.nys.biz.rr.com [208.125.251.170]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n9JB4Ca1017674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Oct 2009 04:04:15 -0700 (PDT) Message-ID: <4ADC47AC.4000301@isi.edu> Date: Mon, 19 Oct 2009 04:04:12 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tsvwg] [port-srv-reg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> <4ACA69C5.1060802@gont.com.ar> <4ADBBDA9.3090102@isi.edu> <4ADC1165.6090207@gont.com.ar> <4ADC2A34.4000602@isi.edu> <4ADC3ED2.3040708@gont.com.ar> <4ADC4089.6070404@isi.edu> <4ADC450F.6030302@gont.com.ar> In-Reply-To: <4ADC450F.6030302@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Mon, 19 Oct 2009 08:05:45 -0700 Cc: "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 11:06:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >> It'd be useful to consider whether there are actually 15K connections >> and thus a real problem, > > file sharing (p2p) applications tend to create lots of connections. > Although I wouldn't go as far as 15K (at least for *my* client systems). > When it comes to e.g., a busy web-proxy server and similar systems, I > guess the number of ongoing connections increases quite a bit. If these are persistent connections between two IP addresses for the same service, it begs the question of whether the connections should be persistent. >> or whether the hosts are incompletely >> implementing port reuse checks that prevent a port from being used for >> different IP addresses simultaneously. > > Unfortunately, you need to do this. See the API section in the CPNI TCP > document (i.e., connection stealing). > > If we had socket(),bind(), and listen() combined in a single system call > (and that was the only way to do things), then I'd agree that we could > implement the checks you refer to. I'm talking about a system that declares port 49999 "in use" for all IP addresses when it's in use for one, just to save the space and/or computation of keeping more detailed state. I wasn't referring to the checks that are required as a result of the lack of a single OS call to setup a connection. >> Again, though, making the >> space even 4x larger has only a 4x impact on current issues - that's not >> all that much, IMO. > > Not all that much... but certainly better than 1x. A X increase in BW results in an X^2 increase in vulnerability, as explained in RFC4953. A X increase in ports would result in an X increase in resistance, which isn't going to keep up. I.e., this is a small and fixed one-time increase that simply won't have enough of an impact to justify changes in how we assign or use ports. There are other good reasons (allowing endpoints to determine port use, removing the need for an index, etc.), but not this. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrcR6sACgkQE5f5cImnZrs/iQCguPBezBn1SeDtz80HQX+pqCbh srwAoMn0tJN5qQOoYTYa0LY+wy6pCgN2 =vaXt -----END PGP SIGNATURE----- From lear@cisco.com Mon Oct 19 08:29:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C813A6823; Mon, 19 Oct 2009 08:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.005 X-Spam-Level: X-Spam-Status: No, score=-10.005 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l7qe34I902F; Mon, 19 Oct 2009 08:29:31 -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 327F63A68FA; Mon, 19 Oct 2009 08:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=100; q=dns/txt; s=amsiport01001; t=1255966178; x=1257175778; 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:=20Eliot=20Lear=20|Subject:=20Re: =20[tsvwg]=20[port-srv-reg]=20=20draft-ietf-tsvwg-iana-po rts-02|Date:=20Mon,=2019=20Oct=202009=2017:29:35=20+0200 |Message-ID:=20<4ADC85DF.9010304@cisco.com>|To:=20Joe=20T ouch=20|CC:=20Fernando=20Gont=20,=20"ah@tr-sys.de"=20,=0D=0A=20 =20=20=20=20=20=20=20tsvwg=20,=0D=0A=20 =20=20=20=20=20=20=20"apps-discuss@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"draft-ietf-t svwg-iana-ports@cabernet.tools.ietf.org"=20,=0D=0A=20=20=20 =20=20=20=20=20"port-srv-reg@ietf.org"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 7bit|In-Reply-To:=20<4ADC47AC.4000301@isi.edu> |References:=20<200909291410.QAA19651@TR-Sys.de>=09<7D5E2 49F-06D0-45DB-A63A-33303229F457@nokia.com>=09<6468cc52091 0050215x9314627uf8c28b25a4ecd13d@mail.gmail.com>=09<8E6CA 11C-76C4-405F-87DA-0627850B3280@nokia.com>=09<6468cc52091 0050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com>=09<2F32 CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com>=09<4ACA69C5.1 060802@gont.com.ar>=09<4ADBBDA9.3090102@isi.edu>=09<4ADC1 165.6090207@gont.com.ar>=20<4ADC2A34.4000602@isi.edu>=09< 4ADC3ED2.3040708@gont.com.ar>=20<4ADC4089.6070404@isi.edu >=09<4ADC450F.6030302@gont.com.ar>=20<4ADC47AC.4000301@is i.edu>; bh=5sMePnbG0tUNwktc4Mmc5j6aTEEvsS+c/R517Rj0kfM=; b=I5EcPozLnn1fN4BN2+KgD2RzvgTg9YXkMUjwF8ae+dFRon5tbb64ngPj yDtvXrtjW5MDIzISHaRucZEs5eojnHDdn3dSWAoeM64cKsI7YrwfrG8Hd xQB5Dvq03JK+PoQeknspG/k5V4T+lVsp1zJgTRjDnEL0jqsyol7BmbYZL s=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAABMj3EqQ/uCWe2dsb2JhbACBUZk9AQEWJAapBpZrhDEEin4 X-IronPort-AV: E=Sophos;i="4.44,585,1249257600"; d="scan'208";a="52170478" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2009 15:29:36 +0000 Received: from elear-mac.local (dhcp-10-61-104-193.cisco.com [10.61.104.193]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9JFTZqE008356; Mon, 19 Oct 2009 15:29:35 GMT Message-ID: <4ADC85DF.9010304@cisco.com> Date: Mon, 19 Oct 2009 17:29:35 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5pre) Gecko/20091017 Shredder/3.0pre MIME-Version: 1.0 To: Joe Touch Subject: Re: [tsvwg] [port-srv-reg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> <4ACA69C5.1060802@gont.com.ar> <4ADBBDA9.3090102@isi.edu> <4ADC1165.6090207@gont.com.ar> <4ADC2A34.4000602@isi.edu> <4ADC3ED2.3040708@gont.com.ar> <4ADC4089.6070404@isi.edu> <4ADC450F.6030302@gont.com.ar> <4ADC47AC.4000301@isi.edu> In-Reply-To: <4ADC47AC.4000301@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , Fernando Gont , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 15:29:31 -0000 I'm confused. Outbound and inbound port numbers are complete separate name spaces, aren't they? From touch@ISI.EDU Mon Oct 19 12:40:06 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0394128C128; Mon, 19 Oct 2009 12:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 4Z+tRPU0OIcb; Mon, 19 Oct 2009 12:40:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 070D528C10E; Mon, 19 Oct 2009 12:40:01 -0700 (PDT) Received: from [172.40.40.57] (rrcs-208-125-251-170.nys.biz.rr.com [208.125.251.170]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n9JJd8su001342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Oct 2009 12:39:11 -0700 (PDT) Message-ID: <4ADCC05A.9030802@isi.edu> Date: Mon, 19 Oct 2009 12:39:06 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [tsvwg] [port-srv-reg] draft-ietf-tsvwg-iana-ports-02 References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com> <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com> <8E6CA11C-76C4-405F-87DA-0627850B3280@nokia.com> <6468cc520910050253i48056e8ewdbd5f8f5ba7aa517@mail.gmail.com> <2F32CF52-93C7-4D26-B3DF-D3F94ADFE383@muada.com> <4ACA69C5.1060802@gont.com.ar> <4ADBBDA9.3090102@isi.edu> <4ADC1165.6090207@gont.com.ar> <4ADC2A34.4000602@isi.edu> <4ADC3ED2.3040708@gont.com.ar> <4ADC4089.6070404@isi.edu> <4ADC450F.6030302@gont.com.ar> <4ADC47AC.4000301@isi.edu> <4ADC85DF.9010304@cisco.com> In-Reply-To: <4ADC85DF.9010304@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "ah@tr-sys.de" , tsvwg , "apps-discuss@ietf.org" , "draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org" , Fernando Gont , "port-srv-reg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 19:40:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eliot Lear wrote: > I'm confused. Outbound and inbound port numbers are complete separate > name spaces, aren't they? They should be, but in implementations they often aren't. E.g., you bind to 80 to listen, and now you cannot use 80 as a source port for outbound. Further, some (IMO, poor) implementations use one space to count which dynamic ports are in use. So they should be separate, but they might not be... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrcwFoACgkQE5f5cImnZrv86QCfXoNoTwhEhvjUy3llNnr/B6sc ysEAoPP1MgjICjkM2ys2u9EGPq+ukUH0 =lq0X -----END PGP SIGNATURE----- From dwing@cisco.com Mon Oct 19 17:49:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376FB3A687C; Mon, 19 Oct 2009 17:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.053 X-Spam-Level: X-Spam-Status: No, score=-6.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPsAUG+fMx-l; Mon, 19 Oct 2009 17:49:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 47EBF3A681A; Mon, 19 Oct 2009 17:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2379; q=dns/txt; s=sjiport06001; t=1255999766; x=1257209366; 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:=20"Dan=20Wing"=20|Reply-To:=20|Subject:=20Building=20IPv6=20Applicatio ns=20which=20Access=20IPv4=20Servers=20-=20draft-wing-v6o ps-v6app-v4server-00|Date:=20Mon,=2019=20Oct=202009=2017: 49:25=20-0700|Message-ID:=20<028701ca511f$2bf3bb70$c4f020 0a@cisco.com>|To:=20"'IPv6=20Operations'"=20,=20,=0D=0A=20=20=20=20=20 =20=20=20"Behave=20WG"=20|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit; bh=lrSODG7T8yLiaWzd2jrZf+Scn2LpUHpoafo+R4HlVtg=; b=fjAocG3lC+cSQVV8B75IMw96i5zbVZnXsiKRITmreveFe8pTWyr8ufkE 7CHDWYpDGiSHKKPTov/GKoPFQDQl5oPcf6d7OQyzBRPTTo3qZkoSktROI 0Rx598l6zaCwQfXDe1cTlsbAuWfolhz658RVwqXV/VGU0+e599U6X717V 4=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAJ+l3EqrR7Hu/2dsb2JhbACKYLdfl0uEMQSBWw X-IronPort-AV: E=Sophos;i="4.44,588,1249257600"; d="scan'208";a="413019968" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 20 Oct 2009 00:49:25 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9K0nPXO025680; Tue, 20 Oct 2009 00:49:25 GMT From: "Dan Wing" To: "'IPv6 Operations'" , , "Behave WG" Subject: Building IPv6 Applications which Access IPv4 Servers - draft-wing-v6ops-v6app-v4server-00 Date: Mon, 19 Oct 2009 17:49:25 -0700 Message-ID: <028701ca511f$2bf3bb70$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpRHyuxTiUCYKaIT2eZtZLH/JbKZg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: v6ops@ops.ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 00:49:19 -0000 (Please reply to v6ops@ops.ietf.org) V6Ops, Apps-Discuss, Behave, I just submitted a short draft, "Building IPv6 Applications which Access IPv4 Servers" which may be interesting to apps area, behave, and v6ops, as it has some bearing on each. The document applies to IPv6 hosts operating in BEHAVE's scenarios 1 ("an IPv6 network to IPv4 Internet"), and scenario 5 ("an IPv6 network to an IPv4 network"). It explains that while DNS64 and 6/4 translation is helpful and functional for many IPv6 applications, there are some IPv6 applications that will need to additional functionality -- either (a) in the application itself using the translator (e.g., an IPv6 SIP application could be extended to do this) or (b) using some sort of application-level proxy functionality (e.g., a SIP application can use a TURN-IPv6 relay; an HTTP application can use an HTTP proxy that is connected to IPv4 and IPv6). The purpose of this document is to examine 6/4 translation in more detail, and show what IPv6 applications need to add so that we can avoid Application Layer Gateways (ALGs) in hosts, in CPEs, and in 6/4 translators. Some protocols, notably SIP, have already finished their efforts to explain how the protocol will transition to IPv6 (in fact, two SIP documents explain two different mechanisms; that might not be a bad thing). Other protocols such as FTP are being examined by BEHAVE. Other protocols, such as RTSP, XMPP, and probably others, I have no idea of their status regarding IPv6 and if/how they have decided to handle IPv6-only applications communicating with IPv4 addresses. This draft hopes to start that discussion. Abstract: When an application runs on a host or network that only supports IPv6 ("IPv6-only"), it is sometimes necessary that the application communicate with IPv4 peers. When that communication involves DNS, DNS64 and a 6/4 translator works well without any changes to most applications. However, when that communication does not involve DNS, it can require additional features be configured on or programmed into the IPv6 application. This document explains why this functionality is important and describes mechanisms for applications to provide such functionality. http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server-00 Comments welcome. -d From barryleiba.mailing.lists@gmail.com Mon Oct 19 18:11:51 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68DC628C197 for ; Mon, 19 Oct 2009 18:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 bctMK4IV+OC5 for ; Mon, 19 Oct 2009 18:11:50 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 826053A681A for ; Mon, 19 Oct 2009 18:11:50 -0700 (PDT) Received: by ywh13 with SMTP id 13so6967862ywh.29 for ; Mon, 19 Oct 2009 18:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=g0KkOYQi0ev5hN0M5ZZclW0/wjjsZ72DcoXE7tZkVg0=; b=l8pYkX30FL3LfLNdBsEhBZneJ5js1uSl+sFYwZRuty54+LKdzuxauzj6w+BxInIHeK +ImtXSZkII+C+gsJWpxq7xivhr5Bi6JGkCcje3F0mmxUJMsUxCr7FvO7vc10dP+PS33O dRRQc34eDC0KppayGfoUHfH2F4ABfNY9CRPLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=Z/KrMOh8x2Brd0ucQYadCQVuJm9CWbhSdwgx/uJGfHdKYYC1FiXoeGt0oWE9JIQAdp YYRk5QLzzJ24Z4acX2qRBqZhMG2HHkv13zqQrgVleKVyWxMBT85LpghDd4PesbdPcIl8 LH5PIvVEJrDzMQMvqSkLd/zxUrBogApc57wbA= MIME-Version: 1.0 Received: by 10.150.250.13 with SMTP id x13mr9333146ybh.230.1256001115325; Mon, 19 Oct 2009 18:11:55 -0700 (PDT) In-Reply-To: References: <92D713CF-28C5-4CCB-8803-A03CDCDED61B@cs.cmu.edu> Date: Mon, 19 Oct 2009 21:11:55 -0400 Message-ID: <6c9fcc2a0910191811y277e931dpe9f9d83ee9bce739@mail.gmail.com> Subject: Re: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 01:11:51 -0000 > Do people find this interesting? To specify it, we'd just need to describe a > format (e.g., a space-separated list of tokens). > >> Depending on how the server is configured a query to >> http://example.com/.well-known/ might return the list of files in that >> directory. It might be nice to actually encourage that. The only downside I >> see is that it might make it easier for an attacker to find out what you run >> and know what to exploit, but without that the attacker could still play 20 >> questions and find out. I like it. I understand Eran's issue, but I don't see the point in waiting before making the specification. Barry From leslie@thinkingcat.com Mon Oct 19 19:00:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373C73A67E2 for ; Mon, 19 Oct 2009 19:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 8oWJGnQWU4eu for ; Mon, 19 Oct 2009 19:00:38 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id EFC7B3A6953 for ; Mon, 19 Oct 2009 19:00:37 -0700 (PDT) Received: from beethoven.local ([::ffff:173.71.204.217]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 19 Oct 2009 22:00:38 -0400 id 015AC50B.4ADD19C6.00002CEA Message-ID: <4ADD19BD.8080800@thinkingcat.com> Date: Mon, 19 Oct 2009 22:00:29 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: FYI -- Congestion Exposure (CONEX) BoF in Hiroshima Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Philip Eardley X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 02:00:39 -0000 Hi, I just wanted to give a heads-up about the Congestion Exposure (CONEX) Bof in Hiroshima - currently scheduled for Tues 15.20 – 18.10. While CONEX is clearly Transport work, there are implications for applications do/not have to do in order to work well with networks, so I thought it might be of interest, here. Best, Leslie Daigle & Philip Eardley (BoF Chairs) Congestion Exposure (CONEX) (was re-ECN) Description Congestion Exposure (ConEx) is a proposed new IETF activity to enable congestion to be exposed along the forwarding path of the Internet. By revealing expected congestion in the IP header of packets, congestion exposure provides a generic network capability which allows greater freedom over how capacity is shared. Such information could be used for many purposes, including congestion policing, accountability and inter-domain SLAs. It may also open new approaches to QoS and traffic engineering. The Internet is, in essence, about pooling resources. The ability to share capacity has been paramount to its success and has traditionally been managed through the voluntary use of TCP congestion control. However, TCP alone is unable to prevent bandwidth intensive applications, such as peer-to-peer or streaming video, from causing enough congestion over time to severely limit the user-experience of many other users. This has led ISPs to deploy ad-hoc solutions such as volume accounting, rate policing and deep packet inspection in an attempt to distribute capacity differently. The consequences of such practices are increasingly leading to calls for government regulations and stifling innovation at the transport and application layer (see for example, the problem statement I-D (ref below) and RFC5594). We believe these problems stem from the lack of a network-layer system for accountability -- among all parties -- for sending traffic which causes congestion. We propose a metric where IP packets carry information about the expected rest-of-path congestion, so that any network node may estimate how much congestion it is likely to cause by sending or forwarding traffic. A network operator can then count the volume of congestion about to be caused by an aggregate of traffic as easily as it can count the volume of bytes entering its network today. Once ISPs can see rest-of-path congestion, they can discourage users from causing large volumes of congestion, discourage other networks from allowing their users to cause congestion, and more meaningfully differentiate between the qualities of services offered from potential connectivity partners. Meanwhile end-hosts may be freed from rate restrictions where their traffic causes little congestion. The purpose of the BoF is to explore the support for and viability of pursuing an IETF activity to define a basic protocol to expose the expected rest-of-path congestion in the IP header. Any such protocol should work with minimal changes to the existing network, in particular it should work with unmodified routers. There is already one existing proposal that builds on ECN to provide rest-of-path congestion information in IP headers and other proposals may come forward. If supported, an eventual WG would focus on the development of its chosen congestion exposure protocol as its main work item. The chosen protocol will need to be deployable with minimal changes to the existing Internet, preferably working with unmodified routers. Additional work items could include detailing the motivations for congestion exposure, a threat analysis of the subsequent protocol, reporting on experimental trials and describing deployment considerations. Importantly, the proposed WG would encourage experimentation but not deliberate on how congestion exposure should be used: our concern would be how flexibly the resulting protocol can support differing needs at run-time, rather than dictating a particular usage at design time. Related Internet-Drafts include: ConEx Problem statement: http://tools.ietf.org/id/draft-moncaster-congestion-exposure-problem re-ECN protocol spec: http://tools.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp re-ECN motivation: http://tools.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-motivation Other useful reference material: Overview: problem & solution (7pp): http://www.bobbriscoe.net/projects/refb/FairerFasterWP.pdf Mailing list for discussion: re-ecn@ietf.org Subscribe: https://www.ietf.org/mailman/listinfo/re-ecn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From Martin.Thomson@andrew.com Mon Oct 19 19:15:51 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A8A3A69F1 for ; Mon, 19 Oct 2009 19:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 T-nKmFa2ZArh for ; Mon, 19 Oct 2009 19:15:50 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 4C1D83A68FB for ; Mon, 19 Oct 2009 19:15:50 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:10142 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S69005AbZJTCP5 (ORCPT ); Mon, 19 Oct 2009 21:15:57 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 19 Oct 2009 21:15:57 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 20 Oct 2009 10:15:50 +0800 From: "Thomson, Martin" To: "barryleiba@computer.org" , Mark Nottingham Date: Tue, 20 Oct 2009 10:16:13 +0800 Subject: RE: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Thread-Topic: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Thread-Index: AcpRIlaHnFjYJc1LQseJXS923yN0SQAB2vRA Message-ID: <8B0A9FCBB9832F43971E38010638454F0F1EA0DE@SISPE7MB1.commscope.com> References: <92D713CF-28C5-4CCB-8803-A03CDCDED61B@cs.cmu.edu> <6c9fcc2a0910191811y277e931dpe9f9d83ee9bce739@mail.gmail.com> In-Reply-To: <6c9fcc2a0910191811y277e931dpe9f9d83ee9bce739@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 02:15:51 -0000 VGhpcyB3b3VsZCBiZSBxdWl0ZSBoZWxwZnVsIC0gaWYgYSBjbGllbnQgbW9kaWZpZXMgYmVoYXZp b3VyIGJhc2VkIG9uIHdoYXQgaXQgdW5kZXJzdGFuZHMgYSBzZXJ2ZXIgdG8gInN1cHBvcnQiLCB0 aGVuIHRoaXMgd291bGQgZmFjaWxpdGF0ZSBkZXRlY3Rpb24gb2YgdGhhdCBzdXBwb3J0Lg0KDQpX aXRoIHJlc3BlY3QgdG8gRXJhbidzIGNvbmNlcm5zLCBpdCdzIHByb2JhYmx5IG5vdCBuZWNlc3Nh cnkgdG8gcm9sbCB0aGUgdHdvIGNvbmNlcHRzIHRvZ2V0aGVyLiAgQSBzZWNvbmQgZG9jdW1lbnQg d291bGQgbGV0IHVzIHJlc29sdmUgdGhvc2UgY29uY2VybnMgd2l0aG91dCBhZmZlY3RpbmcgdGhl IGltbWVkaWF0ZSB1c2VmdWxuZXNzIG9mIHRoZSBiYXNlIHdlbGwta25vd24uDQoNCkFsb25nIHdp dGggdGhhdCwgaXMgdGhlcmUgYW55IGRlc2lyZSB0byBhdHRlbXB0IHRvIHJlZ2lzdGVyIGFueSBl eGFtcGxlcyBpbiB0aGUgcmVnaXN0cnk/ICBNb3Zpbmcgcm9ib3RzLnR4dCBhbmQgZmF2aWNvbi5p Y28gaGVyZSBzZWVtcyBsb2dpY2FsLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNz LQ0KPiBib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmFycnkgTGVpYmENCj4gU2VudDog VHVlc2RheSwgMjAgT2N0b2JlciAyMDA5IDEyOjEyIFBNDQo+IFRvOiBNYXJrIE5vdHRpbmdoYW0N Cj4gQ2M6IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogTGFzdCBDYWxsOiBk cmFmdC1ub3R0aW5naGFtLXNpdGUtbWV0YSAoRGVmaW5pbmcgV2VsbC1Lbm93bg0KPiBVUklzKSB0 byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gPiBEbyBwZW9wbGUgZmluZCB0aGlzIGludGVyZXN0 aW5nPyBUbyBzcGVjaWZ5IGl0LCB3ZSdkIGp1c3QgbmVlZCB0bw0KPiBkZXNjcmliZSBhDQo+ID4g Zm9ybWF0IChlLmcuLCBhIHNwYWNlLXNlcGFyYXRlZCBsaXN0IG9mIHRva2VucykuDQo+ID4NCj4g Pj4gRGVwZW5kaW5nIG9uIGhvdyB0aGUgc2VydmVyIGlzIGNvbmZpZ3VyZWQgYSBxdWVyeSB0bw0K PiA+PiBodHRwOi8vZXhhbXBsZS5jb20vLndlbGwta25vd24vIG1pZ2h0IHJldHVybiB0aGUgbGlz dCBvZiBmaWxlcyBpbg0KPiB0aGF0DQo+ID4+IGRpcmVjdG9yeS4gSXQgbWlnaHQgYmUgbmljZSB0 byBhY3R1YWxseSBlbmNvdXJhZ2UgdGhhdC4gVGhlIG9ubHkNCj4gZG93bnNpZGUgSQ0KPiA+PiBz ZWUgaXMgdGhhdCBpdCBtaWdodCBtYWtlIGl0IGVhc2llciBmb3IgYW4gYXR0YWNrZXIgdG8gZmlu ZCBvdXQgd2hhdA0KPiB5b3UgcnVuDQo+ID4+IGFuZCBrbm93IHdoYXQgdG8gZXhwbG9pdCwgYnV0 IHdpdGhvdXQgdGhhdCB0aGUgYXR0YWNrZXIgY291bGQgc3RpbGwNCj4gcGxheSAyMA0KPiA+PiBx dWVzdGlvbnMgYW5kIGZpbmQgb3V0Lg0KPiANCj4gSSBsaWtlIGl0LiAgSSB1bmRlcnN0YW5kIEVy YW4ncyBpc3N1ZSwgYnV0IEkgZG9uJ3Qgc2VlIHRoZSBwb2ludCBpbg0KPiB3YWl0aW5nIGJlZm9y ZSBtYWtpbmcgdGhlIHNwZWNpZmljYXRpb24uDQo+IA0KPiBCYXJyeQ0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBcHBzLURpc2N1c3MgbWFpbGlu ZyBsaXN0DQo+IEFwcHMtRGlzY3Vzc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0KDQo= From eran@hueniverse.com Mon Oct 19 20:52:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69963A67D6 for ; Mon, 19 Oct 2009 20:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 cGEeswRnPiV3 for ; Mon, 19 Oct 2009 20:52:50 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 088593A62C1 for ; Mon, 19 Oct 2009 20:52:50 -0700 (PDT) Received: (qmail 24047 invoked from network); 20 Oct 2009 03:52:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Oct 2009 03:52:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 19 Oct 2009 20:52:55 -0700 From: Eran Hammer-Lahav To: "barryleiba@computer.org" , Mark Nottingham Date: Mon, 19 Oct 2009 20:53:01 -0700 Subject: RE: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Thread-Topic: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Thread-Index: AcpRIlQrU4fj3rUmT/+2N8XYMU75IQAFe2WQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784F60CD3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <92D713CF-28C5-4CCB-8803-A03CDCDED61B@cs.cmu.edu> <6c9fcc2a0910191811y277e931dpe9f9d83ee9bce739@mail.gmail.com> In-Reply-To: <6c9fcc2a0910191811y277e931dpe9f9d83ee9bce739@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 03:52:50 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Monday, October 19, 2009 6:12 PM > To: Mark Nottingham > Cc: apps-discuss@ietf.org > Subject: Re: Last Call: draft-nottingham-site-meta (Defining Well-Known > URIs) to Proposed Standard >=20 > > Do people find this interesting? To specify it, we'd just need to > describe a > > format (e.g., a space-separated list of tokens). > > > >> Depending on how the server is configured a query to > >> http://example.com/.well-known/ might return the list of files in > that > >> directory. It might be nice to actually encourage that. The only > downside I > >> see is that it might make it easier for an attacker to find out what > you run > >> and know what to exploit, but without that the attacker could still > play 20 > >> questions and find out. >=20 > I like it. I understand Eran's issue, but I don't see the point in > waiting before making the specification. You can go ahead and do it right now. I personally don't have any use case = for it, and I don't think it will be very useful for a while. If anything, = I am working on a proposal that will provide a generically useful document = for more protocols under /.well-known. I just don't think there is compelli= ng reason to use the directory itself as the way to get the list of documen= ts (considering the deployment challenges). EHL From eran@hueniverse.com Mon Oct 19 20:56:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A5F3A63C9 for ; Mon, 19 Oct 2009 20:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 pDtdB3obebU9 for ; Mon, 19 Oct 2009 20:56:22 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2BA943A62C1 for ; Mon, 19 Oct 2009 20:56:22 -0700 (PDT) Received: (qmail 24818 invoked from network); 20 Oct 2009 03:56:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Oct 2009 03:56:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 19 Oct 2009 20:56:29 -0700 From: Eran Hammer-Lahav To: "Thomson, Martin" Date: Mon, 19 Oct 2009 20:56:34 -0700 Subject: RE: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Thread-Topic: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Thread-Index: AcpRIlaHnFjYJc1LQseJXS923yN0SQAB2vRAAAPJvJA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784F60CD4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <92D713CF-28C5-4CCB-8803-A03CDCDED61B@cs.cmu.edu> <6c9fcc2a0910191811y277e931dpe9f9d83ee9bce739@mail.gmail.com> <8B0A9FCBB9832F43971E38010638454F0F1EA0DE@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F1EA0DE@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 03:56:23 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Thomson, Martin > Sent: Monday, October 19, 2009 7:16 PM > To: barryleiba@computer.org; Mark Nottingham > Cc: apps-discuss@ietf.org > Subject: RE: Last Call: draft-nottingham-site-meta (Defining Well-Known > URIs) to Proposed Standard >=20 > This would be quite helpful - if a client modifies behaviour based on > what it understands a server to "support", then this would facilitate > detection of that support. >=20 > With respect to Eran's concerns, it's probably not necessary to roll > the two concepts together. A second document would let us resolve > those concerns without affecting the immediate usefulness of the base > well-known. I would be happy to help/edit such a separate proposal if people are willin= g to submit use cases. This can be very simple or very complex. > Along with that, is there any desire to attempt to register any > examples in the registry? Moving robots.txt and favicon.ico here seems > logical. "Moving" them is wishful thinking at best. I can poke around at Google and = Yahoo! to see if the search teams would even want to think about it but it = would be nothing but dead records in the registry. And dead records tend to= make the whole registry look bad. I have just submitted (an incomplete) proposal for /.well-known/host-meta w= hich will be published (hopefully) shortly after the registry is set up. EHL > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of Barry Leiba > > Sent: Tuesday, 20 October 2009 12:12 PM > > To: Mark Nottingham > > Cc: apps-discuss@ietf.org > > Subject: Re: Last Call: draft-nottingham-site-meta (Defining Well- > Known > > URIs) to Proposed Standard > > > > > Do people find this interesting? To specify it, we'd just need to > > describe a > > > format (e.g., a space-separated list of tokens). > > > > > >> Depending on how the server is configured a query to > > >> http://example.com/.well-known/ might return the list of files in > > that > > >> directory. It might be nice to actually encourage that. The only > > downside I > > >> see is that it might make it easier for an attacker to find out > what > > you run > > >> and know what to exploit, but without that the attacker could > still > > play 20 > > >> questions and find out. > > > > I like it. I understand Eran's issue, but I don't see the point in > > waiting before making the specification. > > > > Barry > > _______________________________________________ > > Apps-Discuss mailing list > > Apps-Discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From Martin.Thomson@andrew.com Mon Oct 19 21:06:14 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59543A67D6 for ; Mon, 19 Oct 2009 21:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 PLMVzMD9VxN5 for ; Mon, 19 Oct 2009 21:06:14 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 0C5A53A62C1 for ; Mon, 19 Oct 2009 21:06:14 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:46852 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S69236AbZJTEGU (ORCPT ); Mon, 19 Oct 2009 23:06:20 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 19 Oct 2009 23:06:19 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 20 Oct 2009 12:06:15 +0800 From: "Thomson, Martin" To: Eran Hammer-Lahav Date: Tue, 20 Oct 2009 12:06:38 +0800 Subject: RE: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Thread-Topic: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard Thread-Index: AcpRIlaHnFjYJc1LQseJXS923yN0SQAB2vRAAAPJvJAAADtngA== Message-ID: <8B0A9FCBB9832F43971E38010638454F0F1EA127@SISPE7MB1.commscope.com> References: <92D713CF-28C5-4CCB-8803-A03CDCDED61B@cs.cmu.edu> <6c9fcc2a0910191811y277e931dpe9f9d83ee9bce739@mail.gmail.com> <8B0A9FCBB9832F43971E38010638454F0F1EA0DE@SISPE7MB1.commscope.com> <90C41DD21FB7C64BB94121FBBC2E72343784F60CD4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784F60CD4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 04:06:14 -0000 PiA+IEFsb25nIHdpdGggdGhhdCwgaXMgdGhlcmUgYW55IGRlc2lyZSB0byBhdHRlbXB0IHRvIHJl Z2lzdGVyIGFueQ0KPiA+IGV4YW1wbGVzIGluIHRoZSByZWdpc3RyeT8gIE1vdmluZyByb2JvdHMu dHh0IGFuZCBmYXZpY29uLmljbyBoZXJlDQo+IHNlZW1zDQo+ID4gbG9naWNhbC4NCj4gDQo+ICJN b3ZpbmciIHRoZW0gaXMgd2lzaGZ1bCB0aGlua2luZyBhdCBiZXN0LiBJIGNhbiBwb2tlIGFyb3Vu ZCBhdCBHb29nbGUNCj4gYW5kIFlhaG9vISB0byBzZWUgaWYgdGhlIHNlYXJjaCB0ZWFtcyB3b3Vs ZCBldmVuIHdhbnQgdG8gdGhpbmsgYWJvdXQgaXQNCj4gYnV0IGl0IHdvdWxkIGJlIG5vdGhpbmcg YnV0IGRlYWQgcmVjb3JkcyBpbiB0aGUgcmVnaXN0cnkuIEFuZCBkZWFkDQo+IHJlY29yZHMgdGVu ZCB0byBtYWtlIHRoZSB3aG9sZSByZWdpc3RyeSBsb29rIGJhZC4NCg0KIm1vdmluZyIgd2FzIGlu dGVudGlvbmFsbHkgaW5mbGFtbWF0b3J5IDspICBJJ2QgaW1hZ2luZSB0aGF0IHRoZXNlIHdvdWxk IG5lZWQgdG8gcmVtYWluIGluIHRoZWlyIGN1cnJlbnQgbG9jYXRpb25zIGluZGVmaW5pdGVseS4g IEhvd2V2ZXIsIEkgZG8gbWVhbiAibW92aW5nIiBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBzZWVtcyB0 aGF0IHdvdWxkIGJlIGEgZGVzaXJhYmxlIGVuZCBnb2FsLiAgU3RhcnRpbmcgd2l0aCBhIHJlZ2lz dHJhdGlvbiB3b3VsZCBiZSBhIHN0YXJ0Lg0K From barryleiba.mailing.lists@gmail.com Mon Oct 19 21:51:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27F13A68B0 for ; Mon, 19 Oct 2009 21:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 evogGDrXx6vq for ; Mon, 19 Oct 2009 21:51:24 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 1EAF43A6358 for ; Mon, 19 Oct 2009 21:51:24 -0700 (PDT) Received: by yxe30 with SMTP id 30so6847396yxe.29 for ; Mon, 19 Oct 2009 21:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mVnXSav/JpW5YVQMfaAsY/Au6noiNkRRdE1AftwiRSQ=; b=pe6rbpTGeHIMe/w0UvrqnEjul2SIXAmJ2Teb5iaffWjQnnnZJUtDBSqTTdljWb5MnL DEhLAkO20A8vQ5erjmC4QAxfIiO5g3S1+eGVUWgu/hGPIs/H3qJxUmyWU2TSB8iAb3Ds j87S7yOr2AieuZ25uRiFPkJvvTc9k8TYWNA3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=Bz9xsjI2BJCp05iGecPJx89MgXQnxFMoJ5TXxHcYJz4Vx3KqOtJryjz4a+eFVFvyop ysitysDNHFDWRA/MBrdBi+mdr5BWVW4f13FLPgIeXSrnVqzyIg0/tI9dYMnGmh+Fui3s +LyEaSGt8ttUBQlMQfEKTnLP/1kjAuYMDv59A= MIME-Version: 1.0 Received: by 10.150.7.17 with SMTP id 17mr9670769ybg.47.1256014288275; Mon, 19 Oct 2009 21:51:28 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784F60CD3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <92D713CF-28C5-4CCB-8803-A03CDCDED61B@cs.cmu.edu> <6c9fcc2a0910191811y277e931dpe9f9d83ee9bce739@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784F60CD3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 20 Oct 2009 00:51:28 -0400 Message-ID: <6c9fcc2a0910192151n1e25a7d6j438052019a418809@mail.gmail.com> Subject: Re: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 04:51:25 -0000 > If anything, I am working on a proposal that will provide a generically > useful document for more protocols under /.well-known. I just don't > think there is compelling reason to use the directory itself as the way > to get the list of documents (considering the deployment challenges). Oh, it certainly doesn't have to use the directory itself. The point was to "query" the directory; that could be done by asking for, say, "index.xml", or whatever. What I like about Lorrie's idea is having a mechanism to do the query. I don't care what the mechanism is. Barry From barryleiba.mailing.lists@gmail.com Tue Oct 20 20:13:20 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A782D3A672F for ; Tue, 20 Oct 2009 20:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjtOSHhzNnaf for ; Tue, 20 Oct 2009 20:13:19 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 8BE283A6898 for ; Tue, 20 Oct 2009 20:13:19 -0700 (PDT) Received: by ywh13 with SMTP id 13so8637361ywh.29 for ; Tue, 20 Oct 2009 20:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=C2s2LB7t6ylaLi0bJxMGo278p6OqNE6+vn6fyg/Wu/k=; b=QdzV3VHFCAKhkIPLLCnuNvSHV+ldBvXPBWQo/+SQrmEVNJ/I+NXZ/xnVNGWjeEUi+D bjDl1yqJuvBg8fvhV67xyrUVTi9Nsjp6tiOgfablM9NNi28r4ebTFWQznlYIjWm5Wc+W jxXwhp+NsWEan07hG78Gtn3mX33WkobsEvWvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=rdwFy8EL9yLSAMfEREhOzilrLV0qhVle0Oilvw5rHxbMaH8MsS+879VYFOcNp8Fk7p UAMHzxcvZsvdDUpewN/EsSQz3sJtzfXqNhGXPHAiEH6NZvn7y39mwuOkVanHKK6aHMCH RDgdMz0OlQZZav1JHio/43Db9BVoN+H+4gzIU= MIME-Version: 1.0 Received: by 10.151.92.9 with SMTP id u9mr12071115ybl.158.1256094804371; Tue, 20 Oct 2009 20:13:24 -0700 (PDT) Date: Tue, 20 Oct 2009 23:13:24 -0400 Message-ID: <6c9fcc2a0910202013o257e902eg405c133676377b85@mail.gmail.com> Subject: Call for Papers about managing information overload From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 03:13:20 -0000 Subscribers here may be interested in the call for papers for a special issue of IEEE Internet Computing magazine, devoted to information overload (posted here with permission of the ADs). Please don't discuss it here, but respond as noted in the CfP. Barry --------------------------------------- Overcoming Information Overload Final submissions due: 1 March 2010 Publication date: November/December 2010 Please email the guest editors by 15 February 2010 with a brief description of the article you plan to submit (see http://www.computer.org/portal/web/computingnow/iccfp6 ). Internet users today are inundated with information. We get masses of email; we=92re interrupted by instant messages; and we must remember to check social networking sites, news sources, and company Web sites daily =97 or even many times each day. Web searches produce more hits than we can sift through, as we try to find what we=92re really looking for. Managing this much information is a very complex task. =93Syndication=94 technology=97such as RSS and Atom=97and feed readers might provide some support, but issues related to the analysis, classification, evolution, retrieval, and other information are open problems. Information overload, therefore, represents a big challenge for software applications seeking to help users by collecting, grouping, classifying, indexing, selecting, searching, ranking, and filtering pieces of information. This special issue seeks original articles examining the state of the art, open problems, research results, tool evaluation, and future research directions in overcoming information overload. Appropriate topics include * building and managing information repositories; * extracting, matching, classifying, clustering, measuring similarity, analyzing natural language, and indexing applied to information; * retrieving, aggregating, and visualizing information; * personalizing, ranking, collaborative filtering, and keyword-based search engines; and * syndication technology and feed readers. --------------------------------------- From connolly@w3.org Thu Oct 22 09:38:18 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45EAF3A68A1; Thu, 22 Oct 2009 09:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zTj0CfEsOvj; Thu, 22 Oct 2009 09:38:17 -0700 (PDT) Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by core3.amsl.com (Postfix) with ESMTP id 58BCA3A68A0; Thu, 22 Oct 2009 09:38:17 -0700 (PDT) Received: from [127.0.0.1] (jay.w3.org [128.30.52.169]) by homer.w3.org (Postfix) with ESMTP id 3559B4EECA; Thu, 22 Oct 2009 12:38:26 -0400 (EDT) Subject: draft-nottingham-site-meta: registration too slow, opaque From: Dan Connolly To: Mark Nottingham , Eran Hammer-Lahav Content-Type: text/plain; charset="UTF-8" Date: Thu, 22 Oct 2009 11:38:25 -0500 Message-Id: <1256229505.4607.1513.camel@pav.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Content-Transfer-Encoding: 7bit Cc: www-archive@w3.org, ietf@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 16:38:18 -0000 Sorry I didn't review and comment when the draft first became available... Regarding: "Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request, communicating this decision both to the review list and to IANA." -- http://www.ietf.org/id/draft-nottingham-site-meta-03.txt My experience is that this sort of latency results in developers working around the IANA and IETF. Please set up a form so that with latency of a few seconds, somebody can have their token provisionally registered. (Perhaps an email callback will have to precede the form.) By way of example, consider the W3C XPointer Scheme Name Registry form http://www.w3.org/2005/04/xpointer-schemes/0register (though it's perhaps not completely shiny either... I see one example of "Status: Being reviewed Last updated on 2006-10-11" on http://www.w3.org/2005/04/xpointer-schemes/ ) I have tried to keep W3C out of the registry business all together, but IANA is widely reputed to be slow and opaque, and my own personal experience bears that out to some extent, so I can't completely stop people who are willing to set up registries in W3C (not to mention elsewhere...). If IANA has in fact gotten a lot better lately, perhaps we just need to address the perception part. As it is, section 5 doesn't even give an exact email address of where to send registration requests. That sends people on a scavenger hunt right from step 1. Perhaps a/the "datatracker" addresses my concern about latency and transparency... if mail to iana@iana.org results in an automated "ticket" response, with a pointer to a status page that always has a clear bound on the latency for the next step, that would suffice (if it's actually documented in section 5). Hmm... it's entitled "IETF I-D Tracker", which suggests its scope doesn't include IANA registration requests. https://datatracker.ietf.org/idtracker/ -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E From connolly@w3.org Thu Oct 22 09:43:55 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00CB3A681F; Thu, 22 Oct 2009 09:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDryJlfUQQ0c; Thu, 22 Oct 2009 09:43:54 -0700 (PDT) Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by core3.amsl.com (Postfix) with ESMTP id 79CBE3A67FA; Thu, 22 Oct 2009 09:43:54 -0700 (PDT) Received: from [127.0.0.1] (jay.w3.org [128.30.52.169]) by homer.w3.org (Postfix) with ESMTP id BE4134EECA; Thu, 22 Oct 2009 12:44:03 -0400 (EDT) Subject: draft-nottingham-site-meta: put key bit (/.well-known/) in the abstract From: Dan Connolly To: Mark Nottingham , Eran Hammer-Lahav Content-Type: text/plain; charset="UTF-8" Date: Thu, 22 Oct 2009 11:44:03 -0500 Message-Id: <1256229843.4607.1528.camel@pav.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Content-Transfer-Encoding: 7bit Cc: www-archive , ietf@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 16:43:55 -0000 I just started to summarize the draft for another audience (www-tag), and the most relevant bit I found was: [[ ... this memo defines a path prefix for these "well- known locations", "/.well-known/". Future specifications that need to define a resource for such site-wide metadata can register their use to avoid collisions and minimise impingement upon sites' URI space. ]] Please add that to the abstract, so that this abstract may better "act as a stand-alone entity instead of a full paper"*. * http://en.wikipedia.org/wiki/Abstract_%28summary%29 -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E From Nicolas.Williams@sun.com Thu Oct 22 10:08:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007D13A6985; Thu, 22 Oct 2009 10:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 aL5YujsDm-ht; Thu, 22 Oct 2009 10:08:15 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id E21593A68A0; Thu, 22 Oct 2009 10:08:14 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9MH8OlM021050; Thu, 22 Oct 2009 17:08:24 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9MH8O0B025345; Thu, 22 Oct 2009 11:08:24 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9MGnT53006178; Thu, 22 Oct 2009 11:49:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9MGnSNC006177; Thu, 22 Oct 2009 11:49:28 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 22 Oct 2009 11:49:28 -0500 From: Nicolas Williams To: Dan Connolly Subject: Re: draft-nottingham-site-meta: registration too slow, opaque Message-ID: <20091022164928.GQ892@Sun.COM> References: <1256229505.4607.1513.camel@pav.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1256229505.4607.1513.camel@pav.lan> User-Agent: Mutt/1.5.7i Cc: apps-discuss@ietf.org, www-archive@w3.org, ietf@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 17:08:16 -0000 On Thu, Oct 22, 2009 at 11:38:25AM -0500, Dan Connolly wrote: > I have tried to keep W3C out of the registry business all together, > but IANA is widely reputed to be slow and opaque, and my own > personal experience bears that out to some extent, so I can't > completely stop people who are willing to set up registries in W3C > (not to mention elsewhere...). If IANA has in fact gotten a lot better > lately, perhaps we just need to address the perception part. For a first-come-first-served name registry, with simple naming constraints, I think one should be able to automate a registry. Some latency is needed to deal with spammers, of course. Even if you need Expert review, the name camping part of the process can be automated. Whether the IANA can deal with automating such things, I don't know, but if not then it may just be a matter of tools availability. From stpeter@stpeter.im Thu Oct 22 13:21:30 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7293A68EB for ; Thu, 22 Oct 2009 13:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 elYTKouWgdm2 for ; Thu, 22 Oct 2009 13:21:30 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 01B353A659B for ; Thu, 22 Oct 2009 13:21:30 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0EED40341 for ; Thu, 22 Oct 2009 14:21:39 -0600 (MDT) Message-ID: <4AE0BED2.8060309@stpeter.im> Date: Thu, 22 Oct 2009 14:21:38 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: port registration (was: Re: [VCARDDAV] Lars DISCUSS on draft-ietf-vcarddav-carddav) X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 20:21:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The revised procedures in draft-ietf-tsvwg-iana-ports might have an interesting impact on AppsArea technologies, since we have registered a fair number of ports, DNS SRV records, etc. Has anyone here thought much about the potential impact? /psa - -------- Original Message -------- Subject: Re: [VCARDDAV] Lars DISCUSS on draft-ietf-vcarddav-carddav Date: Thu, 22 Oct 2009 16:04:47 -0400 From: Cyrus Daboo To: Simon Perreault , vcarddav@ietf.org References: <20091019114100.A27AD3A6862@core3.amsl.com> <4AE09897.3030208@isode.com> <4AE0B2EA.9020105@viagenie.ca> Hi Simon, - --On October 22, 2009 3:30:50 PM -0400 Simon Perreault wrote: >> 1). Register the new service names as aliases for ports 80/443 >> 2). Register 2 new port numbers >> 3). Don't do any change in this area, wait for >> draft-ietf-tsvwg-iana-ports to get published. > > 3 is the way to go. > > Naive suggestion: I think IANA will merge its port-numbers with Stuart > Cheshire's list once draft-ietf-tsvwg-iana-ports is published. Why not > add the SRV in that list until then? SRVs are scattered around all over the place. Stuart's list is one place, several RFCs also define some. At this point it would only confuse matters to have it in two places. The authors of iana-ports are fully aware that they need to go through RFCs and Stuarts data to pre-populate the new registry. - -- Cyrus Daboo _______________________________________________ VCARDDAV mailing list VCARDDAV@ietf.org https://www.ietf.org/mailman/listinfo/vcarddav -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrgvtIACgkQNL8k5A2w/vwzLQCgk3LCGpNodmixsFkbzA/9ya4d 6ywAoOdYCcu225Ax4CkVrUVhRjFkO3+y =yF7a -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Thu Oct 22 13:41:44 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA093A69F0 for ; Thu, 22 Oct 2009 13:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtceW5u48rs3 for ; Thu, 22 Oct 2009 13:41:43 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9EB683A6919 for ; Thu, 22 Oct 2009 13:41:42 -0700 (PDT) Received: from [192.168.0.6] (ool-457c2d3b.dyn.optonline.net [69.124.45.59]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Oct 2009 21:41:51 +0100 Message-ID: <4AE0C38A.6080804@isode.com> Date: Thu, 22 Oct 2009 21:41:46 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Peter Saint-Andre Subject: Re: port registration (was: Re: [VCARDDAV] Lars DISCUSS on draft-ietf-vcarddav-carddav) References: <4AE0BED2.8060309@stpeter.im> In-Reply-To: <4AE0BED2.8060309@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 20:41:45 -0000 Peter Saint-Andre wrote: > The revised procedures in draft-ietf-tsvwg-iana-ports might have an > interesting impact on AppsArea technologies, since we have registered a > fair number of ports, DNS SRV records, etc. Has anyone here thought much > about the potential impact? > Peter, I am going to be the sponsoring AD for this document and going to be tracking registry population after that. This is not to say that I wouldn't need any help, or that I really know what the impact going to be ;-). > /psa > > - -------- Original Message -------- > Subject: Re: [VCARDDAV] Lars DISCUSS on draft-ietf-vcarddav-carddav > Date: Thu, 22 Oct 2009 16:04:47 -0400 > From: Cyrus Daboo > To: Simon Perreault , vcarddav@ietf.org > References: <20091019114100.A27AD3A6862@core3.amsl.com> > <4AE09897.3030208@isode.com> <4AE0B2EA.9020105@viagenie.ca> > > Hi Simon, > > - --On October 22, 2009 3:30:50 PM -0400 Simon Perreault > wrote: > >>> 1). Register the new service names as aliases for ports 80/443 >>> 2). Register 2 new port numbers >>> 3). Don't do any change in this area, wait for >>> draft-ietf-tsvwg-iana-ports to get published. >>> >> 3 is the way to go. >> >> Naive suggestion: I think IANA will merge its port-numbers with Stuart >> Cheshire's list once draft-ietf-tsvwg-iana-ports is published. Why not >> add the SRV in that list until then? >> > SRVs are scattered around all over the place. Stuart's list is one place, > several RFCs also define some. At this point it would only confuse matters > to have it in two places. The authors of iana-ports are fully aware that > they need to go through RFCs and Stuarts data to pre-populate the new > registry. > > - -- > Cyrus Daboo From sm@resistor.net Thu Oct 22 15:27:49 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AFC43A68EF for ; Thu, 22 Oct 2009 15:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 RcchPHenYWrF for ; Thu, 22 Oct 2009 15:27:48 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 8C36D3A67C0 for ; Thu, 22 Oct 2009 15:27:46 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n9MMRiFl006874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Oct 2009 15:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1256250473; x=1256336873; bh=ws104g0S1TlsRr6yrlOBwTsJwQ6okPPkgLiet51NB/8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=RG+OZmuSlsmUmRqAgpUfqXWgZZU+BBOyxgN1cgtaUqqQTWegw1ZOhoVpdIeu7gRcZ lMRDrEdJaFF/RFdwssyBfdgp8rIXC5yC2qEWHr9ZLsTNx0m5UtIt8NNatGP0zAQsxw iO70F5h8HB/grdIPxVTfleTNZ071v/K7ta56YZyM= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=TrhEW5sKMMoYvV7JEtcXnGnRv4/jVlB+iNiP8LnZyid9vlqVVF8pvPF44gps89umq UbyZaQECIlbi5iXHOhKQJtfF87vQzMfY3NVscs3Y8m/fu3mKR2HZ7p2XIem/gkwiz6n dKelfssyDWXJbF9K4LsJui67xMAQKTHtVqivUAI= Message-Id: <6.2.5.6.2.20091022151821.04069dc0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Oct 2009 15:26:57 -0700 To: Peter Saint-Andre From: SM Subject: Re: port registration (was: Re: [VCARDDAV] Lars DISCUSS on draft-ietf-vcarddav-carddav) In-Reply-To: <4AE0BED2.8060309@stpeter.im> References: <4AE0BED2.8060309@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 22:27:49 -0000 Hi Peter, At 13:21 22-10-2009, Peter Saint-Andre wrote: >-----BEGIN PGP SIGNED MESSAGE----- >The revised procedures in draft-ietf-tsvwg-iana-ports might have an >interesting impact on AppsArea technologies, since we have registered a >fair number of ports, DNS SRV records, etc. Has anyone here thought much >about the potential impact? draft-ietf-tsvwg-iana-ports and draft-gudmundsson-dns-srv-iana-registry are set on a collision course. Regards, -sm From stpeter@stpeter.im Thu Oct 22 15:44:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423173A67EC for ; Thu, 22 Oct 2009 15:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 q3sArHTXHT5U for ; Thu, 22 Oct 2009 15:44:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 793F23A67C0 for ; Thu, 22 Oct 2009 15:44:27 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3181440341; Thu, 22 Oct 2009 16:44:37 -0600 (MDT) Message-ID: <4AE0E054.30905@stpeter.im> Date: Thu, 22 Oct 2009 16:44:36 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: port registration References: <4AE0BED2.8060309@stpeter.im> <4AE0C38A.6080804@isode.com> In-Reply-To: <4AE0C38A.6080804@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 22:44:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/22/09 2:41 PM, Alexey Melnikov wrote: > Peter Saint-Andre wrote: >> The revised procedures in draft-ietf-tsvwg-iana-ports might have an >> interesting impact on AppsArea technologies, since we have registered a >> fair number of ports, DNS SRV records, etc. Has anyone here thought much >> about the potential impact? >> > Peter, I am going to be the sponsoring AD for this document and going to > be tracking registry population after that. > This is not to say that I wouldn't need any help, or that I really know > what the impact going to be ;-). When is it due for IETF LC? I'll try to take a close look at it before then (and naturally we can have someone from the apps-review team go over it, too). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrg4FQACgkQNL8k5A2w/vwgMwCgomLBpPM3UKvfaA/525T7ZzPG Ou0AoOfB88QEB9Zg5kSmKp+jRJ+/MZuE =2AlG -----END PGP SIGNATURE----- From lars.eggert@nokia.com Fri Oct 23 00:31:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9913A67D1 for ; Fri, 23 Oct 2009 00:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 zgw6ew6dgZDb for ; Fri, 23 Oct 2009 00:31:44 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id D844F3A67AF for ; Fri, 23 Oct 2009 00:31:43 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9N7VjXn082404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Oct 2009 10:31:46 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Subject: Re: port registration (was: Re: [VCARDDAV] Lars DISCUSS on draft-ietf-vcarddav-carddav) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-72-950514740; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <6.2.5.6.2.20091022151821.04069dc0@resistor.net> Date: Fri, 23 Oct 2009 10:31:45 +0300 Message-Id: References: <4AE0BED2.8060309@stpeter.im> <6.2.5.6.2.20091022151821.04069dc0@resistor.net> To: SM X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Fri, 23 Oct 2009 10:31:47 +0300 (EEST) Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 07:31:45 -0000 --Apple-Mail-72-950514740 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 2009-10-23, at 1:26, SM wrote: > draft-ietf-tsvwg-iana-ports and > draft-gudmundsson-dns-srv-iana-registry are set on a collision course. True. I note that the first is an adopted IETF work item in TSVWG and the other one isn't. (Disclaimer: I'm an author of the first one.) Lars --Apple-Mail-72-950514740 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyMzA3MzE0NVowIwYJKoZIhvcNAQkEMRYEFCOVBEFcPuBSgvndePG7/0FApRTpMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDZfoFxmM4xGlKpnfvwkEGTrqbyLiVtUkB9ORgfQn0YmMTHa9QxMr7qEuUOB7qMZB7D+M7O 5hLKAzdRXG7t8cq5A0rv1ZUYu/tu+nuAoGj+dee7g8ZPGJPi6EEvtEcyHB38G0IumwMJKjOLX5Ze +KaAQuVXVWdr/+IYRLzYA3hKhvWJjIaG1aEd0wxMmLOruKU44i08ef4adYxAht7VLK6Y3BjiWJwI oz6F2zG0mYwAxF6uwiCdAEv3fE7r61y30PTKjmgYmIm2GSYzaRYw9dJxSBTq9iW4ThjeKJD8t7cf HfUs8XXw0rmugKFY9TWnQi3/n7gowioQTzec5YHKs/w8AAAAAAAA --Apple-Mail-72-950514740-- From A.Hoenes@TR-Sys.de Fri Oct 23 14:53:59 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14CD3A6841 for ; Fri, 23 Oct 2009 14:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.039 X-Spam-Level: ** X-Spam-Status: No, score=2.039 tagged_above=-999 required=5 tests=[AWL=0.788, 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 9x76DGIO8ZVZ for ; Fri, 23 Oct 2009 14:53:59 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 4797E3A67FA for ; Fri, 23 Oct 2009 14:53:58 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA297994801; Fri, 23 Oct 2009 23:53:21 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA18889; Fri, 23 Oct 2009 23:53:20 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910232153.XAA18889@TR-Sys.de> Subject: Re: draft-nottingham-site-meta: registration too slow, opaque To: conolly@w3.org, apps-discuss@ietf.org Date: Fri, 23 Oct 2009 23:53:19 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 21:53:59 -0000 Based on the thread subjects used on this list and elsewhere, and confirmed by a simple lookup in the IETF Datatracker, that draft is in IETF Last Call ( running till Nov 6, 2009 ). How could you expect IANA taking action before end of LC and subsequent (potential) approval of the draft by the IESG, (after evaluation of the LC results) for publication as an RFC? Unless I grossly misunderstand collected wisdom: Whenever a registration request (forcibly or voluntarily) follows "IETF Review" process rules, the IANA registration will be embedded in the RFC Editor processing of the approved draft and become effective with the publication of the RFC. See RFC 5226. More precisely: IANA comments on the draft during LC to the IESG, and the RFC Editor process will trigger actual IANA processing that indeed is being tracked; everything before is at an informal level. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Sun Oct 25 14:46:18 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D24C3A682A; Sun, 25 Oct 2009 14:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.012 X-Spam-Level: ** X-Spam-Status: No, score=2.012 tagged_above=-999 required=5 tests=[AWL=0.761, 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 7uLGguAynJV7; Sun, 25 Oct 2009 14:46:17 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id CDEEA3A6801; Sun, 25 Oct 2009 14:46:13 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA006867030; Sun, 25 Oct 2009 22:43:50 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA24711; Sun, 25 Oct 2009 22:43:43 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910252143.WAA24711@TR-Sys.de> Subject: Re: port registration (was: Re: [VCARDDAV] Lars DISCUSS on draft-ietf-vcarddav-carddav) To: apps-discuss@ietf.org, tsvwg@ietf.org Date: Sun, 25 Oct 2009 22:43:42 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 21:46:18 -0000 At Fri, 23 Oct 2009 10:31:45 +0300, Lars Eggert wrote: > On 2009-10-23, at 1:26, SM wrote: > > draft-ietf-tsvwg-iana-ports and > draft-gudmundsson-dns-srv-iana-registry are set on a collision course. > > True. I note that the first is an adopted IETF work item in TSVWG > and the other one isn't. > > (Disclaimer: I'm an author of the first one.) > > Lars The TSVWG Charter mentions this subject only in a milestone: | December 2009 Request publication of 'IANA Procedures for the | Transport Protocol Port Number Space' as BCP RFC This corresponds to the scope of the individual draft that had been adopted by the group and that has been maintained in the wg -00 and -01 revisions of the draft. It was the recent -02 draft version that grossly extended the scope after the authors had been asked to delineate and coordinate with the DNS SRV IANA registry draft. The "Transport Protocol Port Number Space" quoted above is different from the "DNS SRV Service Prefix" name space, and as far as I can see, guidelines for service discovery and the application and use of the Nomain Name System (DNS) do not fall under the chartered scope of TSVWG (see: http://www.ietf.org/dyn/wg/charter/tsvwg-charter.html) nor the Transport Area in general. I therefore suggest that the scope of draft-ietf-tsvwg-iana-ports indeed be restricted to what it has been previously, in accordance with the milestone in the TSVWG charter.. (Disclaimer: I'm co-author of draft-gudmundsson-dns-srv-iana-registry) Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From lars.eggert@nokia.com Mon Oct 26 00:44:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9226F3A68B4; Mon, 26 Oct 2009 00:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 80H2KW9Ac4ZZ; Mon, 26 Oct 2009 00:44:26 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 14A8C3A682C; Mon, 26 Oct 2009 00:44:25 -0700 (PDT) Received: from wlan-226.fit.nokia.com (wlan-226.fit.nokia.com [195.148.124.226]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9Q7iUh6065634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Oct 2009 09:44:30 +0200 (EET) (envelope-from lars.eggert@nokia.com) Subject: Re: port registration (was: Re: [VCARDDAV] Lars DISCUSS on draft-ietf-vcarddav-carddav) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-5--937003907; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <200910252143.WAA24711@TR-Sys.de> Date: Mon, 26 Oct 2009 09:44:30 +0200 Message-Id: <5716800D-1E23-4AA2-8968-C4120C5DCF68@nokia.com> References: <200910252143.WAA24711@TR-Sys.de> To: ah@tr-sys.de X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Mon, 26 Oct 2009 09:44:31 +0200 (EET) Cc: "tsvwg@ietf.org" , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 07:44:27 -0000 --Apple-Mail-5--937003907 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Hi, On 2009-10-25, at 23:43, ah@tr-sys.de wrote: > At Fri, 23 Oct 2009 10:31:45 +0300, Lars Eggert wrote: >> True. I note that the first is an adopted IETF work item in TSVWG >> and the other one isn't. > > The TSVWG Charter mentions this subject only in a milestone: > > | December 2009 Request publication of 'IANA Procedures for the > | Transport Protocol Port Number Space' as BCP RFC What do you mean "only?" It's not like there are several classes of WG =20= work items. > This corresponds to the scope of the individual draft that had been > adopted by the group and that has been maintained in the wg -00 and > -01 revisions of the draft. Of course we're going to ask the WG if there is consensus for the =20 changes that were made since the last meeting in -02 (and -03, which =20 should be available soon.) > It was the recent -02 draft version > that grossly extended the scope after the authors had been asked > to delineate and coordinate with the DNS SRV IANA registry draft. This sounds like you're saying that we purposefully made huge changes =20= to the document in order to create a conflict with draft-gudmundsson. =20= That is not the case. It was the intent that this work item would also =20= define rules for service names, and this was clearly communicated the =20= entire time, see for example "Open Issues" on = https://www.ietf.org/proceedings/72/slides/tsvwg-3/tsvwg-3.htm=20 . I'm not going to argue that it has taken us longer than expected to =20 write this stuff up, however. > The "Transport Protocol Port Number Space" quoted above is different > from the "DNS SRV Service Prefix" name space, and as far as I can see, > guidelines for service discovery and the application and use of the > Nomain Name System (DNS) do not fall under the chartered scope of > TSVWG (see: http://www.ietf.org/dyn/wg/charter/tsvwg-charter.html) > nor the Transport Area in general. We are in disagreement whether there actually is a separate "DNS SRV =20 Service Prefix" namespace. There certainly are service names, most of which are recorded in the =20 "short name" column of the ports registry, some of which are recorded =20= in the "protocol and service names" registry, and some of which are =20 listed in a private registry maintained by Stuart. Our intent is to =20 merge these registries into one, and the (to us) logical place is the =20= ports registry, because it already has the vast majority of such =20 entries in it; and we need to create rules that define how ports and =20 service names interrelate, esp. if a set of management actions happens =20= over time to the entries associated with one service. (First you =20 register just a service name, then later you register a port for one =20 protocol, etc.) Now, service names are certainly used for DNS SRV RRs, but that is =20 *not their only use*. This is why I think that creating a new registry =20= and set of registration procedures just for DNS SRV RRs isn't going to =20= solve the problem. Lars > I therefore suggest that the scope of draft-ietf-tsvwg-iana-ports > indeed be restricted to what it has been previously, in accordance > with the milestone in the TSVWG charter.. > > > (Disclaimer: I'm co-author of draft-gudmundsson-dns-srv-iana-registry) > > Kind regards, > Alfred H=CEnes. > > --=20 > > +------------------------=20 > +--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-=20 > Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: =20 > -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-=20 > Sys.de | > +------------------------=20 > +--------------------------------------------+ > --Apple-Mail-5--937003907 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyNjA3NDQzMFowIwYJKoZIhvcNAQkEMRYEFMo588cbsl0ksG7OQsBfhZDJFoQ8MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAb9Kfk7F017DpAGs9F1JhWtcLNFb39e5XYUeKh83ZqiBhl27NuAn6CJodo1+xL5Im9BzYZ MGTYhrWXwtoBXKKgu+4R+8oOcxLXJ/23YeC0PlyIhXnPtQA/cucom6lmqxdIOF4co/r4EZN53VUF e+D8mlDWAXGFoSfbX3TiqBSCgVZ/foY5LPLu8JytvI/qqzy16HviSCrMV0gs1Smin/TkFowj+IGr ecA/Z29NCqN6vmUI9n60y8N9LMmO4vDI2GloJQ/kTKtNv7KspSvlXDmAD8IteDQUdVzKvLmpNp7o t0LP4nCMDert7y3aOqwDUh7MqA65gwTjmZDds+DzdRDnAAAAAAAA --Apple-Mail-5--937003907-- From stpeter@stpeter.im Mon Oct 26 16:03:08 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3409928C333 for ; Mon, 26 Oct 2009 16:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 4ofeEMjsgy2V for ; Mon, 26 Oct 2009 16:03:07 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3B89528C3BC for ; Mon, 26 Oct 2009 16:03:07 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9F7D7400F6 for ; Mon, 26 Oct 2009 17:03:20 -0600 (MDT) Message-ID: <4AE62AB7.8080607@stpeter.im> Date: Mon, 26 Oct 2009 17:03:19 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: Identity Checking in Application Protocols X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 23:03:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I had hoped to update draft-saintandre-tls-server-id-check before the submission cutoff today, but it's not going to happen because there's quite a bit of feedback to sift through (ideally I would have followed the list discussions more closely the first time around). However, I shall work to update it in the next few days, at which time I will also rename it to remove the strings "tls" and "server" since the scope of the spec has widened to include non-TLS interactions as well as client identity checking. My apologies for the delay. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrmKrcACgkQNL8k5A2w/vzfTwCfaOtoWUS6yE8r1kaAoo70Ae3f Ng4AnjBF+Y/k7EKxE47IhXwIcBIPdu7h =uuU1 -----END PGP SIGNATURE----- From shinta@sfc.wide.ad.jp Mon Oct 26 18:37:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D373A67A6 for ; Mon, 26 Oct 2009 18:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.393 X-Spam-Level: ** X-Spam-Status: No, score=2.393 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzXhtJ7LUZGY for ; Mon, 26 Oct 2009 18:37:56 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id D05C13A67B8 for ; Mon, 26 Oct 2009 18:37:56 -0700 (PDT) Received: from localhost.localdomain (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 177B64C182 for ; Tue, 27 Oct 2009 10:38:06 +0900 (JST) Message-ID: <4AE64BB0.1020108@sfc.wide.ad.jp> Date: Tue, 27 Oct 2009 10:24:00 +0900 From: Shinta Sugimoto User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: draft-ietf-shim6-multihome-shim-api-10 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 01:37:57 -0000 Hi, Let me inform you that we have submitted the following draft: http://tools.ietf.org/html/draft-ietf-shim6-multihome-shim-api-10 The document provides a means for applications to control locator information (e.g., set preferred locator (=IP address) when sending IP packets). Besides, the document provides a way for applications to interact with failure detection mechanism inside the multihoming shim sub-layer (such as informing the status of application session). The base of the draft is SHIM6 WG, but we'd appreciate any feedbacks from people working on application development. Thank you. Regards, Shinta From James.H.Manger@team.telstra.com Mon Oct 26 22:01:38 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544263A684F for ; Mon, 26 Oct 2009 22:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 1GtOjwtgiSd4 for ; Mon, 26 Oct 2009 22:01:37 -0700 (PDT) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 3225A3A6821 for ; Mon, 26 Oct 2009 22:01:35 -0700 (PDT) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 27 Oct 2009 16:01:49 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id BAEACFF85 for ; Tue, 27 Oct 2009 16:01:48 +1100 (EST) Received: from wsmsg3757.srv.dir.telstra.com (wsmsg3757.srv.dir.telstra.com [172.49.40.85]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA03505 for ; Tue, 27 Oct 2009 16:01:48 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Tue, 27 Oct 2009 16:01:43 +1100 From: "Manger, James H" To: "apps-discuss@ietf.org" Date: Tue, 27 Oct 2009 16:01:42 +1100 Subject: host-meta: template syntax hassles Thread-Topic: host-meta: template syntax hassles Thread-Index: AcpWwpMrO2fBkK/zTVK4PvsTZrNbFQ== Message-ID: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112485B4116WSMSG3153Vsrv_" MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 05:01:38 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112485B4116WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ZHJhZnQtaGFtbWVyLWhvc3RtZXRhLTAyPGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNtYXJrdXA/ ZG9jPWRyYWZ0LWhhbW1lci1ob3N0bWV0YSNzZWN0aW9uLTMuMi4xPiDigJxIb3N0LU1ldGE6IFdl YiBIb3N0IE1ldGFkYXRh4oCdIGRlZmluZXMgYSBVUkkgdGVtcGxhdGUgc3ludGF4IGFuZCB2YXJp YWJsZXMgYmFzZWQgb24gcGFydHMgb2YgYSBVUkkgW8KnMy4yLjEuXS4NCg0KDQoNCkkgZG9u4oCZ dCB0aGluayB0aGUgY3VycmVudCBhcnJhbmdlbWVudCBjYW4gd29yayBhcyBlYXNpbHkgYXMgdGhl IGV4YW1wbGVzIGluIHRoZSBkcmFmdCBzdWdnZXN0Lg0KDQoNCg0KVGhlIGV4YW1wbGUgb2YgYSBs aW5rIHRvIGVhY2ggcmVzb3VyY2XigJlzIGF1dGhvciBwcmVzdW1hYmx5IHdhbnRzIOKAnDtieeKA nSB0byBiZSBhcHBlbmRlZCB0byB0aGUgcmVzb3VyY2UgVVJJ4oCZcyBwYXRoIOKAlCBidXQgdGhh dCBpcyBub3Qgd2hhdCB0aGUg4oCceyt1cml9O2J54oCdIHRlbXBsYXRlIGRvZXMuDQoNCiAgPExp bms+IDxSZWw+YXV0aG9yPC9SZWw+IDxVUklUZW1wbGF0ZT57K3VyaX07Ynk8L1VSSVRlbXBsYXRl PiA8L0xpbms+DQoNCkZvciBVUklzIHdpdGggcXVlcnkgc3RyaW5ncywg4oCcO2J54oCdIGlzIGFw cGVuZGVkIHRvIHRoZSBsYXN0IHF1ZXJ5IHBhcmFtZXRlciB2YWx1ZS4gVGhpcyBpcyBhbG1vc3Qg Y2VydGFpbmx5IE5PVCBkZXNpcmVkLiBUaGUgb3JkZXIgb2YgcXVlcnkgcGFyYW1ldGVycyBpcyBu b3JtYWxseSBpcnJlbGV2YW50IGJ1dCB0aGlzIHRlbXBsYXRlIGNoYW5nZXMgdGhlIHZhbHVlIG9m IHdoaWNoZXZlciBwYXJhbWV0ZXIgaGFwcGVucyB0byBiZSBsYXN0Lg0KDQoNCg0KQSBtb3JlIGNv cnJlY3QgdGVtcGxhdGUgaXMgcHJvYmFibHk6IOKAnHsrc2NoZW1lfTovL3srYXV0aG9yaXR5fXsr cGF0aH07Ynk/eytxdWVyeX3igJ0NCg0KSSBhbSBub3Qgc3VyZSB0aGF0IGV2ZW4gdGhpcyBpcyBj b3JyZWN0IGlmIHRoZSBwYXRoIGlzIGVtcHR5IChlZyB5b3UgbWF5IGdldCB0aGUgaW52YWxpZCBV Ukkg4oCcaHR0cDovL2V4YW1wbGUubmV0O2J5P+KAnSkNCg0KVGhlcmUgd2lsbCBhbHNvIGJlIGEg dHJhaWxpbmcg4oCcP+KAnSB3aGVuIHRoZXJlIGFyZSBubyBxdWVyeSBwYXJhbWV0ZXJzLCB3aGlj aCBtYXkgYmUgbW9zdGx5IGhhcm1sZXNzLCBidXQgaXMgc3RyaWN0bHkgZGlmZmVyZW50IGZyb20g YSBVUkkgd2l0aG91dCB0aGUg4oCcP+KAnSBzbyBjYWNoaW5nIGFuZCBjb21wYXJpc29ucyBhcmUg YWR2ZXJzZWx5IGFmZmVjdGVkLg0KDQoNCg0KQW5vdGhlciBleGFtcGxlIGZyb20gdGhlIGRyYWZ0 IGlzIOKAnHsrdXJpfSZ0ZXN04oCdLiBUaGlzIGVpdGhlciBtYWtlcyDigJwmdGVzdOKAnSBwYXJ0 IG9mIHRoZSBwYXRoLCBvciBhIG5ldyBxdWVyeSBwYXJhbWV0ZXIgKGRlcGVuZGluZyBvbiB3aGV0 aGVyIG9yIG5vdCB0aGUgVVJJIGFscmVhZHkgaGFzIGEgcXVlcnkgc3RyaW5nKS4gVGhpcyBpcyBw cm9iYWJseSBuZXZlciBkZXNpcmFibGUuIElmIGEgdGVtcGxhdGUgd2FudHMgdG8gYWRkIGEgcXVl cnkgcGFyYW1ldGVyIGl0IHByb2JhYmx5IG5lZWRzIHRvIHNwZWNpZnkNCg0KICDigJx7K3NjaGVt ZX06Ly97K2F1dGhvcml0eX17K3BhdGh9P3srcXVlcnl9JnRlc3TigJ0uDQoNCkV2ZW4gdGhpcyBp cyBub3QgaWRlYWwgYXMgaXQgcHJvZHVjZXMgdW51c3VhbCBVUklzIHN1Y2ggYXMg4oCcaHR0cDov L2V4YW1wbGUubmV0L2FydGljbGU/JnRlc3TigJ0sIHdoaWNoIGFnYWluIG1heSBiZSBtb3N0bHkg aGFybWxlc3MgYnV0IGlzIHN0cmljdGx5IGRpZmZlcmVudCBmcm9tIGEgVVJJIHdpdGgganVzdCDi gJw/dGVzdOKAnSBzbyBjYWNoaW5nIGFuZCBjb21wYXJpc29ucyBhcmUgYWR2ZXJzZWx5IGFmZmVj dGVkLg0KDQoNCg0KQW5vdGhlciBleGFtcGxlIGZyb20gdGhlIHNwZWMgaXMg4oCcaHR0cDovL21l dGEue2hvc3R9OjgwODB7K3BhdGh9P3srcXVlcnl94oCdLg0KDQpJZiBzb21lIFVSSXMgbWlnaHQg aGF2ZSBhIHVzZXJpbmZvIGNvbXBvbmVudCB0aGVuIHRoZSB0ZW1wbGF0ZSBuZWVkcyB0byBiZSDi gJxodHRwOi8veyt1c2VyaW5mb31AbWV0YS57aG9zdH06ODA4MHsrcGF0aH0/eytxdWVyeX3igJ0u IEhvd2V2ZXIsIHdoZW4gdGhlcmUgaXMgbm8gdXNlcmluZm8gdGhlIHJlc3VsdGluZyBVUkkgc3Rh cnRzIGh0dHA6Ly9A4oCmIHRoYXQgKGluIHNvbWUgY2xpZW50cyBhdCBsZWFzdCwgZWcgY3VybCkg Y2F1c2VzIGEg4oCcQXV0aG9yaXphdGlvbjogQmFzaWMgT2c9PeKAnSBoZWFkZXIgdG8gYmUgaW5j bHVkZWQgd2hlbiByZXF1ZXN0aW5nIHRoZSBVUkkuIFRoYXQgY291bGQgYmUgaGFybWZ1bC4NCg0K UC5TLiBJdCBzaG91bGQgcHJvYmFibHkgYWxzbyB1c2Ugeytob3N0fSwgaW5zdGVhZCBvZiB7aG9z dH0uDQoNCg0KDQoNCg0KVGhlIG1pbmltYWwgKHBhcnRpYWwpIHNvbHV0aW9uIGlzIHRvIGNoYW5n ZSB0aGUgZXhhbXBsZXMgaW4gdGhlIGRyYWZ0IHRvIGJlIHJlYWxpc3RpYyAoZWcgd29yayBmb3Ig YWxsIFVSSXMgaW4gdGhlIHNjb3BlLCB3aXRoIG9yIHdpdGhvdXQgcXVlcnkgc3RyaW5ncykuDQoN Cg0KDQpBbm90aGVyIHNvbHV0aW9uIGlzIHRvIGRlZmluZSBhIG1vcmUgc29waGlzdGljYXRlZCB0 ZW1wbGF0ZSBzeW50YXguIEEgc3ludGF4IHRoYXQgbGlzdHMgYSBwcmVmaXggdGhhdCBpcyBvbmx5 IHN1YnN0aXR1dGVkIHdoZW4gdGhlIHZhcmlhYmxlIGlzIGRlZmluZWQgKG5vbi1udWxsKSBtYXkg YmUgYWxtb3N0IHN1ZmZpY2llbnQuIFRoYXQgYWRkcmVzcyB0aGUgcHJvYmxlbSB0aGF0IHRoZSBk ZWZpbmVkIHZhcmlhYmxlcyBmb3IgVVJJIHBhcnRzIChzY2hlbWUsIGF1dGhvcml0eSwgcXVlcnks IGZyYWdtZW50LCB1c2VyaW5mbywgaG9zdCwgcG9ydCkgZG9u4oCZdCBpbmNsdWRlIHRoZSBzZXBh cmF0b3IgY2hhcmFjdGVycyB1c2VkIHdoZW4gY29tYmluaW5nIHRoZSBwYXJ0cy4NCg0KDQoNCg0K DQpJbiB0aGUgaG9zdC1tZXRhIGNhc2UgYSBiZXR0ZXIgc29sdXRpb24gd291bGQgYmUgdG8gZGVm aW5lIHRoZSB0cmFuc2xhdGlvbiBmcm9tIHJlc291cmNlIFVSSSB0byBsaW5rIFVSSSB3aXRoIGEg cmVndWxhciBleHByZXNzaW9uIGFuZCByZXBsYWNlbWVudCBzdHJpbmcuIFRoZSByZXBsYWNlbWVu dCBzdHJpbmcgY2FuIHJlZmVyZW5jZSDigJxjYXB0dXJpbmcgZ3JvdXBz4oCdIGluIHRoZSByZWd1 bGFyIGV4cHJlc3Npb24uIEkgYW0gc3VyZSBhbGwgbW9kZXJuIHByb2dyYW1taW5nIGxhbmd1YWdl cyBvZmZlciBicm9hZGx5IHNpbWlsYXIgcmVnZXgtYmFzZWQgcmVwbGFjZW1lbnQgZnVuY3Rpb25h bGl0eS4gRm9yIGluc3RhbmNlLCBmb3IgSmF2YSBzZWUgU3RyaW5nI3JlcGxhY2VGaXJzdChyZWdl eCwgcmVwbGFjZW1lbnQpPGh0dHA6Ly9qYXZhLnN1bi5jb20vamF2YXNlLzYvZG9jcy9hcGkvamF2 YS9sYW5nL1N0cmluZy5odG1sI3JlcGxhY2VBbGwoamF2YS5sYW5nLlN0cmluZywlMjBqYXZhLmxh bmcuU3RyaW5nKT4gYW5kIE1hdGNoZXIuYXBwZW5kUmVwbGFjZW1lbnQ8aHR0cDovL2phdmEuc3Vu LmNvbS9qYXZhc2UvNi9kb2NzL2FwaS9qYXZhL3V0aWwvcmVnZXgvTWF0Y2hlci5odG1sI2FwcGVu ZFJlcGxhY2VtZW50JTI4amF2YS5sYW5nLlN0cmluZ0J1ZmZlciwlMjBqYXZhLmxhbmcuU3RyaW5n JTI5Pi4NCg0KDQoNClRoZW4gdGhlIHF1ZXN0aW9uIGlzIHdoZXJlIGlzIHRoZSByZWdleCBzcGVj aWZpZWQ6IGluIHRoZSA8TGluaz4gb3IgYXMgdGhlIDxTdWJqZWN0Pj8NCg0KVXNpbmcgYSByZWd1 bGFyIGV4cHJlc3Npb24gdG8gaW5kaWNhdGUgYWxsIHRoZSBVUklzIHRoYXQgdGhlIG1ldGFkYXRh IChYUkQpIGFwcGxpZXMgdG8gKGllIHRoZSBYUkTigJlzIHN1YmplY3QpIGZlZWxzIGZsZXhpYmxl IGFuZCBhcHByb3ByaWF0ZS4gSG9zdC1tZXRhIHdvdWxkIG5vdCBuZWVkIHRvIGJlIGEgc3BlY2lh bCBjYXNlIHdpdGggaXRzIG93biA8aG9zdC1tZXRhOlNjb3BlPi4gTWV0YWRhdGEgdGhhdCBhcHBs aWVkIHRvIGFsbCB0aGUgVVJJcyBpbiBhIHN1YmRpcmVjdG9yeSAoZWcgYWxsIHVuZGVyIC9ibG9n LyopIHdvdWxkIGJlIGVhc3kgdG8gZGVmaW5lLg0KDQoNCg0KPFhSRD4NCg0KIDxTdWJqZWN0UmVn ZXg+aHR0cHM/Oi8vKD86d3d3XC4pP2V4YW1wbGVcLmNvbS8oW14/I10qKShcP1teI10qKT8oI1wu Kik/PC9TdWJqZWN0UmVnZXg+DQoNCiA8TGluaz48UmVsPmF1dGhvcjwvUmVsPjxVUklQYXR0ZXJu Pmh0dHBzOi8vd3d3LmV4YW1wbGUuY29tL1wxO2J5XDI8L1VSTFBhdHRlcm4+PC9MaW5rPg0KDQo8 L1hSRD4NCg0KDQoNCkl0IGlzIGEgcGl0eSByZWdleHMgY2FuIGJlIGF3a3dhcmQgdG8gd3JpdGUg KCYgaGFyZGVyIHRvIHJlYWQpLiBJbmNsdWRpbmcgYW4gZXhhbXBsZSAob3IgZGVmYXVsdCB2YWx1 ZT8pIGluIHRoZSBzcGVjIHRoYXQgY2FwdHVyZXMgdGhlIHNjaGVtZSwgYXV0aG9yaXR5LCBwYXRo LCBxdWVyeSAmIGZyYWdtZW50IGNvdWxkIGJlIGFsbW9zdCBlcXVpdmFsZW50IHRvIHRoZSBjdXJy ZW50IHRlbXBsYXRlIHByb3Bvc2FsICh3aXRoIG11Y2ggbW9yZSBmbGV4aWJpbGl0eSwgYnV0IGxl c3MgZnJpZW5kbHkgdmFyaWFibGUgbmFtZXMpLg0KDQoNCg0KDQoNCkphbWVzIE1hbmdlcg0KSmFt ZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50 ZWxzdHJhLmNvbT4NCklkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGllZiBUZWNobm9s b2d5IE9mZmljZSDigJQgVGVsc3RyYQ0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E112485B4116WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnBy ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9yZmNtYXJrdXA/ZG9jPWRyYWZ0LWhhbW1lci1ob3N0bWV0YSNzZWN0aW9uLTMuMi4xIj5kcmFm dC1oYW1tZXItaG9zdG1ldGEtMDI8L2E+IOKAnEhvc3QtTWV0YTogV2ViIEhvc3QgTWV0YWRhdGHi gJ0gZGVmaW5lcyBhIFVSSSB0ZW1wbGF0ZSBzeW50YXggYW5kIHZhcmlhYmxlcyBiYXNlZCBvbiBw YXJ0cyBvZiBhIFVSSSBbwqczLjIuMS5dLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKA mXQgdGhpbmsgdGhlIGN1cnJlbnQgYXJyYW5nZW1lbnQgY2FuIHdvcmsgYXMgZWFzaWx5IGFzIHRo ZSBleGFtcGxlcyBpbiB0aGUgZHJhZnQgc3VnZ2VzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIGV4YW1wbGUgb2YgYSBsaW5rIHRvIGVhY2ggcmVzb3VyY2XigJlzIGF1dGhvciBwcmVzdW1h Ymx5IHdhbnRzIOKAnDtieeKAnSB0byBiZSBhcHBlbmRlZCB0byB0aGUgcmVzb3VyY2UgVVJJ4oCZ cyBwYXRoIOKAlCBidXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUg4oCceyYjNDM7dXJpfTtieeKAnSB0 ZW1wbGF0ZSBkb2VzLjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsgJmx0O0xpbmsmZ3Q7ICZs dDtSZWwmZ3Q7YXV0aG9yJmx0Oy9SZWwmZ3Q7ICZsdDtVUklUZW1wbGF0ZSZndDt7JiM0Mzt1cml9 O2J5Jmx0Oy9VUklUZW1wbGF0ZSZndDsgJmx0Oy9MaW5rJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgVVJJcyB3aXRoIHF1ZXJ5IHN0cmluZ3MsIOKAnDtieeKA nSBpcyBhcHBlbmRlZCB0byB0aGUgbGFzdCBxdWVyeSBwYXJhbWV0ZXIgdmFsdWUuIFRoaXMgaXMg YWxtb3N0IGNlcnRhaW5seSBOT1QgZGVzaXJlZC4gVGhlIG9yZGVyIG9mIHF1ZXJ5IHBhcmFtZXRl cnMgaXMgbm9ybWFsbHkgaXJyZWxldmFudCBidXQgdGhpcyB0ZW1wbGF0ZSBjaGFuZ2VzIHRoZSB2 YWx1ZSBvZiB3aGljaGV2ZXIgcGFyYW1ldGVyIGhhcHBlbnMNCiB0byBiZSBsYXN0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BIG1vcmUgY29ycmVjdCB0ZW1wbGF0ZSBpcyBwcm9iYWJseTog4oCc eyYjNDM7c2NoZW1lfTovL3smIzQzO2F1dGhvcml0eX17JiM0MztwYXRofTtieT97JiM0MztxdWVy eX3igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IHN1cmUg dGhhdCBldmVuIHRoaXMgaXMgY29ycmVjdCBpZiB0aGUgcGF0aCBpcyBlbXB0eSAoZWcgeW91IG1h eSBnZXQgdGhlIGludmFsaWQgVVJJIOKAnGh0dHA6Ly9leGFtcGxlLm5ldDtieT/igJ0pPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSB3aWxsIGFsc28gYmUgYSB0cmFp bGluZyDigJw/4oCdIHdoZW4gdGhlcmUgYXJlIG5vIHF1ZXJ5IHBhcmFtZXRlcnMsIHdoaWNoIG1h eSBiZSBtb3N0bHkgaGFybWxlc3MsIGJ1dCBpcyBzdHJpY3RseSBkaWZmZXJlbnQgZnJvbSBhIFVS SSB3aXRob3V0IHRoZSDigJw/4oCdIHNvIGNhY2hpbmcgYW5kIGNvbXBhcmlzb25zIGFyZSBhZHZl cnNlbHkgYWZmZWN0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFub3RoZXIgZXhhbXBsZSBm cm9tIHRoZSBkcmFmdCBpcyDigJx7JiM0Mzt1cml9JmFtcDt0ZXN04oCdLiBUaGlzIGVpdGhlciBt YWtlcyDigJwmYW1wO3Rlc3TigJ0gcGFydCBvZiB0aGUgcGF0aCwgb3IgYSBuZXcgcXVlcnkgcGFy YW1ldGVyIChkZXBlbmRpbmcgb24gd2hldGhlciBvciBub3QgdGhlIFVSSSBhbHJlYWR5IGhhcyBh IHF1ZXJ5IHN0cmluZykuIFRoaXMgaXMgcHJvYmFibHkgbmV2ZXIgZGVzaXJhYmxlLiBJZiBhIHRl bXBsYXRlIHdhbnRzDQogdG8gYWRkIGEgcXVlcnkgcGFyYW1ldGVyIGl0IHByb2JhYmx5IG5lZWRz IHRvIHNwZWNpZnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwO+KAnHsmIzQzO3NjaGVtZX06Ly97JiM0MzthdXRob3JpdHl9eyYjNDM7cGF0aH0/eyYjNDM7 cXVlcnl9JmFtcDt0ZXN04oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RXZlbiB0aGlzIGlzIG5vdCBpZGVhbCBhcyBpdCBwcm9kdWNlcyB1bnVzdWFsIFVSSXMgc3VjaCBh cyDigJw8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5uZXQvYXJ0aWNsZT8mYW1wO3Rlc3QiPmh0dHA6 Ly9leGFtcGxlLm5ldC9hcnRpY2xlPyZhbXA7dGVzdDwvYT7igJ0sIHdoaWNoIGFnYWluIG1heSBi ZSBtb3N0bHkgaGFybWxlc3MgYnV0IGlzIHN0cmljdGx5IGRpZmZlcmVudCBmcm9tIGEgVVJJIHdp dGgganVzdCDigJw/dGVzdOKAnSBzbyBjYWNoaW5nDQogYW5kIGNvbXBhcmlzb25zIGFyZSBhZHZl cnNlbHkgYWZmZWN0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFub3RoZXIgZXhhbXBsZSBm cm9tIHRoZSBzcGVjIGlzIOKAnGh0dHA6Ly9tZXRhLntob3N0fTo4MDgweyYjNDM7cGF0aH0/eyYj NDM7cXVlcnl94oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc29t ZSBVUklzIG1pZ2h0IGhhdmUgYSB1c2VyaW5mbyBjb21wb25lbnQgdGhlbiB0aGUgdGVtcGxhdGUg bmVlZHMgdG8gYmUg4oCcaHR0cDovL3smIzQzO3VzZXJpbmZvfUBtZXRhLntob3N0fTo4MDgweyYj NDM7cGF0aH0/eyYjNDM7cXVlcnl94oCdLiBIb3dldmVyLCB3aGVuIHRoZXJlIGlzIG5vIHVzZXJp bmZvIHRoZSByZXN1bHRpbmcgVVJJIHN0YXJ0cyBodHRwOi8vQOKApiB0aGF0IChpbiBzb21lIGNs aWVudHMgYXQgbGVhc3QsIGVnIGN1cmwpDQogY2F1c2VzIGEg4oCcQXV0aG9yaXphdGlvbjogQmFz aWMgT2c9PeKAnSBoZWFkZXIgdG8gYmUgaW5jbHVkZWQgd2hlbiByZXF1ZXN0aW5nIHRoZSBVUkku IFRoYXQgY291bGQgYmUgaGFybWZ1bC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlAuUy4gSXQgc2hvdWxkIHByb2JhYmx5IGFsc28gdXNlIHsmIzQzO2hvc3R9LCBpbnN0ZWFk IG9mIHtob3N0fS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbWluaW1hbCAocGFydGlhbCkgc29sdXRpb24gaXMg dG8gY2hhbmdlIHRoZSBleGFtcGxlcyBpbiB0aGUgZHJhZnQgdG8gYmUgcmVhbGlzdGljIChlZyB3 b3JrIGZvciBhbGwgVVJJcyBpbiB0aGUgc2NvcGUsIHdpdGggb3Igd2l0aG91dCBxdWVyeSBzdHJp bmdzKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5vdGhlciBzb2x1dGlvbiBpcyB0byBkZWZp bmUgYSBtb3JlIHNvcGhpc3RpY2F0ZWQgdGVtcGxhdGUgc3ludGF4LiBBIHN5bnRheCB0aGF0IGxp c3RzIGEgcHJlZml4IHRoYXQgaXMgb25seSBzdWJzdGl0dXRlZCB3aGVuIHRoZSB2YXJpYWJsZSBp cyBkZWZpbmVkIChub24tbnVsbCkgbWF5IGJlIGFsbW9zdCBzdWZmaWNpZW50LiBUaGF0IGFkZHJl c3MgdGhlIHByb2JsZW0gdGhhdCB0aGUgZGVmaW5lZCB2YXJpYWJsZXMNCiBmb3IgVVJJIHBhcnRz IChzY2hlbWUsIGF1dGhvcml0eSwgcXVlcnksIGZyYWdtZW50LCB1c2VyaW5mbywgaG9zdCwgcG9y dCkgZG9u4oCZdCBpbmNsdWRlIHRoZSBzZXBhcmF0b3IgY2hhcmFjdGVycyB1c2VkIHdoZW4gY29t YmluaW5nIHRoZSBwYXJ0cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgaG9zdC1tZXRhIGNhc2UgYSBiZXR0 ZXIgc29sdXRpb24gd291bGQgYmUgdG8gZGVmaW5lIHRoZSB0cmFuc2xhdGlvbiBmcm9tIHJlc291 cmNlIFVSSSB0byBsaW5rIFVSSSB3aXRoIGEgcmVndWxhciBleHByZXNzaW9uIGFuZCByZXBsYWNl bWVudCBzdHJpbmcuIFRoZSByZXBsYWNlbWVudCBzdHJpbmcgY2FuIHJlZmVyZW5jZSDigJxjYXB0 dXJpbmcgZ3JvdXBz4oCdIGluIHRoZSByZWd1bGFyIGV4cHJlc3Npb24uDQogSSBhbSBzdXJlIGFs bCBtb2Rlcm4gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzIG9mZmVyIGJyb2FkbHkgc2ltaWxhciByZWdl eC1iYXNlZCByZXBsYWNlbWVudCBmdW5jdGlvbmFsaXR5LiBGb3IgaW5zdGFuY2UsIGZvciBKYXZh IHNlZQ0KPGEgaHJlZj0iaHR0cDovL2phdmEuc3VuLmNvbS9qYXZhc2UvNi9kb2NzL2FwaS9qYXZh L2xhbmcvU3RyaW5nLmh0bWwjcmVwbGFjZUFsbChqYXZhLmxhbmcuU3RyaW5nLCUyMGphdmEubGFu Zy5TdHJpbmcpIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5TPC9zcGFuPnRyaW5nI3JlcGxhY2VGaXJzdChyZWdleCwgcmVwbGFjZW1lbnQpPC9h PiBhbmQNCjxhIGhyZWY9Imh0dHA6Ly9qYXZhLnN1bi5jb20vamF2YXNlLzYvZG9jcy9hcGkvamF2 YS91dGlsL3JlZ2V4L01hdGNoZXIuaHRtbCNhcHBlbmRSZXBsYWNlbWVudCUyOGphdmEubGFuZy5T dHJpbmdCdWZmZXIsJTIwamF2YS5sYW5nLlN0cmluZyUyOSI+DQpNYXRjaGVyLmFwcGVuZFJlcGxh Y2VtZW50PC9hPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiB0aGUgcXVlc3Rpb24gaXMg d2hlcmUgaXMgdGhlIHJlZ2V4IHNwZWNpZmllZDogaW4gdGhlICZsdDtMaW5rJmd0OyBvciBhcyB0 aGUgJmx0O1N1YmplY3QmZ3Q7PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VXNpbmcgYSByZWd1bGFyIGV4cHJlc3Npb24gdG8gaW5kaWNhdGUgYWxsIHRoZSBVUklzIHRoYXQg dGhlIG1ldGFkYXRhIChYUkQpIGFwcGxpZXMgdG8gKGllIHRoZSBYUkTigJlzIHN1YmplY3QpIGZl ZWxzIGZsZXhpYmxlIGFuZCBhcHByb3ByaWF0ZS4gSG9zdC1tZXRhIHdvdWxkIG5vdCBuZWVkIHRv IGJlIGEgc3BlY2lhbCBjYXNlIHdpdGggaXRzIG93biAmbHQ7aG9zdC1tZXRhOlNjb3BlJmd0Oy4g TWV0YWRhdGEgdGhhdCBhcHBsaWVkDQogdG8gYWxsIHRoZSBVUklzIGluIGEgc3ViZGlyZWN0b3J5 IChlZyBhbGwgdW5kZXIgL2Jsb2cvKikgd291bGQgYmUgZWFzeSB0byBkZWZpbmUuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZsdDtYUkQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbHQ7U3ViamVjdFJlZ2V4Jmd0O2h0dHBzPzovLyg/Ond3d1wuKT9leGFt cGxlXC5jb20vKFtePyNdKikoXD9bXiNdKik/KCNcLiopPyZsdDsvU3ViamVjdFJlZ2V4Jmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jmx0O0xpbmsmZ3Q7Jmx0 O1JlbCZndDthdXRob3ImbHQ7L1JlbCZndDsmbHQ7VVJJUGF0dGVybiZndDtodHRwczovL3d3dy5l eGFtcGxlLmNvbS9cMTtieVwyJmx0Oy9VUkxQYXR0ZXJuJmd0OyZsdDsvTGluayZndDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDsvWFJEJmd0OzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JdCBpcyBhIHBpdHkgcmVnZXhzIGNhbiBiZSBhd2t3YXJkIHRvIHdyaXRlICgm YW1wOyBoYXJkZXIgdG8gcmVhZCkuIEluY2x1ZGluZyBhbiBleGFtcGxlIChvciBkZWZhdWx0IHZh bHVlPykgaW4gdGhlIHNwZWMgdGhhdCBjYXB0dXJlcyB0aGUgc2NoZW1lLCBhdXRob3JpdHksIHBh dGgsIHF1ZXJ5ICZhbXA7IGZyYWdtZW50IGNvdWxkIGJlIGFsbW9zdCBlcXVpdmFsZW50IHRvIHRo ZSBjdXJyZW50IHRlbXBsYXRlIHByb3Bvc2FsDQogKHdpdGggbXVjaCBtb3JlIGZsZXhpYmlsaXR5 LCBidXQgbGVzcyBmcmllbmRseSB2YXJpYWJsZSBuYW1lcykuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkphbWVzIE1hbmdlcjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4NCjxicj4NCjxhIGhyZWY9Im1haWx0bzpKYW1l cy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibHVlIj5KYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9zcGFu PjwvYT4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZGVudGl0eSBh bmQgc2VjdXJpdHkgdGVhbTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPg0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igJQ8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IENoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PuKAlDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVsc3RyYTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_255B9BB34FB7D647A506DC292726F6E112485B4116WSMSG3153Vsrv_-- From eran@hueniverse.com Mon Oct 26 22:32:33 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8713A67F2 for ; Mon, 26 Oct 2009 22:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 EUc+Oimc2M5d for ; Mon, 26 Oct 2009 22:32:32 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DF11E3A6405 for ; Mon, 26 Oct 2009 22:32:31 -0700 (PDT) Received: (qmail 15602 invoked from network); 27 Oct 2009 05:32:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 27 Oct 2009 05:32:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 26 Oct 2009 22:32:42 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "apps-discuss@ietf.org" Date: Mon, 26 Oct 2009 22:32:47 -0700 Subject: RE: host-meta: template syntax hassles Thread-Topic: host-meta: template syntax hassles Thread-Index: AcpWwpMrO2fBkK/zTVK4PvsTZrNbFQAA8nsQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343784FE8D9AP3PW5EX1MB01E_" MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 05:32:33 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343784FE8D9AP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEphbWVzLg0KDQpUaGUgZXhhbXBsZXMgYXJlIG9idmlvdXNseSBsaW1pdGVkIHRvIFVS SSB3aXRoIHNwZWNpZmljIGNoYXJhY3RlcmlzdGljcy4gSWYgdGhlIHByZXNlbmNlIG9mIHRoZXNl IGV4YW1wbGVzIGlzIG1pc2xlYWRpbmcsIEkgd2lsbCBiZSBoYXBweSB0byBjaGFuZ2UgdGhlbSB0 byBwdXQgdGhlIHt1cml9IGF0IHRoZSBlbmQgYXMgYSBxdWVyeSBwYXJhbWV0ZXIuDQoNCkRlZmlu aW5nIGEgbW9yZSBjb21wbGV4IHN5bnRheCBpcyBhYnNvbHV0ZWx5IG91dCBvZiBzY29wZS4gVGhl IHRlbXBsYXRlIHN5bnRheCBpcyBrZXB0IGludGVudGlvbmFsbHkgc2ltcGxlIGFuZCBhIHN1YnNl dCBvZiBSb3nigJlzIHByb3Bvc2FsIGZvciBhIFVSSSB0ZW1wbGF0ZSBzdGFuZGFyZCBpbiBob3Bl cyB0aGF0IHdoZW4gdGhhdCB3b3JrIGlzIGNvbXBsZXRlZCwgaXQgd2lsbCBiZSBmb3J3YXJkIGNv bXBhdGlibGUgKGNvZGUgd3JpdHRlbiBmb3IgdGhlIG5ldyBwcm9wb3NhbCBiZWluZyBhYmxlIHRv IGhhbmRsZSBvbGQgZmlsZXMpLg0KDQpFSEwNCg0KRnJvbTogYXBwcy1kaXNjdXNzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE1hbmdlciwgSmFtZXMgSA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDI2LCAyMDA5IDEwOjAy IFBNDQpUbzogYXBwcy1kaXNjdXNzQGlldGYub3JnDQpTdWJqZWN0OiBob3N0LW1ldGE6IHRlbXBs YXRlIHN5bnRheCBoYXNzbGVzDQoNCmRyYWZ0LWhhbW1lci1ob3N0bWV0YS0wMjxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvcmZjbWFya3VwP2RvYz1kcmFmdC1oYW1tZXItaG9zdG1ldGEjc2VjdGlvbi0z LjIuMT4g4oCcSG9zdC1NZXRhOiBXZWIgSG9zdCBNZXRhZGF0YeKAnSBkZWZpbmVzIGEgVVJJIHRl bXBsYXRlIHN5bnRheCBhbmQgdmFyaWFibGVzIGJhc2VkIG9uIHBhcnRzIG9mIGEgVVJJIFvCpzMu Mi4xLl0uDQoNCkkgZG9u4oCZdCB0aGluayB0aGUgY3VycmVudCBhcnJhbmdlbWVudCBjYW4gd29y ayBhcyBlYXNpbHkgYXMgdGhlIGV4YW1wbGVzIGluIHRoZSBkcmFmdCBzdWdnZXN0Lg0KDQpUaGUg ZXhhbXBsZSBvZiBhIGxpbmsgdG8gZWFjaCByZXNvdXJjZeKAmXMgYXV0aG9yIHByZXN1bWFibHkg d2FudHMg4oCcO2J54oCdIHRvIGJlIGFwcGVuZGVkIHRvIHRoZSByZXNvdXJjZSBVUknigJlzIHBh dGgg4oCUIGJ1dCB0aGF0IGlzIG5vdCB3aGF0IHRoZSDigJx7K3VyaX07YnnigJ0gdGVtcGxhdGUg ZG9lcy4NCg0KICA8TGluaz4gPFJlbD5hdXRob3I8L1JlbD4gPFVSSVRlbXBsYXRlPnsrdXJpfTti eTwvVVJJVGVtcGxhdGU+IDwvTGluaz4NCkZvciBVUklzIHdpdGggcXVlcnkgc3RyaW5ncywg4oCc O2J54oCdIGlzIGFwcGVuZGVkIHRvIHRoZSBsYXN0IHF1ZXJ5IHBhcmFtZXRlciB2YWx1ZS4gVGhp cyBpcyBhbG1vc3QgY2VydGFpbmx5IE5PVCBkZXNpcmVkLiBUaGUgb3JkZXIgb2YgcXVlcnkgcGFy YW1ldGVycyBpcyBub3JtYWxseSBpcnJlbGV2YW50IGJ1dCB0aGlzIHRlbXBsYXRlIGNoYW5nZXMg dGhlIHZhbHVlIG9mIHdoaWNoZXZlciBwYXJhbWV0ZXIgaGFwcGVucyB0byBiZSBsYXN0Lg0KDQpB IG1vcmUgY29ycmVjdCB0ZW1wbGF0ZSBpcyBwcm9iYWJseTog4oCceytzY2hlbWV9Oi8veythdXRo b3JpdHl9eytwYXRofTtieT97K3F1ZXJ5feKAnQ0KSSBhbSBub3Qgc3VyZSB0aGF0IGV2ZW4gdGhp cyBpcyBjb3JyZWN0IGlmIHRoZSBwYXRoIGlzIGVtcHR5IChlZyB5b3UgbWF5IGdldCB0aGUgaW52 YWxpZCBVUkkg4oCcaHR0cDovL2V4YW1wbGUubmV0O2J5P+KAnSkNClRoZXJlIHdpbGwgYWxzbyBi ZSBhIHRyYWlsaW5nIOKAnD/igJ0gd2hlbiB0aGVyZSBhcmUgbm8gcXVlcnkgcGFyYW1ldGVycywg d2hpY2ggbWF5IGJlIG1vc3RseSBoYXJtbGVzcywgYnV0IGlzIHN0cmljdGx5IGRpZmZlcmVudCBm cm9tIGEgVVJJIHdpdGhvdXQgdGhlIOKAnD/igJ0gc28gY2FjaGluZyBhbmQgY29tcGFyaXNvbnMg YXJlIGFkdmVyc2VseSBhZmZlY3RlZC4NCg0KQW5vdGhlciBleGFtcGxlIGZyb20gdGhlIGRyYWZ0 IGlzIOKAnHsrdXJpfSZ0ZXN04oCdLiBUaGlzIGVpdGhlciBtYWtlcyDigJwmdGVzdOKAnSBwYXJ0 IG9mIHRoZSBwYXRoLCBvciBhIG5ldyBxdWVyeSBwYXJhbWV0ZXIgKGRlcGVuZGluZyBvbiB3aGV0 aGVyIG9yIG5vdCB0aGUgVVJJIGFscmVhZHkgaGFzIGEgcXVlcnkgc3RyaW5nKS4gVGhpcyBpcyBw cm9iYWJseSBuZXZlciBkZXNpcmFibGUuIElmIGEgdGVtcGxhdGUgd2FudHMgdG8gYWRkIGEgcXVl cnkgcGFyYW1ldGVyIGl0IHByb2JhYmx5IG5lZWRzIHRvIHNwZWNpZnkNCiAg4oCceytzY2hlbWV9 Oi8veythdXRob3JpdHl9eytwYXRofT97K3F1ZXJ5fSZ0ZXN04oCdLg0KRXZlbiB0aGlzIGlzIG5v dCBpZGVhbCBhcyBpdCBwcm9kdWNlcyB1bnVzdWFsIFVSSXMgc3VjaCBhcyDigJxodHRwOi8vZXhh bXBsZS5uZXQvYXJ0aWNsZT8mdGVzdOKAnSwgd2hpY2ggYWdhaW4gbWF5IGJlIG1vc3RseSBoYXJt bGVzcyBidXQgaXMgc3RyaWN0bHkgZGlmZmVyZW50IGZyb20gYSBVUkkgd2l0aCBqdXN0IOKAnD90 ZXN04oCdIHNvIGNhY2hpbmcgYW5kIGNvbXBhcmlzb25zIGFyZSBhZHZlcnNlbHkgYWZmZWN0ZWQu DQoNCkFub3RoZXIgZXhhbXBsZSBmcm9tIHRoZSBzcGVjIGlzIOKAnGh0dHA6Ly9tZXRhLntob3N0 fTo4MDgweytwYXRofT97K3F1ZXJ5feKAnS4NCklmIHNvbWUgVVJJcyBtaWdodCBoYXZlIGEgdXNl cmluZm8gY29tcG9uZW50IHRoZW4gdGhlIHRlbXBsYXRlIG5lZWRzIHRvIGJlIOKAnGh0dHA6Ly97 K3VzZXJpbmZvfUBtZXRhLntob3N0fTo4MDgweytwYXRofT97K3F1ZXJ5feKAnS4gSG93ZXZlciwg d2hlbiB0aGVyZSBpcyBubyB1c2VyaW5mbyB0aGUgcmVzdWx0aW5nIFVSSSBzdGFydHMgaHR0cDov L0DigKYgdGhhdCAoaW4gc29tZSBjbGllbnRzIGF0IGxlYXN0LCBlZyBjdXJsKSBjYXVzZXMgYSDi gJxBdXRob3JpemF0aW9uOiBCYXNpYyBPZz094oCdIGhlYWRlciB0byBiZSBpbmNsdWRlZCB3aGVu IHJlcXVlc3RpbmcgdGhlIFVSSS4gVGhhdCBjb3VsZCBiZSBoYXJtZnVsLg0KUC5TLiBJdCBzaG91 bGQgcHJvYmFibHkgYWxzbyB1c2Ugeytob3N0fSwgaW5zdGVhZCBvZiB7aG9zdH0uDQoNCg0KVGhl IG1pbmltYWwgKHBhcnRpYWwpIHNvbHV0aW9uIGlzIHRvIGNoYW5nZSB0aGUgZXhhbXBsZXMgaW4g dGhlIGRyYWZ0IHRvIGJlIHJlYWxpc3RpYyAoZWcgd29yayBmb3IgYWxsIFVSSXMgaW4gdGhlIHNj b3BlLCB3aXRoIG9yIHdpdGhvdXQgcXVlcnkgc3RyaW5ncykuDQoNCkFub3RoZXIgc29sdXRpb24g aXMgdG8gZGVmaW5lIGEgbW9yZSBzb3BoaXN0aWNhdGVkIHRlbXBsYXRlIHN5bnRheC4gQSBzeW50 YXggdGhhdCBsaXN0cyBhIHByZWZpeCB0aGF0IGlzIG9ubHkgc3Vic3RpdHV0ZWQgd2hlbiB0aGUg dmFyaWFibGUgaXMgZGVmaW5lZCAobm9uLW51bGwpIG1heSBiZSBhbG1vc3Qgc3VmZmljaWVudC4g VGhhdCBhZGRyZXNzIHRoZSBwcm9ibGVtIHRoYXQgdGhlIGRlZmluZWQgdmFyaWFibGVzIGZvciBV UkkgcGFydHMgKHNjaGVtZSwgYXV0aG9yaXR5LCBxdWVyeSwgZnJhZ21lbnQsIHVzZXJpbmZvLCBo b3N0LCBwb3J0KSBkb27igJl0IGluY2x1ZGUgdGhlIHNlcGFyYXRvciBjaGFyYWN0ZXJzIHVzZWQg d2hlbiBjb21iaW5pbmcgdGhlIHBhcnRzLg0KDQoNCkluIHRoZSBob3N0LW1ldGEgY2FzZSBhIGJl dHRlciBzb2x1dGlvbiB3b3VsZCBiZSB0byBkZWZpbmUgdGhlIHRyYW5zbGF0aW9uIGZyb20gcmVz b3VyY2UgVVJJIHRvIGxpbmsgVVJJIHdpdGggYSByZWd1bGFyIGV4cHJlc3Npb24gYW5kIHJlcGxh Y2VtZW50IHN0cmluZy4gVGhlIHJlcGxhY2VtZW50IHN0cmluZyBjYW4gcmVmZXJlbmNlIOKAnGNh cHR1cmluZyBncm91cHPigJ0gaW4gdGhlIHJlZ3VsYXIgZXhwcmVzc2lvbi4gSSBhbSBzdXJlIGFs bCBtb2Rlcm4gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzIG9mZmVyIGJyb2FkbHkgc2ltaWxhciByZWdl eC1iYXNlZCByZXBsYWNlbWVudCBmdW5jdGlvbmFsaXR5LiBGb3IgaW5zdGFuY2UsIGZvciBKYXZh IHNlZSBTdHJpbmcjcmVwbGFjZUZpcnN0KHJlZ2V4LCByZXBsYWNlbWVudCk8aHR0cDovL2phdmEu c3VuLmNvbS9qYXZhc2UvNi9kb2NzL2FwaS9qYXZhL2xhbmcvU3RyaW5nLmh0bWwjcmVwbGFjZUFs bChqYXZhLmxhbmcuU3RyaW5nLCUyMGphdmEubGFuZy5TdHJpbmcpPiBhbmQgTWF0Y2hlci5hcHBl bmRSZXBsYWNlbWVudDxodHRwOi8vamF2YS5zdW4uY29tL2phdmFzZS82L2RvY3MvYXBpL2phdmEv dXRpbC9yZWdleC9NYXRjaGVyLmh0bWwjYXBwZW5kUmVwbGFjZW1lbnQlMjhqYXZhLmxhbmcuU3Ry aW5nQnVmZmVyLCUyMGphdmEubGFuZy5TdHJpbmclMjk+Lg0KDQpUaGVuIHRoZSBxdWVzdGlvbiBp cyB3aGVyZSBpcyB0aGUgcmVnZXggc3BlY2lmaWVkOiBpbiB0aGUgPExpbms+IG9yIGFzIHRoZSA8 U3ViamVjdD4/DQpVc2luZyBhIHJlZ3VsYXIgZXhwcmVzc2lvbiB0byBpbmRpY2F0ZSBhbGwgdGhl IFVSSXMgdGhhdCB0aGUgbWV0YWRhdGEgKFhSRCkgYXBwbGllcyB0byAoaWUgdGhlIFhSROKAmXMg c3ViamVjdCkgZmVlbHMgZmxleGlibGUgYW5kIGFwcHJvcHJpYXRlLiBIb3N0LW1ldGEgd291bGQg bm90IG5lZWQgdG8gYmUgYSBzcGVjaWFsIGNhc2Ugd2l0aCBpdHMgb3duIDxob3N0LW1ldGE6U2Nv cGU+LiBNZXRhZGF0YSB0aGF0IGFwcGxpZWQgdG8gYWxsIHRoZSBVUklzIGluIGEgc3ViZGlyZWN0 b3J5IChlZyBhbGwgdW5kZXIgL2Jsb2cvKikgd291bGQgYmUgZWFzeSB0byBkZWZpbmUuDQoNCjxY UkQ+DQogPFN1YmplY3RSZWdleD5odHRwcz86Ly8oPzp3d3dcLik/ZXhhbXBsZVwuY29tLyhbXj8j XSopKFw/W14jXSopPygjXC4qKT88L1N1YmplY3RSZWdleD4NCiA8TGluaz48UmVsPmF1dGhvcjwv UmVsPjxVUklQYXR0ZXJuPmh0dHBzOi8vd3d3LmV4YW1wbGUuY29tL1wxO2J5XDI8L1VSTFBhdHRl cm4+PC9MaW5rPg0KPC9YUkQ+DQoNCkl0IGlzIGEgcGl0eSByZWdleHMgY2FuIGJlIGF3a3dhcmQg dG8gd3JpdGUgKCYgaGFyZGVyIHRvIHJlYWQpLiBJbmNsdWRpbmcgYW4gZXhhbXBsZSAob3IgZGVm YXVsdCB2YWx1ZT8pIGluIHRoZSBzcGVjIHRoYXQgY2FwdHVyZXMgdGhlIHNjaGVtZSwgYXV0aG9y aXR5LCBwYXRoLCBxdWVyeSAmIGZyYWdtZW50IGNvdWxkIGJlIGFsbW9zdCBlcXVpdmFsZW50IHRv IHRoZSBjdXJyZW50IHRlbXBsYXRlIHByb3Bvc2FsICh3aXRoIG11Y2ggbW9yZSBmbGV4aWJpbGl0 eSwgYnV0IGxlc3MgZnJpZW5kbHkgdmFyaWFibGUgbmFtZXMpLg0KDQoNCkphbWVzIE1hbmdlcg0K SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVh bS50ZWxzdHJhLmNvbT4NCklkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGllZiBUZWNo bm9sb2d5IE9mZmljZSDigJQgVGVsc3RyYQ0K --_000_90C41DD21FB7C64BB94121FBBC2E72343784FE8D9AP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5T ZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkg bGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24x Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlRoYW5r cyBKYW1lcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlRoZSBleGFtcGxl cyBhcmUgb2J2aW91c2x5DQpsaW1pdGVkIHRvIFVSSSB3aXRoIHNwZWNpZmljIGNoYXJhY3Rlcmlz dGljcy4gSWYgdGhlIHByZXNlbmNlIG9mIHRoZXNlIGV4YW1wbGVzDQppcyBtaXNsZWFkaW5nLCBJ IHdpbGwgYmUgaGFwcHkgdG8gY2hhbmdlIHRoZW0gdG8gcHV0IHRoZSB7dXJpfSBhdCB0aGUgZW5k IGFzIGENCnF1ZXJ5IHBhcmFtZXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPkRlZmluaW5nIGEgbW9yZSBjb21wbGV4IHN5bnRheA0KaXMgYWJzb2x1dGVseSBvdXQgb2Yg c2NvcGUuIFRoZSB0ZW1wbGF0ZSBzeW50YXggaXMga2VwdCBpbnRlbnRpb25hbGx5IHNpbXBsZQ0K YW5kIGEgc3Vic2V0IG9mIFJveeKAmXMgcHJvcG9zYWwgZm9yIGEgVVJJIHRlbXBsYXRlIHN0YW5k YXJkIGluIGhvcGVzIHRoYXQgd2hlbg0KdGhhdCB3b3JrIGlzIGNvbXBsZXRlZCwgaXQgd2lsbCBi ZSBmb3J3YXJkIGNvbXBhdGlibGUgKGNvZGUgd3JpdHRlbiBmb3IgdGhlIG5ldw0KcHJvcG9zYWwg YmVpbmcgYWJsZSB0byBoYW5kbGUgb2xkIGZpbGVzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPg0KYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphcHBz LWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24NCkJlaGFsZiBPZiA8L2I+TWFuZ2VyLCBK YW1lcyBIPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAyNiwgMjAwOSAxMDowMiBQ TTxicj4NCjxiPlRvOjwvYj4gYXBwcy1kaXNjdXNzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IGhvc3QtbWV0YTogdGVtcGxhdGUgc3ludGF4IGhhc3NsZXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48YQ0KaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY21hcmt1cD9kb2M9ZHJhZnQtaGFtbWVyLWhvc3Rt ZXRhI3NlY3Rpb24tMy4yLjEiPmRyYWZ0LWhhbW1lci1ob3N0bWV0YS0wMjwvYT4NCuKAnEhvc3Qt TWV0YTogV2ViIEhvc3QgTWV0YWRhdGHigJ0gZGVmaW5lcyBhIFVSSSB0ZW1wbGF0ZSBzeW50YXgg YW5kIHZhcmlhYmxlcw0KYmFzZWQgb24gcGFydHMgb2YgYSBVUkkgW8KnMy4yLjEuXS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tQVU+SSBkb27igJl0IHRoaW5rIHRoZSBjdXJyZW50IGFycmFuZ2VtZW50IGNhbg0Kd29y ayBhcyBlYXNpbHkgYXMgdGhlIGV4YW1wbGVzIGluIHRoZSBkcmFmdCBzdWdnZXN0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1BVT5UaGUgZXhhbXBsZSBvZiBhIGxpbmsgdG8gZWFjaCByZXNvdXJjZeKAmXMNCmF1dGhv ciBwcmVzdW1hYmx5IHdhbnRzIOKAnDtieeKAnSB0byBiZSBhcHBlbmRlZCB0byB0aGUgcmVzb3Vy Y2UgVVJJ4oCZcyBwYXRoIOKAlCBidXQNCnRoYXQgaXMgbm90IHdoYXQgdGhlIOKAnHsrdXJpfTti eeKAnSB0ZW1wbGF0ZSBkb2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHByZT48c3BhbiBs YW5nPUVOLUFVPiZuYnNwOyAmbHQ7TGluayZndDsgJmx0O1JlbCZndDthdXRob3ImbHQ7L1JlbCZn dDsgJmx0O1VSSVRlbXBsYXRlJmd0O3srdXJpfTtieSZsdDsvVVJJVGVtcGxhdGUmZ3Q7ICZsdDsv TGluayZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tQVU+Rm9yIFVSSXMgd2l0aCBxdWVyeSBzdHJpbmdzLCDigJw7YnnigJ0gaXMN CmFwcGVuZGVkIHRvIHRoZSBsYXN0IHF1ZXJ5IHBhcmFtZXRlciB2YWx1ZS4gVGhpcyBpcyBhbG1v c3QgY2VydGFpbmx5IE5PVA0KZGVzaXJlZC4gVGhlIG9yZGVyIG9mIHF1ZXJ5IHBhcmFtZXRlcnMg aXMgbm9ybWFsbHkgaXJyZWxldmFudCBidXQgdGhpcyB0ZW1wbGF0ZQ0KY2hhbmdlcyB0aGUgdmFs dWUgb2Ygd2hpY2hldmVyIHBhcmFtZXRlciBoYXBwZW5zIHRvIGJlIGxhc3QuPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LUFVPkEgbW9yZSBjb3JyZWN0IHRlbXBsYXRlIGlzIHByb2JhYmx5Og0K4oCceytzY2hlbWV9Oi8v eythdXRob3JpdHl9eytwYXRofTtieT97K3F1ZXJ5feKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+SSBhbSBub3Qgc3VyZSB0aGF0 IGV2ZW4gdGhpcyBpcyBjb3JyZWN0IGlmDQp0aGUgcGF0aCBpcyBlbXB0eSAoZWcgeW91IG1heSBn ZXQgdGhlIGludmFsaWQgVVJJIOKAnGh0dHA6Ly9leGFtcGxlLm5ldDtieT/igJ0pPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5UaGVy ZSB3aWxsIGFsc28gYmUgYSB0cmFpbGluZyDigJw/4oCdIHdoZW4NCnRoZXJlIGFyZSBubyBxdWVy eSBwYXJhbWV0ZXJzLCB3aGljaCBtYXkgYmUgbW9zdGx5IGhhcm1sZXNzLCBidXQgaXMgc3RyaWN0 bHkgZGlmZmVyZW50DQpmcm9tIGEgVVJJIHdpdGhvdXQgdGhlIOKAnD/igJ0gc28gY2FjaGluZyBh bmQgY29tcGFyaXNvbnMgYXJlIGFkdmVyc2VseSBhZmZlY3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+QW5v dGhlciBleGFtcGxlIGZyb20gdGhlIGRyYWZ0IGlzDQrigJx7K3VyaX0mYW1wO3Rlc3TigJ0uIFRo aXMgZWl0aGVyIG1ha2VzIOKAnCZhbXA7dGVzdOKAnSBwYXJ0IG9mIHRoZSBwYXRoLCBvciBhIG5l dw0KcXVlcnkgcGFyYW1ldGVyIChkZXBlbmRpbmcgb24gd2hldGhlciBvciBub3QgdGhlIFVSSSBh bHJlYWR5IGhhcyBhIHF1ZXJ5DQpzdHJpbmcpLiBUaGlzIGlzIHByb2JhYmx5IG5ldmVyIGRlc2ly YWJsZS4gSWYgYSB0ZW1wbGF0ZSB3YW50cyB0byBhZGQgYSBxdWVyeQ0KcGFyYW1ldGVyIGl0IHBy b2JhYmx5IG5lZWRzIHRvIHNwZWNpZnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPiZuYnNwOyZuYnNwO+KAnHsrc2NoZW1lfTovL3sr YXV0aG9yaXR5fXsrcGF0aH0/eytxdWVyeX0mYW1wO3Rlc3TigJ0uPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5FdmVuIHRoaXMgaXMg bm90IGlkZWFsIGFzIGl0IHByb2R1Y2VzDQp1bnVzdWFsIFVSSXMgc3VjaCBhcyDigJw8YSBocmVm PSJodHRwOi8vZXhhbXBsZS5uZXQvYXJ0aWNsZT8mYW1wO3Rlc3QiPmh0dHA6Ly9leGFtcGxlLm5l dC9hcnRpY2xlPyZhbXA7dGVzdDwvYT7igJ0sDQp3aGljaCBhZ2FpbiBtYXkgYmUgbW9zdGx5IGhh cm1sZXNzIGJ1dCBpcyBzdHJpY3RseSBkaWZmZXJlbnQgZnJvbSBhIFVSSSB3aXRoDQpqdXN0IOKA nD90ZXN04oCdIHNvIGNhY2hpbmcgYW5kIGNvbXBhcmlzb25zIGFyZSBhZHZlcnNlbHkgYWZmZWN0 ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUFVPkFub3RoZXIgZXhhbXBsZSBmcm9tIHRoZSBzcGVjIGlzDQrigJxo dHRwOi8vbWV0YS57aG9zdH06ODA4MHsrcGF0aH0/eytxdWVyeX3igJ0uPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5JZiBzb21lIFVS SXMgbWlnaHQgaGF2ZSBhIHVzZXJpbmZvDQpjb21wb25lbnQgdGhlbiB0aGUgdGVtcGxhdGUgbmVl ZHMgdG8gYmUNCuKAnGh0dHA6Ly97K3VzZXJpbmZvfUBtZXRhLntob3N0fTo4MDgweytwYXRofT97 K3F1ZXJ5feKAnS4gSG93ZXZlciwgd2hlbiB0aGVyZSBpcw0Kbm8gdXNlcmluZm8gdGhlIHJlc3Vs dGluZyBVUkkgc3RhcnRzIGh0dHA6Ly9A4oCmIHRoYXQgKGluIHNvbWUgY2xpZW50cyBhdCBsZWFz dCwgZWcNCmN1cmwpIGNhdXNlcyBhIOKAnEF1dGhvcml6YXRpb246IEJhc2ljIE9nPT3igJ0gaGVh ZGVyIHRvIGJlIGluY2x1ZGVkIHdoZW4NCnJlcXVlc3RpbmcgdGhlIFVSSS4gVGhhdCBjb3VsZCBi ZSBoYXJtZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tQVU+UC5TLiBJdCBzaG91bGQgcHJvYmFibHkgYWxzbyB1c2Ugeytob3N0fSwN Cmluc3RlYWQgb2Yge2hvc3R9LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPlRoZSBtaW5pbWFs IChwYXJ0aWFsKSBzb2x1dGlvbiBpcyB0byBjaGFuZ2UNCnRoZSBleGFtcGxlcyBpbiB0aGUgZHJh ZnQgdG8gYmUgcmVhbGlzdGljIChlZyB3b3JrIGZvciBhbGwgVVJJcyBpbiB0aGUgc2NvcGUsDQp3 aXRoIG9yIHdpdGhvdXQgcXVlcnkgc3RyaW5ncykuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPkFub3RoZXIgc29s dXRpb24gaXMgdG8gZGVmaW5lIGEgbW9yZQ0Kc29waGlzdGljYXRlZCB0ZW1wbGF0ZSBzeW50YXgu IEEgc3ludGF4IHRoYXQgbGlzdHMgYSBwcmVmaXggdGhhdCBpcyBvbmx5DQpzdWJzdGl0dXRlZCB3 aGVuIHRoZSB2YXJpYWJsZSBpcyBkZWZpbmVkIChub24tbnVsbCkgbWF5IGJlIGFsbW9zdCBzdWZm aWNpZW50Lg0KVGhhdCBhZGRyZXNzIHRoZSBwcm9ibGVtIHRoYXQgdGhlIGRlZmluZWQgdmFyaWFi bGVzIGZvciBVUkkgcGFydHMgKHNjaGVtZSwNCmF1dGhvcml0eSwgcXVlcnksIGZyYWdtZW50LCB1 c2VyaW5mbywgaG9zdCwgcG9ydCkgZG9u4oCZdCBpbmNsdWRlIHRoZSBzZXBhcmF0b3INCmNoYXJh Y3RlcnMgdXNlZCB3aGVuIGNvbWJpbmluZyB0aGUgcGFydHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tQVU+SW4gdGhlIGhvc3QtbWV0YSBjYXNlIGEgYmV0dGVyIHNvbHV0aW9uDQp3b3VsZCBiZSB0 byBkZWZpbmUgdGhlIHRyYW5zbGF0aW9uIGZyb20gcmVzb3VyY2UgVVJJIHRvIGxpbmsgVVJJIHdp dGggYSByZWd1bGFyDQpleHByZXNzaW9uIGFuZCByZXBsYWNlbWVudCBzdHJpbmcuIFRoZSByZXBs YWNlbWVudCBzdHJpbmcgY2FuIHJlZmVyZW5jZQ0K4oCcY2FwdHVyaW5nIGdyb3Vwc+KAnSBpbiB0 aGUgcmVndWxhciBleHByZXNzaW9uLiBJIGFtIHN1cmUgYWxsIG1vZGVybiBwcm9ncmFtbWluZw0K bGFuZ3VhZ2VzIG9mZmVyIGJyb2FkbHkgc2ltaWxhciByZWdleC1iYXNlZCByZXBsYWNlbWVudCBm dW5jdGlvbmFsaXR5LiBGb3INCmluc3RhbmNlLCBmb3IgSmF2YSBzZWUgPGENCmhyZWY9Imh0dHA6 Ly9qYXZhLnN1bi5jb20vamF2YXNlLzYvZG9jcy9hcGkvamF2YS9sYW5nL1N0cmluZy5odG1sI3Jl cGxhY2VBbGwoamF2YS5sYW5nLlN0cmluZywlMjBqYXZhLmxhbmcuU3RyaW5nKSI+PHNwYW4NCnN0 eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lJz5TPC9zcGFuPnRyaW5n I3JlcGxhY2VGaXJzdChyZWdleCwNCnJlcGxhY2VtZW50KTwvYT4gYW5kIDxhDQpocmVmPSJodHRw Oi8vamF2YS5zdW4uY29tL2phdmFzZS82L2RvY3MvYXBpL2phdmEvdXRpbC9yZWdleC9NYXRjaGVy Lmh0bWwjYXBwZW5kUmVwbGFjZW1lbnQlMjhqYXZhLmxhbmcuU3RyaW5nQnVmZmVyLCUyMGphdmEu bGFuZy5TdHJpbmclMjkiPk1hdGNoZXIuYXBwZW5kUmVwbGFjZW1lbnQ8L2E+LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1BVT5UaGVuIHRoZSBxdWVzdGlvbiBpcyB3aGVyZSBpcyB0aGUgcmVnZXgNCnNwZWNpZmllZDog aW4gdGhlICZsdDtMaW5rJmd0OyBvciBhcyB0aGUgJmx0O1N1YmplY3QmZ3Q7PzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+VXNpbmcg YSByZWd1bGFyIGV4cHJlc3Npb24gdG8gaW5kaWNhdGUgYWxsDQp0aGUgVVJJcyB0aGF0IHRoZSBt ZXRhZGF0YSAoWFJEKSBhcHBsaWVzIHRvIChpZSB0aGUgWFJE4oCZcyBzdWJqZWN0KSBmZWVscw0K ZmxleGlibGUgYW5kIGFwcHJvcHJpYXRlLiBIb3N0LW1ldGEgd291bGQgbm90IG5lZWQgdG8gYmUg YSBzcGVjaWFsIGNhc2Ugd2l0aA0KaXRzIG93biAmbHQ7aG9zdC1tZXRhOlNjb3BlJmd0Oy4gTWV0 YWRhdGEgdGhhdCBhcHBsaWVkIHRvIGFsbCB0aGUgVVJJcyBpbiBhDQpzdWJkaXJlY3RvcnkgKGVn IGFsbCB1bmRlciAvYmxvZy8qKSB3b3VsZCBiZSBlYXN5IHRvIGRlZmluZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t QVU+Jmx0O1hSRCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUFVPiZuYnNwOyZsdDtTdWJqZWN0UmVnZXgmZ3Q7aHR0cHM/Oi8vKD86 d3d3XC4pP2V4YW1wbGVcLmNvbS8oW14/I10qKShcP1teI10qKT8oI1wuKik/Jmx0Oy9TdWJqZWN0 UmVnZXgmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1BVT4mbmJzcDsmbHQ7TGluayZndDsmbHQ7UmVsJmd0O2F1dGhvciZsdDsvUmVs Jmd0OyZsdDtVUklQYXR0ZXJuJmd0O2h0dHBzOi8vd3d3LmV4YW1wbGUuY29tL1wxO2J5XDImbHQ7 L1VSTFBhdHRlcm4mZ3Q7Jmx0Oy9MaW5rJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+Jmx0Oy9YUkQmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LUFVPkl0IGlzIGEgcGl0eSByZWdleHMgY2FuIGJlIGF3a3dhcmQgdG8gd3JpdGUNCigmYW1wOyBo YXJkZXIgdG8gcmVhZCkuIEluY2x1ZGluZyBhbiBleGFtcGxlIChvciBkZWZhdWx0IHZhbHVlPykg aW4gdGhlIHNwZWMNCnRoYXQgY2FwdHVyZXMgdGhlIHNjaGVtZSwgYXV0aG9yaXR5LCBwYXRoLCBx dWVyeSAmYW1wOyBmcmFnbWVudCBjb3VsZCBiZSBhbG1vc3QNCmVxdWl2YWxlbnQgdG8gdGhlIGN1 cnJlbnQgdGVtcGxhdGUgcHJvcG9zYWwgKHdpdGggbXVjaCBtb3JlIGZsZXhpYmlsaXR5LCBidXQN Cmxlc3MgZnJpZW5kbHkgdmFyaWFibGUgbmFtZXMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUZS IHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz5KYW1lcw0KTWFuZ2VyPC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPg0KPGJyPg0K PGEgaHJlZj0ibWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iPjxzcGFuIGxh bmc9RlINCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5KYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9zcGFuPjwvYT4NCjxicj4N Cjwvc3Bhbj48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5JZGVudGl0eQ0KYW5kIHNlY3VyaXR5IHRlYW08L3Nw YW4+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToN CiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPiA8L3NwYW4+PHNwYW4gbGFuZz1FTi1BVSBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ 4oCUPC9zcGFuPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+IENoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlPC9z cGFuPjxzcGFuDQpsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPiA8L3NwYW4+PHNwYW4NCmxhbmc9RU4tQVUgc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7i gJQ8L3NwYW4+PHNwYW4NCmxhbmc9RU4tQVUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiBUZWxzdHJhPC9zcGFuPjxzcGFuDQpsYW5nPUVO LUFVIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiInPiA8L3NwYW4+PHNwYW4NCmxhbmc9RU4tQVU+PG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_90C41DD21FB7C64BB94121FBBC2E72343784FE8D9AP3PW5EX1MB01E_-- From James.H.Manger@team.telstra.com Tue Oct 27 00:04:20 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72873A67C1 for ; Tue, 27 Oct 2009 00:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 r3GpuxvI0wtf for ; Tue, 27 Oct 2009 00:04:19 -0700 (PDT) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 654233A6403 for ; Tue, 27 Oct 2009 00:04:17 -0700 (PDT) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 27 Oct 2009 18:04:31 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id B2898FF81 for ; Tue, 27 Oct 2009 18:04:30 +1100 (EST) Received: from WSMSG3755.srv.dir.telstra.com (wsmsg3755.in.telstra.com.au [172.49.40.196]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 75A1741D2F for ; Tue, 27 Oct 2009 18:04:14 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 27 Oct 2009 18:04:30 +1100 From: "Manger, James H" To: "apps-discuss@ietf.org" Date: Tue, 27 Oct 2009 18:04:28 +1100 Subject: RE: host-meta: template syntax hassles Thread-Topic: host-meta: template syntax hassles Thread-Index: AcpWwpMrO2fBkK/zTVK4PvsTZrNbFQAA8nsQAAEiIMA= Message-ID: <255B9BB34FB7D647A506DC292726F6E112485B4391@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112485B4391WSMSG3153Vsrv_" MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 07:04:21 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112485B4391WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJhbiwNCg0KDQoNCj4gVGhlIGV4YW1wbGVzIGFyZSBvYnZpb3VzbHkgbGltaXRlZCB0byBVUkkg d2l0aCBzcGVjaWZpYyBjaGFyYWN0ZXJpc3RpY3MuDQoNCj4gSWYgdGhlIHByZXNlbmNlIG9mIHRo ZXNlIGV4YW1wbGVzIGlzIG1pc2xlYWRpbmcsDQoNCg0KDQpob3N0LW1ldGEgaXMgZXhwbGljaXRs eSBub3QgbGltaXRlZCB0byBVUklzIHdpdGggc3BlY2lmaWMgY2hhcmFjdGVyaXN0aWNzIChhcyBp dCBjb3ZlcnMgb25lIG9yIG1vcmUgZW50aXJlIGhvc3RzKSBzbyBJIHRoaW5rIHRoZXkgYXJlIG1p c2xlYWRpbmcuDQoNCltJdCBtYXkgZXZlbiBiZSBwb3RlbnRpYWxseSBkYW5nZXJvdXM6IGF0dGFj a2VyIHNlbmRzIOKAnGh0dHA6Ly9leGFtcGxlLmNvbS94eHg/4oCdIHRvIHZpY3RpbTsgdmljdGlt ICgmIHNlcnZlcikgdHJlYXQgaXQgYXMgZXF1aXZhbGVudCB0byDigJxodHRwOi8vZXhhbXBsZS5j b20veHh44oCdOyBidXQgbWV0YS1kYXRhIGlzIHJldHJpZXZlZCBmcm9tIGEgZGlmZmVyZW50IHNv dXJjZSBnaXZlbiB7K3VyaX07bWV0YSB0ZW1wbGF0ZTogZnJvbSAveHh4IChzZXJ2ZXIgaWdub3Jl cyB1bmV4cGVjdGVkIOKAnD87bWV0YeKAnSBxdWVyeSBzdHJpbmcgaW4gdGhpcyByZXF1ZXN0KSB2 cyBmcm9tIC94eHg7bWV0YSAodGhhdCBzZXJ2ZXIgcmVjb2duaXplcykuXQ0KDQoNCg0KPiBJIHdp bGwgYmUgaGFwcHkgdG8gY2hhbmdlIHRoZW0gdG8gcHV0IHRoZSB7dXJpfSBhdCB0aGUgZW5kIGFz IGEgcXVlcnkgcGFyYW1ldGVyLg0KDQoNCg0KV2UgY2Fu4oCZdCBoYXZlIHRoZSBvbmx5IHJlYWxp c3RpYyBleGFtcGxlIGluIHRoZSBzcGVjIGJlaW5nIHt1cml9IGFzIGEgcXVlcnkgcGFyYW1ldGVy LiBJdCBpcyBubyB1c2UgaGF2aW5nIHRlbXBsYXRlcyBpbiB0aGF0IGNhc2UuDQoNCg0KDQpDaGFu Z2luZyB0aGUgZXh0ZW5zaW9uICgqLmh0bWwgdG8gKi54cmQpLCBhcHBlbmRpbmcg4oCcO21ldGHi gJ0gdG8gdGhlIHBhdGgsIGFkZGluZyBhbiDigJxfYWJvdXTigJ0gcXVlcnkgcGFyYW1ldGVyLCB1 c2luZyBhIG1ldGFkYXRhLmV4YW1wbGUuY29tIHN1Yi1kb21haW4gZXRjIGFsbCBzb3VuZCBsaWtl IHJlYWxpc3RpYyBjaG9pY2VzIGhvc3RzIG1pZ2h0IG1ha2UuIFRoZSBzcGVjIHNob3VsZCBpbmNs dWRlIGV4YW1wbGVzIGZvciB0aGVzZSBzb3J0cyBvZiBjaG9pY2VzLiBJZiB0aGUgZXhhbXBsZXMg YXJlIHRvbyBjb21wbGV4IHRoZW4gdGhlIG9ubHkgYW5zd2VyIGlzIHRvIHNpbXBsaWZ5IHRoZSBz eW50YXgsIG5vdCBqdXN0IG9taXQgdGhlIGV4YW1wbGVzLg0KDQoNCg0KSWYgZXhhbXBsZXMgbGlr ZSB7K3NjaGVtZX06Ly97K2F1dGhvcml0eX17K3BhdGh9O2J5P3srcXVlcnl9IGFuZCB7K3NjaGVt ZX06Ly97K2F1dGhvcml0eX17K3BhdGh9P3srcXVlcnl9JnRlc3QgIGFyZSB0b28gY29tcGxleCB3 ZSBuZWVkIGEgc2ltcGxlciBzeW50YXguDQoNCg0KDQpKYW1lcyBNYW5nZXINCg0KDQoNCkZyb206 IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5nZXIsIEphbWVzIEgNClNlbnQ6IE1vbmRheSwg T2N0b2JlciAyNiwgMjAwOSAxMDowMiBQTQ0KVG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KU3Vi amVjdDogaG9zdC1tZXRhOiB0ZW1wbGF0ZSBzeW50YXggaGFzc2xlcw0KDQoNCg0KZHJhZnQtaGFt bWVyLWhvc3RtZXRhLTAyPGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNtYXJrdXA/ZG9jPWRyYWZ0 LWhhbW1lci1ob3N0bWV0YSNzZWN0aW9uLTMuMi4xPiDigJxIb3N0LU1ldGE6IFdlYiBIb3N0IE1l dGFkYXRh4oCdIGRlZmluZXMgYSBVUkkgdGVtcGxhdGUgc3ludGF4IGFuZCB2YXJpYWJsZXMgYmFz ZWQgb24gcGFydHMgb2YgYSBVUkkgW8KnMy4yLjEuXS4NCg0KDQoNCkkgZG9u4oCZdCB0aGluayB0 aGUgY3VycmVudCBhcnJhbmdlbWVudCBjYW4gd29yayBhcyBlYXNpbHkgYXMgdGhlIGV4YW1wbGVz IGluIHRoZSBkcmFmdCBzdWdnZXN0Lg0KDQoNCg0KVGhlIGV4YW1wbGUgb2YgYSBsaW5rIHRvIGVh Y2ggcmVzb3VyY2XigJlzIGF1dGhvciBwcmVzdW1hYmx5IHdhbnRzIOKAnDtieeKAnSB0byBiZSBh cHBlbmRlZCB0byB0aGUgcmVzb3VyY2UgVVJJ4oCZcyBwYXRoIOKAlCBidXQgdGhhdCBpcyBub3Qg d2hhdCB0aGUg4oCceyt1cml9O2J54oCdIHRlbXBsYXRlIGRvZXMuDQoNCiAgPExpbms+IDxSZWw+ YXV0aG9yPC9SZWw+IDxVUklUZW1wbGF0ZT57K3VyaX07Ynk8L1VSSVRlbXBsYXRlPiA8L0xpbms+ DQoNCkZvciBVUklzIHdpdGggcXVlcnkgc3RyaW5ncywg4oCcO2J54oCdIGlzIGFwcGVuZGVkIHRv IHRoZSBsYXN0IHF1ZXJ5IHBhcmFtZXRlciB2YWx1ZS4gVGhpcyBpcyBhbG1vc3QgY2VydGFpbmx5 IE5PVCBkZXNpcmVkLiBUaGUgb3JkZXIgb2YgcXVlcnkgcGFyYW1ldGVycyBpcyBub3JtYWxseSBp cnJlbGV2YW50IGJ1dCB0aGlzIHRlbXBsYXRlIGNoYW5nZXMgdGhlIHZhbHVlIG9mIHdoaWNoZXZl ciBwYXJhbWV0ZXIgaGFwcGVucyB0byBiZSBsYXN0Lg0KDQoNCg0KQSBtb3JlIGNvcnJlY3QgdGVt cGxhdGUgaXMgcHJvYmFibHk6IOKAnHsrc2NoZW1lfTovL3srYXV0aG9yaXR5fXsrcGF0aH07Ynk/ eytxdWVyeX3igJ0NCg0KSSBhbSBub3Qgc3VyZSB0aGF0IGV2ZW4gdGhpcyBpcyBjb3JyZWN0IGlm IHRoZSBwYXRoIGlzIGVtcHR5IChlZyB5b3UgbWF5IGdldCB0aGUgaW52YWxpZCBVUkkg4oCcaHR0 cDovL2V4YW1wbGUubmV0O2J5P+KAnSkNCg0KVGhlcmUgd2lsbCBhbHNvIGJlIGEgdHJhaWxpbmcg 4oCcP+KAnSB3aGVuIHRoZXJlIGFyZSBubyBxdWVyeSBwYXJhbWV0ZXJzLCB3aGljaCBtYXkgYmUg bW9zdGx5IGhhcm1sZXNzLCBidXQgaXMgc3RyaWN0bHkgZGlmZmVyZW50IGZyb20gYSBVUkkgd2l0 aG91dCB0aGUg4oCcP+KAnSBzbyBjYWNoaW5nIGFuZCBjb21wYXJpc29ucyBhcmUgYWR2ZXJzZWx5 IGFmZmVjdGVkLg0KDQoNCg0KQW5vdGhlciBleGFtcGxlIGZyb20gdGhlIGRyYWZ0IGlzIOKAnHsr dXJpfSZ0ZXN04oCdLiBUaGlzIGVpdGhlciBtYWtlcyDigJwmdGVzdOKAnSBwYXJ0IG9mIHRoZSBw YXRoLCBvciBhIG5ldyBxdWVyeSBwYXJhbWV0ZXIgKGRlcGVuZGluZyBvbiB3aGV0aGVyIG9yIG5v dCB0aGUgVVJJIGFscmVhZHkgaGFzIGEgcXVlcnkgc3RyaW5nKS4gVGhpcyBpcyBwcm9iYWJseSBu ZXZlciBkZXNpcmFibGUuIElmIGEgdGVtcGxhdGUgd2FudHMgdG8gYWRkIGEgcXVlcnkgcGFyYW1l dGVyIGl0IHByb2JhYmx5IG5lZWRzIHRvIHNwZWNpZnkNCg0KICDigJx7K3NjaGVtZX06Ly97K2F1 dGhvcml0eX17K3BhdGh9P3srcXVlcnl9JnRlc3TigJ0uDQoNCkV2ZW4gdGhpcyBpcyBub3QgaWRl YWwgYXMgaXQgcHJvZHVjZXMgdW51c3VhbCBVUklzIHN1Y2ggYXMg4oCcaHR0cDovL2V4YW1wbGUu bmV0L2FydGljbGU/JnRlc3TigJ0sIHdoaWNoIGFnYWluIG1heSBiZSBtb3N0bHkgaGFybWxlc3Mg YnV0IGlzIHN0cmljdGx5IGRpZmZlcmVudCBmcm9tIGEgVVJJIHdpdGgganVzdCDigJw/dGVzdOKA nSBzbyBjYWNoaW5nIGFuZCBjb21wYXJpc29ucyBhcmUgYWR2ZXJzZWx5IGFmZmVjdGVkLg0KDQoN Cg0KQW5vdGhlciBleGFtcGxlIGZyb20gdGhlIHNwZWMgaXMg4oCcaHR0cDovL21ldGEue2hvc3R9 OjgwODB7K3BhdGh9P3srcXVlcnl94oCdLg0KDQpJZiBzb21lIFVSSXMgbWlnaHQgaGF2ZSBhIHVz ZXJpbmZvIGNvbXBvbmVudCB0aGVuIHRoZSB0ZW1wbGF0ZSBuZWVkcyB0byBiZSDigJxodHRwOi8v eyt1c2VyaW5mb31AbWV0YS57aG9zdH06ODA4MHsrcGF0aH0/eytxdWVyeX3igJ0uIEhvd2V2ZXIs IHdoZW4gdGhlcmUgaXMgbm8gdXNlcmluZm8gdGhlIHJlc3VsdGluZyBVUkkgc3RhcnRzIGh0dHA6 Ly9A4oCmIHRoYXQgKGluIHNvbWUgY2xpZW50cyBhdCBsZWFzdCwgZWcgY3VybCkgY2F1c2VzIGEg 4oCcQXV0aG9yaXphdGlvbjogQmFzaWMgT2c9PeKAnSBoZWFkZXIgdG8gYmUgaW5jbHVkZWQgd2hl biByZXF1ZXN0aW5nIHRoZSBVUkkuIFRoYXQgY291bGQgYmUgaGFybWZ1bC4NCg0KUC5TLiBJdCBz aG91bGQgcHJvYmFibHkgYWxzbyB1c2Ugeytob3N0fSwgaW5zdGVhZCBvZiB7aG9zdH0uDQoNCg0K DQoNCg0KVGhlIG1pbmltYWwgKHBhcnRpYWwpIHNvbHV0aW9uIGlzIHRvIGNoYW5nZSB0aGUgZXhh bXBsZXMgaW4gdGhlIGRyYWZ0IHRvIGJlIHJlYWxpc3RpYyAoZWcgd29yayBmb3IgYWxsIFVSSXMg aW4gdGhlIHNjb3BlLCB3aXRoIG9yIHdpdGhvdXQgcXVlcnkgc3RyaW5ncykuDQoNCg0KDQpBbm90 aGVyIHNvbHV0aW9uIGlzIHRvIGRlZmluZSBhIG1vcmUgc29waGlzdGljYXRlZCB0ZW1wbGF0ZSBz eW50YXguIEEgc3ludGF4IHRoYXQgbGlzdHMgYSBwcmVmaXggdGhhdCBpcyBvbmx5IHN1YnN0aXR1 dGVkIHdoZW4gdGhlIHZhcmlhYmxlIGlzIGRlZmluZWQgKG5vbi1udWxsKSBtYXkgYmUgYWxtb3N0 IHN1ZmZpY2llbnQuIFRoYXQgYWRkcmVzcyB0aGUgcHJvYmxlbSB0aGF0IHRoZSBkZWZpbmVkIHZh cmlhYmxlcyBmb3IgVVJJIHBhcnRzIChzY2hlbWUsIGF1dGhvcml0eSwgcXVlcnksIGZyYWdtZW50 LCB1c2VyaW5mbywgaG9zdCwgcG9ydCkgZG9u4oCZdCBpbmNsdWRlIHRoZSBzZXBhcmF0b3IgY2hh cmFjdGVycyB1c2VkIHdoZW4gY29tYmluaW5nIHRoZSBwYXJ0cy4NCg0KDQoNCg0KDQpJbiB0aGUg aG9zdC1tZXRhIGNhc2UgYSBiZXR0ZXIgc29sdXRpb24gd291bGQgYmUgdG8gZGVmaW5lIHRoZSB0 cmFuc2xhdGlvbiBmcm9tIHJlc291cmNlIFVSSSB0byBsaW5rIFVSSSB3aXRoIGEgcmVndWxhciBl eHByZXNzaW9uIGFuZCByZXBsYWNlbWVudCBzdHJpbmcuIFRoZSByZXBsYWNlbWVudCBzdHJpbmcg Y2FuIHJlZmVyZW5jZSDigJxjYXB0dXJpbmcgZ3JvdXBz4oCdIGluIHRoZSByZWd1bGFyIGV4cHJl c3Npb24uIEkgYW0gc3VyZSBhbGwgbW9kZXJuIHByb2dyYW1taW5nIGxhbmd1YWdlcyBvZmZlciBi cm9hZGx5IHNpbWlsYXIgcmVnZXgtYmFzZWQgcmVwbGFjZW1lbnQgZnVuY3Rpb25hbGl0eS4gRm9y IGluc3RhbmNlLCBmb3IgSmF2YSBzZWUgU3RyaW5nI3JlcGxhY2VGaXJzdChyZWdleCwgcmVwbGFj ZW1lbnQpPGh0dHA6Ly9qYXZhLnN1bi5jb20vamF2YXNlLzYvZG9jcy9hcGkvamF2YS9sYW5nL1N0 cmluZy5odG1sI3JlcGxhY2VBbGwoamF2YS5sYW5nLlN0cmluZywlMjBqYXZhLmxhbmcuU3RyaW5n KT4gYW5kIE1hdGNoZXIuYXBwZW5kUmVwbGFjZW1lbnQ8aHR0cDovL2phdmEuc3VuLmNvbS9qYXZh c2UvNi9kb2NzL2FwaS9qYXZhL3V0aWwvcmVnZXgvTWF0Y2hlci5odG1sI2FwcGVuZFJlcGxhY2Vt ZW50JTI4amF2YS5sYW5nLlN0cmluZ0J1ZmZlciwlMjBqYXZhLmxhbmcuU3RyaW5nJTI5Pi4NCg0K DQoNClRoZW4gdGhlIHF1ZXN0aW9uIGlzIHdoZXJlIGlzIHRoZSByZWdleCBzcGVjaWZpZWQ6IGlu IHRoZSA8TGluaz4gb3IgYXMgdGhlIDxTdWJqZWN0Pj8NCg0KVXNpbmcgYSByZWd1bGFyIGV4cHJl c3Npb24gdG8gaW5kaWNhdGUgYWxsIHRoZSBVUklzIHRoYXQgdGhlIG1ldGFkYXRhIChYUkQpIGFw cGxpZXMgdG8gKGllIHRoZSBYUkTigJlzIHN1YmplY3QpIGZlZWxzIGZsZXhpYmxlIGFuZCBhcHBy b3ByaWF0ZS4gSG9zdC1tZXRhIHdvdWxkIG5vdCBuZWVkIHRvIGJlIGEgc3BlY2lhbCBjYXNlIHdp dGggaXRzIG93biA8aG9zdC1tZXRhOlNjb3BlPi4gTWV0YWRhdGEgdGhhdCBhcHBsaWVkIHRvIGFs bCB0aGUgVVJJcyBpbiBhIHN1YmRpcmVjdG9yeSAoZWcgYWxsIHVuZGVyIC9ibG9nLyopIHdvdWxk IGJlIGVhc3kgdG8gZGVmaW5lLg0KDQoNCg0KPFhSRD4NCg0KIDxTdWJqZWN0UmVnZXg+aHR0cHM/ Oi8vKD86d3d3XC4pP2V4YW1wbGVcLmNvbS8oW14/I10qKShcP1teI10qKT8oI1wuKik/PC9TdWJq ZWN0UmVnZXg+DQoNCiA8TGluaz48UmVsPmF1dGhvcjwvUmVsPjxVUklQYXR0ZXJuPmh0dHBzOi8v d3d3LmV4YW1wbGUuY29tL1wxO2J5XDI8L1VSTFBhdHRlcm4+PC9MaW5rPg0KDQo8L1hSRD4NCg0K DQoNCkl0IGlzIGEgcGl0eSByZWdleHMgY2FuIGJlIGF3a3dhcmQgdG8gd3JpdGUgKCYgaGFyZGVy IHRvIHJlYWQpLiBJbmNsdWRpbmcgYW4gZXhhbXBsZSAob3IgZGVmYXVsdCB2YWx1ZT8pIGluIHRo ZSBzcGVjIHRoYXQgY2FwdHVyZXMgdGhlIHNjaGVtZSwgYXV0aG9yaXR5LCBwYXRoLCBxdWVyeSAm IGZyYWdtZW50IGNvdWxkIGJlIGFsbW9zdCBlcXVpdmFsZW50IHRvIHRoZSBjdXJyZW50IHRlbXBs YXRlIHByb3Bvc2FsICh3aXRoIG11Y2ggbW9yZSBmbGV4aWJpbGl0eSwgYnV0IGxlc3MgZnJpZW5k bHkgdmFyaWFibGUgbmFtZXMpLg0KDQoNCg0KDQoNCkphbWVzIE1hbmdlcg0KSmFtZXMuSC5NYW5n ZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNv bT4NCklkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGllZiBUZWNobm9sb2d5IE9mZmlj ZSDigJQgVGVsc3RyYQ0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E112485B4391WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0N CiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJ e3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K IDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FcmFuLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDsgPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIGV4YW1wbGVzIGFyZSBv YnZpb3VzbHkgbGltaXRlZCB0byBVUkkgd2l0aCBzcGVjaWZpYyBjaGFyYWN0ZXJpc3RpY3MuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPklmIHRoZSBwcmVzZW5jZSBvZiB0aGVzZSBleGFtcGxlcyBpcyBtaXNsZWFk aW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5ob3N0LW1ldGEgaXMgZXhwbGljaXRseSBub3QgbGltaXRlZCB0byBVUklzIHdp dGggc3BlY2lmaWMgY2hhcmFjdGVyaXN0aWNzIChhcyBpdCBjb3ZlcnMgb25lIG9yIG1vcmUgZW50 aXJlIGhvc3RzKSBzbyBJIHRoaW5rIHRoZXkgYXJlIG1pc2xlYWRpbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5bSXQgbWF5IGV2ZW4gYmUgcG90ZW50aWFsbHkgZGFuZ2Vyb3VzOiBhdHRh Y2tlciBzZW5kcyDigJxodHRwOi8vZXhhbXBsZS5jb20veHh4P+KAnSB0byB2aWN0aW07IHZpY3Rp bSAoJmFtcDsgc2VydmVyKSB0cmVhdCBpdCBhcyBlcXVpdmFsZW50IHRvIOKAnGh0dHA6Ly9leGFt cGxlLmNvbS94eHjigJ07IGJ1dCBtZXRhLWRhdGEgaXMgcmV0cmlldmVkIGZyb20gYQ0KIGRpZmZl cmVudCBzb3VyY2UgZ2l2ZW4geyYjNDM7dXJpfTttZXRhIHRlbXBsYXRlOiBmcm9tIC94eHggKHNl cnZlciBpZ25vcmVzIHVuZXhwZWN0ZWQg4oCcPzttZXRh4oCdIHF1ZXJ5IHN0cmluZyBpbiB0aGlz IHJlcXVlc3QpIHZzIGZyb20gL3h4eDttZXRhICh0aGF0IHNlcnZlciByZWNvZ25pemVzKS5dPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SSB3aWxsIGJlIGhhcHB5IHRvIGNoYW5nZSB0aGVtIHRvIHB1dCB0aGUge3VyaX0gYXQgdGhlIGVu ZCBhcyBhIHF1ZXJ5IHBhcmFtZXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2UgY2Fu4oCZdCBoYXZlIHRoZSBvbmx5IHJl YWxpc3RpYyBleGFtcGxlIGluIHRoZSBzcGVjIGJlaW5nIHt1cml9IGFzIGEgcXVlcnkgcGFyYW1l dGVyLiBJdCBpcyBubyB1c2UgaGF2aW5nIHRlbXBsYXRlcyBpbiB0aGF0IGNhc2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNo YW5naW5nIHRoZSBleHRlbnNpb24gKCouaHRtbCB0byAqLnhyZCksIGFwcGVuZGluZyDigJw7bWV0 YeKAnSB0byB0aGUgcGF0aCwgYWRkaW5nIGFuIOKAnF9hYm91dOKAnSBxdWVyeSBwYXJhbWV0ZXIs IHVzaW5nIGEgbWV0YWRhdGEuZXhhbXBsZS5jb20gc3ViLWRvbWFpbiBldGMgYWxsIHNvdW5kIGxp a2UgcmVhbGlzdGljIGNob2ljZXMgaG9zdHMgbWlnaHQNCiBtYWtlLiBUaGUgc3BlYyBzaG91bGQg aW5jbHVkZSBleGFtcGxlcyBmb3IgdGhlc2Ugc29ydHMgb2YgY2hvaWNlcy4gSWYgdGhlIGV4YW1w bGVzIGFyZSB0b28gY29tcGxleCB0aGVuIHRoZSBvbmx5IGFuc3dlciBpcyB0byBzaW1wbGlmeSB0 aGUgc3ludGF4LCBub3QganVzdCBvbWl0IHRoZSBleGFtcGxlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWYgZXhhbXBsZXMg bGlrZSA8L3NwYW4+DQp7JiM0MztzY2hlbWV9Oi8veyYjNDM7YXV0aG9yaXR5fXsmIzQzO3BhdGh9 O2J5P3smIzQzO3F1ZXJ5fTxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ IGFuZA0KPC9zcGFuPnsmIzQzO3NjaGVtZX06Ly97JiM0MzthdXRob3JpdHl9eyYjNDM7cGF0aH0/ eyYjNDM7cXVlcnl9JmFtcDt0ZXN0IDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCiZuYnNw OzxzcGFuIGxhbmc9IkVOLVVTIj5hcmUgdG9vIGNvbXBsZXggd2UgbmVlZCBhIHNpbXBsZXIgc3lu dGF4LjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToN CiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBhcHBzLWRpc2N1 c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYW5nZXIsIEphbWVzIEg8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBPY3RvYmVyIDI2LCAyMDA5IDEwOjAyIFBNPGJyPg0KPGI+VG86PC9iPiBhcHBzLWRp c2N1c3NAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gaG9zdC1tZXRhOiB0ZW1wbGF0ZSBz eW50YXggaGFzc2xlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL3JmY21hcmt1cD9kb2M9ZHJhZnQtaGFtbWVyLWhvc3RtZXRhI3NlY3Rpb24tMy4yLjEiPmRy YWZ0LWhhbW1lci1ob3N0bWV0YS0wMjwvYT4g4oCcSG9zdC1NZXRhOiBXZWIgSG9zdCBNZXRhZGF0 YeKAnSBkZWZpbmVzIGEgVVJJIHRlbXBsYXRlIHN5bnRheCBhbmQgdmFyaWFibGVzIGJhc2VkIG9u IHBhcnRzIG9mIGEgVVJJIFvCpzMuMi4xLl0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u 4oCZdCB0aGluayB0aGUgY3VycmVudCBhcnJhbmdlbWVudCBjYW4gd29yayBhcyBlYXNpbHkgYXMg dGhlIGV4YW1wbGVzIGluIHRoZSBkcmFmdCBzdWdnZXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgZXhhbXBsZSBvZiBhIGxpbmsgdG8gZWFjaCByZXNvdXJjZeKAmXMgYXV0aG9yIHByZXN1 bWFibHkgd2FudHMg4oCcO2J54oCdIHRvIGJlIGFwcGVuZGVkIHRvIHRoZSByZXNvdXJjZSBVUkni gJlzIHBhdGgg4oCUIGJ1dCB0aGF0IGlzIG5vdCB3aGF0IHRoZSDigJx7JiM0Mzt1cml9O2J54oCd IHRlbXBsYXRlIGRvZXMuPG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyAmbHQ7TGluayZndDsg Jmx0O1JlbCZndDthdXRob3ImbHQ7L1JlbCZndDsgJmx0O1VSSVRlbXBsYXRlJmd0O3smIzQzO3Vy aX07YnkmbHQ7L1VSSVRlbXBsYXRlJmd0OyAmbHQ7L0xpbmsmZ3Q7PG86cD48L286cD48L3ByZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBVUklzIHdpdGggcXVlcnkgc3RyaW5ncywg4oCcO2J5 4oCdIGlzIGFwcGVuZGVkIHRvIHRoZSBsYXN0IHF1ZXJ5IHBhcmFtZXRlciB2YWx1ZS4gVGhpcyBp cyBhbG1vc3QgY2VydGFpbmx5IE5PVCBkZXNpcmVkLiBUaGUgb3JkZXIgb2YgcXVlcnkgcGFyYW1l dGVycyBpcyBub3JtYWxseSBpcnJlbGV2YW50IGJ1dCB0aGlzIHRlbXBsYXRlIGNoYW5nZXMgdGhl IHZhbHVlIG9mIHdoaWNoZXZlciBwYXJhbWV0ZXIgaGFwcGVucw0KIHRvIGJlIGxhc3QuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkEgbW9yZSBjb3JyZWN0IHRlbXBsYXRlIGlzIHByb2JhYmx5OiDi gJx7JiM0MztzY2hlbWV9Oi8veyYjNDM7YXV0aG9yaXR5fXsmIzQzO3BhdGh9O2J5P3smIzQzO3F1 ZXJ5feKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qgc3Vy ZSB0aGF0IGV2ZW4gdGhpcyBpcyBjb3JyZWN0IGlmIHRoZSBwYXRoIGlzIGVtcHR5IChlZyB5b3Ug bWF5IGdldCB0aGUgaW52YWxpZCBVUkkg4oCcaHR0cDovL2V4YW1wbGUubmV0O2J5P+KAnSk8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIHdpbGwgYWxzbyBiZSBhIHRy YWlsaW5nIOKAnD/igJ0gd2hlbiB0aGVyZSBhcmUgbm8gcXVlcnkgcGFyYW1ldGVycywgd2hpY2gg bWF5IGJlIG1vc3RseSBoYXJtbGVzcywgYnV0IGlzIHN0cmljdGx5IGRpZmZlcmVudCBmcm9tIGEg VVJJIHdpdGhvdXQgdGhlIOKAnD/igJ0gc28gY2FjaGluZyBhbmQgY29tcGFyaXNvbnMgYXJlIGFk dmVyc2VseSBhZmZlY3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5vdGhlciBleGFtcGxl IGZyb20gdGhlIGRyYWZ0IGlzIOKAnHsmIzQzO3VyaX0mYW1wO3Rlc3TigJ0uIFRoaXMgZWl0aGVy IG1ha2VzIOKAnCZhbXA7dGVzdOKAnSBwYXJ0IG9mIHRoZSBwYXRoLCBvciBhIG5ldyBxdWVyeSBw YXJhbWV0ZXIgKGRlcGVuZGluZyBvbiB3aGV0aGVyIG9yIG5vdCB0aGUgVVJJIGFscmVhZHkgaGFz IGEgcXVlcnkgc3RyaW5nKS4gVGhpcyBpcyBwcm9iYWJseSBuZXZlciBkZXNpcmFibGUuIElmIGEg dGVtcGxhdGUgd2FudHMNCiB0byBhZGQgYSBxdWVyeSBwYXJhbWV0ZXIgaXQgcHJvYmFibHkgbmVl ZHMgdG8gc3BlY2lmeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A74oCceyYjNDM7c2NoZW1lfTovL3smIzQzO2F1dGhvcml0eX17JiM0MztwYXRofT97JiM0 MztxdWVyeX0mYW1wO3Rlc3TigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5FdmVuIHRoaXMgaXMgbm90IGlkZWFsIGFzIGl0IHByb2R1Y2VzIHVudXN1YWwgVVJJcyBzdWNo IGFzIOKAnDxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLm5ldC9hcnRpY2xlPyZhbXA7dGVzdCI+aHR0 cDovL2V4YW1wbGUubmV0L2FydGljbGU/JmFtcDt0ZXN0PC9hPuKAnSwgd2hpY2ggYWdhaW4gbWF5 IGJlIG1vc3RseSBoYXJtbGVzcyBidXQgaXMgc3RyaWN0bHkgZGlmZmVyZW50IGZyb20gYSBVUkkg d2l0aCBqdXN0IOKAnD90ZXN04oCdIHNvIGNhY2hpbmcNCiBhbmQgY29tcGFyaXNvbnMgYXJlIGFk dmVyc2VseSBhZmZlY3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5vdGhlciBleGFtcGxl IGZyb20gdGhlIHNwZWMgaXMg4oCcaHR0cDovL21ldGEue2hvc3R9OjgwODB7JiM0MztwYXRofT97 JiM0MztxdWVyeX3igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBz b21lIFVSSXMgbWlnaHQgaGF2ZSBhIHVzZXJpbmZvIGNvbXBvbmVudCB0aGVuIHRoZSB0ZW1wbGF0 ZSBuZWVkcyB0byBiZSDigJxodHRwOi8veyYjNDM7dXNlcmluZm99QG1ldGEue2hvc3R9OjgwODB7 JiM0MztwYXRofT97JiM0MztxdWVyeX3igJ0uIEhvd2V2ZXIsIHdoZW4gdGhlcmUgaXMgbm8gdXNl cmluZm8gdGhlIHJlc3VsdGluZyBVUkkgc3RhcnRzIGh0dHA6Ly9A4oCmIHRoYXQgKGluIHNvbWUg Y2xpZW50cyBhdCBsZWFzdCwgZWcgY3VybCkNCiBjYXVzZXMgYSDigJxBdXRob3JpemF0aW9uOiBC YXNpYyBPZz094oCdIGhlYWRlciB0byBiZSBpbmNsdWRlZCB3aGVuIHJlcXVlc3RpbmcgdGhlIFVS SS4gVGhhdCBjb3VsZCBiZSBoYXJtZnVsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UC5TLiBJdCBzaG91bGQgcHJvYmFibHkgYWxzbyB1c2UgeyYjNDM7aG9zdH0sIGluc3Rl YWQgb2Yge2hvc3R9LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBtaW5pbWFsIChwYXJ0aWFsKSBzb2x1dGlvbiBp cyB0byBjaGFuZ2UgdGhlIGV4YW1wbGVzIGluIHRoZSBkcmFmdCB0byBiZSByZWFsaXN0aWMgKGVn IHdvcmsgZm9yIGFsbCBVUklzIGluIHRoZSBzY29wZSwgd2l0aCBvciB3aXRob3V0IHF1ZXJ5IHN0 cmluZ3MpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm90aGVyIHNvbHV0aW9uIGlzIHRvIGRl ZmluZSBhIG1vcmUgc29waGlzdGljYXRlZCB0ZW1wbGF0ZSBzeW50YXguIEEgc3ludGF4IHRoYXQg bGlzdHMgYSBwcmVmaXggdGhhdCBpcyBvbmx5IHN1YnN0aXR1dGVkIHdoZW4gdGhlIHZhcmlhYmxl IGlzIGRlZmluZWQgKG5vbi1udWxsKSBtYXkgYmUgYWxtb3N0IHN1ZmZpY2llbnQuIFRoYXQgYWRk cmVzcyB0aGUgcHJvYmxlbSB0aGF0IHRoZSBkZWZpbmVkIHZhcmlhYmxlcw0KIGZvciBVUkkgcGFy dHMgKHNjaGVtZSwgYXV0aG9yaXR5LCBxdWVyeSwgZnJhZ21lbnQsIHVzZXJpbmZvLCBob3N0LCBw b3J0KSBkb27igJl0IGluY2x1ZGUgdGhlIHNlcGFyYXRvciBjaGFyYWN0ZXJzIHVzZWQgd2hlbiBj b21iaW5pbmcgdGhlIHBhcnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBob3N0LW1ldGEgY2FzZSBhIGJl dHRlciBzb2x1dGlvbiB3b3VsZCBiZSB0byBkZWZpbmUgdGhlIHRyYW5zbGF0aW9uIGZyb20gcmVz b3VyY2UgVVJJIHRvIGxpbmsgVVJJIHdpdGggYSByZWd1bGFyIGV4cHJlc3Npb24gYW5kIHJlcGxh Y2VtZW50IHN0cmluZy4gVGhlIHJlcGxhY2VtZW50IHN0cmluZyBjYW4gcmVmZXJlbmNlIOKAnGNh cHR1cmluZyBncm91cHPigJ0gaW4gdGhlIHJlZ3VsYXIgZXhwcmVzc2lvbi4NCiBJIGFtIHN1cmUg YWxsIG1vZGVybiBwcm9ncmFtbWluZyBsYW5ndWFnZXMgb2ZmZXIgYnJvYWRseSBzaW1pbGFyIHJl Z2V4LWJhc2VkIHJlcGxhY2VtZW50IGZ1bmN0aW9uYWxpdHkuIEZvciBpbnN0YW5jZSwgZm9yIEph dmEgc2VlDQo8YSBocmVmPSJodHRwOi8vamF2YS5zdW4uY29tL2phdmFzZS82L2RvY3MvYXBpL2ph dmEvbGFuZy9TdHJpbmcuaHRtbCNyZXBsYWNlQWxsKGphdmEubGFuZy5TdHJpbmcsJTIwamF2YS5s YW5nLlN0cmluZykiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPlM8L3NwYW4+dHJpbmcjcmVwbGFjZUZpcnN0KHJlZ2V4LCByZXBsYWNlbWVudCk8 L2E+IGFuZA0KPGEgaHJlZj0iaHR0cDovL2phdmEuc3VuLmNvbS9qYXZhc2UvNi9kb2NzL2FwaS9q YXZhL3V0aWwvcmVnZXgvTWF0Y2hlci5odG1sI2FwcGVuZFJlcGxhY2VtZW50JTI4amF2YS5sYW5n LlN0cmluZ0J1ZmZlciwlMjBqYXZhLmxhbmcuU3RyaW5nJTI5Ij4NCk1hdGNoZXIuYXBwZW5kUmVw bGFjZW1lbnQ8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVuIHRoZSBxdWVzdGlvbiBp cyB3aGVyZSBpcyB0aGUgcmVnZXggc3BlY2lmaWVkOiBpbiB0aGUgJmx0O0xpbmsmZ3Q7IG9yIGFz IHRoZSAmbHQ7U3ViamVjdCZndDs/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Vc2luZyBhIHJlZ3VsYXIgZXhwcmVzc2lvbiB0byBpbmRpY2F0ZSBhbGwgdGhlIFVSSXMgdGhh dCB0aGUgbWV0YWRhdGEgKFhSRCkgYXBwbGllcyB0byAoaWUgdGhlIFhSROKAmXMgc3ViamVjdCkg ZmVlbHMgZmxleGlibGUgYW5kIGFwcHJvcHJpYXRlLiBIb3N0LW1ldGEgd291bGQgbm90IG5lZWQg dG8gYmUgYSBzcGVjaWFsIGNhc2Ugd2l0aCBpdHMgb3duICZsdDtob3N0LW1ldGE6U2NvcGUmZ3Q7 LiBNZXRhZGF0YSB0aGF0IGFwcGxpZWQNCiB0byBhbGwgdGhlIFVSSXMgaW4gYSBzdWJkaXJlY3Rv cnkgKGVnIGFsbCB1bmRlciAvYmxvZy8qKSB3b3VsZCBiZSBlYXN5IHRvIGRlZmluZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmx0O1hSRCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZsdDtTdWJqZWN0UmVnZXgmZ3Q7aHR0cHM/Oi8vKD86d3d3XC4pP2V4 YW1wbGVcLmNvbS8oW14/I10qKShcP1teI10qKT8oI1wuKik/Jmx0Oy9TdWJqZWN0UmVnZXgmZ3Q7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbHQ7TGluayZndDsm bHQ7UmVsJmd0O2F1dGhvciZsdDsvUmVsJmd0OyZsdDtVUklQYXR0ZXJuJmd0O2h0dHBzOi8vd3d3 LmV4YW1wbGUuY29tL1wxO2J5XDImbHQ7L1VSTFBhdHRlcm4mZ3Q7Jmx0Oy9MaW5rJmd0OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0Oy9YUkQmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkl0IGlzIGEgcGl0eSByZWdleHMgY2FuIGJlIGF3a3dhcmQgdG8gd3JpdGUg KCZhbXA7IGhhcmRlciB0byByZWFkKS4gSW5jbHVkaW5nIGFuIGV4YW1wbGUgKG9yIGRlZmF1bHQg dmFsdWU/KSBpbiB0aGUgc3BlYyB0aGF0IGNhcHR1cmVzIHRoZSBzY2hlbWUsIGF1dGhvcml0eSwg cGF0aCwgcXVlcnkgJmFtcDsgZnJhZ21lbnQgY291bGQgYmUgYWxtb3N0IGVxdWl2YWxlbnQgdG8g dGhlIGN1cnJlbnQgdGVtcGxhdGUgcHJvcG9zYWwNCiAod2l0aCBtdWNoIG1vcmUgZmxleGliaWxp dHksIGJ1dCBsZXNzIGZyaWVuZGx5IHZhcmlhYmxlIG5hbWVzKS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmFtZXMgTWFuZ2VyPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPg0KPGJyPg0KPGEgaHJlZj0ibWFpbHRvOkph bWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5KYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9zcGFuPjwvYT4NCjxi cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZGVudGl0eSBhbmQgc2VjdXJp dHkgdGVhbTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igJQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IENoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAlDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVsc3RyYTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E112485B4391WSMSG3153Vsrv_-- From alexey.melnikov@isode.com Tue Oct 27 03:28:24 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03E328C143 for ; Tue, 27 Oct 2009 03:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 Pn0xiSx-a+qy for ; Tue, 27 Oct 2009 03:28:24 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0AB083A69D2 for ; Tue, 27 Oct 2009 03:28:24 -0700 (PDT) Received: from [172.16.2.124] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 27 Oct 2009 10:28:37 +0000 Message-ID: <4AE6CB4E.9030701@isode.com> Date: Tue, 27 Oct 2009 10:28:30 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Peter Saint-Andre Subject: Re: Identity Checking in Application Protocols References: <4AE62AB7.8080607@stpeter.im> In-Reply-To: <4AE62AB7.8080607@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 10:28:25 -0000 Hi Peter, Peter Saint-Andre wrote: > I had hoped to update draft-saintandre-tls-server-id-check before the > submission cutoff today, but it's not going to happen because there's > quite a bit of feedback to sift through (ideally I would have followed > the list discussions more closely the first time around). However, I > shall work to update it in the next few days, at which time I will also > rename it to remove the strings "tls" and "server" since the scope of > the spec has widened to include non-TLS interactions as well as client > identity checking. My apologies for the delay. > Without my AD hat: I don't think the document should cover client identity checking. I found Kurt's arguments to be convincing. From cyrus@daboo.name Tue Oct 27 06:15:18 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9749828C143 for ; Tue, 27 Oct 2009 06:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z3IXVutmakO for ; Tue, 27 Oct 2009 06:15:18 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id C85193A6859 for ; Tue, 27 Oct 2009 06:15:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 41CDC280B2C; Tue, 27 Oct 2009 09:15:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuOoyrFs7VKP; Tue, 27 Oct 2009 09:15:29 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id E4609280B25; Tue, 27 Oct 2009 09:15:27 -0400 (EDT) Date: Tue, 27 Oct 2009 09:15:21 -0400 From: Cyrus Daboo To: Eran Hammer-Lahav , "Manger, James H" , apps-discuss@ietf.org Subject: RE: host-meta: template syntax hassles Message-ID: <40373AF30BED1C371002947A@caldav.corp.apple.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NE T> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=633 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 13:15:18 -0000 Hi Eran, --On October 26, 2009 10:32:47 PM -0700 Eran Hammer-Lahav=20 wrote: > Defining a more complex syntax is absolutely out of scope. The template > syntax is kept intentionally simple and a subset of Roy=E2=80=99s = proposal for > a URI template standard in hopes that when that work is completed, it > will be forward compatible (code written for the new proposal being able > to handle old files). > > There was an old URI template draft:=20 ? Has any thought = been given to reviving that, or is Roy working on something else = altogether? --=20 Cyrus Daboo From julian.reschke@gmx.de Tue Oct 27 06:21:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F58C28C133 for ; Tue, 27 Oct 2009 06:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.067 X-Spam-Level: X-Spam-Status: No, score=-4.067 tagged_above=-999 required=5 tests=[AWL=-1.468, 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 l8z4Z6RSdrUq for ; Tue, 27 Oct 2009 06:21:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 707B228C143 for ; Tue, 27 Oct 2009 06:21:37 -0700 (PDT) Received: (qmail invoked by alias); 27 Oct 2009 13:21:51 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 27 Oct 2009 14:21:51 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18lRypI2iMl07+YAxnBUGNszHteZ4McDCwR4mRZHN XYq0+F3/7BSMnZ Message-ID: <4AE6F3EA.2070901@gmx.de> Date: Tue, 27 Oct 2009 14:21:46 +0100 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: Cyrus Daboo Subject: Re: host-meta: template syntax hassles References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NE T> <40373AF30BED1C371002947A@caldav.corp.apple.com> In-Reply-To: <40373AF30BED1C371002947A@caldav.corp.apple.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Cc: "Manger, James H" , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 13:21:39 -0000 Cyrus Daboo wrote: > Hi Eran, > > --On October 26, 2009 10:32:47 PM -0700 Eran Hammer-Lahav > wrote: > >> Defining a more complex syntax is absolutely out of scope. The template >> syntax is kept intentionally simple and a subset of Roy’s proposal for >> a URI template standard in hopes that when that work is completed, it >> will be forward compatible (code written for the new proposal being able >> to handle old files). >> >> > > There was an old URI template draft: > ? Has any > thought been given to reviving that, or is Roy working on something else > altogether? As far as I recall, Roy has been working on it in July, but I'm not sure what the current status is... See: BR, Julian From eran@hueniverse.com Tue Oct 27 08:55:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD913A690F for ; Tue, 27 Oct 2009 08:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 eD+x5dCgFdcm for ; Tue, 27 Oct 2009 08:55:38 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 535793A69B2 for ; Tue, 27 Oct 2009 08:55:38 -0700 (PDT) Received: (qmail 30880 invoked from network); 27 Oct 2009 15:55:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Oct 2009 15:55:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 27 Oct 2009 08:55:51 -0700 From: Eran Hammer-Lahav To: Julian Reschke , Cyrus Daboo Date: Tue, 27 Oct 2009 08:55:45 -0700 Subject: RE: host-meta: template syntax hassles Thread-Topic: host-meta: template syntax hassles Thread-Index: AcpXCHPKomybVYPWSVSgCV3bbjNYxQAFJ9Ig Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784FE8E8B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NE T> <40373AF30BED1C371002947A@caldav.corp.apple.com> <4AE6F3EA.2070901@gmx.de> In-Reply-To: <4AE6F3EA.2070901@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Manger, James H" , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:55:39 -0000 VGhlIG1vc3QgcmVjZW50IHByb3Bvc2FsIChub3QgeWV0IHN1Ym1pdHRlZCBhcyBhbiBJLUQgYnV0 IGF2YWlsYWJsZSBmcm9tIHRoZSBsaW5rIEp1bGlhbiBtZW50aW9uZWQgYmVsb3cpIGlzIHZlcnkg ZGlmZmVyZW50IGZyb20gdGhlIGN1cnJlbnQgZHJhZnQuIElkZWFsbHksIGhvc3QtbWV0YSB3b3Vs ZCBzaW1wbHkgcmVmZXJlbmNlIGl0IGFuZCBiZSBkb25lIHdpdGggaXQgKHdoaWNoIGlzIHRoZSBt YWluIGdvYWwgb2YgdGhlIGNvbW11bml0eSB3b3JraW5nIG9uIHRoaXMgcHJvcG9zYWwpLiBIb3dl dmVyLCBpdCBpcyB1bmxpa2VseSB0aGF0IHRoZSB0ZW1wbGF0ZSBkcmFmdCB3aWxsIGJlIGNvbXBs ZXRlZCBhbmQgcHVibGlzaGVkIGFzIGFuIFJGQyBpbiB0aGUgbmVhciBmdXR1cmUuIFdoYXQgSSBo YXZlIGF0dGVtcHRlZCB0byBkbyBpcyB0YWtlIHRoZSBiYXJlIG1pbmltdW0gbmVlZGVkIHRvIGhh dmUgc29tZSBraW5kIG9mIGJhc2ljIHRlbXBsYXRlIGZ1bmN0aW9uYWxpdHkgd2hpbGUgYXQgdGhl IHNhbWUgdGltZSBhbGxvd2luZyB1cGdyYWRlIGluIHRoZSBmdXR1cmUuIFdoaWxlIHRoZXJlIGlz IG5vIGd1YXJhbnRlZSB0aGF0IHRoZSB0ZW1wbGF0ZSBwcm9wb3NhbCBpcyBub3QgZ29pbmcgdG8g Y2hhbmdlIHlldCBhZ2FpbiwgSSBmZWVsIG1vcmUgY29tZm9ydGFibGUgd2l0aCB0aGlzIGFwcHJv YWNoIHRoYW4gbWFraW5nIHVwIGEgd2hvbGUgbmV3LCBjb21wZXRpbmcsIHRlbXBsYXRlIHN5bnRh eC4NCg0KSSBhbSBvcGVuIHRvIG90aGVyIHN1Z2dlc3Rpb25zLCBob3dldmVyLCBJIGFtIGNvbXBs ZXRlbHkgb3Bwb3NlZCB0byB0aGUgY3JlYXRpb24gb2YgYW55IG5ldyB0ZW1wbGF0ZSBzeW50YXgg dW5yZWxhdGVkIHRvIHRoZSBkcmFmdC1ncmVnb3Jpby11cml0ZW1wbGF0ZSBlZmZvcnQuDQoNCkhv cGVmdWxseSBSb3kgd2lsbCBmaW5kIHRpbWUgc29vbiB0byBwdWJsaXNoIGhpcyBuZXcgc3ludGF4 IGFzIGFuIEktRC4NCg0KRUhMDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogSnVsaWFuIFJlc2Noa2UgW21haWx0bzpqdWxpYW4ucmVzY2hrZUBnbXguZGVdDQo+IFNlbnQ6 IFR1ZXNkYXksIE9jdG9iZXIgMjcsIDIwMDkgNjoyMiBBTQ0KPiBUbzogQ3lydXMgRGFib28NCj4g Q2M6IEVyYW4gSGFtbWVyLUxhaGF2OyBNYW5nZXIsIEphbWVzIEg7IGFwcHMtZGlzY3Vzc0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogaG9zdC1tZXRhOiB0ZW1wbGF0ZSBzeW50YXggaGFzc2xlcw0K PiANCj4gQ3lydXMgRGFib28gd3JvdGU6DQo+ID4gSGkgRXJhbiwNCj4gPg0KPiA+IC0tT24gT2N0 b2JlciAyNiwgMjAwOSAxMDozMjo0NyBQTSAtMDcwMCBFcmFuIEhhbW1lci1MYWhhdg0KPiA+IDxl cmFuQGh1ZW5pdmVyc2UuY29tPiB3cm90ZToNCj4gPg0KPiA+PiBEZWZpbmluZyBhIG1vcmUgY29t cGxleCBzeW50YXggaXMgYWJzb2x1dGVseSBvdXQgb2Ygc2NvcGUuIFRoZQ0KPiB0ZW1wbGF0ZQ0K PiA+PiBzeW50YXggaXMga2VwdCBpbnRlbnRpb25hbGx5IHNpbXBsZSBhbmQgYSBzdWJzZXQgb2Yg Um954oCZcyBwcm9wb3NhbA0KPiBmb3INCj4gPj4gYSBVUkkgdGVtcGxhdGUgc3RhbmRhcmQgaW4g aG9wZXMgdGhhdCB3aGVuIHRoYXQgd29yayBpcyBjb21wbGV0ZWQsDQo+IGl0DQo+ID4+IHdpbGwg YmUgZm9yd2FyZCBjb21wYXRpYmxlIChjb2RlIHdyaXR0ZW4gZm9yIHRoZSBuZXcgcHJvcG9zYWwg YmVpbmcNCj4gYWJsZQ0KPiA+PiB0byBoYW5kbGUgb2xkIGZpbGVzKS4NCj4gPj4NCj4gPj4NCj4g Pg0KPiA+IFRoZXJlIHdhcyBhbiBvbGQgVVJJIHRlbXBsYXRlIGRyYWZ0Og0KPiA+IDxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ncmVnb3Jpby11cml0ZW1wbGF0ZS0wMz4/IEhhcyBh bnkNCj4gPiB0aG91Z2h0IGJlZW4gZ2l2ZW4gdG8gcmV2aXZpbmcgdGhhdCwgb3IgaXMgUm95IHdv cmtpbmcgb24gc29tZXRoaW5nDQo+IGVsc2UNCj4gPiBhbHRvZ2V0aGVyPw0KPiANCj4gQXMgZmFy IGFzIEkgcmVjYWxsLCBSb3kgaGFzIGJlZW4gd29ya2luZyBvbiBpdCBpbiBKdWx5LCBidXQgSSdt IG5vdA0KPiBzdXJlDQo+IHdoYXQgdGhlIGN1cnJlbnQgc3RhdHVzIGlzLi4uDQo+IA0KPiBTZWU6 IDxodHRwOi8vY29kZS5nb29nbGUuY29tL3AvdXJpLXRlbXBsYXRlcy8+DQo+IA0KPiBCUiwgSnVs aWFuDQoNCg== From eran@hueniverse.com Tue Oct 27 09:12:52 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4553A6A2B for ; Tue, 27 Oct 2009 09:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 0KOmc8iywT5N for ; Tue, 27 Oct 2009 09:12:51 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7F33F3A68FF for ; Tue, 27 Oct 2009 09:12:51 -0700 (PDT) Received: (qmail 24281 invoked from network); 27 Oct 2009 16:13:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 27 Oct 2009 16:13:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 27 Oct 2009 09:11:51 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" Date: Tue, 27 Oct 2009 09:11:45 -0700 Subject: RE: host-meta: template syntax hassles Thread-Topic: host-meta: template syntax hassles Thread-Index: AcpWwpMrO2fBkK/zTVK4PvsTZrNbFQAA8nsQAAEiIMAAFM36oA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784FE8EA5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112485B4391@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112485B4391@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:12:52 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogYXBwcy1kaXNjdXNzLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtDQo+IGJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNYW5nZXIsIEphbWVzIEgNCj4gU2VudDogVHVlc2RheSwgT2N0b2JlciAy NywgMjAwOSAxMjowNCBBTQ0KPiBUbzogYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJFOiBob3N0LW1ldGE6IHRlbXBsYXRlIHN5bnRheCBoYXNzbGVzDQo+IA0KPiBFcmFuLA0KPiAN Cj4gPiBUaGUgZXhhbXBsZXMgYXJlIG9idmlvdXNseSBsaW1pdGVkIHRvIFVSSSB3aXRoIHNwZWNp ZmljDQo+IGNoYXJhY3RlcmlzdGljcy4NCj4gPiBJZiB0aGUgcHJlc2VuY2Ugb2YgdGhlc2UgZXhh bXBsZXMgaXMgbWlzbGVhZGluZywNCj4gDQo+IGhvc3QtbWV0YSBpcyBleHBsaWNpdGx5IG5vdCBs aW1pdGVkIHRvIFVSSXMgd2l0aCBzcGVjaWZpYw0KPiBjaGFyYWN0ZXJpc3RpY3MgKGFzIGl0IGNv dmVycyBvbmUgb3IgbW9yZSBlbnRpcmUgaG9zdHMpIHNvIEkgdGhpbmsgdGhleQ0KPiBhcmUgbWlz bGVhZGluZy4NCg0KSSB3aWxsIGNoYW5nZSB0aGVtIHRvIGJlIG1vcmUgY29uc2lzdGVudCB3aXRo IHRoZSBzY29wZS4gSG93ZXZlciwgaXQgaXMgdWx0aW1hdGVseSB0aGUgam9iIG9mIHRoZSBkb2N1 bWVudCBhdXRob3IgdG8gbWFrZSBzdXJlIHRoZSB0ZW1wbGF0ZXMgYXJlIGNvbXBhdGlibGUgd2l0 aCB0aGUgVVJJIG5hbWVzcGFjZSBpdCBjb3ZlcnMuIFN1Z2dlc3Rpb25zIHRvIGF0dHJpYnV0ZSBz cGVjaWZpYyBzY2hlbWVzIG9yIHJlc291cmNlIHN1YnNldHMgdG8gbGlua3MgaGF2ZSBiZWVuIHJl amVjdGVkIGluIHRoZSBwYXN0IGFzIHRvbyBjb21wbGV4IGFuZCB3aXRob3V0IGFjdHVhbCB1c2Ug Y2FzZXMsIHNvIEkgYW0gbm90IGluY2xpbmVkIHRvIGNvbXBsaWNhdGUgdGhlIG92ZXJhbGwgc2No ZW1hLg0KDQo+IFtJdCBtYXkgZXZlbiBiZSBwb3RlbnRpYWxseSBkYW5nZXJvdXM6IGF0dGFja2Vy IHNlbmRzDQo+IOKAnGh0dHA6Ly9leGFtcGxlLmNvbS94eHg/4oCdIHRvIHZpY3RpbTsgdmljdGlt ICgmIHNlcnZlcikgdHJlYXQgaXQgYXMNCj4gZXF1aXZhbGVudCB0byDigJxodHRwOi8vZXhhbXBs ZS5jb20veHh44oCdOyBidXQgbWV0YS1kYXRhIGlzIHJldHJpZXZlZCBmcm9tDQo+IGEgZGlmZmVy ZW50IHNvdXJjZSBnaXZlbiB7K3VyaX07bWV0YSB0ZW1wbGF0ZTogZnJvbSAveHh4IChzZXJ2ZXIN Cj4gaWdub3JlcyB1bmV4cGVjdGVkIOKAnD87bWV0YeKAnSBxdWVyeSBzdHJpbmcgaW4gdGhpcyBy ZXF1ZXN0KSB2cyBmcm9tDQo+IC94eHg7bWV0YSAodGhhdCBzZXJ2ZXIgcmVjb2duaXplcykuXQ0K DQpJIHRoaW5rIHRoaXMgaXMgbW9yZSBhYm91dCBwb29yIFVSSSBhbmQgdGVtcGxhdGUgZGVzaWdu IHRoYW4gYSBzZWN1cml0eSB0aHJlYXQuIFRoaXMgd2lsbCBhbHdheXMgYmUgdGhlIGNhc2UgdW5s ZXNzIHRoZSBvbmx5IHZhcmlhYmxlIGFsbG93ZWQgaXMgdGhlIGZ1bGwgVVJJIHN0cmluZy4gUHJv dG9jb2xzIG1ha2luZyBzZWN1cml0eS1zZW5zaXRpdmUgZGVjaXNpb25zIGJhc2VkIG9uIFVSSSB0 ZW1wbGF0ZXMgc2hvdWxkIHdhdGNoIG91dCBmb3Igc3VjaCBtYW5pcHVsYXRpb25zLiBJIHdpbGwg YWRkIHRoaXMgdG8gdGhlIHNlY3VyaXR5IHNlY3Rpb24gb2YgdGhlIHNwZWMuDQogDQo+ID4gSSB3 aWxsIGJlIGhhcHB5IHRvIGNoYW5nZSB0aGVtIHRvIHB1dCB0aGUge3VyaX0gYXQgdGhlIGVuZCBh cyBhIHF1ZXJ5DQo+IHBhcmFtZXRlci4NCj4gDQo+IFdlIGNhbuKAmXQgaGF2ZSB0aGUgb25seSBy ZWFsaXN0aWMgZXhhbXBsZSBpbiB0aGUgc3BlYyBiZWluZyB7dXJpfSBhcyBhDQo+IHF1ZXJ5IHBh cmFtZXRlci4gSXQgaXMgbm8gdXNlIGhhdmluZyB0ZW1wbGF0ZXMgaW4gdGhhdCBjYXNlLg0KPiAN Cj4gQ2hhbmdpbmcgdGhlIGV4dGVuc2lvbiAoKi5odG1sIHRvICoueHJkKSwgYXBwZW5kaW5nIOKA nDttZXRh4oCdIHRvIHRoZQ0KPiBwYXRoLCBhZGRpbmcgYW4g4oCcX2Fib3V04oCdIHF1ZXJ5IHBh cmFtZXRlciwgdXNpbmcgYSBtZXRhZGF0YS5leGFtcGxlLmNvbQ0KPiBzdWItZG9tYWluIGV0YyBh bGwgc291bmQgbGlrZSByZWFsaXN0aWMgY2hvaWNlcyBob3N0cyBtaWdodCBtYWtlLiBUaGUNCj4g c3BlYyBzaG91bGQgaW5jbHVkZSBleGFtcGxlcyBmb3IgdGhlc2Ugc29ydHMgb2YgY2hvaWNlcy4g SWYgdGhlDQo+IGV4YW1wbGVzIGFyZSB0b28gY29tcGxleCB0aGVuIHRoZSBvbmx5IGFuc3dlciBp cyB0byBzaW1wbGlmeSB0aGUNCj4gc3ludGF4LCBub3QganVzdCBvbWl0IHRoZSBleGFtcGxlcy4N Cj4gDQo+IElmIGV4YW1wbGVzIGxpa2UgeytzY2hlbWV9Oi8veythdXRob3JpdHl9eytwYXRofTti eT97K3F1ZXJ5fSBhbmQNCj4geytzY2hlbWV9Oi8veythdXRob3JpdHl9eytwYXRofT97K3F1ZXJ5 fSZ0ZXN0IMKgYXJlIHRvbyBjb21wbGV4IHdlIG5lZWQNCj4gYSBzaW1wbGVyIHN5bnRheC4NCg0K SSBkb27igJl0IHRoaW5rIHRoZXkgYXJlIHRvbyBjb21wbGV4LiBJIHdpbGwgYWRkIGEgbW9yZSBl eHRlbnNpdmUgc2VjdGlvbiB3aXRoIHN1Y2ggZXhhbXBsZXMuIFlvdSBtaWdodCBiZSByaWdodCB0 aGF0IHRoZSBzeW50YXggYXMgY3VycmVudGx5IHByb3Bvc2VkIG1pZ2h0IG5vdCBiZSBhYmxlIHRv IGFjY29tcGxpc2ggYWxsIHRoZXNlIHVzZSBjYXNlcyAoZHVlIHRvIGVtcHR5IHBhcmFtZXRlcnMg YW5kIGluYWJpbGl0eSB0byBjb25kaXRpb24gdGhlIGluY2x1c2lvbiBvZiBhIHNlcGFyYXRvciAt ICYsID8sIGV0Yy4gLSBmb3Igbm9uLWVtcHR5IHBhcmFtZXRlcnMpLiBSb3kncyBwcm9wb3NhbCBo YW5kbGVzIHRoZXNlIGNhc2VzIGJ1dCBhdCBzb21lIHBvaW50IGl0IGJlY29tZXMgb2JzY2VuZSB0 byBjb3B5L3Bhc3RlIGxhcmdlciBjaHVua3Mgb2YgdGhhdCB3b3JrLiBUaGUgc2ltcGxlc3Qgc29s dXRpb24gd291bGQgYmUgdG8gZGVmaW5lIGEgZmV3IG1vcmUgdmFyaWFibGVzIHdoaWNoIHdpbGwg aW5jbHVkZSB0aGUgc2VwYXJhdG9yIHdoZW4gbm90IGVtcHR5Lg0KDQpJJ2xsIGdpdmUgaXQgYSB0 cnkgaW4gdGhlIG5leHQgZHJhZnQuDQoNClRoYW5rcywNCg0KRUhMDQo= From stpeter@stpeter.im Tue Oct 27 14:28:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B9C3A688D for ; Tue, 27 Oct 2009 14:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 T3lMUDBtvjnM for ; Tue, 27 Oct 2009 14:28:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 17C703A67AA for ; Tue, 27 Oct 2009 14:28:27 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4A1BF4008F; Tue, 27 Oct 2009 15:28:41 -0600 (MDT) Message-ID: <4AE76608.6030607@stpeter.im> Date: Tue, 27 Oct 2009 15:28:40 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Identity Checking in Application Protocols References: <4AE62AB7.8080607@stpeter.im> <4AE6CB4E.9030701@isode.com> In-Reply-To: <4AE6CB4E.9030701@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 21:28:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/09 4:28 AM, Alexey Melnikov wrote: > Hi Peter, > > Peter Saint-Andre wrote: >> I had hoped to update draft-saintandre-tls-server-id-check before the >> submission cutoff today, but it's not going to happen because there's >> quite a bit of feedback to sift through (ideally I would have followed >> the list discussions more closely the first time around). However, I >> shall work to update it in the next few days, at which time I will also >> rename it to remove the strings "tls" and "server" since the scope of >> the spec has widened to include non-TLS interactions as well as client >> identity checking. My apologies for the delay. >> > Without my AD hat: I don't think the document should cover client > identity checking. I found Kurt's arguments to be convincing. I think that the distinction between application roles and security roles causes some confusion here. This I-D talks about security roles, not application roles. Thus, for example, when two XMPP servers wish to establish a TLS-encrypted connection, from the security point of view the server that initiates the connection is a TLS client whereas the server that receives the connection is a TLS server (despite the fact that from an application point of view both of them are XMPP servers). My understanding of Kurt's argument is that we can't say much that's helpful about how a TLS server checks the identity of a TLS client because the problem is application-specific and the TLS server doesn't really have a "reference identity" (an idea of what identity the client will assert). At some level, the TLS server knows that it expects the TLS client to assert a kind of identity (domain name, email address, XMPP address, etc.) but not necessarily a particular instance of that kind ("example.com", "foo@example.com", or whatever). I need to think about this further. I'm sure that re-reading Kurt's messages will help... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrnZggACgkQNL8k5A2w/vzVlgCgjcykxNdhldEtUN2b+Nex2nmN uK8Anibo46ElJYq1NwYJsOFohTvb3nkK =BVDg -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Oct 27 15:18:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB7A3A6A42 for ; Tue, 27 Oct 2009 15:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 g6IgD-pmD03d for ; Tue, 27 Oct 2009 15:18:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 801C93A6A61 for ; Tue, 27 Oct 2009 15:18:21 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3BF504008F; Tue, 27 Oct 2009 16:18:36 -0600 (MDT) Message-ID: <4AE771BB.9000603@stpeter.im> Date: Tue, 27 Oct 2009 16:18:35 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: miika.komu@hiit.fi Subject: Re: Identity Checking in Application Protocols References: <4AE62AB7.8080607@stpeter.im> <4AE6C8C7.7030305@hiit.fi> In-Reply-To: <4AE6C8C7.7030305@hiit.fi> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:18:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/09 4:17 AM, Miika Komu wrote: > Peter Saint-Andre wrote: > > Hi Peter, > > could you add a section on RFC4843 based authentication? Some other > references: > > http://tools.ietf.org/html/rfc5338 > http://tools.ietf.org/html/draft-ietf-hip-native-api Thanks for the references, I will check those out. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrncbsACgkQNL8k5A2w/vyBgwCg+fkZgTaWI2e+yZbpiX28kZvD 58YAoJQ358JiCa8I2dquqkRXV1QKkfD9 =J2jN -----END PGP SIGNATURE----- From James.H.Manger@team.telstra.com Tue Oct 27 15:51:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B3528C0D6 for ; Tue, 27 Oct 2009 15:51:50 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...84FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET>\n \n X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 jse6VhyprokJ for ; Tue, 27 Oct 2009 15:51:49 -0700 (PDT) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 1ECC328C0D0 for ; Tue, 27 Oct 2009 15:51:48 -0700 (PDT) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 28 Oct 2009 09:52:02 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id BA1C6FF8B for ; Wed, 28 Oct 2009 09:52:01 +1100 (EST) Received: from WSMSG3754.srv.dir.telstra.com (wsmsg3754.in.telstra.com.au [172.49.40.198]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 565D741D62 for ; Wed, 28 Oct 2009 09:51:42 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 28 Oct 2009 09:51:58 +1100 From: "Manger, James H" To: "apps-discuss@ietf.org" Date: Wed, 28 Oct 2009 09:51:56 +1100 Subject: RE: host-meta: template syntax hassles Thread-Topic: host-meta: template syntax hassles Thread-Index: AcpWwpMrO2fBkK/zTVK4PvsTZrNbFQAA8nsQAAEiIMAADvFXsA== Message-ID: <255B9BB34FB7D647A506DC292726F6E112485B46BA@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112485B46BAWSMSG3153Vsrv_" MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:51:50 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112485B46BAWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIHNvbHV0aW9uIChmb3Igc2ltcGxlLCBidXQgY29ycmVjdCwgVVJJIHRlbXBsYXRlcyBmb3Ig Y29tbW9uIHNpdHVhdGlvbnMgaW4gaG9zdC1tZXRhKSBpcyB0byBkZWZpbmUgbW9yZSB2YXJpYWJs ZXMuDQoNCg0KDQpGb3IgaW5zdGFuY2UsIGluIGFkZGl0aW9uIHRvIOKAmHNjaGVtZeKAmSwg4oCY YXV0aG9yaXR54oCZLCDigJhwYXRo4oCZLCDigJhxdWVyeeKAmeKApiBvZmZlciB0aGUgZm9sbG93 aW5nIHZhcmlhYmxlczoNCg0K4oCYdG9EaXLigJkg4oCUIHRoZSBVUkkgdXAgdG8sIGJ1dCBleGNs dWRpbmcsIHRoZSBsYXN0IOKAmC/igJkgaW4gdGhlIHBhdGgNCg0K4oCYYWZ0ZXJEaXLigJkg4oCU IHRoZSBVUkkgZnJvbSB0aGUgbGFzdCBzZWdtZW50IG9mIHRoZSBwYXRoIHRvIHRoZSBlbmQsIGV4 Y2x1ZGluZyB0aGUgZnJhZ21lbnQNCg0K4oCYdG9FeHTigJkg4oCUIHRoZSBVUkkgdXAgdG8sIGJ1 dCBleGNsdWRpbmcsIHRoZSBsYXN0IOKAmC7igJkgaW4gdGhlIGxhc3Qgc2VnbWVudCBvZiB0aGUg cGF0aCAob3IgdG8gdGhlIGVuZCBvZiB0aGUgcGF0aCBpZiB0aGVyZSBpcyBubyBzdWNoIGRvdCkN Cg0KIOKAmHRvUGF0aOKAmSDigJQgdGhlIFVSSSB1cCB0byB0aGUgZW5kIG9mIHRoZSBwYXRoDQoN CuKAmGFmdGVyUGF0aOKAmSDigJQgdGhlIFVSSSBmcm9tIGFmdGVyIHRoZSBwYXRoIHRvIHRoZSBl bmQsIGV4Y2x1ZGluZyB0aGUgZnJhZ21lbnQNCg0K4oCYdG9RdWVyeVBsdXPigJkg4oCUIHRoZSBV UkkgZXhjbHVkaW5nIGFueSBmcmFnbWVudCwgZm9sbG93ZWQgYnkg4oCYJuKAmSBpZiB0aGVyZSBp cyBhIHF1ZXJ5IHN0cmluZyBvciDigJg/4oCZIG90aGVyd2lzZSAoaWUgcmVhZHkgZm9yIGEgbmV3 IHF1ZXJ5IHBhcmFtZXRlciB0byBiZSBhcHBlbmRlZCkNCg0K4oCYYmVmb3JlSG9zdOKAmSDigJQg dGhlIFVSSSB1cCB0bywgYnV0IGV4Y2x1ZGluZywgdGhlIGhvc3QNCg0K4oCYZnJvbUhvc3TigJkg 4oCUIHRoZSBVUkkgZnJvbSB0aGUgaG9zdCB0byB0aGUgZW5kLCBleGNsdWRpbmcgdGhlIGZyYWdt ZW50DQoNCg0KDQpUZW1wbGF0ZSBleGFtcGxlczoNCg0Keyt0b0V4dH0ueHJkeythZnRlclBhdGh9 IOKAlCByZXBsYWNlLCBzYXksIC5odG1sIGV4dGVuc2lvbiB3aXRoIC54cmQgdG8gZ2V0IG1ldGFk YXRhDQoNCnsrdG9RdWVyeVBsdXN9Xz1tZXRhIOKAlCBhZGQgYSBxdWVyeSBwYXJhbWV0ZXIgbmFt ZWQg4oCcX+KAnSB3aXRoIGEgdmFsdWUg4oCcbWV0YeKAnSB0byBnZXQgbWV0YWRhdGENCg0Keyt0 b0Rpcn0vLm1ldGEveythZnRlckRpcn0g4oCUIG1ldGFkYXRhIGlzIGluIGEgc3BlY2lhbCAubWV0 YS8gc3ViZGlyZWN0b3J5IG9mIGVhY2ggZGlyZWN0b3J5DQoNCnsrdG9QYXRofTttZXRheythZnRl clBhdGh9IOKAlCBhcHBlbmQg4oCcO21ldGHigJ0gdG8gdGhlIHBhdGggdG8gZ2V0IHRoZSBtZXRh ZGF0YQ0KDQp7K2JlZm9yZUhvc3R9bWV0YS57K2Zyb21Ib3N0fSDigJRtZXRhZGF0YSBpcyBob3N0 ZWQgb24gYSBzdWItZG9tYWluDQoNCg0KDQpUaGUgdG8vYWZ0ZXIgKGFuZCBiZWZvcmUvZnJvbSkg cGFpcnMgYmFzaWNhbGx5IG9mZmVyIGVhc3kgYWNjZXNzIHRvIGRpZmZlcmVudCBwb2ludHMgaW4g dGhlIFVSSSB0byBpbnNlcnQgYSBuZXcgZWxlbWVudC4gSSB0aGluayB0aGVzZSBleGFtcGxlcyBh cmUgZmFpcmx5IHNpbXBsZSB3YXlzIHRvIGltcGxlbWVudCBjb21tb24gVVJJIG1hbmlwdWxhdGlv bnMgc2FmZWx5Lg0KDQoNCg0KSmFtZXMgTWFuZ2VyDQpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0 cmEuY29tPG1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPg0KSWRlbnRpdHkg YW5kIHNlY3VyaXR5IHRlYW0g4oCUIENoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlIOKAlCBUZWxzdHJh DQoNCg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E112485B46BAWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0N CiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9z ZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFn ZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQVUiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T25lIHNvbHV0aW9uIChmb3Igc2ltcGxlLCBidXQgY29ycmVjdCwgVVJJIHRl bXBsYXRlcyBmb3IgY29tbW9uIHNpdHVhdGlvbnMgaW4gaG9zdC1tZXRhKSBpcyB0byBkZWZpbmUg bW9yZSB2YXJpYWJsZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBpbnN0YW5jZSwgaW4g YWRkaXRpb24gdG8g4oCYc2NoZW1l4oCZLCDigJhhdXRob3JpdHnigJksIOKAmHBhdGjigJksIOKA mHF1ZXJ54oCZ4oCmIG9mZmVyIHRoZSBmb2xsb3dpbmcgdmFyaWFibGVzOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCYdG9EaXLigJkg4oCUIHRoZSBVUkkgdXAgdG8sIGJ1 dCBleGNsdWRpbmcsIHRoZSBsYXN0IOKAmC/igJkgaW4gdGhlIHBhdGg8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAmGFmdGVyRGly4oCZIOKAlCB0aGUgVVJJIGZyb20gdGhl IGxhc3Qgc2VnbWVudCBvZiB0aGUgcGF0aCB0byB0aGUgZW5kLCBleGNsdWRpbmcgdGhlIGZyYWdt ZW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJh0b0V4dOKAmSDigJQg dGhlIFVSSSB1cCB0bywgYnV0IGV4Y2x1ZGluZywgdGhlIGxhc3Qg4oCYLuKAmSBpbiB0aGUgbGFz dCBzZWdtZW50IG9mIHRoZSBwYXRoIChvciB0byB0aGUgZW5kIG9mIHRoZSBwYXRoIGlmIHRoZXJl IGlzIG5vIHN1Y2ggZG90KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A74oCYdG9QYXRo4oCZIOKAlCB0aGUgVVJJIHVwIHRvIHRoZSBlbmQgb2YgdGhlIHBhdGg8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAmGFmdGVyUGF0aOKAmSDigJQgdGhl IFVSSSBmcm9tIGFmdGVyIHRoZSBwYXRoIHRvIHRoZSBlbmQsIGV4Y2x1ZGluZyB0aGUgZnJhZ21l bnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAmHRvUXVlcnlQbHVz4oCZ IOKAlCB0aGUgVVJJIGV4Y2x1ZGluZyBhbnkgZnJhZ21lbnQsIGZvbGxvd2VkIGJ5IOKAmCZhbXA7 4oCZIGlmIHRoZXJlIGlzIGEgcXVlcnkgc3RyaW5nIG9yIOKAmD/igJkgb3RoZXJ3aXNlIChpZSBy ZWFkeSBmb3IgYSBuZXcgcXVlcnkgcGFyYW1ldGVyIHRvIGJlIGFwcGVuZGVkKTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCYYmVmb3JlSG9zdOKAmSDigJQgdGhlIFVSSSB1 cCB0bywgYnV0IGV4Y2x1ZGluZywgdGhlIGhvc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPuKAmGZyb21Ib3N04oCZIOKAlCB0aGUgVVJJIGZyb20gdGhlIGhvc3QgdG8gdGhl IGVuZCwgZXhjbHVkaW5nIHRoZSBmcmFnbWVudDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UZW1w bGF0ZSBleGFtcGxlczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnsmIzQz O3RvRXh0fS54cmR7JiM0MzthZnRlclBhdGh9IOKAlCByZXBsYWNlLCBzYXksIC5odG1sIGV4dGVu c2lvbiB3aXRoIC54cmQgdG8gZ2V0IG1ldGFkYXRhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj57JiM0Mzt0b1F1ZXJ5UGx1c31fPW1ldGEg4oCUIGFkZCBhIHF1ZXJ5IHBhcmFt ZXRlciBuYW1lZCDigJxf4oCdIHdpdGggYSB2YWx1ZSDigJxtZXRh4oCdIHRvIGdldCBtZXRhZGF0 YTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+eyYjNDM7dG9EaXJ9Ly5tZXRh L3smIzQzO2FmdGVyRGlyfSDigJQgbWV0YWRhdGEgaXMgaW4gYSBzcGVjaWFsIC5tZXRhLyBzdWJk aXJlY3Rvcnkgb2YgZWFjaCBkaXJlY3Rvcnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnsmIzQzO3RvUGF0aH07bWV0YXsmIzQzO2FmdGVyUGF0aH0g4oCUIGFwcGVuZCDigJw7 bWV0YeKAnSB0byB0aGUgcGF0aCB0byBnZXQgdGhlIG1ldGFkYXRhPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj57JiM0MztiZWZvcmVIb3N0fW1ldGEueyYjNDM7ZnJvbUhvc3R9 IOKAlG1ldGFkYXRhIGlzIGhvc3RlZCBvbiBhIHN1Yi1kb21haW48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIHRvL2FmdGVyIChhbmQgYmVmb3JlL2Zyb20pIHBhaXJzIGJhc2ljYWxseSBvZmZl ciBlYXN5IGFjY2VzcyB0byBkaWZmZXJlbnQgcG9pbnRzIGluIHRoZSBVUkkgdG8gaW5zZXJ0IGEg bmV3IGVsZW1lbnQuIEkgdGhpbmsgdGhlc2UgZXhhbXBsZXMgYXJlIGZhaXJseSBzaW1wbGUgd2F5 cyB0byBpbXBsZW1lbnQgY29tbW9uIFVSSSBtYW5pcHVsYXRpb25zIHNhZmVseS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpj b2xvcjojMUY0OTdEIj5KYW1lcyBNYW5nZXI8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5Og0KJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5JZGVudGl0eSBh bmQgc2VjdXJpdHkgdGVhbTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDsNCmZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj7igJQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4gQ2hpZWYgVGVjaG5vbG9neSBPZmZpY2U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj7igJQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPiBUZWxzdHJhPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E112485B46BAWSMSG3153Vsrv_-- From alexey.melnikov@isode.com Wed Oct 28 06:42:30 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E253A69C6 for ; Wed, 28 Oct 2009 06:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 wlW8dlHCP0Dl for ; Wed, 28 Oct 2009 06:42:29 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5963D3A687C for ; Wed, 28 Oct 2009 06:42:29 -0700 (PDT) Received: from [172.16.2.174] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 28 Oct 2009 13:42:43 +0000 Message-ID: <4AE84A4A.7010401@isode.com> Date: Wed, 28 Oct 2009 13:42:34 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "apps-discuss@ietf.org" Subject: Call for discussion topics for Apps Area meeting in Hiroshima MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:42:30 -0000 Hi, This is a [late] call for discussion topics for Hiroshima. Please send your requests to Lisa and myself. Regards, Alexey From stpeter@stpeter.im Wed Oct 28 07:49:29 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CC83A684E for ; Wed, 28 Oct 2009 07:49:29 -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 4C+wBs181WLq for ; Wed, 28 Oct 2009 07:49:28 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8DD163A6802 for ; Wed, 28 Oct 2009 07:49:28 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7F59A4008F; Wed, 28 Oct 2009 08:49:43 -0600 (MDT) Message-ID: <4AE85A06.5020305@stpeter.im> Date: Wed, 28 Oct 2009 08:49:42 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Call for discussion topics for Apps Area meeting in Hiroshima References: <4AE84A4A.7010401@isode.com> In-Reply-To: <4AE84A4A.7010401@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:49:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/28/09 7:42 AM, Alexey Melnikov wrote: > This is a [late] call for discussion topics for Hiroshima. Please send > your requests to Lisa and myself. I'd like to discuss draft-saintandre-tls-server-id-check so that we can get closer to consensus about what exactly we want to cover in that I-D and whether we need additional I-Ds for related topics. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkroWgYACgkQNL8k5A2w/vx30QCggdutIEojCQslpUFAl7Zvl5i+ H8kAn1xRTQgIijvuX0H9AqCufKFhmgmi =m6Pq -----END PGP SIGNATURE----- From miika.komu@hiit.fi Tue Oct 27 03:17:30 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990773A6A0C for ; Tue, 27 Oct 2009 03:17:30 -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 p5QFQkFi2Pbg for ; Tue, 27 Oct 2009 03:17:29 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 8A8E83A67F0 for ; Tue, 27 Oct 2009 03:17:29 -0700 (PDT) Received: from [192.168.1.2] (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id DA52C25ED06; Tue, 27 Oct 2009 12:17:42 +0200 (EET) Message-ID: <4AE6C8C7.7030305@hiit.fi> Date: Tue, 27 Oct 2009 12:17:43 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: Identity Checking in Application Protocols References: <4AE62AB7.8080607@stpeter.im> In-Reply-To: <4AE62AB7.8080607@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 28 Oct 2009 08:12:09 -0700 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 10:17:30 -0000 Peter Saint-Andre wrote: Hi Peter, could you add a section on RFC4843 based authentication? Some other references: http://tools.ietf.org/html/rfc5338 http://tools.ietf.org/html/draft-ietf-hip-native-api Thanks! P.S. I also find somebody who can also contribute text if this is needed. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I had hoped to update draft-saintandre-tls-server-id-check before the > submission cutoff today, but it's not going to happen because there's > quite a bit of feedback to sift through (ideally I would have followed > the list discussions more closely the first time around). However, I > shall work to update it in the next few days, at which time I will also > rename it to remove the strings "tls" and "server" since the scope of > the spec has widened to include non-TLS interactions as well as client > identity checking. My apologies for the delay. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrmKrcACgkQNL8k5A2w/vzfTwCfaOtoWUS6yE8r1kaAoo70Ae3f > Ng4AnjBF+Y/k7EKxE47IhXwIcBIPdu7h > =uuU1 > -----END PGP SIGNATURE----- > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From dhc@dcrocker.net Wed Oct 28 09:12:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F803A694F for ; Wed, 28 Oct 2009 09:12:17 -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 6ThqfAa86uAT for ; Wed, 28 Oct 2009 09:12:16 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7148]) by core3.amsl.com (Postfix) with ESMTP id A42203A6847 for ; Wed, 28 Oct 2009 09:12:15 -0700 (PDT) Received: from [192.168.171.65] (66-208-229-11-ubr01a-muncie01-in.hfc.comcastbusiness.net [66.208.229.11]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n9SGCKjn003568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 09:12:27 -0700 Message-ID: <4AE86D62.3070907@dcrocker.net> Date: Wed, 28 Oct 2009 12:12:18 -0400 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: Call for discussion topics for Apps Area meeting in Hiroshima References: <4AE84A4A.7010401@isode.com> <4AE85A06.5020305@stpeter.im> In-Reply-To: <4AE85A06.5020305@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9955/Wed Oct 28 08:18:03 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 28 Oct 2009 09:12:27 -0700 (PDT) Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:12:17 -0000 Peter Saint-Andre wrote: > I'd like to discuss draft-saintandre-tls-server-id-check so that we can > get closer to consensus about what exactly we want to cover in that I-D > and whether we need additional I-Ds for related topics. If I read the draft correctly: "If a client wishes to connect to a server securely, it needs to check the identity of the server so that it can determine if the server is what it claims to be" seems to be the salient statement about the problem to be solved. Can you elaborate a bit? I'm only looking for a somewhat more extensive spec of your topic goal, rather than trying resolving it, here. Tnx. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Wed Oct 28 10:46:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3345A3A6927 for ; Wed, 28 Oct 2009 10:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm1x9TA-0Tlv for ; Wed, 28 Oct 2009 10:46:36 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 204EB3A685D for ; Wed, 28 Oct 2009 10:46:36 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AF1C44033D; Wed, 28 Oct 2009 11:46:50 -0600 (MDT) Message-ID: <4AE88389.5050604@stpeter.im> Date: Wed, 28 Oct 2009 11:46:49 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: identity checking redux (was: Re: Call for discussion topics for Apps Area meeting in Hiroshima) References: <4AE84A4A.7010401@isode.com> <4AE85A06.5020305@stpeter.im> <4AE86D62.3070907@dcrocker.net> In-Reply-To: <4AE86D62.3070907@dcrocker.net> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:46:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/28/09 10:12 AM, Dave CROCKER wrote: > > > Peter Saint-Andre wrote: >> I'd like to discuss draft-saintandre-tls-server-id-check so that we can >> get closer to consensus about what exactly we want to cover in that I-D >> and whether we need additional I-Ds for related topics. > > > If I read the draft correctly: > > "If a client wishes to connect to a server securely, it needs to check > the identity of the server so that it can determine if the server is > what it claims to be" > > seems to be the salient statement about the problem to be solved. > > Can you elaborate a bit? I'm only looking for a somewhat more extensive > spec of your topic goal, rather than trying resolving it, here. We seem to have discussed several possibilities: 1. Define how an application client checks its expectations ("reference identity" = domain name or IP address) against what the application server presents in a CA-issued certificate. We have a great deal of experience with this model in HTTP, IMAP, LDAP, XMPP, and so on. It seems valuable to abstract from those instances to form a more general conception of how an application client should check the identity of an application server. 2. Other application protocols (SSH, Netconf, SysLog, etc.) use keys instead of X.509 certs. Here the application client needs to bootstrap some notion of trust (which might be "leap of faith" in the presented key) and then in the future simply verify that the same association continues to hold (i.e., there is no concept of a "reference identity" here). It appears that some folks would like to specify this in the same document, whereas others want to specify it separately. 3. Other application protocols (DTLS, XMPP, etc.) enable one client to communicate with another client in a way that enables end-to-end security. Here the credentials might be keys or certs, but I think more typically keys, in which case the fingerprint verification model might apply (except that the identity being checked is not an application server but a peer client). There are, no doubt, questionable assumptions lurking in the summary I've provided, which is why I think it makes sense to discuss this in Hiroshima. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrog4kACgkQNL8k5A2w/vwu4wCg4z903KLFIIWKOcF+0EGFAzV/ Ue8AoLUUv/wmZsQ//WjaV7+urao8To5v =o1dz -----END PGP SIGNATURE----- From cfinss@dial.pipex.com Wed Oct 28 11:25:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDFB3A69A7 for ; Wed, 28 Oct 2009 11:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.208, 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 Up4mOx-9IxRJ for ; Wed, 28 Oct 2009 11:25:18 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 61E223A6843 for ; Wed, 28 Oct 2009 11:25:18 -0700 (PDT) X-Trace: 297515268/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.87/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.87 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAB4p6Eo+vGRX/2dsb2JhbACDIo18yVAKgjAOgXcEi2g X-IronPort-AV: E=Sophos;i="4.44,641,1249254000"; d="scan'208";a="297515268" X-IP-Direction: IN Received: from 1cust87.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.87]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Oct 2009 18:25:30 +0000 Message-ID: <02d801ca57f3$44aae3c0$0601a8c0@allison> From: "tom.petch" To: , "Peter Saint-Andre" References: <4AE84A4A.7010401@isode.com> <4AE85A06.5020305@stpeter.im> <4AE86D62.3070907@dcrocker.net> Subject: Re: Call for discussion topics for Apps Area meeting in Hiroshima Date: Wed, 28 Oct 2009 18:18:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 18:25:19 -0000 ----- Original Message ----- From: "Dave CROCKER" Sent: Wednesday, October 28, 2009 5:12 PM > > Peter Saint-Andre wrote: > > I'd like to discuss draft-saintandre-tls-server-id-check so that we can > > get closer to consensus about what exactly we want to cover in that I-D > > and whether we need additional I-Ds for related topics. > > If I read the draft correctly: > > "If a client wishes to connect to a server securely, it needs to check > the identity of the server so that it can determine if the server is > what it claims to be" > > seems to be the salient statement about the problem to be solved. > > Can you elaborate a bit? I'm only looking for a somewhat more extensive spec of > your topic goal, rather than trying resolving it, here. Dave We did discuss scope back in June without anything very concrete emerging, apart from limiting ourselves to X.509, but there was a faint consensus for a cookbook that other RFC would then refer to, selecting a profile, when wanting to verify that a certificate received over a security protocol matched something that the box had 'configured' into it. Tom Petch > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net From cfinss@dial.pipex.com Wed Oct 28 11:25:20 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB12728C1E9 for ; Wed, 28 Oct 2009 11:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.492 X-Spam-Level: X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[AWL=1.107, 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 eQSIfbxHBvif for ; Wed, 28 Oct 2009 11:25:19 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 9A5323A6843 for ; Wed, 28 Oct 2009 11:25:19 -0700 (PDT) X-Trace: 297515293/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.87/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.87 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAB4p6Eo+vGRX/2dsb2JhbACDIo18yVAKgjCCBQQ X-IronPort-AV: E=Sophos;i="4.44,641,1249254000"; d="scan'208";a="297515293" X-IP-Direction: IN Received: from 1cust87.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.87]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Oct 2009 18:25:32 +0000 Message-ID: <02d901ca57f3$46023660$0601a8c0@allison> From: "tom.petch" To: "Peter Saint-Andre" , "Alexey Melnikov" References: <4AE62AB7.8080607@stpeter.im> <4AE6CB4E.9030701@isode.com> <4AE76608.6030607@stpeter.im> Subject: Re: Identity Checking in Application Protocols Date: Wed, 28 Oct 2009 18:20:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 18:25:21 -0000 ----- Original Message ----- From: "Peter Saint-Andre" Sent: Tuesday, October 27, 2009 10:28 PM > On 10/27/09 4:28 AM, Alexey Melnikov wrote: > > Hi Peter, > > > > Peter Saint-Andre wrote: > >> I had hoped to update draft-saintandre-tls-server-id-check before the > >> submission cutoff today, but it's not going to happen because there's > >> quite a bit of feedback to sift through (ideally I would have followed > >> the list discussions more closely the first time around). However, I > >> shall work to update it in the next few days, at which time I will also > >> rename it to remove the strings "tls" and "server" since the scope of > >> the spec has widened to include non-TLS interactions as well as client > >> identity checking. My apologies for the delay. > >> > > Without my AD hat: I don't think the document should cover client > > identity checking. I found Kurt's arguments to be convincing. > > I think that the distinction between application roles and security > roles causes some confusion here. This I-D talks about security roles, > not application roles. Thus, for example, when two XMPP servers wish to > establish a TLS-encrypted connection, from the security point of view > the server that initiates the connection is a TLS client whereas the > server that receives the connection is a TLS server (despite the fact > that from an application point of view both of them are XMPP servers). > > My understanding of Kurt's argument is that we can't say much that's > helpful about how a TLS server checks the identity of a TLS client > because the problem is application-specific and the TLS server doesn't > really have a "reference identity" (an idea of what identity the client > will assert). At some level, the TLS server knows that it expects the > TLS client to assert a kind of identity (domain name, email address, > XMPP address, etc.) but not necessarily a particular instance of that > kind ("example.com", "foo@example.com", or whatever). > > I need to think about this further. I'm sure that re-reading Kurt's > messages will help... My take is that the only difference is one of number. A client is 'configured' with a single reference identity, eg by the user keying it into a window, which is then used in a comparison with what is returned in an X.509 certificate. A server may support more than one client and so may be configured with more than one reference identity and use any or all of them in a comparison with what is received in an X.509 certificate eg with SIP, Netconf, syslog, .... Of course, a server may not care to check, may not be configured with anything, in which case the procedures in this I-D are irrelevant Tom Petch > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > From stpeter@stpeter.im Wed Oct 28 13:47:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B033A686C for ; Wed, 28 Oct 2009 13:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=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 8VxM7OzJ6sSa for ; Wed, 28 Oct 2009 13:47:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 276083A6A6D for ; Wed, 28 Oct 2009 13:47:21 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3B2364008F; Wed, 28 Oct 2009 14:47:36 -0600 (MDT) Message-ID: <4AE8ADE6.7030803@stpeter.im> Date: Wed, 28 Oct 2009 14:47:34 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "tom.petch" Subject: Re: Identity Checking in Application Protocols References: <4AE62AB7.8080607@stpeter.im> <4AE6CB4E.9030701@isode.com> <4AE76608.6030607@stpeter.im> <02d901ca57f3$46023660$0601a8c0@allison> In-Reply-To: <02d901ca57f3$46023660$0601a8c0@allison> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:47:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/28/09 11:20 AM, tom.petch wrote: > ----- Original Message ----- > From: "Peter Saint-Andre" > Sent: Tuesday, October 27, 2009 10:28 PM > >> On 10/27/09 4:28 AM, Alexey Melnikov wrote: >>> Hi Peter, >>> >>> Peter Saint-Andre wrote: >>>> I had hoped to update draft-saintandre-tls-server-id-check before the >>>> submission cutoff today, but it's not going to happen because there's >>>> quite a bit of feedback to sift through (ideally I would have followed >>>> the list discussions more closely the first time around). However, I >>>> shall work to update it in the next few days, at which time I will also >>>> rename it to remove the strings "tls" and "server" since the scope of >>>> the spec has widened to include non-TLS interactions as well as client >>>> identity checking. My apologies for the delay. >>>> >>> Without my AD hat: I don't think the document should cover client >>> identity checking. I found Kurt's arguments to be convincing. >> I think that the distinction between application roles and security >> roles causes some confusion here. This I-D talks about security roles, >> not application roles. Thus, for example, when two XMPP servers wish to >> establish a TLS-encrypted connection, from the security point of view >> the server that initiates the connection is a TLS client whereas the >> server that receives the connection is a TLS server (despite the fact >> that from an application point of view both of them are XMPP servers). >> >> My understanding of Kurt's argument is that we can't say much that's >> helpful about how a TLS server checks the identity of a TLS client >> because the problem is application-specific and the TLS server doesn't >> really have a "reference identity" (an idea of what identity the client >> will assert). At some level, the TLS server knows that it expects the >> TLS client to assert a kind of identity (domain name, email address, >> XMPP address, etc.) but not necessarily a particular instance of that >> kind ("example.com", "foo@example.com", or whatever). >> >> I need to think about this further. I'm sure that re-reading Kurt's >> messages will help... > > My take is that the only difference is one of number. > > A client is 'configured' with a single reference identity, eg by the user > keying it into a window, which is then used in a comparison with what > is returned in an X.509 certificate. > > A server may support more than one client and so may be configured > with more than one reference identity and use any or all of them in a > comparison with what is received in an X.509 certificate eg with SIP, > Netconf, syslog, That's an interesting perspective. In my experience (which is mainly limited to XMPP networks), the largest deployment of certificate-based authentication does not expect that the server will find an XMPP address in the client certificate. Instead, it finds some other information in the cert and uses that information to dynamically construct an XMPP address for the client on the server. However, I freely admit that this usage is non-standard and not something we'd want to document. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkroreYACgkQNL8k5A2w/vzLxQCgyq8pMpcdQwQeMgTCuYCX1UJ8 YgYAoPza3tbBwEibE/NR+O6Rv6wX2j03 =eH/U -----END PGP SIGNATURE----- From vkg@alcatel-lucent.com Wed Oct 28 13:53:21 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4C33A6A6D for ; Wed, 28 Oct 2009 13:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwvtgC+CQXJk for ; Wed, 28 Oct 2009 13:53:20 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 7530F3A6A75 for ; Wed, 28 Oct 2009 13:53:20 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n9SKrZsJ009536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 15:53:35 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n9SKrZ2a000320; Wed, 28 Oct 2009 15:53:35 -0500 (CDT) Message-ID: <4AE8AF4F.30102@alcatel-lucent.com> Date: Wed, 28 Oct 2009 15:53:35 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: Identity Checking in Application Protocols References: <4AE62AB7.8080607@stpeter.im> <4AE6CB4E.9030701@isode.com> <4AE76608.6030607@stpeter.im> <02d901ca57f3$46023660$0601a8c0@allison> <4AE8ADE6.7030803@stpeter.im> In-Reply-To: <4AE8ADE6.7030803@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:53:21 -0000 Peter Saint-Andre wrote: >> A server may support more than one client and so may be configured >> with more than one reference identity and use any or all of them in a >> comparison with what is received in an X.509 certificate eg with SIP, >> Netconf, syslog, > > That's an interesting perspective. An approach that we took in SIP for the server to authenticate clients is documented in Section 7.4 of ietf-sip-domain-certs (http://tools.ietf.org/html/draft-ietf-sip-domain-certs-04#section-7.4). Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From mnot@mnot.net Wed Oct 28 17:57:32 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1923A6A74; Wed, 28 Oct 2009 17:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[AWL=-2.413, 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 OIhml7XcxT0O; Wed, 28 Oct 2009 17:57:31 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 257A13A6A47; Wed, 28 Oct 2009 17:57:31 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.5.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8BA2D509D9; Wed, 28 Oct 2009 20:57:39 -0400 (EDT) Subject: Re: draft-nottingham-site-meta: registration too slow, opaque Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: <1256229505.4607.1513.camel@pav.lan> Date: Thu, 29 Oct 2009 11:57:35 +1100 Content-Transfer-Encoding: 7bit Message-Id: <4090B691-B4A2-47B0-AB27-70E10FD4C5C7@mnot.net> References: <1256229505.4607.1513.camel@pav.lan> To: Dan Connolly X-Mailer: Apple Mail (2.1076) Cc: www-archive@w3.org, apps-discuss@ietf.org, ietf@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 00:57:32 -0000 I think the key question here is whether the contents of a registered well-known URL need to have an interoperable specification available. If so, the current registration policy (Specification Required, which implies Designated Expert) is appropriate. If we're willing to allow anything to be registered (e.g., FooCorp wants to place a completely opaque file on Web servers, and reserve URI space for it; likewise for a developer who wants to try something out, only to decide next week that it's not a good idea, or that they got it slightly wrong), First Come First Served may be more appropriate. Getting an entry in this registry effectively dictates the format of a URL on every Web server on the planet. Do we really want to accommodate developers with such short attention spans? Regardless of that, I agree that the registration process explanation in the draft needs to be tightened up, and that more visible feedback would be helpful. I think this could be addressed by creating a dedicated mailing list for review (assuming we keep the current policy) and having the initial submission and discussion take place on it; it would be the job of the expert reviewer to forward approved registrations to IANA for publication. Cheers, On 23/10/2009, at 3:38 AM, Dan Connolly wrote: > Sorry I didn't review and comment when the draft first > became available... > > Regarding: > > "Before a period of 30 days has passed, the Designated > Expert will either approve or deny the registration request, > communicating this decision both to the review list and to IANA." > -- http://www.ietf.org/id/draft-nottingham-site-meta-03.txt > > My experience is that this sort of latency results in developers > working around the IANA and IETF. Please set up a form so > that with latency of a few seconds, somebody can have their > token provisionally registered. (Perhaps an email callback > will have to precede the form.) > > By way of example, consider the W3C XPointer Scheme Name Registry form > http://www.w3.org/2005/04/xpointer-schemes/0register > (though it's perhaps not completely shiny either... > I see one example of "Status: Being reviewed > Last updated on 2006-10-11" on > http://www.w3.org/2005/04/xpointer-schemes/ ) > > I have tried to keep W3C out of the registry business all together, > but IANA is widely reputed to be slow and opaque, and my own > personal experience bears that out to some extent, so I can't > completely stop people who are willing to set up registries in W3C > (not to mention elsewhere...). If IANA has in fact gotten a lot better > lately, perhaps we just need to address the perception part. > > As it is, section 5 doesn't even give an exact email > address of where to send registration requests. That sends > people on a scavenger hunt right from step 1. > > Perhaps a/the "datatracker" addresses my concern about latency > and transparency... if mail to iana@iana.org results in an > automated "ticket" response, with a pointer to a status page that > always > has a clear bound on the latency for the next step, that > would suffice (if it's actually documented in section 5). > > Hmm... it's entitled "IETF I-D Tracker", which suggests > its scope doesn't include IANA registration requests. > https://datatracker.ietf.org/idtracker/ > > > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E > -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Oct 28 18:08:28 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34CBE3A69D9; Wed, 28 Oct 2009 18:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-2.350, 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 ZZXSVTw3HagM; Wed, 28 Oct 2009 18:08:27 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 46F5E3A69C8; Wed, 28 Oct 2009 18:08:27 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.5.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0BD8B509DC; Wed, 28 Oct 2009 21:08:39 -0400 (EDT) Subject: Re: draft-nottingham-site-meta: registration too slow, opaque Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: <1256229505.4607.1513.camel@pav.lan> Date: Thu, 29 Oct 2009 12:08:35 +1100 Content-Transfer-Encoding: 7bit Message-Id: <50438369-DECF-4169-878A-3B77B8B29236@mnot.net> References: <1256229505.4607.1513.camel@pav.lan> To: Dan Connolly X-Mailer: Apple Mail (2.1076) Cc: www-archive@w3.org, apps-discuss@ietf.org, ietf@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 01:08:28 -0000 ... proposed changes at: http://www.mnot.net/drafts/draft-nottingham-site-meta-04.txt diff: http://www.mnot.net/drafts/draft-nottingham-site-meta-04-from-3.diff.html It may be that we can reuse uri-review@, but for the time being I've specified a new list. Cheers, On 23/10/2009, at 3:38 AM, Dan Connolly wrote: > Sorry I didn't review and comment when the draft first > became available... > > Regarding: > > "Before a period of 30 days has passed, the Designated > Expert will either approve or deny the registration request, > communicating this decision both to the review list and to IANA." > -- http://www.ietf.org/id/draft-nottingham-site-meta-03.txt > > My experience is that this sort of latency results in developers > working around the IANA and IETF. Please set up a form so > that with latency of a few seconds, somebody can have their > token provisionally registered. (Perhaps an email callback > will have to precede the form.) > > By way of example, consider the W3C XPointer Scheme Name Registry form > http://www.w3.org/2005/04/xpointer-schemes/0register > (though it's perhaps not completely shiny either... > I see one example of "Status: Being reviewed > Last updated on 2006-10-11" on > http://www.w3.org/2005/04/xpointer-schemes/ ) > > I have tried to keep W3C out of the registry business all together, > but IANA is widely reputed to be slow and opaque, and my own > personal experience bears that out to some extent, so I can't > completely stop people who are willing to set up registries in W3C > (not to mention elsewhere...). If IANA has in fact gotten a lot better > lately, perhaps we just need to address the perception part. > > As it is, section 5 doesn't even give an exact email > address of where to send registration requests. That sends > people on a scavenger hunt right from step 1. > > Perhaps a/the "datatracker" addresses my concern about latency > and transparency... if mail to iana@iana.org results in an > automated "ticket" response, with a pointer to a status page that > always > has a clear bound on the latency for the next step, that > would suffice (if it's actually documented in section 5). > > Hmm... it's entitled "IETF I-D Tracker", which suggests > its scope doesn't include IANA registration requests. > https://datatracker.ietf.org/idtracker/ > > > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E > -- Mark Nottingham http://www.mnot.net/ From A.Hoenes@TR-Sys.de Thu Oct 29 03:14:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E34E3A69A3 for ; Thu, 29 Oct 2009 03:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.91 X-Spam-Level: * X-Spam-Status: No, score=1.91 tagged_above=-999 required=5 tests=[AWL=0.659, 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 gPe+yWCB7CBl for ; Thu, 29 Oct 2009 03:14:24 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 6424F3A6993 for ; Thu, 29 Oct 2009 03:14:23 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA029961229; Thu, 29 Oct 2009 11:13:49 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA05925; Thu, 29 Oct 2009 11:13:48 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910291013.LAA05925@TR-Sys.de> Subject: draft-nottingham-site-meta-03 --> -04 To: draft-nottingham-site-meta@cabernet.tools.IETF.ORG Date: Thu, 29 Oct 2009 11:13:47 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 10:14:25 -0000 Mark Nottingham wrote: > ... proposed changes at: > http://www.mnot.net/drafts/draft-nottingham-site-meta-04.txt > diff: > http://www.mnot.net/drafts/draft-nottingham-site-meta-04-from-3.diff.html > > It may be that we can reuse uri-review@, but for the time being > I've specified a new list. The draft-nottingham-site-meta-04 predraft says: |Appendix C. Document History | | o -04 | * Restrict to HTTP(S) by default. | * Shorten review SLA to 14 days. | * Allow for multiple designated experts. | * Identify mailing list for request submission and discussion. ad 1) Please make the proper restriction to HTTP(S) URIs evident from the document title as well, e.g.: Defining Well-Known URIs --- Defining Well-Known HTTP URIs "by default" is inappropriate wording; unless you specify it in the memo, other URI scheme definitions won't be changed. No 'user' of the proposed registry can simply start (ab-)using it for, say, 'dns' or 'rtsp' URIs ! Equally, the title of the IANA registry you want to establish needs to be adapted, for the sake of precision and to avoid confusion. ad 2) This shortening is a burden for both reviewers and designated experts. Experience has shown that it is in general unlikely to get feedback in such short timespans because the community is busy in a very bursty manner, and because it is impossible to guarantee such short response time from a single volunteering individual expert all over the year. Having to establish an Expert group for backup does not seem worth the effort and management overhead for such a registry. I therefore heartly recommend that no review deadlines shorter than a month should be specified. ad 3) As I said above, the overhead of multiple experts seems to be inappropriate for such tiny registry. ad 4) Please use {TBD}@ietf.org (or similar) and include an RFC-Editor note requesting pre-publication fixup -- that will be decided by the IESG in cooperation with IANA (cf. RFC 5226) and need fixup shortly before RFC publication. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From cfinss@dial.pipex.com Thu Oct 29 05:20:58 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C752F3A6870 for ; Thu, 29 Oct 2009 05:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=1.022, 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 SQ7KSs1SP-sW for ; Thu, 29 Oct 2009 05:20:57 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 8FBCD3A6774 for ; Thu, 29 Oct 2009 05:20:57 -0700 (PDT) X-Trace: 297829867/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.78/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.78 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAEABcl6Uo+vGRO/2dsb2JhbACDIicaAo09yz0Kgi8OgXYE X-IronPort-AV: E=Sophos;i="4.44,645,1249254000"; d="scan'208";a="297829867" X-IP-Direction: IN Received: from 1cust78.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.78]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Oct 2009 12:17:40 +0000 Message-ID: <000401ca5889$0b527e80$0601a8c0@allison> From: "tom.petch" To: "Peter Saint-Andre" , References: <4AE84A4A.7010401@isode.com> <4AE85A06.5020305@stpeter.im><4AE86D62.3070907@dcrocker.net> <4AE88389.5050604@stpeter.im> Subject: Re: identity checking redux (was: Re: Call for discussion topics forApps Area meeting in Hiroshima) Date: Thu, 29 Oct 2009 11:22:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 12:20:58 -0000 ----- Original Message ----- From: "Peter Saint-Andre" Sent: Wednesday, October 28, 2009 6:46 PM > On 10/28/09 10:12 AM, Dave CROCKER wrote: > > > Peter Saint-Andre wrote: > >> I'd like to discuss draft-saintandre-tls-server-id-check so that we can > >> get closer to consensus about what exactly we want to cover in that I-D > >> and whether we need additional I-Ds for related topics. > > > > > > If I read the draft correctly: > > > > "If a client wishes to connect to a server securely, it needs to check > > the identity of the server so that it can determine if the server is > > what it claims to be" > > > > seems to be the salient statement about the problem to be solved. > > > > Can you elaborate a bit? I'm only looking for a somewhat more extensive > > spec of your topic goal, rather than trying resolving it, here. > > We seem to have discussed several possibilities: > > 1. Define how an application client checks its expectations ("reference > identity" = domain name or IP address) against what the application > server presents in a CA-issued certificate. We have a great deal of > experience with this model in HTTP, IMAP, LDAP, XMPP, and so on. It > seems valuable to abstract from those instances to form a more general > conception of how an application client should check the identity of an > application server. > > 2. Other application protocols (SSH, Netconf, SysLog, etc.) use keys > instead of X.509 certs. Here the application client needs to bootstrap Peter The comments I have made relate solely to use of X.509 certificates with NETCONF, syslog, isms etc, nothing to do with public keys ie the validation of X.509 certificate against reference identity with these protocols. I would widen the reference identity beyond DNS and IP, to eg URL and MAC. The other wrinkle is the use of a fingerprint in order to avoid the need to use CA/CRL/OCSP etc but again, this is for a pukka X.509 certificate which would then be subject to checking against a reference identity as above. Tom Petch > some notion of trust (which might be "leap of faith" in the presented > key) and then in the future simply verify that the same association > continues to hold (i.e., there is no concept of a "reference identity" > here). It appears that some folks would like to specify this in the same > document, whereas others want to specify it separately. > > 3. Other application protocols (DTLS, XMPP, etc.) enable one client to > communicate with another client in a way that enables end-to-end > security. Here the credentials might be keys or certs, but I think more > typically keys, in which case the fingerprint verification model might > apply (except that the identity being checked is not an application > server but a peer client). > > There are, no doubt, questionable assumptions lurking in the summary > I've provided, which is why I think it makes sense to discuss this in > Hiroshima. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ From Kurt.Zeilenga@Isode.com Thu Oct 29 07:51:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E043A698F for ; Thu, 29 Oct 2009 07:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_35=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 4BJ7QSNm2N9k for ; Thu, 29 Oct 2009 07:51:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6E0DA3A6955 for ; Thu, 29 Oct 2009 07:51:13 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 29 Oct 2009 14:51:28 +0000 X-SMTP-Protocol-Errors: NORDNS Subject: Re: Identity Checking in Application Protocols From: Kurt Zeilenga X-Priority: 3 In-Reply-To: <02d901ca57f3$46023660$0601a8c0@allison> Date: Thu, 29 Oct 2009 07:51:00 -0700 Message-Id: <11E83FA6-12C3-4B1C-8BC1-92B42F8C66C8@Isode.com> References: <4AE62AB7.8080607@stpeter.im> <4AE6CB4E.9030701@isode.com> <4AE76608.6030607@stpeter.im> <02d901ca57f3$46023660$0601a8c0@allison> To: "tom.petch" X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 14:51:15 -0000 On Oct 28, 2009, at 10:20 AM, tom.petch wrote: > ----- Original Message ----- > From: "Peter Saint-Andre" > Sent: Tuesday, October 27, 2009 10:28 PM > >> On 10/27/09 4:28 AM, Alexey Melnikov wrote: >>> Hi Peter, >>> >>> Peter Saint-Andre wrote: >>>> I had hoped to update draft-saintandre-tls-server-id-check before >>>> the >>>> submission cutoff today, but it's not going to happen because >>>> there's >>>> quite a bit of feedback to sift through (ideally I would have >>>> followed >>>> the list discussions more closely the first time around). >>>> However, I >>>> shall work to update it in the next few days, at which time I >>>> will also >>>> rename it to remove the strings "tls" and "server" since the >>>> scope of >>>> the spec has widened to include non-TLS interactions as well as >>>> client >>>> identity checking. My apologies for the delay. >>>> >>> Without my AD hat: I don't think the document should cover client >>> identity checking. I found Kurt's arguments to be convincing. >> >> I think that the distinction between application roles and security >> roles causes some confusion here. This I-D talks about security >> roles, >> not application roles. Thus, for example, when two XMPP servers >> wish to >> establish a TLS-encrypted connection, from the security point of view >> the server that initiates the connection is a TLS client whereas the >> server that receives the connection is a TLS server (despite the fact >> that from an application point of view both of them are XMPP >> servers). >> >> My understanding of Kurt's argument is that we can't say much that's >> helpful about how a TLS server checks the identity of a TLS client >> because the problem is application-specific and the TLS server >> doesn't >> really have a "reference identity" (an idea of what identity the >> client >> will assert). At some level, the TLS server knows that it expects the >> TLS client to assert a kind of identity (domain name, email address, >> XMPP address, etc.) but not necessarily a particular instance of that >> kind ("example.com", "foo@example.com", or whatever). >> >> I need to think about this further. I'm sure that re-reading Kurt's >> messages will help... > > My take is that the only difference is one of number. > > A client is 'configured' with a single reference identity, eg by the > user > keying it into a window, which is then used in a comparison with what > is returned in an X.509 certificate. > > A server may support more than one client and so may be configured > with more than one reference identity and use any or all of them in a > comparison with what is received in an X.509 certificate eg with SIP, > Netconf, syslog, > .... > > Of course, a server may not care to check, may not be configured with > anything, in which case the procedures in this I-D are irrelevant My objection is not against an "application server" acting as a TLS client verifying the identity of the TLS server it connects to. My objection is against this I-D discussing in detail how an "application server" acting as a TLS server might verify the identity of the TLS client connecting to it. The difference between the two (generally speaking) is that in the former, the verifying entity (the TLS client) has an assumption of trust in the reference identity as it provided by the user (via some dialog or configuration or whatever) as opposed to be programmatically determined by the verifying entity (such as simply using the TLS client's IP address as the reference identity, or using some IP address to reference identity mapping, etc.). The security considerations for these two scenarios is quite different, and I simply rather avoid discussing the latter in this document. I note that are other use scenarios, such as when the reference identity is provided to the client via a referral mechanism. That is, an application clients to server A, A provides a referral to B, client connects to B and now wants to verify B's identity. I think this scenario likely should be discussed to some degree in the I-D as it is a relatively common application client scenario. -- Kurt > > Tom Petch >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Thu Oct 29 08:39:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C6C3A6885 for ; Thu, 29 Oct 2009 08:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_35=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 I1yTQN-00Dqa for ; Thu, 29 Oct 2009 08:39:44 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7FCD33A67BD for ; Thu, 29 Oct 2009 08:39:44 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BECF64008F; Thu, 29 Oct 2009 09:39:59 -0600 (MDT) Message-ID: <4AE9B74E.9030908@stpeter.im> Date: Thu, 29 Oct 2009 09:39:58 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Kurt Zeilenga Subject: Re: Identity Checking in Application Protocols References: <4AE62AB7.8080607@stpeter.im> <4AE6CB4E.9030701@isode.com> <4AE76608.6030607@stpeter.im> <02d901ca57f3$46023660$0601a8c0@allison> <11E83FA6-12C3-4B1C-8BC1-92B42F8C66C8@Isode.com> In-Reply-To: <11E83FA6-12C3-4B1C-8BC1-92B42F8C66C8@Isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 15:39:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/09 8:51 AM, Kurt Zeilenga wrote: > > On Oct 28, 2009, at 10:20 AM, tom.petch wrote: > >> ----- Original Message ----- >> From: "Peter Saint-Andre" >> Sent: Tuesday, October 27, 2009 10:28 PM >> >>> On 10/27/09 4:28 AM, Alexey Melnikov wrote: >>>> Hi Peter, >>>> >>>> Peter Saint-Andre wrote: >>>>> I had hoped to update draft-saintandre-tls-server-id-check before the >>>>> submission cutoff today, but it's not going to happen because there's >>>>> quite a bit of feedback to sift through (ideally I would have followed >>>>> the list discussions more closely the first time around). However, I >>>>> shall work to update it in the next few days, at which time I will >>>>> also >>>>> rename it to remove the strings "tls" and "server" since the scope of >>>>> the spec has widened to include non-TLS interactions as well as client >>>>> identity checking. My apologies for the delay. >>>>> >>>> Without my AD hat: I don't think the document should cover client >>>> identity checking. I found Kurt's arguments to be convincing. >>> >>> I think that the distinction between application roles and security >>> roles causes some confusion here. This I-D talks about security roles, >>> not application roles. Thus, for example, when two XMPP servers wish to >>> establish a TLS-encrypted connection, from the security point of view >>> the server that initiates the connection is a TLS client whereas the >>> server that receives the connection is a TLS server (despite the fact >>> that from an application point of view both of them are XMPP servers). >>> >>> My understanding of Kurt's argument is that we can't say much that's >>> helpful about how a TLS server checks the identity of a TLS client >>> because the problem is application-specific and the TLS server doesn't >>> really have a "reference identity" (an idea of what identity the client >>> will assert). At some level, the TLS server knows that it expects the >>> TLS client to assert a kind of identity (domain name, email address, >>> XMPP address, etc.) but not necessarily a particular instance of that >>> kind ("example.com", "foo@example.com", or whatever). >>> >>> I need to think about this further. I'm sure that re-reading Kurt's >>> messages will help... >> >> My take is that the only difference is one of number. >> >> A client is 'configured' with a single reference identity, eg by the user >> keying it into a window, which is then used in a comparison with what >> is returned in an X.509 certificate. >> >> A server may support more than one client and so may be configured >> with more than one reference identity and use any or all of them in a >> comparison with what is received in an X.509 certificate eg with SIP, >> Netconf, syslog, >> .... >> >> Of course, a server may not care to check, may not be configured with >> anything, in which case the procedures in this I-D are irrelevant > > My objection is not against an "application server" acting as a TLS > client verifying the identity of the TLS server it connects to. > My objection is against this I-D discussing in detail how an > "application server" acting as a TLS server might verify the identity of > the TLS client connecting to it. > > The difference between the two (generally speaking) is that in the > former, the verifying entity (the TLS client) has an assumption of trust > in the reference identity as it provided by the user (via some dialog or > configuration or whatever) as opposed to be programmatically determined > by the verifying entity (such as simply using the TLS client's IP > address as the reference identity, or using some IP address to reference > identity mapping, etc.). The security considerations for these two > scenarios is quite different, and I simply rather avoid discussing the > latter in this document. Agreed, I would rather keep this I-D focused on the application client's task of verifying the identity of an application server. But nothing is stopping us from writing another I-D that focuses on other problems. > I note that are other use scenarios, such as when the reference identity > is provided to the client via a referral mechanism. That is, an > application clients to server A, A provides a referral to B, client > connects to B and now wants to verify B's identity. I think this > scenario likely should be discussed to some degree in the I-D as it is a > relatively common application client scenario. Yes, I think it would be good to discuss that scenario, although I confess that I don't have a clear handle on what text would be appropriate. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrpt04ACgkQNL8k5A2w/vxRnQCffTdMhPDMKDszdzwQQe4+S0lY 9bUAoO4US35ITGOEPPdo582FqV+jZHIp =TWvB -----END PGP SIGNATURE----- From Kurt.Zeilenga@Isode.com Thu Oct 29 09:23:06 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0913A68C3 for ; Thu, 29 Oct 2009 09:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_35=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 ARakIxNCY3JO for ; Thu, 29 Oct 2009 09:23:05 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C2A613A67F1 for ; Thu, 29 Oct 2009 09:23:04 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 29 Oct 2009 16:23:18 +0000 X-SMTP-Protocol-Errors: NORDNS Subject: Re: Identity Checking in Application Protocols From: Kurt Zeilenga In-Reply-To: <4AE9B74E.9030908@stpeter.im> Date: Thu, 29 Oct 2009 09:22:50 -0700 Message-Id: References: <4AE62AB7.8080607@stpeter.im> <4AE6CB4E.9030701@isode.com> <4AE76608.6030607@stpeter.im> <02d901ca57f3$46023660$0601a8c0@allison> <11E83FA6-12C3-4B1C-8BC1-92B42F8C66C8@Isode.com> <4AE9B74E.9030908@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 16:23:06 -0000 On Oct 29, 2009, at 8:39 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/29/09 8:51 AM, Kurt Zeilenga wrote: >> >> On Oct 28, 2009, at 10:20 AM, tom.petch wrote: >> >>> ----- Original Message ----- >>> From: "Peter Saint-Andre" >>> Sent: Tuesday, October 27, 2009 10:28 PM >>> >>>> On 10/27/09 4:28 AM, Alexey Melnikov wrote: >>>>> Hi Peter, >>>>> >>>>> Peter Saint-Andre wrote: >>>>>> I had hoped to update draft-saintandre-tls-server-id-check >>>>>> before the >>>>>> submission cutoff today, but it's not going to happen because >>>>>> there's >>>>>> quite a bit of feedback to sift through (ideally I would have >>>>>> followed >>>>>> the list discussions more closely the first time around). >>>>>> However, I >>>>>> shall work to update it in the next few days, at which time I >>>>>> will >>>>>> also >>>>>> rename it to remove the strings "tls" and "server" since the >>>>>> scope of >>>>>> the spec has widened to include non-TLS interactions as well as >>>>>> client >>>>>> identity checking. My apologies for the delay. >>>>>> >>>>> Without my AD hat: I don't think the document should cover client >>>>> identity checking. I found Kurt's arguments to be convincing. >>>> >>>> I think that the distinction between application roles and security >>>> roles causes some confusion here. This I-D talks about security >>>> roles, >>>> not application roles. Thus, for example, when two XMPP servers >>>> wish to >>>> establish a TLS-encrypted connection, from the security point of >>>> view >>>> the server that initiates the connection is a TLS client whereas >>>> the >>>> server that receives the connection is a TLS server (despite the >>>> fact >>>> that from an application point of view both of them are XMPP >>>> servers). >>>> >>>> My understanding of Kurt's argument is that we can't say much >>>> that's >>>> helpful about how a TLS server checks the identity of a TLS client >>>> because the problem is application-specific and the TLS server >>>> doesn't >>>> really have a "reference identity" (an idea of what identity the >>>> client >>>> will assert). At some level, the TLS server knows that it expects >>>> the >>>> TLS client to assert a kind of identity (domain name, email >>>> address, >>>> XMPP address, etc.) but not necessarily a particular instance of >>>> that >>>> kind ("example.com", "foo@example.com", or whatever). >>>> >>>> I need to think about this further. I'm sure that re-reading Kurt's >>>> messages will help... >>> >>> My take is that the only difference is one of number. >>> >>> A client is 'configured' with a single reference identity, eg by >>> the user >>> keying it into a window, which is then used in a comparison with >>> what >>> is returned in an X.509 certificate. >>> >>> A server may support more than one client and so may be configured >>> with more than one reference identity and use any or all of them >>> in a >>> comparison with what is received in an X.509 certificate eg with >>> SIP, >>> Netconf, syslog, >>> .... >>> >>> Of course, a server may not care to check, may not be configured >>> with >>> anything, in which case the procedures in this I-D are irrelevant >> >> My objection is not against an "application server" acting as a TLS >> client verifying the identity of the TLS server it connects to. >> My objection is against this I-D discussing in detail how an >> "application server" acting as a TLS server might verify the >> identity of >> the TLS client connecting to it. >> >> The difference between the two (generally speaking) is that in the >> former, the verifying entity (the TLS client) has an assumption of >> trust >> in the reference identity as it provided by the user (via some >> dialog or >> configuration or whatever) as opposed to be programmatically >> determined >> by the verifying entity (such as simply using the TLS client's IP >> address as the reference identity, or using some IP address to >> reference >> identity mapping, etc.). The security considerations for these two >> scenarios is quite different, and I simply rather avoid discussing >> the >> latter in this document. > > Agreed, I would rather keep this I-D focused on the application > client's > task of verifying the identity of an application server. But nothing > is > stopping us from writing another I-D that focuses on other problems. > >> I note that are other use scenarios, such as when the reference >> identity >> is provided to the client via a referral mechanism. That is, an >> application clients to server A, A provides a referral to B, client >> connects to B and now wants to verify B's identity. I think this >> scenario likely should be discussed to some degree in the I-D as it >> is a >> relatively common application client scenario. > > Yes, I think it would be good to discuss that scenario, although I > confess that I don't have a clear handle on what text would be > appropriate. I think our description of the 'reference identity' is a bit too vague. reference identity: The client's conception of the server's identity before it attempts to establish a secure connection to the server, i.e. the identity that the client expects the server to present and to which the client makes reference when attempting to verify the server's identity. It is either the address to which the client connected or the explicit value of the TLS "server_name" extension as specified in [TLS]. The reference identity might be based on a DNS lookup, user configuration, or some other mechanism. One could easily read "server's identity before it attempts to establish a secure connection to the server" as any identity the client has for the server before it does the connect(2) call (or equivalent). That is, one can view DNS name to IP address mapping as occurring before attempting to connect to the server. The reference identity is either the identity of the server that the user provided to the client, or its an identity of the server somehow other obtained (such as via a referral) from another entity (such as a referral service). In the former case, the reference identity is to be implicitly trusted. In the latter case, there should be no implicit trust. The document needs to discuss this distinction. My recommendation is to leave the particulars of the latter case to application protocol specifications that make use of the algorithm (as it's the same basic issue with client identity checking, is the reference identity trustworthy or not). I don't have text to offer at this point... -- Kurt > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrpt04ACgkQNL8k5A2w/vxRnQCffTdMhPDMKDszdzwQQe4+S0lY > 9bUAoO4US35ITGOEPPdo582FqV+jZHIp > =TWvB > -----END PGP SIGNATURE----- > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Thu Oct 29 14:43:07 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56183A6A81 for ; Thu, 29 Oct 2009 14:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_35=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 keVyXAn4S0xh for ; Thu, 29 Oct 2009 14:43:06 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4DA203A6A21 for ; Thu, 29 Oct 2009 14:43:06 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E3E94008F; Thu, 29 Oct 2009 15:43:22 -0600 (MDT) Message-ID: <4AEA0C78.70106@stpeter.im> Date: Thu, 29 Oct 2009 15:43:20 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Kurt Zeilenga Subject: Re: Identity Checking in Application Protocols References: <4AE62AB7.8080607@stpeter.im> <4AE6CB4E.9030701@isode.com> <4AE76608.6030607@stpeter.im> <02d901ca57f3$46023660$0601a8c0@allison> <11E83FA6-12C3-4B1C-8BC1-92B42F8C66C8@Isode.com> <4AE9B74E.9030908@stpeter.im> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:43:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/09 10:22 AM, Kurt Zeilenga wrote: > > On Oct 29, 2009, at 8:39 AM, Peter Saint-Andre wrote: > > On 10/29/09 8:51 AM, Kurt Zeilenga wrote: >>>> >>>> On Oct 28, 2009, at 10:20 AM, tom.petch wrote: >>>> >>>>> ----- Original Message ----- >>>>> From: "Peter Saint-Andre" >>>>> Sent: Tuesday, October 27, 2009 10:28 PM >>>>> >>>>>> On 10/27/09 4:28 AM, Alexey Melnikov wrote: >>>>>>> Hi Peter, >>>>>>> >>>>>>> Peter Saint-Andre wrote: >>>>>>>> I had hoped to update draft-saintandre-tls-server-id-check before >>>>>>>> the >>>>>>>> submission cutoff today, but it's not going to happen because >>>>>>>> there's >>>>>>>> quite a bit of feedback to sift through (ideally I would have >>>>>>>> followed >>>>>>>> the list discussions more closely the first time around). >>>>>>>> However, I >>>>>>>> shall work to update it in the next few days, at which time I will >>>>>>>> also >>>>>>>> rename it to remove the strings "tls" and "server" since the >>>>>>>> scope of >>>>>>>> the spec has widened to include non-TLS interactions as well as >>>>>>>> client >>>>>>>> identity checking. My apologies for the delay. >>>>>>>> >>>>>>> Without my AD hat: I don't think the document should cover client >>>>>>> identity checking. I found Kurt's arguments to be convincing. >>>>>> >>>>>> I think that the distinction between application roles and security >>>>>> roles causes some confusion here. This I-D talks about security roles, >>>>>> not application roles. Thus, for example, when two XMPP servers >>>>>> wish to >>>>>> establish a TLS-encrypted connection, from the security point of view >>>>>> the server that initiates the connection is a TLS client whereas the >>>>>> server that receives the connection is a TLS server (despite the fact >>>>>> that from an application point of view both of them are XMPP servers). >>>>>> >>>>>> My understanding of Kurt's argument is that we can't say much that's >>>>>> helpful about how a TLS server checks the identity of a TLS client >>>>>> because the problem is application-specific and the TLS server doesn't >>>>>> really have a "reference identity" (an idea of what identity the >>>>>> client >>>>>> will assert). At some level, the TLS server knows that it expects the >>>>>> TLS client to assert a kind of identity (domain name, email address, >>>>>> XMPP address, etc.) but not necessarily a particular instance of that >>>>>> kind ("example.com", "foo@example.com", or whatever). >>>>>> >>>>>> I need to think about this further. I'm sure that re-reading Kurt's >>>>>> messages will help... >>>>> >>>>> My take is that the only difference is one of number. >>>>> >>>>> A client is 'configured' with a single reference identity, eg by the >>>>> user >>>>> keying it into a window, which is then used in a comparison with what >>>>> is returned in an X.509 certificate. >>>>> >>>>> A server may support more than one client and so may be configured >>>>> with more than one reference identity and use any or all of them in a >>>>> comparison with what is received in an X.509 certificate eg with SIP, >>>>> Netconf, syslog, >>>>> .... >>>>> >>>>> Of course, a server may not care to check, may not be configured with >>>>> anything, in which case the procedures in this I-D are irrelevant >>>> >>>> My objection is not against an "application server" acting as a TLS >>>> client verifying the identity of the TLS server it connects to. >>>> My objection is against this I-D discussing in detail how an >>>> "application server" acting as a TLS server might verify the identity of >>>> the TLS client connecting to it. >>>> >>>> The difference between the two (generally speaking) is that in the >>>> former, the verifying entity (the TLS client) has an assumption of trust >>>> in the reference identity as it provided by the user (via some dialog or >>>> configuration or whatever) as opposed to be programmatically determined >>>> by the verifying entity (such as simply using the TLS client's IP >>>> address as the reference identity, or using some IP address to reference >>>> identity mapping, etc.). The security considerations for these two >>>> scenarios is quite different, and I simply rather avoid discussing the >>>> latter in this document. > > Agreed, I would rather keep this I-D focused on the application client's > task of verifying the identity of an application server. But nothing is > stopping us from writing another I-D that focuses on other problems. > >>>> I note that are other use scenarios, such as when the reference identity >>>> is provided to the client via a referral mechanism. That is, an >>>> application clients to server A, A provides a referral to B, client >>>> connects to B and now wants to verify B's identity. I think this >>>> scenario likely should be discussed to some degree in the I-D as it is a >>>> relatively common application client scenario. > > Yes, I think it would be good to discuss that scenario, although I > confess that I don't have a clear handle on what text would be > appropriate. > > >> I think our description of the 'reference identity' is a bit too vague. I agree. >> reference identity: The client's conception of the server's identity >> before it attempts to establish a secure connection to the server, >> i.e. the identity that the client expects the server to present >> and to which the client makes reference when attempting to verify >> the server's identity. It is either the address to which the >> client connected or the explicit value of the TLS "server_name" >> extension as specified in [TLS]. The reference identity might be >> based on a DNS lookup, user configuration, or some other >> mechanism. > >> One could easily read "server's identity before it attempts to establish >> a secure connection to the server" as any identity the client has for >> the server before it does the connect(2) call (or equivalent). That is, >> one can view DNS name to IP address mapping as occurring before >> attempting to connect to the server. IMHO that's not what we meant, so we need to make it clearer. >> The reference identity is either the identity of the server that the >> user provided to the client, or its an identity of the server somehow >> other obtained (such as via a referral) from another entity (such as a >> referral service). Do you have examples of referral services and the concept of referral in general? >> In the former case, the reference identity is to be implicitly trusted. >> In the latter case, there should be no implicit trust. I'd be curious to hear your description of "implicit trust". Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrqDHgACgkQNL8k5A2w/vz8zACg3mp0V5Yiwau20EdOrUP+qAqr vHUAnRTLlaWglwflbzvHlg82Z6e1KUzv =PJbF -----END PGP SIGNATURE----- From mark@coactus.com Thu Oct 29 17:46:07 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D2D3A6904 for ; Thu, 29 Oct 2009 17:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pSW7KSyAPjTL for ; Thu, 29 Oct 2009 17:46:06 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id DA9503A67FC for ; Thu, 29 Oct 2009 17:46:06 -0700 (PDT) Received: by pwi4 with SMTP id 4so389548pwi.29 for ; Thu, 29 Oct 2009 17:46:23 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.142.3.3 with SMTP id 3mr81255wfc.141.1256863583640; Thu, 29 Oct 2009 17:46:23 -0700 (PDT) Date: Thu, 29 Oct 2009 21:46:23 -0300 X-Google-Sender-Auth: e29db3f3c8cbb1c4 Message-ID: Subject: Review of metalink I-D From: Mark Baker To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 00:46:07 -0000 This is my review of draft-bryan-metalink-21. - sec 3, last paragraph, it is mentioned that some kinds of white space can produce an "invalid" document, yet no where is it defined what that means - sec 4.1.2.1. not sure why "name" is a MUST. I'm sure metalink agents can pick a reasonable one, or ask the user, but if it was required then they might not include this logic. - sec 4.2.3. If metalink:dynamic is intended to be a cue to agents to redownload the file periodically, you probably also want to give them an indication of how often to do so. HTTP caching could be used to do that. - sec 4.2.6, the Openoffice example confused me briefly. You need to make sure it's seen to be an example, and also that "OpenOffice.org" isn't the only possible value. Perhaps change to; The "metalink:identity" element is a Text construct that conveys a human-readable name for a file. For example, the identity of OpenOffice.org 3.0 might be "OpenOffice.org", "Openoffice", or "OpenOffice 3.0". - sec 4.2.10.2. do we really need to use a special "torrent" type when "application/x-bittorrent" could be used? I'd prefer to stick just to media type syntax and get rid of the reserved syntax. You should also call them "media types" instead of (or as well as if you prefer) MIME types, and include a reference to BCP 13. - in sec 6.3, it's not within the authority of a protocol specification to tell agents that they "MUST NOT stop processing" or "MUST NOT change their behaviour". They might have their own perfectly good reasons for, say, halting if some XHTML with Javascript were included. I agree with what you're trying to accomplish, but that should be specified by saying, for example, that extensions can be ignored. Overall, a decent spec. It's nice to see extensibility given considerable attention for a change. Mark. From Kurt.Zeilenga@Isode.com Thu Oct 29 19:13:49 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3813A67FA for ; Thu, 29 Oct 2009 19:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 mHSqrtPrpLF6 for ; Thu, 29 Oct 2009 19:13:48 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EB2C63A6359 for ; Thu, 29 Oct 2009 19:13:47 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 30 Oct 2009 02:14:03 +0000 X-SMTP-Protocol-Errors: NORDNS Subject: Re: Identity Checking in Application Protocols From: Kurt Zeilenga In-Reply-To: <4AEA0C78.70106@stpeter.im> Date: Thu, 29 Oct 2009 19:13:31 -0700 Message-Id: References: <4AE62AB7.8080607@stpeter.im> <4AE6CB4E.9030701@isode.com> <4AE76608.6030607@stpeter.im> <02d901ca57f3$46023660$0601a8c0@allison> <11E83FA6-12C3-4B1C-8BC1-92B42F8C66C8@Isode.com> <4AE9B74E.9030908@stpeter.im> <4AEA0C78.70106@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 02:13:49 -0000 On Oct 29, 2009, at 2:43 PM, Peter Saint-Andre wrote: > Do you have examples of referral services and the concept of > referral in > general? In directory services accessible by LDAP, an LDAP server can refer the LDAP client to another LDAP server. In web services accessible by HTTP, an HTTP server can redirect the HTTP client to another HTTP server. A URN resolver service is effectively a referral service. > >>> In the former case, the reference identity is to be implicitly >>> trusted. >>> In the latter case, there should be no implicit trust. > > I'd be curious to hear your description of "implicit trust". To me, as used in this thread at least, "implicit trust" implies the information authenticity is unquestioned. As a client is acting upon the behalf of a user, information provided by the user is implicitly trusted. That is, if a user tells a client to return the resource located by some identifier, that identifier is not to be questioned. However, in accessing the resource that identifier identifies, some resolver, redirection, referral, or like service is involved, the authenticity of the service's output should be questioned. Let me give you an example. A user asks their RFC3088-supporting LDAP client to access the object identified by the DN . The client maps this DN to the domain example.org (using the RFC3088 algorithm) and finds DNS SRV records for this domain refer to server example.net. The client then looks up the IP address for example.net, and connects to the appropriate service at that IP address to access the named object. I consider the reference identity in this case is and hence it is implicitly trusted. The domain name example.org is directly derived from this reference identity via the RFC3088 algorithm and, hence, can also be implicitly trusted. But the RFC3088 resolver output, example.net, and the domain name to IP address resolver output, the IP address, should not be implicitly trusted and should be used in verification that the server is the server the user asked (via the DN) to connect to. It would be reasonable for an LDAP client to verify the server certificate via and DN-valued subject information (the particulars of which are reasonably beyond the scope of this I-D) and/or verify the server certificate using example.org and domain- valued subject information. -- Kurt From duerst@it.aoyama.ac.jp Thu Oct 29 19:25:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374F23A682D for ; Thu, 29 Oct 2009 19:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.495 X-Spam-Level: X-Spam-Status: No, score=0.495 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibUIiwUr3XW1 for ; Thu, 29 Oct 2009 19:25:13 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 6E4953A6359 for ; Thu, 29 Oct 2009 19:25:13 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id n9U2PJeO024786 for ; Fri, 30 Oct 2009 11:25:19 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5ab2_779d9488_c4fb_11de_a764_001d096c566a; Fri, 30 Oct 2009 11:25:19 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57796) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 30 Oct 2009 11:21:49 +0900 Message-ID: <4AEA4E7A.50908@it.aoyama.ac.jp> Date: Fri, 30 Oct 2009 11:24:58 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Subject: Re: draft-nottingham-site-meta-03 --> -04 References: <200910291013.LAA05925@TR-Sys.de> In-Reply-To: <200910291013.LAA05925@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org, draft-nottingham-site-meta@cabernet.tools.IETF.ORG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 02:25:15 -0000 On 2009/10/29 19:13, Alfred � wrote: > Mark Nottingham wrote: > The draft-nottingham-site-meta-04 predraft says: > > |Appendix C. Document History > | > | o -04 > | * Restrict to HTTP(S) by default. > | * Shorten review SLA to 14 days. > | * Allow for multiple designated experts. > | * Identify mailing list for request submission and discussion. > ad 2) This shortening is a burden for both reviewers and designated > experts. Experience has shown that it is in general unlikely > to get feedback in such short timespans because the community > is busy in a very bursty manner, and because it is impossible > to guarantee such short response time from a single > volunteering individual expert all over the year. > Having to establish an Expert group for backup does not seem > worth the effort and management overhead for such a registry. > > I therefore heartly recommend that no review deadlines shorter > than a month should be specified. I disagree. While it's not always possible to get some replies in two weeks, it's important to set expectations. The longer the review period, the higher the chance that people put away the review for "later", i.e. never. Also, most other registries I know have two weeks, and I don't see any special reason for this registry being much longer. > ad 3) As I said above, the overhead of multiple experts seems to be > inappropriate for such tiny registry. It's always better to have multiple experts in case somebody is on vacation,... Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From mnot@mnot.net Thu Oct 29 20:24:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F178C3A699C for ; Thu, 29 Oct 2009 20:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[AWL=-2.439, 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 cR95KUTHAy7h for ; Thu, 29 Oct 2009 20:24:22 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 2BB5B3A679C for ; Thu, 29 Oct 2009 20:24:22 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.5.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3A261509DD; Thu, 29 Oct 2009 23:24:29 -0400 (EDT) Subject: Re: draft-nottingham-site-meta-03 --> -04 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: <200910291013.LAA05925@TR-Sys.de> Date: Fri, 30 Oct 2009 14:24:20 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AEBB414-5E5E-4CCE-8417-454ABFFD1EA7@mnot.net> References: <200910291013.LAA05925@TR-Sys.de> To: =?iso-8859-1?Q?Alfred_H=CEnes?= X-Mailer: Apple Mail (2.1076) Cc: apps-discuss@ietf.org, draft-nottingham-site-meta@cabernet.tools.IETF.ORG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 03:24:23 -0000 On 29/10/2009, at 9:13 PM, Alfred H=CEnes wrote: > > ad 1) Please make the proper restriction to HTTP(S) URIs evident > from the document title as well, e.g.: > > Defining Well-Known URIs > --- > Defining Well-Known HTTP URIs > > "by default" is inappropriate wording; unless you specify it > in the memo, other URI scheme definitions won't be changed. > No 'user' of the proposed registry can simply start (ab-)using > it for, say, 'dns' or 'rtsp' URIs ! > > Equally, the title of the IANA registry you want to establish > needs to be adapted, for the sake of precision and to avoid > confusion. This was a conscious decision; as the draft explicitly notes, other =20 URI schemes can opt into this convention, so the title would be =20 misleading as soon as one did this. > ad 2) This shortening is a burden for both reviewers and designated > experts. Experience has shown that it is in general unlikely > to get feedback in such short timespans because the community > is busy in a very bursty manner, and because it is impossible > to guarantee such short response time from a single > volunteering individual expert all over the year. > Having to establish an Expert group for backup does not seem > worth the effort and management overhead for such a registry. > > I therefore heartly recommend that no review deadlines shorter > than a month should be specified. As discussed, I and others disagree; the registry needs to be =20 receptive, and two weeks is a reasonable expectation to set. > ad 3) As I said above, the overhead of multiple experts seems to be > inappropriate for such tiny registry. If the registry is tiny and the work involved in approving a =20 registration is slight, what is the overhead? > ad 4) Please use {TBD}@ietf.org (or similar) and > include an RFC-Editor note requesting pre-publication fixup > -- that will be decided by the IESG in cooperation with IANA > (cf. RFC 5226) and need fixup shortly before RFC publication. Will do. Thanks, -- Mark Nottingham http://www.mnot.net/ From cfinss@dial.pipex.com Fri Oct 30 04:23:41 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC753A6A7E for ; Fri, 30 Oct 2009 04:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, J_CHICKENPOX_35=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 iqj9mlaWE-h4 for ; Fri, 30 Oct 2009 04:23:40 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id EECF93A6889 for ; Fri, 30 Oct 2009 04:23:39 -0700 (PDT) X-Trace: 209420255/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.81/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.81 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAOtp6ko+vGlR/2dsb2JhbACDIkOBDYw1v0yREgqBKIEHDoEjUwSBYood X-IronPort-AV: E=Sophos;i="4.44,653,1249254000"; d="scan'208";a="209420255" X-IP-Direction: IN Received: from 1cust81.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.81]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Oct 2009 11:23:51 +0000 Message-ID: <002601ca594a$b0137e80$0601a8c0@allison> From: "tom.petch" To: "Peter Saint-Andre" References: <4AE62AB7.8080607@stpeter.im> <4AE6CB4E.9030701@isode.com> <4AE76608.6030607@stpeter.im> <02d901ca57f3$46023660$0601a8c0@allison> <11E83FA6-12C3-4B1C-8BC1-92B42F8C66C8@Isode.com> <4AE9B74E.9030908@stpeter.im> Subject: Re: Identity Checking in Application Protocols Date: Fri, 30 Oct 2009 11:19:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 11:23:41 -0000 ---- Original Message ----- From: "Peter Saint-Andre" To: "Kurt Zeilenga" Cc: "tom.petch" ; "Alexey Melnikov" ; Sent: Thursday, October 29, 2009 4:39 PM Subject: Re: Identity Checking in Application Protocols > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/29/09 8:51 AM, Kurt Zeilenga wrote: > > > > On Oct 28, 2009, at 10:20 AM, tom.petch wrote: > > > >> ----- Original Message ----- > >> From: "Peter Saint-Andre" > >> Sent: Tuesday, October 27, 2009 10:28 PM > >> > >>> On 10/27/09 4:28 AM, Alexey Melnikov wrote: > >>>> Hi Peter, > >>>> > >>>> Peter Saint-Andre wrote: > >>>>> I had hoped to update draft-saintandre-tls-server-id-check before the > >>>>> submission cutoff today, but it's not going to happen because there's > >>>>> quite a bit of feedback to sift through (ideally I would have followed > >>>>> the list discussions more closely the first time around). However, I > >>>>> shall work to update it in the next few days, at which time I will > >>>>> also > >>>>> rename it to remove the strings "tls" and "server" since the scope of > >>>>> the spec has widened to include non-TLS interactions as well as client > >>>>> identity checking. My apologies for the delay. > >>>>> > >>>> Without my AD hat: I don't think the document should cover client > >>>> identity checking. I found Kurt's arguments to be convincing. > >>> > >>> I think that the distinction between application roles and security > >>> roles causes some confusion here. This I-D talks about security roles, > >>> not application roles. Thus, for example, when two XMPP servers wish to > >>> establish a TLS-encrypted connection, from the security point of view > >>> the server that initiates the connection is a TLS client whereas the > >>> server that receives the connection is a TLS server (despite the fact > >>> that from an application point of view both of them are XMPP servers). > >>> > >>> My understanding of Kurt's argument is that we can't say much that's > >>> helpful about how a TLS server checks the identity of a TLS client > >>> because the problem is application-specific and the TLS server doesn't > >>> really have a "reference identity" (an idea of what identity the client > >>> will assert). At some level, the TLS server knows that it expects the > >>> TLS client to assert a kind of identity (domain name, email address, > >>> XMPP address, etc.) but not necessarily a particular instance of that > >>> kind ("example.com", "foo@example.com", or whatever). > >>> > >>> I need to think about this further. I'm sure that re-reading Kurt's > >>> messages will help... > >> > >> My take is that the only difference is one of number. > >> > >> A client is 'configured' with a single reference identity, eg by the user > >> keying it into a window, which is then used in a comparison with what > >> is returned in an X.509 certificate. > >> > >> A server may support more than one client and so may be configured > >> with more than one reference identity and use any or all of them in a > >> comparison with what is received in an X.509 certificate eg with SIP, > >> Netconf, syslog, > >> .... > >> > >> Of course, a server may not care to check, may not be configured with > >> anything, in which case the procedures in this I-D are irrelevant > > > > My objection is not against an "application server" acting as a TLS > > client verifying the identity of the TLS server it connects to. > > My objection is against this I-D discussing in detail how an > > "application server" acting as a TLS server might verify the identity of > > the TLS client connecting to it. > > > > The difference between the two (generally speaking) is that in the > > former, the verifying entity (the TLS client) has an assumption of trust > > in the reference identity as it provided by the user (via some dialog or > > configuration or whatever) as opposed to be programmatically determined > > by the verifying entity (such as simply using the TLS client's IP > > address as the reference identity, or using some IP address to reference > > identity mapping, etc.). The security considerations for these two > > scenarios is quite different, and I simply rather avoid discussing the > > latter in this document. > > Agreed, I would rather keep this I-D focused on the application client's > task of verifying the identity of an application server. But nothing is > stopping us from writing another I-D that focuses on other problems. Peter I don't think we can say anything about client or server. We are dealing with TLS or a similar protocol presenting an X.509 certificate for authentication, and the client for the security protocol may be the server for the application or not as the case may be so while I do not want us to restrict ourselves to TLS, I also think it wrong to refer to application. If you do need to differentiate the two ends of the connection (I dont':-) then I suggest transport client and transport server, although even that is not quite right as the TCP client could be the TLS server, ie they are eight choices in prospect. Tom Petch > > I note that are other use scenarios, such as when the reference identity > > is provided to the client via a referral mechanism. That is, an > > application clients to server A, A provides a referral to B, client > > connects to B and now wants to verify B's identity. I think this > > scenario likely should be discussed to some degree in the I-D as it is a > > relatively common application client scenario. > > Yes, I think it would be good to discuss that scenario, although I > confess that I don't have a clear handle on what text would be appropriate. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > From anthonybryan@gmail.com Fri Oct 30 09:55:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A463A68E6 for ; Fri, 30 Oct 2009 09:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.122 X-Spam-Level: X-Spam-Status: No, score=-5.122 tagged_above=-999 required=5 tests=[AWL=-2.523, 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 3xyodk5w3Paw for ; Fri, 30 Oct 2009 09:55:56 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id 98CE63A67EC for ; Fri, 30 Oct 2009 09:55:56 -0700 (PDT) Received: by iwn40 with SMTP id 40so2520553iwn.32 for ; Fri, 30 Oct 2009 09:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qwWedgNLv5o0K3azkhjOZDFwDcW6JE2fNXeoWs6S3yE=; b=C4H3LMo8g8YEEQGEd60efgsbSBW5HXM2yD4GsF/6h+13UorEdefmpaAIUIzxGCVJ8u IK+m8VEqHpQxhOnjQm36qynsHxzedE3x3EG4mPktsJmf73XaHftFCfpQU1Vq+wE8nZhv nXMw1CeQyKVWCu3k0fF0OPq2ytShImZT8byIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gTdJ5GlReY3v8gLh7XJGi5N8NgLi/7F+XF3zPDY74uRlKvxm+EmfNrdrf3bSFzZb5W /AIxPUI8l5NZkQqa/mU3FWh07qOytyoIE3UmIBh+zdFITRBbr9pHqcgJQijl/0aCId+e Vqkox1L+hItoartnyFUtZ5YfT4l18s+fiGKKs= MIME-Version: 1.0 Received: by 10.231.125.13 with SMTP id w13mr4390007ibr.32.1256921769961; Fri, 30 Oct 2009 09:56:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Oct 2009 12:56:09 -0400 Message-ID: Subject: Re: Review of metalink I-D From: Anthony Bryan To: Mark Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Peter_P=F6ml?= , "Neil M." , apps-discuss@ietf.org, Tatsuhiro Tsujikawa X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:55:58 -0000 Mark, thanks so much for your time and comments! On Thu, Oct 29, 2009 at 8:46 PM, Mark Baker wrote: > This is my review of draft-bryan-metalink-21. > > - sec 3, last paragraph, it is mentioned that some kinds of white > space can produce an "invalid" document, yet no where is it defined > what that means This text was borrowed from RFC 4287 yet I don't see more text to borrow to define invalid. :) How about adding this to sec 2, "Metalink Documents". "Metalink Documents that do not follow this specification are invalid, and partially or wholly unusable to Metalink Processors." > - sec 4.1.2.1. =A0not sure why "name" is a MUST. =A0I'm sure metalink > agents can pick a reasonable one, or ask the user, but if it was > required then they might not include this logic. This ends up being the being the filename that the downloaded file is written to most of the time. Agents are free to pick one, or ask the user. (Some use "filename(2).ext" if "filename.ext" is already taken, etc). The agent could use the filename at the end of a URI, but the filename from each URI can be different, the contents just have to match. We are also trying to define the document format in this draft, with as little client behavior as possible. So this seems like the simplest thing to require. > - sec 4.2.3. =A0If metalink:dynamic is intended to be a cue to agents to > redownload the file periodically, you probably also want to give them > an indication of how often to do so. =A0HTTP caching could be used to do > that. Yes, that is planned. We are trying to define the document format in this draft, with as little client behavior as possible. > - sec 4.2.6, the Openoffice example confused me briefly. =A0You need to > make sure it's seen to be an example, and also that "OpenOffice.org" > isn't the only possible value. =A0Perhaps change to; > > =A0 The "metalink:identity" element is a Text construct that conveys a > =A0 human-readable name for a file. =A0For example, the identity of OpenO= ffice.org > =A0 3.0 might be "OpenOffice.org", "Openoffice", or "OpenOffice 3.0". Let's change this because it's confusing. I believe "OpenOffice.org" is specifically named that because "OpenOffice" is a different product. "3.0" would go in the version element (sec 4.2.19) - should I mention that in the draft if it's unclear? Is this sufficient? The "metalink:identity (The "metalink:identity" Element)" element is a Text construct that conveys a human-readable identity for a file. For example, the identity of Firefox 3.5 would be "Firefox". > - sec 4.2.10.2. =A0do we really need to use a special "torrent" type > when "application/x-bittorrent" could be used? =A0I'd prefer to stick > just to media type syntax and get rid of the reserved syntax. =A0You > should also call them "media types" instead of (or as well as if you > prefer) MIME types, and include a reference to BCP 13. This has come up a few times in the past. :) http://www.ietf.org/mail-archive/web/apps-review/current/msg00162.html I prefer your approach, but I'd like others to weigh in. An alternative would be to drop any mention of torrents, but this is how people use metalink so I'd like it to be clear what they can do. I've made it "MIME media type", as used in RFC 4287, and referenced BCP 13/RFC 4288/ > - in sec 6.3, it's not within the authority of a protocol > specification to tell agents that they "MUST NOT stop processing" or > "MUST NOT change their behaviour". =A0They might have their own > perfectly good reasons for, say, halting if some XHTML with Javascript > were included. =A0I agree with what you're trying to accomplish, but > that should be specified by saying, for example, that extensions can > be ignored. That section is stolen outright from RFC 4287 sec 6.3 http://tools.ietf.org/html/rfc4287#section-6.3 You see the intent of what we want. Can you suggest replacement text? > Overall, a decent spec. =A0It's nice to see extensibility given > considerable attention for a change. Thanks, Mark! There are already a handful of metalink extensions and we want to ensure that continues. As you can see, we're relying on the text from Atom. Without it as a starting point, I think this draft would've been impossible. We keep interim revisions at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads