Comment: untrusted environments and security

I imagine that one of the uses of XProc is to perform server-side 
pipelines on documents to prepare them for delivery to a user agent.  If I 
were to be running such a server, I would be worried about allowing a 
p:directory-list step to run on the server.*

The existence of an XProc MIME type hints strongly that XProc might also 
find a home in client-side processors (e.g., user agents) doing similar 
munging on pure input documents.  I would want to lock down any XProc 
processor running on my desktop machine, particularly one that can both 
query my file system with p:directory-list and can connect to arbitrary 
servers with p:http-request.

The 20 September 2007 draft speaks only indirectly of security, so I am 
left to conclude that implementations which fail on certain steps for 
security reasons are not conformant.

My suggestion is that XProc explicitly allows implementations to run with 
(implementation-specific) heightened security.  Certain steps can throw a 
dynamic error if they would otherwise violate the security policy for the 
environment that the pipeline is running in.  XProc need not define the 
security requirements, nor even what the 

* Yes, if I can't trust the pipeline itself then perhaps there are bigger 
problems.  Server-side security may be paranoia, or it may be company 
policy.  The client-side issue is still valid.

-- 
Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne
Deborah_Pickett@moldflow.com