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 tag. 3.7. Author name Name of the author of the content served at this URL. 3.8. Source URL URL that was used by the LIRS provider to acquire update information. This is usually the same as the URL; in case of an implementation that aggregates update information from other LIRS providers, this could be the URL of each LIRS file. How to use this field is left to the implementor. 3.9. Extension Arbitrary string for agent-specific information. Instead of 0 as the default for a blank field, this SHOULD be left empty. ~lucidiot Standards Track [Page 4] RFB 4 LIRS 2.1 June 2021 4. Best Practices LIRS files SHOULD be cached, not generated dynamically. LIRS implementations SHOULD automatically discard records that were last detected more than 28800 seconds (8 hours) ago. 5. Example This is a single LIRS record, uncompressed: LIRS,938779260,938781002,32400,49383,http://hiya.ouchi.to/n/, Tadayo Memories,Hiya,http://amano.hauN.org/,blah blah,\r\n This translates to the following fields: Title: Tadayo Memories Author: Hiya Site URL: http://hiya.ouchi.to/n/ Last modified: 1999-10-01T14:01:00Z Last detected: 1999-10-01T14:30:02Z Server timezone: UTC+9 (32400 seconds) Source: http://amano.hauN.org/ Custom data: blah blah 6. Security Considerations Client implementations SHOULD be wary of the possible decompression bombs that a server could send. The standard was designed with HTTP in mind, but replacing the scheme with HTTPS for added security should not affect any modern implementation. 7. Internationalization Considerations This standard was almost exclusively designed for Japan; no encoding other than EUC-JP is allowed. Client implementations MAY be flexible and try decoding using UTF-8 instead of EUC-JP when errors occur, to allow for a possible evolution towards an internationalized standard if more LIRS implementations support it. ~lucidiot Standards Track [Page 5] RFB 4 LIRS 2.1 June 2021 8. Privacy Considerations The metadata shared in LIRS is already public, and disclosure of this information is under the full control of the publisher. However, when aggregating feds, the removal of already aggregated links or metadata may not be strictly performed by all implementors. This can lead to the same issues as those seen in present-day federated social networks, to which the only guaranteed solution is to not publish what you might have to remove later. 9. BANANA Considerations This document updates the "LIRS" value in the E-mail Signature Protocol Abbreviations registry. The Reference field of the value should now point to this document. 10. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. Appendix A. Warranty Exclusion Statement This document and the information contained herein is provided on an "AS IS" basis and TILDE.TOWN DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Appendix B. Changelog This changelog was included in the original specification. It is included here to provide historical context. The changelog only included timestamps. The associated version numbers have been added where they are known. 2001-12-16 22:48, LIRS 2.1 Added a link to the Meta::LIRS Perl module 2000-10-25 14:36, LIRS 2.1 Fixed an error in the description of the URL field. ~lucidiot Standards Track [Page 6] RFB 4 LIRS 2.1 June 2021 2000-10-13 15:20, LIRS 2.1 Fixed an error in the usage of gzip in LIRS.pm. 2000-06-23 13:52 Added details about handling line feeds (\\015, \\012). 2000-06-16 13:47 Added a link to lirs.rb. 2000-05-31 20:00 Backslashes should now be escaped too (`\\`). Minor corrections due to changes in LIRS.pm. 1999-11-11 19:41 Document converted to HTML, and minor corrections. 1999-11-03 03:25, LIRS 1.1 Minor corrections after a discussion about DI. Added the About LIRS section. 1999-10-13 18:00, LIRS 1.0 Initial version. Acknowledgements The author would like to thank Hiya for creating LIRS, and Yamakazoo for creating some Perl CGI scripts that support LIRS, HINA 1 and HINA 2, and still hosting them proudly on their personal website in the year 2021: http://www.harmonicom.jp/natsu/ Author's Address ~lucidiot (editor) Bikeshedding Microsystems m455.casa 138.197.184.222 The Internet Email: lucidiot@brainshit.fr URI: https://tilde.town/~lucidiot/ ~lucidiot Standards Track [Page 7]