casa/bikeshed
casa
/
bikeshed
9
0
Fork 0
Code Issues Pull Requests Releases Activity
bikeshed/rfb/rfb4.txt

413 lines
13 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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]
Reference in New Issue View Git Blame Copy Permalink