Technologies for PubSub Application Format (PSAF )

1. Technologies for PubSub Application Format (PSAF) Leonardo Chiariglione CEDEO.net Kenichi Nakamura (Panasonic) Giuseppe Tropea (CNIT) Valencia, ES, 2014/04/01

2. Publish/Subscribe (PubSub) • An established communication paradigm where communication is • Not directly between Sender and Receiver but • Mediated by a service between Sender and Receiver • How it works • Senders (called Publishers) post information on their information to a service • Receivers (called Subscribers) declare their interest in a certain type of information to the same service • The match service detects Pub/Sub matches and notifies accordingly

3. PubSub actors and workflow • Creator stores content • Publisher publishes information on content • Subscriber subscribes to a type of content • Match Service • Matches subscription with publication • Issues appropriate notification(s) • Consumer plays content referenced in notification

4. Information exchange in PubSub

5. Information Centric Networking (ICN) • In ICN, entities are individual, identifiable (named) content elements, instead of unidentifiable data containers (i.e., IP packets) Connect me with Give me today’s issue host 66.45.78.89 of Time Magazine Future Information Centric Networking Current Address Centric Networking • PubSub is well suited for ICN

6. PubSub users shall be able to/1 • Define lists of users to be/not to be notified of an event • Enumerations • Groups of users • Users satisfying certain conditions • Reference the Resource via a standard information package containing • Descriptions of Resource • Rights and conditions for use of Resource • List of users to be notified that specific use of a Resource has been made

7. PubSub users shall be able to/2 • Select Match Service Provider(s) • Prescribe to Match Service Provider ;ist of • Pub-Sub users to be considered in computing matches, specifically defined as • Subscriptions to be/not to be considered as candidates for matches with publications • Publishers to be/not to be considered as candidates for matches with subscribers • Users to be/not to be notified of an event in the event of a match

8. PubSub users shall be able to/3 • Define additional conditions to be added to Publications and Subscriptions such as • Validity of Publication/Subscription (i.e. the period of time defined by a start and end time the Match Service Provider shall notify matches) • Update their Publications/Subscriptions

9. Elements of Resource Information

10. Elements of Publication Information

11. Elements of Subscription Information

12. Elements of Notification Information

13. Publish/Subscribe in ICN Peer1 NI 6 Match Service Subscribe SI Request RI SI 3 4 PI 1 SI PI 7 5 MATCH RI Publish PI NI Peer2 Store RI Content Centric Network RI RI 2

14. Technologies for PSAF • MPEG technologies to specify the PSAF • Digital Item • Digital Item Identifier • Simple Metadata Profile • MPEG Query Format • Rights Expression Language • Event Reporting • Outside MPEG to specify the PSAF • W3C Signature Recommendation. A gateway to new opportunities for digital content

15. Design of RI, PI, SI, NI/1 INFORMATION OBJECT • HEADER • PAYLOAD • RIGHTS • NOTIFICATION HEADER • INFORMATION OBJECT ID • SIGNATURE of INFORMATION OBJECT’s creator A gateway to new opportunities for digital content

16. Design of RI, PI, SI, NI/2 PAYLOAD • TYPE of payload (R, P, S, N) • USER ID of INFORMATION OBJECT’s creator • METADATA {optional, for instance in case of NI} • [ RESOURCE METADATA ] or [ PUB METADATA ] or [ SUB METADATA ] • RESOURCE METADATA • [ KEYWORDS ] or [ FIELD-VALUE ] or [ STRUCTURED DATA ] • PUB METADATA • [ KEYWORDS ] or [ FIELD-VALUE ] or [ STRUCTURED DATA ] • SUB METADATA • QUERY • List of IDs of INFORMATION OBJECTs the PAYLOAD refers to {optional, e.g. in case of SI}

17. Design of RI, PI, SI, NI/3 RIGHT • PRINCIPALs • List of USER/SERVICE IDENTIFIERS • VERBs • ID of INFORMATION OBJECT the RIGHT refers to • CONDITIONs • [ List of USERs who must be involved in the RIGHT ] or [ other REL conditions ]  NOTIFICATION • RECIPIENTs to notify • List of USER IDs to notify • List of USER IDs not to notify

18. Discussion – PAYLOAD/1 • KEYWORD and FIELD-VALUE to cover most PubSub Applications’ needs for • STRUCTURED DATA element imported by the didl-msx schema to define any kind of XML based metadata (including RDF/XML) - when metadata in the form of field/value is not sufficient • QUERY element imported from the MPEG Query Format schema (e.g. of InputQueryType). The MPQF schema can contain any kind of queries, as it can flexibility define complex disjunctive/conjunctive queries of any type e.g. SPARQL, XQuery, or field/value.

19. Discussion – PAYLOAD/2 • Identifier of user/peer that created the Information object – needed to serve as conditions (in the RIGHT block of matching objects) to filter the match based on information issuer. • Identifiers the payload refers to – a vital information to be reported back to users: for instance • In NI the triple {ID of PI, ID of SI, ID of RI} is reported back to a subscriber to signal that the specific SI issued by the subscriber matches a specific PI and the relevant resource can be located through the given RI A gateway to new opportunities for digital content

20. Discussion – RIGHT/1 • Requires a verb to indicate the right to perform MATCH of a pub with a sub and vice-versa. Current REL specification does not appear to include such a verb. • Need to specify conditions, to restrict MATCH to Information objects coming from selected issuers or to notify only of matches that satisfy the given conditions. • We want to have the right to match a pub with a sub to be subject to the fact that a “third party shares in the execution of the right”, in addition to the right’s principal A gateway to new opportunities for digital content

21. Discussion – RIGHT/2 • A new verb NOTIFY is a possible alternative, i.e. he right to create a list of users/peers to be notified depending on the result of satisfying the conditions expressed in • Publications • Users to be/not to be notified • Subscriptions that are eligible for matches with Publications • Subscriptions • Users to be/not to be notified • Publications that are eligible for matches with Subscriptions A gateway to new opportunities for digital content

22. Discussion – RIGHT/3 • An alternative is the use of CEL. • In REL “Pub-Sub user gives MSP the right to match” and MSP has the duty to notify • In CEL more sophisticated Pub-Sub user vs Match Service Provider relationships can be encoded • Publisher will pay 20 € if MSP notifies 1000 (Mil) Subscribers as profiled in Publication, satisfying Subscribers’ conditions. • The Cost Per Mil (CPM) notifications could depend on how finely the Publication profiles Subscribers. • With User Description Publishers (Subscribers) can make fine specification of target Subscribers (Publisers) because Pub-Sub users share the semantics of user descriptors.

23. Discussion - NOTIFICATION • Whenever a match occurs between a specific PI and SI, the notification lists of PI and SI are crosschecked to preserve the request made by Pub-Sub users for dissemination of notifications • If user A is on the black list of the SI (i.e. SI’s creator B didn’t want user A to be notified whenever B’s SI gets matched), but also on the white list of the PI, user A will not be notified. • The white list may include the creator of the Information object but, if that user appears on the black list of the matching Information, the original creator is not notified.

24. Mapping to existing technologies A gateway to new opportunities for digital content

25. Schema of PSAF Payload/1

26. Schema of PSAF Payload/2

27. Schema of PSAF Payload/3

28. Conclusions • This document proposes • Multimedia application requirements in PubSub messaging that take into account controlled distribution of information • Four payload formats • A set of (MPEG) technologies that can be used to specify the formats • There are some alternatives that may need further investigations but there is enough material to start drafting the PSAF standard