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

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 <jasnell@gmail.com> 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
> 
> 
> On Sun, Dec 2, 2012 at 5:14 PM, Tim Bray <tbray@textuality.com> wrote:
> 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 <paulej@packetizer.com> 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
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 