Subject: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme

From: Tim Bray <[email-masked]>
Date: Sun, 2 Dec 2012 17:14:48 -0800

I don’t want to wait for work on this to be completed, and I don’t think
that its presence is necessary for WebFinger to be useful.  So let's take
it out.

Proposal:
Section 4.1: Change the URI in the example from acct: to mailto:
Section 4.2: Same
Section 5.3: Same
Section 5.4: s/it could be an "acct" URI [7], //
Section 5.4: Remove 2nd para, beginning "For resources associated with a
user account at a host...“
Section 5.4: s/both an "acct" URI and any alias/any alias/
Section 8: Change the URI in the example from acct: to mailto:

On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray <[email-masked]> wrote:

> No, we’re on the same side here. I’m suggesting taking webfinger-07 as a
> baseline, and all *future* changes need to be proposed as a concrete delta
> against it.  -T
>
>
> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones <[email-masked]>wrote:
>
>> Tim,****
>>
>> ** **
>>
>> I didn’t mean to be rude by introducing these changes, just trying to
>> move things along.  Most changes were fairly trivial, not worth mentioning,
>> and can be seen here:****
>>
>>
>> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-appsawg-webfinger-07.txt
>> ****
>>
>> ** **
>>
>> The most significant changes were the re-write of section 5.2 and
>> modification to the language related to HTTPS in 5.1.  I suspect that is
>> the text to which you refer as preferring it to be “camera-ready”.  (I
>> would assume the balance of the changes would not need to be presented as
>> “camera-ready”, since they’re minor editorial things.)****
>>
>> ** **
>>
>> In any case, the most important text changes I would like folks to
>> consider is section 5.2 (which aims to fully document the JSON Resource
>> Descriptor object) and paragraphs 2 and 3 in section 5.1.****
>>
>> ** **
>>
>> Paul****
>>
>> ** **
>>
>> *From:* Tim Bray [mailto:[email-masked]]
>> *Sent:* Sunday, December 02, 2012 2:54 PM
>> *To:* Paul E. Jones
>> *Cc:* [email-masked]; [email-masked]
>> *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-07****
>>
>> ** **
>>
>> Thanks to Paul for the extra effort.  I’d like to suggest, in the
>> interests of courtesy and efficiency, that from here on on, contributions
>> to this discussion be “camera-ready”, that is to say, specific suggestions
>> in the style of a diff, including fully-written-out replacements language.
>>
>>  -Tim****
>>
>> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]>
>> wrote:****
>>
>> Folks,****
>>
>>  ****
>>
>> I published another version of the WebFinger spec trying to bring closure
>> to the two open issues I see (resource representation and transport).  The
>> new version is here:****
>>
>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07****
>>
>>  ****
>>
>> With respect to resource representation, I fully described the JSON
>> Resource Descriptor within the document.  There are no external references
>> to RFC 6415 now, no need to go read the XRD spec, etc.  It’s a fairly
>> simple format and I believe this text documents it sufficiently.  Combined
>> with the visual examples, I think this makes it pretty clear.  Have a look
>> at the JRD documentation in section 5.2 and provide your comments. ****
>>
>>  ****
>>
>> With respect to HTTPS, it seems there is strong preference for “HTTPS
>> only”, but some a fair bit of insistence for allowing HTTP.  I changed the
>> wording in 5.2 to try to capture opinions.  Previously, the text led with a
>> requirement to try HTTPS first.  That is still there.  I just added some
>> extra conditions that make it clearer that there are some instances where a
>> client must not utilize HTTP.  This might need further refinement, but I
>> think there is a balance we can strike here between the two camps without
>> introducing a lot of complex language.****
>>
>>  ****
>>
>> I made some editorial changes through the document.****
>>
>>  ****
>>
>> Comments are welcome, as always.  Seems I don’t need to say that to this
>> group, though :-)****
>>
>>  ****
>>
>> Paul****
>>
>>  ****
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/apps-discuss****
>>
>> ** **
>>
>
>

---

From: Bob Wyman <[email-masked]>
Date: Sun, 2 Dec 2012 20:34:48 -0500

I think this would be unwise. If the spec is filled with mailto: examples,
we're going to be dealing for years with people who claim that "WebFinger
is for email addresses." No, that will not be a correct reading of the
spec, but that is how many will read it.

Moving acct:'s definition to a distinct document is no justification for
essentially removing acct: from WebFinger. Acct: and WebFinger go together.

bob wyman

On Sun, Dec 2, 2012 at 8:14 PM, Tim Bray <[email-masked]> wrote:

>>> I published another version of the WebFinger spec trying to bring
>>> closure to the two open issues I see (resource representation and
>>> transport).  The new version is here:****
>>>

---

From: John Bradley <[email-masked]>
Date: Sun, 2 Dec 2012 22:51:53 -0300

I agree that WF is not just about email.

A question ( perhaps channeling Blane) is if it should only be about acct: for simplicity.

As an example should we be expecting it to resolve xmpp:  tel:  or other things.   
For http: and https: scheme URI perhaps link headers pointing to a acct: relation are the most appropriate.

WF is about having a identifier in User Principal name (UPN)  form where the principal is a domain and finding the JRD document or documents for that account.

There is a bunch of hedging that it can work with any URI but that may just be confusing the issue.

My personal preference t this point (others working on openID Connect may well disagree) is to go all in on acct: and just admit that WF is the resolution process for those URI.

That is what most people think of it as anyway.

John B.

On 2012-12-02, at 10:35 PM, Brad Fitzpatrick <[email-masked]> wrote:

> -1.  I feel strongly for keeping the acct: scheme.  WebFinger isn't just about email.
> 
> On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray <[email-masked]> wrote:
> I don’t want to wait for work on this to be completed, and I don’t think that its presence is necessary for WebFinger to be useful.  So let's take it out.
> 
> Proposal:
> Section 5.4: Remove 2nd para, beginning "For resources associated with a user account at a host...“
> No, we’re on the same side here. I’m suggesting taking webfinger-07 as a baseline, and all *future* changes need to be proposed as a concrete delta against it.  -T
> 
> 
> On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones <[email-masked]> wrote:
> Tim,
> 
>  
> 
> I didn’t mean to be rude by introducing these changes, just trying to move things along.  Most changes were fairly trivial, not worth mentioning, and can be seen here:
> 
> The most significant changes were the re-write of section 5.2 and modification to the language related to HTTPS in 5.1.  I suspect that is the text to which you refer as preferring it to be “camera-ready”.  (I would assume the balance of the changes would not need to be presented as “camera-ready”, since they’re minor editorial things.)
> 
>  
> 
> In any case, the most important text changes I would like folks to consider is section 5.2 (which aims to fully document the JSON Resource Descriptor object) and paragraphs 2 and 3 in section 5.1.
> 
>  
> 
> Paul
> 
>  
> 
> From: Tim Bray [mailto:[email-masked]] 
> Sent: Sunday, December 02, 2012 2:54 PM
> To: Paul E. Jones
> Cc: [email-masked]; [email-masked]
> Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07
> 
>  
> 
> Thanks to Paul for the extra effort.  I’d like to suggest, in the interests of courtesy and efficiency, that from here on on, contributions to this discussion be “camera-ready”, that is to say, specific suggestions in the style of a diff, including fully-written-out replacements language.
> 
>  -Tim
> 
> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]> wrote:
> 
> Folks,
> 
>  
> 
> I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport).  The new version is here:
> 
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07
> 
>  
> 
> With respect to resource representation, I fully described the JSON Resource Descriptor within the document.  There are no external references to RFC 6415 now, no need to go read the XRD spec, etc.  It’s a fairly simple format and I believe this text documents it sufficiently.  Combined with the visual examples, I think this makes it pretty clear.  Have a look at the JRD documentation in section 5.2 and provide your comments.
> 
>  
> 
> With respect to HTTPS, it seems there is strong preference for “HTTPS only”, but some a fair bit of insistence for allowing HTTP.  I changed the wording in 5.2 to try to capture opinions.  Previously, the text led with a requirement to try HTTPS first.  That is still there.  I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP.  This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language.
> 
>  
> 
> I made some editorial changes through the document.
> 
>  
> 
> Comments are welcome, as always.  Seems I don’t need to say that to this group, though :-)
> 
>  
> 
> Paul
> 
>  
> 
> 
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
>  
> 
> 
> 
>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 2 Dec 2012 19:08:39 -0800

I share Brad's opinion.

On Dec 2, 2012, at 6:03 PM, Brad Fitzpatrick <[email-masked]> wrote:

> I would be fine with acct:-only, but I also don't really care whether any URI is accepted.
> 
> Little bit more simplicity vs future generality.  I'll let people who feel more strongly decide this.  I only feel strongly that we say "acct:" and not "mailto:".
> 
> 
> On Sun, Dec 2, 2012 at 5:51 PM, John Bradley <[email-masked]> wrote:

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Sun, 2 Dec 2012 22:14:39 -0500

+1 on going with acct:

--G

---

From: James M Snell <[email-masked]>
Date: Sun, 2 Dec 2012 21:51:56 -0800

-1 ... I believe the utility of the acct scheme when used with WF is
readily apparent, and honestly there's no reason to "wait" for acct to be
finished. If we complete work on WF before acct is done, the only real
impact is that we wait a bit longer for WF to get an RFC#. Implementors can
still get started doing their thing.

(I do agree that WF is useful with non acct uri's too tho)

- James

---

From: Mike Jones <[email-masked]>
Date: Mon, 3 Dec 2012 06:54:38 +0000

In reply to Tim's suggestion to ditch the dependency upon acct: - this seems like a "premature optimization".  It looks likely that both WebFinger and the acct: URI drafts will be ready to go to working group last call at the same time, and that in fact, they are likely to proceed to RFC status at the same time.  I don't see any schedule reason to remove the dependency at this time.  (And I think there are technical reasons not to do so, e.g. acct:[email-masked].)

In reply to the opposing suggestion that WebFinger be only useful for acct: URIs and not others, among other consequences, this would mean that OpenID Connect would not be able to use WebFinger, as it has to do resolution on several kinds of URIs, some of which don't use e-mail syntax.  (See http://openid.bitbucket.org/openid-connect-discovery-1_0.html#anchor5,  http://openid.bitbucket.org/openid-connect-discovery-1_0.html#anchor8 and http://openid.bitbucket.org/openid-connect-discovery-1_0.html#host.port.example.)

So while on the same thread people are advocating not using acct: and only using acct:, I believe the most flexible and best path is to allow the use of acct: - but also other URIs - exactly where we are today.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Sunday, December 02, 2012 5:52 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] Draft -07 proposal: Remove dependency on "acct:" scheme

John B.

On 2012-12-02, at 10:35 PM, Brad Fitzpatrick <[email-masked]<mailto:[email-masked]>> wrote:

-1.  I feel strongly for keeping the acct: scheme.  WebFinger isn't just about email.
On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray <[email-masked]<mailto:[email-masked]>> wrote:
I don't want to wait for work on this to be completed, and I don't think that its presence is necessary for WebFinger to be useful.  So let's take it out.

Proposal:
Section 5.4: Remove 2nd para, beginning "For resources associated with a user account at a host..."

On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray <[email-masked]<mailto:[email-masked]>> wrote:
No, we're on the same side here. I'm suggesting taking webfinger-07 as a baseline, and all *future* changes need to be proposed as a concrete delta against it.  -T

On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
Tim,

I didn't mean to be rude by introducing these changes, just trying to move things along.  Most changes were fairly trivial, not worth mentioning, and can be seen here:
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-appsawg-webfinger-07.txt

The most significant changes were the re-write of section 5.2 and modification to the language related to HTTPS in 5.1.  I suspect that is the text to which you refer as preferring it to be "camera-ready".  (I would assume the balance of the changes would not need to be presented as "camera-ready", since they're minor editorial things.)

Paul

From: Tim Bray [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, December 02, 2012 2:54 PM
To: Paul E. Jones
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-07

Thanks to Paul for the extra effort.  I'd like to suggest, in the interests of courtesy and efficiency, that from here on on, contributions to this discussion be "camera-ready", that is to say, specific suggestions in the style of a diff, including fully-written-out replacements language.

 -Tim
On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

With respect to resource representation, I fully described the JSON Resource Descriptor within the document.  There are no external references to RFC 6415 now, no need to go read the XRD spec, etc.  It's a fairly simple format and I believe this text documents it sufficiently.  Combined with the visual examples, I think this makes it pretty clear.  Have a look at the JRD documentation in section 5.2 and provide your comments.

With respect to HTTPS, it seems there is strong preference for "HTTPS only", but some a fair bit of insistence for allowing HTTP.  I changed the wording in 5.2 to try to capture opinions.  Previously, the text led with a requirement to try HTTPS first.  That is still there.  I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP.  This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language.

Comments are welcome, as always.  Seems I don't need to say that to this group, though :-)

Paul

_______________________________________________
apps-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 02:01:33 -0500

A single URI scheme does not make it simpler or more complex.  The scheme
just defines that entity being queried.

If you want to learn something given my twitter id, then the client would
query using acct:.  Generally, I think that "acct:" is the scheme that
should be used for user@domain forms.

However, if I want to auto-provision my email client, I would expect my
email client to query using "mailto:[email-masked]".  If I want to
know how to configure my XMPP client, my client might query
xmpp:[email-masked].

Perhaps if both queries go to the same server, one might get the same reply.
Perhaps not.

WebFinger is intended to describe any entity on the Internet, not just
users.  Thus "acct" is not appropriate in all cases.  If I want to get
metadata information about a URI (e.g., http://www.packetizer.com/), then
WebFinger could be used to return that metadata.  That might be a copyright
date, server information, or whatever one wants to define.

A given client does not need to understand every kind of response from a
server.  Things not understood are ignored.  So, given a URI, there may or
may not be things a generic client understands.  However, as we start to
define link relations and property values, and describe how those are used
in certain specialized tasks (e.g., email client configuration), then I
believe you will appreciate the flexibility offered by the current protocol.

Paul

From: John Bradley [mailto:[email-masked]] 
Sent: Sunday, December 02, 2012 8:52 PM
To: [email-masked]
Cc: Paul E. Jones; [email-masked]
Subject: Re: Draft -07 proposal: Remove dependency on "acct:" scheme

A question ( perhaps channeling Blane) is if it should only be about acct:
for simplicity.

As an example should we be expecting it to resolve xmpp:  tel:  or other
things.   

For http: and https: scheme URI perhaps link headers pointing to a acct:
relation are the most appropriate.

WF is about having a identifier in User Principal name (UPN)  form where the
principal is a domain and finding the JRD document or documents for that
account.

There is a bunch of hedging that it can work with any URI but that may just
be confusing the issue.

My personal preference t this point (others working on openID Connect may
well disagree) is to go all in on acct: and just admit that WF is the
resolution process for those URI.

John B.

-1.  I feel strongly for keeping the acct: scheme.  WebFinger isn't just
about email.

I don't want to wait for work on this to be completed, and I don't think
that its presence is necessary for WebFinger to be useful.  So let's take it
out.

Proposal:
user account at a host..."

No, we're on the same side here. I'm suggesting taking webfinger-07 as a
baseline, and all *future* changes need to be proposed as a concrete delta
against it.  -T

On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones <[email-masked]>
wrote:

Tim,

I didn't mean to be rude by introducing these changes, just trying to move
things along.  Most changes were fairly trivial, not worth mentioning, and
can be seen here:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff
<http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-appsawg-web
finger-07.txt> &url2=draft-ietf-appsawg-webfinger-07.txt

The most significant changes were the re-write of section 5.2 and
modification to the language related to HTTPS in 5.1.  I suspect that is the
text to which you refer as preferring it to be "camera-ready".  (I would
assume the balance of the changes would not need to be presented as
"camera-ready", since they're minor editorial things.)

In any case, the most important text changes I would like folks to consider
is section 5.2 (which aims to fully document the JSON Resource Descriptor
object) and paragraphs 2 and 3 in section 5.1.

Paul

Thanks to Paul for the extra effort.  I'd like to suggest, in the interests
of courtesy and efficiency, that from here on on, contributions to this
discussion be "camera-ready", that is to say, specific suggestions in the
style of a diff, including fully-written-out replacements language.

 -Tim

wrote:

Folks,

I published another version of the WebFinger spec trying to bring closure to
the two open issues I see (resource representation and transport).  The new
version is here:

With respect to resource representation, I fully described the JSON Resource
Descriptor within the document.  There are no external references to RFC
6415 now, no need to go read the XRD spec, etc.  It's a fairly simple format
and I believe this text documents it sufficiently.  Combined with the visual
examples, I think this makes it pretty clear.  Have a look at the JRD
documentation in section 5.2 and provide your comments. 

With respect to HTTPS, it seems there is strong preference for "HTTPS only",
but some a fair bit of insistence for allowing HTTP.  I changed the wording
in 5.2 to try to capture opinions.  Previously, the text led with a
requirement to try HTTPS first.  That is still there.  I just added some
extra conditions that make it clearer that there are some instances where a
client must not utilize HTTP.  This might need further refinement, but I
think there is a balance we can strike here between the two camps without
introducing a lot of complex language.

Comments are welcome, as always.  Seems I don't need to say that to this
group, though :-)

Paul

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 2 Dec 2012 17:35:45 -0800

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 2 Dec 2012 18:03:08 -0800

I would be fine with acct:-only, but I also don't really care whether any
URI is accepted.

Little bit more simplicity vs future generality.  I'll let people who feel
more strongly decide this.  I only feel strongly that we say "acct:" and
not "mailto:".

On Sun, Dec 2, 2012 at 5:51 PM, John Bradley <[email-masked]> wrote:

> WF is about having a identifier in User Principal name (UPN)  form where
> the principal is a domain and finding the JRD document or documents for
> that account.
>
>>>> Comments are welcome, as always.  Seems I don’t need to say that to
>>>> this group, though :-)****
>>>>
>>>>  ****
>>>>
>>>> Paul****
>>>>
>>>>  ****
>>>>
>>>>

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 3 Dec 2012 17:52:12 +0100

On Dec 3, 2012, at 3:03 AM, Brad Fitzpatrick <[email-masked]> wrote:

> Little bit more simplicity vs future generality.  I'll let people who feel more strongly decide this.

FWIW I just looked at WebFinger the first time and I am kinda shocked how much it is coupled with / mentions other specs.

Have you guys heard about http://www.w3.org/TR/webarch/#orthogonal-specs ?

Suggestion: drop the idea of it being a protocol, define a decent media type and a well-known URI so clients can do their initial GET:

GET /.well-known/webfinger
Accept: application/webfinger

The rest of what you try to accomplish IMO will fall into place naturally.

Jan

>  I only feel strongly that we say "acct:" and not "mailto:".
> 
>

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 3 Dec 2012 17:52:36 +0100

Jan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 03 Dec 2012 09:35:10 -0800

I agree there's no need to wait on the 'acct' scheme -- in fact it might
be done before the WebFinger draft. There was some contention about
whether 'acct' is tied to WebFinger. My sense is still that 'acct' is an
independent thing, used by WebFinger but usable by other technologies.
Feedback on that issue is still welcome.

In any case I'll review the 'acct' spec again in the next few days and
request further input on the uri-review list ASAP, in accordance with
RFC 4395.

Peter

On 12/2/12 9:51 PM, James M Snell wrote:
> readily apparent, and honestly there's no reason to "wait" for acct to
> be finished. If we complete work on WF before acct is done, the only
> real impact is that we wait a bit longer for WF to get an RFC#.
> Implementors can still get started doing their thing.
> 
>     I don’t want to wait for work on this to be completed, and I don’t
>     think that its presence is necessary for WebFinger to be useful.  So
>     let's take it out.
> 
>     Proposal:
>         No, we’re on the same side here. I’m suggesting taking
>         webfinger-07 as a baseline, and all *future* changes need to be
>         proposed as a concrete delta against it.  -T
> 
> 
>         On Sun, Dec 2, 2012 at 12:59 PM, Paul E. Jones
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Tim,____
> 
>             __ __
> 
>             I didn’t mean to be rude by introducing these changes, just
>             trying to move things along.  Most changes were fairly
>             trivial, not worth mentioning, and can be seen here:____
> 
>             http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-appsawg-webfinger-07.txt____
> 
>             __ __
> 
>             The most significant changes were the re-write of section
>             5.2 and modification to the language related to HTTPS in
>             5.1.  I suspect that is the text to which you refer as
>             preferring it to be “camera-ready”.  (I would assume the
>             balance of the changes would not need to be presented as
>             “camera-ready”, since they’re minor editorial things.)____
> 
>             __ __
> 
>             In any case, the most important text changes I would like
>             folks to consider is section 5.2 (which aims to fully
>             document the JSON Resource Descriptor object) and paragraphs
>             2 and 3 in section 5.1.____
> 
>             __ __
> 
>             Paul____
> 
>             __ __
> 
>             *From:*Tim Bray [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             *Cc:* [email-masked] <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>
>             *Subject:* Re: [apps-discuss]
>             draft-ietf-appsawg-webfinger-07____
> 
>             __ __
> 
>             Thanks to Paul for the extra effort.  I’d like to suggest,
>             in the interests of courtesy and efficiency, that from here
>             on on, contributions to this discussion be “camera-ready”,
>             that is to say, specific suggestions in the style of a diff,
>             including fully-written-out replacements language.
> 
>              -Tim____
> 
>             On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones
>             <[email-masked] <mailto:[email-masked]>>
>             wrote:____
> 
>             Folks,____
> 
>              ____
> 
>             I published another version of the WebFinger spec trying to
>             bring closure to the two open issues I see (resource
>             representation and transport).  The new version is here:____
> 
>             http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07____
> 
>              ____
> 
>             With respect to resource representation, I fully described
>             the JSON Resource Descriptor within the document.  There are
>             no external references to RFC 6415 now, no need to go read
>             the XRD spec, etc.  It’s a fairly simple format and I
>             believe this text documents it sufficiently.  Combined with
>             the visual examples, I think this makes it pretty clear. 
>             Have a look at the JRD documentation in section 5.2 and
>             provide your comments. ____
> 
>              ____
> 
>             With respect to HTTPS, it seems there is strong preference
>             for “HTTPS only”, but some a fair bit of insistence for
>             allowing HTTP.  I changed the wording in 5.2 to try to
>             capture opinions.  Previously, the text led with a
>             requirement to try HTTPS first.  That is still there.  I
>             just added some extra conditions that make it clearer that
>             there are some instances where a client must not utilize
>             HTTP.  This might need further refinement, but I think there
>             is a balance we can strike here between the two camps
>             without introducing a lot of complex language.____
> 
>              ____
> 
>             I made some editorial changes through the document.____
> 
>              ____
> 
>             Comments are welcome, as always.  Seems I don’t need to say
>             that to this group, though :-)____
> 
>              ____
> 
>             Paul____

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Dec 2012 11:38:19 -0600

> Feedback on that issue is still welcome.

+1

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 3 Dec 2012 18:46:57 +0100

+1

mailto (as either a direct or indirect identifier as per awww) should be
used in all cases, acct: is not only extraneous, it conflates the
user@hostpattern that 99% of clients will interpret as mailto:as of
today, it opens the door to one uri scheme per concept e.g. user: and
others which dilute the name space, triggering a potential land grab and
it's simply confusing to developers

SWD had a formulation that contained only mailto: which was cleaner imho

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 3 Dec 2012 18:48:54 +0100

> -1.  I feel strongly for keeping the acct: scheme.  WebFinger isn't just

If Webfinger isnt just about email.  What else is it about?

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Mon, 03 Dec 2012 19:07:13 +0000

> it's simply confusing to developers
for 'one uri scheme per concept e.g. user'... i consider us - PEOPLE, as quite unique concept who may deserve little special pampering ;)

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 15:17:13 -0500

Melvin,

Just because one has an account on a blog or Twitter or CNN or elsewhere
does not mean they have email there.  It is important to differentiate an
account at a domain from email services at a domain.

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Monday, December 03, 2012 12:47 PM
To: [email-masked]
Cc: Paul E. Jones; [email-masked]
Subject: Re: Draft -07 proposal: Remove dependency on "acct:" scheme

Proposal:

+1

mailto (as either a direct or indirect identifier as per awww) should be
used in all cases, acct: is not only extraneous, it conflates the user@host
pattern that 99% of clients will interpret as mailto: as of today, it opens
the door to one uri scheme per concept e.g. user: and others which dilute
the name space, triggering a potential land grab and it's simply confusing
to developers

 

Tim,

Paul

 -Tim

Folks,

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 15:24:23 -0500

It's definitely not about email.

I create an account on Twitter, say "paulej" (which is not mine, BTW).
Let's say Twitter opens its network up to other microblogging sites (perhaps
it already has).  Let's say you create an account at a different
microblogging site at example.com.  I might post something on Twitter and
want to refer to you.  Today, that would be done via @melvin, but you're not
on twitter.  I might refer to @[email-masked] ([email-masked] looks
better here, but whatever).  Likewise, you might respond back to me with
[email-masked].  There is no email relationship here.  But, using the
account at the other domain, the respective services can grab pictures and
other useful information to make the serves feel more integrated.

I have many accounts at various places.  But, if I want to refer to an
account other than my packetizer.com account, it's not going to be an email
ID.

Paul

Sent: Monday, December 03, 2012 12:49 PM

 

Proposal:

Tim,

Paul

 -Tim

Folks,

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 16:26:01 -0500

Jan,

There are not a lot external specs that are unusual.  There are a few specs
that are in the normative section that need to be moved to informative.
I've not always been consistent there, I see.

But, most of the normative references are to things that should be
referenced, like RFC 2119, the HTTP spec, CORS, URI specs, etc.  References
exist so users unfamiliar with a concept can find information and should be
there somewhere.  There may even be a few I should mention and didn't.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Jan Algermissen
> Sent: Monday, December 03, 2012 11:52 AM
> To: Brad Fitzpatrick
> Cc: [email-masked]; [email-masked]
> FWIW I just looked at WebFinger the first time and I am kinda shocked
> how much it is coupled with / mentions other specs.
> 
> Suggestion: drop the idea of it being a protocol, define a decent media
> type and a well-known URI so clients can do their initial GET:
> 
> > WF is about having a identifier in User Principal name (UPN)  form
> where the principal is a domain and finding the JRD document or
> documents for that account.
> >
> > My personal preference t this point (others working on openID Connect
> may well disagree) is to go all in on acct: and just admit that WF is
> the resolution process for those URI.
> >
> >> I don't want to wait for work on this to be completed, and I don't
> >> Section 5.4: s/it could be an "acct" URI [7], // Section 5.4: Remove
> >> 2nd para, beginning "For resources associated with a user account at
> >> a host..." Section 5.4: s/both an "acct" URI and any alias/any alias/
> >> No, we're on the same side here. I'm suggesting taking webfinger-07
> >> as a baseline, and all *future* changes need to be proposed as a
> >> concrete delta against it.  -T
> >>
> >>
> >> I didn't mean to be rude by introducing these changes, just trying to
> move things along.  Most changes were fairly trivial, not worth
> mentioning, and can be seen here:
> >>
> >> modification to the language related to HTTPS in 5.1.  I suspect that
> >> is the text to which you refer as preferring it to be "camera-ready".
> >> (I would assume the balance of the changes would not need to be
> >> presented as "camera-ready", since they're minor editorial things.)
> >>
> >>
> >>
> Descriptor object) and paragraphs 2 and 3 in section 5.1.
> >>
> >>
> >>
> >> Paul
> >>
> >>
> >>
> >> Thanks to Paul for the extra effort.  I'd like to suggest, in the
> interests of courtesy and efficiency, that from here on on,
> contributions to this discussion be "camera-ready", that is to say,
> specific suggestions in the style of a diff, including fully-written-out
> replacements language.
> >>
> >>  -Tim
> >>
> transport).  The new version is here:
> >>
> Resource Descriptor within the document.  There are no external
> references to RFC 6415 now, no need to go read the XRD spec, etc.  It's
> a fairly simple format and I believe this text documents it sufficiently.
> Combined with the visual examples, I think this makes it pretty clear.
> Have a look at the JRD documentation in section 5.2 and provide your
> comments.
> >>
> >>
> >>
> >> With respect to HTTPS, it seems there is strong preference for "HTTPS
> only", but some a fair bit of insistence for allowing HTTP.  I changed
> the wording in 5.2 to try to capture opinions.  Previously, the text led
> with a requirement to try HTTPS first.  That is still there.  I just
> added some extra conditions that make it clearer that there are some
> instances where a client must not utilize HTTP.  This might need further
> refinement, but I think there is a balance we can strike here between
> the two camps without introducing a lot of complex language.
> >>
> >>
> >>

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 3 Dec 2012 23:02:05 +0100

On 3 December 2012 19:00, Brad Fitzpatrick <[email-masked]> wrote:

> On Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho <[email-masked]>wrote:
>
>>
>>
> Accounts on services.
Limited to social services, or including, say, bank accounts?

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 3 Dec 2012 23:06:24 +0100

On 3 December 2012 23:02, Brad Fitzpatrick <[email-masked]> wrote:

>
>
> On Mon, Dec 3, 2012 at 2:02 PM, Melvin Carvalho <[email-masked]>wrote:
>
>>
>>
>>> On Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho <
>>> [email-masked]> wrote:
>>>
>>>>
>>>>
>  Why would we limit it to social services?
>

It's relatively easy to understand [email-masked] as an email account.
Maybe it could be argued [email-masked] is a microblogging account.  But
[email-masked] could be more problematic because you have a further
granularity such as sort code etc.  If the scope is wide, then there may be
more cases to consider...

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 3 Dec 2012 23:13:26 +0100

On 3 December 2012 23:09, Brad Fitzpatrick <[email-masked]> wrote:

> On Mon, Dec 3, 2012 at 2:06 PM, Melvin Carvalho <[email-masked]>wrote:
>
>>
>> Maybe it could be argued [email-masked] is a microblogging account.
>> But [email-masked] could be more problematic because you have a
>> further granularity such as sort code etc.  If the scope is wide, then
>> there may be more cases to consider...
>>
>
> sort? scope? cases?  I don't understand what you're asking about, but in
> any case:  The rules are all the same regardless of what service(s) the
> hostname provides.
>
> 1) hit /.well-known/webfinger,  2) receive document.
>
> If Citibank pivots and becomes a Pinterest clone, their WebFinger still
> works.
>

sorry perhaps its a UK thing ... banks have both an account identifier and
a "sort code" to identify a branch

just wondering if [email-masked] would be considered part of webfinger
scope

hope that makes more sense, tho perhaps you've answered already in that, if
the file is missing it's not part of the system

---

From: William Mills <[email-masked]>
Date: Mon, 3 Dec 2012 14:20:09 -0800 (PST)

The same person might have multiple ways to contact and extant schemes have a specific protocol context, so querying acct:wmills_92105 against a Jabber or Skype or IRC or other service to be named later will work without confusion, where mailto:wmills_92105 implies an SMTP destination (and lacking domain also presumes a local context.

>________________________________
> From: Melvin Carvalho <[email-masked]>
>Sent: Monday, December 3, 2012 2:02 PM
>On Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho <[email-masked]> wrote:
>>
>>
>>>
>>>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 04 Dec 2012 14:06:54 +0900

Hello Peter,

> Feedback on that issue is still welcome.

I agree that we should define 'acct:' this way.

However, I have previously said so, but maybe it helps to repeat it 
here: There is no need to strictly distinguish between protocol-tied URI 
schemes and protocol-independent URIs. So while in general, 'acct:' is 
not only for WebFinger, it may well happen that sooner or later, 
browsers implement dereferencing of 'acct:', e.g. in an a@href, using 
WebFinger.

Thus I think section 3 of your document could benefit from some 
tweaking. Here are some proposals:

3.  Definition

    The syntax of the 'acct' URI scheme is defined under Section 4 of
    this document.

Aside/editorial: Starting a section entitled 'definition' with a 
sentence saying that the definition is in a different section is 
confusing. Proposal: Change section title to "Semantics" (or at least to 
something like "Definition of Semantics".

                    Although 'acct' URIs take the form "user@host", the

"user@host" -> "acct:user@host"

    scheme is designed for the purpose of identification instead of
    interaction (regarding this distinction, see Section 1.2.2 of
    [RFC3986]).

Please change any text that says "for the purpose of identification 
instead of interaction" to something like "mainly for the purpose of 
identification". Then add some text along the lines of "Resolving an 
'acct' URI scheme may result in some information related to or about the 
account. At the time of publication of this specification, no preferred 
or dedicated resolution protocol exists."
(an informative reference to WebFinger and Simple Web Discovery may also 
be a good idea)

While we are at it, please remove the subsections in Section 4. I think 
they only will create work for IANA.

In Section 4.4, please remove "There is no media type associated with 
the 'acct' URI scheme." Media Types and URI schemes are orthogonal 
concepts, and thus such a sentence is unnecessary (and potentially 
confusing).

Also, in what is currently Section 4.6, please change "Note
    that domain labels need to be encoded as A-labels (see [RFC5890]) in
    order to support internationalized domain names (IDNs)." to 
something like "This also applies to domain labels. Alternatively, 
domain labels MAY be encoded as A-labels (see [RFC5890])."
Using %-encoding for domain name parts is part of [RFC3986] (see the 
last two paragraphs of http://tools.ietf.org/html/rfc3986#section-3.2.2).

Regards,   Martin.

>> On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray<[email-masked]
>> <mailto:[email-masked]>>  wrote:
>>
>>      On Sun, Dec 2, 2012 at 1:57 PM, Tim Bray<[email-masked]
>>      <mailto:[email-masked]>>  wrote:
>>
>>          <[email-masked]<mailto:[email-masked]>>  wrote:
>>
>>              Tim,____
>>
>>              __ __
>>
>>              *Cc:* [email-masked]<mailto:[email-masked]>;
>>              [email-masked]<mailto:[email-masked]>
>>              <[email-masked]<mailto:[email-masked]>>
>>              wrote:____
>>
>>              Folks,____
>>
>>               ____
>>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Mon, 3 Dec 2012 10:00:24 -0800

Accounts on services.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Mon, 3 Dec 2012 14:02:52 -0800

On Mon, Dec 3, 2012 at 2:02 PM, Melvin Carvalho <[email-masked]>wrote:

>> On Mon, Dec 3, 2012 at 9:48 AM, Melvin Carvalho <[email-masked]
>> > wrote:
>>
>>>
>>>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Mon, 3 Dec 2012 14:09:33 -0800

---

From: Brad Fitzpatrick <[email-masked]>
Date: Mon, 3 Dec 2012 14:18:24 -0800

On Mon, Dec 3, 2012 at 2:13 PM, Melvin Carvalho <[email-masked]>wrote:

>> On Mon, Dec 3, 2012 at 2:06 PM, Melvin Carvalho <[email-masked]
>> > wrote:
>>
>>>
> just wondering if [email-masked] would be considered part of
> webfinger scope
>
> hope that makes more sense, tho perhaps you've answered already in that,
> if the file is missing it's not part of the system
>

WebFinger isn't going to specify rules for every possible application's
user account naming policy.  Banks get no special distinction, just as
[email-masked] and [email-masked] get no special distinction.  How the
WebFinger server interprets the username is up to them.  Gmail, for
instance, is not case sensitive and pe.r...m.i..t.s periods anywhere in the
username.  That is also not being specified in WebFinger.