From stephen.farrell@cs.tcd.ie Wed Jun 1 05:43:52 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4FEE0B86; Wed, 1 Jun 2011 05:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz26MaXCl7YQ; Wed, 1 Jun 2011 05:43:49 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 24705E0825; Wed, 1 Jun 2011 05:16:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5A5E4153CD3; Wed, 1 Jun 2011 13:16:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1306930582; bh=B0uyx00XBLNKek /AwackzC4lMLYhoqEs4LxaRC2jnNM=; b=tMavOGikYAMNQZ3FGsFmgf9xFXM1Km EZc3+c2ZtVwIDlvpHiX8SUK1C6nwaSw60ySI0fPsWrtQqarRmS2IT/2/BC1rXMpY FgX6obZChRXJ/hJCt0njxxiVe1Ubn6c6pAJ/c+pzFVfmo6hh9J9+PHItrHHEShv6 o/GrfkIxmGNSsUnLHw/v7U9XXTpM4tzu5rc8aG9m1hQUU+oe50fTY/mg0kP9AcQm ZLBzjZWbP9sSbr3mfEP9KnserDJgnD7+PzMmSVgZ1Wq6ROQts+V4saJWLDMB1W93 8TNOZKEuTagsadkbaEJExC8wT2Y+s8H2o60XLMuBwFjnOTaGfPBf4bDQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id bfMUO+l4uhr5; Wed, 1 Jun 2011 13:16:22 +0100 (IST) Received: from [10.87.48.4] (unknown [86.45.55.19]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 31630153CD2; Wed, 1 Jun 2011 13:16:19 +0100 (IST) Message-ID: <4DE62D93.7040009@cs.tcd.ie> Date: Wed, 01 Jun 2011 13:16:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Nottingham References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 12:43:52 -0000 Just on DOSETA - that's not currently got any official home in the IETF so its not something that would be right to reference at this point (unless the oauth WG wanted to adopt DOSETA but I'd be very surprised if that were the case for timing reasons). However I do agree that keeping in mind that folks may move towards something like DOESTA in future is a good plan. To be clear, as an individual, I do think that "something like DOSETA" is a really good idea and maybe DOSETA will turn out to be that something, I don't know. S. On 01/06/11 00:57, Mark Nottingham wrote: > Hi, > > Reading draft -05. > > The "normalized request string" contains the request-URI and values extracted from the Host header. Be aware that intermediaries can and do change these; e.g., they may change an absolute URI to a relative URI in the request-line, without affecting the semantics of the request. See [1] for details (it covers other problematic conditions too). > > It would be more robust to calculate an effective request URI, as in [2]. > > Also, if you include a hash of the request body, you really need to include a hash of the body media type. > > Generally, I think that people can and will want to include other headers; just because *some* developers can't get this right doesn't mean we should preclude *all* developers from doing it. It'd be really nice to see this either leverage DOSETA [3][4], or at least offer a clean transition path to it. > > Regards, > > 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.1.2 > 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 > 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00 > 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02 > > > On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote: > >> (Please discuss this draft on the Apps-Discuss mailing list) >> >> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >> >> The draft includes: >> >> * An HTTP authentication scheme using a MAC algorithm to authenticate requests (via a pre-arranged MAC key). >> * An extension to the Set-Cookie header, providing a method for associating a MAC key with a session cookie. >> * An OAuth 2.0 binding, providing a method of returning MAC credentials as an access token. >> >> Some background: OAuth 1.0 introduced an HTTP authentication scheme using HMAC for authenticating an HTTP request with partial cryptographic protection of the HTTP request (namely, the request URI, host, and port). The OAuth 1.0 scheme was designed for delegation-based use cases, but is widely “abused” for simple client-server authentication (the poorly named ‘two-legged’ use case). This functionality has been separated from OAuth 2.0 and has been reintroduced as a standalone, generally applicable HTTP authentication scheme called MAC. >> >> Comments and feedback is greatly appreciated. >> >> EHL >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From ht@inf.ed.ac.uk Wed Jun 1 03:45:05 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE3CE07D0; Wed, 1 Jun 2011 03:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV5mc00uEw8j; Wed, 1 Jun 2011 03:45:03 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 920A3E07D3; Wed, 1 Jun 2011 03:45:02 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id p51AiPdH004603; Wed, 1 Jun 2011 11:44:30 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id p51AiOLN007641; Wed, 1 Jun 2011 11:44:24 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id p51AiOYt005860; Wed, 1 Jun 2011 11:44:24 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.13.8/8.13.8/Submit) id p51AiNIw005856; Wed, 1 Jun 2011 11:44:23 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Mary Barnes References: From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 01 Jun 2011 11:44:23 +0100 In-Reply-To: (Mary Barnes's message of "Mon, 23 May 2011 13:59:25 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 X-Mailman-Approved-At: Wed, 01 Jun 2011 08:02:24 -0700 Cc: Alan Johnston , apps-discuss@ietf.org, Richard Barnes , Simon Pietro Romano , Chris Boulton , xcon@ietf.org, iesg@ietf.org, Henning Schulzrinne Subject: Re: [apps-discuss] apps-team review of draft-ietf-xcon-ccmp-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 10:45:05 -0000 Mary Barnes writes: > Thank you for your detailed review. Responses are inline below [MB]. > > On Mon, May 16, 2011 at 4:04 AM, Henry S. Thompson wrote: > >> I have been selected as the Applications Area Review Team reviewer for >> this draft (for background on apps-review, please see >> http://www.apps.ietf.org/content/applications-area-review-team). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-xcon-ccmp-13 >> >> Title: Centralized Conferencing Manipulation Protocol >> >> Reviewer: Henry S. Thompson >> >> Review Date: 2011-05-13 >> >> Summary: This draft is almost ready for publication as a Proposed >> Standard but has a few issues that should be fixed before publication >> >> Major Issues: >> >> 4.2 Data Management >> >> 1) The approach to detecting competing updates and their consequences >> specified here seems unnecessarily complex. Was the alternative of >> including version numbers in _update_ messages (so that the server >> could reject any update whose target version had been superseded) >> considered and rejected? If so, perhaps a brief explanation of why >> it was rejected might be helful at this point. >> > [MB] The alternative was considered, however, with the XCON model, the > server is the only entity that "centralizes" information (in this case, the > available conference objects). A client might not have the very last version > of a conference object, due to the potential for concurrent operations > amongst independent client participants. However, an operation can still > succeed if there is no overlap amongst the data that is manipulated. Thus, > the server-side mechanism is what guarantees coherence in the data stored. > We can add some more text around that. Perhaps, prefacing the paragraph > with a statement about the model. [/MB] That sounds like a helpful addition. >> 2) In a related point, the statement at the end of this section that >> "a client subscribed to . . . notifications . . . will always have >> the most up-to-date version" is clearly false, in-so-far as it >> implies that such a client is guaranteed success for any update, as >> there is clearly a race condition here. >> > [MB] Yes, I can see that it's really not properly stated. The statement is > intending to say that the client will "get" the most up-to-date version with > the next notification - i.e., there is a way to recover in the case that the > update was either on an earlier version or no response received. [/MB] Right, something to that effect. . . >> 4.3 Data Model Compliance >> >> 1) Again this approach seems unnecessarily complex -- why does the >> data model have to constrain the initiation of a conference in this >> way. why not simply have messages which request new conference or >> new user IDs? >> > [MB] We do have messages for a new conference and new user IDs. The intent > here, was to eliminate the step of requesting those and thus have multiple > operations as a result of one request. We can add text around that. [/MB] Seems like a false economy to me, but yes, at least add a note. >> 2) I'm also confused by the fact that _elements_ described here as >> "mandatory" are not required by the schema. Specifically in 5.1 we >> will see that the 'confUserID' and 'confObjID' elements, which >> correspond precisely to XCON-USERID and XCON-URI which are >> described here as mandatory, appear in message type definitions as >> minOccurs="0", i.e. as optional. If they are optional, why is the >> above gensym complexity needed? If they are not optional, why >> doesn't the schema say so? >> > [MB] This is a common practice from what I have seen. This is because the > base request type is being reused, thus the elements are not mandatory for > each operation that uses the request type. So, the expectation is that it's > mandatory for the protocol for specific operations, but not mandatory in the > schema for all operations. In that case, XML Schema provides ways for the derived types to make inherited optional fields mandatory. . . > There may also be confusion in that the mandatory elements being referenced > are those in the *body* of the CCMP messages (the elements as defined in the > data model document) as opposed to the IDs in the *header* of the CCMP > messages defined in this document (confUserID and confObjID). > Perhaps this clarification would help? > OLD: > Since the XML documents carried in the CCMP need to be compliant with the > XCON data model... > NEW: > Since the XML documents carried in the body of CCMP requests/responses > need to be compliant with the XCON data model..." Yes. . . >> >> 3) It is unusual to refer to aspects of a data model with words such >> as 'element' and 'attribute', which are better reserved for use >> with respect to _XML serializations_ of data model instances. Ah, >> I see by looking at draft-ietf-xcon-common-data-model that the XCON >> data model is defined as an XML document. It's undoubtedly too >> late to do anything about that, but confounding data models and XML >> serializations is usually considered to be a mistake. . . >> > [MB] Can you characterize in what sense it is a mistake and what problems > it might cause? Or is it purely a nomenclature issue that is inaccurate? > I agree that resolving this concern would impact the data model. [/MB] Data is not inherently tree-structured. Thinking about data models as if they were often leads to awkward-at-best compromises. But in the end this was just a comment to explain to myself why what I think of as XML (serialisation) terminology was being applied to the data model. It might be worth including a note early on explaining that the data model is specified _as_ an XML infoset. . . >> 12.5 CCMP Protocol Registry >> >> Why are these registries needed? No role is specified for them >> anywhere in the body of the document. Registries are not free, and if >> all the information in the registry is also in the published schemas >> it's not at all clear what purpose they will serve. >> > [MB] We define the registries as the protocol is extensible and does > require specification. The registries also allow a reference to the > appropriate document that defines the normative behavior for the new > operations and new error codes. This is a standard procedure for RAI area > protocols - c.f., HELD (RFC 5985), SIP (RFC 3261), Registry for SIP header > field parameters (RFC 3698)... > I will note that we don't typically add a reference in the document that we > are defining the IANA registries. Is there a particular place you suggest > we add such a reference? Same place you end up putting the URIs for the XML Schema documents, maybe? > >> Minor Issues: >> >> >> 6.2. Alice gets detailed information about a specific blueprint >> >> The blueprintResponse message is not schema-valid per ccmp.xsd. On >> lines 32 and 33 of the example read >> confirm >> >> The problem really lies in DataModel.xsd -- whereas (correctly) >> ccmp.xsd uses xs:token as the base type for enumerated types, >> DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string, >> and the string value of the above element is "confirm >> ", which is not one of the allowed values. The >> example should be corrected, or, for preference, the schema in >> draft-ietf-xcon-common-data-model should be changed to use xs:token as >> the base type for join-handling-type and all other enumerated types. >> >> [MB] > Agree that the schema in the data model draft could be improved, by > changing definitions of the enumberated types. Did you send the authors of > that document this comment? Or has that been covered by another apps-team > review? No, would you be so kind? > "confirm" is one of the allowed tokens in the > element (at least in the latest version -- 27 -- of the data model draft.): > > > > > > > > > > The "newline" character was introduced for proper formatting of the document, but we agree that is not allowed per the definition above (). So, we should remove the newline. This change likely needs to be done elsewhere in the document. I'm all in favour of readability -- no change will be needed if the schema is changed as suggested above. . . >> 12.3 Media Type Registration >> >> It seems unlikely that the proposed extension of 'ccmpxml' will see >> much use---4 characters seems to be the practical limit for >> extensions. >> > [MB] How about 'ccmp'? Yes. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From eran@hueniverse.com Wed Jun 1 08:02:45 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E75E06FD for ; Wed, 1 Jun 2011 08:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-mTJCdNOzel for ; Wed, 1 Jun 2011 08:02:43 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A9667E07F8 for ; Wed, 1 Jun 2011 08:02:23 -0700 (PDT) Received: (qmail 25729 invoked from network); 1 Jun 2011 15:02:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 15:02:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 1 Jun 2011 08:00:40 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Wed, 1 Jun 2011 08:00:12 -0700 Thread-Topic: [apps-discuss] HTTP MAC Authentication Scheme Thread-Index: Acwf7oEQJBF82ilkT/6VDPS/ahDBDQAfEq6g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 15:02:45 -0000 > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Tuesday, May 31, 2011 4:57 PM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org; Ben Adida; http-state@ietf.org; OAuth WG; > 'Adam Barth (adam@adambarth.com)'; HTTP Working Group > Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme >=20 > Hi, >=20 > Reading draft -05. >=20 > The "normalized request string" contains the request-URI and values > extracted from the Host header. Be aware that intermediaries can and do > change these; e.g., they may change an absolute URI to a relative URI in = the > request-line, without affecting the semantics of the request. See [1] for > details (it covers other problematic conditions too). >=20 > It would be more robust to calculate an effective request URI, as in [2]. I'll take a look. > Also, if you include a hash of the request body, you really need to inclu= de a > hash of the body media type. This was suggested before, but are there really attack vectors for this? The problem is that content-type is a pretty flexible header, which means n= ormalization of the header will be required (case, parameter order, white s= pace, etc.). I would argue that if you are using MAC with body hash and an attacker chan= ging the media type can cause harm, you should use additional methods to se= cure the content-type (such as making the body self-describing). > Generally, I think that people can and will want to include other headers= ; just > because *some* developers can't get this right doesn't mean we should > preclude *all* developers from doing it. It'd be really nice to see this = either > leverage DOSETA [3][4], or at least offer a clean transition path to it. If someone comes up with a practical and secure way to normalize HTTP reque= st headers, they can either define a new authentication scheme or use the '= ext' parameter to pass the additional values. I would vote for a new scheme= . MAC is trivial to implement and interoperate. That simplicity comes at a = significant lack of features, and limiting extensibility is a design goal. EHL > Regards, >=20 > 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section- > 4.1.2 > 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-= 4.3 > 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00 > 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02 >=20 >=20 > On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote: >=20 > > (Please discuss this draft on the Apps-Discuss > mailing list) > > > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > > > The draft includes: > > > > * An HTTP authentication scheme using a MAC algorithm to authenticate > requests (via a pre-arranged MAC key). > > * An extension to the Set-Cookie header, providing a method for > associating a MAC key with a session cookie. > > * An OAuth 2.0 binding, providing a method of returning MAC credentials > as an access token. > > > > Some background: OAuth 1.0 introduced an HTTP authentication scheme > using HMAC for authenticating an HTTP request with partial cryptographic > protection of the HTTP request (namely, the request URI, host, and port). > The OAuth 1.0 scheme was designed for delegation-based use cases, but is > widely "abused" for simple client-server authentication (the poorly named > 'two-legged' use case). This functionality has been separated from OAuth = 2.0 > and has been reintroduced as a standalone, generally applicable HTTP > authentication scheme called MAC. > > > > Comments and feedback is greatly appreciated. > > > > EHL > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 From dzonatas@gmail.com Wed Jun 1 13:27:22 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14789E096E for ; Wed, 1 Jun 2011 13:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.189 X-Spam-Level: X-Spam-Status: No, score=-5.189 tagged_above=-999 required=5 tests=[AWL=-1.590, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQMi6JNpNH1k for ; Wed, 1 Jun 2011 13:27:21 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 63A7CE07A5 for ; Wed, 1 Jun 2011 13:27:21 -0700 (PDT) Received: by pvh18 with SMTP id 18so86747pvh.31 for ; Wed, 01 Jun 2011 13:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8HOSpu6HfaJ1q2Slonk3U7tQPsOqpGE8JA26Gbr9+4o=; b=MoAseUWBAm4Oxj953jxqpej4cSCzxfXztGHIrNyt5QLB9SDgopoV2fFqJ/UKTy6Xvq SP2vcVv7ZmrPkyumwL6Cgl3pz7/i79c2p8XFkCQyz64RLRe1/ddJwCUlI6cWauKumQDD TYvQaC19YxrVXG6if3hpbkDFGRCWafHuWIG3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=YHhiROicM/99ioQu/UjxvSfDITLaEP0C7H9y1D8fu+Ao/a0P6fgsSDcEic2XsTMWPB gDpMP90PG37aBOtHg15t7TKN//3HGXFkMq0mZtT5/IOG4Ef2RHfzk/I9e9dtIug+RWgN Smz0AwbDP2jnue4z3vg9Aj5Xud6juX3ZkOdt8= Received: by 10.68.25.102 with SMTP id b6mr3335022pbg.14.1306960040845; Wed, 01 Jun 2011 13:27:20 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id k9sm1364635pbc.54.2011.06.01.13.27.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 13:27:19 -0700 (PDT) Message-ID: <4DE6A061.5050005@gmail.com> Date: Wed, 01 Jun 2011 13:26:09 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Apps Discuss References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> In-Reply-To: <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 20:27:22 -0000 " Proposed: 5.9. strict-xhtml o Browser Hint Name: strict-xhtml o Description: Validation is enforced or is required before any expected requests or responses are allowed and processed. This hint neither prescribes any particular validation scheme nor prescribes any methods of invocation either before or after any given validation scheme. o Value Type: true | false o Contact: mnot@mnot.net " One example, if an intermediary detects javascript comments within tags (i.e. , ) then those may be changed to XML style comments (), removed, or aborted with one of the HTTP status 4XX codes. That example could be activated by the POST method with descriptors, and the hint reveals these methods are already allowed. They were proven comments that were not requested. That hint makes more sense in reverse POST events, gentler like how sandboxes work yet without specific emulation or virtual machine code. On 05/30/2011 11:28 PM, Mark Nottingham wrote: > FYI. Diffs at: > http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-browser-hints-02 > > Changelog: > - removed Ref header and rearranged referer-based hints > - added 'prefixlist' value type > - changed omit-cookies from list of cookie names to prefixlist > - added caching advice for 404s > > Feedback appreciated, as always. > > > > Begin forwarded message: > > >> From: internet-drafts@ietf.org >> Date: 31 May 2011 4:22:29 PM AEST >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : HTTP Browser Hints >> Author(s) : Mark Nottingham >> Filename : draft-nottingham-http-browser-hints-02.txt >> Pages : 9 >> Date : 2011-05-30 >> >> Over time, Web browsers have adapted how they use HTTP based upon >> common server configurations and behaviours. While this is necessary >> in the common case, it can be detrimental for performance and >> interoperability. >> >> This document establishes a mechanism whereby origin servers can make >> available hints for browsers about their preferences and >> capabilities, without imposing overhead on their interactions or >> requiring support for them. >> >> This is intended to allow browsers to safely optimise connections to >> servers. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From mnot@mnot.net Wed Jun 1 14:06:03 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7660DE0978 for ; Wed, 1 Jun 2011 14:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.222 X-Spam-Level: X-Spam-Status: No, score=-105.222 tagged_above=-999 required=5 tests=[AWL=-2.623, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoWZIJ5euSVd for ; Wed, 1 Jun 2011 14:06:01 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B894EE0970 for ; Wed, 1 Jun 2011 14:06:01 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.19.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E32E7509EE; Wed, 1 Jun 2011 17:05:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4DE6A061.5050005@gmail.com> Date: Thu, 2 Jun 2011 07:05:51 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <81A4D128-EFD1-4EA5-9311-625552167463@mnot.net> References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4DE6A061.5050005@gmail.com> To: Dzonatas Sol X-Mailer: Apple Mail (2.1084) Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 21:06:03 -0000 Browser-hints are targeted at browsers; see the requirements in the = draft. On 02/06/2011, at 6:26 AM, Dzonatas Sol wrote: > " > Proposed: >=20 > 5.9. strict-xhtml >=20 > o Browser Hint Name: strict-xhtml > o Description: Validation is enforced or is required before any = expected requests > or responses are allowed and processed. This hint neither = prescribes any > particular validation scheme nor prescribes any methods of = invocation either > before or after any given validation scheme. > o Value Type: true | false > o Contact: mnot@mnot.net > " >=20 > One example, if an intermediary detects javascript comments within = tags (i.e. , ) then those may be changed to XML style comments (), removed, or aborted with one of the HTTP status 4XX codes. = That example could be activated by the POST method with descriptors, and = the hint reveals these methods are already allowed. They were proven = comments that were not requested. >=20 > That hint makes more sense in reverse POST events, gentler like how = sandboxes work yet without specific emulation or virtual machine code. >=20 > On 05/30/2011 11:28 PM, Mark Nottingham wrote: >> FYI. Diffs at: >> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-browser-hints-0= 2 >>=20 >> Changelog: >> - removed Ref header and rearranged referer-based hints >> - added 'prefixlist' value type >> - changed omit-cookies from list of cookie names to prefixlist >> - added caching advice for 404s >>=20 >> Feedback appreciated, as always. >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >> =20 >>> From: internet-drafts@ietf.org >>> Date: 31 May 2011 4:22:29 PM AEST >>> To: i-d-announce@ietf.org >>> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt >>> Reply-To: internet-drafts@ietf.org >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>> Title : HTTP Browser Hints >>> Author(s) : Mark Nottingham >>> Filename : draft-nottingham-http-browser-hints-02.txt >>> Pages : 9 >>> Date : 2011-05-30 >>>=20 >>> Over time, Web browsers have adapted how they use HTTP based upon >>> common server configurations and behaviours. While this is = necessary >>> in the common case, it can be detrimental for performance and >>> interoperability. >>>=20 >>> This document establishes a mechanism whereby origin servers can = make >>> available hints for browsers about their preferences and >>> capabilities, without imposing overhead on their interactions or >>> requiring support for them. >>>=20 >>> This is intended to allow browsers to safely optimise connections = to >>> servers. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02= .txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> = ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.= txt >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> =20 >> -- >> Mark Nottingham http://www.mnot.net/ >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> =20 >=20 >=20 > --=20 > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From dzonatas@gmail.com Wed Jun 1 14:29:21 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF43DE099F for ; Wed, 1 Jun 2011 14:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[AWL=-1.535, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyNnmQRHo1Eg for ; Wed, 1 Jun 2011 14:29:21 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8BDE083F for ; Wed, 1 Jun 2011 14:29:21 -0700 (PDT) Received: by pzk5 with SMTP id 5so109542pzk.31 for ; Wed, 01 Jun 2011 14:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lWx3p67cvx/Gj8Y5O3lGR6v5nnG1OUes5k9NriL5oEk=; b=eOEzkRyjRn4RE+q6sXl6XJqpER/rE1sxAsRkkFPW/ePc+nP8LtYha3z7VkHre/GjIQ YeiUimw7Z/4Fw4ES0FXatrb2RTeiSg2wTNYsuGssKaeZkyOsaF650sH3zriTz6zU2/AS dNis0+FCG/rUKOtK8DrTNQf0Dt9833bM7sHTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=eCTgwgW5SPfWfobK3LmWRB87ixzWqd5bw3FFjOlOaVm/esD+mCO2YhaRIjNnqQn3K7 a4z3RWNSD0k8fcutHRtTEx+EJdTVdGUI/UfuFNYpYF1SJkb3Nyu2SmVtcDZ95rH5erRi 35xGsC/VNz9MNQ0samJny+3QT7TPGq+GF/4Oc= Received: by 10.68.23.169 with SMTP id n9mr618743pbf.265.1306963760666; Wed, 01 Jun 2011 14:29:20 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id y2sm1398765pbi.67.2011.06.01.14.29.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 14:29:19 -0700 (PDT) Message-ID: <4DE6AEEA.5090500@gmail.com> Date: Wed, 01 Jun 2011 14:28:10 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Mark Nottingham References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4DE6A061.5050005@gmail.com> <81A4D128-EFD1-4EA5-9311-625552167463@mnot.net> In-Reply-To: <81A4D128-EFD1-4EA5-9311-625552167463@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 21:29:21 -0000 Exactly, thanks. In "1. Introduction": " These are just two examples of common, conservative behaviour by browsers that is good for interoperability, but potentially bad for performance in certain circumstances. This memo proposes a mechanism whereby a HTTP server can advertise hints for browsers (and other clients), so that communication with them can be optimised. " Updated for requirements of RFC2119: " Proposed: 5.9. strict-xhtml o Browser Hint Name: strict-xhtml o Description: Validation SHOULD be enforced by the browser or SHOULD be required by the HTTP client/server that are related to the mechanisms, as described by section 1, before any expected requests or responses are allowed and processed. This hint neither prescribes any particular validation scheme nor prescribes any methods of invocation either before or after any given validation scheme. o Value Type: true | false o Contact: mnot@mnot.net " On 06/01/2011 02:05 PM, Mark Nottingham wrote: > Browser-hints are targeted at browsers; see the requirements in the draft. > > > On 02/06/2011, at 6:26 AM, Dzonatas Sol wrote: > > >> " >> Proposed: >> >> 5.9. strict-xhtml >> >> o Browser Hint Name: strict-xhtml >> o Description: Validation is enforced or is required before any expected requests >> or responses are allowed and processed. This hint neither prescribes any >> particular validation scheme nor prescribes any methods of invocation either >> before or after any given validation scheme. >> o Value Type: true | false >> o Contact: mnot@mnot.net >> " >> >> One example, if an intermediary detects javascript comments within tags (i.e.,) then those may be changed to XML style comments (), removed, or aborted with one of the HTTP status 4XX codes. That example could be activated by the POST method with descriptors, and the hint reveals these methods are already allowed. They were proven comments that were not requested. >> >> That hint makes more sense in reverse POST events, gentler like how sandboxes work yet without specific emulation or virtual machine code. >> >> On 05/30/2011 11:28 PM, Mark Nottingham wrote: >> >>> FYI. Diffs at: >>> http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-browser-hints-02 >>> >>> Changelog: >>> - removed Ref header and rearranged referer-based hints >>> - added 'prefixlist' value type >>> - changed omit-cookies from list of cookie names to prefixlist >>> - added caching advice for 404s >>> >>> Feedback appreciated, as always. >>> >>> >>> >>> Begin forwarded message: >>> >>> >>> >>>> From: internet-drafts@ietf.org >>>> Date: 31 May 2011 4:22:29 PM AEST >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt >>>> Reply-To: internet-drafts@ietf.org >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> Title : HTTP Browser Hints >>>> Author(s) : Mark Nottingham >>>> Filename : draft-nottingham-http-browser-hints-02.txt >>>> Pages : 9 >>>> Date : 2011-05-30 >>>> >>>> Over time, Web browsers have adapted how they use HTTP based upon >>>> common server configurations and behaviours. While this is necessary >>>> in the common case, it can be detrimental for performance and >>>> interoperability. >>>> >>>> This document establishes a mechanism whereby origin servers can make >>>> available hints for browsers about their preferences and >>>> capabilities, without imposing overhead on their interactions or >>>> requiring support for them. >>>> >>>> This is intended to allow browsers to safely optimise connections to >>>> servers. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >>> >> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > -- > Mark Nottingham http://www.mnot.net/ > > > > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From mnot@mnot.net Wed Jun 1 14:38:18 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91787E09A1 for ; Wed, 1 Jun 2011 14:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.165 X-Spam-Level: X-Spam-Status: No, score=-105.165 tagged_above=-999 required=5 tests=[AWL=-2.566, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQBbSF+qKCSR for ; Wed, 1 Jun 2011 14:38:17 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5A06BE083F for ; Wed, 1 Jun 2011 14:38:17 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.19.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AFBBC509E2; Wed, 1 Jun 2011 17:38:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4DE6AEEA.5090500@gmail.com> Date: Thu, 2 Jun 2011 07:38:07 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4DE6A061.5050005@gmail.com> <81A4D128-EFD1-4EA5-9311-625552167463@mnot.net> <4DE6AEEA.5090500@gmail.com> To: Dzonatas Sol X-Mailer: Apple Mail (2.1084) Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 21:38:18 -0000 If you can convince a browser to implement that, great. On 02/06/2011, at 7:28 AM, Dzonatas Sol wrote: > Exactly, thanks. >=20 > In "1. Introduction": > " > These are just two examples of common, conservative behaviour by > browsers that is good for interoperability, but potentially bad for > performance in certain circumstances. >=20 > This memo proposes a mechanism whereby a HTTP server can advertise > hints for browsers (and other clients), so that communication with > them can be optimised. > " >=20 > Updated for requirements of RFC2119: >=20 > " > Proposed: >=20 > 5.9. strict-xhtml >=20 > o Browser Hint Name: strict-xhtml > o Description: Validation SHOULD be enforced by the browser or = SHOULD be > required by the HTTP client/server that are related to the = mechanisms, as > described by section 1, before any expected requests or responses = are > allowed and processed. This hint neither prescribes any = particular validation > scheme nor prescribes any methods of invocation either before or = after any > given validation scheme. > o Value Type: true | false > o Contact: mnot@mnot.net > " >=20 >=20 > On 06/01/2011 02:05 PM, Mark Nottingham wrote: >> Browser-hints are targeted at browsers; see the requirements in the = draft. >>=20 >>=20 >> On 02/06/2011, at 6:26 AM, Dzonatas Sol wrote: >>=20 >> =20 >>> " >>> Proposed: >>>=20 >>> 5.9. strict-xhtml >>>=20 >>> o Browser Hint Name: strict-xhtml >>> o Description: Validation is enforced or is required before any = expected requests >>> or responses are allowed and processed. This hint neither = prescribes any >>> particular validation scheme nor prescribes any methods of = invocation either >>> before or after any given validation scheme. >>> o Value Type: true | false >>> o Contact: mnot@mnot.net >>> " >>>=20 >>> One example, if an intermediary detects javascript comments within = tags (i.e.,) = then those may be changed to XML style comments (), = removed, or aborted with one of the HTTP status 4XX codes. That example = could be activated by the POST method with descriptors, and the hint = reveals these methods are already allowed. They were proven comments = that were not requested. >>>=20 >>> That hint makes more sense in reverse POST events, gentler like how = sandboxes work yet without specific emulation or virtual machine code. >>>=20 >>> On 05/30/2011 11:28 PM, Mark Nottingham wrote: >>> =20 >>>> FYI. Diffs at: >>>> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-browser-hints-0= 2 >>>>=20 >>>> Changelog: >>>> - removed Ref header and rearranged referer-based hints >>>> - added 'prefixlist' value type >>>> - changed omit-cookies from list of cookie names to prefixlist >>>> - added caching advice for 404s >>>>=20 >>>> Feedback appreciated, as always. >>>>=20 >>>>=20 >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>=20 >>>> =20 >>>>> From: internet-drafts@ietf.org >>>>> Date: 31 May 2011 4:22:29 PM AEST >>>>> To: i-d-announce@ietf.org >>>>> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt >>>>> Reply-To: internet-drafts@ietf.org >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>>=20 >>>>> Title : HTTP Browser Hints >>>>> Author(s) : Mark Nottingham >>>>> Filename : draft-nottingham-http-browser-hints-02.txt >>>>> Pages : 9 >>>>> Date : 2011-05-30 >>>>>=20 >>>>> Over time, Web browsers have adapted how they use HTTP based = upon >>>>> common server configurations and behaviours. While this is = necessary >>>>> in the common case, it can be detrimental for performance and >>>>> interoperability. >>>>>=20 >>>>> This document establishes a mechanism whereby origin servers can = make >>>>> available hints for browsers about their preferences and >>>>> capabilities, without imposing overhead on their interactions or >>>>> requiring support for them. >>>>>=20 >>>>> This is intended to allow browsers to safely optimise = connections to >>>>> servers. >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>> = http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02= .txt >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>> = ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.= txt >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>=20 >>>>> =20 >>>> -- >>>> Mark Nottingham http://www.mnot.net/ >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>=20 >>>>=20 >>>> =20 >>>=20 >>> --=20 >>> --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> =20 >> -- >> Mark Nottingham http://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >> =20 >=20 >=20 > --=20 > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant >=20 -- Mark Nottingham http://www.mnot.net/ From dzonatas@gmail.com Wed Jun 1 14:55:31 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6256AE0874 for ; Wed, 1 Jun 2011 14:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[AWL=-2.464, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOpUBq1xCTdr for ; Wed, 1 Jun 2011 14:55:30 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 81950E086D for ; Wed, 1 Jun 2011 14:55:30 -0700 (PDT) Received: by pwi5 with SMTP id 5so247246pwi.31 for ; Wed, 01 Jun 2011 14:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GZBjbzkNJOMEJi/XPjkcSIUqjPe/VPrXOyRzVo5doDM=; b=XwgjOhHmj6B4e4jjjJEDdK8GVj49D4CArEk5mtZ1C33yPVvoITkiXOSP0sy8y6YjMl Sz01VQClPKfUEcl2vfsJK6AiNBupy47oabmsuZaqMen68ZhGCaJAtqgn7BhxGtmJ8iVG 64kwRINqFuBQTVlhICGLRkLoVnVVriH1lrP2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=AsZoEPAqDkWdBaGf+i1rniGvRjYQPy1siMI+thod1aCRzdSZcAarh6KsCSbiwjqGGI OynI3uioy+kGF495yjIOLnt+F+jiHwapwlPJPvBW4JaE/MAyC2eyDB8kCIg/iKDAinaN M1VdE8E+pWctPdLqv54QqFbJ1l1ye0CnwICzE= Received: by 10.68.27.103 with SMTP id s7mr3284891pbg.246.1306965330134; Wed, 01 Jun 2011 14:55:30 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id c3sm44544pbk.13.2011.06.01.14.55.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 14:55:29 -0700 (PDT) Message-ID: <4DE6B50B.7050803@gmail.com> Date: Wed, 01 Jun 2011 14:54:19 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Mark Nottingham References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4DE6A061.5050005@gmail.com> <81A4D128-EFD1-4EA5-9311-625552167463@mnot.net> <4DE6AEEA.5090500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 21:55:31 -0000 Without my specific implementation, let me point out the implied strictness of the .XXX domain. I've known implementations that try the cookie-cutter approach to create walled gardens around minorities, yet those implementations have only broken families by blind's eye to enforcement of rules that separate kids from parents in any way, especially those in potentially exploited situations or uncontrolled conditions. Instead of those cookie-cutter cases, the most successful guideline is no age, no sex, and no location. The "strict-xhtml" hint can help balance these well known experiences. On 06/01/2011 02:38 PM, Mark Nottingham wrote: > If you can convince a browser to implement that, great. > > > On 02/06/2011, at 7:28 AM, Dzonatas Sol wrote: > > >> Exactly, thanks. >> >> In "1. Introduction": >> " >> These are just two examples of common, conservative behaviour by >> browsers that is good for interoperability, but potentially bad for >> performance in certain circumstances. >> >> This memo proposes a mechanism whereby a HTTP server can advertise >> hints for browsers (and other clients), so that communication with >> them can be optimised. >> " >> >> Updated for requirements of RFC2119: >> >> " >> Proposed: >> >> 5.9. strict-xhtml >> >> o Browser Hint Name: strict-xhtml >> o Description: Validation SHOULD be enforced by the browser or SHOULD be >> required by the HTTP client/server that are related to the mechanisms, as >> described by section 1, before any expected requests or responses are >> allowed and processed. This hint neither prescribes any particular validation >> scheme nor prescribes any methods of invocation either before or after any >> given validation scheme. >> o Value Type: true | false >> o Contact: mnot@mnot.net >> " >> >> >> On 06/01/2011 02:05 PM, Mark Nottingham wrote: >> >>> Browser-hints are targeted at browsers; see the requirements in the draft. >>> >>> >>> On 02/06/2011, at 6:26 AM, Dzonatas Sol wrote: >>> >>> >>> >>>> " >>>> Proposed: >>>> >>>> 5.9. strict-xhtml >>>> >>>> o Browser Hint Name: strict-xhtml >>>> o Description: Validation is enforced or is required before any expected requests >>>> or responses are allowed and processed. This hint neither prescribes any >>>> particular validation scheme nor prescribes any methods of invocation either >>>> before or after any given validation scheme. >>>> o Value Type: true | false >>>> o Contact: mnot@mnot.net >>>> " >>>> >>>> One example, if an intermediary detects javascript comments within tags (i.e.,) then those may be changed to XML style comments (), removed, or aborted with one of the HTTP status 4XX codes. That example could be activated by the POST method with descriptors, and the hint reveals these methods are already allowed. They were proven comments that were not requested. >>>> >>>> That hint makes more sense in reverse POST events, gentler like how sandboxes work yet without specific emulation or virtual machine code. >>>> >>>> On 05/30/2011 11:28 PM, Mark Nottingham wrote: >>>> >>>> >>>>> FYI. Diffs at: >>>>> http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-browser-hints-02 >>>>> >>>>> Changelog: >>>>> - removed Ref header and rearranged referer-based hints >>>>> - added 'prefixlist' value type >>>>> - changed omit-cookies from list of cookie names to prefixlist >>>>> - added caching advice for 404s >>>>> >>>>> Feedback appreciated, as always. >>>>> >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>> >>>>> >>>>> >>>>>> From: internet-drafts@ietf.org >>>>>> Date: 31 May 2011 4:22:29 PM AEST >>>>>> To: i-d-announce@ietf.org >>>>>> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt >>>>>> Reply-To: internet-drafts@ietf.org >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>> >>>>>> Title : HTTP Browser Hints >>>>>> Author(s) : Mark Nottingham >>>>>> Filename : draft-nottingham-http-browser-hints-02.txt >>>>>> Pages : 9 >>>>>> Date : 2011-05-30 >>>>>> >>>>>> Over time, Web browsers have adapted how they use HTTP based upon >>>>>> common server configurations and behaviours. While this is necessary >>>>>> in the common case, it can be detrimental for performance and >>>>>> interoperability. >>>>>> >>>>>> This document establishes a mechanism whereby origin servers can make >>>>>> available hints for browsers about their preferences and >>>>>> capabilities, without imposing overhead on their interactions or >>>>>> requiring support for them. >>>>>> >>>>>> This is intended to allow browsers to safely optimise connections to >>>>>> servers. >>>>>> >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> This Internet-Draft can be retrieved at: >>>>>> ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Mark Nottingham http://www.mnot.net/ >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> apps-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> --- https://twitter.com/Dzonatas_Sol --- >>>> Web Development, Software Engineering, Virtual Reality, Consultant >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> >>>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >>> >>> >>> >> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> > -- > Mark Nottingham http://www.mnot.net/ > > > > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Wed Jun 1 16:13:31 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB02E06FA for ; Wed, 1 Jun 2011 16:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.023 X-Spam-Level: X-Spam-Status: No, score=-4.023 tagged_above=-999 required=5 tests=[AWL=-2.384, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OB4+BcHr89A for ; Wed, 1 Jun 2011 16:13:30 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFEBE0678 for ; Wed, 1 Jun 2011 16:13:30 -0700 (PDT) Received: by pwi5 with SMTP id 5so271223pwi.31 for ; Wed, 01 Jun 2011 16:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=K3AmqB6IuIsoJPe64eSCR/eKsOxi6+t9yL28Jaiu2JY=; b=o98ve1GlIz50l4QD/PeGv99ljsKgxaJhSKQkk7ZbmhUm9SU9iLkSqr/dJDMxjtm8Lg NXy/I+nJZq+4rctd6RjMLxaQsAoDOHdoIF/X2m8cr5n5pgo8pU1DJ43hQkQpcdUWcoJP mTzDYfEyYBJiXeOzyMo7oT+U1oK9z6uWVSBJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ldInVSMB9FRO6+Tkvhu5aWrqo600WLZjYe3/QNpQVGAWQkyomT6QVbTPqsjPN9FG3o 0Sm1oWugZcgDYE0Z9xAs7/eZh7/wyBGOQabZCLu4fcqfxuJXZoGHdIuuJHbbFk2ZBpvk jYDBFYl3tekj8ZgLqL21z3y52jtXnjT+RIX4w= Received: by 10.68.8.105 with SMTP id q9mr28615pba.3.1306970010211; Wed, 01 Jun 2011 16:13:30 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id p5sm24202pbd.92.2011.06.01.16.13.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 16:13:29 -0700 (PDT) Message-ID: <4DE6C753.3050300@gmail.com> Date: Wed, 01 Jun 2011 16:12:19 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Dzonatas Sol References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4DE6A061.5050005@gmail.com> <81A4D128-EFD1-4EA5-9311-625552167463@mnot.net> <4DE6AEEA.5090500@gmail.com> <4DE6B50B.7050803@gmail.com> In-Reply-To: <4DE6B50B.7050803@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , Apps Discuss Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 23:13:31 -0000 For non-.XXX domains, there is also this Assembly approved implementation, already: http://www.leginfo.ca.gov/pub/11-12/bill/asm/ab_0151-0200/ab_155_bill_20110502_amended_asm_v97.html That begs the question on how browsers need to implement the wholesaler perspective or else what compliant implementations exist due to http status code 402 (obvious optimization), which "strict-xhtml" may help filter-in currency per state by presence. On 06/01/2011 02:54 PM, Dzonatas Sol wrote: > Without my specific implementation, let me point out the implied > strictness of the .XXX domain. I've known implementations that try the > cookie-cutter approach to create walled gardens around minorities, yet > those implementations have only broken families by blind's eye to > enforcement of rules that separate kids from parents in any way, > especially those in potentially exploited situations or uncontrolled > conditions. > > Instead of those cookie-cutter cases, the most successful guideline is > no age, no sex, and no location. The "strict-xhtml" hint can help > balance these well known experiences. > > On 06/01/2011 02:38 PM, Mark Nottingham wrote: >> If you can convince a browser to implement that, great. >> >> >> On 02/06/2011, at 7:28 AM, Dzonatas Sol wrote: >> >>> Exactly, thanks. >>> >>> In "1. Introduction": >>> " >>> These are just two examples of common, conservative behaviour by >>> browsers that is good for interoperability, but potentially bad for >>> performance in certain circumstances. >>> >>> This memo proposes a mechanism whereby a HTTP server can advertise >>> hints for browsers (and other clients), so that communication with >>> them can be optimised. >>> " >>> >>> Updated for requirements of RFC2119: >>> >>> " >>> Proposed: >>> >>> 5.9. strict-xhtml >>> >>> o Browser Hint Name: strict-xhtml >>> o Description: Validation SHOULD be enforced by the browser or >>> SHOULD be >>> required by the HTTP client/server that are related to the >>> mechanisms, as >>> described by section 1, before any expected requests or >>> responses are >>> allowed and processed. This hint neither prescribes any >>> particular validation >>> scheme nor prescribes any methods of invocation either before >>> or after any >>> given validation scheme. >>> o Value Type: true | false >>> o Contact: mnot@mnot.net >>> " >>> >>> >>> On 06/01/2011 02:05 PM, Mark Nottingham wrote: >>>> Browser-hints are targeted at browsers; see the requirements in the >>>> draft. >>>> >>>> >>>> On 02/06/2011, at 6:26 AM, Dzonatas Sol wrote: >>>> >>>> >>>>> " >>>>> Proposed: >>>>> >>>>> 5.9. strict-xhtml >>>>> >>>>> o Browser Hint Name: strict-xhtml >>>>> o Description: Validation is enforced or is required before >>>>> any expected requests >>>>> or responses are allowed and processed. This hint neither >>>>> prescribes any >>>>> particular validation scheme nor prescribes any methods of >>>>> invocation either >>>>> before or after any given validation scheme. >>>>> o Value Type: true | false >>>>> o Contact: mnot@mnot.net >>>>> " >>>>> >>>>> One example, if an intermediary detects javascript comments within >>>>> tags (i.e.,) then those may be changed to XML style comments (>>>> comments ?>), removed, or aborted with one of the HTTP status 4XX >>>>> codes. That example could be activated by the POST method with >>>>> descriptors, and the hint reveals these methods are already >>>>> allowed. They were proven comments that were not requested. >>>>> >>>>> That hint makes more sense in reverse POST events, gentler like >>>>> how sandboxes work yet without specific emulation or virtual >>>>> machine code. >>>>> >>>>> On 05/30/2011 11:28 PM, Mark Nottingham wrote: >>>>> >>>>>> FYI. Diffs at: >>>>>> >>>>>> http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-browser-hints-02 >>>>>> >>>>>> >>>>>> Changelog: >>>>>> - removed Ref header and rearranged referer-based hints >>>>>> - added 'prefixlist' value type >>>>>> - changed omit-cookies from list of cookie names to prefixlist >>>>>> - added caching advice for 404s >>>>>> >>>>>> Feedback appreciated, as always. >>>>>> >>>>>> >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> >>>>>> >>>>>>> From: internet-drafts@ietf.org >>>>>>> Date: 31 May 2011 4:22:29 PM AEST >>>>>>> To: i-d-announce@ietf.org >>>>>>> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt >>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line >>>>>>> Internet-Drafts directories. >>>>>>> >>>>>>> Title : HTTP Browser Hints >>>>>>> Author(s) : Mark Nottingham >>>>>>> Filename : draft-nottingham-http-browser-hints-02.txt >>>>>>> Pages : 9 >>>>>>> Date : 2011-05-30 >>>>>>> >>>>>>> Over time, Web browsers have adapted how they use HTTP based >>>>>>> upon >>>>>>> common server configurations and behaviours. While this is >>>>>>> necessary >>>>>>> in the common case, it can be detrimental for performance and >>>>>>> interoperability. >>>>>>> >>>>>>> This document establishes a mechanism whereby origin servers >>>>>>> can make >>>>>>> available hints for browsers about their preferences and >>>>>>> capabilities, without imposing overhead on their interactions or >>>>>>> requiring support for them. >>>>>>> >>>>>>> This is intended to allow browsers to safely optimise >>>>>>> connections to >>>>>>> servers. >>>>>>> >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt >>>>>>> >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> This Internet-Draft can be retrieved at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt >>>>>>> >>>>>>> _______________________________________________ >>>>>>> I-D-Announce mailing list >>>>>>> I-D-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>> >>>>>>> >>>>>> -- >>>>>> Mark Nottingham http://www.mnot.net/ >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> apps-discuss mailing list >>>>>> apps-discuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> --- https://twitter.com/Dzonatas_Sol --- >>>>> Web Development, Software Engineering, Virtual Reality, Consultant >>>>> >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> apps-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>> >>>> -- >>>> Mark Nottingham http://www.mnot.net/ >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From mnot@mnot.net Wed Jun 1 17:15:48 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3002E0758; Wed, 1 Jun 2011 17:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.11 X-Spam-Level: X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[AWL=-2.511, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrE3nCJNmr6D; Wed, 1 Jun 2011 17:15:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2A76EE06EB; Wed, 1 Jun 2011 17:15:47 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.19.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5BC68509DB; Wed, 1 Jun 2011 20:15:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 2 Jun 2011 10:15:37 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2011 00:15:48 -0000 On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: > This was suggested before, but are there really attack vectors for = this? If not having a current, working attack to demonstrate is a valid way to = shrug off a security concern, that's great; it'll be a useful approach = to many of the discussions I have. :) > The problem is that content-type is a pretty flexible header, which = means normalization of the header will be required (case, parameter = order, white space, etc.). The media type is the important part, and it's much more constrained. > I would argue that if you are using MAC with body hash and an attacker = changing the media type can cause harm, you should use additional = methods to secure the content-type (such as making the body = self-describing). That seems like a step backwards, considering all of the work that Adam = has put into limiting the use of sniffing. Cheers, -- Mark Nottingham http://www.mnot.net/ From ietf@adambarth.com Wed Jun 1 18:26:26 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01C4E0796; Wed, 1 Jun 2011 18:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4q+OLj2WaGw; Wed, 1 Jun 2011 18:26:26 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 487D1E06A0; Wed, 1 Jun 2011 18:26:26 -0700 (PDT) Received: by yxk30 with SMTP id 30so203231yxk.31 for ; Wed, 01 Jun 2011 18:26:25 -0700 (PDT) Received: by 10.151.5.14 with SMTP id h14mr168197ybi.182.1306977985636; Wed, 01 Jun 2011 18:26:25 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id p23sm81293ybc.29.2011.06.01.18.26.24 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 18:26:24 -0700 (PDT) Received: by gyf3 with SMTP id 3so206066gyf.31 for ; Wed, 01 Jun 2011 18:26:24 -0700 (PDT) Received: by 10.91.103.14 with SMTP id f14mr155271agm.125.1306977984068; Wed, 01 Jun 2011 18:26:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Wed, 1 Jun 2011 18:25:54 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Adam Barth Date: Wed, 1 Jun 2011 18:25:54 -0700 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" , Ben Adida , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2011 01:26:27 -0000 On Wed, Jun 1, 2011 at 5:15 PM, Mark Nottingham wrote: > On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: >> This was suggested before, but are there really attack vectors for this? > > If not having a current, working attack to demonstrate is a valid way to shrug off a security concern, that's great; it'll be a useful approach to many of the discussions I have. :) > > >> The problem is that content-type is a pretty flexible header, which means normalization of the header will be required (case, parameter order, white space, etc.). > > The media type is the important part, and it's much more constrained. > > >> I would argue that if you are using MAC with body hash and an attacker changing the media type can cause harm, you should use additional methods to secure the content-type (such as making the body self-describing). > > That seems like a step backwards, considering all of the work that Adam has put into limiting the use of sniffing. Yeah, I tried to twist Eran's arm into including the media type in the body hash too. It's probably more important for responses than requests, however. Adam From stpeter@stpeter.im Wed Jun 1 20:42:42 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A5FE0740 for ; Wed, 1 Jun 2011 20:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.629 X-Spam-Level: X-Spam-Status: No, score=-102.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A25g0WHps1KF for ; Wed, 1 Jun 2011 20:42:42 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2883FE07A3 for ; Wed, 1 Jun 2011 20:42:31 -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 2EEA740046 for ; Wed, 1 Jun 2011 21:42:30 -0600 (MDT) Message-ID: <4DE706A4.6000904@stpeter.im> Date: Wed, 01 Jun 2011 21:42:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080708080805080501040704" Subject: [apps-discuss] reminder: WG session and BoF requests X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2011 03:42:43 -0000 This is a cryptographically signed message in MIME format. --------------ms080708080805080501040704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, Monday is the deadline for requesting WG sessions at IETF 81: https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi And Monday the 13th is the deadline for BoF requests: http://www.ietf.org/iesg/bof-procedures.html Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080708080805080501040704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw MjAzNDIyOFowIwYJKoZIhvcNAQkEMRYEFGgnkeqQWgbJNuN1xfJ5AevPwAUKMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCUP6elvqjODpYUxj/zcxMoelaWmw1jMdUo69MXdJhpB0Crxof3D/RRWpOK LRPp48eFOSMD9gkiCKNUEoQeRbB1rj6CbVeYF6dxzdsZ7mHPGNtWFfThJ1paYZXOL8AE2t37 ZhiqP54JHD67J7lpQxoO/Cq3VdoaHnJWCgWtmYeLMdXQUhjtDj1lui/aBVR4XONkcrdtYTKn 8HXPS9+LgozkJnpFQcE0VnpyQ4i4KG6rn3/rIAEcpeTEoSZDTZL30nxdq6/U6FQrK235JlT6 VjQ5+uZjhaRkR0sV1viXdQa0+JukQA3Fwc3zyCJI03oKxlL44wtvbXpEkJdCy0XslYvjAAAA AAAA --------------ms080708080805080501040704-- From eran@hueniverse.com Thu Jun 2 08:58:51 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D39E0827 for ; Thu, 2 Jun 2011 08:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.823 X-Spam-Level: X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Are86GKE5-sD for ; Thu, 2 Jun 2011 08:58:51 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 14295E0826 for ; Thu, 2 Jun 2011 08:58:50 -0700 (PDT) Received: (qmail 11884 invoked from network); 2 Jun 2011 15:45:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Jun 2011 15:45:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 2 Jun 2011 08:45:04 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Thu, 2 Jun 2011 08:44:35 -0700 Thread-Topic: [apps-discuss] HTTP MAC Authentication Scheme Thread-Index: AcwgujliuTi4Kf4mRayjenHdrNw8EQAgXYFA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA782@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2011 15:58:51 -0000 > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, June 01, 2011 5:16 PM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org; Ben Adida; http-state@ietf.org; OAuth WG; > 'Adam Barth (adam@adambarth.com)'; HTTP Working Group > Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme >=20 >=20 > On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: >=20 > > This was suggested before, but are there really attack vectors for this= ? >=20 > If not having a current, working attack to demonstrate is a valid way to = shrug > off a security concern, that's great; it'll be a useful approach to many = of the > discussions I have. :) No, but its valid as long as it is fully documented. We're not going to sol= ve everything. > > The problem is that content-type is a pretty flexible header, which mea= ns > normalization of the header will be required (case, parameter order, whit= e > space, etc.). >=20 > The media type is the important part, and it's much more constrained. So include just the: type "/" subtype forced to lowercase? >=20 > > I would argue that if you are using MAC with body hash and an attacker > changing the media type can cause harm, you should use additional methods > to secure the content-type (such as making the body self-describing). >=20 >=20 > That seems like a step backwards, considering all of the work that Adam h= as > put into limiting the use of sniffing. I wasn't suggesting sniffing. EHL > Cheers, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 From dzonatas@gmail.com Thu Jun 2 14:14:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD92E0864 for ; Thu, 2 Jun 2011 14:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.929 X-Spam-Level: X-Spam-Status: No, score=-4.929 tagged_above=-999 required=5 tests=[AWL=-1.330, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-P7mZ3GxtCx for ; Thu, 2 Jun 2011 14:14:00 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9EFAE0830 for ; Thu, 2 Jun 2011 14:14:00 -0700 (PDT) Received: by pzk5 with SMTP id 5so636502pzk.31 for ; Thu, 02 Jun 2011 14:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zK4VI9d82OrDA3dvVeMxsGuJTe1H1IlwAykMNbkZMFg=; b=IMKa6Z/BewoIXY6T6IJx57rlJ6w9t7eRMz3MDAybtpGPPH35LSZZKnroHviYLEEy9L 6jLAFsC2XFhk5BNCjkdcIihRfEwr43/07H3Gt68OrsbA4Iwo9Hggt26eggrsc1/TMtpf W/IgLhPxy/XwRHhX3yTwwctE6A52kYW4CId+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=HVMbPilrN2ZFzCjNDse671pcK1UGW4AhvnzUI3d/zj4RW5V2WPlEjafDOu5nTob7u9 5DjIEuX/xftCgO05Jty4/L1KVCGpjJg/icr+NMuADC8UExB/+LQ8InuyF7MVXdyU3h36 5aK7a0ACP0sWNRjiwMwQl8wE+hAIOlftIo3iI= Received: by 10.68.21.8 with SMTP id r8mr484635pbe.499.1307049240467; Thu, 02 Jun 2011 14:14:00 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id c5sm847749pbj.73.2011.06.02.14.13.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2011 14:13:59 -0700 (PDT) Message-ID: <4DE7FCD4.9010909@gmail.com> Date: Thu, 02 Jun 2011 14:12:52 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA782@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA782@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2011 21:14:02 -0000 On 06/02/2011 08:44 AM, Eran Hammer-Lahav wrote: > The media type is the important part, and it's much more constrained. > > So include just the: > > type "/" subtype > > forced to lowercase? > If that media is constrained within x dimensions of n known types then that is the normalization vector. Outside of that vector is magic types, but preliminary lamda(x) may be intentionally denoted as predicates(n) where subtype starts with /. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dhc@dcrocker.net Thu Jun 2 14:16:44 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528C1E08BD; Thu, 2 Jun 2011 14:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRyOR0rfJk53; Thu, 2 Jun 2011 14:16:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A98F1E06FC; Thu, 2 Jun 2011 14:16:43 -0700 (PDT) Received: from [192.168.1.8] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p52LGW9q002436 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 14:16:38 -0700 Message-ID: <4DE7FDA7.8030300@dcrocker.net> Date: Thu, 02 Jun 2011 14:16:23 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE62D93.7040009@cs.tcd.ie> In-Reply-To: <4DE62D93.7040009@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 02 Jun 2011 14:16:39 -0700 (PDT) Cc: OAuth WG , HTTP Working Group , "apps-discuss@ietf.org" , "http-state@ietf.org" Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 02 Jun 2011 21:16:44 -0000 Stephen, On 6/1/2011 5:16 AM, Stephen Farrell wrote: > Just on DOSETA - that's not currently got any official > home in the IETF so its not something that would be right > to reference at this point (unless the oauth WG wanted to > adopt DOSETA but I'd be very surprised if that were the > case for timing reasons). I'm confused on two counts. (To be honest, of course, I'm confused about many points, but two of them are relevant to this thread...) One, of course, is that I've been actively raising DOSETA in various IETF venues for the different groups to considering adopting and/or adapting it. As such, discussion of DOSETA permits exploring the possibility of adoption and/or adaptation. The second is that you appear to be stating a policy that a working group is only permitted to reference things which are currently and officially IETF work items. I suspect that that is not what you meant, so at the least, please clarify what you do mean. If you really do mean anything like the interpretation I just summarized, please explain its basis. > To be clear, as an individual, I do think that "something > like DOSETA" is a really good idea and maybe DOSETA will > turn out to be that something, I don't know. If it is not acceptable to 'reference' DOSETA now and here, then how will the determination of its utility be made? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mnot@mnot.net Thu Jun 2 16:21:51 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9067E0709; Thu, 2 Jun 2011 16:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.089 X-Spam-Level: X-Spam-Status: No, score=-105.089 tagged_above=-999 required=5 tests=[AWL=-2.490, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0vi4daJ2NNH; Thu, 2 Jun 2011 16:21:51 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id DF821E06AB; Thu, 2 Jun 2011 16:21:50 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.19.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 637C8509DB; Thu, 2 Jun 2011 19:21:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA782@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 3 Jun 2011 09:21:42 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8AEC97B7-D39F-4234-A33C-533906E8485E@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA782@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2011 23:21:51 -0000 On 03/06/2011, at 1:44 AM, Eran Hammer-Lahav wrote: >=20 >=20 >> -----Original Message----- >> From: Mark Nottingham [mailto:mnot@mnot.net] >> Sent: Wednesday, June 01, 2011 5:16 PM >> To: Eran Hammer-Lahav >> Cc: apps-discuss@ietf.org; Ben Adida; http-state@ietf.org; OAuth WG; >> 'Adam Barth (adam@adambarth.com)'; HTTP Working Group >> Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme >>=20 >>=20 >> On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: >>=20 >>> This was suggested before, but are there really attack vectors for = this? >>=20 >> If not having a current, working attack to demonstrate is a valid way = to shrug >> off a security concern, that's great; it'll be a useful approach to = many of the >> discussions I have. :) >=20 > No, but its valid as long as it is fully documented. We're not going = to solve everything. >=20 >>> The problem is that content-type is a pretty flexible header, which = means >> normalization of the header will be required (case, parameter order, = white >> space, etc.). >>=20 >> The media type is the important part, and it's much more constrained. >=20 > So include just the: >=20 > type "/" subtype >=20 > forced to lowercase? Think so. >=20 >>=20 >>> I would argue that if you are using MAC with body hash and an = attacker >> changing the media type can cause harm, you should use additional = methods >> to secure the content-type (such as making the body self-describing). >>=20 >>=20 >> That seems like a step backwards, considering all of the work that = Adam has >> put into limiting the use of sniffing. >=20 > I wasn't suggesting sniffing. >=20 > EHL >=20 >> Cheers, >>=20 >> -- >> Mark Nottingham http://www.mnot.net/ >>=20 >>=20 >=20 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Jun 2 20:13:23 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C72E0674 for ; Thu, 2 Jun 2011 20:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.1 X-Spam-Level: X-Spam-Status: No, score=-105.1 tagged_above=-999 required=5 tests=[AWL=-2.501, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IotfKeggVfo for ; Thu, 2 Jun 2011 20:13:22 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED29E0678 for ; Thu, 2 Jun 2011 20:13:22 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.19.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7F101509EB; Thu, 2 Jun 2011 23:13:15 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 3 Jun 2011 13:13:12 +1000 Message-Id: <321CAE57-EDC0-4DEE-801C-808FCBA36EF9@mnot.net> To: "apps-discuss@ietf.org Discuss" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [apps-discuss] draft-saintandre-xdash-considered-harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2011 03:13:23 -0000 Will this be progressing? I, for one, would like to see this as an BCP. Cheers, -- Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Thu Jun 2 20:22:16 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96915E07EC for ; Thu, 2 Jun 2011 20:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB0+H+gK+5gR for ; Thu, 2 Jun 2011 20:22:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D58B4E0678 for ; Thu, 2 Jun 2011 20:22:15 -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 AEC3340046; Thu, 2 Jun 2011 21:22:14 -0600 (MDT) Message-ID: <4DE85364.6030900@stpeter.im> Date: Thu, 02 Jun 2011 21:22:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Nottingham References: <321CAE57-EDC0-4DEE-801C-808FCBA36EF9@mnot.net> In-Reply-To: <321CAE57-EDC0-4DEE-801C-808FCBA36EF9@mnot.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050101040604060700090808" Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2011 03:22:16 -0000 This is a cryptographically signed message in MIME format. --------------ms050101040604060700090808 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/2/11 9:13 PM, Mark Nottingham wrote: > >=20 > Will this be progressing? I, for one, would like to see this as an BCP.= I'd be happy to bring it back to life, although I admit that I've mostly forgotten about it and that I haven't yet addressed some of the feedback I received last year. Also, I think "harmful" might be a bit strong -- "considered-useless" perhaps? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050101040604060700090808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw MzAzMjIxMlowIwYJKoZIhvcNAQkEMRYEFF74hJbVULQ0b5VlLD6asImudOGCMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBR4grfK0WsLbKDNBPr7p1nL5jTD6QZrNI4f0SFK53C9R6BkrgPD4Ktkdal InblosnQIaVWVf4f5NEkxR45DBMuOFLCQfA6/h4nme26Uj7G0hSPqu6VrTZkMPGWkmBkTPKN FxSiVmaDAeoGkaqCKedL+j4qV5pQ/IIz3FCP7ojPsdEOEH3VXGunHUnaEKIGbPLT663ydHsv 3CjQO8ZDWwOajhZN+3ZbY0HZXktHozOOo9EadFU2x/NDhEEaIKONysjwnrsEsP4vs1x/rsLz ZfX6+cuyTdEV+fgW6qV4lbJmy9coMsz+PkvyNHkfUbZSXOdg2CBHum7Z4QNnNGiGXLVSAAAA AAAA --------------ms050101040604060700090808-- From mnot@mnot.net Thu Jun 2 20:25:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB57E088B for ; Thu, 2 Jun 2011 20:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.052 X-Spam-Level: X-Spam-Status: No, score=-105.052 tagged_above=-999 required=5 tests=[AWL=-2.453, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RuphvUczapO for ; Thu, 2 Jun 2011 20:25:00 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 59A66E07EC for ; Thu, 2 Jun 2011 20:25:00 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.19.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0CE6A509B3; Thu, 2 Jun 2011 23:24:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4DE85364.6030900@stpeter.im> Date: Fri, 3 Jun 2011 13:24:56 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <321CAE57-EDC0-4DEE-801C-808FCBA36EF9@mnot.net> <4DE85364.6030900@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2011 03:25:01 -0000 On 03/06/2011, at 1:22 PM, Peter Saint-Andre wrote: > On 6/2/11 9:13 PM, Mark Nottingham wrote: >> = >>=20 >> Will this be progressing? I, for one, would like to see this as an = BCP. >=20 > I'd be happy to bring it back to life Please do. Happy to help. > , although I admit that I've mostly > forgotten about it and that I haven't yet addressed some of the = feedback > I received last year. Also, I think "harmful" might be a bit strong -- > "considered-useless" perhaps? Not *quite* strong enough. "considered bad practice?" Or just change the title to something more generic like "Appropriate use = of X-". Cheers, -- Mark Nottingham http://www.mnot.net/ From evnikita2@gmail.com Thu Jun 2 23:57:40 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A24E070F for ; Thu, 2 Jun 2011 23:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7Ll9dwhAQcr for ; Thu, 2 Jun 2011 23:57:39 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D09DE06E7 for ; Thu, 2 Jun 2011 23:57:39 -0700 (PDT) Received: by fxm15 with SMTP id 15so1283513fxm.31 for ; Thu, 02 Jun 2011 23:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9NRo2iQwC+w9PU7k7ep0VKwNWEoopnEFhQm0E5Xv/XA=; b=eFsEzctOi5TkXA7r7FaRno4+q3aMUfQnIUwigpJ20SqhnEieH3DEs9qBx2KvvAFQ6r viKuA4P6jv9QTD0rLiFi8VEvoMslqupc3lGpTwGc4B+zFUjVXmBL5Q1OJl4lw0mFVffs MH6p9Z4KIObFAjsMW5R1HgIP4rkzJ10HQ8OGM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=dZm3Yn4UBUZs1wL3S18SVG/F6/xc1TpGitYKcKNp2p9n9VoR8BbPzSlvgPtovq5pkX 5y9Wz5t6ia31gsLfmRT1zRo7SpoO7DD5bwGLnmTZ2etdJh3OmppjbaQC5luZApqyBylN 9DmaQCbubT6z6ElGsrRU/QqexWX+zO64AmW7s= Received: by 10.223.68.193 with SMTP id w1mr650996fai.42.1307084258407; Thu, 02 Jun 2011 23:57:38 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id b25sm401125fab.4.2011.06.02.23.57.36 (version=SSLv3 cipher=OTHER); Thu, 02 Jun 2011 23:57:37 -0700 (PDT) Message-ID: <4DE8860E.4070801@gmail.com> Date: Fri, 03 Jun 2011 09:58:22 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <321CAE57-EDC0-4DEE-801C-808FCBA36EF9@mnot.net> <4DE85364.6030900@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2011 06:57:40 -0000 03.06.2011 6:24, Mark Nottingham wrote: > On 03/06/2011, at 1:22 PM, Peter Saint-Andre wrote: > >> On 6/2/11 9:13 PM, Mark Nottingham wrote: >>> >>> >>> Will this be progressing? I, for one, would like to see this as an BCP. >> I'd be happy to bring it back to life > Please do. Happy to help. Maybe the document may be adopted as APPSAWG document; but the author should finally decide on this. > >> , although I admit that I've mostly >> forgotten about it and that I haven't yet addressed some of the feedback >> I received last year. Also, I think "harmful" might be a bit strong -- >> "considered-useless" perhaps? Writing "considered harmful" RFCs is a current practice; see https://datatracker.ietf.org/doc/search/?name=harmful&rfcs=on. So I think having the title "X-" Considered Harmful is fine. Mykyta Yevstifeyev > > Not *quite* strong enough. "considered bad practice?" > > Or just change the title to something more generic like "Appropriate use of X-". > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From stephen.farrell@cs.tcd.ie Fri Jun 3 05:26:59 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2180E0714; Fri, 3 Jun 2011 05:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpMnUKF7BM61; Fri, 3 Jun 2011 05:26:59 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id B4A26E06D3; Fri, 3 Jun 2011 05:26:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 49D41171C30; Fri, 3 Jun 2011 13:26:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307104014; bh=Q+JdJI1kXBA9eH 9b6Y2qCB0QRbUR9H7RHhiWCvjUFeo=; b=N1PKaHRptFYeLUajLdGdur0Ld5LqE0 HDQhAvu/rkDmIz/pMpxIsn/xp0YhfCrvAtZDQ3Ckz4pe0PGUSRB/b4TyISIpNk5L Ut6/1asppg+oA4/BTDaK78mO9wd+TvhUXp45fQ5C764h2n3xdmNcKfbnZbap8KtZ w03WP+l5n27LTfv+KLoMWQh5V4zDTyrv1FUqQCAf2rucEmDlcg4DiDs1ALGWn4Cf 9Eqqh8HCNRD5t6jl9vTvgXxHrLf4RKyiJMqyuocfjGBvW2eHosPx7zAymzl94dZP cLIcOHy7dXl/cfTDl5J6kf4W2VdZayPXy0jVKKodwzKxu9IK0tMPlWEQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id bBe2TUES7iDn; Fri, 3 Jun 2011 13:26:54 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 74227171C2E; Fri, 3 Jun 2011 13:26:51 +0100 (IST) Message-ID: <4DE8D2F4.1050103@cs.tcd.ie> Date: Fri, 03 Jun 2011 13:26:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE62D93.7040009@cs.tcd.ie> <4DE7FDA7.8030300@dcrocker.net> In-Reply-To: <4DE7FDA7.8030300@dcrocker.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: OAuth WG , HTTP Working Group , "apps-discuss@ietf.org" , "http-state@ietf.org" Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2011 12:26:59 -0000 Hi Dave, On 02/06/11 22:16, Dave CROCKER wrote: > Stephen, > > On 6/1/2011 5:16 AM, Stephen Farrell wrote: >> Just on DOSETA - that's not currently got any official >> home in the IETF so its not something that would be right >> to reference at this point (unless the oauth WG wanted to >> adopt DOSETA but I'd be very surprised if that were the >> case for timing reasons). > > I'm confused on two counts. (To be honest, of course, I'm confused > about many points, but two of them are relevant to this thread...) > > One, of course, is that I've been actively raising DOSETA in various > IETF venues for the different groups to considering adopting and/or > adapting it. As such, discussion of DOSETA permits exploring the > possibility of adoption and/or adaptation. I don't get the confusion aspect there, but the rest below might clarify. > The second is that you appear to be stating a policy that a working > group is only permitted to reference things which are currently and > officially IETF work items. I suspect that that is not what you meant, > so at the least, please clarify what you do mean. Right. I wasn't stating any general policy. What I meant was that the oauth WG needs to get oauth2.0 done and that seems to require also getting the mac scheme done, so adding a dependency to something at an early stage of development (like DOSETA) at this point would not be a good plan for oauth. That's all. Exploring whether DOSETA or something similar is useful is a fine thing to do, its just a bit early for oauth. > If you really do mean anything like the interpretation I just > summarized, please explain its basis. > >> To be clear, as an individual, I do think that "something >> like DOSETA" is a really good idea and maybe DOSETA will >> turn out to be that something, I don't know. > > If it is not acceptable to 'reference' DOSETA now and here, then how > will the determination of its utility be made? Following our usual highly-predictable process I guess;-) I assume that the next step would be for a bunch of interested folks to figure out where and when it might make sense to do more on DOSETA. S. > > > Thanks. > > d/ > From julian.reschke@gmx.de Mon Jun 6 05:42:18 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D535711E8135 for ; Mon, 6 Jun 2011 05:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNBnaFT5yAXO for ; Mon, 6 Jun 2011 05:42:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 949E111E8133 for ; Mon, 6 Jun 2011 05:42:16 -0700 (PDT) Received: (qmail invoked by alias); 06 Jun 2011 12:42:15 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp013) with SMTP; 06 Jun 2011 14:42:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+reiMucm6rVutIQvUt1rNHsyk4h+u7dL9r/qC8sA FMECnLVL+s13xF Message-ID: <4DECCB27.4030209@gmx.de> Date: Mon, 06 Jun 2011 14:42:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] Thoughts on text/* encoding defaults X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2011 12:42:18 -0000 Hi there. In Prague, we had a few hallway conversations with respect to the default encoding of text/* media types. Below are my notes (references to the relevant spec sections, information about a recent change in HTTPbis, and a rough proposal about how to proceed). Best regards, Julian -- snip -- 1) RFC 2046 says that the default is US-ASCII "Note that the character set used, if anything other than US- ASCII, must always be explicitly specified in the Content-Type field." -- 2) RFC 2616 says it's ISO-8859-1 "The "charset" parameter is used with some media types to define the character set (Section 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value. See Section 3.4.1 for compatibility problems." -- 3) For text/xml, RFC 3023 says it's US-ASCII, no matter what 2616 says :-) "Conformant with [RFC2046], if a text/xml entity is received with the charset parameter omitted, MIME processors and XML processors MUST use the default charset value of "us-ascii"[ASCII]. In cases where the XML MIME entity is transmitted via HTTP, the default charset value is still "us-ascii". (Note: There is an inconsistency between this specification and HTTP/1.1, which uses ISO-8859-1[ISO8859] as the default for a historical reason. Since XML is a new format, a new default should be chosen for better I18N. US-ASCII was chosen, since it is the intersection of UTF-8 and ISO-8859-1 and since it is already used by MIME.)" -- The problem Recipients do not implement this; they take the absence of encoding information as indicator to inspect the payload; this is at least true for text/xml and text/html (see and ) Current development: HTTPbis, P3 has dropped drop the default and delegate to the relevant media type definitions (see , ). Left to do: a) Revise RFC 2046; allow text/* types that carry encoding information inline to do the expected thing (overriding the US-ASCII default); warn against doing so in new registrations (recommend to only support UTF-8, and require to always explicitly include the charset parameter, such as text/vcard is going to do it?) b) Revise RFC 3023 to delegate text/xml charset defaults to revision of 2046? Best regards, Julian From vumip1@gmail.com Mon Jun 6 08:09:25 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899F911E80FE for ; Mon, 6 Jun 2011 08:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-BgrR5mLen1 for ; Mon, 6 Jun 2011 08:09:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7248D11E8167 for ; Mon, 6 Jun 2011 08:09:24 -0700 (PDT) Received: by gxk19 with SMTP id 19so2039470gxk.31 for ; Mon, 06 Jun 2011 08:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=37rCtzfsX//ZTfmThqj//fTzYHOVX4Pw2MpoOMJ+ONk=; b=R/IDw9BcrN6z2e6+eX6Vut8Jygk9bH8AKjMYZcUaxn2eOPjzNl0ZV/IDD+ga5qcEMg GoKleSOjLvVNxpJg4oxZ+iqA1qARCMIuuJS9jtET6xNEJO9uFU/KkR/kflrl01d8n/Oe b7KwKuxUZeJtE4QLMD+6pLs3sYPJ8kL1ppCtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Qxm9mZAdg2YXzTzsK7r2B6mie0MyBz7SDbJq53PgvodbaKBquVC5t8XRdFJVmjWBD3 /6LxzJhsu72wFLN9flQJmPAbjD0smvy4T3yeVMdzNlREPY5/OTMSmqYB73/4YB4g1ZB7 Z4suStDPrwDujiFBn75UlA0iwjCW7InsTHOt4= MIME-Version: 1.0 Received: by 10.236.180.102 with SMTP id i66mr6583770yhm.138.1307372963750; Mon, 06 Jun 2011 08:09:23 -0700 (PDT) Received: by 10.236.136.70 with HTTP; Mon, 6 Jun 2011 08:09:23 -0700 (PDT) Date: Mon, 6 Jun 2011 11:09:23 -0400 Message-ID: From: Bhumip Khasnabish To: Barry Leiba , Apps Discuss Content-Type: multipart/mixed; boundary=20cf3056409717e29604a50c7dab Subject: [apps-discuss] may I have your permisison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2011 15:09:25 -0000 --20cf3056409717e29604a50c7dab Content-Type: multipart/alternative; boundary=20cf3056409717e28b04a50c7da9 --20cf3056409717e28b04a50c7da9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Barry, Can I distribute the JNSM CFP on CCNS (Cloud Computing, Networking, and Services) SI to apps-discuss@ietf.org ? Thanks for quick response. Best. Bhumip Khasnabish vumip1@gmail.com bhumip.khasnabish@zteusa.com +1-781-752-8003 (mobile) http://www.linkedin.com/in/bhumipkhasnabish __o _ `\ <, _ .......... ( =95 ) / ( =95 ) ...................... --20cf3056409717e28b04a50c7da9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Barry,
=A0
Can I distribute the JNSM CFP on CCNS (Cloud Computing, Networking, an= d Services)
=A0
Thanks for quick response.
Best.

Bhumip Khasnabish

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __o
=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 _ `\ <, _
.......... ( =95 ) / ( =95 = ) ......................

--20cf3056409717e28b04a50c7da9-- --20cf3056409717e29604a50c7dab Content-Type: application/pdf; name="JNSM-CCNS-SI-CFP-17Feb2011.pdf" Content-Disposition: attachment; filename="JNSM-CCNS-SI-CFP-17Feb2011.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_golk2g8o0 JVBERi0xLjQKJeLjz9MKMiAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDgxMj4+ c3RyZWFtCkiJhJTbbtswDIbv8xS8lIZalnwOUBRo0gJrgQwF4ru0F27sNF4TJ3CUdn37kfQhXtat QBxLIilSPz/Zva5tucqWFi4v3Wtrs+W6yGHhprs9PLmTye4XLGKtfAOx79MrDDwVjEOIw1CNtT9G r/nx2X7sC3C/F1le1OCmPHvIXsoqs+Wugquryc0URpN05E7nGpYH0ACHZTVy01SDgXQ10kprHCzB aUfvYDx00/SK8RcEKkgg3Y4W4v6HdHwxn8mn9H6kKUiTv6e8MY3ykQCZ/jxtSQOfPLTyvMZjIeZ7 6QSikI4RSxmIMttIowWUB+kJeo69GR4FOszvpC8eJY5gJxNRkRmmON3spEPukcj7NV7a0oachYyW BiWHveD2FxI3Jgc+SyHH6BCJd3w4tn7F0Zl3xtMcDTDnwuo3LKmk6gd1Ttun0agpeEaBGWXjLTLa kkO2lJjX7JmYxigdNPrzKDS+MsM2NBojDH44FP2We2y4x8pPcAtlAkP/ftz0HHEKI8YJXwHOkgR8 qIvR6ltvi5WXdDatsP2N+XbWUvRAuM6mdzeYuoXrv2SF/yLL6ARi7auoRWuKrd1wA7GlOSxxSkNs ZSD2R1LQlmiuXs7kitQ4aGW4aNjzgnMWT0WELYx+B2NVSOML+04JdtJg/zHJK82G2f7iOVBRz3OH SIch4bTuGS5rprvmyYZRsL2RkTpQ2k+x2mYdNeaEDf5XTPUZNpHCGr+6hP25y55JSrc5NoAPLgpm BKK1LrnIXoczLR0vUV4MjqG9eedT56hxdiBltw1Hj9vSTKdnVxneJSfCO+Ng4EE6CWqLV5kooMJq XsebivU1y81KmVmekT6GvhbO50UzhQuxzrCkNxkLbj/ULLnPtfNKZYnFD5zyp4Js29aHfOks7JcD Q3O00ADkiRW3m5wpRU8TRSLAphNi/SFNIva0zKGWYoEqKjkUHZ83bcZWNdKIdPa+1tmVKMKfaP9N dkSotjZ6KN2BVlfDiFYbOuuRUg7OwPuQ76puj4soI5k1ubCzPfJ4cIi+Gz1BC5Fj02LupsYiHP4Q Jyg+f8mdiMMrttpmF/gtwADSV6kbCmVuZHN0cmVhbQplbmRvYmoKMyAwIG9iago8PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDc3ND4+c3RyZWFtCkiJfFVNb9swDL3nV/AoFbVj2XHiAEWBru2h Awp0mG/LDkYS197y4SVO0/bXj4+SXCcrdrAt0eQj+UhRURhFhvI5RbxIKD9SnIUsiShfDH6oYqPH aqGDkaK9NrFa6sCo3YtOVD3XI7sl/TP/Oggii3SkwCIEJoyNRVkzDEMUz9ohrJd6qkTWMn4PIDkJ JQ3HIx/JfKuDsdrrIGabIOMVjCLRl7DDaGJ1GS//NYj+SSwK48SjHdltDd8VP1uAHrpo9hxlgex2 dQmhZFpLtM/ggKxd0KVvIvUHW4EoVjUE0HljOxLw0jGI9Kfn/A11kNjVK4uaDngHnFqW4twaTBXN FK++8SPY38X+HmozzcKQwemMHEvJ/eMtDYZPdHU1fLx9uCND19df7lgGilIo94o4Cacj1HCcWsZu GHrFT1ttQcLhWUjgCJkOfldLuH3RE1WDOW1Y81A4mxrbd+xEV7ZbJmNDglXSXGciWONPcxACgbNh wrkisNxAuCD5wJcgHfGC4Y41fltssWKjndCVcKOMReUAARx54aU26Qm2rZtPxuYhZRuLzQrBlefM Br7ZzgiM5ADElN8xeT5EBCYOAf4uPNhg7bJdapMoH6cwhHA28A5J22MOCHs5PKwh1Nr4K08QdavC ZSK5ecoFqr3UqS9gZ7d2xFmxqC/gaaj54Lp/iKbynjc+lrX7sqZRLeLEs+pH2laFOCb5+BrZfs0v mKqDp9vVQ/wTBK/sswGg1WCmcBIy5ZsOYm45IGXhpBsctgGl/+C41o5BPiwZusT8t03O2s+m8NEe bEwHwez3+YkfIV0C7dVGdJrGxwZ/UsNege1QlExcJyGbZudw0TZYw2ztns8aKrFRlsVZ95M/OiXd QOGJlw/MJP5ZakrbtUhxASvw3J0D/Gt6/iTaYZ4bnip5aYf5yI/fEQ4EXybSzG86mGCET1VV6yCF vbONrO352PrkYoiTME59gWfqAjgz7aaeH/wmTLp5X2D2UuFG8Cd3GBfo9GCnocncfXJxcp98HHH6 K8AAUyGrjgplbmRzdHJlYW0KZW5kb2JqCjQgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aCA3OTA+PnN0cmVhbQpIiXRVTW/bMAy951fwKAGzIskfiYeih6Y7dFiHAfGtHQavTptstpO5 zrL++5GUZTvOdohjiRT53iNFaxWDhqyYiTxfy+zHTCutQ8hO8CAepYwE5M1GBkbAqzRWtDKIxK4s QX7NPs4CcjbkHIRa2QQCo6x10QoOBtkThT+BUejoEgU+jWGrz6dV2Hk8iK1MxF4GVjwxghqXBWWe yyBEw1I0cMC9hn0OZGl20mjBSBlj3tD6jY7vatoACpK3+DiyP7sqGQqAdX+U0h2HcByJYryTKMAo z288l5Nzb8w5CYOEilw4TOn0YrEGLWyk0sVUjJjMg6BjNdqNNKGoc2kiUT8h+zf8YT2QyuFAufbS igaRtLToSmMTNarHA9s3CPvXcYdvDcWiZcXbFL6lgMBJioID5Wirffx261QK8ew5HaPVwjcRXNAx HR0bejoFAag8gJrS0s6e+quGlpJBu2VQgEXRgnCUDLrDShsFi8B2kmQ/NGTs2ypldEaFkU9dySCh fsFDJQcLFuIP9RCqGXTrFrCrluIZVmQo6QRvHAuYEBeP1i6I8FIl6X8FoLdzARxe6zQ4HLnTSIH6 RZpEDFfLdFcLixhxKY07z3UpoGYt2tO4A37Soot1DjZR4QSjB9TT0OqChZl25cCici2fU8YXTM8X qOInG+iqdYr5Kx6rpC+Fu00OO+r8na/LRqaiesVg7mJOKEQqjsYAP9yvYDb/AldX8/vV3S1YuL6+ ucW9y+ESmIVKQxIxiV3+jLJu+XpSQvhIUD7TfFnfE/L1HUGgWePGxwpFpZ9zcXe8U2DMPh2RP1Fn 46x0A4jGRXn0k8zNVB4mbKWJsmudJe3myDD3oOlH1LP3cRNsM50tC2qTfw3as9niq9D0Y4+YVqPy FZibVw7AeSEDTBObcU9yOfNDT63hzwVwbYkGkCLbgTnxYSrsUZb8x4Jx9hc+3frPAMfdEczX6fCx yi47vu+7vk4um+TTzb546xsl9o0yX9lvGpDC8yxVKZ3TwC8miiDWyDeCrJpdab2MrjHYPMusc3fB 4a8AAwDraKNYCmVuZHN0cmVhbQplbmRvYmoKNSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDc0OD4+c3RyZWFtCkiJrFXbTttAEH3PV8zjroQ3u2s7tiWEFJJKUBUJCYsXqConTiiF xpadgMLXd2bWjpOQkiL1IfZ6dm5nLif9NNVgIJ33tNI6hHQKHp0spK9gVKwj0JDmvTsxkrF4lqEo pBWrHIZyIMqSBI/4m+JXhhdL6fM3KS1qabQAEi9yuEGNmUxEhbcv0pjGzHPSWn5Pv/Y0hdcc2ao4 sS60AJn+6n25GkGv/+28yNdwetq/Gl2OwWg4Ozsf08XI/mhweMYoHQfgGRVZnxycah0Nz9BHP02t U3I++/8MntAu1kAwCdpvTLlctWAXDyg+QTHkDoZzMYU7rIlnxDLbQxerIG7BeZQIWfh8rXxt2qA1 RllKI4qKA/liIT0rHmQgTiDjc04P4ONMRqz8im82eNqxgIy8QQb0It1Kegk2ImHH2IeYpdBl+kHZ w4NlD5TFGu6UPQ4+LjtX2zjgWgfvy35N+V8yyjnmWUgvoMyNgJlDR2OHsgmdnunikR588eDAeFvF 5cMr9mWEuuxuIFaEPd/rUKL0YL9B3XyEpLLTqglNee36kIh8K/IGnSEjqwYDvzW6IQyM5kV6kct8 OtvLxKrEtKnULhU/iY9thj28Gb4Kfe6QH/6nxbjG2VpNtmmAF4HEVSPkbW/JgcrDGg0tXOBrPWlV c7gXPMfUGxPwrpHvJ3zTPV2wZVlWDcvQF4X9eS9pfmlRKfgl/vZJxWpl4+Ro6Q5Otw1VZMznpnsz eDsVu8XMHrnxPi/siqYme25W/C0jGZ0K3l0qCAKdEza382sWb+8/G9MPKmlC3mPa8oI9V9vrXSOH Y53CXfuLguRt3I4yuvJZo2wUHaucf3joEhVEnxu6Y7Rwy6vCm7OkPV5teKCjgDf6ZBmrsIzpg7kB +EiUAiOesdZsQytsVVPh+iQfz4gvayzLU+PThM5fSdondIIhn8tdLpr+NYkaG+EMt5kgbMzwYTkd CurUssbUEGERinHnu6NB/LeBPwIMAMlXwp4KZW5kc3RyZWFtCmVuZG9iago2IDAgb2JqCjw8L0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjM1Pj5zdHJlYW0KSInsVE1v2zAMvedX8CgdrOjDHzEQ FGjTbWixAkXn21AMrpN2GdKkSJoO+ffjo+Is8bJ2A3bcxZbIJ5Li02N12UussTanqqHt4jv5whTO kaVq3PusVhOdeLXSiVOkb6vLnhUwgM5kfEJw7Ku+9d5djajX/3i2GG9oOOxfjS7OKaR0cnJ2DsfI f7HkqLrvJcEZ61NKnCl8QIChtcXpCcfoV5WPoBiT99tDKDBDcqnZxwoGtmgrPde5muqMa3VOPeug lryB4W6N3USXakwXOlXz1ll3LpSbIt2GUwmSWxOs27/hkRqs8b5sa6i1V/O9LEi67GQJpgjZYRZr Q6Rglw7XSQZq8agLVU850hw00CcO/KydWizZVD/wbsKAvk5K9Z43AM4kbZIpYDeRvFIOiRUBmc2U D4WYo4avvgOyBhQR96h+hdrBMWpdMM7/Z1aySCzXqiuNQQ85dl4tQMcjCMViCqkx2zmz3XzFf8Ku MRZrfGbw/wQ9kBy/ZwwtYZ3gMay4TLHLEbE3O0dXx79nOPWvM8y3/TcM3+hcOsoMWy7cqzVYbOLt y0g8XbEJvjtQz20o5A2AjA1t6QFkPdtap9155UyZp13l/UL6Hj8t0XMJ33CRG6Ju+4Ip/eCtMciv 70gnvTO564zBQfp2K2VaHDTwmgvETFjIdGhAPwbBSg8U1TI7xjJALnARrOJAKOKhJ1jaXRwF7SjB H1iZJPRHcyE79mpitX/1aI6o5+DOpyIKEc0TVs86CVEZL/wCoBq6RtXy/EUNgpBVI19oCU3KFEFA YhM0fYBYJnHuRgUuW90F1dCI2zjbhRWRjaNkd9CX+ED3lHdLPwQYAMnoqw4KZW5kc3RyZWFtCmVu ZG9iago3IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjE1Pj5zdHJlYW0KSImk VU1v2kAQvfMr9rgr1ct+eW1LCIlApFKFKhVWL1VVBZsg2sREpDTl33dmjO2YOCGoB+zd9cybeW9m lvRTT7E0Y/B4YjqW3kS4znucifRn73I2Zr3+1cUm37PBoD8bTycs9Gw4vJjgh7H5oZhm6W0vMEo6 61igZWQsAgyUikZDwOinqSmNSkzYV05KKuUofLmAFGSsDhl841MRhLwQQcJ/i8Dz5VZ8T1v5ysS7 Q7oBQhOgbgEqaeHkADjZiEB7fi8svxGB42vYYgDP2XwJh1vYW/5HhOWXbHkU0Etro3MCzh8AJ+aI nRHkLazWFCVj8DJ8lGN4yuYBV8C0tKA00JFdi8BQanyDZmRBq4yedwT3eKyNlsqfKqXXnaUMpY19 u5Sxe7uUSD/E4KSIeVHKa+GAAuoaAjGtgbEBJhYYJvwDrBla7BZ3B5tM+PJ4LGIkqxVULaHfrkAD 9N2TxUd47BcVeE4eCLOB813+QpdI6sSeFKazx3UjjA3f2eOnhBkB0TzfUq0TqCKU+rHSZ4GEKkUa wp/RErdP8EaW6P0L3mhWrACQXWK3/BWulrgAUEUG6FBQCAKb02SBxbaqDDRfRPrjKfsCADtMppUH w7QxUpl4UAa5rxYFGrEj5V9XO+psw1A6Y87rwo5xbIk9Jh7VIO2Qet6efpAA2FfTDySu6mlbrWhg mztjxWhsiwZmVmPTIZk240r4z9zfr09XN5bEzr9v35Bnit1HuWWkUiPQc9Kjo+PmxnpFla+1uK0r EHoM9byp77R1Wz123EDaydCZU6MbdzaTTui/ojW6/3ensX8CDADBmJ0bCmVuZHN0cmVhbQplbmRv YmoKOCAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDcwMj4+c3RyZWFtCkiJlFXb ThsxEH3PV/jRlljH9q73IqFIIVCVikgo2TdAFd1NWlpIUEio8vedM96FkCygPmRlj+d65szkSk5V KpfKybkq5FrFUtzSZVGLr8pKHFfKy1pcqoRPd/R7VjY8VWS6bfXhZ0Y+KnVTfutZp60TRpR170pu Wkv43wpEWjaexUjl8p4OEGxqtiWrCqZ/hYxU+bsXGW1MykI6FHhItS3i1v0PFXFCUSGf6EhZRE7W LKSsIg+BRfpRKp/v6JxTki9imFDV+5EFIp+NR6LXvzhZ1ltxfNwfj85PRZ6KweDkFA8j990IK8p5 L7Kp9pRjZHXmYqR1bEw2HJCPflm6oBR80r0xsjo3WSgiPHGhti00QR5GO1e0hV6isBVKXKookdWM 4KT0c/p4eQSReFW5ZZW1imKJmoO2YOkCSNT4iHEDGPXtFwSv72z0RG1/CMAmBxjZRDvjdwvowquw nXgVOvee8Yp9g1eefIxXBzw7EF7JSZOyl39QRQBkMmvT59d7fO645cCDK622+Ab1fXymFwBwKK4l jcNkMr1WgVfcgDkQncLPij0+M80D1i1mfGeHRHUX4rPx5iVIF7bOatMO0AfYdnOx4L78FxffYmvf xTYhbPdYoFObNInyuMKBxzP7dIHFMflsXGEJLAMUGW8M7AFeIlWzQo7oQsz0cgyVUlkjv6i0SzwJ nSP5rFlf8KEB6MGWweWBhI84LKC/WIc2kaN2iw3J/PHxCRuuT4btUlshIu89rLEKUSFmPUHIOEkE yeQZN7t7izVg7MLiip0BWi9Z68XK6DzN3sfVH+DaBCeGZod00jRdn7HJms5RjQudFXt0+mxUOzjw hk5vt754hRn/LlGLchC2rTmnri7mO3xh9Nc8fV5uoI7LhtsBERuPW3Lh85Nd0kCDBw0D9tic78D+ AVIYPPFPgAEA/NqcvgplbmRzdHJlYW0KZW5kb2JqCjkgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCA2MjU+PnN0cmVhbQpIiaRUyW7bMBC96yt4JIGK5iqJgGEglhwgRd1Dq/YSBIVj OUKKeIETt3W/vpyhFsc24qK9SJzhLG+Wx3GRk2iQq2+CSFI+RLFMuUhILHmqLSmraChEejUqv0eD slTBhhIW5NZHcCH8aU6aw08ieSZSIiDALb1hsaIrFid0/sRiSXdwrODzCCLe1ITdle8jCGAggObO qjbAV7R7Zja4zlhsKEZC/W8QUffCYh10axAx8Ds4kSt0xHu8WjJ9yaVYeJt7kNG3rg/BzjpjrIMU eInaGtUYDRB30JsCsU1QoZLcaBNKDB2dTGEWH8brak+Gw8E0vymIlJKMRuPjKWmBDYYxKd2MKTN/ MSbTjik9GdMnaMViw2IH6FO6bfqTePiSkgeU/Y10dEly/9cUvvTjUWEp17oJSj8DBEin4UZwY7O2 YkT3GhNO/pYuZ5B+BUDwVCMwn0r5ucF3gXcILXQ14bJblok3EfQXiy3FWhaI+xGn3jq2q2YhM2JQ kNrwxLk2ji/aVz1jfnUrcs1gWa3fOuuROFqFvHETBFAX3mQBSDdgtPZ++6W3BOvVi1+l56M2Oe7S 5PL4k3PjVwlPM/0/LDUn4//CGpLixv7AQn2ztmF/TVAjXfY9SXLv1BMHzFDadrY9L4JD/xZUHbWA HWi8xaXC8ANyja5AQqR64FnJmuB93Cd0gtQhA3hgtDmHXMe0k45boy72XZ2lnTLcJeYfaPfG6zjt Hp/7rvv949Y0/HUNmmuXHZZwZpcFV8r1OSzFTYZPjYvqSXy4nQS2e+XnmdF2fXfItQp1IIP9ZgfG aFsfN1bz1LqTxk7KiPwRYADbpGs9CmVuZHN0cmVhbQplbmRvYmoKMTEgMCBvYmoKPDwvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCAyNTc0L04gMz4+c3RyZWFtCkiJnJZ5VFN3Fsd/b8mekJWww2MN W4CwBpA1bGGRHQRRCEkIARJCSNgFQUQFFEVEhKqVMtZtdEZPRZ0urmOtDtZ96tID9TDq6Di0FteO nRc4R51OZ6bT7x/v9zn3d+/v3d+9953zAKAnpaq11TALAI3WoM9KjMUWFRRipAkAAwogAhEAMnmt Li07IQfgksZLsFrcCfyLnl4HkGm9IkzKwDDw/4kt1+kNAEAZOAcolLVynDtxrqo36Ez2GZx5pZUm hlET6/EEcbY0sWqeved85jnaxAqNVoGzKWedQqMw8WmcV9cZlTgjqTh31amV9ThfxdmlyqhR4/zc FKtRymoBQOkmu0EpL8fZD2e6PidLgvMCAMh01Ttc+g4blA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp 66uUBoMwQyavlOkVmKRao5NpGwGYv/OcOKbaYniRg0WhwcFCfx/RO4X6r5u/UKbeztOTzLmeQfwL b20/51c9CoB4Fq/N+re20i0AjK8EwPLmW5vL+wAw8b4dvvjOffimeSk3GHRhvr719fU+aqXcx1TQ N/qfDr9A77zPx3Tcm/JgccoymbHKgJnqJq+uqjbqsVqdTK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOn TK1V4e3WKtQGdbUWU2v/UxN/ZdhPND/XuLhjrwGv2AewLvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA1 3+He/NzPCfr3U+E+06NWrZqLk2TlYHKjvm5+z/RZAgKgAibgAStgD5yBOxACfxACwkE0iAfJIB3k gAKwFMhBOdAAPagHLaAddIEesB5sAsNgOxgDu8F+cBCMg4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8g CCJBDIgLWUEOkCvkBflDYigSiodSoSyoACqBVJAWMkIt0AqoB+qHhqEd0G7o99BR6AR0DroEfQVN QQ+g76CXMALTYR5sB7vBvrAYjoFT4Bx4CayCa+AmuBNeBw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJH HBEhIkYkSDpSiJQheqQV6UYGkVFkP3IMOYtcQSaRR8gLlIhyUQwVouFoEpqLytEatBXtRYfRXehh 9DR6BZ1CZ9DXBAbBluBFCCNICYsIKkI9oYswSNhJ+IhwhnCNME14SiQS+UQBMYSYRCwgVhCbib3E rcQDxOPES8S7xFkSiWRF8iJFkNJJMpKB1EXaQtpH+ox0mTRNek6mkR3I/uQEciFZS+4gD5L3kD8l XybfI7+isCiulDBKOkVBaaT0UcYoxygXKdOUV1Q2VUCNoOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS 1LTltCHa72if06ZoL+gcuiddQi+iG+nr6B/Sj9O/oj9hMBhujGhGIcPAWMfYzTjF+Jrx3Ixr5mMm NVOYtZmNmB02u2z2mElhujJjmEuZTcxB5iHmReYjFoXlxpKwZKxW1gjrKOsGa5bNZYvY6WwNu5e9 h32OfZ9D4rhx4jkKTifnA84pzl0uwnXmSrhy7gruGPcMd5pH5Al4Ul4Fr4f3W94Eb8acYx5onmfe YD5i/on5JB/hu/Gl/Cp+H/8g/zr/pYWdRYyF0mKNxX6LyxbPLG0soy2Vlt2WByyvWb60wqzirSqt NliNW92xRq09rTOt6623WZ+xfmTDswm3kdt02xy0uWkL23raZtk2235ge8F21s7eLtFOZ7fF7pTd I3u+fbR9hf2A/af2Dxy4DpEOaocBh88c/oqZYzFYFTaEncZmHG0dkxyNjjscJxxfOQmccp06nA44 3XGmOoudy5wHnE86z7g4uKS5tLjsdbnpSnEVu5a7bnY96/rMTeCW77bKbdztvsBSIBU0CfYKbrsz 3KPca9xH3a96ED3EHpUeWz2+9IQ9gzzLPUc8L3rBXsFeaq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc 8uH7pPp0+Iz7PPZ18S303eB71ve1X5Bfld+Y3y0RR5Qs6hAdE33n7+kv9x/xvxrACEgIaAs4EvBt oFegMnBb4J+DuEFpQauCTgb9IzgkWB+8P/hBiEtISch7ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGG sINhfw8XhleG7wm/v0CwQLlgbMHdCKcIWcSOiMlILLIk8v3IySjHKFnUaNQ30c7Riuid0fdiPGIq YvbFPI71i9XHfhT7TBImWSY5HofEJcZ1x03Ec+Jz44fjv05wSlAl7E2YSQxKbE48nkRISknakHRD aieVS3dLZ5JDkpcln06hp2SnDKd8k+qZqk89lganJadtTLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMm MTMjcyTzL1mirJass9nc7OLsPdlPc2Jz+nJu5brnGnNP5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF 6oIjhaTCvMKdhbOL4xdvWjxdFFTUVXR9iWBJw5JzS62XVi39pJhZLCs+VEIoyS/ZU/KDLF02Kpst lZa+Vzojl8g3yx8qohUDigfKCGW/8l5ZRFl/2X1VhGqj6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoP K3+syq86oCFrSjRHtRxtpfZ0tX11Q/UlnZeuSzdZE1azqWZGn6LfWQvVLqk9YuDhP1MXjO7Glcap usi6kbrn9Xn1hxrYDdqGC42ejWsa7zUlNP2mGW2WN59scWxpb5laFrNsRyvUWtp6ss25rbNtenni 8l3t1PbK9j91+HX0d3y/In/FsU67zuWdd1cmrtzbZdal77qxKnzV9tXoavXqiTUBa7ased2t6P6i x69nsOeHXnnvF2tFa4fW/riubN1EX3DftvXE9dr11zdEbdjVz+5v6r+7MW3j4QFsoHvg+03Fm84N Bg5u30zdbNw8OZT6TwCkAVv+mLiZJJmQmfyaaJrVm0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg 2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1E rbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6 tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9 yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW 2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE 5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1 UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf//AgwA94Tz+wplbmRzdHJlYW0K ZW5kb2JqCjEwIDAgb2JqClsvSUNDQmFzZWQgMTEgMCBSXQplbmRvYmoKMTMgMCBvYmoKPDwvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMTYvTiAxPj5zdHJlYW0KSIliYGCc4eji5MokwMCQm1dS 5B7kGBkRGaXAfp6BjYGZAQwSk4sLHAMCfEDsvPy8VAYM8O0aAyOIvqwLMgtTHi9gTS4oKgHSB4DY KCW1OBlIfwHizPKSAqA4YwKQLZKUDWaD1IlkhwQ5A9kdQDZfSWoFSIzBOb+gsigzPaNEwdDS0lLB MSU/KVUhuLK4JDW3WMEzLzm/qCC/KLEkNQWoFmoHCPC7FyVWKrgn5uYmKhjpGZHociIAKCwhrM8h 4DBiFDuPEEOA5NKiMiiTkcmYgQEgwABJxjgvCmVuZHN0cmVhbQplbmRvYmoKMTIgMCBvYmoKWy9J Q0NCYXNlZCAxMyAwIFJdCmVuZG9iagoxOCAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDExPj5zdHJlYW0KSIlqAAgwAACBAIEKZW5kc3RyZWFtCmVuZG9iagoxOSAwIG9iago8PC9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMyOTcvTGVuZ3RoMSA2MTkyPj5zdHJlYW0KSInEVn1Q VNcVP+fe97G7YPhG69r41heIkV0R0WrQIpHdVaBGENRdjXWXDwMKStBh1Fhnrbbqg3TacZM2NmlI KqlfZN6KSTFjG0uLoWMb64yZSUar/SBjJs1mkqnUtplAz30LVDNj/+377Xnv3HN+79xzzr1v9gIC QBJEgMOcldX5cwsuDhlkOU+ypq59h/Za/okTAJgOIBdtan2y5Te3F5kAyjcApI1PNu/aFN3u3grg OEX8/saGcP1vD26qoYAtNP5aIxnSMxzfo/FPafxQY8uOnWVLjcM0fhuAH2reVheetnLaSoAUErzY Et7ZytcoswDSsoivbQ23NJidRT+i8Xzi/6y1raF15dsPbwTIvE7jGkD1Qfw+yJTLO9I7ZMkef0I9 15KF4z7XimpNg5JPtU9HlTw8BgVqAZqR+7L/z9eV+3oKCHUYYPvYOtJ+DLV0P0pST/I8RCHKehMc KCQxSSuHW/IgzIU2y14Ie+juhX/icfiuZVkMteSvJfYAPYvJV0dPtGJEsdN6fgsOUOzPWC/rZ/2W dwnFLReMBFivPEh2EW8/vAY38AJxnoYj5DsHV8RbFDkKPXAHZxI68AOMs0qyopif4mwhdpTy/SW8 D3/HTCxGA88TJ53ts3JJzBYhzgDhihVFYAU24zZsw8MUc4hxNp+ibmOHWBczWT8PSsXyoJKuLFCb KQoCoz2fRhWKaI9DNc1cC09NRE3gD8iwCmuwEZ/DLsphAOOE28zDllDXBZ7lISlZ+lDeIr9CGFRW qy/aFIotgwJTQYMcmEdV+WiOKsq5HjbDbgtPE/ZQL78NL0EXvAwnIAZvwq/EnHANbsAd6k4KQdS1 AB/FtYQgoQ334gHqR8ddeAZfwF58k/K7hO+y6VR1As1UfSLL/ewoO8susd+xm2yIfcQ+48DtfCOv 5dt5Nz/JL/PL0nKpS3pZui5dl1E2rU6lK5nKBqWD0Kna1S3qAfUH6ovqG47ZMJnqclNd5bCWqtpF leyBQ2BYqxYjnIXXCYPwkaiDMDpWicCj6EU/riYEcR2GsAW3486Jio7hq3gcz1It7xLew2v4Z/wb fmLhDlNYNsubqK+SVbO1bAt7jj3PXmCnaEf2svPsPXaDahxiw1RjEk/nWfxB7uN+Qg1fz3fy/byH 9/NrPE7rlix9XSqWVksbqPaL0pD0Ia0kk7mcI8+XiwiN8lZ5r9wh/4R2dFyOK8lWV9KVDGWRclB5 SelV3le+ULPUbHUGYbZaoFarzWq7elIdUm/ZTtsfszfZ2xxuOAlz4Odf+npfp939a7ZByYepeI12 w1M8hVia+PZYstpsb2K9Iju1GmfSSv0R7nA7VEgXYS1fD81yLU9SP4bjuF3ah6e4H05Dt9qO53mI x3m3nKMsSvSTHeUn1V1qSL1Fmd7mR+RGdTY+JnfgcbaEvug2rIJ/4DB8k2bewWbBRTgMh7AdbBC1 ncZJ9K0NsOnYIb/Cz0hd3CfvxUdoBZ3yIP8OzIcsSIaZMIP2ugyZIJcsWLhgXuHcgjn5sz3uvFmP zHw4N+chfYZLm/7gV6c5p35lyuTsrMyM9LTUlAcmJSc57DZVkSXOENw+3R/SzNyQKeXqy5d7xFgP kyF8lyFkamTy38sxtZBF0+5llhBz05eYJQlmyQQTU7XFsNjj1ny6Zv7eq2t9uK4qQPozXj2omXFL X2HpUq41mEQDl4ve0HxTGr2aiSHNZ/rbGw1fyEvxYkmOUr20weFxQ8yRRGoSaaZfb42hvxgthfl9 RTEGtkmUlVmue31mme4VKZg8xxeuNyurAj6v0+UKetwmltbptSboS82UPIsCpdY0plJqqtY0WpMo Bzq0mPuC0dmXCrWhvOR6vT78RMDk4aCYIy3PXKZ7zWW7h6Z43H34ak3AtJf2IdQEzkH5aCRWFvF6 g2K29NLAQYs+meiTdw85ueGb0qSJoWEc1MyuqsDdXpe4B4MU1OOuWBVwUda6r1MTZawKWBVQUJyS T0kKmygzUXCD7hOW0GbNtOtL9UZjc4gWa6phwqpdrjNTy0vOjf4Jyn2aURPQXeYSpx4Me6fFMsFY tau3rEQru9fjccdS0xKdjj2QMqYkT7pbaZjwWZpFFxplPd5qFBnpZbRFTK1Oo0wCuslyFopbw0Iw 6hYSja4gUkebqH8hI7VILISck6prxjDQRtDjH99rCY9ZlJzUYRCq2C4TW47847qZl2fOmiV2ilpK S0uZFVvj+R53u1mht6ZqZgW1DCoD9FKwKJ9a7nKJVe7oK4FaGpiRqkBirEGt8wyU5OcFTRYSngvj nqzVwhMZ90y8HtJpO58FcQjMMm25E7+U1OwMX2ORidn/w92Q8NPn49NikpxjVAZyw0aHMzdkdAZp afz0KRqGX9f8RsgI941GanUtVTdiFRVGqy80XlLf6IUOp1nSGWxEaqpZmOiGmVEa4E4WTGjMyYMe +lON0OEuQkcLDiroJSnqVZSuIp0tpVGQR/k5/AAgfySeGocln9C9YE5hmistx5XminD4IsJgBOTB fy+MSIN02qTjR1R+XJ5Hh9/MXwBnnWAHBT+nAHH6FczJmAeFcyErE/QZ0IPrh4fxiZFjw8Mj3Wxo GNePdAsV14/FWUFxuIiDFIdyvCvOAkqhR+qKSl2fh6xGsghUnOmftjFl8bDNabP+Cbp7joyIZ+yS ehVgpNJxUy2gYbLFF7mCWjBSScdmCj562XFzzP7f6y8SiN7QwZxExLQVQ7l9JkQdTSQXoFzNhaj9 PPTwkzBgOw09KhVlTxmTjQlJOkjSCT22AehxvAU98g8TIrjSNpIr5KNjm/oslNu6KOYB0l0JvyVC X0Z2EqkXepQAvd+QEPVwQqT6hAi+8hasGRfbX4m3nGyXaI43yO8kSSLbPLLto2cWRJUyiI7PJf9r TAZJKOf/kF9+MW1VcRz/nbbrPTAEhow0onIR44MMBBYcZG62RbeyZhnSJvxxyVbaUpp13Oa2QMjM XhYiUTFXTXxzbJk60LF1wz9s8cFEp77uwRmdD8b46Isvvvgwv+f+7rq1IkqiD8befPr9nd/5nd/5 c29P7/E+D/92ZxyP81gq/MiFcWvIJ69CMT9tBryG8k7oJM9VzqH9Hug4rVa20rwHa6e40xfW80AZ PSWcQMyJsrX4h8GL74p7meds91POIvNXcR4V99O9MaLWqbsBu2bd3DZirMz34p/H/j3kWBk40Eh+ fjs3otKL59PL99y+76V5vynaNx2csre7FPkSU6z/rZSi/wW6rlD32LYD0Htw36K4ezvF5X683hM9 9j+8Dqxzxf7Dl9pffxRV9AQtUDX+d2ph9WIj/tlzxD46qr35zeIunOU9Wm385EOJbQ/secf2wj7j 2BoyrSGSPBUo/UC/OLagDnHDsV1Ujdditt3U4apxbA/spx3bC9twbI1M12KfkZ0106mJvL6sd/b2 drXhq1s/mI6bRs4Yz+t9hplt1wOZjD6oonL6YDKXNKeTiXZu0KEadOrR2WxSjxiZqXzamMzt0Psn 4+u3CkZGQ8Gh1qH0ZCoBcm2DydRUJmZu1h+dSOpwJoyZnJ4xUoaezuFNP2/GEsnjMfOYboyXTcIw Y2ps7dRHBpZ7lkxKU4omKI/T0zLoxBL3Uhe1OVY3fAcRE0ekQTkwbseq9iYytMMOUAaXToPFXDm7 lIQmETWN74QdebeHjmIPnfBFMZIsonSKIG+GppAjDWsSGXbA2w8rvqm+gsg0SiHoELWCNDKkUMOa Q++qTQo9ZfDQmmWlzbb+t+OjmKlaHY5MYGVm7HlnYKWADr8qx0Ae8THEJOm43fYYfOqubXwfDbvV nVVv91fRvn34jdVtk/6QvuZ68kqoC3LKFnGB5X2WZZYllvMs51jOsiyy9LOEWPazBFn8LHtZnmLp ZfGyeFjcLMJ/CPo9uAW+AzfBZ+Aj8CG4BFbABbAEzoNFcBq8BV4Bp0AcHLFzXuLUKyzvsbzL8g7L 2yynWZ5hCbDsYelh0Vi2sLhYyO+Hfgu+Bl+BL8EX4Dr4GHwAVsFFcAa8DmZBItRVX1FfsctaE9P+ fs06q1lvaNaCZhmaldGscc1KatZhzRrVrBHNGtYelY9IXT4sH5QPSJ9skPWyTtbKalklK6WUXumR LokXhsL97rArHAmKcOHTOIXH9MKvkZY1UfncaGFLS1AU6sIUjgZ9hZ7Wgmse448Or4nbl4V4da5R HXyvkhC35xYaHR0ZoYbWP358JaXwwOwn1CR2Ye9tEjtXtabPNeWNwGvZXkt5LdvrE1cGqCsce/no Q7RO4rsfsWFtSeSzaTXdgeHLkoIjfYdZV11bKzGfo43NI8GG2uxee3K7m30nG695SCzRVpz/qlqC hfuAqmoLtAVUFY4Pqqoa7hqnyndyd3PjNbHkVNXCvQ1L+bsAAwB1G4bNCmVuZHN0cmVhbQplbmRv YmoKMTcgMCBvYmoKPDwvQ0lEU2V0IDE4IDAgUi9YSGVpZ2h0IDcyMy9UeXBlL0ZvbnREZXNjcmlw dG9yL0NhcEhlaWdodCA3NTQvRmxhZ3MgNC9Gb250U3RyZXRjaC9Ob3JtYWwvRGVzY2VudCAtMjEx L0ZvbnRCQm94WzAgLTIxMSAxMzU5IDg5OV0vU3RlbVYgNTgwL0ZvbnRGYW1pbHkoV2luZ2Rpbmdz KS9Gb250TmFtZS9CU1pIQlcrV2luZ2RpbmdzLVJlZ3VsYXIvRm9udEZpbGUyIDE5IDAgUi9Bc2Nl bnQgODk5L0ZvbnRXZWlnaHQgNDAwL0l0YWxpY0FuZ2xlIDA+PgplbmRvYmoKMjAgMCBvYmoKPDwv T3JkZXJpbmcoSWRlbnRpdHkpL1N1cHBsZW1lbnQgMC9SZWdpc3RyeShBZG9iZSk+PgplbmRvYmoK MTYgMCBvYmoKPDwvVHlwZS9Gb250L0RXIDEwMDAvQ0lEU3lzdGVtSW5mbyAyMCAwIFIvRm9udERl c2NyaXB0b3IgMTcgMCBSL0Jhc2VGb250L0JTWkhCVytXaW5nZGluZ3MtUmVndWxhci9DSURUb0dJ RE1hcC9JZGVudGl0eS9TdWJ0eXBlL0NJREZvbnRUeXBlMi9XWzEyMls3NDddIDEzMls3NDddXT4+ CmVuZG9iagoxNSAwIG9iagpbMTYgMCBSXQplbmRvYmoKMjEgMCBvYmoKPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCAyMzg+PnN0cmVhbQpIiVyQwWrDMAyG734KHdtDcRrKtkMIlGyDHLqNZXsA x1ZSw2IbxTnk7Sc7pYMJbPjR/4lfkk373DobQX6Q1x1GGKwzhLNfSCP0OFonjiUYq+NN5V9PKgjJ cLfOEafWDV5UFchPbs6RVtidje9xL+Q7GSTrRth9N90eZLeE8IMTuggF1DUYHHjQRYU3NSHIjB1a w30b1wMzf46vNSCUWR+3MNobnIPSSMqNKKqCq4bqlasW6My/frlR/aCvipL78ZzcxUNTJ/V02tRL Zm+uNIWXhXtEvRBxunyRHCsFsg7vRws+AFPpiV8BBgBJKHKvCmVuZHN0cmVhbQplbmRvYmoKMTQg MCBvYmoKPDwvVHlwZS9Gb250L0Rlc2NlbmRhbnRGb250cyAxNSAwIFIvVG9Vbmljb2RlIDIxIDAg Ui9CYXNlRm9udC9CU1pIQlcrV2luZ2RpbmdzLVJlZ3VsYXIvU3VidHlwZS9UeXBlMC9FbmNvZGlu Zy9JZGVudGl0eS1IPj4KZW5kb2JqCjIzIDAgb2JqCjw8L0NhcEhlaWdodCA3MTYvVHlwZS9Gb250 RGVzY3JpcHRvci9YSGVpZ2h0IDUxOS9GbGFncyAzMi9Gb250U3RyZXRjaC9Ob3JtYWwvRGVzY2Vu dCAtMzI1L0ZvbnRCQm94Wy02NjUgLTMyNSAyMDAwIDEwMDZdL1N0ZW1WIDg4L0ZvbnRGYW1pbHko QXJpYWwpL0ZvbnROYW1lL0FyaWFsL0FzY2VudCAxMDA2L0ZvbnRXZWlnaHQgNDAwL0l0YWxpY0Fu Z2xlIDA+PgplbmRvYmoKMjIgMCBvYmoKPDwvRmlyc3RDaGFyIDAvVHlwZS9Gb250L0ZvbnREZXNj cmlwdG9yIDIzIDAgUi9CYXNlRm9udC9BcmlhbE1UL1N1YnR5cGUvVHJ1ZVR5cGUvRW5jb2Rpbmcv V2luQW5zaUVuY29kaW5nL0xhc3RDaGFyIDI1NS9XaWR0aHNbNzUwIDc1MCA3NTAgNzUwIDc1MCA3 NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1 MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCAyNzggMjc4 IDM1NSA1NTYgNTU2IDg4OSA2NjcgMTkxIDMzMyAzMzMgMzg5IDU4NCAyNzggMzMzIDI3OCAyNzgg NTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggNTg0IDU4NCA1 ODQgNTU2IDEwMTUgNjY3IDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTAwIDY2NyA1 NTYgODMzIDcyMiA3NzggNjY3IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYx MSAyNzggMjc4IDI3OCA0NjkgNTU2IDMzMyA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2 IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgNTU2IDMzMyA1MDAgMjc4IDU1NiA1MDAg NzIyIDUwMCA1MDAgNTAwIDMzNCAyNjAgMzM0IDU4NCAzNTAgNTU2IDM1MCAyMjIgNTU2IDMzMyAx MDAwIDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDM1MCA2MTEgMzUwIDM1MCAyMjIgMjIy IDMzMyAzMzMgMzUwIDU1NiAxMDAwIDMzMyAxMDAwIDUwMCAzMzMgOTQ0IDM1MCA1MDAgNjY3IDI3 OCAzMzMgNTU2IDU1NiA1NTYgNTU2IDI2MCA1NTYgMzMzIDczNyAzNzAgNTU2IDU4NCAzMzMgNzM3 IDU1MiA0MDAgNTQ5IDMzMyAzMzMgMzMzIDU3NiA1MzcgMjc4IDMzMyAzMzMgMzY1IDU1NiA4MzQg ODM0IDgzNCA2MTEgNjY3IDY2NyA2NjcgNjY3IDY2NyA2NjcgMTAwMCA3MjIgNjY3IDY2NyA2Njcg NjY3IDI3OCAyNzggMjc4IDI3OCA3MjIgNzIyIDc3OCA3NzggNzc4IDc3OCA3NzggNTg0IDc3OCA3 MjIgNzIyIDcyMiA3MjIgNjY3IDY2NyA2MTEgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgODg5IDUw MCA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAyNzggMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2 IDU1NiA1NDkgNjExIDU1NiA1NTYgNTU2IDU1NiA1MDAgNTU2IDUwMF0+PgplbmRvYmoKMjUgMCBv YmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyNjY+PnN0cmVhbQpIiVyQzWrDMAzH734K HdtDsRPG0kIIlK6DHPbBsj1AYiuZYbGN4xzy9pPt0sEEtn5C+tuS+KV9ao0OwN+9lR0GGLVRHhe7 eokw4KQNK0pQWoZblG45945xEnfbEnBuzWhZXQP/oOQS/Aa7s7ID7hl/8wq9NhPsvi7dHni3OveD M5oAApoGFI700EvvXvsZgSfZoVWU12E7kOav4nNzCGWKi9yMtAoX10v0vZmQ1YKsgfqZrGFo1L98 lVXDKL97z+rHgmqFIEdcZa4iHzMfI58ynyJfM1+Jq4fE5IhzTRVrhChFisjFDm5/xV5oZXAfVK7e 04xpr2m4OJY2eF+9sw5IFQ/7FWAAIcyAFgplbmRzdHJlYW0KZW5kb2JqCjI3IDAgb2JqCjw8L0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTA1MTYvTGVuZ3RoMSAyMzQ0MD4+c3RyZWFtCkiJ1JZp VFXXGYbfb7iAKLMoolzOvSKiIA44gCMqKooKivOEjGIVJYCKShRRSeKIoolTiTapTVKjtjWKiXOM iSYaTYd0raZpBfunK5pUk2XrwO2+V2qGH+nqz+61zjn7+84++z3Dfp/vgAD4oRKCjPTM7r0WLihZ ZzKfmW1ublF2cf2tsrkADQR8PstdWmYd23PtJOAbBtj8C4rnFR34+7BDQEA00CJk3sLlBfaUw1lA WJKJDxbmZ+c1xJ2fDDj+YubrW2gSAanBNYAz1MRRhUVl5dErZu01sRkftG7h4txs2HeeAhJOm/j5 ouzyYv+rosCIEWa8tSi7KP9vPPSwifPd+sWLS8tK10Z8DowpdZ8vLskvzr97McrEtUDgY4jaqAY2 +Nh22xLMU9ifHOU6qhk+4AAbM6sv637wl8mwVqK5jcu0LBCsh+qFJtBF7zqOtoCX3efktC3IrWbe GMAgzwWtTWR6bIcX+7oThOYz3zYyo9nTY/x4e3KlyBh5SU7Ia5oku+RFWSWrZYsOkslSItNkoXwh t+WOfClfyT/krtyTr+UbmSpTNEWH6ggZJ3uhCEIwwtAB0eiMOHRHfwzEYKRgBNIwFdMxA3OQh0KU ogzLsQKrpVKKZY3skBV0m5gCKJDCyU4xlEEzaDbNp4W0mJbQUnqWXqCNtIlqaA+9RefoPF2i9+kj qZJFslZ2mvtvgVZoCztSkYEiUhKykTd5kS+FkkWR5KCOlEVzaC7l0HJaTauokqpoDZ2g41RPb8tW eUXekEOyTVbKdtol+6VODtBd9tZhCMAkHasjdZSmyhGdqON0kmbyRh1P1+mGTiA/qpbxkqajNV3e 1OGaIYUyX6abr2RWA9IxhZ6XMlkqcyRLZshMTdbJ9CFWaYwclDzJp3gaJTVSITmSq/3hjUh4wYEI 9EQv9EYPjMN484Rj8RMswHwqoPtmIflxMEdxW+7KkRxHj6BeZ8yYCiQbzYFYZZ5wO7m4Pb/Pl/nP ouIjrSRYQiVGUmSJ+bobZJMckGuapbm6RLfZ19vvWYFWqBVu2S2nFW31sPpbg6wUq9jaYh1y2Bwh jrYOy+F0RDviHVmO3U52ejkDnMHOcKfdGetMdc515ne68lBdLs9q3W/UH3AYXzLqfxSIl/h61KON eplRX2fUt8grCs3REq2xV9rvGvUQK8zqYFke9aRm9bJm9TZP1TMdNc3qQc52T9XzjDo86uD2Txa2 K+U/S9wV0fSF2U93xbs6Ak31P7RAY87TXsIt38bYxpDGW43VQMODhqONieZY1bDaZDu4RzSkNYxp 8MzcEN/Q8ebDmw03Gz/f6PFRBZmx/DU3uSli3rm/tJFwj7nCn8wuhmTilFSp01k6R/O0QIsBLdYy LdeK796RljUff/Y0s0+PNffO6YXvja3/v/evSJrHfa/KEVks29hb6ui6FOpoc/f72c+slJHyT/kX 3dWJsl0quKvcpxsyX+O0q/aS8WbNexnf+HgoEGA4EGFIEGk81KPZQ+0NF8Z6fJSODB2CSZjvcVOR ccw02mVooYYXXoYYvsbNoYYXlocYcwwz3MSIMMxwe6rSEKNKk6naUOOEmxt0mTYYL/uSD1pSC/hT K4RQEFpTMNpQa4RSCNpRe4RTBzgpCh2pE6IoGp2oMyxyIoYmoAtNRFfKRCxNQjeaiXiahQTKRh/K RV/KQyLlox8VIInmYQAtwCAqokUYQsUYSiVIpmcwnMowjEoxkpZhNK3AKCqnlRhDFZhAazGR1iGT 1rsphJm0GbNpK2bRFmTRNsyl7cihHcimWhTQPuTTXsyjn2IhncQiegeL6RSK6TSeoTMoobNYRhfx LF3BKlTSVVTRx1hD12g3/KglAskfk+k55NJO91x0nx41MyrO8CqSvqJvDBNsHMihHMMtOZydhlDx HMvdeA/v455cx305iQfyGM7gKu7BvTiBe3Mf7seJ3J8H8GAewsk8lIfxcB7BI3kUp/JoHsvjeDyn 8yBO41JezhVcybVcwmW8lJdxOa/glfwsr+a1vI7XczU/xy/wRt7EW3gzb+Ua3sEv8ku8i9fwdt7A 23g3H+I3+ff8Gn/CF/g3fIzf4pN8iv/AJ/jX/B5f4Vf553yQf8Fv8C/5MB/ho/wrPs71/Da/w6f5 LJ/j8/wuXzTs/cDw70P+iK/yNf6Yr/MN/i3/zpDYTwIkUFobPrSTcGkvHcQhHaWT4WOMdJU46Sbd paf0lj7SVxIlSfrLABkog2SwJMtQaSthMkyCZIjEi10ixZIo6SzDDVkipJf0408lhc9IF74kCfy6 BGMJXcBSehfl9B5W0geeWlTurkSm4rhrUq6pfjWm7j2Qh/JIHkuTuAyZSVlFlf6qNvVSb/XRFuqr LbWV+qm/BmigBmmwhshxeVljtYd2056aoH00Xvtqd+2t/TRRu+gUnaZTdbqhXZbO1BmGe7NN9Rws FZpOse7KR4mUBnjXGS7Xfg/KGcahpeZfsRLV2IxanMWfkIO1prcb+3EQr+MozuMyPv0v/zf/U2ta bitCKzlheBJiKsYD1+2mg2art/l/J1NrohC1vs24Al13fpC701TrCmyq9wqGr+daP/7EZO/RY9eD fzNe5cFtnFX87a6kXUm2LB+xHWsar/JFqhPZVhwnvmOr1hEfuWQ7sJujlXzFZkpjSklD2zQmHA5K eodSCrSUwoQp0HxKGiqHQkIodIYSoMAEpkNCmOkMMIP+oENngJKY9327ki1PyqDZb/e93zu+9733 9kkSexi/0MJ4cQ7pEm7xd/m5m6dvnioIZwCn1gjsgg/x+bvDmF8Qx0m2D+6CJIzhPJ6ASdiPU9mY aHfjTLsH1yQcgBn4GNzLp/Un4CDS95mIwR/iM/yw+XwQJ+FhpB5CmlEPwxHM/Kfyz6P55yLyafgs rs/g/XMwB8fg8/hk90KskEvBcTiB9XwUHsvTj90SZfTj8AVcT8CTWPWTSD+DtX8Wvgxf4ehT8DR8 kXPPw9dR/nSBLpMt6n8VnkOtr8ELqPkids+pZbpM83l4DX6APfVT+CF22wWkLsE80pfgj3Ad3oE/ w1/gr9i1LcIWeBf+Ab/E7E9i1lnOZ/h9Gu/78xm/H3Oby+zDmLHCPBw0ZUY+j/I85WT3o+YcVuPo EpsUr1POF9PO+VqaL3YmdqJFzDjhU3lk8dyFVobe0pwVZvBZjhRKl2d2Kf3CB0pehG/i+gbeWR2W cznqW/iGs/USfBu+g5RxX+Rz1HfhZTiNsyANZ+EcfA9ehUyefwW5RfkZjuR0bo2fh+/zLrgAF3n9 fwyvc+wCUvOm9IIpOc/pS/AGTqE34edwGX6CvfMGX2/CL7A/3oJf49T6A1wzO+gK7yAiBOBX8JbF D7+3ugSrdBEuidvhEPK/E78ET4Zid925b++e3bq2a2R4KL5zx/ZtWwcH+vu2xKKRcO8doZ7uzV2d He1trS2bgo0N9XV+3xqyura6otRdUux02BXZZrVIogD1URJLqNSfoBY/6etrYDxJIpBcAiSoilCs UIeqCa6mFmqGUHNymWbI0AzlNQW32gVdDfVqlKj0coSoGWF3XEP6kQjRVZrl9DZOW/ycKUbG60UL NVo9FVGpkFCjNHZwKhVNRNBf2ukIk/CEo6Ee0g4nkk6kaB2ZSQt13QInxLpoR1oEpZhtSyVfNDlO d8a1aMTj9eocgzD3RW1hKnNf6jSLGY6r6fqLqRMZN4wmAkXjZDy5V6NSEo1SUjSVmqOlAbqWROja B96pxiNP0HoSidIAQWeDQ/kNBGr1uYmaeg8weJL9WyGSNBGbz/0eMJIdMZ8mlOdowNgwQjyf18ti OZ4JwSgydDauGbwKo54zEAoGdCommORiTrJiF5PM5iR58wTxslJFE+Z1cKqazo6qDfWYfX758EK5 SiV/YnRsij2TEykSiRh5G9FoKIJEKGmeNZpeH0T9ZAIPMc3SENdokMzQCtJrKCCgshpMD2vcxDSj FWEKiTHTigajERaXGk0lIkaAzBeJa/PQvHA9vVH1nG3GH+46i4NWhrEo/mhKG5+ktQnPOPbnpKp5 vDSkY/p0ok3orErETddex+28fEduhWdbpp1TZieXfYqqiR5JZ9VCQI3hjfR2ocCN5eIsq2hvl6rh r/icGu5iajCqwA8yki/cx0QSMw33eby61/j8j5A8ZkxWH1WW+HIjkI/J2OcDQzO0WUBr1ehEZEmA BU6tZoCmt1vHKbJcmBujhcLK2ZcTST58cxET0Q2HWBWrVQo7VY1MEJ1gD4V2auxsLNe8voPDZDC+ W+PVNrtkpIAz5G0GR8GL4hwjhrEHYwFPrqyc38L5PNu3TNyfE6sphQwOp5hzYjoEFd8gPLTN3588 3la2EV/NGE43EksS1a3GUsnMwuxoKh0KpWaiiakO5oP0j6fIsNbl4bEOaYc9D7CtymBQGBzpbajH 2dObJsKxeDokHBverc27AdRjI9oZURDDiV49vQZl2rwKEOKoyFAGMkZlDPM0hIzC9T3zIYBZLrVw gPNjGQE4puQwAcYyooG5c5iImMXAQhxjHyxS9RSmGMdtVB1n5XlIn0oldPZyQSWWEi+BCqQbqEi6 04JoK6IOMtFLnaSX4T0M7zFwG8NlbAyhUsDksJmUShCcU9hQGngEoxUl5lLNLCyMaN7LnqzuxVbb i2u3Ru0BnP1W3wDqbWErgfAWOjuWZHHALo3Zyr7+MR3bNucQVfqpHT3YTQ+oEeM2rB3RaAxrgwXk 9rPI0Fmd6gG2qTat83Z2U+gjHVh2w6fVzzYK6qkysoG/m/gqOHxz7GHH2GBYMxAPsriZbiRJLsLI xwiKxhIqZtsCY8PY6sYsdXgMZAJHosU/wZfDYwqBHUvyOYsd1N6IDvFitLORvZJWn6zrRvCcmzMV cG83dWJE/iWpNA0wOyjqZ7HgNYehMtUfMTfxDAyRQzhZWNDck4xiWuzrT+LwN+ydiJC2nLHCZoTT 9PG6gcrs5EWYd8k3klk4RT7pXfJpqCfsy4E1JnjmsbFBTy0H6J5AQ72yHC3mcCqlFN/awMiXUpx/ IghW/Gv2celt/CslgQyd/C/RjnMNlQ2VStcdDiEL/SAL49j8qnACFBCE8VCZRfS12qS4p7h0Ji7E I7I4Aj1Xr13dd+3qZXxeFoJXs1ey7htXsmXt7cFg03qh1FvKV4VLlGWbjaxuFFtbW1qamzd0i5s2 NopktQuXf9PGbrG1W2resErkqoYmR1GZodLb/9kj7bhhEx+sjd6zfY1Y63FVFFkF1VpbpWze0Vhe 4t1UVxcK1soOm2hVbMrajsjqyJ0dNTfPSbJTdqiVlTUuq0UuUuzqyvKVLsvNmNX173etrvfDlrvf Pyk1bdw/1GJ9xqGIFpvtNU+VrzPmXRlQy0vK3UUua3llmU0uL3P6Nw/cOK5U1VTJDodc5HbYq6sr FbvDVuS+0YaJii9kpT9JPwM/ZvOR8+IRcRa0AL7h4V3aWfttyqqMcPoV/+3+TiUjvPwqlPiFcsnf lBFXharKwd55+21+m+TtX/evmoGWf4Zc26StdYHqnp6abdmebE9ZVbsQzP4Wf8VezTaXNruzpe3t Tes9ocr/w7Bpve7Lpd4lmYm1NG+orDKTK8t+PxbCsqJilcgK0yrVW9asq6hxo9viyL57O3dOd1et CA5+5ISuH9lQbvHXVXjcFuE3wY9GWj4cbqotcda2BFoPJAbKVpa6LLLT/pK6NbSube99m9sePXni QLivZ4/bJSlF8n85LxfYJq8rjp/v3vt99mcbO44feTiJkzgxJA7k4TSJIcY2IYSQBJKQQkgZL42W Z8C8p5GWFujWIlTRgNgmUSisXdeXkAqUldIOZiZ1AvbQGrZW2sY6UWBkQAUr0MTfzvdwABOJaJZ+ Ofee3Ifv/5577/G1+np/x/I13SWe+oAnuOLVTkDVJsV7FdVqoQ2OPKxaeJS/srY22NaanRXMCjbI UnmNRZBVWQtZjK9udLcF/awgfLds2hjxdmpqWvOdgpa0i2F+hiyAsv7UQCn0+9CmBVQN/aWx/lhK z4/MsVjMyvlTVRnz/+8RUVxeFhX31avKqmlYVTVSsbNTGrr3Lpj5UpHFyPE6Y4poKqidE6maHSky WPONKVPmdgealoSynGVNy3Z0PrIBs+oq3BaMfq+yAeNaN80Yk5dmsFkEpzPdZnRkOp0lk0uf2pRX 2BQaXTF7Y/34Xb07Vk56cEsqZq6Irhrrm+rPCa7onY0vYEi6Rw/zUYhAT9J+eMZlFESMYPAY042R Ssbb7oYD0zwZBigYJ+QUTclp5tXYk5WR5VIkL41VWP3n/BWy0Jkj7idHrSpgta2qKnFX6Kjm49Tb Qq7r1KLDLuhoOTE4cjPS3VaeW8XrTC6f+4lV85usrcRgz0vPQDfhDER05MlNGNfKmy0WIWXy3FUT wl2BTL0uQ2/UM4Z/SElmJD27zGOfuHL3k/Fows3X6E1yyaSPL82seqIs1dMUKi6MdFUWTPbIsYzK cdf5UrBBESx7WLsjRW57Dhwni8JGgzsnx+4uYgUZluNcwzE+XNCYoZ3Zv7X0WxXR+v7cb8WDjpp9 +Ji2KBSniaLdoAnZNIm4K7w1qzgn25tKeCHVhaVCG4l/e1+SDzgsqqKxs1neNIMhzZuVVZghihmF 35Un1k636dS16yARI3hqx8MPk2LEW56Z6fIyMwULZ6cWc6HjbrhqWqHLzDIt5V59rq8xt1l8eLu5 0lgMrzYMk9/6K5RFh52P7yUvXN7zB6PE+1CQJBTQIoQe1uuiuPuJANHxlcHk8DjKibZsu8NlYVy+ ZfK8aLCuqyad9HkmFwyevx8c7vHOYFNwee+sePeQPNtRHiofqXfz8fYrqutElaLSdXKGvQf18HKS SkVVJb5q3yS9GBEj1aLPV1adVp0GZZOmVkdq9SVfib68qqmWO+G8lsTFgzdVf8W5QCDElZ6TH9fU gBwfeJPFYimIrJltBL0V0czM46GC4LA75RsILyeH/OgOXVconPYm+/3VCQmxFTlDBIPRLF5azARf mWtMtlOvF3lcsT63uDStpr3GRXieLu4xmgSTbdSzPs6IqipS+y5ZDLRXdDidVkPc4Ki0+ktFg2i0 jHLnpOt0ZqOQ7m+pMmXn5pq5e6Ns5sJcZ5/OJDImmnR9TtTREd9ND9GPoQyWJL2rHrut6ATBHweQ zw1+kJ4O4nHiCZvDtnGNHr09u9HeZJ6hRY2iHYoRC5T2Dz2gpmHbaaGFd4tymLzeqmp8q1VJUI00 m38iVZRx0kOMz5u+ZMeC+KCQmlmY4fKkEuOtPYTocO0ut1XHrScTv9/R4CZGR4FrbA79uTHN8NSZ C1efj+/X4xJ5k93MBegqk11ntIiU6syGwfzZR351cqEcUyZcO5423r1+/uDl+Zba25ChB/lz4t+b z8r2VPGtroHy+FrxmO41vH9EROkBIEAcuJhh+kD54EXxGOZvP4MHPmwhM9+vcb9Hz+vS70aK4JLW ybAu6GDjYO0wrGPXoFNBgpAMvQydiF+zdcgEpANp0Xwq70E7b4LuZNgAtMvwYVhHGLQTJhWidaIN IGOR6UgzshH9LrT72KvYbqd0HHmDjcH+CP0eziGzSLOrwcPmQadwAcceMww4F18Lax5LHXhlhOuw huXjXPnQxrdiuRPLKrWypa8BU5H+i5Ybql+CQ4hTs7v5fOgdKexlOKVzw5fJsNHSH3GsT5EJmm1B ltBPpcsPcUv6cIQc4+dKO2QYg0b6DiwdDrYYmhU2QlCGbsF5t8BYzeYibqQE8SJhzd9CW6GBvQDL H2ED+mX2wRzuGjRw16Q6tFlopyKjkSeRdiSKfivancwFDWSidBjZQj+DBhnyD2hRuKTZG1BIP4cW QYAp7AfD8DTO+VNY8Fg+gkYZHGcRPY1znYZ6dhAW0K+xrFKv2BAQFekG8p+h+hzYQudId9GuQ55j 26EnibXD+BRoP+wRcuDNZOhZ6Qv6LLyIWDVrQNLpUunmg7BsaEti/DA+BUGEUhksB2kHNGtMREKJ um4KNAtnoZm/qaL0XY0sQSqhlf4J93kEkKgUFLZJQf0nUpC9I7mFrVg+ieXaJGYkofmFDUm8lITm H2q/ERFxjroHxt56fyz2LxXeIAV1bixnw6RkaEw6mQz6QwrF0ML1QYjrk2TuIK2IC+lG2pB5yI/l NvTX2N4FXu6qNCEBPYQ6q4TUcWAsyVLGO8p9BxEyCCGhQ5vrPj7F7pS+UawLpidR9oivFvcXEbZh OVu6owJt5BMIqUhXEYlmg6gifYPcTNT5N1RYjeTjbkqZ5H2IkhjyPiwkH0MxuwRRtn5k8DaI6pog Kvx1ZOD3XI20alZG3qflyNPI0gf8q+ku2Mwfh1eSoRulP9Dd4EA4zcrYaRHwGqDYNRClC+F5ugm6 yF/gbfI57CcReFMpvw5vcaek21j+BfkC9nOL4CC3UrpC9sIBbh4cYM1wgHyJ9GHbC7ABeZu7gfUy 2Mp9BSfwf6fIdvgNvQ7nyWaYR16EV0gN9JAO/JGxHtktv9qDmAoMXCazHvUp33E+ovgG9iPPJPn2 IUs5CeuYF9CDyFuKfzGygBbgeLfRNwV5RvEfQJ6lo7HeiCwbGqMHcxSgFsSq+N5Ffkl2Yf+fIAcU 3xXknwRzDHIaOYptTyEXMedQso+BdqSc+wzzkD7kvAqupUWGrJfk/n8nz0n30F7jvpW+JuVD+cpe OQehM/F93YbvmJJDxM/Ib5qaL8TxFxOsUfOF+EdyjqDkAXuks4n3HjUG9Q3/H/vlHhxVdcfx3577 2IRHRAiQEAhXoAV5JGmQgBAeSeSRhYSQBxGohE2ySRaSbNjdhMfUtghaHAan46stGQbRwpRWFG6t iAXpODIDRQZbbWlrldKCAypgkRgeMaffc383mOnwB+3UTjtuMt/9nPc5d89vf7/flaYzB7Fb+5m8 4sbhg9oHnZvAUjMReyKemkSHENd7GUWdbW5MXKNiobihYow8wbGs8zeOb3XiVudRfS8t47jVeRCx qdSJR6fl/q64o32PenIskVP01airGLJEXnXiwnpar63vfA7sY+CbUn7duJ9asWZffa8sRQxY4Ohe 2Plk2Q67Xq1nYNwOSlcSR+ge+N3pjlbTDD2H6kUmBUSmfA9aKzI7Lymfor0EX1WIPX+AmCKQp2k0 /qZPqCdD7yvfxty5uP8iLRnfUxk1uwpC8cYU+Pss8uG5W4xd+G09TguVxKPOXfbQrjh3nSUMuiwM z0TIFCPkXtjgYY+UF5z7LKBFzn024Q6UWnBHI2WwW+5YatbB9/yaNOQ9xV1y88FClevdzLf+Jl8w r0MnOW/0al/kcfo1vmeVq3blXvokxHClffS68STftTEY+W0bFKbXzMtU6k1F+SPabiYhr50BVVKq 7qcmbzzWWilvIM99Rr9M25EzkmMbFxH/VJ6UiPtUGgl7+K5c1S0fGmuslh+BCfqj6HPl5jhlKn/R jsAeID1T7nLspcXNSVqh5U6uMdvJu7ryiK3I9fDL1NORQ/Zge9EfI58exN1cpy3mcPKZM1GvoLXG epztHHQGedgnVGmmYy34BPSt06voIdwHmR7sm4k9VRzPQ5+yrd9hrXzkcBD83nRFfYLjd3O7x3DT J9uQZ2uuz1Uxcr4bA5ucmPYy4hmk95cHsM8BI0imPhFxbJQbq4ZCo7tiGWxT5RiIMSrOmVnIlRzf jNjzW9jbc9gTvluf7fr3X5FfjTH9eBfxUblRSgHtl1SjbUKc2ozc/A2c+5g8q8+lAhWb9ZFUqzXi 2VzBVncoiVb441bEv1Zq0H5B16Fh0HTtffqrWEat0EKtmt5DLMiAHT+lbFqMoAbYuc94mPJh3x9D 34Ek9Dju6Dz0ENQBPaXmIPf7oXiZvgWtgZ6GntCTkQcm470nmX4EbdQGyZXilNyivUjntA5PnNaP 3hSn6HURoTlQjdaBmNRBg7zTaAf0ahe1DrkU7Wdwnp9A+0UDNYsG+a6I0hgRlYfFBqoRG+QZMYMa xQzEdh/afag30EaMu4hx0zDuDxi3BuPasdZn0J+hADRT30OH9Kn0DMrroCc8b1C7NoHaDcQkA7HJ 2w4hbnizHSaau+moEt4/Lxg/pt8bz9MmPC/hnJf0n9NctI/FOgPAofBZiSgfQ1+7el9FuQbfxSSU fdqnNELbRoO115DTbsOzb4Nd96L6uHHwG/gezL/AZu+UUn+SlohjtFTDe4H2sXxfL4OPPin/qGfR tzUbv4Ms2FYW/FsCfGMCVUCWniCvQMehC6gvh1ZBaahfw2+gQmymRdo62FGE+mrPw3/UwQ730QOO b1T2cYBG4TwzoTKoD5QCJbosgjZAw6FhON9ynG8zn496Iz7doZ2kOPd8a9zzjcf+BV+cD++sCZQE DXHPt5PPR3drd9F+z1XYxh7aIHbTOuQS68VOehi2cgRx+aA4jTzlFPQhHQYPi7foJc8BOgGFMNeD uYlij3xT7JZHxbvymNgpj2NcH8w1xGnE3lPQh9Qbbb3FW7ID8wZ6Dsh9Yiveu9ooQxTLD0Q+YosP NjNLnhILSEfu0kuUy7OiAPa0FTbSRrYopjqRj+/Sh/xpFnLDBfQIxj0myqlWFFCT2Nt5VusnO40K KAgNdJkmPzdKoKO01FEtFRj7oGeh41RlPIg49Cw0Wr6DfM4fV0h+Yx1VeY/jzjocVUDjoWwoH/JB s6FyaBikdVOhcZ7G6gbNMd+mjbj7InFBrkT7QpVvqDxAxUwzQNv1UnlIH0D1+M1tgZ6GjjpKoBe9 CZ7JXexRCB88ibbh3XKUk/6QpyimmGL6qgtveTH9G9KTbk/q7alLZvaXL2/l/5bifvr/p/idMcUU U0wxxRRTTDHF9B+XB28IfnqHvLQHEtSH0mkZes57CklXvZRAL+BTI/VX7Xyqspeuo+Yh/sv0LHXL GvX3fN8t6yjvcMsmyq+6ZS896DmBkR49Xq0p5rllD40We9yyoATxJ7esof2cW9ZptNbXLZsoZ7tl nEeroV1kUSZl4D8LpQIKUhWFKUQRqIaiaMtDKUxNzqcfLUGUGikNPTlUj3+LitFWS3Xoizi1ABjA 6BZ8VmNkHubVY0wl2oIYEXTGBcAoZqmRFkZYYADrqN6o06pmWyirfatRawDDtAJtoZtzbt1b8y89 izpRo7OWOo1FZagFnTOo/UtQ8ju1iLNnI1rT3ROEuj1BFWrN6I06T6lGp+2yMjMysqyCYFU4FAnV RK28ULgpFPZHg6HGNCunvt4qDtbWRSNWcSASCLcEqtNySxbPyS0fk+evD1aGg+PyoyhU3X6jW7OC ESsQjNYFwpbfCgdqg5FoIByotqJhf3WgwR9eYYVUT7dqza0PaQUbLSxjlTUGo5hfEvVHAxHL31id jgVCzgZVoebGaDgYiKT9V2wpF/exmOaA5TTmnyxrHOU7d1Xv7FzsWFMzasoubn/elzHyK/sLUJ5P Xtl9TibRI3SLv73x2itirZ06begrYg1jtZ3aE1jFaLFTJwPNjCgPidipU4CwnZoNrGQ0MUJ26lSg kdHAE+oZK+whOcByRtAekgvU2UPygFpGDSPAqGZU8YRKnuBnLOO+CsZSe/BM4AHGNxlLGIsZixj3 M8oZCxlljFJGMWMBo4gxn1FoD74PKODaPMZcho+Rz5jDmM2YxZjJuM9OyQfy7BQfkMvIYcywU+YC 0xnT7JR5wFRGNmMKYzKjhHEvrzmJMZEXy2JMYNzDa45nZPK8bzAyGOmMNMY4XmwsTx/D80Zz392M UYyRPPLrjK/xhBGM4TxvGI+8i2ExhjJSGUPsQYXAYEaKPWg+MIiRzEjivoGMAdzYn5HI6Md9fRl3 cmMfrt3BSODG3oxejJ6MHox4O7kIiLOTFwBehskwGDoP0bgmGB4GOfBIRifjc2eCp4NrNxjXGdcY VxntjM/spBKgjXHFTioFPmVcZvyd8QkPucS4yI0X/kFdncc3UeZhAJ83qahJ00maTNqSwlvXRRcD LqxXPNbOcgQ0FijtCz2kFShQUETSROQIVJAVXTm9RQQPRB2P9AUVFQXv23pfqNT7Vrx1V80+02f/ 9t/VNE++8/7ye995J580Qz4jn5JP2PIx+Yh8yPc+IO+T98i7bHmHvM1iD9lD3iJv6rIJ4A2yW5dN BK+T11h8lbzC4svkJfIieYEtz3P0HEfPkm4WnyFPk6fIk+QJdj5OHmPxUfIIeZg8pKP4XRIP6mg1 eIDcr6PNYBfZSe4j95Id5B5yN+fdRbazeCe5g9xOtpGtRJMuzstzL7dxdCu5hS03E4fcRG4kN3De Fk64nsXN5DpyLbmGXE02kY3kKm1NARvIldqaCtZrqw1coa1p4HJtTQeXkUvJJeRichG5kKzT1mSw lmuu4ZqrueYqspJLX8AJ/yLns/M8tqzQlgLncrF/crHl5Bx2LuMqSzn9bNJJlpDFJEcWkYVkgbbw myzm8wxncel55EyeIcu9ZEgHz5fm9LnkDDKHnE5mk9PIqbyUWTzfTNKurSPBDDJdR5aCaTrifnfb dGQJmKoj7rwpLE7WERucwmIriy06shhM0pFl4GQdWQ6adRg3YdGkw/1BI2nQYR+YSCboMG7zQukw 7u+intSR8TqM27yo1WHc2MU4MlaXurseo0uToIacxGKKnMjiCWQ0GaVLcd8USbaMZHEEGa5Do8Aw HXL/Kf+hQw3A1qFGUK1DTeB48ncdcr+tx5FjyTHkaB2Kg4QODQJH6dDR4EhyhA65JzqcJzqM/E2H 3E9wKBmiQ+4H+VdyKPcymAziluLc0iFkILf0F3IwN3EQGUD+TA7khD+x8wBuqYqbkDxff9KPnZUk xul9SQUpZ2cZiXKDFolwn2GeqJSEOC9ITFJCAmwp5sivg5OATwdbwP462Ar2I/uSPmQfdhax08ui hwhi2AVYQN+v8BfkZ+Q/yL9R+wkTf8TxD8j3yHfIt+YU+Q3ytTlVfmW2yb3Il8gXyOeof4Z8ivc+ wfhj5CPkQ+QD1N9H3sPxu/Ad5G309WC8B3kLeRN5A9mNvF4yQ75W0i5fRV5BXkZeQu1F+ALyPPIc xs/CbuQZ5GnkKeRJ5AnkceSxwKny0cBp8pHAIfJh+FBgkHwQtQdwfH9gtrQLuwKz5M7ATHlfoF3e i3d2BIbKe5C7kbuK58rtxWl5Z3GHvKM4I29HtiFbMdawCz155DbkVuQW5GbEQW5CbvQvljf4F8gt /vnyerjZv0he58/Ja1G/Brka2YRsRK5CNiBXIuuRK/yD5eXIZb4t8lLfZnkJvBi5CLkQWedrl2t9 S+Ua33q52rdBrvJtlCtRvwBZ7h0gz/Em5DKRkEtVpzrb6VRLVE4tdnLKnxP+XCyXyi3MObndObum j2+RWqAWOgvUfDVPneXMU2c6WVWUjWQzWe+3WeFkxYisGJIVHiMbzFZlvcUZlVYdTloZ6XHpznQ+ XXRsPt2T9hhp4dte2LU1HeufhPaidCCYnKvmqDOcOer06bPVLGxrZmKGandmqOmJNjXNaVNTE1PU 5MQpqjUxSbU4k9TJiSbV7DSpxkSDmoj+CYl6pZx6VZeoVeOdWjU2MUaNQb0mkVInOSl1YmK0OsEZ rUYlkmokLtmoDFZWVXqD7gbGVGInRkwMGxKzYz2xvbEiI5aP7Yp5S82+sq9noFkhho+tEHMqllSs rvCa5d3lHrt84KCkWdZdtqfsy7KisF028NCkEQ1Gq6Jey722aE19stfqEXToEb3XWhM98KCkaQnT kpZnpLSEEeoJ7Q15rZ3B7qDHNIVpFkyPbaLdLJElHvelUOK1S4YelTQDMuBxXwoBb9QOoOKueHDx uPqk6Zd+j6r2j/V7bH/18KTtHzwkaXhFlRCGCALvfujdJiyZ9O5AyTD2MYRY01VfF4+ntu9bGJ/K 7z+uOS9W5AfUua92bVO+z4q8oZqaG7qEWNXYJTzD6/ORVG0Tx8tXrjT6DUvl+9U1aO+mTf2GNaby ne6xbfceF9xjAy2N8ZaObEc8nmnBS0tHJt77xEhk3VHcLbrPjgzG7l+2d2zEf/PBNtDagUfmf7XM b0/6wz7E/3sDv/NHeWvLfwUYAM+rtogKZW5kc3RyZWFtCmVuZG9iagoyNiAwIG9iago8PC9YSGVp Z2h0IDQ2Ny9DYXBIZWlnaHQgNjMzL1R5cGUvRm9udERlc2NyaXB0b3IvRmxhZ3MgOTYvRm9udFN0 cmV0Y2gvTm9ybWFsL0Rlc2NlbnQgLTE5NC9Gb250QkJveFstNDc2IC0xOTQgMTIxNCA5NTJdL1N0 ZW1WIDgwL0ZvbnRGYW1pbHkoQ2FsaWJyaSkvRm9udE5hbWUvQlNaSEJXK0NhbGlicmktSXRhbGlj L0ZvbnRGaWxlMiAyNyAwIFIvQXNjZW50IDk1Mi9Gb250V2VpZ2h0IDQwMC9JdGFsaWNBbmdsZSAt MTI+PgplbmRvYmoKMjQgMCBvYmoKPDwvRmlyc3RDaGFyIDk3L1R5cGUvRm9udC9Ub1VuaWNvZGUg MjUgMCBSL0ZvbnREZXNjcmlwdG9yIDI2IDAgUi9CYXNlRm9udC9CU1pIQlcrQ2FsaWJyaS1JdGFs aWMvU3VidHlwZS9UcnVlVHlwZS9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvTGFzdENoYXIgMTIx L1dpZHRoc1s1MTQgMCAwIDAgMCAwIDUxNCA1MTQgMjI5IDAgMCAwIDAgNTE0IDAgMCAwIDAgMCAz MzUgMCAwIDAgMCA0NDddPj4KZW5kb2JqCjI5IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggNTIyPj5zdHJlYW0KSIlclM2Ko0AUhfc+RS27F41/t+7tgATSSRqymB8mMw9gtJIRJirG LPL2U8fT9MAIiZ9onfrqYJluD7tD380u/T4NzTHM7tz17RRuw31qgjuFS9cneeHarpk/rpb/5lqP SRoHHx+3OVwP/XlIqsqlP+LN2zw93NOmHU7hOUm/TW2Yuv7inn5tj88uPd7H8U+4hn52mVuvXRvO MehLPX6tr8Gly7CXQxvvd/PjJY7598TPxxhcsVznlGmGNtzGuglT3V9CUmXxWLvqPR7rJPTtf/dV Oex0bn7XU1IVeDjL4inyK/kVvCKvwBvyBrwlb8E78g68J+/B7+QoUJXML5Ff5uQcXJALcEkuwZ7s wZy3xLzCHEGOMEeQI8wR5AhzBDkiZAEzU5ApSlawkQ3MtQvWLly7YO1CB1kc3shvYPYg6EHYg6AH YQ+CHjydPZw9nT2cPZ09nD2dPZw9nT2cPZ09nD2dPZw9PT08Pd083JT5inxlviJfma/IV+Yr8pX5 inxlviJf2YmiE+VcirmUnSg6Uc6ry7zsRNGJshNFJ8pOFJ0oO1F0onw3FO+GsR9DP0Z/g7/R3+Bv 9Df4G/0N/kZ/g7/R3+Bv9Df4G/0N/kZ/g7/R3+C/wvNFliNzT594wsb52CHYQnGnu8/92dynKW7N 5XOw7Ensxq4Pn1+McRhdHIVf8leAAQDusggtCmVuZHN0cmVhbQplbmRvYmoKMzEgMCBvYmoKPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMTc4NS9MZW5ndGgxIDQzNDE4Pj5zdHJlYW0KSInU lnlUVdcVxr898EAGmUQRFe57KqIoDijijIojIijOCsgoNiAEUFFREZUkDohiEk0sMU1qMxi1bSJk coox0SRG0yFdq2mXgqurq0tNqlEbNbye96Ta5I929c/ete67Z+9z7vnuffd8v31AAPxQBUFqSlr/ QYUFpU0m85U5F+cUZZU0XSlfDNBIwOurnBXl1uH6xu8A71DAwzu/ZEnR7dvJvoC/A2gXtqRwVX7F lVu3gVAzPvFqQV5WbnOvkAQgPcrMF1dgEn6HfExfeoaJexQUlVf0y7v0VxNXA4GbCotzsnDOuwoo tpn4yaKsipIoEj+gqtaMt5ZlFeVVp1e8buJDgJ4sKS4rL6stNnqbi139JaV5Jc6//eWSiXeY6X0g 6kl18ICXx16PWPMW4Q+ucgE1DC+wvwczq7DuB3+dAGsN2o7kNMuCSdxTG1pBpz0bONICXnD1SaNH e5ea+ccABrlv6GAi0+Jw2NjblSC09Tw6yIxmd4vxn48Hd4pMlWelUV7RYbJHnpF1sl5qdZTMllKZ J4VyVa7JdflavpG/yw25Kd/KLZkrczRRx+oESZbnoQhEEELRFZHohb7oj+EYidFIxAQkYS7mYwEy kIsClKEcq7Aa66VKSmSD7JbVdI2Y/CmAwiicoiiVFlA6LaVCKqbltILW0lO0lbZRHT1Hb9EJOkln 6CP6VKplmWyUp83zt4MvOiEck5GKIlIS8iBPspE3hZBFEWSn7pRJGbSYsmkVrad1VEXVtIEa6Sg1 0TuyQ16S1+Sg7JQ1sov2yH5pkBfpBnvqOPhjlk7TiTpJJ8thnanJOkvTeKtOpwt0UWeQH9XIdEnS KZoib+h4TZUCWSrzzVcyqwEpmENPSrmskAzJlAWyUBN0Nn2CdRolByRX8iiGJkmdVEq25OhweCIC NtjRDQMxCIMxAMmYbt5wGn6Cx7CU8umOWUh+HMQ9uBP34QjuS/ehtmNmTKVZRx7mX19n3nAXObkL f8Rn+U+i4iW+EiQhEiWJstx83S2yTV6U85qpObpcd4ZvDr9pBVghVpgVbjmsSGuANdwaZSVaJVat ddDuYQ+2d7Jbdoc90h5jz7TvdbDD5vB3BDnCHOGOaMdkx2JHXs9z99TpdK/W/Ub9LofyGaP+B4HY xNutHmnUy436JqNeKy8pNFtLtS68KvyGUQ+2Qq2uluVWH9amXt6m3vGhepq9rk090NH5oXquUYdb HdzlwcJ2Jv5riTu7tV41v/OdMc7uQGvTjy3Qkv2wFXvFuyW6JbjlSksN0Hy3+UhLvLlWN6832a6u Ec1JzVOb3TM3xzR3v3zvcvPllj9vdfuoksxY/pZbRY2hVNpLRwlzmyvswexiSCYOmSwNukgzNFfz tcSwpUTLtUIr//2JtLzt+rOHmX36ZlvrhJ76wdim/3v/iiS53feyHJZi2cme0kAXpECnmKffz35m pUyUf8h3dENnyi6p5D5yhy7KUu2rfXSQTDdr3mZ84+WmgL/hQDdDggjjoQFtHupiuDDN7aMUpOoY zMJSt5uKjGPm0R5DCzW8sBlieBs3hxheWG5iZBhmuIjRzTDD5akqQ4xqTaAaQ41GFzfoLG0xXvYm L/hQO7QnXwRTIDpQEDpSB4RQMDpTF4RRVzioB7pTT/SgSPSkXrDIgSiagd40E30oDdE0C/1oIWJo EWIpC0MoB3GUi3jKw1DKxzBaghH0GEZRES3DGCrBWCpFAj2O8VSOcVSGibQSU2g1JlEFrcFUqsQM 2oiZtAlptNlFISyk7UinHVhEtciknVhMu5BNu5FF9cinfcij57GEfopCehvL6F0U03sooffxOB1D KR3HSjqNtXQO61BFn6GaPscGOk974Uc+CKD2mE1PIIeeds1Fd+h+G6P6Gl5F0Dd0yzDBgwM4hKPY h8PYYQgVw9Hcj5/jfTyQGziOh/FInsqpXM0DeBDH8mAewkM5nofzCB7NYziBx/I4Hs8TeCJP4sk8 hadxMk/nFB7FSVzGq7iSq7ieS7mcV/BKruDVvIbX8nreyJt4M9fwE/wUb+VtXMvbeQfX8W5+hp/l PbyBd/EW3sl7+SC/wb/jV/gLPsW/5jf5LX6b3+PfcyP/ij/kc/wy/5wP8C/4NX6dD/FhPsK/5KPc xO/wu/w+H+cTfJI/4NOGvR8b/n3Cn/JnfJ4/5wt8kX/DvzUk9hN/CZAOhg+dJUy6SFexS3fpafgY JX2kr/ST/jJQBssQiZN4GSbDZYSMlFEyWhJkrHSSUBkngTJGYiRcIsSSHtJLxhuydJNBMpS/lEQ+ Jr35jMTyqxKE5XQKK+gDVNCHWEMfu2tRhasSmYrjqkk5pvrVmbp3V+7JffleWsVpyExqdiuqdEk9 1Kae6qXt1Ft91Ff9tL36a4AGapAGy1F5QaN1gPbTgRqrQzRG47S/DtahGq+9dY7O07k639AuUxfq AsO9dFM9R0ulplC0q/JRPCUBng2Gy/U/gHKqcWiZ2StWoQbbUY/j+COysdG09mI/DuBVHMFJnMWX /2V/8z8dras8iuArjYYnwaZi3HVeaz1gziazC3uUqTdRsFqPMs4A5/Uf5a631jsDWptsQfB23+vH X5jsTfreeZfHuGJnnCvmf/JdrcFtXFX47K4eaz3slWOrrhXHK9+s4lS2VeK8nLiWsCTHrus2fqSz 6zhUsuzgMJnW0MmDvDAN4HTTQGGa0qFtyrNhoDRXTtLIUNoQSimPpiUwwwwMoZlhGJjBM5Shf1oc c+7dlWN7kmh3757znXPPPY97j6RJpMv4jPfdp66fuX56SQ56setuhyHYARnIYvys/1q9azd2r4c5 9zDKPonjTuQeQq0cajH6htYjMI7PZ7Bv74G9eI0j/ajNMdmnOb8H9uG1n/f2g9gZD9vjPo4cQskB zu/H5wh8DivzeXiMU8W3hRyFL8AXsWqTcAwevy33+DxlwnF4Auv8ZfjKLekTi7gn8foqfA33w1Nw Ep6GZ3BfPAvPLUG/zvFvwCn8Pf0il51E5AVOMemr8Cach5fhDLzCc5nDrFkZKeZlJ8/hOObgEEZ4 dIHHVv72zWfrCMbOYjPtSPcj/tiCGXvtPDLNo6hpWbHqwKwcXpKJJzEGi74RkcWd5PHfQBdm5XZo MR/PLcjMs5xj1FL0VvTT8DyewG/hyLLKqG8jbVEvcHohfmpe95uc/w58F76HtTjNqeLbQl5E+jR8 H8/2D+CH8BJeN+iFlPV+GX7EK0chD1NwFs5hJV+BC1Dg+O1kN8PP2vjUPDINP4af4A55DS5ip7mE VxH5KWKv2+gbHLP4S/Bz5JmWxb0Jv8QO9Wv4DfwW3oFfIHeZj28h9y5cgd/DHwU/Ur+Df+I4C+8m tow89IkdQ9sHDX3bQH9f79YH7u+5r/vers4tHelUsv3jiXjbPa2bN7Vs3LB+XaypsaE+oq0kdbVV FQGlzO/1lMhulxP/YwrQkCYdGZVGMtQRIZ2djYwnWQSyC4AMVRHqWKxD1QxXUxdrJlBz5xLNhKWZ mNcUFLUVWhsb1DRR6dspohaEwV4d6RMpYqh0htM9nHZEOONHJhzGGWq6aiylUiGjpmnH3jEznUmh vbzXkyTJUU9jA+Q9XiS9SNF6Mp4X6tsEToj16U15EWQ/W5ZKWjo7Qrf26ulUKBw2OAZJbou6ktTN bam7mM9wXM03XDSfKCgwnIn6RshIdkinUhYnmVLaNCdpIEpXkxRdfeBvVRjyKG0gqTSNEjTW3Te/ gECdmkJU8wNA58nMvxYjWRtxacoHwEgW4nyaUF6kAX1DDzG+cJj5cryQgGFk6ESvbvEqDIemIBGL GlTMMMnFoqRyG5NMFCXz0zMkzEqVztj33rEqOjGsNjZg9vmt4Y1ylUqRzHBujL2zoyZJpay8Deg0 kUIikbVjTefvjqF+NoNB7GJp6NVpjIzTCtJuKSCgshrs6tf5FHsarUhSyOTsWTSWTjG/1LSZSVkO MlukV5+G5rn38mvV0Nlm/NVuMD9oMIlFiaRNfWQnrc2ERnB/7lT1UJgmDEyfQfRRg1WJKHT1e7hc mK/IZ2FsS7SLyixytyaruhiSDFYtBNQOHEh7KwoULBdnWUXbW1Udf8IX1XAVW4NRi+wgI2nJTiaS 2NRkZyhshK3PbVwK2T45NSovsKUgMO+Ttc4tXbO0mUOr1fRoaoGDi4w6bQdtazf3U2S5sBfGGTIr Z2dRJGl4chET0QyHWBWrVApbVZ2MEoPgHkps1VlsLNe8vt39pLt3UOfVtnfJwCLOkm+0OAphFBcZ MYl7sCMaKpaV81s4P892LhF3FcWqKZPufpMZJ7ZBUPEEYdCuSFf2+MbytXg0O7C7kY4sURW1w8wW 5iaGzXwiYY6nM2ObmA3SNWKSfr01xH3t0w+HDrClyqFb6B5ob2zA3tOeJ8Kx3nxCONY/qE8rAOqx AX1KFMRkpt3Ir0SZPq0CJDgqMpSBjFEZwyz1ISNz/dB0AmCCSx0c4HyuIADH5CImQK4gWphSxETE HBaW4Bj7YJGqxjDF2G7T6ggrzyFjzMwY7HBBEEuJt0AF0gZUJG15QXT5qIeMtlMvaWd4nOFxC3cx 3I0bQwgKmBzWk8wMwT6FG0qHkGBtRYmZVAtzcwN6+O3QjBHGrTaEz6BOS6LY+53avai3hT0ZhLfQ iVyW+QHbdDbXrXXlDNy2RYOo0kVL0EKJbQE1Ovgcth1xUg5rgwXk8yeQoRMGNaJsUX2XwbezQqGT bMKyWzadEbZQzDDLyRp+NvEoeLRJ9ipB36Bft5AQsriYYSXJ7UPPcwRFuYyK2XZArh+3utVLPSEL GcWW6IiM8scTsoXAwpI0r99DS5rQIN6M9jaxI+nU3IZhOc+5SVsB11aoFz2KLEilPQGzg6Iu5gve k+gqU/0ZM9NbgD6yHzsLc5pbcqOY+rWuLDZ/a74XEbKxOFlmPcJr23jDQt0sch/mXdIGCnOnyWfD Cz6NDYR9ObCNCaFp3NhgmEsBuj3a2CAvRf0cNk3Zf/MJVr5k//ybgWoavzXAif/OHpWu4L8pCdzQ Aj1wP2x/FfxCHwRhk3D+fGUqJTe6XxOSeAxUYQBkEIRkoswh+i9UV8fJhXWuE1KgqyA0nou7T4gi xGevzl6OzV6dKW+JzQixv1y7ek15/3KgJdZ87Q/XPna3EAgH+FNRKrrdFS5S1ySuWxVZ39y8pk1c tzZC6kpFjq1dv6FNal6zQpQqikibyHhBuvK/QemBWZd4hMQfbHauqC6r8Luc4vKq8sZWTenfrrU2 1bglt0tyyu76De113bvTdX9yB2oqgzXlslxeE6ysCbhn/+ws/fA/ztKPko7dHz0luTYPxVdKz3hk 0eFyFVZU3XnX5nDXg2XLFId3mRIIyu7ygK8+NTT7pcrlzMbyykrL1mwPpoXMfeg44qyAOojA89Ow cu4f53yKcB8p2ESkMPfvc14kvEXCg0SimlGawkY/H318TNQLGhM3eIWelSSi/dfn9VXV1RCPXwg6 fOBTfOIZ8jp5h0jER3zlNX3l25zbIB6Pl7e0xGI7dgTuaAkgGWhWZtYEmjHj0R1R/oFoVAsGXTzl q6SwVCqRukhk/QbByvMdbiKFHXtkQdFqa7VlJY5HZv/+KcmzjCyv0coEWZhy+O9ctUK9q7rUcVD4 q3DpnmCo1CG5fSXC5uu/KvGXOJyloaBjylsqS5Jc5j0xexBwT70E4BBwd62AKGyEtxLVtVWK0FOr lLHBj0OVDwcVY60tiE2J+urK/1NetbFNXWf4nOvr6+vr69jX997Yvrbjr8TXjj07thOS8BEbFQhf IcRkwIBQIO1oqcpXqwKFUdQyKq3aqAZiLV23dV1RyxgscRhe0ViYInXa1Ipp2X5M2rRJncSPgpg2 TR1gZ++xj50A/bH9uPe8uvf8eJ/nPO/7PicP/9U8/FdVS4JsTpDNCbI5QTYnyObEh0wGoZnJyxCj SBaYLsJOWO8UbXS1Vtd/F8XqerNoIStjz1t/YJm0MBZN/1c6bWotYfO4faizhC1jpmGUu5Wr6rYX p0b+ViUtMx2vBfA5Hu+txUCq0sSGg6FIl9Q5LxsE9lSi5xYD7kwy4bBExCzPhiz29wyO7ltRueiM xZw48vzp0UxzfHF715al0UpZ69m0cnzqscI895q2/meGPrm7YONjEfzcop2FvnbVr7Mv6/7E8IsD yeH+HofQVdjN4NTqLm9lJLxgsPzn+RsX+is93u4CTK7tM3dY0dgCVbyj6EUL4pSVOGUF1s8IK7De JqzEKSvxa0wWNSEXTqEgiuDEuLyOvYrbURfqwMkx83oo6elb5MGpGnz7H6fSHW1KEzenLDmVlikp YFVpYQhuIitWZIy8kn/88Iqjvz05sO7M717q2bVpmYc3GljewjdlBvcNrv/mE91do69vHnhuqNNm EjjDFbvL0aTEdM/wj/7x9jv3L21RA+2eJllzKF7ZrKf0pSeuHzn8i5cWR1IRTmqBCiQqOwkqcyA/ OpD35YJYJsqRiXJkBTDLDgAsuwCtfJUoB2k1bjTKjUYVo1HFaJQb7SojITNwI443DXlKODJmrKmk zsV0XREjpKM9IAnTHAGcXP/enXOV29Xjb3v/5ttDlzv3nD9xaezI+f29zNn3771XqB30hndvvvn0 5eMr70t9x64jOFNAZjgCyBLohTFNpyeq06x1mrVOs9Zp1nqJkfJmsxyQA5C8VsJ83nosgicj+EYE RyKcuwR4rEM6LGNcQ/Uj+/YDrFS1jdip+qvnzDyi9HBQeig0HGEFK18+RRAyX+WtvNEIrwqHx3lo DawZ4jUM5q0C2+/wOPgaWt7hURweia/sMtu9skOzmyppXvJUcc/cNQwDbh1tGTPJFLdMccsUt0xx yxS3DLgvW32oxWcCaEVZdnMlHC2GhtykQdKJlJqSehvo8CNg6tOmDtcwDMBMFWDPBMlX4zyvBDRX SOEB6rLq1ynZCyiWm+weVfZI5vLfTVaT0Qgv9iJB6SOINs/cZg8aAyiHfpj3eb02F1GoiyjURXqb SxBJBChc5PSs6Jc6Duh5fZtu0G0Uv43it9FKttFKtlH8thKTmUh14k5XCQsToVBvqu8qFmDGCzg2 3rtOKeHEWGo9OW+oZqlGB+1z0yMjU41GR3l5oJrndUtEBaTaq2xJpAPO1j/LHmR50ST2bH1l0zPn X8gtffGDJxce7qpMSxJrhhnxlqXZITjmb9nxRPrMZ++uH/ng1usrX35yqSawW2WfzEeSkTXfuLbn yOTxJT4fPhRqBRp53u51VGQt4gu5xJELd06fvfvT7Vo4poVq+mDXwsxNodJELo3DIqVIpBSJVCIi lYhIKRIJuV5nq4WwbyHsWwj7FsK+hfQHC5kRTpRXYbDkZfKyS3g1ysN/5CzNTBbhB1l/Bv+c7QUY IIm8bVLEN0QsPjiNoaBu5TBMjWlCK5XcbGGNtDWkNld1ta6pwrd6yK7llaBLCyh8uQiRmyiPV0Iu d1DhmYGqFiHSgH2QnMgzfeVf1WP2T/WofJfh6jGtL7wR+FPR2is556DzktOAKIWIUogohYhSiCiF 6EPoicLM5BVgQrAXqnABZqMRtj0CBm+s521Wg0733GxnMyRZmWZu408hqyjaCPb1/0jHB+lIeMDX FC6Yr+IMkqFlJ8eMdHZB0cfnTG6SHVe3k1XfOZvpp94lewre7mTIYjIyBphQvDuc9Ic6AvYaBNmM lw0c25Q22yRRlNyOZvCSNodNSg4tNnyP4CFVQPvX54Aki3bkpTQp6w6irhSJggJlWqDQBApNoNAE Ck0gYhVVvRAU7J6Cfdbn5erjB3QE7xrjkYiOv0BI1N6pCmfCuLnZ8LlJCXnCiWZTpfVhNeHfcHZn UNMCssnqqKzDn0gmL2nlnF1gXi0fajS1WVVdZ3Jm0cQa4YNVc5Znymc1mU6tVYBeQ8t/jtQaWJWC VSlYlYJVKVgVwE4gs62glnCcjiWc+rh+bnPmUKNESHteBbPFXJ5yxhogbhAzukrxyGaYMhfrqd57 xyx5qfK5OEyWhehC3r6tb28fY+3ocKZSQtLl0kr/oy0gB9PSmhZFgfQRgfQRgfQRgfQRgZy0QGQJ DjXvJhptnTdkcTmtKVc6yfmjQ/4v19tEzgF2PQtA6z4TPLu9EUm9i1LZLHHxc6oqjIlzBw+Pww9M q6qJx1ly3lV+uDiv+N3OoMwzlazBovoUtUWxMJV+DD3D7YJDTnieCnS0usz4gBGfsGj+iPtZm0cW Z4tz573TJsFkYMGUwTXpzcb3c+2tohb13N9gONfS7raYZZ9Ke/JRo4QWoa8XdZtNoWRWVxtdrdX1 DiFToWQqVTJbhGQyQ8jMuGzkBRszdpFEsCVDtthRS09BSNp01k0mOlFIlT5C3iPcpbJUMjWmoDbC zc3qF/DVYnBmI3NUxR61qpq1W9PDYbXyVGCxl2EYXva7XH4Hn9AKPt3vk/B837xM2oXB0Mh+d3PA wfcrcC+0+DI689fery1Yfmbl/X82quV8NCQ4Y/7yrztHt42kBn88yFyDWxN4ImgUxLtCp/gI9OhF MXRwrJWjrHFUghyVIEclyFHWOEKJU/IRynxEfz67aMWrfeR25AMfMI6kNnABRY4Tw3C7KapD4hwT VCPM/qAPCj9sftg5FtbwUf7ATw6eMstBN6mydg2r7QNPP7s6dnnBhpHE999as3NZq+HU9u/uXlhJ NnQC0E3O3JZDGwZ3dTaV/xPtHyWIR2cWG181BsHbLUDfyvuEoCNKUEQJiihx61Hi1qPk4KOAJC+g gLfDe8xr8GYoORlKToYaoQw1QhlKDuglO+EICtYvlXBswrmuje0mTcVKvM/0x4SE3oaBn/U9vekO I2VA5+Zebujtzli93c253wAKQeSUrzx/vC99ZvTbf3htycrTfzn92u9PLpdjfe0rdi+PKnzlgr75 jb1733g8Ftn0nf37zm6N/pfxso1t4r7j+P3vzs+P57PPD2fHj/HZnBMTx7FxnnxOnAAhCXkiAYop EOiAqkCALIV2LQU6baLdisQmZeumbupYtReUAAEDm+AFaNpe8WJVNamdkNaJiSkv1hfrUOtkv//5 HEx5syi6O18wuv/3vr/v//M96vQz6mB+e2dDYvLiVx/87MnHL07+5stfjF44e6SpszdkYcPkw0O/ Pzc8/u6t/UfvvDM08eM/KD6hDeCTDFEkzksN1mYmq4WlZrFqWfndZ7GKWSxbFtZ/Iy7Bx3iewVrB FaNoxiiGYhRDMYpmDBjqirfZCm3h+hEJSZKzC3yzGBx1KlEld4SlVeFStcSShavFk0A1U88ZiXM2 UFUJKSfLcSgdFaLRWjUyqO2RBk/QbqDnHE3dEx3HahaDqsS2FDybjg0L4Z4duUC6KWY/btYuV4oj 7nzr+Y+K0z1+iCrYcnUQFC3pqXy48tdV6wF4qyjTusnDvYXvbG63m8XO4Zblv0d81NuDB5wa9fJg sGMEMmv9yhI1DV7cSDy6SRRW/nnNYkWDBUWigiJdQUmsgiJVoUwmJDElsXY0mJKAOyKpSMrIu/B3 ebwN8FYrPsBXePw6+FtkC94LrvIytty96lbO9ur5ugUjprH5NhKILMB6VDIwgSzKSgYjGoT3c1fS 46ssk2W4Tmg2iwVeFR/nwNsy4ixhJFhicG8TxZJ1yYoH/Clz2qp/+BYA0c8AUHoViNSOZ9FfTU33 zv2qVDg81eE0ANxoza0jMwPrSr2R1NiBQ/vHWjsOnJ8Qp4Y6WTVNUmqDxpAsltozI2lPavzgoYPj rejlF340neICIVejn/PZNKFYuCE70pod7mhp7Z6Y2Tz65mSTxe1nDYyLtXlZnTfs863tacwMd6Za u8Zn4B1ZICE/BeeHiH03XBLuSgxW7RqGwf87LvF2zKzcXcTOV9twLfQpiZgCeP23LM590XpPXC2F T/G8lgQycHwql9kLNXaCK6XsUmflqit3wa9/uWrEPVrGy7I+m1bpgb9bWaJPABuJxLzk29WEAnhq A3iKA9g6AUwQAeyaAG4iTH0TAacRnLJgTlkwpyyYUxbMKQvmbpFWTOm4r+ixhXTwX+ijY9Yx/qlv 5Hqi5KD41CIl9DxG2r+NyvSJvlPl2Zcvv1GUK0iI1SbGZzdumh0VZWmCQMp/++7NUz3dJ67PUeGa HN98uf3725oSW09PUc568g9Buu0HVSLEIckXwcEWiyAPPkc9KOZEURNKuFHChdxlZUjlCxx7rtod fCHZ8C23y+2KNvrHXCpbtZ/YcnnGhqqDgFdIlEqoVCqJJbFRhikaI0ImU4dQKY5Ta8gbtNkt+Lig izFqqOVtWmSLhbxBm45GxxA6QGkhuvwRE6VtMJi1FAIONmjpKxxvpimtSf/1HTqP76vMPIfXuBZ8 /B+5s66VfPEkijejqAtFnUjgUIxA8bGwgfGNMXWYD14syT+N8DTqKsrI9AcPm0V1j7z6xIj6wqSy xUOBiMNALz9c/lxldEQaglGLyoR2L39s1Fhh/KKcXo04ZFfp2ZDPLzC0cflyN+exqKDw6EiqUgE0 oVQWD0eOk3mOt9CUBizvRV9oTRp5NZX7eD0dQPkXYC7jhGchxJRR9Co/ahTKSFhQYXpPwW8dt+MJ yqK6WeIc8p6A4Iq6IFM87QlQepuJ3FK5ojdjQjLryQe8n9Yz5sol8lXGtoHlbdpAuNHEuf0O6qKW 4W0YvPwBwer2NNi/2RnCO+UOyPQ89WfoXhJxWQpYevw9yR7KoHOmjTAgaTxlaTxgaSt2TbqMvpLM hCBYCGQk8BwS7UretyvE2q7MVHvNae1lUivZGed9Im1Nkx1304hIo3S6ubCmjHjJ8iCEQiHa97h5 oOsz4xBNJGHUqrsng48zO0tLyi56T9xZyiWrHJaCbXQncD5+0UCkbXUI0tqmkIdyh5YnUFONaK41 lclSeauX9/jNHedH1x8bbeo+/tGB17mW4VzX7o0tRi3gpobvmXwpvfsHE9EP3y3u7fFvGykc7nIZ jcCHxu35/sb+lwqDRwYa+9Mjbbwv7NNa3Ra3zxP2sYktb0zcczbl4/3jPcWVlaq6qpNkFJEEQajR 0itY83m4+4lqhliD6X8RgkUfzCiJlFESKqOoiD/LKmbK6L8S7xAx7YkB+BcifisizkMRvwexTOol HeHQZ9qCtGptGamuRwf4futgDi4XVENygoGwztxqA3iq5GqGCY7nwwxPSwOpUUTVMBwnI+4nrdPv lcSN/f2C1sY7wFlqDRtwuYHvY5s2bIjtOTcVu+RIT0qBbqlPKL7e270160aPZm+f7Wei7fFDkGc0 DXmmWidTCRwq/4ivC1uHz1ye7Tu9t8u2pie1PD8+1Tn9GkzPdlAsQP2JaCN+uOCVacAq08BDrBWB nYaLo6DEvaDEvaCQrqCICefH+AtCmTRIpqQZmd2P/JLetMEfKSPyGjtA/asF75U604aWRBmpF3Qg W+Uv4pJ8QMlSVbd71RoAw1rPvcAC6ioKqGvIi3WjAqRK4+7ctDW5+6f72goz89vE0WKbS6cmbSaL 0Lmlfe7NoFTqzE3mRSOuj79m3IzJ3eizSa9dnX37zskOqyfkMrMum+APxoI3Lk2d2SpGxLCW9WEn 7QJd3le9QkSJHHFO8uc7kIHP4ZnN4Z0xh8kqh92Rw2bJ3UZPwIXJqmpJRaykIlZSmeOkIlYSG0rP BvsNOYGnzTCsqiuuAQgA+qp5SDWIYUC2U361HCioi/1UI9xnBhPQdtVVFDBtXTnIUu9rGK/dAfm0 fv6F6XemYqk951/cfEbS2P3YU7qLvd8r5sFB4KhCsEvqF9w1A80NTQ6dWdhz/PbZ9X29pKHWJCt9 4J09r0vF0/vAS70tWK0SqDUPWScSaeKStCaZyWcOZygWTxMbAAlYNpjAHJrAaiWwjAk59cALTxaL 4ociKYJIi3ja0rRiPlrxmPzZIJ+rsUdj/YLBxB9P0e/R5F0aPaARTXuTn0UHXI93mY+YSbPusVc2 WElJvJmjtahLfS5WzQa3FchQh4N1tnI8az7SIWRkQTXUvOCuXGnoPzIq7d2YNGoMaoqkNIbM5Ix0 +LdH2ztnPpg++JNdTRepE3NdO7pDJEkKwU2vTjY7PA6N2W0zsRajwe1iu0+WTx6/+VZf8djPt/6P 8WoLauM6w3u0SCutBNrVaiXEgi7ohiQEAomLMEgrIxASwhjjC24CdjBOp25tk9h1k9htYkzccduZ XuJOx5085KVJZ9rGNabGtfvghzw0D/Z4OnFm0kvGL52J62GmyUw7TiYW/c/uWSLAbcrAntXuSuj/ zvd/3/cLCxfbyod7sIsF1z7Tnde/QPVTc0sODjeg0ngSUS1JUyuJyJlEyAQx6tOlRDR4fe2ubOMg wAfZ1e5CQ2g1MeItcyPKxAQWCAnrneTHao8l31mP32q8FtW6DdUTE4i/pvkKDjW685ArDIzojkjB lLfuXfBovc36rhGkqd4rGF/mOCw1L/tHjpb82wMWyBtWwVmnN5lN9cmJvlmGbxAC3s8f4mhSAwda 9AaEBp6Znvnu3kit1SJIYONUV+U1+gL9RypD7aAOUHdl0RYv4C4rGKHkgpcTULmQzF5fe4QhyJL+ gvX+NXwry4zDqVxrtaHyuFRjTdBJhsHs4RS8bsm1cBJPMpLEJOM1GGM5hUGewv9iysvB26aiQdkM a9CaYOje0p8tkx+J4sFe+kH/SNS7/YPe0lMfeMcp1Uizio+uvq9Kfyx5G4PrhHCH4x0PF7nbMfiN aQeMOmDscKhWEAobQM8cTjKVapzrAdNNdStHtbMhmMCoum6yGZ0Ag2u4jiav6AuC9ay/sXP6lR09 hySbM9f9cHB+V1vq628+d/TSbCvn6/B2tHcGPYHU02fLkYIHcTxfqRyeThTanYef6hhpd04emHjg jdSbFk+NHs5I9Em/J7CvfccLk61NDlub29+mY3W+gf3bMvN7OoLy/pQv05t0ucqtAwdDwentYy/t jpuMvsrHT3/V21ts2f+sp2fk8UxfVmd0xSMtYm6wKZHB/L4EqfMNcOZO6sXlbApFBcJfQSO2QIgt EMYL2JadbjOWWzNWDDPWDrMiG2Z8j6VkuEW5oy4OHGUlXgoMu8qKfGI3hh1pVycJ1Yw3aCevWK6B 4bd6shplRfoNo0313Pq2YiJzJg8vXcBzRrPiwo+KXzld9rk0PuusYzP5wNSex9/XrlT772hx4NkL z2ClfHXtMzShb6dEykf9YCXrH/cf99MOkvA2TE+Cst7fNGWpU9VN3XNUIyWqSInkXSK5K2qQigDT NdYjwzs911Fm2cUVFXzeX40RNSTOEtsIDsFCwLaLyQgsRJnNAAit2/pi+G8dAnqRUQtmUKIvGknD H1S8dq/yGpqDigNUgjp/dbwTBUlYgPUT/L2DmrAHcZlmfEE3vxSzUOQ5itRHaXVRpFAKtE9mXS6q sw3X2AY1Xm3xFO3gpFf0SpdCpXwyqaVctVqoVa/WWkNabONEuaHsCbc8V/DG62HUohkTY/A7fe3u Ok30MAbR2LZtUevc6d0xI1vL22ptDRyjt8dHivSvtsKh9sEZ6IMU9VPZku1GkQ7UIdvQGMSju0px HcT+OnD1FmVV7K/jpi5MNVMWgoGFtImFgGMhmFhwazQ44nEKQ6K2iKPZrG8pNg7zWnvAUIfaIWxB 5lc8ofO+xoJ1GoTRE5oDqYkVrIJByOGgzxiF5gbJX281VBY38wPtNtpczfWuZtFUa63cQMdqzQ24 IWCIM6FPKrVb2+TzP6FTbK2JBlM1Weq5yo1KkBeJdqAMYCZS8krWOe487qQpUn4VNwgl1jmCHi2z 3LBSMSHAE1m+ldmurV+NfAv9Xcg4O6l/yJKNw9qFFSnEmS2oHK7Hx/ldaLhKx9YFDvewQHpYIKxW 9M3tdsCp293JYpljscyx+ENZReZY4PfKTplHYzszYfKxVYn7n5sSuQJI+CZ6BCLLIcPSaAnCt0Gu zZUyw/HeYrzsqtp/bGFavky/pyolnyaSqaglhU/+l2T+Nw0VVQ11ErLo76pSKhjtrfm29Ikh3D1O n8A4Wgfb0ifXldVga3Q6mjim/MNi7/58gotPjBYC+04VPV9orD+9SWO3XqEXIZjQtMls/Nae8Yb2 XEtHPiqA+JY1D4Id7KQuylZ1B/GB2NHmXSIutHk38bDoNuP8r7oSzg6qSSn+BPdXiDFhW5LZeCnq ChQ16HFqWHcmYk0a2v+HPYlfZk/rIP5s7EvsaQNQANBB7E54GvwQEBKoMPVLuTEbQS02FOFRqBaF LChkRCEGRWkU0SE3GXLcBDA3kS03Se1uApgbh3V3O4tYez08bsdw2fFcYLfBU3aMmf2GjqWotVsr VmpsHrbJdR2hJWvJD5PjFf0YpTJ1mkCmjYpYq8gPqkpPGB0mRXItSfX0h30nfvP88V8c606f+PUJ WHveljJHxotfy/uk7JHxkSN5L/r7sd+fH93+neXnYS3Beqa4MJtOHVgYKy08k07NLAA2lyoX6XuA TZQaoF75HYiKr5slLGEJS1hNfVhSPauEGDGGC47hgmP1+HYMlx3DyJgoke3u8tXoEzAFXguVpCI3 noZTUng2q4bL96qSjDIGajWHn8ARte80FBjeoebEe8lDP5lpyefkQBVZ7KJkYyLlsYn47Pf2tbwt JvfK3gwMgfmXBjP7exrQg1N/OFfgmlP+SkbTwpoHwBmaBva8GM1ExPLi5W8OnZ3rFyKDHZWfT071 z53BTDoIaL1O0DovSwCXxxzDDRNjFRgwAIrIxW6iT+GppEqbJKFTkqhkktAsSQBNYtBYMVg0D8Q8 NRxYvn6podQLjn+VG8Oer0RzZ1qTfJJwNmDWxdfR1Xxxro96dChUTZwe+nUTbjOPnYmURophDFHn oR8faBkeKkSNtkbR3sgzbw5+O5+d6nGJqb053wBAV1nWkEK3I2m/dezcldmTNxcLfHBb5KgGXeVf k/v6Z8/IQwtzA7boYIeqTrq3ALEkdWh5vguFrIRUVlK6VSOXlbDOisllo2QB+zyYBIVZRjUA54Ky KVYKWUVvUcSqo8i9Yvix9SxcPQA+SWgUEhl0b+kMJqPR2RQQXYmuPv9mmQnm+tJNtb5Ak6WGRvSs w82bTCajva3c8/i3W4XmXHc+bKWNLGuqk7CjTqyt6u5AxUXqjmxpH82Ojo++PHp5VJ8jBeYIAjlC Clhv4VicI2KdI3kxdx39VfYEOgOdFglTTMIUk7BES1jfJaw50g30bywyMotjkUVWohK8DMHnZS2X LTpL29962If8Tv4gP8/TPXwP7+j/S07SR0qOj9RmBBhX+TTMd9PcKqdIUowYZ8yGL3+RpdGGfKmS qSvVZiCvDWIV+EA2g+5OcmZhR2LfUMLB1hjMjDmW3dsbzXdKYXnnngk5HNl1eldgpC8iMjSkI9Zg au4utkfliNgi79ozKYdR3dA3YL+dLnvAI0D+lLySzd8d/A/b1RrixnWF77l3nprRaB7SjN4zI+1q tN6V5PXaK79XJXWywnFMQ9M0Tdampo3BxW6NcRPitE6JDQ3FtJQmhdi00B91/aMU5+WYvigEgls2 NMHxJtCkhULd/jDBtOA46Y577ox2nZoISfcx0uXc73znnO+01rf9xuT2L2zd8OXhlG4XTD3nmlbJ lN2S6zTXVqMN7aCxZuvnuS/CWx/Qg8IvyWbyyEsTxGp2Rph3Rr7ojHzRGQVkZ8TKDieh7mU715rz tew1b36aq285TduLnHYzKS7rFl9bN70Wa5yQMi3R2AjHzGr0FUbastm00taWr+lBxQwmut7dXxnU vp2zRSWrfGtFqF1VdFWwc1f793hj1bwiqqLwcK1hGqo0vvPIfdQIxpyyJV+R8VeCquPEKjtjQZxZ 2KtmVNEo8nv/CCveGfYb1AQ/HPioBLSIMyjiDIoUrrOSJBWZieSCm6+kkeaPUPFHqOD4YRKbfMJh 8VeC1R9x1Oe9iup0hpEmloYozMQXjV2JJkiItZqvVin1fw3rBkm6Q4onKWq2v7rBzsh2reDVLGnX c0npl/Npj+L15tduP7ZDzvsYuba6qggee+C+rfuf2UcbK9G5/J/de+8a/+ID9OjKDsengZrpGOIz Rf5+kTRvYTXjQtdX+Pe4D/V0Ugd3dM/CaMzflr/JaI9GC58P+jjpo6qwIDKhLUKjjRvbGjDWgJBP 50IYCyFIdgMYCyDKwTdDCLFHGqhWYT4MMGpx9c+BilQMg1y64p4I+fk6/jFsD0OtPNTSBIj4JqiS yYVEOUymb+D6IcUd15OTPHBlSMtDBJ8oEY7Xd9K6yo4BZTReFLLldr3eLhlC/IYgguL4Xq3pqEIs sI9pxgkrXt2S2U8FNaPL/z2nGQoTFCPDHtRtlWFPSPFLXS7rOv2HqiuMKhpHewP2GCcQ7R3k/Yvk HkxP2/Bq2IXAromN0OfjeBdaIbQCaPnQqkOrBlEV2gJMMNi8BbZshi0d2DoFZlCAXSbXZGY6DjJI VzPAE8zcaJuPA50XEr6d+8ww+R0Hc87cbX7dPG4K5sB2582Z4fhw8w+mYIo/m+JZ03Tc+f1Tj03R Hbjr3atykN/mSC68Nje3iEimePfSfEgSlbaq11KgpVWcWSSzFchbrU+B/BNT8YQgxjdY1mvX/TUl nf2W0l+xbHmi7ke4im+KAnYXXrVhK+xdSl+nqo20922FLlG4QlUnLBdr3C1yPnfbKfSUqi4fue2i XF5WNfQQdqrLZVVFD2Ux8cq6slxcWVElw/01gdGxE/3VI98ZWME09HjK6PJksaULRaTiKzhdXwRv lBbclS0XVE7UNbxl5f/ZSmBjE2Y10ALeWXCHaNr02olhU7NqQ2u1e9g0Z9mAbVqKKnDER9RdGHfz aZaIWAJnqzXbBwR01I05CYKui7izuxQn8uvNgia8syRohUa1Nm6BCsX4hgJOFNSa+Yyw+GchY/mV 2rhN1fjmlOHoIpM1Gb4an8aBibpjwAU4azhZgUkZOT4Pu3FggpbPxXuSzIEK8EnEZozcf5FU8LIb eNRXYKICRS7/WkVoGbMGjVQo83K8uQyljRy5EvjDUsYZZnYKu8nOUcM6h2E7mQYsD9yQpXftO60W smb96JIw43D2uG5epjOPS9PryoFFpSdVk8W/V8yxer2RV0UA9qFkNYLqmCXFL5uWqOcN2CTYGfZI oWiITMlll7v0iqOJWCNsvMlDKGiX2AUySbZcJCbexMWoubdl8u8ePl+vflal6riFDcuLpflclDQu aPi1dfhGnbCIOWfU3oVY9TjD+xCO6l+YlL4k7/ApXZIUQ1m+UqhwLsKp+LjpCGpWpYJm6TLfi4/C z5WsKt3tVCy5GjYM1y2Z9EA4buNaMlwrMIpe2Vx+TjYrXIkTdgHeEp8gBeKSyiBLBtpx868mNZ8S 3Xky9355cQF65cXptYDcSPkTrZIG4HVZ0EpuvuwY8ssKNZrVYuiaSnxJOKSZGQmDIvMv1cpyw7R4 H2KxJn4fjpC/kQrJvKB5VWJeXkyqPpXlNMb7zkqEwxHJ8KxnxKxTciwvA8JJrThWLo152vf99d1O 6Q05oyRhB85TlcCUJDPg9/n1rRtwij2b9KiV8yT/Kj12IVNvlu4Vc3ifxblFLjlQatzZFlp3rOGU Wmr7QRtjutgO/HZJvXPNgmCqommVqaDR4WNnuR2mG2HYwdRd7nCe/xjtOYQ31oh3nkiYHV/B4JVU hhGLpkz+gV9fStQOYurCod72rV3+OXhPr7sDP/wMiK+yjPg79JFy3hRJrze91hvBBaN27hdCNl8r lEJbkOiCkHXqBZRAgng9m1MEOetkpWPZnIpo5bN43g54iXbpNpIjxktE1q4JpIdKjDsZTQlTWxK2 dW0r3mPjC36GnBLhZlT3W626ZJXxlGfhmnSOHidZYr2Ap1yEGvn0g1zpnJf7aFOuWLDF160CnZ0I gglspfCMk/FZ+Lf4PdIkjUGB8czIuBxnSfCwgq+dJHM99FhSKEBC/Wd7q0TssiRWUgTgg70Lex8W waiV7LKjs9n7N1b9TffPgGpWXa9qUnHfpfihK0vxl/6kW5pIJUV89M133jt8+C/vvrVfkCTMUibH +gm06CpaFJKZi8RO1Yo9Urt8fJlbZhPuSC3pp1ILJ9elJnIqr6TXWXvDehq1RgXLteFqdePnZpnu lO1yLQviI3v27BGoWfUKVUuh+4/S0uH33nnzUVGRqIjh/Ec4u3QFzl5SeSRJkrAY70b7fkLPsAfF 72JNKQ6MetuPep6cM6WM1tSQGNjb8lCVZEmKIsflxOpjP9bCmO33I27TrOexFqeazPqzLoIpy2xo UM+r6W9XWdDtBqx6Wa97HhjXrxvgeXX98sr+23rN86hxnZ2VmlHbVk/HH+VM9Jd0WrXbUVP62gG5 GUW2+jyIJr7ij5/H/VZTPkAYNldZ6XGxS75BniYnyIEXDz9dHH8VDg7+x3jZxzZ1XQH83vdpPzvP fnbiOHHivDi2Y8f5dD4cJyQ8SAIJkC9CyEcJNFBgQLqQlAIrqIVSoEWhtKi0o6ODrNWmsrDBaFkG lQCJqpoKqiYB2z/TxqQhxPjotH5og8Q7977HV0Aqtn4595337nXeOfece05JodVdUIk2uTvdnWjW snVXskJZJS/fUnpvtbXNFa3bCof8vJIF38U1twZea597ezHssekXb9KeCl43qsSLoN+KKqWk6Tp7 jqjP2v90GVqxKwB1Ce0pcmnEkKaLo/6I6UlMZAXSTYCeNlzQfOkNmd5tyGBBP606BFpfBGHbylyK 3oDEsLBRCdb2bmgOz6oIiKG5jQ3ZkZmlfrckq5Udw/PU6opousJlBB1pMs/02IvrwjOjPpdUNHz6 rfXjI8815LnE0pcvjjat76qAro1nMCda4/2vtpyanPiw0ZJV2fPKkb/t/uj2gXkTnwXbSqHjy3GZ y6e7o5XTg3fusrj+zR0bekud/nggFPfbleziaY15kcH1Qz0xm1qc3S3LnAgnb1lXR3hW38qBaNcH G2aX9azb9sYra3MHx3fMUZyKaEtVZIfNKiUny90fXX2zbOf+gz/dubyq9a2vzmj14RnzF7ZnzWlT cuK57HzIrY3QDX3BZ0NujaDrWlrIgcNQpifhoBUHTTgg4jwWhxlcQGrAgI1pfrYAJ7uhYEkmMZ3s gloymXROySrpANxkdIqBJIlUvWlUjTADeZ20T6rRPoG8RrImVPrqOFOgmSUVFSMNsRIpkswwo0hq lRhE63+4kuzw2yRCNYkMJCQV5HvGsfQ7WwdsOekYv5C2n6RUgs2iF/f2K3qhbzf6LFpPGJ+pR4VY Vgg7SmaMrcKxXxQ9f3TrS79aESkeOLplE8ijsicyrbm4c3WNyztjeWNlZw2cG8yufd8d6+/6+PtD 73xP5Vj/++s7Y2ltI58NvP3llip/3eLh7RDhv4Ez+SCfigrRPzW/34v9mdifgXM82J+O/WmYFEap OExt7yDlYDF50yRi7mKMiGlReFw3aNgwaNjoR8OGQcNGvRkeZxRIIm4yyW0hfy0Kqf5ttBG7eBzW BHmGLPWQ/gxZgjZqZphxSMGK0zGOpx/PmR+2j2PxmLCA1jYTcLwZzdOFyLlI6b/p8HNqWRR5UO/3 GZWPYd9sqFIEvc6PBfTUnqLQzuqgICWJE4tEq0UQzEkmLP/PmQr1mGAx4zzO6nA7oIEVrptkM1/v TLeLoj3d6UhXzOxf9klckjdVcdutwmmW4yDKLMKdPWY4xMDaw2DtA7Cna9E7WlK4Ake8OJxJeieN mDWVmFXDLrKLXfRQcqm0UGcKTpQG4Ivihq3jJ+EotOjGsZBOyWIj5qyMq2ocNl/hiVKXUNhhj4/j 0D0LQQq7CdkLBGmHrkQukO1INyC1Ee2JHjEOaXOMPHVvQwpGnoICipzY8Cpmm3miXE6xiaxks97p WhV3ZJS3ldX0N5VYoTLnGN7kru5ZU714d1+ha/aOwQtMqclm4ec4Mpxm0e51JUPqT8LSor0bl0Yi zVU+X8hncnhTbC67nOLPcZcveqmhdtOe3w5fNjs8xH4rISfsBft1Y/4PqBdMlkFM1otLTGCUEhL4 JdRuJcRuJeNMuSa1dARbWtxO3AwmvqYF4ZEgaR010AY1VvaQmR4y00NneshMj7FlPWD5T2lPBAF+ 7RMS37KxNWVjt8vEcU5wg1ytwWW1Rgvxaky3rrGFNYkoq5VqxVUxji2a1NSR/x9V5Zs6XHBpZAgH nCxxO7iIZgnSlpJkcZG4inzg8Cmi6UNxxPW0QdxmJAuB1nP6UUJddj+B3Nc8yYkpXpbdW7vu8JoZ Q91VNpPAyknm8o7B+pnP1fsiHT9p3gS+EgWLbB6auaopN72svbyqf15UIi0XVDTOqs5Brff1ZwrU 2t7qusG2Ajzcs2dFLCUzS5ahOvRnqAHVV9sZjXVrPgiPFGeaTfRpPbFQU0VWTiiHt3lc5EBwgp8L F7w4u2ZVe9zCiOVta8DPy8HP7/IyxMlZLSk3hnMrSM4PsjROTuhhEjNiAeTXn1jAwLGTjIJCYO4Q aEPEGyG5NToYfSXKRjNJTGUSN2dSN2cSN2eeZEqhVLh23Mjgn8JtpDlh9HubHc9zOt3grnzNml/1 jerDPh+f3+5+xGF9N4nDiiLYftnw07m+i7rL9KAiUfXAR3pCf+ASWokrRvmbQopYRS8T2HdnbTk2 MG1gQYVN4BnWZBGlvNmrGuvWthfmtm9eWNMdzHBnZTI1JpvEJzsmM3Oaigd/ORjHh370i8EqJc0t W5V0h+JRTGmZ6Wr9yjm1S6ZnWdMDjC1bNUPo+UOT+3imvH8XWBqiis96gd/ctcQ27VuUZkLkc+pf m88TeTa3seFuyeQL5hPiz+HSDKcynYGQgCYRPie1wN0R8wmqfejD9XPygyv8FWhGUc7TIngS5wlc Lxrj6lH/E7kB926g97gE8hDYa2gMaDDkLINlwBJgq6EfY4+gMd6KnpkKdxfWA3gNqQyHxhguMQdk CGQcKAHagFZgE+i9QC63F57bjURmd+JjLgTzAbaPspVdaozXogxuMRoT/gxr5z0BEZiHlv0grTrC bbSM88FvAfxSGHfDWKeDSHi/2QYpgPv+9VVkexjehw4/Ldwu5BO9qGYqXC4qhrW8j3EaVRukU/kN sj8t/KLEPwgch0bZL9HzT4JbjkaB1dwGFCWwW+DZLfC/6FI1yAfCwExDP8q2wbxX0cBjbAT9RjTC fYA0fAON4huJbpBpIBuBXKATmA8MgV4B3JwHjTK1CDG1iRH2j7A2wPydspO5aoy/hv/tEhoVBFj/ 7fvsBzbS8QrgMFrxg5zUgXVWsJ/DbwHcMRjfhLFOA5WtqEkn8S3w3f3rHpTB9iQmdQn7cTc6CBww 5HvAi8b4MdgJlC3UothU2POogt0GPpvKKlRvYKLyElo0Be8TdBShSIcrQ/shfnoNWoCue9fiIOoV /gpgHXj2WW4EWA2UoX72Dup7GpghFBDeRwHTJRTgfg3jnxnjaVNonYKhF9ZP4Y0pGPpHnjfDb9Q9 tPa2B/e4mzq8E0FvhwLsOVQ+Ffquj7OfK0sc4eoS/8WX0XZ8OfFjkDaQvYAKDAPdwErQK8B+9gza znnR6/h64pLBMvZD0BuQZ4A8JoPKufgOymD+z37ZAEd1VXH8/+57bxfSTigfhVCpvAACJRRCKCHy VSB8Jk0kCQlfNWFJNmEh2dDdTYgoSCmkIqWDnQAFhNSMdWQMn1LAilUY1NJqp9Zqq86IiHZAqdYq rWDY9X/vew8SEphQOh0ck8xvz/+ed+/d+949756zV7DNUyK/qwXZyjbEdiqbxv1oyeda+cbZeH6m 9s6dZ6F4BdtsYpdog3oicmwYt4mxK27b3GvDubZp/2D/vUgUJ4m0xzDQeAeJRlX74LNO9GYyvn/T PrjOOvK0Y2tJFlnv6Lrm6DvRzzyKUdejL+eZVI9+rXgA8xy8yqYhpPtQotcwVhsxRfwZ5SJb2Rni KKZrxzFAbOUenUe5VgyfVhF7m+1yrZDnWQH7vqOYqsZxjPYBbTIma2fRX44R69BX/zuGilXMcbXo K0ZjspjN86yK1MmsfYWlQNM5UdDax/VBLyLK11RPyq7z7SQBLcb2dtJAvq38frJQH8D5LtI3jZQp /3NklT6I7ZlkydU5Vup3s92FdFW+RrJbfI3jnyXPKd958kfBGkOcIC+w73FyhjWHqj6acskI7TXW Ib8mr9nwXrIkvLe1tCv4c0raau1DrBUj3Holtl7WIHoe8+tajLFriOhPZU6z64XoLpmb7XohepC1 Qa6qAzZjgJvv+Yzz7Bwe66nGMG/r32FtYudh5stoUFpPd34n86kH2GTOQqE5K3rJzomxKpkLxX9U julv57LoL+TZauet6JvGIZTaeSv6A+ao2SofnUFXN+/oT6LQziWxsXKMyiELkKnygTq3ow3SmnxS 8lw35+JJmV+MA7Ey5n6fYiLf0xTG4zPMfcns9zxjlIiXeQY8wmuSSTyPauARKagTKbELZAXpos6V Q7y/UtqtjHWBLF3nu+OeCeUYbHRDNcfP4/4/qveGbuRjk8NK0tNMRb45Fvm8727mbtSZz6BEItar vYzjs5J7nSpMbL3KAMZ9DEGJ2s8s7FH7ucyhmns0CHqz2tHnWczveAWZpqyvHJx6cJas9a7WW2eh ey6Tt+y60atfq+OMS/Y+yzrVrb14nzZHeS7U2Xtt9mGfiySEiOd9zvFp6r+iiyeBdiJZhM8bPizy dqJ+jPVdjOPfZ+3GwFax8Tc0qDqph8Mg7vdqxDerh4aaNczBqzHHWM9r67GFbHZqnHxZv/BevyHh 3moqXmqcmmQ3WeLEiqy73DpiJ2N2J2vu4byPODtejKc5JsB+l1Hh6c96ZyrbRehlPkHfOfInLNXf Y/2SQh1jfi9CX6OY8A1kDteUn/nfSOdzkbH1K57rJx2oGRMzWef1knmieQ7n/BNYE2QaeYy9PNZU ecxpdg4MybymH+ZYYtyLnh6B7mYARcZ05rHBTq4aQYZcy2eqxpB5pjfiZK5zzuYE/Q30M6L08+xm LG4zRqocOtl8E9vMKNsZiDNn03eCbGBsb+TafkL9KtKMvNglmZu53wl6kPfmwFh9XiJ2aHFiB34o 0V/AOlKo+D1jeyHeJQf0EqxgLihiHA+RMU2+L+PbrMUW+p6Sftdyj75Cklzr+JLEYUTIj1xr9GbN 15vvg2P1XtDEaeaEfdpX9SZtL9t3sf2gCDOHEL2J9STxTsDm5tB3SW/C8avvXAXWkRUiwnuKYL5Y iwJSJSbyXJ1Ifwb2k7Ib9eNcu8hyUkOqjf1YaoxnPdCEJWS8dhIb9FHYYDInmcxN3g8J84Z3nG09 e7BPwt+fq81v4mGzEVm8X3Dsw8Z3GUfxfB5NfB/iVe00l/p7JIPtPNoKPosk6of0fzJX1/P9fYm/ H+vZr551WiJmdhrJs6KJ5/tZxnhX3G/UoUi8ynP5AhaRHMZHP/0t2lSs0g+yZkvleZDK2I7HDLKX hEgZsYifLCXFJFeRzmezEb31x3kOhnkeNmKgvpjrOMJnMBPDGRuZ+jHkcj2zyEbiJ4vIGFKm1lzP +KlnvLJPq/UNbvf6kttaH9+PGdq/WUPsR6bYg0nid/iM+BZj5DQWMC+niDP0n2ad8hfk0OaI1zFH O4aFZO7tjBU7kaZdxAiRi3FiJuMyAz3ENI7JQbJIQz8xh3Nlce729jsQy9S7Y4pZRJhLzV6OHUby yClkK8ow3TxCGsjPMchcianUU5nbZT03o1M2ZtD3qPcU96uJeb0Jj5CFJIkUOnoe4TvEvbKv55MC Gc/meQw1TIzy/BIB7r1PvMv6rwmdZL0h6wCZMz1+nsWzscDoiQy+c9vJFnJKEY993nhtjGvjsrHd k8bfbqUYrMofaJNbIgpvHWYIGCfbxtzVEs+W9uFdDHQ63JrOH1wj7qn2c1eBzd2zHd5rm/gMoMvq j4d7QjZdWd12i7akR0Pb3LusJT1r20+vJW2TMOYGvNFBBzb3sbK6b9qt8akaoM+m9nH/Sy3pi/Zh ee5sEv/QPvqdu0b/394aA85dY2CfZjS0zeAS4IHaGzOk4dZIet3mQUH+1ZLhq9tHcs0nx4hn289I 7uFDh1sziu9E6tdbM3r+HcDLHXTQQQcd3ImkDXF4kUQ/Xj6bfQPqruPtmzOGvwvGxt0GJ26d8bUd 3C4TLgATWQNM2g6kr7GZcqGD/2E0wPBhD7xoJAL3YDj8rPwTtDUw5FXEYy8/dci/EvUptReX2dJg /6VohY7WEa9tcrRBvcvRHupGR3uxUnuRPTWjs5xTjHa0hj5ih6MF4sURR+v0/9jRBvUZR3uorzia 69F7YzcspCCZ/6lUWQigGCFUIkxKEaEvnSqEZerTR0+AKohhvDIJ5fy3kEtfGRbzWli1/LR+9q7m Zwl7pnNcOfssoi/AHgHVz08b4SjZ02IPi9bPeeTViPLK0Ra1/N4StipoQ1hKX+XVMW1fLb2le5Er Cqq55Gos5LMVUGuQ359H5VOtsPrOIL3DnRVUNruDYraqeDWi7lL2HrbbSklOTrWyAsWhynBlacRK rwwtqwz5IoHK4DBrUnm5lRsoWxwJW7n+sD9U7S8ZllsweX5uTlK6rzywKBS4WcsxViBs+QORxf6Q 5bNC/rJAOOIP+UusSMhX4q/whZZalfJKs2Zp2+uxAkGL01j5wUCE4/Mivog/bPmCJcM5QaX6guLK qmAkFPCHh30iYZOLAkzGfNocJF0XRLkqVKrokZt+854f7dr/bdA6BxdiCahFG38HO+vWUbH2UOcE LYPiCVesccXjrljtii+7YpUrVrriS674oitWuOILrqhxxXJXVLuiyhURV4Rd8Zgrlrmi0hVBV1S4 otwVS12xxBX/pbGu46LK/jCOc8RkGGV0wEC4dneOjYUNolwDxQAEbB0dexR1XTfs7u4xj93d3d3d 3fX7ss/v+ePs+3POvfeg+3Ldb0dGIiOBEc/owIhjxDJiGO0Z7RhtGW0Y0YzWjFaMKEZLRgtGc0Yz hsmIZDRlNGFEMBozwhlhjEaMhowGjPqMeoy6jDqMUEZtRi1GTUYNRnVGCKMaoyqjCqMyoxKjIqMC w8EozyjHKMsowyjNKMUoySjBKM4oxijKKMIozCjEKMgowMjPyMfIy8jDyM3IxcjJyMEwGMGMIEZ2 RiAjGyMrIwsjMyOA4c+wMzIxMjJsDD9GBkZ6hpXhy7AwfBjpGGkZaRipGakYKRnejBQMxfD6f6jf jF+Mn4wfjO+Mb4yvjC+Mz4xPjI+MD4z3jHeMt4w3jNeMV4yXjBeM54xnjKeMJ4zHjEeMh4wHjPuM e4y7jDuM24xbjJuMG4zrjGuMq4wrjMuMS4yLjAuM84xzjLOMM4zTjFOMk4wTjOOMY4yjjCOMw4xD jIOMA4z9jH2MvYw9jN2MXYydjB2M7YxtjK2MLYzNjE2MjYwNjPUMzVjHWMtYw1jNWMVYyfAwVjCW M5YxljKWMBYzFjEWMhYw5jPmMeYy5jBmM2YxZjJmMKYzpjGmMqYwJjMmMSYyJjDGM8YxxjLGMEYz RjH+ZfzD+JvxF2Mk40/GCAbHHsWxR3HsURx7FMcexbFHcexRHHsUxx7FsUdx7FEcexTHHsWxR3Hs URx7FMcexbFHORmcfxTnH8X5R3H+UZx/FOcfxflHcf5RnH8U5x/F+Udx/lGcfxTnH8X5R3H+UZx/ FOcfxflHcf5RnH8U5x/F+Udx/lGcfxTnH8X5R3H+UZx/FOcfxflHcf5RHHsUxx7FsUdx2lGcdhSn HcVpR3HaUZx2FKcdxWlHcdpRNdcnh0zNOriqITOzDvYXhmE3VAdXFJKwGwIG62BfwY3dIDAQDAD9 dVB1oZ8Oqin0BX2AC896Y9cLOHHYUwfVEHqA7qAbXukKuoDOOnttoRPoCBJBAojX2WsJHbCLA7Eg BrQH7UBb0AbfRWPXGrQCUaAlaAGag2bABJGgKWgCIkBjEA7CQCPQEDQA9XVgPaEeqKsD6wt1QKgO bCDU1oENhVqgJqiBZ9XxXQiohu+qgiqgMt6sBCri8wrAAcqDcqAsLisDSuOWUqAkKIHLioNi+K4o KAIKg0KgICgA8uPqfCAv7swDcoNcuDonyIHvDBAMgkB2EAiy6WxhQlaQRWcLFzKDABz6AzsOM4GM wIZnfiADDtMDK/DFMwvwAenwLC1IA1LrrI2FVDprhJASeOMwBXYKeP2H+g1+/feK+ondD/AdfMOz r9h9AZ/BJ/BRZ4kUPugsTYX32L0Db8EbPHuN3SvwErzAs+fgGQ6fgifgMXiEVx5i9wC7+9jdA3fB HTy7DW7h8Ca4Aa6Da3jlKnZXwGWdublwSWduJlwEF3B4HpwDZ8EZvHIanMLhSXACHAfH8MpRcASH h8EhcBAcAPvx5j7s9oI9YDee7QI7cbgDbAfbwFawBW9uxm4T2Ag2gPU6oJqgdUArYR1YC9aA1WAV WAk8YIUOkL+v1XLcsgwsxbMlYDFYBBaCBWA+mAfm4rI5uGU2mIVnM8EMMB1MwwdTsZsCJoNJeDYR t0wA4/FsHBgLxoDRYBTe/Be7f8Df4C8wEvyp/dsLI7R/jPAHGK7944VhYKj2N4Uk7S9/Gash2r+c MBi48fkgfDcQDND+cUJ/fN4P9AV9gAv0Br1wtROf9wQ9tH+s0B2XdcObXUEX0Bl0Ah3xXSJIwK8s Hp93AHF4MxbEgPagHWgL2uA3HY1fWWvQCr/pKFzdEj+oBWiOX24z/CATt0SCpqAJiND2EKGxtif/ hHBtT/7jHabtw4VG2l5UaIhXGoD62i5zgaqHXV1QB4eh2j5YqK3tI4Va2j5EqKntSUINnTFUqA5C QDVQVWeU/7+rKthV1raWQiVQUduS/2hUAA5tqyOU17YWQjltixLK4lkZUFrbigil8GZJbUv+jZXQ tuT/NouDYvi8KH5CEVAYlxUCBXFZAZAf5AN5tS3531IekBt35sKdOXFZDtxigGB8FwSyg0CQDWTV ftFCFu3XRsis/doKAcAf2EEmkBEf2PCBHw4zgPTACnzxpgVv+uAwHUgL0oDUeDMV3kyJQ2+QAijg FfI7Q4yRvH5liDV+Zogzfkh/l/VN1lc5+yJnn2V9kvVR1gc5fy/rnTx7K/s3sl7LeiXrpZy/kPVc nj2T/VNZT2Q9lvUofYLxMH2i8UDWfVn3ZN2VszvibVm3ZN2U/Q3xuqxrsq7KumLtbFy2ljQuiRet XYwL1nzGeVnnpM9aCxtnZJ2WdUqen5SzE9auxnHpY9JHpY9YOxmHrR2NQ9ZE46A1wTgg3+6X+/bJ 2isr5Pce+eduWbtk7fTtaezwdRrbfXsZ23x7G1tlbZG1Wc43ydoozzbIs/VypmWtk7VW1hpLf2O1 ZYCxyjLIWGlxGx7LYGOFrOWylslaKmuJrMWWosYicaGsBfLNfHGepbMxV3qO9GxZs6Rnyl0z5K7p ctc0OZsqa4qsybImyZooa4J8N17uG+cTZoz1CTfG+CQYo30WG6N8lhojvPMaf3g7jOHKYQwzk8yh niRziOk2B3vcpsWtLO5AdwP3QLfHfd0d0ii1zyBzgDnQM8Dsb/Y1+3n6mn08LjOly+7q7fL+4FIe l6rlUiVcKoWXy8+Vw+Xt29t0mr08TtPL2diZ5FzrTFlprfOOM4WXU/ls+b1nvTMwOFQMGeS0+oX2 NLubPTzdzW7xXc1O8svq6EgwEz0JZrwjzuzgiTNjHTFme0c7s60j2mzjiTZbO6LMVp4os6Wjhdlc 3m/miDRNT6TZ1BFhNvFEmOGOMDNMzhv9j5r6DmujDOA4fr87WtEULrRNQggYtLYV01ZQa3FyQElp UwoUogwFB+5RNeDW4qjioK17K+6BI9SqVaute4t7a3Fvi3sbvwf+3X+RN/d57973ueS5e578fsWx +PzeWHxecWV8bm9lfE5xNF7BKxu53tz8XMvrPsCCXJ7ECKmsMOSEBkKDoTQjlAytDVnj7Zxwjllg B1VeHdSi4OLgsqBlZ/dnm052wbSoHegPrAusD6RNcAIFM6KG3+vP91s+9938VfXRoXPJ7OFz0cyh d63yT5oStX2yfWGfWRH2ycgayBrMsnxrvP1e07Zl2ynbdGxutzPDmaY7pTItJ7NoVtTOCGeY7pTK sPxOBjvuL04dV1MftT1hjxkv8VR7TMdTUh51PNMLo4alfMmQl5OVzr0r5QtHrdVsGcYYQ1reV18X icRWpRsLY8n0muakupKT69zZqW1Kju1KGvGm5oY+aWljn8zy+uTEWG3T8HpJd7eRVxZL5tU1rLB6 evLKGmPJTvfacYauU+61wS2NkZZERyISaW9hakm0R4YOVupwVxF30z0S7azdT8fQ2ohscAzfxqk1 wWj/b699w1/6vw+N9AOM/tFn8DdtKE2Zpxtt5mk4FaegE4txMk7CiTgBx+M4HItjcDQ60I4EjsQR WITDcRgOxSE4GAfhQByA/bEf2rAv9sHe2AutaMGe2APNaEIjGrA7dkMc9ajDQtSiBtVYgCrMRwzz MBeVmIMoKjAb5ShDKRyUYFfsgp2xE3bEDijGLGyPmdgO22IbFKEQW2MGpmMaItgKBdgSUzEFk7EF JmFzbIZ8hLEp8pCLEHIQRDYC8MOHiZiA8ciCFzYykYFx8GATbIx0bISxGIO00hSzBROCYbSJPf2D v/EX/sQf+B2/4Vf8gp/xE37ED/geg1iP7/AtvsHX+Apf4gt8js/wKT7Bx/gIH2IA6/AB3sd7eBfv 4G28hTfxBl7Ha3gVr+BlvIR+vIgX8Dyew7N4Bk/jKTyJJ/A4HsOjeARrsQYP4yGsxoN4APdjFe7D vbgHK3E3VqAPSdyFO3EHbkcvbsOtuAU34ybciBtwPa7DtejBNbgaV+FKXIHLcRkuxSW4GBfhQlyA 83EelmMZlqIb5+IcnI2z0IUzcQaWGG2lnSL/Iv8i/yL/Iv8i/yL/Iv8i/yL/Iv8i/yL/Iv8i/yL/ Iv8i/zoKdIDoANEBogNEB4gOEB0gOkB0gOgA0QGiA0QHiA4QHSA6QHSA6ADRAaIDRAeIDhAdIDpA dIDoANEBogNEB4gOEB0gOkDkX+Rf5F9kX2RfZF9kX2RfZF9kX2RfZF9kf6R7eJSPxpF+gFE+sltb /hVgAGRK5q8KZW5kc3RyZWFtCmVuZG9iagozMCAwIG9iago8PC9YSGVpZ2h0IDQ2Ny9DYXBIZWln aHQgNjMyL1R5cGUvRm9udERlc2NyaXB0b3IvRmxhZ3MgMzIvRm9udFN0cmV0Y2gvTm9ybWFsL0Rl c2NlbnQgLTE5NC9Gb250QkJveFstNDc2IC0xOTQgMTIxNCA5NTJdL1N0ZW1WIDgwL0ZvbnRGYW1p bHkoQ2FsaWJyaSkvRm9udE5hbWUvUlZCWlJRK0NhbGlicmkvRm9udEZpbGUyIDMxIDAgUi9Bc2Nl bnQgOTUyL0ZvbnRXZWlnaHQgNDAwL0l0YWxpY0FuZ2xlIDA+PgplbmRvYmoKMjggMCBvYmoKPDwv Rmlyc3RDaGFyIDMyL1R5cGUvRm9udC9Ub1VuaWNvZGUgMjkgMCBSL0ZvbnREZXNjcmlwdG9yIDMw IDAgUi9CYXNlRm9udC9SVkJaUlErQ2FsaWJyaS9TdWJ0eXBlL1RydWVUeXBlL0VuY29kaW5nL1dp bkFuc2lFbmNvZGluZy9MYXN0Q2hhciAyMjQvV2lkdGhzWzIyNiAwIDAgMCAwIDAgMCAwIDMwMyAz MDMgNDk4IDAgMjUwIDMwNiAyNTIgMzg2IDUwNyA1MDcgNTA3IDUwNyAwIDUwNyAwIDAgMCAwIDI2 OCAwIDAgMCAwIDAgODk0IDU3OSA1NDQgNTMzIDYxNSA0ODggNDU5IDYzMSA2MjMgMjUyIDMxOSA1 MjAgNDIwIDg1NSA2NDYgMCA1MTcgNjczIDU0MyA0NTkgNDg3IDY0MiA1NjcgMCA1MTkgMCA0Njgg MCAwIDAgMCAwIDAgNDc5IDUyNSA0MjMgNTI1IDQ5OCAzMDUgNDcxIDUyNSAyMjkgMjM5IDQ1NSAy MjkgNzk5IDUyNSA1MjcgNTI1IDUyNSAzNDkgMzkxIDMzNSA1MjUgNDUyIDcxNSA0MzMgNDUzIDM5 NSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDkwNSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA0NzldPj4KZW5kb2JqCjEgMCBvYmoK PDwvVHlwZS9QYWdlL0NvbnRlbnRzWzIgMCBSIDMgMCBSIDQgMCBSIDUgMCBSIDYgMCBSIDcgMCBS IDggMCBSIDkgMCBSXS9TdHJ1Y3RQYXJlbnRzIDAvUGFyZW50IDMyIDAgUi9SZXNvdXJjZXM8PC9D b2xvclNwYWNlPDwvQ1MxIDEwIDAgUi9DUzAgMTIgMCBSPj4vRm9udDw8L0MyXzAgMTQgMCBSL1RU MiAyMiAwIFIvVFQxIDI0IDAgUi9UVDAgMjggMCBSPj4+Pi9Dcm9wQm94WzAuMCAwLjAgNjEyLjAg NzkyLjBdL01lZGlhQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1JvdGF0ZSAwPj4KZW5kb2JqCjM0 IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjUwNz4+c3RyZWFtCkiJrFdpc9tG Ev2uXzEfgS1zNAdOl8sVHd4kjuVSlkwltXJqCzwkIaZIhiIdy79++/UAAxCkRFlSlQgNMFf36zev ew6PlqvyshitxJs3h0erVTG6nozFxeFgvhB/Hh4fz7+Ki1RJq0VqLf7FkZFRHos0jmWubE6j+uvh 6m4xEYc/TYrxZCkOB/x2XlyVs2JVzmfi7dvj0xNxcDw4ODzpKzG6FUqI29Hs4HAwUEKLweWBkkpR YyR6VesfoQ0NU/iX0l8UySgTg5uDi+D9x7Bng/5Z+Ofg/YHCJIXxRpocrfFBIMLBX82SaFiMUNIY N+Ii6C/CXhRMwp4ORmEUlMU01CoQ5W1oAvzWvlt8CmhA/+fQBp9Caol5mAUzdIsTep3Owx6GJ8HY f+NPN1iQd0HnCo2Sp13R8q9CWhgD2JdJmNOAJPiHfjx3+ZlandEFv46pQ/TZsOUXMqmE9S07T6qf w8gZfIaJBXbjJQosyVNusDF/W3XA1FqqyOHPrVhbqdthcBgTGWzcBv0dx1hzjKXNaAmpI42nTV3M iU5xwnSifxG9ZZmwYjk5uPyX70ulyeo+JSn8rvvdWcWiD8fz8R0oe3by8ynNrgjWZdeJ+V9Fr1zm CXvDDZ0pkWray8CTN0qlR2/JdmKjdsOdLw07extcihggmam0JtMJAToFoHMX7h6TgQJ1G8aEtA2W 1GmDL/RWOsb1tOEOcY1xPA1jV4gaD5nh+5W4oTHcO8Q79/BG3OLRd9TKiB0YNGvvHPmdd26MlUs2 64rHFI4B/vTlMrF57WBj19zt02GLTEy6QQNEqhOmtAmTj0vPWKkovj1NUbaY/wLReBf2UodS4XCN WvaPxIhdgPsLIMXR2sKdv97WsFUfGbx7ImIdqm5xDgHeb7tAxdLovUjRQdsFleKIACo6cw6qLHoY KgAUe1k1W1Cds1iBvPA0Jn4kwR1RIyfoTDDD4yqEKwQPvrJerOAoRs9I7DKeizXWYzFi/TI8dLFe McNo2FUXhUQaFe9FYSdhdCRtnn0fYfah8B92MWdX13AHftfWw5/ZLScHxmQsMPQrAbdA15JPLSJf +c7wLKuJWEygcUlzxJqXqSBJgieiR0dmJ4fOPXJGe+QGA+Mw2MimSUSpsFHxrfmmNX8XhpolQiEK NhGDU8LwR2DnKE/HSaA1LkNNR8+hFAWUnjLupaSUBa87XiXS2n2MMHHDCOUZwTPJkqg+FGmynw6b hYGWcc2FY4L8ulJxUolygUD9QvmXPxYoDWb0qRhyPscrd1CGpgz8X6jBAAn8HeKNaP9GQPSPOIGj guBki5QtwRmCBCiwr8ic/UUxa/iv4s3KyWVVBLFbPe0qmkyiRaISXzWhWPA+0T8NM38gb1EN3BQl jJ3CqlFTwLBxgwO3FB08I/JUJsjJlNk7OXnDdpPel5M3bbabYfDG2zjDPo39RBpX1HnCUPreSxir dxHGUA3DKSdKXoIxp8yEv8qiKtcoR4ifQhAI8EVSe50p2gUdEeJoWX6rK76Zr9FEH6VgsWoK0N9C XTGnRBRd8QfqlTzojjeiOs1vxHRzzNsqkvWG8JIO1CgSGWsYd3AxeSwXH6zkrTYyEXGWoQxjWnr0 fHkKfMBDhyFQ8Z9B18JX57LGAjXxuiZrvUUiM6pd0/1ctffWj/dwNd30KTL5hk+gqtgiK+WsfWRN d5HVUv2bvRxZ/ygLpttd2L6NCKheUfpLCUsYE8wPuWaMEY3H0XEz5zoaWGQLT9HYJcBrzhKzYouo afokoqbfQ9TGwrijnllO/IlTwj1yRB0WgIx+X8noO/r9gEsb8hk+ckK/Xhes7ClhQhCN12iO+LZY K6lbNslxwdE6egQ78+cpaaTshiNPE9LI7hTSTOrs5VLvOVjn6DnlJ9OS6TWdFnzZvYW6MsuKSuPu oyJozAM/2UiJsStiNVN5Woq+73a6QVWlF88xL8dTSragZdFVnf6dgCOjO2umOFD78nn2nHxuE4ML axxHUlWU5DzeBgyKOPR5YwdoENB1dVMkJ4d19sFEOr21hNZbUZVMNDUx2LqXqVH8TKZmKZjq/Xsi U/OdKhrXTP0eFe3UuxtVYs417XqG6hYXQxX0Q1R2mhSN7hAkad9QA7PMfQxxFaVSmKVu7m5WUcCj xAe+b+A6CfTrG4pDiK8qgawEcOvoUHh0bdElAjonrVmKPiq4cuIuromLfHkJOqODRLeu7xas6fWI Jht0pDhvklfPWWL1pjR3LWvE+iL4QM5/xP0R++LHBxfnask5/xtvPt13dvIXkfXIUAFEydomIDgf Iig4NBpRo6DBJAQO6o4PM/ThBy0fLusj4heKkNPSHLXx3hMS6+edkFhplMON9U87IvHOaxQtap9Y Ffeaqqg5Ij/i2uc1lwm3LJ2sn7EWLb0GO+pNCPFv1V2qOlJ7K42oJmsDljR5bQKOA58LLmrO/K1u yQfEZRDOBE5IS1+C7iGjVs8ScmOhcLHOHQGv7gXKq/WNL3VvvUbXqyRgXaa5tNpLwGdeyyK6BHrL n0a+ZPeVLINivFglwXpTfq6zGxgjjrwWVvetqnNRCycjPfUTuvUFyHEvCRumndaVxnJY9/rb2C9c NOzhln4RobNU0VDShmJUFy0kIWjYEZfbqzmKAs5eC3iGBgsgGpBE6N+4FkOkuuFdJYIF5znXXn9u rl28YZTnKDR1lErziOo2+d67V5eQieZKpXbzsZw8byzwF9se3ePynEmoHxjvj5DioWJwes/I1KvE NlfTSmuJ9K3Sd+FLN9ZG4W+6qNNuytuwupR5AguuVQsvpDz3NR7bOTzJH4IhjTwMlZizta7wUX7y RfA+7PFRAXv4OQG7hY5ZsF+FvTQQRvGLds+uKc6AxOv0PQblbfQ6lVhPZ8i+Dv9xRW4w11VYl2VF 0aroAqthr8CQy53m7GBZIpX3ugC6o9GEBHkBAFZ4FBSBGRr0vRcT7psLRzJLH/Iws20P/d4V4rlu iRk594WvQjq4IReG5BraS+iaRfTVKzqlwnBT644hGRLFQ4ZkW0RtMnpPxzhhDdT/dtm6mAqXNbuk 5aCPubJsGLlpEJUvDyKTmwcMakNzxJsvqXrUOBIxHqy2Bi2FhyasTGf/WCbx1v6Q4pYJ/pj/faDj VMaJsDlpmsALBI7SLpTtdzFjVbtHlTup35hE5kijplblcxzxIYS34az2pMUZA6Zj9xFS/BoZSdSq ++v3mtfOEFTBtmypoBhsRUMrn5KwndVxvZdJnoiDNYro1IIBdyd4tyAfyb8b5BuXeHBFMiGCqRFM UwWz8v2RxrQrGM1parfXv/K0tuteFluLaXeelHCtlPzJEpm216sI9X8BBgDIbGOtCmVuZHN0cmVh bQplbmRvYmoKMzYgMCBvYmoKPDwvQ2FwSGVpZ2h0IDY2My9UeXBlL0ZvbnREZXNjcmlwdG9yL1hI ZWlnaHQgNDQ4L0ZsYWdzIDM0L0ZvbnRTdHJldGNoL05vcm1hbC9EZXNjZW50IC0zMDcvRm9udEJC b3hbLTU2OCAtMzA3IDIwMDAgMTAwN10vU3RlbVYgODAvRm9udEZhbWlseShUaW1lcyBOZXcgUm9t YW4pL0ZvbnROYW1lL1RpbWVzTmV3Um9tYW4vQXNjZW50IDEwMDcvRm9udFdlaWdodCA0MDAvSXRh bGljQW5nbGUgMD4+CmVuZG9iagozNSAwIG9iago8PC9GaXJzdENoYXIgMC9UeXBlL0ZvbnQvRm9u dERlc2NyaXB0b3IgMzYgMCBSL0Jhc2VGb250L1RpbWVzTmV3Um9tYW5QU01UL1N1YnR5cGUvVHJ1 ZVR5cGUvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0xhc3RDaGFyIDI1NS9XaWR0aHNbNzc4IDc3 OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4 IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3Nzgg Nzc4IDc3OCAyNTAgMzMzIDQwOCA1MDAgNTAwIDgzMyA3NzggMTgwIDMzMyAzMzMgNTAwIDU2NCAy NTAgMzMzIDI1MCAyNzggNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI3 OCAyNzggNTY0IDU2NCA1NjQgNDQ0IDkyMSA3MjIgNjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgNzIy IDMzMyAzODkgNzIyIDYxMSA4ODkgNzIyIDcyMiA1NTYgNzIyIDY2NyA1NTYgNjExIDcyMiA3MjIg OTQ0IDcyMiA3MjIgNjExIDMzMyAyNzggMzMzIDQ2OSA1MDAgMzMzIDQ0NCA1MDAgNDQ0IDUwMCA0 NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCA1MDAgMzMzIDM4 OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMCA0NDQgNDgwIDIwMCA0ODAgNTQxIDM1MCA1MDAgMzUw IDMzMyA1MDAgNDQ0IDEwMDAgNTAwIDUwMCAzMzMgMTAwMCA1NTYgMzMzIDg4OSAzNTAgNjExIDM1 MCAzNTAgMzMzIDMzMyA0NDQgNDQ0IDM1MCA1MDAgMTAwMCAzMzMgOTgwIDM4OSAzMzMgNzIyIDM1 MCA0NDQgNzIyIDI1MCAzMzMgNTAwIDUwMCA1MDAgNTAwIDIwMCA1MDAgMzMzIDc2MCAyNzYgNTAw IDU2NCAzMzMgNzYwIDUwMCA0MDAgNTQ5IDMwMCAzMDAgMzMzIDU3NiA0NTMgMjUwIDMzMyAzMDAg MzEwIDUwMCA3NTAgNzUwIDc1MCA0NDQgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgODg5IDY2NyA2 MTEgNjExIDYxMSA2MTEgMzMzIDMzMyAzMzMgMzMzIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcy MiA1NjQgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNTU2IDUwMCA0NDQgNDQ0IDQ0NCA0NDQgNDQ0 IDQ0NCA2NjcgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCAyNzggMjc4IDI3OCAyNzggNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDU0OSA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwXT4+CmVu ZG9iago0MSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDExPj5zdHJlYW0KSIlq AAgwAACBAIEKZW5kc3RyZWFtCmVuZG9iago0MiAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDI4My9TdWJ0eXBlL0NJREZvbnRUeXBlMEM+PnN0cmVhbQpIiWJkYGFiYGRk5PMN8Q2L ctQOrsxNys8BiRj/kP4h080j90OW8Yc4yw85HtHfHr93/rr2q41VloFh+Rfe79w8St+L+L9XCH4v 5VH9vpxHhYGVkZGNL7Ox3TElPynVMyU1rySzpNI5v6CyKDM9o0RBI1lTwdDSwlQHRJqDSUsQaWkA Js0VwPoUgiuLS1JzixU885LziwryixJLUlP0FBxzchTAxhQrFKUWpxaVAQX1/YEibvl5JSGVBakK +iDSUCElNQ3qCyAoAxFMjIwsWt/7+H4kfGf9/odx7/c/zD/0vu8UfWd1R0PdykqjR079ttX7Hrl3 d26/l+cDeZ7zhzyP2ozvW4Qq5v00nfU7dgbbc64H3AABBgDK4WjiCmVuZHN0cmVhbQplbmRvYmoK NDAgMCBvYmoKPDwvQ0lEU2V0IDQxIDAgUi9YSGVpZ2h0IDUwMC9UeXBlL0ZvbnREZXNjcmlwdG9y L0NhcEhlaWdodCA3MDAvRmxhZ3MgNC9Gb250U3RyZXRjaC9Ob3JtYWwvRGVzY2VudCAtMjkzL0Zv bnRCQm94Wy0xODAgLTI5MyAxMDkwIDEwMTBdL0ZvbnRGaWxlMyA0MiAwIFIvU3RlbVYgOTIvRm9u dEZhbWlseShTeW1ib2wpL0ZvbnROYW1lL01UTVZaQStTeW1ib2wvQXNjZW50IDEwMTAvRm9udFdl aWdodCA0MDAvSXRhbGljQW5nbGUgMD4+CmVuZG9iago0MyAwIG9iago8PC9PcmRlcmluZyhJZGVu dGl0eSkvU3VwcGxlbWVudCAwL1JlZ2lzdHJ5KEFkb2JlKT4+CmVuZG9iagozOSAwIG9iago8PC9U eXBlL0ZvbnQvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDQzIDAgUi9Gb250RGVzY3JpcHRvciA0MCAw IFIvQmFzZUZvbnQvTVRNVlpBK1N5bWJvbC9TdWJ0eXBlL0NJREZvbnRUeXBlMC9XWzExOFs0NjBd XT4+CmVuZG9iagozOCAwIG9iagpbMzkgMCBSXQplbmRvYmoKNDQgMCBvYmoKPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCAyMzA+PnN0cmVhbQpIiVyQwWrDMAyG734KHdtDcerDdgmB0THIod1Y tgdwbCUzLLJRnEPefooXOpjABvn/P/Fb+tI+txQy6DeOrsMMQyDPOMeFHUKPYyB1NuCDy3tXbjfZ pLTA3TpnnFoaoqpr0O8izplXODz52ONR6Vf2yIFGOHxeuiPobknpGyekDBU0DXgcZNDVppudEHTB Tq0XPeT1JMyf42NNCKb0598wLnqck3XIlkZUdSXVQP0i1Sgk/0/fqX5wX5Y39+ODuE1lTHHv7xsn 34N7KLcwS56ygxJkixAI72tKMYFQ21E/AgwApHJvnwplbmRzdHJlYW0KZW5kb2JqCjM3IDAgb2Jq Cjw8L1R5cGUvRm9udC9EZXNjZW5kYW50Rm9udHMgMzggMCBSL1RvVW5pY29kZSA0NCAwIFIvQmFz ZUZvbnQvTVRNVlpBK1N5bWJvbC9TdWJ0eXBlL1R5cGUwL0VuY29kaW5nL0lkZW50aXR5LUg+Pgpl bmRvYmoKNDcgMCBvYmoKPDwvUy9VUkkvVVJJKG1haWx0bzp2dW1pcDFAZ21haWwuY29tACk+Pgpl bmRvYmoKNDYgMCBvYmoKPDwvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90L0JTPDwvVHlwZS9Cb3Jk ZXIvUy9TL1cgMD4+L1JlY3RbMjU4LjcyNyA2MDAuOTczIDM2MC45MTQgNjE4LjQ1OF0vU3VidHlw ZS9MaW5rL1N0cnVjdFBhcmVudCAyL0gvSS9BIDQ3IDAgUj4+CmVuZG9iago0OSAwIG9iago8PC9T L1VSSS9VUkkobWFpbHRvOkRpamlhbmcuSHVhbmdAYXN1LmVkdQApPj4KZW5kb2JqCjQ4IDAgb2Jq Cjw8L0JvcmRlclswIDAgMF0vVHlwZS9Bbm5vdC9CUzw8L1R5cGUvQm9yZGVyL1MvUy9XIDA+Pi9S ZWN0WzMxMC4yNiA1ODMuNDg5IDQzMS44MTggNjAwLjk3M10vU3VidHlwZS9MaW5rL1N0cnVjdFBh cmVudCAzL0gvSS9BIDQ5IDAgUj4+CmVuZG9iago1MSAwIG9iago8PC9TL1VSSS9VUkkobWFpbHRv OmJhaXh5QHRzaW5naHVhLmVkdS5jbgApPj4KZW5kb2JqCjUwIDAgb2JqCjw8L0JvcmRlclswIDAg MF0vVHlwZS9Bbm5vdC9CUzw8L1R5cGUvQm9yZGVyL1MvUy9XIDA+Pi9SZWN0WzI4Ny41MTQgNTY2 LjAwNCA0MDUuOTczIDU4My40ODldL1N1YnR5cGUvTGluay9TdHJ1Y3RQYXJlbnQgNC9IL0kvQSA1 MSAwIFI+PgplbmRvYmoKNTMgMCBvYmoKPDwvUy9VUkkvVVJJKG1haWx0bzpwYW9sby5iZWxsYXZp c3RhQHVuaWJvLml0ACk+PgplbmRvYmoKNTIgMCBvYmoKPDwvQm9yZGVyWzAgMCAwXS9UeXBlL0Fu bm90L0JTPDwvVHlwZS9Cb3JkZXIvUy9TL1cgMD4+L1JlY3RbMzYwLjM3NSA1NDguNTIgNDkwLjA2 MSA1NjYuMDA0XS9TdWJ0eXBlL0xpbmsvU3RydWN0UGFyZW50IDUvSC9JL0EgNTMgMCBSPj4KZW5k b2JqCjU1IDAgb2JqCjw8L1MvVVJJL1VSSShtYWlsdG86c2NodWx6ZUBsbmNjLmJyACk+PgplbmRv YmoKNTQgMCBvYmoKPDwvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90L0JTPDwvVHlwZS9Cb3JkZXIv Uy9TL1cgMD4+L1JlY3RbNDIwLjAxOCA1MzEuMDM2IDUwMy44MTIgNTQ4LjUyXS9TdWJ0eXBlL0xp bmsvU3RydWN0UGFyZW50IDYvSC9JL0EgNTUgMCBSPj4KZW5kb2JqCjU3IDAgb2JqCjw8L1MvVVJJ L1VSSShtYWlsdG86Z3JlZ29yaW9AdW0uZXMAKT4+CmVuZG9iago1NiAwIG9iago8PC9Cb3JkZXJb MCAwIDBdL1R5cGUvQW5ub3QvQlM8PC9UeXBlL0JvcmRlci9TL1MvVyAwPj4vUmVjdFszMjAuNzcx IDUxMy41NTEgNDA2LjYyOSA1MzEuMDM2XS9TdWJ0eXBlL0xpbmsvU3RydWN0UGFyZW50IDcvSC9J L0EgNTcgMCBSPj4KZW5kb2JqCjU5IDAgb2JqCjw8L1MvVVJJL1VSSShtYWlsdG86Ti5BbnRvbm9w b3Vsb3NAZGVyYnkuYWMudWsAKT4+CmVuZG9iago1OCAwIG9iago8PC9Cb3JkZXJbMCAwIDBdL1R5 cGUvQW5ub3QvQlM8PC9UeXBlL0JvcmRlci9TL1MvVyAwPj4vUmVjdFszMTIuMCA0OTYuMDY3IDQ2 My43ODEgNTEzLjU1MV0vU3VidHlwZS9MaW5rL1N0cnVjdFBhcmVudCA4L0gvSS9BIDU5IDAgUj4+ CmVuZG9iago0NSAwIG9iagpbNDYgMCBSIDQ4IDAgUiA1MCAwIFIgNTIgMCBSIDU0IDAgUiA1NiAw IFIgNTggMCBSXQplbmRvYmoKMzMgMCBvYmoKPDwvVHlwZS9QYWdlL0NvbnRlbnRzIDM0IDAgUi9T dHJ1Y3RQYXJlbnRzIDEvUGFyZW50IDMyIDAgUi9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1Mx IDEwIDAgUi9DUzAgMTIgMCBSPj4vRm9udDw8L0MyXzAgMTQgMCBSL1RUMiAzNSAwIFIvVFQxIDIy IDAgUi9UVDAgMjggMCBSL0MwXzAgMzcgMCBSPj4+Pi9Dcm9wQm94WzAuMCAwLjAgNjEyLjAgNzky LjBdL0Fubm90cyA0NSAwIFIvTWVkaWFCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vUm90YXRlIDA+ PgplbmRvYmoKNjEgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNDg+PnN0cmVh bQp4nEWNQQ6CMBBF9z3FLHVhO20pFJdG3Zv0AgYVIZQCYnp9p3RhZjE/+S//zWwGqSwgnTZcgS6h qpBbaDyIzrcI5wA3orTBjSroE6Rq/YdkhghjJ8eotViCezCEwzaao7QpiKskI7gX273XdToKEWPk n2npxva58CZ40YfvMt4HIbFWau96lrx5ozB1ShdHsh/W3y0PCmVuZHN0cmVhbQplbmRvYmoKNjIg MCBvYmoKPDwvVHlwZS9YT2JqZWN0L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTM2MC9IZWln aHQgNDQvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2VbL0luZGV4ZWQvRGV2aWNlUkdCIDI1 NSj///9Pa5APNmgAJVsvUHtxiKXymDqltMaNn7fQ2OLFztq2wtHh5uzudwDn6/Da4Ojx8/bt8PP3 +frz9fgAIFf29/n9/f77/P35+vv8/P3++fT9/v7+/v7+/v////7++/gAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApXS9TdWJ0eXBlL0ltYWdlL1dpZHRoIDE2MD4+ c3RyZWFtCniczVjt2uIoDC0hLGnplrZi1XE6c/93uQlQ7Ye++vo46+SPlAZ6CMlJYlHMhABd8ZdK Q1SS1qH6NJA7UoWgQZug9qPznwZzQxqNqLXHABhw/2k0NwSw1vqg2IghgOn6X58GtBKEA0JhQtU4 pTWA+TSgpTiNh6ErVAyQ2oSAn0a0kA6CG/m3MnV8riCozyKay4EgBLuYaiDQh9BspQpa2X455yHg X0KGZxPssV6DsSHcyCbeGmNseXpm3/5dPAUcuwHWs2qLr1HMPiLwhGktwHtcxARzRpUCoziqzCxj tYnhGjTY2hNz5OMv96C17t4AzwVoi2Z6agKOeYi6XiiOqCHmPvbNx/S4F3zNQ7WHwtQyv6zySiy0 ihDHYTS9eYK+2czvuF+1/Ja9Pnod7DB7ZbTO79qgzo93bt5gPTFSBpZsM48KWMYM573JI83/RY7l xUe4tiJDBmA3A7SwANtPr0P6D5c6PWpSqd6jSB16ftsmlDPdwTE+mAP0Fk1xIoVm0qut6kan4pb7 0qS9Bk88cArVNUd5QlTk93Vp4+c7ec57J31C07KFjE8gbADrKgowowRa0gjHL4uZglpohvMOp0ae JXbUneKQDSfiQ2LhkF8opoIaeRZrJVrBHPLJWQVjSRxidDrOVqLPw5L1eb2K2hioVEX5i8NWqGPA RRpepxAvAKU6jE9O4GjNXiG/JNTJA7AMRPApeVdETudZDYZ4ddpvNJFAK3mBFD+kq2Iw8fJ8XEiy ixImc6y9L1BW9riOZbUk2E7W8qY0WYENw/mx5i8zh0ZvBjap0vYsDpPpyIrV2XB7zDNMVJjXx2ev dTQLH08um2QXYxFKOQNIanNi2iOuiiq7KmpYqnjHWgnvDJQJZxBLiGqnU4g3GVbazuW4P1MeqLyu zAzOVXuR5ynp8/ux7xIGRutV8EW7hif4hmItLnnhIZ0/OxTPmVG6GK0vlL7BJzOYteMNiHoZf9BZ S+LQJunDcdplJKOClMu7DTyOj1v98CA8I17N9pj8QWVfy/f8Nb4DZvsJPp/uP1UdqQF3V55Ny6Rk Om3hsX1upzGj0wfEfsdpxgzpgxePvW+/ieir9Ctu6KrK1+1xqT8Z5DRI3tjA47pwXoDU6sKGED99 td+QAjLa70Lp9/FxPRwvWKV4vubN4ia+uPRW14t6WTlcdpHrPM3tx+xWFk/bL14Ah3lIbihhM/fz G/jOuEgVWZb5t9aXxxSAV/udIO34pP3iiNlZVdP7haPfwMdV1TZS6+WVcyE20Q3qeJxL/NpkPuEX eMZ+e6Wp9lOil0oR0npqb+OjLdMJjS7S2wB5F8krYrfIZz5umJcv7pc2sKaBxSUAEs43VcVtpJ/r ZzkoTnm4FcaDcwtKlqCyKbl7V6cx2Y9tZJjgI7w25TQbD+FtzHoVlwxCmMYXfRqUclDZSCQ7Q0pL fOPchGd9e63de4S7MsfHCTd1R5jsKvbT8e+a9BnhVQAdveJg0gMUeaAki8kA87kiHp05gS0nxYZP hxa1eUgf98c70i+74saRMVRN3aUQV+2qSefQdS1L10ptvcvjok+DffEzvu7E62JFkSUB7CubCq2s 33arfvwFOZO+Q+APhZMBEWcuPcXQH5Fr/v2eNDhFHocC/HwrppnM8u+3ZF6IcMv6ygmfk2v++O4y mto/tU1lG/nxzxfy1cIX7admbotP9Mg//r0vX+KT+B2/Uri7DDK70TP/g76IzxFEIv323/0+9oHM H40J+EQP//u1+0XhUXiFYhzEzogbONU+1n5Vdu1OpH0hQmoTm05zo2b6O2RfEdnqsfH+Az90QFsK ZW5kc3RyZWFtCmVuZG9iago2MyAwIG9iago8PC9UeXBlL1hPYmplY3QvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCA0NzkzL0hlaWdodCA0NTAvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2Uv RGV2aWNlUkdCL1N1YnR5cGUvSW1hZ2UvV2lkdGggMzUwPj5zdHJlYW0KeJzt3X+EXVceAPDHioio ChUrYlSJGFFjlBERUVUqKiIiVFSsGEuMtaJqqVpRay1VK6LWsFbUbEUZEaOqSkStiLWsiIiqUCsi okKsWFHx9muuHjf3nHvffdP8mE4+nz/ivPPOPffcO/f8uC/vft9wCAAAAAAAAAAAAAAAAPBsGQwG q3BfZ86cmZiYyMtHTry1sjp/ose3o7zmW7duzc7OPvfcc7/4xS8Gyx7TrscVLfn444/Ty7/85S+r p208WqtzZFi3bt29e/eKNezfv//OnTs969ywYcNYLezwJEeGmZmZ06dP//DDD+NW9QiPtyiaumfP nvRy7969P/eR4XGfsZ+v9Je9ffv2a6+99vzzz8e/kW68W09H4sKFC1NTUzGjpZcvvfTSxo0b//a3 v1Vlzp07F5d3dPCtW7cuLCzktSX5fgc/Krb26tWrMZ/mrfrf//739ttvRxump6dv3rzZqGfHjh03 btyIRLwVOd98802k//Of/0xOTnYce+Mwq/zPP/983759ebdtO+T85IR33nkndhet+uyzz/Ijjcu1 OoTKf//736jhwYMHKef+/fvbtm37+9//Hvuq1hX5ectPSFXm7NmzsVUsSKLB3377bbThxRdfjHRV YHFxsV5nfv6jzuvXr0f67t27Bw8erBfrfwaKJWPAf/311+PYT5w48ROPom2rRks6rjTSafn1r3/9 pz/9KRLx77FjxxrvDh8eGd56663oVullXCHR76K7bd68uco8fPhwdOFIfP3119EF8tqSkfvNW/vu u+9GtY2Sv/vd76qFbixxf/WrXzXeff/99yM/EvPz83HZnzx5sir529/+tqMNjcOMfz/99NPdu3cX 1zNth5yfnD/84Q9//OMfh8td/sMPP8wP9ssvv4yOk67zMDc398knn6SXf/7zn3//+99Hv/juu+/y 89N9QqJrXLt2LdoTXSkWYFV606ZNVYG8zkb9X3zxxQcffBDpaE/c2dX32P8MFEseP348Rt1I1EfL lR1F21Z5SwwLbdKZibMaF2ok4rIv9uX6yFCfMeNlteGw5TzXN8zfHbnfvKqYEWJyiXmzXvKXv/xl zGKRiLk1r+ef//znm2++GYmY7o8ePfrGG29EOnK++uqrjjY0DvPUqVOvvPJKtZdu9UPOT05M9/VK igf7/fffx76itZGIl3Hl79y5s3orDjBqiLXN9u3bYyiLs1Gsqu2EVF0yT1eJvM7GcUVtMTZG+tCh Q/En6P5LtZ2BYslocFoXjfyzdh9F21Z5S4wMbYqnKJZ5eWbbySyWiXnnyJEj6TO04oY991ssHPNp LAMarUqq9X+jnlh8RsePJsX1HEvWKl1din3aEC9jro8Rqa3XjDzklE7N6z7Y2FFMfNUgFiIR41sk IjNuRobLw8WuXbuiF8Q8Xtxd9wkppvM686bGQuvSpUuxoGpU0v8MFEumMz8c58/adon23MrI0CZf M8S/+ZwbmWONDHHfF+vkatXdc81Q3G9ba8OBAwdiskg5ExMTeZ+tl5+dnY2rMdaxkY6rOtLVtd2z DdXLuBlpGxxGHnJKx31u/UOD7osz9Ze4xYh752rBkO5xhsufe0RHzqsaeULa0o06883//e9/x2I+ 1vyNDfufgWLJGCjykis7iv5bGRnapDMT99fVvXbMjHHfXWVu2bIlbspu3rwZ3XCskSEu/suXL8dl vLS0FJm3bt3KN+zYb5+RIW4YX3vttZQTd+7VJwl10Yz0AVS0JKaPs2fPDpc/Loh0+kCsTxvSy7i5 jtuQ/BPIkYec0rGL6kODaNvc3FzHxRntnJmZSS8nJyc/+uij1MLKlStXUi+uH2/xhPQcGep1Fjd/ +eWXG3dzY52BYskY92IpGJknTpxI4+HKjqL/VvUzRl36E8T9bPX5fMyJ1b1tiD/f9PR0TFIXLlwY a2RYWFjYtCz62vHjx6sPfIpdoLjfPiNDiG5Sz3nvvfdisqgvUGPuSzNRXHJxGVQ9OtYGUSxdEn3a UH8ZK+0YKhuDw8hDTuk7d+7s27cvGhMzb1SVH2y1DF6/fn3cQdSXB3EfEfmx4K8Xi0NOK//68RZP SM91eL3OtpOQ5/Q/A8WS169fj6Evzsn58+d/4lH036pxxqhcvHixPiWxyi0uLqY7oDUsBqW413va rXh2xZQUg+o//vGPp90Q+pqamopV3NNuxeMSS4i4JmMG379/f3V/AQAAAAAAwLNgkCmWaSQe1a5X sNXS0tLU1NS6devqre1udlFHZJjKhg0bdu/eXT1v1W3wk4OZ/JQDgcehz1WXl3lawS4uXry4efPm /AsYK+g7HZFhqsT9+/fn5+c3btx46dKl7qoGPzmYie/ws9q0XYrFuCJVorG66BPzpHvXg5bYJrn9 +/efPn26WFVeQ6q/O6LLsP3rteHUqVPVs9sdBp3BTIohRIbtZ7jjQOCJKV51bXFFil2pT8yT7l0P SvE0ip577rniQ47FGlL93RFd2lpViTMQnbSjSdUmHcFMinvvOMNCi7AaFD9kaIsrUhwZ+sQ8adt1 SnRH9sg3yfM7InJ0R3QZuYt60IC2TTqCmRT33nGGhRZhNShedW1xRUYuvztinuTjT3dtxU1i+m5b M3S3NikG8Wirarj8DOaWLVuKJRubtAUzKe595Bluy4Qno3jVtcUV6V4z9Im7Utx1x21+Q9zyz8/P dx9FXu3IIB4d+SdPnjx69GhHk9ImbcFMinsfeYbbMuHJKF51bXFF6nN3+jBtrLgrxV33HxkuXLjw wgsv5HEDujvUyCAexfy4G/rrX/+6devWjnCpjU2KwUyKex95hosHAk/MIDNsjyuSEvVgF2PFXWns Oi88csPFxcXJycnG77OM7FBjhf6obNiw4eDBg1Xw+e625fmNnHzvI89w24EAAAAAAAAAAMCzqfoW za1bt2ZnZ9PPjw6Wf02skVMVPnPmTL55t2+++eaDDz6Ymppq5C8tLW1fFol6/qVLl/bs2bN+/fr6 d5mShYWFkTstfn0rzx9ZvqORDY2fkxvZvP6FH7lx9z43N/eYWsJqVl0nMzMzp0+frj8dmedUhffv 33/nzp3G5t3efvvt+fn5RsmLFy9G9/9+2auvvhovq/yrV69OT09fuXKlWFXk79q1a6xr+5NPPokG 9G9tvXxbIxtiCK0el3gknlZUnDZxaGONe6wNVWeJq7Hxo595TlU4em50hMbmwx6drlEgRpgLFy5U 6a+//nrfvn1V+siRI/GyWEOMSDt37rxx40b/keHevXuxVun/ne1G+bZG1sVwceDAgVT/559//tJL Lz3//PORWd9vPY5N/aQ14rTki5bK7t276z9NFcuqyCnGhGnsa3FxcevWrcWvhXeE3GmEjjl06FDb qMhaVV0nX375ZSwSzp07l/LznFT43XffTZ23fydtlIz7lPSwYSTSUxgvvPBC3C9MTExs27atMREf PHiwuj777/S9996rHlxKbVi3bl30mmJgqLx8WyPr3nrrrThXqf5jx45VnfSLL76oP19Wj2NT76Q9 47TEgHP48OH0Mrpq/GnaItLU9xVtbjwRlupvC7mTN+mrr756Fn5Mk7p0ncQE98orr8S0mGa6PKcq HFPV66+/nj9U2HNHxZcpsEPMbrEmuXv3btQfiTRtxdWb+mzPnV6/fj1uPRqZ0cH/9a9/xSxZHwHa yrc1si7m3OpUNMrXR5LBw3Fs6iND/zgtk5OTVX+Pnr59+/Zhe0Sa+r6iZJy6+mPgqf62kDt5k+IA UwGeEfXrMK6fmIPeeOONtpxUOCas999/f/iI1gxxJadOFEuFlB+XaCwe0uZjfagYYj3fdmMSY92O HTsamXn5tka2HVejAW1RYoqDwMiRIf4QsVobLq/ZTp06NWyJCdPY/Nq1azHcxRiSHl0v7qgYcqdY gGdEfh3m10Dxsol+dPXq1RWPDPVb+EikKKyxTkifcMZUFYuWPm3OxcIgXzAkUXMMQSPLtzWyrrFm SL/gHJn1NUOx/WONDFFh3P5H/SkUTP+INHEzEoNDo8DIkDvWDM+yxoX06aefzszMtOXUC8etaKzJ VzwyXLx48dVXX41B4Pbt23v27IlLt8q/fPnykSNHYpEcc/Tc3FwepCWvqijuu9vCUEflR48ebXzU UCzf1si6uP1Pv0kRDYsBs7qvn5+fjwMpNrh7ZKhHxWk4ceLE1NRUtVobjhOR5sqVK/nIMDLkTkqf P3/e5wzPmsGPX1QI69evjxuH6mY2zxlmV91HH300cqZLVeUL/qWlpZi4Y+Y6efJkvfzCwkJMjps3 b277r8A+I8OWLVvSxyP1DWPVvXPnzhju+pTvaGTS+L+JS5cuvfjii1E+MtP6YayRoR4VpyEGqPiL 1MeN7og0wx9PfpTJ7yZGhtxJ6UOHDuW/8QF0izug6gtg/VdQPyMxivo+A6zMb37zm/g3JvSn3ZBH rzo0AAAAAAAAeHwGTylyS9vXnwaZen71pGR6trHjoDoqafvaVR6hpa1wruN//J/Klxye8E7H3Z1o MKvf4ClFbumzYT2ISnLt2rX0mFUfxUqG/SK09LzguyO3jNtrVlvklsdBNJjVb/CUIreMLN8IopI8 ePBg06ZN3duOrKRnhJY+nbr+7ei2UCod78Ywu3fv3lgLpVVZY5FTD8PSP9ZKqqFRf51oMHQYPKXI LYMxg6hUoi/HQrTtUameleT5bRFaRjZy+HDklrZQKh3vHjt27NSpU2nvw4dP1ODhMCz9Y62kSvL6 E9Fg6JD+pk84cstwzCAqwx/n02JPLypWUsxvtK3+HHpHIyv1p7DbQql0vBvrn0a3bYwM9Ru6/rFW UiKvv040GNrUr8MnGbkl6RlEpRIXbUz38/Pz9WrbPiRsq2QFEVqKjcyPq96SPJRK8d2UaKuw7a3u WCspkddfJxoMbfIO+2QityQ9g6jU9Xlwqa2SlUVoyRuZ1NcM3aFUiu9G/8o/5i2mh+PEWqkvVBr1 N45LNBiKGn/0Jxa5pdI/iEoS030x0FNDWyUriNBSbGRSj9zSHUql+O4777wT+fWceuSWxknrH2sl JfL6G0SDoWjwlCK3DMYMovLZZ5/F7Fa1p/HxV1FbJJaxIrR0NDKp/9/EcFQolfzdmFv37t1bz6lH bmmc1f6xVjrqbxANhp+12dnZ9L9gq02K3EJPosHwjBDeZCxOFwAAAAAAAA39v8e4mvdVjA8zbAnJ Es6ePTs5Ofnyyy/XQytU3+FZt27drl27vv3225H5sIatjZGhGB+mLSRLjAZzc3M//PDD7du333zz zcXFxfpWDx48+Pjjj6enpxu7aMuHNSn1prawG3nJwcOhPAal0Bznzp2bmZmJeXbr1q0LCwt5bfVq 882Ljel/LJW2kCzRu9NzRjdu3Ni9e3deVdtzW2vyh6ggl3pTW9iNvOTg4VAeg1JojsOHD1+9enW4 3CWLj93Vq803Lzam/7FU2kKyxE3EvXv3Un4eYC3Gk1hj5PW35cPakz9C2wi7kZccPBzKY1AKzVHc Rdu7+ebFxvQ/luLL9Dj5+fPnZ2dn79+/f/fu3RiCGg+e37x5M1Y7MVI1Km/LhzVpBWE3OjpgSn/3 3XdHjhxJ0aeLG/bcRf8QHx1rhkZIlrNnz8b9y8TExJkzZ+ohZ2PdEjcdeQzMtnxYq3qG3YjMsUaG HTt2fPjhh9WifQUjQ7Ex/Y+lMjIky3D585AU5Dw6fpRJC5ikLR/WsO6wG1u2bInpMrrGgQMHxhoZ Nm7cePny5Ziyl5aWBss/YJFv2LF5sTH9j6XSHZJluDxcTE1NpRuEvXv3Xrt2La+2LR/WsLRWL4bd iN49PT29bdu26ERjjQwLCwublkXXPn78ePXRYv+RYWQMkLySPD7MsD0ky2A5Lk0sKvLvLeSVtOXD WhWzaiO8G/CMi0lzYmJC0C0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgMr/ATFoOFIKZW5kc3RyZWFt CmVuZG9iago2NCAwIG9iago8PC9UeXBlL0ZvbnQvQmFzZUZvbnQvSGVsdmV0aWNhL1N1YnR5cGUv VHlwZTEvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nPj4KZW5kb2JqCjYwIDAgb2JqCjw8L1R5cGUv UGFnZS9Db250ZW50cyA2MSAwIFIvUGFyZW50IDMyIDAgUi9SZXNvdXJjZXM8PC9YT2JqZWN0PDwv aW1nMCA2MiAwIFIvaW1nMSA2MyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VD L0ltYWdlSV0vRm9udDw8L0YxIDY0IDAgUj4+Pj4vTWVkaWFCb3hbMCAwIDU5NSA4NDJdPj4KZW5k b2JqCjMyIDAgb2JqCjw8L0NvdW50IDMvVHlwZS9QYWdlcy9JVFhUKDUuMC40KS9LaWRzWzEgMCBS IDMzIDAgUiA2MCAwIFJdPj4KZW5kb2JqCjY1IDAgb2JqCjw8L1R5cGUvQ2F0YWxvZy9QYWdlcyAz MiAwIFI+PgplbmRvYmoKNjYgMCBvYmoKPDwvQ3JlYXRpb25EYXRlKEQ6MjAxMTAyMTgwMjAxMDQr MDEnMDAnKS9Qcm9kdWNlcihpVGV4dCA1LjAuNCBcKGNcKSAxVDNYVCBCVkJBKS9Nb2REYXRlKEQ6 MjAxMTAyMTgwMjAxMDQrMDEnMDAnKT4+CmVuZG9iagp4cmVmCjAgNjcKMDAwMDAwMDAwMCA2NTUz NSBmIAowMDAwMDQ5OTI0IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMDg5NCAw MDAwMCBuIAowMDAwMDAxNzM1IDAwMDAwIG4gCjAwMDAwMDI1OTIgMDAwMDAgbiAKMDAwMDAwMzQw NyAwMDAwMCBuIAowMDAwMDA0MTA5IDAwMDAwIG4gCjAwMDAwMDQ3OTEgMDAwMDAgbiAKMDAwMDAw NTU2MCAwMDAwMCBuIAowMDAwMDA4ODk5IDAwMDAwIG4gCjAwMDAwMDYyNTIgMDAwMDAgbiAKMDAw MDAwOTIyMiAwMDAwMCBuIAowMDAwMDA4OTM0IDAwMDAwIG4gCjAwMDAwMTM1NjMgMDAwMDAgbiAK MDAwMDAxMzIzMiAwMDAwMCBuIAowMDAwMDEzMDUzIDAwMDAwIG4gCjAwMDAwMTI3MTQgMDAwMDAg biAKMDAwMDAwOTI1NyAwMDAwMCBuIAowMDAwMDA5MzM1IDAwMDAwIG4gCjAwMDAwMTI5ODQgMDAw MDAgbiAKMDAwMDAxMzI1NyAwMDAwMCBuIAowMDAwMDEzOTIzIDAwMDAwIG4gCjAwMDAwMTM3MDIg MDAwMDAgbiAKMDAwMDAyNjI4OSAwMDAwMCBuIAowMDAwMDE1MDk5IDAwMDAwIG4gCjAwMDAwMjYw MzMgMDAwMDAgbiAKMDAwMDAxNTQzMyAwMDAwMCBuIAowMDAwMDQ5MjM2IDAwMDAwIG4gCjAwMDAw MjY1MzAgMDAwMDAgbiAKMDAwMDA0ODk4OSAwMDAwMCBuIAowMDAwMDI3MTIwIDAwMDAwIG4gCjAw MDAwNjUxNTUgMDAwMDAgbiAKMDAwMDA1NzEzMiAwMDAwMCBuIAowMDAwMDUwMjE1IDAwMDAwIG4g CjAwMDAwNTMwMzAgMDAwMDAgbiAKMDAwMDA1Mjc5MSAwMDAwMCBuIAowMDAwMDU1NDUzIDAwMDAw IG4gCjAwMDAwNTUxMzAgMDAwMDAgbiAKMDAwMDA1NDk5MiAwMDAwMCBuIAowMDAwMDU0NjYzIDAw MDAwIG4gCjAwMDAwNTQyMTIgMDAwMDAgbiAKMDAwMDA1NDI5MCAwMDAwMCBuIAowMDAwMDU0OTIz IDAwMDAwIG4gCjAwMDAwNTUxNTUgMDAwMDAgbiAKMDAwMDA1NzA2NSAwMDAwMCBuIAowMDAwMDU1 NjM4IDAwMDAwIG4gCjAwMDAwNTU1ODEgMDAwMDAgbiAKMDAwMDA1NTg1MiAwMDAwMCBuIAowMDAw MDU1NzkwIDAwMDAwIG4gCjAwMDAwNTYwNjUgMDAwMDAgbiAKMDAwMDA1NjAwMyAwMDAwMCBuIAow MDAwMDU2MjgzIDAwMDAwIG4gCjAwMDAwNTYyMTcgMDAwMDAgbiAKMDAwMDA1NjQ5MCAwMDAwMCBu IAowMDAwMDU2NDM0IDAwMDAwIG4gCjAwMDAwNTY2OTYgMDAwMDAgbiAKMDAwMDA1NjY0MSAwMDAw MCBuIAowMDAwMDU2OTE1IDAwMDAwIG4gCjAwMDAwNTY4NDggMDAwMDAgbiAKMDAwMDA2NDk2MyAw MDAwMCBuIAowMDAwMDU3NDA4IDAwMDAwIG4gCjAwMDAwNTc2MjQgMDAwMDAgbiAKMDAwMDA1OTky NCAwMDAwMCBuIAowMDAwMDY0ODc0IDAwMDAwIG4gCjAwMDAwNjUyMzMgMDAwMDAgbiAKMDAwMDA2 NTI4MCAwMDAwMCBuIAp0cmFpbGVyCjw8L0lEIFs8ZTQzOGU0NmMyMWI2YWEwMGRkNDU0NTM4Mjhh ZWUzMDg+PGUyZTViMmFjNDNiOWNjMzAxNWQ2YjAwYmMzOGFhYzBjPl0vUm9vdCA2NSAwIFIvU2l6 ZSA2Ny9JbmZvIDY2IDAgUj4+CnN0YXJ0eHJlZgo2NTQxMQolJUVPRgo= --20cf3056409717e29604a50c7dab-- From dzonatas@gmail.com Mon Jun 6 11:57:46 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36D611E816B for ; Mon, 6 Jun 2011 11:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxGLDtskvzXc for ; Mon, 6 Jun 2011 11:57:46 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1E111E816A for ; Mon, 6 Jun 2011 11:57:46 -0700 (PDT) Received: by pwi5 with SMTP id 5so2506880pwi.31 for ; Mon, 06 Jun 2011 11:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EDimmeQ4Ye1pXKZyRywH+u30b1uTZYoB6ePaWOQHQJ4=; b=UVjVPZVTogmIfO6+OVv4LHEz8nd6m+Ycd/uXWJw69jBGMKWNVxSTxLd4j4EV+0mcld Jnw+JW4JX9xxcnwD5+VyxbshGk2VEWKYMW6pI3l7CtgmhdPBHU0vVhOqXKV7NutzQfgA dX8xrEISj9OiYYwWK4GwbXzUhs8kpBbpcp3+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=OrojVyHl4C7G3kyNaj9yDtyFrAdXGTJfN/cdO5A5wjNiPO3lFeFLq+WvXAUy0CiC2S WBhJlAd1p9+jSLWpmV56kNtZROEBIw2j6r+Q4x0xKF4jqsFHyudQ7tTt+lSX7/cTw+Ly x1CySiRclVUaHCDS73OB5OMB0+JBd/w3tB8a4= Received: by 10.68.52.199 with SMTP id v7mr1973653pbo.244.1307386665768; Mon, 06 Jun 2011 11:57:45 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id w2sm3863735pbg.53.2011.06.06.11.57.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2011 11:57:44 -0700 (PDT) Message-ID: <4DED22F1.6050809@gmail.com> Date: Mon, 06 Jun 2011 11:56:49 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4DECCB27.4030209@gmx.de> In-Reply-To: <4DECCB27.4030209@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Thoughts on text/* encoding defaults X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2011 18:57:46 -0000 On 06/06/2011 05:42 AM, Julian Reschke wrote: > > Left to do: > > a) Revise RFC 2046; allow text/* types that carry encoding information > inline to do the expected thing (overriding the US-ASCII default); > warn against doing so in new registrations (recommend to only support > UTF-8, and require to always explicitly include the charset parameter, > such as text/vcard is going to do it?) > > b) Revise RFC 3023 to delegate text/xml charset defaults to revision > of 2046? > This has probably been said before by someone else, yet there is some reason about the above action which makes me concerned when we don't first assume use of "us-ascii" that there may be loss of compatibility with 7bit communications (and compression algorithms), especially in hardware that doesn't require updates based on known standards. I know UTF-8 includes the literals, yet if we strip the 8th bit on unicoded-to-ascii escape sequences then is the media content still compatible (even size wise before and after compression)? Or would this cause unknown error correction where UTF-8 is an explicit replacement of "us-ascii". I think that there is the significant point to 7bit being "must" by that 7bit mode being specifically implied by "ascii" because the 8th bit in UTF-8 is not "human readable" in regards to plain XML. To only support UTF-8 means one more bit is being added to the 7bit standard. I do recognize you want to resolve the conflict for further support with ISO & I18N. I think what you want why some tried to progress "code pages" in context. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From barryleiba.mailing.lists@gmail.com Mon Jun 6 16:56:14 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722B621F84EE for ; Mon, 6 Jun 2011 16:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeVmCTovrW-v for ; Mon, 6 Jun 2011 16:56:13 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C052821F84EB for ; Mon, 6 Jun 2011 16:56:13 -0700 (PDT) Received: by gwb20 with SMTP id 20so2155224gwb.31 for ; Mon, 06 Jun 2011 16:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=3dCTQupVYphAtccXZDo2X3ygev2HCDpEthCHUFJgnSE=; b=XNuF5fBZdno1LIGoLCwdZhORum3oaxtFmhmlAbYBFdbiBXdMsi6jt6C/ciyvFsWXgp 0vFAZDFxIodRekgbiXCVrmRydZ+MwC2xF9PaCQG0xosrxXujB60+0HvO6iKC3XmcJb4K k9SqHzGoYPclkPcHSoiIqSUxqEII6i0wKit0Y= 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:content-type :content-transfer-encoding; b=aS0dgj6BUXS8fDXYigDph+YJGk25MeSysp6ORiP0zGQnJT85S5XaVa8RM/rde7J4x9 DWzlN3rw4JDmcqMuv8dv3A3076ir3ucgVPpnvHXWdAyDuLwGKoVp+POn7h2tVmKsUwEa iywFxKpptpfREdfyZwLF6fXmPhbw8ZahBahTg= MIME-Version: 1.0 Received: by 10.150.240.10 with SMTP id n10mr4797402ybh.77.1307404573235; Mon, 06 Jun 2011 16:56:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.125.15 with HTTP; Mon, 6 Jun 2011 16:56:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Jun 2011 23:56:13 +0000 X-Google-Sender-Auth: GTdBB1fPEmJ96vSCRqyDS3YVtWU Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] may I have your permisison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2011 23:56:14 -0000 On Mon, Jun 6, 2011 at 3:09 PM, Bhumip Khasnabish wrote: > Can I distribute the JNSM CFP on CCNS (Cloud Computing, Networking, and > Services) SI =A0to apps-discuss@ietf.org=A0? For the record, Bhumip accidentally sent this to the list as well as to me, and we've had an off-list exchange about it. It was an "oops", but it was OK for him to post that CFP. In general, I think -- and the ADs and/or my co-chairs might have slightly different views here -- that it's OK to have on this list *limited* non-IETF-related announcements that are of general interest to the IETF App Area participants. Requests to post those sorts of things should always be cleared through the chairs, ... and please do NOT make the same mistake and copy the list on your request. Remember that the primary purpose of this list is to discuss things directly related to IETF work in the Applications Area. That can also include proposed new work, and open discussion of new ideas is encouraged. At some point, new work, if there's enough interest, will deserve its own list, and discussions would then be moved there. A lot of this is "I know it when I see it," so keep in mind that we want to encourage discussion, but we want it to be within the charter of appsawg and the Applications Area in general. Barry, as chair From paulej@packetizer.com Mon Jun 6 20:26:13 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA22E11E8151; Mon, 6 Jun 2011 20:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yonClR2e1Ev9; Mon, 6 Jun 2011 20:26:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7789B11E8097; Mon, 6 Jun 2011 20:26:12 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p573Pw77008885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Jun 2011 23:26:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307417165; bh=jV52Ps4tuBilrdVoLwOntDyoyy8VqHJU8rKf8rGCbhs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=iATpPDFOH+ap5GbsUPzczIe3OKiBpEFzoUQ0R55MRLW6YA2f9Y7ftYn8G+am2rJqH pbRBfmWKJ77UkCpKQNM+DkyIIoUSrbPLyNSX7O4MiYKGUbWa85U+rGdIZ3r3+ZIkjX nQ9/X4zvoTeTBgVFsYs1EKfbc5UxRyDmLVaRRsQE= From: "Paul E. Jones" To: "'Nico Williams'" , "'Eran Hammer-Lahav'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Date: Mon, 6 Jun 2011 23:25:54 -0400 Message-ID: <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJuZniGB/7VI7fQeF44Yd3wW4or/QFyB4gcAph0XNqTTGN1IA== Content-Language: en-us Cc: apps-discuss@ietf.org, 'Ben Adida' , 'Adam Barth' , http-state@ietf.org, 'HTTP Working Group' , 'OAuth WG' Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 03:26:13 -0000 Nico, Sorry for coming into this so late, but I just saw this message. I don't have all of the background, but when I saw this message header and some of the dialog, it seems there is a desire to provide some level of authentication to requests and/or responses between the clients and servers. Gonzalo and I worked on this: https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04 This may not be entirely complete, but the idea was to allow a client and server to establish an association so that requests and responses could be authenticated. Is this something along the lines of what you are discussing, or is this an entirely different application? Paul > -----Original Message----- > From: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org] > On Behalf Of Nico Williams > Sent: Friday, May 20, 2011 4:25 PM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org; Ben Adida; Adam Barth (adam@adambarth.com); > http-state@ietf.org; HTTP Working Group; OAuth WG > Subject: Re: [http-state] [apps-discuss] HTTP MAC Authentication Scheme > > Additional comments: > > - Using nonces for replay protection is heavy-duty. It is difficult to > implement a reliable, secure, high-performance replay cache. (It is > easy to implement just a high-performance replay cache: use > memcache.) > > I recommend an option to use sequence numbers at the server's choice, > understanding, of course, that requests will not be received in > sequence. The use of a sliding sequence number window makes it possible > to do at least as well as when using nonce, and probably faster while > still being secure. > > - In an open wifi environment active attacks may not be very difficult, > thus an option to secure more than just a handful of bits from the > request, would be nice (all of the request and all of the response, > say). The hard part is how to decide when to use one or the other. > Ideally browsers can request more protection when the network is > reconfigured such that there's one or more clear wifi interfaces. > > Nico > -- > _______________________________________________ > http-state mailing list > http-state@ietf.org > https://www.ietf.org/mailman/listinfo/http-state From alexey.melnikov@isode.com Tue Jun 7 03:30:52 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D5C228004 for ; Tue, 7 Jun 2011 03:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1grV2tdERg1x for ; Tue, 7 Jun 2011 03:30:51 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2D072228003 for ; Tue, 7 Jun 2011 03:30:51 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 7 Jun 2011 11:30:50 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4DEDFDCF.9050403@isode.com> Date: Tue, 07 Jun 2011 11:30:39 +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: Barry Leiba References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] may I have your permisison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 10:30:52 -0000 Barry Leiba wrote: >On Mon, Jun 6, 2011 at 3:09 PM, Bhumip Khasnabish wrote: > >>Can I distribute the JNSM CFP on CCNS (Cloud Computing, Networking, and >>Services) SI to apps-discuss@ietf.org ? >> > >For the record, Bhumip accidentally sent this to the list as well as >to me, and we've had an off-list exchange about it. It was an "oops", >but it was OK for him to post that CFP. > >In general, I think -- and the ADs and/or my co-chairs might have >slightly different views here -- that it's OK to have on this list >*limited* non-IETF-related announcements that are of general interest >to the IETF App Area participants. Requests to post those sorts of >things should always be cleared through the chairs, >... and please do NOT make the same >mistake and copy the list on your request. > >Remember that the primary purpose of this list is to discuss things >directly related to IETF work in the Applications Area. That can also >include proposed new work, and open discussion of new ideas is >encouraged. At some point, new work, if there's enough interest, will >deserve its own list, and discussions would then be moved there. > >A lot of this is "I know it when I see it," so keep in mind that we >want to encourage discussion, but we want it to be within the charter >of appsawg and the Applications Area in general. > > +1. From nico@cryptonector.com Tue Jun 7 10:35:55 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2D51F0C39; Tue, 7 Jun 2011 10:35:55 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxdZ496aZXFB; Tue, 7 Jun 2011 10:35:54 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6481F0C36; Tue, 7 Jun 2011 10:35:54 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id C35D11B4078; Tue, 7 Jun 2011 10:35:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=w8IK2aGMWRP9XrsrgfCDepvGOFww6Y8qqUz9zVWp6f3M rryvqeEjSMsmkbkLFA1ty80S+oOFsZ6DWgKjlplQ+3cW/BMa0Gy7bgLrEulPkuqt V+9Smxm24Qu3/7jHi3M8CEIV2bofVEnulb4YmpT9qq7A4OvIY95tJVofpmFENMU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=btKLDXJPPjTq3XZvKHfUdtb6H/A=; b=NzPxHv8LHsd 6CJrUKAMDSHIJIQ9+86/zXngVBVfNmvh/tc++dv2TfUgZAWFYJ6huSam02gQzzAQ 0JBS51TterCU1Rxn0M1Ahr6AVasLptnQ8rH/ixjkAMPWHgPPyieel25RvfnORUlj wtPVAov7F+9/wZXT5EFWuLt575INmwXw= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 96C8C1B406F; Tue, 7 Jun 2011 10:35:53 -0700 (PDT) Received: by pzk5 with SMTP id 5so2920439pzk.31 for ; Tue, 07 Jun 2011 10:35:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr295077pbj.456.1307468153080; Tue, 07 Jun 2011 10:35:53 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 10:35:52 -0700 (PDT) In-Reply-To: <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> Date: Tue, 7 Jun 2011 12:35:52 -0500 Message-ID: From: Nico Williams To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , Adam Barth , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 17:35:55 -0000 On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones wrot= e: > Nico, > > Sorry for coming into this so late, but I just saw this message. > > I don't have all of the background, but when I saw this message header an= d > some of the dialog, it seems there is a desire to provide some level of > authentication to requests and/or responses between the clients and serve= rs. > > Gonzalo and I worked on this: > https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04 > > This may not be entirely complete, but the idea was to allow a client and > server to establish an association so that requests and responses could b= e > authenticated. =C2=A0Is this something along the lines of what you are > discussing, or is this an entirely different application? I'm completely on-board with session state[*]. My comments were particularly in regards to threat models. I believe that eavesdroppers and active attackers both need to be considered, particularly as we have so many open wifi networks. To me the simplest way to address the Internet threat model is to always use TLS (except, maybe, for images and such elements that have little or no security value, though one must be careful when making that determination) and to use channel binding. See the I-D referenced below. [*] See, for example: http://www.ietf.org/id/draft-williams-rest-gss-00.tx= t Nico -- From ietf@adambarth.com Tue Jun 7 11:30:46 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0BE11E818F; Tue, 7 Jun 2011 11:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVXebRqn0uVr; Tue, 7 Jun 2011 11:30:45 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91EFF11E8166; Tue, 7 Jun 2011 11:30:45 -0700 (PDT) Received: by gyf3 with SMTP id 3so2861189gyf.31 for ; Tue, 07 Jun 2011 11:30:45 -0700 (PDT) Received: by 10.236.136.164 with SMTP id w24mr1418916yhi.171.1307471445065; Tue, 07 Jun 2011 11:30:45 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id w70sm296093yhl.3.2011.06.07.11.30.42 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 11:30:42 -0700 (PDT) Received: by gyf3 with SMTP id 3so2861155gyf.31 for ; Tue, 07 Jun 2011 11:30:42 -0700 (PDT) Received: by 10.91.198.17 with SMTP id a17mr5984674agq.44.1307471442099; Tue, 07 Jun 2011 11:30:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Tue, 7 Jun 2011 11:30:12 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> From: Adam Barth Date: Tue, 7 Jun 2011 11:30:12 -0700 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 18:30:46 -0000 On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wrot= e: > On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones wr= ote: >> Nico, >> >> Sorry for coming into this so late, but I just saw this message. >> >> I don't have all of the background, but when I saw this message header a= nd >> some of the dialog, it seems there is a desire to provide some level of >> authentication to requests and/or responses between the clients and serv= ers. >> >> Gonzalo and I worked on this: >> https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04 >> >> This may not be entirely complete, but the idea was to allow a client an= d >> server to establish an association so that requests and responses could = be >> authenticated. =A0Is this something along the lines of what you are >> discussing, or is this an entirely different application? > > I'm completely on-board with session state[*]. =A0My comments were > particularly in regards to threat models. =A0I believe that > eavesdroppers and active attackers both need to be considered, > particularly as we have so many open wifi networks. Sorry. We can't address active attackers using this mechanism. If you need protection from active attackers, please use TLS. > To me the simplest way to address the Internet threat model is to > always use TLS (except, maybe, for images and such elements that have > little or no security value, though one must be careful when making > that determination) and to use channel binding. =A0See the I-D > referenced below. Indeed. This mechanism is for folks who cannot or will not deploy TLS. Adam From nico@cryptonector.com Tue Jun 7 14:17:43 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1BD11E80CC; Tue, 7 Jun 2011 14:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2XfefYX-LcR; Tue, 7 Jun 2011 14:17:42 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id CBB1811E80C2; Tue, 7 Jun 2011 14:17:42 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 9406543807C; Tue, 7 Jun 2011 14:17:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=A+CIUGyKNSbymLMArkpGnX0oaqW2ZWVs1JISqMrjmeGg uQJBZwmmPSNglbYLbh6rXf8QoxSMF67XJCD4p2Sn9BJprL/fYkmI3goQ2T6PUC++ +KZnCu4GTeb3Tr0A5u/1peMyvOQuZmUXkPwwNLhWtF5lI3sUvPWMJ3M6S5PcNgc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=c1O9EsvOTcCw3PxOhd33itaxmWg=; b=eSeYMt1hBjf vT30PS7dcZVVlQr9YXFWD7Rt0yoXKtWdtKaIXNiUtdyGmVIsOlTh3DtTq/Rf6BP9 8UQXn4DS++Q5RN07EF82IaaSGz0fvKRSSPakhLNc3K1k7HCJxR0phbmuAIBJVlVG Ft99hy44xIi/iN6PQmqnnxOVPT6WlUtY= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 642F3438072; Tue, 7 Jun 2011 14:17:42 -0700 (PDT) Received: by pxi20 with SMTP id 20so4535056pxi.27 for ; Tue, 07 Jun 2011 14:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.10.9 with SMTP id e9mr577932pbb.255.1307481461766; Tue, 07 Jun 2011 14:17:41 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 14:17:41 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> Date: Tue, 7 Jun 2011 16:17:41 -0500 Message-ID: From: Nico Williams To: Adam Barth Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 21:17:43 -0000 On Tue, Jun 7, 2011 at 1:30 PM, Adam Barth wrote: > On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wr= ote: >> I'm completely on-board with session state[*]. =C2=A0My comments were >> particularly in regards to threat models. =C2=A0I believe that >> eavesdroppers and active attackers both need to be considered, >> particularly as we have so many open wifi networks. > > Sorry. =C2=A0We can't address active attackers using this mechanism. =C2= =A0If > you need protection from active attackers, please use TLS. I've already said as much now several times. However, I want channel binding to TLS too. >> To me the simplest way to address the Internet threat model is to >> always use TLS (except, maybe, for images and such elements that have >> little or no security value, though one must be careful when making >> that determination) and to use channel binding. =C2=A0See the I-D >> referenced below. > > Indeed. =C2=A0This mechanism is for folks who cannot or will not deploy T= LS. It has value outside TLS as well. Particularly if you're using an authentication mechanism that can provide mutual authentication (which OAuth doesn't do today, but I hear there's work in progress to add mutual auth to it). And then you realize that you might want to do something similar with other non-OAuth authentication methods, thus the urge to generalize. Nico -- From nico@cryptonector.com Tue Jun 7 14:20:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D028B11E8132; Tue, 7 Jun 2011 14:20:52 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpY2U1+oFk6J; Tue, 7 Jun 2011 14:20:52 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC5B11E80C2; Tue, 7 Jun 2011 14:20:52 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id CDA31350079; Tue, 7 Jun 2011 14:20:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=SmrAffH1meiUfZiFx2JEFJ0JBF/RqGmcy9QTOcXaAx+F diHmCBIzbZIEwJxyy7x4dhCeBeZQr6cxqK81vF2Wgc371fCrinRgZcs3czX9CgMS OSTlwDjWJwKIJJdAmVrA8sj2aO9M9Rg9jpd2QJ6KdR24kcooghv0dcOliel1N3o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=pp0EJ7zweYfXbLyZMx7md3xj7dY=; b=P00JbqVkyva YR9fZCAehX084AC2Lun5zPrYa1Z0bzM+d98VK406tD5u5LDkEKYlzQMLhhOrfjTW 0n0ENVRi107M1BC12432wSal8+XmOVqfRoItFAWlGOh+CxHAbE2EHj1VDdDBB8l7 sUQRPgr62rElGtPZo8ju8y8x68gI+/Fk= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 9C967350078; Tue, 7 Jun 2011 14:20:51 -0700 (PDT) Received: by pvh18 with SMTP id 18so1199081pvh.31 for ; Tue, 07 Jun 2011 14:20:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr434791pbc.523.1307481651289; Tue, 07 Jun 2011 14:20:51 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 14:20:51 -0700 (PDT) In-Reply-To: <4DEE70E6.90602@alcatel-lucent.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <4DEE70E6.90602@alcatel-lucent.com> Date: Tue, 7 Jun 2011 16:20:51 -0500 Message-ID: From: Nico Williams To: igor.faynberg@alcatel-lucent.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 21:20:54 -0000 On Tue, Jun 7, 2011 at 1:41 PM, Igor Faynberg wrote: > Adam Barth wrote: >> Sorry. =C2=A0We can't address active attackers using this mechanism. =C2= =A0If >> you need protection from active attackers, please use TLS. > > Actually, IPsec will work here (with WiFi networks) just as well. =C2=A0I= t is Not really. See RFCs 5660, 5386, and 5387. If only RFC5660 were widely implemented... but it's not. > also true that we COULD develop both the authentication and confidentiali= ty > mechanisms that would offer protection from both active and passive > attackers; it is just that we CHOSE (in opinion, correctly) not to do tha= t > because other Internet protocols already do that. And rightly so. As we've learned from SASL, having an option for security layers (the "SL" in SASL) at multiple network layers only adds unnecessary complications. Nico -- From ietf@adambarth.com Tue Jun 7 14:24:44 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346F41F0C36; Tue, 7 Jun 2011 14:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqAO8ic83vEo; Tue, 7 Jun 2011 14:24:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BABC1F0657; Tue, 7 Jun 2011 14:24:43 -0700 (PDT) Received: by iyn15 with SMTP id 15so6346666iyn.31 for ; Tue, 07 Jun 2011 14:24:42 -0700 (PDT) Received: by 10.42.1.82 with SMTP id 18mr11300549icf.274.1307481882488; Tue, 07 Jun 2011 14:24:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id w11sm2321212ibw.41.2011.06.07.14.24.41 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 14:24:41 -0700 (PDT) Received: by iyn15 with SMTP id 15so6346595iyn.31 for ; Tue, 07 Jun 2011 14:24:41 -0700 (PDT) Received: by 10.42.177.4 with SMTP id bg4mr10324481icb.164.1307481881104; Tue, 07 Jun 2011 14:24:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.229.196 with HTTP; Tue, 7 Jun 2011 14:24:10 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> From: Adam Barth Date: Tue, 7 Jun 2011 14:24:10 -0700 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 21:24:44 -0000 On Tue, Jun 7, 2011 at 2:17 PM, Nico Williams wrote= : > On Tue, Jun 7, 2011 at 1:30 PM, Adam Barth wrote: >> On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams w= rote: >>> I'm completely on-board with session state[*]. =A0My comments were >>> particularly in regards to threat models. =A0I believe that >>> eavesdroppers and active attackers both need to be considered, >>> particularly as we have so many open wifi networks. >> >> Sorry. =A0We can't address active attackers using this mechanism. =A0If >> you need protection from active attackers, please use TLS. > > I've already said as much now several times. =A0However, I want channel > binding to TLS too. I'm not sure that's appropriate for this mechanism. What problem does channel binding solve? Adam >>> To me the simplest way to address the Internet threat model is to >>> always use TLS (except, maybe, for images and such elements that have >>> little or no security value, though one must be careful when making >>> that determination) and to use channel binding. =A0See the I-D >>> referenced below. >> >> Indeed. =A0This mechanism is for folks who cannot or will not deploy TLS= . > > It has value outside TLS as well. =A0Particularly if you're using an > authentication mechanism that can provide mutual authentication (which > OAuth doesn't do today, but I hear there's work in progress to add > mutual auth to it). =A0And then you realize that you might want to do > something similar with other non-OAuth authentication methods, thus > the urge to generalize. > > Nico > -- > From paulej@packetizer.com Tue Jun 7 14:59:43 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EC311E817D; Tue, 7 Jun 2011 14:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuUYpWUCu7Bd; Tue, 7 Jun 2011 14:59:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A98E411E8071; Tue, 7 Jun 2011 14:59:42 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p57LxSSU026304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jun 2011 17:59:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307483975; bh=vAymWHB3vMQrUVrj09s12KmZ5xj9/zFu66TKvHefjnc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=P2Ly20UN2MnQdVu9fxOgahTjEqfr4w9UM967g3OJzK+yeQB44k5sgOeKeTIDDtLNO bvywhKoLntceXy9npodJTLIPDUjiNkA7Geib65yX/I7rd+4+Qc3Y3zCP37jrGJbCGX iV6cB7agKi1Q4amxLwBj/qo3iEU//lFk0yLkpZBU= From: "Paul E. Jones" To: "'Nico Williams'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> In-Reply-To: Date: Tue, 7 Jun 2011 17:59:23 -0400 Message-ID: <00f101cc255e$2d426020$87c72060$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpJUw+Lnw Content-Language: en-us Cc: apps-discuss@ietf.org, 'Ben Adida' , 'Adam Barth' , http-state@ietf.org, 'HTTP Working Group' , 'OAuth WG' Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 21:59:43 -0000 Nico, > > Gonzalo and I worked on this: > > = https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04 > > > > This may not be entirely complete, but the idea was to allow a = client > > and server to establish an association so that requests and = responses > > could be authenticated. Is this something along the lines of what = you > > are discussing, or is this an entirely different application? >=20 > I'm completely on-board with session state[*]. My comments were > particularly in regards to threat models. I believe that = eavesdroppers > and active attackers both need to be considered, particularly as we = have > so many open wifi networks. >=20 > To me the simplest way to address the Internet threat model is to = always > use TLS (except, maybe, for images and such elements that have little = or > no security value, though one must be careful when making that > determination) and to use channel binding. See the I-D referenced > below. >=20 > [*] See, for example: http://www.ietf.org/id/draft-williams-rest-gss- > 00.txt I fully agree with you that using TLS is usually preferred. That said, = we encounter situations where there were a large number of client/server = interactions and the data conveyed is not confidential information in = any way. Using TLS can significantly decreases server performance, = particularly when there are a number of separate connections that are = established and broken. So, we were trying to find a non-TLS solution that still provides a way = to ensure the server can identify the user and that both can verify that = data has not been tampered in flight. (It would still be preferred to = establish security relations with TLS, though we were open to other = solutions.) Paul From nico@cryptonector.com Tue Jun 7 15:33:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3811E8084; Tue, 7 Jun 2011 15:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0EizRmivHBn; Tue, 7 Jun 2011 15:33:37 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id D807911E8072; Tue, 7 Jun 2011 15:33:35 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 40D651F0083; Tue, 7 Jun 2011 15:33:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=chqaBCti5o446gpVly0Tx8eDlUkn17K1DAKHIL0wHuqL dZMVrOsjyLl5fVlxZCdkomJzhW08U68aGQivwtqNfKlR9YJppHcZ8jVW2BbsNSXI utxv8ExFOfg+yk1DXj4C973r32EKtUBjIxNiojJ1fQZn0ZLqVojG81Am5rtTZak= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=CaY172oGfQ/cmxWYif9ddWcAy4o=; b=uMnpvd5CaRO 8jG5foIflgTxdmLsXn6vjvs8HTdPsV1CQ7XsT9OC5F0tT9PuS46Bh6BK/v7D+3zU uKYIaLEMGlgohibt223Ure61cuVVyFNsXIKl6aklmySb+WUJjICIPqjx5JFTveXN XgZjlFGlU3kS7Lh36qsaEpudgTcBblAY= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 032151F0081; Tue, 7 Jun 2011 15:33:34 -0700 (PDT) Received: by pzk5 with SMTP id 5so3062072pzk.31 for ; Tue, 07 Jun 2011 15:33:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr439492pbj.456.1307486014688; Tue, 07 Jun 2011 15:33:34 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 15:33:34 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> Date: Tue, 7 Jun 2011 17:33:34 -0500 Message-ID: From: Nico Williams To: Adam Barth Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 22:33:38 -0000 On Tue, Jun 7, 2011 at 4:24 PM, Adam Barth wrote: > I'm not sure that's appropriate for this mechanism. =C2=A0What problem do= es > channel binding solve? CB is not appropriate for OAuth today, no, because OAuth doesn't give you mutual authentication, which means channel binding can't be done either (well, not with any security guarantees). You missed my point however: I don't really want to see a specific purpose MAC here because I do believe it's generalizable, and if we don't generalize it now we'll just have more special casing in code later. For a general MAC I'd want an option for CB (when TLS is used, of course). Nico -- From nico@cryptonector.com Tue Jun 7 15:35:33 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239EE11E8106; Tue, 7 Jun 2011 15:35:33 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57W7uQ8AqLLf; Tue, 7 Jun 2011 15:35:32 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 76BAB11E8101; Tue, 7 Jun 2011 15:35:32 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 4BC8758406E; Tue, 7 Jun 2011 15:35:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=JEyiIBgiin5z8haGINQAbeKV7LnYLLj9la/5VqpGmtiC HqABRuY2t78iKmycNevV70Y5p0mldhjlVYo+JMbzeuIANn+AXjUzbzrDSoc/4/9f deQButTh+mP8finqk4MDtWPeMMp7LihyfE3EO77MIojlrI5KOaJ/jl1BVyxSLRQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=8HZt5XI9AHWjWME8qN2YQPuzDtI=; b=KO60gFwsH88 GwmJvpm0CWkAk8Rj08qwgZzOMkRtUiQ0k7o8WemQLD0mSnhFGRxcxrKKkh6e2uEb kApEk2o734qMMG7oIH9WjGwWYO7ADlydSUwBBgLiEDkD1Y5pqXI9/8ug7+BWYktl PLg3HyPrs0wykTfEODAFaD6nfp8wfCbM= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 2169A584059; Tue, 7 Jun 2011 15:35:32 -0700 (PDT) Received: by pvh18 with SMTP id 18so1223953pvh.31 for ; Tue, 07 Jun 2011 15:35:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr461586pbc.523.1307486131806; Tue, 07 Jun 2011 15:35:31 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 15:35:31 -0700 (PDT) In-Reply-To: <00f101cc255e$2d426020$87c72060$@packetizer.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> Date: Tue, 7 Jun 2011 17:35:31 -0500 Message-ID: From: Nico Williams To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , Adam Barth , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 22:35:33 -0000 On Tue, Jun 7, 2011 at 4:59 PM, Paul E. Jones wrote= : > I fully agree with you that using TLS is usually preferred. =C2=A0That sa= id, we encounter situations where there were a large number of client/serve= r interactions and the data conveyed is not confidential information in any= way. =C2=A0Using TLS can significantly decreases server performance, parti= cularly when there are a number of separate connections that are establishe= d and broken. > > So, we were trying to find a non-TLS solution that still provides a way t= o ensure the server can identify the user and that both can verify that dat= a has not been tampered in flight. =C2=A0(It would still be preferred to es= tablish security relations with TLS, though we were open to other solutions= .) I don't see the point of having a MAC instead of a cookie for HTTP requests sent without TLS, not unless you cover enough of the request (and response). Of course, you'll want two different cookies -- one for HTTP and one for HTTPS. I think you've just convinced me that this MAC adds no value whatsoever. Nico -- From nico@cryptonector.com Tue Jun 7 15:57:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C98311E81C9; Tue, 7 Jun 2011 15:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SjVEoMxQuFN; Tue, 7 Jun 2011 15:57:01 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 03D8A11E80CF; Tue, 7 Jun 2011 15:57:01 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id D3864678062; Tue, 7 Jun 2011 15:57:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Jcjadx0we/+FYjNkC5Z/q 8pA9HxFpJbSgQsrxTSvLmBQzFf7AMWpyGAjCe8JplI1PGo2OiIv1/hN2rj80rqDh QEkr4Ry8vMSDSEQgSclWugz1eRV4TPUAt5OU8K3ru0kzIHaNmXkgo0ADPoF72ggQ jLTa2xprmP7gdv7jQI8FEA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=tkn5ldRCD2ME+hplUIi1 u66Ly3M=; b=G+5+iYV8gwBpIBA0fVd/WeJ1QJ9n1VME+rWXq9Bk8TX2zmfZ2zkF ug9kzhKHzB7gUYM/qHOrwvWBsRz0ZyPOUn+tvCrs+xg62ffWGxL6OKDPmZqZynpm TjosLkE1HVYSdpAD2R1mqsxstwqC5/jsqiUKf2zCezeXXQnc0wJs84k= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id A91F0678056; Tue, 7 Jun 2011 15:57:00 -0700 (PDT) Received: by pxi20 with SMTP id 20so4585098pxi.27 for ; Tue, 07 Jun 2011 15:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.20.137 with SMTP id n9mr446071pbe.121.1307487420276; Tue, 07 Jun 2011 15:57:00 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 15:57:00 -0700 (PDT) In-Reply-To: <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 7 Jun 2011 17:57:00 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , Ben Adida , Adam Barth , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 22:57:01 -0000 On Tue, Jun 7, 2011 at 5:43 PM, William J. Mills wrote: > MAC adds security if the initial secret exchange is secure, and it provides > a definition for signing payload as part of the request. Not if the MAC doesn't protect enough of the request _and_ response to prevent active attacks. Unless you don't care about those attacks (which some of you have indicated), in which case why bother with the MAC at all? Nico -- From nico@cryptonector.com Tue Jun 7 16:09:44 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4C211E8072; Tue, 7 Jun 2011 16:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHkmy3WubpgE; Tue, 7 Jun 2011 16:09:43 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id B51E511E8101; Tue, 7 Jun 2011 16:09:35 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 814A36B007C; Tue, 7 Jun 2011 16:09:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=QLYkrGySk//VPWRH3vMHrMV8l2HEQvF1xxPvYlBiRmAE Jxq9R0DFm3wvipjvYpLqQl08u5WRzRD1h32LEaU3dKWEBF3B0HMuri4j+V7f01t4 +QE0YmqDfugwYrZuEsZYkN47HG0JDUN/2L8GxShEc+uSVYTx5I5By9Mepcg5Eks= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=4lDtf11LS1OMOrjp2f2TD2cUC94=; b=CwhMt7cv39b CP5Ha23E9xNjqKS7kvE96MhkupEMyW1fVjd9gn122BzPLaanpyzeuiZWZqPYruwX FJdSjt9cEyHm1XTnA7y8NtYmkypvMlhGXJVefZ6NzTJlrBrHPMwc3ytz4lYDrEdW mYwwCxJcpfhrV8bchie14zU+ABEI07NE= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 4EC866B007B; Tue, 7 Jun 2011 16:09:35 -0700 (PDT) Received: by pvh18 with SMTP id 18so1233930pvh.31 for ; Tue, 07 Jun 2011 16:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.135 with SMTP id a7mr506451pbi.54.1307488174872; Tue, 07 Jun 2011 16:09:34 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 16:09:34 -0700 (PDT) In-Reply-To: <4DEEAD76.2090800@adida.net> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> Date: Tue, 7 Jun 2011 18:09:34 -0500 Message-ID: From: Nico Williams To: Ben Adida Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , Adam Barth , "http-state@ietf.org" , "William J. Mills" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 23:09:44 -0000 On Tue, Jun 7, 2011 at 6:00 PM, Ben Adida wrote: > On 6/7/11 3:57 PM, Nico Williams wrote: >> >> Not if the MAC doesn't protect enough of the request _and_ response to >> prevent active attacks. =C2=A0Unless you don't care about those attacks >> (which some of you have indicated), in which case why bother with the >> MAC at all? > > A passive attacker can sniff your cookie and thus hijack your session. Al= l > you need to accomplish that attack is connect to any open wifi network an= d > use Firesheep. It's a good bit harder to be an active attacker, even on a= n > open wireless network. Yes, but only for resources that you've already stated you don't care about= . If you cared about those resources you'd protect more of the request _and_ response, or you'd use TLS. But you don't want to protect the response and you don't want to use TLS and you don't even want to protect the request body. What you're proposing adds a very marginal degree of security that will be trivial to defeat on open wifi (particularly once the toolset for doing it gets published). Are we serious about security? Or it this just for show? Or am I missing something? Nico -- From nico@cryptonector.com Tue Jun 7 17:07:40 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6F211E813F; Tue, 7 Jun 2011 17:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.088 X-Spam-Level: X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cefikWRneL9D; Tue, 7 Jun 2011 17:07:40 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id F202211E80B2; Tue, 7 Jun 2011 17:07:39 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id C4C2F67C06D; Tue, 7 Jun 2011 17:07:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Qp2Tej8sQu6p8GCJ3ViGASnUPPlA230lKv1LANp9H1ID f1b1rdAJuJm56m60LpnKP7fyGKGgHO5FvKLrmt10ji3SjXyVPSEtcZ3TRuihLlXS x5C5eTz1sXes0GCCNaMjQQ6NwCyyx84OpO7WaHUEsFZOX1JCC1cM3TRmU0ugVUo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=H6jQsCDKAW1ELuHLEHnpEBnUiNs=; b=T52XUZRkd0e 6GZgKOxowzNbcf3syhQcaBoUm/CwIjYPQV6a32koBZwQI8n+U4rWA01RUayiKU4J RxKyu9La76RjkabYTJYYGxGyfpGHz4aLE0MeFjkptSpa7vqeHnNcIlojkLoz7w9G Q4fMKh2Q/JR5eA70pgr1X+MJgW6p88Ho= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 9FCF067C069; Tue, 7 Jun 2011 17:07:39 -0700 (PDT) Received: by pzk5 with SMTP id 5so2867pzk.31 for ; Tue, 07 Jun 2011 17:07:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.10.9 with SMTP id e9mr636701pbb.255.1307491659198; Tue, 07 Jun 2011 17:07:39 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 17:07:39 -0700 (PDT) In-Reply-To: <20110607234131.GI1565@sentinelchicken.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> Date: Tue, 7 Jun 2011 19:07:39 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG , HTTP Working Group , "apps-discuss@ietf.org" , "http-state@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 00:07:40 -0000 On Tue, Jun 7, 2011 at 6:41 PM, Tim wrot= e: > I have to agree with Nico here. =C2=A0In almost all cases I assert that, = on > typical modern networks: > > =C2=A0let P =3D difficulty of passive attack > =C2=A0let M =3D difficulty of active (man-in-the-middle) attack > > O(P) =3D O(M) > . > > This isn't to say the "real world" difficulty of an active attack is > just as easy, but it is within a constant factor. =C2=A0If someone has > published a tool that conducts MitM attacks for the specific protocol > you're dealing with, the difference in difficulty clearly becomes > marginal. =C2=A0Consider the complexity of the attacks implemented by > sslstrip and yet the relative ease with which you can use it to MitM > all SSL connections. Exactly, and very well put. Active attacks sound harder, and they do actually require more work, but in many cases that work can be automated, and once automated there can be no difference in effort required to mount an active attack versus a passive one. Do we suppose that this proposal can get past secdir, IESG, and IETF reviews as-is? I doubt it. Here's another issue: some of you are saying that an application using this extension will be using TLS for some things but not others, which presumes a TLS session. Does using TLS _with_ session resumption _and_ HTTP/1.1 pipelining for all requests really cost that much more in latency and compute (and electric) power than the proposed alternative? I seriously doubt it, and I'd like to see some real analysis showing that I'm wrong before I'd accept such a rationale for this sort of proposal. Or perhaps the motivation relates to accidental leakage of "secure" cookies in non-secure contexts. But why not just fix the clients in that case? Nico -- From nico@cryptonector.com Tue Jun 7 18:22:05 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE8111E8153; Tue, 7 Jun 2011 18:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuR9xz6PGLW2; Tue, 7 Jun 2011 18:22:04 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 800AE11E80FE; Tue, 7 Jun 2011 18:22:04 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 51EE46B0078; Tue, 7 Jun 2011 18:22:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=dDjqdD+Ai35GrrIFdxLEjX0o7vLxXrewoJkw9M5BnP3K f4GtSOhqNN+ZXOI1lDbyNJ8OJJ3wkpOR9izCa/AOqVkVa7sV7t8fJsDry7E1CgH2 b3pjpxxR0FTNAJLagerEE96DWUAiaARx1sPC6HK3oW7Mimhhcs5qE/2ywxhh4ug= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=LLMXHPcMoJJiak5gDNxcrRWfRXY=; b=bHPsiZLUI6q g1fmiEjAS2ncEg27mtBAtEgeO4cefRAxI/3bi9SVxmotixxL0rzCRM0I7uC3jQKr Ua3kEg6Nnzf2TccGXP4LlBQgRIuNCb4mUmwJmZ0iLQpqWxSAnXokv7flrk8MJYaN mDLYCWxQ9imY6NsFgDbzRpvuvEZ653Zc= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 2319A6B0059; Tue, 7 Jun 2011 18:22:04 -0700 (PDT) Received: by pzk5 with SMTP id 5so12781pzk.31 for ; Tue, 07 Jun 2011 18:22:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr486208pbj.456.1307496123808; Tue, 07 Jun 2011 18:22:03 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 18:22:03 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> Date: Tue, 7 Jun 2011 20:22:03 -0500 Message-ID: From: Nico Williams To: Randy Fischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , Ben Adida , Adam Barth , "http-state@ietf.org" , "William J. Mills" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 01:22:05 -0000 On Tue, Jun 7, 2011 at 8:05 PM, Randy Fischer wro= te: > On Tue, Jun 7, 2011 at 7:09 PM, Nico Williams wro= te: >> Or am I missing something? > > Well, last I tried it under apache, at least, there was a hard limit > on the length of > a TLS stream. =C2=A0 Since I use HTTP for a storage system for multi-GB f= iles, =C2=A0I'd > really love to see alternatives. Really? But if it'd have to be pretty short for the cost of the subsequent TLS session resumption to add up to so much latency and compute cost that you'd want to avoid using TLS. Also, that sounds like a fixable bug. If you can implement this MAC proposal, you can fix that bug. Nico -- From nico@cryptonector.com Tue Jun 7 20:17:49 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5BC11E8072; Tue, 7 Jun 2011 20:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[AWL=-1.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es0YgEAaevRd; Tue, 7 Jun 2011 20:17:49 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 15C0911E8071; Tue, 7 Jun 2011 20:17:49 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id A078021DE77; Tue, 7 Jun 2011 20:17:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=dy/V6Vq49DKQUKR8Tu5YvJOyUDc/2cL0izV6EkSUvegF S+7H48vhvq5X+AoZCfVz4l+C1OasHL9A4dYu4DuKBWRA6s4nWqXP7MjANzSTxWyC 0lqbMoDmcvxwhSo2fDMnaewC5w8m4Hdxgf+W8ifVKBoNgI6o18pzFu1ZT/nuclQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Gi28YkJLenZ65hJkPHLi3wF5pfo=; b=BgPP1WhxxyR Gzut5IEzhILbW0byB821vvp3uPMFv0RVUQmNO0S6SdHWE2oEu3UXmX9aIyTzhqMT DCpJsfj9Q3AsH+O0Q0aYmsAkJ3lnVAHKHJqyTmBeAiEo+BlsQx76ekA+63lFt+pU +zktF8vpdQbHp96jyPu/nLdnpEAQ3Vt4= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 5A89521DE71; Tue, 7 Jun 2011 20:17:48 -0700 (PDT) Received: by pxi20 with SMTP id 20so68988pxi.27 for ; Tue, 07 Jun 2011 20:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.10.9 with SMTP id e9mr697477pbb.255.1307503068005; Tue, 07 Jun 2011 20:17:48 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 20:17:47 -0700 (PDT) In-Reply-To: <1307500800.70339.YahooMailNeo@web31810.mail.mud.yahoo.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> <1307500800.70339.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 7 Jun 2011 22:17:47 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Tim , "http-state@ietf.org" , OAuth WG , "apps-discuss@ietf.org" , HTTP Working Group Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 03:17:49 -0000 On Tue, Jun 7, 2011 at 9:40 PM, William J. Mills wro= te: > It is possible to implement decent security with MAC, it is also possible= to Not as specified. See earlier posts regarding active attacks. > screw it up.=C2=A0 It is far more difficult (impossible?) to implement de= cent > security with cookies over HTTP. Assuming well-behaved browsers that understand the distinction between "secure" and non-secure cookies, and assuming that active attacks are often no more difficult than passive attacks, what does MAC without TLS add that cookies don't provide? Nico -- From mnot@mnot.net Tue Jun 7 20:26:20 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE9F11E807C; Tue, 7 Jun 2011 20:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-6trkkkAyGs; Tue, 7 Jun 2011 20:26:19 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 720B211E8072; Tue, 7 Jun 2011 20:26:19 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [203.122.208.196]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DB368509D9; Tue, 7 Jun 2011 23:26:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 8 Jun 2011 13:26:05 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <3D7340ED-C6F5-464D-BD14-1A606B7D8228@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> <1307500800.70339.YahooMailNeo@web31810.mail.mud.yahoo.com> To: Nico Williams , "William J. Mills" , Tim X-Mailer: Apple Mail (2.1084) Cc: HTTP Working Group , OAuth WG , "apps-discuss@ietf.org Discuss" , http-state@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "apps-discuss@ietf.org Discuss" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 03:26:21 -0000 This is an interesting discussion, but a bit much to cross-post to four = different lists.=20 I've set followups to apps-discuss (since it's the most general). Cheers, On 08/06/2011, at 1:17 PM, Nico Williams wrote: > On Tue, Jun 7, 2011 at 9:40 PM, William J. Mills = wrote: >> It is possible to implement decent security with MAC, it is also = possible to >=20 > Not as specified. See earlier posts regarding active attacks. >=20 >> screw it up. It is far more difficult (impossible?) to implement = decent >> security with cookies over HTTP. >=20 > Assuming well-behaved browsers that understand the distinction between > "secure" and non-secure cookies, and assuming that active attacks are > often no more difficult than passive attacks, what does MAC without > TLS add that cookies don't provide? >=20 > Nico > -- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From yaojk@cnnic.cn Wed Jun 8 00:04:49 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D364011E80B4 for ; Wed, 8 Jun 2011 00:04:49 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.578 X-Spam-Level: X-Spam-Status: No, score=-99.578 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yufd36qdbtVt for ; Wed, 8 Jun 2011 00:04:48 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 55BC711E807E for ; Wed, 8 Jun 2011 00:04:46 -0700 (PDT) Received: (eyou send program); Wed, 08 Jun 2011 15:04:42 +0800 Message-ID: <507516682.01337@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 08 Jun 2011 15:04:42 +0800 Message-ID: From: "Jiankang YAO" To: "IETF-Discussion list" Date: Wed, 8 Jun 2011 15:04:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: appsawg-ads@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Summary for IESG last call to 5892bis draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 07:04:50 -0000 RGVhciBhbGwsDQoNCiAgDQogIEFEIHN1Z2dlc3RzIHRoYXQgd2Ugc2VuZCBhIGxhc3QgY2FsbCBz dW1tYXJ5IHRvIHRoZSBsaXN0Lg0KDQogIEJlbG93IGlzIHRoZSBzdW1tYXJ5IGZvciBJRVNHIGxh c3QgY2FsbCB0byA1ODkyYmlzIGRyYWZ0Lg0KDQogIEFueSBjb21tZW50cyBhcmUgd2VsY29tZS4N Cg0KICBKaWFua2FuZyBZYW8gYXMgYSBjby1jaGFpciBvZiBBUFBTQVdHDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KU3VtbWFyeToNCiBUaGUgSUVTRyBsYXN0IGNhbGwgZm9yIGRyYWZ0 LWZhbHRzdHJvbS01ODkyYmlzLTA0LnR4dCBlbmRlZCBvbiA2IEp1bmUuDQogTW9zdCBwYXJ0aWNp cGFudHMgc3VwcG9ydCB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBkcmFmdC4gTm9ib2R5IGV4cGxp Y2l0bHkgc2F5IHRoYXQgdGhleSBvYmplY3QgdGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQu DQoNCkJlbG93IGFyZSBzb21lIHF1ZXN0aW9ucyBvciBpc3N1ZXMgZGlzY3Vzc2VkIGR1cmluZyB0 aGUgSUVTRyBsYXN0IGNhbGwNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KaXNzdWUxOiBB Ym91dCB0aGUgdGV4dCBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHRoZSBJbnRyb2R1Y3Rpb24g DQpQZXRlciBTYWludC1BbmRyZTpUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIHRoZSBJbnRyb2R1Y3Rp b24gY29udGFpbnMgYSBmZXcgaW5mZWxpY2l0aWVzIGFuZCBncmFtbWF0aWNhbCBlcnJvcnMsIGFu ZCBJIHN1Z2dlc3Qgc29tZSBtb2RpZnlpbmcuIA0KQ2xhcmlmaWNhdGlvbiBmcm9tIEpvaG4gQyBL bGVuc2luOiBXZSBzaG91bGQgbGVhdmUgdGhlIGVkaXRpbmcgd29yayBvciBtb2RpZnlpbmcgd29y ayB0byBSRkMgRWRpdG9yLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KaXNzdWUyOiBB Ym91dCB0aGUgb2xkIElETkFiaXMgV0cncyBkZWNpc2lvbg0KQ2xhcmlmaWNhdGlvbiBmcm9tIEpv aG4gQyBLbGVuc2luOiB0aGUgV0cgY29uY2x1ZGVkIHRoYXQgVW5pY29kZSBjaGFuZ2VzIG9mIGNo YXJhY3Rlcg0KIHByb3BlcnRpZXMgdGhhdCBhZmZlY3RlZCBJRE5BIG5lZWRlZCB0byBiZSBldmFs dWF0ZWQgaW4gdGhlIElFVEYNCiBvbiBhIGNhc2UtYnktY2FzZSBiYXNpcyBhcyB0byB3aGV0aGVy IHRoZXkgd2VyZSBpbXBvcnRhbnQgZW5vdWdoDQogdG8ganVzdGlmeSBhbiBhZGRpdGlvbiB0byB0 aGF0IGV4Y2VwdGlvbnMgdGFibGUgb3Igd2hldGhlciB0aGUNCiBiYWxhbmNlIGZlbGwgb24gdGhl IHNpZGUgb2Yga2VlcGluZyB0aGUgdGFibGUgc21hbGwuICANCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tIA0KaXNzdWUzOiBBYm91dCB0aGUgSUFOQSBjb25zaWRlcmF0aW9uIHNlY3Rpb24g DQpSb25pIEV2ZW46IEkgYW0gbm90IHN1cmUgaG93IHRoZSBJQU5BIGNvbnNpZGVyYXRpb24gc2Vj dGlvbiBpcyBpbi1saW5lIHdpdGggdGhlIElBTkEgY29uc2lkZXJhdGlvbiBzZWN0aW9uIG9mIFJG QzU4OTIuIE1heWJlIHNvbWUgY2xhcmlmaWNhdGlvbiB0ZXh0IHdvdWxkIGJlIGhlbHBmdWwuIA0K Q2xhcmlmaWNhdGlvbiBmcm9tIFBhdWwgSG9mZm1hbjogV2UgdGhpbmsgdGhhdCB0aGUgSUFOQSBj b25zaWRlcmF0aW9ucyBoZXJlIGFyZSwgaW4gZmFjdCwgd2hhdCBSRkMgNTg5MiB3YXMgZGVzaWdu ZWQgZm9yLiBUaGF0IGlzLCBSRkMgNTg5MiBzYXlzIHRoYXQgdGhlIHJlZ2lzdHJ5IHdpbGwgYmUg dXBkYXRlZCAoIklBTkEgaGFzIGNyZWF0ZWQgYSByZWdpc3RyeSB3aXRoIHRoZSBkZXJpdmVkIHBy b3BlcnRpZXMgZm9yIHRoZSB2ZXJzaW9ucyBvZiBVbmljb2RlIHJlbGVhc2VkIGFmdGVyIChhbmQg aW5jbHVkaW5nKSB2ZXJzaW9uIDUuMiIpLiANCldlIGFyZSBub3QgdXBkYXRpbmcgZWl0aGVyIDU4 OTIsIG5vciB0aGUgcmVnaXN0cnksIGJ5IHB1Ymxpc2hpbmcgNTg5MmJpcy4gV2UgYXJlIHNpbXBs eSBnaXZpbmcgSUVURiBjb25zZW5zdXMgYWR2aWNlIGFib3V0IHdoYXQgd2UgdGhpbmsgdGhlIGV4 cGVydCByZXZpZXdlciB3aG8gdXBkYXRlcyB0aGUgcmVnaXN0cnkgc2hvdWxkIGNvbnNpZGVyLg0K V2UgY2FuIGNoYW5nZSB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyB0byByZWZsZWN0IHRoYXQ6DQog ICBJQU5BIHdpbGwgdXBkYXRlIHRoZSBkZXJpdmVkIHByb3BlcnR5IHZhbHVlIHJlZ2lzdHJ5IGFj Y29yZGluZyB0bw0KICAgUkZDIDU4OTIgYW5kIHByb3BlcnR5IHZhbHVlcyBhcyBkZWZpbmVkIGlu IFRoZSBVbmljb2RlIFN0YW5kYXJkDQogICB2ZXJzaW9uIDYuMCwgcmVnYXJkbGVzcyBvZiB0aGUg Y29udGVudCBvZiB0aGlzIFJGQy4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpp c3N1ZTQ6IEFkZCB0aGUgSUFOQSBJRE5BIHJlZ2lzdHJ5IG9yIHJlcGxhY2UgdGhlIG9sZCBvbmU/ IA0KQ29tbWVudCBmcm9tIEpvaG4gQyBLbGVuc2luOiBNeSBleHBlY3RhdGlvbiB3aGVuIDU5ODIg d2FzIGNvbXBsZXRlZA0Kd2FzIHRoYXQgSUFOQSB3YXMgZXhwZWN0ZWQgdG8ga2VlcCBkZXJpdmVk IHByb3BlcnR5IHRhYmxlcywNCmNsZWFybHkgaWRlbnRpZmllZCBieSB2ZXJzaW9uLCBmb3IgZWFj aCBhbmQgZXZlcnkgVW5pY29kZQ0KdmVyc2lvbiBmcm9tIDUuMiBmb3J3YXJkLiAgSW4gb3RoZXIg d29yZHMsIHRoZSB0YWJsZXMgZm9yIHRoZQ0KW21vc3RdIGN1cnJlbnQgdmVyc2lvbiB3b3VsZCBi ZSBhZGRlZCB0bywgbm90IHJlcGxhY2UsIHdoYXRldmVyDQpwcmV2aW91cyB2ZXJzaW9uIHRhYmxl cyB3ZXJlIGFyb3VuZC4gIFRoZSByZWFzb25zIGZvciB0aGlzLCBpbg0KdGVybXMgb2Ygc3lzdGVt cyBhbmQgaW1wbGVtZW50YXRpb25zIGluIHZhcmlvdXMgc3RhZ2VzIG9mDQpkZXZlbG9wbWVudCwg aW1wbGVtZW50YXRpb24sIGFuZCBkZXBsb3ltZW50LCBzZWVtIG9idmlvdXMuLi4gYnV0DQptYXli ZSBpdCB3YXMgdG9vIG9idmlvdXMgdG8gc29tZSBvZiB1cyBhdCB0aGUgdGltZSB0byBnZXQgdGhl DQp3b3JkaW5nIGV4YWN0bHkgcmlnaHQuDQpDb21tZW50IGZyb20gUGF1bCBIb2ZmbWFuOiBXaGls ZSBKb2huJ3MgaW50ZXJwcmV0YXRpb24gY291bGQgYmUgb25lIHRoaW5nIHdlIG1pZ2h0IGhhdmUg bWVhbnQsIGl0IGlzIG5vdCB3aGF0IGlzIHJlZmxlY3RlZCBpbiB0aGUgUkZDIG9yIHRoZSByZWdp c3RyeS4NCk5vdGUgdGhhdCBldmVyeSByZWZlcmVuY2UgdG8gdGhlIHJlZ2lzdHJ5IGlzIHNpbmd1 bGFyLiBBbHNvLCB0aGUgcmVnaXN0cnkgYXQgPGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvaWRuYWJpcy10YWJsZXMvaWRuYWJpcy10YWJsZXMueG1sPiBkb2Vzbid0IG1lbnRpb24gIjUu MiIgYXQgYWxsLg0KSWYgdGhlIHJlZ2lzdHJ5IGRlZmluaXRpb24gZG9lcyBub3QgdGFsayBhYm91 dCBrZWVwaW5nIHZlcnNpb25zLCBhbmQgdGhlIHJlZ2lzdHJ5IGl0c2VsZiBkb2Vzbid0IGxvb2sg bGlrZSBpdCB0cmllZCwgaXQgbWF5IGJlIGltcGxhdXNpYmxlIHRvIHRoaW5rIHRoYXQgSUFOQSB3 b3VsZCBqdXN0IHN0YXJ0IHRvIGRvIHNvIGluIHNvbWUgZnV0dXJlLiBUbyBtZSwgImEgcmVnaXN0 cnkiIG1lYW5zIGEgc2luZ2xlIHJlZ2lzdHJ5Lg0KKioqKipXZSBhcmUgd2FpdGluZyBmb3IgSm9o biBhbmQgUGF1bCByZWFjaGluZyB0aGUgYWdyZWVtZW50IGFib3V0IHRoaXMgaXNzdWUqKioqKioq DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KaXNzZTU6IEFib3V0IG5vbi1iYWNr d2FyZC1jb21wYXRpYmxlIGNoYW5nZXMgb2YgdGhlIHRhYmxlIG9mIGRlcml2ZWQgcHJvcGVydHkg dmFsdWVzDQpSb25pIEV2ZW46IFNlY3Rpb24gNS4xIG9mIFJGQzU4OTIgc2F5cyAiSWYgbm9uLWJh Y2t3YXJkLWNvbXBhdGlibGUgY2hhbmdlcyBvciBvdGhlcg0KcHJvYmxlbXMgYXJpc2UgZHVyaW5n IHRoZSBjcmVhdGlvbiBvciBkZXNpZ25hdGVkIGV4cGVydCByZXZpZXcgb2YgdGhlIHRhYmxlIG9m IGRlcml2ZWQgcHJvcGVydHkgdmFsdWVzLCB0aGV5IHNob3VsZCBiZSBmbGFnZ2VkIGZvciB0aGUg SUVTRy4iIC4gTXkgcXVlc3Rpb24gd2FzIGlmIHRoZQ0KY2hhbmdlIGlzIGJhY2t3YXJkIGNvbXBh dGlibGUuIFRoZSA1ODkyYmlzIGRyYWZ0IGRvZXMgbm90IHNheSBpdC4NCkNsYXJpZmljYXRpb24g ZnJvbSBQYXVsIEhvZmZtYW46IFdlIGludGVuZGVkIHRoYXQgYXMgIm5vbi1iYWNrd2FyZHMtY29t cGF0aWJsZSI7d2UgY2FuIGNoYW5nZSB0aGUgd29yZGluZyB0byBtYWtlIHRoYXQgZXhwbGljaXQu DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KaXNzdWU2OiBBYm91dCB0aGUgcmVm ZXJlbmNlIG9mIHRoZSBJQU5BIHJlZ2lzdHJ5IGZvciBkZXJpdmVkIHByb3BlcnR5IHZhbHVlIA0K Um9uaSBFdmVuOiAgVGhlIElBTkEgcmVnaXN0cnkgZm9yIGRlcml2ZWQgcHJvcGVydHkgdmFsdWUg aGFzIFJGQyA1ODkyLCBkb2VzIHRoaXMgZHJhZnQgd2FudCB0byBjaGFuZ2UgdGhlIHJlZmVyZW5j ZSwgaG93IHdpbGwgaXQgYmUgZG9uZT8NCkNsYXJpZmljYXRpb24gZnJvbSBQYXVsIEhvZmZtYW46 ICBTZWN0aW9uIDIgb2YgdGhlIGRyYWZ0IGlzIHByZXR0eSBjbGVhciBoZXJlOiAiTm8gY2hhbmdl IHRvIFJGQyA1ODkyIGlzIG5lZWRlZCBiYXNlZCBvbiB0aGUgY2hhbmdlcyBtYWRlIGluIFVuaWNv ZGUgNi4wIi4NCjU4OTJiaXMoUkZDKSB3aWxsIG5vdCBiZSBsaXN0ZWQgaW4gdGhlIHJlZ2lzdHJ5 LiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KaXNzdWU3OiBBYm91dCB0aGUgaW1w YWN0cyBvbiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBvZiBSRkMgNTg5MiAodGhlIHJlbGF0 aW9uc2hpcCBiZXR3ZWVuIHRoZSBydWxlcyBhbmQgdGhlIHRhYmxlcykNClNpbW9uIEpvc2Vmc3Nv bqO6SWYgdGhlIGRvY3VtZW50IGRvZXMgbm90IHVwZGF0ZSBSRkMgNTg5MiAob3Igc29tZSBvdGhl ciBkb2N1bWVudCksIEkNCnN1cHBvcnQgcHVibGlzaGluZyB0aGlzIGRvY3VtZW50IGJlY2F1c2Ug aXQgd2lsbCBub3QgYWZmZWN0IG15DQppbXBsZW1lbnRhdGlvbiBvZiBSRkMgNTg5Mi4gSWYgaXQg bWFya3MgdXBkYXRpbmcgUkZDNTg5MiwgSSBhbSBhZnJhaWQgdGhhdCBJIGhhcyB0byB1cGRhdGUg dGhlIGltcGxlbWVudGF0aW9uLg0KDQpDbGFyaWZpY2F0aW9uIGZyb20gSm9obiBDIEtsZW5zaW46 IA0KVGhlIHRleHQgaW4gU2VjdGlvbiA0IG9mIHRoaXMgZHJhZnQgc2F5czoNCiJUaGUgdGFibGUg aW4gQXBwZW5kaXggQiBzaG93cywgZm9yIGlsbHVzdHJhdGl2ZQ0KcHVycG9zZXMsIHRoZSBjb25z ZXF1ZW5jZXMgb2YgdGhlIGNhdGVnb3JpZXMgYW5kDQpjbGFzc2lmaWNhdGlvbiBydWxlcywgYW5k IHRoZSByZXN1bHRpbmcgcHJvcGVydHkgdmFsdWVzLiINCg0KIlRoZSBsaXN0IG9mIGNvZGUgcG9p bnRzIHRoYXQgY2FuIGJlIGZvdW5kIGluIEFwcGVuZGl4IEINCmlzIG5vbi1ub3JtYXRpdmUuICBT ZWN0aW9ucyAyIGFuZCAzIGFyZSBub3JtYXRpdmUuIg0KDQoNClRob3NlIHRhYmxlcyBjb250YWlu aW5nIFUrMTlEQSBjaGFyYWN0ZXIgYXJlIG5vdCBub3JtYXRpdmUsIHNvIGl0IGlzIG5vdCBwb3Nz aWJsZSB0byBzYXkgIkkNCmltcGxlbWVudGVkIHRoZSB0YWJsZXMgaW4gUkZDIDU4OTIgYW5kIHRo ZXJlZm9yZSBJIGNvbmZvcm0gdG8NCnRoZSBzdGFuZGFyZCIuICBUaGUgY2xvc2VzdCB5b3UgY2Fu IGdldCB3b3VsZCBiZSB0byBzYXkgIkkNCmltcGxlbWVudGVkIHRoZSBydWxlcyBhbmQgdGVzdGVk IGFnYWluc3QgdGhlIHRhYmxlcyB3aGVuIHRob3NlDQpydWxlcyB3ZXJlIGFwcGxpZWQgdG8gVW5p Y29kZSA1LjIgYW5kIHRoZXJlZm9yZSBoYXZlIGdyZWF0DQpjb25maWRlbmNlIGluIG15IGltcGxl bWVudGF0b24iLCBidXQgY29uZm9ybWFuY2Ugc3RhdGVtZW50cyBzdG9wDQp3aXRoICJpbXBsZW1l bnRlZCB0aGUgcnVsZXMgY29ycmVjdGx5Ii4= From paulej@packetizer.com Wed Jun 8 00:09:56 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C4F11E809F; Wed, 8 Jun 2011 00:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUcKNzOTuoWw; Wed, 8 Jun 2011 00:09:55 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C668F11E80B6; Wed, 8 Jun 2011 00:09:48 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p5879Zvs026255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2011 03:09:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307516981; bh=EqA8sObHvgjD2JNx49j1AwimuPqnmf948JUMPiOdJ4w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=HeYerh+ds7j3Bquz1AhEPWr47ADnZ3Mr5/baHDx0CJHBvy+QAQRFX9hZlsygDUdQ/ WJ4obHlhlGjjky7KWtRK+hb/oVxc/ckCLKsow96uWg1Z3grWMNRBA+ZE5LaCvKKgFU KQWHrjiX/Bi57G/cyjaSt6C6zKTlMMLY8qIWV0ac= From: "Paul E. Jones" To: "'Nico Williams'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> In-Reply-To: Date: Wed, 8 Jun 2011 03:09:29 -0400 Message-ID: <015801cc25ab$063a2150$12ae63f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDCVCDS9sA== Content-Language: en-us Cc: apps-discuss@ietf.org, 'Ben Adida' , 'Adam Barth' , http-state@ietf.org, 'HTTP Working Group' , 'OAuth WG' Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 07:09:56 -0000 Nico, Cookies would still be employed. A cookie would be used to identify the = particular user, for example. However, it's important to make sure that = the cookie provided by the client to the server is not stolen. It's = important to ensure that the client provided by the server to the client = is not modified. That's the reason for the MAC. Once we can ensure the = integrity of the message exchange, then the existing cookie mechanism = can provide us with the secure state management capability we need. Paul > -----Original Message----- > From: Nico Williams [mailto:nico@cryptonector.com] > Sent: Tuesday, June 07, 2011 6:36 PM > To: Paul E. Jones > Cc: Eran Hammer-Lahav; apps-discuss@ietf.org; Ben Adida; Adam Barth; > http-state@ietf.org; HTTP Working Group; OAuth WG > Subject: Re: [http-state] [apps-discuss] HTTP MAC Authentication = Scheme >=20 > On Tue, Jun 7, 2011 at 4:59 PM, Paul E. Jones > wrote: > > I fully agree with you that using TLS is usually preferred. That > said, we encounter situations where there were a large number of > client/server interactions and the data conveyed is not confidential > information in any way. Using TLS can significantly decreases server > performance, particularly when there are a number of separate > connections that are established and broken. > > > > So, we were trying to find a non-TLS solution that still provides a > > way to ensure the server can identify the user and that both can > > verify that data has not been tampered in flight. (It would still = be > > preferred to establish security relations with TLS, though we were > > open to other solutions.) >=20 > I don't see the point of having a MAC instead of a cookie for HTTP > requests sent without TLS, not unless you cover enough of the request > (and response). Of course, you'll want two different cookies -- one = for > HTTP and one for HTTPS. >=20 > I think you've just convinced me that this MAC adds no value = whatsoever. >=20 > Nico > -- From nico@cryptonector.com Wed Jun 8 07:54:35 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF1121F84E0; Wed, 8 Jun 2011 07:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIhATiHWBWlm; Wed, 8 Jun 2011 07:54:35 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 75A5121F84DE; Wed, 8 Jun 2011 07:54:35 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 42A3242807A; Wed, 8 Jun 2011 07:54:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=POqsYsC7GUNGirMoCVtHK gNfjM6dAbE9+/asiDdq30aavjlxB8a9zQSC5MrEbMF6VLUeCjP3wtiVORGhxQgII l4d/nCMDWQRfx7EBbrzPvF+1F0Tr/wxEmVJgC+W6uL7ytlV/rybBErLZMo2ZxTqP BQfpSLx2kueO6WnXbpxvgs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=MWIpQm+nK1ebSht6Ppx7 DUz0oGQ=; b=dtXGJiQkjsdMz6VPu1qQHIjEUnpznn91/uQYkPnzsNLjvSA9poDV Gosrzqh2+zM2+NxmzQRsQblcUT7BIWcFfHKBwgvTn00FsRmPR30N3exXRtEp5X6E S9UtbWqVud7wr9wre1dc+jmX6aajBcVBvDu74rO4us+3+e7ooSKnJI0= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id DDFF0428078; Wed, 8 Jun 2011 07:54:34 -0700 (PDT) Received: by pvh18 with SMTP id 18so313627pvh.31 for ; Wed, 08 Jun 2011 07:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.33 with SMTP id d1mr823108pbk.389.1307544874582; Wed, 08 Jun 2011 07:54:34 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 07:54:34 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 07:54:34 -0700 (PDT) In-Reply-To: <015801cc25ab$063a2150$12ae63f0$@packetizer.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> Date: Wed, 8 Jun 2011 09:54:34 -0500 Message-ID: From: Nico Williams To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec520e845c7038c04a53483df Cc: apps-discuss@ietf.org, Ben Adida , Adam Barth , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 14:54:36 -0000 --bcaec520e845c7038c04a53483df Content-Type: text/plain; charset=UTF-8 On Jun 8, 2011 2:09 AM, "Paul E. Jones" wrote: > > Nico, > > Cookies would still be employed. A cookie would be used to identify the particular user, for example. However, it's important to make sure that the cookie provided by the client to the server is not stolen. It's important to ensure that the client provided by the server to the client is not modified. That's the reason for the MAC. Once we can ensure the integrity of the message exchange, then the existing cookie mechanism can provide us with the secure state management capability we need. You're still not addressing the issues raised. Nico -- --bcaec520e845c7038c04a53483df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 8, 2011 2:09 AM, "Paul E. Jones" <paulej@packetizer.com> wrote:
>
> Nico,
>
> Cookies would still be employed. =C2=A0A cookie would be used to ident= ify the particular user, for example. =C2=A0However, it's important to = make sure that the cookie provided by the client to the server is not stole= n. =C2=A0It's important to ensure that the client provided by the serve= r to the client is not modified. =C2=A0That's the reason for the MAC. = =C2=A0Once we can ensure the integrity of the message exchange, then the ex= isting cookie mechanism can provide us with the secure state management cap= ability we need.

You're still not addressing the issues raised.

Nico
--

--bcaec520e845c7038c04a53483df-- From hugh.winkler@wellstorm.com Tue Jun 7 12:30:17 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776DC11E8228 for ; Tue, 7 Jun 2011 12:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxYeXvsL3qAu for ; Tue, 7 Jun 2011 12:30:16 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C1AC811E81AE for ; Tue, 7 Jun 2011 12:30:15 -0700 (PDT) Received: from mail-px0-f182.google.com (unknown [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E3E5F22E257 for ; Tue, 7 Jun 2011 15:30:08 -0400 (EDT) Received: by pxi20 with SMTP id 20so4451068pxi.27 for ; Tue, 07 Jun 2011 12:30:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.59.169 with SMTP id a9mr385945pbr.60.1307475007759; Tue, 07 Jun 2011 12:30:07 -0700 (PDT) Received: by 10.68.62.104 with HTTP; Tue, 7 Jun 2011 12:30:07 -0700 (PDT) Date: Tue, 7 Jun 2011 14:30:07 -0500 Message-ID: From: Hugh Winkler To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=bcaec53af16863e4cf04a5243fca X-Mailman-Approved-At: Wed, 08 Jun 2011 08:39:52 -0700 Subject: [apps-discuss] Typo in draft-abarth-mime-sniff-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 19:30:17 -0000 --bcaec53af16863e4cf04a5243fca Content-Type: text/plain; charset=ISO-8859-1 In the table in section 5, the fourth row from last incorrectly specifies the WebM mime type. It says "vidow/webm" Should be "video/webm". :) Hugh --bcaec53af16863e4cf04a5243fca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the table in section 5, the fourth row from last incorrectly specifies t= he WebM mime type.=A0

It says "vidow/webm"

Should be "video/webm".

:)
Hu= gh

--bcaec53af16863e4cf04a5243fca-- From wmills@yahoo-inc.com Tue Jun 7 15:43:22 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9409C11E8121 for ; Tue, 7 Jun 2011 15:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ehp8C7okM6Q for ; Tue, 7 Jun 2011 15:43:21 -0700 (PDT) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by ietfa.amsl.com (Postfix) with SMTP id 925E711E80CF for ; Tue, 7 Jun 2011 15:43:21 -0700 (PDT) Received: from [98.139.91.70] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 22:43:21 -0000 Received: from [98.139.91.24] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 22:43:21 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 22:43:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 328992.41590.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 86697 invoked by uid 60001); 7 Jun 2011 22:43:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1307486600; bh=+2VRbgPF+M1tYu3PXLrJxNrET7XInG8vxHJCwHhVU5U=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gXEF+Fpug9+wDPDlAfEB7L26mTKD/AC2tuqZdEKMgvbOrntZlrWZ5CosqBUg0aRax9RL2CNBFm2Ho4kdQSFb06D63LhSmqb88BTU/3kjRy8hR13kB6ZdJPKFSoGU/KukOSNr/Wum0X2iOhbrcvbbPMm0hQkdd8V9ZK+9SJaek1s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tJURKFvzQqxC0JdM6NL+q6M4LeoLf4PykmLlwcf4J3S6KHrjPVXudAJ9KGKt8noQp2gO/Y+w8WijKJms+VF+VsN3D0yJ8BvSVOMH66RU1AEBPx7ZDPcOszJikQ6W/rZr5FKeP7s/a+sd9W1M5Z5nCNqcAbTsvsIzS+CXf+vgjnQ=; X-YMail-OSG: 9vFg2EUVM1kPwDsdeLAwvl2uh_bot3pb1HgYgZuM9kQj5MI 2JoUITQrRUigiKmpnpIMyLZ.yRhZ31fHulo2muqkAIiD5zsf1U36e9lsuWaO uFDD2Qdd9.f.LEkPVPYgImYpgnV0Sqs9C3NLZzck.v3YGLu.RIqWo86ZQmbO 5RbqKimDXgRhG4F2HHoa9l8Db5g8PwPznUHIFMNZeEE2_Ev_hA0JdxAR.rZ. MMCJ.yNK64pS5AYXa0iRvYqYdo7LjhtjYYgPQz.M6cFKL7YdPuMupcoF_yMY FwrgNPRnvWs4j.IrC_hpz8pKBDqMIK10bzPxXefkhzOJStpVCv7adva5f_Rj APD.onAL3.Y.pWcNjL4ZKEsrwCh3O8__dtUvw Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Tue, 07 Jun 2011 15:43:20 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.307740 References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> Message-ID: <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 7 Jun 2011 15:43:20 -0700 (PDT) From: "William J. Mills" To: Nico Williams , "Paul E. Jones" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-935686083-1307486600=:48324" X-Mailman-Approved-At: Wed, 08 Jun 2011 08:39:52 -0700 Cc: "apps-discuss@ietf.org" , Ben Adida , Adam Barth , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:43:22 -0000 --0-935686083-1307486600=:48324 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MAC adds security if the initial secret exchange is secure, and it provides= a definition for signing payload as part of the request.=0A=0A=0A=0A______= __________________________=0AFrom: Nico Williams =0A= To: Paul E. Jones =0ACc: apps-discuss@ietf.org; Ben = Adida ; Adam Barth ; http-state@ietf.org= ; HTTP Working Group ; OAuth WG =0ASen= t: Tuesday, June 7, 2011 3:35 PM=0ASubject: Re: [OAUTH-WG] [http-state] [ap= ps-discuss] HTTP MAC Authentication Scheme=0A=0AOn Tue, Jun 7, 2011 at 4:59= PM, Paul E. Jones wrote:=0A> I fully agree with yo= u that using TLS is usually preferred. =A0That said, we encounter situation= s where there were a large number of client/server interactions and the dat= a conveyed is not confidential information in any way. =A0Using TLS can sig= nificantly decreases server performance, particularly when there are a numb= er of separate connections that are established and broken.=0A>=0A> So, we = were trying to find a non-TLS solution that still provides a way to ensure = the server can identify the user and that both can verify that data has not= been tampered in flight. =A0(It would still be preferred to establish secu= rity relations with TLS, though we were open to other solutions.)=0A=0AI do= n't see the point of having a MAC instead of a cookie for HTTP=0Arequests s= ent without TLS, not unless you cover enough of the request=0A(and response= ).=A0 Of course, you'll want two different cookies -- one=0Afor HTTP and on= e for HTTPS.=0A=0AI think you've just convinced me that this MAC adds no va= lue whatsoever.=0A=0ANico=0A--=0A__________________________________________= _____=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/= listinfo/oauth --0-935686083-1307486600=:48324 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
MAC adds security if the initial secret exchange is secure, and it provid= es a definition for signing payload as part of the request.

=
From: Nico = Williams <nico@cryptonector.com>
To: Paul E. Jones <paulej@packetizer.com>
Cc: apps-discuss@ietf.org; Ben Adi= da <ben@adida.net>; Adam Barth <adam@adambarth.com>; http-state= @ietf.org; HTTP Working Group <ietf-http-wg@w3.org>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, June 7, 2011 3:35 PM
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC = Authentication=0A=09Scheme

=0AOn Tue, Jun 7, 2011 at 4:59 PM,= Paul E. Jones <paulej@packetizer.com> wrote:
> I fu= lly agree with you that using TLS is usually preferred.  That said, we= encounter situations where there were a large number of client/server inte= ractions and the data conveyed is not confidential information in any way. =  Using TLS can significantly decreases server performance, particularl= y when there are a number of separate connections that are established and = broken.
>
> So, we were trying to find a non-TLS solution that = still provides a way to ensure the server can identify the user and that bo= th can verify that data has not been tampered in flight.  (It would st= ill be preferred to establish security relations with TLS, though we were o= pen to other solutions.)

I don't see the point of having a MAC inste= ad of a cookie for HTTP
requests sent without TLS, not unless you cover enough of the request
(and response).=   Of course, you'll want two different cookies -- one
for HTTP and = one for HTTPS.

I think you've just convinced me that this MAC adds n= o value whatsoever.

Nico
--
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m= ailman/listinfo/oauth


--0-935686083-1307486600=:48324-- From tim-projects@sentinelchicken.org Tue Jun 7 16:41:34 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A024721F8465 for ; Tue, 7 Jun 2011 16:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcHuyeFTFRQl for ; Tue, 7 Jun 2011 16:41:34 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id C9FFD21F8463 for ; Tue, 7 Jun 2011 16:41:33 -0700 (PDT) Received: (qmail 14024 invoked from network); 7 Jun 2011 23:41:31 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 7 Jun 2011 23:41:31 -0000 Received: (qmail 26041 invoked from network); 7 Jun 2011 23:42:48 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 7 Jun 2011 23:42:48 -0000 Received: (nullmailer pid 17134 invoked by uid 1000); Tue, 07 Jun 2011 23:41:31 -0000 Date: Tue, 7 Jun 2011 16:41:31 -0700 From: Tim To: Nico Williams Message-ID: <20110607234131.GI1565@sentinelchicken.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 08 Jun 2011 08:39:52 -0700 Cc: OAuth WG , HTTP Working Group , "apps-discuss@ietf.org" , "http-state@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 23:41:34 -0000 > > A passive attacker can sniff your cookie and thus hijack your session. All > > you need to accomplish that attack is connect to any open wifi network and > > use Firesheep. It's a good bit harder to be an active attacker, even on an > > open wireless network. > > Yes, but only for resources that you've already stated you don't care about. > > If you cared about those resources you'd protect more of the request > _and_ response, or you'd use TLS. But you don't want to protect the > response and you don't want to use TLS and you don't even want to > protect the request body. What you're proposing adds a very marginal > degree of security that will be trivial to defeat on open wifi > (particularly once the toolset for doing it gets published). > > Are we serious about security? Or it this just for show? > > Or am I missing something? I have to agree with Nico here. In almost all cases I assert that, on typical modern networks: let P = difficulty of passive attack let M = difficulty of active (man-in-the-middle) attack O(P) = O(M) . This isn't to say the "real world" difficulty of an active attack is just as easy, but it is within a constant factor. If someone has published a tool that conducts MitM attacks for the specific protocol you're dealing with, the difference in difficulty clearly becomes marginal. Consider the complexity of the attacks implemented by sslstrip and yet the relative ease with which you can use it to MitM all SSL connections. I didn't bring this up before because I didn't understand any of the context behind the MAC proposal, but I will now, at risk of sounding ignorant: What is the MAC Authentication proposal intended to accomplish, in a security sense, above and beyond HTTP Digest? Yes, the HTTP Digest spec is, shall we say, a little rough around the edges, but would it make more sense to simply *fix* the minor problems with it and slightly extend it to integrate with OAuth? Note that it already does allow for arbitrary encrypted blob values to be attached to the digest... Ignoring the integration details for a minute though, how does MAC improve on Digest from a security persepctive? tim From randy.fischer@gmail.com Tue Jun 7 18:05:53 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA42311E8169; Tue, 7 Jun 2011 18:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZFKTlgRcCfe; Tue, 7 Jun 2011 18:05:53 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88A8D11E8154; Tue, 7 Jun 2011 18:05:52 -0700 (PDT) Received: by eye13 with SMTP id 13so7213eye.31 for ; Tue, 07 Jun 2011 18:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zWUBEWDsEim3T3uROAtyiYrb74HcVJGxmn5fllGZeoA=; b=elj0QzMOORMz98wvXUMU7auOGAmAK1vKE1rKLTU2m9A1XtPtpHkXstC46Egv9L5FJT x8n3F3fKD0+U5+mEylbne50gXstVPkEkLCc6qHawTr7ZNh7hjdQH4Q2xQzDE6wbm3zHl ukf+gTVdICsnypzo7HOKNxJf3j61dLoM6HokQ= 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=l1Vz0ptlBcmd6V1wgL+IJVv93lmCQRBTfwjzcEk6X0CnyuuQya65kw4BhWcv8ZYCQl F8EAU2AkX8kKRcHCohfZBMatw4qskj5eeTnKFGNelS8jkm1+ccHAMtKrG/UnX6HqvoBf xMZbvmZPCEx5f1oa7hvoPsDEH8+xVfvnECVdY= MIME-Version: 1.0 Received: by 10.213.15.6 with SMTP id i6mr11009eba.148.1307495151605; Tue, 07 Jun 2011 18:05:51 -0700 (PDT) Received: by 10.213.23.2 with HTTP; Tue, 7 Jun 2011 18:05:51 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> Date: Tue, 7 Jun 2011 21:05:51 -0400 Message-ID: From: Randy Fischer To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 08 Jun 2011 08:39:52 -0700 Cc: "apps-discuss@ietf.org" , Ben Adida , Adam Barth , "http-state@ietf.org" , "William J. Mills" , HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 01:07:44 -0000 On Tue, Jun 7, 2011 at 7:09 PM, Nico Williams wrote: > Or am I missing something? Well, last I tried it under apache, at least, there was a hard limit on the length of a TLS stream. Since I use HTTP for a storage system for multi-GB files, I'd really love to see alternatives. -Randy Fischer From igor.faynberg@alcatel-lucent.com Tue Jun 7 11:41:53 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1033228007; Tue, 7 Jun 2011 11:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYgeQDqPEq9e; Tue, 7 Jun 2011 11:41:53 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id DC65021F8564; Tue, 7 Jun 2011 11:41:52 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p57Ifkgp025162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jun 2011 13:41:46 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p57IfjcQ008947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jun 2011 13:41:46 -0500 Received: from [135.244.5.22] (faynberg.lra.lucent.com [135.244.5.22]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p57IfhCF003676; Tue, 7 Jun 2011 13:41:43 -0500 (CDT) Message-ID: <4DEE70E6.90602@alcatel-lucent.com> Date: Tue, 07 Jun 2011 14:41:42 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Barth References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> In-Reply-To: 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 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 X-Mailman-Approved-At: Wed, 08 Jun 2011 08:39:52 -0700 Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 18:41:53 -0000 Adam Barth wrote: > On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wrote: > >> On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones wrote: >> >>> ... >>> >> I'm completely on-board with session state[*]. My comments were >> particularly in regards to threat models. I believe that >> eavesdroppers and active attackers both need to be considered, >> particularly as we have so many open wifi networks. >> > > Sorry. We can't address active attackers using this mechanism. If > you need protection from active attackers, please use TLS. > Actually, IPsec will work here (with WiFi networks) just as well. It is also true that we COULD develop both the authentication and confidentiality mechanisms that would offer protection from both active and passive attackers; it is just that we CHOSE (in opinion, correctly) not to do that because other Internet protocols already do that. Igor From wmills@yahoo-inc.com Tue Jun 7 19:40:06 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25FA11E8093 for ; Tue, 7 Jun 2011 19:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdFgMC+-SL-D for ; Tue, 7 Jun 2011 19:40:06 -0700 (PDT) Received: from nm22-vm0.bullet.mail.bf1.yahoo.com (nm22-vm0.bullet.mail.bf1.yahoo.com [98.139.212.126]) by ietfa.amsl.com (Postfix) with SMTP id 8AC4921F8482 for ; Tue, 7 Jun 2011 19:40:04 -0700 (PDT) Received: from [98.139.212.153] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 08 Jun 2011 02:40:01 -0000 Received: from [98.139.212.193] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 08 Jun 2011 02:40:01 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 08 Jun 2011 02:40:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 536884.85481.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 30367 invoked by uid 60001); 8 Jun 2011 02:40:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1307500800; bh=igtgdMlafKNXXXgX0IJWz0qWyJjefq/o4nz+eZJ8Njs=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QMbedK2JX62LFEbS+zWvILP2CdIoynZPpV3H35GlUjcLPeNnX19h04w/zc5kVkroL5wZQkUZKcDWlVv+epC96q8ZaB7vFdmtxpeoMkb4Ir/88EUQLigwNjGeQC+oBBza4qHZWhYgIpvg6psw+FxP5J1r0hnsa2ZYEEZmPTy1m+U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gDxobXeIAY7NJCP6JKQT14sMq9ajpYx29amaX8rr8ETR2T5OORe22Xd7Ki5VZe2/RlrgQfIWxBQor6vRTmM2UJIdViq9hK97+IezI1gDlsqaCdI4x5vFmjy35ZrQeLAwuzmUi2voyHtUto+C2ZEeXCPoORDT7pgnElJJ5jl+10Y=; X-YMail-OSG: Pq_6HkcVM1ktF0rmBX3uAidfzEbiW6Mq.rhQCYHB2.OReUV ya.C2GO76l6OqwvPIkhCZqlsV_6nmZQPO.QUVeYjt.Re4vjAoNsuHtqMbqLg nD.VbM05Y7ezyBs1hHwONQJVqoel3gmPoKv9Erj1itzhyA.552kZ.ReoTG5t aCIZD5KT6NVIpzPGhZpEI3.UwvISIVLxPetiOnfxRvjpwBzPTlTgyPLyyzYE Iyf12Zdk2hm1CKlVzrQIjv3gJF8bYl3dL7VTkpCjf5TAgckz8yIltuyaB8uL 1GSFXMG_1iab2aZzwf7EQ.vazYPl6xWIZ_qRcf766ceZ75XfvbY177TpKKvH Bb5d_L3.fwAh9oC738M6OC19IxiDbPTmQBbUV Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Tue, 07 Jun 2011 19:40:00 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.307740 References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> Message-ID: <1307500800.70339.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 7 Jun 2011 19:40:00 -0700 (PDT) From: "William J. Mills" To: Tim , Nico Williams In-Reply-To: <20110607234131.GI1565@sentinelchicken.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-787661544-1307500800=:70339" X-Mailman-Approved-At: Wed, 08 Jun 2011 08:39:52 -0700 Cc: "http-state@ietf.org" , OAuth WG , "apps-discuss@ietf.org" , HTTP Working Group Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 02:40:07 -0000 --0-787661544-1307500800=:70339 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It is possible to implement decent security with MAC, it is also possible t= o screw it up.=A0 It is far more difficult (impossible?) to implement decen= t security with cookies over HTTP.=0A=0A=0A=0A_____________________________= ___=0AFrom: Tim =0ATo: Nico Williams =0ACc: OAuth WG ; HTTP Working Group ; "apps-discuss@ietf.org" ; "http-= state@ietf.org" =0ASent: Tuesday, June 7, 2011 4:41 PM= =0ASubject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authenticat= ion Scheme=0A=0A=0A> > A passive attacker can sniff your cookie and thus hi= jack your session. All=0A> > you need to accomplish that attack is connect = to any open wifi network and=0A> > use Firesheep. It's a good bit harder to= be an active attacker, even on an=0A> > open wireless network.=0A> =0A> Ye= s, but only for resources that you've already stated you don't care about.= =0A> =0A> If you cared about those resources you'd protect more of the requ= est=0A> _and_ response, or you'd use TLS.=A0 But you don't want to protect = the=0A> response and you don't want to use TLS and you don't even want to= =0A> protect the request body.=A0 What you're proposing adds a very margina= l=0A> degree of security that will be trivial to defeat on open wifi=0A> (p= articularly once the toolset for doing it gets published).=0A> =0A> Are we = serious about security?=A0 Or it this just for show?=0A> =0A> Or am I missi= ng something?=0A=0A=0AI have to agree with Nico here.=A0 In almost all case= s I assert that, on=0Atypical modern networks:=0A=0A=A0 let P =3D difficult= y of passive attack=0A=A0 let M =3D difficulty of active (man-in-the-middle= ) attack=0A=0AO(P) =3D O(M)=0A.=0A=0A=0AThis isn't to say the "real world" = difficulty of an active attack is=0Ajust as easy, but it is within a consta= nt factor.=A0 If someone has=0Apublished a tool that conducts MitM attacks = for the specific protocol=0Ayou're dealing with, the difference in difficul= ty clearly becomes=0Amarginal.=A0 Consider the complexity of the attacks im= plemented by=0Asslstrip and yet the relative ease with which you can use it= to MitM=0Aall SSL connections.=0A=0A=0AI didn't bring this up before becau= se I didn't understand any of the=0Acontext behind the MAC proposal, but I = will now, at risk of sounding=0Aignorant: =0A=0A=A0 What is the MAC Authent= ication proposal intended to accomplish, in a=0Asecurity sense, above and b= eyond HTTP Digest?=A0 =0A=0AYes, the HTTP Digest spec is, shall we say, a l= ittle rough around the=0Aedges, but would it make more sense to simply *fix= * the minor problems=0Awith it and slightly extend it to integrate with OAu= th?=A0 Note that it=0Aalready does allow for arbitrary encrypted blob value= s to be attached=0Ato the digest...=A0 Ignoring the integration details for= a minute=0Athough, how does MAC improve on Digest from a security persepct= ive?=0A=0Atim=0A_______________________________________________=0AOAuth mai= ling list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-787661544-1307500800=:70339 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It is possible to implement decent security with MAC, it is also possible= to screw it up.  It is far more difficult (impossible?) to implement = decent security with cookies over HTTP.

From: Tim <tim-projects@sent= inelchicken.org>
To:= Nico Williams <nico@cryptonector.com>
Cc: OAuth WG <oauth@ietf.org>; HTTP Working Gro= up <ietf-http-wg@w3.org>; "apps-discuss@ietf.org" <apps-discuss@ie= tf.org>; "http-state@ietf.org" <http-state@ietf.org>
Sent: Tuesday, June 7, 2011 4:41 PM
Subject: Re: [OAUTH-WG] [http-stat= e] [apps-discuss] HTTP MAC Authentication=0A Scheme


> = > A passive attacker can sniff your cookie and thus hijack your session.= All
> > you need to accomplish that attack is connect to any open= wifi network and
> > use Firesheep. It's a good bit harder to be = an active attacker, even on an
> > open wireless network.
> =
> Yes, but only for resources that you've already stated you don't c= are about.
>
> If you cared about those resources you'd protec= t more of the request
> _and_ response, or you'd use TLS.  But y= ou don't want to protect the
> response and you don't want to use TLS= and you don't even want to
> protect the request body.  What yo= u're proposing adds a very marginal
> degree of security that will be= trivial to defeat on open wifi
> (particularly once the toolset for = doing it gets published).
>
> Are we serious about security?&n= bsp; Or it this just for show?
>
> Or am I missing something?


I have to agr= ee with Nico here.  In almost all cases I assert that, on
typical m= odern networks:

  let P =3D difficulty of passive attack
&nb= sp; let M =3D difficulty of active (man-in-the-middle) attack

O(P) = =3D O(M)
.


This isn't to say the "real world" difficulty of a= n active attack is
just as easy, but it is within a constant factor.&nbs= p; If someone has
published a tool that conducts MitM attacks for the sp= ecific protocol
you're dealing with, the difference in difficulty clearl= y becomes
marginal.  Consider the complexity of the attacks impleme= nted by
sslstrip and yet the relative ease with which you can use it to = MitM
all SSL connections.


I didn't bring this up before becau= se I didn't understand any of the
context behind the MAC proposal, but I= will now, at risk of sounding
ignorant:

  What is the MAC Authentication proposal intended to accomplish, in a
security sense, ab= ove and beyond HTTP Digest? 

Yes, the HTTP Digest spec is, sha= ll we say, a little rough around the
edges, but would it make more sense= to simply *fix* the minor problems
with it and slightly extend it to in= tegrate with OAuth?  Note that it
already does allow for arbitrary = encrypted blob values to be attached
to the digest...  Ignoring the= integration details for a minute
though, how does MAC improve on Digest= from a security persepctive?

tim
_______________________________= ________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth


--0-787661544-1307500800=:70339-- From tim-projects@sentinelchicken.org Wed Jun 8 08:39:07 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B365211E8158 for ; Wed, 8 Jun 2011 08:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.307 X-Spam-Level: X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afLrlkoAo-oi for ; Wed, 8 Jun 2011 08:39:07 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 377C911E8142 for ; Wed, 8 Jun 2011 08:39:07 -0700 (PDT) Received: (qmail 18903 invoked from network); 8 Jun 2011 15:32:25 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 8 Jun 2011 15:32:25 -0000 Received: (qmail 4385 invoked from network); 8 Jun 2011 15:33:39 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 8 Jun 2011 15:33:39 -0000 Received: (nullmailer pid 21338 invoked by uid 1000); Wed, 08 Jun 2011 15:32:25 -0000 Date: Wed, 8 Jun 2011 08:32:25 -0700 From: Tim To: "Paul E\. Jones" Message-ID: <20110608153225.GL1565@sentinelchicken.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015801cc25ab$063a2150$12ae63f0$@packetizer.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 08 Jun 2011 08:39:52 -0700 Cc: apps-discuss@ietf.org, http-state@ietf.org, 'HTTP Working Group' , 'OAuth WG' Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 15:39:07 -0000 Hi Paul, > That's the reason for the MAC. Once we can ensure the integrity of > the message exchange, then the existing cookie mechanism can provide > us with the secure state management capability we need. Maybe I'm missing something in the MAC authentication draft, but I don't see how it provides integrity for the "exchange". In particular, the body of request messages may be optionally hashed to protect their integrity, but no such facility seems to be provided for responses from the server. In many modern web applications, this could be trivially exploited by an attacker to inject malicious script into a server response. HTTP Digest authentication provides an option (auth-int) for integrity protection of both requests and responses and for every request/response after the initial authentication. In fact if servers change nonces each time, reuse of hashes becomes difficult. Some level of mutual authentication is also provided and the opaque string can be used to pass arbitrary extra data between clients and servers. IIRC, this value can be passed *cross domain* based on a defined white list. At risk of repeating myself: Why not just adapt HTTP Digest for OAuth? That is not just rhetorical, it is a genuine question. What is HTTP Digest missing that you need? tim From dzonatas@gmail.com Wed Jun 8 09:00:07 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A91228010 for ; Wed, 8 Jun 2011 09:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=-2.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YswIOuUkSal1 for ; Wed, 8 Jun 2011 09:00:06 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D83D11E8142 for ; Wed, 8 Jun 2011 09:00:06 -0700 (PDT) Received: by pwi5 with SMTP id 5so346758pwi.31 for ; Wed, 08 Jun 2011 09:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QgmZULgfsgtXWSAPm9ZK5R8N7oajwHr+8LQeJDWJ6HY=; b=FlHcYE09h47dPw6/K1pkeyPhTwKcZiCYowWGrD6l7bZ30VaYG+IUo6bH0B5T0IDeIe 9JH8q+D6TZ9FpHO/x38iU0cFYV3uA683xwKyIIaG6LpeqExO9lHfYZAGyq8iq1W1k+He Lwz3IhrcebweTL0Q6dCOA2j8dPSh5Ssqdgl2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=q4TFbfb9/3sMaLEnaXSI5/BcGlSNCZYOu2t0xsBR2NatcDr6MGcm8162KktxavKVFc Ir4PqSQaZ11H4S+sSETCrgSo5XguPNIJWnrqd2aLgffHzH7fY3axp9DAtye5MUaTsGcb /kOdZ5L77oqiFaURELOfqAw9+qNIPuKk2QBuo= Received: by 10.68.24.65 with SMTP id s1mr921433pbf.35.1307548806125; Wed, 08 Jun 2011 09:00:06 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id k4sm605073pbl.75.2011.06.08.09.00.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Jun 2011 09:00:05 -0700 (PDT) Message-ID: <4DEF9C53.4060306@gmail.com> Date: Wed, 08 Jun 2011 08:59:15 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> <1307500800.70339.YahooMailNeo@web31810.mail.mud.yahoo.com> In-Reply-To: <1307500800.70339.YahooMailNeo@web31810.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 16:00:08 -0000 On 06/07/2011 07:40 PM, William J. Mills wrote: > It is far more difficult (impossible?) to implement decent security > with cookies over HTTP. > Especially, when any addition of security cookies may cause HTTP status code 203 and even more-so in idempotent expectations. Possible workaround if MAC or GSS can be encapsulted/transformed into S/MIME multiparts/mixed streams, which is where I think the cookies should move-into and leave the origin header alone. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From presnick@qualcomm.com Wed Jun 8 10:12:05 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6E321F8546; Wed, 8 Jun 2011 10:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.391 X-Spam-Level: X-Spam-Status: No, score=-106.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3Qdxm2d1n-B; Wed, 8 Jun 2011 10:12:04 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id BA76D21F8526; Wed, 8 Jun 2011 10:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1307553124; x=1339089124; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DEFAD27.1070701@qualcomm.com>|Date:=20We d,=208=20Jun=202011=2012:11:03=20-0500|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Jiankang=20YAO=20|CC:=20IETF-Discussion=20list=20,=20,=0D=0A=09|Subject:=20Re:=20Summary=20for=20IESG=20last=20call=20t o=205892bis=20draft|References:=20|In-Reply-To:=20|Content-Type:=20text/p lain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=aB8qEwTHYfUu7F1i2dB55ZYUz7ccKNUyEfQoELPtK+M=; b=DtCcBkw5iOb9vGj3x1+wjawlk4JVsvEjiMLo4eo7Vt30GLbyk2+hxkT6 xqnMSsQ7ihKkWzxWFsMAd+uxCLkpCmbA/DaH5KEAVCdsn+03Xdfw76GYl jrW+tYpL0CG68uEXnkjT5YgNZcFMGOBcyNiJX5cmsLcl7CtbnVkObipTx U=; X-IronPort-AV: E=McAfee;i="5400,1158,6370"; a="96232796" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 08 Jun 2011 10:12:04 -0700 X-IronPort-AV: E=Sophos;i="4.65,339,1304319600"; d="scan'208";a="143323448" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 08 Jun 2011 10:12:04 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 8 Jun 2011 10:11:05 -0700 Message-ID: <4DEFAD27.1070701@qualcomm.com> Date: Wed, 8 Jun 2011 12:11:03 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Jiankang YAO References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: IETF-Discussion list , apps-discuss@ietf.org, appsawg-ads@tools.ietf.org Subject: Re: [apps-discuss] Summary for IESG last call to 5892bis draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 17:12:05 -0000 Well, a little miscommunication; I had meant to send the summary to the APPSAWG where the document was discussed, but sending it to the IETF list is OK too. Since it's here, one comment: On 6/8/11 2:04 AM, Jiankang YAO wrote: > ---------------------------- > issue4: Add the IANA IDNA registry or replace the old one? > [...] > *****We are waiting for John and Paul reaching the agreement about this issue******* > I think we have gotten agreement from folks (including but not limited to doc authors and ADs involved in the conversation) that we'll go ahead with this document and write a quick new document clarifying that what 5892 meant was that IANA should *add* a new table to the registry and (with the older one) label it as to from which version of Unicode the table was generated. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From eran@hueniverse.com Wed Jun 8 10:33:04 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E6311E8104 for ; Wed, 8 Jun 2011 10:33:04 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C4ZuTMQhwlL for ; Wed, 8 Jun 2011 10:33:03 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id DEA5311E8076 for ; Wed, 8 Jun 2011 10:33:02 -0700 (PDT) Received: (qmail 11392 invoked from network); 8 Jun 2011 17:33:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jun 2011 17:33:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 8 Jun 2011 10:32:56 -0700 From: Eran Hammer-Lahav To: Tim , "Paul E. Jones" Date: Wed, 8 Jun 2011 10:32:50 -0700 Thread-Topic: [http-state] [apps-discuss] HTTP MAC Authentication Scheme Thread-Index: Acwl8UxVsvuTiAXMQdeQ4L4C/3sh6QAEDGxg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> In-Reply-To: <20110608153225.GL1565@sentinelchicken.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'OAuth WG' , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 17:33:04 -0000 > -----Original Message----- > From: Tim [mailto:tim-projects@sentinelchicken.org] > Sent: Wednesday, June 08, 2011 8:32 AM > At risk of repeating myself: Why not just adapt HTTP Digest for OAuth? > That is not just rhetorical, it is a genuine question. What is HTTP Dige= st > missing that you need? The latest version of this draft: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00 Includes a Design Constraints section which tries to explain this: Unlike the HTTP Digest authentication scheme, this mechanism does not require interacting with the server to prevent replay attacks. Instead, the client provides both a nonce and a timestamp, which the server can use to prevent replay attacks using a bounded amount of storage. Also unlike Digest, this mechanism is not intended to protect the user's password itself because the client and server both have access to the key material in the clear. Instead, servers should issue a short-lived derivative credential for this mechanism during the initial TLS setup phase. EHL From breno@google.com Wed Jun 8 15:26:19 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4921F0C51 for ; Wed, 8 Jun 2011 15:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uy7UnHhc4WSd for ; Wed, 8 Jun 2011 15:26:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 34E531F0C49 for ; Wed, 8 Jun 2011 15:26:19 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p58MQI5O024668 for ; Wed, 8 Jun 2011 15:26:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307571978; bh=Eh29TvEYVQ8aLUKnXlMEK0zOZd0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=CHF0iBvfmoBw/hXHwOD2WB/fsWQ8iXamYQ8v8htJXC3hKjQl78pZQvkUBVJ30xRQa 3PjqeMh5uQG74eW74Qmhg== Received: from yie19 (yie19.prod.google.com [10.243.66.19]) by hpaq13.eem.corp.google.com with ESMTP id p58MPUAn005883 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 8 Jun 2011 15:26:04 -0700 Received: by yie19 with SMTP id 19so622230yie.16 for ; Wed, 08 Jun 2011 15:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZEsXVsGWrIac74D30ZKaoEDizHGk1RowbHXYAqBKR1M=; b=MfLx12RjC8/hLjbuSlfKkp92zufQaTO3AE6AWph30mgZJN97DEOZSbInUf7pbUGL0W wvmKwbN2oSxq/xF926fg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EQA+Ot4PSZWr110iCbLGG7r5IGrdwo2SnOwovSDOaNjJLPnJz/9Ps9Wn0gaFqFOVtD jQyxtsbKEY3dnWZ1F/JQ== MIME-Version: 1.0 Received: by 10.101.1.2 with SMTP id d2mr16581ani.9.1307571963776; Wed, 08 Jun 2011 15:26:03 -0700 (PDT) Received: by 10.100.244.26 with HTTP; Wed, 8 Jun 2011 15:26:03 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> Date: Wed, 8 Jun 2011 15:26:03 -0700 Message-ID: From: Breno de Medeiros To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Tim , "http-state@ietf.org" , OAuth WG , "apps-discuss@ietf.org" , HTTP Working Group Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 22:26:20 -0000 On Tue, Jun 7, 2011 at 17:07, Nico Williams wrote: > On Tue, Jun 7, 2011 at 6:41 PM, Tim wr= ote: >> I have to agree with Nico here. =A0In almost all cases I assert that, on >> typical modern networks: >> >> =A0let P =3D difficulty of passive attack >> =A0let M =3D difficulty of active (man-in-the-middle) attack >> >> O(P) =3D O(M) >> . >> >> This isn't to say the "real world" difficulty of an active attack is >> just as easy, but it is within a constant factor. =A0If someone has >> published a tool that conducts MitM attacks for the specific protocol >> you're dealing with, the difference in difficulty clearly becomes >> marginal. =A0Consider the complexity of the attacks implemented by >> sslstrip and yet the relative ease with which you can use it to MitM >> all SSL connections. > > Exactly, and very well put. > > Active attacks sound harder, and they do actually require more work, > but in many cases that work can be automated, and once automated there > can be no difference in effort required to mount an active attack > versus a passive one. > > Do we suppose that this proposal can get past secdir, IESG, and IETF > reviews as-is? =A0I doubt it. > > Here's another issue: some of you are saying that an application using > this extension will be using TLS for some things but not others, which > presumes a TLS session. =A0Does using TLS _with_ session resumption > _and_ HTTP/1.1 pipelining for all requests really cost that much more > in latency and compute (and electric) power than the proposed > alternative? =A0I seriously doubt it, and I'd like to see some real > analysis showing that I'm wrong before I'd accept such a rationale for > this sort of proposal. Google has performed detailed analysis of SSL performance after several optimizations and we have concluded that the answer is 'no significant overhead' as you suggest. Indeed, in some workload situations it may be actually cheaper to serve SSL traffic because there is reduction in network latency by avoiding bad proxies. We have published some results here: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html > > Or perhaps the motivation relates to accidental leakage of "secure" > cookies in non-secure contexts. =A0But why not just fix the clients in > that case? > > Nico > -- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 --Breno From nico@cryptonector.com Wed Jun 8 15:30:19 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025D721F8490; Wed, 8 Jun 2011 15:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gxrb-ocgHXn; Wed, 8 Jun 2011 15:30:18 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA6521F848F; Wed, 8 Jun 2011 15:30:18 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id C16E635007A; Wed, 8 Jun 2011 15:30:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=xvMSouKYJD7Mhn9JGzAqPoQxa9Qnv3MRnUWqyLqoE7Qf z++bCKQ+7zVjDqeXeZt3Wp0s1e9KrWOlgWT2kKFpHYkfuh/Y6VKyZxV3FIzU8ZND aR2FxDtzkEoNIXKS/C3lbR4EfEc6erYUmIQVTaIKMM/+mLo81/TuYC/5n02V9Kk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kd1WcEXZG0a9WviCNc7RPHRJbk0=; b=GVTcmGLFqnV i87bhDF1h8ddigZFgMCyn2zWtxECXIwIyPkVPDcxk4cImAXH+vD2M9eAX6EGFjVj EQhsMszWDxX4Zq3lTRnhc65HDqZgK4qBaRiFMAh/ywA3A0mnfevVIolboXG2kUDH DFbqMXbVjIOtmqwlNoA2RvFw4w8f8Zxk= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 93CE9350058; Wed, 8 Jun 2011 15:30:17 -0700 (PDT) Received: by pvh18 with SMTP id 18so505009pvh.31 for ; Wed, 08 Jun 2011 15:30:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr1122589pbc.523.1307572217268; Wed, 08 Jun 2011 15:30:17 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 15:30:16 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> Date: Wed, 8 Jun 2011 17:30:16 -0500 Message-ID: From: Nico Williams To: Breno de Medeiros Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Tim , "http-state@ietf.org" , OAuth WG , "apps-discuss@ietf.org" , HTTP Working Group Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 22:30:19 -0000 On Wed, Jun 8, 2011 at 5:26 PM, Breno de Medeiros wrote: > On Tue, Jun 7, 2011 at 17:07, Nico Williams wrote= : >> Here's another issue: some of you are saying that an application using >> this extension will be using TLS for some things but not others, which >> presumes a TLS session. =C2=A0Does using TLS _with_ session resumption >> _and_ HTTP/1.1 pipelining for all requests really cost that much more >> in latency and compute (and electric) power than the proposed >> alternative? =C2=A0I seriously doubt it, and I'd like to see some real >> analysis showing that I'm wrong before I'd accept such a rationale for >> this sort of proposal. > > Google has performed detailed analysis of SSL performance after > several optimizations and we have concluded that the answer is 'no > significant overhead' as you suggest. Indeed, in some workload > situations it may be actually cheaper to serve SSL traffic because > there is reduction in network latency by avoiding bad proxies. We have > published some results here: > http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html Sweet! Thanks for confirming my intuition, and then some. I like the idea that using TLS actually reduces latency -- I'd not have imagined it. Nico -- From svartman95@gmail.com Wed Jun 8 17:24:28 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC6611E809E; Wed, 8 Jun 2011 17:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8Zm9RP2daKP; Wed, 8 Jun 2011 17:24:27 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8D7911E8080; Wed, 8 Jun 2011 17:24:27 -0700 (PDT) Received: by gxk19 with SMTP id 19so647769gxk.31 for ; Wed, 08 Jun 2011 17:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=566QAG7CNN/tVaKePByWyGGCc6puSRwhNRUG+WxTV1Q=; b=U1WaseFwTD/Wm7SHzYmU7EUjrBrFd5sv1Vz16EnRc2Isu8a3nYKsX4CamYrcLIu2Tl EUgLpVjMHJiUd0Q6/lFdSekNj3ISsW59wyG19zhRiRJcUnSnyVAITtaiQ5vZTyLaaW4r sErnQ09Fy59ooISUziIaPYXhqBy5NMFmS5bIw= 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=XF9yZ+u4/LaP+5IbVz5E3C1mjF6hhhgJSfVifeu2RI4WuAPmVSJ24wnlblI5OPpivG 09LCU8nhAj8vDNSQbiInA4dSdmbpazbCG6X5/M9YbaEiudDvKB+tZwKWG/gbobHsYDHb 5yGU2rtw7VXnr361OGFBICI/QFKxhyTRsmC7g= MIME-Version: 1.0 Received: by 10.236.186.38 with SMTP id v26mr65736yhm.415.1307579066953; Wed, 08 Jun 2011 17:24:26 -0700 (PDT) Received: by 10.236.47.228 with HTTP; Wed, 8 Jun 2011 17:24:25 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> Date: Thu, 9 Jun 2011 00:24:25 +0000 Message-ID: From: Bjartur Thorlacius To: Nico Williams Content-Type: text/plain; charset=UTF-8 Cc: Tim , HTTP Working Group , OAuth WG , "apps-discuss@ietf.org" , "http-state@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2011 00:24:28 -0000 On 6/8/11, Nico Williams wrote: > Sweet! Thanks for confirming my intuition, and then some. I like the > idea that using TLS actually reduces latency -- I'd not have imagined > it. > Well, it's the enforcement of the end-to-end principle that reduces latency, not the TLS protocol per se. You'd get the same effect if HTTP didn't support proxies in the first place. From paulej@packetizer.com Wed Jun 8 22:04:00 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A96811E8074; Wed, 8 Jun 2011 22:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQF-pv-jrl7m; Wed, 8 Jun 2011 22:03:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7407111E80A1; Wed, 8 Jun 2011 22:03:57 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p5953hAL023650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2011 01:03:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307595829; bh=bHUS1hrduBOhmVFiZU6VBRq2kMVBuAuYbE74ZGGRx8c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=epqzw1+fBL5v7YSl+6SHpNmcKgiGq3AQOac3v7bKnxDPSEGp4mHZZBtr6efZD+RmO SeV3yDxMFF4LJdc8W1BW3lQm6AumAdv24K+FvL5ZjN1jEkArFJW5B1LnYLOH2F/5zf ndZukHsMv+FSYo9RMrLVSodAa4GA+s4566kvYYSI= From: "Paul E. Jones" To: "'Nico Williams'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> In-Reply-To: Date: Thu, 9 Jun 2011 01:03:35 -0400 Message-ID: <02c401cc2662$9a21d220$ce657660$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C5_01CC2641.13103220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDABal05/QI7UtjxlOx2sXA= Content-Language: en-us Cc: apps-discuss@ietf.org, 'Ben Adida' , http-state@ietf.org, 'Adam Barth' , 'OAuth WG' , 'HTTP Working Group' Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2011 05:04:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02C5_01CC2641.13103220 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What issues, specifically. (Messages are all over the place and I = don=E2=80=99t know exactly what issues you=E2=80=99re raising. Is it = with the approach we=E2=80=99re proposing or something else?) =20 Paul =20 From: Nico Williams [mailto:nico@cryptonector.com]=20 Sent: Wednesday, June 08, 2011 10:55 AM To: Paul E. Jones Cc: apps-discuss@ietf.org; Nico Williams; OAuth WG; HTTP Working Group; = Ben Adida; Adam Barth; Eran Hammer-Lahav; http-state@ietf.org Subject: RE: [http-state] [apps-discuss] HTTP MAC Authentication Scheme =20 On Jun 8, 2011 2:09 AM, "Paul E. Jones" wrote: > > Nico, > > Cookies would still be employed. A cookie would be used to identify = the particular user, for example. However, it's important to make sure = that the cookie provided by the client to the server is not stolen. = It's important to ensure that the client provided by the server to the = client is not modified. That's the reason for the MAC. Once we can = ensure the integrity of the message exchange, then the existing cookie = mechanism can provide us with the secure state management capability we = need. You're still not addressing the issues raised. Nico --=20 ------=_NextPart_000_02C5_01CC2641.13103220 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

What issues, specifically.=C2=A0 (Messages are all over the place and = I don=E2=80=99t know exactly what issues you=E2=80=99re raising.=C2=A0 = Is it with the approach we=E2=80=99re proposing or something = else?)

 

Paul

 

From:= = Nico Williams [mailto:nico@cryptonector.com]
Sent: Wednesday, = June 08, 2011 10:55 AM
To: Paul E. Jones
Cc: = apps-discuss@ietf.org; Nico Williams; OAuth WG; HTTP Working Group; Ben = Adida; Adam Barth; Eran Hammer-Lahav; = http-state@ietf.org
Subject: RE: [http-state] [apps-discuss] = HTTP MAC Authentication Scheme

 


On Jun 8, 2011 2:09 AM, = "Paul E. Jones" <paulej@packetizer.com> = wrote:
>
> Nico,
>
> Cookies would still be = employed.  A cookie would be used to identify the particular user, = for example.  However, it's important to make sure that the cookie = provided by the client to the server is not stolen.  It's important = to ensure that the client provided by the server to the client is not = modified.  That's the reason for the MAC.  Once we can ensure = the integrity of the message exchange, then the existing cookie = mechanism can provide us with the secure state management capability we = need.

You're still not addressing the issues = raised.

Nico
-- =

------=_NextPart_000_02C5_01CC2641.13103220-- From paulej@packetizer.com Wed Jun 8 22:13:21 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0B11E80A1; Wed, 8 Jun 2011 22:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWNlOPCX6C02; Wed, 8 Jun 2011 22:13:21 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B1AE411E808D; Wed, 8 Jun 2011 22:13:20 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p595DCHV024090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2011 01:13:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307596397; bh=slx2jdY6CfKAWo//nDtH0XhGc+XjcXkUrBdSyGAS4t4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LoFlQNxAfimVGF8/HQnsk92vMbGZdUSpuvjny1jNF8leCFTPBBMcoWbcoStQ7Pnf/ 5ZMMjdWHiCzeCHWWe8FbwAxbpMbWpNZyVAm1cO/urIT0UyikmqhmvBDJNuHSvBlqjH +osK1DrzqWwkUq7zHsQ4FRd1R+HN6lyhmjIW0RXY= From: "Paul E. Jones" To: "'Tim'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> In-Reply-To: <20110608153225.GL1565@sentinelchicken.org> Date: Thu, 9 Jun 2011 01:13:04 -0400 Message-ID: <02d101cc2663$eceb6790$c6c236b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDABal05/QFg30tslPNKqlA= Content-Language: en-us Cc: apps-discuss@ietf.org, http-state@ietf.org, 'HTTP Working Group' , 'OAuth WG' Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2011 05:13:21 -0000 Tim, > Hi Paul, > > > That's the reason for the MAC. Once we can ensure the integrity of > > the message exchange, then the existing cookie mechanism can provide > > us with the secure state management capability we need. > > Maybe I'm missing something in the MAC authentication draft, but I don't > see how it provides integrity for the "exchange". In particular, the > body of request messages may be optionally hashed to protect their > integrity, but no such facility seems to be provided for responses from > the server. In many modern web applications, this could be trivially > exploited by an attacker to inject malicious script into a server > response. You are referring to draft-salgueiro-secure-state-management-04? In that document, Section 6 covers responses from the server. The server may hash any part of the message it wishes, including the body and selected header. It's possible to also have an empty body and including that in the hash will ensure that no body is inserted where one shouldn't have been. > HTTP Digest authentication provides an option (auth-int) for integrity > protection of both requests and responses and for every request/response > after the initial authentication. In fact if servers change nonces each > time, reuse of hashes becomes difficult. Some level of mutual > authentication is also provided and the opaque string can be used to > pass arbitrary extra data between clients and servers. > IIRC, this value can be passed *cross domain* based on a defined white > list. > > At risk of repeating myself: Why not just adapt HTTP Digest for OAuth? > That is not just rhetorical, it is a genuine question. What is HTTP > Digest missing that you need? We've not looked at HTTP Digest and we were not targeting OAuth with our document. Just so that I'm looking at the right "HTTP Digest" text, can you tell me the document name? I found several when I did a search. Paul From evnikita2@gmail.com Thu Jun 9 02:55:32 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D916211E80B5; Thu, 9 Jun 2011 02:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUM9cTaP1saZ; Thu, 9 Jun 2011 02:55:32 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2B411E8071; Thu, 9 Jun 2011 02:55:31 -0700 (PDT) Received: by bwz13 with SMTP id 13so1359887bwz.31 for ; Thu, 09 Jun 2011 02:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=U7pPyb8sLMQvZwTdrbWL7SbZ2o7ECzjBigEWsCjkK1M=; b=V++avwnPYrxokzfAEi7vxrRO/jz9Q04GBma8ZdjAXzAN+netl4/UEnNsYb06aMhWcw 7dV3SMuTqkbUJTd43yQ0CSJt45by+QeqMbfkAy2RrP7enai8K5a5YclO+gfQwdx3YH7J oMIsalyaXwviubORVBcWtwTRDVa16V4Lj0LEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=Ehi1cjpTj+xzAypjO+YgkA3xMR1mYGAMgCMKDFjrFOwr1elQIAhcO0WhXGLz0AOthW 0Ajta6z6VcYwZRLWGPTV58ShurDzefp2g0uh4bIjLSxBN31g/Ig0Roa62biAcWou99nI 9wPCs+lKl6l/hdTQxzIHUZVe1jRqOW5n44MjY= Received: by 10.204.33.70 with SMTP id g6mr537975bkd.123.1307613330185; Thu, 09 Jun 2011 02:55:30 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id a28sm1318906fak.1.2011.06.09.02.55.28 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 02:55:29 -0700 (PDT) Message-ID: <4DF098BE.1000009@gmail.com> Date: Thu, 09 Jun 2011 12:56:14 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "uri-review@ietf.org" , URI , Apps-discuss list Content-Type: multipart/alternative; boundary="------------010609050803090606060606" Subject: [apps-discuss] FYI: RFC 6270 on The 'tn3270' URI Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2011 09:55:33 -0000 This is a multi-part message in MIME format. --------------010609050803090606060606 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit This is FYI. Mykyta. > A new Request for Comments is now available in online RFC libraries. > > > RFC 6270 > > Title: The 'tn3270' URI Scheme > Author: M. Yevstifeyev > Status: Standards Track > Stream: IETF > Date: June 2011 > Mailbox:evnikita2@gmail.com > Pages: 6 > Characters: 10876 > Updates: RFC2355, RFC1738, RFC1041 > > I-D Tag: draft-yevstifeyev-tn3270-uri-18.txt > > URL:http://www.rfc-editor.org/rfc/rfc6270.txt > > This document is the specification of the 'tn3270' Uniform Resource > Identifier (URI) scheme, which is used to designate the access to the > resources available via Telnet 3270 mode (TN3270) and Telnet 3270 > Enhanced mode (TN3270E). It updates RFC 1041 and RFC 2355, which > specify these protocols, and RFC 1738, which firstly mentioned this > URI scheme without defining its syntax and semantics. [STANDARDS-TRACK] > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, seehttp://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, seehttp://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or torfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --------------010609050803090606060606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit This is FYI.  Mykyta.
A new Request for Comments is now available in online RFC libraries.

        
        RFC 6270

        Title:      The 'tn3270' URI Scheme 
        Author:     M. Yevstifeyev
        Status:     Standards Track
        Stream:     IETF
        Date:       June 2011
        Mailbox:    evnikita2@gmail.com
        Pages:      6
        Characters: 10876
        Updates:    RFC2355, RFC1738, RFC1041

        I-D Tag:    draft-yevstifeyev-tn3270-uri-18.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6270.txt

This document is the specification of the 'tn3270' Uniform Resource 
Identifier (URI) scheme, which is used to designate the access to the 
resources available via Telnet 3270 mode (TN3270) and Telnet 3270 
Enhanced mode (TN3270E).  It updates RFC 1041 and RFC 2355, which 
specify these protocols, and RFC 1738, which firstly mentioned this 
URI scheme without defining its syntax and semantics.  [STANDARDS-TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
--------------010609050803090606060606-- From tim-projects@sentinelchicken.org Thu Jun 9 07:36:43 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792BA11E80D2 for ; Thu, 9 Jun 2011 07:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=-1.191, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StpE7Sq4hyrO for ; Thu, 9 Jun 2011 07:36:43 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 13ED511E808B for ; Thu, 9 Jun 2011 07:36:43 -0700 (PDT) Received: (qmail 24240 invoked from network); 9 Jun 2011 14:30:01 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 9 Jun 2011 14:30:01 -0000 Received: (qmail 19446 invoked from network); 9 Jun 2011 14:31:11 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 9 Jun 2011 14:31:11 -0000 Received: (nullmailer pid 28089 invoked by uid 1000); Thu, 09 Jun 2011 14:30:00 -0000 Date: Thu, 9 Jun 2011 07:30:00 -0700 From: Tim To: "Paul E\. Jones" Message-ID: <20110609143000.GQ1565@sentinelchicken.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <02d101cc2663$eceb6790$c6c236b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02d101cc2663$eceb6790$c6c236b0$@packetizer.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'OAuth WG' , 'HTTP Working Group' , apps-discuss@ietf.org, http-state@ietf.org Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2011 14:36:43 -0000 > You are referring to draft-salgueiro-secure-state-management-04? > > In that document, Section 6 covers responses from the server. The server > may hash any part of the message it wishes, including the body and selected > header. It's possible to also have an empty body and including that in the > hash will ensure that no body is inserted where one shouldn't have been. No, throughout this discussion I'm just looking at: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token Does this tie in to the secure state management draft? If so, can you point me to the section in the MAC draft so I can get up to speed? > We've not looked at HTTP Digest and we were not targeting OAuth with our > document. Just so that I'm looking at the right "HTTP Digest" text, can you > tell me the document name? I found several when I did a search. Just the (latest?) RFC: http://www.ietf.org/rfc/rfc2617.txt thanks, tim From tim-projects@sentinelchicken.org Thu Jun 9 07:42:29 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535E321F8477 for ; Thu, 9 Jun 2011 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-1.389, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5o-v2p4eIXC for ; Thu, 9 Jun 2011 07:42:25 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1D46921F8476 for ; Thu, 9 Jun 2011 07:42:25 -0700 (PDT) Received: (qmail 24291 invoked from network); 9 Jun 2011 14:42:24 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 9 Jun 2011 14:42:24 -0000 Received: (qmail 19503 invoked from network); 9 Jun 2011 14:43:35 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 9 Jun 2011 14:43:35 -0000 Received: (nullmailer pid 28192 invoked by uid 1000); Thu, 09 Jun 2011 14:42:24 -0000 Date: Thu, 9 Jun 2011 07:42:24 -0700 From: Tim To: Robert Sayre Message-ID: <20110609144224.GR1565@sentinelchicken.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "apps-discuss@ietf.org" , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2011 14:42:29 -0000 > Digest has a bunch of problems. See this document > > http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#section-2.2.2 > > for a short tour of them. Thanks for the link. I totally agree with all of this, and in fact there are more MitM attacks possible than are alluded to in that document. This is one of the two reasons I brought up Digest initially. The MAC proposal does not appear to provide any additional security over Digest, and yet Digest is still susceptible to MitM attacks. We can pick and prod at the MAC proposal all we want from a security perspective, but we'll probably end up at the same place that Digest is at, security-wise. We'll still have a protocol that can't defend against MitM attacks. So what is the point in providing integrity again? We need to use TLS. Everywhere. The more you look at advanced web attacks (MitM downgrade attacks, DNS rebinding attacks, etc), the more you realize that most of these are addressed by TLS if only it were used everywhere. It's fine to bring out special-purpose authentication protocols. Authentication can happen in a variety of ways either within TLS or tunneled over it (hopefully with channel binding), but don't pretend you'll be doing anyone favors by trying to provide partial integrity protection that is ultimately ineffective. Just focus on better authentication and key/certificate management and let TLS do the rest. tim From internet-drafts@ietf.org Thu Jun 9 08:02:40 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACCF21F855C; Thu, 9 Jun 2011 08:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHnRAVkgZI6s; Thu, 9 Jun 2011 08:02:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BE921F8556; Thu, 9 Jun 2011 08:02:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110609150239.24286.7944.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2011 08:02:39 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-faltstrom-5892bis-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2011 15:02:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : The Unicode code points and IDNA - Unicode 6.0 Author(s) : Patrik Faltstrom Paul Hoffman Filename : draft-faltstrom-5892bis-05.txt Pages : 5 Date : 2011-06-09 This memo documents IETF consensus for IDNA derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-faltstrom-5892bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-faltstrom-5892bis-05.txt From sayrer@gmail.com Wed Jun 8 20:53:13 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EF611E8084; Wed, 8 Jun 2011 20:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEMT+rGY9S1w; Wed, 8 Jun 2011 20:53:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 465C011E8078; Wed, 8 Jun 2011 20:53:11 -0700 (PDT) Received: by vxg33 with SMTP id 33so1219782vxg.31 for ; Wed, 08 Jun 2011 20:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7+OuI7nMzSdOiI4TY2x7oxBl9Cr0FcxkduNdE1pceI4=; b=Ikf0HLeEhmJQMQYywovgv9WA94Klipy2XQ7vKKKReWeRQS6FFJQnfVgcn5QfdE2Y5I Ha9diz3mr1GajlvWyr1J/itE8luPFRHNUeVFb+zP0raryjOBBgzXxUbxNcNoQyViowKp BLTEpFbySq1PvNe8m5DTqdgsdtigBDqrtGW0g= 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=cH4Y3ug7EpA/Ig2xWO40p9Kh49NA+S6dCac/ZHKP/FVOKz/u3xUZvqbI+DxKFodiSh 7e+I1fOtwEA2QUXD8vdJioK1R+4gEg0Y2/kXIxu3YLPRMJ0A78ww7ZmCZ05XNvLFcLDU KMtUtAf8Cr46h7W61UBXxGpoYWKSbhIwT+irY= MIME-Version: 1.0 Received: by 10.52.76.10 with SMTP id g10mr310749vdw.252.1307591590090; Wed, 08 Jun 2011 20:53:10 -0700 (PDT) Received: by 10.52.111.169 with HTTP; Wed, 8 Jun 2011 20:53:10 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 8 Jun 2011 20:53:10 -0700 Message-ID: From: Robert Sayre To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 09 Jun 2011 08:37:18 -0700 Cc: Tim , OAuth WG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2011 03:53:13 -0000 On Wed, Jun 8, 2011 at 10:32 AM, Eran Hammer-Lahav wrote: >> -----Original Message----- >> From: Tim [mailto:tim-projects@sentinelchicken.org] >> Sent: Wednesday, June 08, 2011 8:32 AM > >> At risk of repeating myself: Why not just adapt HTTP Digest for OAuth? >> That is not just rhetorical, it is a genuine question. What is HTTP Digest >> missing that you need? Digest has a bunch of problems. See this document http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#section-2.2.2 for a short tour of them. > The latest version of this draft: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00 > > Includes a Design Constraints section which tries to explain this: > > Unlike the HTTP Digest authentication scheme, this mechanism does not > require interacting with the server to prevent replay attacks. > Instead, the client provides both a nonce and a timestamp, which the > server can use to prevent replay attacks using a bounded amount of > storage. It's not obvious to me why the mechanism in the draft is better than a server-generated nonce and/or opaque string, as found in Digest. The mechanism in the draft can be bitten by clock skew problems, and having the server send a nonce doesn't necessarily require an unbounded amount of storage. I'm sorry if I've missed previous discussion on this issue, but could someone explain? > Also unlike Digest, this mechanism is not intended to > protect the user's password itself because the client and server both > have access to the key material in the clear. Instead, servers > should issue a short-lived derivative credential for this mechanism > during the initial TLS setup phase. That makes sense. I'm having trouble reconciling the Design Constraints section (1.1) with the section on Entropy of MAC Keys (7.5). How long are these keys supposed to be around in practice? Also, Adam wrote "this mechanism is for folks who cannot or will not deploy TLS". How does that statement fit here? - Rob From internet-drafts@ietf.org Thu Jun 9 15:50:26 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CF01F0C5C; Thu, 9 Jun 2011 15:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIgSxqNAGcNh; Thu, 9 Jun 2011 15:50:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E011F0C3D; Thu, 9 Jun 2011 15:50:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110609225026.4504.91435.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2011 15:50:26 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2011 22:50:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Terminology Used in Internationalization in the IETF Author(s) : Paul Hoffman John C Klensin Filename : draft-ietf-appsawg-rfc3536bis-02.txt Pages : 47 Date : 2011-06-09 This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-02.txt From barryleiba@gmail.com Thu Jun 9 16:00:20 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3F211E811A for ; Thu, 9 Jun 2011 16:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5KfKS1kPLmS for ; Thu, 9 Jun 2011 16:00:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CFDA011E8116 for ; Thu, 9 Jun 2011 16:00:18 -0700 (PDT) Received: by vxg33 with SMTP id 33so2220666vxg.31 for ; Thu, 09 Jun 2011 16:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=Hoe4k8ECy2d8x/V2oDtYtLYVzTlgR6cD38xi8gcYNwI=; b=YU+Bg4PGHKm9AdzDA2GbpZPAhFE1wmwhvFAv3HxJD+XOb08E1njuNFtvJV6WokTrFf HEp3okX2uw8zJK/qca5XV0Lev0YvtpE4Zs+HBxqAcxKe6Ew8EgjaM3kaZ8UMWc4LvMPq vQL0C0N6ju6MpnzlIEGqx4DM6mfHud7r4gvTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=keYMiBEyFJG5iIZJQwJEyAPD07ybX07crql3Y4PcVf+3czzuPdMlYk+UxblBYnFs40 PlfryrLCZSfdxzoia/teFhVYmvMqFs6WwMvLM6dievRLm9ICsw1Iug2I3UoBoVKOKDhj iZDXtjHvoX74d41j54rXaZ8BybdZb4pAaWL6E= MIME-Version: 1.0 Received: by 10.236.78.1 with SMTP id f1mr1763116yhe.391.1307660416938; Thu, 09 Jun 2011 16:00:16 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.42.200 with HTTP; Thu, 9 Jun 2011 16:00:16 -0700 (PDT) Date: Thu, 9 Jun 2011 19:00:16 -0400 X-Google-Sender-Auth: U91TSLkR9BTD4COCmz1NATN7Qos Message-ID: From: Barry Leiba To: appsawg-ads@tools.ietf.org Content-Type: multipart/mixed; boundary=20cf300fab09a374b704a54f6aab Cc: Apps Discuss Subject: [apps-discuss] Request to publish draft-ietf-appsawg-rfc3536bis-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2011 23:00:20 -0000 --20cf300fab09a374b704a54f6aab Content-Type: text/plain; charset=ISO-8859-1 Area Directors: The Applications Area Working Group requests the publication of draft-ietf-appsawg-rfc3536bis-02 as a BCP, obsoleting RFC 3536, which is Informational. Attached is the PROTO writeup. Barry, appsawg chair, and document shepherd --20cf300fab09a374b704a54f6aab Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-appsawg-rfc3536bis-02-PROTO.txt" Content-Disposition: attachment; filename="draft-ietf-appsawg-rfc3536bis-02-PROTO.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_goqb7x610 UFJPVE8gd3JpdGV1cCBmb3IgZHJhZnQtaWV0Zi1hcHBzYXdnLXJmYzM1MzZiaXMtMDIKClRoZSBB cHBsaWNhdGlvbnMgQXJlYSBXb3JraW5nIEdyb3VwIHJlcXVlc3RzIHRoZSBwdWJsaWNhdGlvbiBv ZiBkcmFmdC1pZXRmLWFwcHNhd2ctcmZjMzUzNmJpcy0wMiBhcyBhIEJDUCwgb2Jzb2xldGluZyBS RkMgMzUzNiwgd2hpY2ggaXMgSW5mb3JtYXRpb25hbC4KCiAgKDEuYSkgV2hvIGlzIHRoZSBEb2N1 bWVudCBTaGVwaGVyZCBmb3IgdGhpcyBkb2N1bWVudD8gSGFzIHRoZQogICAgICAgIERvY3VtZW50 IFNoZXBoZXJkIHBlcnNvbmFsbHkgcmV2aWV3ZWQgdGhpcyB2ZXJzaW9uIG9mIHRoZSAKICAgICAg ICBkb2N1bWVudCBhbmQsIGluIHBhcnRpY3VsYXIsIGRvZXMgaGUgb3Igc2hlIGJlbGlldmUgdGhp cyAKICAgICAgICB2ZXJzaW9uIGlzIHJlYWR5IGZvciBmb3J3YXJkaW5nIHRvIHRoZSBJRVNHIGZv ciBwdWJsaWNhdGlvbj8gCgpCYXJyeSBMZWliYSBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuICBJ IGhhdmUgcmV2aWV3ZWQgdGhpcyB2ZXJzaW9uLCBhbmQgYW0gc2F0aXNmaWVkIHRoYXQgaXQncyBy ZWFkeS4KCiAgKDEuYikgSGFzIHRoZSBkb2N1bWVudCBoYWQgYWRlcXVhdGUgcmV2aWV3IGJvdGgg ZnJvbSBrZXkgV0cgbWVtYmVycyAKICAgICAgICBhbmQgZnJvbSBrZXkgbm9uLVdHIG1lbWJlcnM/ IERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUgCiAgICAgICAgYW55IGNvbmNlcm5zIGFi b3V0IHRoZSBkZXB0aCBvciBicmVhZHRoIG9mIHRoZSByZXZpZXdzIHRoYXQgCiAgICAgICAgaGF2 ZSBiZWVuIHBlcmZvcm1lZD8gIAoKVGhlIGRvY3VtZW50IGhhcyBhZGVxdWF0ZSByZXZpZXcsIG9u IHRoZSBJRE5BYmlzIGFuZCBFQUkgbGlzdHMgYW5kIHRoZW4gb24gdGhlIGFwcHMtZGlzY3VzcyBs aXN0LCBhbmQgSSBoYXZlIG5vIGNvbmNlcm5zLgoKICAoMS5jKSBEb2VzIHRoZSBEb2N1bWVudCBT aGVwaGVyZCBoYXZlIGNvbmNlcm5zIHRoYXQgdGhlIGRvY3VtZW50IAogICAgICAgIG5lZWRzIG1v cmUgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGJyb2FkZXIgcGVyc3BlY3RpdmUsIAogICAg ICAgIGUuZy4sIHNlY3VyaXR5LCBvcGVyYXRpb25hbCBjb21wbGV4aXR5LCBzb21lb25lIGZhbWls aWFyIHdpdGggCiAgICAgICAgQUFBLCBpbnRlcm5hdGlvbmFsaXphdGlvbiBvciBYTUw/IAoKSSBo YXZlIG5vIGNvbmNlcm5zLgoKICAoMS5kKSBEb2VzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXZl IGFueSBzcGVjaWZpYyBjb25jZXJucyBvciAKICAgICAgICBpc3N1ZXMgd2l0aCB0aGlzIGRvY3Vt ZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IKICAgICAgICBhbmQvb3IgdGhl IElFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyBGb3IgZXhhbXBsZSwgcGVyaGFwcyBoZSAKICAgICAg ICBvciBzaGUgaXMgdW5jb21mb3J0YWJsZSB3aXRoIGNlcnRhaW4gcGFydHMgb2YgdGhlIGRvY3Vt ZW50LCBvciAKICAgICAgICBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHkgaXMgYSBu ZWVkIGZvciBpdC4gSW4gYW55IAogICAgICAgIGV2ZW50LCBpZiB0aGUgV0cgaGFzIGRpc2N1c3Nl ZCB0aG9zZSBpc3N1ZXMgYW5kIGhhcyBpbmRpY2F0ZWQgCiAgICAgICAgdGhhdCBpdCBzdGlsbCB3 aXNoZXMgdG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQsIGRldGFpbCB0aG9zZSAKICAgICAgICBjb25j ZXJucyBoZXJlLiBIYXMgYW4gSVBSIGRpc2Nsb3N1cmUgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50 IAogICAgICAgIGJlZW4gZmlsZWQ/IElmIHNvLCBwbGVhc2UgaW5jbHVkZSBhIHJlZmVyZW5jZSB0 byB0aGUgCiAgICAgICAgZGlzY2xvc3VyZSBhbmQgc3VtbWFyaXplIHRoZSBXRyBkaXNjdXNzaW9u IGFuZCBjb25jbHVzaW9uIG9uIAogICAgICAgIHRoaXMgaXNzdWUuIAoKSSBoYXZlIG5vIGNvbmNl cm5zLiAgVGhlcmUgaXMgbm8gSVBSIGludm9sdmVkLgoKICAoMS5lKSBIb3cgc29saWQgaXMgdGhl IFdHIGNvbnNlbnN1cyBiZWhpbmQgdGhpcyBkb2N1bWVudD8gRG9lcyBpdCAKICAgICAgICByZXBy ZXNlbnQgdGhlIHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aCAK ICAgICAgICBvdGhlcnMgYmVpbmcgc2lsZW50LCBvciBkb2VzIHRoZSBXRyBhcyBhIHdob2xlIHVu ZGVyc3RhbmQgYW5kIAogICAgICAgIGFncmVlIHdpdGggaXQ/ICAgCgpUaGVyZSBpcyBjb25zZW5z dXMgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgYmVoaW5kIGl0LCBub3QganVzdCAiYSBmZXciLiAgVGhh dCBzYWlkLCBpbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBhIHZlcnkgc3BlY2lhbGl6ZWQgdG9waWMs IGFuZCB0aGUgbWFqb3JpdHkgb2YgQXBwbGljYXRpb25zIEFyZWEgcGFydGljaXBhbnRzIGFyZSBu b3Qgd2VsbCB2ZXJzZWQgaW4gaXQsIGFuZCBoYXZlIG5vdCBjb21tZW50ZWQgb24gdGhlIGRvY3Vt ZW50LgoKICAoMS5mKSBIYXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lz ZSBpbmRpY2F0ZWQgZXh0cmVtZSAKICAgICAgICBkaXNjb250ZW50PyBJZiBzbywgcGxlYXNlIHN1 bW1hcmlzZSB0aGUgYXJlYXMgb2YgY29uZmxpY3QgaW4gCiAgICAgICAgc2VwYXJhdGUgZW1haWwg bWVzc2FnZXMgdG8gdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IuIChJdCAKICAgICAgICBz aG91bGQgYmUgaW4gYSBzZXBhcmF0ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVlc3Rpb25uYWlyZSBp cyAKICAgICAgICBlbnRlcmVkIGludG8gdGhlIElEIFRyYWNrZXIuKSAKCk5vLgoKICAoMS5nKSBI YXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgdmVyaWZpZWQgdGhhdCB0aGUgCiAg ICAgICAgZG9jdW1lbnQgc2F0aXNmaWVzIGFsbCBJRCBuaXRzPyAoU2VlIHRoZSBJbnRlcm5ldC1E cmFmdHMgQ2hlY2tsaXN0IAogICAgICAgIGFuZCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMv aWRuaXRzLykuIEJvaWxlcnBsYXRlIGNoZWNrcyBhcmUgCiAgICAgICAgbm90IGVub3VnaDsgdGhp cyBjaGVjayBuZWVkcyB0byBiZSB0aG9yb3VnaC4gSGFzIHRoZSBkb2N1bWVudCAKICAgICAgICBt ZXQgYWxsIGZvcm1hbCByZXZpZXcgY3JpdGVyaWEgaXQgbmVlZHMgdG8sIHN1Y2ggYXMgdGhlIE1J QiAKICAgICAgICBEb2N0b3IsIG1lZGlhIHR5cGUgYW5kIFVSSSB0eXBlIHJldmlld3M/IAoKSSBo YXZlIHZlcmlmaWVkIGl0IHdpdGggaWRuaXRzIHZlcnNpb24gMi4xMi4xMi4gIEl0IGlzIGZpbmUu CgogICgxLmgpIEhhcyB0aGUgZG9jdW1lbnQgc3BsaXQgaXRzIHJlZmVyZW5jZXMgaW50byBub3Jt YXRpdmUgYW5kIAogICAgICAgIGluZm9ybWF0aXZlPyBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVy ZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgCiAgICAgICAgYXJlIG5vdCByZWFkeSBmb3IgYWR2YW5j ZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyIAogICAgICAgIHN0YXRlPyBJZiBz dWNoIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZSAKICAgICAgICBzdHJh dGVneSBmb3IgdGhlaXIgY29tcGxldGlvbj8gQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2Vz IAogICAgICAgIHRoYXQgYXJlIGRvd253YXJkIHJlZmVyZW5jZXMsIGFzIGRlc2NyaWJlZCBpbiBb UkZDMzk2N10/IElmIAogICAgICAgIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMg dG8gc3VwcG9ydCB0aGUgQXJlYSAKICAgICAgICBEaXJlY3RvciBpbiB0aGUgTGFzdCBDYWxsIHBy b2NlZHVyZSBmb3IgdGhlbSBbUkZDMzk2N10uIAoKQWxsIHJlZmVyZW5jZXMgYXJlIHByb3Blcmx5 IHNlcGFyYXRlZCBhbmQgbGFiZWxsZWQuICBUaGlzIGRvY3VtZW50LCBieSBpdHMgbmF0dXJlLCBo YXMgYSBudW1iZXIgb2YgcmVmZXJlbmNlcyB0byBkb2N1bWVudHMgZnJvbSBvdGhlciBib2RpZXMg LS0gSVNPLCB0aGUgVW5pY29kZSBDb25zb3J0aXVtLCBXM0MsIGFuZCBBTlNJLiAgVHdvIG9mIHRo b3NlIHJlZmVyZW5jZXMgYXJlIG5vcm1hdGl2ZS4gIFRoZXkgd2VyZSBub3JtYXRpdmUgaW4gdGhl IG9yaWdpbmFsIGRvY3VtZW50IGFzIHdlbGwsIGFuZCBhcmUgdXBkYXRlZCBoZXJlOgoKICAgW0lT T0lFQzEwNjQ2XQogICAgICAgICAgICAgIElTTy9JRUMsICJJU08vSUVDIDEwNjQ2LTE6MjAwMy4g SW50ZXJuYXRpb25hbCBTdGFuZGFyZCAtLQogICAgICAgICAgICAgIEluZm9ybWF0aW9uIHRlY2hu b2xvZ3kgLSBVbml2ZXJzYWwgTXVsdGlwbGUtT2N0ZXQgQ29kZWQKICAgICAgICAgICAgICBDaGFy YWN0ZXIgU2V0IChVQ1MpIiwgMjAwMy4KCiAgIFtVTklDT0RFXSAgVGhlIFVuaWNvZGUgQ29uc29y dGl1bSwgIlRoZSBVbmljb2RlIFN0YW5kYXJkLCBWZXJzaW9uCiAgICAgICAgICAgICAgNi4wIiwg TW91bnRhaW4gVmlldywgQ0E6IFRoZSBVbmljb2RlIENvbnNvcnRpdW0sCiAgICAgICAgICAgICAg MjAxMS4gSVNCTiA5NzgtMS05MzYyMTMtMDEtNikuLCAyMDExLAogICAgICAgICAgICAgIDxodHRw Oi8vd3d3LnVuaWNvZGUub3JnL3ZlcnNpb25zL1VuaWNvZGU2LjAuMC8+LgoKCiAgKDEuaSkgSGFz IHRoZSBEb2N1bWVudCBTaGVwaGVyZCB2ZXJpZmllZCB0aGF0IHRoZSBkb2N1bWVudCBJQU5BIAog ICAgICAgIGNvbnNpZGVyYXRpb24gc2VjdGlvbiBleGlzdHMgYW5kIGlzIGNvbnNpc3RlbnQgd2l0 aCB0aGUgYm9keSAKICAgICAgICBvZiB0aGUgZG9jdW1lbnQ/IElmIHRoZSBkb2N1bWVudCBzcGVj aWZpZXMgcHJvdG9jb2wgCiAgICAgICAgZXh0ZW5zaW9ucywgYXJlIHJlc2VydmF0aW9ucyByZXF1 ZXN0ZWQgaW4gYXBwcm9wcmlhdGUgSUFOQSAKICAgICAgICByZWdpc3RyaWVzPyBBcmUgdGhlIElB TkEgcmVnaXN0cmllcyBjbGVhcmx5IGlkZW50aWZpZWQ/IElmIAogICAgICAgIHRoZSBkb2N1bWVu dCBjcmVhdGVzIGEgbmV3IHJlZ2lzdHJ5LCBkb2VzIGl0IGRlZmluZSB0aGUgCiAgICAgICAgcHJv cG9zZWQgaW5pdGlhbCBjb250ZW50cyBvZiB0aGUgcmVnaXN0cnkgYW5kIGFuIGFsbG9jYXRpb24g CiAgICAgICAgcHJvY2VkdXJlIGZvciBmdXR1cmUgcmVnaXN0cmF0aW9ucz8gRG9lcyBpdCBzdWdn ZXN0IGEgCiAgICAgICAgcmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5PyBTZWUg W1JGQzUyMjZdLiBJZiB0aGUgCiAgICAgICAgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIEV4cGVydCBS ZXZpZXcgcHJvY2VzcyBoYXMgU2hlcGhlcmQgCiAgICAgICAgY29uZmVycmVkIHdpdGggdGhlIFJl c3BvbnNpYmxlIEFyZWEgRGlyZWN0b3Igc28gdGhhdCB0aGUgSUVTRyAKICAgICAgICBjYW4gYXBw b2ludCB0aGUgbmVlZGVkIEV4cGVydCBkdXJpbmcgdGhlIElFU0cgRXZhbHVhdGlvbj8gCgpUaGVy ZSBhcmUgbm8gSUFOQSBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50LCBhbmQgdGhlIElBTkEgQ29u c2lkZXJhdGlvbnMgc2VjdGlvbiBzYXlzIHRoYXQuCgogICgxLmopIEhhcyB0aGUgRG9jdW1lbnQg U2hlcGhlcmQgdmVyaWZpZWQgdGhhdCBzZWN0aW9ucyBvZiB0aGUgCiAgICAgICAgZG9jdW1lbnQg dGhhdCBhcmUgd3JpdHRlbiBpbiBhIGZvcm1hbCBsYW5ndWFnZSwgc3VjaCBhcyBYTUwgCiAgICAg ICAgY29kZSwgQk5GIHJ1bGVzLCBNSUIgZGVmaW5pdGlvbnMsIGV0Yy4sIHZhbGlkYXRlIGNvcnJl Y3RseSBpbiAKICAgICAgICBhbiBhdXRvbWF0ZWQgY2hlY2tlcj8KClRoZXJlIGlzIG5vIGZvcm1h bCBsYW5ndWFnZSBpbiB0aGlzIGRvY3VtZW50LgoKICAoMS5rKSBUaGUgSUVTRyBhcHByb3ZhbCBh bm5vdW5jZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudCAKICAgICAgICBBbm5vdW5jZW1lbnQgV3Jp dGUtVXAuIFBsZWFzZSBwcm92aWRlIHN1Y2ggYSBEb2N1bWVudCAKICAgICAgICBBbm5vdW5jZW1l bnQgV3JpdGUtVXA/IFJlY2VudCBleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlCiAgICAgICAg IkFjdGlvbiIgYW5ub3VuY2VtZW50cyBmb3IgYXBwcm92ZWQgZG9jdW1lbnRzLiBUaGUgYXBwcm92 YWwgCiAgICAgICAgYW5ub3VuY2VtZW50IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnM6 IAoKICAgICBUZWNobmljYWwgU3VtbWFyeSAKICAgICAgICBSZWxldmFudCBjb250ZW50IGNhbiBm cmVxdWVudGx5IGJlIGZvdW5kIGluIHRoZSBhYnN0cmFjdCAKICAgICAgICBhbmQvb3IgaW50cm9k dWN0aW9uIG9mIHRoZSBkb2N1bWVudC4gSWYgbm90LCB0aGlzIG1heSBiZSAKICAgICAgICBhbiBp bmRpY2F0aW9uIHRoYXQgdGhlcmUgYXJlIGRlZmljaWVuY2llcyBpbiB0aGUgYWJzdHJhY3QgCiAg ICAgICAgb3IgaW50cm9kdWN0aW9uLiAKClRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBnbG9zc2Fy eSBvZiB0ZXJtcyB1c2VkIGluIHRoZSBJRVRGIHdoZW4gZGlzY3Vzc2luZyBpbnRlcm5hdGlvbmFs aXphdGlvbi4gIFRoZSBwdXJwb3NlIGlzIHRvIGhlbHAgZnJhbWUgZGlzY3Vzc2lvbnMgb2YgaW50 ZXJuYXRpb25hbGl6YXRpb24gaW4gdGhlIHZhcmlvdXMgYXJlYXMgb2YgdGhlIElFVEYgYW5kIHRv IGhlbHAgaW50cm9kdWNlIHRoZSBtYWluIGNvbmNlcHRzIHRvIElFVEYgcGFydGljaXBhbnRzLgoK VGhpcyBkb2N1bWVudCBnaXZlcyBhbiBvdmVydmlldyBvZiBpbnRlcm5hdGlvbmFsaXphdGlvbiBh cyBpdCBhcHBsaWVzIHRvIElFVEYgc3RhbmRhcmRzIHdvcmsgYnkgbGlnaHRseSBjb3ZlcmluZyB0 aGUgbWFueSBhc3BlY3RzIG9mIGludGVybmF0aW9uYWxpemF0aW9uIGFuZCB0aGUgdm9jYWJ1bGFy eSBhc3NvY2lhdGVkIHdpdGggdGhvc2UgdG9waWNzLiBTb21lIG9mIHRoZSBvdmVydmlldyBpcyBh IHNvbWV3aGF0IHR1dHVyaWFsIGluIG5hdHVyZS4gIEl0IGlzIG5vdCBtZWFudCB0byBiZSBhIGNv bXBsZXRlIGRlc2NyaXB0aW9uIG9mIGludGVybmF0aW9uYWxpemF0aW9uLiAgVGhlIGRlZmluaXRp b25zIGluIHRoaXMgZG9jdW1lbnQgYXJlIG5vdCBub3JtYXRpdmUgZm9yIElFVEYgc3RhbmRhcmRz OyBob3dldmVyLCB0aGV5IGFyZSB1c2VmdWwgYW5kIHN0YW5kYXJkcyBtYXkgbWFrZSBpbmZvcm1h dGl2ZSByZWZlcmVuY2UgdG8gdGhpcyBkb2N1bWVudCBhZnRlciBpdCBiZWNvbWVzIGFuIFJGQy4g IFNvbWUgb2YgdGhlIGRlZmluaXRpb25zIGluIHRoaXMgZG9jdW1lbnQgY29tZSBmcm9tIG1hbnkg ZWFybGllciBJRVRGIGRvY3VtZW50cyBhbmQgYm9va3MuCgogICAgIFdvcmtpbmcgR3JvdXAgU3Vt bWFyeSAKICAgICAgICBXYXMgdGhlcmUgYW55dGhpbmcgaW4gV0cgcHJvY2VzcyB0aGF0IGlzIHdv cnRoIG5vdGluZz8gRm9yIAogICAgICAgIGV4YW1wbGUsIHdhcyB0aGVyZSBjb250cm92ZXJzeSBh Ym91dCBwYXJ0aWN1bGFyIHBvaW50cyBvciAKICAgICAgICB3ZXJlIHRoZXJlIGRlY2lzaW9ucyB3 aGVyZSB0aGUgY29uc2Vuc3VzIHdhcyBwYXJ0aWN1bGFybHkgCiAgICAgICAgcm91Z2g/IAoKTm90 IHN1cnByaXNpbmdseSBmb3IgYSBkb2N1bWVudCBzdWNoIGFzIHRoaXMsIHRoZXJlIHdlcmUgbWFu eSBzdWdnZXN0aW9ucyBvZiB0ZXJtaW5vbG9neSB0byBpbmNsdWRlLCBhbmQgb2YgYWx0ZXJuYXRp dmUgZGVmaW5pdGlvbnMgdG8gdGhlIG9uZXMgaW5jbHVkZWQuICBUaGUgZWRpdG9ycyBoYXZlIGRv bmUgYSBnb29kIGpvYiBvZiBzdHJpa2luZyBhIG5lY2Vzc2FyeSBiYWxhbmNlIGJldHdlZW4gYW4g b3Zlcmx5IGJsb2F0ZWQgZG9jdW1lbnQgYW5kIG9uZSB0aGF0IGluY2x1ZGVzIHRoZSByaWdodCBz ZXQgb2YgdGVybXMsIHdpdGggZGVmaW5pdGlvbnMgdGhhdCByZWZsZWN0IHJlYXNvbmFibGUgY29u c2Vuc3VzLCBpZiBub3QgYWx3YXlzIHVuYW5pbWl0eS4gIFRoZXJlIHdlcmUgYSBudW1iZXIgb2Yg c3VjaCBkaXNjdXNzaW9ucywgd2l0aCBub25lIGJlYXJpbmcgcGFydGljdWxhciBtZW50aW9uIGhl cmUuCgogICAgIERvY3VtZW50IFF1YWxpdHkgCiAgICAgICAgQXJlIHRoZXJlIGV4aXN0aW5nIGlt cGxlbWVudGF0aW9ucyBvZiB0aGUgcHJvdG9jb2w/IEhhdmUgYSAKICAgICAgICBzaWduaWZpY2Fu dCBudW1iZXIgb2YgdmVuZG9ycyBpbmRpY2F0ZWQgdGhlaXIgcGxhbiB0byAKICAgICAgICBpbXBs ZW1lbnQgdGhlIHNwZWNpZmljYXRpb24/IEFyZSB0aGVyZSBhbnkgcmV2aWV3ZXJzIHRoYXQgCiAg ICAgICAgbWVyaXQgc3BlY2lhbCBtZW50aW9uIGFzIGhhdmluZyBkb25lIGEgdGhvcm91Z2ggcmV2 aWV3LCAKICAgICAgICBlLmcuLCBvbmUgdGhhdCByZXN1bHRlZCBpbiBpbXBvcnRhbnQgY2hhbmdl cyBvciBhIAogICAgICAgIGNvbmNsdXNpb24gdGhhdCB0aGUgZG9jdW1lbnQgaGFkIG5vIHN1YnN0 YW50aXZlIGlzc3Vlcz8gSWYgCiAgICAgICAgdGhlcmUgd2FzIGEgTUlCIERvY3RvciwgTWVkaWEg VHlwZSBvciBvdGhlciBleHBlcnQgcmV2aWV3LCAKICAgICAgICB3aGF0IHdhcyBpdHMgY291cnNl IChicmllZmx5KT8gSW4gdGhlIGNhc2Ugb2YgYSBNZWRpYSBUeXBlIAogICAgICAgIHJldmlldywg b24gd2hhdCBkYXRlIHdhcyB0aGUgcmVxdWVzdCBwb3N0ZWQ/IAogICAgICAgIApUaGlzIGRvY3Vt ZW50IHJlcGxhY2VzIFJGQyAzNTM2LCBjbGVhbmluZyB1cCBhbmQgdXBkYXRpbmcgbWFueSBvZiB0 aGUgZGVmaW5pdGlvbnMgdGhlcmVpbi4gIFJGQyAzNTM2IGhhcyBiZWVuIGluIHVzZSBmb3IgZWln aHQgeWVhcnMsIGFuZCB0aGlzIGRvY3VtZW50IHJlZmxlY3RzIHRoYXQgbWF0dXJpdHkgYW5kIHdo YXQgd2UndmUgbGVhcm5lZCBhYm91dCB0aGUgZ2FwcyBpbiB0aGUgdGVybWlub2xvZ3kgYW5kIGRl ZmluaXRpb25zIG92ZXIgdGhhdCB0aW1lLiAgU2VjdGlvbiA3IGlzIGEgc2lnbmlmaWNhbnQgbmV3 IHNlY3Rpb24gdGhhdCB0YWxrcyBhYm91dCBJRE5BIHdvcmsgZG9uZSBzaW5jZSBSRkMgMzUzNi4K --20cf300fab09a374b704a54f6aab-- From jdfalk-lists@cybernothing.org Thu Jun 9 18:49:16 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AAD11E814C for ; Thu, 9 Jun 2011 18:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upFrEvotJqzy for ; Thu, 9 Jun 2011 18:49:15 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8F11E8145 for ; Thu, 9 Jun 2011 18:49:15 -0700 (PDT) Received: from [10.102.0.106] (64.1.211.248.ptr.us.xo.net [64.1.211.248]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5A1nCYL028399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 9 Jun 2011 18:49:14 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p5A1nCYL028399 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1307670554; bh=BNnA87BqVaqWh0WSswhdh56KWxwM1i/NTkmOsJWsw sM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=jNGWuT2MnhYH VL1twGcrOhmOvQhlLu8fQwW/u9unBb6C/KSvB9t5KdeAkjEvkTH2V2EmVp/xGdSVHnx 8V5KOf8M/104BTsK6pKx7LwSyvh3dbqDEKlXFg5FKfzUPnLK/MnbAaWCPG7m4nfYLdS FvvKnzPckT3RDEI8TLnDX7XWU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Thu, 9 Jun 2011 18:49:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <321CAE57-EDC0-4DEE-801C-808FCBA36EF9@mnot.net> <4DE85364.6030900@stpeter.im> To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1084) Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 01:49:16 -0000 On Jun 2, 2011, at 8:24 PM, Mark Nottingham wrote: > Or just change the title to something more generic like "Appropriate = use of X-". +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Jun 10 06:15:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4A11F0C42 for ; Fri, 10 Jun 2011 06:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnCWtnQCF65f for ; Fri, 10 Jun 2011 06:15:37 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1481F0C40 for ; Fri, 10 Jun 2011 06:15:37 -0700 (PDT) Received: by pxi20 with SMTP id 20so1942838pxi.27 for ; Fri, 10 Jun 2011 06:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xncIaygohQ4kNSlK79jg4TpMl8MxdAreEdQ0c4JbUsA=; b=WCnsqC6oNxpVLr+Ra64YAy6kCviFQjAsCfjlhoAOS+g9e/z2+u4/1c7mzWdtw4u1Ap upaCntPzQxdh3E4aL28e42T5KFzye2i8xcLe6yUQiibcOrIjJuUbnDNWjAqemD/gFgLf TyxtEK+3eog19ENZJdXDMreAoEqATpah2uljo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=vVi0GvEgyVt9syLvOWMV8cizK9L+SlbiMynVMmQzMEF4cumwzb390EQk7eHmFRMYV7 pJTynT/gzqNsFbHE18fYVycTUlSgLG3nuGo6VG4pOoDsLCRU4CIU6ZYeA3urSmfb8dRe 68t3ursgT+0BCGs3i+QeAa0fmjl9rUn3FscnM= Received: by 10.142.212.10 with SMTP id k10mr380211wfg.4.1307711737154; Fri, 10 Jun 2011 06:15:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.34.19 with HTTP; Fri, 10 Jun 2011 06:15:17 -0700 (PDT) In-Reply-To: <4DE85364.6030900@stpeter.im> References: <321CAE57-EDC0-4DEE-801C-808FCBA36EF9@mnot.net> <4DE85364.6030900@stpeter.im> From: Frank Ellermann Date: Fri, 10 Jun 2011 15:15:17 +0200 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 13:15:38 -0000 On 3 June 2011 05:22, Peter Saint-Andre wrote: > I haven't yet addressed some of the feedback > I received last year. Also, I think "harmful" > might be a bit strong -- "considered-useless" > perhaps? No, "harmful" is clearer. Some days ago I wasted hours trying to explain the fine points of MIME types image/vnd.microsoft.icon vs. image/x-icon in the Wikipedia favicon article and on my blog. The worst about it is that I'm far from sure that I got it right, because I can't test IE7 oddities on my boxes (and wouldn't be eager to test IE7 even if I could). If your not yet incorporated feedback covers MIME x-types please include it. Cheers, Frank From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Jun 10 06:33:03 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E401F0C60 for ; Fri, 10 Jun 2011 06:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyGXJBFVvO3g for ; Fri, 10 Jun 2011 06:33:02 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8F4711E8075 for ; Fri, 10 Jun 2011 06:33:02 -0700 (PDT) Received: by pzk5 with SMTP id 5so1353894pzk.31 for ; Fri, 10 Jun 2011 06:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZDFiYngdioWRyzfCqp4OQgoMd5bM7yo6uBEznKo+RvI=; b=ixAF6CVQWF2Lly+XBvMnlATTo80sm2LvAHyD3yh4yEX/9oD/7k6rmA+6pHHNKVRw6Z 92iPSTNcnIi/g4io9wIBjf2soqELitN0/kw8ENzdg/McMK2m0aoUfSwRr4Cm+NEa47SN 4CsuYy9ZPLQp+qWD0r0ezsOXyxQ1HaIxzoS+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=cPEnD0ZrVrOu+XaHEBjti2AHEy7I2plCr99Yz5BXFKe7E1T9X4O89s3J9gNwJ6MZmY Zkrxrj2Q1cZTLSN+cJMQZfgAiwLWNUGwm4dBCtvb/pJBbWZH3MOAFLZzMYA4iK5aR9yJ ZubVWgIdBKqu9B/DiUtHapOZBHQJpNgdxubVQ= Received: by 10.142.242.12 with SMTP id p12mr350984wfh.346.1307712782194; Fri, 10 Jun 2011 06:33:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.34.19 with HTTP; Fri, 10 Jun 2011 06:32:42 -0700 (PDT) In-Reply-To: References: From: Frank Ellermann Date: Fri, 10 Jun 2011 15:32:42 +0200 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] Request to publish draft-ietf-appsawg-rfc3536bis-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 13:33:03 -0000 On 10 June 2011 01:00, Barry Leiba wrote: > Attached is the PROTO writeup. +1. I'm still not convinced that a BCP with an international audience should contain a reading list for a mainly English audience, but hopefully we'll arrive at better solutions in future RFCs. I'd love to have "official RFC fan pages", where I could add comments, share, "like", "+1", "pingback", "trackback", etc. certain RFCs. -Frank From john-ietf@jck.com Fri Jun 10 07:05:53 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485B511E80CB for ; Fri, 10 Jun 2011 07:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu1s6l-Rz6pW for ; Fri, 10 Jun 2011 07:05:52 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 6FACE11E81B6 for ; Fri, 10 Jun 2011 07:05:52 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QV2LO-000I56-Bp; Fri, 10 Jun 2011 10:05:50 -0400 Date: Fri, 10 Jun 2011 10:05:49 -0400 From: John C Klensin To: Frank Ellermann Message-ID: <5D92A844AC739C22A4525EAA@PST.JCK.COM> In-Reply-To: References: 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: Apps Discuss Subject: [apps-discuss] Non-English reading lists (was: Re: Request to publish draft-ietf-appsawg-rfc3536bis-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 14:05:53 -0000 --On Friday, June 10, 2011 15:32 +0200 Frank Ellermann wrote: > +1. I'm still not convinced that a BCP with an international > audience should contain a reading list for a mainly English > audience, but hopefully we'll arrive at better solutions in > future RFCs. Frank, A big problem, especially for a BCP or standards-track document, is the question of evaluation of the references. Using myself as a handy example, I can read a few languages other than English, but I absolutely do not know the internationalization literature in those languages to be able to know what to recommend (or even to evaluate a recommendation). I know that there are some materials in English that we did not list, not because they were overlooked, but because they are pretty bad (at least in my opinion or Paul's, but the WG Last Call didn't turn up complaints about their omission). But let me make a suggestion. If you want to gather up some people who could do (and that includes cross-checking and evaluating) a reading list in one or more languages (I'd recommend doing it in annotated bibliography form) or even a multilingual thesaurus of i18n terminology, I'd assume that the Independent Submission Editor would be included to publish such a thing as relevant and useful to the community. I can't speak for the ISE, of course, but you could check first if you wanted to go ahead with such an effort. There would be some issues about publication in other than English and publication in page-layout (PS and/or PDF) form to capture the relevant characters and not have to resort entirely to transliteration. However, we've had PS-only RFCs in the past and the rules permit them as special exceptions when justified. And, while I haven't asked him, I note that the Acting RSE is not a native speaker of English and might be sympathetic to the goal. john From presnick@qualcomm.com Fri Jun 10 07:41:09 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5AF11E81C6 for ; Fri, 10 Jun 2011 07:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.432 X-Spam-Level: X-Spam-Status: No, score=-106.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXNCXXqighsu for ; Fri, 10 Jun 2011 07:41:08 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id C663711E80B7 for ; Fri, 10 Jun 2011 07:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1307716868; x=1339252868; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: content-type:content-transfer-encoding:mime-version; z=From:=20"Resnick,=20Pete"=20|To: =20Barry=20Leiba=20,=20"appsawg- ads@tools.ietf.org"=0D=0A=09 |CC:=20Apps=20Discuss=20|Subject: =20Re:=20[apps-discuss]=20Request=20to=20publish=0D=0A=20 draft-ietf-appsawg-rfc3536bis-02|Thread-Topic:=20[apps-di scuss]=20Request=20to=20publish=0D=0A=20draft-ietf-appsaw g-rfc3536bis-02|Thread-Index:=20AQHMJvkdb8F0SzWDcEyw+zdMV zDQ55S2qutp|Date:=20Fri,=2010=20Jun=202011=2014:41:07=20+ 0000|Message-ID:=20|References:=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|Content-Type:=20t ext/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=XpJna+zXw8vC/VqCFi+kC6m6+w2cqLJyEvOjXWsiahQ=; b=fCSGa7rT94ekuXmieKb9r0ap6Q2UgVtfLPvhrwalsmmlCWbSNQiMMKTG YMmXcz/+gDwfyDZ6qTnJjjoQgsDACFfSGZMvp82HsTogpF4N34XlVoZHF kAxcL2AcpLAIdVx8o/0gBdaDf7vaj8ixzok8KHoV+KgIPGWKDOpIO20P1 c=; X-IronPort-AV: E=McAfee;i="5400,1158,6372"; a="96719761" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 10 Jun 2011 07:41:07 -0700 X-IronPort-AV: E=Sophos;i="4.65,347,1304319600"; d="scan'208";a="112631064" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 10 Jun 2011 07:41:07 -0700 Received: from NASANEXD01B.na.qualcomm.com ([fe80::35f4:3d53:dd65:8b60]) by nasanexhc09.na.qualcomm.com ([::1]) with mapi id 14.01.0270.001; Fri, 10 Jun 2011 07:41:07 -0700 From: "Resnick, Pete" To: Barry Leiba , "appsawg-ads@tools.ietf.org" Thread-Topic: [apps-discuss] Request to publish draft-ietf-appsawg-rfc3536bis-02 Thread-Index: AQHMJvkdb8F0SzWDcEyw+zdMVzDQ55S2qutp Date: Fri, 10 Jun 2011 14:41:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] Request to publish draft-ietf-appsawg-rfc3536bis-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 14:41:09 -0000 Thanks for a nice writeup. I'll get this last called ASAP. pr Barry Leiba wrote: Area Directors: The Applications Area Working Group requests the publication of draft-ietf-appsawg-rfc3536bis-02 as a BCP, obsoleting RFC 3536, which is Informational. Attached is the PROTO writeup. Barry, appsawg chair, and document shepherd From evnikita2@gmail.com Fri Jun 10 08:33:33 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6711E81E6 for ; Fri, 10 Jun 2011 08:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoN0uA3yxkj4 for ; Fri, 10 Jun 2011 08:33:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1711E8090 for ; Fri, 10 Jun 2011 08:33:32 -0700 (PDT) Received: by fxm15 with SMTP id 15so1932941fxm.31 for ; Fri, 10 Jun 2011 08:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=JkwN1HXkDbgNbdWuxzT7+VR23JdihNIW85SgCiINyRo=; b=Bnpo7HernEq3zJ7IDndLyLgsh+DoZSYVCOyTF0KDCvPIhUomde+r+ZSqI3DxO+HxDh K1L1eMWJfOF8CBq/RAmqxYvvCANbQidLM2PFq828VG4iWGwTMILzEAh7QTI/VPQJESii uOrOOdt/hmjsp/SFqZch7xVC4ICmlYRkCEPcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=Rs2XI2vbw0U2xW9wtsjWEtcZGV2lcJnChB3KIOTK3deuIHsPsKBh7ernqiWqqdCbWq M/5Pu9bhqDERKVmmbu4AYxYRamceETZBCsN/vS+xQ+38e7t6aRGe43DfJsWpoNriYSwd Sg26ro+saOhoFFsgNpuzemAh690agge4GusDo= Received: by 10.223.5.28 with SMTP id 28mr2157036fat.103.1307720010085; Fri, 10 Jun 2011 08:33:30 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id e16sm1107153fak.41.2011.06.10.08.33.28 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 08:33:29 -0700 (PDT) Message-ID: <4DF23976.4080301@gmail.com> Date: Fri, 10 Jun 2011 18:34:14 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Apps-discuss list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Documenting UTF-1 as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 15:33:33 -0000 Hello, There are a number of RFCs defining transformation formats of ISO 10646/Unicode - various UTFs. I mean RFC 3629 (UTF-8), RFC 2152 (UTF-7), RFC 2781 (UTF-16) and others. However, I've noticed UTF-1 isn't properly documented (or, at least, there is no formal record of it). However, since UTF-1 has never been widely used, I suppose it could be formally documented in Historic RFC, taking http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis. Any thoughts on this? Mykyta Yevstifeyev From julian.reschke@gmx.de Fri Jun 10 08:44:24 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A640F11E81F8 for ; Fri, 10 Jun 2011 08:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.907 X-Spam-Level: X-Spam-Status: No, score=-103.907 tagged_above=-999 required=5 tests=[AWL=-1.308, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkU-O-oxYl-z for ; Fri, 10 Jun 2011 08:44:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 67A7211E8090 for ; Fri, 10 Jun 2011 08:44:23 -0700 (PDT) Received: (qmail invoked by alias); 10 Jun 2011 15:44:21 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp062) with SMTP; 10 Jun 2011 17:44:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX185+ssheOE5XidUwM39heQJjKijhN5e+EPyBOzZjF gCvbthRzf2tbyk Message-ID: <4DF23BD4.1080802@gmx.de> Date: Fri, 10 Jun 2011 17:44:20 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4DF23976.4080301@gmail.com> In-Reply-To: <4DF23976.4080301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps-discuss list Subject: Re: [apps-discuss] Documenting UTF-1 as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 15:44:24 -0000 On 2011-06-10 17:34, Mykyta Yevstifeyev wrote: > Hello, > > There are a number of RFCs defining transformation formats of ISO > 10646/Unicode - various UTFs. I mean RFC 3629 (UTF-8), RFC 2152 (UTF-7), > RFC 2781 (UTF-16) and others. However, I've noticed UTF-1 isn't properly > documented (or, at least, there is no formal record of it). However, > since UTF-1 has never been widely used, I suppose it could be formally > documented in Historic RFC, taking > http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis. Any thoughts on > this? > ... Yes. Why do we care? From evnikita2@gmail.com Fri Jun 10 08:47:40 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1DE11E8109 for ; Fri, 10 Jun 2011 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xidgz9JHXhij for ; Fri, 10 Jun 2011 08:47:40 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9FD311E8090 for ; Fri, 10 Jun 2011 08:47:39 -0700 (PDT) Received: by fxm15 with SMTP id 15so1941102fxm.31 for ; Fri, 10 Jun 2011 08:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aegEFxJOYV0wLqLS2tylruuiCB9YzMyXqH9sv5uwJik=; b=oYyCv4CY0llZkcz5/x8nQp7HuE75sWe0/FiwugANXTtM5IGXqmU186xlHynnVheO25 SNvSzxUffHtBYIgY+GjyXXt0Jdajsbl//ftT6ryitEeRPFGvSbQx1+yZDJAjhd9o2g5T ICeh2Ffct1uSy7gMNoi+IXOoOx2MHYqzYkwqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=JcamBF5y3rvWaLU7XjKXwSwtaRsotVVdj2j8KvEWf0BZsdyXqE0qqDtr8whqkEWWfu j1Mglm3dQBjxf2dsnsjopHUfrsjrL5jLjwiO23uMjnfqnbwokc6Dg6raorKm0DHTWzh2 GdjHpvGAdzvkaPGS4MimG2G4I1WRU6cvqSDS0= Received: by 10.223.51.4 with SMTP id b4mr367124fag.93.1307720858085; Fri, 10 Jun 2011 08:47:38 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id m26sm1113326fab.10.2011.06.10.08.47.36 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 08:47:37 -0700 (PDT) Message-ID: <4DF23CC6.7040607@gmail.com> Date: Fri, 10 Jun 2011 18:48:22 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Julian Reschke References: <4DF23976.4080301@gmail.com> <4DF23BD4.1080802@gmx.de> In-Reply-To: <4DF23BD4.1080802@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps-discuss list Subject: Re: [apps-discuss] Documenting UTF-1 as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 15:47:40 -0000 10.06.2011 18:44, Julian Reschke wrote: > On 2011-06-10 17:34, Mykyta Yevstifeyev wrote: >> Hello, >> >> There are a number of RFCs defining transformation formats of ISO >> 10646/Unicode - various UTFs. I mean RFC 3629 (UTF-8), RFC 2152 (UTF-7), >> RFC 2781 (UTF-16) and others. However, I've noticed UTF-1 isn't properly >> documented (or, at least, there is no formal record of it). However, >> since UTF-1 has never been widely used, I suppose it could be formally >> documented in Historic RFC, taking >> http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis. Any thoughts on >> this? >> ... > > Yes. Why do we care? > We care to have a formal record of UTF-1, as I explained above. From julian.reschke@gmx.de Fri Jun 10 08:56:32 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19EB11E8129 for ; Fri, 10 Jun 2011 08:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.807 X-Spam-Level: X-Spam-Status: No, score=-103.807 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI0UGmSSnXm1 for ; Fri, 10 Jun 2011 08:56:32 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E4CF811E811A for ; Fri, 10 Jun 2011 08:56:31 -0700 (PDT) Received: (qmail invoked by alias); 10 Jun 2011 15:56:30 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp014) with SMTP; 10 Jun 2011 17:56:30 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19IIBB95UBIROCU2tEEazYXcgbx3IH6nrOwMlnAGj uhKIN3JyOiBsct Message-ID: <4DF23EAD.4070804@gmx.de> Date: Fri, 10 Jun 2011 17:56:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4DF23976.4080301@gmail.com> <4DF23BD4.1080802@gmx.de> <4DF23CC6.7040607@gmail.com> In-Reply-To: <4DF23CC6.7040607@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps-discuss list Subject: Re: [apps-discuss] Documenting UTF-1 as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 15:56:33 -0000 On 2011-06-10 17:48, Mykyta Yevstifeyev wrote: > 10.06.2011 18:44, Julian Reschke wrote: >> On 2011-06-10 17:34, Mykyta Yevstifeyev wrote: >>> Hello, >>> >>> There are a number of RFCs defining transformation formats of ISO >>> 10646/Unicode - various UTFs. I mean RFC 3629 (UTF-8), RFC 2152 (UTF-7), >>> RFC 2781 (UTF-16) and others. However, I've noticed UTF-1 isn't properly >>> documented (or, at least, there is no formal record of it). However, >>> since UTF-1 has never been widely used, I suppose it could be formally >>> documented in Historic RFC, taking >>> http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis. Any thoughts on >>> this? >>> ... >> >> Yes. Why do we care? >> > We care to have a formal record of UTF-1, as I explained above. Why do we care if we do not use it? From nico@cryptonector.com Fri Jun 10 10:36:43 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E150C11E80B1; Fri, 10 Jun 2011 10:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 208vBsYuTKkI; Fri, 10 Jun 2011 10:36:43 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7011E81A6; Fri, 10 Jun 2011 10:36:43 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 544CF21DE82; Fri, 10 Jun 2011 10:36:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=GYpPq5RJTqWHu2GhBAPXD8lw0ad1N/eR4W4C1BTSocB5 Ysng1dmlX0nEhkZpuqwgkjZo4Tuq13d2eHcmPoKMsZAIrNjD0MkkbNtnzNeJgFbc 1A1qmyCIkjUnq80Ozl/gsJP65DxGdth0HfEGDBbVrPolRUtulRELuq8rqoSK0cc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ogMqrLJYBNMpf2sdZYydrvyFAcs=; b=M+vUWCC5Wui orFhCufVJ+e0WjyPSIDns2IdhjdKlCID9mgeyHHSCkCzCcQeA5WrTZxIA/XMliOp L04Z01RcRqr5B27E3mTJaSWdFbgwYhk6YFlXt4wx9wO+/QeASMkjMRod/edyqpXM 4RPjqIjHaGkKIhnLJ6RindfVfA/t33vo= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id D25C121DE8E; Fri, 10 Jun 2011 10:36:30 -0700 (PDT) Received: by pzk5 with SMTP id 5so1476613pzk.31 for ; Fri, 10 Jun 2011 10:36:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.0.7 with SMTP id 7mr1214506pba.188.1307727390261; Fri, 10 Jun 2011 10:36:30 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Fri, 10 Jun 2011 10:36:30 -0700 (PDT) In-Reply-To: <02c401cc2662$9a21d220$ce657660$@packetizer.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <02c401cc2662$9a21d220$ce657660$@packetizer.com> Date: Fri, 10 Jun 2011 12:36:30 -0500 Message-ID: From: Nico Williams To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ben Adida , Adam Barth , OAuth WG , apps-discuss@ietf.org Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 17:36:44 -0000 [Dropped a few lists.] On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones wrot= e: > What issues, specifically.=C2=A0 (Messages are all over the place and I d= on=E2=80=99t > know exactly what issues you=E2=80=99re raising.=C2=A0 Is it with the app= roach we=E2=80=99re > proposing or something else?) The fundamental issue is that protecting the cookie alone is not enough. On open wifi networks it's a fair assumption that the difficulty of active attacks is about the same as the difficulty of passive attacks. Therefore you need to provide integrity protection for most of the request and most of the response, including the bodies. Nico -- From lear@cisco.com Fri Jun 10 10:45:45 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBE811E81D7 for ; Fri, 10 Jun 2011 10:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Mxfm-VVKZuk for ; Fri, 10 Jun 2011 10:45:44 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 88BB711E81C6 for ; Fri, 10 Jun 2011 10:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=3068; q=dns/txt; s=iport; t=1307727944; x=1308937544; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=95QYT0fZ6RFBeTT7u8TWPphm2Yx6wxadOEp+d6i3MV0=; b=iOZVSn02BkpUhb5hTyLUY9gHvTS4SIlmI+1mp0XxHHeN0Hp2BeKQM0l0 h64eFbHsrzOngdCVIF4LZDUBb3vjbe4SC9lv3hgLSQgnwSwe7Z270bsbc tkbsV64H2fUu4ixeTKwXrXn4m+vcMjXmeEpgQxQYNTU71WvfqZmgdGv+5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHZX8k2Q/khL/2dsb2JhbABShEmiA3eIcp4ojSeQY4UZgQoEkSuPWQ X-IronPort-AV: E=Sophos;i="4.65,348,1304294400"; d="scan'208,217";a="34727807" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 10 Jun 2011 17:45:43 +0000 Received: from dhcp-10-55-91-129.cisco.com (dhcp-10-55-91-129.cisco.com [10.55.91.129]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5AHjhTm015609; Fri, 10 Jun 2011 17:45:43 GMT Message-ID: <4DF25847.9000007@cisco.com> Date: Fri, 10 Jun 2011 19:45:43 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4DF23976.4080301@gmail.com> In-Reply-To: <4DF23976.4080301@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------050609090607000201060705" Cc: Apps-discuss list Subject: Re: [apps-discuss] Documenting UTF-1 as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 17:45:45 -0000 This is a multi-part message in MIME format. --------------050609090607000201060705 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > > There are a number of RFCs defining transformation formats of ISO > 10646/Unicode - various UTFs. I mean RFC 3629 (UTF-8), RFC 2152 > (UTF-7), RFC 2781 (UTF-16) and others. However, I've noticed UTF-1 > isn't properly documented (or, at least, there is no formal record of > it). However, since UTF-1 has never been widely used, I suppose it > could be formally documented in Historic RFC, taking > http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis. Any thoughts > on this? Yes. The time of the IESG and the IETF and the RFC Editor is precious. In order for the work to be done it should be important to do for the sake of guiding actual implementations. As such, let me restate Julian's question: * Which implementors or what user base are in need of knowing either the proper application of UTF-1 in our various specification or that it should not be used (e.g., marked Historic)? If you cannot enumerate at least a small group where this has actual impact, let me suggest that we allow for this gap in our compendium of RFCs. Eliot --------------050609090607000201060705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

There are a number of RFCs defining transformation formats of ISO 10646/Unicode - various UTFs.  I mean RFC 3629 (UTF-8), RFC 2152 (UTF-7), RFC 2781 (UTF-16) and others.  However, I've noticed UTF-1 isn't properly documented (or, at least, there is no formal record of it).  However, since UTF-1 has never been widely used, I suppose it could be formally documented in Historic RFC, taking http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis.  Any thoughts on this?

Yes.  The time of the IESG and the IETF  and the RFC Editor is precious.  In order for the work to be done it should be important to do for the sake of guiding actual implementations.  As such, let me restate Julian's question:
  • Which implementors or what user base are in need of knowing either the proper application of UTF-1 in our various specification or that it should not be used (e.g., marked Historic)?
If you cannot enumerate at least a small group where this has actual impact, let me suggest that we allow for this gap in our compendium of RFCs.

Eliot
--------------050609090607000201060705-- From john-ietf@jck.com Fri Jun 10 11:25:15 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7048411E807C for ; Fri, 10 Jun 2011 11:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB1-SVWKzUuA for ; Fri, 10 Jun 2011 11:25:14 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 6411511E8075 for ; Fri, 10 Jun 2011 11:25:14 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QV6OO-000Ni4-5n; Fri, 10 Jun 2011 14:25:12 -0400 Date: Fri, 10 Jun 2011 14:25:11 -0400 From: John C Klensin To: Mykyta Yevstifeyev Message-ID: <61A6FA2030E93A75C586A699@PST.JCK.COM> In-Reply-To: <4DF23BD4.1080802@gmx.de> References: <4DF23976.4080301@gmail.com> <4DF23BD4.1080802@gmx.de> 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: Apps-discuss list Subject: Re: [apps-discuss] Documenting UTF-1 as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 18:25:15 -0000 --On Friday, June 10, 2011 17:44 +0200 Julian Reschke wrote: > On 2011-06-10 17:34, Mykyta Yevstifeyev wrote: >> Hello, >> >> There are a number of RFCs defining transformation formats of >> ISO 10646/Unicode - various UTFs. I mean RFC 3629 (UTF-8), >> RFC 2152 (UTF-7), RFC 2781 (UTF-16) and others. However, I've >> noticed UTF-1 isn't properly documented (or, at least, there >> is no formal record of it). However, since UTF-1 has never >> been widely used, I suppose it could be formally documented >> in Historic RFC, taking >> http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis. Any >> thoughts on this? >> ... > > Yes. Why do we care? Mykyta, Let me say that a little more strongly. As far as I know, it isn't used on the Internet and definitely is not used in any IETF protocol. The document you cite was a proposal to ISO/IEC JTC1/SC2, not to the IETF. It went nowhere in SC2 and, in particular, was not incorporated into ISO/IEC 10646 or any closely-related document. To the best of my knowledge, it was never proposed for use in the IETF, not that it would make much difference if it had been. If we were to expand our goals to include documenting (as Historic) every bad idea proposed to some other SDO, or even every bad idea proposed to the IETF, we would be very busy indeed -- the population of bad ideas, or even possibly-good ideas that did not achieve any level of standardization-- is a rather extensive and target-rich environment. Seriously, even proposing this has the appearance of either bad judgment or a desire to waste the community's time. I've tried to be supportive of your efforts to tie up assorted loose ends in the RFC Series and gaps in protocol definitions where that work is actually useful, but this one is really over the line. Perhaps your next proposal should be a URI type for SUPDUP. While RFC 734 has been designated as HISTORIC, RFCs 736, 746, 747, and 749 have not been and there is no published analysis of why SUPDUP didn't take off and why 734 was identified as HISTORIC. I think doing such a URI, or trying to develop that documentation, would be a waste of time too, but at least SUPDUP was believed by many of us to be a good idea, was defined in the IETF (or actually in its predecessor), and was deployed and used (although not, IMO, enough). john From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Jun 10 11:45:17 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859CD11E8151 for ; Fri, 10 Jun 2011 11:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g49aAPvfhZzy for ; Fri, 10 Jun 2011 11:45:17 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id B21DD11E8126 for ; Fri, 10 Jun 2011 11:45:04 -0700 (PDT) Received: by pvh18 with SMTP id 18so1498746pvh.31 for ; Fri, 10 Jun 2011 11:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=auGMpxYivJaHezT7WGX3E89iC5o5rmshgT9iSR8g9ms=; b=mDWjJshAbk62Cs0pXIH/IKMnJ9O+y8RTzWoK6W/fertrvtZqwgZrmJKj0FeB6qOD4A LbGBUvGv5KJOQaY2GaF1kKWH5L4LIO/Gq8BKXWRnMfZexOgLUlUjG+azlfvkNT6TwX5K wuUIVuJwGGODOYYj9TH/7nLE5voSUR1Gz+t1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=WUk/OFlyZMsKaY5U9Q2i6ynVt/XqbM2FrqCaqSb5JyQjCxnTmo4niUd5KgiAJ+woFl 06JvL3KXvTJJxOAKzxo9+pwDx48nXw/TBOJ6GAki+e6odbkyKPDAwbhmRDnK5VH3it5X ZKWROpco9RD2Zea4VBUJBbS+hXLwhI0nmQuc8= Received: by 10.143.27.11 with SMTP id e11mr435602wfj.289.1307731504262; Fri, 10 Jun 2011 11:45:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.34.19 with HTTP; Fri, 10 Jun 2011 11:44:44 -0700 (PDT) In-Reply-To: <4DF23976.4080301@gmail.com> References: <4DF23976.4080301@gmail.com> From: Frank Ellermann Date: Fri, 10 Jun 2011 20:44:44 +0200 Message-ID: To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps-discuss list Subject: Re: [apps-discuss] Documenting UTF-1 as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 18:45:17 -0000 On 10 June 2011 17:34, Mykyta Yevstifeyev wrote: > I suppose it could be formally documented > in Historic RFC In theory. But the IETF (etc.) never used UTF-1 for anything. ISO deprecated UTF-1 years ago, and of course they still formally document it: http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf Admittedly that page is hard to find, but OTOH the en-wikipedia UTF-1 article lists it as its one and only external reference (at the moment). >=A0Any thoughts on this? Unless somebody did it already: It would be a very good thing to deprecate UTF-7 "officially" in an RFC, because UTF-7 is at least in theory an IETF invention. There was an AD willing to sponsor this effort in 2007, maybe the new ADs also like the idea. The author of the UTF-7 RFC has no objections (and should certainly get credits for his stunt to register a "moving target" as IANA charset before UTF-8 existed, and when Unicode was still only registered with a version number). As far as HTML5 and WhatWG care about standards they should also welcome if UTF-7 is "formally" dead. If you volunteer for this effort you can also talk about UTF-1 "just for the records" if you wish. -Frank From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Jun 10 12:16:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B69311E809D for ; Fri, 10 Jun 2011 12:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqvuONqn4ioI for ; Fri, 10 Jun 2011 12:16:37 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBA911E80D4 for ; Fri, 10 Jun 2011 12:16:37 -0700 (PDT) Received: by pxi20 with SMTP id 20so2192569pxi.27 for ; Fri, 10 Jun 2011 12:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0WEp2xMP+WnLkclO0sV8PIPCTQUBjz3pJlUuqxFCosk=; b=S+y/g/ozjCMW6yDO5EVQ+kHOk484VPCxKJYy5rp1lfeNwimPVLhEcW48eCU+yCZdSQ qXv6eEYznn8GvXMF7jffevBFxwtuKjWMXnGc0hC3b5nyvGo7jmtrgjqEXDsj8XwrcIe6 q5tQWN2oyuxpx/UFIgF0ZmXhh7/DbzTfcr4P4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=xZfxtI8Ba0ziPOshk9xIROYT6HMCovXc7w5onaDsYC/Fn+CST4KEaR9iIipXS32xt2 CWrF9BtNHjhI/LWKNKPFKzHtG+9YDaHoyA+X6Edem6I9kaS1opOHLDeNEyokmULl1bAO 4t7o9m9Ja6eZQpBhA8LeH7FqPcgXkkrqftMNA= Received: by 10.142.208.20 with SMTP id f20mr432616wfg.403.1307733377122; Fri, 10 Jun 2011 12:16:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.34.19 with HTTP; Fri, 10 Jun 2011 12:15:57 -0700 (PDT) In-Reply-To: <5D92A844AC739C22A4525EAA@PST.JCK.COM> References: <5D92A844AC739C22A4525EAA@PST.JCK.COM> From: Frank Ellermann Date: Fri, 10 Jun 2011 21:15:57 +0200 Message-ID: To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] Non-English reading lists (was: Re: Request to publish draft-ietf-appsawg-rfc3536bis-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 19:16:38 -0000 On 10 June 2011 16:05, John C Klensin wrote: > A big problem, especially for a BCP or standards-track document, > is the question of evaluation of the references. Yes, and actually I could not evaluate anything in your reading list, because I won't buy books just because they are mentioned in an I-D I care about, and I'm no member of any library at the moment. In essence the same problem why I don't like ISO standards unless I find a free online version at ECMA or elsewhere. > If you want to gather up some people who could do > (and that includes cross-checking and evaluating) > a reading list in one or more languages (I'd > recommend doing it in annotated bibliography form) [...] Well, no, we discussed the one and only German book I could contribute to this BCP offlist, and agreed that adding it does not really help with the issue. But your I-D still asks for a general solution, and my proposal would be "RFC fan pages", e.g., a Wiki based on MediaWiki (but not another Wiki software) with a page for each RFC, and a "talk" page for the community. Or something in this direction cooked up by the IETF tools folks. Whatever the solution is, it should somehow integrate the errata process, and offer pointers to related RFC xxxx-bis mailing lists. In an ideal world I could grab the last SMTP and message format XML versions, fix the known errata, and send them to the authors for publication as STD. Unless the IETF already committed two step suicide... ;-) Cheers From paulej@packetizer.com Fri Jun 10 13:04:03 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6D511E80FB; Fri, 10 Jun 2011 13:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=-1.818, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAy2cIYevvjP; Fri, 10 Jun 2011 13:04:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 13DED11E8097; Fri, 10 Jun 2011 13:03:49 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p5AK3VJs002670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jun 2011 16:03:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307736217; bh=65DhJkxJweupl9J5VTi9bGIOu1I5puC8lk5CxwhLUo8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=TiuOXknIBjKKfYuabwcRFFZ02Xa5AxBB9qKAa/eXRofYC/A5dsoESJIQiJ4+DVdZY 1l0NYQo/LpN7v2d4pQjpZFZ21WcFB2eK11wI9YqBrILJxd5Gqc/jeJRUWrhJnGy307 HZo4jNmOb/zhbqShegKSyhimv9hsqDx7oVNfGAis= From: "Paul E. Jones" To: "'Nico Williams'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <02c401cc2662$9a21d220$ce657660$@packetizer.com> In-Reply-To: Date: Fri, 10 Jun 2011 16:03:20 -0400 Message-ID: <051201cc27a9$7603f970$620bec50$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDABal05/QI7UtjxArFQ00YB68uctpTKGnTw Content-Language: en-us Cc: 'Ben Adida' , 'Adam Barth' , 'OAuth WG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 20:04:03 -0000 Nico, > On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones > wrote: > > What issues, specifically. (Messages are all over the place and I > > don=E2=80=99t know exactly what issues you=E2=80=99re raising. Is = it with the > > approach we=E2=80=99re proposing or something else?) >=20 > The fundamental issue is that protecting the cookie alone is not = enough. > On open wifi networks it's a fair assumption that the difficulty of > active attacks is about the same as the difficulty of passive attacks. > Therefore you need to provide integrity protection for most of the > request and most of the response, including the bodies. While I will not claim that our current draft is bullet proof, we did = make an attempt to define a means of allowing the client and server to = be able to detect if a request has been altered, including both message = headers and message body. Draft: http://tools.ietf.org/html//draft-salgueiro-secure-state-management-04 Paul From john-ietf@jck.com Fri Jun 10 14:13:13 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09C99E8009 for ; Fri, 10 Jun 2011 14:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccsfQXTgtG84 for ; Fri, 10 Jun 2011 14:13:12 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 42E719E8007 for ; Fri, 10 Jun 2011 14:13:12 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QV90x-0000mN-FI; Fri, 10 Jun 2011 17:13:11 -0400 Date: Fri, 10 Jun 2011 17:13:10 -0400 From: John C Klensin To: Frank Ellermann Message-ID: <58B194EA134F64A163C24F35@PST.JCK.COM> In-Reply-To: References: <5D92A844AC739C22A4525EAA@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: Apps Discuss Subject: Re: [apps-discuss] Non-English reading lists (was: Re: Request to publish draft-ietf-appsawg-rfc3536bis-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 21:13:14 -0000 --On Friday, June 10, 2011 21:15 +0200 Frank Ellermann wrote: > On 10 June 2011 16:05, John C Klensin wrote: > >> A big problem, especially for a BCP or standards-track >> document, is the question of evaluation of the references. > > Yes, and actually I could not evaluate anything in your > reading list, because I won't buy books just because > they are mentioned in an I-D I care about, and I'm no > member of any library at the moment. In essence the > same problem why I don't like ISO standards unless I > find a free online version at ECMA or elsewhere. Understood. >> If you want to gather up some people who could do >> (and that includes cross-checking and evaluating) >> a reading list in one or more languages (I'd >> recommend doing it in annotated bibliography form) > [...] > > Well, no, we discussed the one and only German book > I could contribute to this BCP offlist, and agreed > that adding it does not really help with the issue. > > But your I-D still asks for a general solution, and > my proposal would be "RFC fan pages", e.g., a Wiki > based on MediaWiki (but not another Wiki software) > with a page for each RFC, and a "talk" page for the > community. Or something in this direction cooked > up by the IETF tools folks. Whatever the solution > is, it should somehow integrate the errata process, > and offer pointers to related RFC xxxx-bis mailing > lists. Well, I didn't see myself asking for a general solution. While it is just my personal opinion, I think a German-only reading list should be perfectly publishable. If it then was supplemented by, e.g., Dutch-only, Swedish-only, Norwegian-only, Japanese-only, Chinese-only, or Ukrainian-only one, that would be great too, except that I think we'd have a lot less difficulty finding independent reviewers for the first seven than for Ukrainian. While I think any of those --either single-language or multilingual-- would be useful, I carefully made my proposal in a way that would, IMO, fall well within RFC Editor precedents and RSE discretion based on those precedents. I deliberately did not address your broader dreams/fantasies precisely because they would require fundamental changes to how we do things that aren't going to happen any time soon (regardless of whether I think they are good ideas or not). >... john From evnikita2@gmail.com Fri Jun 10 20:48:46 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E7C22800B for ; Fri, 10 Jun 2011 20:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0l+41zY1c12 for ; Fri, 10 Jun 2011 20:48:45 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65FA7228007 for ; Fri, 10 Jun 2011 20:48:45 -0700 (PDT) Received: by fxm15 with SMTP id 15so2205303fxm.31 for ; Fri, 10 Jun 2011 20:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rDo7Hm+90BjN/v6Bqyisl8JmtzqN66NRG3zCgGrIkZA=; b=w8lkRLWR5tj+WkqLieuebjAflgwBnxK4AO7MQc5QlW9yYHBTv8mz8UgdEr2lERYZ76 rNwuKtKCqHNUr7zIS5XQ4FUg07j/a4bdvTKVFju34/GQSgVG+h2m9QhxsISXaX0FrRhQ UqAumIbsn20xaerm4VaC54Q5UYTpZgKyxH/30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dPN400FnktSw5dS67zI644MwYOUJ8hsgB6KVY2hZGr0811YT+QJHEo/PUlVidUASVM ftALIa6oG2/b1Wukc4iTBu6hbczIycTOvQGvdfajwkD4Iep4P+E7+IwWaJj5RNYn8RBU H4+sj6/E1D6/B0YgwTfCBdxDm8Ot+kAvq27MI= Received: by 10.223.32.142 with SMTP id c14mr2725885fad.59.1307764124204; Fri, 10 Jun 2011 20:48:44 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id e16sm1268930fak.41.2011.06.10.20.48.42 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 20:48:43 -0700 (PDT) Message-ID: <4DF2E5C7.30002@gmail.com> Date: Sat, 11 Jun 2011 06:49:27 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: John C Klensin References: <4DF23976.4080301@gmail.com> <4DF23BD4.1080802@gmx.de> <61A6FA2030E93A75C586A699@PST.JCK.COM> In-Reply-To: <61A6FA2030E93A75C586A699@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps-discuss list Subject: Re: [apps-discuss] Documenting UTF-1 as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2011 03:48:46 -0000 10.06.2011 21:25, John C Klensin wrote: > > --On Friday, June 10, 2011 17:44 +0200 Julian Reschke > wrote: > >> On 2011-06-10 17:34, Mykyta Yevstifeyev wrote: >>> Hello, >>> >>> There are a number of RFCs defining transformation formats of >>> ISO 10646/Unicode - various UTFs. I mean RFC 3629 (UTF-8), >>> RFC 2152 (UTF-7), RFC 2781 (UTF-16) and others. However, I've >>> noticed UTF-1 isn't properly documented (or, at least, there >>> is no formal record of it). However, since UTF-1 has never >>> been widely used, I suppose it could be formally documented >>> in Historic RFC, taking >>> http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis. Any >>> thoughts on this? >>> ... >> Yes. Why do we care? > Mykyta, > > Let me say that a little more strongly. > > As far as I know, it isn't used on the Internet and definitely > is not used in any IETF protocol. The document you cite was a > proposal to ISO/IEC JTC1/SC2, not to the IETF. It went nowhere > in SC2 and, in particular, was not incorporated into ISO/IEC > 10646 or any closely-related document. Actually it did; the aforementioned document refers to Annex G of ISO/IEC 10646:1993 as authoritative definition of UTF-1. > To the best of my > knowledge, it was never proposed for use in the IETF, not that > it would make much difference if it had been. > > If we were to expand our goals to include documenting (as > Historic) every bad idea proposed to some other SDO, or even > every bad idea proposed to the IETF, we would be very busy > indeed -- the population of bad ideas, or even possibly-good > ideas that did not achieve any level of standardization-- is a > rather extensive and target-rich environment. I don't consider it is necessary to document each bad idea as Historic, but rather an outdated idea, an idea, (citing RFC 2026) fallen into disuse or disfavor. Certainly, documenting bad ideas is a bad idea (sorry for pun), but documenting ideas, which were once used but now not, and which were considered to be good makes some sense (at least, for the history)... > Seriously, even proposing this has the appearance of either bad > judgment or a desire to waste the community's time. I've tried > to be supportive of your efforts to tie up assorted loose ends > in the RFC Series and gaps in protocol definitions where that > work is actually useful, but this one is really over the line. Understand. > Perhaps your next proposal should be a URI type for SUPDUP. I wouldn't be so ironic, though... > While RFC 734 has been designated as HISTORIC, RFCs 736, 746, > 747, and 749 have not been and there is no published analysis of > why SUPDUP didn't take off and why 734 was identified as > HISTORIC. Actually, I also don't see at least when (and at most why) was 734 moved to historic, which is very unhelpful. A good question is why all other SUPDUP-related RFCs weren't moved to Historic as well (2 of which are Proposed Standards, and they depend on Historic document). > I think doing such a URI, or trying to develop that > documentation, would be a waste of time too, but at least SUPDUP > was believed by many of us to be a good idea, was defined in the > IETF (or actually in its predecessor), and was deployed and used > (although not, IMO, enough). Mykyta Yevstifeyev > john > > > From evnikita2@gmail.com Fri Jun 10 21:17:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6621F846A for ; Fri, 10 Jun 2011 21:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hznNRKN8hNAG for ; Fri, 10 Jun 2011 21:17:00 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6A7B21F8469 for ; Fri, 10 Jun 2011 21:16:59 -0700 (PDT) Received: by fxm15 with SMTP id 15so2210666fxm.31 for ; Fri, 10 Jun 2011 21:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WHFR3AUSArc97htff2J5ugE7MfQF4US3gb2Pg7C74Vg=; b=AtGipemjKLFZxEUvo6HpF2rgmBjJN+XnaFJFI4zeTwYHVmzu9e6PX3voGSVHGYqYZm M/OZ9RmQVimPEjyJkr78SHqZE6ZPx/9jJFmOGVUncngysNvXUAmJWvZkNRKxbAupggyH 3WkBGzfokdI2Uq2bWTL/uc+rppmDmWCueBEsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gbeX1yHPgs9SjtxO3i2rJY5JENVDN6BW9LkzooS2d08CBlId+kC7a8Dwok6abXOQxF DwOu1GH6s9jo1Vm/oDxLzxIfK0Ueufm1N88SgWu7kyce8yIRFZ+ApnMbfqsjM0LuyXYH Wj3ZH62AFkozCZbGkcO6B5keGv389KDBURuVI= Received: by 10.223.73.199 with SMTP id r7mr2748819faj.118.1307765818966; Fri, 10 Jun 2011 21:16:58 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id h9sm1274719fai.30.2011.06.10.21.16.56 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 21:16:58 -0700 (PDT) Message-ID: <4DF2EC66.10107@gmail.com> Date: Sat, 11 Jun 2011 07:17:42 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Frank Ellermann References: <4DF23976.4080301@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps-discuss list Subject: Re: [apps-discuss] Documenting UTF-1 as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2011 04:17:01 -0000 10.06.2011 21:44, Frank Ellermann wrote: > On 10 June 2011 17:34, Mykyta Yevstifeyev wrote: > >> I suppose it could be formally documented >> in Historic RFC > In theory. But the IETF (etc.) never used UTF-1 > for anything. ISO deprecated UTF-1 years ago, > and of course they still formally document it: > > http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf > > Admittedly that page is hard to find, but OTOH > the en-wikipedia UTF-1 article lists it as its > one and only external reference (at the moment). > >> Any thoughts on this? > Unless somebody did it already: It would be a > very good thing to deprecate UTF-7 "officially" > in an RFC, because UTF-7 is at least in theory > an IETF invention. Indeed; however if we want to deprecate its use, we should provide reasonable justification for it. Maybe a reason may be "UTF-7 was written specially for RFC 822 purposes, which is obsolete", but I am not sure if it is appropriate. > There was an AD willing to sponsor this effort > in 2007, maybe the new ADs also like the idea. > The author of the UTF-7 RFC has no objections > (and should certainly get credits for his stunt > to register a "moving target" as IANA charset > before UTF-8 existed, and when Unicode was > still only registered with a version number). > > As far as HTML5 and WhatWG care about standards > they should also welcome if UTF-7 is "formally" > dead. If you volunteer for this effort you can > also talk about UTF-1 "just for the records" if > you wish. I'll then firstly discuss the issue with ADs before taking any action. > -Frank > From alexey.melnikov@isode.com Sun Jun 12 05:48:17 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DA311E8085 for ; Sun, 12 Jun 2011 05:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.27 X-Spam-Level: X-Spam-Status: No, score=-101.27 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFt6r-LdxFns for ; Sun, 12 Jun 2011 05:48:17 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1882C11E8088 for ; Sun, 12 Jun 2011 05:48:17 -0700 (PDT) Received: from [188.28.0.10] (188.28.0.10.threembb.co.uk [188.28.0.10]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Jun 2011 13:48:15 +0100 Message-ID: <4DF4B57B.4060704@isode.com> Date: Sun, 12 Jun 2011 13:47:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org References: <4DCEB8C4.3060205@isode.com> In-Reply-To: <4DCEB8C4.3060205@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Private Enterprise Number (PEN) IANA registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2011 12:48:17 -0000 Alexey Melnikov wrote: > Hi, > IANA is writing a draft on formalizing how Private Enterprise Numbers > (PENs) are registered. Is anybody interested in helping out (as > co-editor) with the document? If yes, please contact me off-list. Just to followup on this: thanks to everyone for volunteering! Michelle from IANA has asked Marc Blanchet to help with editing of the document. From duerst@it.aoyama.ac.jp Mon Jun 13 00:08:55 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DEA11E808D for ; Mon, 13 Jun 2011 00:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.79 X-Spam-Level: X-Spam-Status: No, score=-99.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtSxclPSMYEl for ; Mon, 13 Jun 2011 00:08:54 -0700 (PDT) Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9D84F228011 for ; Mon, 13 Jun 2011 00:08:53 -0700 (PDT) Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p5D78nZv016736 for ; Mon, 13 Jun 2011 16:08:49 +0900 Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 6c7f_34ff_fc987cd6_958b_11e0_9751_001d0969ab06; Mon, 13 Jun 2011 16:08:49 +0900 Received: from [IPv6:::1] ([133.2.210.5]:49306) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 13 Jun 2011 16:08:46 +0900 Message-ID: <4DF5B770.50407@it.aoyama.ac.jp> Date: Mon, 13 Jun 2011 16:08:32 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4DF23976.4080301@gmail.com> In-Reply-To: <4DF23976.4080301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps-discuss list Subject: Re: [apps-discuss] Documenting UTF-1 as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 07:08:55 -0000 I agree with what others have said, and will stay short (and unfortunately a bit blunt): UTF-1, like most UTF-X (where X isn't 8/16/32, and maybe also 7) are totally irrelevant. Spending time on such stuff is just wasteful. The 'historic' description is to relabel stuff that was in an RFC without a 'historic' label. That doesn't apply to UTF-1. UTF-1 is in the IANA charset registry (http://www.iana.org/assignments/character-sets), but so are several others that are completely useless, too. Enough said. Regards, Martin. On 2011/06/11 0:34, Mykyta Yevstifeyev wrote: > Hello, > > There are a number of RFCs defining transformation formats of ISO > 10646/Unicode - various UTFs. I mean RFC 3629 (UTF-8), RFC 2152 (UTF-7), > RFC 2781 (UTF-16) and others. However, I've noticed UTF-1 isn't properly > documented (or, at least, there is no formal record of it). However, > since UTF-1 has never been widely used, I suppose it could be formally > documented in Historic RFC, taking > http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis. Any thoughts on > this? > > Mykyta Yevstifeyev > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From eran@hueniverse.com Mon Jun 13 00:26:58 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1F121F84BC for ; Mon, 13 Jun 2011 00:26:58 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtIucvyxHGS2 for ; Mon, 13 Jun 2011 00:26:58 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 5A49D21F84BA for ; Mon, 13 Jun 2011 00:26:58 -0700 (PDT) Received: (qmail 13399 invoked from network); 13 Jun 2011 07:26:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jun 2011 07:26:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 13 Jun 2011 00:26:53 -0700 From: Eran Hammer-Lahav To: Tim , Robert Sayre Date: Mon, 13 Jun 2011 00:26:37 -0700 Thread-Topic: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme Thread-Index: Acwms3fxX3rJ7OFlSrWL/fhQrFzuuQC5jjtg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E774395@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110609144224.GR1565@sentinelchicken.org> In-Reply-To: <20110609144224.GR1565@sentinelchicken.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 07:26:59 -0000 > -----Original Message----- > From: Tim [mailto:tim-projects@sentinelchicken.org] > Sent: Thursday, June 09, 2011 7:42 AM > To: Robert Sayre > Cc: Eran Hammer-Lahav; OAuth WG; apps-discuss@ietf.org > Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC > Authentication Scheme >=20 > > Digest has a bunch of problems. See this document > > > > http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#s > > ection-2.2.2 > > > > for a short tour of them. >=20 > Thanks for the link. I totally agree with all of this, and in fact there= are more > MitM attacks possible than are alluded to in that document. This is one o= f the > two reasons I brought up Digest initially. The MAC proposal does not app= ear > to provide any additional security over Digest, and yet Digest is still > susceptible to MitM attacks. >=20 > We can pick and prod at the MAC proposal all we want from a security > perspective, but we'll probably end up at the same place that Digest is a= t, > security-wise. We'll still have a protocol that can't defend against Mit= M > attacks. So what is the point in providing integrity again? >=20 > We need to use TLS. Everywhere. Sure. =20 > The more you look at advanced web attacks (MitM downgrade attacks, DNS > rebinding attacks, etc), the more you realize that most of these are > addressed by TLS if only it were used everywhere. >=20 > It's fine to bring out special-purpose authentication protocols. > Authentication can happen in a variety of ways either within TLS or tunne= led > over it (hopefully with channel binding), but don't pretend you'll be doi= ng > anyone favors by trying to provide partial integrity protection that is > ultimately ineffective. Just focus on better authentication and > key/certificate management and let TLS do the rest. Modern web applications require a lot of third-party hosted services: analy= tics, advertising, plug-ins, etc. Until everyone deploys TLS, including suc= h non-TLS bits in a TLS page cause the browser to show a broken TLS state i= n the address bar. For most web users, that's more of a red flag (valid TLS= but with some resources loaded without TLS) than no TLS at all. The realit= y is that it is really hard to deploy TLS applications today without having= issues with at least one vendor (especially when that vendor is an ad netw= ork you rely on for your profits). So while we wait for the web to catch up and deploy TLS (and this effort do= es not delay that), we should try and do something about trivial attacks li= ke Firesheep. Yes, adding MAC to cookies without TLS does not provide anywh= ere near the protection of TLS, but it is better than nothing, when TLS is = not available. Note that the MAC authentication scheme is not exclusively about cookies, a= nd has value beside just making session cookies better. EHL From tim-projects@sentinelchicken.org Mon Jun 13 08:28:39 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042E621F84E6 for ; Mon, 13 Jun 2011 08:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1u59Cblecda for ; Mon, 13 Jun 2011 08:28:38 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2020A21F84DE for ; Mon, 13 Jun 2011 08:28:37 -0700 (PDT) Received: (qmail 24165 invoked from network); 13 Jun 2011 15:28:33 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 13 Jun 2011 15:28:33 -0000 Received: (qmail 14338 invoked from network); 13 Jun 2011 15:29:28 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 13 Jun 2011 15:29:28 -0000 Received: (nullmailer pid 337 invoked by uid 1000); Mon, 13 Jun 2011 15:28:32 -0000 Date: Mon, 13 Jun 2011 08:28:32 -0700 From: Tim To: Eran Hammer-Lahav Message-ID: <20110613152832.GU1565@sentinelchicken.org> References: <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110609144224.GR1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E774395@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E774395@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: OAuth WG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 15:28:39 -0000 Hi Eran, > ... Until everyone deploys TLS, including such non-TLS bits in a TLS > page cause the browser to show a broken TLS state in the address bar. > For most web users, that's more of a red flag (valid TLS but with some > resources loaded without TLS) than no TLS at all. And in fact, in any modern browser, this situation is rightfully called out as an insecure deployment. Many one of those non-TLS resources you refer to could be modified by an attacker to inject malicious script and therefore hijack sessions. > The reality is that > it is really hard to deploy TLS applications today without having > issues with at least one vendor (especially when that vendor is an ad > network you rely on for your profits). Agreed. It is a typical "no one can do it because no one else is doing it" situation. > Yes, adding MAC to cookies without TLS > does not provide anywhere near the protection of TLS, but it is better > than nothing, when TLS is not available. To Nico's point, I'm not entirely sure about that. If something like MAC caught on, where would people deploy it? They deploy it to protect credentials over non-TLS connections, right? So it might be used as yet another excuse not to use TLS, even though it doesn't provide the kind of protection that most users would expect. In modern browsers, MAC would do nothing to stop someone from injecting script into a response which initiates arbitrary requests on behalf of a user. A browser would have no idea that the script was malicious, so it would happily sign requests as if they were user-initiated. To the point: session hijacking isn't just about stealing and reusing a session token. I see no problem trying to provide something to help protect user credentials through hard-to-crack hashes and the like, since those are often used in more than one place, but I see no point in trying to provide one-way integrity protection. thanks, tim From svartman95@gmail.com Mon Jun 13 08:45:02 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F2E11E8072; Mon, 13 Jun 2011 08:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+mjzCwzzNVK; Mon, 13 Jun 2011 08:45:01 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59BD511E80D9; Mon, 13 Jun 2011 08:45:00 -0700 (PDT) Received: by gxk19 with SMTP id 19so4116763gxk.31 for ; Mon, 13 Jun 2011 08:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1tjUbpJ2L4XoEaTJI1CgNC/2eMAtanVrxdlaOqFwNVw=; b=xsjbuawlyqVvM8dNaIt+hZvoi7cjBkoNCalXeD8hnGQviLy0c2e6yKugXDxCI16sMq VciyuOX5bvPzGuVOmFlqFpJCjG1mWtSAqdtDAuMv4eLmt/TDdVH+ju9Lus+/pHiSuJiZ Z64KaWB4u+czRSzX3RMck4S2Ciiv9Q7TKH1Ko= 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=dyg1l3I0wQ0UcFt8XKzWezLZblQZkzEOBs4/lquzCCAAK1puN+jBquNSt1drlCQNmW +gTr9Q4PpixNRGEkm+Agj+6V/fiGzeYWKDfvh4DE/S1gnCRwUu7i+JqgqBE9a6WwdpwO ou9VStN2dGp2W452zgfNPzI80AO6bqY4XpiXc= MIME-Version: 1.0 Received: by 10.236.66.49 with SMTP id g37mr3527411yhd.237.1307979880381; Mon, 13 Jun 2011 08:44:40 -0700 (PDT) Received: by 10.236.70.35 with HTTP; Mon, 13 Jun 2011 08:44:39 -0700 (PDT) In-Reply-To: <20110613152832.GU1565@sentinelchicken.org> References: <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110609144224.GR1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E774395@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110613152832.GU1565@sentinelchicken.org> Date: Mon, 13 Jun 2011 15:44:39 +0000 Message-ID: From: Bjartur Thorlacius To: Tim Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 15:45:02 -0000 On 6/13/11, Tim wrote: > Agreed. It is a typical "no one can do it because no one else is > doing it" situation. Not quite, as ad networks are free to support TLS. Embedders simply link to ads using either the http or the https scheme (without breaking anythings as user agents support both already). The problem seems to be lack of pressure, as ad networks compete primarily on price and amount of distraction. Users won't notice if they're downloading both their content and ads over plain HTTP over TCP. From evnikita2@gmail.com Wed Jun 15 08:24:07 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838C421F849F; Wed, 15 Jun 2011 08:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4uAHzqLyrAp; Wed, 15 Jun 2011 08:24:02 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 655E721F8493; Wed, 15 Jun 2011 08:23:59 -0700 (PDT) Received: by fxm15 with SMTP id 15so565897fxm.31 for ; Wed, 15 Jun 2011 08:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZZmwJ/ktzzzR3063P7pQViUholgyEuGU7r6QURRbk6E=; b=bCELpv2PpHdyCNWXuHwDI8GARX/XM6r3mCHK2u29twC/0yqsL52IG97QWJKoQWhTpR bUdvElOw1BnZQi3pqdydHBSb7QAiQkOIqnUrHjJ114+vXFUrt4kAOoAeXn61b1ZcBNMs Ltp+SIDhICRJAKOHvwO4b+jbeLomMOpLIfTok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wXbNJ3AfYdgcMm+WdfX2C1RYv4FCBkXnRkDFd75nzFOV4WPvJ9558lGrHmoAuudpXG rp4W90+ttbamHf6pLzT4c6xQWCkdhNNcKJpi/jqTcFXMCM4roy6K49oN4LgHqqRcOznv 9Tr+/T7E65in1DrY/gSaf2bo9pMKrsFStl3dk= Received: by 10.223.68.193 with SMTP id w1mr771281fai.42.1308151438466; Wed, 15 Jun 2011 08:23:58 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id l26sm281789fah.14.2011.06.15.08.23.55 (version=SSLv3 cipher=OTHER); Wed, 15 Jun 2011 08:23:56 -0700 (PDT) Message-ID: <4DF8CEB9.9030108@gmail.com> Date: Wed, 15 Jun 2011 18:24:41 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alexey Melnikov References: <4D4FD50E.2020503@it.aoyama.ac.jp> <4D83B681.60906@isode.com> In-Reply-To: <4D83B681.60906@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "uri-review@ietf.org" , draft-holsten-about-uri-scheme@tools.ietf.org, "apps-discuss@ietf.org" , IESG Subject: Re: [apps-discuss] apps-team review of draft-holsten-about-uri-scheme-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2011 15:24:07 -0000 18.03.2011 21:46, Alexey Melnikov wrote: > Hi Martin, > As authors didn't respond to your comments and I need to pass on > shepherding of this document to Peter, so I will quickly respond to > clarify where I stand on your comments (as the shepherding AD): Hello all, The authors of draft-holsten-about-uri-scheme allowed me to help them with the draft. The -07 version is almost ready; it is believed to incorporate comments from Martin above. Let me inform what was changed with regard to each of these points. > > Martin J. Dürst wrote: > >> I have been selected as the Applications Area Review Team reviewer for >> this draft (for background on apps-review, please see >> http://www.apps.ietf.org/content/applications-area-review-team). >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> >> Document: draft-holsten-about-uri-scheme-06 >> Title: The 'about' URI scheme >> Reviewer: Martin J. Dürst >> Review Date: February 7, 2011 >> >> >> Summary: This draft is not ready for publication, but because it is >> short, the problems identified below could be fixed soon. >> >> This draft defines the about: URI scheme, a scheme that has been used >> internally, informally by browsers since ages. It's good to see this >> defined and registered finally, but there are some problems that need >> to be fixed. >> >> >> Major Issues: >> >> - Section 5.1: "Other specification MAY reserve "about" URIs.": How >> is this done? And done in a way that gives implementers a chance to >> know about it? Surely if specifications are involved, a very >> lightweight version of IANA registry/process should not be too heavy. >> For my own taste, even a Wikipedia page might do the job, but just >> leaving this open looks like a bad idea. If additions are thought to >> be very infrequent, "updates to this specification" might also do the >> job. > > I think pretty much everybody (including GenArt, Ted Hardie and > myself) spotted this issue. Currently, the registry for 'about' URI tokens is intended to be created. The proposed text is: > 9.2. IANA Registry for Reserved 'about' URIs Tokens > > IANA is asked to create and maintain the registry called "Reserved > 'about' URIs Tokens" following the guidelines below. > > The registry provides a listing of registered reserved 'about' URI > tokens. The reserved 'about' URI token refers to the string used in > the part of reserved 'about' URIs, with the syntax > described in Section 2 for this rule. The entries in the registry > MUST refer only to those values that are used in reserved 'about' > URIs, as described in Section 5.1. > > The registration procedures for this registry are 'First Come First > Served', described in RFC 5226 [RFC5226]. The registrant of such > token SHALL also provide the following registration template, that > SHALL be available on IANA web site: > > Reserved 'about' URI Token. REQUIRED field. Desired 'about' URI > token, compliant to the syntax described in Section 2 of this > document for the rule > > Intended Usage. REQUIRED field. A short description of intended > usage of 'about' URI with such token > > Resolvable 'about' URI. REQUIRED field. Should be "yes" if > resolvable or "no" if unresolvable, per Section 5.2 of this > document > > Specification. OPTIONAL field. References to the document(s), if > any, that described the registered 'about' URI token > > Assignment Notes. OPTIONAL field. Any additional information > about the assignment > > Contact/Change Controller. REQUIRED field. A person or an > organization, authorized to change this registration, that should > > be contacted for further information on the registered 'about' > URI,with their contact points > > 9.2.1. Initial Contents > > The registry initially contains the following registration: > > 'about' URI token: blank > > Intended usage: The "about:blank" URI returns the blank page > > Resolvable 'about' URI: Yes > > Specification: RFC XXXX (this document - note to RFC Editor) > > Author/Change Controller: W3C > >> - 6. Normalization: This is confused. There are NO standard URI >> normalization rules, just various choices, in RFC 3986. And the >> choice of normalization rule is NOT a per-scheme choice, it's a >> per-usage choice, where usage for XML namespaces differs widely from >> usage for some protocol-based resolutions, and that again differs >> widely from what spiders and robots do. As an example, when used as >> an XML namespace URI, "about:blank" and "about:blan%6B" identify >> different namespaces. The text should make it excruciatingly clear >> that the normalization rules given there apply ONLY to (browser >> built-in) resolution of about URIs. Also, the phrase "Due to the >> structure of the "about" URI, some normalizations do not apply, >> specifically ..." is inappropriate given the examples following, and >> unnecessary. > > Right. This was considered. The current Section 7 (the renumbered Section 6) reads: > 7. Normalization > > 'about' URIs use the following URI normalization rules of [RFC3986]: > Simple String Comparison, Case Normalization, and Percent-Encoding > Normalization. For example, "about:blank", "about:blan%6B" and > "about:blan%6b" are equivalent, though the percent-encoded forms are > discouraged. > > Note that these normalization rules apply only to the case of > application built-in resolution of 'about' URIs, i.e. "about:blan%6B" > and "about:blank" SHALL be resolved in the same way. Other cases of > these URIs usage would require other normalization rules Some words concerning http://www.ietf.org/mail-archive/web/ietf/current/msg66862.html are also planned to be added, I think. >> Minor Issues: >> >> - The split of about: URIs into three kinds (reserved, unreserved, >> and unrecognized) is highly confusing. It looks as if two binary >> distinctions are conflated: a) The distinction between reserved and >> unreserved, which is a distinction from a specification point. b) The >> distinction between recognized and unrecognized, which is a >> distinction from an implementation (resolution) point. There's >> nothing to rule out reserved but unrecognized about: URIs in the >> future (with only about:blank being standardized at the moment, and >> unrecognized about: URIs defaulting to about:blank, there's currently >> no such case). > > Agreed. I think this is considered in the following paragraph added in Section 5: > The division of 'about' URIs into the reservation and resolution > categories is per-fact while the recognition per-application. > Therefore, while an 'about' URI may be classified as, for example, > reserved and resolvable, it may be not be recognized by all > applications. > >> - The abstract describes the about: scheme. It should explicitly >> contain the wording "defines ... the about: scheme", because that's >> the most important thing done with this document. That will also make >> the Abstract more different from the Introduction; currently the read > > Ok. Current abstract is: > Abstract > > This document specifies the 'about' URI scheme, that may be used by > the applications for almost any desired purpose, such as providing > access to application information, settings, preferences, etc. This > URI scheme has been used by many web browsers for quite a long time > informally, i. e. without being documented; this document is to > remove such uncertainty and give this scheme an official > specification. > >> - The abstract and the text mention "easter eggs". There are large >> parts of the world where Easter isn't known, and nor are Easter eggs >> (in the general sense of fancifully colored eggs). On top of this, >> the use of the term "easter egg" in the document is a very >> specialized hacker jargon use. Proposal: Remove from abstract, add >> explanation in text. > > Possibly. I wouldn't worry too much about this particular issue: I > hope RFC Editor can provide a good advice on this. The reference to http://en.wikipedia.org/wiki/Easter_egg_%28media%29 was added to clarify this. > >> - End of first paragraph of Section 4: "then only those octets that >> do not correspond to characters in the unreserved set [RFC3986] >> SHOULD be percent-encoded." This can very easily be misunderstood. >> The writer seems to want to apply the SHOULD to 'only', but readers >> will apply it to 'percent-encoded', meaning that an implementation >> might be okay even if it didn't percent-encode characters outside the >> unreserved set. The best thing to do here is to not make this >> normative language (because RFC 3986 already defines what's allowed >> and what not). The authors seems to be worried that some people might >> apply percent-escaping to a-z and such, but this is not something to >> worry about in practice. > > I actually found similar text in other RFCs. The sentence was changed to: > those octets that correspond to characters in the unreserved set > [RFC3986] should noy be percent-encoded. > >> - Section 5 starts defining various kinds of "about" URIs. It should >> start by first saying that there are three different kinds of "about" >> URIs, to make the reader's job easier (but see above). Now it is: > 5. Resolving 'about' URIs > > All 'about' URIs are categorized in three ways: > > o Reservation. [ . . . ] >> >> - Section 5.1.1 contains a lone sentence fragment 'i.e. >> "about:blank".', which seems to be unnecessary. Corrected. >> >> - 5.4. Examples is inconsistent with final punctuation. Corrected as well. >> >> - I seem to remember that the change controller for standards track >> stuff is the IESG. But I may be wrong. > > Yes. After some internal discussions it was decided to remain W3C change controller; yet, they will still need IESG approval to make changes to registration. As soon as some other minor issues are considered, I think -07 will be published. At least, at the end of June, I hope. Mykyta Yevstifeyev > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From gih@apnic.net Wed Jun 15 07:50:48 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7AD21F85B8; Wed, 15 Jun 2011 07:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.729 X-Spam-Level: X-Spam-Status: No, score=-98.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, J_CHICKENPOX_31=0.6, J_CHICKENPOX_35=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+ru9BIvlzyk; Wed, 15 Jun 2011 07:50:48 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id E1D3B21F85AC; Wed, 15 Jun 2011 07:50:46 -0700 (PDT) Received: from [192.35.165.135] (unknown [192.35.165.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 6D557B68BC; Thu, 16 Jun 2011 00:50:43 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <9780CDCD-0C08-4D19-B63F-240D8FDA6425@tzi.org> Date: Thu, 16 Jun 2011 00:50:21 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9780CDCD-0C08-4D19-B63F-240D8FDA6425@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 15 Jun 2011 08:28:25 -0700 Cc: draft-ietf-sidr-rescerts-provisioning.notify@tools.ietf.org, The IESG , Apps Discuss Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-rescerts-provisioning-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2011 14:50:49 -0000 We have submitted a new version of this document. It addresses most of = the issues raised in the review. A point-by-point response to the review = is as follows: = --------------------------------------------------------------------------= - **=20 Thank you for this detailed review. We appreciate the care and=20 attention to detail that has gone into this review. We will respond to the review pint a point-by-point basis, marked by ** delimiters in the test. I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sidr-rescerts-provisioning-09 Title: A Protocol for Provisioning Resource Certificates Reviewer: Carsten Bormann Review Date: 2011-04-09 SUMMARY: This document is ready for publication after a number of relatively simple changes have been performed. A slightly larger set of potentially desirable improvements have also been identified. PURPOSE: The draft describes a protocol for provisioning resource certificates. A resource in this context is an Internet Number Resource (INR), i.e., IP Address or Autonomous System (AS) Number. The protocol is used between a client "Subject" (such as an ISP) and a server "Issuer" (such as a registry, acting as a CA). The protocol will thus be used between in a very specialized setting between members of two closely-knit communities; there is little danger of properties of this protocol spilling over into mainstream application protocols. REVIEW: Several properties of this protocol represent current practice, but not necessarily best practice, in application protocol design. The message transport used is an HTTP POST request, which is used as a request-response vehicle for carrying around CMS objects which in turn carry XML-encoded messages that are the subject of this protocol. Given the specialized status of this protocol, this may be acceptable. Major Issues: 1. The media type used for requests and responses cannot be registered under the name 'application/x-rpki' (section 4.2 of RFC 4288). Unless significant deployment makes this prohibitive, a permanent name SHOULD be chosen and the media type be registered according to RFC 4288 (BCP 13). ** Accepted The document now includes an IANA Considerations section that includes a completed registration template for application/rpki-updown This template is to be forwarded to the ietf-types folks for their=20 review. ** 2. There is an explicit mandate for serializing the processing of all requests between one server/client pair, without it being fully clear what exactly constitutes that pair (i.e., when are two requests from the *same* client)? Similarly, it is not quite clear how to "Check that the XML sender and recipient attributes reference a known client and this server's system respectively" (the underlying data type is an xsd:token). ** Accepted. The text now clarifies what a "client" is in this context. ** Details: 3. There is no such thing as a "HTTP 400 Bad Data" response to an HTTP POST. Status code 400 stands for "Bad Request". ** Accepted Edit applied ** 4. It may be worthwhile to mention the use of the Retry-After: HTTP header with a 503 status. ** Accepted Edit applied ** 5. My ASN.1 is a bit rusty, but the content of 3.1.1.3.2 looks strange to me and is rejected by asn1c. Has this been validated? Same comment for Appendix A. Remove duplicate definition of ContentType as well. ** Accepted reviewer is correct, this asn.1 is confused. this particular line is setting the identifier id-ct-xml to be an alias for the built-in type name OCTET STRING, which is wrong. the other definition for id-ct-xml is correct (the "ct" stands for "content type" and is a hint that this is supposed to be an object identifier). the definition in section 3.1.1.3.2 and the second definition of id-ct-xml in the appendix should be replaced by something like: RPKIXMLProtocolObject ::=3D OCTET STRING -- XML encoded message ie, make up a sort-of-human-meaningful identifier that follows the ASN.1 conventions for type names and just set it to the right type, which is indeed OCTET STRING. yes it looks a little odd to have this sitting all by itself in the definitions with nothing referencing it, but that appears to be the way cms eContentType is done, see, eg, the definitions in the roa-format and manifest drafts. Edit applied ** 6. re 3.2 Common Message format: The reader's mind should be put at ease here by quickly pointing to the Relax-NG spec in Annex B. It should be clarified that the text in 3.2 is specifying the message format by way of examples, and that the actual (also normative) format is specified in Appendix B. ** Accepted Edit applied ** 7. re 3.2 Common Message format: please remove the spaces around the '=3D' in 'recipient =3D "recipient name"' to minimize confusion. ** Accepted Edit applied ** 8. The use of a comma-separated list of URIs (which in turn requires escaping commas in the URIs themselves) in the attribute "cert_url" in the context of a class or certificate element is suboptimal. Allowing one or more cert_url elements nested in the class element would be more natural XML. ** While it may be "more natural" for this reviewer, this is a matter=20 of style, and in this case the running code uses the format described here. The text will remain consistent to the running code. ** 9. It is unclear why a new convention for the representation for IPv6 addresses needs to be invented. One should simply make use of RFC 5952. The example given in the text for resource_set_ipv6 does not conform to either RFC 5952 (it uses upper case, as seems to be recommended by the somewhat opaque reference to http://www.w3.org/TR/xmlschema-2/#hexBinary and its canonical form) nor the new convention (it uses leading zeros). (The reference to RFC 3779 seems to point to section 2.2.3.6 in that RFC?) ** Accepted Edit applied ** 10. re 3.4: I have trouble understanding: If any of the req_resource_set attributes are specified in the request, then any missing req_resource_set attributes are to be interpreted as specifying the complete set of the corresponding resource type that match the client's current resource allocation. If the value of any req_resource_set attributes is the null value (""), then this indicates that no resources of that resource type are to be certified with this request. What is the semantics if none of the req_resource_set attributes are specified? ** Accepted Edits to clarify the text have been made ** 11. What are the circumstances under which the following SHOULD is not required, and what can the client rely on to happen in this case? o If the resource class is not defined by the server, then the server SHOULD return error code 1201. ** SHOULD has been replaced with MUST ** 12. (The reviewer got curious why ski is using base64url and all other binary data are encoded in base64.) ** because they are used differently. existing implementations use ski in filenames, but plain base64 is easier to work with for general use because it's more widely supported by existing tools. ** 13. What is the point of limiting the error_response status code to one quadrillion minus one? The set of status codes ever standardized is likely to be smaller, not requiring a 50 bit number. Right now, they are all four-digit numbers, which might be a hint to a more reasonable upper limit. ** No known point - the texty has been edited to drop the limit ** 14. There is no way in the schema to include a second description element, as is require in the description of "description" in 3.6. ** Accepted Schema edited to allow >1 description elements ** 15. The schema allows zero-length certificates throughout -- this will be caught at the semantic level, but it is probably worthwhile spending a couple of minLength constraints on the xsd:base64Binary. Similar comment for the xsd:token in class_name. ** Accepted MinLength values added to the schema ** 16. (There are some indentation idiosyncrasies in the schema, e.g. in issue_request and in revocation. The schema might also be improved by factoring out some common types such as xsd:base64Binary { maxLength=3D"512000" } xsd:token { maxLength=3D"1024" } as was done e.g. in draft-ietf-sidr-publication.) ** Accepted Schema edited ** ------------------------------------------------------------------------ Geoff On 12/04/2011, at 11:29 AM, Sandra Murphy wrote: > Gentlepersons, >=20 > I received the following message indicating that the Apps Review team = had reviewed the rescerts-provisioning draft. The URL points to the = review in the apps-discuss mailing list. It is not clear from the = archive that the authors were recipients on the message, even though the = tone of the message seems to directed toward the authors. >=20 > The review is long and detailed. I would appreciate your attention to = the review as soon as possible so I can give some reply to the = apps-discuss mailing list. >=20 > --Sandy >=20 >=20 > ---------- Forwarded message ---------- > Date: Mon, 11 Apr 2011 17:05:01 -0700 > From: SM > To: Sandra Murphy > Cc: Carsten Bormann , Chris Morrow = , > Alexey Melnikov > Subject: Re: [apps-discuss] apps-team review of > draft-ietf-sidr-rescerts-provisioning-09 >=20 > Hi Sandra, > At 13:30 09-04-2011, Carsten Bormann wrote: >> I have been selected as the Applications Area Review Team reviewer = for >> this draft (for background on apps-review, please see >> http://www.apps.ietf.org/content/applications-area-review-team). >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document = shepherd >> or AD before posting a new version of the draft. >> Document: draft-ietf-sidr-rescerts-provisioning-09 >> Title: A Protocol for Provisioning Resource Certificates >> Reviewer: Carsten Bormann >> Review Date: 2011-04-09 >=20 > Carsten posted a review of draft-ietf-sidr-rescerts-provisioning-09 at = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02448.html = I suggest that you follow up on the Apps-discuss mailing list. >=20 > Regards, > S. Moonesamy From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Jun 15 09:23:35 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1973921F8592; Wed, 15 Jun 2011 09:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_55=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cwKgVIZIk3i; Wed, 15 Jun 2011 09:23:34 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6E6B21F8591; Wed, 15 Jun 2011 09:23:34 -0700 (PDT) Received: by pvh18 with SMTP id 18so491729pvh.31 for ; Wed, 15 Jun 2011 09:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=N5JAKgAoLdU1q7k/BmUMVZSu4987zJ7VfOFlw7ernsk=; b=lkbgT6yk/phmYD0sBpcvrAd6XJZOGiWgNjd7q04O3jHWaf7w3UZpkWCq82d9/gsTQ9 iNiMHweoeaoh32/CiXYtGc+7zqBFdcY86tQN3G6ZscL3T3KMS8mBCmTzscVq5rYHML22 A2GDMG7+IHB/gCNq39eyd8y79nAyR4xtLNn24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=AsgPdah1mfVznNRp9HmPExRans/5qzbVEsPYJUUH+jakZjnN1H51dcA/tG+ISkEDYy 9I4WLap9WZVz3Zwus8t2AFKg1TB1MVsm+gnpLYZr4G2Pzh/+O3N6Dh1d6YpSyD+vxJQm jrRE1tGLm2sB4+DgsEbseBbp0aJz8DKCMSMOY= Received: by 10.142.3.39 with SMTP id 39mr188133wfc.61.1308155014233; Wed, 15 Jun 2011 09:23:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.34.19 with HTTP; Wed, 15 Jun 2011 09:23:14 -0700 (PDT) In-Reply-To: <4DF8CEB9.9030108@gmail.com> References: <4D4FD50E.2020503@it.aoyama.ac.jp> <4D83B681.60906@isode.com> <4DF8CEB9.9030108@gmail.com> From: Frank Ellermann Date: Wed, 15 Jun 2011 18:23:14 +0200 Message-ID: To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "uri-review@ietf.org" Subject: Re: [apps-discuss] apps-team review of draft-holsten-about-uri-scheme-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2011 16:23:35 -0000 Back in January I sent a comment to the authors of this good I-D, but I guess that mail never made it. Just in case, because it's apparently still not *too* late, I add the content below. ---------------------------------------------------------------- Hi, I like your "about" Internet-Draft. If you are not already in Last Call a simple suggestion: You offer well-known examples such as about:plugins and about:mozilla. One thing users often have to fight with is to FIND relevant about: URIs for their UA. Sometimes about:about is used to display a list of relevant about: URIs. If you would add about:about as example this will encourage developers to support it in their product. From iesg-secretary@ietf.org Thu Jun 16 06:04:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339A521F8557; Thu, 16 Jun 2011 06:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJceso3Ah76C; Thu, 16 Jun 2011 06:04:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C766721F854F; Thu, 16 Jun 2011 06:04:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110616130400.4851.68985.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 06:04:00 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (Terminology Used in Internationalization in the IETF) to BCP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 13:04:01 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Terminology Used in Internationalization in the IETF' as a BCP 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 2011-06-30. 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. Abstract This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/ No IPR declarations have been submitted directly on this I-D. From evnikita2@gmail.com Thu Jun 16 20:20:48 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA54011E807D; Thu, 16 Jun 2011 20:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEe+PjKO3FO2; Thu, 16 Jun 2011 20:20:47 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABDA11E8079; Thu, 16 Jun 2011 20:20:46 -0700 (PDT) Received: by fxm15 with SMTP id 15so1697426fxm.31 for ; Thu, 16 Jun 2011 20:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WdV6NsnjeBCPj6HnqIZIrKgZb44FJN13AQkKC5ssCpE=; b=NRiwqGnqLDDT2E1c1Ir2UaY7hr7PN3zUJsjCzcawZ1vqCw/uzhgQ6wV77v96ENXHgI MWLIizMdrSqs6N+9WSFuzTy7VWPFuGWOU4gYlZaoVEtoPevLjQ+1dY7pYC8ZB45dHPNV wK7czNCp8rO9TKn77esUF1Kgqkz7rQJ1hZcgc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cY3U5Miiuh3GLUdC3QtoBNVocEXi6Tbn+vL1hTpKx+gXD7Fq2KBDJc088TQwzcnukt DCeR7hMR7QvtBp52bmTRE12nF69uvg2y6Yc03UiQsixiOiioAJP+2QQ4RYovhw1SUh2P GH5oDa7ZDr2YvF1qUGIQxjSCbtU9lBbvVP4rw= Received: by 10.223.33.80 with SMTP id g16mr1894230fad.125.1308280845518; Thu, 16 Jun 2011 20:20:45 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id o23sm1105859faa.33.2011.06.16.20.20.43 (version=SSLv3 cipher=OTHER); Thu, 16 Jun 2011 20:20:44 -0700 (PDT) Message-ID: <4DFAC83A.6010208@gmail.com> Date: Fri, 17 Jun 2011 06:21:30 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ietf@ietf.org References: <20110616130400.4851.68985.idtracker@ietfa.amsl.com> In-Reply-To: <20110616130400.4851.68985.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Terminology Used in Internationalization in the IETF) to BCP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2011 03:20:48 -0000 Hello all, I have an only concern with regard to this document which I expressed before, during WG discussions, and which I'd like to bring to IESG's attention now. For a number of times I proposed improving the "control character" definition in Section 4.1: > control character > > The 65 characters in the ranges U+0000..U+001F and U+007F..U+009F. > The basic space character, U+0020, is often considered as a > control character as well, making the total number 66. They are > also known as control codes. In terminology adopted by Unicode > from ASCII and the ISO 8859 standards, these codes are treated as > belonging to three ranges: "C0" (for U+0000..U+001F), "C1" (for > U+0080...U+009F), and the single control character "DEL" (U+007F). > My proposals included http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02558.html and http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02589.html. The main justification I provided is that, in accordance with Abstract: "This document provides a glossary of terms [...]" so we need to specify "what does the control character mean" but not "what Unicode codepoints are assigned for control characters". Yet, on the apps-discuss mailing list there were some concerns regarding the fact that control characters are unfamiliar to internalization so my proposed definition is not an option (one of the authors shares this opinion). Thus, why does it occur in its current form? So, there are two possible variants, I think: (1) remove the "control character" definition from the document as irrelevant to internalization or (2) produce a really good definition of this term (consider we're trying to give the terms normative meaning within IETF, since the intended status is BCP). I didn't manage to persuade the authors or WG to undertake any of the aforementioned options and I hope IESG should decide on this. Also, as a minor remark on references. The document makes normative reference to an obsolete document - ISO/IEC 10646:2003 whereas ISO/IEC 10646:2011 is published. The reference should be corrected. Thanks, Mykyta Yevstifeyev 16.06.2011 16:04, The IESG wrote: > The IESG has received a request from the Applications Area Working Group > WG (appsawg) to consider the following document: > - 'Terminology Used in Internationalization in the IETF' > as a BCP > > 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 2011-06-30. 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. > > Abstract > > > This document provides a glossary of terms used in the IETF when > discussing internationalization. The purpose is to help frame > discussions of internationalization in the various areas of the IETF > and to help introduce the main concepts to IETF participants. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From evnikita2@gmail.com Thu Jun 16 20:21:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F0B11E8139; Thu, 16 Jun 2011 20:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJnOP5vjsaVf; Thu, 16 Jun 2011 20:21:10 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E62D11E8135; Thu, 16 Jun 2011 20:21:09 -0700 (PDT) Received: by mail-fx0-f44.google.com with SMTP id 15so1697426fxm.31 for ; Thu, 16 Jun 2011 20:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bqqXsoHOynVumw4lfNx3Z9v0PCJOOsi08QC6bKYMrjE=; b=nCOIDCZ7EPkUFlBBvPJz2mjiCZrjIO9UX0wSieZieimRqZ7wG/RPJpOi2o71HpJzQx VYXkSK8FIXlujFx5idN5+UjqQ3YGaskSxLeGDp1LX0DodRd43lFJ2vAP5Lo1LwPWVbgk X+5N4i+H96M6V3ajZPd7ffgExxmz1bU3lK5VM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rsGGjAMnp/ka3NNMa/K0W02mt4DsfaY9f/tCnYuiSpD8LulKFZDEK7435vXoG3SYIv 7S6T0pn1ZvHi6FdcxPlWXCTFjnMHOl09ANQ2xKUXUZzFQZD0qLw8tt3xkIUabd+Yh5B0 e4HBqEMRFCjLl4un/OQjzlhNR56LmcCj1S+uo= Received: by 10.223.20.210 with SMTP id g18mr1962632fab.30.1308280868936; Thu, 16 Jun 2011 20:21:08 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id o23sm1106874faa.9.2011.06.16.20.21.07 (version=SSLv3 cipher=OTHER); Thu, 16 Jun 2011 20:21:07 -0700 (PDT) Message-ID: <4DFAC852.4090806@gmail.com> Date: Fri, 17 Jun 2011 06:21:54 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Frank Ellermann References: <4D4FD50E.2020503@it.aoyama.ac.jp> <4D83B681.60906@isode.com> <4DF8CEB9.9030108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "uri-review@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] apps-team review of draft-holsten-about-uri-scheme-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2011 03:21:10 -0000 15.06.2011 19:23, Frank Ellermann wrote: > Back in January I sent a comment to the authors of this good > I-D, but I guess that mail never made it. Just in case, because it's > apparently still not *too* late, I add the content below. > ---------------------------------------------------------------- > Hi, I like your "about" Internet-Draft. If you are not already > in Last Call a simple suggestion: > > You offer well-known examples such as about:plugins and about:mozilla. > One thing users often have to fight with is to > FIND relevant about: URIs for their UA. Sometimes > about:about is used to display a list of relevant about: URIs. > > If you would add about:about as example this will encourage > developers to support it in their product. I think this will be considered. Mykyta > _______________________________________________ > Uri-review mailing list > Uri-review@ietf.org > https://www.ietf.org/mailman/listinfo/uri-review > From barryleiba.mailing.lists@gmail.com Thu Jun 16 20:41:15 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA0011E80E8; Thu, 16 Jun 2011 20:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.904 X-Spam-Level: X-Spam-Status: No, score=-102.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFAS4XTtRsqj; Thu, 16 Jun 2011 20:41:14 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 845FA11E80DC; Thu, 16 Jun 2011 20:41:14 -0700 (PDT) Received: by gyf3 with SMTP id 3so952985gyf.31 for ; Thu, 16 Jun 2011 20:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wgn7wIVBXv2GXZRO0FfrE3tDAWoFf0DBJ7p91VqO/1E=; b=iWy1GtfTTSXH5iLAzZif7VHXnb1hgRWVt5Pgust1QUrqbTMIoI9BCJ7bj2VMcl/uIv 4a3rUx63dNphHXz0LbpGHjjkRMWWPRjVqzNcdywjPYb95EZ/3Je0zFzB7dx5ZlnurVUH EA39FsYcO8Y1zcbdPgabPA89u7aGdci2KPYp4= 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=bsL9hLrH+iwbo1OLs7fYdlSkXQxqoLwWBP5EDUsqz0V3llgZjSD14UWoit44iD181M WzEar0mcc9TqDpINTJ5cRRFvFwlSuHSXHRzVXzKjaGLm/Xfm6SF1NzSc+2F2BFFLys9w JN1n7mJS42Na9KXl7zH9LDPNPzhN0DxgtK7QA= MIME-Version: 1.0 Received: by 10.236.80.69 with SMTP id j45mr2767196yhe.50.1308282073930; Thu, 16 Jun 2011 20:41:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.99.3 with HTTP; Thu, 16 Jun 2011 20:41:13 -0700 (PDT) In-Reply-To: <4DFAC83A.6010208@gmail.com> References: <20110616130400.4851.68985.idtracker@ietfa.amsl.com> <4DFAC83A.6010208@gmail.com> Date: Thu, 16 Jun 2011 23:41:13 -0400 X-Google-Sender-Auth: ytg7NALuHkKPawrQ5lZGcFHkqVQ Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: ietf@ietf.org, iesg Subject: Re: [apps-discuss] Last Call: (Terminology Used in Internationalization in the IETF) to BCP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2011 03:41:15 -0000 On Thu, Jun 16, 2011 at 11:21 PM, Mykyta Yevstifeyev wrote: > I have an only concern with regard to this document which I expressed > before, during WG discussions, and which I'd like to bring to IESG's > attention now. > > For a number of times I proposed improving the "control character" > definition in Section 4.1: And in the WG discussions, Mykyta was in the rough when it came to a consensus judgment. I, as chair and doc shepherd, actually supported some change initially, but was convinced that the final text that's in the document is best. The document isn't meant to be a history lesson, but to make it clear what certain terms refer to. The current "control character" text accomplishes that, and there's been no support for Mykyta's suggested change. Barry, appsawg chair From mnot@mnot.net Fri Jun 17 13:45:17 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3D19E8051 for ; Fri, 17 Jun 2011 13:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cli5mmRUS4PZ for ; Fri, 17 Jun 2011 13:45:16 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 150E89E8033 for ; Fri, 17 Jun 2011 13:45:16 -0700 (PDT) Received: from [10.6.121.164] (unknown [64.39.4.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 852DF22E25D for ; Fri, 17 Jun 2011 16:45:09 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jun 2011 13:45:09 -0700 Message-Id: To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [apps-discuss] Last Call for HTML5 in the W3C X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2011 20:45:17 -0000 [ with my IETF/W3C Liaison hat on ] The W3C has announced a Last Call on the HTML5 specification; see: http://www.w3.org/2011/02/htmlwg-pr.html The IETF has been encouraged to provide feedback, especially regarding = HTML's use of and interface with IETF technologies. For background on Last Call in their process, see: http://www.w3.org/2005/10/Process-20051014/tr.html#last-call and the specification itself: http://www.w3.org/TR/html5/ paying special attention to the 'status of this document' section for = information about the Last Call and how to provide feedback. See also their LC FAQ: http://www.w3.org/2011/05/html5lc-faq.html Cheers, -- Mark Nottingham http://www.mnot.net/ From dzonatas@gmail.com Fri Jun 17 15:11:15 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BC411E8130 for ; Fri, 17 Jun 2011 15:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.408 X-Spam-Level: X-Spam-Status: No, score=-5.408 tagged_above=-999 required=5 tests=[AWL=-1.809, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fg3BbfN8rpq for ; Fri, 17 Jun 2011 15:11:14 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7DB11E812F for ; Fri, 17 Jun 2011 15:11:14 -0700 (PDT) Received: by pzk5 with SMTP id 5so2416724pzk.31 for ; Fri, 17 Jun 2011 15:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bE8Ds6Y0+LEwJCE9aMlp04IpYks4q3XHoP7711t4TP8=; b=oeHL3Qg1ptR9s3IgbshAwEnVAdDtfL6jhI7KH5CehUguAYhOpm8g/nY1cx5PvWUaci WAsFk9afk4v30+Y6WwNfw87ePgP0IGjtpPdI0MBgSt9zLaT9nkD7vO5981OnpWzThMae x9JRHb2JBq0Kp5+4wEZYRqi1Gk/pMRi8+ZfoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=CnluZU66JRegAJBZtFGKIip4zSX3HrShywAvSOkgfDVlK+0LoT4AVQyLfE4tukcF2B BV9w8gp2NyraWoDFL+di+QI2Aguouc9KExtHUAl+6M9q6J6Eo5kRvqFXfu2Jt8QkJ0++ hIqoIsoOwKiXS0eFPNm3+p1NDk9S4LGWjxA9k= Received: by 10.143.20.20 with SMTP id x20mr383494wfi.131.1308348674121; Fri, 17 Jun 2011 15:11:14 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id p5sm1701988pbk.36.2011.06.17.15.11.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Jun 2011 15:11:13 -0700 (PDT) Message-ID: <4DFBD0C5.50208@gmail.com> Date: Fri, 17 Jun 2011 15:10:13 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Last Call for HTML5 in the W3C X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2011 22:11:15 -0000 That is the API perspective. That would also make the ABI perspective regard HTTP status codes 200, 201, 202, and 203 as standard input, output, error, and one bit "control flow" where TLS does not exist in SI/SO modes. Note that "network order" considers top three bits, yet that is not clear about top three of each byte or the thee most significant bits of the last byte. That standard creates this kind of mask: 100000001000000011111000 Can we just default something like the OAuth MAC header to that code to signify that mask is known? Then, check /.well-known/ for that bitstream? We can then determine the queue direction. On 06/17/2011 01:45 PM, Mark Nottingham wrote: > [ with my IETF/W3C Liaison hat on ] > > The W3C has announced a Last Call on the HTML5 specification; see: > http://www.w3.org/2011/02/htmlwg-pr.html > > The IETF has been encouraged to provide feedback, especially regarding HTML's use of and interface with IETF technologies. > > For background on Last Call in their process, see: > http://www.w3.org/2005/10/Process-20051014/tr.html#last-call > > and the specification itself: > http://www.w3.org/TR/html5/ > paying special attention to the 'status of this document' section for information about the Last Call and how to provide feedback. > > See also their LC FAQ: > http://www.w3.org/2011/05/html5lc-faq.html > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From evnikita2@gmail.com Fri Jun 17 21:44:31 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EB911E810C for ; Fri, 17 Jun 2011 21:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRGFtyHg3Qq1 for ; Fri, 17 Jun 2011 21:44:30 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4755311E80E8 for ; Fri, 17 Jun 2011 21:44:29 -0700 (PDT) Received: by fxm15 with SMTP id 15so211263fxm.31 for ; Fri, 17 Jun 2011 21:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=LbWh6TTzq9WCAPNbVr8se4Th183R/B5Yse1oD5VvLAk=; b=siLFbiwk+UqUzVl/obrVyRmZ1qUPpeY8ECdSiK5ICqFRd7uutaZBMMgRpCNsHKQe7t mAc+ZjfE2Xn0Suv6mGrlFU246V1rpKzxMRq+/PJjSA99zZGkG3o3D/JJhnDAXYiDSzFZ PhPXmDsFuXmM/Wf6U5UUfsyMliZOKE5/Yem54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=rfAgK382gb6wwnb9IlTGc+cXPjKEQIlM7meEZQVfPv9S8z14Xb97qH/7yna5ir48lt lQS3SSlUTKBBLd8llsMe5hPcEwoCIDf1vXhQv2JbF1rWenuklrcfiTTi0BUSep9YOl8N MA/oZ8QG1NCOkP/ggJrO63ToAd5wf3YPL5lLE= Received: by 10.223.92.146 with SMTP id r18mr3286678fam.135.1308372267624; Fri, 17 Jun 2011 21:44:27 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id m26sm1638699fab.10.2011.06.17.21.44.25 (version=SSLv3 cipher=OTHER); Fri, 17 Jun 2011 21:44:26 -0700 (PDT) Message-ID: <4DFC2D58.6020502@gmail.com> Date: Sat, 18 Jun 2011 07:45:12 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090208090502060100090103" Subject: Re: [apps-discuss] Last Call for HTML5 in the W3C X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2011 04:44:31 -0000 This is a multi-part message in MIME format. --------------090208090502060100090103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I see the proposed HTML5 specification has the following text (Section 2.6.1): > This specification defines the URL |about:legacy-compat| as a > reserved, though unresolvable, |about:| URI, for use in DOCTYPE > s in HTML > documents > when needed for compatibility with XML tools. [ABOUT] > > > This specification defines the URL |about:srcdoc| as a reserved, > though unresolvable, |about:| URI, that is used as the document's > address > of > |iframe| |srcdoc| documents > . [ABOUT] > > Moreover, the [ABOUT] references the well-known draft-holsten-about-uri-scheme which we have had a lot of discussions on. Considering that there isn't a strong decision on this draft, I'd recommend W3C not to include this text in the proposed document. Mentioning that "about:legacy-compat" is to be used for a specific purpose in Section 8.1.1 (the same is with "about:srcdoc") seems fine to me. Probably the same is with 'javascript' URIs (Section 6.1.5). It references [JSURL], the draft-hoehrmann-javascript-scheme, which is now expired. It includes-by-reference the source code retrieval operation for these URIs (http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03#section-3.1). I propose not to include it by reference but rather describe in the specification itself. The algorithm contains only 4 steps so it shouldn't be a problem. An editorial comment. I see the document using such terms as "mailto: URL", "data: URL", "javascript: URL" etc. An example is (Section 2.1.1): > The term |data:| URL refers to URLs > that use the |data:| > scheme. Considering the string before "URL" identifies the scheme, I'd recommend not to include ":" (colon) their, since this character isn't a part of the scheme name (but rather a delimiter). Having "scheme URL" or " 'scheme' URL " (I personally prefer the last) is OK. With regard to references. The [MAILTO] references the document which was obsoleted by RFC 6068. [COOKIES] has become RFC 6265 (the link should be fixed). References to Internet-Drafts should be given as "Work in Progress" per RFC 2026. Probably Section 2.6, as well as some other URI-related stuff, can be interested for some people on uri@w3.org list so I'll forward the LC announcement there to encourage their feedback. All the best, Mykyta Yevstifeyev 17.06.2011 23:45, Mark Nottingham wrote: > [ with my IETF/W3C Liaison hat on ] > > The W3C has announced a Last Call on the HTML5 specification; see: > http://www.w3.org/2011/02/htmlwg-pr.html > > The IETF has been encouraged to provide feedback, especially regarding HTML's use of and interface with IETF technologies. > > For background on Last Call in their process, see: > http://www.w3.org/2005/10/Process-20051014/tr.html#last-call > > and the specification itself: > http://www.w3.org/TR/html5/ > paying special attention to the 'status of this document' section for information about the Last Call and how to provide feedback. > > See also their LC FAQ: > http://www.w3.org/2011/05/html5lc-faq.html > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --------------090208090502060100090103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello,

I see the proposed HTML5 specification has the following text (Section 2.6.1):

This specification defines the URL about:legacy-compat as a reserved, though unresolvable, about: URI, for use in DOCTYPEs in HTML documents when needed for compatibility with XML tools. [ABOUT]

This specification defines the URL about:srcdoc as a reserved, though unresolvable, about: URI, that is used as the document's address of iframe srcdoc documents. [ABOUT]

Moreover, the [ABOUT] references the well-known draft-holsten-about-uri-scheme which we have had a lot of discussions on.  Considering that there isn't a strong decision on this draft, I'd recommend W3C not to include this text in the proposed document.  Mentioning that "about:legacy-compat" is to be used for a specific purpose in Section 8.1.1 (the same is with "about:srcdoc") seems fine to me.

Probably the same is with 'javascript' URIs (Section 6.1.5).  It references [JSURL], the draft-hoehrmann-javascript-scheme, which is now expired.  It includes-by-reference the source code retrieval operation for these URIs (http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03#section-3.1).  I propose not to include it by reference but rather describe in the specification itself.  The algorithm contains only 4 steps so it shouldn't be a problem.

An editorial comment.  I see the document using such terms as "mailto: URL", "data: URL", "javascript: URL" etc.  An example is (Section 2.1.1):

The term data: URL refers to URLs that use the data: scheme.
Considering the string before "URL" identifies the scheme, I'd recommend not to include ":" (colon) their, since this character isn't a part of the scheme name (but rather a delimiter).  Having "scheme URL" or " 'scheme' URL " (I personally prefer the last) is OK.

With regard to references.  The [MAILTO] references the document which was obsoleted by RFC 6068.  [COOKIES] has become RFC 6265 (the link should be fixed).  References to Internet-Drafts should be given as "Work in Progress" per RFC 2026.

Probably Section 2.6, as well as some other URI-related stuff, can be interested for some people on uri@w3.org list so I'll forward the LC announcement there to encourage their feedback.

All the best,
Mykyta Yevstifeyev

17.06.2011 23:45, Mark Nottingham wrote: 
[ with my IETF/W3C Liaison hat on ]

The W3C has announced a Last Call on the HTML5 specification; see:
 http://www.w3.org/2011/02/htmlwg-pr.html

The IETF has been encouraged to provide feedback, especially regarding HTML's use of and interface with IETF technologies.

For background on Last Call in their process, see:
 http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

and the specification itself:
 http://www.w3.org/TR/html5/
paying special attention to the 'status of this document' section for information about the Last Call and how to provide feedback.

See also their LC FAQ:
 http://www.w3.org/2011/05/html5lc-faq.html

Cheers,

--
Mark Nottingham   http://www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--------------090208090502060100090103-- From mnot@mnot.net Sat Jun 18 11:52:40 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF7111E81F4 for ; Sat, 18 Jun 2011 11:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcQXunKFbDOU for ; Sat, 18 Jun 2011 11:52:40 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id E548311E80E0 for ; Sat, 18 Jun 2011 11:52:39 -0700 (PDT) Received: from [192.168.33.96] (unknown [66.140.241.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 40A38509E2; Sat, 18 Jun 2011 14:52:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4DFC2D58.6020502@gmail.com> Date: Sat, 18 Jun 2011 11:52:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89D4EFA7-4F77-4886-B838-2C987BB7A8B6@mnot.net> References: <4DFC2D58.6020502@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1084) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call for HTML5 in the W3C X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2011 18:52:40 -0000 Mykyta, Just to make sure it's clear -- while it's fine to discuss things here = to see if other IETFers agree, if you want your feedback to be noticed = by the HTML WG, you'll need to submit it to them using the procedures = they outline in the document.=20 I've already forwarded the announcement to the IRI list, FWIW. Cheers, On 17/06/2011, at 9:45 PM, Mykyta Yevstifeyev wrote: > Hello, >=20 > I see the proposed HTML5 specification has the following text (Section = 2.6.1): >=20 >> This specification defines the URL about:legacy-compat as a reserved, = though unresolvable, about: URI, for use in DOCTYPEs in HTML documents = when needed for compatibility with XML tools. [ABOUT] >>=20 >> This specification defines the URL about:srcdoc as a reserved, though = unresolvable, about: URI, that is used as the document's address of = iframe srcdoc documents. [ABOUT] >>=20 > Moreover, the [ABOUT] references the well-known = draft-holsten-about-uri-scheme which we have had a lot of discussions = on. Considering that there isn't a strong decision on this draft, I'd = recommend W3C not to include this text in the proposed document. = Mentioning that "about:legacy-compat" is to be used for a specific = purpose in Section 8.1.1 (the same is with "about:srcdoc") seems fine to = me. >=20 > Probably the same is with 'javascript' URIs (Section 6.1.5). It = references [JSURL], the draft-hoehrmann-javascript-scheme, which is now = expired. It includes-by-reference the source code retrieval operation = for these URIs = (http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03#section-3= .1). I propose not to include it by reference but rather describe in = the specification itself. The algorithm contains only 4 steps so it = shouldn't be a problem. >=20 > An editorial comment. I see the document using such terms as "mailto: = URL", "data: URL", "javascript: URL" etc. An example is (Section = 2.1.1): >=20 >> The term data: URL refers to URLs that use the data: scheme. > Considering the string before "URL" identifies the scheme, I'd = recommend not to include ":" (colon) their, since this character isn't a = part of the scheme name (but rather a delimiter). Having "scheme URL" = or " 'scheme' URL " (I personally prefer the last) is OK. >=20 > With regard to references. The [MAILTO] references the document which = was obsoleted by RFC 6068. [COOKIES] has become RFC 6265 (the link = should be fixed). References to Internet-Drafts should be given as = "Work in Progress" per RFC 2026. >=20 > Probably Section 2.6, as well as some other URI-related stuff, can be = interested for some people on uri@w3.org list so I'll forward the LC = announcement there to encourage their feedback. >=20 > All the best, > Mykyta Yevstifeyev=20 >=20 > 17.06.2011 23:45, Mark Nottingham wrote: >> [ with my IETF/W3C Liaison hat on ] >>=20 >> The W3C has announced a Last Call on the HTML5 specification; see: >> =20 >> http://www.w3.org/2011/02/htmlwg-pr.html >>=20 >>=20 >> The IETF has been encouraged to provide feedback, especially = regarding HTML's use of and interface with IETF technologies. >>=20 >> For background on Last Call in their process, see: >> =20 >> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call >>=20 >>=20 >> and the specification itself: >> =20 >> http://www.w3.org/TR/html5/ >>=20 >> paying special attention to the 'status of this document' section for = information about the Last Call and how to provide feedback. >>=20 >> See also their LC FAQ: >> =20 >> http://www.w3.org/2011/05/html5lc-faq.html >>=20 >>=20 >> Cheers, >>=20 >> -- >> Mark Nottingham =20 >> http://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >>=20 >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >>=20 >>=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From evnikita2@gmail.com Sat Jun 18 21:05:45 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7ECE11E80BB for ; Sat, 18 Jun 2011 21:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-BartZN6vUL for ; Sat, 18 Jun 2011 21:05:44 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05F5E11E80EF for ; Sat, 18 Jun 2011 21:05:43 -0700 (PDT) Received: by fxm15 with SMTP id 15so570097fxm.31 for ; Sat, 18 Jun 2011 21:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zWlfvdvQT3KHLQ0MM7MEV3YrqkNrR0yuOlo1SP1aUBM=; b=X/0eVCUY2L5K14vvD2JjtimPwgoe2yTrxPqnz/yax5dRA62HhFeyjCuRdeiR67e8cK ZrM6JsXcTn3SyTh1LS28T191oNOl7rwtu6b4hWl2u77rcz7hNoza5975foAEXkavLFNr HeAKa7iawgm6FDt2IeK+ZVXyySEvjY5eKNUmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WQO1AO06GRxS0EMou7MU+ZoDz71kS+AOBCf9Ir6wF4VEIEeitO+W6mHqGuBWQ/wVBg VlME5ddnHnkp5AKuLZQe5f8PU3EKEYrbiuQU+6tu323DfTpgxPmZztuJLMwFWBjT3LI5 amR+DiSuUjlTiCPVlCqisFAxDsJnFF6lx1duc= Received: by 10.223.20.210 with SMTP id g18mr4324132fab.30.1308456343097; Sat, 18 Jun 2011 21:05:43 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id l26sm2085855fah.14.2011.06.18.21.05.39 (version=SSLv3 cipher=OTHER); Sat, 18 Jun 2011 21:05:39 -0700 (PDT) Message-ID: <4DFD75C1.6090900@gmail.com> Date: Sun, 19 Jun 2011 07:06:25 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Nottingham References: <4DFC2D58.6020502@gmail.com> <89D4EFA7-4F77-4886-B838-2C987BB7A8B6@mnot.net> In-Reply-To: <89D4EFA7-4F77-4886-B838-2C987BB7A8B6@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call for HTML5 in the W3C X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2011 04:05:46 -0000 18.06.2011 21:52, Mark Nottingham wrote: > Mykyta, > > Just to make sure it's clear -- while it's fine to discuss things here to see if other IETFers agree, if you want your feedback to be noticed by the HTML WG, you'll need to submit it to them using the procedures they outline in the document. Mark, I've already copied the message to public-html-comments@w3.org: http://lists.w3.org/Archives/Public/public-html-comments/2011Jun/0034.html. The appropriate database entry was already created: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12986; it was forwarded to public-html@w3c.org list: http://lists.w3.org/Archives/Public/public-html/2011Jun/0250.html. Mykyta > I've already forwarded the announcement to the IRI list, FWIW. > > Cheers, > > > > On 17/06/2011, at 9:45 PM, Mykyta Yevstifeyev wrote: > >> Hello, >> >> I see the proposed HTML5 specification has the following text (Section 2.6.1): >> >>> This specification defines the URL about:legacy-compat as a reserved, though unresolvable, about: URI, for use in DOCTYPEs in HTML documents when needed for compatibility with XML tools. [ABOUT] >>> >>> This specification defines the URL about:srcdoc as a reserved, though unresolvable, about: URI, that is used as the document's address of iframe srcdoc documents. [ABOUT] >>> >> Moreover, the [ABOUT] references the well-known draft-holsten-about-uri-scheme which we have had a lot of discussions on. Considering that there isn't a strong decision on this draft, I'd recommend W3C not to include this text in the proposed document. Mentioning that "about:legacy-compat" is to be used for a specific purpose in Section 8.1.1 (the same is with "about:srcdoc") seems fine to me. >> >> Probably the same is with 'javascript' URIs (Section 6.1.5). It references [JSURL], the draft-hoehrmann-javascript-scheme, which is now expired. It includes-by-reference the source code retrieval operation for these URIs (http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03#section-3.1). I propose not to include it by reference but rather describe in the specification itself. The algorithm contains only 4 steps so it shouldn't be a problem. >> >> An editorial comment. I see the document using such terms as "mailto: URL", "data: URL", "javascript: URL" etc. An example is (Section 2.1.1): >> >>> The term data: URL refers to URLs that use the data: scheme. >> Considering the string before "URL" identifies the scheme, I'd recommend not to include ":" (colon) their, since this character isn't a part of the scheme name (but rather a delimiter). Having "scheme URL" or " 'scheme' URL " (I personally prefer the last) is OK. >> >> With regard to references. The [MAILTO] references the document which was obsoleted by RFC 6068. [COOKIES] has become RFC 6265 (the link should be fixed). References to Internet-Drafts should be given as "Work in Progress" per RFC 2026. >> >> Probably Section 2.6, as well as some other URI-related stuff, can be interested for some people on uri@w3.org list so I'll forward the LC announcement there to encourage their feedback. >> >> All the best, >> Mykyta Yevstifeyev >> >> 17.06.2011 23:45, Mark Nottingham wrote: >>> [ with my IETF/W3C Liaison hat on ] >>> >>> The W3C has announced a Last Call on the HTML5 specification; see: >>> >>> http://www.w3.org/2011/02/htmlwg-pr.html >>> >>> >>> The IETF has been encouraged to provide feedback, especially regarding HTML's use of and interface with IETF technologies. >>> >>> For background on Last Call in their process, see: >>> >>> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call >>> >>> >>> and the specification itself: >>> >>> http://www.w3.org/TR/html5/ >>> >>> paying special attention to the 'status of this document' section for information about the Last Call and how to provide feedback. >>> >>> See also their LC FAQ: >>> >>> http://www.w3.org/2011/05/html5lc-faq.html >>> >>> >>> Cheers, >>> >>> -- >>> Mark Nottingham >>> http://www.mnot.net/ >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > -- > Mark Nottingham http://www.mnot.net/ > > > > From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Sun Jun 19 13:17:06 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D7611E8084 for ; Sun, 19 Jun 2011 13:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtjPIKKoF+tG for ; Sun, 19 Jun 2011 13:17:05 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD43811E8077 for ; Sun, 19 Jun 2011 13:17:05 -0700 (PDT) Received: by pzk5 with SMTP id 5so3369884pzk.31 for ; Sun, 19 Jun 2011 13:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=eXED9/l3G7LAPjGhFxFbyy6sjuDYgqcNzL1ABfWJ22Q=; b=MNdDY8CxN34RSMmoAK6ZPFrxdIKEMiu/QZWUzifJ2xJ9Qc0CLxPhOVKfFkBVkq4OAr BokvBU0PIG7BxRtbDDE7m/VPwKSlPwm0+HkjmJ10R/WWa5Ec0GFAXh3VEhFZ+DvFG7/h AkSG+Cs9K8T2hXA3D/OsmrJSr0hQ0Njyu6HUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=nYGxZg5fh6lQZtbXbCy5n2OEXKsMkCVV2HOGpbf2zxAMA5YEiMMKVuCE6x7uLcTRzL edU3JeS+KAr25ot1cMa8dg9Hv1Kw3FDThIHnLfp6dWSFjsEsMNysNUBzNjmYR8MopEiK kS4PiFIGSd6rO7/4Y6L74jS+6JcjLMwkHq0FI= Received: by 10.142.226.15 with SMTP id y15mr702956wfg.232.1308514625227; Sun, 19 Jun 2011 13:17:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.156.6 with HTTP; Sun, 19 Jun 2011 13:16:45 -0700 (PDT) In-Reply-To: <4DFC2D58.6020502@gmail.com> References: <4DFC2D58.6020502@gmail.com> From: Frank Ellermann Date: Sun, 19 Jun 2011 22:16:45 +0200 Message-ID: To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call for HTML5 in the W3C X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2011 20:17:06 -0000 On 18 June 2011 06:45, Mykyta Yevstifeyev wrote: > I see the proposed HTML5 specification has the following > text (Section 2.6.1): | This specification defines the URL about:legacy-compat as | a reserved, though unresolvable, about: URI, for use in | DOCTYPEs in HTML documents when needed | for compatibility with XML tools. [ABOUT] Thanks for that note, I vaguely recalled this oddity when I tried to send my about: draft comments to this list, but forgot to mention it. I think this pseudo-URL doesn't do anything apart from filling a slot where a syntactically valid URL is expected. If that's the case I wonder why they don't pick about:blank for this purpose. I'm not hot about it -- I anyway dislike the concepts of no HTML5 DTD and no proper HTML5 DOCTYPE version. > This specification defines the URL about:srcdoc as a > reserved, though unresolvable, about: URI, that is > used as the document's address of iframe srcdoc > documents. [ABOUT] If that is a good idea (I didn't know it and have no time to check it today) independent of HTML5 it should be added to the about: draft. > Moreover, the [ABOUT] references the well-known > draft-holsten-about-uri-scheme which we have had > a lot of discussions on. Well, it should. The about: draft should be an RFC long before HTML5 arrives at its "last last call" in 2012. The WhatWG HTML is no problem, it's a moving target and can be updated whenever the WhatWG folks feel like it. > Probably the same is with 'javascript' URIs (Section 6.1.5). > It references [JSURL], the draft-hoehrmann-javascript- > scheme, which is now expired.=A0 It includes-by-reference > the source code retrieval operation for these URIs > (http://tools.ietf.org/html/draft-hoehrmann-javascript- > scheme-03#section-3.1). I recall an old version of this brave attempt to document javascript: URLs, and various essential points were unclear in the 2006 draft. But now there's a newer draft (expired in March 2011), maybe it's ready before HTML5. > I propose not to include it by reference but rather > describe in the specification itself.=A0 The algorithm > contains only 4 steps so it shouldn't be a problem. If what you want is simple it should better be done in the javascript: URL draft. And as long as the new draft says "you really do not want to do this" at least once per page and subsection I might even like it now. ;-) > The [MAILTO] references the document which was > obsoleted by RFC 6068. [etc.] Yes, but as Mark said that's not the business of the IETF Apps list. Hopefully the W3C HTML5 Last Call FAQ meanwhile manages to identify which of the numerous HTML drafts is the "first last call" version, e.g., giving an immutable URL of this draft would be a good thing in the FAQ. And it should specify where interested users can post comments (without preconditions above a working mail address). From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Sun Jun 19 14:55:45 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1683211E8114 for ; Sun, 19 Jun 2011 14:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.824 X-Spam-Level: X-Spam-Status: No, score=-102.824 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 622+MjWVaSl6 for ; Sun, 19 Jun 2011 14:55:44 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 895F811E80EC for ; Sun, 19 Jun 2011 14:55:44 -0700 (PDT) Received: by pvh18 with SMTP id 18so3458486pvh.31 for ; Sun, 19 Jun 2011 14:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=QmG8VlrxMsEJVvlfTKubwT44BCa8IJMiEdp53SOmCo4=; b=S/lNzR+rhwPO4JvFpLHviitiRciBgpugThVURZDPWNU9OLVGNvx1i+0AEgQ0V/IQWP AcNTKbIWoIAVKxdMHmH+4NBaLiajm08SFW4nnWGZ5X/lAswsktKrtXIe5Tu+C/37wTBY +mMwvUyySZ7ZlIz6HHCj7oKEq6/cLSoWvd6zw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=xCvF7VXIOjPLXKmsoCs7DsiS8O2ONHurD57Hhhx40VP2aDqiMziFECEkPkavNoI2iN VDeKQuPCBQA9SDKEOWRK+Yh2Dpcnd/eqwBddRKreEndoqIm8CioBua3H0xN5XOnv0LtH DV4m45KQPU5V40Mi/fJne+CYh5qX1Umcd+R04= Received: by 10.142.226.15 with SMTP id y15mr710483wfg.232.1308520544258; Sun, 19 Jun 2011 14:55:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.156.6 with HTTP; Sun, 19 Jun 2011 14:55:23 -0700 (PDT) In-Reply-To: <4DFAC83A.6010208@gmail.com> References: <20110616130400.4851.68985.idtracker@ietfa.amsl.com> <4DFAC83A.6010208@gmail.com> From: Frank Ellermann Date: Sun, 19 Jun 2011 23:55:23 +0200 Message-ID: To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Terminology Used in Internationalization in the IETF) to BCP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2011 21:55:45 -0000 On 17 June 2011 05:21, Mykyta Yevstifeyev wrote: > I proposed improving the "control character" definition Let's keep it simple. ECMA 48 5th edition claims that its 4th edition corresponds to ISO 6429:1992, and that there should be a new ISO 6429 based on ECMA 48 5th ed. If that actually happened your proposal to add a non-free ISO 6429:1992 reference could be arguably obsolete. The control codes only mean something in the context of specifications using it, e.g., TUS doesn't use most of the C0 or C1 control codes (adding its own oddities). Wrt i18n ECMA 48 5th ed. could be even interesting, it covers BiDi. But I'd never trust in any BiDi spec. unless it was written by one of the usual suspects (Martin, John, Harald, Paul, etc.) > we're trying to give the terms normative meaning within > IETF, since the intended status is BCP The business with the C0 + C1 terminology is IMO correct in the draft, and explaining what if anything specifc control codes do is out of scope. The "net UTF-8" BCP obsoletes most of these codes, and the i18n terminology draft has a pointer to the "net UTF-8 BCP" (IIRC). > The document makes normative reference to an obsolete > document - ISO/IEC 10646:2003 whereas ISO/IEC > 10646:2011 is published. =A0The reference should be > corrected. Above all it should be the ISO 10646 version corresponding to the referenced TUS version, if you checked that I'd agree. -Frank From evnikita2@gmail.com Mon Jun 20 10:20:27 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8D821F846F for ; Mon, 20 Jun 2011 10:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9qYQIdkrofN for ; Mon, 20 Jun 2011 10:20:26 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC19D21F846E for ; Mon, 20 Jun 2011 10:20:25 -0700 (PDT) Received: by fxm15 with SMTP id 15so1443449fxm.31 for ; Mon, 20 Jun 2011 10:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7Bsp4WaYnIu7/AGJKHSsLfy4jWb2j+3WfnvK/CSZCCM=; b=TmxdqpCUtb1BRC/NjY73eppJ63hXSxejPSKIKIF4yD7QscSzhz+YDJxgQ7TgAdCHnG OSfZPft+8W9MGljWgdengGtS6YmmbaeOBk+QAh50h0OxoLppxLgLsJoBAVSPXDwThRLo vQTRui08ccB9SdhRDye85zP+9T9IZjUjKE8wU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PkKlKCMnewVYUh2u/u4VZHOFen+BBZHs8WB4gqDVyLswFLJTHaKxFCDNCAZREG4zhZ 9wBgd0QoBG5J7CgbAAMbhqNElHcit3H4yBT86o3sPouWARI53J7LnameGqvxgI7/MgWR gPbnK4Z7E7KtzU3n5zre2To/vfImSzc+yfQxQ= Received: by 10.223.17.142 with SMTP id s14mr211807faa.145.1308590424773; Mon, 20 Jun 2011 10:20:24 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id r10sm2935934fah.26.2011.06.20.10.20.22 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 10:20:23 -0700 (PDT) Message-ID: <4DFF8185.9090300@gmail.com> Date: Mon, 20 Jun 2011 20:21:09 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Frank Ellermann References: <20110616130400.4851.68985.idtracker@ietfa.amsl.com> <4DFAC83A.6010208@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Terminology Used in Internationalization in the IETF) to BCP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2011 17:20:27 -0000 20.06.2011 0:55, Frank Ellermann wrote: > On 17 June 2011 05:21, Mykyta Yevstifeyev wrote: > >> I proposed improving the "control character" definition > Let's keep it simple. ECMA 48 5th edition claims that its > 4th edition corresponds to ISO 6429:1992, and that there > should be a new ISO 6429 based on ECMA 48 5th ed. > > If that actually happened your proposal to add a non-free > ISO 6429:1992 reference could be arguably obsolete. > > The control codes only mean something in the context > of specifications using it, e.g., TUS doesn't use most of > the C0 or C1 control codes (adding its own oddities). > > Wrt i18n ECMA 48 5th ed. could be even interesting, it > covers BiDi. But I'd never trust in any BiDi spec. unless > it was written by one of the usual suspects (Martin, John, > Harald, Paul, etc.) My first proposal was to include reference to ISO 6429; yet, it isn't mandatory. Let's produce a simple definition of what is the control character used for. It may be taken from ISO/IEC 10646 as well. I don't think the current text reflects this. >> we're trying to give the terms normative meaning within >> IETF, since the intended status is BCP > The business with the C0 + C1 terminology is IMO correct > in the draft, and explaining what if anything specifc control > codes do is out of scope. See above. Let's not explain what do they mean, but rather what are their overall mission. That's my point. Mykyta > The "net UTF-8" BCP obsoletes > most of these codes, and the i18n terminology draft has a > pointer to the "net UTF-8 BCP" (IIRC). > > > The document makes normative reference to an obsolete >> document - ISO/IEC 10646:2003 whereas ISO/IEC >> 10646:2011 is published. The reference should be >> corrected. > Above all it should be the ISO 10646 version corresponding > to the referenced TUS version, if you checked that I'd agree. > > -Frank > From stpeter@stpeter.im Tue Jun 21 09:41:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35CA11E829F for ; Tue, 21 Jun 2011 09:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uQkCq4KlZoD for ; Tue, 21 Jun 2011 09:41:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 06A8F11E829A for ; Tue, 21 Jun 2011 09:41:10 -0700 (PDT) Received: from dhcp-64-101-72-207.cisco.com (dhcp-64-101-72-207.cisco.com [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5477940126; Tue, 21 Jun 2011 10:41:47 -0600 (MDT) Message-ID: <4E00C9A4.3020106@stpeter.im> Date: Tue, 21 Jun 2011 10:41:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , "ietf-http-wg@w3.org Group" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050107040601000903090702" Subject: [apps-discuss] Fwd: Second Last Call: (Web Host Metadata) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2011 16:41:10 -0000 This is a cryptographically signed message in MIME format. --------------ms050107040601000903090702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI, you still have 8 days to provide feedback on this one. -------- Original Message -------- Subject: Second Last Call: (Web Host Metadata) to Proposed Standard Date: Wed, 01 Jun 2011 14:53:38 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Web Host Metadata' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-29. 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. Abstract This specification describes a method for locating host metadata as well as information about individual resources controlled by the host. Editorial Note (to be removed by RFC Editor) Please discuss this draft on the apps-discuss@ietf.org [1] mailing list. The file can be obtained via http://datatracker.ietf.org/doc/draft-hammer-hostmeta/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-hammer-hostmeta/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------ms050107040601000903090702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYy MTE2NDEwOFowIwYJKoZIhvcNAQkEMRYEFLO4hvZCcmgg++ZQLh8Bf9O52IyEMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCelb9gXLrwbKEAai0MIwpudRGj7cm68/Stbcmv/5Q8DtUcPMXPXuLSxHjR 3abq4kG89pi2LLbAB6gO1uL9epad9ceXnfm2JgZvuN1D7gPbUNv4FWlEIAEVphnenhSC/kRQ MHwAUYzWC32LyFCpqaaq/3LJ59ifMUiF36i6xky+Kq5hKp5oVbZp0Ua9HuRKa2yhhjTJTkM/ r4NMNChS9/4E2uD3jAPfnI3jwqEIYD/5eWAvPqXKNkEPp0039qoo7164E+pq8ISKHigm9N7k NMMRcSkI2CbI/Ic7waWSWDshLwZy+XICRkdqfdkC7M8i0uxh9zrvz7Xa7bDkzf969SEjAAAA AAAA --------------ms050107040601000903090702-- From evnikita2@gmail.com Tue Jun 21 21:11:48 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B561E21F845F for ; Tue, 21 Jun 2011 21:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1dLFeRxgiEE for ; Tue, 21 Jun 2011 21:11:47 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F43321F845B for ; Tue, 21 Jun 2011 21:11:47 -0700 (PDT) Received: by fxm15 with SMTP id 15so387982fxm.31 for ; Tue, 21 Jun 2011 21:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iFZq0RQCRu4mh9QjioAHEWsXYidfuu3KDRgNSAnmHsQ=; b=S3CS3cEDTXHySiPz8ZAGdqL89CXPEKnTN09Yt32HmMekHgE2meVHlyRRPA9PoFMBHg 4Pmt40N+x6YcvL9/qcnjrhx0+P/I+NPMQBrvrTvN+4t45nOj0JIG+In9iDT4lrox8slW 0SYaJY8x7b40Amr2xq6oqGTVlKrZJjkgDSJ4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bafmBZlLp/Qim1Ry2zD1gAqRx6bXt6Pvi5EG68+mZKp82l2s67XXziiX2zLL7Yk2cT 05e4fdnUJbKRZ8g6KoyTegHyf0INJM9odM+hlgQBVAc0lwmq53G0ntfumRI48zHMZ5Tk /A5+IUBzMqM2f1NJWwUyRo/6JMpzK3lkDVdgs= Received: by 10.223.83.194 with SMTP id g2mr213419fal.133.1308715906588; Tue, 21 Jun 2011 21:11:46 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id g7sm67711fac.39.2011.06.21.21.11.44 (version=SSLv3 cipher=OTHER); Tue, 21 Jun 2011 21:11:45 -0700 (PDT) Message-ID: <4E016BAF.5050000@gmail.com> Date: Wed, 22 Jun 2011 07:12:31 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Frank Ellermann References: <4DFC2D58.6020502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call for HTML5 in the W3C X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2011 04:11:48 -0000 19.06.2011 23:16, Frank Ellermann wrote: > On 18 June 2011 06:45, Mykyta Yevstifeyev wrote: > > [ . . . ] >> This specification defines the URLabout:srcdoc as a >> reserved, though unresolvable, about: URI, that is >> used as the document's address of iframe srcdoc >> documents. [ABOUT] > If that is a good idea (I didn't know it and have no time > to check it today) independent of HTML5 it should be > added to the about: draft. We discussed the idea to add these two about URIs in the draft and decided not to do this and leave reservation to the HTML5 itself. >> Moreover, the [ABOUT] references the well-known >> draft-holsten-about-uri-scheme which we have had >> a lot of discussions on. > Well, it should. The about: draft should be an RFC long > before HTML5 arrives at its "last last call" in 2012. The > WhatWG HTML is no problem, it's a moving target and > can be updated whenever the WhatWG folks feel like it. We haven't currently reached a consensus whether to create or not the possibility to reserve the about URI tokens, as far as you know. It's better for HTML5 to mention the above URIs as "used for a specific purpose" and later, if about URI draft progresses with the above possibility, they may be included by reference. >> Probably the same is with 'javascript' URIs (Section 6.1.5). >> It references [JSURL], the draft-hoehrmann-javascript- >> scheme, which is now expired. It includes-by-reference >> the source code retrieval operation for these URIs >> (http://tools.ietf.org/html/draft-hoehrmann-javascript- >> scheme-03#section-3.1). > I recall an old version of this brave attempt to document > javascript: URLs, and various essential points were > unclear in the 2006 draft. But now there's a newer draft > (expired in March 2011), maybe it's ready before HTML5. The draft is currently expired. If Bjoern is ready to reopen work on it, then this shouldn't be a problem. >> I propose not to include it by reference but rather >> describe in the specification itself. The algorithm >> contains only 4 steps so it shouldn't be a problem. > If what you want is simple it should better be done in the > javascript: URL draft. That draft isn't going to progress, as I see; see below. > And as long as the new draft says > "you really do not want to do this" at least once per page > and subsection I might even like it now. ;-) Best, Mykyta Yevstifeyev >> The [MAILTO] references the document which was >> obsoleted by RFC 6068. > [etc.] > > Yes, but as Mark said that's not the business of the IETF > Apps list. Hopefully the W3C HTML5 Last Call FAQ > meanwhile manages to identify which of the numerous > HTML drafts is the "first last call" version, e.g., giving an > immutable URL of this draft would be a good thing in the > FAQ. And it should specify where interested users can > post comments (without preconditions above a working > mail address). > From liang.liang12@zte.com.cn Fri Jun 24 02:34:17 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58A011E80B5 for ; Fri, 24 Jun 2011 02:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDNUke0ppCxP for ; Fri, 24 Jun 2011 02:34:17 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 60BBD11E8092 for ; Fri, 24 Jun 2011 02:34:16 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48641193944097; Fri, 24 Jun 2011 17:32:14 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 67779.1193944097; Fri, 24 Jun 2011 17:33:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5O9Y07d065716 for ; Fri, 24 Jun 2011 17:34:00 +0800 (GMT-8) (envelope-from liang.liang12@zte.com.cn) To: apps-discuss@ietf.org MIME-Version: 1.0 X-KeepSent: 82FB4301:B91311DF-482578B9:0033AFFE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.liang12@zte.com.cn Date: Fri, 24 Jun 2011 17:33:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-24 17:34:02, Serialize complete at 2011-06-24 17:34:02 Content-Type: multipart/alternative; boundary="=_alternative 00348AEA482578B9_=" X-MAIL: mse02.zte.com.cn p5O9Y07d065716 Subject: [apps-discuss] Two VDI(Virtual Desktop Infrastructure) related drafts submitted in appsawg for your comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 09:34:17 -0000 This is a multipart message in MIME format. --=_alternative 00348AEA482578B9_= Content-Type: text/plain; charset="US-ASCII" Dear All, We submitted two drafts to appsawg on this May, but at that time there were some problems with IETF online submission tools and no auto-generated emails were sent out. Now I'm sending them out manually. Following is the details: 1st Draft: draft-wang-appsawg-vdi-problem-statement-00.txt This document summarizes the limitations of existing virtual desktop systems, and proposes the intent standardization work in IETF. URL for this draft: http://datatracker.ietf.org/doc/draft-wang-appsawg-vdi-problem-statement/ 2nd Draft: Survey of Virtual Desktop Infrastructure System This document presents a survey of VDI (Virtual Desktop Infrastructure) system, including different product arch. and VDI protocols. URL for this draft: http://datatracker.ietf.org/doc/draft-ma-appsawg-vdi-survey/ Welcome your comments! Thanks, Liang -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00348AEA482578B9_= Content-Type: text/html; charset="US-ASCII"
Dear All,

We submitted two drafts to appsawg on this May, but at that time there were some
problems with IETF online submission tools and no auto-generated emails were sent
out. Now I'm sending them out manually. Following is the details:

1st Draft: draft-wang-appsawg-vdi-problem-statement-00.txt  
   This document summarizes the limitations of existing virtual desktop systems,
   and proposes the intent standardization work in IETF.
URL for this draft:
http://datatracker.ietf.org/doc/draft-wang-appsawg-vdi-problem-statement/
   
2nd Draft: Survey of Virtual Desktop Infrastructure System
   This document presents a survey of VDI (Virtual Desktop
   Infrastructure) system, including different product arch.
   and VDI protocols.
URL for this draft:
http://datatracker.ietf.org/doc/draft-ma-appsawg-vdi-survey/

Welcome your comments!

Thanks,
Liang
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00348AEA482578B9_=-- From barryleiba.mailing.lists@gmail.com Fri Jun 24 06:59:43 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EC111E80A1 for ; Fri, 24 Jun 2011 06:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.63 X-Spam-Level: X-Spam-Status: No, score=-102.63 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1dEG-IPsfee for ; Fri, 24 Jun 2011 06:59:42 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC4411E8076 for ; Fri, 24 Jun 2011 06:59:42 -0700 (PDT) Received: by ywp31 with SMTP id 31so1675618ywp.31 for ; Fri, 24 Jun 2011 06:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bqPAxR3+SEIqjhd8avu09J+ODp+5v+c1jmCCs4Why28=; b=EGPS0rbch+rSCGYJNMYkTLwXClyeXn52k7DZCZVUQcsMvWYC/2hewP6wlBvxF8GJgK 6aiq4eZPmLiagDZKI/4KTeBhijyJZ/I2bMsYETpJJKBfUJ4x/Ww42Cq7ZSgfsqg06JFl DvGRdrFVUUBkrQq5HhRaGExYI/pD3vQ9AIL7c= 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:content-type :content-transfer-encoding; b=cM1/6gK/Xi8dkGO5aceSO4Rrsph2sd8lcIJF9BsaHW3C7W5YcsaKu06Vw7yiSz2dmT 5iUhjJezW1BoZlkF3KCpN0gf6RLmuTFZp/GfKI06ellEIfZajnn5UwE3eI1DDaRx4IiL caMJ+6KR5GttUxG2a7PljdRmGTwgjm98PBumU= MIME-Version: 1.0 Received: by 10.146.28.25 with SMTP id b25mr3623368yab.0.1308923981587; Fri, 24 Jun 2011 06:59:41 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.170.15 with HTTP; Fri, 24 Jun 2011 06:59:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Jun 2011 09:59:41 -0400 X-Google-Sender-Auth: TtnKHHVISkAOMg9Vf8r6SG_bc2o Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Two VDI(Virtual Desktop Infrastructure) related drafts submitted in appsawg for your comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 13:59:43 -0000 On Fri, Jun 24, 2011 at 5:33 AM, wrote: > 1st Draft: draft-wang-appsawg-vdi-problem-statement-00.txt > =A0 =A0This document summarizes the limitations of existing virtual deskt= op > systems, > =A0 =A0and proposes the intent standardization work in IETF. > URL for this draft: > http://datatracker.ietf.org/doc/draft-wang-appsawg-vdi-problem-statement/ > > 2nd Draft: Survey of Virtual Desktop Infrastructure System > =A0 =A0This document presents a survey of VDI (Virtual Desktop > =A0 =A0Infrastructure) system, including different product arch. > =A0 =A0and VDI protocols. > URL for this draft: > http://datatracker.ietf.org/doc/draft-ma-appsawg-vdi-survey/ I want to point out here that, while the authors have given the documents filenames with "appsawg" in them, these are not appsawg documents, and they are not under consideration as appsawg documents. The naming is fine, and it allows you to see them as "related" documents on the appsawg tools page ( http://trac.tools.ietf.org/wg/appsawg/ ). How they will proceed, if there is consensus to proceed with them, is entirely undecided. Of course, we do encourage Applications Area participants to review and comment on the documents, and this list is a fine place to do that until something changes. Barry, appsawg chair From evnikita2@gmail.com Fri Jun 24 10:03:28 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0F311E80B2 for ; Fri, 24 Jun 2011 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zJdnwq9VgN3 for ; Fri, 24 Jun 2011 10:03:27 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7097711E809B for ; Fri, 24 Jun 2011 10:03:27 -0700 (PDT) Received: by fxm15 with SMTP id 15so2271292fxm.31 for ; Fri, 24 Jun 2011 10:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=YLDhSY9WGtf+hpprB4ou88y/gywmmqRyw1lICqCUSlY=; b=vE4KBBzUaDeLYLsDoqVnEZSXVPKdNvZe0lvJewhwp5EvMYOjCajB0gno5hNfGycV+O GigwYcFMVxSww1DwCprWGsG/BZ8ejYf/BvxpLv0SRtPG7U3OTAn7ALz3+dwYpdsW/gpd N6OF9UqeH6DQ19Tz6Q1tIeCAfBrXqVdAral5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=ctRAQ1+F+G5OWUAT8yrCGUXwNa0MfBJit9F0rAGVBUctgSNYicITsFWMiGRbvPwuVP QfSd24wAC5KGOmRyFytO9aBdyeCG08WgcUn1DOUSbuFkIgKX8QBReSJEAwjA8HkLQThE qAYnlM9caz8WyWPzr0t+ODwiVuKy+3s/PKLL4= Received: by 10.223.87.3 with SMTP id u3mr4799603fal.13.1308935006489; Fri, 24 Jun 2011 10:03:26 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 10sm1764999faw.24.2011.06.24.10.03.25 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 10:03:25 -0700 (PDT) Message-ID: <4E04C38A.6090505@gmail.com> Date: Fri, 24 Jun 2011 20:04:10 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Apps-discuss list , public-html-comments-request@w3.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] HTML5 and RFC 2854 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 17:03:28 -0000 Hello all, Cross-posting this to Apps-discuss and html-comments lists. The proposed HTML5 specification (http://dev.w3.org/html5/spec/), which is currently in Last Call, in its Section 12.1 updates the registration of text/html media type. I should note that we have RFC 2854 (http://tools.ietf.org/html/rfc2854) which also specifies this media type. Therefore the question is what should be done with this RFC. Should it be retired upon approval of HTML5? Or something else? Mykyta Yevstifeyev From julian.reschke@gmx.de Sat Jun 25 02:52:59 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD4021F8493 for ; Sat, 25 Jun 2011 02:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.768 X-Spam-Level: X-Spam-Status: No, score=-103.768 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7ulPzaA6805 for ; Sat, 25 Jun 2011 02:52:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2182321F8447 for ; Sat, 25 Jun 2011 02:52:57 -0700 (PDT) Received: (qmail invoked by alias); 25 Jun 2011 09:52:55 -0000 Received: from p508FBF56.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.191.86] by mail.gmx.net (mp015) with SMTP; 25 Jun 2011 11:52:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/dZTFBgvXdaVPZV3NhFPRl5XuqtIP379yqdL6W5s CMZNpg+25d1+YN Message-ID: <4E05AFF0.9080705@gmx.de> Date: Sat, 25 Jun 2011 11:52:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4E04C38A.6090505@gmail.com> In-Reply-To: <4E04C38A.6090505@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps-discuss list , public-html-comments-request@w3.org Subject: Re: [apps-discuss] HTML5 and RFC 2854 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2011 09:52:59 -0000 On 2011-06-24 19:04, Mykyta Yevstifeyev wrote: > Hello all, > > Cross-posting this to Apps-discuss and html-comments lists. The proposed > HTML5 specification (http://dev.w3.org/html5/spec/), which is currently > in Last Call, in its Section 12.1 updates the registration of text/html > media type. I should note that we have RFC 2854 > (http://tools.ietf.org/html/rfc2854) which also specifies this media > type. Therefore the question is what should be done with this RFC. > Should it be retired upon approval of HTML5? Or something else? > > Mykyta Yevstifeyev HTML5 currently tries to obsolete RFC 2854; I believe this is a problem. From : Changes should be requested only when there are serious omissions or errors in the published specification. When review is required, a change request may be denied if it renders entities that were valid under the previous definition invalid under the new definition. Note the second sentence; many currently valid HTML4 documents aren't valid HTML5 documents anymore. Thus, a document updating the media type registration for text/html will need to continue to allow HTML4.01 documents as well. See related HTML WG issue: Best regards, Julian From evnikita2@gmail.com Sat Jun 25 04:16:09 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E24228006; Sat, 25 Jun 2011 04:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU8MJqfQfgL5; Sat, 25 Jun 2011 04:16:07 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1433C228005; Sat, 25 Jun 2011 04:16:06 -0700 (PDT) Received: by fxe4 with SMTP id 4so916178fxe.27 for ; Sat, 25 Jun 2011 04:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8n5LXtUencGcqFfHcL4/1l8t1tah0X/DYYEm+VKultA=; b=u7clKSfkETAsrkWieK1Falb8ODY8VoUa42h/yjVK7nXQ0wExiea79E02xXlE34OxD4 rmxE5qW21ASRcK6z9BveNfN94n/Q7gg4IYHWtOkYF1YgzB3yqDhPzTZ/GPpY27gH5vZu LhOf/Viik4Bwionv6JRa5AAoOMlkTbNpWK6pQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=uxDLrurymtWQtiGIpox0Tne59T2KYRRWNT/49TnEqpC6mvnEYrNoWFfofe74qDopII 9LkqZj6kRhhFhtR66I/Tg8vuZeuSDFM7WDlSjYNeJfqz6nG/u/FYeMKMTOC0yk6S09c7 eaBjEfRPvb+PpWVzGI1m23YY7o075TtmScL3I= Received: by 10.223.20.210 with SMTP id g18mr6024401fab.30.1309000566038; Sat, 25 Jun 2011 04:16:06 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id e16sm2204488fak.41.2011.06.25.04.16.04 (version=SSLv3 cipher=OTHER); Sat, 25 Jun 2011 04:16:04 -0700 (PDT) Message-ID: <4E05C3A1.9080002@gmail.com> Date: Sat, 25 Jun 2011 14:16:49 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Julian Reschke References: <4E04C38A.6090505@gmail.com> <4E05AFF0.9080705@gmx.de> In-Reply-To: <4E05AFF0.9080705@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-types@ietf.org, Apps-discuss list , public-html-comments-request@w3.org Subject: Re: [apps-discuss] HTML5 and RFC 2854 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2011 11:16:09 -0000 25.06.2011 12:52, Julian Reschke wrote: > On 2011-06-24 19:04, Mykyta Yevstifeyev wrote: >> Hello all, >> >> Cross-posting this to Apps-discuss and html-comments lists. The proposed >> HTML5 specification (http://dev.w3.org/html5/spec/), which is currently >> in Last Call, in its Section 12.1 updates the registration of text/html >> media type. I should note that we have RFC 2854 >> (http://tools.ietf.org/html/rfc2854) which also specifies this media >> type. Therefore the question is what should be done with this RFC. >> Should it be retired upon approval of HTML5? Or something else? >> >> Mykyta Yevstifeyev > > HTML5 currently tries to obsolete RFC 2854; I believe this is a problem. > > From : > > Changes should be requested only when there are serious omissions or > errors in the published specification. When review is required, a > change request may be denied if it renders entities that were valid > under the previous definition invalid under the new definition. > > Note the second sentence; many currently valid HTML4 documents aren't > valid HTML5 documents anymore. Thus, a document updating the media > type registration for text/html will need to continue to allow > HTML4.01 documents as well. Currently copying this to ietf-types@ietf.org . I personally think HTML5 should be backwards-compatible with previous version as well as the media type defined for that version. So, first what should be done is identification whether there are some issue which make create confusion with the aforementioned regulations of RFC 4288. Next, if it doesn't, IANA should update registration of this media type with reference to HTML5, not RFC 2854. RFC 2854 itself should then be moved to Historic in order to represent it isn't an authoritative definition any more. This won't create confusion with different definitions of the media type. Just my opinion. Mykyta Yevstifeyev > > See related HTML WG issue: > > Best regards, Julian > From julian.reschke@gmx.de Sat Jun 25 04:21:06 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48F711E808A for ; Sat, 25 Jun 2011 04:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.687 X-Spam-Level: X-Spam-Status: No, score=-103.687 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCaeGb4jssU7 for ; Sat, 25 Jun 2011 04:21:06 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id F14F711E8070 for ; Sat, 25 Jun 2011 04:21:05 -0700 (PDT) Received: (qmail invoked by alias); 25 Jun 2011 11:21:03 -0000 Received: from p508FBF56.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.191.86] by mail.gmx.net (mp047) with SMTP; 25 Jun 2011 13:21:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18ff3xFSvAfjyBuM3I+WoScQtTPr74QKIacFoWJUo uy7DdbBVwOuo+2 Message-ID: <4E05C490.8090702@gmx.de> Date: Sat, 25 Jun 2011 13:20:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4E04C38A.6090505@gmail.com> <4E05AFF0.9080705@gmx.de> <4E05C3A1.9080002@gmail.com> In-Reply-To: <4E05C3A1.9080002@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf-types@ietf.org, Apps-discuss list , public-html-comments-request@w3.org Subject: Re: [apps-discuss] HTML5 and RFC 2854 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2011 11:21:07 -0000 On 2011-06-25 13:16, Mykyta Yevstifeyev wrote: > Currently copying this to ietf-types@ietf.org . I personally think HTML5 > should be backwards-compatible with previous version as well as the > media type defined for that version. So, first what should be done is > ... But it isn't. It forbids certain things that were allowed before and which are in use. I believe that in this case, a single level of indirection, like the one we have in RFC 2854, is the right thing. Best regards, Julian From presnick@qualcomm.com Sun Jun 26 20:41:37 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E9711E80AE; Sun, 26 Jun 2011 20:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.855 X-Spam-Level: X-Spam-Status: No, score=-103.855 tagged_above=-999 required=5 tests=[AWL=1.256, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8avJVp7NPQM5; Sun, 26 Jun 2011 20:41:36 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4F511E80A8; Sun, 26 Jun 2011 20:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1309146096; x=1340682096; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4E07FBEA.4090402@qualcomm.com>|Date:=20Su n,=2026=20Jun=202011=2022:41:30=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Julian=20Reschke=20|CC:=20Mykyta=20Yevstifeyev=20,=20,=0D=0A=09Apps-discuss=20l ist=20,=0D=0A=09|Subject:=20Re:=20[apps-discuss]=20HTM L5=20and=20RFC=202854|References:=20<4E04C38A.6090505@gma il.com>=20<4E05AFF0.9080705@gmx.de>=09<4E05C3A1.9080002@g mail.com>=20<4E05C490.8090702@gmx.de>|In-Reply-To:=20<4E0 5C490.8090702@gmx.de>|Content-Type:=20text/plain=3B=20cha rset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=LjjgVqH1hrOHjp8p9Gb3br8yNOF67uDYwwxjEnzgo5Y=; b=liP1rZOTNcrt2y7A2dKUiAFG4DgG12Jbi0yjzrFUltklTCKsLfvcgYI0 rnK2nZpQr0WdrAuLBUj+SGQiLmrPqBClZzw03aUjHU+WOSenaZNjmaWeS 911tV8swrD4/3OSuAjXEA3h7t3vbX9f1wOMESKBNwJibKDRBo6Im0Fcby c=; X-IronPort-AV: E=McAfee;i="5400,1158,6389"; a="100200211" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 26 Jun 2011 20:41:34 -0700 X-IronPort-AV: E=Sophos;i="4.65,429,1304319600"; d="scan'208";a="149896101" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jun 2011 20:41:34 -0700 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 26 Jun 2011 20:41:34 -0700 Message-ID: <4E07FBEA.4090402@qualcomm.com> Date: Sun, 26 Jun 2011 22:41:30 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <4E04C38A.6090505@gmail.com> <4E05AFF0.9080705@gmx.de> <4E05C3A1.9080002@gmail.com> <4E05C490.8090702@gmx.de> In-Reply-To: <4E05C490.8090702@gmx.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: public-html-comments-request@w3.org, Apps-discuss list , ietf-types@ietf.org Subject: Re: [apps-discuss] HTML5 and RFC 2854 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 03:41:37 -0000 On 6/25/11 6:20 AM, Julian Reschke wrote: > On 2011-06-25 13:16, Mykyta Yevstifeyev wrote: >> Currently copying this to ietf-types@ietf.org . I personally think HTML5 >> should be backwards-compatible with previous version as well as the >> media type defined for that version. So, first what should be done is > > ... > > But it isn't. It forbids certain things that were allowed before and > which are in use. > > I believe that in this case, a single level of indirection, like the > one we have in RFC 2854, is the right thing. I agree. HTML defines, internal to the document, the version of HTML it is using, often in a DOCTYPE directive. 2854 points to authoritative documents for the different versions of HTML and thereby defines the MIME type. It seems perfectly reasonable for a new IETF document to update (or obsolete) 2854 giving pointers to HTML5 *and all of the prior versions of HTML* that might be found in a text/html MIME body. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From julian.reschke@gmx.de Mon Jun 27 01:20:20 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E81721F8637 for ; Mon, 27 Jun 2011 01:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff62JcE4FJnh for ; Mon, 27 Jun 2011 01:20:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E8A7621F8634 for ; Mon, 27 Jun 2011 01:20:18 -0700 (PDT) Received: (qmail invoked by alias); 27 Jun 2011 08:20:17 -0000 Received: from p508F9D9F.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.157.159] by mail.gmx.net (mp053) with SMTP; 27 Jun 2011 10:20:17 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Q4CxX1DKQSICxleVdR4p4DY0ra6ADPzIntb0Ovo 8/Da9m1sQNHWC3 Message-ID: <4E083D3F.6030200@gmx.de> Date: Mon, 27 Jun 2011 10:20:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "link-relations@ietf.org" , IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 08:20:20 -0000 (FYI) -------- Original Message -------- Subject: I-D Action: draft-ohye-canonical-link-relation-00.txt Date: Sun, 26 Jun 2011 22:46:52 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Canonical Link Relation Author(s) : Maile Ohye Filename : draft-ohye-canonical-link-relation-00.txt Pages : 6 Date : 2011-06-26 This specification defines the canonical link relation -- an element which designates the preferred version of content/URI from a set of duplicate or near duplicate pages. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Apps-Discuss mailing list (see <https://www.ietf.org/mailman/listinfo/apps-discuss>). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stpeter@stpeter.im Mon Jun 27 11:37:02 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3879911E8154 for ; Mon, 27 Jun 2011 11:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jBNB3BnV+rS for ; Mon, 27 Jun 2011 11:37:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 84C6811E8152 for ; Mon, 27 Jun 2011 11:37:01 -0700 (PDT) Received: from dhcp-64-101-72-207.cisco.com (dhcp-64-101-72-207.cisco.com [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B163A4032B for ; Mon, 27 Jun 2011 12:37:55 -0600 (MDT) Message-ID: <4E08CDCB.70902@stpeter.im> Date: Mon, 27 Jun 2011 12:36:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 18:37:02 -0000 Based on comments received to date, I've published a heavily-revised version of the "X-" proposal: http://www.ietf.org/id/draft-saintandre-xdash-00.txt Further feedback is welcome! Peter -- Peter Saint-Andre https://stpeter.im/ From ben@niven-jenkins.co.uk Mon Jun 27 14:21:49 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C186221F8664 for ; Mon, 27 Jun 2011 14:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+GRqK4a45vV for ; Mon, 27 Jun 2011 14:21:48 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8D21F865D for ; Mon, 27 Jun 2011 14:21:47 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.2]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QbJFa-0002CC-DT; Mon, 27 Jun 2011 22:21:46 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <4E08CDCB.70902@stpeter.im> Date: Mon, 27 Jun 2011 22:21:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05DFA786-1C32-48C9-9581-13E7DA008FAA@niven-jenkins.co.uk> References: <4E08CDCB.70902@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 21:21:49 -0000 Peter, On 27 Jun 2011, at 19:36, Peter Saint-Andre wrote: > Based on comments received to date, I've published a heavily-revised > version of the "X-" proposal: >=20 > http://www.ietf.org/id/draft-saintandre-xdash-00.txt >=20 > Further feedback is welcome! One question. The draft concludes that: The foregoing considerations lead to the conclusion that segregating non-standard parameters into an "X-" ghetto has few if any benefits, and has at least one significant cost in terms of interoperability. Therefore, this document recommends against the creation of new names with the special "X-" prefix in application protocols produced within the IETF. Is the guidance aimed only at documents produced within the IETF or is = the intention that it is more general guidance. For example is it saying = that someone defining a private extension that they do not intend to (at = least initially) to bring to the IETF should still avoid use of "X-" = because forseeing the future is hard and although at definition time = they do not intend to standardise it, at some future point that might = happen and it could cause the interoperability problems outlined in the = draft? Thanks Ben From dhc@dcrocker.net Mon Jun 27 14:29:13 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72AD11E8144 for ; Mon, 27 Jun 2011 14:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R5WN9YuJRuj for ; Mon, 27 Jun 2011 14:29:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A430511E807F for ; Mon, 27 Jun 2011 14:29:12 -0700 (PDT) Received: from [192.168.1.90] (ppp-68-120-198-5.dsl.pltn13.pacbell.net [68.120.198.5]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p5RLT6Qr019448 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 27 Jun 2011 14:29:12 -0700 Message-ID: <4E08F623.2030803@dcrocker.net> Date: Mon, 27 Jun 2011 14:29:07 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ben Niven-Jenkins References: <4E08CDCB.70902@stpeter.im> <05DFA786-1C32-48C9-9581-13E7DA008FAA@niven-jenkins.co.uk> In-Reply-To: <05DFA786-1C32-48C9-9581-13E7DA008FAA@niven-jenkins.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 27 Jun 2011 14:29:12 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 27 Jun 2011 21:29:13 -0000 On 6/27/2011 2:21 PM, Ben Niven-Jenkins wrote: > Is the guidance aimed only at documents produced within the IETF or is the intention that it is more general guidance. For example is it saying that someone defining a private extension that they do not intend to (at least initially) to bring to the IETF should still avoid use of "X-" because forseeing the future is hard and although at definition time they do not intend to standardise it, at some future point that might happen and it could cause the interoperability problems outlined in the draft? It can't be only for documents within the IETF. The entire purpose of the X- construct, when we first introduced it in RFC822, was to support /private/ activities. It defined a safe haven for that private work, within a naming structure defined by the equivalent of the IETF. But 'private' means outside the IETF. What motivates the current document is that 'safe haven' turns out not to be nearly as important as making it easier to take the private efforts that have become popular and make then standardized, with the minimum transition pain. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Mon Jun 27 16:16:47 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98EA9E8005 for ; Mon, 27 Jun 2011 16:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.759 X-Spam-Level: X-Spam-Status: No, score=-107.759 tagged_above=-999 required=5 tests=[AWL=3.440, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q1NwV1yUYve for ; Mon, 27 Jun 2011 16:16:47 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 02D2C1F0C42 for ; Mon, 27 Jun 2011 16:16:46 -0700 (PDT) Received: (qmail 74736 invoked from network); 27 Jun 2011 23:16:45 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 27 Jun 2011 23:16:45 -0000 Received: (qmail 6857 invoked from network); 27 Jun 2011 23:16:45 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Jun 2011 23:16:45 -0000 Date: 27 Jun 2011 23:16:23 -0000 Message-ID: <20110627231623.17098.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <4E08F623.2030803@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 23:16:47 -0000 >What motivates the current document is that 'safe haven' turns out not to be >nearly as important as making it easier to take the private efforts that have >become popular and make then standardized, with the minimum transition pain. Perhaps some advice beyond not using X- would be helpful. Something like use a descriptive name, and longer (within reason) is better than shorter to avoid collisions. R's, John From mnot@mnot.net Mon Jun 27 21:34:30 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074E721F8629 for ; Mon, 27 Jun 2011 21:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHzUXgtXzQ7u for ; Mon, 27 Jun 2011 21:34:29 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id DF0B421F8609 for ; Mon, 27 Jun 2011 21:34:28 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.116.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9729A509DB; Tue, 28 Jun 2011 00:34:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4E08F623.2030803@dcrocker.net> Date: Tue, 28 Jun 2011 14:34:18 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5A5FF3BA-D378-4134-B867-1FD22CDE63C7@mnot.net> References: <4E08CDCB.70902@stpeter.im> <05DFA786-1C32-48C9-9581-13E7DA008FAA@niven-jenkins.co.uk> <4E08F623.2030803@dcrocker.net> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2011 04:34:30 -0000 On 28/06/2011, at 7:29 AM, Dave CROCKER wrote: > It can't be only for documents within the IETF. >=20 > The entire purpose of the X- construct, when we first introduced it in = RFC822, was to support /private/ activities. >=20 > It defined a safe haven for that private work, within a naming = structure defined by the equivalent of the IETF. But 'private' means = outside the IETF. >=20 > What motivates the current document is that 'safe haven' turns out not = to be nearly as important as making it easier to take the private = efforts that have become popular and make then standardized, with the = minimum transition pain. I don't think that it goes far enough, as written. What's needed here is = something we can point people at when they ask why they shouldn't use = X-. As it is, it says: > Therefore, this document recommends against the creation of new names = with the special "X-" prefix in IETF protocols. We understand what that means, but to the outside world -- i.e., someone = who's NOT an "IETF insider" -- that statement isn't nearly clear enough. I'd like to see the document rewritten with that target audience in mind = -- i.e, instead of talking about applications protocols passively, speak = actively about why using X- is a bad design choice for *your* protocol = extension.=20 Peter, I'll offer to help again, if you're amenable. Cheers, -- Mark Nottingham http://www.mnot.net/ From ben@niven-jenkins.co.uk Tue Jun 28 10:14:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42AC11E8107 for ; Tue, 28 Jun 2011 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.52 X-Spam-Level: X-Spam-Status: No, score=-103.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrEJFsErc2+r for ; Tue, 28 Jun 2011 10:14:54 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id EE03711E80F4 for ; Tue, 28 Jun 2011 10:14:53 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-128-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QbbsC-0006dP-PL; Tue, 28 Jun 2011 18:14:53 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <4E08F623.2030803@dcrocker.net> Date: Tue, 28 Jun 2011 18:14:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <482874CD-5929-4111-A016-3B34F1A2DA7B@niven-jenkins.co.uk> References: <4E08CDCB.70902@stpeter.im> <05DFA786-1C32-48C9-9581-13E7DA008FAA@niven-jenkins.co.uk> <4E08F623.2030803@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2011 17:14:54 -0000 Dave, On 27 Jun 2011, at 22:29, Dave CROCKER wrote: > On 6/27/2011 2:21 PM, Ben Niven-Jenkins wrote: >> Is the guidance aimed only at documents produced within the IETF or = is the intention that it is more general guidance. For example is it = saying that someone defining a private extension that they do not intend = to (at least initially) to bring to the IETF should still avoid use of = "X-" because forseeing the future is hard and although at definition = time they do not intend to standardise it, at some future point that = might happen and it could cause the interoperability problems outlined = in the draft? >=20 >=20 > It can't be only for documents within the IETF. >=20 > The entire purpose of the X- construct, when we first introduced it in = RFC822, was to support /private/ activities. >=20 > It defined a safe haven for that private work, within a naming = structure defined by the equivalent of the IETF. But 'private' means = outside the IETF. >=20 > What motivates the current document is that 'safe haven' turns out not = to be nearly as important as making it easier to take the private = efforts that have become popular and make then standardized, with the = minimum transition pain. That's what I thought based on the initial sections of the document but = the wording of the final guidance is such that it wasn't clear what was = actually being recommended. I'd suggest changing the language to make it = clear to non-IETF regulars that the guidance is wider than just = documents produced by the IETF. It was the use of "produced within the IETF" that got me confused, so = maybe drop it and just have "Therefore, this document recommends against = the creation of new names with the special "X-" prefix in application = protocols"? Ben From al@akc.com Tue Jun 28 10:28:29 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C65821F86C8 for ; Tue, 28 Jun 2011 10:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5ExhFdBXA-e for ; Tue, 28 Jun 2011 10:28:28 -0700 (PDT) Received: from mail.akc.com (mail.akc.com [98.109.199.131]) by ietfa.amsl.com (Postfix) with ESMTP id 3878B21F86C1 for ; Tue, 28 Jun 2011 10:28:28 -0700 (PDT) Received: from upstairs (static-98-109-199-130.nwrknj.fios.verizon.net [98.109.199.130]) by mail.akc.com with SMTP; Tue, 28 Jun 2011 13:27:54 -0400 Message-ID: <9CAEFAF597924B478936B2FB7B277884@upstairs> From: "Al Costanzo" To: "Ben Niven-Jenkins" , References: <4E08CDCB.70902@stpeter.im><05DFA786-1C32-48C9-9581-13E7DA008FAA@niven-jenkins.co.uk><4E08F623.2030803@dcrocker.net> <482874CD-5929-4111-A016-3B34F1A2DA7B@niven-jenkins.co.uk> Date: Tue, 28 Jun 2011 13:27:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Al Costanzo List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 17:28:29 -0000 Originally, if I remember, this "X-" was used by vendors, for specific headers that they needed and wanted to be "ignored or not used by other until possibly they were done with the design and implementation. Was it not? Al Costanzo ----- Original Message ----- From: "Ben Niven-Jenkins" To: Cc: Sent: Tuesday, June 28, 2011 1:14 PM Subject: Re: [apps-discuss] "X-" revisited > Dave, > > On 27 Jun 2011, at 22:29, Dave CROCKER wrote: >> On 6/27/2011 2:21 PM, Ben Niven-Jenkins wrote: >>> Is the guidance aimed only at documents produced within the IETF or is >>> the intention that it is more general guidance. For example is it saying >>> that someone defining a private extension that they do not intend to (at >>> least initially) to bring to the IETF should still avoid use of "X-" >>> because forseeing the future is hard and although at definition time >>> they do not intend to standardise it, at some future point that might >>> happen and it could cause the interoperability problems outlined in the >>> draft? >> >> >> It can't be only for documents within the IETF. >> >> The entire purpose of the X- construct, when we first introduced it in >> RFC822, was to support /private/ activities. >> >> It defined a safe haven for that private work, within a naming structure >> defined by the equivalent of the IETF. But 'private' means outside the >> IETF. >> >> What motivates the current document is that 'safe haven' turns out not to >> be nearly as important as making it easier to take the private efforts >> that have become popular and make then standardized, with the minimum >> transition pain. > > That's what I thought based on the initial sections of the document but > the wording of the final guidance is such that it wasn't clear what was > actually being recommended. I'd suggest changing the language to make it > clear to non-IETF regulars that the guidance is wider than just documents > produced by the IETF. > > It was the use of "produced within the IETF" that got me confused, so > maybe drop it and just have "Therefore, this document recommends against > the creation of new names with the special "X-" prefix in application > protocols"? > > Ben > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From dhc@dcrocker.net Tue Jun 28 11:56:30 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDA111E815E for ; Tue, 28 Jun 2011 11:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGnCzR1LlBwX for ; Tue, 28 Jun 2011 11:56:29 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7773911E811F for ; Tue, 28 Jun 2011 11:56:29 -0700 (PDT) Received: from [192.168.1.104] (ppp-68-120-198-5.dsl.pltn13.pacbell.net [68.120.198.5]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p5SIuLMH027009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2011 11:56:27 -0700 Message-ID: <4E0A23D3.7020706@dcrocker.net> Date: Tue, 28 Jun 2011 11:56:19 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Al Costanzo References: <4E08CDCB.70902@stpeter.im><05DFA786-1C32-48C9-9581-13E7DA008FAA@niven-jenkins.co.uk><4E08F623.2030803@dcrocker.net> <482874CD-5929-4111-A016-3B34F1A2DA7B@niven-jenkins.co.uk> <9CAEFAF597924B478936B2FB7B277884@upstairs> In-Reply-To: <9CAEFAF597924B478936B2FB7B277884@upstairs> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 28 Jun 2011 11:56:27 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 28 Jun 2011 18:56:30 -0000 On 6/28/2011 10:27 AM, Al Costanzo wrote: > Originally, if I remember, this "X-" was used by vendors, for specific headers > that they needed and wanted to be "ignored or not used by other until possibly > they were done with the design and implementation. > > Was it not? When I was doing RFC822, there was an associated discussion list. RFC822 was really only a refinement of RFC733. There was an additional 5 years of email experience and a better understanding of some issues, and the task was merely tweaking the spec. The list was informal and collaborative. There was no IETF and no formal standardization in those days, but absent formal processes, it was like a working group.(*) I do not remember who posted the idea of X-, except that it wasn't me, but as I recall it got immediate support. I, for one, thought it a very cool idea. However, this was long before "vendors" were much of an issue, by nearly 10 years. I don't recall any sense, in those days, of "vendor" as a distinct class within our work. However various folk did private stuff. Lots of experimentation in those days. So the concern was that somebody's private stuff, which invented its own header field, would get stepped on by a later group/standards process that chose the same header field name. This was merely to protect against that happening. Alas, we gave no thought to /wanting/ the private effort to become 'standardized'. d/ (*) In 1977, RFC733 was the first RFC to declare itself a standard. However there was no reall standards process. We got permission from ARPA to use the word in the title in order to flag to the community some strong pressure to move from whatever ad hoc formats were being used to this one. In spite of the ARPA approval, there was a firestorm of indignation that we would be so presumptious as to /demand/ that folks adopt the spec. That just wasn't they way things were adopted in those days... -- Dave Crocker Brandenburg InternetWorking bbiw.net From dzonatas@gmail.com Tue Jun 28 12:22:51 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA50A11E8118 for ; Tue, 28 Jun 2011 12:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.892 X-Spam-Level: X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=-2.293, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f89Ix5DEn1E for ; Tue, 28 Jun 2011 12:22:51 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42DB611E8100 for ; Tue, 28 Jun 2011 12:22:51 -0700 (PDT) Received: by pwj5 with SMTP id 5so441998pwj.31 for ; Tue, 28 Jun 2011 12:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=sYtsntMzQY2SWivDHpLw7SaIlQIqaOn5njiHKEt1BBU=; b=YKTYXTDkGlJokwttxAB3TQqGcX8rpHlGA7hDXMiWFI/7RtFSzDkZPbx7CLUbz1nkjX o1RY0EhgDN8QMeTJ3kl2VdPYtQpCxsdmIMuI777FdK/2X6nAp665SuLcjMjIf+9QoYdc 8ZzK/Sa5vpiKAeEeYX9uzmhGmcuL4qH5CgrY4= Received: by 10.142.63.8 with SMTP id l8mr1554770wfa.12.1309288970939; Tue, 28 Jun 2011 12:22:50 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id e6sm326828pbm.87.2011.06.28.12.22.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Jun 2011 12:22:49 -0700 (PDT) Message-ID: <4E0A29E4.4050401@gmail.com> Date: Tue, 28 Jun 2011 12:22:12 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4E08CDCB.70902@stpeter.im><05DFA786-1C32-48C9-9581-13E7DA008FAA@niven-jenkins.co.uk><4E08F623.2030803@dcrocker.net> <482874CD-5929-4111-A016-3B34F1A2DA7B@niven-jenkins.co.uk> <9CAEFAF597924B478936B2FB7B277884@upstairs> In-Reply-To: <9CAEFAF597924B478936B2FB7B277884@upstairs> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2011 19:22:52 -0000 The only reason I have seen the use "X-" other than experimental were for non-standard distributions (past transition from USENET), except for no-delay or non-blocking I/O (i.e. "X-Non-Blocking:..." which helps denote not-critical). Some servers may want to avoid botnets and catch headers like "X-Trends:" or other cookie monsters. On that note, maybe the "X-" headers are less harmful if some rules like the use of atomic names if they are used at all, like "X-Oxygen:". The atomic names are well-known (universal, translatable), so servers then know what "X-" headers to prune, especially as an optimization techniques. On 06/28/2011 10:27 AM, Al Costanzo wrote: > Originally, if I remember, this "X-" was used by vendors, for specific > headers that they needed and wanted to be "ignored or not used by > other until possibly they were done with the design and implementation. > > Was it not? > > Al Costanzo > ----- Original Message ----- From: "Ben Niven-Jenkins" > > To: > Cc: > Sent: Tuesday, June 28, 2011 1:14 PM > Subject: Re: [apps-discuss] "X-" revisited > > >> Dave, >> >> On 27 Jun 2011, at 22:29, Dave CROCKER wrote: >>> On 6/27/2011 2:21 PM, Ben Niven-Jenkins wrote: >>>> Is the guidance aimed only at documents produced within the IETF or >>>> is the intention that it is more general guidance. For example is >>>> it saying that someone defining a private extension that they do >>>> not intend to (at least initially) to bring to the IETF should >>>> still avoid use of "X-" because forseeing the future is hard and >>>> although at definition time they do not intend to standardise it, >>>> at some future point that might happen and it could cause the >>>> interoperability problems outlined in the draft? >>> >>> >>> It can't be only for documents within the IETF. >>> >>> The entire purpose of the X- construct, when we first introduced it >>> in RFC822, was to support /private/ activities. >>> >>> It defined a safe haven for that private work, within a naming >>> structure defined by the equivalent of the IETF. But 'private' >>> means outside the IETF. >>> >>> What motivates the current document is that 'safe haven' turns out >>> not to be nearly as important as making it easier to take the >>> private efforts that have become popular and make then standardized, >>> with the minimum transition pain. >> >> That's what I thought based on the initial sections of the document >> but the wording of the final guidance is such that it wasn't clear >> what was actually being recommended. I'd suggest changing the >> language to make it clear to non-IETF regulars that the guidance is >> wider than just documents produced by the IETF. >> >> It was the use of "produced within the IETF" that got me confused, so >> maybe drop it and just have "Therefore, this document recommends >> against the creation of new names with the special "X-" prefix in >> application protocols"? >> >> Ben >> >> _______________________________________________ >> 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 > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From internet-drafts@ietf.org Tue Jun 28 18:14:08 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976F311E812F; Tue, 28 Jun 2011 18:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P69jE2tyCLUP; Tue, 28 Jun 2011 18:14:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3264B11E8131; Tue, 28 Jun 2011 18:14:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110629011408.4466.1816.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 18:14:08 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 01:14:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Terminology Used in Internationalization in the IETF Author(s) : Paul Hoffman John C Klensin Filename : draft-ietf-appsawg-rfc3536bis-03.txt Pages : 47 Date : 2011-06-28 This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-03.txt From paul.hoffman@vpnc.org Tue Jun 28 18:52:59 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C0F9E8018 for ; Tue, 28 Jun 2011 18:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCxkJsbwabAs for ; Tue, 28 Jun 2011 18:52:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 608719E8004 for ; Tue, 28 Jun 2011 18:52:58 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p5T1qo3d001598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 28 Jun 2011 18:52:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: <20110629011408.4466.1816.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 18:52:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110629011408.4466.1816.idtracker@ietfa.amsl.com> To: Apps Discuss X-Mailer: Apple Mail (2.1084) Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 01:52:59 -0000 On Jun 28, 2011, at 6:14 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Applications Area Working = Group Working Group of the IETF. >=20 > Title : Terminology Used in Internationalization in = the IETF > Author(s) : Paul Hoffman > John C Klensin > Filename : draft-ietf-appsawg-rfc3536bis-03.txt > Pages : 47 > Date : 2011-06-28 As noted in the changelog, this addresses the issues we have seen so far = during IETF LC. --Paul Hoffman From tony@att.com Tue Jun 28 19:32:50 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1011E812B for ; Tue, 28 Jun 2011 19:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-ZIPmBGlbd8 for ; Tue, 28 Jun 2011 19:32:50 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE2211E8129 for ; Tue, 28 Jun 2011 19:32:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1309314768!26548988!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 29234 invoked from network); 29 Jun 2011 02:32:49 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jun 2011 02:32:49 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5T2XDE9032037 for ; Tue, 28 Jun 2011 22:33:13 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5T2X9vb031979 for ; Tue, 28 Jun 2011 22:33:10 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p5T2Wis3011545 for ; Tue, 28 Jun 2011 22:32:44 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p5T2WZwJ011388 for ; Tue, 28 Jun 2011 22:32:36 -0400 Received: from [135.70.35.38] (vpn-135-70-35-38.vpn.west.att.com[135.70.35.38]) by maillennium.att.com (mailgw1) with ESMTP id <20110629023234gw100e4lhpe> (Authid: tony); Wed, 29 Jun 2011 02:32:35 +0000 X-Originating-IP: [135.70.35.38] Message-ID: <4E0A8EC0.6080509@att.com> Date: Tue, 28 Jun 2011 22:32:32 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E08CDCB.70902@stpeter.im> In-Reply-To: <4E08CDCB.70902@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 02:32:50 -0000 I think it's worth mentioning the use of the VND.domain.name, PRS and reversed.domain.name namespace prefixes as alternative mechanisms that *have* worked well in other protocols. This way the reader isn't left wondering "okay, I've been told what *not* to do and *why* I shouldn't do it, but what *should* I do instead?" Tony Hansen tony@att.com On 6/27/2011 2:36 PM, Peter Saint-Andre wrote: > Based on comments received to date, I've published a heavily-revised > version of the "X-" proposal: > > http://www.ietf.org/id/draft-saintandre-xdash-00.txt > > Further feedback is welcome From duerst@it.aoyama.ac.jp Wed Jun 29 00:28:21 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A7121F868A for ; Wed, 29 Jun 2011 00:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.79 X-Spam-Level: X-Spam-Status: No, score=-99.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk8Hwjuk3cXi for ; Wed, 29 Jun 2011 00:28:21 -0700 (PDT) Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9483321F8688 for ; Wed, 29 Jun 2011 00:28:19 -0700 (PDT) Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p5T7S5h5026468 for ; Wed, 29 Jun 2011 16:28:05 +0900 Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 406c_fdc4_545a0ca4_a221_11e0_b748_001d096c5b62; Wed, 29 Jun 2011 16:28:05 +0900 Received: from [IPv6:::1] ([133.2.210.5]:51400) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Jun 2011 16:28:00 +0900 Message-ID: <4E0AD3EB.6070403@it.aoyama.ac.jp> Date: Wed, 29 Jun 2011 16:27:39 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E08CDCB.70902@stpeter.im> In-Reply-To: <4E08CDCB.70902@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 07:28:21 -0000 Hello Peter, I see: To preserve interoperability, newer implementations simply support the "X-" name forever, which means that the non-standard name becomes a de facto standard (thus obviating the need for segregation of the name spaces in the first place). As one example, we can see this phenomenon at work in [RFC2068] (similar examples can be found in [RFC5064]): I would want to propose a tiny change to the last phrase: "similar examples" -> "a similar example" (because it's only about one header, and there are no actual examples of the X- header in usage). I'd also want to point out that I consider the X-Archived-At -> Archived-At transition in many ways the 'ideal' success story for a X- prefix. But the success was due to some very special circumstances: - When Archived-At was standardized, it was used only at two (very big) places, and these were willing and able to switch over extremely quickly. - Usage is mainly by individuals, with "software update" possible by settings in MUAs and the like, which made the transition easy on the receiving side. - There was somebody (me) who was willing to go through all the red tape, deal with people who claimed that it was totally useless, and so on. Regards, Martin. On 2011/06/28 3:36, Peter Saint-Andre wrote: > Based on comments received to date, I've published a heavily-revised > version of the "X-" proposal: > > http://www.ietf.org/id/draft-saintandre-xdash-00.txt > > Further feedback is welcome! > > Peter > From evnikita2@gmail.com Wed Jun 29 01:24:37 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0A621F86C8 for ; Wed, 29 Jun 2011 01:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.095 X-Spam-Level: X-Spam-Status: No, score=-3.095 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNo9gSK3Yx6m for ; Wed, 29 Jun 2011 01:24:35 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2056E21F86C9 for ; Wed, 29 Jun 2011 01:24:33 -0700 (PDT) Received: by bwb17 with SMTP id 17so965056bwb.31 for ; Wed, 29 Jun 2011 01:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=JVJ358ePwntiDrW5HQUkLd7Ed6mSsWHrQrJH4Efjsno=; b=LczA1kSA982aGwblpneUKLM+Ss2BWYA41lYSBG3BeyZpQwJ+7IuOthPaBLIRoJbRno OuMA7gw+ZMZ+pAbX4T/mQhK0/Ba4Dnqu9WgSiqtjTwvkXNlSeMpEDc6bloo9wwYqOpZn 0x03NALo2WH9E0xTYb+8EVvdavRj4X6mLW5XE= Received: by 10.204.2.141 with SMTP id 13mr449179bkj.20.1309335872844; Wed, 29 Jun 2011 01:24:32 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id e16sm277379bke.18.2011.06.29.01.24.28 (version=SSLv3 cipher=OTHER); Wed, 29 Jun 2011 01:24:30 -0700 (PDT) Message-ID: <4E0AE16A.1010504@gmail.com> Date: Wed, 29 Jun 2011 11:25:14 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Lachlan Hunt References: <0EC26EB10287E2A20769C9CC@PST.JCK.COM> <4E0171EB.4020109@gmail.com> <4E0320A2.6030000@lachy.id.au> <4E040968.3050205@gmail.com> In-Reply-To: <4E040968.3050205@gmail.com> Content-Type: multipart/mixed; boundary="------------040207060603070203080409" Cc: draft-holsten-about-uri-scheme@tools.ietf.org, John C Klensin , Apps-discuss list Subject: Re: [apps-discuss] Last Call: (The 'about' URI scheme) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 08:24:37 -0000 This is a multi-part message in MIME format. --------------040207060603070203080409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, As I proposed below, I've made some changes to produce an "alternative" about URI scheme draft. As no one of the current editors responded to this message (and, explicitly, my actual proposals), I'd like to bring them in form of the remade draft to the public discussions. You may find it attached to this message. Thanks, Mykyta Yevstifeyev 24.06.2011 6:50, Mykyta Yevstifeyev wrote: > Hello all, > > 23.06.2011 14:16, Lachlan Hunt wrote: >> On 2011-06-22 06:39, Mykyta Yevstifeyev wrote: >>>> (1) There seems to be consensus that registering this URI as a >>>> mechanism for accessing built-in functionality and configuration >>>> information such as application information, preferences, or >>>> settings. (Text derived from the Abstract with "configuration >>>> information", which may mean more to some readers, added and >>>> "easter eggs" dropped. Dropping "easter eggs" reflects other >>>> comments on the list and my opinion that it isn't worth the >>>> trouble to define. >>> >>> With regard to easter eggs I have no strong position. If it is >>> troubling, I don't object to remove any mention of them from the >>> document. >> >> The easter eggs are mentioned only in non-normative parts of the >> document, including the abstract and examples, and just reflect the >> reality of what some implementations use about URLs for. I do not >> understand the objection. > As I've already mentioned, I have no any strong position regarding > "easter eggs". Yet, my opinion is that mentioning them clarifies the > usage of about URIs a bit. >> >>>> (2) The document itself reflects an attempt to define the >>>> undefinable. There is no cross-implementation interoperability >>>> issue here; if anything, the document should me more clear that >>>> it would be stupid to assume it. The document, nonetheless, >>>> tries to define what is done with some specific URIs in some >>>> places and then has to turn around and indicate that they may be >>>> used in entirely different ways in other places and should not >>>> be relied upon. In the process, it skips back and forth between >>>> being descriptive and being normative, with some definitions >>>> becoming circular in the process. That just isn't a good >>>> combination and some of it actually looks pretty silly. >> >> This feedback is not helpful, as it just vague hand waving and >> dismissive. > I wouldn't say so; this remark is quite reasonable. In our section > dedicated to categorization we try to normatively specify how about > URIs are resolved due to the categories we try to create; ibidem we > sometimes give no clear description of related issue. Eg., suppose I > write my browser, YevstifeyevBrowser, which uses the about URI > about:bad-guy. I then claim it as "reserved" and, according to our > draft, any application which is compatible to it must resolve it to > what I want. Suppose another browser, FooBrowser, makes use if > about:bad-guy as well, but for other purpose; but, being compatible > with our spec. it can't. The issue is impossibility to rule out which > is a priori used internally only and is implementation-specific. > Another instance. Some application may treat some about URIs as > resolvable while other as unresolvable. Eg., FooBrowser may resolve > "unresolvable-as-per-HTML5" about:legacy-compat to the page saying it > is unresolvable etc. >> >>> I may partly agree with you. Reading the document for a number of times >>> I've also noticed this. A logical conclusion of everything >>> aforementioned is below. >>> >>>> "about:blank" is particularly troubling in that regard because >>>> the text essentially says that it is reserved except where it >>>> isn't. >> >> Nonsense. "about:blank" is clearly defined as reserved, and nowhere >> does it indicate otherwise. Perhaps you are confused where it >> excludes variations that include query strings? > "about:blank" is a special case which is one of the rare instances of > what is acceptable by almost all browsers. As for queries - I've > checked several browsers for their behavior. Firefox 5.0 - > about:blank?aa is treated about:blank. Chrome 12 - the same. IE8 > treats about:blank?aa as invalid URI returning "going to web page > canceled". Opera 11 - as FF. Finally, Safari 3.2.1 has the same > behavior. I see the majority of contemporary browsers treat > about:blank with query component as if it isn't present. I personally > see no point in reserving the about URI with no query only. >> >>>> Option 2: Really try to make this normative wrt some subset of >>>> URI values. In this approach, stop the extremely confusing >>>> circling around. >> >> The circular definitions have been resolved in the editor's draft. >> >> https://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-07.txt >> > I, as one of the editors, is a bit confused by this draft. It > incorporates none of changes I proposed and made after you made it > available. My editor's version is from June 14, not April 13, when > this file was uploaded. >> >>>> Indicate explicitly that "about" URIs have been used enough and in >>>> enough different circumstances that no application should assume >>>> that an "about" URI, if encountered, is actually its own and that >>>> due caution needs to be taken about non-conforming implementations. >> >> That's the whole point of the unreserved category. >> >>>> Then explicitly reserve, not only"about:blank", but everything the >>>> authors think is worth listing in Examples _and_ create an IANA >>>> registry for more of them. >> >> No. The registry is a completely unnecessary bureaucratic mess that >> I'm strongly fighting against, and will most likely be removing from >> a future draft. Mykyta added mention of it to the draft* against my >> wishes after I allowed him/her > I'm male, FYI. >> to become an editor even though (s)he has still not been able to >> provide justification for why such a registry is necessary. >> (However, I allowed the draft to be publicised with it for public >> review and comment.) >> >> * Note: That change hasn't been checked into github, and I don't know >> if Mykyta has those changes somewhere public yet. > I have no access to Github but I've sent you the latest edited version > of the draft in email on 14 June, if you remember. >> >> The purely informative value of a registry can and has already been >> achieved by Wikipedia. The three known reserved about URIs (blank, >> legacy-compat and scrdoc) are already documented, as are many other >> unreserved, but recognised application-specific URIs. >> >> Beyond that, the whole concept of reservation only exists to give >> other specifications a clear way to define about URIs for their own >> purposes and doesn't need any formal registration process. It doesn't >> have any impact on any implementations that are not implementing the >> given specification. > Considering the controversy of this question, I think we may put it > aside for a time. Anyway, when the document is published, we can add > the registry if there is a necessity; please note that my > justification for the registry was ongoing comments on its necessity > during Last Call, so IMO, of course, "he has still not been able to > provide justification for why such a registry is necessary" is > probably untrue. > > Actually, I have some concerns about section on resolving about URIs. > I understand what I propose below surely does not fit in what we have > in the current draft and, mainly, its concepts. However, were I to > decide myself, I would fully rewrite the document is the following > way. First, the intended status would be Informational. Syntax would > be left in the current form. More important the semantics probably > are. I'd mention that (1) 'about' URIs are used internally only, so > any application is free to resolve it to any resource with any > semantics, except the several instances, defined below as > "special-purpose 'about' URIs", which are permanently reserved for use > in a specific manner; (2) a special-purpose 'about' URI as an 'about' > URI using a particular well-known segment and which is defined to be > used for a specific purpose and MUST be used only and only as defined > in a specification of such URI; (3) categorization into > "resolvable/unresolvable" would be eliminated; (4) provisions > regarding recognition of the URIs would be almost the same. Encoding > considerations would be that about URIs may contain characters from > UCS first encoded with UTF-8; those UTF-8 encoded characters which do > not fit in the RFC 3986 definition for or SHALL be > percent-encoded within corresponding part. Then a registry for > special-purpose 'about' URIs would be created. For a number of > now-in-use, though not special-purpose, 'about' URIs the reader would > be pointed to http://en.wikipedia.org/wiki/About_URI_scheme > > I'd like to seek the current editors' opinion on the proposed approach > above. IMO, such description is (a) clearer and (b) removes a number > of controversial issues. >> >>>> the document should be really clear that all that the use of >>>> "about:" really tells someone is that it is application-specific >>>> and that a particular implementation of a particular application >>>> may do whatever it pleases with them. >> >> It still says that, though the way it is written is a quite ambiguous >> and convoluted and I understand the confusion here. I'll rephrase >> the section on recognised URIs to address this. > See my proposal above. >> >>>> Smaller issues: >>>> >>>> (i) Section 6, Normalization, sadly really doesn't belong here >>>> unless the authors can show that everyone interprets "about:" >>>> according to those rules. Otherwise, it would be better to say >>>> that the URI is interpreted in an implementation-specific way >>>> and that implementations would be well-advised to conform to >>>> normal URI syntax rules unless there is a strong reason not >> >>> Agree here. This thread restarted with the response to Boris's comment >>> regarding Gecko's normalization rules. This was to claim that no >>> unified >>> rules for the scheme which is a priori used by the applications on >>> their >>> own. As I proposed below, if no document is to be written, the template >>> may contain such statement about implementation-specific normalization >>> rules. >> >> Yes, normalisation requirements will be removed. > Probably they aren't to be removed but rather mentioned as > implementation-specific. >> >>>> (ii) IMO, Section 7, Security Considerations, should be modified >>>> to include an explicit statement that, since these things are >>>> intended for convenience use within an implementation of an >>>> application, passing them between systems (embedded in files or >>>> otherwise) is very risky behavior and should generally be >>>> discouraged except, possibly, in documentation contexts. >>> I agree here. >>> ... >>> Section 4 is what is also questionable. This issue was raised during >>> Last Call and I think can be resolved by saying that an about URIs may >>> contain UTF-8 encoded characters in the , as suggested by RFC >>> 3986 and that's all. >> >> Mykyta, feel free to revise sections 4 and 7 as you see fit. >> > All the best, > Mykyta Yevstifeyev > --------------040207060603070203080409 Content-Type: text/plain; name="draft-holsten-about-uri-scheme-07-wc.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-holsten-about-uri-scheme-07-wc.txt" IA0KDQoNCg0KSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURikgICAgICAg ICAgICAgICAgICAgICAgICBKLiBIb2xzdGVuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCkludGVu ZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTC4gSHVudA0KRXhwaXJlczogRGVjZW1iZXIgMzEsIDIwMTEgICAgICAgICAgICAg ICAgICAgICAgICAgIE9wZXJhIFNvZnR3YXJlLCBBU0EuDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gWWV2c3RpZmV5ZXYN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSnVuZSAyOSwgMjAxMQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgVGhlICdh Ym91dCcgVVJJIHNjaGVtZQ0KICAgICAgICAgICAgICAgICAgIGRyYWZ0LWhvbHN0ZW4tYWJv dXQtdXJpLXNjaGVtZS0wNw0KDQpBYnN0cmFjdA0KDQogICBUaGUgJ2Fib3V0JyBVUkkgc2No ZW1lIGhhcyBsb25nIGJlZW4gdXNlZCBieSB2YXJpb3VzIGFwcGxpY2F0aW9ucywNCiAgIGVz cGVjaWFsbHkgd2ViIGJyb3dzZXJzLCB0byBkZXNpZ25hdGUgdGhlIGFjY2VzcyB0byB0aGVp ciBpbnRlcm5hbA0KICAgcmVzb3VyY2VzLiAgVGhpcyBVUkkgc2NoZW1lIGhhcyBuZXZlciBi ZWVuIGdpdmVuIGFueSBzcGVjaWZpY2F0aW9uLA0KICAgZWl0aGVyIHB1Ymxpc2hlZCBhcyBS RkMgb3IgaW4gdGhlIG90aGVyIHdheS4gIFRoaXMgZG9jdW1lbnQgcmVtb3Zlcw0KICAgdGhp cyB1bmNlcnRhaW50eTsgaXQgc2VydmVzIGFzIGEgZGVmaW5pdGlvbiBvZiAnYWJvdXQnIFVS SSBzY2hlbWUuDQoNClN0YXR1cyBvZiBUaGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1E cmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0KICAgcHJv dmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRh c2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0 cmlidXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uDQoNCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBj aXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoaXMg SW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTWF5IDUsIDIwMTEuDQoNCkNvcHlyaWdo dCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJp Z2h0cyByZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3 OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0 byBJRVRGIERvY3VtZW50cw0KICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2Ut aW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBwdWJsaWNhdGlvbiBvZiB0aGlz IGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNCiAgIGNhcmVmdWxs eSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGgg cmVzcGVjdA0KICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0 ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0Qg TGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KICAgdGhlIFRy dXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5 IGFzDQogDQoNCg0KSG9sc3RlbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDMx LCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgVGhlICdhYm91dCcgVVJJIHNjaGVtZSAgICAgICAgICAgIEp1bmUgMjksIDIwMTEN Cg0KDQogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNClRh YmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMg0KICAgICAxLjEuIFRlcm1p bm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAyDQogICAyLiBVUkkgU2NoZW1lIERlZmluaXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDINCiAgICAgMi4xLiBVUkkgU2NoZW1lIFN5bnRheCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMg0KICAgICAyLjIu IFVSSSBTY2hlbWUgU2VtYW50aWNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAzDQogICAgICAgMi4yLjEuIFNwZWNpYWwtUHVycG9zZSAnYWJvdXQnIFVSSXMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgICAgICAyLjIuMi4gUmVjb2duaXRp b24gb2YgJ2Fib3V0JyBVUklzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAg ICAyLjMuIEVuY29kaW5nIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA0DQogICAzLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDQuIElBTkEgQ29uc2lk ZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NQ0KICAgICA0LjEuIFVSSSBTY2hlbWUgUmVnaXN0cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICAgIDQuMi4gSUFOQSBSZWdpc3RyeSBmb3IgUmVz ZXJ2ZWQgJ2Fib3V0JyBVUklzIFRva2VucyAgLiAuIC4gLiAuIC4gIDUNCiAgICAgICA0LjIu MS4gIEluaXRpYWwgQ29udGVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgNg0KICAgNS4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAgIDUuMS4gTm9ybWF0aXZlIFJlZmVy ZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAg NS4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNw0KICAgQXBwZW5kaXggQS4gIEFja25vd2xlZGdtZW50cyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICBBdXRob3JzJyBBZGRyZXNz ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcN Cg0KMS4gSW50cm9kdWN0aW9uDQoNCiAgIFRoZSAnYWJvdXQnIFVSSSBzY2hlbWUgaGFzIGxv bmcgYmVlbiB1c2VkIGJ5IHZhcmlvdXMgYXBwbGljYXRpb25zLA0KICAgZXNwZWNpYWxseSB3 ZWIgYnJvd3NlcnMsIHRvIGRlc2lnbmF0ZSB0aGUgYWNjZXNzIHRvIHRoZWlyIGludGVybmFs DQogICByZXNvdXJjZXMgKHdoaWNoIGluY2x1ZGUgcHJlZmVyZW5jZXMsIHNldHRpbmdzLCBh cHBsaWNhdGlvbg0KICAgaW5mb3JtYXRpb24gZXRjLikuICBBbHRob3VnaCB0aGlzIHNjaGVt ZSBoYXMgbmV2ZXIgYmVlbiBnaXZlbiBhbnkNCiAgIHNwZWNpZmljYXRpb24sIGVpdGhlciBw dWJsaXNoZWQgYXMgUkZDIG9yIGluIG90aGVyIHdheSwgJ2Fib3V0JyBVUklzDQogICBoYXZl IGJlY29tZSBhIGRlIGZhY3RvIHN0YW5kYXJkLiAgSW4gb3JkZXIgdG8gcmVtb3ZlIHRoZSB1 bmNlcnRhaW50eSwNCiAgIHRoaXMgZG9jdW1lbnQgc2VydmVzIGEgc3BlY2lmaWNhdGlvbiBm b3IgJ2Fib3V0JyBVUkkgc2NoZW1lLg0KDQogICBHZW5lcmljIFVSSSBzeW50YXggaXMgZGVm aW5lZCBpbiBSRkMgMzk4NiBbUkZDMzk4Nl07IHJlZ2lzdHJhdGlvbg0KICAgcHJvY2VkdXJl cyBmb3IgbmV3IFVSSSBzY2hlbWVzIC0gaW4gUkZDIDQzOTUgW1JGQzQzOTVdLg0KDQoxLjEu IFRlcm1pbm9sb2d5DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAi UkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxE IE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQog ICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAy MTE5IFtSRkMyMTE5XS4NCg0KMi4gVVJJIFNjaGVtZSBEZWZpbml0aW9uDQoNCjIuMS4gVVJJ IFNjaGVtZSBTeW50YXgNCg0KICAgVGhlICdhYm91dCcgVVJJIHRha2VzIHRoZSBmb3JtIG9m IDxhYm91dC11cmk+IHJ1bGUgYmVsb3csIHdoaWNoIGlzDQogICBkZWZpbmVkIHVzaW5nIEFC TkYgW1JGQzUyMzRdOg0KIA0KDQoNCkhvbHN0ZW4sIGV0IGFsLiAgICAgICAgRXhwaXJlcyBE ZWNlbWJlciAzMSwgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgIFRoZSAnYWJvdXQnIFVSSSBzY2hlbWUgICAgICAgICAgICBKdW5l IDI5LCAyMDExDQoNCg0KICAgICBhYm91dC11cmkgICA9ICJhYm91dDoiIGFib3V0LXRva2Vu IFsgIj8iIHF1ZXJ5IF0NCiAgICAgYWJvdXQtdG9rZW4gPSBzZWdtZW50DQoNCiAgIHdoZXJl IDxzZWdtZW50PiBhbmQgPHF1ZXJ5PiBhcmUgZGVmaW5lZCBpbiBBcHBlbmRpeCBBIG9mIFJG QyAzOTg2DQogICBbUkZDMzk4Nl0uDQoNCjIuMi4gVVJJIFNjaGVtZSBTZW1hbnRpY3MNCg0K ICAgR2VuZXJhbGl6ZWQsIGluIGNvbnRleHQgb2YgYSBnaXZlbiBhcHBsaWNhdGlvbiwgdGhl IDxhYm91dC10b2tlbj4NCiAgIHBhcnQgZGVub3RlcyB0aGUgbWVhbmluZyBhbmQgdGhlIG9i amVjdCBvZiBhIHBhcnRpY3VsYXIgJ2Fib3V0JyBVUkkNCiAgIHdoZXJlYXMgdGhlIHF1ZXJ5 IGNvbXBvbmVudCBtYXkgcHJvdmlkZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGZvcg0KICAg cHJvY2Vzc2luZyB0aGUgVVJJLiAgSG93ZXZlciwgYXMgbWVudGlvbmVkIGFib3ZlLCAnYWJv dXQnIFVSSXMgYXJlIGENCiAgIHByaW9yaSB1c2VkIGJ5IGFwcGxpY2F0aW9ucyBpbiBhbiBh cHBsaWNhdGlvbi1zcGVjaWZpYyBtYW5uZXIuICBJdCBpcw0KICAgaW1wb3NzaWJsZSB0byBk ZWZpbmUgZ2VuZXJpYyBzZW1hbnRpY3MgZm9yIF9hbGxfICdhYm91dCcgVVJJcw0KICAgZGVw ZW5kaW5nIG9uIHRoZSBwYXJ0aWN1bGFyIDxhYm91dC10b2tlbj4sIHdoaWNoIHRoaXMgZG9j dW1lbnQgZG9lcw0KICAgbm90IGF0dGVtcHQgdG8gZG8uICBBbnkgYXBwbGljYXRpb24sIHJl c29sdmluZyBhbiAnYWJvdXQnIFVSSSwgTUFZDQogICBjaG9vc2UgdGhlIHJlc291cmNlIGl0 IGlzIHJlc29sdmVkIHRvIGF0IGl0cyBvd24gZGlzY3JldGlvbiBtb2R1bG8NCiAgIHNldmVy YWwgZXhjZXB0aW9ucyBkZWZpbmVkIGJlbG93IGFzICJzcGVjaWFsLXB1cnBvc2UgJ2Fib3V0 JyBVUklzIi4gDQogICBUaGV5IE1BWSBhbHNvIHJlZGlyZWN0ICdhYm91dCcgVVJJcyAoZm9y IGluc3RhbmNlLCBPcGVyYSByZWRpcmVjdHMNCiAgIGFsbCAnYWJvdXQnIFVSSXMsIGV4Y2Vw dCAiYWJvdXQ6YmxhbmsiLCB0byBpdHMgaW50ZXJuYWwgJ29wZXJhJw0KICAgVVJJcykuDQoN CjIuMi4xLiBTcGVjaWFsLVB1cnBvc2UgJ2Fib3V0JyBVUklzDQoNCiAgIFNldmVyYWwgPGFi b3V0LXRva2Vucz4gYXJlIHJlc2VydmVkIGZvciB1c2UgaW4gc3BlY2lhbC1wdXJwb3NlDQog ICAnYWJvdXQnIFVSSXMuICBBIHNwZWNpYWwtcHVycG9zZSAnYWJvdXQnIFVSSSBpcyBhbiAn YWJvdXQnIFVSSSB3aGljaA0KICAgaXMgY2xlYXJseSBkZWZpbmVkIHRvIGJlIHVzZWQgZm9y IGEgc3BlY2lmaWMgcHVycG9zZSBhbmQgTVVTVCBiZSB1c2VkDQogICBvbmx5IGFuZCBvbmx5 IGluIHN1Y2ggbWFubmVyLiAgVGhlIHNwZWNpYWwtcHVycG9zZSAnYWJvdXQnIFVSSSBTSEFM TA0KICAgYWxzbyBiZSBjb25zaWRlcmVkIHRvIGJlIHNvIGV2ZW4gaWYgaXQgY29udGFpbnMg dGhlIHF1ZXJ5IGNvbXBvbmVudC4NCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVkIHNldmVy YWwgc3BlY2lhbC1wdXJwb3NlICdhYm91dCcgVVJJczsgZnVydGhlcg0KICAgb25lcyBtYXkg YmUgcmVzZXJ2ZWQgdmlhIHRoZSBjcmVhdGVkIHJlZ2lzdHJ5IGZvciBzcGVjaWFsLXB1cnBv c2UNCiAgICdhYm91dCcgVVJJcyB0b2tlbnMuICBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBz cGVjaWFsLXB1cnBvc2UgJ2Fib3V0Jw0KICAgVVJJcyBzaG91bGQgYmUgZGVmaW5lZCBvbmx5 IGluIHRoZSBjYXNlIG9mICJlbWVyZ2VuY3ksIiB3aGVuIHRoZXJlIGlzDQogICBhIG5lZWQg dG8gc3Ryb25nbHkgbWFuZGF0ZSB0aGUgdXNlIG9mIGEgcGFydGljdWxhciA8YWJvdXQtdG9r ZW4+IGluDQogICBhbGwgYXBwbGljYXRpb25zLg0KDQogICBUd28gc3BlY2lhbC1wdXJwb3Nl ICdhYm91dCcgVVJJcyBhcmUgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50LiAgVGhleQ0KICAg YXJlIDxhYm91dDpibGFuaz4gYW5kIDxhYm91dDpleGFtcGxlPi4gIFRoZSBVUkkgPGFib3V0 OmJsYW5rPiwgd2hpY2gNCiAgIGlzIGN1cnJlbnRseSBpbXBsZW1lbnRlZCBieSBhbG1vc3Qg YWxsIG1vZGVybiB3ZWIgYnJvd3NlcnMsIE1VU1QgYmUNCiAgIHJlc29sdmVkIHRvIHRoZSBy ZXNvdXJjZSB3aGljaCByZXByZXNlbnRzIGJsYW5rIHBhZ2UuICBTdWNoIHJlc291cmNlDQog ICBuZWVkIG5vdCBuZWNlc3NhcmlseSBjb250YWluIG5vIGRhdGEgKGZvciBleGFtcGxlLCBN aWNyb3NvZnQgSW50ZXJuZXQNCiAgIEV4cGxvcmVyIHJlc29sdmVzIDxhYm91dDpibGFuaz4g dG8gdGhlIEhUTUwgcGFnZSBjb250YWluaW5nDQogICAiPGh0bWw+PC9odG1sPiIpLg0KDQog ICBUaGUgPGFib3V0OmV4YW1wbGU+IGlzIHBlcm1hbmVudGx5IHJlc2VydmVkIGZvciB1c2Ug aW4gZG9jdW1lbnRhdGlvbg0KICAgW1JGQzM2OTJdIGFuZCBNVVNUIGJlIHRyZWF0ZWQgYXMg dW5yZWNvZ25pemVkIFVSSSBpbiBjb250ZXh0IG9mIGENCiAgIGdpdmVuIGFwcGxpY2F0aW9u Lg0KIA0KDQoNCkhvbHN0ZW4sIGV0IGFsLiAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAzMSwg MjAxMSAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgIFRoZSAnYWJvdXQnIFVSSSBzY2hlbWUgICAgICAgICAgICBKdW5lIDI5LCAyMDExDQoN Cg0KMi4yLjIuIFJlY29nbml0aW9uIG9mICdhYm91dCcgVVJJcw0KDQogICBJbiBjb250ZXh0 IG9mIGEgZ2l2ZW4gYXBwbGljYXRpb24sIGFueSAnYWJvdXQnIFVSSSBtYXkgYmUgZWl0aGVy DQogICByZWNvZ25pemVkIG9yIHVucmVjb2duaXplZC4gIFRoZSByZWNvZ25pemVkICdhYm91 dCcgVVJJIGlzIGFuICdhYm91dCcNCiAgIFVSSSB3aGljaCBjYW4gYmUgc3VjY2Vzc2Z1bGx5 IHJlc29sdmVkIGJ5IGFuIGFwcGxpY2F0aW9uLiAgVGh1cywgYW4NCiAgICdhYm91dCcgVVJJ IHdoaWNoIGFuIGFwcGxpY2F0aW9uIGlzIG5vdCBwb3NzaWJsZSB0byByZXNvbHZlLiAgQW55 DQogICB1bnJlY29nbml6ZWQgJ2Fib3V0JyBVUkkgU0hPVUxEIGJlIHJlc29sdmVkIGJ5IGFu IGFwcGxpY2F0aW9uIGluIHRoZQ0KICAgc2FtZSB3YXkgYXMgaXQgcmVzb2x2ZXMgPGFib3V0 OmJsYW5rPi4NCg0KMi4zLiBFbmNvZGluZyBDb25zaWRlcmF0aW9ucw0KDQogICAnYWJvdXQn IFVSSXMgbWF5IGNvbnRhaW4gY2hhcmFjdGVycyBmcm9tIFVuaXZlcnNhbCBDaGFyYWN0ZXIg U2V0DQogICAoVUNTKSBbVUNTXSwgZmlyc3QgZW5jb2RlZCB1c2luZyBVVEYtOCBbUkZDMzYy OV0uICBUaGVuIHRob3NlDQogICBjaGFyYWN0ZXJzIHdoaWNoIGFyZSBub3QgYWxsb3dlZCBi eSBBQk5GIHN5bnRheCBmb3IgYSBwYXJ0aWN1bGFyIHBhcnQNCiAgIG9mIHRoZSBVUkkgU0hB TEwgYmUgcGVyY2VudC1lbmNvZGVkIHdpdGhpbiBzdWNoIHBhcnQuICBJbiBmYWN0LCB0aGVy ZQ0KICAgYXJlIG5vIG90aGVyIGVuY29kaW5nIGNvbnNpZGVyYXRpb25zIGZvciAnYWJvdXQn IFVSSXMgbm90IGRpc2N1c3NlZA0KICAgaW4gU2VjdGlvbiAyIG9mIFJGQyAzOTg2IFtSRkMz OTg2XS4NCg0KMy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgJ2Fib3V0JyBVUklz IG1pZ2h0IGlkZW50aWZ5IHJlc291cmNlcyB0aGF0IHJldmVhbCBzZW5zaXRpdmUNCiAgIGlu Zm9ybWF0aW9uLiAgQXBwbGljYXRpb25zIFNIQUxMIGVuc3VyZSBhcHByb3ByaWF0ZSByZXN0 cmljdGlvbnMgYXJlDQogICBpbiBwbGFjZSB0byBwcm90ZWN0IHN1Y2ggaW5mb3JtYXRpb24g ZnJvbSBhY2Nlc3Mgb3IgbW9kaWZpY2F0aW9uIGJ5DQogICB1bnRydXN0ZWQgc291cmNlcy4N Cg0KICAgSW1wbGVtZW50YXRpb25zIHNob3VsZCBhbHNvIHRha2Ugbm90ZSBvZiB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMNCiAgIGRlc2NyaWJlZCBieSBSRkMgMzk4NiBbUkZDMzk4 Nl0uICBJbiBwYXJ0aWN1bGFyLCB0aGUgZm9sbG93aW5nIGlzc3Vlcw0KICAgc2hvdWxkIGJl IGNvbnNpZGVyZWQ6DQoNCiAgICAgUmVsaWFiaWxpdHkgYW5kIENvbnNpc3RlbmN5LiAgSW1w bGVtZW50YXRpb25zIGFyZSByZXNwb25zaWJsZSBmb3INCiAgICAgdGhlIHJlbGlhYmlsaXR5 IGFuZCBjb25zaXN0ZW5jeSBvZiB0aGUgcmVzb3VyY2VzIHJldHVybmVkLiANCiAgICAgSG93 ZXZlciwgaW1wbGVtZW50YXRpb25zIHNob3VsZCB0YWtlIGNhcmUgd2l0aCAnYWJvdXQnIFVS SXMgdGhhdA0KICAgICBtaWdodCByZWRpcmVjdCB0bywgb3Igb3RoZXJ3aXNlIHJldHVybiBh IHJlc291cmNlIHRoYXQgbWlnaHQNCiAgICAgc3Vic2VxdWVudGx5IGFjY2VzcywgcmVtb3Rl IHJlc291cmNlcywgd2hpY2ggbWlnaHQgbm90IGJlIHJlbGlhYmxlDQogICAgIG9yIGNvbnNp c3RlbnQuDQoNCiAgICAgTWFsaWNpb3VzIENvbnN0cnVjdGlvbi4gIEltcGxlbWVudGF0aW9u cyBzaG91bGQgdGFrZSBjYXJlIHRvDQogICAgIHByZXZlbnQgdGhlIGNvbnN0cnVjdGlvbiBv ZiAnYWJvdXQnIFVSSXMgdGhhdCBtaWdodCBpbmFkdmVydGVudGx5DQogICAgIHBlcmZvcm0g ZGFtYWdpbmcgbG9jYWwgb3IgcmVtb3RlIG9wZXJhdGlvbnMsIHN1Y2ggYXMgdGhlDQogICAg IG1vZGlmaWNhdGlvbiBvZiBkYXRhLCBvciBsZWFraW5nIG9mIGRhdGEgdG8gdW50cnVzdGVk IHJlc291cmNlcy4gDQogICAgIEZvciBleGFtcGxlLCBpbmNvcnBvcmF0aW5nIHVuc2FuaXRp c2VkIGRhdGEgcHJvdmlkZWQgYnkgdGhlIHVzZXINCiAgICAgdmlhIHRoZSBxdWVyeSBzdHJp bmcgaW50byB0aGUgcmVzdWx0aW5nIHBhZ2UgY291bGQgYWxsb3cgYXR0YWNrZXJzDQogICAg IHRvIGluamVjdCBzY3JpcHRzIGludG8gcGFnZXMsIHNpbWlsYXIgdG8gYSBjcm9zcy1zaXRl IHNjcmlwdGluZw0KICAgICAoWFNTKSBhdHRhY2suDQoNCiAgICAgU2Vuc2l0aXZlIEluZm9y bWF0aW9uLiAgSW1wbGVtZW50YXRpb25zIHNob3VsZCBhdm9pZCBpbmNsdWRpbmcNCiAgICAg c2Vuc2l0aXZlIGluZm9ybWF0aW9uLCBzdWNoIGFzIHBhc3N3b3Jkcywgd2l0aGluICdhYm91 dCcgVVJJcyBvcg0KICAgICByZXNvdXJjZXMgdGhleSBhcmUgcmVzb2x2ZWQgdG8uDQogDQoN Cg0KSG9sc3RlbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDMxLCAyMDExICAg ICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhl ICdhYm91dCcgVVJJIHNjaGVtZSAgICAgICAgICAgIEp1bmUgMjksIDIwMTENCg0KDQogICBU aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIFJhcmUgSVAgQWRkcmVzcyBGb3JtYXRz IGFuZCBTZW1hbnRpYw0KICAgQXR0YWNrcywgYXMgZGlzY3Vzc2VkIGJ5IFJGQyAzOTg2IFtS RkMzOTg2XSBkbyBub3QgYXBwbHkgdG8gYWJvdXQNCiAgIFVSSXMsIGFzIHRoZXkgZG8gbm90 IGNvbnRhaW4gZWl0aGVyIElQIGFkZHJlc3NlcyBub3IgdXNlciBpbmZvcm1hdGlvbg0KICAg Y29tcG9uZW50cy4NCg0KNC4gSUFOQSBDb25zaWRlcmF0aW9ucw0KDQo0LjEuIFVSSSBTY2hl bWUgUmVnaXN0cmF0aW9uDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiByZXF1ZXN0cyB0aGUg SUFOQSByZWdpc3RlciB0aGUgJ2Fib3V0JyBVUkkgc2NoZW1lDQogICB3aXRoIHJlZmVyZW5j ZSB0byB0aGlzIGRvY3VtZW50IHBlciBSRkMgNDM5NSBbUkZDNDM5NV06DQoNCiAgICAgVVJJ IHNjaGVtZSBuYW1lOiAgYWJvdXQNCg0KICAgICBTdGF0dXM6ICBQZXJtYW5lbnQNCg0KICAg ICBVUkkgc2NoZW1lIHN5bnRheDogIFNlZSBSRkMgWFhYWCwgU2VjdGlvbiAyLjENCg0KICAg ICBVUkkgc2NoZW1lIHNlbWFudGljczogIFNlZSBSRkMgWFhYWCwgU2VjdGlvbiAyLjINCg0K ICAgICBFbmNvZGluZyBjb25zaWRlcmF0aW9uczogIFNlZSBSRkMgWFhYWCwgU2VjdGlvbiAy LjMNCg0KICAgICBJbnRlbmRlZCB1c2FnZTogIEFuICdhYm91dCcgVVJJIGlzIGRlc2lnbmVk IHRvIGJlIHVzZWQgaW50ZXJuYWxseQ0KICAgICBieSBhcHBsaWNhdGlvbnMgZm9yIGFsbW9z dCBhbnkgZGVzaXJlZCBwdXJwb3NlLiAgU2VlIFJGQyBYWFhYLA0KICAgICBTZWN0aW9uIDIu Mg0KDQogICAgIEFwcGxpY2F0aW9ucyBhbmQvb3IgcHJvdG9jb2xzIHRoYXQgdXNlIHRoaXMg VVJJIHNjaGVtZSBuYW1lOiAgQW55DQogICAgIGFwcGxpY2F0aW9ucyB0aGF0IHVzZSBVUklz IGFzIGlkZW50aWZpZXJzIGZvciBpbnRlcm5hbCByZXNvdXJjZXMNCg0KICAgICBTZWN1cml0 eSBjb25zaWRlcmF0aW9uczogIFNlZSBSRkMgWFhYWCwgU2VjdGlvbiAzDQoNCiAgICAgQ29u dGFjdDogIEpvc2VwaCBIb2xzdGVuIDxqb3NlcGhAam9zZXBoaG9sc3Rlbi5jb20+DQoNCiAg ICAgQXV0aG9yL0NoYW5nZSBjb250cm9sbGVyOiAgVzNDIDx3ZWItaHVtYW5AdzMub3JnPg0K DQogICBbUkZDIEVkaXRvcjogWFhYWCBpcyB0aGUgbnVtYmVyIG9mIHRoaXMgUkZDXQ0KDQo0 LjIuIElBTkEgUmVnaXN0cnkgZm9yIFJlc2VydmVkICdhYm91dCcgVVJJcyBUb2tlbnMNCg0K ICAgSUFOQSBpcyBhc2tlZCB0byBjcmVhdGUgYW5kIG1haW50YWluIHRoZSByZWdpc3RyeSBj YWxsZWQgIlNwZWNpYWwtDQogICBQdXJwb3NlICdhYm91dCcgVVJJcyBUb2tlbnMiIGZvbGxv d2luZyB0aGUgZ3VpZGVsaW5lcyBiZWxvdy4NCg0KICAgVGhlIHJlZ2lzdHJ5IHByb3ZpZGVz IGEgbGlzdGluZyBvZiByZWdpc3RlcmVkIHNwZWNpYWwtcHVycG9zZSAnYWJvdXQnDQogICBV UklzIHRva2VucywgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4yLjEuICBUaGUgc3BlY2lh bC1wdXJwb3NlDQogICAnYWJvdXQnIFVSSSB0b2tlbiByZWZlcnMgdG8gdGhlIHN0cmluZyB1 c2VkIGluIHRoZSA8YWJvdXQtdG9rZW4+IHBhcnQNCiAgIG9mIHNwZWNpYWwtcHVycG9zZSAn YWJvdXQnIFVSSSwgd2l0aCB0aGUgc3ludGF4IGRlc2NyaWJlZCBpbiBTZWN0aW9uDQogICAy LjEgZm9yIHRoaXMgcHJvZHVjdGlvbi4NCg0KIA0KDQoNCkhvbHN0ZW4sIGV0IGFsLiAgICAg ICAgRXhwaXJlcyBEZWNlbWJlciAzMSwgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSA1XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSAnYWJvdXQnIFVSSSBzY2hlbWUgICAg ICAgICAgICBKdW5lIDI5LCAyMDExDQoNCg0KICAgVGhlIHJlZ2lzdHJhdGlvbiBwcm9jZWR1 cmVzIGZvciB0aGlzIHJlZ2lzdHJ5IGFyZSAnU3BlY2lmaWNhdGlvbg0KICAgUmVxdWlyZWQn LCBkZXNjcmliZWQgaW4gUkZDIDUyMjYgW1JGQzUyMjZdLiAgVGhlIHJlZ2lzdHJhbnQgb2Yg c3VjaA0KICAgdG9rZW4gTVVTVCBhbHNvIHByb3ZpZGUgdGhlIGZvbGxvd2luZyByZWdpc3Ry YXRpb24gdGVtcGxhdGUsIHRoYXQNCiAgIHNob3VsZCBiZSBhdmFpbGFibGUgb24gSUFOQSB3 ZWIgc2l0ZToNCg0KICAgICBTcGVjaWFsLVB1cnBvc2UgJ2Fib3V0JyBVUklzIFRva2VuLiAg UkVRVUlSRUQgZmllbGQuICBEZXNpcmVkDQogICAgICdhYm91dCcgVVJJIHRva2VuLCBjb21w bGlhbnQgdG8gdGhlIHN5bnRheCBkZXNjcmliZWQgaW4gU2VjdGlvbiAyDQogICAgIG9mIHRo aXMgZG9jdW1lbnQgZm9yIHRoZSA8YWJvdXQtdG9rZW4+IHJ1bGUNCg0KICAgICBJbnRlbmRl ZCBVc2FnZS4gIFJFUVVJUkVEIGZpZWxkLiAgQSBzaG9ydCBkZXNjcmlwdGlvbiBvZiBpbnRl bmRlZA0KICAgICB1c2FnZSBvZiAnYWJvdXQnIFVSSSB3aXRoIHN1Y2ggdG9rZW4NCg0KICAg ICBTcGVjaWZpY2F0aW9uLiAgUkVRVUlSRUQgZmllbGQuICBSZWZlcmVuY2VzIHRvIHRoZSBk b2N1bWVudChzKSwgaWYNCiAgICAgYW55LCB0aGF0IGRlc2NyaWJlZCB0aGUgcmVnaXN0ZXJl ZCAnYWJvdXQnIFVSSSB0b2tlbg0KDQogICAgIEFzc2lnbm1lbnQgTm90ZXMuICBPUFRJT05B TCBmaWVsZC4gIEFueSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uDQogICAgIGFib3V0IHRoZSBh c3NpZ25tZW50DQoNCiAgICAgQ29udGFjdC9DaGFuZ2UgQ29udHJvbGxlci4gIFJFUVVJUkVE IGZpZWxkLiAgQSBwZXJzb24gb3IgYW4NCiAgICAgb3JnYW5pemF0aW9uLCBhdXRob3JpemVk IHRvIGNoYW5nZSB0aGlzIHJlZ2lzdHJhdGlvbiwgd2hpY2ggc2hvdWxkDQogICAgIGJlIGNv bnRhY3RlZCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbiBvbiB0aGUgcmVnaXN0ZXJlZCBzcGVj aWFsLQ0KICAgICBwdXJwb3NlICdhYm91dCcgVVJJLCB3aXRoIHRoZWlyIGNvbnRhY3QgcG9p bnRzDQoNCjQuMi4xLiAgSW5pdGlhbCBDb250ZW50cw0KDQogICBUaGUgcmVnaXN0cnkgaW5p dGlhbGx5IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgdHdvIHJlZ2lzdHJhdGlvbnM6IA0KDQog ICBvIFNwZWNpYWwtUHVycG9zZSAnYWJvdXQnIFVSSXMgVG9rZW46ICBibGFuaw0KICAgbyBJ bnRlbmRlZCB1c2FnZTogIFRoZSA8YWJvdXQ6Ymxhbms+IFVSSSByZXR1cm5zIHRoZSBibGFu ayBwYWdlDQogICBvIFNwZWNpZmljYXRpb246ICBSRkMgWFhYWCAodGhpcyBkb2N1bWVudCAt IG5vdGUgdG8gUkZDIEVkaXRvcikNCiAgIG8gQXV0aG9yL0NoYW5nZSBDb250cm9sbGVyOiAg VzNDIDx3ZWItaHVtYW5AdzMub3JnPg0KDQogICBvIFNwZWNpYWwtUHVycG9zZSAnYWJvdXQn IFVSSXMgVG9rZW46ICBleGFtcGxlDQogICBvIEludGVuZGVkIHVzYWdlOiAgVGhlIDxhYm91 dDpleGFtcGxlPiBVUkkgaXMgcGVybWFuZW50bHkgcmVzZXJ2ZWQNCiAgICAgZm9yIHVzZSBp biBkb2N1bWVudGF0aW9uDQogICBvIFNwZWNpZmljYXRpb246ICBSRkMgWFhYWCAodGhpcyBk b2N1bWVudCAtIG5vdGUgdG8gUkZDIEVkaXRvcikNCiAgIG8gQXV0aG9yL0NoYW5nZSBDb250 cm9sbGVyOiAgVzNDIDx3ZWItaHVtYW5AdzMub3JnPg0KDQo1LiBSZWZlcmVuY2VzDQoNCjUu MS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzIxMTldICAgQnJhZG5lciwgUy4s ICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAg ICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0K DQogICBbUkZDMzYyOV0gICBZZXJnZWF1LCBGLiwgIlVURi04LCBhIHRyYW5zZm9ybWF0aW9u IGZvcm1hdCBvZiBJU08NCiAgICAgICAgICAgICAgIDEwNjQ2IiwgU1REIDYzLCBSRkMgMzYy OSwgTm92ZW1iZXIgMjAwMy4NCg0KIA0KDQoNCkhvbHN0ZW4sIGV0IGFsLiAgICAgICAgRXhw aXJlcyBEZWNlbWJlciAzMSwgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSAnYWJvdXQnIFVSSSBzY2hlbWUgICAgICAgICAg ICBKdW5lIDI5LCAyMDExDQoNCg0KICAgW1JGQzM5ODZdICAgQmVybmVycy1MZWUsIFQuLCBG aWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgIlVuaWZvcm0NCiAgICAgICAgICAgICAg IFJlc291cmNlIElkZW50aWZpZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4IiwgU1REIDY2LA0K ICAgICAgICAgICAgICAgUkZDIDM5ODYsIEphbnVhcnkgMjAwNS4NCg0KICAgW1JGQzUyMjZd ICAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRp bmcgYW4NCiAgICAgICAgICAgICAgIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBS RkNzIiwgQkNQIDI2LCBSRkMgNTIyNiwNCiAgICAgICAgICAgICAgIE1heSAyMDA4Lg0KDQog ICBbUkZDNTIzNF0gICBDcm9ja2VyLCBELiwgRWQuLCBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21l bnRlZCBCTkYgZm9yDQogICAgICAgICAgICAgICBTeW50YXggU3BlY2lmaWNhdGlvbnM6IEFC TkYiLCBTVEQgNjgsIFJGQyA1MjM0LCBKYW51YXJ5DQogICAgICAgICAgICAgICAyMDA4Lg0K DQogICBbVUNTXSAgICAgICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRh cmRpemF0aW9uLA0KICAgICAgICAgICAgICAgIkluZm9ybWF0aW9uIFRlY2hub2xvZ3kgLSBV bml2ZXJzYWwgTXVsdGlwbGUtT2N0ZXQgQ29kZWQNCiAgICAgICAgICAgICAgIENoYXJhY3Rl ciBTZXQgKFVDUykiLCBJU08vSUVDIFN0YW5kYXJkIDEwNjQ2OjIwMTEsIE1hcmNoDQogICAg ICAgICAgICAgICAyMDExLg0KDQo1LjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAg W1JGQzM2OTJdICAgTmFydGVuLCBULiwgIkFzc2lnbmluZyBFeHBlcmltZW50YWwgYW5kIFRl c3RpbmcgTnVtYmVycw0KICAgICAgICAgICAgICAgQ29uc2lkZXJlZCBVc2VmdWwiLCBCQ1Ag ODIsIFJGQyAzNjkyLCBKYW51YXJ5IDIwMDQuDQoNCiAgIFtSRkM0Mzk1XSAgIEhhbnNlbiwg VC4sIEhhcmRpZSwgVC4sIGFuZCBMLiBNYXNpbnRlciwgIkd1aWRlbGluZXMgYW5kDQogICAg ICAgICAgICAgICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlcyBmb3IgTmV3IFVSSSBTY2hlbWVz IiwgQkNQIDM1LA0KICAgICAgICAgICAgICAgUkZDIDQzOTUsIEZlYnJ1YXJ5IDIwMDYuDQoN CkFwcGVuZGl4IEEuICBBY2tub3dsZWRnbWVudHMNCg0KICAgVGhpcyBkb2N1bWVudCB3YXMg bWFkZSBwb3NzaWJsZSB0aGFua3MgdG8gdGhlIGlucHV0IG9mIChpbiBubw0KICAgcGFydGlj dWxhciBvcmRlcikgSGVucmkgU2l2b25lbiwgSWFuIEhpY2tzb24sIExhcnJ5IE1hc2ludGVy LCBCam9lcm4NCiAgIEhvZWhybWFubiwgTWFydGluIER1ZXJzdCBhbmQgSnVsaWFuIFJlc2No a2UuDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBKb3NlcGggQW50aG9ueSBQYXNxdWFs ZSBIb2xzdGVuDQoNCiAgIEVNYWlsOiBqb3NlcGhAam9zZXBoaG9sc3Rlbi5jb20NCiAgIFVS STogICBodHRwOi8vam9zZXBoaG9sc3Rlbi5jb20NCg0KDQogICBMYWNobGFuIEh1bnQNCiAg IE9wZXJhIFNvZnR3YXJlLCBBU0EuDQoNCiAgIEVNYWlsOiBsYWNobGFuLmh1bnRAbGFjaHku aWQuYXUNCiAgIFVSSTogICBodHRwOi8vbGFjaHkuaWQuYXUvDQoNCg0KICAgTXlreXRhIFll dnN0aWZleWV2DQogDQoNCg0KSG9sc3RlbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIERlY2Vt YmVyIDMxLCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgVGhlICdhYm91dCcgVVJJIHNjaGVtZSAgICAgICAgICAgIEp1bmUgMjks IDIwMTENCg0KDQogICBFTWFpbDogZXZuaWtpdGEyQGdtYWlsLmNvbQ0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhvbHN0ZW4sIGV0IGFsLiAgICAg ICAgRXhwaXJlcyBEZWNlbWJlciAzMSwgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSA4XQ0K --------------040207060603070203080409-- From stpeter@stpeter.im Wed Jun 29 14:19:23 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEDD11E8072 for ; Wed, 29 Jun 2011 14:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7SX09uaDw6f for ; Wed, 29 Jun 2011 14:19:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A502A9E8056 for ; Wed, 29 Jun 2011 14:19:22 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 17ABD4005B for ; Wed, 29 Jun 2011 15:19:21 -0600 (MDT) Message-ID: <4E0B96D8.7000409@stpeter.im> Date: Wed, 29 Jun 2011 15:19:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: Internet Draft Initial Version (-00) Cut-Off Monday, July 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 21:19:23 -0000 FYI. -------- Original Message -------- Subject: Internet Draft Initial Version (-00) Cut-Off Monday, July 4 Date: Wed, 29 Jun 2011 13:22:27 -0700 (PDT) From: Internet-Drafts Administrator To: IETF Announcement list This is a reminder that the Internet Draft Initial Version (-00) cut- off is this coming Monday, July 4, 2011. Please note that, because the AMS office is closed this Monday, manual submissions will not be processed until Tuesday, July 5. All Initial Version (-00) submissions are due by 17:00 PDT (00:00 Tuesday, July 5 UTC). All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ The Internet-Draft cutoff dates as well as other significant dates for IETF 81 can be found at: http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF81 Thank you for your understanding and cooperation. If you have any questions or concerns please send a message to internet-drafts@ietf.org. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dpranke@google.com Wed Jun 29 15:05:47 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315A811E80FE for ; Wed, 29 Jun 2011 15:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWxGcTJRdaPz for ; Wed, 29 Jun 2011 15:05:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2778611E80F3 for ; Wed, 29 Jun 2011 15:05:45 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p5TM5iqg009634 for ; Wed, 29 Jun 2011 15:05:44 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309385145; bh=xkeuZxk9Bq5HBStYKgPs1B/W+1E=; h=MIME-Version:Sender:In-Reply-To:References:From:Date:Message-ID: Subject:To:Cc:Content-Type; b=CdLlIlVZKyh8nEFmcdYlvgEBcZVgia793AVXbIQy+gJWzRRmCp24XM3YvYnUyRt97 /g2/LeVH99bnJoffzZgIQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:sender:in-reply-to:references:from: date:x-google-sender-auth:message-id:subject:to:cc:content-type:x-system-of-record; b=noR7OFu+xPh0GGtXm/cm7eVCg/XnpC7TC5fjM1uf7bwSXfxbH99Z9okYHdPs4RXov 3vOXQJOyOr1noS6LSvQPw== Received: from pvg7 (pvg7.prod.google.com [10.241.210.135]) by wpaz9.hot.corp.google.com with ESMTP id p5TM5gaG012957 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 29 Jun 2011 15:05:43 -0700 Received: by pvg7 with SMTP id 7so1383745pvg.37 for ; Wed, 29 Jun 2011 15:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=lzSY1o/tRYEfze/gp2zI0NX3mLY9CreOzmOxnMNuItk=; b=W7vAabzkxD17TRwMRt0ceQ+XNPJM1VR4l4RKCsbwRt1r+aRgfpHXm1ySJPRrXUw5Ib UAhaTYplqmVvpTP9MRZw== Received: by 10.143.39.17 with SMTP id r17mr639923wfj.113.1309385142318; Wed, 29 Jun 2011 15:05:42 -0700 (PDT) MIME-Version: 1.0 Sender: dpranke@google.com Received: by 10.142.193.2 with HTTP; Wed, 29 Jun 2011 15:05:22 -0700 (PDT) In-Reply-To: <4E08CDCB.70902@stpeter.im> References: <4E08CDCB.70902@stpeter.im> From: Dirk Pranke Date: Wed, 29 Jun 2011 15:05:22 -0700 X-Google-Sender-Auth: EVQGnIqNNiFf7F3VgoudHRR7-Eo Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 22:05:47 -0000 Your draft has: > In some situations, segregating the name space of parameters used in > a given application protocol can be justified: > ... > 2. When parameter names might have significant meaning. This case > is rare, since implementers can almost always find a synonym > (e.g., "urgency" instead of "priority") or simply invent a new > name. It seems to me that a primary benefit of the "X-" convention is that it makes unprefixed parameter names less socially acceptable; i.e., there's a pretty clear rule of thumb that if the name isn't X- prefixed, it probably has seen a pass through a committee and hence it stands at least a chance of having the same meaning in multiple implementations. I am concerned that if you abandon the X- practice, you will lose this benefit and finding untainted, available parameter names might become harder. Sure, you can often find a synonym, but it is not usually as good as the original choice. I would hate to see things move to a namespace land-grab like we have seen in DNS. Has this been raised as an issue before? -- Dirk On Mon, Jun 27, 2011 at 11:36 AM, Peter Saint-Andre wrote: > Based on comments received to date, I've published a heavily-revised > version of the "X-" proposal: > > http://www.ietf.org/id/draft-saintandre-xdash-00.txt > > Further feedback is welcome! > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From internet-drafts@ietf.org Wed Jun 29 15:12:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FE621F855B; Wed, 29 Jun 2011 15:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfOPcNNLZqfY; Wed, 29 Jun 2011 15:12:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1366B21F8554; Wed, 29 Jun 2011 15:12:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110629221254.1797.9456.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2011 15:12:54 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 22:12:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Terminology Used in Internationalization in the IETF Author(s) : Paul Hoffman John C Klensin Filename : draft-ietf-appsawg-rfc3536bis-04.txt Pages : 47 Date : 2011-06-29 This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-04.txt From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Jun 30 00:19:42 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39EA11E8173 for ; Thu, 30 Jun 2011 00:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBbsh5R8fjNK for ; Thu, 30 Jun 2011 00:19:42 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id DC69511E816E for ; Thu, 30 Jun 2011 00:19:41 -0700 (PDT) Received: by pzk27 with SMTP id 27so2394850pzk.27 for ; Thu, 30 Jun 2011 00:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dcqqr1dsaalRVv8T53Ty4E3JZNcCzXv9mOsRg/5bt0g=; b=m+7J3VeFl+c5q3Nfhz8yE5QpmErvbI9t0V7IfxxuCQjWJZ9+BapjkEuJK1qL5Ex7MN buXKznv4EssxVyiljl5p9omiBG/oGUuSIfH1sgBAJCUa/wb5/EwkmWDx8zo6yCo9vWB4 NRmMbhNm5UoGx46gRTUOxQdkD/ye5bnP018hc= Received: by 10.143.35.14 with SMTP id n14mr807958wfj.437.1309418381369; Thu, 30 Jun 2011 00:19:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.89.6 with HTTP; Thu, 30 Jun 2011 00:19:21 -0700 (PDT) In-Reply-To: <4E08CDCB.70902@stpeter.im> References: <4E08CDCB.70902@stpeter.im> From: Frank Ellermann Date: Thu, 30 Jun 2011 09:19:21 +0200 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 07:19:42 -0000 On 27 June 2011 20:36, Peter Saint-Andre wrote: > I've published a heavily-revised version of the "X-" proposal Thanks. The worst case I'm aware of is image/x-icon vs. MIME type image/vnd.microsoft.icon - add this if you need more bad examples. Maybe pick some well-known RFCs and honour them with an "updates", obsoleting their x-foo conventions. IIRC the NetNews RFC also inherited this x-cruft. As Dave wrote, I also considered "x-foo" as cool idea, but it turned out to work like "bar", and we need no "x-" to arrive at "foobar". Wrt RFC 5064, as long as the relevant message format / mail / netnews / MIME / http / etc. RFCs are not updated a BCP calling for updates doesn't help, and developers will continue to invent new x-cruft, because it's their only "officially allowed" option. It could be also tricky to fix x-issues in the future message format and mail STDs, because STDs are not supposed to be very different from the DS. A newer BCP overruling the older DS with an "updates" could justify to adopt the new state of the art in the STD. Or maybe I'm just a bit paranoid... ;-) -Frank From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Jun 30 01:02:13 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4045521F86B4 for ; Thu, 30 Jun 2011 01:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04mohdjWT0Ye for ; Thu, 30 Jun 2011 01:02:12 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B01B021F86B3 for ; Thu, 30 Jun 2011 01:02:12 -0700 (PDT) Received: by pzk5 with SMTP id 5so2101942pzk.31 for ; Thu, 30 Jun 2011 01:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6Ym+MhX4kdthS0OARKxV4+v1khGXXwPXHZGgQu89pmc=; b=YzMjUkdqdDWW8kmthSbrc/MxT7fYLevCFkeLi49tuo0riZxnY+RZWs2o/sWgr6DnLt Q1P0qijo4Jhcj06UyVzdouRm12hJfqzsGJtaiE3Pvr3u0fUiffAJBTprCVfLpGUG4dOx NBXSf+cuWnxpPYUYAicl/4M0YSikRo/EWpl04= Received: by 10.143.35.14 with SMTP id n14mr820689wfj.437.1309420932076; Thu, 30 Jun 2011 01:02:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.89.6 with HTTP; Thu, 30 Jun 2011 01:01:52 -0700 (PDT) In-Reply-To: <4E0AE16A.1010504@gmail.com> References: <0EC26EB10287E2A20769C9CC@PST.JCK.COM> <4E0171EB.4020109@gmail.com> <4E0320A2.6030000@lachy.id.au> <4E040968.3050205@gmail.com> <4E0AE16A.1010504@gmail.com> From: Frank Ellermann Date: Thu, 30 Jun 2011 10:01:52 +0200 Message-ID: To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps-discuss list Subject: Re: [apps-discuss] Last Call: (The 'about' URI scheme) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 08:02:13 -0000 On 29 June 2011 10:25, Mykyta Yevstifeyev quoted: >> For a number of now-in-use, though not special-purpose, 'about' >> URIs the reader would be pointed to >> http://en.wikipedia.org/wiki/About_URI_scheme IBTD, Wikipedia relies on 3rd party sources, not the other way around. And Wikipedia pointers in RFCs should use permalinks to specific versions of articles. I could edit this article in a totally unsuited way, and it could take hours or days until somebody reverts it to a reasonable state. Worse, many folks know how to circumvent Wikipedia rules in hard to detect ways (for articles not on many watchlists). The current draft does not have any additional examples, so for the third time I urge you to add about:about as *good* example - nobody claims that it works everywhere, let alone as it should, or that it needs to be registered. But for users and developers it would be very helpful if they can learn which relevant about: URIs exist in the product they are interested in. -Frank From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Jun 30 01:10:27 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E04B21F851A for ; Thu, 30 Jun 2011 01:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH2BnerSYuQ5 for ; Thu, 30 Jun 2011 01:10:26 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id A98F721F860B for ; Thu, 30 Jun 2011 01:10:25 -0700 (PDT) Received: by pvh18 with SMTP id 18so1954667pvh.31 for ; Thu, 30 Jun 2011 01:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=DDieJY6brkoLyCEb4axuRG5V50OtgrHCkduD50lZjSk=; b=iHPvUiGqO5VhwbuLsQJFRhTJxMXj2kUnAgzAeR+4h3KghgO3I2BtVYXf1P5+nuZJkC bTFzOiealY43RNY8byJ2HlN5R/7Feyg545FWyAXTjbpkRlZkdENvY+FruVCHm/J72Z3/ GKvPvriGvyrn99LVUjXUlHyjztjumHG6uonzg= Received: by 10.142.212.3 with SMTP id k3mr887557wfg.323.1309421390413; Thu, 30 Jun 2011 01:09:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.89.6 with HTTP; Thu, 30 Jun 2011 01:09:30 -0700 (PDT) In-Reply-To: <20110629011408.4466.1816.idtracker@ietfa.amsl.com> References: <20110629011408.4466.1816.idtracker@ietfa.amsl.com> From: Frank Ellermann Date: Thu, 30 Jun 2011 10:09:30 +0200 Message-ID: To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 08:10:27 -0000 > On 29 June 2011 03:14, wrote: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-03.txt At least one of the www.ietf.org servers does not know this URL, but s/www/tools/ worked for me. From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Jun 30 01:24:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7652821F878C for ; Thu, 30 Jun 2011 01:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJrx16JULO4D for ; Thu, 30 Jun 2011 01:24:38 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2ED21F878A for ; Thu, 30 Jun 2011 01:24:38 -0700 (PDT) Received: by pzk5 with SMTP id 5so2124270pzk.31 for ; Thu, 30 Jun 2011 01:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=OhM41p6Mc2QeaoeCSwSlNrJUU+GAMInx5k+apXxDwRU=; b=kq85uwh/DBysSlifIWbmVa4i5GdE3ptdtdSxLSGSpayMAAbq/25MEvaotSPrJ/F7Dh Ca1+C3AbharpuyhJHAHqft80cynR+Pnes5kAmD6g7lGy45y5csq0r4K6KoqWpvIIr9Vm pqqGoseKefn37TBE4BnrSm9BzUxtDgxubvpEI= Received: by 10.142.44.16 with SMTP id r16mr849394wfr.406.1309422277357; Thu, 30 Jun 2011 01:24:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.89.6 with HTTP; Thu, 30 Jun 2011 01:24:17 -0700 (PDT) In-Reply-To: <4E083D3F.6030200@gmx.de> References: <4E083D3F.6030200@gmx.de> From: Frank Ellermann Date: Thu, 30 Jun 2011 10:24:17 +0200 Message-ID: To: maileohye@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 08:24:38 -0000 > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : The Canonical Link Relation > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Maile Ohye > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ohye-canonical-link-relati= on-00.txt A relative canonical URL can't be a good idea. If there is more than one "content URL" (in the terminology of the draft) this would result in more than one canonical URL, defeat the purpose, and worse, this could make googlebot angry. The draft could s/SHOULD NOT/MUST NOT/, I don't see any good reason to violate a SHOULD NOT, and if that's correct MUST NOT is clearer. -Frank From eburger@standardstrack.com Thu Jun 30 04:23:02 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DF321F87F1 for ; Thu, 30 Jun 2011 04:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3DA0YXZ+aOU for ; Thu, 30 Jun 2011 04:23:00 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAD721F87EF for ; Thu, 30 Jun 2011 04:23:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=NMqctOExAPMkAtTQu2casxNYe3+EwijRcaC/p/ei+FYXvgLXG5iXdWJ5ZTVsOmmSinEpq+M7ThHOimX/UPUPWl3SX6egOZHw58SHGBJREiz5WPa5mGOeLAjrINvO6uY7; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.126]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QcFKj-0002t0-Ho; Thu, 30 Jun 2011 04:22:57 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-68-413294549; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: Date: Thu, 30 Jun 2011 07:22:56 -0400 Message-Id: References: <4E08CDCB.70902@stpeter.im> To: Dirk Pranke X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: General application-layer protocols discussion of Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 11:23:02 -0000 --Apple-Mail-68-413294549 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The difference between protocol parameters and domain names is domain = names are meant for human consumption, while protocol parameters are = arbitrary strings of ASCII or UTF-8 text. A protocol might use the = string "kritisch" to mean "something critical." Great -- people building = user interfaces will read the RFC, know that parameter is "kritisch" and = will display "critical," "crucial," "krytyczny," or whatever is = appropriate for the user. For that matter, one could really use the = string "foobar" to mean "something criticial" or even the number 42. The = protocol will work just fine, and users (who do NOT read what is on the = wire) can have a great experience. The point is *this* name space is huge and fungible, whereas the DNS is = large and NOT fungible. On Jun 29, 2011, at 6:05 PM, Dirk Pranke wrote: > Your draft has: >=20 >> In some situations, segregating the name space of parameters used in >> a given application protocol can be justified: >> ... >> 2. When parameter names might have significant meaning. This case >> is rare, since implementers can almost always find a synonym >> (e.g., "urgency" instead of "priority") or simply invent a new >> name. >=20 > It seems to me that a primary benefit of the "X-" convention is that > it makes unprefixed parameter names less socially acceptable; i.e., > there's a pretty clear rule of thumb that if the name isn't X- > prefixed, it probably has seen a pass through a committee and hence it > stands at least a chance of having the same meaning in multiple > implementations. >=20 > I am concerned that if you abandon the X- practice, you will lose this > benefit and finding untainted, available parameter names might become > harder. Sure, you can often find a synonym, but it is not usually as > good as the original choice. I would hate to see things move to a > namespace land-grab like we have seen in DNS. >=20 > Has this been raised as an issue before? >=20 > -- Dirk >=20 >=20 > On Mon, Jun 27, 2011 at 11:36 AM, Peter Saint-Andre = wrote: >> Based on comments received to date, I've published a heavily-revised >> version of the "X-" proposal: >>=20 >> http://www.ietf.org/id/draft-saintandre-xdash-00.txt >>=20 >> Further feedback is welcome! >>=20 >> Peter >>=20 >> -- >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail-68-413294549 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA2MzAxMTIyNTZaMCMGCSqGSIb3DQEJ BDEWBBSwZpIysXn08JnWlwbbeqZrokoqGTCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAEHFfbi/spyWHL0RYSB2ie1L9N/JGbc6yTgNanFAGd9SnV4A YFJwYpTfQL8UMH96wTV84GpsDxYRHdq3796AIr2IFEn6QiLg5B9uJ/sTPuyz1W4KmGvSJ+Pkm6wm EbKhPNVFhgHDonQ5OJxJraoWNbUE+Js7r+mw1T2oTSh/pv7lwa5ERQnGraqf7hnLFi0lJLCtJgI/ iaxDbGEkv8J7Zyc82HbIE5eLw5DmAaEkuizd1DvVOIPwQYUYO5oXkdaUo6xvvFxl3Y2PaZRCMqmY X0qkZf2y1OuTyazNWhWX2j/3MbGu4L6Awl8BSY53g8X2qFhIeVD+q7xuwi6AhmAtL84AAAAAAAA= --Apple-Mail-68-413294549-- From dpranke@google.com Thu Jun 30 11:46:07 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4551511E80AC for ; Thu, 30 Jun 2011 11:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gvLknRxAkMy for ; Thu, 30 Jun 2011 11:46:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE1F11E8077 for ; Thu, 30 Jun 2011 11:46:06 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p5UIk22v024470 for ; Thu, 30 Jun 2011 11:46:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309459562; bh=Y6t/7q0Fc2HFejzvh7wN9ztuyjs=; h=MIME-Version:Sender:In-Reply-To:References:From:Date:Message-ID: Subject:To:Cc:Content-Type:Content-Transfer-Encoding; b=fDAFZQr7fW5lzHlNE3jOl7R/F6/GF4VaSt5TTowpq2m/VVmiacOkopJfXSs70MyA1 KPSE5svKTw6yXDYPv6wdw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:sender:in-reply-to:references:from: date:x-google-sender-auth:message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=fh4Kz0BLI9hjNtMp9ay/cZsS9yB05YsdgoyKXOzuPTbdr+zpU0m1hJedhrno9iN4b vqtUKWELEATLKP166M8Ng== Received: from pvc21 (pvc21.prod.google.com [10.241.209.149]) by hpaq6.eem.corp.google.com with ESMTP id p5UIi0gJ012252 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 30 Jun 2011 11:46:01 -0700 Received: by pvc21 with SMTP id 21so2929226pvc.39 for ; Thu, 30 Jun 2011 11:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=eSYnOISNA9UierdVrX8TIEgnHnGRWbghrj9iIZb8y6U=; b=brxBAqeQB7aoSqrI3LnChaAK/+V/V55+5G/y/C6IWVbBH/Qrn3JDjUtAMETRnOBtA6 6kCRR4SPyFdPdC55Tfyg== Received: by 10.142.136.18 with SMTP id j18mr1056299wfd.284.1309459560439; Thu, 30 Jun 2011 11:46:00 -0700 (PDT) MIME-Version: 1.0 Sender: dpranke@google.com Received: by 10.142.193.2 with HTTP; Thu, 30 Jun 2011 11:45:40 -0700 (PDT) In-Reply-To: References: <4E08CDCB.70902@stpeter.im> From: Dirk Pranke Date: Thu, 30 Jun 2011 11:45:40 -0700 X-Google-Sender-Auth: rM36F6BE1jSdCJQlefKFY8dvjYo Message-ID: To: Eric Burger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: General application-layer protocols discussion of Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 18:46:07 -0000 If we wanted protocol parameters to be arbitrary strings, we'd just use huffman-encoded binary data or something similar. We don't, and it is well acknowledged that having protocols composed of human-readable text has a lot of advantages. In addition, since the protocol *is* text and not always hidden behind an API, the protocol *is* the API, and a well-designed API is easier to use. -- Dirk On Thu, Jun 30, 2011 at 4:22 AM, Eric Burger w= rote: > The difference between protocol parameters and domain names is domain nam= es are meant for human consumption, while protocol parameters are arbitrary= strings of ASCII or UTF-8 text. A protocol might use the string "kritisch"= to mean "something critical." Great -- people building user interfaces wil= l read the RFC, know that parameter is "kritisch" and will display "critica= l," "crucial," "krytyczny," or whatever is appropriate for the user. For th= at matter, one could really use the string "foobar" to mean "something crit= icial" or even the number 42. The protocol will work just fine, and users (= who do NOT read what is on the wire) can have a great experience. > > The point is *this* name space is huge and fungible, whereas the DNS is l= arge and NOT fungible. > > On Jun 29, 2011, at 6:05 PM, Dirk Pranke wrote: > >> Your draft has: >> >>> =C2=A0In some situations, segregating the name space of parameters used= in >>> =C2=A0a given application protocol can be justified: >>> =C2=A0... >>> =C2=A02. =C2=A0When parameter names might have significant meaning. =C2= =A0This case >>> =C2=A0 =C2=A0 =C2=A0is rare, since implementers can almost always find = a synonym >>> =C2=A0 =C2=A0 =C2=A0(e.g., "urgency" instead of "priority") or simply i= nvent a new >>> =C2=A0 =C2=A0 =C2=A0name. >> >> It seems to me that a primary benefit of the "X-" convention is that >> it makes unprefixed parameter names less socially acceptable; i.e., >> there's a pretty clear rule of thumb that if the name isn't X- >> prefixed, it probably has seen a pass through a committee and hence it >> stands at least a chance of having the same meaning in multiple >> implementations. >> >> I am concerned that if you abandon the X- practice, you will lose this >> benefit and finding untainted, available parameter names might become >> harder. Sure, you can often find a synonym, but it is not usually as >> good as the original choice. I would hate to see things move to a >> namespace land-grab like we have seen in DNS. >> >> Has this been raised as an issue before? >> >> -- Dirk >> >> >> On Mon, Jun 27, 2011 at 11:36 AM, Peter Saint-Andre = wrote: >>> Based on comments received to date, I've published a heavily-revised >>> version of the "X-" proposal: >>> >>> http://www.ietf.org/id/draft-saintandre-xdash-00.txt >>> >>> Further feedback is welcome! >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> _______________________________________________ >>> 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 behnam@gmail.com Thu Jun 30 13:56:43 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCAE11E80AA for ; Thu, 30 Jun 2011 13:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfmfQ9-X1+94 for ; Thu, 30 Jun 2011 13:56:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 951D411E80A7 for ; Thu, 30 Jun 2011 13:56:42 -0700 (PDT) Received: by iye7 with SMTP id 7so2882949iye.31 for ; Thu, 30 Jun 2011 13:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=PG8GFuqUg/PZb404puQwaf6Xvj3crT4AHW4P8hBcEzA=; b=grhY5zOgk4/XUWjcY9Usp5rm1CTo8Uv1nqLSxWmGLNrf6Z/+vgiwd8dlo7227BbL3V 3GPOl7rtuW+Vgl6vb4iLpKWvGMR5cGYZLl8BHyQCrkqjKE2gujaRqhhmacqiiEz0fiFK NG6lmBcmuNDEbDyNKRWsoAbhCFW0FLjtIEvj8= Received: by 10.231.202.200 with SMTP id ff8mr2016395ibb.145.1309467402107; Thu, 30 Jun 2011 13:56:42 -0700 (PDT) MIME-Version: 1.0 Sender: behnam@gmail.com Received: by 10.231.15.139 with HTTP; Thu, 30 Jun 2011 13:56:02 -0700 (PDT) From: Behnam Esfahbod Date: Thu, 30 Jun 2011 16:56:02 -0400 X-Google-Sender-Auth: cQEHrX2KYxVgX8RE8_CFXN3gdJg Message-ID: To: apps-discuss Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 20:56:43 -0000 Hello, The restriction rules of the latest draft for "Top Level Domain Name Specification", section 4 [1], is unfortunately very restrictive for some languages, including Persian language (in Arabic script). """ =C2=A0 2. =C2=A0the derived property value of all code points, as defined b= y =C2=A0 =C2=A0 =C2=A0 [RFC5890], is PVALID; =C2=A0 3. =C2=A0the general category of all code points, is one of { Ll, Lo= , Lm, =C2=A0 =C2=A0 =C2=A0 Mn }. """ These restrictions are simply ignoring the characters with CONTEXTJ derived property value, which was added to IDNA2008 protocol to support Persian (and some Indic languages) in domain name labels [2]. Restricting TLD DNS-labels to only PVALID characters makes it impossible to write very basic words of Persian language. For example, "=D8=AE=D8=A7=D9=86=D9=87=E2=80=8C= =D9=87=D8=A7" (English: houses) and "=DA=A9=D9=88=D9=87=E2=80=8C=D9=87=D8=A7" (mountains) which are basic P= ersian words include U+200C (ZERO WIDTH NON-JOINER or ZWNJ) and it is impossible to write those words in Unicode without using ZWNJ. IDNA2003 didn't support ZWNJ in lables and that practically made the standard broken for Persian language. Now that this problem has been resolved, we expect that TLD DNS-Labels also benefit from the effort that has been put into the new standard and allow the CONTEXTJ characters, specially U+200C (ZWNJ), in TLD DNS-Labels. Hereby, I would like to request reconsidering the restriction rules of TLD DNS-Labels and to allow characters with CONTEXTJ derived property value in the labels. (Of course the IDNA2008 contextual restrictions for CONTEXTJ characters must apply.) Thanks in advance, -Behnam Esfahbod ISOC and ICANN TLD Variant Issue Project, Arabic-Script Case Study Team mem= ber 1: https://tools.ietf.org/html/draft-liman-tld-names-05#section-4 2: https://tools.ietf.org/html/rfc5894#section-3.1.2 From liang.liang12@zte.com.cn Thu Jun 30 18:01:00 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C2621F8814 for ; Thu, 30 Jun 2011 18:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bbnBWeViahr for ; Thu, 30 Jun 2011 18:00:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBDA21F8812 for ; Thu, 30 Jun 2011 18:00:58 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131321193944097; Fri, 1 Jul 2011 08:57:16 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.1193944097; Fri, 1 Jul 2011 09:00:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6110fTF024657 for ; Fri, 1 Jul 2011 09:00:41 +0800 (GMT-8) (envelope-from liang.liang12@zte.com.cn) To: apps-discuss MIME-Version: 1.0 X-KeepSent: 355208F3:25BF1A93-482578C0:0003CD25; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.liang12@zte.com.cn Date: Fri, 1 Jul 2011 09:00:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-01 09:00:42, Serialize complete at 2011-07-01 09:00:42 Content-Type: multipart/alternative; boundary="=_alternative 00058BB4482578C0_=" X-MAIL: mse01.zte.com.cn p6110fTF024657 Subject: [apps-discuss] FW: New Version(-01) for VDI(Virtual Desktop Infrastructure) problem statement document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2011 01:01:00 -0000 This is a multipart message in MIME format. --=_alternative 00058BB4482578C0_= Content-Type: text/plain; charset="US-ASCII" Dear All, We just published version-01 for VDI problem statement, reworked based on comments from different sources. Thanks a lot for your valuable comments! Following is the detail for version-01 document, pls. help review it and welcome any further comments. ------------------------------------------------------------------------------- Filename: draft-wang-appsawg-vdi-problem-statement Revision: 01 Title: Virtual Desktop Infrastructure Problem Statement Creation date: 2011-06-30 WG ID: Individual Submission Number of pages: 16 Abstract: The Virtual Desktop Infrastructure is a technology to separate local desktop and remote computing/storage resources, which was initially derived from the remote desktop administration but with new business models and very different use cases. Most of existing VDI systems are based on proprietary implementation, and positioning different market with different features. Since virtual desktop technology is believed to be a mainstream application delivery method, like http protocol against web applications, so it's important to make the virtual desktop access protocol open and standard. This draft summarizes the limitations of existing virtual desktop systems, and proposes the intent standardization work in IETF. URL: http://datatracker.ietf.org/doc/draft-wang-appsawg-vdi-problem-statement/ ------------------------------------------------------------------------------- In last mail we didn't describe why we submitted our drafts in IETF APPSAWG and it confused many, including our chairman. So I want to say sorry for that. Now I want to explain it briefly: - In current cloud-computing age, more and more "physical computer" will be moved into cloud. For end-user whose computers run in the cloud, people will use some kind of clients to connect to their remote computers. Currently this is adopted by enterprises around the world, and we believe it will be widely adopted by both enterprise and consumer market in near future, just like HTTP we used today. - Currently there are different protocols for communication between user and remote computer, like VNC, SPICE and etc (described in the survey document). And at the same time there will be some trouble if we don't standardize this protocol, which is described in the problem statement document. - VDI protocol runs on top of existing transport and network layer, and it is one application protocol, like HTTP. Because it will re-use many protocols designed in IETF, like TCP/IP, TLS/DTLS and etc, we think IETF is the best place. And IETF APPSAWG focuses on protocols presented in user-oriented programs, so we submit these two documents in APPSAWG. Have a nice day! Thanks, Liang -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00058BB4482578C0_= Content-Type: text/html; charset="US-ASCII"
Dear All,

We just published version-01 for VDI problem statement, reworked based on comments
from different sources. Thanks a lot for your valuable comments! Following is
the detail for version-01 document, pls. help review it and welcome any further
comments.

-------------------------------------------------------------------------------
Filename:                  draft-wang-appsawg-vdi-problem-statement
Revision:                  01
Title:                                   Virtual Desktop Infrastructure Problem Statement
Creation date:                  2011-06-30
WG ID:                                   Individual Submission
Number of pages: 16

Abstract:
  The Virtual Desktop Infrastructure is a technology to separate local
  desktop and remote computing/storage resources, which was initially
  derived from the remote desktop administration but with new business
  models and very different use cases.  Most of existing VDI systems
  are based on proprietary implementation, and positioning different
  market with different features.  Since virtual desktop technology is
  believed to be a mainstream application delivery method, like http
  protocol against web applications, so it's important to make the
  virtual desktop access protocol open and standard.  This draft
  summarizes the limitations of existing virtual desktop systems, and
  proposes the intent standardization work in IETF.
URL: http://datatracker.ietf.org/doc/draft-wang-appsawg-vdi-problem-statement/
-------------------------------------------------------------------------------

In last mail we didn't describe why we submitted our drafts in IETF APPSAWG and it
confused many, including our chairman. So I want to say sorry for that. Now I want
to explain it briefly:
- In current cloud-computing age, more and more "physical computer" will be moved
into cloud. For end-user whose computers run in the cloud, people will use some
kind of clients to connect to their remote computers. Currently this is adopted
by enterprises around the world, and we believe it will be widely adopted by
both enterprise and consumer market in near future, just like HTTP we used today.
- Currently there are different protocols for communication between user and remote
computer, like VNC, SPICE and etc (described in the survey document). And at the
same time there will be some trouble if we don't standardize this protocol, which
is described in the problem statement document.
- VDI protocol runs on top of existing transport and network layer, and it is one
application protocol, like HTTP. Because it will re-use many protocols designed in
IETF, like TCP/IP, TLS/DTLS and etc, we think IETF is the best place. And IETF
APPSAWG focuses on protocols presented in user-oriented programs, so we submit
these two documents in APPSAWG.

Have a nice day!

Thanks,
Liang
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00058BB4482578C0_=-- From dhc@dcrocker.net Thu Jun 30 20:13:52 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FD61F0C41 for ; Thu, 30 Jun 2011 20:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S9cIkmqAuoD for ; Thu, 30 Jun 2011 20:13:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BE9DA1F0C35 for ; Thu, 30 Jun 2011 20:13:51 -0700 (PDT) Received: from [192.168.1.147] (ppp-68-120-198-5.dsl.pltn13.pacbell.net [68.120.198.5]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p613Dk8d011226 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 30 Jun 2011 20:13:51 -0700 Message-ID: <4E0D3B64.5020500@dcrocker.net> Date: Thu, 30 Jun 2011 20:13:40 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4E08CDCB.70902@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 30 Jun 2011 20:13:51 -0700 (PDT) Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jul 2011 03:13:52 -0000 Eric, On 6/30/2011 4:22 AM, Eric Burger wrote: > The difference between protocol parameters and domain names is domain names are meant for human consumption, while protocol parameters are arbitrary strings of ASCII or UTF-8 text. A protocol might use the string "kritisch" to mean "something critical." Great -- people building user interfaces will read the RFC, know that parameter is "kritisch" and will display "critical," "crucial," "krytyczny," or whatever is appropriate for the user. For that matter, one could really use the string "foobar" to mean "something criticial" or even the number 42. The protocol will work just fine, and users (who do NOT read what is on the wire) can have a great experience. You have the theory down exactly correctly, IMO. The practice however matches the theory only partially. Were all fieldnames fully registered, it would probably match completely, but they aren't. In point of fact, most header fields are meant for human consumption and that includes their fieldnames, which frequently are entirely ad hoc and can't be predictably translated. > The point is *this* name space is huge and fungible, whereas the DNS is large and NOT fungible. I guess I'm missing what the import is, for the distinction(s) you are making. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From evnikita2@gmail.com Thu Jun 30 20:26:50 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769761F0C4F; Thu, 30 Jun 2011 20:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l54glfAynd55; Thu, 30 Jun 2011 20:26:50 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEC61F0C4B; Thu, 30 Jun 2011 20:26:49 -0700 (PDT) Received: by fxe4 with SMTP id 4so3627917fxe.27 for ; Thu, 30 Jun 2011 20:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C68y6oF2J46LdaDar+rb31HojWC5rEEiss9m7ZYOCfc=; b=Pkmc8A8KMaCthIuQhANJK1QX7uimRbuJi9ES9xNCoyuL40JwCsQceXG6uHS35DClgm JGoQKgIotPv/zozEq/eB8Xz7PIJZn9VQnaWu2DXypYOKgrowlJAmGpGOj+DIIA4yc4LH TjziigD8KdM9IT63+cN69S4oSOjFKjLb/yrFo= Received: by 10.223.59.92 with SMTP id k28mr4056953fah.27.1309490808651; Thu, 30 Jun 2011 20:26:48 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 21sm1902916fay.21.2011.06.30.20.26.46 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 20:26:47 -0700 (PDT) Message-ID: <4E0D3EA5.7010803@gmail.com> Date: Fri, 01 Jul 2011 06:27:33 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "link-relations@ietf.org" , IETF Apps Discuss References: <4E083D3F.6030200@gmx.de> In-Reply-To: <4E083D3F.6030200@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2011 03:26:50 -0000 Hello Maile, Several comments to your draft-ohye-canonical-link-relation-00. There is the Intended Status missing in it. I suppose Informational should be fine. > 1. Introduction > > The canonical link relation specifies the preferred version of a URI I think some introductory text on linking, probably based on RFC 5988, should go here. Section 2: > Presence of the canonical link relation indicates > to applications, such as search engines, that they MAY: I wonder why it's MAY; in this case implementations (explicitly, those apps which interpret Link: headers and corresponding construction in HTML) will be free to ignore it. I think normative SHOULD should be OK (sorry for pun). I support the remark from Frank Ellermann (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02870.html) about SHOULD NOTs in the document. > The value of the target/canonical URI MAY: I suppose omitting "value of the" should be better, since there is no such term in RFC 3986. In fact, when referring the URI, we mean its value, meaning. > o Exist on a different protocol: http to https, or vice versa You probably meant URI scheme here, since https isn't a separate protocol. As before these points we had "The value of the target/canonical URI MAY" or, if you consider my comment above, "The target/canonical URI MAY", this point may be reworded as "Have different scheme names" (which suits the second variant of a preface to this list better). Reading section 3 and 5 of the draft, it seems that is mandates use of HTTP when referring to canonical URIs. And what is the situation when target URI is a 'ftp' or 'gopher' URI? Section 3 allows different scheme names in context/target URIs, if I understand it correctly. Therefore, unless it is deliberately, I think any mention of HTTP should be replaced by more generic regulations. > 8. Internationalisation Considerations > > In designating a canonical URI, please see [RFC3986] for information > on URI encoding. URIs themselves are not internationalized, in terms of RFC 3536, which defined: > internationalization > > In the IETF, "internationalization" means to add or improve the > handling of non-ASCII text in a protocol. IRIs serve for this purpose. I recommend either to rename the section to Encoding considerations or skip it at all ( I personally like 2nd variant). Thanks, Mykyta Yevstifeyev 27.06.2011 11:20, Julian Reschke wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : The Canonical Link Relation > Author(s) : Maile Ohye > Filename : draft-ohye-canonical-link-relation-00.txt > Pages : 6 > Date : 2011-06-26 > From evnikita2@gmail.com Thu Jun 30 21:06:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D29E1F0C3B for ; Thu, 30 Jun 2011 21:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 223ZdytzoTmy for ; Thu, 30 Jun 2011 21:06:09 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEAC1F0C57 for ; Thu, 30 Jun 2011 21:06:09 -0700 (PDT) Received: by fxe4 with SMTP id 4so3647398fxe.27 for ; Thu, 30 Jun 2011 21:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=D7Xyg+c2GPljPKzDIjOxQ6JBeseRosAp5+tWnYT7fxU=; b=ngV6KDjHfIeFe5XIqAUnzHHZDop9dv2KkQVIKVTnrVTnSmRlbncp1c9yoQjDRJxUXJ XtWw+5k8WwJX7HTpOELt5GqVDGIvr4v1IseG2muJlDYkSNubgdAbCZj2Jc5SQIebnrWZ eFOPd/8ljJEiZDyXS6Jkp2YYKTitysq9DS9E4= Received: by 10.223.143.67 with SMTP id t3mr3979404fau.105.1309491065164; Thu, 30 Jun 2011 20:31:05 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id e16sm2034449fak.41.2011.06.30.20.31.03 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 20:31:03 -0700 (PDT) Message-ID: <4E0D3FA5.8060504@gmail.com> Date: Fri, 01 Jul 2011 06:31:49 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4DAF5256.2040303@isode.com> In-Reply-To: <4DAF5256.2040303@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2011 04:06:10 -0000 Is it going to result in something? Mykyta 21.04.2011 0:38, Alexey Melnikov wrote: > Dear APPSAWG participants, > There has been an active discussion about the document this week. > Given that, I would like to ask the following questions: > > 1). Who is willing to review and post comments on the document if the > WG accepts this document as a WG document? > > 2). Are there any objections to accepting this document as a WG document? > > If you have an objection, please be explicit about the nature of the > objection (for example, if you think the document is harmful and > shouldn't be worked on). Note that just saying that you don't like the > document is not a good enough reason without further explanation. > > Explicit statements in favor of accepting are welcomed as well. But > please also respond if you find objections by others to be > objectionable ;-). > > You can send both objections and your statements of support directly > to me (if you wish) or to the mailing list. > > Please send your responses by the end of April 29th. > > Alexey, > as an APPSAWG co-chair >