One other thought: it might be more descriptive to change the draft title to:
HTTP header fields for packaged content delivery
#g
--
Graham Klyne wrote:
> 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
>
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Sword-app-techadvisorypanel mailing list
Sword-app-techadvisorypanel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
