Re: [apps-discuss] Webfinger: acct "link relation"

["Paul E. Jones" <[e-mail]>]

Bob,

 

I used an example wherein the client makes an assumption.  However, I feel a
little nervous about putting in normative statements that declare that this
is the way it must work.  My email client also makes the assumption when I
type an address that looks like an email address that it is one.  Such
client-side "intelligent" assumptions are reasonable to make life easier for
users, but I think it is best to leave that as non-normative.

 

What I want to do is split section 6 into 6.1 and 6.2.  In 6.1, I'll
introduce the purpose for the "acct" URI, void of any example usage.  In
6.2, I'll have a non-normative example (one like what is there presently.)

 

Paul

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Bob Wyman
Sent: Wednesday, March 14, 2012 4:01 PM
To: Paul E. Jones
Cc: [e-mail]; [e-mail]
Subject: Re: [apps-discuss] Webfinger: acct "link relation"

 

Paul,

If one may assume that mailto:[e-mail] and acct:[e-mail]
<mailto:[e-mail]>  are associated with the same user,
shouldn't it be stated in the RFC that clients MAY assume this and that
servers MUST NOT allow for the assumption to be invalid? Certainly, allowing
the two identifiers to be associated with different people will cause
never-ending confusion, however, if we want to prevent the confusion, then
we should explicitly state that this situation should not arise.

 

Note: I support your efforts to clarify the situation where a mailto:
corresponds to a dissimilar acct:. Also, allowing user editing of WebFinger
data, will drastically increase the utility of the protocol.

 

bob wyman

On Wed, Mar 14, 2012 at 3:38 PM, Paul E. Jones <[e-mail]>
wrote:

Bob,

 

I want to improve the language in the introduction of that section, but I do
think it is reasonable to assume that a user with a given email address may
have an account with the same name on the server.  There are instances where
that would not be the case, but a 404 would be returned in that instance.
It has been suggested that perhaps making this assumption would lead to
returning information for the wrong person.  That's possible, but I believe
Webfinger might help to encourage domain owners from putting themselves in
that situation.  If [e-mail] is a non-email account at that domain,
there should not be a real user account with the same name, but belonging to
a different person.  It's simply poor practice.  It confuses humans.  We
could get this straight in protocol, but it would never address the
confusion in the human mind.

 

In any case, I want the "acct" link relation to refer to other accounts, not
necessarily the "right" account.  The wording was not clear on that.  Here's
the proposed wording changes for the first 3 paragraphs (now reduced to
two):

 

Users of some services might have an acct URI that looks significantly
different from their email address, perhaps using entirely different domain
names.  It is also possible that a user has multiple accounts that a
Webfinger client may want to query.  As such, it is useful to allow one user
account to refer to one or more other account identifiers.

 

To make a reference to other user accounts, one uses the "acct" link
relation.  Consider the following example.

 

I welcome any textual changes to make this clearer.

 

Paul

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Bob Wyman
Sent: Wednesday, March 14, 2012 11:26 AM
To: Paul E. Jones
Cc: [e-mail]; [e-mail]
Subject: Re: [apps-discuss] Webfinger: acct "link relation"

 

Thanks for mentioning section 6. I have been puzzling over this for some
time now. It seems to me that if Alice receives an email from
"[e-mail]" then, because there is no certain equivalence of mailto:
and acct: identifiers, Alice should query for "mailto:[e-mail]" in
order to discover "acct:[e-mail] <mailto:[e-mail]> "
rather than assuming similarity between the mailto: and acct: identifiers
and first querying for "acct:[e-mail] <mailto:[e-mail]>
." 
It must be remembered that WebFinger acct: identifiers need not be the same
as or even similar to mailto: identifiers. Additionly, similar identifiers,
such as "mailto:[e-mail]" and "acct:[e-mail]
<mailto:[e-mail]> ," need not identify the same person or
entity. (although it would be really, really smart if they did...)

Given that in most cases, "acct:xxx" and "mailto:xxx" will, in fact, be
associated with the same entity, it would be a bit of a nuisance to require
the multi-step discovery process outlined above. Especially since we know
that mapping from mailto: to acct: will be a very, very common requirement.
Thus, it seems reasonable to me that we would add a few new rules:
1) If the server responding to a request for mailto: information is also the
authoritative server for the WebFinger acct information, it may provide that
information as long as it also provides a link with rel=acct element to
identify the acct:. In this case, it should be understood that any
information provided (other than the link that shows the relationship
between the identifiers) is associated with the acct: identifier, not with
the mailto: identifier. This server-side automatic mapping rule could, of
course, be generalized to say that whenever the server knows the exact
mapping from any URI, no matter what scheme it uses, to a corresponding
acct: URI, it may perform the translation as long as it provides an
appropriate link with (rel=acct) in its response.
2) To enable clients to do URI translations, it would be useful for servers
to be able to describe those translations which are easily performed. For
instance, for servers that maintain a one-to-one relationship between
mailto: and acct: URIs, it should be possible for the server to publish in
its host metadata the mapping between the two identifiers. Thus, we might
have an XRD like the following:

    <XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
       <Link rel="lrdd"
             type="application/xrd+xml"
             template="https://example.com/lrdd/?uri={uri}
<https://example.com/lrdd/?uri=%7buri%7d> "/>
       <Link rel="mailto2acct" template="acct:{mailto_id}"/>


 
     </XRD>

 

The XRD above not only describes the general template for forming queries,
it gives specific instructions re optional pre-translation for mailto: URIs.
Clearly, more complex template mappings would be interesting and often
useful, but perhaps too complex.

bob wyman

On Wed, Mar 14, 2012 at 1:56 AM, Paul E. Jones <[e-mail]>
wrote:
> Folks,
>
>  
>
> In the latest Webfinger draft, we introduced a "acct" link relation named
> "acct" (see Section 6).  The intent with that link relation was to allow
for
> one to inform a webfinger client that a user's account information may be
> retrieved elsewhere.  I believe this will be important, since a user might
> have more than one account and this might serve as a means of associating
> them.  Certainly, it would be a way of retrieving information from those
> other accounts automatically.
>
>  
>
> Perhaps calling the new link relation "acct" is too restrictive, though.
If
> one used Webfinger to query other kinds of information other than a user's
> account, there may still be a need/desire to refer the Webfinger client to
> other resources.
>
>  
>
> What do you think about changing this section such that the link relation
is
> renamed to "seealso"?  This would still be useful when querying an acct
URI,
> but would also be useful when querying any URI since it  is more generic.
>
>  
>
> Do note that "seealso" would be different than the "alternate" link
> relation.  It would not refer to alternative information, but would refer
to
> supplemental information.  In practice, the supplemental information may
be
> the more informative since the bulk of the information related to a user
> might be held under a different account.
>
>  
>
> Your thoughts?
>
>  
>
> Paul
>
>  
>
>  
>
>  
>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>