Bikeshedding Working Group ~lucidiot, Ed. Request for Bikeshedding: 4 Bikeshedding Microsystems Category: Standards Track June 30, 2021 Last-modified Information Relaying Specification (LIRS) 2.1 Abstract This document is an English translation and clean-up of the Last-modified Information Relaying Specification (LIRS) 2.1, in its only recovered and latest revision of December 16, 2001. It aims to preserve historical knowledge over syndication formats. Status of This Memo This is a Bikeshedding Standards Track document. This document is a product of the Bikeshedding Working Group (BWG). It represents the consensus of the bikeshedding community. It has received public review and has been approved for publication by the Bikeshedding Engineering Steering Group (BESG). Information about the current status of this document, any errata, and how to provide feedback on it may be obtained on the tildepals mailing list. Copyright Notice Copyright (c) 2021 Bikeshedding Microsystems and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the Bikeshedding Microsystems' Legal Provisions Relating to Bikeshedding Documents 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. ~lucidiot Standards Track [Page 1] RFB 4 LIRS 2.1 June 2021 Table of Contents 1. Introduction ...................................................2 1.1. Notational Conventions ....................................2 2. Format .........................................................3 3. Fields .........................................................3 3.1. Last-Modified .............................................3 3.2. Last-Detected .............................................4 3.3. Time difference ...........................................4 3.4. Content-Length ............................................4 3.5. URL .......................................................4 3.6. Title .....................................................4 3.7. Author name ...............................................4 3.8. Source URL ................................................4 3.9. Extension .................................................4 4. Best Practices .................................................5 5. Example ........................................................5 6. Security Considerations ........................................5 7. Internationalization Considerations ............................5 8. Privacy Considerations .........................................6 9. BANANA Considerations ..........................................6 10. References .....................................................6 Appendix A. Warranty Exclusion Statement ...........................6 Appendix B. Changelog ..............................................6 Acknowledgements ...................................................7 Author's Address ...................................................7 1. Introduction This document is a continuation of the historical research project of the Bikeshedding Microsystems Research and Development Division, aiming to preserve the history of syndication formats. It is a cleaned up English translation of a Japanese specification that has been recovered via the Internet Archive Wayback Machine. Last-modified Information Relaying Specification (LIRS) 2.1 is a last-modified-detection protocol designed to only include the minimal necessary information for update time acquisition agents (antennas). It assumes that a site that provides update times should not be burdened with anything other than reporting update times. It also assumes that the sites all run on UNIX environments. The person exclusively in charge for changes to this specification is Hiya (hiya@haun.org). 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document SHALL NOT be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ~lucidiot Standards Track [Page 2] RFB 4 LIRS 2.1 June 2021 2. Format An LIRS file is a text file compressed using gzip. The text is encoded using EUC-JP and consists in a series of records. A record starts with "LIRS,", followed by a data part, and ends with a comma and LF or CRLF. LF is recommended. CR MUST NOT be used alone. Lines that begin with # are comments and SHOULD be ignored. The data part of a record consists in a series of fields separated by commas (,). Field values MUST NOT include the CR or LF characters, or unescaped commas. All dates are expressed as Unix timestamps: seconds from 1970-01-01T00:00:00Z. With the exception of the extension field, blank fields SHOULD be represented as a zero (0). The backslash character (\) is the escape character. Commas in fields MUST be escaped (\,). A literal backslash can be inserted using two backslashes (\\). 3. Fields The following fields MUST appear in all records, in this order: - Last-Modified - Last-Detected - Time difference - Content-Length - URL - Title - Author name - Source URL - Extension 3.1. Last-Modified Timestamp of when the target site was last updated. Should the last update detection fail, the LIRS provider SHOULD set this field to zero, and antenna agents SHOULD assume this record is unusable. ~lucidiot Standards Track [Page 3] RFB 4 LIRS 2.1 June 2021 3.2. Last-Detected Timestamp of when the LIRS provider last checked for the last update time for this site. This defines a notion of "freshness" that antenna agents can use to sort records by priority, or discard old records. Should the last update detection fail, the LIRS provider SHOULD set this field to zero, and antenna agents SHOULD assume this record is unusable. 3.3. Time difference Signed integer. Difference, in seconds, between GMT and the timezone of the target site; 32400 or +32400 in Japan. Since update times are reported in GMT, this allows sharing the timezone of the target site. 3.4. Content-Length Size of the content served at the target URL, in bytes. LIRS providers that check the target site externally, and do not have more internal ways to detect an update, SHOULD consider a change in the Content-Length to be an update. 3.5. URL URL of the target site. This field MUST be unique; a single URL MUST NOT be repeated twice in the same LIRS file. This field can be used as a unique identifier by antenna implementations. 3.6. Title Title of the content served at the target site; usually the contents of the HTML