[要約] RFC 4355は、Enumservicesの電子メール、ファックス、MMS、EMS、およびSMSのIANA登録に関する要約と目的を提供しています。
Network Working Group R. Brandner
Request for Comments: 4355 Siemens AG
Category: Standards Track L. Conroy
Siemens Roke Manor Research
R. Stastny
Oefeg
January 2006
IANA Registration for Enumservices email, fax, mms, ems, and sms
Enumservices電子メール、FAX、MMS、EMS、SMSのIANA登録
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.
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document registers the Enumservices "email", "fax", "sms", "ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC 3761.
このドキュメントは、enumservices "email"、 "fax"、 "sms"、 "ems"、および「mms」をURIスキーム「Tel： ''および 'mailto：'を登録します。3761。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Email Service Registration ......................................4
4. Fax Service Registration ........................................4
5. MMS, EMS, SMS Service ...........................................5
5.1. Introduction ...............................................5
5.2. SMS Service Registrations ..................................6
5.2.1. SMS Service Registration with tel: URI ..............6
5.2.2. SMS Service Registration with mailto: URI ...........6
5.3. EMS Service Registrations ..................................7
5.3.1. EMS Service Registration with tel: URI ..............7
5.3.2. EMS Service Registration with mailto: URI ...........8
5.4. MMS Service Registrations ..................................9
5.4.1. MMS Service Registration with tel: URI ..............9
5.4.2. MMS Service Registration with mailto: URI ..........10
6. Security Considerations ........................................11
7. Acknowledgements ...............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................14
ENUM (E.164 Number Mapping, RFC 3761 [2]) is a system that transforms E.164 numbers [3] into domain names and then uses DNS (Domain Name Service, RFC 1034 [4]) services like delegation through NS records and NAPTR records to look up what services are available for a specific domain name.
Enum（E.164番号マッピング、RFC 3761 [2]）は、E.164番号[3]をドメイン名に変換し、DNS（ドメイン名サービス、RFC 1034 [4]）サービスをNSレコードを介した委任などのシステムです。NAPTRレコードは、特定のドメイン名で利用可能なサービスを検索します。
This document registers Enumservices according to the guidelines given in RFC 3761 to be used for provisioning in the services field of a NAPTR [5] resource record to indicate what class of functionality a given endpoint offers. The registration is defined within the DDDS (Dynamic Delegation Discovery System [6][7][5][8][9]) hierarchy, for use with the "E2U" DDDS Application defined in RFC 3761.
このドキュメントは、NAPTR [5]リソースレコードのサービスフィールドでのプロビジョニングに使用されるRFC 3761に記載されているガイドラインに従って、enmservicesを登録して、特定のエンドポイントが提供する機能のクラスを示します。登録は、DDDS（動的委任ディスカバリーシステム[6] [7] [5] [8] [9]）内で定義され、RFC 3761で定義された「E2U」DDDSアプリケーションで使用します。
The following Enumservices are registered with this document: "email", "fax", "sms", "ems", and "mms". These share a common feature in that they each indicate that the functionality of the given endpoints and the associated resources are capable of receiving discrete messages, albeit of different types.
次のEnumservicesは、このドキュメントに登録されています：「電子メール」、「FAX」、「SMS」、「EMS」、および「MMS」。これらは、特定のエンドポイントと関連するリソースの機能が異なるタイプではあるが個別のメッセージを受信できることを示しているという点で共通の機能を共有しています。
According to RFC 3761, the Enumservice registered must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the Uniform Resource Identifier (URI) scheme that is the outcome of the use of it.
RFC 3761によると、登録されたEnumserviceは、あるNaptrリソースレコードを別のNaptrリソースレコードを選択する際に選択メカニズムとして機能できる必要があります。つまり、登録は、そのまさにNAPTRレコードを使用するときに予想されることを指定する必要があります。また、その使用の結果である均一なリソース識別子（URI）スキームが必要です。
Therefore, an Enumservice acts as a hint, indicating the kind of service with which the URI constructed using the regexp field is associated. There can be more than one Enumservice included within a single NAPTR; this indicates that there is more than one service that can be achieved using the associated URI scheme.
したがって、Enumserviceはヒントとして機能し、URIがRegexpフィールドを使用して構築されたサービスの種類を示しています。単一のNAPTRには複数のEnumserviceが含まれています。これは、関連するURIスキームを使用して達成できる複数のサービスがあることを示しています。
The common thread with this set of definitions is that they reflect the kind of service that the end-user will hope to achieve with the communication using the associated URI.
この一連の定義セットの共通スレッドは、エンドユーザーが関連するURIを使用してコミュニケーションで達成したいと考えているサービスの種類を反映していることです。
The services specified here are intended not to specify the protocol or even method of connection that must be used to achieve each service. Instead they define the kind of interactive behaviour that an end-user will expect, leaving the end system to decide (based on policies outside the remit of this specification) how to execute the service.
ここで指定されているサービスは、各サービスを達成するために使用する必要があるプロトコルまたは接続方法を指定しないことを目的としています。代わりに、エンドユーザーが予想するインタラクティブな動作の種類を定義し、最終システムに（この仕様の送金以外のポリシーに基づいて）サービスの実行方法を決定します。
Since the same URI scheme may be used for different services (e.g., 'tel:'), and the same kind of service may use different URI schemes (e.g., for VoIP 'h323:' and 'tel:' may be used), it is necessary in some cases to specify the service and the URI scheme used.
同じURIスキームが異なるサービス（例： 'Tel：'）に使用される場合があり、同じ種類のサービスが異なるURIスキームを使用する可能性があるため（例：voip 'h323：'および 'tel：'が使用される場合があります）、場合によっては、使用されるサービスとURIスキームを指定する必要があります。
The service parameters defined in RFC 3761 allow, therefore, a "type" and a "subtype" to be specified. Within this set of specifications, the convention is assumed that the "type" (being the more generic term) defines the service and the "subtype" defines the URI scheme.
Even where currently only one URI scheme is associated with a given service, it should be considered that an additional URI scheme to be used with this service may be added later. Thus, the subtype is needed to identify the specific Enumservice intended.
現在1つのURIスキームのみが特定のサービスに関連付けられている場合でも、このサービスで使用する追加のURIスキームが後で追加される可能性があると考える必要があります。したがって、意図した特定のEnumserviceを識別するためにサブタイプが必要です。
In this document, there are two URI schemes that are used within the various services. These are 'tel:', as specified in RFC 3966 [10] and 'mailto:', as specified in RFC 2368 [11].
このドキュメントには、さまざまなサービス内で使用される2つのURIスキームがあります。これらは、RFC 3966 [10]および「Mailto：」で指定されている「Tel：」です。RFC2368[11]で指定されています。
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 BCP 14, RFC 2119 [1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
Enumservice Name: "email"
Enumservice名：「電子メール」
Enumservice Type: "email"
Enumserviceタイプ：「電子メール」
Enumservice Subtypes: "mailto"
Enumserviceサブタイプ： "mailto"
URI Scheme: 'mailto:'
URIスキーム：「Mailto：」
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource can be addressed by the associated URI scheme in order to send an email.
このEnumserviceは、電子メールを送信するために、関連するURIスキームによってリモートリソースに対処できることを示しています。
Security Considerations:
セキュリティ上の考慮事項：
See Section 6.
セクション6を参照してください。
Intended Usage: COMMON
意図された使用法：共通
Authors:
著者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
Any other information the author deems interesting:
著者が興味深いと思うその他の情報：
None
Enumservice Name: "fax"
Enumservice名：「FAX」
Enumservice Type: "fax"
Enumserviceタイプ：「FAX」
Enumservice Subtype: "tel"
Enumserviceサブタイプ： "Tel"
URI Scheme: 'tel:'
URIスキーム：「Tel：」
Functional Specification:
機能仕様：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of being contacted to provide a communication session during which facsimile documents can be sent.
このEnumserviceは、関連するURIスキームによって識別されるリソースが連絡できることを示しており、ファクシミリドキュメントを送信できる通信セッションを提供します。
Clients selecting this NAPTR will have support for generating and sending facsimile documents to the recipient using the Public Switched Telephone Network (PSTN) session and transfer protocols specified in [12] and [13]. In short, they will have a fax program with a local or shared PSTN access over which they can send faxes.
このNAPTRを選択するクライアントは、[12]および[13]で指定された公開された電話ネットワーク（PSTN）セッションと転送プロトコルを使用して、受信者にファクシミリドキュメントを生成および送信することをサポートします。要するに、彼らはファックスを送ることができるローカルまたは共有PSTNアクセスを備えたFAXプログラムを持っています。
Security Considerations:
セキュリティ上の考慮事項：
See Section 6.
セクション6を参照してください。
Intended Usage: COMMON
意図された使用法：共通
Authors:
著者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see Authors' Addresses section)
Rudolf Brandner、Lawrence Conroy、Richard Stastny（著者の連絡先の詳細については、著者のアドレスセクションを参照）
Any other information the author deems interesting:
著者が興味深いと思うその他の情報：
None
なし
An ENUM NAPTR indicates ability on the part of the Subscriber to receive specified communication service (or services) provided via the contact address (shown in the generated URI).
Enum NAPTRは、サブスクライバー側の能力を示し、連絡先アドレスを介して提供される指定された通信サービス（またはサービス）を受け取る能力（生成されたURIに表示）を示します。
In the case of MMS, EMS, and SMS services, the capability of these services is a nested superset; thus, a service supporting MMS can support also delivery of EMS or SMS message content to a recipient that is receiving a Multimedia Message, whilst a service supporting EMS can also deliver SMS message content to a recipient that can accept receipt of EMS Messages.
MMS、EMS、およびSMSサービスの場合、これらのサービスの機能はネストされたスーパーセットです。したがって、MMSをサポートするサービスは、EMSまたはマルチメディアメッセージを受信している受信者にEMSまたはSMSメッセージコンテンツの配信をサポートできますが、EMSをサポートするサービスは、EMSメッセージの受信を受信できる受信者にSMSメッセージコンテンツを配信することもできます。
Thus, even if a client wants only to generate and send content that could be carried in an SMS message, the client MAY choose to consider also NAPTRs holding EMS and/or MMS Enumservices, as these indicate that the destination can accept EMS and/or MMS messages. These services will be able to deliver SMS content to the recipient address.
したがって、クライアントがSMSメッセージに携帯できるコンテンツのみを生成して送信することを希望している場合でも、クライアントはEMSおよび/またはMMS Enumservicesを保持しているNAPTRも検討することを選択できます。MMSメッセージ。これらのサービスは、SMSコンテンツを受信者アドレスに配信できます。
Conversely, a client capable of sending MMS messages may choose to consider also NAPTRs indicating support for EMS or SMS messages (assuming that the network to which it is connected provides these services as well, or is capable of providing a gateway to systems that do provide these services). In taking this choice, it would have to "downgrade" its User Interface to allow only generation of content that conforms to SMS or EMS standards.
逆に、MMSメッセージを送信できるクライアントは、EMSまたはSMSメッセージのサポートを示すNAPTRも検討することを選択できます（接続されているネットワークがこれらのサービスも提供する、または提供するシステムへのゲートウェイを提供できると仮定しますこれらのサービス）。この選択をするには、SMSまたはEMS標準に準拠するコンテンツの生成のみを許可するために、ユーザーインターフェイスを「ダウングレード」する必要があります。
These behaviours on the part of the client are purely optional and are NOT the subject of any protocol standardisation.
クライアント側のこれらの動作は純粋にオプションであり、プロトコル標準化の対象ではありません。
Enumservice Name: "sms"
Enumservice Type: "sms"
Enumserviceタイプ：「SMS」
Enumservice Subtypes: "tel"
Enumserviceサブタイプ： "Tel"
URI Scheme: 'tel:'
URIスキーム：「Tel：」
Functional Specification:
機能仕様：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using the Short Message Service (SMS) [14].
このEnumserviceは、関連するURIスキームによって識別されるリソースが、短いメッセージサービス（SMS）[14]を使用してメッセージを受信できることを示しています。
Security Considerations:
セキュリティ上の考慮事項：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
このEnumserviceには具体的なセキュリティの問題はありません。ただし、セクション6の一般的な考慮事項が適用されます。
Intended Usage: COMMON
意図された使用法：共通
Authors:
著者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
Rudolf Brandner、Lawrence Conroy、Richard Stastny（著者の連絡先の詳細については、著者のアドレスセクションを参照）
Any other information the author deems interesting:
著者が興味深いと思うその他の情報：
None
なし
Enumservice Name: "sms"
Enumservice名：「SMS」
Enumservice Type: "sms"
Enumserviceタイプ：「SMS」
Enumservice Subtypes: "mailto"
URI Scheme: 'mailto:'
Functional Specification:
機能仕様：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using an email protocol.
このEnumserviceは、関連するURIスキームによって識別されるリソースが、電子メールプロトコルを使用してメッセージを受信できることを示しています。
SMS content is sent over SMTP using the format specified by TS 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4, as an MMS message. Within such a message, SMS content is carried as either a text or application/octet-stream MIME sub-part (see TS 26.140 [16] Section 4.1).
SMSコンテンツは、MMSメッセージとしてTS 23.140 [15]セクション8.4.4およびTS 26.140 [16]セクション4で指定された形式を使用してSMTPを介して送信されます。このようなメッセージ内で、SMSコンテンツはテキストまたはアプリケーション/オクテットストリームMIMEサブパートのいずれかとして運ばれます（TS 26.140 [16]セクション4.1を参照）。
Security Considerations:
セキュリティ上の考慮事項：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
このEnumserviceには具体的なセキュリティの問題はありません。ただし、セクション6の一般的な考慮事項が適用されます。
Intended Usage: COMMON
意図された使用法：共通
Authors:
著者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
Rudolf Brandner、Lawrence Conroy、Richard Stastny（著者の連絡先の詳細については、著者のアドレスセクションを参照）
Any other information the author deems interesting:
著者が興味深いと思うその他の情報：
None
なし
Enumservice Name: "ems"
Enumservice名：「EMS」
Enumservice Type: "ems"
Enumservice Subtype: "tel"
URI Scheme: 'tel:'
URIスキーム：「Tel：」
Functional Specification:
機能仕様：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using the Enhanced Message Service (EMS) [14].
Security Considerations:
セキュリティ上の考慮事項：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
このEnumserviceには具体的なセキュリティの問題はありません。ただし、セクション6の一般的な考慮事項が適用されます。
Intended Usage: COMMON
意図された使用法：共通
Authors:
著者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
Rudolf Brandner、Lawrence Conroy、Richard Stastny（著者の連絡先の詳細については、著者のアドレスセクションを参照）
Any other information the author deems interesting:
著者が興味深いと思うその他の情報：
Note that an indication of EMS can be taken as implying that the recipient is capable of receiving SMS messages at this address as well.
EMSの兆候は、受信者がこのアドレスでSMSメッセージを受信できることを暗示すると見なすことができることに注意してください。
Enumservice Name: "ems"
Enumservice名：「EMS」
Enumservice Type: "ems"
Enumserviceタイプ：「EMS」
Enumservice Subtypes: "mailto"
Enumserviceサブタイプ： "mailto"
URI Scheme: 'mailto:'
URIスキーム：「Mailto：」
Functional Specification:
機能仕様：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using an email protocol.
EMS content is sent over SMTP using the format specified by TS 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4, as an MMS message. Within such a message, EMS content is carried as either a text or application/octet-stream MIME sub-part (see TS 26.140 [16] section 4.1).
EMSコンテンツは、MMSメッセージとしてTS 23.140 [15]セクション8.4.4およびTS 26.140 [16]セクション4で指定された形式を使用してSMTPを介して送信されます。このようなメッセージ内で、EMSコンテンツはテキストまたはアプリケーション/オクテットストリームMIMEサブパートのいずれかとして運ばれます（TS 26.140 [16]セクション4.1を参照）。
Security Considerations:
セキュリティ上の考慮事項：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
このEnumserviceには具体的なセキュリティの問題はありません。ただし、セクション6の一般的な考慮事項が適用されます。
Intended Usage: COMMON Authors:
意図された使用法：一般的な著者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
Rudolf Brandner、Lawrence Conroy、Richard Stastny（著者の連絡先の詳細については、著者のアドレスセクションを参照）
Any other information the author deems interesting:
著者が興味深いと思うその他の情報：
None
なし
Enumservice Name: "mms"
Enumservice名：「MMS」
Enumservice Type: "mms"
Enumserviceタイプ：「MMS」
Enumservice Subtype: "tel"
Enumserviceサブタイプ： "Tel"
URI Scheme: 'tel:'
URIスキーム：「Tel：」
Functional Specification:
機能仕様：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using the Multimedia Messaging Service (MMS) [15].
このEnumserviceは、関連するURIスキームによって特定されたリソースが、マルチメディアメッセージングサービス（MMS）[15]を使用してメッセージを受信できることを示しています。
Security Considerations:
セキュリティ上の考慮事項：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
このEnumserviceには具体的なセキュリティの問題はありません。ただし、セクション6の一般的な考慮事項が適用されます。
Intended Usage: COMMON
意図された使用法：共通
Authors:
著者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
Rudolf Brandner、Lawrence Conroy、Richard Stastny（著者の連絡先の詳細については、著者のアドレスセクションを参照）
Any other information the author deems interesting:
著者が興味深いと思うその他の情報：
Note that MMS can be used as an alternative to deliver an SMS RP-DATA RPDU if, for example, the SMS bearer is not supported. If an entry includes this Enumservice, then in effect this can be taken as implying that the recipient is capable of receiving EMS or SMS messages at this address. Such choices on the end system design do have two small caveats; whilst in practice all terminals supporting MMS today support SMS as well, it might not necessarily be the case in the future, and there may be tariff differences in using the MMS rather than using the SMS or EMS.
たとえば、SMSベアラーがサポートされていない場合、MMSはSMS RP-DATA RPDUを提供するための代替として使用できることに注意してください。エントリにこのEnumserviceが含まれている場合、事実上、これは受信者がこのアドレスでEMSまたはSMSメッセージを受信できることを暗示していると見なすことができます。エンドシステム設計のこのような選択には、2つの小さな注意事項があります。実際には、MMSをサポートするすべてのターミナルもSMSをサポートしていますが、将来的には必ずしも当てはまるわけではなく、SMSまたはEMSを使用するのではなく、MMSの使用に関税の違いがあるかもしれません。
Enumservice Name: "mms"
Enumservice名：「MMS」
Enumservice Type: "mms"
Enumserviceタイプ：「MMS」
Enumservice Subtypes: "mailto"
Enumserviceサブタイプ： "mailto"
URI Scheme: 'mailto:'
URIスキーム：「Mailto：」
Functional Specification:
機能仕様：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using an email protocol.
このEnumserviceは、関連するURIスキームによって識別されるリソースが、電子メールプロトコルを使用してメッセージを受信できることを示しています。
MMS messages are sent over SMTP using the format specified by TS 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4.
MMSメッセージは、TS 23.140 [15]セクション8.4.4およびTS 26.140 [16]セクション4で指定された形式を使用してSMTPを介して送信されます。
Within and between MMS Environments (MMSE, network infrastructures that support the MultiMedia Service), other pieces of state data (for example, charging-significant information) are exchanged between MMS Relay Servers. Thus, although these servers use SMTP as the "bearer" for their application exchanges, they map their internal state to specialised headers carried in the SMTP message exchanges. The headers used in such MMSE are described in detail in [17].
MMS環境内および間およびその間（MMSE、マルチメディアサービスをサポートするネットワークインフラストラクチャ）、他の状態データ（たとえば、重要な情報を充電する）がMMSリレーサーバー間で交換されます。したがって、これらのサーバーはアプリケーション交換の「ベアラー」としてSMTPを使用していますが、内部状態をSMTPメッセージ交換で運ばれる専門のヘッダーにマッピングします。このようなMMSEで使用されるヘッダーは、[17]で詳細に説明されています。
Security Considerations:
セキュリティ上の考慮事項：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
このEnumserviceには具体的なセキュリティの問題はありません。ただし、セクション6の一般的な考慮事項が適用されます。
Intended Usage: COMMON
意図された使用法：共通
Authors:
著者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see Authors' Addresses section)
Rudolf Brandner、Lawrence Conroy、Richard Stastny（著者の連絡先の詳細については、著者のアドレスセクションを参照）
Any other information the author deems interesting:
著者が興味深いと思うその他の情報：
The MMS Architecture describes an interface between the MMSE and "legacy messaging systems" (labelled as MM3) that accepts
MMSアーキテクチャは、MMSEと「レガシーメッセージングシステム」（MM3とラベル付け）の間のインターフェイスを説明しています。
"standard" SMTP messages. Thus, although the MMS Relay Server that supports this interface appears as a standard SMTP server from the perspective of an Internet-based mail server, it acts as a gateway and translator, adding the internal state data that is used within and between the MMS Environments. This mechanism is described in [17], which also includes references to the specifications agreed by those bodies responsible for the design of the MMS.
「標準」SMTPメッセージ。したがって、このインターフェイスをサポートするMMSリレーサーバーは、インターネットベースのメールサーバーの観点から標準のSMTPサーバーとして表示されますが、ゲートウェイと翻訳者として機能し、MMS環境内およびMMS環境間で使用される内部状態データを追加します。。このメカニズムは[17]で説明されています。これには、MMSの設計に責任がある身体によって合意された仕様への参照も含まれています。
DNS, as used by ENUM, is a global, distributed database. Thus, any information stored there is visible to anyone anonymously. Whilst this is not qualitatively different from publication in a Telephone Directory, it does open data subjects to having "their" information collected automatically without any indication that this has been done or by whom.
enumで使用されるDNSは、グローバルな分散データベースです。したがって、そこに保存されている情報は、匿名で誰にも表示されます。これは電話ディレクトリに公開されることと定性的に違いはありませんが、これが行われたことを示すことなく、「彼らの」情報を自動的に収集する「」情報をオープンします。
Such data harvesting by third parties is often used to generate lists of targets for unrequested information; in short, they are used to address "spam". Anyone who uses a Web-archived mailing list is aware that the volume of "spam" email they are sent increases when they post to the mailing list. Publication of a telephone number in ENUM is no different, and may be used to send "junk faxes" or "junk SMS", for example.
サードパーティによるこのようなデータ収穫は、多くの場合、要求されていない情報のターゲットのリストを生成するために使用されます。要するに、それらは「スパム」に対処するために使用されます。Webアーカイブメーリングリストを使用する人は誰でも、送信される「スパム」メールのボリュームがメーリングリストに投稿すると増加することを認識しています。Enumでの電話番号の公開も例外ではなく、たとえば「ジャンクファックス」または「ジャンクSMS」を送信するために使用できます。
Many mailing list users have more than one email address and use "sacrificial" email accounts when posting to such lists to help filter out unrequested emails sent to them. This is not so easy with published telephone numbers; the PSTN E.164 number assignment process is much more involved, and usually a single E.164 number (or a fixed range of numbers) is associated with each PSTN access. Thus, providing a "sacrificial" phone number in any publication is not possible.
多くのメーリングリストのユーザーは、複数のメールアドレスを持っており、そのようなリストに投稿するときに「犠牲」メールアカウントを使用して、送信されていない要求のない電子メールをフィルタリングするのに役立ちます。これは、公開された電話番号ではそれほど簡単ではありません。PSTN E.164番号割り当てプロセスがはるかに複雑であり、通常、単一のE.164数（または固定範囲の数値）が各PSTNアクセスに関連付けられています。したがって、どの出版物でも「犠牲的な」電話番号を提供することは不可能です。
Due to the implications of publishing data on a globally accessible database, as a principle, data subjects MUST give their explicit informed consent to data being published in ENUM.
原則として、グローバルにアクセス可能なデータベースにデータを公開することの意味があるため、データ主体はenumで公開されているデータに明示的なインフォームドコンセントを与えなければなりません。
In addition, they should be made aware that, due to storage of such data during harvesting by third parties, removal of the data from publication will not remove any copies that have been taken; in effect, any publication may be permanent.
さらに、第三者による収穫中にそのようなデータを保存したため、出版物からのデータの削除が取得されたコピーを削除しないことを認識する必要があります。事実上、どの出版物も永続的である可能性があります。
However, regulations in many regions will require that data subjects can at any time request that the data is removed from publication and that their consent for its publication is explicitly confirmed at regular intervals.
ただし、多くの地域の規制では、データ主体はいつでもデータが公開から削除され、その出版物の同意が定期的に明示的に確認されることを要求することができます。
When placing a fax call via the PSTN or a sending a message via the Public Land Mobile Network, the sender may be charged for this action. In both kinds of network, calling or messaging to some numbers is more expensive than sending to others; both networks have "premium rate" services that can charge considerably more than a "normal" call or message destination. As such, it is important that end-users be asked to confirm sending the message and that the destination number be presented to them. It is the originating user's choice on whether or not to send a message to this destination number, but end-users SHOULD be shown the destination number so that they can make this decision.
PSTNを介してFAXコールを配置したり、Public Land Mobile Networkを介してメッセージを送信したりすると、このアクションに対して送信者が請求される場合があります。どちらの種類のネットワークでも、一部の数値への呼び出しまたはメッセージングは、他の数字に送信するよりも高価です。両方のネットワークには、「通常の」通話やメッセージの宛先よりもかなり多く請求できる「プレミアムレート」サービスがあります。そのため、エンドユーザーをメッセージの送信を確認するように求められ、宛先番号を提示することが重要です。これは、この宛先番号にメッセージを送信するかどうかについてのユーザーの選択ですが、エンドユーザーにこの決定を下すことができるように宛先番号を表示する必要があります。
Although a fax number, like other E.164 numbers, doesn't appear to reveal as much identity information about a user as a name in the format user@host (e.g., an email or SIP address), the information is still publicly available; thus, there is still the risk of unwanted communication.
FAX番号は、他のE.164番号と同様に、Format user@host（電子メールやSIPアドレスなど）の名前としてユーザーに関する多くの身元情報を明らかにしているようには見えませんが、情報はまだ公開されています;したがって、不要なコミュニケーションのリスクがまだあります。
An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC [18] to these, is provided in RFC 3761 [2]. A thorough analysis of threats to the DNS itself is covered in RFC 3833 [19].
DNSへの酵素の依存性に特有の脅威の分析、およびこれらへのDNSSEC [18]の適用可能性は、RFC 3761 [2]で提供されています。DNS自体に対する脅威の徹底的な分析は、RFC 3833でカバーされています[19]。
An email address is a canonical address by which a user is known. Placing this address in ENUM is comparable to placing a SIP or H.323 address in the DNS.
メールアドレスは、ユーザーが既知の標準的なアドレスです。このアドレスを列挙に配置することは、DNSにSIPまたはH.323アドレスを配置することに匹敵します。
DNS does not make any policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM NAPTR resource record must, therefore, be considered to be open to the public, which is a cause for some privacy considerations.
DNSは、Inquirerと共有する記録についてポリシー決定を下しません。すべてのDNSレコードは、常にすべての問い合わせ者が利用できると想定する必要があります。したがって、Enum Naptrリソースレコード内で提供される情報は、公開されていると見なされなければなりません。これは、プライバシーに関する考慮事項の原因です。
Therefore, ENUM Subscribers should be made aware of this risk. Since it is within the responsibility of the ENUM Subscriber which data is entered in ENUM, it is within the ENUM Subscriber's control if he enters email addresses:
したがって、列挙者はこのリスクを認識する必要があります。列挙されたサブスクライバーの責任の範囲内であるため、列挙されたデータが入力されているため、メールアドレスを入力すると、サブスクライバーのコントロール内にあります。
1. allowing inference of private data, e.g., his first and last name 2. at all
1. プライベートデータの推論を許可します。たとえば、彼の姓と姓2
It should also be considered that it is the purpose of public communication identifiers to be publicly known. To reduce spam and other unwanted communication, other means should be made available, such as incoming message filtering.
また、公共のコミュニケーション識別子の目的であることも考慮されるべきです。スパムやその他の不要な通信を減らすには、受信メッセージフィルタリングなど、他の手段を利用できるようにする必要があります。
Some Value Added Service Providers use receipt of a short message to a given special service telephone number as a trigger to start delivery of data messages to the calling number. By sending an SMS (or, in principle, an EMS or MMS) to one of these special service numbers, one is entering into a contract to pay for receipt of a set of messages containing information (e.g., news, sports results, "ring tones").
一部の付加価値サービスプロバイダーは、指定された特別なサービス電話番号への短いメッセージの受信を、呼び出し番号へのデータメッセージの配信を開始するトリガーとして使用します。これらの特別なサービス番号のいずれかにSMS（または原則としてEMSまたはMMS）を送信することにより、情報を含むメッセージのセットを受信するために契約を結びます（例：ニュース、スポーツ結果、「リング」リングトーン "）。
Thus, it is very important that the end terminal presents the destination number to which any message is to be sent using the "sms: tel", "ems:tel", or "mms:tel" Enumservices, to allow the end-user to cancel any message before it is sent to one of these numbers.
したがって、エンドユーザーがエンドユーザーを許可するために、「SMS：Tel」、「EMS：Tel」、または「MMS：TEL」Enamservicesを使用して送信されるメッセージが送信される宛先番号をエンド端末に提示することが非常に重要です。これらの番号のいずれかに送信される前に、任意のメッセージをキャンセルします。
At present, these systems use the circuit switched network trusted calling line identifier to identify the destination for the subsequent charged information messages, and so it is believed that sending using the "sms:mailto", "ems:mailto", or "mms:mailto" Enumservices does not have this risk currently.
現在、これらのシステムは、回路スイッチ付きネットワーク信頼性の呼び出しライン識別子を使用して、後続の充電された情報メッセージの宛先を識別するため、「SMS：MailTo」、「EMS：MailTo」、または「MMSを使用して送信すると考えられています。Mailto "Enumservicesには現在、このリスクはありません。
Many thanks to Ville Warsta for his close reading of the document and extracting the right references. Thanks also to those who are involved in the parallel effort to specify the requirements for "real world" ENUM trials resulting in TS 102 172 [20], in which this and other Enumservices are referenced.
ドキュメントを詳しく読んで、適切な参照を抽出してくれたVille Warstaに感謝します。また、TS 102 172 [20]をもたらす「現実世界」の列挙試験の要件を指定するための並行努力に関与している人にも感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[2] Faltstrom、P。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[3] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.
[3] ITU-T、「国際公開通信番号計画」、推奨事項E.164、1997年5月。
[4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987.
[4] Mockapetris、P。、「ドメイン名 - 概念と施設」、RFC 1034、1987年11月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[5] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[6] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[7] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート2：アルゴリズム」、RFC 3402、2002年10月。
[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[8] Mealling、M。、「動的委任発見システム（DDDS）パート4：ユニフォームリソース識別子（URI）」、RFC 3404、2002年10月。
[9] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[9] Mealling、M。、「動的委任発見システム（DDDS）パート5：URI.ARPA割り当て手順」、RFC 3405、2002年10月。
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[10] Schulzrinne、H。、「電話番号のためのTel URI」、RFC 3966、2004年12月。
[11] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[11] Hoffman、P.、Masinter、L。、およびJ. Zawinski、「The Mailto URL Scheme」、RFC 2368、1998年7月。
[12] ITU-T, "Standardization of Group 3 facsimile terminals for document transmission", Recommendation T.4, April 1999.
[12] ITU-T、「ドキュメント伝送のためのグループ3ファクシミリ端子の標準化」、推奨T.4、1999年4月。
[13] ITU-T, "Procedures for document facsimile transmission in the general switched telephone network", Recommendation T.30, April 1999.
[13] ITU-T、「一般的な切り替えの電話ネットワークにおけるドキュメントファクシミリ送信の手順」、推奨T.30、1999年4月。
[14] 3GPP, "Technical realization of the Short Message Service (SMS); (Release5)", 3GPP TS 23.040.
[14] 3GPP、「短いメッセージサービス（SMS）;（リリース5）の技術的実現」、3GPP TS 23.040。
[15] 3GPP, "Multimedia Messaging Service (MMS); Functional description; Stage 2 (Release 5)", 3GPP TS 23.140.
[15] 3GPP、「マルチメディアメッセージングサービス（MMS）;機能説明;ステージ2（リリース5）」、3GPP TS 23.140。
[16] 3GPP, "Multimedia Messaging Service (MMS); Media formats and codecs; (Release 5)", 3GPP TS 26.140.
[16] 3GPP、「マルチメディアメッセージングサービス（MMS）、メディア形式とコーデック、（リリース5）」、3GPP TS 26.140。
[17] Gellens, R., "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", RFC 4356, January 2006.
[17] Gellens、R。、「マルチメディアメッセージングサービス（MMS）とインターネットメールのマッピング」、RFC 4356、2006年1月。
[18] Arends, R. and et al. , "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[18] Arends、R。and et al。、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月。
[19] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[19] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[20] ETSI, "Minimum Requirements for Interoperability of ENUM Implementations", ETSI TS 102 172, January 2005.
[20] ETSI、「列挙実装の相互運用性に関する最小要件」、ETSI TS 102 172、2005年1月。
Authors' Addresses
著者のアドレス
Rudolf Brandner Siemens AG Hofmannstr. 51 81359 Munich Germany
Rudolf Brandner Siemens AG Hofmannstr。51 81359ミュンヘンドイツ
Phone: +49-89-722-51003
EMail: rudolf.brandner@siemens.com
Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey United Kingdom
ローレンス・コンロイ・シーメンス・ローク・マナー研究ローク・マナー・ロムジー・イギリス
Phone: +44-1794-833666
EMail: lwc@roke.co.uk
Richard Stastny Oefeg Postbox 147 1103 Vienna Austria
リチャード・スタストニー・オフェグ・ポストボックス147 1103ウィーン・オーストリア
Phone: +43-664-420-4100
EMail: Richard.stastny@oefeg.at
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。