GRDDL WD comments

Here are my collected comments on the GRDDL WD

	Gleaning Resource Descriptions from Dialects of Languages (GRDDL)
	editor's draft $Date: 2007/02/21 16:25:45 $
	$Revision: 1.228 $

I think that only one of my comments is substantial and it is identified in 
HTTP Headers.

I have taken the liberty to edit Jeremy's Security section. Feel free to 
ignore my edits.
In particular, I tried to reduce the use of "should" phrases and substitute 
"are advised" phrases.
I did this on the basis that one man's security risk is another man's 
design feature.

Caveat transformor.


In the Abstract, paragraph 2.
	Please add a sentence about HTTP Headers
	"Finally, an HTTP header allows transformation links to be associated with 
documents
	that do not have the necessary extension mechanisms in either their 
schemas or instances."

In the Introduction, rewrite:

	"Although the examples describe the exact same thing, as it stands there's 
no clear mechanism
	 through which computer software might be able to make this connection."

to

	"Although the examples above are obviously encodings of the same information,
	there remains no clear mechanism through which computer software might be 
able
	to determine this connection."

in Preface and Companion Documents
	Need mention and forward reference to HTTP Headers

in 2. Adding GRDDL to well-formed XML
	in the paragraph that follows the image labelled "extracting title and 
author information"

	"As you will see in later sections, there are other ways to add GRDDL to 
HTML documents,
	especially designed to leverage HTML's existing capabilities and thereby 
overcome constraints
	imposed by the XML DTDs for some dialects of HTML. See Using GRDDL with 
valid XHTML
	and GRDDL for HTML Profiles."

	Add a mention and forward reference to HTTP Headers

in 6. Using GRDDL With HTTP Headers (substantial comment)

	It occurs to me that it might be wise to differentiate the rel value in an 
HTTP header
	from the rel value in an HTML link element. Currently they both use 
"transformation"
	as a value from the GRDDL namespace. Just as we differentiate among the
	transformation/namespaceTransformation/profileTransformation, I think that
	we should have an httpTransformation to differentiate from transformations
	that are encoded within the document. I believe that this is a factor that 
would
	be very valuable in assessing which transformations to apply. I.E., I 
think that
	I would trust a transformation more than an httpTransformation if there were
	any dispute between their result graphs. But maybe that's just me.

in 8. GRDDL-aware Agents, edit the 2nd para as follows:

	"The appropriate policy for which results to compute and when is likely to 
involve waiting
	for a signal from user more in the Web browser case than in the query 
service case."

changes to:

	"The appropriate policy, for which results to compute and when, is more 
likely to involve waiting
	for a signal from a user in the Web browser case than in the query service 
case."

in 8. GRDDL-aware Agents, edit the 4th & 5th para as follows:

	Use alpha sub-list instead of ordinal numbers to avoid confusion
	Refer to steps 1.d and 1.e instead of 4 and 5 to avoid confusion.

in Example: A GRDDL-aware Agent protocol trace

	"While this declarative specification of GRDDL allows a variety of 
implementation strategies,
	in this appendix we trace the behavior common to a number of typical 
implementations."

becomes

	"While this declarative specification of GRDDL allows a variety of 
implementation strategies,
	in this example we trace the behavior common to a number of typical 
implementations."

in 9. Security considerations

	s/GRDDL transforms/GRDDL transformations/
	s/the transform/the transformation/

	"The execution of general-purpose programming languages as interpreters 
for transformations
	entails serious security risks, and GRDDL-aware agents should not simply 
send GRDDL
	transforms to "off-the-shelf" interpreters. "

[in my opinion] becomes

	"The execution of general-purpose programming languages as interpreters 
for transformations
	exposes serious security risks. Designers of GRDDL-aware agents are 
advised to guard against
	simply sending GRDDL transforms to untrusted interpreters. "

Using material found in 9.1-9.6, I extracted a paragraph which becomes para #2

	"GRDDL, like many Web technologies, fundamentally relies on the 
dereferencing of URIs.
	Writers of GRDDL transformations are advised against employing URL operations
	which are potentially dangerous, because these operations are more likely 
to be
	unavailable in secure GRDDL implementations. Software executing GRDDL 
transformations
	are advised to either completely disable all potentially dangerous URL 
operations or
	take special care not to delegate any special authority to their 
operation. In particular,
	operations to read or write URLs are more safely executed with the 
privileges associated
	with an untrusted party, rather than the current user. Such disabling 
and/or checking
	should be done completely outside of the reach of the transformation 
language itself;
	care should be taken to insure that no method exists for re-enabling 
full-function versions
	of these operators.

In 9.1
	"GRDDL, like many Web technologies, fundamentally relies on the 
dereferencing of URIs.
	With unconstrained use of GRDDL, untrusted transform may access URLs which
	the end-user has read or write permission, while the author of the 
transform does not."

becomes

	"With unconstrained use of GRDDL, untrusted transformations may access 
URLs for which
	the end-user has read or write permission, while the author of the 
transformation does not."

In 9.2

	Delete 2nd paragraph. It has been moved up

In 9.3

	"Some implementations of the transform language may provide nonstandard 
facilities
	for the direct loading and execution of other programming language code. 
For example,
	an XSLT implementation may provide a method of calling Java code. Such 
facilities are
	quite obviously open to substantial abuse. GRDDL transforms should not 
make use of
	such features. Besides being totally implementation-specific, they are 
also likely to be
	unavailable in secure implementations of the transformation langauge. 
Software executing
	GRDDL transforms should not allow such operators to be used if they exist."

becomes

	"Some transformation language implementations may provide facilities
	for loading and executing other programming language code. For example,
	an XSLT implementation may provide a method for executing Java code. Such 
facilities are
	obviously open to abuse. Designers of GRDDL transformations are advised 
against making use of
	such features. Besides being implementation-specific, they are more likely 
to be
	unavailable in secure implementations of the transformation language. The 
use of
	such operators in software executing GRDDL transformations should protect 
against
	such operators in case they are encountered."

In 9.4

	"XSLT is an extensible language, and many, if not most, implementations of it
	provide a number of their own extensions. This document does not deal with
	such extensions explicitly since they constitute an unknown factor.
	GRDDL transforms should not make use of nonstandard extensions;
	they are likely to be missing from some implementations.
	Software executing GRDDL transforms should make sure that any nonstandard 
operations
	are secure and don't present any kind of threat."

becomes

	"XSLT implementations often provide their own extensions.
	Designers of GRDDL transformations are advised not make use of extensions
	because they are not guaranteed to be present in all implementations.
	Software executing GRDDL transformations should make sure that extensions
	are secure and do not present any kind of threat."
	
In 9.5

	"It is possible to write transforms that consumes huge amounts of various 
system resources.
	It is also possible to write transforms that loop indefinitely. Both types 
of transforms have
	the potential to cause damage if sent to unsuspecting recipients. Authors 
of GRDDL source
	documents should avoid the construction and dissemination of such transforms.
	Software executing GRDDL transforms should provide appropriate mechanisms
	to abort processing after a reasonable amount of time has elapsed. In 
addition,
	GRDDL software should be limited to the consumption of only a reasonable 
amount
	of any given system resource."

becomes

	"Since it is possible to write transformations that inordinately consume 
system resources
	or that loop indefinitely. Both types of transforms have the potential to 
cause damage
	if sent to unsuspecting recipients. Designers of GRDDL transformations are 
advised
	to avoid the construction and dissemination of such transformations.
	Software executing GRDDL transformations should provide appropriate 
mechanisms
	to abort processing after a reasonable amount of time has elapsed. In 
addition,
	GRDDL software should be limited to the consumption of only a reasonable 
amount
	of any given system resource."

in 9.6

	"Finally, bugs may exist in some interpreters of the transform language which
	could possibly be exploited to gain unauthorized access to a recipient's 
system.
	Apart from noting this possibility, there is no specific action to take to 
prevent this,
	apart from the timely correction of such bugs if any are found."

becomes

	"Finally, bugs may exist in some interpreters of a transformation language 
which
	might be exploited to gain unauthorized access to a recipient's system.
	Apart from noting this possibility, no specific action is advised to take 
to prevent this
	aside from timely correction of such bugs as they are discovered."

in Appendix: Implementation Experience: Test Cases, Software, and Services

	s/identifyable/identifiable/


There may be other spelling/grammatical errors which I have not detected.

These are my comments. After these comments are considered by the editor,
I will be prepared to vote in favor of sending this WD to the next stage.

Just in case I am unavailable over the next few weeks, my proxy is in Dan's 
hands.

Regards,

Murray

Received on Wednesday, 21 February 2007 21:29:43 UTC