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

"Paul E. Jones" <paulej@packetizer.com> Tue, 22 May 2012 13:57 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 B382C21F85E7 for <apps-discuss@ietfa.amsl.com>; Tue, 22 May 2012 06:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1zrdrjPcLye for <apps-discuss@ietfa.amsl.com>; Tue, 22 May 2012 06:57:36 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A486E21F857D for <apps-discuss@ietf.org>; Tue, 22 May 2012 06:57:36 -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 q4MDvCop021582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 May 2012 09:57:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1337695033; bh=Zv4IslMgcrpdwOde1YYPugR6ln37D8UitS0eHlIH8SQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=o3VcCdUh2XObnWloZFqzBu+8Q46CzF5T9cuyhjPZRorFtDHizsWeba5u1uAfiUBE7 YgLyxVGseJyBKN68zXRKaPVACf2ACS9xbizHuFhhYalwoGMsajffecat+SvENPOHwB GA4dfa48cnQDKbhfklASwse9br+GpzeF7Ye5H8nQ=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Murray S. Kucherawy'" <msk@cloudmark.com>, apps-discuss@ietf.org
References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com>
Date: Tue, 22 May 2012 09:57:15 -0400
Message-ID: <028401cd3822$cba40520$62ec0f60$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0285_01CD3801.44939DA0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHACExhZgXedi2je/bJAOmWfz8jR5bwIzAQ
Content-Language: en-us
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: Tue, 22 May 2012 13:57:41 -0000

Murray, et al,

 

I invite others to weigh in on this discussion, but I do want to restate my
thoughts on this issue.

 

The WebFinger draft introduces only minor enhancements over the current RFC
6415.  Specifically, it:

.         Mandates server support for JSON

.         Introduces the "resource" parameter

.         Introduces the "rel" parameter

.         Requires support for CORS (at least in most situations; this has
been softened a bit to consider enterprise security requirements in the -05
draft)

.         Introduces the "acct" URI scheme for identifying individuals

.         Introduces the "acct" link relation to refer to user accounts

 

I believe the group is largely in agreement on everything, except the
introduction of the "acct" URI.  There was some debate over server-side
requirement for both XML and JSON, need for "rel", etc. I view all of these
as binary decisions and the group could easily cast a vote.

 

The question of whether to include the "acct" URI or not I believe largely
depends on whether this URI scheme would have utility outside of WebFinger.
If it does have other uses then it might make sense to have it stand on its
own.  At present, the only use I can see for it is for discovery of
information about people via WebFinger.

 

Further on that point, the "acct" URI scheme was, in fact, one of the more
significant reasons we introduced this new Internet Draft.  After all, RFC
6415 defines the framework for discovery.  The "acct" URI scheme, which was
heavily discussed previously among interested parties, was not a part of
that RFC.  Even so, it was implemented and cited in various documents,
blogs, etc.  Thus, we wanted to formalize it and also introduce addition
minor restrictions and enhancements that make WebFinger more useful for
discovering information about people.  Those additions are enumerated above
(e.g., the "resource" parameter, requirement for JSON, etc.).

 

The debate over the "acct" URI scheme still seems to be centered on the
argument that we either do not need a URI scheme at all or we can re-use an
existing scheme.  I am very much opposed to a scheme-less solution, since
RFC 6415, link relations, and Web-Linking, HTML, and all related work upon
which WebFinger depends relies on URIs.  The URI is what is used to
differentiate one type of entity from another.  A query for "mailto:", for
example, might return information about one's mail servers, mail accounts
(e.g., POP or IMAP configuration information), etc.  A query for "xmpp:"
might return information about one's XMPP server, buddy list, etc.  A query
for "sip:" might return information about a user's SIP registrar, outbound
SIP proxy, or other configuration information.

 

Of course, one could build a WebFinger server to return everything about a
user regardless of the URI scheme.  I just think that is an inappropriate
way to respond to a WebFinger query.  The "acct" URI was intended to be the
single URI scheme that would return information about a person (or possibly
a thing) that holds an account at a given domain.  It would be the one URI
scheme that would return information like vcards, OpenID identifiers,
references to social networking pages, photo sharing resources, etc.  It
might also return other URIs like "sip:paulej@packetizer.com" or
"mailto:paulej@packetizer.com", which is information about me and ways to
contact me.

 

There are perhaps many agreements to be reached through accepted practice,
further extensions to WebFinger (and I would love one that defines how to
have my email client auto-provision itself), etc.  However,  I view the
"acct" URI scheme and link relation as integral to WebFinger.  Without it,
discovery would have to be performed using some other less neutral URI
scheme that isn't quite right.  Another scheme would work, but it would not
be the cleanest approach, IMO.

 

Normally, I like taking a pragmatic approach to solving problems and will
not argue for architectural purity. However, we have an opportunity to make
the right selection right out of the gate with WebFinger.  It would be
trivial for us to implement any choice at this point.  We could build
everything around "mailto:", but not all service providers offer email
accounts (e.g., Twitter) and it's entirely nonsensical for other accounts
(e.g., PhotoBucket).  As such, I'd like to argue for using "acct" to refer
to information related to an individual's account at a domain and to retain
that URI scheme within the WebFinger document.

 

Paul

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Murray S. Kucherawy
Sent: Tuesday, May 22, 2012 3:23 AM
To: apps-discuss@ietf.org
Subject: [apps-discuss] The acct: scheme question

 

As we prepare to bring webfinger into appsawg, it looks a lot like there's
substantial discussion just on the point of the proposed "acct:" scheme.

 

So, a question for those tracking the discussion:  Is this a big enough
topic that it should be split into its own document?  This would be a useful
thing to decide as we figure out how to handle the work once it enters
working group mode.

 

(This by itself has me wondering if we should revisit the conversation about
whether webfinger needs its own working group, but I'll leave it to Barry
and Pete to make that call.)

 

-MSK