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].").
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? 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? 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. 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-new) 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
