Subject: [alto] Update RFC7285 for unified property new draft

From: Qin Wu <[email-masked]>
Date: Sun, 17 Oct 2021 07:04:38 +0000

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)

---

From: Sebastian Kiesel <[email-masked]>
Date: Sun, 17 Oct 2021 14:34:25 +0200

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

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto