Re: [webfinger] [appsawg] #12: Semantic gap for the client side

Barry Leiba <barryleiba@computer.org> Fri, 14 June 2013 16:59 UTC

Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: webfinger@ietfa.amsl.com
Delivered-To: webfinger@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB09921F9D01 for <webfinger@ietfa.amsl.com>; Fri, 14 Jun 2013 09:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.097
X-Spam-Level:
X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 kE+PbP7rBK3n for <webfinger@ietfa.amsl.com>; Fri, 14 Jun 2013 09:59:16 -0700 (PDT)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A6AD621F9D00 for <webfinger@ietf.org>; Fri, 14 Jun 2013 09:59:15 -0700 (PDT)
Received: by mail-ve0-f172.google.com with SMTP id jz10so675494veb.17 for <webfinger@ietf.org>; Fri, 14 Jun 2013 09:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MTy/rLScoey/n0gXeXf4u/r4hN70fYqEbCoVqMWK7n8=; b=tKK8+d+JvPQQdbPVKhW/AbIjMNFcYxvn4hzB1g2cGIrjPtF6qRsrUSoBNT0Sljhuuz 9K5mK5Kt6Fv01HFKE60xNP5VRsasAzaDF31LPlHHHCCM2PHx56OyRgOLvMmqUKA80AjX t/59LJzljcJU4NXws1zf2Zojv74Le/HCLUdavOsYOLj/fyoGaAaBqJ9GSRH9u1HYK8n8 B+ihNVvD0x9yeeRGKVhlJi5tXMhDpUPmkL2LBaq4HYfprZSUswA1xLqauMG9DDctkyuf lC8pQKae0Mlnmbc3J/ycxn2Y6wc8zILboD2ZIou8F7+oqxFBwnnB8oTJazMryGek+rTI d0kQ==
MIME-Version: 1.0
X-Received: by 10.220.101.69 with SMTP id b5mr1255891vco.55.1371229154831; Fri, 14 Jun 2013 09:59:14 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.58.234.105 with HTTP; Fri, 14 Jun 2013 09:59:14 -0700 (PDT)
In-Reply-To: <51BB264C.3090602@qti.qualcomm.com>
References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <CAKaEYhLX5o9XM-t0iX5fMAXBrcmv1f2pYbPhP+DVNK=OUjSe=w@mail.gmail.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com>
Date: Fri, 14 Jun 2013 18:59:14 +0200
X-Google-Sender-Auth: bz93FzVnrCuj9zSPPn01k1RMXEA
Message-ID: <CAC4RtVBhYYy8eRYD4n=ijCR-2HF91QMT81UD6-d9XR4r2ZEVVg@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Pete Resnick <presnick@qti.qualcomm.com>
Content-Type: multipart/alternative; boundary="047d7b3a7e92adf47604df202a01"
Cc: salvatore loreto <salvatore.loreto@ericsson.com>, "Paul E. Jones" <paulej@packetizer.com>, "draft-ietf-appsawg-webfinger@tools.ietf.org" <draft-ietf-appsawg-webfinger@tools.ietf.org>, Melvin Carvalho <melvincarvalho@gmail.com>, webfinger <webfinger@ietf.org>
Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webfinger>, <mailto:webfinger-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/webfinger>
List-Post: <mailto:webfinger@ietf.org>
List-Help: <mailto:webfinger-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webfinger>, <mailto:webfinger-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2013 16:59:16 -0000

>
> 2. The JRD name/value pairs that can be returned for any given URI scheme.

...

> Neither this document nor the acct: URI document gives any guidance about
> what set of links will be returned for the acct: URI. The semantics of
> querying for the acct: URI are never defined. It gives examples using the
> acct: URI, but it never actually defines what links or other properties an
> acct: URI can return.
>

Let me stick something in here:

There are two ways we can get interoperability from this.  One is to
explicitly specify everything that might be returned from a particular
query.  Another is to make sure that what gets returned is self-defining.
 The latter is the point of link relations -- the link relation tells you
what the link means, so the recipient knows whether it understands this
type or not, and, if it understands it, knows what its semantics are and
what to do with it.

Barry