RFC4488 日本語訳

Network Working Group                                           O. Levin
Request for Comments: 4488                         Microsoft Corporation
Category: Standards Track                                       May 2006

コメントを求めるワーキンググループO.レヴィンの要求をネットワークでつないでください: 4488年のマイクロソフト社カテゴリ: 標準化過程2006年5月

           Suppression of Session Initiation Protocol (SIP)
                   REFER Method Implicit Subscription

セッション開始プロトコル(一口)の抑圧は方法の暗黙の購読を参照します。

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)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   The Session Initiation Protocol (SIP) REFER extension as defined in
   RFC 3515 automatically establishes a typically short-lived event
   subscription used to notify the party sending a REFER request about
   the receiver's status in executing the transaction requested by the
   REFER.  These notifications are not needed in all cases.  This
   specification provides a way to prevent the automatic establishment
   of an event subscription and subsequent notifications using a new SIP
   extension header field that may be included in a REFER request.

RFC3515で自動的に定義されるSession Initiationプロトコル(SIP)REFER拡張子はREFERによって要求された取引を実行する際に受信機の状態に関するREFER要求を送るパーティーに通知するのに使用される通常短命なイベント購読を確立します。 これらの通知はすべての場合で必要ではありません。 この仕様はREFER要求に含まれるかもしれない新しいSIP拡大ヘッダーフィールドを使用することでイベント購読とその後の通知の自動確立を防ぐ方法を提供します。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   4.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  Preventing Forking of REFER Requests  . . . . . . . . . . . . . 4
   6.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
       10.1.  Normative References . . . . . . . . . . . . . . . . . . 7
       10.2.  Informative References . . . . . . . . . . . . . . . . . 7

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 動機. . . . . . . . . . . . . . . . . . . . . . . . . . 2 4。 定義. . . . . . . . . . . . . . . . . . . . . . . . . . 3 5。 分岐するのを防いで、要求. . . . . . . . . . . . . 4 6を参照してください。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 6 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 6 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1。 引用規格. . . . . . . . . . . . . . . . . . 7 10.2。 有益な参照. . . . . . . . . . . . . . . . . 7

Levin                       Standards Track                     [Page 1]

RFC 4488             SIP REFER without Subscription             May 2006

レヴィン標準化過程[1ページ]RFC4488一口は2006年5月に購読なしで参照されます。

1.  Introduction

1. 序論

   The REFER specification [3] specifies that every REFER creates an
   implicit subscription between the REFER-Issuer and the REFER-
   Recipient.

REFER仕様[3]は、あらゆるREFERがREFER-発行人とREFER受取人の間で暗黙の購読を作成すると指定します。

   This document defines a new SIP header field: "Refer-Sub" meaningful
   within a REFER transaction only.  This header field, when set to
   "false", specifies that a REFER-Issuer requests that the REFER-
   Recipient doesn't establish an implicit subscription and the
   resultant dialog.

このドキュメントは新しいSIPヘッダーフィールドを定義します: 「潜水艦を参照する、」 REFER取引だけの中で重要です。 「誤っていること」に設定されると、このヘッダーフィールドは、REFER-発行人が、REFER受取人が暗黙の購読と結果の対話を確立しないよう要求すると指定します。

   This document defines a new option tag: "norefersub".  This tag, when
   included in the Supported header field, indicates that a User Agent
   (UA) is capable of accepting a REFER request without creating an
   implicit subscription when acting as a REFER-Recipient.

このドキュメントは新しいオプションタグを定義します: "norefersub"。 Supportedヘッダーフィールドに含まれていると、このタグは、Userエージェント(UA)がREFER-受取人として機能するとき暗黙の購読を作成しないでREFER要求を受け入れることができるのを示します。

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 RFC 2119 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?

   To simplify discussions of the REFER method and its extensions, the
   three terms below are being used throughout the document:

REFER方法とその拡大の議論を簡素化するために、以下の3つの用語がドキュメント中で使用されています:

   o  REFER-Issuer: the UA issuing the REFER request

o 発行人を参照します: REFER要求を出すUA

   o  REFER-Recipient: the UA receiving the REFER request

o 受取人を参照します: REFERが要求するUA受信

   o  REFER-Target: the UA designated in the Refer-To Uniform Resource
      Identifier (URI)

o 目標を参照します: UAが中で指定した、Refer、-、Uniform Resource Identifier(ユリ)

3.  Motivation

3. 動機

   The REFER specification mandates that every REFER creates an implicit
   subscription between the REFER-Issuer and the REFER-Recipient.  This
   subscription results in at least one NOTIFY being sent from the
   REFER-Recipient to the REFER-Issuer.  The REFER-Recipient may choose
   to cancel the implicit subscription with this NOTIFY.  The REFER-
   Issuer may choose to cancel this implicit subscription with an
   explicit SUBSCRIBE (Expires: 0) after receipt of the initial NOTIFY.

REFER仕様は、あらゆるREFERがREFER-発行人とREFER-受取人の間で暗黙の購読を作成するのを強制します。 この購読はREFER-受取人からREFER-発行人に送られる少なくとも1NOTIFYをもたらします。 REFER-受取人は、このNOTIFYとの暗黙の購読を中止するのを選ぶかもしれません。 この暗黙の購読を中止する、REFER発行人が、選ぶかもしれない明白である、登録、(: 0を吐き出します) 初期のNOTIFYの領収書の後に。

   One purpose of requiring the implicit subscription and initial NOTIFY
   is to allow for the situation where the REFER request gets forked and
   the REFER-Issuer needs a way to see the multiple dialogs that may be
   established as a result of the forked REFER.  This is the same
   approach used to handle forking of SUBSCRIBE [4] requests.  Where the

暗黙の購読と初期のNOTIFYを必要とする1つの目的がREFER要求が分岐する状況を考慮することであり、REFER-発行人は股状のREFERの結果、確立されるかもしれない複数の対話を見る方法を必要とします。 これが分岐を扱うのにおいて中古の同じアプローチである、登録、[4]要求。 どこ

Levin                       Standards Track                     [Page 2]

RFC 4488             SIP REFER without Subscription             May 2006

レヴィン標準化過程[2ページ]RFC4488一口は2006年5月に購読なしで参照されます。

   REFER-Issuer explicitly specifies that forking not occur, the
   requirement that an implicit subscription be established is
   unnecessary.

REFER-発行人は、分岐が起こらないと明らかに指定して、暗黙の購読が確立されるという要件は不要です。

   Another purpose of the NOTIFY is to inform the REFER-Issuer of the
   progress of the SIP transaction that results from the REFER at the
   REFER-Recipient.  In the case where the REFER-Issuer is already aware
   of the progress of the requested operation, such as when the REFER-
   Issuer has an explicit subscription to the dialog event package at
   the REFER-Recipient, the implicit subscription and resultant NOTIFY
   traffic related to the REFER can create an unnecessary network
   overhead.

NOTIFYの別の目的はREFER-受取人にREFERから生じるSIP取引の進歩についてREFER-発行人に知らせることです。 REFER-発行人が既に意識しているREFER発行人がREFER-受取人に対話イベントパッケージの明白な購読を持っている時などの要求された操作の進歩の場合では、REFERに関連する暗黙の購読と結果のNOTIFY交通は不要なネットワークオーバーヘッドを作成できます。

4.  Definitions

4. 定義

   This document defines a new SIP header field: "Refer-Sub".  This
   header field is meaningful and MAY be used with a REFER request and
   the corresponding 2XX response only.  This header field set to
   "false" specifies that a REFER-Issuer requests that the REFER-
   Recipient doesn't establish an implicit subscription and the
   resultant dialog.  Note that when using this extension, the REFER
   remains a target refresh request (as in the default case -- when the
   extension is not used).

このドキュメントは新しいSIPヘッダーフィールドを定義します: 「潜水艦を参照する、」 このヘッダーフィールドは、重要であり、REFER要求と対応する2XX応答だけと共に使用されるかもしれません。 「誤っていること」に設定されたこのヘッダーフィールドは、REFER-発行人が、REFER受取人が暗黙の購読と結果の対話を確立しないよう要求すると指定します。 この拡張子を使用するREFERが目標のままで残っているとそれが要求をリフレッシュすることに注意してください(拡大が使用されていないときの不履行格のように)。

   This document adds the following entry to Table 2 of [2].  The
   additions to this table are also provided for extension methods at
   the time of publication of this document.  This is provided as a
   courtesy to the reader and is not normative in any way:

このドキュメントは[2]のTable2に以下のエントリーを加えます。 また、このドキュメントの公表時点で、このテーブルへの追加を拡大方法に提供します。 これは、礼儀として読者に提供されて、何らかの方法で規範的ではありません:

   Header field        where    proxy ACK  BYE  CAN  INV  OPT  REG  MSG

ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG MSG

   Refer-Sub           R, 2xx          -    -    -    -    -    -    -

潜水艦を参照しているR、2xx--、--、--、--、--、--、-

   Header field        where    SUB  NOT  REF  INF  UPD  PRA  PUB

ヘッダーフィールドどこSUB NOT REF INF UPD PRA PUB

   Refer-Sub           R, 2xx    -    -    o    -    -    -    -

潜水艦を参照しているR、2xx----o、--、--、--、-

   The Refer-Sub header field MAY be encrypted as part of end-to-end
   encryption.

Refer-潜水艦ヘッダーフィールドは終端間暗号化の一部としてコード化されるかもしれません。

   The syntax of the header field follows the BNF defined below:

ヘッダーフィールドの構文は以下で定義されたBNFに続きます:

    Refer-Sub       = "Refer-Sub" HCOLON refer-sub-value *(SEMI exten)
    refer-sub-value = "true" / "false"
    exten           = generic-param

潜水艦を参照している=、「」 サブ値を参照しているHCOLON*(SEMI exten)=「本当」潜水艦を参照しているサブ値を参照している/「誤った」extenはジェネリック-paramと等しいです。

   where the syntax of generic-param is defined in [2].

ジェネリック-paramの構文が[2]で定義されるところ。

Levin                       Standards Track                     [Page 3]

RFC 4488             SIP REFER without Subscription             May 2006

レヴィン標準化過程[3ページ]RFC4488一口は2006年5月に購読なしで参照されます。

   The "Refer-Sub" header field set to "false" MAY be used by the REFER-
   Issuer only when the REFER-Issuer can be certain that the REFER
   request will not be forked.

「潜水艦を参照する、」 REFER-発行人がREFER要求が分岐しないのを確信している場合があるときだけ、「誤っていること」に設定されたヘッダーフィールドはREFER発行人によって使用されるかもしれません。

   If the REFER-Recipient supports the extension and is willing to
   process the REFER transaction without establishing an implicit
   subscription, it MUST insert the "Refer-Sub" header field set to
   "false" in the 2xx response to the REFER-Issuer.  In this case, no
   implicit subscription is created.  Consequently, no new dialog is
   created if this REFER was issued outside any existing dialog.

REFER-受取人が、拡大を支持して、暗黙の購読を確立しないでREFER取引を処理することを望んでいるなら、挿入しなければならない、「潜水艦を参照する、」 ヘッダーフィールドはREFER-発行人への2xx応答で「誤っていること」にセットしました。 この場合、どんな暗黙の購読も作成されません。 その結果、このREFERがどんな既存の対話の外でも発行されたなら、どんな新しい対話も作成されません。

   If the REFER-Issuer inserts the "Refer-Sub" header field set to
   "false", but the REFER-Recipient doesn't grant the suggestion (i.e.,
   either does not include the "Refer-Sub" header field or includes the
   "Refer-Sub" header field set to "true" in the 2xx response), an
   implicit subscription is created as in the default case.

REFER-発行人差し込みである、「潜水艦を参照する、」 「誤っていること」に設定されたヘッダーフィールド、REFER-受取人だけが提案を承諾しない、(すなわち、どちらかがどんなインクルードもしない、「潜水艦を参照する、」 ヘッダーフィールドかインクルード、「潜水艦を参照する、」、2xx応答で「本当に」設定されたヘッダーフィールド)、暗黙の購読は不履行格のように作成されます。

   This document also defines a new option tag, "norefersub".  This tag,
   when included in the Supported header field, specifies that a User
   Agent (UA) is capable of accepting a REFER request without creating
   an implicit subscription when acting as a REFER-Recipient.

また、このドキュメントは新しいオプションタグ、"norefersub"を定義します。 Supportedヘッダーフィールドに含まれていると、このタグは、Userエージェント(UA)がREFER-受取人として機能するとき暗黙の購読を作成しないでREFER要求を受け入れることができると指定します。

   The REFER-Issuer can know the capabilities of the REFER-Recipient
   from the presence of the option tags in the Supported header field of
   the dialog initiating request or response.  Another way of learning
   the capabilities would be by using presence, such as defined in [6].
   However, if the capabilities of the REFER-Recipient are not known,
   using the "norefersub" tag with the Require header field is NOT
   RECOMMENDED.  This is due to the fact that in the event the REFER-
   Recipient doesn't support the extension, in order to fall back to the
   normal REFER, the REFER-Issuer will need to issue a new REFER
   transaction thus resulting in additional round-trips.

REFER-発行人は対話のSupportedヘッダーフィールドにおける、オプションタグの存在からのREFER-受取人が要求か応答を開始する能力を知ることができます。 能力について知る別の方法は[6]で定義されるように存在を使用することでしょう。 しかしながら、REFER-受取人の能力が知られていないなら、Requireヘッダーフィールドがある"norefersub"タグを使用するのは、NOT RECOMMENDEDです。 これは出来事では、REFER受取人が拡大を支持しないという事実のためです、正常なREFERへ後ろへ下がるためにREFER-発行人は、追加周遊旅行をもたらしながら、その結果、新しいREFER取引を発行する必要があるでしょう。

   As described in Section 8.2.2.3 in [2], a REFER-Recipient will reject
   a REFER request containing a Require: norefersub header field with a
   420 (Bad Extension) response unless it supports this extension.  Note
   that Require: norefersub can be present with a Refer-Sub: false
   header field.

セクション8.2.2で説明されるように、[2]の.3、REFER-受取人はRequireを含むREFER要求を拒絶するでしょう: この拡大を支持しない場合、norefersubヘッダーは420(悪いExtension)で応答をさばきます。 そのRequireに注意してください: norefersubはRefer-潜水艦について存在している場合があります: 誤ったヘッダーフィールド。

5.  Preventing Forking of REFER Requests

5. 分岐するのを防いで、要求を参照してください。

   The REFER specification allows for the possibility of forking a REFER
   request that is sent outside of an existing dialog.  In addition, a
   proxy may fork an unknown method type.  Should forking occur, the
   sender of the REFER with "Refer-Sub" will not be aware as only a
   single 2xx response will be forwarded by the forking proxy.  As a
   result, the responsibility is on the issuer of the REFER with "Refer-
   Sub" to ensure that no forking will result.

REFER仕様は既存の対話の外に送られるREFER要求を分岐させる可能性を考慮します。 さらに、プロキシは未知の方法タイプを分岐させるかもしれません。 分岐して、起こってください、REFERの送付者、「潜水艦を参照する、」 ただ一つの2xx応答だけが分岐しているプロキシによって進められるので、意識しているべきではありません。 その結果、分岐でないのが結果として生じるのを保証するために、責任は「潜水艦を参照してください」があるREFERの発行人にあります。

Levin                       Standards Track                     [Page 4]

RFC 4488             SIP REFER without Subscription             May 2006

レヴィン標準化過程[4ページ]RFC4488一口は2006年5月に購読なしで参照されます。

   If a REFER request to a given Request-URI might fork, the REFER-
   Issuer SHOULD NOT include the "Refer-Sub" header field.  The REFER-
   Issuer SHOULD use standardized mechanisms for ensuring the REFER
   request does not fork.  In absence of any other mechanism, the
   Request-URI of the REFER request SHOULD have Globally Routable User
   Agent URI (GRUU) properties according to the definitions of [5] as
   those properties ensure the request will not fork.

当然のことのRequest-URIへのREFER要求が分岐するかもしれなくて、REFER発行人SHOULD NOTがインクルードである、「潜水艦を参照する、」 ヘッダーフィールド REFER発行人SHOULD使用は、REFER要求が分岐しないのを確実にするためにメカニズムを標準化しました。 いかなる他のメカニズムの欠如ではも、それらの特性が要求を確実にするとき[5]の定義に従ってSHOULDにはGlobally Routable Userのエージェントのユリ(GRUU)の特性があるというREFER要求のRequest-URIは分岐しないでしょう。

6.  Example

6. 例

   An example of REFER that suppresses the implicit subscription is
   shown below.  Note that the conventions used in the SIP Torture Test
   Messages [7] document are reused, specifically the <allOneLine> tag.

暗黙の購読を抑圧するREFERに関する例は以下に示されます。 SIP Torture Test Messages[7]ドキュメントで使用されるコンベンションが再利用されて、明確に<allOneLineが>タグであることに注意してください。

   REFER sip:pc-b@example.com SIP/2.0
   Via: SIP/2.0/TCP issuer.example.com;branch=z9hG4bK-a-1
   From: <sip:a@example.com>;tag=1a
   <allOneLine>
   To: sip:b@example.com;opaque=urn:uuid:f8
   1d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a
   </allOneLine>
   Call-ID: 1@issuer.example.com
   CSeq: 234234 REFER
   Max-Forwards: 70
   Refer-To: <sip:c@example.com;method=INVITE>
   Refer-Sub: false
   Supported: norefersub
   Contact: sip:a@issuer.example.com
   Content-Length: 0

REFER一口: pc-b@example.com SIP/2.0Via: 一口/2.0/TCP issuer.example.com; ブランチ=z9hG4bK-a-1From: <一口: a@example.com 、gt;、;=1a<allOneLine>To:にタグ付けをしてください 一口: b@example.com;opaque =つぼ:uuid:f8 1d4fae-7dec-11d0-a765-00a0c91e6bf6; 格子=99a</allOneLine>Call-ID: 1@issuer.example.com CSeq: 234234 前方へマックスを参照してください: 70、To:を参照します。 <一口: c@example.com;method =は潜水艦を参照する状態で>を招待します: 偽のSupported: norefersub Contact: 一口: a@issuer.example.com のContent-長さ: 0

7.  IANA Considerations

7. IANA問題

   This document registers a new SIP header field "Refer-Sub".  This
   header field is only meaningful for the REFER request defined in RFC
   3515 [3] and the corresponding response.  The following information
   has been added to the SIP Header field sub-registry in the SIP
   Parameters Registry:

このドキュメントが新しいSIPヘッダーフィールドを示す、「潜水艦を参照する、」 RFC3515[3]で定義されたREFER要求と対応する応答だけに、このヘッダーフィールドは重要です。 以下の情報はSIP Parameters Registryにサブ登録しているSIP Header分野に加えられます:

   o  Header Name: Refer-Sub

o ヘッダー名: 潜水艦を参照します。

   o  Compact Form: None

o コンパクト形: なし

   o  Reference: RFC 4488

o 参照: RFC4488

   This document also registers a new SIP option tag, "norefersub",
   adding it to the SIP Option Tags sub-registry in the SIP Parameters
   Registry.  The required information for this registration, as
   specified in RFC 3261 [2], is:

また、このドキュメントは新しいSIPオプションタグ、"norefersub"を登録します、SIP Parameters Registryにサブ登録しているSIP Option Tagsにそれを加えて。 この登録のためのRFC3261[2]で指定される必須情報は以下の通りです。

Levin                       Standards Track                     [Page 5]

RFC 4488             SIP REFER without Subscription             May 2006

レヴィン標準化過程[5ページ]RFC4488一口は2006年5月に購読なしで参照されます。

   o  Name: norefersub

o 以下を命名してください。 norefersub

   o  Description: This option tag specifies a User Agent ability of
      accepting a REFER request without establishing an implicit
      subscription (compared to the default case defined in RFC 3515
      [3]).

o 記述: 暗黙の購読を確立しないで、このオプションタグはREFERが要求する受諾のUserエージェント能力を指定します。(RFC3515[3])で定義された不履行格にたとえられます。

8.  Security Considerations

8. セキュリティ問題

   The purpose of this SIP extension is to modify the expected behavior
   of the REFER-Recipient.  The change in behavior is for the REFER-
   Recipient not to establish a dialog and not to send NOTIFY messages
   back to the REFER-Issuer.  As such, a malicious inclusion of a
   "Refer-Sub" header field set to "false" reduces the processing and
   state requirements on the recipient.  As a result, its use in a
   denial-of-service attack seems limited.

このSIP拡張子の目的はREFER-受取人の予想された振舞いを変更することです。 振舞いにおける変化は、REFER受取人が対話を確立しないで、REFER-発行人にNOTIFYメッセージを送り返すことになっていません。 そういうものとしてaの悪意がある包含、「潜水艦を参照する、」 「誤っていること」に設定されたヘッダーフィールドは受取人に関する処理と州の要件を減らします。 その結果、サービス不能攻撃における使用は制限されるように思えます。

   On the other hand, by inserting a "Refer-Sub" header field set to
   "false", a man-in-the-middle (MitM) can potentially exploit the
   mechanism for easier (than an interception) suppression of the
   notifications from the REFER-Receiver without the REFER-Issuer
   noticing it.  Also, by removing a "Refer-Sub" header field set to
   "false", a MitM can cause the REFER-Receiver to generate
   notifications over the implicit dialog that otherwise had been
   suppressed by the REFER-Issuer.

aを挿入する、「潜水艦を参照している」 「誤っていること」に設定されたヘッダーフィールド、中央の男性の(MitM)は、REFER-受信機からの通知の、より簡単な(妨害より)秘匿にそれに気付きながら、REFER-発行人なしでメカニズムを潜在的に利用できます。 aを取り除く、「潜水艦を参照する、」 「誤っていること」に設定されたヘッダーフィールド、MitMはREFER-受信機にそうでなければREFER-発行人が抑圧されていた暗黙の対話の上で通知を発生させることができます。

   To protect against these kinds of MitM attacks, integrity protection
   should be used.  For example, the REFER-Issuer could use S/MIME as
   discussed in RFC 3261 [2] to protect against these kinds of attacks.

これらの種類のMitM攻撃から守るために、保全保護は使用されるべきです。 例えば、REFER-発行人はこれらの種類の攻撃から守るためにRFC3261[2]で議論するようにS/MIMEを使用できました。

9.  Acknowledgements

9. 承認

   The SIP community would like to thank Sriram Parameswar for his
   ideas, originally presented in "Suppressing Refer Implicit
   Subscription" (October 2002), which served as the basis for this
   specification.

SIP共同体は元々「抑圧して、暗黙の購読を参照する」(2002年10月)に提示されたこの仕様の基礎として機能した彼の考えについてSriram Parameswarに感謝したがっています。

Levin                       Standards Track                     [Page 6]

RFC 4488             SIP REFER without Subscription             May 2006

レヴィン標準化過程[6ページ]RFC4488一口は2006年5月に購読なしで参照されます。

10.  References

10. 参照

10.1.  Normative References

10.1. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]  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.

[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [3]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
        Method", RFC 3515, April 2003.

[3] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、2003年4月。

   [4]  Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

[4] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。

10.2.  Informative References

10.2. 有益な参照

   [5]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
        (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
         Work in Progress, October 2005.

[5] ローゼンバーグ、J.、「セッション開始プロトコル(一口)にRoutableユーザエージェント(UA)URI(GRUU)をグローバルに得て、使用すること」は進行中(2005年10月)で働いています。

   [6]  Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP)
        User Agent Capability Extension to Presence Information Data
        Format (PIDF)", Work in Progress, January 2006.

[6] 「存在情報データの形式(PIDF)へのセッション開始プロトコル(一口)ユーザエージェント能力拡大」というLonnfors、M.、およびK.キスは進行中(2006年1月)で働いています。

   [7]  Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
        and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture
        Test Messages", RFC 4475, May 2006.

[7] スパーク、R.Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH.Schulzrinne(エド)、「セッション開始プロトコル(一口)耐久テストメッセージ」(RFC4475)は2006がそうするかもしれません。

Author's Address

作者のアドレス

   Orit Levin
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

Oritレヴィンマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)

   Phone: 425-722-2225
   EMail: oritl@microsoft.com

以下に電話をしてください。 425-722-2225 メールしてください: oritl@microsoft.com

Levin                       Standards Track                     [Page 7]

RFC 4488             SIP REFER without Subscription             May 2006

レヴィン標準化過程[7ページ]RFC4488一口は2006年5月に購読なしで参照されます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(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.

このドキュメントは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 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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に情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Levin                       Standards Track                     [Page 8]

レヴィン標準化過程[8ページ]