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 <i...@kuehlewind.net> 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 <y...@cs.yale.edu> wrote: > > > > Dear Suresh, > > > > Thanks for the review! Please see inline. > > > > On Wed, Mar 11, 2020 at 12:20 PM Suresh Krishnan via Datatracker < > nore...@ietf.org> 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 > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
