RFC5365 日本語訳
5365 Multiple-Recipient MESSAGE Requests in the Session InitiationProtocol (SIP). M. Garcia-Martin, G. Camarillo. October 2008. (Format: TXT=41393 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Garcia-Martin
Request for Comments: 5365 G. Camarillo
Category: Standards Track Ericsson
October 2008
コメントを求めるワーキンググループM.ガルシア-マーチンの要求をネットワークでつないでください: 5365年のG.キャマリロカテゴリ: 標準化過程エリクソン2008年10月
Multiple-Recipient MESSAGE Requests in
the Session Initiation Protocol (SIP)
セッション開始プロトコルにおける複数の受取人メッセージ要求(一口)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list.
このドキュメントはSIP UserエージェントClient(UAC)が1セットの目的地にSIP MESSAGE要求を送ることができるメカニズムを指定します、SIP URI-リスト(Uniform Resource Identifierリスト)サービスを利用することによって。 UACはMESSAGE URI-リストサービスにURIリストに伴うペイロードを含んでいるSIP MESSAGE要求を送ります。リストにそれぞれのURIにペイロードを含めるのを含んでいて、サービスはMESSAGE要求を送ります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. URI-List Document . . . . . . . . . . . . . . . . . . . . . . 5
5. Option-Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Procedures at the User Agent Client . . . . . . . . . . . . . 6
7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 7
7.1. Determining the Intended Recipient . . . . . . . . . . . . 8
7.2. Creating an Outgoing MESSAGE Request . . . . . . . . . . . 8
7.3. Composing Bodies in the Outgoing MESSAGE Request . . . . . 10
8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . 11
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 概要. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4。 URIリストドキュメント. . . . . . . . . . . . . . . . . . . . . . 5 5。 オプションタグ.6 6。 ユーザエージェントのクライアント. . . . . . . . . . . . . 6 7における手順。 メッセージURIリストサービス. . . . . . . . . . 7 7.1における手順。 意図している受取人. . . . . . . . . . . . 8 7.2を決定します。 送信されるメッセージ要求. . . . . . . . . . . 8 7.3を作成します。 送信されるメッセージ要求. . . . . 10 8でボディーを構成します。 UAS. . . . . . . . . . . . . . . . . . . . 11 9の手順。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 15 11。 IANA問題. . . . . . . . . . . . . . . . . . . . . 15 12。 承認. . . . . . . . . . . . . . . . . . . . . . . 15 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 16 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 17
Garcia-Martin & Camarillo Standards Track [Page 1] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[1ページ]RFC5365一口
1. Introduction
1. 序論
RFC 3261 (SIP) [RFC3261] is extended by RFC 3248 [RFC3428] to carry instant messages in MESSAGE requests. SIP-based messaging, as described in RFC 3428 [RFC3428], does not provide a mechanism to send the same request to multiple recipients or replying to all recipients of a SIP MESSAGE request. This memo addresses these functions.
RFC3261(SIP)[RFC3261]は、MESSAGE要求におけるインスタントメッセージを運ぶためにRFC3248[RFC3428]によって広げられます。 RFC3428[RFC3428]で説明されるSIPベースのメッセージングは、複数の受取人かSIP MESSAGE要求のすべての受取人に答えるのに同じ要求を送るためにメカニズムを提供しません。 このメモはこれらの機能を扱います。
A first requirement can be expressed as:
以下として最初の要件を言い表すことができます。
REQ-1: It must be possible for a user to send an instant message
request to an ad hoc group, where the identities of the recipients
are carried in the message itself.
REQ-1: ユーザがインスタントメッセージ要求を専門家班に送るのは、可能であるに違いありません。(そこでは、受取人のアイデンティティがメッセージ自体で運ばれます)。
One possibility to fulfill the above requirement is to establish a session of instant messages with an instant messaging conference server, and exchange the messages, for example, using MSRP (Message Session Relay Protocol) [RFC4975]. While this option seems to be reasonable in many cases, in other situations the sending user just wants to send a small pager-mode instant message to an ad hoc group without the burden of setting up a session. This document focuses on sending a pager-mode instant message to a number of intended recipients.
上記の要件を実現させる1つの可能性がインスタントメッセージング会議サーバとのインスタントメッセージのセッションを確立することであり、交換は例えばMSRP(メッセージSession Relayプロトコル)[RFC4975]を使用するメッセージです。 このオプションは多くの場合、妥当であるように思えますが、他の状況で、送付ユーザはセッションをセットアップする負担なしでただ小さいポケットベルモードインスタントメッセージを専門家班に送りたがっています。 このドキュメントは、ポケットベルモードインスタントメッセージを多くの意図している受取人に送るのは焦点を合わせます。
To meet the requirement with a pager-mode instant message, we allow SIP MESSAGE requests carry recipient-list bodies, i.e., URI lists in body parts whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list', as specified in RFC 5363 [RFC5363]. A SIP MESSAGE URI-list service, which is a specialized application service, receives the request and sends a MESSAGE request including the received payload to each of the URIs in the list. Each of these MESSAGE requests contains a copy of the body included in the original MESSAGE request.
ポケットベルモードインスタントメッセージで条件を満たすために、私たちは受取人リスト本体(すなわち、身体の部分の'受取人リスト'が指定されるとしてRFC5363[RFC5363]のだれのContent-気質(RFC2183)[RFC2183]であるかというURIリスト)を要求が運ぶSIP MESSAGEに許します。 SIP MESSAGE URI-リストサービス(専門化しているアプリケーション・サービスである)は、要求を受け取って、リストのそれぞれのURIに容認されたペイロードを含むMESSAGE要求を送ります。 それぞれのこれらのMESSAGE要求はオリジナルのMESSAGE要求にボディーを含むコピーを含んでいます。
A second requirement addresses the "Reply-To-All" functionality:
2番目の要件は「すべてに関する回答」の機能性を扱います:
REQ-2: It MUST be possible for the recipient of a group instant
message to send a message to all other participants that received
the same group instant message (i.e., Reply-To-All).
REQ-2: グループインスタントメッセージの受取人が同じグループインスタントメッセージ(すなわち、すべてへのReply)を受け取った他のすべての関係者にメッセージを送るのは、可能であるに違いありません。
To meet this requirement, we provide a mechanism whereby the MESSAGE URI-list service also includes a URI list in body parts whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list-history', as specified in RFC 5364 [RFC5364]. The 'recipient-list-history' body is sent along with the instant message payload in each of the instant messages sent to the recipients.
この必要条件を満たすために、私たちはまたMESSAGE URI-リストサービスが身体の部分の'受取人リスト歴史'が指定されるとしてRFC5364[RFC5364]のだれのContent-気質(RFC2183)[RFC2183]であるかというURIリストを含んでいるメカニズムを提供します。 インスタントメッセージペイロードと共に受取人に送られたそれぞれに関するインスタントメッセージで'受取人リスト歴史'ボディーを送ります。
Garcia-Martin & Camarillo Standards Track [Page 2] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[2ページ]RFC5365一口
The User Agent Client (UAC) that sends a MESSAGE request to a MESSAGE URI-list service needs to be configured with the SIP URI of the service that provides the functionality. Discovering and provisioning of this URI to the UAC is outside the scope of this document.
MESSAGE URI-リストサービスにMESSAGE要求を送るUserエージェントClient(UAC)は、機能性を提供するサービスのSIP URIによって構成される必要があります。 このドキュメントの範囲の外にUACへのこのURIの発見と食糧を供給することがあります。
2. Terminology
2. 用語
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 [RFC2119] and indicate requirement levels for compliant implementations.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが本書ではこと解釈されるのは中でBCP14について説明しました、RFC2119[RFC2119]であり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
This document reuses the following terminology defined in RFC 3261 [RFC3261]:
このドキュメントはRFC3261[RFC3261]で定義された以下の用語を再利用します:
o Address-of-Record (AOR)
o 記録されている住所(AOR)
o User Agent (UA)
o ユーザエージェント(Ua)
o User Agent Client (UAC)
o ユーザエージェントのクライアント(UAC)
o User Agent Server (UAS)
o ユーザエージェントサーバ(UAS)
This document defines the following new terms:
このドキュメントは次の新学期を定義します:
MESSAGE URI-list service: A specialized URI-list service that
receives a MESSAGE request with a URI list and sends a similar
MESSAGE request to each URI in the list. In this context, similar
indicates that some SIP header fields can change, but the MESSAGE
URI-list service will not change the instant message payload.
MESSAGE URI-list services behave effectively as specialized B2BUAs
(Back-to-Back-User-Agents). A server providing MESSAGE URI-list
services can also offer URI-list services for other methods,
although this functionality is outside the scope of this document.
In this document, we only discuss MESSAGE URI-list services.
MESSAGE URI-リストサービス: URIリストでMESSAGE要求を受け取って、同様のMESSAGE要求をリストの各URIに送る専門化しているURIリストサービス。 中、この文脈で、同様である、いくつかのSIPヘッダーフィールドが変化できますが、MESSAGE URI-リストサービスがインスタントメッセージペイロードは変えないのを示します。 MESSAGE URI-リストサービスは専門化しているB2BUAs(ユーザエージェントを支持するためには逆)として有効に振る舞います。 また、MESSAGE URI-リストサービスを提供するサーバは他のメソッドのためにURIリストサービスを提供できます、このドキュメントの範囲の外にこの機能性がありますが。 本書では、私たちはMESSAGE URI-リストサービスについて議論するだけです。
Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates
and addresses to a MESSAGE URI-list service. Besides the regular
instant message payload, an incoming MESSAGE request contains a
URI list.
入って来るMESSAGEは以下を要求します。 UACがMESSAGE URI-リストサービスに作成して、扱うSIP MESSAGE要求。 通常のインスタントメッセージペイロード以外に、入って来るMESSAGE要求はURIリストを含んでいます。
Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI-
list service creates and addresses to a UAS (User Agent Server).
It contains the regular instant message payload.
出発しているMESSAGEは以下を要求します。 MESSAGE URIがサービスを記載するというSIP MESSAGE要求は、(ユーザエージェントServer)をUASに作成して、扱います。 それは通常のインスタントメッセージペイロードを含んでいます。
Garcia-Martin & Camarillo Standards Track [Page 3] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[3ページ]RFC5365一口
Intended recipient: The intended final recipient of the request to
be generated by MESSAGE URI-list service.
受取人は意図しました: MESSAGE URI-リストサービスで生成されるという要求の意図している最終的な受取人。
Reply-To-All: The ability of an intended recipient to receive a
MESSAGE request that includes the payload and the list of
recipients, and compose and send a MESSAGE request to the sender
and the rest of the recipients. The replying entity can use a
MESSAGE URI-list service if one is at its disposal or can create a
sequence of regular single-recipient MESSAGE requests to each SIP
AOR.
すべてに関して、返答してください: MESSAGE要求を送付者にペイロードを含んでいるMESSAGE要求と受取人のリストを受け取って、構成して、送る意図している受取人の能力と受取人の残り。 1つが自由にはあるか、または定期的な独身の受取人MESSAGE要求の系列を各SIP AORに作成できるなら、返答実体はMESSAGE URI-リストサービスを利用できます。
3. Overview
3. 概要
A UAC creates a MESSAGE request that contains a multipart body including a list of URIs (intended recipients) and an instant message. The list of URIs is formatted according to the resource list document format specified in RFC 4826 [RFC4826] and extended with the attributes defined in RFC 5364 [RFC5364]. The UAC sends this MESSAGE request to the MESSAGE URI-list service. On reception of this incoming MESSAGE request, the MESSAGE URI-list service creates a MESSAGE request per intended recipient (listed in the URI list) and copies the instant message payload to each of those MESSAGES. The MESSAGE URI-list service also manipulates the XML resource list according to the procedures indicated in RFC 5364 [RFC5364], and attaches the result to each of the MESSAGE requests, along with the instant message payload. Then the MESSAGE URI-list service sends each of the created outgoing MESSAGE request to the respective receiver.
UACはURI(意図している受取人)とインスタントメッセージのリストを含む複合ボディーを含むMESSAGE要求を作成します。 RFC4826[RFC4826]で指定されて拡張しているRFC5364[RFC5364]で定義されている属性でリソースリストドキュメント・フォーマットに従って、URIのリストはフォーマットされます。 UACはMESSAGE URI-リストサービスにこのMESSAGE要求を送ります。 この入って来るMESSAGE要求のレセプションに、MESSAGE URI-リストサービスは意図している受取人(URIリストでは、記載されている)あたり1つのMESSAGE要求とそれぞれのそれらのMESSAGESへの即時のメッセージペイロードのコピーを作成します。 MESSAGE URI-リストサービスは、また、RFC5364[RFC5364]で示された手順によってXMLリソースリストを操って、それぞれのMESSAGE要求に結果を付けます、インスタントメッセージペイロードと共に。 そして、MESSAGE URI-リストサービスはそれぞれの作成された送信するMESSAGE要求をそれぞれの受信機に送ります。
The MESSAGE URI-list mechanism allows a sender to specify multiple targets for a MESSAGE request by including an XML resource list document according to RFC 4826 [RFC4826] in the body of the MESSAGE request extended with the attributes defined in RFC 5364 [RFC5364]. This resource list, whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list', as specified in RFC 5363 [RFC5363], includes the URIs of the targets. Each target URI may also be marked to indicate in what role the URI-list service will place the target (e.g., "to", "cc", or "bcc"), and whether the target URI is expected to be anonymized or not, according to the procedures described in RFC 5364 [RFC5364]. When the MESSAGE URI-list server expands the MESSAGE request to each recipient, it includes (along with the instant message payload) a new URI list (based on the received one), whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list-history', as specified in RFC 5364 [RFC5364]. This new URI list includes the list of non-anonymous "to" and "cc" targets, allowing recipients both to get knowledge of other recipients and to reply to them.
MESSAGE URI-リストメカニズムで、送付者は、RFC4826[RFC4826]によると、属性がRFC5364[RFC5364]で定義されている状態で広げられたMESSAGE要求のボディーにXMLリソースリストドキュメントを含んでいることによって、MESSAGE要求のためのマルチターゲットを指定できます。 '受取人リスト'が指定されるとしてRFC5363[RFC5363]のだれのContent-気質(RFC2183)[RFC2183]であるかというこのリソースリストは目標のURIを含んでいます。 また、それぞれの目標URIはURIリストサービスが目標(例えば、“to"、「cc」、または"bcc")をどんな役割に置くだろうか、そして、目標URIがanonymizedされると予想されるかどうかを示すためにマークされるかもしれません、RFC5364[RFC5364]で説明された手順によると。 MESSAGE URI-リストサーバが各受取人にMESSAGE要求を広くするとき、それはRFC5364[RFC5364]の'受取人リスト歴史'がだれのContent-気質(RFC2183)[RFC2183]であるかという指定されるとしての新しいURIリスト(容認されたものに基づいている)を含んでいます(インスタントメッセージペイロードと共に)。 この新しいURIリストは非匿名の“to"と「cc」目標のリストを含んでいます、受取人がともに他の受取人に関する知識を得て、彼らに答えるのを許容して。
Garcia-Martin & Camarillo Standards Track [Page 4] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[4ページ]RFC5365一口
4. URI-List Document
4. URIリストドキュメント
As described in RFC 5363 [RFC5363], specifications of individual URI- list services, like the MESSAGE URI-list service described here, need to specify a default format for 'recipient-list' bodies used within the particular service.
RFC5363[RFC5363]で説明されるように、ここで説明されたMESSAGE URI-リストサービスのように、個々にURIリストサービスの仕様は、特定のサービスの中で使用された'受取人リスト'ボディーに省略時書式を指定する必要があります。
The default format for 'recipient-list' bodies for MESSAGE URI-list services is the resource list document specified in RFC 4826 [RFC4826] extended with the copy control attributes [RFC5364]. UACs and MESSAGE URI-list services handling 'recipient-list' bodies MUST support both of these formats and MAY support other formats.
MESSAGE URI-リストサービスのための'受取人リスト'ボディーのための省略時書式はコピーコントロール属性[RFC5364]で広げられたRFC4826[RFC4826]で指定されたリソースリストドキュメントです。 '受取人リスト'ボディーを扱うUACsとMESSAGE URI-リストサービスは、これらの形式の両方をサポートしなければならなくて、他の形式をサポートするかもしれません。
As described in RFC 5364 [RFC5364], each URI can be tagged with a 'copyControl' attribute set to either "to", "cc", or "bcc", indicating the role in which the recipient will get the MESSAGE request. Additionally, URIs can be tagged with the 'anonymize' attribute to prevent that the MESSAGE URI-list server discloses the target URI in a URI list.
RFC5364[RFC5364]で説明されるように、“to"、「cc」か"bcc"のどちらかに設定された'copyControl'属性で各URIにタグ付けをすることができます、受取人がMESSAGE要求を得る役割を示して。 さらに、URIは'anonymizeする'属性でタグ付けをされて、それを防いで、MESSAGE URI-リストサーバがURIリストの目標URIを明らかにするということであるかもしれません。
Additionally, RFC 5364 [RFC5364] defines a 'recipient-list-history' body that contains the list of intended recipients. The default format for 'recipient-list-history' bodies for MESSAGE URI-list services is also the resource list document specified in RFC 4826 [RFC4826] extended with the copy control attributes [RFC5364]. MESSAGE URI-list services MUST support both of these formats; UASs MAY support these formats. MESSAGE URI-list servers and UASs MAY support other formats.
さらに、RFC5364[RFC5364]は意図している受取人のリストを含む'受取人リスト歴史'ボディーを定義します。 また、MESSAGE URI-リストサービスのための'受取人リスト歴史'ボディーのための省略時書式はコピーコントロール属性[RFC5364]で広げられたRFC4826[RFC4826]で指定されたリソースリストドキュメントです。 MESSAGE URI-リストサービスはこれらの形式の両方をサポートしなければなりません。 UASsはこれらの形式をサポートするかもしれません。 MESSAGE URI-リストサーバとUASsは他の形式をサポートするかもしれません。
The resource list document specified in RFC 4826 [RFC4826] provides a number of features that are not needed by the MESSAGE URI-list service defined in this document. The MESSAGE URI-list service needs to transfer a simple flat list of URIs between a UAC and the MESSAGE URI-list server and between the MESSAGE URI-list server and the UAS. The service does not need hierarchical lists or the ability to include entries by reference relative to the Extensible Configuration Access Protocol (XCAP) [RFC4825] root URI. Therefore, the MESSAGE URI-list service specified herein only uses flat resource lists documents that do not contain relative references.
RFC4826[RFC4826]で指定されたリソースリストドキュメントは本書では定義されたMESSAGE URI-リストサービスで必要でない多くの特徴を提供します。 MESSAGE URI-リストサービスは、UACとMESSAGE URI-リストサーバの間と、そして、MESSAGE URI-リストサーバとUASの間にURIの簡単な平坦なリストを移す必要があります。 サービスは階層的なリストか参照でExtensible Configuration Accessプロトコル(XCAP)[RFC4825]根のURIに比例してエントリーを含む能力を必要としません。 したがって、ここに指定されたMESSAGE URI-リストサービスは相対参照を含まない平坦なリソースリストドキュメントを使用するだけです。
Garcia-Martin & Camarillo Standards Track [Page 5] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[5ページ]RFC5365一口
5. Option-Tag
5. オプションタグ
This document defines the 'recipient-list-message' option-tag for use in the Require and Supported SIP header fields.
このドキュメントはRequireとSupported SIPヘッダーフィールドにおける使用のための'受取人リストメッセージ'オプションタグを定義します。
This option-tag is used to ensure that a server can process the
'recipient-list' body used in a MESSAGE request. It also provides
a mechanism to discover the capability of the server in responses
to OPTIONS requests.
このオプションタグは、サーバがMESSAGE要求で使用される'受取人リスト'ボディーを処理できるのを保証するのに使用されます。 また、それは、OPTIONS要求への応答におけるサーバの能力を発見するためにメカニズムを提供します。
Section 6 provides normative procedures for the usage of this option tag.
セクション6はこのオプションタグの使用法に標準の手順を提供します。
6. Procedures at the User Agent Client
6. ユーザエージェントのクライアントにおける手順
A UAC that wants to create a multiple-recipient MESSAGE request creates a MESSAGE request that MUST be formatted according to RFC 3428 [RFC3428] Section 4. The UAC populates the Request-URI with the SIP or SIPS URI of the MESSAGE URI-list service. In addition to the regular instant message body, the UAC adds a recipient-list body whose Content-Disposition type is 'recipient-list', specified in RFC 5363 [RFC5363]. This body contains a URI list with the recipients of the MESSAGE. Target URIs in this body MAY also be tagged with the 'copyControl' and 'anonymize' attributes specified in RFC 5364 [RFC5364]. The UAC MUST also include the 'recipient-list-message' option-tag, defined in Section 5, in a Require header field.
MESSAGEが要求する複数の受取人を創造したがっているUACはRFC3428[RFC3428]部4によると、フォーマットしなければならないMESSAGE要求を作成します。 UACはMESSAGE URI-リストサービスのSIPかSIPS URIと共にRequest-URIに居住します。 通常のインスタントメッセージ本体に加えて、UACはContent-気質タイプがRFC5363[RFC5363]で指定された'受取人リスト'である受取人リスト本体を加えます。 このボディーはMESSAGEの受取人がいるURIリストを含みます。 このボディーの目標URIは、また、'copyControl'と共にタグ付けをされて、RFC5364[RFC5364]で指定された属性を'anonymizeするかもしれません'。 また、UAC MUSTはRequireヘッダーフィールドにセクション5で定義された'受取人リストメッセージ'オプションタグを含んでいます。
UACs generating MESSAGE requests that carry recipient-list bodies, as described in previous sections, MUST include this option-tag in a Require header field. UAs that are able to receive and process MESSAGEs with a recipient-list body, as described in previous sections, SHOULD include this option-tag in a Supported header field when responding to OPTIONS requests.
前項で説明されるように運ばれるMESSAGE要求に受取人リスト本体を生成するUACsはRequireヘッダーフィールドにこのオプションタグを含まなければなりません。 受取人リスト本体がある受信できるUAsとプロセスMESSAGEs、OPTIONS要求に応じるとき、前項で説明されるように、SHOULDはSupportedヘッダーフィールドにこのオプションタグを含んでいます。
Multiple-recipient MESSAGE requests contain a multipart body that contains the body carrying the list and the actual instant message payload. In some cases, the MESSAGE request can contain bodies other than the text and the list bodies (e.g., when the request is protected with S/MIME as per RFC 3851 [RFC3851]).
複数の受取人MESSAGE要求はリストを運ぶボディーを含む複合ボディーと実際のインスタントメッセージペイロードを含んでいます。 いくつかの場合、MESSAGE要求はテキスト以外のボディーとリスト本体を含むことができます(例えば、要求はいつRFC3851[RFC3851]に従ってS/MIMEで保護されますか)。
Typically, the MESSAGE URI-list service will copy all the significant header fields in the outgoing MESSAGE request. However, there might be cases where the SIP UA wants the MESSAGE URI-list service to add a particular header field with a particular value, even if the header field wasn't present in the MESSAGE request sent by the UAC. In this case, the UAC MAY use the "?" mechanism described in Section 19.1.1 of RFC 3261 [RFC3261] to encode extra information in any URI in the
通常、MESSAGE URI-リストサービスは出発しているMESSAGEの分野が要求するすべての重要なヘッダーをコピーするでしょう。 しかしながら、ケースがSIP UAが、MESSAGE URI-リストサービスに特定の値で特定のヘッダーフィールドを加えて欲しいところにあるかもしれません、ヘッダーフィールドがUACによって送られたMESSAGE要求に存在していなかったとしても。 この場合、UACは中でどんなURIにもその他の情報をコード化するために.1セクション19.1RFC3261[RFC3261]で説明された“?"メカニズムを使用するかもしれません。
Garcia-Martin & Camarillo Standards Track [Page 6] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[6ページ]RFC5365一口
list. However, the UAC MUST NOT use the special "body" hname (see Section 19.1.1 of RFC 3261 [RFC3261]) to encode a body, since the body is present in the MESSAGE request itself.
記載してください。 しかしながら、UAC MUST NOTはボディーをコード化するのに、特別な「ボディー」hname(.1セクション19.1RFC3261[RFC3261]を見る)を使用します、ボディーがMESSAGE要求自体に存在しているので。
The following is an example of a URI that uses the "?" mechanism:
↓これは“?"メカニズムを使用するURIに関する例です:
sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22
一口: bob@example.com?Accept-Contact =*%3bmobility%3d%22mobile%22
The previous URI requests the MESSAGE URI-list service to add the following header field to a MESSAGE request to be sent to bob@example.com:
前のURIは、 bob@example.com に送られるというMESSAGE要求に以下のヘッダーフィールドを追加するようMESSAGE URI-リストサービスに要求します:
Accept-Contact: *;mobility="mobile"
接触を受け入れます: *; 移動性は「モバイル」と等しいです。
The resource list document format specified in RFC 4826 [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XCAP root URI. However, these features are not needed by the multiple MESSAGE URI-list service defined in this document. Therefore, when using the default resource list document, UAs SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref> elements.
RFC4826[RFC4826]で指定されたリソースリストドキュメント・フォーマットは特徴を提供します、階層的なリストや参照でXCAP根のURIに比例してエントリーを含む能力のように。 しかしながら、これらの特徴は本書では定義された複数のMESSAGE URI-リストサービスで必要ではありません。 したがって、デフォルトリソースリストドキュメントを使用するとき、UAs SHOULDは平坦なリスト(すなわち、階層的なリストがない)を使用します、そして、SHOULD NOTは<エントリー審判>に要素を使用します。
7. Procedures at the MESSAGE URI-List Service
7. メッセージURIリストサービスにおける手順
On reception of a MESSAGE request containing a URI list, the MESSAGE URI-list service answers to the UAC with a 202 (Accepted) response.
URIリストを含むMESSAGE要求のレセプションでは、MESSAGE URI-リストサービスは202(受け入れる)応答があるUACに対応します。
Note that the status code in the response to the MESSAGE does not
provide any information about whether or not the MESSAGEs
generated by the URI-list service were successfully delivered to
the URIs in the list. That is, a 202 (Accepted) response means
that the MESSAGE URI-list service has received the MESSAGE and
that it will try to send a similar MESSAGE to the URIs in the
list. Designing a mechanism to inform a client about the delivery
status of an instant message is outside the scope of this
document.
MESSAGEへの応答におけるステータスコードがURIリストサービスで生成されたMESSAGEsが首尾よくリストのURIに提供されたかどうかの少しの情報も提供しないことに注意してください。 すなわち、202(受け入れる)応答はMESSAGE URI-リストサービスがMESSAGEを受けて、同様のMESSAGEをリストのURIに送ろうとすることを意味します。 このドキュメントの範囲の外にインスタントメッセージの配送状態に関してクライアントに知らせるようにメカニズムを設計するのがあります。
Since the MESSAGE URI-list service does not use hierarchical lists nor lists that include entries by reference to the XCAP root URI, a MESSAGE URI-list server receiving a URI list with more information than what has just been described MAY discard all the extra information.
以来、MESSAGE URI-リストサービスは、どんな使用にも階層的なリストをしないで、XCAP根のURIの参照でエントリーを含んでいるリスト、ちょうど説明されることより多くの情報でURIリストを受け取ると捨てられるかもしれないMESSAGE URI-リストサーバにすべてのその他の情報をします。
If a MESSAGE request contains a Request-URI containing a URI that uses the "?" mechanism (see Section 19.1.1 of RFC 3261 [RFC3261]) and such URI contains the special "body" hname to include an additional body, the MESSAGE URI-list server MAY discard the contents of the "body" parameter.
MESSAGE要求が“?"メカニズムを使用するURIを含むRequest-URIを含んでいて(.1セクション19.1RFC3261[RFC3261]を見てください)、そのようなユリが追加ボディーを含むように特別な「ボディー」hnameを含むなら、メッセージユリ-リストサーバは「ボディー」パラメタのコンテンツを捨てるかもしれません。
Garcia-Martin & Camarillo Standards Track [Page 7] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[7ページ]RFC5365一口
7.1. Determining the Intended Recipient
7.1. 意図している受取人を決定します。
On reception of a MESSAGE request containing a URI list, a MESSAGE URI-list service determines the list of intended recipients by inspecting the URI list contained in the body.
URIリストを含むMESSAGE要求のレセプションでは、MESSAGE URI-リストサービスは、ボディーに含まれたURIリストを点検することによって、意図している受取人のリストを決定します。
Section 4.1 of RFC 5363 [RFC5363] discusses cases when duplicated URIs are found in a URI list. In order to avoid duplicated requests, MESSAGE URI-list services MUST take those actions specified in RFC 5363 [RFC5363] into account to avoid sending duplicated requests to the same recipient.
コピーされたURIがURIリストで見つけられるとき、RFC5363[RFC5363]のセクション4.1はケースについて論じます。 コピーされた要求を避けるために、MESSAGE URI-リストサービスはコピーされた要求を同じ受取人に送るのを避けるためにRFC5363[RFC5363]でアカウントに指定されたそれらの行動を取らなければなりません。
7.2. Creating an Outgoing MESSAGE Request
7.2. 送信されるメッセージ要求を作成します。
Since the MESSAGE URI-list service behaves as a UAC for outgoing MESSAGE requests, for each of the intended recipients, the MESSAGE URI-list service creates a new MESSAGE request according to the procedures described in Section 4 of RFC 3428 [RFC3428]. Additionally, Section 5.3 of RFC 5363 [RFC5363] provides additional general guidance in creating outgoing requests. This document also specifies the following procedures:
以来、出発しているMESSAGEのためのUACが、意図している受取人各人のためにRFC3428[RFC3428]のセクション4で説明された手順によると、MESSAGE URI-リストサービスが新しいMESSAGE要求を作成するよう要求するとき、MESSAGE URI-リストサービスは振る舞います。 さらに、RFC5363[RFC5363]のセクション5.3は追加一般的な指導を送信する要求を作成するのに提供します。 また、このドキュメントは以下の手順を指定します:
o A MESSAGE URI-list service MUST include a From header field whose
value is the same as the From header field included in the
incoming MESSAGE request, subject to the privacy requirements (see
RFC 3323 [RFC3323] and RFC 3325 [RFC3325]) expressed in the
incoming MESSAGE request.
o MESSAGE URI-リストサービスは値が入って来るMESSAGE要求に要件(RFC3323[RFC3323]とRFC3325[RFC3325]を見る)が入って来るMESSAGE要求で言い表したプライバシーを条件としてFromヘッダーフィールドを含んでいるのと同じであるFromヘッダーフィールドを含まなければなりません。
Note that this does not apply to the "tag" parameter.
これが「タグ」パラメタに適用されないことに注意してください。
Failure to copy the From header field of the sender results in
unacceptable security and privacy failures. Note also that
this requirement does not intend to contradict requirements for
additional services running on the same physical node.
Specifically, a privacy service (see RFC 3323 [RFC3323]) can be
co-located with the MESSAGE URI-list service, in which case,
the privacy service has precedence over the MESSAGE URI-list
service.
送付者のFromヘッダーフィールドをコピーしない場合、容認できないセキュリティとプライバシー失敗をもたらします。 また、この要件が同じ物理的なノードで動く追加サービスのための要件に矛盾しないつもりであることに注意してください。 明確に、MESSAGE URI-リストサービスでプライバシーサービス(RFC3323[RFC3323]を見る)の共同見つけることができます、その場合、プライバシーサービスには、MESSAGE URI-リストサービスの上の先行があります。
o A MESSAGE URI-list service SHOULD generate a new To header field
value set to the intended recipient's URI. According to the
procedures of RFC 3261 [RFC3261] Section 8.1.1.1, this value is
also expected to be equal to the Request-URI of the outgoing
MESSAGE request.
o サービスSHOULDが新しいToヘッダーフィールド価値を生成するMESSAGE URI-リストは意図している受取人のURIにセットしました。 また、RFC3261[RFC3261]部8.1の.1の手順によると、.1、この値はそうです。送信するMESSAGE要求のRequest-URIと等しいと予想されます。
The MESSAGE URI-list service behaves as a User Agent Client;
thus, the To header field should be populated with the
recipient's URI.
MESSAGE URI-リストサービスはUserエージェントClientとして振る舞います。 したがって、Toヘッダーフィールドは受取人のURIで居住されるべきです。
Garcia-Martin & Camarillo Standards Track [Page 8] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[8ページ]RFC5365一口
o A MESSAGE URI-list service SHOULD create a new Call-ID header
field value.
o MESSAGE URI-リストサービスSHOULDは新しいCall-IDヘッダーフィールド価値を作成します。
A Call-ID header field might contain addressing information
that the sender wants to remain private. Since there is no
need to keep the same Call-ID on both sides of the MESSAGE URI-
list service, and since the MESSAGE URI-list service behaves as
a User Agent Client, it is recommended to create a new Call-ID
header field value according to the regular SIP procedures.
Call-IDヘッダーフィールドは送付者が個人的に残りたがっているというアドレス指定情報を含むかもしれません。 同じCall-IDを保つ必要は全くMESSAGE URIリストサービスの両側になくて、MESSAGE URI-リストサービスがUserエージェントClientとして振る舞うので、通常のSIP手順によると、新しいCall-IDヘッダーフィールド価値を作成するのはお勧めです。
o If a P-Asserted-Identity header field was present in the incoming
MESSAGE request and the request was received from a trusted
source, as specified in RFC 3325 [RFC3325], and the first hop of
the outgoing MESSAGE request is also trusted, a MESSAGE URI-list
service MUST include a P-Asserted-Identity header field in the
outgoing MESSAGE request with the same received value. However,
if the first hop of the outgoing MESSAGE request is not trusted
and the incoming MESSAGE request included a Privacy header field
with a value different than 'none', the MESSAGE URI-list service
MUST NOT include a P-Asserted-Identity header field in the
outgoing MESSAGE request.
o アイデンティティであると断言されたPヘッダーフィールドが入って来るMESSAGE要求に存在していて、RFC3325[RFC3325]で指定されるように信頼できるソースから要求を受け取って、また、送信するMESSAGE要求の最初のホップを信じるなら、MESSAGE URI-リストサービスは送信するMESSAGE要求に同じ容認された値でアイデンティティであると断言されたPヘッダーフィールドを含まなければなりません。 しかしながら、送信するMESSAGE要求の最初のホップが信じられないで、入って来るMESSAGE要求が'なにも'と異なった値があるPrivacyヘッダーフィールドを含んでいたなら、MESSAGE URI-リストサービスは送信するMESSAGE要求にアイデンティティであると断言されたPヘッダーフィールドを含んではいけません。
o If a MESSAGE URI-list service is able to assert the identity of a
user (e.g., using HTTP Digest authentication scheme as per RFC
2617 [RFC2617], S/MIME as per RFC 3851 [RFC3851], etc.) and the
service implements a mechanism where it can map that
authentication scheme to a user's SIP or SIPS URI, and subject to
the privacy requirements expressed in the incoming MESSAGE request
(see RFC 3323 [RFC3323]), the MESSAGE URI-list service MAY insert
a P-Asserted-Identity header with the value of the user's asserted
URI.
o MESSAGE URI-リストサービスがユーザ(例えば、RFC2617RFC2617に従ってHTTP Digest認証体系を使用するRFC3851RFC3851に従ってS/MIMEなど)のアイデンティティについて断言できるか、そして、サービスはそれがその認証体系をユーザのSIPかSIPS URIに写像できるメカニズムを実装します; そして、入って来るMESSAGE要求(RFC3323RFC3323を見る)で言い表されたプライバシー要件を条件として、ユーザの値がURIであると断言されている状態で、MESSAGE URI-リストサービスはアイデンティティであると断言されたPヘッダーを挿入するかもしれません。
o If the incoming MESSAGE request contains an Authorization or
Proxy-Authorization header field whose realm is set to the MESSAGE
URI-list server's realm, then the MESSAGE URI-list service SHOULD
NOT copy it to the outgoing MESSAGE request; otherwise (i.e., if
the Authorization or Proxy-Authorization header field of incoming
MESSAGE request contains a different realm), the MESSAGE URI-list
service MUST copy the value to the respective header field of the
outgoing MESSAGE request.
o 入って来るMESSAGE要求が分野がMESSAGE URI-リストサーバの分野に設定されるAuthorizationかProxy-承認ヘッダーフィールドを含んでいるなら、MESSAGE URI-リストサービスSHOULD NOTは送信するMESSAGE要求にそれをコピーします。 さもなければ(すなわち、MESSAGEが要求する入来のAuthorizationかProxy-承認ヘッダーフィールドが異なった分野を含んでいるなら)、MESSAGE URI-リストサービスは送信するMESSAGE要求のそれぞれのヘッダーフィールドに値をコピーしなければなりません。
o A MESSAGE URI-list service SHOULD create a separate count for the
CSeq header field [RFC3261] of the outgoing MESSAGE request.
o MESSAGE URI-リストサービスSHOULDは送信するMESSAGE要求のCSeqヘッダーフィールド[RFC3261]のための別々のカウントを作成します。
o A MESSAGE URI-list service SHOULD initialize the value of the Max-
Forward header field of the outgoing MESSAGE request.
o MESSAGE URI-リストサービスSHOULDは送信するMESSAGE要求のマックスの前進のヘッダーフィールドの値を初期化します。
Garcia-Martin & Camarillo Standards Track [Page 9] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[9ページ]RFC5365一口
o A MESSAGE URI-list service MUST include its own value in the Via
header field.
o MESSAGE URI-リストサービスはViaヘッダーフィールドにそれ自身の値を含まなければなりません。
7.3. Composing Bodies in the Outgoing MESSAGE Request
7.3. 送信されるメッセージのボディーが要求する構成
When creating the body of each of the outgoing MESSAGE requests, the MESSAGE URI-list service keeps the relevant bodies of the incoming MESSAGE request and copies them to the outgoing MESSAGE request. The following guidelines constitute exceptions to the general body handling:
それぞれの送信するMESSAGE要求のボディーを作成するとき、MESSAGE URI-リストサービスは、入って来るMESSAGE要求の関連ボディーを保って、送信するMESSAGE要求にそれらをコピーします。 以下のガイドラインは一般的なボディー取り扱いへの例外を構成します:
o A MESSAGE request received at a MESSAGE URI-list service can
contain one or more security bodies (e.g., S/MIME, RFC 3851
[RFC3851]) encrypted with the public key of the MESSAGE URI-list
service. These bodies are deemed to be read by the URI-list
service rather than the recipient of the outgoing MESSAGE request
(which will not be able to decrypt them). Therefore, a MESSAGE
URI-list service MUST NOT copy any security body (such as an
S/MIME as per RFC 3851 [RFC3851] encrypted body) addressed to the
MESSAGE URI-list service to the outgoing MESSAGE request. This
includes bodies encrypted with the public key of the URI-list
service.
o MESSAGE URI-リストサービスのときに受け取られたMESSAGE要求はMESSAGE URI-リストサービスの公開鍵で暗号化された1つ以上のセキュリティ本体(例えば、S/MIME、RFC3851[RFC3851])を含むことができます。 送信するMESSAGE要求(それらを解読することができない)の受取人よりむしろURIリストサービスでこれらのボディーが読まれると考えられます。 したがって、MESSAGE URI-リストサービスは送信するMESSAGE要求に対するMESSAGE URI-リストサービスに扱われたどんなセキュリティ本体(RFC3851[RFC3851]の暗号化されたボディーに従ってS/MIMEなどの)もコピーしてはいけません。 これはURIリストサービスの公開鍵で暗号化されたボディーを含んでいます。
o The incoming MESSAGE request typically contains a recipient-list
body or reference, as indicated in RFC 5363 [RFC5363] with the
actual list of recipients. If this URI list includes resources
tagged with the 'copyControl' attribute set to a value of "to" or
"cc", the URI-list service SHOULD include a URI list in each of
the outgoing MESSAGE requests. This list SHOULD be formatted
according to the resource list document format specified in RFC
4826 [RFC4826] and the copyControl extension specified in RFC 5364
[RFC5364]. The MESSAGE URI-list service MUST follow the
procedures specified in RFC 5364 [RFC5364] with respect to
handling of the 'anonymize', 'count', and 'copyControl'
attributes.
o 入って来るMESSAGE要求は受取人リスト本体か参照を通常含んでいます、受取人の実際のリストがあるRFC5363[RFC5363]にみられるように。 このURIリストが'copyControl'属性セットで“to"の値にタグ付けをされたリソースか「cc」を含んでいるなら、URIリストサービスSHOULDはそれぞれの送信するMESSAGE要求にURIリストを含んでいます。 これはSHOULDを記載します。RFC4826で指定されたリソースリストドキュメント・フォーマット[RFC4826]とRFC5364で指定されたcopyControl拡張子[RFC5364]に従って、フォーマットされてください。 MESSAGE URI-リストサービスはRFC5364[RFC5364]で'anonymizeする'、'カウント'、および'copyControl'属性の取り扱いに関して指定された手順に従わなければなりません。
o If the MESSAGE URI-list service includes a URI list in an outgoing
MESSAGE request, it MUST include a Content-Disposition header
field as per RFC 2183 [RFC2183] with the value set to 'recipient-
list-history' and a "handling" parameter as per RFC 3204 [RFC3204]
set to "optional".
o MESSAGE URI-リストサービスが送信するMESSAGE要求にURIリストを含んでいるなら、それは選択値群があるRFC2183[RFC2183]に従って'受取人リスト歴史'にContent-気質ヘッダーフィールドを含めなければなりません、そして、RFC3204[RFC3204]に従って「取り扱い」パラメタは「任意に」セットしました。
o If a MESSAGE URI-list service includes a URI list in an outgoing
MESSAGE request, it SHOULD use S/MIME (RFC 3851) [RFC3851] to
encrypt the URI list with the public key of the receiver.
o MESSAGE URI-リストサービスは送信するMESSAGE要求にURIリストを含んで、それは受信機の公開鍵でURIリストを暗号化するSHOULD使用S/MIMEです(RFC3851)[RFC3851]。
Garcia-Martin & Camarillo Standards Track [Page 10] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[10ページ]RFC5365一口
o The MESSAGE URI-list service SHOULD copy all the remaining message
bodies (e.g., text messages, images, etc.) of the incoming MESSAGE
request to the outgoing MESSAGE request.
o MESSAGE URI-リストサービスSHOULDは入って来るMESSAGEのボディー(例えば、テキスト・メッセージ、イメージなど)が送信するMESSAGE要求に要求するすべての残っているメッセージをコピーします。
o If there is only one body left, the MESSAGE URI-list service MUST
remove the multipart/mixed wrapper in the outgoing MESSAGE
request.
o 1つのボディーだけが残っているなら、MESSAGE URI-リストサービスは送信するMESSAGE要求における複合の、または、複雑なラッパーを取り除かなければなりません。
The rest of the MESSAGE request corresponding to a given URI in the URI list MUST be created following the rules in Section 19.1.5, "Forming Requests from a URI", of RFC 3261 [RFC3261]. In particular, Section 19.1.5 of RFC 3261 [RFC3261] states:
セクション19.1.5で約束を守って、URIリストの与えられたURIに対応するMESSAGE要求の残りを作成しなければなりません、RFC3261[RFC3261]について「URIから要求を形成し」て。 特に、.5セクション19.1RFC3261[RFC3261]が以下を述べます。
"An implementation SHOULD treat the presence of any headers or
body parts in the URI as a desire to include them in the message,
and choose to honor the request on a per-component basis."
「実装SHOULDはメッセージにそれらを含んで、要求を光栄に思うのを選ぶ願望としてURIにおける、どんなヘッダーや身体の部分の存在も1コンポーネントあたり1個のベースに扱います。」
SIP allows to append a "method" parameter to a URI. Therefore, it is legitimate that the 'uri' attribute of the <entry> element in the XML resource list contains a "method" parameter. MESSAGE URI-list services MUST generate only MESSAGE requests, regardless of the "method" parameter that the URIs in the list indicate. Effectively, MESSAGE URI-list services MUST ignore the "method" parameter in each of the URIs present in the URI list.
SIPは「メソッド」パラメタをURIに追加させます。 したがって、XMLリソースリストの<エントリー>要素の'uri'属性が「メソッド」パラメタを含むのは、正統です。 MESSAGE URI-リストサービスはリストのURIが示す「メソッド」パラメタにかかわらずMESSAGE要求だけを生成しなければなりません。 事実上、MESSAGE URI-リストサービスはURIリストのそれぞれのURI現在の「メソッド」パラメタを無視しなければなりません。
8. Procedures at the UAS
8. UASの手順
A UAS (in this specification, also known as intended recipient UAS) that receives a MESSAGE request from the MESSAGE URI-list service behaves as specified in RFC 3428 [RFC3428] Section 7.
MESSAGE URI-リストサービスからMESSAGE要求を受け取るUAS(また、意図している受取人UASとして知られているこの仕様による)はRFC3428[RFC3428]部7で指定されるように振る舞います。
If the UAS supports this specification and the MESSAGE request contains a body with a Content-Disposition header field as per RFC 2183 [RFC2183] set to 'recipient-list-history', then the UAS will be able to determine the SIP Address-of-Record (AOR) of the other intended recipients of the MESSAGE request. This allows the user to create a reply request (e.g., MESSAGE, INVITE) to the sender and the rest of the recipients included in the URI list.
UASがこの仕様をサポートして、MESSAGE要求が'受取人リスト歴史'に用意ができているRFC2183[RFC2183]に従ってContent-気質ヘッダーフィールドがあるボディーを含んでいると、UASはMESSAGE要求の他の意図している受取人記録のSIP Address(AOR)を決定できるでしょう。 これで、ユーザは回答要求(例えば、MESSAGE、INVITE)を送付者とURIリストに受取人を含む残りに作成できます。
Garcia-Martin & Camarillo Standards Track [Page 11] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[11ページ]RFC5365一口
9. Examples
9. 例
Figure 1 shows an example of operation. A SIP UAC issuer sends a MESSAGE request. The MESSAGE URI-list service answers with a 202 (Accepted) response and sends a MESSAGE request to each of the intended recipients.
図1は操作に関する例を示しています。 SIP UAC発行人はMESSAGE要求を送ります。 MESSAGE URI-リストサービスは、202(受け入れる)応答で答えて、意図している受取人各人にMESSAGE要求を送ります。
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | MESSAGE | |intended| |intended| |intended|
| issuer | | URI-list| | recip. | | recip. | | recip. |
| | | service | | 1 | | 2 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 MESSAGE | | | |
| ---------------->| | | |
| F2 202 Accepted | | | |
|<---------------- | F3 MESSAGE | | |
| | ------------->| | |
| | F4 MESSAGE | | |
| | ------------------------>| |
| | F5 MESSAGE | | |
| | ----------------------------------->|
| | F6 200 OK | | |
| |<------------- | | |
| | F7 200 OK | | |
| |<------------------------ | |
| | F8 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
+--------+ +---------+ +--------+ +--------+ +--------+ |一口UAC| | メッセージ| |意図します。| |意図します。| |意図します。| | 発行人| | URIリスト| | recip。 | | recip。 | | recip。 | | | | サービス| | 1 | | 2 | | n| +--------+ +---------+ +--------+ +--------+ +--------+ | | | | | | F1メッセージ| | | | | ---------------->|、|、|、|、| F2 202は受け入れました。| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| F3メッセージ| | | | | ------------->|、|、|、|、| F4メッセージ| | | | | ------------------------>|、|、|、| F5メッセージ| | | | | ----------------------------------->|、|、| F6 200OK| | | | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| F7 200OK| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| F8 200OK| | | | |<----------------------------------- | | | | | | | | | | | | | | | |
Figure 1: Example of operation
図1: 操作に関する例
The MESSAGE request F1 (shown in Figure 2) contains a multipart/mixed body that is composed of two bodies: a text/plain body containing the instant message payload and an application/resource-lists+xml body containing the list of recipients.
MESSAGEは、F1(図2では、目立つ)が2つのボディーで構成される複合の、または、混ぜられたボディーを含むよう要求します: インスタントメッセージペイロードを含むテキスト/明瞭なボディーと受取人のリストを含むアプリケーション/リソースリスト+xmlボディー。
Garcia-Martin & Camarillo Standards Track [Page 12] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[12ページ]RFC5365一口
MESSAGE sip:list-service.example.com SIP/2.0
Via: SIP/2.0/TCP uac.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: MESSAGE URI-list service <sip:list-service.example.com>
From: Alice <sip:alice@example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 1 MESSAGE
Require: recipient-list-message
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501
MESSAGE一口: リスト-service.example.com SIP/2.0Via: SIP/2.0/TCP uac.example.com; ブランチは前方へz9hG4bKhjhs8ass83マックスと等しいです: 70 To: MESSAGE URI-リストサービス<一口: service.example.comを記載された>From: アリス<一口: alice@example.com 、gt;、; タグは32331呼び出しIDと等しいです: d432fa84b4c76e66710 CSeq: 1つのメッセージが以下を必要とします。 受取人リストメッセージコンテントタイプ: 複合か混ぜられる;、境界=、「boundary1" Content-長さ:」 501
--boundary1 Content-Type: text/plain
--boundary1コンテントタイプ: テキスト/平野
Hello World!
こんにちは、世界!
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
--boundary1コンテントタイプ: アプリケーション/リソースリスト+xml Content気質: 受取人リスト
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>
--boundary1--
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlnsは「つぼ:ietf:params:xml:ナノ秒: リソースリスト」xmlnsと等しいです: cpは「つぼ:ietf:params: xml:ナノ秒:copycontrol「><リスト><エントリーuri=」一口: bill@example.com 」cpと等しいです: copyControl="to"/><エントリーuriは「一口: randy@example.net 」cp: copyControl="to" cpと等しいです:、anonymizeする、= 「本当」/><エントリーuriは「一口: eddy@example.com 」cp: copyControl="to" cpと等しいです:; 本当..エントリー..等しい..一口..エントリー..等しい..一口..本当..エントリー..等しい..一口..エントリー..等しい..一口..等しい..リスト..リソースリスト
Figure 2: MESSAGE request received at the MESSAGE URI-list server
図2: MESSAGE URI-リストサーバで受け取られたMESSAGE要求
The MESSAGE requests F3, F4, and F5 are similar in nature. All those MESSAGE requests contain a multipart/mixed body that is composed of two other bodies: a text/plain body containing the instant message payload and an application/resource-lists+xml containing the list of recipients. Unlike the text/plain body, the application/ resource-lists+xml bodies of MESSAGE requests F3, F4, and F5 are not equal to the application/resource-lists+xml body included in the
MESSAGE要求のF3、F4、およびF5は同様です。 それらのすべてのMESSAGE要求が他の2つのボディーで構成される複合の、または、混ぜられたボディーを含んでいます: インスタントメッセージペイロードを含むテキスト/明瞭なボディーと受取人のリストを含むアプリケーション/リソースリスト+xml。 テキスト/明瞭なボディー、含んでいる要求のF3、F4、およびF5がアプリケーション/リソースリスト+xmlボディーが等しくないMESSAGEのアプリケーション/リソースリスト+xmlボディー
Garcia-Martin & Camarillo Standards Track [Page 13] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[13ページ]RFC5365一口
incoming MESSAGE request F1. This is because the URI-list service has anonymized those URIs tagged with the 'anonymize' attribute and has removed those URIs tagged with a "bcc" 'copyControl' attribute; besides, the content disposition of these bodies is different. Figure 3 shows an example of the MESSAGE request F3.
入って来るMESSAGEはF1を要求します。 これはURIリストサービスが'anonymizeする'属性でタグ付けをされたそれらのURIをanonymizedして、"bcc"'copyControl'属性でタグ付けをされたそれらのURIを取り除いたからです。 そのうえ、これらのボディーの満足している気質は異なっています。 図3はMESSAGE要求F3に関する例を示しています。
MESSAGE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP list-service.example.com
;branch=z9hG4bKhjhs8as34sc
Max-Forwards: 70
To: <sip:bill@example.com>
From: Alice <sip:alice@example.com>;tag=210342
Call-ID: 39s02sdsl20d9sj2l
CSeq: 1 MESSAGE
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501
MESSAGE一口: bill@example.com SIP/2.0Via: SIP/2.0/TCPリスト-service.example.com; ブランチは前方へz9hG4bKhjhs8as34scマックスと等しいです: 70 To: <一口: bill@example.com 、gt;、From: アリス<一口: alice@example.com 、gt;、; タグは210342呼び出しIDと等しいです: 39s02sdsl20d9sj2l CSeq: 1 メッセージコンテントタイプ: 複合か混ぜられる;、境界=、「boundary1" Content-長さ:」 501
--boundary1 Content-Type: text/plain
--boundary1コンテントタイプ: テキスト/平野
Hello World!
こんにちは、世界!
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list-history; handling=optional
--boundary1コンテントタイプ: アプリケーション/リソースリスト+xml Content気質: 受取人リスト歴史。 取り扱い=任意です。
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>
--boundary1--
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlnsは「つぼ:ietf:params:xml:ナノ秒: リソースリスト」xmlnsと等しいです: cpは「つぼ:ietf:params: xml:ナノ秒:copycontrol「><リスト><エントリーuri=」一口: bill@example.com 」cpと等しいです: copyControl="to"/><エントリーuriは「一口: anonymous@anonymous.invalid 」cpと等しいです:; 「cc」/><「copyControl="to" cp: カウント=「2インチ/><エントリーuri=」一口: joe@example.org 」cp: copyControl=エントリーuriは「一口: anonymous@anonymous.invalid 」cpと等しいです: copyControlは「cc」cpと等しいです: 数えてください。= 「1インチ/>の</リスト></は>--boundary1をリソースで記載します」。
Figure 3: MESSAGE request sent by the MESSAGE URI-list server
図3: MESSAGE URI-リストサーバによって送られたMESSAGE要求
Garcia-Martin & Camarillo Standards Track [Page 14] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[14ページ]RFC5365一口
10. Security Considerations
10. セキュリティ問題
RFC 5363 [RFC5363] discusses issues related to SIP URI-list services. Implementations of MESSAGE URI-list services MUST follow the security-related rules in RFC 5363 [RFC5363]. These rules include opt-in lists and mandatory authentication and authorization of clients.
RFC5363[RFC5363]はSIP URI-リストサービスに関連する問題について議論します。 MESSAGE URI-リストサービスの実装はRFC5363[RFC5363]のセキュリティ関連の規則に従わなければなりません。 これらの規則はクライアントのオプトインリスト、義務的な認証、および承認を含んでいます。
If the contents of the instant message needs to be kept private, the User Agent Client SHOULD use S/MIME as per RFC 3851 [RFC3851] to prevent a third party from viewing this information. In this case, the user agent client SHOULD encrypt the instant message body with a content encryption key. Then, for each receiver in the list, the UAC SHOULD encrypt the content encryption key with the public key of the receiver, and attach it to the MESSAGE request.
インスタントメッセージのコンテンツが、個人的に保たれる必要があるなら、UserエージェントClient SHOULDは、RFC3851[RFC3851]に従って第三者がこの情報を見るのを防ぐのにS/MIMEを使用します。 この場合、ユーザエージェントクライアントSHOULDは満足している暗号化キーでインスタントメッセージ本体を暗号化します。 次に、リストの各受信機に関して、UAC SHOULDは受信機の公開鍵によって主要な満足している暗号化を暗号化して、MESSAGE要求にそれを付けます。
11. IANA Considerations
11. IANA問題
This document defines the SIP option tag 'recipient-list-message'
このドキュメントはSIPオプションタグ'受取人リストメッセージ'を定義します。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
SIP Parameter Registryの「オプションタグ」セクションに以下の行を追加してあります:
+------------------------+------------------------------+-----------+ | Name | Description | Reference | +------------------------+------------------------------+-----------+ | recipient-list-message | The body contains a list of | [RFC5365] | | | URIs that indicates the | | | | recipients of the SIP | | | | MESSAGE request | | +------------------------+------------------------------+-----------+
+------------------------+------------------------------+-----------+ | 名前| 記述| 参照| +------------------------+------------------------------+-----------+ | 受取人リストメッセージ| ボディーはリストを含みます。| [RFC5365]| | | それが示すURI| | | | SIPの受取人| | | | MESSAGE要求| | +------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-message' Option-Tag
in SIP
テーブル1: 一口における、'受取人リストメッセージ'オプションタグの登録
12. Acknowledgements
12. 承認
Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben Campbell, Paul Kyzivat, Cullen Jennings, Jonathan Rosenberg, Dean Willis, and Keith Drage provided helpful comments.
ダンカン・ミルズは1〜n MESSAGEsを持っているという考えをサポートしました。 ベン・キャンベル、ポールKyzivat、Cullenジョニングス、ジョナサン・ローゼンバーグ、ディーン・ウィリス、およびキースDrageは役に立つコメントを提供しました。
Garcia-Martin & Camarillo Standards Track [Page 15] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[15ページ]RFC5365一口
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost、R.、デルナー、S.、およびK.ムーア、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「満足している気質ヘッダーフィールド」、RFC2183、1997年8月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2617] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for ISUP
and QSIG Objects", RFC 3204, December 2001.
[RFC3204] Zimmerer、E.、ピーターソン、J.、Vemuri、A.、オング、L.、Audet、F.、ワトソン、M.、およびM.Zonoun、「ISUPとQSIG ObjectsのためのMIMEメディアタイプ」、RFC3204(2001年12月)。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3325] ジョニングス、C.、ピーターソン、J.、およびM.ワトソン、「セッション開始への個人的な拡大は断言されたアイデンティティのために信じられたネットワークの中で(一口)について議定書の中で述べます」、RFC3325、2002年11月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC3428] キャンベル、B.、ローゼンバーグ、J.、Schulzrinne、H.、Huitema、C.、およびD.Gurle、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]ローゼンバーグ(J.、「リソースリストを表すための拡張マークアップ言語(XML)形式」、RFC4826)は2007がそうするかもしれません。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) URI-
List Services", RFC 5363, October 2008.
[RFC5363] キャマリロ、G.、およびA.B.ローチ、「セッション開始のためのフレームワークとセキュリティ問題はURIリストサービスについて議定書の中で述べ(ちびちび飲みます)」、RFC5363、2008年10月。
Garcia-Martin & Camarillo Standards Track [Page 16] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[16ページ]RFC5365一口
[RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup
Language (XML) Format Extension for Representing Copy
Control Attributes in Resource Lists", RFC 5364,
October 2008.
[RFC5364]ガルシア-マーチン、M.、およびG.キャマリロ、「拡張マークアップ言語(XML)はリソースリストのコピーコントロール属性を表すための拡大をフォーマットします」、RFC5364、2008年10月。
13.2. Informative References
13.2. 有益な参照
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]ローゼンバーグ(J.、「拡張マークアップ言語(XML)構成アクセス・プロトコル(XCAP)」RFC4825)は2007がそうするかもしれません。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]キャンベル、B.、マーイ、R.、およびC.ジョニングス、「メッセージセッションリレープロトコル(MSRP)」、RFC4975 2007年9月。
Authors' Addresses
作者のアドレス
Miguel A. Garcia-Martin Ericsson Via de los Poblados 13 Madrid 28033 Spain
ミゲルA.ガルシア-マーチンエリクソンVia de los Poblados13マドリード28033スペイン
EMail: miguel.a.garcia@ericsson.com
メール: miguel.a.garcia@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Garcia-Martin & Camarillo Standards Track [Page 17] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008
メッセージ要求2008年10月の複数の受取人のガルシア-マーチンとキャマリロ標準化過程[17ページ]RFC5365一口
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Garcia-Martin & Camarillo Standards Track [Page 18]
ガルシア-マーチンとキャマリロ標準化過程[18ページ]
一覧
スポンサーリンク
