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

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

OK.  And I'll split the balance the paragraph at that point so that the
"alias" text starts as a new paragraph.

 

Paul

 

From: Dick Hardt [mailto:[e-mail]] 
Sent: Friday, December 21, 2012 10:48 PM
To: Paul E. Jones
Cc: 'Dick Hardt'; [e-mail]; [e-mail]
Subject: Re: [webfinger] [apps-discuss] I-D Action:
draft-ietf-appsawg-webfinger-08.txt

 

Certainly, text changes were what you requested. I must learn to read
directions. I must learn to read directions. I must learn to read
directions.



Change the following in 3.1
   In the above example, an "acct" URI [8
<http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#ref-8> ] is used
in the query, though
   any valid alias for the user might also be used.

 

to be:

   In the above example, an "acct" URI [8
<http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#ref-8> ] is used
in the query, though
   any valid alias for the user might also be used. See section 4.5 for
   more information on WebFinger and URIs. 




On Dec 21, 2012, at 7:43 PM, "Paul E. Jones" <[e-mail]> wrote:





Any suggested wording?

My hands have been smacked so many times...

Paul




-----Original Message-----
From: Dick Hardt [mailto:[e-mail]]
Sent: Friday, December 21, 2012 10:40 PM
To: Paul E. Jones
Cc: [e-mail]; [e-mail]
Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-
webfinger-08.txt

Thanks for the explanation Paul.

I see that section 4.5 answers my question.

Perhaps a pointer to section 4.5 in section 3 would help when an
implementor is reading the spec?

I agree that we don't want to dictate more than that.

-- Dick

On Dec 21, 2012, at 7:30 PM, "Paul E. Jones" <[e-mail]>
wrote:




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