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

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

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
> >
> >