Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt

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

Dick,

> First off, thanks for all the effort in pulling this together -- it is
> much simpler and tighter than it was in the past.

I just hope we're almost done... this is exhausting ;-)
 
> One aspect that jumped out at me as a client implementor is that I am
> not sure what URI am supposed to query when I have an email address for
> a user.

This is the topic I tried to cover in section 4.5:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#section-4.5

I don't want to go so far as to dictate what URI schemes must be used for
what purpose in this draft.  I don't want to limit people's creativity.
That said, we do need a means of identifying "[e-mail]".
Several years ago, people argued over this and decided "acct:" was a
reasonable solution for identifying user accounts.  This is what is
recommended in WebFinger.

> In 3.1 acct: is used, but then later there are mailto: and http: URIs
> that seem equivalent. i.e.:
> 
> 1) acct:[e-mail] is used in 3.1, 3.2
> 2) mailto:[e-mail] is used in 3.3
> 3) http://www.example.com/~bob/ in 3.1
> 
> As a mail client I can see that (3) may be a separate URI that has
> slightly different meaning that (1) or (2)

I would expect email clients to always use "acct" if the purpose is to look
up information about a user's account at some domain.  It does not matter if
it's an email client, web browser, FTP client, or whatever.  The "acct" URI
has a specific purpose.

I would expect the mail client to query the server if it is looking for
configuration information.  So, when I enter my email address into my
client, it goes out and discovered my SMTP and IMAP server and whatever
server settings to use.  (Now, what is documented presently is just an
example.  I'd like to see a more complete spec for how that should be done.
Ditto for other kinds of clients, including SIP, XMPP, H.323, etc.)

> As a server implementor, would I need to support both (1) and (2)?

Servers should just serve whatever is populated in the database.  My
database has a "resource" table populated with:
    acct:[e-mail]
    http://packetizer.com
    http://www.packetizer.com
    mailto:[e-mail]
    xmpp:[e-mail]

The records in the resource table have a 1-to-n relationship with another
table called "aliases".  The "acct:[e-mail]" record, for
example, has an alias called "h323:[e-mail]".  If you query my
server using either of those values, you will get more-or-less the same
reply.  What changes is the aliases array in the output.

In my server, mailto: is its own "resource".  I did this, because the usage
I expect is entirely different from "acct".  I expect mailto to be used by
email clients for configuration, as I mentioned.

So, why the "h323" URI in aliases?  Well, that's there only because I needed
something to test with.  Like mailto and xmpp, an H.323 client would query
the server and get data to help auto-provision.  If H.323 did not already
have the ability (which is does using SRV records), I could imagine that an
H.323 URI might be used by an H.323 client (or Gatekeeper) to determine how
to route a call.  Same thing for email.  If MX records did not exist, I
could imagine using this to advertise the location of the mail server for
the queried URI. (Note that I'm not at all suggesting we switch to WF rather
than use established call routing or mail routing mechanisms.)

Bottom line is that the server should not really care about what is queried.
However, the server admin who populates the database will care what is going
to be queried.  Since all of the important stuff have unique "rel" values, I
could merge acct:, xmpp:, mailto:, etc. and serve up one large JRD.

I think the right answer as to what gets placed where should come with WF
procedure specs.  For example, if we define a mail client auto-provisioning
spec, let's define the mailto usage there.

For the moment, I'm strongly suggesting we converge on using "acct" for most
things, especially if looking for "social" kinds of information.
 
> As a client, can I query either (1) or (2)?

The client should issue a query knowing what it's looking for.  If it's
looking for my avatar for me, it should query acct:[e-mail].
If it's looking for an avatar that represents my blog, it would query using
http://www.packetizer.com/people/paulej/blog/.  If the email client is
looking for provisioning info for my email address, it uses mailto.

Anyway, that's my opinion.  Nothing in the foregoing is law. ;-)
 
> Is (2) only for email configuration per 3.3?

I would say "it is for nothing" until the mail configuration spec or other
spec is defined that says use mailto for this.  This and other specs need to
be written.
 
> Did I miss a reference somewhere that would clarify?

Perhaps only section 4.5.  There is more work to be done, but I don't want
to clutter the core WF spec with specific things like mail configuration.  I
presented that as an example to show the possibilities.

BTW, I do want to work on that mail config doc if Cyrus does not :-)

Paul