wiki/content/hina/specs/0.7.md

348 lines
9.8 KiB
Markdown
Raw Normal View History

2021-03-27 17:20:48 +00:00
---
title: Asahina Antenna Metadata Format (HINA) 2.2, rev. 0.7
date: September 24, 2000
toc: true
---
> This document is an unofficial English translation of the original Japanese
> specification made by someone who has no knowledge of Japanese. Implement at
> your own risk.
## Overview
This document describes Hina-Di, the metadata format used by [Asahina
Antenna][antenna]. In this document, "metadata" is defined as data on a webpage
such as its last update time or its author. Asahina Antenna acts as a feed
reader for Hina-Di.
## Conventions used in this document
This document uses the Backus-Naur notation ([RFC 822][rfc822]) to formally
specify the format.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 ([RFC 2119][rfc2119],
[RFC 8174][rfc8174]) when, and only when, they appear in all capitals, as shown
here.
## Data Types
The basic data types that constitute Hina-Di are listed below. The US-ASCII
character set is defined by ANSI X3.4-1986.
```
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "A".."Z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
WORD = <1*(ALPHA|DIGIT) but excluding ":" and "-">
CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF
TEXT = <any OCTET except CTLs, but including HT>
TOKEN = <any TEXT, but don't start with SP or HT>
SEPARATOR = ":" 1*( SP | HT )
DELIMITER = "," *(SP|HT)
```
## Structure
A Hina-Di file consists of a series of blocks that summarize the metadata on a
website: a header block, followed by one or more entity blocks.
```
hina-di = header-block
1*( entity-block )
```
### Block
A block is a set of metadata for a document. Each metadata is represented as a
single header, in a manner similar to [RFC 822][rfc822], with a field name and a
field value. Field names are case-sensitive. Field values may be
case-sensitive, depending on the field.
```
line-format = field-name SEPARATOR field-value CRLF
field-name = WORD *( "-" WORD)
field-value = TOKEN
```
### Header block
Exactly one header block MUST appear in a Hina-Di file, and it MUST be the
first block. It holds metadata about the Hina-Di file itself.
```
header-block = HINA
Hinadi-Header
CRLF
Hinadi-Header = 1*( User-Agent
| Content-Type
| Date )
```
### Entity block
One or more entity blocks MUST be present after the header block. Each entity
block defines metadata about a specific document.
```
Entity-block = 1*( URL
| HINA-Version
| Content-Type
| Date
| Title
| Author-Name
| Expires
| Expire
| Last-Modified
| Last-Modified-Detected
| Server
| Authorized
| Authorized-url
| Method
| Keyword
| Experimental-field
| Undefined-field
CRLF )
```
## Fields
This section defines the various fields that may be found in blocks.
All fields are OPTIONAL and case-insensitive unless otherwise specified.
### HINA
Indicates that this is a Hina-Di file, and includes its version.
This field is REQUIRED as the first field of Hina-Di files.
```
HINA = "HINA" "/" hinadi-version CRLF
hinadi-version = "2.2"
```
### User-Agent
Name of the user agent that created this Hina-Di file.
This field is REQUIRED in header blocks.
The value of this field is case-sensitive.
```
User-Agent = "User-Agent" SEPARATOR TOKEN CRLF
```
### URL
URL of the document, compliant with [RFC 2396][rfc2396].
This field is REQUIRED in entity blocks.
Making this field the first field of an entity block is RECOMMENDED.
The value of this field is case-sensitive to the extent defined by RFC 2396.
```
URL = "URL" SEPARATOR rfc2396-url CRLF
rfc2396-url = <URI described in section 5.1.2 "Request-URI" in RFC 2396>
```
### HINA-Version
Specifies that the integrity of the entity block was guaranteed according to
the specification of a specific Hina-Di version.
If this field is missing from an entity block, it means the block might be
incomplete.
```
HINA-Version = "HINA-Version" SEPARATOR version
version = "HINA" "/" 1*( DIGIT ) "." 1*( DIGIT )
```
### Content-Type
MIME type of the Hina-Di file or the document, as described in
[RFC 1521][rfc1521].
The value of this field is case-sensitive to the extent defined by RFC 1521.
```
Content-Type = "Content-Type" SEPARATOR rfc1521-type
rfc1521-type = <Content-Type as described in RFC 1521>
```
### Date
The date and time when the block was generated. The dates MUST comply with
section 3.3 of [RFC 2616][rfc2616], but [RFC 1123][rfc1123] compliance is
RECOMMENDED.
The value of this field is case-sensitive to the extent defined by RFC 2616.
```
Date = "Date" SEPARATOR rfc2616-date CRLF
rfc2616-date = <Date described in section 3.3 "Date/Time Formats" in RFC 2616,
but RFC 1123 is recommended>
```
### Title
The title of the document.
```
Title = "Title" SEPARATOR TOKEN CRLF
```
### Author-Name
Name of the author of the document.
```
Author-Name = "Author-Name" SEPARATOR TOKEN CRLF
```
### Expires
Expiration date for the block. The dates MUST comply with section 3.3 of
[RFC 2616][rfc2616], but [RFC 1123][rfc1123] compliance is RECOMMENDED.
The value of this field is case-sensitive to the extent defined by RFC 2616.
```
Expires = "Expires" SEPARATOR rfc2616-date CRLF
```
### Expire
Alias for the `Expires` field, included for backwards compatibility.
```
Expire = "Expire" SEPARATOR rfc2616-date CRLF
```
### Last-Modified
Date and time when the document was last updated. The dates MUST comply with
section 3.3 of [RFC 2616][rfc2616], but [RFC 1123][rfc1123] compliance is
RECOMMENDED.
The value of this field is case-sensitive to the extent defined by RFC 2616.
```
Last-Modified = "Last-Modified" SEPARATOR rfc2616-date CRLF
```
### Last-Modified-Detected
Date and time representing when the user agent retrieved the document's
metadata. The dates MUST comply with section 3.3 of [RFC 2616][rfc2616], but
[RFC 1123][rfc1123] compliance is RECOMMENDED.
The value of this field is case-sensitive to the extent defined by RFC 2616.
```
Last-Modified-Detected = "Last-Modified-Detected" SEPARATOR rfc2616-date CRLF
```
### Server
User agent string of the server used to retrieve the metadata of the document
described by this entity block.
```
Server = "Server" SEPARATOR TOKEN CRLF
```
### Authorized
The user agent that retrieved the metadata of the document described by this
entity block.
```
Authorized = "Authorized" SEPARATOR TOKEN CRLF
```
### Authorized-url
URL of a page describing the user agent referred to in the `Authorized` field,
compliant with [RFC 2396][rfc2396].
The value of this field is case-sensitive to the extent defined by RFC 2396.
```
Authorized-url = "Authorized-url" SEPARATOR rfc2396-url CRLF
```
### Method
To be determined. Example: `Method: REMOTE/GET/200`
### Keyword
Words that can be used to give an overview of the document described by this
entity block; tags, categories, etc. The value of this field is case-sensitive.
```
Keyword = "Keyword" SEPARATOR keywords CRLF
keywords = TOKEN *(SEPARATOR TOKEN)
```
### Experimental fields
Implementations MAY define custom fields with an X- prefix to provide
additional metadata not covered in this specification. Implementations MUST NOT
assume that all clients will use each of those fields. Clients that do not
support any experimental field SHOULD ignore them.
```
Experimental-field = x-field-name SEPARATOR TOKEN
x-field-name = "X-" WORD *("-" WORD)
```
### Undefined fields
Any field that is not defined in this specification. Implementations that
encounter such fields and do not support them SHOULD ignore them.
```
Undefined-field = undef-field-name SEPARATOR TOKEN CRLF
undef-field-name = WORD *("-" WORD)
```
## Encoding
The character encoding of the Hina-Di file SHOULD be specified as a parameter
of the `Content-Type` field of the header block. If it is not specified,
it defaults to `EUC-JP`.
## Propagation
In Hina-Di, metadata propagation consists in acquiring metadata from other
agents, then sharing it as it is in the user agent's own Hina-Di file.
This can be used for aggregation services or a peer-to-peer network.
The `Authorized` and `Authorized-url` fields allow indicating the user agent
from which the metadata originally came from to help ensure its legitimacy.
Propagating MUST only be performed if both fields are defined and if the user
agent is trusted.
When propagating, all fields of an entity block defined in this specification,
with the exception of experimental and undefined fields, MUST be reproduced
without modification. Propagating experimental or undefined fields is not
guaranteed. A header block MUST NOT be propagated.
The `Method` field MUST be processed according to the process described in the
Method section.
[antenna]: http://masshy.fastwave.gr.jp/hina/release/
[rfc822]: https://tools.ietf.org/html/rfc822
[rfc1123]: https://tools.ietf.org/html/rfc1123
[rfc1521]: https://tools.ietf.org/html/rfc1521
[rfc2119]: https://tools.ietf.org/html/rfc2119
[rfc2396]: https://tools.ietf.org/html/rfc2396
[rfc2616]: https://tools.ietf.org/html/rfc2616
[rfc8174]: https://tools.ietf.org/html/rfc8174