Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 01 Feb 2013 10:14:39 -0500

Mervin,

What would be the reason? There are tons of applications that return JSON, but they don't each have their own media type. We did that with XML and have tons of media types, ask of which are just XML documents.

What is preferred by others? My preference is to leave it as defined. Clients know what the response is.

Paul

-------- Original Message --------
From: Melvin Carvalho <[email-masked]>
Sent: Tue Jan 29 13:40:38 EST 2013
To: Salvatore Loreto <[email-masked]>
Cc: [email-masked], "Murray S. Kucherawy" <[email-masked]>
Subject: Re: [webfinger] Working Group Last Call for	draft-ietf-appsawg-webfinger-09

On 28 January 2013 19:13, Salvatore Loreto <[email-masked]>wrote:

>  Dear WG partecipants,
>
>
> I would like to initiate a 2 weeks WG Last Call on
> draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
> http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt<http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.txt>
>
>
> Please send your reviews, as well as expression of support regarding
> document readiness for IESG (or not) either to the **webfinger** mailing
> list ([email-masked]),
> or directly to the WG chairs (Murray Kucherawy and myself).
>
> Comments like "I've read the document and it is Ok to publish" or
> "I've read the document and it has the following issues"
> are useful and would be gratefully accepted by chairs.
>

I have read the document and I think the JRD should have it's own MIME
type, which the client SHOULD send with the HTTP(S) GET.

>
>
> The WG LC will end on Friday, February 8th.
>
>
> Thank you,
> Salvatore as an APPSAWG co-chair.
>
>
>
> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger
>
>

------------------------------------------------------------------------

_______________________________________________
webfinger mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/webfinger

---

From: Melvin Carvalho <[email-masked]>
Date: Fri, 1 Feb 2013 16:30:56 +0100

On 1 February 2013 16:14, Paul E. Jones <[email-masked]> wrote:

> Mervin,
>
> What would be the reason? There are tons of applications that return JSON,
> but they don't each have their own media type. We did that with XML and
> have tons of media types, ask of which are just XML documents.
>

Examining Eran's original post on JRD has it's own MIME type, which I
believe was always the intention:

Accept: application/xrd+json

http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comment-8122

In previous discussions, at least one person (I think it may have been Tim
Bray) has stated that this represents a best practice.

There are many JSON serializations out there, with JRD being relatively
bespoke.

A MIME type would help the client understand what data it is getting
without close coupling to the URL that returned it, and also would aid
interoperability with other formats, in particular, many implementations
still use XRD, which uses (application/xrd+xml)

> Paul
>
> ------------------------------
> *From:* Melvin Carvalho <[email-masked]>
> *Sent:* Tue Jan 29 13:40:38 EST 2013
> *To:* Salvatore Loreto <[email-masked]>
> *Cc:* [email-masked], "Murray S. Kucherawy" <[email-masked]>
> *Subject:* Re: [webfinger] Working Group Last Call for
> draft-ietf-appsawg-webfinger-09
>
>
>
> ------------------------------
>
> webfinger mailing list
> [email-masked]

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 1 Feb 2013 18:19:02 +0200

someone pointed out that
the embedded link to WF, in the original announcement, takes you to the 
acct uri draft.

sorry it was a cut and paste error!

*here the right one:*
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-09

/Salvatore

On 1/28/13 8:13 PM, Salvatore Loreto wrote:
> http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt
>
>
> document readiness for IESG (or not) either to the *webfinger* mailing

---

From: John Bradley <[email-masked]>
Date: Fri, 1 Feb 2013 14:03:54 -0300

I have a hard time getting excited about the mime type.

Having a specific mime type for JRD would be useful if we were going to allow alternate JSON serializations.
Lets not do that.  Or if someone is going to let them register a specific mime type for there JSON serialization.

I think the spec is fine as is.  I think it is ready for the IESG.

John B.

On 2013-02-01, at 12:30 PM, Melvin Carvalho <[email-masked]> wrote:

> Examining Eran's original post on JRD has it's own MIME type, which I believe was always the intention:
> 
> In previous discussions, at least one person (I think it may have been Tim Bray) has stated that this represents a best practice.
> 
> There are many JSON serializations out there, with JRD being relatively bespoke.  
> 
> A MIME type would help the client understand what data it is getting without close coupling to the URL that returned it, and also would aid interoperability with other formats, in particular, many implementations still use XRD, which uses (application/xrd+xml)
> 
> 
> Paul
> 
> On 28 January 2013 19:13, Salvatore Loreto <[email-masked]> wrote:
> Dear WG partecipants, 
> 
> 
> document readiness for IESG (or not) either to the *webfinger* mailing list ([email-masked]), 
> I have read the document and I think the JRD should have it's own MIME type, which the client SHOULD send with the HTTP(S) GET.  
>  
> 
>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Fri, 1 Feb 2013 09:12:46 -0800

+1

Looks good to me.

---

From: SM <[email-masked]>
Date: Thu, 31 Jan 2013 16:15:19 -0800

At 10:16 28-01-2013, Salvatore Loreto wrote:
>the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started.
>Please see the mail below and note that the right venue for discussion is
>the *webfinger* mailing list

These are quick comments.

In Section 3.1:

   "rel" : "http://webfinger.net/rel/avatar",
            "type" : "image/jpeg",
            "href" : "http://www.example.com/~bob/bob.jpg"
          },
          {
            "rel" : "http://webfinger.net/rel/profile-page",
            "href" : "http://www.example.com/~bob/"

In Section 4.3:

   In this example, the client requests the link relations of type
    "http://webfinger.net/rel/profile-page" and "vcard".  The server then

   "links" :
        [
          {
            "rel" : "http://webfinger.net/rel/profile-page",
            "href" : "http://www.example.com/~bob/"

In Section 4.4.4:

  "properties" : { "http://webfinger.net/ns/name" : "Bob Smith" }

I suggest using RFC 2606 domain names.

In the references section:

RFC 4288 should be replaced by RFC 6838.

In Section 3.3:

   "WebFinger could be used to auto-provision an email client with basic
    configuration data."

RFC 6186 describes how SRV records can be used to locate email 
services.  It's confusing if there is another Proposed Standard 
specifying another way to do the same thing.

In Section 4.3:

   "Support for the "rel" parameter is OPTIONAL, but RECOMMENDED on the
    server."

Either the above is recommended or it is optional.  Having both does 
not make sense (see RFC 2119).

In Section 4.4.5.1:

   "The value of the "rel" member MUST contain exactly one URI string
    or registered relation type and MUST NOT contain a space-separated
    list of URIs or registered relation types."

The MUST condition already implies the "MUST NOT" condition.  What's 
a URI string?

In Section 7:

   "An MX record points to the mail server to which mail for the domain
    should be delivered.  It does not matter to the sending mail server
    whether those MX records point to a server in the destination domain
    or a different domain."

It may be easier to reference RFC 5321 instead of explaining how SMTP works.

In Section 8:

   "Clients MUST verify that the certificate used on an HTTPS connection
    is valid and accept a response only if the certificate is valid."

Maybe the working group would like to reference RFC 6125.

   "WebFinger server MUST NOT be used to provide any personal information
    to any party unless explicitly or implicitly authorized by the person
    whose information is being shared."

I suggest using "consent" instead of "authorized".

   "Implicit authorization can be determined by the user's voluntary
    utilization of a service as defined by that service's relevant
    terms of use or published privacy policy."

I don't think it is up to this document to get into such 
advice.  People generally do not read the terms of service or privacy 
policy.  The guidance comes out as how to get around the "MUST NOT".

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Sat, 2 Feb 2013 11:20:58 -0500

> What would be the reason? There are tons of applications that return
JSON, but they
> don't each have their own media type. We did that with XML and have tons
of media
> types, ask of which are just XML documents.

The general reason is that if someone sends you an email message, for
example, with an application/xml attachment, how is your mail program to
know which program to run in order to handle it?  It's not like we have a
generic XML handler that parses XML, figures out what program it's for,
then invokes it with the parsed XML.  The distinct media types help sort
this out.

You can argue that you have context from elsewhere that makes this work
without media types, but that won't always be the case with many JSON
things.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Feb 2013 15:58:56 -0700

> Looks good to me.

Here too. I sent a bunch of editorial feedback to the authors, but I
see no substantive technical problems here. Kudos to the authors for
their work on the spec!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 4 Feb 2013 23:08:23 -0500

On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Thanks for the extremely detailed review.  Upon quick inspection the suggested edits seem perfectly reasonable.  The post WGLC version will include these.

Gonzalo

> 
> Peter
> 
> - -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT
> /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =RV/l
> -----END PGP SIGNATURE-----

---

From: Tim Bray <[email-masked]>
Date: Mon, 4 Feb 2013 20:49:10 -0800

One editorial issue, which has no effect on the actual normative effect.
4.2 says “A WebFinger client issues a query to the well-known [3] resource
   /.well-known/webfinger.”

Um, not really; that isn’t a resource, that’s part of a URI.  Language
should be along the lines of “It issues a query to the resource identified
by the URI whose path component begins with “/.well-known/webfinger?” and
whose query component MUST include include the "resource" parameter
exactly....” [proceed as before].

I’d say I hate to be pedantic, but evidence would be against me.  In my
defense, publications of the IETF should be careful of their nomenclature
about important things like resources and URIs.  -T

On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro <[email-masked]>wrote:

> Thanks for the extremely detailed review.  Upon quick inspection the
> suggested edits seem perfectly reasonable.  The post WGLC version will
> include these.
>
> Gonzalo
>
> >
> > Peter
> >
> > - --
> > Peter Saint-Andre
> > https://stpeter.im/
> >
> >

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 5 Feb 2013 00:00:18 -0500

Pedantic is good in this case.  A subtle difference, but valid IMO.  I think we can improve the wording but I understand the spirit of your comment.  I'll let Paul (as principal editor) comment on specific text.

Thanks,

Gonzalo

On Feb 4, 2013, at 11:49 PM, Tim Bray <[email-masked]> wrote:

> One editorial issue, which has no effect on the actual normative effect.  4.2 says “A WebFinger client issues a query to the well-known [3] resource
>    /.well-known/webfinger.”  
> 
> Um, not really; that isn’t a resource, that’s part of a URI.  Language should be along the lines of “It issues a query to the resource identified by the URI whose path component begins with “/.well-known/webfinger?” and whose query component MUST include include the "resource" parameter exactly....” [proceed as before].
> 
> I’d say I hate to be pedantic, but evidence would be against me.  In my defense, publications of the IETF should be careful of their nomenclature about important things like resources and URIs.  -T
> 
> 
> On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro <[email-masked]> wrote:
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 6 Feb 2013 00:05:29 -0500

Tim,

I agree that this is the URI that identifies the resource.  Even so, it is
the resource.

Consider,

  "Tim submitted a suggestion to the co-author Paul"

vs.

"Time submitted a suggestion to the co-author identified by the given name
Paul"

The second form and the first are the same.  I am Paul and I am identified
by the given name.  Likewise, "/.well-known/webfinger" is often referred to
as the resource.  It's not the resource, but it's the name of the resource.

In section 4.1 we (I think you) introduced text to help clarify what we mean
by a URI parameter.  The intent was to not have to have so much verbosity
every time we talk about a URI parameter.

What Peter suggested to me separately is that we put the name of the
well-known location in quotes.  Thus, we have:

    A WebFinger client issues a query to the well-known [3] resource
"/.well-known/webfinger"

I agree we need to be precise, but it makes the text more difficult to read.
What's a reasonable compromise?

The Co-Author Identified by the Given Name Paul ;-)

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tim Bray
Sent: Monday, February 04, 2013 11:49 PM
To: Gonzalo Salgueiro
Cc: Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter Saint-Andre;
[email-masked]
Subject: Re: [webfinger] Working Group Last Call for
draft-ietf-appsawg-webfinger-09

One editorial issue, which has no effect on the actual normative effect.
4.2 says "A WebFinger client issues a query to the well-known [3] resource
   /.well-known/webfinger."  

Um, not really; that isn't a resource, that's part of a URI.  Language
should be along the lines of "It issues a query to the resource identified
by the URI whose path component begins with "/.well-known/webfinger?" and
whose query component MUST include include the "resource" parameter
exactly...." [proceed as before].

I'd say I hate to be pedantic, but evidence would be against me.  In my
defense, publications of the IETF should be careful of their nomenclature
about important things like resources and URIs.  -T

On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro <[email-masked]>
wrote:

Gonzalo

---

From: Tim Bray <[email-masked]>
Date: Tue, 5 Feb 2013 21:16:41 -0800

These things all live in the context of the WWW, and I think the
nomenclature in http://www.w3.org/TR/webarch/ applies.  The Web consists of
Resources, which are identified by URIs, that’s all there is to it.

Per webfinger, there should be a resource identified by the URI “
https://www.textuality.com/.well-known/webfinger?resource=acct:[email-masked]”
On the other hand, “./well-known/webfinger” is not in any sane sense of the
word a “resource”, it’s a string fragment you’re using to assemble a URI to
identify a particular webfinger resource.

The webfinger spec describes how to construct the URI to identify the
resource by specifying the construction of the path and query components of
the URI. These are totally conventional web operations and should be
referred to by conventional web terminology.  -T

On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones <[email-masked]> wrote:

> Tim,****
> ** **
> the resource.****
> ** **
> Consider,****
> ** **
>   “Tim submitted a suggestion to the co-author Paul”****
>
> ** **
>
> vs.****
>
> ** **
>
> “Time submitted a suggestion to the co-author identified by the given name
> Paul”****
>
> ** **
>
> by the given name.  Likewise, “/.well-known/webfinger” is often referred to
> as the resource.  It’s not the resource, but it’s the name of the resource.
> ****
>
> ** **
>
> In section 4.1 we (I think you) introduced text to help clarify what we
> mean by a URI parameter.  The intent was to not have to have so much
> verbosity every time we talk about a URI parameter.****
>
> ** **
>
> well-known location in quotes.  Thus, we have:****
>
> ** **
>
> “/.well-known/webfinger”****
>
> ** **
>
> I agree we need to be precise, but it makes the text more difficult to
> read.  What’s a reasonable compromise?****
>
> ** **
>
> The Co-Author Identified by the Given Name Paul ;-)****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Tim Bray
> *Sent:* Monday, February 04, 2013 11:49 PM
> *To:* Gonzalo Salgueiro
> *Cc:* Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter
> Saint-Andre; [email-masked]
> draft-ietf-appsawg-webfinger-09****
>
> ** **
>
> exactly....” [proceed as before].****
>
> about important things like resources and URIs.  -T****
>
> ** **
>
> wrote:****
> > their work on the spec!****
>
> Gonzalo****
> https://www.ietf.org/mailman/listinfo/webfinger****
>
> ** **
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 6 Feb 2013 00:55:36 -0500

SM,

> I suggest using RFC 2606 domain names.

You just want to replace all references to webfinger.net with something like
example.com or webfinger.example?

The reason these are here is that these are in use today.  I don't mind
changing them, though.  What do others think?

> RFC 4288 should be replaced by RFC 6838.

Changed.
 
> RFC 6186 describes how SRV records can be used to locate email services.
> It's confusing if there is another Proposed Standard specifying another
> way to do the same thing.

This is just an example.  That said, I'd personally prefer to use WF to
solve this kind of problem than SRV records.  The SRV approach presents
certain administrative challenges and it's not tailored for a specific user.
Rather, it applies to the whole domain.  So, if you and I have accounts on
packetizer.com, for example, there is no means of telling our respective
mail clients which server to use if our mailbox accounts are provisioned on
different servers.

I believe Cyrus is still working to come up with the best solution to this
provisioning issue.

> Either the above is recommended or it is optional.  Having both does not
> make sense (see RFC 2119).

OK.  How about this?

"Servers SHOULD support for the "rel" parameter"

> The MUST condition already implies the "MUST NOT" condition.  What's a
> URI string?

Now reads:

   'The value of the "rel" member MUST contain exactly one URI
    or registered relation type.'
 
> It may be easier to reference RFC 5321 instead of explaining how SMTP

I do not think we should replace this simple explanation with a reference to
a 95-page document.  Nobody needs to be a mail server expert to read what is
written there now.  One only needs to understand the high-level idea.  I'm
not opposed to adding an informative reference, if you think that helps.  I
just don't think it does.
 
> Maybe the working group would like to reference RFC 6125.

Separately, Peter suggested a reference to RFC 2818, so I inserted that.
Should it be 6125?
 
> I suggest using "consent" instead of "authorized".

"... implicitly consented by..."?

Or,
"... implicitly approved by ..."?
"... implicitly agreed by ..."?
"... implicitly allowed by ..."?

Personally, I like "authorized", but I'll take suggestions.  If we want
"consent", I would suggest re-wording as:

"unless consent is obtained explicitly or implicitly from the person whose
information is being shared"

> I don't think it is up to this document to get into such advice.  People
> generally do not read the terms of service or privacy policy.  The
> guidance comes out as how to get around the "MUST NOT".

James wanted that.

James, can we strike that sentence?

Paul

---

From: James M Snell <[email-masked]>
Date: Tue, 5 Feb 2013 22:25:22 -0800

So long as it remains clear that consent can be explicit or implicit...
that's fine.

On Tue, Feb 5, 2013 at 9:55 PM, Paul E. Jones <[email-masked]> wrote:

> [snip]

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 6 Feb 2013 02:18:37 -0500

Ok, too tired to argue ;-)  You're right, but. darn, that's verbose.

It now reads:

'A WebFinger client issues a query to the well-known [3] resource identified
by the URI whose path component begins with "/.well-known/webfinger" and
whose query component MUST include the "resource" parameter exactly once and
set to the value of the URI for which information is being sought.'

To avoid further verbosity, I tried to sidestep the issue by replacing
"/.well-known/webfinger" in the document (not the examples, but just the
prose).  Those changes are:

Section 6:

"As with all web resources, access to the WebFinger resource ..."

Section 7:

"When a query is issued to the WebFinger resource, ..."

"This WebFinger service URL does not need to point to the well-known
WebFinger location on the hosting service provider server."

Are those other changes OK?

Paul

From: Tim Bray [mailto:[email-masked]] 
Sent: Wednesday, February 06, 2013 12:17 AM
To: Paul E. Jones
Cc: Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy;
Peter Saint-Andre; [email-masked]
Subject: Re: [webfinger] Working Group Last Call for
draft-ietf-appsawg-webfinger-09

These things all live in the context of the WWW, and I think the
nomenclature in http://www.w3.org/TR/webarch/ applies.  The Web consists of
Resources, which are identified by URIs, that's all there is to it. 

Per webfinger, there should be a resource identified by the URI
"https://www.textuality.com/.well-known/webfinger?resource=acct:tbray@textua
lity.com" On the other hand, "./well-known/webfinger" is not in any sane
sense of the word a "resource", it's a string fragment you're using to
assemble a URI to identify a particular webfinger resource.

Tim,

Consider,

vs.

Gonzalo

---

From: SM <[email-masked]>
Date: Tue, 05 Feb 2013 23:38:13 -0800

Hi James,
At 22:25 05-02-2013, James M Snell wrote:
>So long as it remains clear that consent can be explicit or 
>implicit... that's fine.

It may be better not to get into whether the consent is explicit or 
implicit.  if the working group wants the "consent" to be clear it 
may turn into a non-webfinger discussion.

Regards,
-sm

---

From: Tim Bray <[email-masked]>
Date: Wed, 6 Feb 2013 08:07:12 -0800

Thanks, looks good. I see you used the string "URL"; intentional, or did
you mean URI?
On Feb 5, 2013 11:18 PM, "Paul E. Jones" <[email-masked]> wrote:

> Ok, too tired to argue ;-)  You’re right, but… darn, that’s verbose.****
>
> ** **
>
> It now reads:****
>
> ** **
>
> ‘A WebFinger client issues a query to the well-known [3] resource
> identified by the URI whose path component begins with
> “/.well-known/webfinger” and whose query component MUST include the
> “resource” parameter exactly once and set to the value of the URI for which
> information is being sought.’****
>
> ** **
>
> “/.well-known/webfinger” in the document (not the examples, but just the
> prose).  Those changes are:****
>
> ** **
>
> Section 6:****
>
> “As with all web resources, access to the WebFinger resource ...”****
>
> ** **
>
> Section 7:****
>
> “When a query is issued to the WebFinger resource, ...”****
>
> “This WebFinger service URL does not need to point to the well-known
> WebFinger location on the hosting service provider server.”****
>
> ** **
>
> Are those other changes OK?****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* Tim Bray [mailto:[email-masked]]
> *Sent:* Wednesday, February 06, 2013 12:17 AM
> *To:* Paul E. Jones
> *Cc:* Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray
> Kucherawy; Peter Saint-Andre; [email-masked]
> nomenclature in http://www.w3.org/TR/webarch/ applies.  The Web consists
> of Resources, which are identified by URIs, that’s all there is to it.
>
> identify a particular webfinger resource.****
>
> referred to by conventional web terminology.  -T****
>
> ** **
>
> On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones <[email-masked]>
> wrote:****
>
> Tim,****
>
>  ****
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 7 Feb 2013 00:37:08 -0500

Actually, the revised text was using URI, but I should have used URL to be
consistent with other parts of the document.  Every place where we refer to
the WebFinger resource, we say "URL".

The acronym "URL" appears 5 times in the document.

Most other places we use the term "URI" since the "href" can be any URI, the
resource parameter is a URI, etc.

Paul

From: Tim Bray [mailto:[email-masked]] 
Sent: Wednesday, February 06, 2013 11:07 AM
To: Paul E. Jones
Cc: Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy;
[email-masked]; Brad Fitzpatrick; Gonzalo Salgueiro
Subject: RE: [webfinger] Working Group Last Call for
draft-ietf-appsawg-webfinger-09

Thanks, looks good. I see you used the string "URL"; intentional, or did you
mean URI?

It now reads:

Section 6:

Section 7:

Paul

Tim,

Consider,

vs.

Gonzalo

---

From: Tim Bray <[email-masked]>
Date: Wed, 6 Feb 2013 21:42:39 -0800

Quoting from http://tools.ietf.org/html/rfc3986#section-1.1.3: “Future
specifications and related documentation should use the general term "URI"
rather than the more  restrictive terms "URL" and "URN"”

- your favorite Web-architecture pedant, T

On Wed, Feb 6, 2013 at 9:37 PM, Paul E. Jones <[email-masked]> wrote:

> the WebFinger resource, we say “URL”.****
>
> ** **
>
> The acronym “URL” appears 5 times in the document.****
>
> ** **
>
> Most other places we use the term “URI” since the “href” can be any URI,
> the resource parameter is a URI, etc.****
>
> ** **
>
> Paul****
>
> ** **
>
> *Sent:* Wednesday, February 06, 2013 11:07 AM
> *To:* Paul E. Jones
> *Cc:* Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy;
> *Subject:* RE: [webfinger] Working Group Last Call for
> you mean URI?****
> On Feb 5, 2013 11:18 PM, "Paul E. Jones" <[email-masked]> wrote:***
> *
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 7 Feb 2013 01:10:31 -0500

I'll note that says "should" and not even normatively.

In every instance where we use URL, it is a locator.  Unless we're striking
the term URL entirely from the IETF vocabulary, I think it's more
appropriate to use URL where we do.

I'm perplexed by this sentence, actually.  It reads like "we've invented
cars and trucks, both of which are called automobiles.  However, you should
never refer to cars as cars or trucks as trucks.  Rather, you should only
speak of automobiles, even if you're referring only to a truck."

Why?  I must be missing something.

Your favorite co-author identified by a name whose given component is Paul

Sent: Thursday, February 07, 2013 12:43 AM

Quoting from http://tools.ietf.org/html/rfc3986#section-1.1.3: "Future
specifications and related documentation should use the general term "URI"
rather than the more  restrictive terms "URL" and "URN""

Paul

It now reads:

Section 6:

Section 7:

Paul

Tim,

Consider,

vs.

Gonzalo

---

From: Tim Bray <[email-masked]>
Date: Wed, 6 Feb 2013 22:20:38 -0800

If the WG is OK with ignoring the perfectly-clear terminology guidance from
RFC3986, I’m certainly not going to lie down in the road over it.

-T

On Wed, Feb 6, 2013 at 10:10 PM, Paul E. Jones <[email-masked]>wrote:

> I’ll note that says “should” and not even normatively.****
>
> ** **
>
> In every instance where we use URL, it is a locator.  Unless we’re
> striking the term URL entirely from the IETF vocabulary, I think it’s more
> appropriate to use URL where we do.****
>
> ** **
>
> I’m perplexed by this sentence, actually.  It reads like “we’ve invented
> speak of automobiles, even if you’re referring only to a truck.”****
>
> ** **
>
> Why?  I must be missing something.****
>
> ** **
>
> *Sent:* Thursday, February 07, 2013 12:43 AM
>
> *To:* Paul E. Jones
> rather than the more  restrictive terms "URL" and "URN"”****
>
> - your favorite Web-architecture pedant, T****
>
> ** **
>
> On Wed, Feb 6, 2013 at 9:37 PM, Paul E. Jones <[email-masked]>
> wrote:****
>

---

From: SM <[email-masked]>
Date: Wed, 06 Feb 2013 00:21:55 -0800

Hi Paul,
>example.com or webfinger.example?

I mentioned this as the IESG may raise it as an issue.  I don't have 
any preference.

>I believe Cyrus is still working to come up with the best solution to this

Thanks for explaining this.  I read "Proposed Standard" as the 
standardized way to solve problem X.  I'll leave it to the working 
group to see what it wants to do about the point I mentioned previously.

>"Servers SHOULD support for the "rel" parameter"

Ok.

>     or registered relation type.'

That sounds better.

>just don't think it does.

I am not arguing for an informative reference as I am not the author 
of that RFC. :-)

My point is that a draft gets a lot of additional text if I explain 
what is already explained in another specification.  It can cause 
divergence if there are different interpretations of what the text 
means in that other specification means.

>Separately, Peter suggested a reference to RFC 2818, so I inserted that.

I'll leave it to Peter to argue this one as he knows RFC 6125 better.

[snip]

>James, can we strike that sentence?

See my comment to James.

Regards,
-sm

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 7 Feb 2013 03:33:45 -0500

Ok, ok. I changed it.

For the record, though, I drive a truck. ;-)

Paul

Sent: Thursday, February 07, 2013 1:21 AM

If the WG is OK with ignoring the perfectly-clear terminology guidance from
RFC3986, I'm certainly not going to lie down in the road over it. 

-T

On Wed, Feb 6, 2013 at 10:10 PM, Paul E. Jones <[email-masked]>
wrote:

To: Paul E. Jones

Paul

It now reads:

Section 6:

Section 7:

Paul

Tim,

Consider,

vs.

Gonzalo

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Feb 2013 17:42:56 -0500

> changing them, though.  What do others think?

I see this is resolved, but just for the record:
The reason for RFC 2606 was exactly that we *were* using names that
are actually in use (or that later came into use), and the owners of
those domains were getting annoyance traffic because people were
copying the domain names directly from the documents.  Never
underestimate.....

Using the reserved names also avoids trademark issues, as well as
questions of favoritism or endorsement (should we put things such as
"facebook.com" in an RFC).

Sigh.

Barry