Re: [apps-discuss] The acct: scheme question

"Paul E. Jones" <paulej@packetizer.com> Thu, 24 May 2012 15:15 UTC

Return-Path: <paulej@packetizer.com>
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 6DC2921F8512 for <apps-discuss@ietfa.amsl.com>; Thu, 24 May 2012 08:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHAQ77CBoWh9 for <apps-discuss@ietfa.amsl.com>; Thu, 24 May 2012 08:14:59 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 568BB21F84EA for <apps-discuss@ietf.org>; Thu, 24 May 2012 08:14:59 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q4OFEvn3016515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 May 2012 11:14:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1337872498; bh=tAqrR5WiYpn5pVZbnNmEJ9tPUhwGJAVmDchWlRmrBt0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=TBNSVSR3EC+Z3qh/OMNdozfY4o88ORA25a2fHnpOVROK6tnFLr7M1n5anyrkF/qPo D8y4+HHOIzHQoXXOpoeL6JvpRj/MkF5hDU0FFCT1Y+HshlVuHTJxAzPtVJoXrLgDFG epf76H/RlE0J54K1cTkhrkNF1t3+94fZN2fLyQwI=
From: "Paul E. Jones" <paulej@packetizer.com>
To: 'John Bradley' <ve7jtb@ve7jtb.com>
References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B1680429673943665131A7@TK5EX14MBXC284.redmond.corp.microsoft.com> <7BCF42BF-127F-478B-A922-1E84D087A0F3@ve7jtb.com> <4FBBE0A6.5040906@stpeter.im> <B3B7CC14-B6E2-40FC-BA84-427CEE96A8E5@ve7jtb.com> <1337714535.85430.YahooMailNeo@web31806.mail.mud.yahoo.com> <4FBBEF0C.1020108@stpeter.im> <45370D62-B0A0-43F3-831F-BCAFA3959F8F@ve7jtb.com> <CAKaEYhJEWChPS4MS8pa+trqSNsmDS=dbD0gjK4Lu84a_=Lgbiw@mail.gmail.com> <1337798245.55153.YahooMailNeo@web31810.mail.mud.yahoo.com> <04f601cd3957$14ea4d90$3ebee8b0$@packetizer.com> <f5b396pzwkg.fsf@calexico.inf.ed.ac.uk> <058101cd39b6$02a28990$07e79cb0$@packetizer.com> <811BB5B1-74BB-4754-B064-DD198FCCADB6@ve7jtb.com>
In-Reply-To: <811BB5B1-74BB-4754-B064-DD198FCCADB6@ve7jtb.com>
Date: Thu, 24 May 2012 11:15:05 -0400
Message-ID: <059101cd39c0$002bd8b0$00838a10$@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: AQHACExhZgXedi2je/bJAOmWfz8jRwJNCmz6AWqGqq0A5pqAzQFvsme0Ae5wlHMCDZAj4AI8tnIJAV3lJy8CtExKPwKYSG+wAavAi3cBeGulnwKuOh8/li1LaXA=
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] The acct: scheme question
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2012 15:15:00 -0000

John,

It seems that most people largely agree with the procedures we've defined
now; I've seen no other proposed changes (noting -05 contained only a very
few).  It also seems that most people see the utility for "acct", even
though other URIs might be used for some use cases (e.g., mail client
configuration or XMPP client configuration).

The only remaining concern I see is with approval of "acct" and delays that
might happen.  I think that if properly positioned for what "acct" is, it
would be opposed.  If there was opposition, though, we could always split
the draft into two pieces in order to get the draft moved to RFC status.  Of
course, I'd prefer to keep all of the text together, but I would prefer to
not hold up progress on OpenID Connect.

Paul

> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Thursday, May 24, 2012 10:27 AM
> To: Paul E. Jones
> Cc: Henry S. Thompson; apps-discuss@ietf.org Discuss
> Subject: Re: [apps-discuss] The acct: scheme question
> 
> The question comes down to the same one that has been discussed in the
> past.
> 
> What to use as a abstract identifier for a user.
> 
> I am sympathetic to the use of acct:
> 
> However I have not been convinced that it belongs in WF directly.
> 
> Until acct: is an approved URI I am not keen to have openID Connect take a
> normative reference to it.
> 
> If the WG and the chairs decide to do it as one spec,  that will likely
> impact our decision to reference WF for discovery.
> 
> That is just a personal opinion and the Connect WG will need to take the
> decision.
> 
> John B.
> 
> 
> On 2012-05-24, at 10:03 AM, Paul E. Jones wrote:
> 
> > Henry,
> >
> >> Paul E. Jones writes:
> >>
> >>> The "acct" URI scheme has a narrow scope . . . I suspect
> >>> appreciation for that URI scheme will grow with wider deployment of
> >>> WebFinger, though.
> >>
> >> I find those two statements bordering on the contradictory.  It is
> >> precisely because if it does indeed turn out that acct: URIs address
> >> a real need, they will 'leak' out of WF and into wider contexts (i.e.
> >> "appreciation . . . will grow"), and so acct: needs review as such in
> >> the normal way any new URI scheme needs review.
> >
> > It wasn't intended to be.  Several have said before that they do not
> > like "acct" and prefer something else.  However, I think that is because
> "acct"
> > is presently not widely deployed and the novelty concerns people.  It
> > has been suggested, for example, to use the URI scheme "mailto"
> > instead.  So, my intent was just to say that once "acct" is adopted
> > for querying for a user's account information using "acct", people
> > will appreciate it more than they do now.  I think back on the
> > examples I've given where I feel "mailto" just isn't right because it
> > relates to email and some of my accounts on the Internet have no
> relationship to email.
> >
> > That's not to say that "mailto" could not be used.  If the OpenID spec
> > declared that was the URI to use, then that's what that protocol
> > mandates and I'd have no objection to it.  What I'd like to see mailto
> > used for, though, is to provide information to my mail client so it
> > can be provisioned.  Someone referred to RFC 6186 as a way to do that,
> > but that RFC only specifies what POP, IMAP, and SMTP servers to use
> > globally.  Users are often clustered on certain machines and I'd
> > personally like to see a link relation called "config-email" that has
> > a URI that, when queried, would return JSON like this:
> >
> >  {
> >    "imaps" : "cluster23.imap.packetizer.com",
> >    "smtp-submission" : "smtp.packetizer.com"
> >  }
> >
> >
> > That link relation could be returned when querying for my account (via
> > the "acct" URI), but if there was a document that defined mail
> > auto-configuration, then it could specify the use of "mailto" and I
> > believe that would be a perfectly good example of where "mailto:"
> > would be more appropriate than "acct".
> >
> > The "acct" URI should be used to return a wide variety of information
> > about a user's account.  I view it as information that is largely of
> > interest to people other than the actual user.  That would include
> > information like my contact list or my picture or other information.
> >
> > Anyway, we've discussed before that WebFinger can operate on a variety
> > of URIs.  The one that should relate to the users account we put a
> > stake in the ground and declare to be "acct".  If we want to specify
> > other URIs for a subset of that information or instead of "acct"
> > (e.g., mailto for mail configuration), that would be a reasonable thing
> to do.
> >
> > Paul
> >
> >