Subject: [apps-discuss] Draft -07 mod proposal: Clean up "subject"

From: Tim Bray <[email-masked]>
Date: Sun, 2 Dec 2012 17:14:42 -0800

Right now, section 5.2.2 says "The value of the "subject" member is a
string that MUST be set to the same value as the "resource" parameter in
the client request. "

This is a recipe for trouble, for a couple of reasons. First of all, what
does “the same value” mean?  Go visit RFC3986, section 6, and enjoy several
hundred words walking through all the issues that arise in trying to figure
out when two URIs are equivalent, ranging from exact character-by-character
identity to all sorts of protocol-specific goo. You are just one level of
case-sensitivity-in-%-escaping from a big hairy false negative.

I’m also worried about a lack of flexibility. I might have a single
webfinger resource that declares a bunch of link relations for a bunch of
different resources. This section, as written, wouldn’t let me do that.

Proposal: Re-write section 5.2.2 as follows:

<<<<<<<
The value of the "subject" member is a string whose value is advisory,
identifying the resource to which the properties given in the "links"
member apply.  Normally this would be expected to be equivalent to the
value of the "resource" parameter in the client request.
<<<<<<<

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]>wrote:

> Folks,****
>
> ** **
>
> I published another version of the WebFinger spec trying to bring closure
> to the two open issues I see (resource representation and transport).  The
> new version is here:****
>
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07****
>
> ** **
>
> With respect to resource representation, I fully described the JSON
> Resource Descriptor within the document.  There are no external references
> to RFC 6415 now, no need to go read the XRD spec, etc.  It’s a fairly
> simple format and I believe this text documents it sufficiently.  Combined
> with the visual examples, I think this makes it pretty clear.  Have a look
> at the JRD documentation in section 5.2 and provide your comments. ****
>
> ** **
>
> With respect to HTTPS, it seems there is strong preference for “HTTPS
> only”, but some a fair bit of insistence for allowing HTTP.  I changed the
> wording in 5.2 to try to capture opinions.  Previously, the text led with a
> requirement to try HTTPS first.  That is still there.  I just added some
> extra conditions that make it clearer that there are some instances where a
> client must not utilize HTTP.  This might need further refinement, but I
> think there is a balance we can strike here between the two camps without
> introducing a lot of complex language.****
>
> ** **
>
> I made some editorial changes through the document.****
>
> ** **
>
> Comments are welcome, as always.  Seems I don’t need to say that to this
> group, though :-)****
>
> ** **
>
> Paul****
>
> ** **
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: James M Snell <[email-masked]>
Date: Sun, 2 Dec 2012 21:42:46 -0800

-1 ... fixing this would be good but your proposed text isn't quite enough
without either defining or specifically referencing what "equivalence"
means. For example, as currently defined, the resource parameter can be a
relative URI reference, while the subject could be an absolute URI
reference. How does one determine equivalence exactly?

- James

---

From: Tim Bray <[email-masked]>
Date: Sun, 2 Dec 2012 21:49:22 -0800

Sounds to me like you’re arguing my side of it.  The current language
suggests that you should turf the JRD if they’re not “the same value” that
you put in your query. There are lots of reasons why they might not be
byte-for-byte or even character-for-character identical, and still be
equivalent for all practical purposes.  -T

On Sun, Dec 2, 2012 at 9:42 PM, James M Snell <[email-masked]> wrote:

>>> I published another version of the WebFinger spec trying to bring
>>> closure to the two open issues I see (resource representation and
>>> transport).  The new version is here:****
>>>

---

From: James M Snell <[email-masked]>
Date: Sun, 2 Dec 2012 21:55:18 -0800

Yes, I -1'd the specific change because I don't believe it's good enough.
Honestly, I'd be happy to get rid of the subject property entirely, as I do
not believe it's going to be all that useful. The subject of the JRD should
be the effective request URI. Period. Anything other than that adds
unhelpful and unnecessary complexity. If, however, we keep subject in, then
clear equivalent rules should be spelled out or referenced. We can't just
say "equivalent" and hope for the best.

- James

On Sun, Dec 2, 2012 at 9:49 PM, Tim Bray <[email-masked]> wrote:

>> -1 ... fixing this would be good but your proposed text isn't quite
>> enough without either defining or specifically referencing what
>> "equivalence" means. For example, as currently defined, the resource
>> parameter can be a relative URI reference, while the subject could be an
>> absolute URI reference. How does one determine equivalence exactly?
>>
>> - James
>>
>>
>>> This is a recipe for trouble, for a couple of reasons. First of all,
>>> what does “the same value” mean?  Go visit RFC3986, section 6, and enjoy
>>> several hundred words walking through all the issues that arise in trying
>>> to figure out when two URIs are equivalent, ranging from exact
>>> character-by-character identity to all sorts of protocol-specific goo. You
>>> are just one level of case-sensitivity-in-%-escaping from a big hairy false
>>> negative.
>>>
>>>> Comments are welcome, as always.  Seems I don’t need to say that to
>>>> this group, though :-)****
>>>>
>>>> ** **
>>>>
>>>> Paul****
>>>>
>>>> ** **
>>>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 02:16:24 -0500

Tim,

Yeah, I can appreciate that.  However, I would like to suggest some slightly
different wording.  How is this for the first paragraph in 5.2.2?

"The value of the "subject" member is a string whose value is advisory and
normally would be expected to be equivalent to the value of the "resource"
parameter in the client request.  The "subject" identifies the entity to
which the JRD describes."

Paul

From: Tim Bray [mailto:[email-masked]] 
Sent: Sunday, December 02, 2012 8:15 PM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Draft -07 mod proposal: Clean up "subject"

Right now, section 5.2.2 says "The value of the "subject" member is a string
that MUST be set to the same value as the "resource" parameter in the client
request. "

does "the same value" mean?  Go visit RFC3986, section 6, and enjoy several

I'm also worried about a lack of flexibility. I might have a single
webfinger resource that declares a bunch of link relations for a bunch of
different resources. This section, as written, wouldn't let me do that.

<<<<<<<
The value of the "subject" member is a string whose value is advisory,
identifying the resource to which the properties given in the "links" member
apply.  Normally this would be expected to be equivalent to the value of the
"resource" parameter in the client request. 
<<<<<<<

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]>
wrote:

Folks,

I published another version of the WebFinger spec trying to bring closure to
the two open issues I see (resource representation and transport).  The new
version is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

With respect to resource representation, I fully described the JSON Resource
Descriptor within the document.  There are no external references to RFC
6415 now, no need to go read the XRD spec, etc.  It's a fairly simple format
and I believe this text documents it sufficiently.  Combined with the visual
examples, I think this makes it pretty clear.  Have a look at the JRD
documentation in section 5.2 and provide your comments. 

With respect to HTTPS, it seems there is strong preference for "HTTPS only",
but some a fair bit of insistence for allowing HTTP.  I changed the wording
in 5.2 to try to capture opinions.  Previously, the text led with a
requirement to try HTTPS first.  That is still there.  I just added some
extra conditions that make it clearer that there are some instances where a
client must not utilize HTTP.  This might need further refinement, but I
think there is a balance we can strike here between the two camps without
introducing a lot of complex language.

I made some editorial changes through the document.

Comments are welcome, as always.  Seems I don't need to say that to this
group, though :-)

Paul

---

From: John Bradley <[email-masked]>
Date: Mon, 3 Dec 2012 10:11:01 -0300

Added Web Finger to subject for the inocent.

I would change that to:

> “The value of the "subject" member is a string whose value is advisory and normally would be expected to be equivalent to the value of the "resource" parameter in the client request.  The "subject" identifies the entity to which the JRD claims to describe.”

The subject is self asserted saying that it is defiantly the ting that the JRD describes will lead to applications making mistakes.   The subject is the thing that the JRD claims to be about.  It is more likely to be about the thing you did the query on.   If they differ the client should understand that the query parameter is the stronger binding.

If we go in on the acct: URI then I would be tempted to say that the value SHOULD be the normalized acct: uri for the thing you are asking about.  That is likely more useful information to the client.

John B.

On 2012-12-03, at 4:16 AM, "Paul E. Jones" <[email-masked]> wrote:

> Tim,
>  
> Yeah, I can appreciate that.  However, I would like to suggest some slightly different wording.  How is this for the first paragraph in 5.2.2?
>  
> “The value of the "subject" member is a string whose value is advisory and normally would be expected to be equivalent to the value of the "resource" parameter in the client request.  The "subject" identifies the entity to which the JRD describes.”
>  
> Paul
>  
>  
> Right now, section 5.2.2 says "The value of the "subject" member is a string that MUST be set to the same value as the "resource" parameter in the client request. "
> 
> This is a recipe for trouble, for a couple of reasons. First of all, what does “the same value” mean?  Go visit RFC3986, section 6, and enjoy several hundred words walking through all the issues that arise in trying to figure out when two URIs are equivalent, ranging from exact character-by-character identity to all sorts of protocol-specific goo. You are just one level of case-sensitivity-in-%-escaping from a big hairy false negative.
> 
> I’m also worried about a lack of flexibility. I might have a single webfinger resource that declares a bunch of link relations for a bunch of different resources. This section, as written, wouldn’t let me do that.
> 
> The value of the "subject" member is a string whose value is advisory, identifying the resource to which the properties given in the "links" member apply.  Normally this would be expected to be equivalent to the value of the "resource" parameter in the client request. 
> <<<<<<<
> 
> On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <[email-masked]> wrote:
> Folks,
>  
> I published another version of the WebFinger spec trying to bring closure to the two open issues I see (resource representation and transport).  The new version is here:
> With respect to resource representation, I fully described the JSON Resource Descriptor within the document.  There are no external references to RFC 6415 now, no need to go read the XRD spec, etc.  It’s a fairly simple format and I believe this text documents it sufficiently.  Combined with the visual examples, I think this makes it pretty clear.  Have a look at the JRD documentation in section 5.2 and provide your comments.
>  
> With respect to HTTPS, it seems there is strong preference for “HTTPS only”, but some a fair bit of insistence for allowing HTTP.  I changed the wording in 5.2 to try to capture opinions.  Previously, the text led with a requirement to try HTTPS first.  That is still there.  I just added some extra conditions that make it clearer that there are some instances where a client must not utilize HTTP.  This might need further refinement, but I think there is a balance we can strike here between the two camps without introducing a lot of complex language.
>  
> Comments are welcome, as always.  Seems I don’t need to say that to this group, though :-)
>  
> Paul
>  
>

---

From: Nick Jennings <[email-masked]>
Date: Mon, 3 Dec 2012 14:18:50 +0100

On Mon, Dec 3, 2012 at 8:16 AM, Paul E. Jones <[email-masked]> wrote:
> “The value of the "subject" member is a string whose value is advisory and
> which the JRD describes.”
>

For someone writing a client library, I would take this to mean that
the subject "should" match, but since it doesn't have to, there's no
point in checking it and it can be safely ignored.

Also, I was discussing WF with a friend the other day and they asked
about the possibility of specifying a forwarding address, in the case
you switched email addresses, or have several and don't want to manage
WF data for all of them.

Is there any in-built mechanism for specifying a forwarding account,
or something which has a similar effect?

-Nick

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 15:58:56 -0500

John,

But, the subject is the subject of what the JRD describes.  Who is the
authority here?  It's the WF server.  If my server tells you "the following
JRD describes acct:[email-masked]", this is not subject to second
guessing.  The value might not be equal to the "resource" parameter (for
good cause), but normally would be.

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of John Bradley
Sent: Monday, December 03, 2012 8:11 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up
"subject"

I would change that to:

"The value of the "subject" member is a string whose value is advisory and
normally would be expected to be equivalent to the value of the "resource"
parameter in the client request.  The "subject" identifies the entity to
which the JRD claims to describe."

The subject is self asserted saying that it is defiantly the ting that the
JRD describes will lead to applications making mistakes.   The subject is
the thing that the JRD claims to be about.  It is more likely to be about
the thing you did the query on.   If they differ the client should
understand that the query parameter is the stronger binding.

If we go in on the acct: URI then I would be tempted to say that the value
SHOULD be the normalized acct: uri for the thing you are asking about.  That
is likely more useful information to the client.

John B.

Tim,

Paul

<<<<<<<

On Sun, Dec 2, 2012 at 12:21 AM, Paul E. Jones <
<mailto:[email-masked]> [email-masked]> wrote:

Folks,

 <http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07>
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07

Paul

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 16:11:56 -0500

Nick,

Does the words "would be expected to be equivalent" cause the concern?  Should I make that "normally be equivalent"?

The "best" means for "forwarding" would be to have the WF server respond with a 3xx pointing to the new location.

So, if you query
  acct:[email-masked]

It might return a 301 (though Blaine would suggest 307) that refers the client to
https://example.org/.well-known/webfinger?acct:[email-masked]

An alternative that is not documented is to utilize the "acct" link relation for this purpose.  That was text that used to be in the draft but was removed and is planned for a separate draft.

One could query acct:[email-masked] and the reply that comes back might be:

{
  "subject" : "acct:[email-masked]",
  "links" :
  [
    {
      "rel" : "acct",
      "href" : "acct:[email-masked]",
    }
  ]
}

This is not a "forwarding", per se, but could inform the client that additional or other information is available elsewhere.  This was never intended to a be a "forwarding" mechanism, though.  The 3xx should do that.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Nick Jennings
> Sent: Monday, December 03, 2012 8:19 AM
> Cc: Tim Bray; [email-masked]
> Subject: Re: Draft -07 mod proposal: Clean up "subject"
> 
> > Yeah, I can appreciate that.  However, I would like to suggest some
> > slightly different wording.  How is this for the first paragraph in
> 5.2.2?
> >
> > “The value of the "subject" member is a string whose value is advisory
> > and normally would be expected to be equivalent to the value of the
> "resource"
> > parameter in the client request.  The "subject" identifies the entity
> > to which the JRD describes.”
> >
> 
> For someone writing a client library, I would take this to mean that the
> subject "should" match, but since it doesn't have to, there's no point
> in checking it and it can be safely ignored.
> 
> Is there any in-built mechanism for specifying a forwarding account, or
> something which has a similar effect?
> 
> -Nick

---

From: Joseph Anthony Pasquale Holsten <[email-masked]>
Date: Mon, 3 Dec 2012 22:14:04 +0000

URI equivalence/normalization/canonicalization is a well defined rat hole. It's URI scheme specific, so we'll never be able to define all of these. If you think we need to explicitly say that "We defer the definition of URI equivalence to the mechanism defined by its schema," we can.

On 2012-12-03, at 05:42 , James M Snell <[email-masked]> wrote:

> -1 ... fixing this would be good but your proposed text isn't quite enough without either defining or specifically referencing what "equivalence" means. For example, as currently defined, the resource parameter can be a relative URI reference, while the subject could be an absolute URI reference. How does one determine equivalence exactly? 
> 
> - James
> 
>

---

From: Nick Jennings <[email-masked]>
Date: Mon, 3 Dec 2012 23:03:30 +0100

> Does the words "would be expected to be equivalent" cause the concern?  Should I make that "normally be equivalent"?

Well I guess it would help to have some clarification on the
implications (if any) of differences in the subject. Are there reasons
the client library would want to check this and do something different
if there is a difference?

> This is not a "forwarding", per se, but could inform the client that additional or other information is available elsewhere.  This was never intended to a be a "forwarding" mechanism, though.  The…

If you were using an email provider like gmail, or yahoo, but changed
your email address and wanted to forward to your new address, do you
think it's likely one of these big email providers would implement a
way for you to set up a 301 (or 307) redirect for all queries on your
account? I would guess no, so it seems more practical to have some
method of specifying this 'inline'.

In the JRD example you gave above, a WF client probably wouldn't
automatically issue a new request to the address based on that 'acct'
relation entry. So you'd loose quick-lookup functionality for all your
old interactions with your old email address.

I know there's probably no chance of this being introduced to the spec
(having a standard way of specifying a forwarding account within the
JRD response) but thought I'd bring it up anyway as I think there's
plenty of use cases for it (ie. switching jobs, switching email providers,
switching from an @gmail.com account to an @[mydomainname]
account, or just having a few variations on the spelling of your name).

-Nick

---

From: John Bradley <[email-masked]>
Date: Tue, 4 Dec 2012 13:20:37 -0300

Yes but if I query [email-masked] and it comes back with a subject of acct:[email-masked] I may be claiming the JRD is about you but that doesn't make it true.

Clients need to be mindful that the subject of the JRD is self asserted and care needs to be taken if any security related decisions are being made. 

On 2012-12-03, at 5:58 PM, "Paul E. Jones" <[email-masked]> wrote:

> John,
>  
> But, the subject is the subject of what the JRD describes.  Who is the authority here?  It’s the WF server.  If my server tells you “the following JRD describes acct:[email-masked]”, this is not subject to second guessing.  The value might not be equal to the “resource” parameter (for good cause), but normally would be.
>  
> Paul
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
> Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up "subject"
>

---

From: Tim Bray <[email-masked]>
Date: Tue, 4 Dec 2012 08:56:20 -0800

The longer this discussion goes on, the more convinced I am that we should
just remove “subject”. It’s really hard to specify properly and it’s not
obvious that it’s actually useful. -T

On Tue, Dec 4, 2012 at 8:20 AM, John Bradley <[email-masked]> wrote:

> Yes but if I query [email-masked] and it comes back with a subject of
> acct:[email-masked] I may be claiming the JRD is about you but
> that doesn't make it true.
>
> Clients need to be mindful that the subject of the JRD is self asserted
> and care needs to be taken if any security related decisions are being
> made.
>
>
> John,****
> authority here?  It’s the WF server.  If my server tells you “the following
> JRD describes acct:[email-masked]”, this is not subject to second
> guessing.  The value might not be equal to the “resource” parameter (for
> good cause), but normally would be.****
>
> Paul****
>
> *From:* [email-masked] [mailto:apps-
> [email-masked]] *On Behalf Of *John Bradley
> *Sent:* Monday, December 03, 2012 8:11 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up
> "subject"****
> ** **
> Added Web Finger to subject for the inocent.****
> ** **
> I would change that to:****
> ** **
>
> which the JRD claims to describe.”****
>
> ** **
> understand that the query parameter is the stronger binding.****
> ** **
> SHOULD be the normalized acct: uri for the thing you are asking about.
>  That is likely more useful information to the client.****
> ** **
> John B.****
> ** **
> ** **
> On 2012-12-03, at 4:16 AM, "Paul E. Jones" <[email-masked]> wrote:*
> ***
>
>
> ****
> Tim,****
>  ****
> slightly different wording.  How is this for the first paragraph in 5.2.2?
> ****
>  ****
> which the JRD describes.”****
>  ****
> Paul****
>  ****
>  ****
> *From:* Tim Bray [mailto:[email-masked]]
> *Sent:* Sunday, December 02, 2012 8:15 PM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Draft -07 mod proposal: Clean up "subject"****
>  ****
>
> <<<<<<<****
> wrote:****
>  ****
>  ****
> at the JRD documentation in section 5.2 and provide your comments.****
>  ****
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
>
>

---

From: John Panzer <[email-masked]>
Date: Tue, 4 Dec 2012 09:22:37 -0800

If subject is not spec'd, my guess is that people who want it would use
something like rel=canonical.  Which would have all the same issues but
would be not a Webfinger problem per se.
On Dec 4, 2012 8:56 AM, "Tim Bray" <[email-masked]> wrote:

>> *Subject:* Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean
>> up "subject"****
>> ** **
>> "resource" parameter in the client request.  The "subject" identifies the
>> entity to which the JRD claims to describe.”****
>>
>> ** **
>> The subject is self asserted saying that it is defiantly the ting that
>> the JRD describes will lead to applications making mistakes.   The subject
>> is the thing that the JRD claims to be about.  It is more likely to be
>> about the thing you did the query on.   If they differ the client should
>> If we go in on the acct: URI then I would be tempted to say that the
>> value SHOULD be the normalized acct: uri for the thing you are asking
>> about.  That is likely more useful information to the client.****
>> ** **
>> John B.****
>> ** **
>> ** **
>> "resource" parameter in the client request.  The "subject" identifies the
>> entity to which the JRD describes.”****
>>  ****
>> Paul****
>>  ****
>>  ****

---

From: James M Snell <[email-masked]>
Date: Tue, 4 Dec 2012 09:28:06 -0800

I'm quite the opposite on this actually... at first I didn't think it would
be useful but then I really sat down and started going through various use
cases.. in particular, how things could be implemented in environments like
IBM's hosted cloud social services.

In our environment, there are two critical identifiers for a user... their
email address (which is usually their company specific address.. e.g.
[email-masked]) and the account id used within our application. If we
were to implement WebFinger in our infrastructure on behalf of our clients,
it should be possible to pass in either the email address or the account id
as the value of the resource parameter. Regardless of which is passed in,
the JRD returned should be identical. The subject (and aliases) properties
would provide the necessary correlation we need to match them up.. e.g.

https://apps.example.com/.well-known/webfinger?resource=acct:[email-masked]

https://apps.example.com/.well-known/webfinger?resource=acct:[email-masked]

both would return...

  {
    "subject": "acct:[email-masked]",
    "aliases": [
       "acct:[email-masked]",
       "acct:[email-masked]"
    ],
    ...
  }

It's ok if the value of the resource parameter does not match,
character-for-character, the subject value.. and determining the
equivalence of the two values is not critical so long as the resource
parameter value shows up as one of the listed aliases.

- James

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 5 Dec 2012 18:16:01 -0500

It's true, because that's what your server said.  It does not mean that this
document represents me, though.  It only means that, at your server, this is
the document that particular URI will return when queried.

Consider other examples like the "tel" URI.  They don't even have domain
information with them, but folks want to be able to query some defined
server any query using that tel URI.  Assume the server returns a reply.
Another server that also accepts tel URIs might reply with something
different.

There may be some language we need to add so that the client does not assume
the "subject" returned does represent a "subject" at another domain,
especially one where the "subject" is like this one you present.  By itself,
it's harmless.  But, if a client assumes the response really is me. yes,
that's bad.

Words?

Paul

From: John Bradley [mailto:[email-masked]] 
Sent: Tuesday, December 04, 2012 11:21 AM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [apps-discuss] Web Finger Draft -07 mod proposal: Clean up
"subject"

Yes but if I query [email-masked] and it comes back with a subject of
acct:paulej@ <http://packetizer.com/> packetizer.com I may be claiming the
JRD is about you but that doesn't make it true.

Clients need to be mindful that the subject of the JRD is self asserted and
care needs to be taken if any security related decisions are being made. 

John,

But, the subject is the subject of what the JRD describes.  Who is the
authority here?  It's the WF server.  If my server tells you "the following
JRD describes acct:paulej@ <http://packetizer.com> packetizer.com", this is
not subject to second guessing.  The value might not be equal to the
"resource" parameter (for good cause), but normally would be.

Paul

I would change that to:

John B.

On 2012-12-03, at 4:16 AM, "Paul E. Jones" < <mailto:[email-masked]>
[email-masked]> wrote:

Tim,

Paul

From: Tim Bray [mailto:tbray@ <http://textuality.com> textuality.com] 
Sent: Sunday, December 02, 2012 8:15 PM
To: Paul E. Jones
Cc:  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]
Subject: Draft -07 mod proposal: Clean up "subject"

<<<<<<<

Folks,

Paul