Re: [alto] Suresh Krishnan's No Objection on draft-ietf-alto-incr-update-sse-20: (with COMMENT)

["Y. Richard Yang" <[e-mail]>]

- add Adam explicitly.

Hi Jensen,

Not sure by loose dependency, what you meant. The current approach is to
revise the current document to include key features/notes of the algorithm.
We will plan to use the change below:

Old


   To avoid always sending complete data, a server needs mechanisms to
   encode incremental changes.  This design uses JSON merge patch as one
   mechanism.  Below is a non-normative summary of JSON merge patch; see
   [RFC7396 <https://tools.ietf.org/html/rfc7396>] for the normative definition.

   JSON merge patch is intended to allow applications to update server
   resources via the HTTP patch method [RFC5789
<https://tools.ietf.org/html/rfc5789>].  This document adopts

   the JSON merge patch message format to encode incremental changes,
   but uses a different transport mechanism.

   Informally, a JSON merge patch object is a JSON data structure that
   defines how to transform one JSON value into another.  Specifically,
   JSON merge patch treats the two JSON values as trees of nested JSON
   objects (dictionaries of name-value pairs), where the leaves are
   values (e.g., JSON arrays, strings, numbers) other than JSON objects
   and the path for each leaf is the sequence of keys leading to that
   leaf.  When the second tree has a different value for a leaf at a
   path, or adds a new leaf, the JSON merge patch tree has a leaf, at
   that path, with the new value.  When a leaf in the first tree does
   not exist in the second tree, the JSON merge patch tree has a leaf
   with a JSON "null" value.  The JSON merge patch tree does not have an
   entry for any leaf that has the same value in both versions.

   As a result, if all leaf values are simple scalars, JSON merge patch
   is a quite efficient representation of incremental changes.  It is
   less efficient when leaf values are arrays, because JSON merge patch
   replaces arrays in their entirety, even if only one entry changes.

   Formally, the process of applying a JSON merge patch is defined by
   the following recursive algorithm, as specified in [RFC7396
<https://tools.ietf.org/html/rfc7396>]:

     define MergePatch(Target, Patch) {
       if Patch is an Object {
         if Target is not an Object {
           Target = {} # Ignore the contents and
                       # set it to an empty Object
         }
         for each Name/Value pair in Patch {
           if Value is null {
             if Name exists in Target {
               remove the Name/Value pair from Target
             }
           } else {
             Target[Name] = MergePatch(Target[Name], Value)
           }
         }
         return Target
       } else {
         return Patch
       }
     }

   Note that null as the value of a name/value pair will delete the
   element with "name" in the original JSON value.



New

   To avoid always sending complete data, a server needs mechanisms to
   encode incremental changes.  This design uses JSON merge patch as one
   mechanism.  Below is a non-normative summary of JSON merge patch; see
   [RFC7396 <https://tools.ietf.org/html/rfc7396>] for the normative definition.

   JSON merge patch is intended to allow applications to update server
   resources via the HTTP patch method [RFC5789
<https://tools.ietf.org/html/rfc5789>].  This document adopts

   the JSON merge patch message format to encode incremental changes,
   but uses a different transport mechanism.

   Informally, a JSON merge patch message consists of a JSON merge patch
   object (referred to as a patch in [RFC7396]), which defines
   how to transform one JSON value into another using a recursive
   merge patch algorithm.
   Specifically, the patch is computed by treating two JSON values (first one
   being the original, and the second being the updated) as trees
   of nested JSON objects (dictionaries of name-value pairs), where the
   leaves are values (e.g., JSON arrays, strings, numbers) other than
   JSON objects and the path for each leaf is the sequence of keys leading
   to that leaf.  When the second tree has a different value for a leaf at a

   path, or adds a new leaf, the patch has a leaf, at
   that path, with the new value.  When a leaf in the first tree does
   not exist in the second tree, the JSON merge patch tree has a leaf
   with a JSON "null" value. Hence, in the patch, null as the value of
   a name/value pair will delete the element with "name" in the original
   JSON value. The patch does not have an entry for any leaf that has the same
   value in both versions. See the MergePatch pseudocode

   at the beginning of Section 2 of [RFC7396] for the formal specification of
   how to apply a given patch.

   As a result, if all leaf values are simple scalars, JSON merge patch
   is a quite efficient representation of incremental changes.  It is
   less efficient when leaf values are arrays, because JSON merge patch
   replaces arrays in their entirety, even if only one entry changes.


====

If there is an objection, please do let us know.

Thanks,
Richard

On Thu, Mar 12, 2020 at 11:30 AM Jensen Zhang <[e-mail]>
wrote:

> Hi Suresh, Mirja and Richard,
>
> To make the content consistent, I agree that we should not duplicate the
> formal specification. But I don't think it should be a loose dependency.
> Personally, I think we should strictly refer to RFC7396, even though it
> could be updated or obsoleted. If it is a loose dependency, an ALTO client
> adopting the old specification may not be compatible with the ALTO server
> adopting the new specification. We should make sure all the clients/servers
> based on this document are compatible in any case. If RFC7396 is updated or
> obsoleted in the future, we can also update this document.
>
> Jensen
>
>
> On Thu, Mar 12, 2020 at 6:23 AM Mirja Kuehlewind <[e-mail]>
> wrote:
>
>> Hi Richard,
>>
>> The concern is that RFC7396 could be updated by another RFC or even
>> obsoleted. Therefore duplicating any formal specification should be avoided
>> and it’s actually a feature that people have to look up RFC7396. I
>> recommend to remove the pseudo code and replace it by a few sentences that
>> loosely described the scheme.
>>
>> Mirja
>>
>>
>>
>> > On 11. Mar 2020, at 21:49, Y. Richard Yang <[e-mail]> wrote:
>> >
>> > Dear Suresh,
>> >
>> > Thanks for the review! Please see inline.
>> >
>> > On Wed, Mar 11, 2020 at 12:20 PM Suresh Krishnan via Datatracker <
>> [e-mail]> wrote:
>> > Suresh Krishnan has entered the following ballot position for
>> > draft-ietf-alto-incr-update-sse-20: No Objection
>> >
>> > When responding, please keep the subject line intact and reply to all
>> > email addresses included in the To and CC lines. (Feel free to cut this
>> > introductory paragraph, however.)
>> >
>> >
>> > Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> > for more information about IESG DISCUSS and COMMENT positions.
>> >
>> >
>> > The document, along with other ballot positions, can be found here:
>> > https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/
>> >
>> >
>> >
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> > Section 3.1.1.:
>> >   I feel strongly that this document should not restate the pseudo-code
>> for the
>> >   JSON merge patch algorithm and should instead use a reference to
>> Section 2 of
>> >   RFC7396 instead. This will avoid inconsistencies (e.g. note that the
>> pseudo
>> >   code in this draft is *already different* from that in RFC7396 even
>> though
>> >   the difference is only the braces) and be amenable to updates to
>> RFC7396.
>> >
>> >
>> > This is an interesting discussion point. In an earlier version, the
>> authors had some back-and-forth on including the pseudo-code or not. The
>> "include" argument "won" because it makes the document more self-contained
>> and a potentially more pleasant read---a reader does not need to track down
>> a separate document to find the pseudo-code, and we are referring to a
>> "fixed" document---I can see your argument that there can be Errata/Update
>> to the RFC7396 pseudocode. It is amazing that you caught the difference in
>> braces vs : ! One proposal is that we change to the exact format (replace
>> braces with {) as in RFC 7396 and keep the pseudocode. Or let the coauthors
>> discuss a bit more and get a conclusion in the next couple of days. How
>> does this sound?
>> >
>> > References:
>> >
>> > Is there a reason this document is using the obsoleted JSON reference to
>> > RFC7159? Suggest updating the reference to RFC8259.
>> >
>> >
>> > Good catch. We are updating to RFC 8259. Thanks!
>> >
>> > Thanks again.
>> > Richard
>>
>> _______________________________________________
>> alto mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>>
>