Subject: [ESDS] Work Items - update

From: Mark Harrison <[email-masked]>
Date: Mon, 8 Sep 2008 15:55:35 +0100

Dear ESDS folks,

Please find below an edited version of the ESDS work items.

Reading through the work items that Ali posted on 31st July, there is  
still quite some emphasis on industrial supply chains - particularly  
in the data fields.  The IETF may be more interested in developing a  
protocol for a rather more generic referral system, which can be used  
for other applications as well as for supply chains.

Certainly, one of the applications motivating the development and  
standardization of Discovery Services is the increasing use of  
automatic identification technologies (in particular Radio Frequency  
Identification (RFID) ) to capture observations of tagged physical  
objects within the premises of a company and also as they pass from  
one company to another, in a supply chain or supply network.

However, Discovery Services have a potentially wider generic  
applicability, as a bottom-up mechanism for constructing indices and  
referral systems for information about particular topics or keywords,  
particularly when the contributed information is distributed across  
multiple nodes on the internet and in particular, where the  
contributed information (and the metadata that enables its discovery)  
is not intended to be available to everyone or is not ordinarily  
discoverable by public web search engines that perform automated  
crawling and indexing of publicly accessible content.

Some of the optional data fields and example extensible data fields  
are perhaps too specific to supply chains and might need to be made  
one level more abstract.  I've therefore made some minor edits to the  
work item 1b.

I have also split work item 3b (publishing interface) into three  
separate items and also made some edits and comments on work items 4c  
(multilayer information visibility), 5a (queries within a federation  
of Discovery Services) and 5c (joining a federation of Discovery  
Services).

Best regards,

- Mark Harrison

Suggested modifications too the work items (and additional comment  
from Mark Harrison) below:

Work item current status and summary:
1.Initial Conventions

    a) Define common vocabulary and terminology.
    http://www.ietf.org/mail-archive/web/esds/current/msg00085.html
    http://www.ietf.org/mail-archive/web/esds/current/msg00087.html

    b) Define core data sets for sharing on Discovery Service,
    There are two sets of core data fields, one for data being  
published, and
    another for the data returned in response to a query.
    Publishing data fields:
        required data fields:
            URI object identifier (what)
            Publish timestamp (server timestamp)
            Service list of URLs (links)
            Event class (event type attributes, such as time-to-live  
(TTL))
            URI of event publisher (who)
        optional data fields:
            Contextual metadata (why)
		Application context:	e.g. supply chain
		sub-context:			e.g. pharmaceuticals
		Process:				e.g. shipping
		Location:			e.g. geospatial location (latitude, longitude, altitude)
								postcode
								businessLocation URI (as in EPCIS standard)
						(includes extension mechanism for other kinds of location)
            Event timestamp (client timestamp)
            Related identifiers:
		Application context:	e.g. supply chain,
		Process:				e.g. aggregation, disaggregation, relabeling, synonyms
		Related ID List:		e.g. ID of parent container or relabelled product
		Relation:			e.g. parent, children, relabelled-as

        example extensible data fields:
            Cross-referenced documents and transactions (type and ID):
			e.g. Purchase Order #, Advanced Shipment Notice #, Invoice #

    Query response data fields:
        required data fields:
            URI object identifier (what)
        optional data fields:
            Publish timestamp (server timestamp)
            List of URL referrals to information resources
            Event class (event type attributes, such as time-to-live  
(TTL))
            URI of event publisher (who)
            Contextual metadata (why)
		Application context:	e.g. supply chain
		sub-context:			e.g. pharmaceuticals
		Process:				e.g. shipping
		Location:			e.g. geospatial location (latitude, longitude, altitude)
								postcode
								businessLocation URI (as in EPCIS standard)
						(includes extension mechanism for other kinds of location)
            Event timestamp (client timestamp)
             Related identifiers:
		Application context:	e.g. supply chain,
		Process:				e.g. aggregation, disaggregation, relabeling, synonyms
		Related ID List:		e.g. ID of parent container or relabelled product
		Relation:			e.g. parent, children, relabelled-as

        example extensible data fields:
            Cross-referenced documents and transactions (type and ID):
			e.g. Purchase Order #, Advanced Shipment Notice #, Invoice #

    c) Define handling for time zones.
    ESDS will only support UTC timestamps

    d) Define handling for Aggregation, Disaggregation, and Relabeling  
events.
    These events are useful for expressing when it may be necessary to  
track
    a different identifier in order to follow the same object.
    http://www.ietf.org/mail-archive/web/esds/current/msg00101.html

    e) Define handling for Transaction events. These events would  
associate (or
    disassociate) one or more object identifiers from the identifier of
    a business transaction or document.

2.Security

    a) Considerations for access control policies and their impact on  
Work
    Items 3 and 4.

    b) Define security architecture and mechanisms for authorization,
    authentication , encryption (e.g. integrating security  
certificates into
    the protocol vs. relying on a security layer such as SSL).
    http://www.ietf.org/mail-archive/web/esds/current/msg00104.html

    c) Define a common interface and roles for access control  
configuration
    (e.g. supply chain, partner, user).

    d) Define a mechanism for verifying digitally signed DS events  
published.
    The challenge is that the DS may need to validate the signatures  
for signed
    events it receives and log whether the data underlying a link was  
from a
    verifiable signed source.  i.e. the DS should log and indicate the  
presence
    of a verified signature in the query response (especially when it  
does not
    pass the whole signed event record to the query client).

3.Publishing Interface

    a) Define mechanism for uniquely identifying objects in a scope  
without
    requiring a global unique identifier for each and all objects that  
enter a
    scope (e.g. supply chain).
    Closed deployments of DS can utilize internal numbering authority/ 
rule and
    to make the identifier globally unique, prefix it with a  
registered domain name
    (e.g. to construct a well-formed HTTP URI )
    http://www.ietf.org/mail-archive/web/esds/current/msg00114.html

    3b-part 1) Define an initial registration protocol through which a  
data resource
    may join a Discovery Service, including mutual authentication  
between a
    Discovery Service and the new resource. (Resource Registration)

    3b-part 2) Define a protocol for advertising/publishing data  
records for a
    particular ID (or list of IDs), to link to particular resources
    (Record Publication)

    3b-part 3) To cater for the situation where a resource publishes a  
record to
    establish a link to another resource other than itself (see 3e  
below), define a
    protocol to allow the Discovery Service to authenticate the  
identity and type
    of that other resource, which may include periodic monitoring to  
detect
    change of address or non-availability (Resource Authentication &  
Monitoring)

    c) Define a protocol and policy for retracting or voiding  
published data.

    d) Define policies for updating stale and broken links (e.g. for  
events
    with a long retention period, it is vital that links can be  
updated, when
    required).
    Publisher profile described in BRIDGE's "High level design for  
Discovery
    Services" will address this requirement:
    http://www.ietf.org/mail-archive/web/esds/current/pdfuMVBqNwBjM.pdf

    e) Define a mechanism to enable linking Discovery Service servers  
together
    (e.g. retrieving information about the entire lifecycle of a  
product as it
    moves through various supply chains).
    In the case of a record that points to another DS (instead of an  
information
    source), the query client application may choose to make a  
separate query
    to the other DS, not necessarily requring any involvement of the  
original
    DS (other than if DS1 is required to provide a federated trust  
token to the
    client that it can present to DS2).

4.Query Interface

    a) Define a protocol for querying published data, supporting both
    one-time queries and standing queries (e.g. pull vs. push queries).

    b) Determine how aggregation and disaggregation events should be  
handled
    including policies for access control and visibility of these  
events (e.g.
    a pallet is broken down into boxes and each box has its own  
destination
    supply chain and access policy).
    Refer to 1.d above.

    c) Determine if multilayer information visibility is required  
(e.g. a query
    with limited access can be informed of the existence of  
information for a
    particular object, but to view the actual information, full access
    privileges would be required.
    The client may be provided with one of the following three kinds  
of visibility:
	i) no visibility - no awareness that the resource exists
	ii) awareness of existence of a resource, albeit via an opaque
	    non-revealing reference.  ( Like the NodeRef idea in the BRIDGE  
design)
	iii) URL referral data (and optionally also contextual metadata) that  
enables
	    it to connect to the resource if it chooses to do so.

    This has particular implications for peer-to-peer searching across  
multiple
    Discovery Services).

    In the case of peer-to-peer searching, the remote peer DS may  
provide one
    of the above responses (where the URL in iii) is the URL of the  
peer DS,
    rather than returning the URLs of the resources that the peer DS  
knows about.

    d) Determine if Discovery Services should facilitate an access  
negotiation
    process (e.g. a query client negotiates for access to information  
from an
    organization in the situation where the information-providing  
organization
    does not have an established business (trust) relationship with  
the client
    and therefore chooses initially not to reveal its identity to the  
client).

5.DS-DS Peer Communications Interface

    a) Define a protocol for inter-DS  querying.
        Initial draft of approach to DS federation
        1) Each DS holds an index of neighboring DSs (URLs) in its DS  
federation.
        2) A propagating-query is sent to a DS whose address is known  
by the client.
        This is hereafter referred to as the 'initiating DS'.
        3) The DS forwards the propagating-query to DSs listed in its  
index and
        waits for the replies. The DS also appends its DS index to the
        propagating-query, so that the same DS is not queried multiple  
times.
        4) Each DS that receives the propagating-query will perform  
step 3 on
        DSs which are not queried already.
        5) Each DS will review the propagating-query and decides  
whether it is
        interested in volunteering to receive the actual query.
        6) Each DS will wait until a specified deadline is passed for  
its
        federation neighbors to reply back.
        7) Once that period has passed, it will merge the received  
replies
        along with its own reply and send it back to the initiating DS.

Comment:  We need to be clear about whether a DS receiving the  
propagating query should reply to the DS that sent the propagating  
query to it (the previous DS) or whether it should reply directly to  
the initiating DS.  In step 7, we seem to be saying that some  
intermediate DS within the DS network will wait for replies from the  
DS nodes it contacted and then merge their responses together with its  
own response and reply directly back to the initiating DS.  However,  
if the DS nodes that it contacts adopt the same approach, then they  
respond directly to the initiating DS with their response, rather than  
to the previous DS that sent them the propagating query.  In that  
case, the previous DS might be waiting a very long time to receive a  
response from the DS nodes that it contacts - since they have replied  
direct to the initiating DS node instead of responding to the previous  
DS that propagated the query to it.  I think we need to be consistent  
here.  I'd suggest that each DS node adds its own ID to the list of DS  
that have already been contacted, replies direct to the initiating DS  
and forwards the propagating query to any of its contacts that do not  
already appear in the list of 'already contacted DS nodes'.  In this  
way, none of the intermediate nodes (other than the initiating DS  
node) need to wait for responses from the DS nodes that they contact -  
the burden of waiting for responses from other DS peers falls only on  
the initiating DS.

        8) The first DS will send back to the client a list of DSs  
(URLs)
        which have replied.
        Note: All above actions are voluntarily for any DS server. A  
server
        could provide discovery Services without opting into  
forwarding or
        replying to any propagating-queries.

    b) Architect a bootstrapping policy for objects while ensuring  
security and
    confidentiality (e.g. locating one or more Discovery Services for a
    product which is mis-delivered).

    c) Define a procedure for a Discovery Service server to join or  
leave a
    federation of Discovery Services. This could potentially involve  
some
    manual operations (e.g. physically validating identity of a DS  
operator).

Comment: this may also involve checks that the joining DS is using  
identifiers that are globally unambiguous within the federation into  
which it is joining or has a mechanism for translating its identifiers  
into a form that is globally unambiguous within the federation it is  
joining.
Note that I did not say globally unique because we may have a  
situation where two rival Discovery Services choose to co-operate  
within the same federation and a client has published records for the  
same identifier to both of them and both records refer to the same  
object.  i.e. maybe we need to explicitly say that this does not mean  
that the identifier ranges handled by the members of the DS federation  
must have no intersection or overlap - since that is allowed if  
referring to the same object.  What we are trying to ensure is that we  
avoid collisions of unqualified (locally-scoped) identifiers that are  
numerically or lexically identical but in fact refer to different  
objects.
_______________________________________________
ESDS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/esds