Hi, Sebastian: Good to hear your feedback on this issue, see my reply inline below. -----邮件原件----- 发件人: alto [mailto:[email protected]] 代表 Sebastian Kiesel 发送时间: 2021年10月17日 20:34 收件人: Qin Wu <[email protected]> 抄送: alto-chairs <[email protected]>; [email protected]; [email protected] 主题: Re: [alto] Update RFC7285 for unified property new draft
Hi Qin, all, I think "obsoletes" is definitively not adequate in this situation. My understanding of "A document that obsoletes an earlier document can stand on its own." is, that if the draft wanted to "obsolete" RFC 7285, it would have to contain a complete, self-contained, new specification of the ALTO protocol without any kind of "we do it like described in RFC 7285" reference, such that someone could implement the ALTO protocol without even reading RFC 7285. This is not the case here, to the opposite (sec 3 says: "It assumes the reader is familiar with the ALTO protocol [RFC7285]."). [Qin Wu] Agree, "obsoletes" is definitely not applied here unless we want to make a bis document for RFC7285. Regarding "updates": Does the draft change anything to RFC 7285, except adding a set of new optional features through the mechanisms we put into RFC 7285 specifically for extending it, i.e., the IRD and the IANA registries? [Qin Wu] My understanding is no. In other words, if someone were not interested in that addon, would it still make sense to implement RFC 7285 and completely ignore the RFC-to-be? [Qin Wu] Yes, it makes sense, in my understanding. Or did the authors, while working on the extension, identify some issue in the base protocol specification and specified a fix for that, which is important even if someone is not interested in unified-props as such? If the latter is true, it's definitively a case for "updates", otherwise I'm not so sure. [Qin Wu] Yes, I tend to agree with you, if we replace the existing text with new text, or if we fix the bug issue in the existing mechanism or protocol, we should use update "tag" If we extend the base protocol with new protocol extension or new features, our principle is to not tag anything, either "obsolete" or "update" based on RFC2223 and RFC7322. But one document catches my eye recently, i.e., https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag It proposes to link two documents with update by but splits update tag into 3 different tags, one is amends/amended by, the second is extends/extend by, the third is See also/See also. Tag both cases above with update tag flavors. In other words, for protocol extension or new feature without any update to existing base protocol, we can still tag such document with update tag, but we need to add more semantics to the update tag. Two reviews on unified property new draft now came up with the similar issue, i.e., clarifying the relation with RFC7285 which makes me rethink this issue again. Hope this clarifies my motivation to bring up this issue on the list. Maybe the author of draft-kuehlewind-update-tag can chime in to clarify this to us. thanks Sebastian On Sun, Oct 17, 2021 at 07:04:38AM +0000, Qin Wu wrote: > Hi, All: > I have seen two directorate review discussed the relation of unified > property new draft > (https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-n > ew) to ALTO based Protocol document (i.e.,RFC7285) and proposed to indicate > this relation in the RFC header. > I am thinking whether update or obsolete in the document header is to clarify > the relation to other RFCs. > See RFC2223 section 6: > " > 6. Relation to other RFCs > > Sometimes an RFC adds information on a topic discussed in a previous > RFC or completely replaces an earlier RFC. There are two terms used > for these cases respectively, Updates and Obsoletes. A document that > obsoletes an earlier document can stand on its own. A document that > merely updates an earlier document cannot stand on its own; it is > something that must be added to or inserted into the previously > existing document, and has limited usefulness independently. The > terms Supercedes and Replaces are no longer used. > > Updates > > To be used as a reference from a new item that cannot be used > alone (i.e., one that supplements a previous document), to refer > to the previous document. The newer publication is a part that > will supplement or be added on to the existing document; e.g., an > addendum, or separate, extra information that is to be added to > the original document. > > Obsoletes > > To be used to refer to an earlier document that is replaced by > this document. This document contains either revised information, > or else all of the same information plus some new information, > however extensive or brief that new information is; i.e., this > document can be used alone, without reference to the older > document. > > For example: > > On the Assigned Numbers RFCs the term Obsoletes should be used > since the new document actually incorporate new information > (however brief) into the text of existing information and is > more up-to-date than the older document, and hence, replaces it > and makes it Obsoletes. > > " > See RFC7322 section 4.14, > " > > 4.1.4. Updates and Obsoletes > > > > When an RFC obsoletes or updates a previously published RFC or > RFCs, > > this information is included in the document header. For example: > > > > "Updates: nnnn" or "Updates: nnnn, ..., nnnn" > > > > "Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn" > > > > If the document updates or obsoletes more than one document, > numbers > > will be listed in ascending order. > > " > Note than RFc7322 has obsoleted RFC2223. > I think "Update" is more close to what I am looking for since what we > did is Not to redefine the definition of "Unified property map or Entity > property map" > Instead, we adds definitions to the existing RFC(i.e., entity property map). > The content of the existing RFC is not invalidated by the new RFC and > is still needed to implement the endpoint property map in the base > protocol in some cases, but for some other cases when the endpoint > property map falls short, we will got for unified property map defined in > unified property new draft. > > Therefore my understanding, is endpoint property map and entity > property map Have its own use cases, can be used separately, in other > words, use of endpoint property Map and use of entity property map are > mutually exclusive, even though like this, We should still label update in > the document header. > If there is disagreement on this, please speak up and comment on this. Thanks! > > -Qin (with chair hat on) > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
