RE: Section 3.5. Passing fragment identifiers to other systems.

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