Hi Richard,
The current revision sounds good to me.
Sorry for the confusion. The "loose dependency" refers to what Mirja said
("... replace it by a few sentences that loosely described the scheme.")
Maybe I misunderstood it. I thought Mirja suggested when the RFC7396 is
updated in the future, the sentences in this document should also imply the
updated specification. What I suggest is that we should use a fixed
specification, not an adaptive one.
Thanks,
Jensen
On Thu, Mar 12, 2020 at 12:13 PM Y. Richard Yang <[email protected]> wrote:
> - 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 <[email protected]>
> 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 <[email protected]>
>> 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 <[email protected]> wrote:
>>> >
>>> > Dear Suresh,
>>> >
>>> > Thanks for the review! Please see inline.
>>> >
>>> > On Wed, Mar 11, 2020 at 12:20 PM Suresh Krishnan via Datatracker <
>>> [email protected]> 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
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
