[要約] RFC 9285はBase64、Base32、Base16エンコーディングスキームに基づいて構築されたBase45エンコーディングスキームについて説明しています。目的は、データを効率的にエンコードし、データのサイズを最小限に抑えることです。
Internet Engineering Task Force (IETF) P. Fältström
Request for Comments: 9285 Netnod
Category: Informational F. Ljunggren
ISSN: 2070-1721 Kirei
D.W. van Gulik
Webweaving
August 2022
The Base45 Data Encoding
base45データエンコーディング
Abstract
概要
This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes.
このドキュメントでは、base64、base32、およびbase16エンコーディングスキームに基づいて構築されたbase45エンコードスキームについて説明します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9285.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9285で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
3. Interpretation of Encoded Data
4. The Base45 Encoding
4.1. When to Use and Not Use Base45
4.2. The Alphabet Used in Base45
4.3. Encoding Examples
4.4. Decoding Example
5. IANA Considerations
6. Security Considerations
7. Normative References
Acknowledgements
Authors' Addresses
A QR code is used to encode text as a graphical image. Depending on the characters used in the text, various encoding options for a QR code exist, e.g., Numeric, Alphanumeric, and Byte mode. Even in Byte mode, a typical QR code reader tries to interpret a byte sequence as text encoded in UTF-8 or ISO/IEC 8859-1. Thus, QR codes cannot be used to encode arbitrary binary data directly. Such data has to be converted into an appropriate text before that text could be encoded as a QR code. Compared to already established Base64, Base32, and Base16 encoding schemes that are described in [RFC4648], the Base45 scheme described in this document offers a more compact QR code encoding.
QRコードは、テキストをグラフィカルな画像としてエンコードするために使用されます。テキストで使用される文字に応じて、QRコードのさまざまなエンコードオプションが存在します。たとえば、数値、英数字、バイトモードです。バイトモードでさえ、典型的なQRコードリーダーは、UTF-8またはISO/IEC 8859-1でエンコードされたテキストとしてバイトシーケンスを解釈しようとします。したがって、QRコードを使用して任意のバイナリデータを直接エンコードすることはできません。そのようなデータは、そのテキストをQRコードとしてエンコードする前に、適切なテキストに変換する必要があります。[RFC4648]に記載されているBase64、Base32、およびBase16エンコードスキームと比較して、このドキュメントで説明されているBase45スキームは、よりコンパクトなQRコードエンコードを提供します。
One important difference from those others and Base45 is the key table and that the padding with '=' is not required.
他のものやBase45との重要な違いの1つはキーテーブルであり、「=」のあるパディングは必要ありません。
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Encoded data is to be interpreted as described in [RFC4648] with the exception that a different alphabet is selected.
エンコードされたデータは、別のアルファベットが選択されていることを除いて、[RFC4648]で説明されているように解釈されます。
QR codes have a limited ability to store binary data. In practice, binary data have to be encoded in characters according to one of the modes already defined in the standard for QR codes. The easiest mode to use in called Alphanumeric mode (see Section 7.3.4 and Table 2 of [ISO18004]. Unfortunately Alphanumeric mode uses 45 different characters which implies neither Base32 nor Base64 are very effective encodings.
QRコードには、バイナリデータを保存する機能が限られています。実際には、QRコードの標準で既に定義されているモードの1つに従って、バイナリデータを文字でエンコードする必要があります。呼び出された英数字モードで使用する最も簡単なモード（[ISO18004]のセクション7.3.4と表2を参照してください。残念ながら、英数字モードでは、Base32もBase64も非常に効果的なエンコードではないことを意味する45の異なる文字を使用します。
A 45-character subset of US-ASCII is used; the 45 characters usable in a QR code in Alphanumeric mode (see Section 7.3.4 and Table 2 of [ISO18004]). Base45 encodes 2 bytes in 3 characters, compared to Base64, which encodes 3 bytes in 4 characters.
US-ASCIIの45文字のサブセットが使用されます。45文字は、英数字モードのQRコードで使用可能です（[ISO18004]のセクション7.3.4および表2を参照）。Base45は、4文字で3バイトをコードするBase64と比較して、3文字で2バイトをエンコードします。
For encoding, two bytes [a, b] MUST be interpreted as a number n in
base 256, i.e. as an unsigned integer over 16 bits so that the number
n = (a * 256) + b.
This number n is converted to base 45 [c, d, e] so that n = c + (d * 45) + (e * 45 * 45). Note the order of c, d and e which are chosen so that the left-most [c] is the least significant.
この数値nはベース45 [c、d、e]に変換されるため、n = c（d * 45）（e * 45 * 45）。左の[c]が最も重要であるように選択されたC、D、およびEの順序に注意してください。
The values c, d, and e are then looked up in Table 1 to produce a three character string. The process is reversed when decoding.
次に、値C、D、およびEを表1で検索して、3文字の文字列を生成します。デコード時にプロセスが逆になります。
For encoding a single byte [a], it MUST be interpreted as a base 256 number, i.e. as an unsigned integer over 8 bits. That integer MUST be converted to base 45 [c d] so that a = c + (45 * d). The values c and d are then looked up in Table 1 to produce a two-character string.
単一のバイト[a]をエンコードするには、ベース256番号、つまり8ビットを超える署名のない整数として解釈する必要があります。その整数は、a = c（45 * d）になるように、ベース45 [c d]に変換する必要があります。次に、値CとDを表1で検索して、2文字の文字列を生成します。
A byte string [a b c d ... x y z] with arbitrary content and arbitrary length MUST be encoded as follows: From left to right pairs of bytes MUST be encoded as described above. If the number of bytes is even, then the encoded form is a string with a length that is evenly divisible by 3. If the number of bytes is odd, then the last (rightmost) byte MUST be encoded on two characters as described above.
任意のコンテンツと任意の長さを備えたバイト文字列[a b c d ... x y z]は、次のようにエンコードする必要があります。上記のように、バイトの左から右のペアをエンコードする必要があります。バイト数が均等な場合、エンコードされたフォームは、3で均等に分割できる長さの文字列です。バイト数が奇妙な場合、最後の（右端の）バイトは上記の2つの文字でエンコードする必要があります。
For decoding a Base45 encoded string the inverse operations are performed.
Base45エンコード文字列をデコードするために、逆操作が実行されます。
If binary data is to be stored in a QR code, the suggested mechanism is to use the Alphanumeric mode that uses 11 bits for 2 characters as defined in Section 7.3.4 of [ISO18004]. The Extended Channel Interpretation (ECI) mode indicator for this encoding is 0010.
バイナリデータがQRコードに保存される場合、推奨されるメカニズムは、[ISO18004]のセクション7.3.4で定義されているように、2文字に11ビットを使用する英数字モードを使用することです。このエンコードの拡張チャネル解釈（ECI）モードインジケーターは0010です。
On the other hand if the data is to be sent via some other transport, a transport encoding suitable for that transport should be used instead of Base45. For example, it is not recommended to first encode data in Base45 and then encode the resulting string in Base64 if the data is to be sent via email. Instead, the Base45 encoding should be removed, and the data itself should be encoded in Base64.
一方、データを他の輸送で送信する場合、その輸送に適したエンコードをbase45の代わりに使用する必要があります。たとえば、データを電子メールで送信する場合は、最初にbase45でデータをエンコードし、base64で結果の文字列をエンコードすることはお勧めしません。代わりに、base45エンコードを削除し、データ自体をbase64でエンコードする必要があります。
The Alphanumeric mode is defined to use 45 characters as specified in this alphabet.
英数字モードは、このアルファベットで指定されている45文字を使用するように定義されています。
+=====+==========+=====+==========+=====+==========+=====+==========+
|Value| Encoding |Value| Encoding |Value| Encoding |Value| Encoding |
+=====+==========+=====+==========+=====+==========+=====+==========+
| 00| 0 | 12| C | 24| O | 36| Space |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 01| 1 | 13| D | 25| P | 37| $ |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 02| 2 | 14| E | 26| Q | 38| % |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 03| 3 | 15| F | 27| R | 39| * |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 04| 4 | 16| G | 28| S | 40| + |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 05| 5 | 17| H | 29| T | 41| - |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 06| 6 | 18| I | 30| U | 42| . |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 07| 7 | 19| J | 31| V | 43| / |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 08| 8 | 20| K | 32| W | 44| : |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 09| 9 | 21| L | 33| X | | |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 10| A | 22| M | 34| Y | | |
+-----+----------+-----+----------+-----+----------+-----+----------+
| 11| B | 23| N | 35| Z | | |
+-----+----------+-----+----------+-----+----------+-----+----------+
Table 1: The Base45 Alphabet
表1：Base45アルファベット
It should be noted that although the examples are all text, Base45 is an encoding for binary data where each octet can have any value 0-255.
例はすべてテキストですが、base45は各オクテットが任意の値0-255を持つことができるバイナリデータのエンコードであることに注意してください。
Encoding example 1:
エンコード例1：
The string "AB" is the byte sequence [[65 66]]. If we look at all 16 bits, we get 65 * 256 + 66 = 16706. 16706 equals 11 + (11 * 45) + (8 * 45 * 45), so the sequence in base 45 is [11 11 8]. Referring to Table 1, we get the encoded string "BB8".
文字列「ab」はバイトシーケンス[[65 66]]です。16ビットすべてを見ると、65 * 256 66 = 16706を取得します。16706は11（11 * 45）（8 * 45 * 45）に等しいため、ベース45のシーケンスは[11 11 8]です。表1を参照すると、エンコードされた文字列「BB8」が取得されます。
+-----------+------------------+
| AB | Initial string |
+-----------+------------------+
| [[65 66]] | Decimal value |
+-----------+------------------+
| [16706] | Value in base 16 |
+-----------+------------------+
| [11 11 8] | Value in base 45 |
+-----------+------------------+
| BB8 | Encoded string |
+-----------+------------------+
Table 2: Example 1 in Detail
表2：例1詳細
Encoding example 2:
エンコード例2：
The string "Hello!!" as ASCII is the byte sequence [[72 101] [108 108] [111 33] [33]]. If we look at this 16 bits at a time, we get [18533 27756 28449 33]. Note the 33 for the last byte. When looking at the values in base 45, we get [[38 6 9] [36 31 13] [9 2 14] [33 0]], where the last byte is represented by two values. The resulting string "%69 VD92EX0" is created by looking up these values in Table 1. It should be noted it includes a space.
文字列「こんにちは!!」ASCIIはバイトシーケンス[[72 101] [108 108] [111 33] [33]]です。一度にこの16ビットを見ると、[18533 27756 28449 33]を取得します。最後のバイトの33に注意してください。ベース45の値を見ると、[[38 6 9] [36 31 13] [9 2 14] [33 0]]を取得し、最後のバイトは2つの値で表されます。結果の文字列「％69 VD92Ex0」は、表1でこれらの値を調べることで作成されます。スペースが含まれていることに注意してください。
+---------------------------------------+------------------+
| Hello!! | Initial string |
+---------------------------------------+------------------+
| [[72 101] [108 108] [111 33] [33]] | Decimal value |
+---------------------------------------+------------------+
| [18533 27756 28449 33] | Value in base 16 |
+---------------------------------------+------------------+
| [[38 6 9] [36 31 13] [9 2 14] [33 0]] | Value in base 45 |
+---------------------------------------+------------------+
| %69 VD92EX0 | Encoded string |
+---------------------------------------+------------------+
Table 3: Example 2 in Detail
表3：例2詳細
Encoding example 3:
エンコード例3：
The string "base-45" as ASCII is the byte sequence [[98 97] [115 101] [45 52] [53]]. If we look at this two bytes at a time, we get [25185 29541 11572 53]. Note the 53 for the last byte. When looking at the values in base 45, we get [[30 19 12] [21 26 14] [7 32 5] [8 1]] where the last byte is represented by two values. Referring to Table 1, we get the encoded string "UJCLQE7W581".
ASCIIとしての文字列「ベース45」はバイトシーケンスです[[98 97] [115 101] [45 52] [53]]。一度にこの2バイトを見ると、[25185 29541 11572 53]を取得します。最後のバイトの53に注意してください。ベース45の値を見ると、[[30 19 12] [21 26 14] [7 32 5] [8 1]]を取得します。最後のバイトは2つの値で表されます。表1を参照すると、エンコードされた文字列「ujclqe7w581」が取得されます。
+----------------------------------------+------------------+
| base-45 | Initial string |
+----------------------------------------+------------------+
| [[98 97] [115 101] [45 52] [53]] | Decimal value |
+----------------------------------------+------------------+
| [25185 29541 11572 53] | Value in base 16 |
+----------------------------------------+------------------+
| [[30 19 12] [21 26 14] [7 32 5] [8 1]] | Value in base 45 |
+----------------------------------------+------------------+
| UJCLQE7W581 | Encoded string |
+----------------------------------------+------------------+
Table 4: Example 3 in Detail
表4：例3詳細
Decoding example 1:
デコード例1：
The string "QED8WEX0" represents, when looked up in Table 1, the values [26 14 13 8 32 14 33 0]. We arrange the numbers in chunks of three, except for the last one which can be two numbers, and get [[26 14 13] [8 32 14] [33 0]]. In base 45, we get [26981 29798 33] where the bytes are [[105 101] [116 102] [33]]. If we look at the ASCII values, we get the string "ietf!".
文字列「Qed8Wex0」は、表1で見上げると、値[26 13 8 32 14 33 0]を表します。2つの数字になる可能性のある最後のものを除き、3つのチャンクで数値を配置し、[[26 13] [8 32 14] [33 0]]を取得します。ベース45では、バイトが[[105 101] [116 102] [33]]である[26981 29798 33]を取得します。ASCII値を見ると、文字列「IETF！」が表示されます。
+-------------------------------+------------------------+
| QED8WEX0 | Initial string |
+-------------------------------+------------------------+
| [26 14 13 8 32 14 33 0] | Looked up values |
+-------------------------------+------------------------+
| [[26 14 13] [8 32 14] [33 0]] | Groups of three |
+-------------------------------+------------------------+
| [26981 29798 33] | Interpreted as base 45 |
+-------------------------------+------------------------+
| [[105 101] [116 102] [33]] | Values in base 8 |
+-------------------------------+------------------------+
| ietf! | Decoded string |
+-------------------------------+------------------------+
Table 5: Example 4 in Detail
表5：例4詳細
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
When implementing encoding and decoding it is important to be very careful so that buffer overflow or similar issues do not occur. This of course includes the calculations in base 45 and lookup in the table of characters (Table 1). A decoder must also be robust regarding input, including proper handling of any octet value 0-255, including the NUL character (ASCII 0).
エンコードとデコードを実装する場合、バッファーオーバーフローまたは同様の問題が発生しないように、非常に注意することが重要です。もちろん、ベース45の計算と文字の表の検索が含まれます（表1）。デコーダーは、NUL文字（ASCII 0）を含む任意のオクテット値0-255の適切な処理を含む、入力に関しても堅牢でなければなりません。
It should be noted that Base64 and some other encodings pad the string so that the encoding starts with an aligned number of characters while Base45 specifically avoids padding. Because of this, special care has to be taken when an odd number of octets is to be encoded. Similarly, care must be taken if the number of characters to decode are not evenly divisible by 3.
base64および他のエンコーディングは文字列をパッドして、エンコードがアライメントされた数の文字で始まる一方で、base45がパディングを特別に回避することに注意する必要があります。このため、奇数のオクテットをエンコードする場合、特別な注意を払う必要があります。同様に、デコードする文字の数が3で均等に分割できない場合は、注意を払う必要があります。
Base encodings use a specific, reduced alphabet to encode binary data. Non-alphabet characters could exist within base-encoded data, caused by data corruption or by design. Non-alphabet characters may be exploited as a "covert channel", where non-protocol data can be sent for nefarious purposes. Non-alphabet characters might also be sent in order to exploit implementation errors leading to, for example, buffer overflow attacks.
ベースエンコーディングは、特定の削減されたアルファベットを使用して、バイナリデータをエンコードします。非アルファベット文字は、データの破損または設計によって引き起こされる基本エンコードデータ内に存在する可能性があります。アルファベット以外の文字は、「秘密のチャネル」として悪用される場合があります。この場合、非プロトコルデータを邪悪な目的で送信できます。たとえば、バッファオーバーフロー攻撃につながる実装エラーを活用するために、アルファベット以外の文字も送信される場合があります。
Implementations MUST reject any input that is not a valid encoding. For example, it MUST reject the input (encoded data) if it contains characters outside the base alphabet (in Table 1) when interpreting base-encoded data.
実装は、有効なエンコードではない入力を拒否する必要があります。たとえば、ベースエンコードデータを解釈するときにベースアルファベットの外側（表1）の外側に文字が含まれている場合、入力（エンコードされたデータ）を拒否する必要があります。
Even though a Base45-encoded string contains only characters from the alphabet in Table 1, cases like the following have to be considered: The string "FGW" represents 65535 (FFFF in base 16), which is a valid encoding of 16 bits. A slightly different encoded string of the same length, "GGW", would represent 65536 (10000 in base 16), which is represented by more than 16 bits. Implementations MUST also reject the encoded data if it contains a triplet of characters that, when decoded, results in an unsigned integer that is greater than 65535 (FFFF in base 16).
Base45エンコードの文字列には、表1のアルファベットの文字のみが含まれていますが、次のようなケースを考慮する必要があります。文字列「FGW」は、16ビットの有効なエンコードである65535（ベース16のFFFF）を表します。同じ長さのわずかに異なるエンコードされた文字列「GGW」は、16ビット以上で表される65536（ベース16で10000）を表します。また、実装は、デコードされたときに65535（ベース16のFFFF）を超える符号なし整数になる文字のトリプレットが含まれている場合、エンコードされたデータを拒否する必要があります。
It should be noted that the resulting string after encoding to Base45 might include non-URL-safe characters so if the URL including the Base45 encoded data has to be URL-safe, one has to use percent-encoding.
Base45へのエンコード後の結果の文字列には、非URLセーフ文字が含まれる可能性があるため、base45エンコードされたデータを含むURLがURLセーフでなければならない場合、パーセントエンコードを使用する必要があります。
[ISO18004] ISO/IEC, "Information technology - Automatic identification and data capture techniques - QR Code bar code symbology specification", ISO/IEC 18004:2015, February 2015, <https://www.iso.org/standard/62021.html>.
[ISO18004] ISO/IEC、「情報技術 - 自動識別とデータキャプチャテクニック - QRコードバーコードシンボル学仕様」、ISO/IEC 18004：2015、2015年2月、<https://www.iso.org/standard/620211.html>。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、RFC 4648、DOI 10.17487/RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
Acknowledgements
謝辞
The authors thank Mark Adler, Anders Ahl, Alan Barrett, Sam Spens Clason, Alfred Fiedler, Tomas Harreveld, Erik Hellman, Joakim Jardenberg, Michael Joost, Erik Kline, Christian Landgren, Anders Lowinger, Mans Nilsson, Jakob Schlyter, Peter Teufl, and Gaby Whitehead for the feedback. Also, everyone who has been working with Base64 over a long period of years and has proven the implementations are stable.
著者は、マーク・アドラー、アンダース・アール、アラン・バレット、サム・スペンス・クラソン、アルフレッド・フィードラー、トマス・ハレヴェルド、エリック・ヘルマン、ジョアキム・ジャルデンバーグ、マイケル・ジョースト、エリック・クライン、クリスチャン・ランドグレン、アンダース・ローウィング、マンズ・ニルソン、ヤコブ・シュレーター、ペテロ・テウフ、フィードバックのためのGaby Whitehead。また、長年にわたってbase64を扱っており、実装が安定していることが証明されているすべての人がいます。
Authors' Addresses
著者のアドレス
Patrik Fältström Netnod Email: paf@netnod.se
PatrikfältströmNetnodメール：paf@netnod.se
Fredrik Ljunggren Kirei Email: fredrik@kirei.se
Fredrik Ljunggren Kireiメール：fredrik@kirei.se
Dirk-Willem van Gulik Webweaving Email: dirkx@webweaving.org
Dirk-Willem Gulik WebWeavingメール：dirkx@webweaving.org