I'm starting a detailed review of the SWORD specs (http://swordapp.org/sword-v2/sword-v2-specifications/), for the first time since our meeting last year, and have decided to start with the draft internet-drafts, since I'm expecting that these+AtomPub will form the foundation of SWORD. I'm hoping to complete this over the coming week, but can't promise on timescales.
So, reviewing: http://swordapp.org/wp-content/uploads/2011/03/PackagedContentDelivery.txt == Front page == I think it would be better to target "Informational" status rather than "Experimental" as the first step. I think the overall message here should be "this is what we are doing" rather that "this is what we might do". Is SWORD a legal entity capable of holding copyright? Suggest yourself or UKOLN. == Abstract == You start with "Often in information systems...", which seems a bit vague to me. A reason for submititng this to IETF would be that the technical pieces are more widely applicable, e.g. in the context of "document management systems", which I think will better help people to understand the intended scope of the feature. Also, mentions media features, which you no longer define. Suggest something along the lines of: [[ Document management systems often present a requirement to move content between applications and servers in groups of files and associated metadata. HTTP and AtomPub protocols provide a good match for this requirement, but do not make certain information easily available to the systems exchanging data. This document describes HTTP Headers to convey information about packaging and authority information relating to a transfer. ]] == 1. Introduction == "Media features" mentioned again I think some background to this work, and brief discussion of motivation would help, explaining that it has been developed as part of the SWORD protocol for depositing academic outputs (including but not restricted to papers...) into institional and subject repositories, etc... Then go on to indicate the additional requirements this evokes that go beyond simple HTTP and AtomPub usage. I also think (somewhere in the document) a brief example of these proposed headers used in an exchange would make it much easier to follow. It may be worth briefly discussing alternatives considered and why they were not chosen (e.g. media features) - the IETF community are likely to push back if it is perceived that existing features have not been considered. Your HTTP reference (RFC2068) is very dated - RFC2616 (http://tools.ietf.org/html/rfc2616) is more current (yet still over 10 years old!) I think something should be said about what the packaging expression actually means, for easch of the alternative syntaxes allowed. How is a token or quoted string to be interpreted? Is there a registry of package values? If not, I'd be inclined to go with just a URI here. Are MIME media-types usable in this context? How does this differ from a MIME media type? If there are a small number of non-URI values in use, then they could be enumerated here to avoid the overhead of creating a registry. == 2. Packaging == It is implied that "packaging" applies to resource that is composed of component resources. I think this should be stated explicitly. You make reference to a "user agent" - I'm not sure this is appropriate. In the context, I think "client" would be clearer. (I still think "Content-features" could be used here, with suitably registered media features.) == 3. Accept-packaging == The "Prefer" header field might be an option here. I think many of my comments applied to packaging would also apply here. A separate section about the nature of packaging might be in order. == 4. On-behalf-of == Nit: I think it might be better to use digest auth in the example, to avoid discussioin of the inadequacies of HTTP basic auth == 5. In-progress == == 6. Suppress-metadata == In reading this, it was very unclear to me what element of interoperability is served by these headers. Especially w.r.t. "it is necessary that server/client pairs will have to have a common understanding of its meaning", I am asking myself if the server and client have a commin understanding, why do they need this header field? More generally, I also wonder if these elements might not be treated as parameters or options of the "packaging" header field, rarther than separate headers. That's a small detail, but if they serve any useful purpose it might be easier to get them approved that way. I also suggests that package description parameters might prove a useful extension point for further developments. == 7. Security considerations == This needs more work! There's far more at scope here than just using HTTP. For example, the package may be used as a carrier for malicious content... Also need to note that the On-Behalf-Of field should not be taken as confirming authority to act on behalf of the agent thus identified. Also, if script files are created with that agents ownership, it might open privilege escalation opportunities. And so on. == 8. IANA considerations == Still mentions media feature The registration templates are incomplete (even if just indications of the "current" document) - it is possible, in principle, for the registration template to be presented separately from the containing document. ... #g -- ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
