Re: [webfinger] Question about device info discovery example.

"Paul E. Jones" <paulej@packetizer.com> Sat, 22 December 2012 05:39 UTC

Return-Path: <paulej@packetizer.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 03C1021E8042 for <webfinger@ietfa.amsl.com>; Fri, 21 Dec 2012 21:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level:
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYHMyP3qPzQu for <webfinger@ietfa.amsl.com>; Fri, 21 Dec 2012 21:39:38 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB8521E8037 for <webfinger@ietf.org>; Fri, 21 Dec 2012 21:39:38 -0800 (PST)
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 qBM5daKU004767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 00:39:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356154777; bh=nDyRPhlXM8ErcPyTgQ2QHexLIi5vAvW5/96YvofYiOw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Bqb69/v+9ia2ifYugA4YrS1ck+zcbM2lCBk/n5ee4iC9eAoLoMr4CcOsnoC1uHIPp T2Y9BG7VLiHkNJPNJyKUp2LNBXomUkwLawCtbPLadrvLaRIP/6wRf6eB3Y95/lKhAF RTMXSOFCqmNfk2+m+LElooAcs7lgbjEWqUhUgLmY=
From: "Paul E. Jones" <paulej@packetizer.com>
To: 'nov matake' <matake@gmail.com>
References: <D6A97D9D-9431-4C0F-9428-397677C179D1@gmail.com> <075b01cde000$d283d790$778b86b0$@packetizer.com> <1B7C31D3-E41E-4DF2-910F-AC43340C62D6@gmail.com> <077601cde004$d8ae8760$8a0b9620$@packetizer.com>
In-Reply-To: <077601cde004$d8ae8760$8a0b9620$@packetizer.com>
Date: Sat, 22 Dec 2012 00:39:39 -0500
Message-ID: <078901cde006$bc9724e0$35c56ea0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_078A_01CDDFDC.D3C2CA90"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIeIapXe7gOJ5OOW00neyp/e43xxwISwboRAW9vMOQCCvx/RZdXX1rA
Content-Language: en-us
Cc: webfinger@ietf.org
Subject: Re: [webfinger] Question about device info discovery example.
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: Sat, 22 Dec 2012 05:39:43 -0000

Nov,

 

As I quickly looked at the text, I think we really should be consistent in
using the hostname that immediately follows http(s):// or device:.  So, I'm
going to change the WF draft accordingly.

 

So, the end of section 3.1 now looks like this:

 

An alias is a URI that is different from the "subject" URI that identifies
the same entity.  In the above example, there is one "http" alias returned,
though there might have been more than one.  Had the "http:" URI shown as an
alias been used to query for information about Bob, the query would have
appeared as:

 

  GET /.well-known/webfinger?

           resource=http%3A%2F%2Fwww.example.com%2F~bob%2F HTTP/1.1

  Host: www.example.com

 

Note that the host queried changed in this example, since the URI refers to
a different host.  Either this host would provide a response, or it would
redirect the client to another host (e.g., example.com).  Either way, the
response would have been substantially the same, with the subject and alias
information changed as necessary.  Other information, such as the expiration
time might also change, but the set of link relations and properties would
be the same with either response.

 

I also put "p1.example.com" as the host for the device: URI.  I do think the
particular host to query is something we'll have to take up on a URI-by-URI
basis, but a very logical assumption with no other guidance is to query the
host that is in the "hostname" position of the URI (if there is one).

 

For URIs like "tel", the WF client would just have to be provisioned to know
where to go query.

 

Paul

 

From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On
Behalf Of Paul E. Jones
Sent: Saturday, December 22, 2012 12:26 AM
To: 'nov matake'
Cc: webfinger@ietf.org
Subject: Re: [webfinger] Question about device info discovery example.

 

Nov,

 

The host to query for the acct URI should be the host portion following the
@.  For example, if one's email ID is "user@nc.example.com" then the host to
be queried would be nc.example.com.  That would be true for mailto, also.

 

For http(s): URIs like "http://www.example.com/some/path/", there are one of
two possibilities.  In the examples, I've suggested that to one would query
the host "example.com".  However, it probably isn't the right place.  In the
case of an http: URI, perhaps queries should be directed to the host itself
(in this case www.example.com).  We need to answer that question: do we
direct queries to the parent "host" (as I have it in the examples) or to the
named host in the URI?

 

Paul

 

From: nov matake [mailto:matake@gmail.com] 
Sent: Saturday, December 22, 2012 12:10 AM
To: Paul E. Jones
Cc: webfinger@ietf.org
Subject: Re: [webfinger] Question about device info discovery example.

 

OK,

 

Then basically webfinger clients MUST use the host of resource parameter (at
least when using acct, mailto, http and https schema),

but extension spec MAY define another rule and in that case, client MUST
follow the extension's rule.

 

Is it right?

 

Or webfinger itself doesn't specify anything for host usage?

(It just define path "/.well-known/webfinger" and schema "https", but not
host?)

 

On 2012/12/22, at 13:57, Paul E. Jones <paulej@packetizer.com> wrote:

 

Nov,

 

Keep in mind that this is an entirely fictional example.  There isn't even a
URI scheme called "device".

 

The answer to your question would come from a document (if it existed, but
does not) that describes the "device" URI and how to use it within the
context of WebFinger.

 

My thinking when I wrote this is that there are named devices on the network
and one would query the parent domain to learn about the device.  The parent
in this case being <http://example.com> example.com.  It might be that there
is a designated host that serves as the device info server called "
<http://devices.example.com> devices.example.com" to which all queries are
directed.  In any case, this is completely unspecified and the example is
there only to illustrate the range of use for WebFinger.  It should not be
viewed in any way as proper usage, though.

 

Paul

 

From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On
Behalf Of nov matake
Sent: Friday, December 21, 2012 11:40 PM
To: webfinger@ietf.org
Subject: [webfinger] Question about device info discovery example.

 

Hi all,

I'm new to this ML.

I'm writing a ruby webfinger library.
 <https://rubygems.org/gems/webfinger> https://rubygems.org/gems/webfinger

After reading usecases in section 3, I have a question.

In the device info discovery example in section 3.4, resource is "device:p1.
<http://example.com/> example.com" but the host of discovery endpoint is "
<http://example.com/> example.com", not " <http://p1.example.com/>
p1.example.com".
Is there any reason why these hosts are different?
How did the client decide the host of the discovery endpoint from resource
URI?

Thanks

Nov Matake