Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is athttps://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 10 October 2020.¶

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1.Introduction

(TO DO: Insert an extended form of the abstract first here, expandingthe reference to[RFC7230] and[RFC7252] in the process.)¶

Examples for protocols that provide Series-shaped data are:¶

• The Atom Syndication Format[RFC4287] definesfeeds as Seriesofentries (links plus some metadata, which can often be much ofthe content of an entry), where a feed is represented by acollection resource that contains just a small number of the mostrecent entries. By polling a feed, a client can contain a freshview of the Series, with a focus on recent items. If the clientdoes not poll often enough, it willmiss items.¶
• Messaging protocols such as XMPP or SIMPLE transfer series of whatis often called "Instant Messages". A publish/subscribe mechanismallows a client to select sequences of messages that it isinterested in.¶
• Mail servers that provide interactive access to stored messagespresent a Series to their clients. Obviously, loss of messages isfrowned upon.¶
• CoAP Observe allows a client to observe a resource as it changes;the client can collect the changes into a Series. Observe isfocused on eventual consistency: a fresher data items simplyoverwrites an older one. The present document uses the observepattern to build a more general Series Transfer Pattern.¶
• Syslog is an interesting case of a Series Transfer.¶
• [RFC8641],[I-D.voit-netmod-yang-notifications2],[RFC8639],[I-D.ietf-netconf-notification-messages],[RFC8650].¶
• An RTP stream can be viewed as an (somewhat extreme) case of aSeries; new items are just sent inside separate UDP packets. Asequence number allows to detect (but not normally ask forretransmission of) missing items. A timestamp as well as sourcedata (SSRC, CSRC) provide further common metadata that aid in theprocessing of the Series items.¶
• An example of an ad-hoc design of a series transfer protocol is[I-D.ietf-netconf-udp-pub-channel].¶
• Server-sent events[sse] are a somewhat bizarre version of a seriestransfer protocol.¶
• The Interface for Metadata Access Points (IF-MAP) specified by theTrusted Computing Group and emerging derivatives of that protocolcreate a series of updates to a graph representation of relatednetwork-related security information. The requests created byIF-MAP clients are bundled operations of updates to aMAP Graph, which compose a Series Transfer Pattern of bundled atomicoperations that ensure the integrity of the MAP Graph. [Henk Birkholz]¶
• netflow/IPFIX was defined to transfer a series of data items about flows.Information about PDU flows accounted by network interfaces ofendpoints is emitted in a series of counter bundles via the IPFIXprotocol. Only a series of these continuous Flow Records creates ameaningful bigger picture about the current traffic in the networktopology of an administrative domain. Depending on the characteristicsmeasured, loss of a Flow Record can range from harmless to missing theonly vital counter measurement. [Henk Birkholz]¶
• TO DO: Add more items.¶

[I-D.birkholz-yang-push-coap-problemstatement] is a problemstatement that will require the design of another scheme to transferSeries-shaped data.¶

2.Objectives

Series transfer applications may have rather different objectives.¶

• The completeness of the Series transfer may be of utmost importance(e.g., if each item represents a sale), it may be desirable but canbe jettisoned in an overload situation, or it may just be a likelyoutcome with a very active client (e.g., with Atom). Note thatthere is never a way toguarantee completeness unless all of therate and size of incoming new items, the transfer capacityavailable, and the processing capabilities of the client arecontrolled; however, system designs may want to give the illusion of"reliability".¶
• Minimizing the latency of the transfer may be important, as may belimiting it below a defined maximum (note that these are differentobjectives). The latter can be supported in a polling system bypolling at least as often as that maximum latency; this may beconsidered inefficient and "push" mechanisms may be developed. Mailenvironments have developed "push" services to enable minimizing thelatency. Where latency requirements go below the time that might beneeded for an end-to-end retransmission, error concealment mayprovide an acceptable user experience (e.g., in RTP).¶

In general, minimizing latency and ensuring completeness are competingobjectives.¶

Series transfer environments sometimes centralize informationdistribution functions, leading to "broker" architectures (oftencombined with the "publish/subscribe" pattern). With brokers, Seriespublishers may use an entirely different interface to the brokers fromthat used by the receiving clients, or the interfaces can be designedso they are similar for all the forwarding steps.¶

3.A REST Series Transfer Pattern (STP)

4.IANA considerations

This memo registers a number of media types: TO DO.¶

• A media type for FETCH selectors (Section 3):¶

  • An alternative way to encode this information into the URIof a GET should also be available.¶
• A Series media type as alluded to inSection 3.¶

5.Security considerations

TO DO¶

Acknowledgements

The need for a Series Transfer Pattern has been made clear by a numberof people that contribute to the IRTF Thing-to-Thing Research Group(T2TRG), e.g. Matthias Kovatsch and Henk Birkholz (both of whom alsoprovided feedback on an early draft). Henk also contributed furtherexamples for the use of Series Transfers in protocols.¶

Authors' Addresses