413 lines
13 KiB
Plaintext
413 lines
13 KiB
Plaintext
|
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 <title> 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]
|