Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E334011E8215 for ; Wed, 24 Jul 2013 12:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLwoAITpAhVY for ; Wed, 24 Jul 2013 12:13:16 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C18A711E8242 for ; Wed, 24 Jul 2013 12:13:13 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id ev20so643243lab.4 for ; Wed, 24 Jul 2013 12:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kteA71tLG/U5I5qo91OVh9gXmBvIUT7WwUeltxESGOs=; b=yhBip2EMPNDJIj6Y5DEuJF0RFeBSMe2droeEF4v763RJX7FB2PIhPjCBkcm3tZ2asL 5otU8U+DMroQy2hEfBWdadAnRNIb3fAGAnHTbJyb0+ksSGyp1HmaP0XzLYr0c88oY85U XbUA3F6MS6H2wguPqx4mLtbwCgn6Mlj9zw/Q0GySOLDLhhtrmLB1tSXqv4vzmnVu4XjI T3PxghCImUkUc6yDvgUQKv6BY19HRCm2ubBMkbJqncEAgp2VYm1IPFLWYp/Zj5Zn8TGu GA2DKMre39N8Uz8FH876MJBFev0x1h3vFyB/0ItTL/YzdUPgEBdVtyVIOJr1r+3ivkdb lkmA== MIME-Version: 1.0 X-Received: by 10.152.115.142 with SMTP id jo14mr17414253lab.87.1374693192588; Wed, 24 Jul 2013 12:13:12 -0700 (PDT) Received: by 10.112.59.193 with HTTP; Wed, 24 Jul 2013 12:13:12 -0700 (PDT) In-Reply-To: <979B65CA-EC87-4D98-9FA0-67822BEC0DFF@ve7jtb.com> References: <028101ce869e$f02cddb0$d0869910$@packetizer.com> <0a1140f5-24d9-4be6-aab4-1ae6a3d63c0c@email.android.com> <032701ce86e5$27b2dff0$77189fd0$@packetizer.com> <979B65CA-EC87-4D98-9FA0-67822BEC0DFF@ve7jtb.com> Date: Wed, 24 Jul 2013 21:13:12 +0200 Message-ID: From: Melvin Carvalho To: John Bradley Content-Type: multipart/alternative; boundary=001a11c3504c6b62a804e246b309 Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] Absolute URI vs URI X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 19:13:18 -0000 --001a11c3504c6b62a804e246b309 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 24 July 2013 19:19, John Bradley wrote: > Relative URI are not useful without a base to be relative to. Unless we > say how to determine the base of a relative URI they should not be allowe= d. > > I an imagine several ways to determine a base but without specifying it > applications will not behave consistently. The JRD is not a HTML docume= nt. > Sure. I wasnt trying to imply the JRD was the same as an HTML document. Relative URIs, can be used in many contexts such as html/json/xml do indeed require a base. I think the following text from RFC 3986, "5.1. Establishing a Base URI" would be relevant here, and it's referred to by JSON LD too http://tools.ietf.org/html/rfc3986#section-5.1 > > John B. > > On 2013-07-24, at 12:58 PM, Melvin Carvalho > wrote: > > > > > On 22 July 2013 16:10, Paul E. Jones wrote: > >> Melvin,**** >> >> ** ** >> >> It=92s easy enough to replace strings in URIs should data need to be >> ported. I suggest we remove the word =93absolute=94 where we currently = have >> =93absolute URI=94 and then introduce a new paragraph in the terminology >> section as follows:**** >> >> ** ** >> >> The use of URIs throughout this document refers to URIs following the >> syntax specified in Section 3 of RFC 3986. Relative URIs, having syntax >> following that of Section 4.2 or RFC 3986, are not used with WebFinger.*= * >> ** >> >> ** ** >> >> Is that clear? >> > > Hi Paul, currently "Absolute URI" occurs only in section 4.4 (ie the > description of JRD). Certainly I think the 'absolute' should be removed = in > section 4.4. > > The RFC in essence describes two things, > > 1. the webfinger protocol > 2. the JRD definition > > This restriction on relative URIs applies to (2), rather than, the whole > document, but as it happens that turns out to be the same thing > > Side note: in other situations I like relative URIs because they can be > moved from one location to another in a non-breaking way. Say I have > /about/ /photos/ /blog/ at one location, I can move them to another witho= ut > having to worry too much. Therefore, if JRD was ever used in a context > outside of webfinger, that would be a slight advantage. > > >> **** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] >> *Sent:* Monday, July 22, 2013 4:09 AM >> *To:* Paul E. Jones >> *Cc:* webfinger >> >> *Subject:* Re: [webfinger] Absolute URI vs URI**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> On 22 July 2013 09:06, Paul E. Jones wrote:**** >> >> In not suggesting we use or allow relative URIs. The immediate question >> would be "relative to what". I think the URIs should be absolute, but no= t >> following the syntax of "absolute-URI", but instead just following "URI"= . >> **** >> >> Yes, that's a good question. Generally relative URIs are relative to th= e >> document, but they need not be. For example they could be relative by >> default to the [supposed] webfinger registry. In JSON LD they have a >> @context variable which allows quite a bit of flexibility in this regard= . >> I'm unsure if relative URIs are considered a must in standards based >> serialization (I suspect not) but they have the advantage of slightly >> increased data portability.**** >> >> **** >> >> Paul**** >> >> ** ** >> ------------------------------ >> >> *From:* Melvin Carvalho >> *Sent:* Mon Jul 22 02:46:25 EDT 2013**** >> >> >> *To:* "Paul E. Jones" **** >> >> *Cc:* webfinger **** >> >> >> *Subject:* Re: [webfinger] Absolute URI vs URI**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> On 22 July 2013 07:47, Paul E. Jones wrote:**** >> >> Folks, >> >> One of the requirements in the JRD spec is that certain URIs (e.g., thos= e >> identifying link relation types and properties) be "absolute URIs". Thi= s >> term has been a point of confusion, since RFC 3986 uses the term to have= a >> concrete meaning, namely this: >> >> absolute-URI =3D scheme ":" hier-part [ "?" query ] >> >> And the term is used, because that's the term used in the OASIS XRD >> specification. However, it was not clear to me whether that referred to >> the >> above (which I assumed) or referred to URIs that are not relative URIs >> (i.e., those lacking a scheme specified). >> >> I had an exchange with Eran Hammer and Mark Nottingham. I believe the >> intent of that language was not to require the above constrained syntax, >> but to require the standard URI syntax: >> >> URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ]**** >> >> ** ** >> >> There are many ways that people do this, see: >> >> http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces**** >> >> **** >> >> >> Given that understanding, I believe we should remove the word "absolute" >> that appears in front of "URI" in the WebFinger spec. Do others have an >> opinion on this?**** >> >> ** ** >> >> +1 on allowing relative URIs**** >> >> **** >> >> >> Paul >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger**** >> >> ** ** >> >> ** ** >> > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > > --001a11c3504c6b62a804e246b309 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On 24 July 2013 19:19, John Bradley <ve7jtb@ve7jtb.com> wrote:
Relative URI are not useful without a base to be relative to. = =A0Unless we say how to determine the base of a relative URI they should no= t be allowed.

I an imagine several ways to determine a base but without sp= ecifying it applications will not behave consistently. =A0 The JRD is not a= HTML document.

Sure.=A0 I wasn= t trying to imply the JRD was the same as an HTML document.=A0 Relative URI= s, can be used in many contexts such as html/json/xml do indeed require a b= ase.=A0 I think the following text from RFC 3986, "5.1.=A0 Establishin= g a Base URI" would be relevant here, and it's referred to by JSON= LD too

=A0

John B.
<= div class=3D"h5">

On 2013-07-24, at 12:58 PM, Melvin Carv= alho <melv= incarvalho@gmail.com> wrote:




On 22 July 2013 16:10, Paul E. Jones = <paulej@packetizer.com> wrote:

Me= lvin,

=A0

<= p class=3D"">It=92s easy enough to replace = strings in URIs should data need to be ported.=A0 I suggest we remove the w= ord =93absolute=94 where we currently have =93absolute URI=94 and then intr= oduce a new paragraph in the terminology section as follows:<= /span>

=A0

<= p class=3D"" style=3D"margin-left:0.5in">Th= e use of URIs throughout this document refers to URIs following the syntax = specified in Section 3 of RFC 3986.=A0 Relative URIs, having syntax followi= ng that of Section 4.2 or RFC 3986, are not used with WebFinger.<= /u>

=A0

<= p class=3D"">Is that clear?


Hi Paul, currently "Absolute UR= I" occurs only in section 4.4 (ie the description of JRD).=A0 Certainl= y I think the 'absolute' should be removed in section 4.4.=A0

The RFC in essence describes two things,

1. the webf= inger protocol
2. the JRD definition

This restriction on relative= URIs applies to (2), rather than, the whole document, but as it happens th= at turns out to be the same thing

Side note: in other situations I like relative URIs because they can be= moved from one location to another in a non-breaking way.=A0 Say I have /a= bout/ /photos/ /blog/ at one location, I can move them to another without h= aving to worry too much.=A0 Therefore, if JRD was ever used in a context ou= tside of webfinger, that would be a slight advantage.
=A0

=A0

<= p class=3D"">Paul

=A0

<= div style=3D"border-width:medium medium medium 1.5pt;border-style:none none= none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-t= ext-color blue;padding:0in 0in 0in 4pt">

From: = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Monday, July 22, 2013 4:09 AM
To: Paul E. Jones
<= b>Cc: webfinger


Subject: Re: [webfinger]= Absolute URI vs URI

=A0

=A0<= u>

=A0=

On 22 July 2013 09:06, Paul E. Jones <paulej@packetizer.com&g= t; wrote:

In not suggesting we use or allow relative URIs. The immediate ques= tion would be "relative to what". I think the URIs should be abso= lute, but not following the syntax of "absolute-URI", but instead= just following "URI".

Yes, that's a good question.=A0 Generally rela= tive URIs are relative to the document, but they need not be.=A0 For exampl= e they could be relative by default to the [supposed] webfinger registry.= =A0 In JSON LD they have a @context variable which allows quite a bit of fl= exibility in this regard.=A0 I'm unsure if relative URIs are considered= a must in standards based serialization (I suspect not) but they have the = advantage of slightly increased data portability.

=A0

Paul

=A0

From: Melvin Carvalho <melvincarvalho@gmail.com= >
Sent: Mon Jul 22 02:46:25 EDT 2013


To: "Paul E. Jones" <paulej@packetizer.com&= gt;

Cc: webfinger <webfinger@ietf.org= >


Subject: Re: [webfinger] Absolute U= RI vs URI

=A0

=A0

=A0

=A0

On 22 July 2013 07:47, Paul E. Jones <paulej@packetizer.com> wrote:=

Folks,

One of the requirements in the JRD spec is that= certain URIs (e.g., those
identifying link relation types and propertie= s) be "absolute URIs". =A0This
term has been a point of confus= ion, since RFC 3986 uses the term to have a
concrete meaning, namely this:

=A0 =A0 =A0absolute-URI =A0=3D scheme= ":" hier-part [ "?" query ]

And the term is use= d, because that's the term used in the OASIS XRD
specification. =A0H= owever, it was not clear to me whether that referred to the
above (which I assumed) or referred to URIs that are not relative URIs
(= i.e., those lacking a scheme specified).

I had an exchange with Eran= Hammer and Mark Nottingham. =A0I believe the
intent of that language wa= s not to require the above constrained syntax,
but to require the standard URI syntax:

=A0 =A0 =A0URI =3D scheme &q= uot;:" hier-part [ "?" query ] [ "#" fragment ]=

=A0

There are many ways that people do this, see:

http:= //tantek.com/2011/238/b1/many-ways-slice-url-name-pieces<= /p>

=A0


Given that understanding, I believe we should remove the = word "absolute"
that appears in front of "URI" in the WebFinger spec. =A0Do other= s have an
opinion on this?

=A0

+1 on allowing relative= URIs

=A0


Paul


_______________________________________________
webfinger mailing listwebfinger@ietf.or= g
https://www.ietf.org/mailman/listinfo/webfinger

=A0

=A0

=

_______________________________________________
webfinger mailing listwebfinger@ietf.or= g
https://www.ietf.org/mailman/listinfo/webfinger


--001a11c3504c6b62a804e246b309--