Re: [apps-discuss] Webfinger & acct: draft

Blaine Cook <romeda@gmail.com> Sat, 19 November 2011 12:24 UTC

Return-Path: <romeda@gmail.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 3409221F8A95 for <apps-discuss@ietfa.amsl.com>; Sat, 19 Nov 2011 04:24:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.448
X-Spam-Level:
X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 e6AhgEJ1wCOk for <apps-discuss@ietfa.amsl.com>; Sat, 19 Nov 2011 04:24:46 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 282E921F84DC for <apps-discuss@ietf.org>; Sat, 19 Nov 2011 04:24:46 -0800 (PST)
Received: by ggeq3 with SMTP id q3so2192190gge.31 for <apps-discuss@ietf.org>; Sat, 19 Nov 2011 04:24:45 -0800 (PST)
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=+IpfktO10mLH1ck5ftgVQaEVrlaqEbro4lPqrNPZ7ss=; b=VpOFTRKH3ZWB88gTrFzadUfY+hmbmcL0rWMxkceVWNFnTRjMxm2/Cjcw9rCjl+SWND cGK8XCtngi05eupsUSxPL79zYUqp2m0wa7/QGVAIaQm/Y7iPyItZ66zFuZWdpm6GneAS LOYh92rl8NHAswRXLzfxp49Dy9MDmJg85cZnI=
Received: by 10.182.172.41 with SMTP id az9mr1569096obc.42.1321705485699; Sat, 19 Nov 2011 04:24:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.44.35 with HTTP; Sat, 19 Nov 2011 04:24:24 -0800 (PST)
In-Reply-To: <4EC754A8.3090408@gmail.com>
References: <A09A9E0A4B9C654E8672D1DC003633AE4056F73E86@GRFMBX704BA020.griffon.local> <047c01cca646$f32f8100$d98e8300$@packetizer.com> <740878FD-AA49-4F62-8612-7AE76CA36710@cisco.com> <CAAz=sc=K1m8dEZQ2BfWG2eVZSiMkMZFa+zPgM-aEOZLg=0OjrQ@mail.gmail.com> <4EC754A8.3090408@gmail.com>
From: Blaine Cook <romeda@gmail.com>
Date: Sat, 19 Nov 2011 12:24:24 +0000
Message-ID: <CAAz=sc=X8NTuDi_cgPtgSLt6-+1oaOAVyFk24Q1P+EnLOHJOkg@mail.gmail.com>
To: =?UTF-8?B?TXlreXRhIFlldnN0aWZleWV2ICjQnC4g0ITQstGB0YLRltGE0LXRlNCyKQ==?= <evnikita2@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f83a729f90c0a04b21589e2
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger & acct: draft
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: Sat, 19 Nov 2011 12:24:51 -0000

2011/11/19 "Mykyta Yevstifeyev (М. Євстіфеєв)" <evnikita2@gmail.com>

>  19.11.2011 8:58, Blaine Cook wrote:
>
> +1; defining the actual link relations should be done outside the
> webfinger spec, most likely as part of RFC 5988 as Paul mentioned.
>
>  The relations are perhaps the trickiest bit of webfinger to standardise,
> but thankfully 5988 offers guidance; new relations should be defined as
> specifically as possible, with obvious relation overlap being aggregated
> into more general identifiers, and eventually being submitted to the
> registry once sufficient deployment mandates it.
>
>
> How many of them will we have to define?  Can we at all predict how will
> Webfinger be used?
>

We don't know, and no. :-)

We can make educated guesses, but it would be folly to start defining
shared, generic terminology before implementation. The XMPP specs are a
great example of too much definition stifling actual implementations from
growing and evolving.

b.