This page provides an overview of issues being tracked by the group

• Local file access
• Use of SRM with distributed filesystems, experiences - SRM implementations are now being used widely with Lustre, GPFS, etc.,
• Optimisation - it is possible to use the protocol more effectively than a standard get/wait/read/done cycle widely used by clients, eg by grouping files, or by returning TURLs immediately if the file is already on disk.
• Limiting resource use - currently the most common way for a server to tell the client to "back off" is to make it hold by delaying the next getXStatus (increasing the callback interval) - however, this may cause some clients to time out.
• Clarifications of where the implementations differ: different implementations have slightly different views of what a space is, for example, even if the protocol they provide to it is the same.
• Clarification of deviations from the protocol. The interoperation testing between the implementations has been highly effective, to the extent that interoperating has had higher priority than following the standard. (Plus feature pressure from certain large user communities tend to have this effect as well.) gLite clients do not use the full API, so implementations used only by projects using gLite do not necessarily implement the full API.
• Use of SRM outside HEP (dissemination)
• WAN access is normally managed by GridFTP, and a WAN protocol has to be supported by ALL implementations, or it cannot move data between them.
• The use of GSI sockets for SRM: srmCopy depends on delegation, but there have been several requests for managing delegation in other ways, eg. via the gLite delegation API, and make the control interface fully compatible with normal HTTPS.