Subject: [CDNi] fci alto transport design discussion

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 3 Jul 2017 19:59:02 +0800

Hi Jan, Jon, Kevin, all,

As we are working on the design, a key issue that we are trying to
understand is the conflict resolution of the capabilities in the
"capabilities" list [RFC8008]. Consider

   {
     "capabilities": [
       {
         "capability-type": "FCI.DeliveryProtocol",
         "capability-value": {
           "delivery-protocols": [
             "http/1.1",
           ]
         },
         "footprints": [
           <Footprint objects 1>
         ]
       },
       {
         "capability-type": "FCI.DeliveryProtocol",
         "capability-value": {
           "delivery-protocols": [
             "http/1.0",
           ]
         },
         "footprints": [
           <Footprint objects 2>
         ]
       }

     ]
   }

What if the footprints in the two entries have overlap? I see two options:
(1) Enforce that each capability-type has a single entry; that is, make
capability-type a key;
(2) Allow multiple entries with the same capability-type, and the search is
ordered by the array; that is, the result is the first matching footprints.

I assume that (2) is more flexible. An issue, however, is that it
makes incremental updates harder. In other words, this issue will determine
whether we should integrate JSON Patch. The current alto incremental
updates, based on SSE and JSON Merge Patch, is pretty useful. The FCI use
case may argue that we extend the incremental update w/ JSON Patch, to
better handle arrays, right away.

Any clarification, comments and suggestions will be great.

Richard

---

From: Jan Seedorf <[email-masked]>
Date: Mon, 3 Jul 2017 14:56:38 +0200

Hi Richard and all,

looking at RFC8008, its states that "FCI objects are composed of a 
dictionary of (key,value) pairs where the keys are the property names 
and the values are the associated property values.", meaning that the 
"capability-value" is a key. However, I did not find anything on 
multiple "capability-type" entries, and what to do when they are 
conflicting. From a CDNI perspective, it should certainly be possible to 
have something like in your example below: support http1.1 for footprint 
a and support http1.0 for footprint b.

I am for option 2) below, that is allow multiple entries with the same 
capability type.

> The FCI use case may argue that we extend the incremental update w/ 
> JSON Patch, to better handle arrays, right away.
Indeed. Do you want to choose one of the two (JSON Patch vs. JSON Merge 
Patch) or do you think of making JSON Merge Patch mandatory and JSON 
Patch optional and then we say in the ALTO FCI service specification 
that this one demands JSON Patch (as pecified in the ALTO incr. updates)?

  - Jan

On 03.07.17 13:59, Y. Richard Yang wrote:
> (1) Enforce that each capability-type has a single entry; that is, 
> make capability-type a key;
> (2) Allow multiple entries with the same capability-type, and the 
> search is ordered by the array; that is, the result is the first 
> matching footprints.
>
> makes incremental updates harder. In other words, this issue will 
> determine whether we should integrate JSON Patch. The current alto 
> incremental updates, based on SSE and JSON Merge Patch, is pretty 
> useful. The FCI use case may argue that we extend the incremental 
> update w/ JSON Patch, to better handle arrays, right away.
>

-- 
****************************
Prof. Dr. Jan Seedorf
[email-masked]
****************************
Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de
****************************

---

From: Kevin Ma J <[email-masked]>
Date: Mon, 3 Jul 2017 16:59:43 +0000

Hi All,

  (as an individual/author) I agree that the functionality described would be useful, i.e., being able to specify different footprints for different capability-values associated with a given capability-type.  This was more explicitly laid out in draft-ma-cdni-capabilities, but did not all come over into RFC8008.  The delivery protocol example in [1] shows http and https being supported across different footprints, just as Richard showed.  The first part of the last paragraph of [2] describes the intended restriction on duplicate capability-values (ignoring the typo where it says "footprint-value" and should just say "values"); though this is describing a "response", it maintains the same rational wrt restrictions on creating the json objects:

   Multiple FCIMapData objects with the same capability type are allowed
   within a given CDNI FCI Map response as long as the capability option
   [values] do not overlap, i.e., a given capability option value
   MUST NOT show up in multiple FCIMapData objects within a single CDNI
   FCI Map response.

[1] https://tools.ietf.org/html/draft-ma-cdni-capabilities-09#section-3.1.7.1
[2] https://tools.ietf.org/html/draft-ma-cdni-capabilities-09#section-3.1.6

thanx.

--  Kevin J. Ma

From: Jan Seedorf [mailto:[email-masked]]
Sent: Monday, July 03, 2017 8:57 AM
To: Y. Richard Yang <[email-masked]>; Jon Peterson <[email-masked]>; Kevin Ma J <[email-masked]>; [email-masked]; IETF ALTO <[email-masked]>
Subject: Re: fci alto transport design discussion

Hi Richard and all,

looking at RFC8008, its states that "FCI objects are composed of a dictionary of (key,value) pairs where the keys are the property names and the values are the associated property values.", meaning that the "capability-value" is a key. However, I did not find anything on multiple "capability-type" entries, and what to do when they are conflicting. From a CDNI perspective, it should certainly be possible to have something like in your example below: support http1.1 for footprint a and support http1.0 for footprint b.

I am for option 2) below, that is allow multiple entries with the same capability type.
The FCI use case may argue that we extend the incremental update w/ JSON Patch, to better handle arrays, right away.
Indeed. Do you want to choose one of the two (JSON Patch vs. JSON Merge Patch) or do you think of making JSON Merge Patch mandatory and JSON Patch optional and then we say in the ALTO FCI service specification that this one demands JSON Patch (as pecified in the ALTO incr. updates)?

 - Jan

As we are working on the design, a key issue that we are trying to understand is the conflict resolution of the capabilities in the "capabilities" list [RFC8008]. Consider
   {
     "capabilities": [
       {
         "capability-type": "FCI.DeliveryProtocol",
         "capability-value": {
           "delivery-protocols": [
             "http/1.1",
           ]
         },
         "footprints": [
           <Footprint objects 1>
         ]
       },
       {
         "capability-type": "FCI.DeliveryProtocol",
         "capability-value": {
           "delivery-protocols": [
             "http/1.0",
           ]
         },
         "footprints": [
           <Footprint objects 2>
         ]
       }

     ]
   }

What if the footprints in the two entries have overlap? I see two options:
(1) Enforce that each capability-type has a single entry; that is, make capability-type a key;
(2) Allow multiple entries with the same capability-type, and the search is ordered by the array; that is, the result is the first matching footprints.

I assume that (2) is more flexible. An issue, however, is that it makes incremental updates harder. In other words, this issue will determine whether we should integrate JSON Patch. The current alto incremental updates, based on SSE and JSON Merge Patch, is pretty useful. The FCI use case may argue that we extend the incremental update w/ JSON Patch, to better handle arrays, right away.

Richard

--

Prof. Dr. Jan Seedorf

[email-masked]<mailto:[email-masked]>

Schellingstr. 24

D-70174 Stuttgart

www.hft-stuttgart.de<http://www.hft-stuttgart.de>