Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986113A6832 for ; Sun, 27 Jun 2010 22:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srZRqX5HGrz2 for ; Sun, 27 Jun 2010 22:37:33 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 8911F3A67E5 for ; Sun, 27 Jun 2010 22:37:33 -0700 (PDT) Received: by pvd12 with SMTP id 12so647326pvd.31 for ; Sun, 27 Jun 2010 22:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=xaRYHrsvgelaVR1NpUAQ1+Yhgp2GHouvpy8MDty8NeU=; b=tL62wB2CsRshJ0USEQ7Y1qfwk3CmA5iQnq6p3AJribpAU1/DfLw+755ktmHxB549g/ pacQMMa35H9bkGJl6v+lCVQXLjJs+KAEE1EhTrxRCi1+h0aQyC8CpQQhT4Ep3/ihZQuQ xRP1Lhza7pZNQtMHccNqFV1T25hbiv6sqfAmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=JfsMA1hlNgrBLde/EgQs2ZqYMgFd7SdJU2TWbhM7P+dR2F4OuDvXPK0siG4fdI0XqQ iCkV4rzyBQbM8XV99E/DTuxbNQWU7VkqkAvkFjSaSswrMhXrndkN0ofnacOyDu5bIGtH LiyKzyq1oNSIwByPHyWuwq1/+E83K+TvSLXAA= Received: by 10.142.178.2 with SMTP id a2mr43569wff.308.1277703458925; Sun, 27 Jun 2010 22:37:38 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id b12sm11000267rvn.22.2010.06.27.22.37.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 27 Jun 2010 22:37:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-12-896029306 From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 27 Jun 2010 22:37:36 -0700 Message-Id: <269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1081) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 05:37:34 -0000 --Apple-Mail-12-896029306 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I vote for (3) unless a good (4) is suggested. On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: > Over the past year many people expressed concerns about the use of the = =91realm=92 WWW-Authenticate header parameter. The parameter is defined = in RFC 2617 as required, and is allowed to have scheme-specific = structure. > =20 > We have a few options: > =20 > 1. Leave it as required under the definition of RFC 2617 (i.e. provide = no help, developers will need to ready 2617 and figure out what to do = with it). > 2. Update 2617 to remove the requirement =96 this is not going to be = easy or possible to predict success. > 3. Provide specific guidance as to what to do with the realm = parameter. > 4. Something else. > =20 > Comments? > =20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-12-896029306 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I vote for (3) unless a good (4) is = suggested.

On 2010-06-27, at 6:51 PM, Eran = Hammer-Lahav wrote:

Over the past year many people = expressed concerns about the use of the =91realm=92 WWW-Authenticate = header parameter. The parameter is defined in RFC 2617 as required, and = is allowed to have scheme-specific structure.
We have a few = options:
 
2. Update 2617 to remove the = requirement =96 this is not going to be easy or possible to predict = success.
3. Provide specific guidance as to = what to do with the realm parameter.