Re: [alto] fci alto transport design discussion

[Kevin Ma J <[e-mail]>]

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:[e-mail]]
Sent: Monday, July 03, 2017 8:57 AM
To: Y. Richard Yang <[e-mail]>; Jon Peterson <[e-mail]>; Kevin Ma J <[e-mail]>; [e-mail]; IETF ALTO <[e-mail]>
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

On 03.07.17 13:59, Y. Richard Yang wrote:
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




--

****************************

Prof. Dr. Jan Seedorf

[e-mail]<mailto:[e-mail]>

****************************

Hochschule für Technik Stuttgart

Fakultät Vermessung, Informatik und Mathematik

Schellingstr. 24

D-70174 Stuttgart

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

****************************