Subject: [apps-discuss] XML in Webfinger

From: Evan Prodromou <[email-masked]>
Date: Fri, 07 Sep 2012 09:17:41 -0400

My name is Evan Prodromou; I'm the lead developer for StatusNet, and 
also the creator and maintainer of the NodeJS "webfinger" library.

Webfinger is not being created ex nihilo; there are at least half a 
dozen implementations, and none of the servers I've seen support JSON.

The interests of existing and new implementers aren't served when 
specifications fail to describe the existing state of the world.

I think there are ways to structure the specification to strongly guide 
new implementers toward the JRD implementation without failing to 
document the existence of XRD implementations.

-Evan

-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: [email-masked] P: +1-514-554-3826

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 10 Sep 2012 16:43:31 +0200

On 7 September 2012 15:17, Evan Prodromou <[email-masked]> wrote:

> My name is Evan Prodromou; I'm the lead developer for StatusNet, and also
> the creator and maintainer of the NodeJS "webfinger" library.
>
> Webfinger is not being created ex nihilo; there are at least half a dozen
> implementations, and none of the servers I've seen support JSON.
>
> new implementers toward the JRD implementation without failing to document
> the existence of XRD implementations.
>

My understanding was that consensus was reached that JSON would be the only
REQUIRED format to be supported.

If I've understood correctly, this does not preclude also supporting XML,
for those that wish to.  This would still mean that current XML
implementations will continue to operate as they are, but just that new
implementations would start including JSON, and, over time, hopefully older
ones will add JSON too.

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

---

From: Evan Prodromou <[email-masked]>
Date: Mon, 10 Sep 2012 12:11:02 -0400

On 12-09-10 10:43 AM, Melvin Carvalho wrote:
>
>
> On 7 September 2012 15:17, Evan Prodromou <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     My name is Evan Prodromou; I'm the lead developer for StatusNet,
>     and also the creator and maintainer of the NodeJS "webfinger" library.
>
>     Webfinger is not being created ex nihilo; there are at least half
>     a dozen implementations, and none of the servers I've seen support
>     JSON.
>
>     I think there are ways to structure the specification to strongly
>     guide new implementers toward the JRD implementation without
>     failing to document the existence of XRD implementations.
>
>
> My understanding was that consensus was reached that JSON would be the 
> only REQUIRED format to be supported.
>
> If I've understood correctly, this does not preclude also supporting 
> XML, for those that wish to.  This would still mean that current XML 
> implementations will continue to operate as they are, but just that 
> new implementations would start including JSON, and, over time, 
> hopefully older ones will add JSON too.

Changing the semantics of the "lrdd" link relation from "XRD by default" 
to "JRD by default" is unnecessarily damaging to existing implementations.

It does not serve new implementers well if the specification doesn't 
describe the way current implementations work, or give a reasonable 
upgrade path.

I very much like the way RFC 6415 deals with XRD and JRD and I think it 
is a great model to follow with Webfinger: XRD by default, and easy 
mechanisms (content negotiation or a separate endpoint) to get JRD.

-Evan

---

From: James M Snell <[email-masked]>
Date: Mon, 10 Sep 2012 10:08:33 -0700

I've seen similar kinds of issues pop up many times in other places. Within
the Activity Streams spec, for instance, the way we dealt with this was to
have a one spec for the Atom-based Activity Streams stuff and one spec for
the JSON-based work. Emphasis moving forward, however, has been on the JSON
spec with an eye towards eventually deprecating the Atom extensions. Such
deprecation does not need to happen automatically so long as there is a
consistent message and strategy moving forward.

- James

On Mon, Sep 10, 2012 at 9:11 AM, Evan Prodromou <[email-masked]> wrote:

> describe the way current implementations work, or give a reasonable upgrade
> path.
>
> I very much like the way RFC 6415 deals with XRD and JRD and I think it is
> a great model to follow with Webfinger: XRD by default, and easy mechanisms
> (content negotiation or a separate endpoint) to get JRD.
>
>
> -Evan
>
> --
> _______________________________________________
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: Evan Prodromou <[email-masked]>
Date: Mon, 10 Sep 2012 21:35:17 -0400

On 12-09-10 12:11 PM, Evan Prodromou wrote:
> Changing the semantics of the "lrdd" link relation from "XRD by 
> default" to "JRD by default" is unnecessarily damaging to existing 
> implementations.
>
> I very much like the way RFC 6415 deals with XRD and JRD and I think 
> it is a great model to follow with Webfinger: XRD by default, and easy 
So, reviewing RFC 6415, I see it covers almost everything I think of as 
"Webfinger": the lrdd link relation, XRD and JRD versions of host-meta 
and LRDD doc.

-Evan

---

From: Goix Laurent Walter <[email-masked]>
Date: Tue, 11 Sep 2012 10:36:29 +0200

> "Webfinger": the lrdd link relation, XRD and JRD versions of host-meta
except the "resource" and "rel" query parameters (and the "acct" link rel) yes. Your (and james) points seem to suggest to rather rely on 2 distinct endpoints and have both support such query parameters. As pointed out many times in the past this does not conflict with neither rfc6415 nor with existing implementations (basically for fsw/ostatus implementations resource and rel could need to be added over time), and does accommodate new use cases (openid connect etc) to have json supported with a minimal overhead on the server-side.
Theoretically if the ietf WF is specified as json/jrd only then it would be a somehow independent spec from rfc6415. In this case current implementations would claim rfc6415-compliance but not wf-compliance, which could be ok if referenced as such from other specs.
I guess the whole point is here in claiming compliance. Json endpoints may not be needed for federated social web use cases for now, but at this stage one could argue whether anything more is actually needed to be specified beyond rfc6415 for webfinger, now that acct uri is on its way. Then it becomes all about "resource" and "rel" parameters, which to me look like they could easily apply to both endpoints.

walter

> -Evan

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.

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 25 Sep 2012 01:02:40 -0400

On 9/10/2012 9:35 PM, Evan Prodromou wrote:
>> it is a great model to follow with Webfinger: XRD by default, and 
>> easy mechanisms (content negotiation or a separate endpoint) to get JRD.
> So, reviewing RFC 6415, I see it covers almost everything I think of 
> as "Webfinger": the lrdd link relation, XRD and JRD versions of 
> host-meta and LRDD doc.

Evan, you're entirely correct that it does. The WebFinger spec was 
originally intended to provide some examples, add a few new requirements 
(e.g., CORS) and to bring JSON more into prominence.

What happened through dialog on this list was that, rather than 
requiring server-side support for both XML and JSON, there was a 
preference to "one format only".  And, there was a fair number of people 
strongly arguing for "JSON only".  Personally, I don't see a strong 
reason to abandon XML.  XRD is a trivial format.  Further, I personally 
found it trivial to publish both XRD and JRD from the server.  So, my 
preference was to require both.

Based on dialog on the list and privately with a few folks, I think what 
the spec should say is that all servers MUST implement JRD and SHOULD 
implement XRD.  The clients may use either XRD or JRD, but obviously 
only JRD can be definitely relied upon over the long-term.  This 
flip-flops what was stated in RFC 6415.

Would you be OK with language that mandates JRD and says the server 
"SHOULD" support XRD?  Or do you strongly believe the server should 
continue to require XML as the only mandatory format?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 26 Sep 2012 06:35:25 +1000

I didn't follow that. Where did UDP come into this discussion? Everything in WebFinger is HTTPS or HTTP.

Paul

-------- Original Message --------
From: Jonathan Ballard <[email-masked]>
Sent: Wed Sep 26 03:12:04 AEST 2012
To: "Paul E. Jones" <[email-masked]>
Cc: Evan Prodromou <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [apps-discuss] XML in Webfinger

XML as mandatory on UDP sounds reasonable when there is an alternative on
TCP, so that does not make XML mandatory on UDP at all, especially if there
is no alternative.

On Monday, September 24, 2012, Paul E. Jones wrote:

>> "Webfinger": the lrdd link relation, XRD and JRD versions of host-meta and
>> LRDD doc.
>>
>
> What happened through dialog on this list was that, rather than requiring
> server-side support for both XML and JSON, there was a preference to "one
> format only".  And, there was a fair number of people strongly arguing for
> "JSON only".  Personally, I don't see a strong reason to abandon XML.  XRD
> is a trivial format.  Further, I personally found it trivial to publish
> both XRD and JRD from the server.  So, my preference was to require both.
>
> implement XRD.  The clients may use either XRD or JRD, but obviously only
> JRD can be definitely relied upon over the long-term.  This flip-flops what
> was stated in RFC 6415.
>

---

From: William Mills <[email-masked]>
Date: Tue, 25 Sep 2012 15:05:17 -0700 (PDT)

Typo of IDP perhaps?

>________________________________
> From: Paul E. Jones <[email-masked]>
>To: Jonathan Ballard <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, September 25, 2012 1:35 PM
>________________________________
>XML as mandatory on UDP sounds reasonable when there is an alternative on TCP, so that does not make XML mandatory on UDP at all, especially if there is no alternative.
>
>>>Changing the semantics of the "lrdd" link relation from "XRD by default" to "JRD by default" is unnecessarily damaging to existing implementations.
>>>>
>>>>It does not serve new implementers well if the specification doesn't describe the way current implementations work, or give a reasonable upgrade path.
>>>>
>>>>I very much like the way RFC 6415 deals with XRD and JRD and I think it is a great model to follow with Webfinger: XRD by default, and easy mechanisms (content negotiation or a separate endpoint) to get JRD.
>>>>
So, reviewing RFC 6415, I see it covers almost everything I think of as "Webfinger": the lrdd link relation, XRD and JRD versions of host-meta and LRDD doc.
>>>
>>Evan, you're entirely correct that it does. The WebFinger spec was originally intended to provide some examples, add a few new requirements (e.g., CORS) and to bring JSON more into prominence.
>>
>>What happened through dialog on this list was that, rather than requiring server-side support for both XML and JSON, there was a preference to "one format only".  And, there was a fair number of people strongly arguing for "JSON only".  Personally, I don't see a strong reason to abandon XML.  XRD is a trivial format.  Further, I personally found it trivial to publish both XRD and JRD from the server.  So, my preference was to require both.
>>
>>Based on dialog on the list and privately with a few folks, I think what the spec should say is that all servers MUST implement JRD and SHOULD implement XRD.  The clients may use either XRD or JRD, but obviously only JRD can be definitely relied upon over the long-term.  This flip-flops what was stated in RFC 6415.
>>
>>Would you be OK with language that mandates JRD and says the server "SHOULD" support XRD?  Or do you strongly believe the server should continue to require XML as the only mandatory format?
>>
>>Paul
>>
>>
>>

---

From: Jonathan Ballard <[email-masked]>
Date: Tue, 25 Sep 2012 10:12:04 -0700

---

From: Evan Prodromou <[email-masked]>
Date: Wed, 26 Sep 2012 13:12:07 -0400

Paul,

I'm happy with making XRD "SHOULD" and JRD "MUST".

I suggest that the default content type, if unspecified, stay XRD. So, 
if a client sees:

      <Link rel="lrdd"
                template="http://webfinger.example/lrdd?uri={uri}" />

...they can be somewhat confident that the results will be XRD, 
regardless of the specification the remote host supports.

-Evan

---

From: Mike Jones <[email-masked]>
Date: Wed, 26 Sep 2012 18:09:21 +0000

The problem with this is that it doesn't accomplish the core goal of the change - which is simplifying WebFinger by requiring only one data format.  It's fine to describe XML support in an appendix describing historical usage and it's fine to say that implementations MAY implement it, but saying that implementations SHOULD implement it leaves us with an unnecessarily complicated two-format spec, in practice.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Evan Prodromou
Sent: Wednesday, September 26, 2012 10:12 AM
To: [email-masked]
Subject: Re: [apps-discuss] XML in Webfinger

Paul,

I suggest that the default content type, if unspecified, stay XRD. So, if a client sees:

      <Link rel="lrdd"

...they can be somewhat confident that the results will be XRD, regardless of the specification the remote host supports.

-Evan

---

From: Evan Prodromou <[email-masked]>
Date: Wed, 26 Sep 2012 14:58:41 -0400

One thing I'm grappling with with the Webfinger draft is that it depends 
on RFC 6415, then requires some incompatible changes to that spec, or 
drops requirements from it.

This means that implementers that support the (still active!) RFC 6415 
but don't yet know about or support the Webfinger draft will get 
unexpected results.

Is there a reason that we don't simply replace RFC 6415 with a new RFC? 
That would make it clear that there's a preferred new way to do things.

Otherwise, we should make it a priority that a compliant Webfinger 
implementation is also compliant with the closely-related RFC 6415.

-Evan

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 27 Sep 2012 10:31:32 +0200

Indeed, should the group feel that some of the basic principles of rrfc6415 be deprecated (see json vs xml discussion) then I would go in favor of such an approach for a cleaner migration. This deprecation would also incentive the related implementations to migrate and avoid a dual-rfc specification that would facilitate fragmentation.

In this process though care should be given to other usages of current rfc6415 outside "webfinger" that may be impacted.

walter

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per
> conto di Evan Prodromou
> Inviato: mercoledì 26 settembre 2012 20.59
> A: [email-masked]
> Oggetto: [apps-discuss] Making Webfinger replace RFC 6415 (was Re: XML in
> Webfinger)
>

---

From: William Mills <[email-masked]>
Date: Thu, 27 Sep 2012 07:08:27 -0700 (PDT)

I'm generally in favor of having the new thing modify but not replace 6415.  Much of 6415 can, and I think should, remain intact.

> From: Goix Laurent Walter <[email-masked]>
>To: Evan Prodromou <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, September 27, 2012 1:31 AM
>Subject: [apps-discuss] R: Making Webfinger replace RFC 6415 (was Re: XML in Webfinger)
>

---

From: Evan Prodromou <[email-masked]>
Date: Fri, 28 Sep 2012 16:44:11 -0400

On Thu 27 Sep 2012 10:08:27 AM EDT, William Mills wrote:
> I'm generally in favor of having the new thing modify but not replace
> 6415.  Much of 6415 can, and I think should, remain intact.

So, do you think that a client implementing 6415 but not the Webfinger 
draft should work with a server implementing the Webfinger draft?

Similarly with a Webfinger client encounters an RFC 6415 server?

I think it's counterproductive to have a current RFC that says, "Do it 
this way" and another RFC that says "do it another way" and those ways 
don't actually interoperate.

-Evan

---

From: Evan Prodromou <[email-masked]>
Date: Fri, 28 Sep 2012 16:48:15 -0400

> The problem with this is that it doesn't accomplish the core goal of the change - which is simplifying WebFinger by requiring only one data format.  It's fine to describe XML support in an appendix…

Mike,

I don't agree with that goal.

I also disagree that simplicity of the spec is a higher priority than 
compatibility with existing implementations.

I think that dealing with the existing XRD documents on the Web isn't an 
unnecessary complexity, but a necessary one.

-Evan

---

From: Melvin Carvalho <[email-masked]>
Date: Fri, 28 Sep 2012 22:54:01 +0200

On 28 September 2012 22:48, Evan Prodromou <[email-masked]> wrote:

>> The problem with this is that it doesn't accomplish the core goal of the
>> change - which is simplifying WebFinger by requiring only one data format.
>>  It's fine to describe XML support in an appendix describing historical
>> usage and it's fine to say that implementations MAY implement it, but
>> saying that implementations SHOULD implement it leaves us with an
>> unnecessarily complicated two-format spec, in practice.
>>
>>
>>
>
> Mike,
>

I could be mistaken, but my understanding was that consensus was reached,
to move forward with JSON as the required serialization, rather than, XML

Given that it took several months of debate to reach such a consensus, is
it going to be productive to reopen the debate?

---

From: Mike Jones <[email-masked]>
Date: Fri, 28 Sep 2012 23:30:16 +0000

Exactly

From: Melvin Carvalho [mailto:[email-masked]]
Sent: Friday, September 28, 2012 1:54 PM
To: Evan Prodromou
Cc: Mike Jones; [email-masked]
Subject: Re: [apps-discuss] XML in Webfinger

On 28 September 2012 22:48, Evan Prodromou <[email-masked]<mailto:[email-masked]>> wrote:
On 12-09-26 02:09 PM, Mike Jones wrote:
The problem with this is that it doesn't accomplish the core goal of the change - which is simplifying WebFinger by requiring only one data format.  It's fine to describe XML support in an appendix describing historical usage and it's fine to say that implementations MAY implement it, but saying that implementations SHOULD implement it leaves us with an unnecessarily complicated two-format spec, in practice.

Mike,

I also disagree that simplicity of the spec is a higher priority than compatibility with existing implementations.

I think that dealing with the existing XRD documents on the Web isn't an unnecessary complexity, but a necessary one.

I could be mistaken, but my understanding was that consensus was reached, to move forward with JSON as the required serialization, rather than, XML

Given that it took several months of debate to reach such a consensus, is it going to be productive to reopen the debate?

-Evan

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

---

From: Evan Prodromou <[email-masked]>
Date: Fri, 28 Sep 2012 20:18:20 -0400

I think that JRD should be favoured over XRD.

But conflicting specs with different requirements are confusing for 
implementers and may cause interoperability problems.

I think that Webfinger should either cleanly extend or replace RFC 6415.

-Evan

---

From: Mike Jones <[email-masked]>
Date: Sat, 29 Sep 2012 00:24:02 +0000

This change isn't being made in a vacuum.  You're not including the more than a dozen of implementations of SWD in your description of the current state of discovery protocol adoption.  They have an investment in a JSON-only discovery protocol that's already working for them.  If we can simplify WebFinger sufficiently, I suspect we can persuade them to switch in the name of unification.  But if it stays a two-format protocol, that makes the case a lot harder to make.

As I see it, WebFinger may continue to use RFC 6415 IF it makes sense for the WebFinger goals.  But starting with the premise that using RFC 6415 is a goal in and of itself seems like the tail wagging the dog.

The real goal here is a simple and secure discovery protocol that can and will be ubiquitously adopted.  All other considerations should be secondary.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Evan Prodromou
Sent: Friday, September 28, 2012 5:18 PM
To: [email-masked]
Subject: Re: [apps-discuss] XML in Webfinger

But conflicting specs with different requirements are confusing for implementers and may cause interoperability problems.

-Evan

---

From: Evan Prodromou <[email-masked]>
Date: Fri, 28 Sep 2012 22:28:04 -0400

Mike,

I get that!

If we want an all-JRD flow, what about starting from the /.well-known/host-meta.json endpoint instead of /.well-known/host-meta ?

The explicit contract for the .json endpoint has always been to provide JRD exclusively, and the lrdd link there is supposed to be jrd, too.

It would make it unnecessary to talk at all about XML and XRD in the draft.

-Evan

Mike Jones <[email-masked]> wrote:

>This change isn't being made in a vacuum.  You're not including the
>more than a dozen of implementations of SWD in your description of the
>current state of discovery protocol adoption.  They have an investment
>in a JSON-only discovery protocol that's already working for them.  If
>we can simplify WebFinger sufficiently, I suspect we can persuade them
>to switch in the name of unification.  But if it stays a two-format
>protocol, that makes the case a lot harder to make.
>
>As I see it, WebFinger may continue to use RFC 6415 IF it makes sense
>for the WebFinger goals.  But starting with the premise that using RFC
>6415 is a goal in and of itself seems like the tail wagging the dog.
>
>The real goal here is a simple and secure discovery protocol that can
>and will be ubiquitously adopted.  All other considerations should be
>secondary.
>
>				-- Mike
>
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Evan Prodromou

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 30 Sep 2012 13:40:48 +0200

On 29 September 2012 04:28, Evan Prodromou <[email-masked]> wrote:

> Mike,
>
> I get that!
>
> If we want an all-JRD flow, what about starting from the
> /.well-known/host-meta.json endpoint instead of /.well-known/host-meta ?
>

Content negotiation elegantly solves this problem.

http://en.wikipedia.org/wiki/Content_negotiation

If implementations have correctly followed the spec, and set the correct
accept header (xrd or jrd), they should always get back the right
serialization?

If not, it's a one line bug fix?

>
> The explicit contract for the .json endpoint has always been to provide
> JRD exclusively, and the lrdd link there is supposed to be jrd, too.
>
>> ------------------------------
>>

---

From: Evan Prodromou <[email-masked]>
Date: Sun, 30 Sep 2012 09:17:46 -0400

On 12-09-30 07:40 AM, Melvin Carvalho wrote:
>
>
> On 29 September 2012 04:28, Evan Prodromou <[email-masked] 
In RFC 6415, the default content type for the /.well-known/host-meta 
endpoint is XRD.

    If no "Accept" request header field
    is included with the request, or if the client requests an
    "application/xrd+xml" representation, the server MUST respond using
    the REQUIRED XRD 1.0 XML representation described inSection 3.1  <http://tools.ietf.org/html/rfc6415#section-3.1>.

On the other hand, the /.well-known/host-meta.json endpoint always 
returns JRD.

    Alternatively, the client MAY request a JRD representation by
    requesting the "host-meta.json" well-known document, by making a GET
    request for "/.well-known/host-meta.json", following the same process
    used for "/.well-known/host-meta".  If the server does not support
    serving a JRD representation at this location, the server MUST
    respond with an HTTP 404 (Not Found) status code.

If there's a desire to make a JRD-only version of the Webfinger draft -- 
which I think is a good idea! -- I think using the host-meta.json 
endpoint /only/ is a good idea.
> If implementations have correctly followed the spec, and set the 
> correct accept header (xrd or jrd), they should always get back the 
> right serialization?
The Accept header isn't required in RFC 6415, probably because there are 
plenty of implementations that antedate the RFC and just return (or 
expect) XRD no matter what.

Having different default content types at the same well-known endpoint 
makes it impossible for servers to support both RFC 6415 and the new 
Webfinger draft.
> If not, it's a one line bug fix?
I think as with any network protocol, the hard part isn't fixing one's 
own software, but communicating with everyone else's.

-Evan

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 30 Sep 2012 15:35:47 +0200

On 30 September 2012 15:17, Evan Prodromou <[email-masked]> wrote:

>    the REQUIRED XRD 1.0 XML representation described in Section 3.1 <http://tools.ietf.org/html/rfc6415#section-3.1>.
>
> On the other hand, the /.well-known/host-meta.json endpoint always returns
> JRD.
>
> which I think is a good idea! -- I think using the host-meta.json endpoint
> *only* is a good idea.
>

Thanks for the clarification.  That makes sense.

> plenty of implementations that antedate the RFC and just return (or expect)
> XRD no matter what.
>
> I think as with any network protocol, the hard part isn't fixing one's own
> software, but communicating with everyone else's.
>
> -Evan
>