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

[Dick Hardt <[e-mail]>]

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