Subject: Re: [webfinger] [apps-discuss] Draft -07 mod proposal: Clean up "subject"

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 4 Dec 2012 23:53:43 -0500

Nick,

> On Mon, Dec 3, 2012 at 10:11 PM, Paul E. Jones <[email-masked]>
> wrote:
> > Nick,
> >
> > Does the words "would be expected to be equivalent" cause the concern?
> Should I make that "normally be equivalent"?
> 
> Well I guess it would help to have some clarification on the
> implications (if any) of differences in the subject. Are there reasons
> the client library would want to check this and do something different
> if there is a difference?

The subject will properly identify the entity being queried. If a querying
user provides a correct, but perhaps not the preferred normalized form or
perhaps an identifier that has been updated or changed.  It could also be
safely ignored in favor of what the user provided.

If the subject is different, nothing should break.  The client should still
accept the reply and use it.
 
> > This is not a "forwarding", per se, but could inform the client that
> additional or other information is available elsewhere.  This was never
> intended to a be a "forwarding" mechanism, though.  The 3xx should do
> that.
> 
> 
> If you were using an email provider like gmail, or yahoo, but changed
> your email address and wanted to forward to your new address, do you
> think it's likely one of these big email providers would implement a way
> for you to set up a 301 (or 307) redirect for all queries on your
> account? I would guess no, so it seems more practical to have some
> method of specifying this 'inline'.

I would think it's highly unlikely that the big mail providers would be so
kind as to provide any sort of forwarding service whatsoever.  They
certainly don't do it for email today (and that's well-defined), so I cannot
expect they'll do it for WF.
 
> In the JRD example you gave above, a WF client probably wouldn't
> automatically issue a new request to the address based on that 'acct'
> relation entry. So you'd loose quick-lookup functionality for all your
> old interactions with your old email address.

Possibly.  For now, I'd only consider 3xx as the forwarding mechanism.
We'll get to the "acct" link relation in another document and debate the
merits there.
 
> I know there's probably no chance of this being introduced to the spec
> (having a standard way of specifying a forwarding account within the JRD
> response) but thought I'd bring it up anyway as I think there's plenty
> of use cases for it (ie. switching jobs, switching email providers,
> switching from an @gmail.com account to an @[mydomainname] account, or
> just having a few variations on the spelling of your name).

I do think 3xx is the right way to do it, and that's in the spec.  This
mechanism requires nothing new for the client to implement to get forwarding
benefits.

Paul