Could this:
WebFinger is used to discover information about people or other
entities on the Internet that are identified by a URI [6] or IRI [7]
using standard Hypertext Transfer Protocol (HTTP) [2] methods over a
secure transport [14].
become:
WebFinger is used to discover information about people or other
entities on the Internet that are *denoted* by a URI [6] or IRI [7]. Actual information retrieval uses
standard Hypertext Transfer Protocol (HTTP) [2] methods over a
secure transport [14].
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
No. The I in URI stands for Identifier. URIs identify resources, that’s what they’re for. -T
Tim is correct.
The URI or IRI is an identifier for a resource.
Where it gets slightly grey is with the acct: scheme. However I think that the scheme is still identifying an account as the resource, even if there is no default derefrencing.
I think I understand Kingsley wanting to make the transitive link form a identifier for a resource to having that resource denote a abstract object.
However I think that is best left to philosophers and the W3C.
I think the current text is fine.
John B.
Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/) has been repealed, these are instances of URIs, whose function per rfc3986 is to Identify resources. I don't see how it could be any clearer.
A good thing about WF is that it's just good basic Web stuff. No semantic castles in the sky required.
Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/) has been repealed, these are instances of URIs, whose function per rfc3986 is to Identify resources. I don't see how it could be any clearer.
A good thing about WF is that it's just good basic Web stuff. No semantic castles in the sky required.
Certainly, text changes were what you requested. I must learn to read directions. I must learn to read directions. I must learn to read directions.
Change the following in 3.1
In the above example, an "acct" URI [8] is used in the query, though any valid alias for the user might also be used.
In the above example, an "acct" URI [8] is used in the query, though any valid alias for the user might also be used. See section 4.5 for
more information on WebFinger and URIs.
1) acct:bob@example.com is used in 3.1, 3.2
2) mailto:b...@example.com is used in 3.3
3) http://www.example.com/~bob/ in 3.1
As a mail client I can see that (3) may be a separate URI that has
slightly different meaning that (1) or (2)
I would expect email clients to always use "acct" if the purpose is to
look up information about a user's account at some domain. It does
not matter if it's an email client, web browser, FTP client, or
whatever. The "acct" URI has a specific purpose.
I would expect the mail client to query the server if it is looking
for configuration information. So, when I enter my email address into
my client, it goes out and discovered my SMTP and IMAP server and
whatever server settings to use. (Now, what is documented presently
is just an example. I'd like to see a more complete spec for how that
should be done.
Ditto for other kinds of clients, including SIP, XMPP, H.323, etc.)As a server implementor, would I need to support both (1) and (2)?
Servers should just serve whatever is populated in the database. My
database has a "resource" table populated with:
acct:paulej@packetizer.com
http://packetizer.com
http://www.packetizer.com
mailto:pau...@packetizer.com
xmpp:pau...@packetizer.com
The records in the resource table have a 1-to-n relationship with
another table called "aliases". The "acct:paulej@packetizer.com"
acct:paulej@packetizer.com.
OK. And I’ll split the balance the paragraph at that point so that the “alias” text starts as a new paragraph.
Paul
Folks,
I just posted a revised version of the WebFinger text. Highlights include:
* Change all queries to require HTTPS only
* Forbid server redirection to HTTP URIs
* Merged the "Introduction" and "Overview" sections
* Moved some references to the informative references section
* Removed instructions for the server to return specific
status codes (Tim successfully argued it was not needed)
* Retained one statement, though, in section 4.2 that
requires a server to return a 400. However, the
text was changed to refer to behavior in RFC 2616.
Same end result, though.
* Moved section the "rel" parameter section before the
JRD section.
* Made edits to the JRD section as discussed on the list
* Various editorial changes
Please have a look at this text and suggest any changes we should make.
The media type used for the JSON Resource Descriptor (JRD) is "application/json"Doesnt JRD have it's own content type?
Folks,
I just posted a revised version of the WebFinger text. Highlights include:
* Change all queries to require HTTPS only
* Forbid server redirection to HTTP URIs
* Merged the "Introduction" and "Overview" sections
* Moved some references to the informative references section
* Removed instructions for the server to return specific
status codes (Tim successfully argued it was not needed)
* Retained one statement, though, in section 4.2 that
requires a server to return a 400. However, the
text was changed to refer to behavior in RFC 2616.
Same end result, though.
* Moved section the "rel" parameter section before the
JRD section.
* Made edits to the JRD section as discussed on the list
* Various editorial changes
Please have a look at this text and suggest any changes we should make.
On 22 December 2012 00:32, Tim Bray <tb...@textuality.com> wrote:
Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/) has been repealed, these are instances of URIs, whose function per rfc3986 is to Identify resources. I don't see how it could be any clearer.
A good thing about WF is that it's just good basic Web stuff. No semantic castles in the sky required.
Totally agree, but perhaps for a moment forget AWWW, which, in imho. is an incredible piece of work.
A URI is simply a global variable. The benefit of a URI is that is it is constant between heterogeneous systems. Hence the Web. As Tim once said, "When you add global variables to some languages, they fall apart, when you add them to hypertext, you get The Web"
There was one deep question discussed it the last decade, and that was: is it reasonably to divide a web page into a number of sections. And the decision (perhaps arbitrary) in AWWW, was, that yes it that would be reasonable. After much thought on the subject, I am also of the opinion that, that is a reasonably approach.
Im not really sure it's about castles in the sky, but rather, that if different systems take an entitty/attribute/value approach with a global naming scheme (ie the URI) we can strongly foster interop, and grow the network effect for mutual benefit.
Melvin,
This actually looks pretty good!
PEJ: Great!
Re:
The media type used for the JSON Resource Descriptor (JRD) is "application/json"
Doesnt JRD have it's own content type?
See Eran's comment:
http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comment-8122
"For now I’m using application/json, but application/xrd+json is also possible."
Maybe something like application/jrd+json would be best?
PEJ: Nothing has ever been defined and RFC 6415 says JRD is “application/json”. Should somebody (note “somebody”) define something specific for JRD? I didn’t see any other +json definitions and I know people expressed concern with that previously (not related to WF). If we defined such a thing, it should either be application/jrd or application/jrd+json.
Paul