Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Update section 7

...

Lead

Expand

6.

Notification Events 

§

  • (tick) For every resource whose state is changed as a result of an HTTP operation, there must be a corresponding notification made available describing that change.

6.

Notification Serialization 

§

  • (tick) The notification serialization must conform to the [ activitystreams-core ] specification.
  • (tick) Wherever possible, data should be expressed using the [ activitystreams-vocabulary ].
  • Each event described by a notification must contain:
    • (question)The IRI of the resource that was created, modified or deleted
    (
    • (tick) The event type(s) corresponding to the HTTP operation
  • Each event described by a notification should contain:
    • (tick) The agent(s) that caused the change to occur
    • (tick) The RDF type(s) of the resource that was changed
    • (minus) The location of the ldp:inbox for the resource that was changed, if such an inbox link exists
    • We are not planning to support the ldp:inbox in the reference implementation.
  • (tick) Notifications should not contain the entire content of repository resources.

6.3 Examples

  • Non-normative section

7 Binary Resource Fixity

Lead

Expand

7.1

What is fixity?

Example proceedures that may be used to verify fixity:

  • (tick)Checksums like MD5 or SHA1, often used for digital images.
  • (minus) XML Signatures

    Transmission Fixity

    • non-normative section

    7.2 Persistance Fixity

    • non-normative section
    • not implemented / Not required
    (minus) Per-segment results as used for time-based media
    • not implemented / not required

    7.2 Transmission Fixity

  • (tick)   may be verified by including a  Digest  header (defined in [ RFC3230 ]) in POST
    • for example, in curl command: -H "Digest:sha=a79ca8393d8866ce4899f523235a3b8b6812e76b"
  • (tick)   may be verified by including a  Digest  header (defined in [ RFC3230 ])  in PUT

    for example, in curl command: -H "Digest:sha=a79ca8393d8866ce4899f523235a3b8b6812e76b"

    7.3 Persistance Fixity
    • (tick) may retrieve the checksum of an  LDP-NR  by performing a  HEAD  request on it with the  Want-Digest  header
      • mechanism: curl command for HEAD with header: -H "Want-Digest: md5,sha" will return, in the headers:
        Digest: sha=9f0f5b0c24303b003b5afaa0031e126cc6f7fa67,md5=0a85fd5f25c09a9f282b15e7758b3acd
    • (tick) may retrieve the checksum of an  LDP-NR  by performing a  GET  request on it with the  Want-Digest  header mechanism: curl command for GET with header: -H "Want-Digest: md5,sha" will return, in the headers:
      Digest: sha=9f0f5b0c24303b003b5afaa0031e126cc6f7fa67,md5=0a85fd5f25c09a9f282b15e7758b3acd