Subject: Re: [ESDS] Proposed Charter - update

From: Kary Främling <[email-masked]>
Date: Wed, 03 Sep 2008 16:52:26 +0300

Dear Ali,

I personally find your proposal well structured, clear and a good 
initiative to work on (as usually with your proposals on ESDS). It would 
require some more thought to allow me to provide any improvement 
proposals - but at least I think your initiative deserves a response! I 
am surprised that there hasn't been more reactions on the list about this?

The again, some quick comments:
- It would be good to separate the "charter" part more clearly from the 
"work item current status and summary" part; I didn't notice the 
separation straight away.
- From the charter, it is hard to see whether ESDS will provide 
discovery only of information sources or also access to the actual 
information. The same old question...

Best regards,

  Kary
> Dear ESDS members,
>
> We have had considerable progress on the Discovery Services protocol 
> discussions. I have summarized current status on some of the ESDS work 
> items and updated our charter. Our charter is modified to include 
> secure and restricted discovery for the broader Internet community.
>
> Please review and comment.
>
> Best Regards,
> Ali Rezafard
>
> ESDS Charter:
> ESDS has been chartered to architect and define a protocol for Discovery
> Services. Discovery Services at its core offers to authenticated and 
> authorized
> users the means to discover sources of information for a particular 
> object.
> Discovery Services can be implemented as a decentralized directory of 
> resources
> indexed by a shared identifier. Discovery Services need to be 
> deployable in
> both closed networks as well as open and global networks such as 
> Internet.
>
> ESDS will develop interfaces for users of Discovery Services as well 
> as an
> interface for peer-to-peer communication among Discovery Services. 
> ESDS will
> develop interfaces for publishing data, submitting onetime queries, and
> registering for standing queries.  ESDS should support utilization of 
> a trusted
> external identity management service for Authentication. ESDS should 
> enable
> configuration of Authorization and Access Control for publishing clients.
>
> 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 TTL)
>             URI of event publisher (who)
>         optional data fields:
>             Lifecycle step (why)
>             Event timestamp (client timestamp)
>             Change in identifier (aggregation, disaggregation, 
> relabeling)
>         example extensible data fields:
>             Where (bizLocation)
>             Transaction data (PO, AWB, Invoice)
>
>     Query response data fields:
>         required data fields:
>             URI object identifier (what)
>         optional data fields:
>             Publish timestamp (server timestamp)
>             Service list of URLs (links)
>             Event class (event type attributes, such as TTL)
>             URI of event publisher (who)
>             Lifecycle step (why)
>             Event timestamp (client timestamp)
>             Change in identifier (aggregation, disaggregation, 
> relabeling)
>         example extensible data fields:
>             Where (bizLocation)
>             Transaction data (PO,AWB,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.
>     http://www.ietf.org/mail-archive/web/esds/current/msg00114.html
>
>     b) Define a protocol for advertising/publishing data resources 
> (Resource
>     Discovery).
>
>     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).
>     a record that points to another DS (instead of an information 
> source) In
>     this case, the query client application may choose to make a 
> separate query
>     to the other DS, not necessarily involving 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. This has particular implications for
>     peer-to-peer searching across multiple Discovery Services).
>
>     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.
>         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.
>         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).
>
>
>
> On 5-Feb-08, at 6:40PM, Ali Rezafard wrote:
>
>> Dear ESDS group,
>>
>> Thanks for your responses to the initial proposed charter. Attached 
>> is the updated charter based on your feedback and comments by IAB and 
>> IESG. Please review and comment.
>>
>> Best Regards,
>> Ali Rezafard
>>
>> Extensible Supply-chain Discovery Service (ESDS)
>>
>> Chair(s):
>>    Mark Harrison <mark.harrison at cantab.net>
>> Applications Area Director(s):
>>    Lisa Dusseault <lisa at osafoundation.org>
>>    Chris Newman <chris.newman at sun.com>
>> Applications Area Advisor:
>>    Lisa Dusseault <lisa at osafoundation.org>
>> Mailing List(s):
>>    esds at ietf.org
>> General information about the mailing list is at:
>>    https://www1.ietf.org/mailman/listinfo/esds
>>
>> Purpose of Working Group:
>> The use of Supply chain Tracking Systems is rising at an 
>> unprecedented rate,
>> particularly as various industry sectors are increasingly adopting 
>> automatic
>> identification technologies such as Radio-Frequency Identification 
>> (RFID) to
>> automatically track individual physical objects as they move through 
>> a supply
>> chain.  Rather than tracking at batch or lot level, the ultimate goal 
>> of this
>> technology is that each individual physical object will have its own 
>> unique
>> ID, which can be used to gather and retrieve complete lifecycle 
>> information
>> about the object, which is fragmented across the supply chain. 
>> Deployment of
>> these systems has grown to a point where they can no longer operate
>> effectively in isolation from other systems.  There is a need to 
>> share data
>> among these disparate systems, which are owned and operated by separate
>> organizations.
>>
>> ESDS has been chartered to architect and define the protocol of a 
>> Discovery
>> Service for global supply chains. ESDS's goal is to enable searching for
>> information on physical objects flowing in a supply chain, by 
>> authorized and
>> authenticated users.  Economic and technical factors dictate that 
>> Discovery
>> Services and their protocol ESDS must be designed for deployment on the
>> Internet. Access control, data protection and security are of utmost
>> importance, due to sensitivity and value of the information generated 
>> by the
>> supply chain.
>>
>> Work Items:
>> The work group will address to the following work items:
>> 1.Initial Conventions
>>    a)Define common vocabulary and terminology
>>    b)Define core data sets for sharing on Discovery Service, including
>>    required data fields, optional data fields, and extensible data 
>> fields
>>    (e.g. who, what, when, where, why, links, identifier, lifecycle, 
>> class,
>>    etc.)
>>    c)Define handling for time zones (e.g. accepting only UTC 
>> timestamps vs.
>>    accepting timestamps with any timezone)
>> 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)
>>    c)Define a common interface and roles for access control 
>> configuration
>>    (e.g. supply chain, partner, user )
>> 3.Publishing Interface
>>    a)Define mechanism for uniquely identifying objects in a supply chain
>>    without requiring a global unique identifier for each and all 
>> objects that
>>    enter a supply chain
>>    b)Define a protocol for advertising/publishing data resources 
>> (Resource
>>    Discovery)
>>    c)Define a protocol and policy for retracting or voiding published 
>> data
>>    d)Define policies for updating stale and broken links (e.g. for 
>> records
>>    with a long retention period, it is vital that links can be 
>> updated, when
>>    required)
>> 4.Query Interface
>>    a)Define a protocol for querying published data, facilitating 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)
>>    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. This has particular implications for
>>    peer-to-peer searching across multiple Discovery Services)
>> 5.DS-DS Peer Communications Interface
>>    a)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)
>>    b)Define a peer-to-peer protocol 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)
>>    c)Determine if Discovery Services should facilitate peer-to-peer 
>> 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)
>>
>> Goals and Milestones:
>> Done            Submit a draft problem statement
>> April 2008      Submit a document outlining the Initial Conventions
>> July 2008       Submit a draft on requirements for Security
>> September 2008  Submit a draft requirements for Publishing Interface
>> November 2008   Submit a draft proposed protocol for Publishing 
>> Interface
>> January 2008    Submit a draft on requirements for Query Interface
>> March 2009      Submit a draft proposed protocol for Query Interface
>> May 2009        Submit a draft on requirements for DS-DS peer 
>> Communications Interface
>> July 2009       Submit a draft proposed protocol for DS-DS peer 
>> Communications Interface
>>
>> Current Internet-Drafts:
>> http://www.ietf.org/internet-drafts/draft-rezafard-esds-problem-statement-00.txt 
>>
>> http://www.ietf.org/internet-drafts/draft-young-esds-concepts-03.txt
>> http://www.ietf.org/internet-drafts/draft-thompson-esds-commands-02.txt
>> http://www.ietf.org/internet-drafts/draft-thompson-esds-schema-02.txt
>>
>> Further Background Reading:
>> BRIDGE project - Requirements for Discovery Services
>> http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20Serial%20level%20lookup%20Requirements.pdf 
>>
>>
>> BRIDGE project - high-level design for Discovery Services
>> http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20High%20level%20design%20Discovery%20Services.pdf 
>>
>> _______________________________________________
>> ESDS mailing list
>> [email-masked]
>> http://www.ietf.org/mailman/listinfo/esds
>
> _______________________________________________
> ESDS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/esds

_______________________________________________
ESDS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/esds

---

From: Ali Rezafard <[email-masked]>
Date: Thu, 4 Sep 2008 17:44:20 -0400

Dear Kary,

Thank you very much for your support and suggestions. I am going to  
start a separate thread to review the clarified charter with the group.

Best Regards,
Ali

On 3-Sep-08, at 9:52AM, Kary Främling wrote:

> initiative to work on (as usually with your proposals on ESDS). It  
> would require some more thought to allow me to provide any  
> improvement proposals - but at least I think your initiative  
> deserves a response! I am surprised that there hasn't been more  
> reactions on the list about this?
>
> - It would be good to separate the "charter" part more clearly from  
> the "work item current status and summary" part; I didn't notice the  
>> We have had considerable progress on the Discovery Services  
>> protocol discussions. I have summarized current status on some of  
>> the ESDS work items and updated our charter. Our charter is  
>> modified to include secure and restricted discovery for the broader  
>> Internet community.
>>
>> Services. Discovery Services at its core offers to authenticated  
>> and authorized
>> Discovery Services can be implemented as a decentralized directory  
>> of resources
>> ESDS will develop interfaces for users of Discovery Services as  
>> well as an
>> registering for standing queries.  ESDS should support utilization  
>> of a trusted
>> external identity management service for Authentication. ESDS  
>> should enable
>>    d) Define handling for Aggregation, Disaggregation, and  
>> Relabeling events.
>>    These events are useful for expressing when it may be necessary  
>> to track
>>    a) Considerations for access control policies and their impact  
>> on Work
>>    Items 3 and 4.
>>
>>    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
>>    requiring a global unique identifier for each and all objects  
>> that enter a
>>    to make the identifier globally unique prefix it with a  
>> registered domain
>>    name.
>>    e) Define a mechanism to enable linking Discovery Service  
>> servers together
>>    to the other DS, not necessarily involving any involvement of  
>> the original
>>    process (e.g. a query client negotiates for access to  
>> information from an
>>    and therefore chooses initially not to reveal its identity to  
>> the client).
>>
>>        1) Each DS holds an index of neighboring DSs (URLs) in its  
>> DS federation.
>>        3) The DS forwards the propagating-query to DSs listed in  
>> its index and
>>        propagating-query, so that the same DS is not queried  
>> multiple times.
>>> Thanks for your responses to the initial proposed charter.  
>>> Attached is the updated charter based on your feedback and  
>>> comments by IAB and IESG. Please review and comment.
>>>
>>> Best Regards,
>>> Ali Rezafard
>>>
>>> automatically track individual physical objects as they move  
>>> through a supply
>>> chain.  Rather than tracking at batch or lot level, the ultimate  
>>> goal of this
>>> technology is that each individual physical object will have its  
>>> own unique
>>> importance, due to sensitivity and value of the information  
>>> generated by the
>>> supply chain.
>>>
>>> Work Items:
>>>   c)Define a protocol and policy for retracting or voiding  
>>> published data
>>>   c)Determine if multilayer information visibility is required  
>>> (e.g. a query

---

From: Kary Främling <[email-masked]>
Date: Mon, 08 Sep 2008 16:34:02 +0300

Dear Mark,

I agree with you completely.

The wording in the current charter that I reacted to was "develop 
interfaces for publishing data, submitting onetime queries, and 
registering for standing queries". Maybe it should be changed into 
"develop interfaces for publishing available data sources, submitting 
onetime queries for such sources, and registering for standing queries 
to changes in available data sources"? Is this what is actually intended?

And should we change "data sources" into "information sources" according 
to your message? I would personally vote for "information sources".

Hmmm, discussing small details like this may seem a bit irrelevant - but 
then again, a charter has to be short, exact and unambiguous.

Best regards,

   Kary
> Dear Kary,
>
> In response to your question about the role of ESDS, my understanding 
> is that it serves to provide referrals to information resources (e.g. 
> by providing authorized authenticated clients with a list of URLs of 
> resources relevant for a particular ID or keyword (and perhaps some 
> helpful contextual metadata to enable the clients to intelligently 
> choose which of those resources to contact).
>
> I do not consider that it is the responsibility of ESDS to actually 
> retrieve the information from the underlying resources.  That role is 
> the responsibility of a separate client application, similar to what 
> David Potter has called a 'Consolidated Information Broker', or to the 
> 'Event Gathering Layer' in the track and trace application that has 
> been developed in work package 3 of the BRIDGE project.
>
> Such client applications may interface with Discovery Services and 
> with the underlying resources (including EPC Information Services 
> (EPCIS)) in order to retrieve complete event information from multiple 
> resources - but I don't feel that it is the role of a Discovery 
> Service itself to perform this retrieval or to provide a 
> 'one-stop-shop' for gathering complete detailed lifecycle information 
> for an object.  In my view, a Discovery Service is only a referral 
> system that acts as an enabler for such applications.
>
> Best regards,
>
> - Mark
>
>
> On 3 Sep 2008, at 14:52, Kary Främling wrote:
>
>> Dear Ali,
>>

---

From: Mark Harrison <[email-masked]>
Date: Mon, 8 Sep 2008 13:13:53 +0100

Dear Kary,

Such client applications may interface with Discovery Services and  
with the underlying resources (including EPC Information Services  
(EPCIS)) in order to retrieve complete event information from multiple  
resources - but I don't feel that it is the role of a Discovery  
Service itself to perform this retrieval or to provide a 'one-stop- 
shop' for gathering complete detailed lifecycle information for an  
object.  In my view, a Discovery Service is only a referral system  
that acts as an enabler for such applications.

Best regards,

- Mark

On 3 Sep 2008, at 14:52, Kary Främling wrote:

> would
> the
>>> goal
>>> generated

---

From: Mark Harrison <[email-masked]>
Date: Mon, 8 Sep 2008 16:38:17 +0100

Dear Kary,

I like your suggestion to modify the wording to say  "develop  
interfaces for publishing available data sources, submitting one-time  
queries for such sources, and registering for standing queries to  
changes in available data sources".

However regarding standing queries, I think that in the context of a  
Discovery Service, the purpose of a standing query with a DS is to  
inform the client of changes in the availability of data sources  
(primarily when additional data sources register that they hold  
information for a particular ID), rather than informing the client  
that an existing data source for an ID has recorded additional data  
internally within its own database.

I also prefer 'information resource' to 'data source', since it is  
more likely that organisations may wish to exchange information rather  
than raw data.

I would therefore suggest fine-tuning the wording further to say,

"develop interfaces for:
i) publishing the address of available information resources [for a  
particular ID of an object of interest],
ii) submitting one-time queries for retrieving the addresses of such  
resources, and
iii) registering for standing queries, whose responses inform the  
client of addresses of any additional information resources that  
publish a record to a DS at a future time for the particular ID of an  
object of interest ",

Perhaps we also need a footnote that when we talk about 'publishing'  
or 'available', this does not imply that the information resources or  
their addresses are available to all or publicly known - the  
availability of a particular information resource might only be made  
available to a restricted set of authorized clients.

Best regards,

- Mark

On 8 Sep 2008, at 14:34, Kary Främling wrote:

> "develop interfaces for publishing available data sources,  
> submitting onetime queries for such sources, and registering for  
> standing queries to changes in available data sources"? Is this what  
> is actually intended?
>
> And should we change "data sources" into "information sources"  
> according to your message? I would personally vote for "information  
> sources".
>
> Hmmm, discussing small details like this may seem a bit irrelevant -  
> but then again, a charter has to be short, exact and unambiguous.
>
> Best regards,
>
>  Kary
>> Dear Kary,
>>
>> In response to your question about the role of ESDS, my  
>> understanding is that it serves to provide referrals to information  
>> resources (e.g. by providing authorized authenticated clients with  
>> a list of URLs of resources relevant for a particular ID or keyword  
>> (and perhaps some helpful contextual metadata to enable the clients  
>> to intelligently choose which of those resources to contact).
>>
>> retrieve the information from the underlying resources.  That role  
>> is the responsibility of a separate client application, similar to  
>> what David Potter has called a 'Consolidated Information Broker',  
>> or to the 'Event Gathering Layer' in the track and trace  
>> application that has been developed in work package 3 of the BRIDGE  
>> project.
>>
>> (EPCIS)) in order to retrieve complete event information from  
>> multiple resources - but I don't feel that it is the role of a  
>> Discovery Service itself to perform this retrieval or to provide a  
>> 'one-stop-shop' for gathering complete detailed lifecycle  
>> information for an object.  In my view, a Discovery Service is only  
>> a referral system that acts as an enabler for such applications.
>>
>> Best regards,
>>
>> - Mark
>>
>>
>>>> protocol
>>>> and
>>>> well
>>>> should
>>>> Relabeling
>>>> to
>>>> that
>>>> registered
>>>> multiple
>>>>> Attached
>>>>> through
>>>>> own
>>>>> published
>>>>> (e.g.

---

From: Kary Främling <[email-masked]>
Date: Tue, 09 Sep 2008 11:14:21 +0300

Dear Mark,

For standing queries, I had the same thing in mind as you but didn't get 
the wording unambiguous enough. Still, in the proposed point iii), we 
would need to make a difference between the addition, deletion and 
modification of DS records (rather than just addressing addition of new 
URLs to a record).

Therefore, my proposal for a modified point iii):
"iii) registering for standing queries, whose responses inform the 
client of addition, deletion or modification of DS records at a future 
time for a particular ID or group of IDs of an object or objects of 
interest."

We would then deal with both 1) additions of information resources as 
new DS records or new URLs added to existing ones and 2) deletion of 
information resources either by deletion of DS record or deletion of URL 
from DS records. This way we could actually deal with any modifications 
to DS records, not only modifications to the list of URLs.

Case number 1) is probably the more interesting one. Let's imagine a 
vehicle scenario where the initial DS record for the vehicle (or class 
of vehicles?) would be created by the manufacturer. When a concerned 
vehicle has been maintained by a new company, which then becomes a new 
information source, the corresponding information resource URL would be 
added to the DS record for that vehicle. Someone who has a standing 
query to receive updates to DS records about the vehicle should receive 
a notification in both cases. The notification would mainly include "DS 
identifier+DS record identifier+event type classifier", which then 
allows the receiver to retrieve the new information with functionality 
ii) "one-time query". The advantage of not including the modified record 
in the notification itself is to reduce network traffic - there might be 
a great number of "unnecessary" notifications being sent so it is best 
to keep their payload low.

Best regards,

   Kary

>> onetime queries for such sources, and registering for standing 
>> queries to changes in available data sources"? Is this what is 
>> actually intended?
>>
>>> resources (e.g. by providing authorized authenticated clients with a 
>>> list of URLs of resources relevant for a particular ID or keyword 
>>> what David Potter has called a 'Consolidated Information Broker', or 
>>> to the 'Event Gathering Layer' in the track and trace application 
>>> that has been developed in work package 3 of the BRIDGE project.
>>>

---

From: Mark Harrison <[email-masked]>
Date: Tue, 9 Sep 2008 12:23:22 +0100

Dear Kary,

Many thanks for the further refinement on this.  I agree with your  
modified proposal and that we should include also deletion or  
modification of DS records.

I think it's important to be clear that for a standing query to a DS,  
the client can expect to be notified about additional / changed /  
deleted DS records - but that their standing query will not result in  
them receiving notifications from the DS about changes to the detailed  
data within each resource, such as additional observation events  
captured within each information resource unless the resource  
explicitly registers a new or modified record to the DS with which the  
client has registered their standing query.  If the client needs to be  
notified about changes to the detailed data within the referenced  
resources, then the client would need to make a separate standing  
query directly to those particular resources.  For example, the EPC  
Information Services (EPCIS) standard from the EPCglobal community  
allows an EPCIS information resource to support both one-time queries  
as well as standing queries (a.k.a. subscription-based queries).

Just a few comments about the vehicle scenario you describe below:

Where you say that for 'a new information source, the corresponding  
information resource URL would be added to the DS record for that  
vehicle', I would suggest that we re-phrase this slightly to say,
' a new information source, the corresponding information resource URL  
would be included within a new additional DS record for that vehicle,  
which the resource owner publishes to the DS'

I consider that it will not generally be possible for the owner of an  
information resource to append any existing DS records that were  
created by a different resource owner for the following reasons:
1) Each owner of an information resource may wish to publish or revoke  
(void or delete) any record that they previously published to a  
Discovery Service, independently of any related DS records (i.e. for  
the same ID) that were posted by other information resource owners.
2) Each information resource might choose (or be required) to  
digitally sign the records that they post to a Discovery Service,  
independently of any related DS records (i.e. for the same ID) that  
were posted by other information resource owners..
3) A DS might only released to a query client selected fields such as  
URLs and some limited metadata), rather than releasing the entire DS  
record that it received.

I therefore think of the list of URL referrals for a particular object  
as being extracted from a collection of related DS records, (each  
posted independently by an individual resource owner, but all  
including the ID of the object) rather than being a single internal  
record within the DS, which is incrementally appended with URLs as new  
information resource publish to the DS for that ID.

Regarding the one-time query as a follow-up, when the client receives  
a notification of the additional URL address(es) in response to the  
standing query, the client can then make a one-time query directed at  
the address of the additional information resource, in order to gather  
the detailed information from that resource, since the detailed  
information would not be replicated within a Discovery Service.  I  
hope that is what you meant to say with 'one-time query' - but I think  
we have to make it very clear that the one-time query is a follow-up  
query that is directed at the newly discovered resource, rather than  
to the Discovery Service itself.

I think this is consistent with the aim of reducing network traffic -  
and also with minimizing the amount of data that needs to be stored  
within a Discovery Service, (which should help the DS to be more  
responsive and also allow the resource owners to retain greater  
control over the detailed information that is only held within their  
own resources.)

Best regards,

- Mark

On 9 Sep 2008, at 09:14, Kary Främling wrote:

> Dear Mark,
>
> For standing queries, I had the same thing in mind as you but didn't  
> get the wording unambiguous enough. Still, in the proposed point  
> iii), we would need to make a difference between the addition,  
> deletion and modification of DS records (rather than just addressing  
> addition of new URLs to a record).
>
> client of addition, deletion or modification of DS records at a  
> future time for a particular ID or group of IDs of an object or  
> objects of interest."
>
> We would then deal with both 1) additions of information resources  
> as new DS records or new URLs added to existing ones and 2) deletion  
> of information resources either by deletion of DS record or deletion  
> of URL from DS records. This way we could actually deal with any  
> modifications to DS records, not only modifications to the list of  
> URLs.
>
> vehicle scenario where the initial DS record for the vehicle (or  
> class of vehicles?) would be created by the manufacturer. When a  
> concerned vehicle has been maintained by a new company, which then  
> becomes a new information source, the corresponding information  
> resource URL would be added to the DS record for that vehicle.  
> Someone who has a standing query to receive updates to DS records  
> about the vehicle should receive a notification in both cases. The  
> notification would mainly include "DS identifier+DS record identifier 
> +event type classifier", which then allows the receiver to retrieve  
> the new information with functionality ii) "one-time query". The  
> advantage of not including the modified record in the notification  
> itself is to reduce network traffic - there might be a great number  
> of "unnecessary" notifications being sent so it is best to keep  
> their payload low.
>
> Best regards,
>
>  Kary
>
>> Dear Kary,
>>
>> interfaces for publishing available data sources, submitting one- 
>> time queries for such sources, and registering for standing queries  
>> to changes in available data sources".
>>
>> However regarding standing queries, I think that in the context of  
>> a Discovery Service, the purpose of a standing query with a DS is  
>> to inform the client of changes in the availability of data sources  
>> more likely that organisations may wish to exchange information  
>> rather than raw data.
>>
>> ii) submitting one-time queries for retrieving the addresses of  
>> such resources, and
>> publish a record to a DS at a future time for the particular ID of  
>> an object of interest ",
>>
>> Perhaps we also need a footnote that when we talk about  
>> 'publishing' or 'available', this does not imply that the  
>> information resources or their addresses are available to all or  
>> publicly known - the availability of a particular information  
>> resource might only be made available to a restricted set of  
>> authorized clients.
>>
>> Best regards,
>>
>> - Mark
>>
>>
>>
>>
>>> standing queries to changes in available data sources"? Is this  
>>> what is actually intended?
>>>
>>> according to your message? I would personally vote for  
>>> "information sources".
>>>
>>> Hmmm, discussing small details like this may seem a bit irrelevant  
>>> - but then again, a charter has to be short, exact and unambiguous.
>>>
>>> Best regards,
>>>
>>> Kary
>>>> Dear Kary,
>>>>
>>>> understanding is that it serves to provide referrals to  
>>>> information resources (e.g. by providing authorized authenticated  
>>>> clients with a list of URLs of resources relevant for a  
>>>> particular ID or keyword (and perhaps some helpful contextual  
>>>> metadata to enable the clients to intelligently choose which of  
>>>> those resources to contact).
>>>>
>>>> I do not consider that it is the responsibility of ESDS to  
>>>> actually retrieve the information from the underlying resources.   
>>>> That role is the responsibility of a separate client application,  
>>>> similar to what David Potter has called a 'Consolidated  
>>>> Information Broker', or to the 'Event Gathering Layer' in the  
>>>> track and trace application that has been developed in work  
>>>> package 3 of the BRIDGE project.
>>>>
>>>> Such client applications may interface with Discovery Services  
>>>> and with the underlying resources (including EPC Information  
>>>> Services (EPCIS)) in order to retrieve complete event information  
>>>> from multiple resources - but I don't feel that it is the role of  
>>>> a Discovery Service itself to perform this retrieval or to  
>>>> provide a 'one-stop-shop' for gathering complete detailed  
>>>> lifecycle information for an object.  In my view, a Discovery  
>>>> Service is only a referral system that acts as an enabler for  
>>>> such applications.
>>>>
>>>> Best regards,
>>>>
>>>> - Mark
>>>>
>>>>
>>>>>> on
>>>>>> was
>>>>>> it
>>>>>> servers
>>>>>> DS
>>>>>> its