Subject: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Mar 2013 11:10:27 -0400

On Mon, Mar 11, 2013 at 03:23:20PM +0000,
 Dave Cridland <[email-masked]> wrote 
 a message of 150 lines which said:

> 1) There's some suggestions that webfinger could be used for email
> autoconfig; I suspect this is at best going to cause confusion

Indeed, the example with IMAP in 3.3 confuses me. Why is is better
than the standard RFC 6186?

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 Mar 2013 10:16:46 +0000

> than the standard RFC 6186?

There's also aggsrv, and of course ACAP. It's aggsrv I'm concerned about
here, since it's likely to be close to, but current from, the design
outlined here. The likelihood for confusion will be very high.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 20 Mar 2013 20:39:26 -0400

Dave,

My apologies for the belated reply.  Please see my comments below.

> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.  Document:
> draft-ietf-appsawg-webfinger-11
> Title: Webfinger
> Reviewer: Dave Cridland
> Review Date: 2013/03/11
> IESG Telechat Date: 2013/03/28
> Summary: Close to ready for publication as standards track; some
> comments which suggest a new version may be required and/or technical
> discussion needed.
> 
> Minor Comments:
> 
> especially when there's a BOF tomorrow on the subject. This feels like
> text that doesn't need to be present.

This particular example provides a useful illustration of the "properties"
construct in the JRD format.  It's there purely as an example and is not
otherwise adopted as a provisioning mechanism.  Would this have presented
confusion if the aggsrv BoF had not been scheduled?  I think there are some
good ideas in the aggsrv proposal, but I do not think that that work or this
example will cause confusion.  In the end, the IETF will adopt some
mechanism for provision email servers and this small example in the WF
document should not be a source of confusion.

So, I do think the text should be there, but if you really think it might
cause some confusion, perhaps we insert a note to make it clearer that this
is only an example and not the way client devices should be provisioned?
 
> Also, it's a cursed subject anyway; see ACAP. :-)

Yeah, I'll give you that.  The outcome of the BoF seemed to be no clearer
than it was going in.
 
> Major Comments:
> 
> 1) I note that §4.4.4.1 describes a 'rel' such that it redefines and
> repeats RFC 5988's §4; I think this should be deferred explicitly to RFC
> 5988 in entirety, rather than specifically only for registered link
> relation types.
> 
> The good news is that this should simplify the text rather a lot:
> 
> """
> The value of the "rel" member is a string containing a link relation
> type (see RFC 5988 [4]). Both registered and extended relation types are
> permitted.
>  """

I do not think we can simplify the text so much.  There is an explicit
limitation in the WebFinger draft that a "rel" value must either be a single
absolute URI or a registered link relation type.  RFC 5988 allows for
multiple values like 'rel="shortcut icon"', but WebFinger does not.  RFC
5988 also allows URIs with fragments, but WebFinger does not.  Valid URIs
must conform to Section 4.3 of RFC 3986 (Absolute URIs).  These decisions
were intended to avoid ambiguity.

Much of the text you removed talks about the other members of the link
relation object, which include "type", "href", "titles", and "properties".
The value of the "rel" member dictates how the other members are interpreted
and so I think that text needs to remain.
 
> 2) The use of webfinger with arbitrary URIs is something I had not
> previously realised. This raises some concerns for me, as it's not clear
> whether this is either genuinely desirable or whether it introduces
> considerations (security and otherwise) beyond those discussed within
> the document.
> 
> I would in general rather the mechanism were restricted to acct, http,
> https, and perhaps mailto.

I don't think use of one URI scheme vs. another makes any difference in
terms of security.  However, it was definitely the desire of the group to be
able to use any URI scheme, including some URIs like 'tel'.  Use of 'tel'
would mean the exact resolution mechanism would have to be defined, but
people did not want to preclude its use.  For others that have a domain
part, the desire is to be able to go to the server and request a JRD for
that URI.  There may or may not be information available for a given URI,
but the procedures for one URI or another would be exactly the same.
 
> 3) There is no use of SRV here; I would prefer an SRV resolution step
> for at least acct and mailto scheme URIs, and possibly http/https as
> well. My concern is that a corporate webserver is typically unlikely to
> be capable of providing webfinger services (being often externally
> hosted), and while this could be solved by handling redirects, or by
> reverse proxying, SRV feels like a more stable solution here.
> 
> I'd be curious as to whether this has been discussed.

This was discussed at length, yes.  We also discussed the use of the URI
resource record type.

SRV records will tell you what host to go to, but not what URI.
URI records will tell you more precisely what URI to query.

However, both mechanisms build a dependency on DNS that will not work in web
browsers.  One of the first uses of WebFinger (for which there are already a
few libraries available) is to query for information about people directly
from JavaScript in a browser.  Thus, it was preferred to use a .well-known
location rooted at the given host.
 
> 4) It would make §8 more readable if it were split into subsections. I
> think the first three paragraphs form a discussion about the transport
> security, the middle paragraphs discuss privacy, and the final paragraph
> discusses information reliability.

That's a good suggestion.  I'll make the changes (and adapt as I get through
other reviewers' comments).
 
> I suspect there is one more case to be concerned about, which is that it
> may be possible for an attacker to use webfinger resources to test the
> existence of a hypothetical user; that is, one might use webfinger as a
> harvesting mechanism.

Again, a valid point.  I'll insert text into a new sub-section just above
"Information Reliability" and call it "Abuse Potential".

Here's what I propose:

-----------------
8.3 Abuse Potential

Service providers should be mindful of the potential for abuse using
WebFinger.

As one example, one might query a WebFinger server only to discover
whether a given URI is valid or not.  With such a query, the person
may deduce that an email identifier is valid, for example.  Such an
approach could help spammers maintain a current list of known email
addresses and to discover new ones.

WebFinger could be used to associate a name or other personal
information with an email address, allowing spammers to craft more
convincing email messages.  This might be of particular value in
phishing attempts.
-----------------

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 20 Mar 2013 22:57:29 -0400

Stephane,

> Indeed, the example with IMAP in 3.3 confuses me. Why is is better than
> the standard RFC 6186?

Keep in mind that this is just an example, but one reason this approach is
"better" is that I could build an email client entirely in JavaScript
running in a browser using WF and some kind of configuration like this.  In
the end, we likely will not provision email clients exactly like this, but
that was not the expectation.  This example shows how one might do that and
demonstrates how "properties" might be used in WF.

Paul

---

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Mar 2013 11:55:10 +0000

> demonstrates how "properties" might be used in WF.

Right, but you're mixing the canonical description of WF with a reasonable
looking example which is actually not what's being standardized. I maintain
that it'll almost certainly cause confusion when people are looking for how
to provision and/or discovery email configuration, because it looks
plausible enough and it's in a standards track document. The fact that
Stéphane is even asking why it's better suggests this is happening to a
degree already; I'm afraid it looks like a standards proposal even if it's
dressed as an example.

Pick a small example that's not in conflict with ongoing standardization
work, please. I understand you want to demonstrate that WF can be used for
autoconfiguration; I suggest making up a service to autoconfigure.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Mar 2013 13:46:11 +0000

> is only an example and not the way client devices should be provisioned?

As stated elsewhere, I think this is very confusing, and already generating
the confusion I'm concerned about, in relation to RFC 6186 rather than
AggSrv, in fact.

I'd strongly prefer this example were removed, and replaced with something
else.

> were intended to avoid ambiguity.

Link relation types are a single one of those values, the <relation-type>
ABNF production, as opposed to the rel, which contains a <relation-types>.
I'm entirely with you on why you want to restrict your rel to a single link
relation type. Worth calling it out the difference, but it's not a
deviation from RFC 5988.

However, if you're changing the definition of link relation types, then:

a) I'm deeply concerned. Redefining a standards-track specification seems
worryingly close to NIH. There's horrible confusion lurking when someone
says "Link relation type" and then has to qualify which definition.

b) You need to make this absolutely clear in the document; it reads like
you're restating, not redefining.

c) The only distinction you claim above that appears to me to be an actual
distinction is that fragments are disallowed. Yet no such restriction
exists in the current draft.

> and so I think that text needs to remain.

Yes, I've probably trimmed too much there.

> but the procedures for one URI or another would be exactly the same.

I did say "security and otherwise". I'm not saying that any given URI
scheme should be discounted forever more, I am suggesting the document
should limit the schemes which have a defined behaviour for now.

I have no clue what the possible impacts of using webfinger on a message id
URI might be, nor do I wish to even think about it.

I'm pretty sure that mailto has some corner cases we've not yet thought
about; it's not just an email address after all.

> location rooted at the given host.

That sucks.

It's a shame that browsers are holding back use of SRV and other decade-old
technology for things like this.

But I accept that this has been discussed and blocked by browser brokenness.

> Here's what I propose:

That seems sensible.

Dave.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 21 Mar 2013 22:05:41 -0400

Dave,

I agree that it looks entirely plausible.  However, it cannot be implemented
as defined, because none of the rel values or property values are defined.
Of course, I could replace rel values like
http://webfinger.example/rel/smtp-server with
http://packetizer.com/rel/smtp-server and properties like
http://webfinger.example/email/host with http://packetizer.com/ns/host.
However, that does not make any of that standard.

I’m not interested to demonstrate that WF can be used for auto-provisioning.
Rather, I am interested to demonstrate use of “properties” in a “link
relation object” that has no “href” member.  Basically, this is example has
information that is entirely self-contained in the JRD and not dependent on
an external link.

You suggest I make up a service to auto-provision.  So, it concerns you only
that I have an example with IMAP or does it concern you that the example is
an auto-provisioning example?  I’m a little confused.

Paul

From: Dave Cridland [mailto:[email-masked]] 
Sent: Thursday, March 21, 2013 7:55 AM
To: Paul E. Jones
Cc: [email-masked]; Stephane Bortzmeyer
Subject: RE: [webfinger] Email autoconfiguration (Was: [apps-discuss]
AppsDir Review of draft-ietf-appsawg-webfinger-11

Dave.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 21 Mar 2013 22:50:41 -0400

Dave,

> Link relation types are a single one of those values, the
> <relation-type> ABNF production, as opposed to the rel, which contains a
> <relation-types>. I'm entirely with you on why you want to restrict your
> rel to a single link relation type. Worth calling it out the difference,
> but it's not a deviation from RFC 5988.

So, you are OK with the restriction?
 
> a) I'm deeply concerned. Redefining a standards-track specification
> seems worryingly close to NIH. There's horrible confusion lurking when
> someone says "Link relation type" and then has to qualify which
> definition.
>
> c) The only distinction you claim above that appears to me to be an
> actual distinction is that fragments are disallowed. Yet no such
> restriction exists in the current draft.

I'm still missing something.  How are we changing the definition of a link
relation type, aside from restricting rel to having a single value that is
either an absolute URI or a single link relation type?

Perhaps what might be confusing is the part that starts with "The other
members of the object have meaning only..."  probably should be a separate
paragraph.  The whole focus of the rest of the paragraph is to explain that
the other members of the "link relation object" can only be interpreted once
the link relation type is understood.

We had no intention of changing the definition of a link relation type,
though we do have the stated restrictions in 4.4.4.1: "rel" is exactly one
of either an absolute URI or a registered relation type.

> should limit the schemes which have a defined behaviour for now.

All URIs have the same defined behavior.  You ask the server if it has any
information about X and it replies with a JRD if it does or 404 if it does
not.  There is no difference in behavior between acct:[email-masked]
or h323:[email-masked].  Both are requesting information about the
person or thing associated with the URI.  As you can see, you'll get the
same answer:

$ curl
https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer
.com
$ curl
https://packetizer.com/.well-known/webfinger?resource=h323:paulej@packetizer
.com

(Except that the aliases array is modified.)
 
> I have no clue what the possible impacts of using webfinger on a message
> id URI might be, nor do I wish to even think about it.

Likely a 404.
 
> about; it's not just an email address after all.

On my server, that returns a JRD in the form of the example you do not like
so much. :-)

It would be entirely reasonable to also return the same JRD as the acct:
URI.  We struggled several years with whether to use mailto or acct.  Given
that some services do not have email (notably, Twitter), there were a push
for acct.  That's fairly well adopted at this point, but I would not dismiss
the use of mailto if that is the identifier one has in hand.

It might also be that aggsrv uses mailto to query for a JRD that has links
pointing to aggsrv documents.  I outlined two ways WF could be used to make
that happen during the BoF.  (But I did it with lightning speed due to time
constraints, so people might have blinked and missed it.)

> It's a shame that browsers are holding back use of SRV and other
> decade-old technology for things like this.  But I accept that this has
> been discussed and blocked by browser brokenness.

I agree. Folks have some security concerns with the prospect, though.  I'm
not sure exactly what those concerns are, but it would be nice if there was
a secure was to do SRV or URI record lookups from the browser.

Paul

---

From: Dave Cridland <[email-masked]>
Date: Fri, 22 Mar 2013 08:33:44 +0000

On 22 Mar 2013 02:05, "Paul E. Jones" <[email-masked]> wrote:
> I’m not interested to demonstrate that WF can be used for
auto-provisioning.  Rather, I am interested to demonstrate use of
“properties” in a “link relation object” that has no “href” member.
Basically, this is example has information that is entirely self-contained
in the JRD and not dependent on an external link.

Great, so find an example that demonstrates that.

>
> You suggest I make up a service to auto-provision.  So, it concerns you
only that I have an example with IMAP or does it concern you that the
example is an auto-provisioning example?  I’m a little confused.

My concern is that you have an example which overlaps an area of
standardization. I'd hate people to implement this instead of whatever
aggsrv comes up with.

Replace mail with blurdybloop and I'll be happy.

Dave.

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 22 Mar 2013 09:59:17 +0100

Hi all,

Autoconfiguration in general is a useful use case of webfinger and it would make sense to me to call it out explicitly. I could try to make an example focused on the social networking space in order not to conflict with email provisioning, although it may contain hrefs if this can accommodate all.

Then if we want an example to show link rels with properties and no href could we move this to the fictitious tipsi example adding another link rel with only properties (e.g. printer capabilities such as front-retro, a3 format, color, etc) ?

walter

Da: [email-masked] [mailto:[email-masked]] Per conto di Dave Cridland
Inviato: venerdì 22 marzo 2013 9.34
A: Paul E. Jones
Cc: [email-masked]; Stephane Bortzmeyer
Oggetto: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11

On 22 Mar 2013 02:05, "Paul E. Jones" <[email-masked]<mailto:[email-masked]>> wrote:
> I'm not interested to demonstrate that WF can be used for auto-provisioning.  Rather, I am interested to demonstrate use of "properties" in a "link relation object" that has no "href" member.  Basically, this is example has information that is entirely self-contained in the JRD and not dependent on an external link.
>
>

>
> You suggest I make up a service to auto-provision.  So, it concerns you only that I have an example with IMAP or does it concern you that the example is an auto-provisioning example?  I'm a little confused.

My concern is that you have an example which overlaps an area of standardization. I'd hate people to implement this instead of whatever aggsrv comes up with.

Dave.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 22 Mar 2013 09:32:09 +0000

> So, you are OK with the restriction?

Restricting it to a single link relation type (as defined by RFC 5988, and
the <relation-type> ABNF production therein) is perfectly fine.

So, you said, broken apart for readability:

>>> RFC 5988 allows for multiple values like 'rel="shortcut icon"', but
WebFinger does not.

I see that RFC 5988 allows its 'rel' parameter to hold multiple Link
Relation Types, yes. I agree that restricting this is reasonable. (I have
no view on whether it's sensible). However, that's referring to the RFC
5988 "rel" parameter (or attribute), and absolutely not the definition of
Link Relation Type, which is always a single registered token or an
absolute URI (which itself SHOULD be lowercased).

>>> RFC 5988 also allows URIs with fragments, but WebFinger does not.

Your current draft makes no restriction on whether a Link Relation Type may
have a fragment or not. It stipulates an absolute URI, which in RFC 3986
may have a fragment; therefore this restriction is not in the draft as
written. Neither is it in RFC 5988; however if you do intend adding this
restriction then this represents a deviation.

>>> Valid URIs must conform to Section 4.3 of RFC 3986 (Absolute URIs).

I'm not sure if you considered this a difference or not; as far as I can
tell RFC 5988 only allows absolute URIs (of the extended relation types),
though it explicitly calls out this requirement for the Link header itself.
Either way this seems reasonable, and not a deviation.

> of either an absolute URI or a registered relation type.

Right, which is a Link Relation Type as defined in RFC 5988.

Either you have changed the definition (or at least, rel doesn't hold a
link relation type), in which case my opinion remains that this is a bad
thing, but in any case needs to be made abundantly clear in the document...

... or you haven't, in which case I don't understand why you won't simply
reference RFC 5988 instead of referencing it piecemeal.

> > id URI might be, nor do I wish to even think about it.

I don't think whether it works is the sole consideration.

> On my server, that returns a JRD in the form of the example you do not
like

I said corner cases. Please read RFC 6068; you appear to be labouring under
the assumption that a mailto URI is identical to an acct URI except for the
scheme.

> the use of mailto if that is the identifier one has in hand.

I don't think mailto is nearly as simple as you seem to think it is. I
don't know enough about other URI schemes to know whether other schemes
have the same problem.

My issue here is not a matter of the good things that might reasonably
happen from careful use of simple URIs with arbitrary schemes; my concern
is that there may be bad things with odd cases and there's no evidence that
these have been thought through.

So for mailto, for example, I'd think you want to restrict the URI form
used to being, using RFC 6068's ABNF, '"mailto:" to', and avoid any other
forms. What I don't know - and given the way URIs can have entertaining
corner cases like this, what worries me - is not only whether the whole
thing works if you have an odd URI construct (mailto or no), but whether
it's safe.

I think as you look deeply into various URI schemes, there'll be cans of
worms in a number of places, and the safer thing to do is to restrict the
schemes and URI forms that are - currently - allowed. Look on the bright
side, you'll have the fun of specifying what a telnet URI should give you
back from WF.

At the very least, I'd suggest that you add a security consideration

> constraints, so people might have blinked and missed it.)

I listened to your presentation with interest, I've not yet formed a view
on how aggsrv ought to work, and I've personally not ruled out that
WebFinger ought to play a role in it. I've no "anti WF" axe to grind here;
in fact I'd have unequivocally supported using WF if it weren't for the
lack of SRV, which leaves me undecided.

I'm just concerned that this has the potential to be sidestepping the
standardization process inadvertently.

Dave.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 22 Mar 2013 10:09:29 -0400

Dave,

This example does demonstrate what I wanted to demonstrate.  So, in terms of
objective for the example, the example does the job.

So, the real concern is that it overlaps with aggsrv?  I'll note we
discussed this long before aggsrv, though it wasn't until November that such
an example was inserted because I was hoping Cyrus would produce an example.
He produced something that more-or-less replicates much of WebFinger.

There is a danger in giving an example of "blurdybloop".  The example in
Section 3.4 is like that.  It's entirely fictitious and people did express
concern with that.  There is no such thing as a "device" URI scheme, after
all.  However, I had to have something that demonstrated the applicability
of WF to things like this.  It's abstract, because I don't have a concrete
example to point to.

Now, with Section 3.3, I have something more concrete I can point to.  You
read it and understood it.  You rightfully pointed out that it looks
plausible.  That's the whole point and I wish I had something equally as
good for Section 3.4.  Still, though it looks plausible, it's not
implementable since none of the values (link relation type of properties)
are standard.  I'd say the example works.

Now, I insert something off-the-wall, it might not make as much sense to
people.  I need an example that people can understand and it clicks when
they read it.  So what kind of example could that be?  I don't have a good
example coming to mind right now.

Paul

Sent: Friday, March 22, 2013 4:34 AM

On 22 Mar 2013 02:05, "Paul E. Jones" <[email-masked]> wrote:
> I'm not interested to demonstrate that WF can be used for
auto-provisioning.  Rather, I am interested to demonstrate use of
"properties" in a "link relation object" that has no "href" member.
Basically, this is example has information that is entirely self-contained
in the JRD and not dependent on an external link.

only that I have an example with IMAP or does it concern you that the
example is an auto-provisioning example?  I'm a little confused.

Dave.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 22 Mar 2013 10:19:09 -0400

If it’s only a matter of email provisioning and any other kind of
auto-provisioning is OK, then I could insert an example of provisioning an
H.323 terminal.

If you have a good example for social networking that does not require an
href, that would be good.  Even if it was just one link that did not have an
href and only properties, that would work.  It needs to be concise, though.

Paul

From: Goix Laurent Walter [mailto:[email-masked]] 
Sent: Friday, March 22, 2013 4:59 AM
To: Dave Cridland; Paul E. Jones
Cc: [email-masked]; Stephane Bortzmeyer
Subject: R: [webfinger] Email autoconfiguration (Was: [apps-discuss] AppsDir
Review of draft-ietf-appsawg-webfinger-11

Hi all,

Autoconfiguration in general is a useful use case of webfinger and it would
make sense to me to call it out explicitly. I could try to make an example
focused on the social networking space in order not to conflict with email
provisioning, although it may contain hrefs if this can accommodate all.

Then if we want an example to show link rels with properties and no href
could we move this to the fictitious tipsi example adding another link rel
with only properties (e.g. printer capabilities such as front-retro, a3
format, color, etc) ?

walter

Da: [email-masked] [mailto:[email-masked]] Per conto
di Dave Cridland
Inviato: venerdì 22 marzo 2013 9.34
A: Paul E. Jones
Cc: [email-masked]; Stephane Bortzmeyer
Oggetto: Re: [webfinger] Email autoconfiguration (Was: [apps-discuss]
AppsDir Review of draft-ietf-appsawg-webfinger-11

Dave.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks. 

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 22 Mar 2013 14:25:26 +0000

On Fri, Mar 22, 2013 at 2:09 PM, Paul E. Jones <[email-masked]>wrote:

> So, the real concern is that it overlaps with aggsrv?  I’ll note we
> discussed this long before aggsrv, though it wasn’t until November that
> such an example was inserted because I was hoping Cyrus would produce an
> example.  He produced something that more-or-less replicates much of
> WebFinger.
>
>
This paragraph reads like your intention is to provide a proposal for
AggSrv. I do hope that's not the case.

> plausible.  That’s the whole point and I wish I had something equally as
> good for Section 3.4.  Still, though it looks plausible, it’s not
> are standard.  I’d say the example works.
>
>
>
It works as a strawman proposal for email autoconfiguration, but not as an
example for a specification on something else.

Dave.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 22 Mar 2013 11:16:18 -0400

Dave,

On 3/22/2013 5:32 AM, Dave Cridland wrote:
> Restricting it to a single link relation type (as defined by RFC 5988, 
> and the <relation-type> ABNF production therein) is perfectly fine.

OK

> >>> RFC 5988 allows for multiple values like 'rel="shortcut icon"', 
> but WebFinger does not.
>
> Relation Types, yes. I agree that restricting this is reasonable. (I 
> have no view on whether it's sensible). However, that's referring to 
> the RFC 5988 "rel" parameter (or attribute), and absolutely not the 
> definition of Link Relation Type, which is always a single registered 
> token or an absolute URI (which itself SHOULD be lowercased).

RFC 5988 says that "extension relation types are REQUIRED to be absolute 
URIs in Link headers".  However, we cannot simply assume that "Link 
Headers" also means "Link Relation Objects" in WebFinger.

That's why we make it clear:

'The value of the "rel" member is a string that is either an absolute 
URI or a registered relation type [10] (see RFC 5988 [4]).'

So, I don't see an issue with that sentence.  The rest of the first 
paragraph in the WF spec (up to the point where I'm proposing the 
paragraph break) would then read:

"The value of the "rel" member MUST contain exactly one URI or 
registered relation type.  The URI or registered relation type 
identifies the type of the link relation."

Any concern with this part?

> Your current draft makes no restriction on whether a Link Relation 
> Type may have a fragment or not. It stipulates an absolute URI, which 
> in RFC 3986 may have a fragment; therefore this restriction is not in 
> the draft as written. Neither is it in RFC 5988; however if you do 
> intend adding this restriction then this represents a deviation.

The WF spec says link relation types MUST be either absolute URIs or 
registered a registered relation type.  Per RFC 3986, absolute URIs do 
not have fragments (See Section 4.3).  RFC 5988 also requires use of 
absolute URIs when used in Link Headers.  Perhaps the intent was to 
always require absolute URIs?  I don't know, since the text limits the 
statement to "Link Headers".  WebFinger wants the same restriction, so 
we inserted an explicit statement.

> I'm not sure if you considered this a difference or not; as far as I 
> can tell RFC 5988 only allows absolute URIs (of the extended relation 
> types), though it explicitly calls out this requirement for the Link 
> header itself. Either way this seems reasonable, and not a deviation.

It does, but the document is scoped for HTTP headers.  We need an 
explicit statement for WEbFinger, since it's not HTTP headers and RFC 
5988 limits the absolute URI wording to Link headers.

> > though we do have the stated restrictions in 4.4.4.1 
> <http://4.4.4.1>: "rel" is exactly one
> Either you have changed the definition (or at least, rel doesn't hold 
> a link relation type), in which case my opinion remains that this is a 
> bad thing, but in any case needs to be made abundantly clear in the 
> document...
>
> ... or you haven't, in which case I don't understand why you won't 
> simply reference RFC 5988 instead of referencing it piecemeal.

We tried referencing RFC 5988 as much as we could.  But, since that text 
speaks explicitly of HTTP Link Headers and places restrictions only 
there in the text, while the ABNF is more relaxes, we felt it was 
necessary to state more-or-less the same "absolute URI" requirement in 
WebFinger.

I don't see this as a re-definition.  I do think it's valuable, as it 
makes it clear.

So, we have these two paragraphs now in that section:

The value of the "rel" member is a string that is either an absolute URI 
or a registered relation type [10] (see RFC 5988 [4]).  The value of the 
"rel" member MUST contain exactly one URI or registered relation type.  
The URI or registered relation type identifies the type of the link 
relation.

The other members of the object have meaning only once the type of link 
relation is understood.  In some instances, the link relation will have 
associated semantics enabling the client to query for other resources on 
the Internet.  In other instances, the link relation will have 
associated semantics enabling the client to utilize the other members of 
the link relation object without fetching additional external resources.

The first paragraph has to do with the "rel" values, leaning on RFC 
5988, but being explicit in applying the same "absolute URI" 
requirement.  It does add the restriction of not allowing more than one 
value inside "rel" (whereas RFC 5988 allow for an unlimited number).  
The second paragraph as WF-specific, talking about the other members of 
the "link relation object", which is something specific to WF.

> I don't think whether it works is the sole consideration.

Agreed.

> I said corner cases. Please read RFC 6068; you appear to be labouring 
> under the assumption that a mailto URI is identical to an acct URI 
> except for the scheme.
>

I make no assumption.  With WF, a URI of any form is just a "resource" 
identifier.  Given that identifier, one gets back a JRD.

> don't know enough about other URI schemes to know whether other 
> schemes have the same problem.

I'm quite familiar with mailto URIs and recognize that they're complex, 
or can be.

> happen from careful use of simple URIs with arbitrary schemes; my 
> concern is that there may be bad things with odd cases and there's no 
> evidence that these have been thought through.

Nothing "bad" can happen.  Either a WF query returns useful information 
or it does not.  Use of any particular URI scheme will come about either 
through common usage or through standardization efforts.

>
> So for mailto, for example, I'd think you want to restrict the URI 
> form used to being, using RFC 6068's ABNF, '"mailto:" to', and avoid 
> any other forms. What I don't know - and given the way URIs can have 
> entertaining corner cases like this, what worries me - is not only 
> whether the whole thing works if you have an odd URI construct (mailto 
> or no), but whether it's safe.
>
> I think as you look deeply into various URI schemes, there'll be cans 
> of worms in a number of places, and the safer thing to do is to 
> restrict the schemes and URI forms that are - currently - allowed. 
> Look on the bright side, you'll have the fun of specifying what a 
> telnet URI should give you back from WF.

URI schemes can have many forms, have parameters, etc.  They range from 
simple to complex.  However, a WF server that accepts any given URI 
scheme will understand that URI scheme and will return useful 
information.  If it does not understand the scheme (or does not have 
information for the particular URI), it will return a 404.

I strongly believe we should allow use of any URI scheme.  Any 
complexities that arise will either be addressed through common usage or 
as part of a standardization effort.

> At the very least, I'd suggest that you add a security consideration

What should we add?  I'm not seeing any new or different security issues 
arising from use of any particular URI scheme.  Every URI returns either 
a JRD or it does not.  What would be different with mailto, http, sip, 
tel, gopher, or any other scheme?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 22 Mar 2013 11:25:47 -0400

On 3/22/2013 10:25 AM, Dave Cridland wrote:
> On Fri, Mar 22, 2013 at 2:09 PM, Paul E. Jones <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     discussed this long before aggsrv, though it wasn’t until November
>     that such an example was inserted because I was hoping Cyrus would
>     produce an example.  He produced something that more-or-less
>     replicates much of WebFinger.
>
>

No, I provided my proposal at the BoF.  For those who did not see it, 
here are the slides:
http://www.ietf.org/proceedings/86/slides/slides-86-aggsrv-3.pdf

I believe WF could be used as a means of acquiring the service 
information, which could either be aggregated by a service provider or 
IT department (a bit of a pain, IMO) or aggregated by the client (work 
on the client, but allows for direct access to third-party service 
configuration documents.)

But, this is off topic :-)

>     Now, with Section 3.3, I have something more concrete I can point
>     to.  You read it and understood it.  You rightfully pointed out
>     that it looks plausible. That’s the whole point and I wish I had
>     something equally as good for Section 3.4.  Still, though it looks
>     plausible, it’s not implementable since none of the values (link
>     relation type of properties) are standard.  I’d say the example works.
>
>
> It works as a strawman proposal for email autoconfiguration, but not 
> as an example for a specification on something else.
>

It wasn't intended to be a proposal, but just a clear example. Perhaps 
Walter or someone can come up with a replacement that is equally clear.

However, I'd prefer to keep it and would not be opposed to adding a 
statement that made it abundantly clear that the example does not 
represent any agreed means of provisioning an email client as there are 
(or will be) other standards to accomplish that task.

Would you like to suggest such wording or do you still insist we replace 
the example?  And will we have someone else objecting to that example? :-(

Paul

---

From: Dave Cridland <[email-masked]>
Date: Fri, 22 Mar 2013 16:53:35 +0000

On Fri, Mar 22, 2013 at 3:16 PM, Paul E. Jones <[email-masked]>wrote:

> Your current draft makes no restriction on whether a Link Relation Type
> may have a fragment or not. It stipulates an absolute URI, which in RFC
> 3986 may have a fragment; therefore this restriction is not in the draft as
> registered a registered relation type.  Per RFC 3986, absolute URIs do not
> have fragments (See Section 4.3).  RFC 5988 also requires use of absolute
> URIs when used in Link Headers.  Perhaps the intent was to always require
> absolute URIs?  I don't know, since the text limits the statement to "Link
> Headers".  WebFinger wants the same restriction, so we inserted an explicit
> statement.
>
>
Ah, there's my error, then - I'd made the mistake of assuming "absolute"
meant the same as "not relative".

I still think that first sentence might be reworded, but it's good enough
as is.

> Nothing "bad" can happen.
>

Oh, well that's OK, then. :-)

> arising from use of any particular URI scheme.  Every URI returns either a
> JRD or it does not.  What would be different with mailto, http, sip, tel,
> gopher, or any other scheme?
>

sip, simple mailto, acct, xmpp, and so on - those URIs which refer
explicitly to an individual - are, I think, adequately considered in the
specification.

http seems to be considered only when referring to a person. However, in
general http resources can have links anyway, so I'm not concerned about
these - however I'm not sure that the fragment identifier needs to be sent.

I'm entirely willing to believe you've considered these considerably more
than that, however there's no evidence of it in the specification as
written.

I've spent very little time considering what might happen (beyond a 404)
with arbitrary URI schemes. Should a client ever send a file: URI, for
example? I'm not concerned with what information in the JRD it might be
expecting, or whether or not the WF server understands it, but what
information transfer has occurred and whether this is safe and can
reasonably be expected to be interoperable.

For example, I'd expect a sensible WF client to only ever send a simple
mailto:local-part@domain URI to a server, and if the initial input was one
of the deliciously complex forms, to strip away the header fields and body
and extract (if needed) the To field value. I have no clue what a WF server
might usefully do with a subject line, mind, whether it's malicious or not
- I just think it doesn't need to have it.

I'd suggest simply stating that the security considerations and protocol
are scoped to consider only URIs identifying an individual entity, (perhaps
give some simple examples), and that use beyond that may involve further
security considerations. Then everyone's happy.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 22 Mar 2013 17:17:02 +0000

The problem with concrete examples is that people expect them to be
concrete, rather than examples.

My concerns remain with this example, but I'll leave it to your decision.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 23 Mar 2013 15:05:08 -0400

Dave,

An "http" URI could be used to query information about a web page.  It might
return "copyright" or "author" or other defined link relation values.  Had
WF existed when OpenID 2.0 was drafted, it could have been used to resolve
the OpenID Provider information for a given OpenID identifier.  WebFinger
might be used to find other information about things on the Internet,
including printer, refrigerators, thermostats, or whatever.  What one would
or should expect for various URI schemes is not fully-defined, except that
any URI will return a JRD document with links.  How those links are
interpreted will be defined by whatever document defines the link relation
types or some document such as "Discovering Information about X using
WebFinger" (where "X" might be a printer, thermostat, or whatever).

So, it's not accurate to say the document is scoped to return information
only about individuals.  We put most of the emphasis there, because that has
the most immediate practical use and we expect the 'acct' URI type to be
used primarily.

Paul

For example, I'd expect a sensible WF client to only ever send a simple
mailto:local-part@domain URI to a server, and if the initial input was one
of the deliciously complex forms, to strip away the header fields and body
and extract (if needed) the To field value. I have no clue what a WF server
might usefully do with a subject line, mind, whether it's malicious or not -
I just think it doesn't need to have it.

I'd suggest simply stating that the security considerations and protocol are
scoped to consider only URIs identifying an individual entity, (perhaps give
some simple examples), and that use beyond that may involve further security
considerations. Then everyone's happy.

Dave.