- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Fri, 27 Feb 2004 12:57:43 -0500
- To: Martin Duerst <duerst@w3.org>, "Williams, Stuart" <skw@hp.com>
- Cc: uri@w3.org
At 11:14 AM 2004-02-27, Martin Duerst wrote: >At 15:06 04/02/24 -0500, Al Gilman wrote: > >>But "MUST NOT" pass to "other systems" is unjustified and detrimental. >>It should be fixed. If we want to warn people off of abuse-encouraging >>variants, we need to check out appropriate uses and draw the line >>appropriately before we go there. >> >>Has there been abuse? Is there a public discussion of it somewhere? > >Yes, at least proposed. There were proposals for schemes that tried >to say something like "in general, you don't need to send the fragment >identifier, but for this scheme, you actually do". > >That's what Larry's statement at >http://www.w3.org/mid/0HTK004JSDWDTK@mailsj-v1.corp.adobe.com >would address. What did Larry say? He said that you can't identify client and server in the future, so don't key rules to those roles. He did offer that one might rephrase the rule as keyed to the scheme-specific processing. But that was simply to avoid the above problem. He wasn't introducing any evidence of abuse, that is to say instances where violation of this rule had been exploited to do something bad. Larry's statement is IMHO grounded in HTTP and HTML. I didn't regard it as a position taken after a careful review of the model and functioning of the 'info' scheme. 'Abuse' requires actual damage, not simply the violation of a clause in a draft spec. Hopefully Larry will find time to comment again. On the other hand, there may be a perfectly good binding in URI syntax for the 'info' model that uses path segments or ?query-part name-value selectors rather than #fragments for what the current proposal uses #fragments for. Al >Regards, Martin.
Received on Friday, 27 February 2004 13:24:52 UTC