[要約] RFC 5593は、IMAPプロトコルにURLアクセス識別子拡張を提供します。この拡張の目的は、IMAPクライアントがメッセージのURLにアクセスし、メッセージを直接表示またはダウンロードできるようにすることです。
Network Working Group N. Cook
Request for Comments: 5593 Cloudmark
Updates: 5092 June 2009
Category: Standards Track
Internet Message Access Protocol (IMAP) - URL Access Identifier Extension
インターネットメッセージアクセスプロトコル（IMAP） - URLアクセス識別子拡張機能
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications.
既存のIMAP URL仕様（RFC 5092）には、Urlauthが生成したURLへのアクセスを制限するために使用できるいくつかの<アクセス>識別子および<アクセス>識別子プレフィックスがリストされています。ただし、これらの識別子は、ストリーミングなどの新しいサービスの施設を提供していません。このドキュメントでは、将来のアプリケーションの新しい<Access>識別子を登録するためのIANAメカニズムと同様に、新しい<Access>識別子のセットとIANAメカニズムを提案します。
This document updates RFC 5092.
このドキュメントは、RFC 5092を更新します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Additional Authorized Access Identifiers ........................3
3.1. Existing Access Identifiers ................................3
3.2. Requirement for Additional Access Identifiers ..............3
3.3. Additional Access Identifier Specification .................4
3.4. Defining an Access Identifier for Streaming ................5
4. Formal Syntax ...................................................5
5. Acknowledgements ................................................6
6. IANA Considerations .............................................6
6.1. Access Identifier Registration Template ....................7
6.2. Stream Application Registration ............................7
6.3. Submit Application Registration ............................8
6.4. User Application Registration ..............................8
6.5. Authuser Application Registration ..........................9
6.6. Anonymous Application Registration .........................9
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
The IMAP URL specification [RFC5092] provides a way to carry authorization information in IMAP URLs. Several authorization <access> identifiers are specified in the document that allow URLAUTH-authorized URLs to be used only by anonymous users, authenticated users, or message submission entities. However, there is no mechanism defined to create new <access> identifiers, and overloading the existing mechanisms has security as well as administrative implications.
IMAP URL仕様[RFC5092]は、IMAP URLに承認情報を伝達する方法を提供します。いくつかの承認<Access>識別子は、匿名ユーザー、認証されたユーザー、またはメッセージ提出エンティティによってのみ使用できるようにするドキュメントで指定されています。ただし、新しい<cassion>識別子を作成するためのメカニズムはありません。既存のメカニズムに過負荷になると、セキュリティと管理上の意味があります。
This document describes a new <access> identifier, "stream", to be used by message streaming entities (as described in [STREAMING]), and defines an IANA registration template, which can be used to register new <access> identifiers for future applications. IANA definitions for the existing access identifiers and prefixes from RFC 5092 are also defined in this document -- this document updates RFC 5092 and should be taken as the master in the event of any differences or discrepancies.
このドキュメントでは、メッセージストリーミングエンティティ（[ストリーミング]で説明されている）で使用される新しい<cassion>識別子「ストリーム」について説明し、将来の新しい<アクセス>識別子を登録するために使用できるIANA登録テンプレートを定義します。アプリケーション。RFC 5092の既存のアクセス識別子とプレフィックスのIANA定義もこのドキュメントで定義されています。このドキュメントはRFC 5092を更新し、違いや矛盾がある場合にマスターとして取得する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then some of the line breaks between those lines are for editorial clarity only and may not be part of the actual protocol exchange.
例では、「C：」と「S：」は、それぞれクライアントとサーバーから送信された行を示します。単一の「c：」または「s：」が複数の行に適用される場合、それらのライン間のラインブレークの一部は編集の明確さのみであり、実際のプロトコル交換の一部ではない場合があります。
The IMAP URL specification [RFC5092] specifies the following authorized <access> identifiers:
IMAP URL仕様[RFC5092]は、次の承認された<Access>識別子を指定します。
o "authuser" - Indicates that use of this URL is limited to authenticated IMAP sessions that are logged in as any non-anonymous user.
o 「authuser」 - このURLの使用は、非匿名のユーザーとしてログインしている認証されたIMAPセッションに限定されていることを示しています。
o "anonymous" - Indicates that use of this URL is not restricted by session authorization identity.
o 「匿名」 - このURLの使用がセッション認証IDによって制限されていないことを示します。
Additionally, the following <access> identifier prefixes are defined in [RFC5092]:
さらに、次の<Access>識別子プレフィックスは[RFC5092]で定義されています。
o "submit+" - Followed by a userid, indicates that only a userid authorized as a message submission entity on behalf of the specified userid is permitted to use this URL.
o 「送信」 - ユーザーIDが続いて、指定されたユーザーIDに代わってメッセージ提出エンティティとして承認されたユーザーIDのみがこのURLを使用することが許可されていることを示します。
o "user+" - Followed by a userid, indicates that use of this URL is limited to IMAP sessions that are logged in as the specified userid.
o 「ユーザー」 - ユーザーIDが続くと、このURLの使用は、指定されたユーザーIDとしてログインされるIMAPセッションに限定されていることを示します。
The existing <access> identifiers are suitable for user-based authorization, but only the "submit+" <access> identifier prefix is suitable for entities acting on behalf of a user. Generic support for external entities acting on behalf of users is required for new services such as streaming [STREAMING].
既存の<Access>識別子はユーザーベースの承認に適していますが、「送信」<Access>識別子プレフィックスのみがユーザーに代わって行動するエンティティに適しています。ユーザーに代わって行動する外部エンティティの一般的なサポートは、ストリーミング[ストリーミング]などの新しいサービスに必要です。
The "submit+" <access> identifier prefix is not suitable for use as a general mechanism to grant access to entities acting on behalf of users, for reasons that include:
「submit」<chince <Access>識別子プレフィックスは、以下を含む理由により、ユーザーに代わって行動するエンティティへのアクセスを付与するための一般的なメカニズムとして使用するのに適していません。
o Security - The IMAP server maintains a list of submission server entities that are entitled to retrieve IMAP URLs specifying the "submit+" <access> identifier prefix. If this list is extended to include the set of all external entities that could act on behalf of users, then the attack surface would be increased.
o セキュリティ-IMAPサーバーは、「submit "<chince>識別子プレフィックスを指定するIMAP URLを取得する権利がある提出サーバーエンティティのリストを維持します。このリストが拡張されている場合、ユーザーに代わって行動できるすべての外部エンティティのセットを含めると、攻撃面が増加します。
o Administration - When URLAUTH-style IMAP URLs are presented to an IMAP server by entities acting on behalf of users, the server administrator has no way of determining the intended use of that URL from the server logs.
o 管理 - ユーザーに代わって行動するエンティティによってUrlauthスタイルのIMAP URLがIMAPサーバーに提示される場合、サーバー管理者は、サーバーログからそのURLの使用を意図した使用を決定する方法がありません。
o Resourcing - Without a mechanism to distinguish between the application for which an IMAP URL is to be used, the IMAP server has no way to prioritize resources for particular applications. For example, the server could prioritize "submit+" URL fetch requests over other access identifiers.
o リソース - IMAP URLを使用するアプリケーションを区別するメカニズムがないため、IMAPサーバーには特定のアプリケーションのリソースに優先順位を付ける方法がありません。たとえば、サーバーは、他のアクセス識別子よりもURLフェッチ要求を「送信」することができます。
The previous section establishes that additional access identifiers are required to support applications, such as streaming [STREAMING], that require entities to retrieve URLAUTH URLs on behalf of users. This section describes the scope and meaning of any additional <access> identifiers that are created.
前のセクションでは、ユーザーに代わってUrluth URLを取得する必要があるストリーミング[ストリーミング]などのアプリケーションをサポートするために追加のアクセス識別子が必要であることを確立します。このセクションでは、作成された追加の<アクセス>識別子の範囲と意味について説明します。
Additional <access> identifiers MUST take one of two forms (Section 4 gives the formal ABNF syntax):
追加の<アクセス>識別子は、2つのフォームのいずれかを取得する必要があります（セクション4に正式なABNF構文を示します）：
o <access> identifier - The name of the application, e.g., "exampleapp".
o <Access>識別子 - アプリケーションの名前、たとえば「ExamPleApp」。
o <access> identifier prefix - The name of the application, e.g., "exampleapp3", followed by a "+" and then a userid. For example, consider "exampleapp3+testuser".
o <Access>識別子プレフィックス - アプリケーションの名前、たとえば "ExampleApp3"、その後に ""、次にユーザーIDが続きます。たとえば、「Exampleapp3 Testuser」を検討してください。
Note that an <access> identifier name can also be registered as an <access> identifier prefix. However, this would require 2 separate IANA registrations.
<access>識別子名は、<cassion>識別子プレフィックスとして登録することもできます。ただし、これには2つの個別のIANA登録が必要です。
In both cases, the semantics are the same as those for "submit+", i.e., the <access> identifier or <access> identifier prefix (which MUST be followed by a userid) indicates that only a userid authorized as an application entity for the specified application is permitted to use this URL. In the case of <access> identifier prefixes, the IMAP server SHALL NOT validate the specified userid but MUST validate that the IMAP session has an authorization identity that is authorized as an application entity for the specified application.
どちらの場合も、セマンティクスは「送信」用のセマンティクスと同じです。つまり、<access>識別子または<access>識別子プレフィックス（useridが従う必要がある）は、ユーザーIDのみがアプリケーションエンティティとして許可されているユーザーIDのみを示しています。指定されたアプリケーションは、このURLを使用することができます。<access>識別子のプレフィックスの場合、IMAPサーバーは指定されたユーザーIDを検証しないものとしますが、IMAPセッションには指定されたアプリケーションのアプリケーションエンティティとして承認された承認IDがあることを検証する必要があります。
The application entity itself MAY choose to perform validation on any specified userid before attempting to retrieve the URL.
アプリケーションエンティティ自体は、URLを取得しようとする前に、指定されたユーザーIDで検証を実行することを選択できます。
The authorization granted by any <access> identifiers used as described above is self-describing, and so requires that the IMAP server provide an extensible mechanism for associating userids with new applications. For example, imagine a new application, "foo", is created that requires application entities to retrieve URLs on behalf of users. In this case, the IMAP server would need to provide a way to register the new application "foo" and to associate the set of userids to be used by those entities with the application "foo". Any attempt to retrieve URLs containing the <access> identifier "foo" would be checked for authorization against the list of userids associated with the application "foo".
上記のように使用される<cassion>識別子によって付与された承認は、自己記述であるため、IMAPサーバーがユーザーIDを新しいアプリケーションに関連付けるための拡張可能なメカニズムを提供する必要があります。たとえば、ユーザーに代わってURLを取得するためにアプリケーションエンティティを必要とする新しいアプリケーション「Foo」を想像してください。この場合、IMAPサーバーは、新しいアプリケーション「FOO」を登録し、それらのエンティティがアプリケーション「FOO」で使用するユーザーIDのセットを関連付ける方法を提供する必要があります。<cassion>識別子「foo」を含むURLを取得しようとすると、アプリケーション「FOO」に関連付けられたユーザーIDのリストに対する許可が確認されます。
Section 6 provides the template required to register new <access> identifiers or prefixes with IANA.
セクション6では、IANAにnew <access>識別子またはプレフィックスを登録するために必要なテンプレートを提供します。
One application that makes use of URLAUTH-authorized URLs is that of streaming multimedia files that are received as internet-messaging attachments. This application is described in [STREAMING].
Urlauthが許可されたURLを使用するアプリケーションの1つは、インターネットメッシングの添付ファイルとして受信されるストリーミングマルチメディアファイルのアプリケーションです。このアプリケーションは[ストリーミング]で説明されています。
See Section 6.2 for the IANA registration template for the "stream" <access> identifier.
「Stream」<Access>識別子のIANA登録テンプレートについては、セクション6.2を参照してください。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
次の構文仕様では、[RFC5234]で指定されているように、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper- or lower-case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
それ以外の場合は、言及されている場合を除き、すべてのアルファベット文字はケース非感受性です。トークン文字列を定義するために上下ケースの文字を使用することは、編集の明確性のみを目的としています。実装は、これらの文字列をケースに依存しない方法で受け入れる必要があります。
The ABNF specified below updates the formal syntax of <access> identifiers as defined in IMAP URL [RFC5092].
以下に指定されたABNFは、IMAP URL [RFC5092]で定義されている<Access>識別子の正式な構文を更新します。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2009 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
変更とバイナリ形式での再配布と使用は、変更を伴うまたは伴わない場合、次の条件が満たされている場合が許可されています。
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- ソースコードの再配布は、上記の著作権通知、この条件リスト、および次の免責事項を保持する必要があります。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- バイナリ形式の再配布は、上記の著作権通知、この条件のリスト、および分布に提供されたドキュメントおよび/またはその他の資料の次の免責事項を再現する必要があります。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- インターネット社会、IETFまたはIETFトラストの名前も、特定の貢献者の名前も、特定の事前の書面による許可なしにこのソフトウェアから派生した製品を支持または宣伝するために使用することはできません。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
このソフトウェアは、制限された著作権所有者と貢献者によって提供されます。商品性と特定の目的に対する適合性の暗黙の保証は否認されます。いかなる場合でも、著作権所有者または貢献者は、直接的、間接的、偶発的、特別な、模範的、または結果的な損害（代替品またはサービスの調達を含むがこれらに限定されない、使用の損失、データ、または利益に対して責任を負いません。ただし、契約、厳格責任、または不法行為（過失などを含む）であろうと、このソフトウェアの使用から何らかの形で発生するかどうかにかかわらず、責任の理論に起因します。
application = 1*(ALPHA/DIGIT)
access =/ application / (application "+" enc-user)
This document was inspired by discussions in the Lemonade Working Group.
この文書は、レモネードワーキンググループでの議論に触発されました。
IANA created a new registry for IMAP URLAUTH access identifiers and prefixes.
IANAは、IMAP Urlauthアクセス識別子とプレフィックスの新しいレジストリを作成しました。
Access identifiers and prefixes MUST be registered using the "IETF Review" policy [RFC5226]. This section gives the IANA registration entries for the existing access identifiers and prefixes from RFC 5092 as well as the entry for the "stream" application.
「IETFレビュー」ポリシー[RFC5226]を使用して、アクセス識別子とプレフィックスを登録する必要があります。このセクションでは、RFC 5092の既存のアクセス識別子とプレフィックスのIANA登録エントリ、および「ストリーム」アプリケーションのエントリを提供します。
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
宛先：iana@iana.org件名：IMAP URLアクセス識別子登録
Type: [Either "<access> identifier" or
"<access> identifier prefix"]
Application: [Name of the application, e.g., "stream"]
アプリケーション：[アプリケーションの名前、たとえば、「ストリーム」]
Description: [A description of the application and its use of IMAP URLs]
説明：[アプリケーションの説明とIMAP URLの使用]
RFC Number: [Number of the RFC in which the application is defined]
RFC番号：[アプリケーションが定義されているRFCの番号]
Contact: [Email and/or physical address to contact for additional information]
連絡先：[追加情報については、連絡先へのメールおよび/または物理的な住所]
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
宛先：iana@iana.org件名：IMAP URLアクセス識別子登録
Type: <access> identifier
Application: stream
アプリケーション：ストリーム
Description: Used by SIP Media Servers to retrieve attachments for streaming to email clients
説明：SIPメディアサーバーで使用して、クライアントにストリーミングするための添付ファイルを取得します
RFC Number: RFC 5593
RFC番号：RFC 5593
Contact: Neil Cook <neil.cook@noware.co.uk>
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
宛先：iana@iana.org件名：IMAP URLアクセス識別子登録
Type: <access> identifier prefix
Application: submit
申請：送信
Description: Used by message submission entities to retrieve attachments to be included in submitted messages
説明：メッセージ提出エンティティで使用されて、提出されたメッセージに含まれる添付ファイルを取得する
RFC Number: RFC 5593 and RFC 5092
RFC番号：RFC 5593およびRFC 5092
Contact: Lemonade WG <lemonade@ietf.org>
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
宛先：iana@iana.org件名：IMAP URLアクセス識別子登録
Type: <access> identifier prefix
Application: user
アプリケーション：ユーザー
Description: Used to restrict access to IMAP sessions that are logged in as the specified userid
説明：指定されたユーザーIDとしてログインされるIMAPセッションへのアクセスを制限するために使用されます
RFC Number: RFC 5593 and RFC 5092
RFC番号：RFC 5593およびRFC 5092
Contact: Lemonade WG <lemonade@ietf.org>
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
宛先：iana@iana.org件名：IMAP URLアクセス識別子登録
Type: <access> identifier
Application: authuser
アプリケーション：authuser
Description: Used to restrict access to IMAP sessions that are logged in as any non-anonymous user of that IMAP server
説明：そのIMAPサーバーの非匿名ユーザーとしてログインされるIMAPセッションへのアクセスを制限するために使用されます
RFC Number: RFC 5593 and RFC 5092
RFC番号：RFC 5593およびRFC 5092
Contact: Lemonade WG <lemonade@ietf.org>
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
宛先：iana@iana.org件名：IMAP URLアクセス識別子登録
Type: <access> identifier
Application: anonymous
アプリケーション：匿名
Description: Indicates that use of this URL is not restricted by session authorization identity
説明：このURLの使用がセッション認証IDによって制限されていないことを示します
RFC Number: RFC 5593 and RFC 5092
RFC番号：RFC 5593およびRFC 5092
Contact: Lemonade WG <lemonade@ietf.org>
The extension to <access> identifiers specified in this document provides a mechanism for extending the semantics of the "submit+" <access> prefix to arbitrary applications. The use of such additional <access> identifiers and prefixes is primarily for security purposes, i.e., to prevent the overloading of "submit+" as a generic mechanism to allow entities to retrieve IMAP URLs on behalf of userids. Other than this, the security implications are identical to those discussed in Section 10.1 of IMAPURL [RFC5092].
このドキュメントで指定されている<Access>識別子への拡張機能は、任意のアプリケーションに「access>プレフィックス」のセマンティクスを拡張するためのメカニズムを提供します。このような追加の<アクセス>識別子とプレフィックスの使用は、主にセキュリティ目的、つまり、ユーザーIDに代わってエンティティがIMAP URLを取得できるようにする一般的なメカニズムとして「送信」を防ぐためです。これ以外に、セキュリティへの影響は、Imapurl [RFC5092]のセクション10.1で説明したものと同一です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5092] Melnikov, A., Ed., and C. Newman, "IMAP URL Scheme", RFC 5092, November 2007.
[RFC5092] Melnikov、A.、ed。、およびC. Newman、「IMAP URLスキーム」、RFC 5092、2007年11月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[STREAMING] Cook, N., "Streaming Internet Messaging Attachments", Work in Progress, May 2009.
[ストリーミング] Cook、N。、「ストリーミングインターネットメッセージング添付ファイル」、2009年5月、進行中の作業。
Author's Address
著者の連絡先
Neil L Cook Cloudmark
ニールLクッククラウドマーク
EMail: neil.cook@noware.co.uk