Subject: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-02.txt

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 22 Oct 2012 21:20:07 -0400

Folks,

I posted a slightly revised draft considering input received over the
weekend.  You can see the differences are fairly minor, but they were
changes I could easily make to improve the text.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Monday, October 22, 2012 7:38 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Applications Area Working Group
> Working Group of the IETF.
> 
> 	Title           : WebFinger
> 	Author(s)       : Paul E. Jones
>                           Gonzalo Salgueiro
>                           Joseph Smarr
> 	Filename        : draft-ietf-appsawg-webfinger-02.txt
> 	Pages           : 26
> 	Date            : 2012-10-22
> 
> Abstract:
>    This specification defines the WebFinger protocol.  WebFinger may be
>    used to discover information about people on the Internet, such as a
>    person's personal profile address, identity service, telephone
>    number, or preferred avatar.  WebFinger may also be used to discover
>    information about objects on the network, such as the amount of toner
>    in a printer or the physical location of a server.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-02
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 28 Oct 2012 21:02:04 +0200

Hi Paul,

I have read the last 02 version and I have the following comments:

1)
In the Abstract, you define WebFinger

    WebFinger may be
    used to discover information about people on the Internet, such as a
    person's personal profile address, identity service, telephone
    number, or preferred avatar.

however I found this definition slightly different from the one you 
provide in the Overview:

    WebFinger enables the discovery of information about accounts,
    devices, and other entities that are associated with a host.

I think it would be better to align the two

2) In Section 5.2

        *  Collect and expand all resource-specific link relations,
           including those returned by querying for any LRDD link
           relations, discard any host-wide link relations, and return a
           complete resource descriptor following the processing rules in
           Section 4.2 of RFC 6415  <http://tools.ietf.org/html/rfc6415#section-4.2>; and

as a nit: above you should remove the "and".

    It is not the responsibility of the WebFinger server to verify, for
    example, that a URI pointing to a person's avatar is a valid URI.  If
    the WebFinger server needs to query an LRDD resource to collect
    additional resource-specific information, any errors (e.g., 500 or
    404) MUST be ignored by the server.  When a request for an LRDD
    fails, the server MUST NOT attempt to augment missing resource
    information or return a "template" type link relation to a client
    that utilizes the "resource" parameter.

Is it correct my interpretation that if a request for an LRDD fails, the
server will remove it from the response?
if so what is the rationale for this behavior?

3) In Section 5.4

    A host MAY utilize one or more URIs that serve as aliases for the
    user's account, such as URIs that use the "http" URI scheme [2  <http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#ref-2>].  A
    WebFinger server MUST return substantially the same response to both
    an "acct" URI and any alias URI for the account, including the same
    set of link relations and properties.

I don't like the "MUST return substantially" expression, it leaves to 
much ambiguities.
You should explicitly say what are the expected differences if any.

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 28 Oct 2012 16:25:46 -0400

Sal,

For (1), what is not aligned.  I saw in the abstract I used "one the
network" rather than "on the Internet" in once place, so I want to change
that.  Otherwise, it's different wording, but the same message, I think.
Perhaps change "objects" in the Abstract to "other entities"?  What were you
thinking in terms of alignment?

For (2), the "and" is easy.  How to handle issues where the WF server fails
to retrieve LRDD information is more challenging.  The rationale was simply
that we needed to provide an answer to the question. ;-)  We should decide
what the appropriate action is.  We can either ignore it, which might result
in a partial set of link relations or no link relations.  That's the current
wording.  The other option is to return some specific 5xx error code.  I'm
happy with whatever the group proposes here.

Related to (2), if the server is requesting 5 pieces of information in the
background and one request results in 5xx, do we return 5xx?  What if four
requests return a reply and one returns 404?  Does the server just ignore
the 404? Or does it return 5xx?  What if there are a mix of errors?

For (3), I like "substantially" myself, because it does tell me something.
But, your point is taken.  Rather than removing "substantially", how about I
add the following sentence right after:

The only elements in the response that MAY be different include "subject",
"expires", and "aliases".

I think it is only those three that are affected.  The expires element might
change with every request, though if issued in parallel might be the same.
The subject line must change, of course, and if the subject changes, then
the set of aliases changes. 

Paul

From: Salvatore Loreto [mailto:[email-masked]] 
Sent: Sunday, October 28, 2012 3:02 PM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-02.txt

Hi Paul,

1)

   WebFinger may be

however I found this definition slightly different from the one you provide
in the Overview:

2) In Section 5.2 

          Section <http://tools.ietf.org/html/rfc6415#section-4.2>  4.2 of
RFC 6415; and

 

3) In Section 5.4

   A host MAY utilize one or more URIs that serve as aliases for the
   user's account, such as URIs that use the "http" URI scheme [2
<http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#ref-2> ].  A
   WebFinger server MUST return substantially the same response to both
   an "acct" URI and any alias URI for the account, including the same
   set of link relations and properties.

I don't like the "MUST return substantially" expression, it leaves to much
ambiguities.
You should explicitly say what are the expected differences if any.

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

Folks,

Paul

-----Original Message-----

  Title           : WebFinger
 
Abstract:

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 29 Oct 2012 10:56:03 +0200

On 10/28/12 10:25 PM, Paul E. Jones wrote:
> network" rather than "on the Internet" in once place, so I want to 
> change that.
>

great!

> Otherwise, it's different wording, but the same message, I think.  
> Perhaps change "objects" in the Abstract to "other entities"?
>

yes I would prefer "entities" to "objects"

> What were you thinking in terms of alignment?
>

what you have already spotted. thanks!

> For (2), the "and" is easy.
>
:-)
>
> How to handle issues where the WF server fails to retrieve LRDD 
> information is more challenging.  The rationale was simply that we 
> needed to provide an answer to the question. ;-)  We should decide 
> what the appropriate action is.  We can either ignore it, which might 
> result in a partial set of link relations or no link relations.  
> That's the current wording.
>

I think it is the right choice. It is much better to return a little set 
of info then an error.
My concerns are more on the clarity of the text about the fact that in 
the final response
the LRDD that fails to be retrieved is completely removed

> The other option is to return some specific 5xx error code.  I'm happy 
> with whatever the group proposes here.
>
> Related to (2), if the server is requesting 5 pieces of information in 
> the background and one request results in 5xx, do we return 5xx?  What 
> if four requests return a reply and one returns 404?  Does the server 
> just ignore the 404? Or does it return 5xx?  What if there are a mix 
> of errors?
>

if we get only errors then we have to decide which is the most important 
to return... :-)
but that is something that we can leave to the implementors

however if we have a mix of errors and info, then lets return the 
content info we get

> For (3), I like "substantially" myself, because it does tell me 
> something.  But, your point is taken.  Rather than removing 
> "substantially", how about I add the following sentence right after:
>
> The only elements in the response that MAY be different include 
> "subject", "expires", and "aliases".
>
perfect!
with this addition the all paragraph will be much clear.

Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

> I think it is only those three that are affected.  The expires element 
> might change with every request, though if issued in parallel might be 
> the same.  The subject line must change, of course, and if the subject 
> changes, then the set of aliases changes.
>

> Paul
>
> *From:*Salvatore Loreto [mailto:[email-masked]]
> *Sent:* Sunday, October 28, 2012 3:02 PM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-02.txt
>
> Hi Paul,
>
> www.sloreto.com  <http://www.sloreto.com>
>
>
>
>         From:[email-masked]  <mailto:[email-masked]>  [mailto:apps-discuss-
>
>         [email-masked]  <mailto:[email-masked]>] On Behalf [email-masked]  <mailto:[email-masked]>
>
>         To:[email-masked]  <mailto:[email-masked]>
>
>         Cc:[email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Oct 2012 12:04:39 -0400

Sal,

Regarding error handling when using the "resource" parameter.  I have added
a couple of sentences and changed it slightly.  I have this:

If the WebFinger server needs to query an LRDD resource to collect
additional resource-specific information, any errors (e.g., 500 or 404) MUST
be handled by the server.  It is RECOMMENDED that if part of the
resource-specific information is available to return to the WebFinger client
that the server return the information is has.  If all requests made by the
server for resource-specific information fail, the server SHOULD return a
500 status code.  When a request for an LRDD fails, the server MUST NOT
attempt to augment missing resource information or return a "template" type
link relation to a client that utilizes the "resource" parameter.  Note that
a WebFinger server might be implemented such that all LRDD resource-specific
information can be resolved without issuing HTTP requests.  How a WebFinger
server collects and expands such resource-specific link relations is an
implementation matter.

How is this?  This allows some information through (if available), but we
specify to return 500 if the server fails to retrieve any at all.

Paul

From: Salvatore Loreto [mailto:[email-masked]] 
Sent: Monday, October 29, 2012 4:56 AM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-02.txt

Sal,

that. 

great!

Otherwise, it's different wording, but the same message, I think.  Perhaps
change "objects" in the Abstract to "other entities"?  

 

:-)

How to handle issues where the WF server fails to retrieve LRDD information
is more challenging.  The rationale was simply that we needed to provide an
answer to the question. ;-)  We should decide what the appropriate action
is.  We can either ignore it, which might result in a partial set of link
relations or no link relations.  That's the current wording.  

I think it is the right choice. It is much better to return a little set of
info then an error.
My concerns are more on the clarity of the text about the fact that in the
final response 
the LRDD that fails to be retrieved is completely removed 

The other option is to return some specific 5xx error code.  I'm happy with
whatever the group proposes here.

if we get only errors then we have to decide which is the most important to
return... :-)
but that is something that we can leave to the implementors

however if we have a mix of errors and info, then lets return the content
info we get 

perfect! 

Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

 

Paul

Hi Paul,

1)

   WebFinger may be

2) In Section 5.2 

 

3) In Section 5.4

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

Folks,

Paul

-----Original Message-----

  Title           : WebFinger
 
Abstract: