RFC3508 日本語訳

3508 H.323 Uniform Resource Locator (URL) Scheme Registration. O.Levin. April 2003. (Format: TXT=10983 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           O. Levin
Request for Comments: 3508                                     RADVISION
Category: Informational                                       April 2003

コメントを求めるワーキンググループO.レヴィンの要求をネットワークでつないでください: 3508年のRADVISIONカテゴリ: 情報の2003年4月

        H.323 Uniform Resource Locator (URL) Scheme Registration

H.323Uniform Resource Locator(URL)計画登録

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   ITU-T Recommendation H.323 version 4 introduced an H.323-specific
   Uniform Resource Locator (URL).  This document reproduces the H323-
   URL definition found in H.323, and is published as an RFC for ease of
   access and registration with the Internet Assigned Numbers Authority
   (IANA).

ITU-T Recommendation H.323バージョン4はH.323特有のUniform Resource Locator(URL)を導入しました。 このドキュメントは、H.323で見つけられたH323URL定義を再生させて、インターネットAssigned民数記Authority(IANA)とのアクセスと登録の容易さのためのRFCとして発表されます。

Conventions used in this document

本書では使用されるコンベンション

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

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

Table of Contents

目次

   1. Introduction...................................................2
   2. URL Scheme Formal Syntax Definition and Character Encoding.....2
   3. Intended Usage.................................................3
   4. Applications and/or protocols, which may use H.323 URL scheme..3
   5. Security Considerations........................................3
   6. IANA Considerations............................................4
   References........................................................4
   Acknowledgments...................................................5
   Author's Address..................................................5
   Full Copyright Statement..........................................6

1. 序論…2 2. URLの計画の正式な構文定義とキャラクターコード化…2 3. 用法を意図します…3 4. アプリケーション、そして/または、プロトコル。(そのプロトコルはH.323 URL計画を使用するかもしれません)。3 5. セキュリティ問題…3 6. IANA問題…4つの参照箇所…4つの承認…5作者のアドレス…5 完全な著作権宣言文…6

Levin                        Informational                      [Page 1]

RFC 3508                    H.323 URL Scheme                  April 2003

3508時間.323の[1ページ]RFC URL計画2003年4月の情報のレヴィン

1.   Introduction

1. 序論

   ITU-T Recommendations H.323 [3] and H.225.0 [4] define a system for
   multimedia communications services over packet based networks.
   H.225.0 [4] defines an alias type for carrying any standard Uniform
   Resource Locator (URL).  H.323 version 4 [3] introduced an H.323-
   specific URL, which may be used to resolve the address of a network
   entity to which H.323 calls may be directed.

ITU-TのRecommendations H.323[3]とH.225.0[4]はパケットに基づいているネットワークの上のマルチメディア通信サービスのシステムを定義します。 H.225.0[4]はどんな標準のUniform Resource Locator(URL)も運ぶための別名タイプを定義します。 H.323バージョン4[3]はH.323の特定のURLを紹介しました。(それは、H.323が呼ぶネットワーク実体のアドレスが指示されるかもしれないと決議するのに使用されるかもしれません)。

   This document reproduces the H323-URL definition found in ITU-T
   recommendation H.323 [3] and is published as an RFC for ease of
   access and IANA registration.

このドキュメントは、ITU-T推薦H.323[3]で見つけられたH323-URL定義を再生させて、アクセスとIANA登録の容易さのためのRFCとして発表されます。

2.   URL Scheme Formal Syntax Definition and Character Encoding

2. URLの計画の正式な構文定義とキャラクターコード化

   The H.323 URL is defined in ABNF as shown below.  Note that it
   utilizes the Core Rules specified in section 6.1 of [2].

H.323 URLはABNFで以下に示すように定義されます。 [2]のセクション6.1で指定されたCore Rulesを利用することに注意してください。

   H323-URL    =   "h323:" address [ url-parameters ]
   address     =   user / "@" hostport / user "@" hostport
   user        =   1*(%x21-24 / %x26-3F / %x41-7F / escaped)
                        ; The symbols "%", "@", and symbols with
                        ; a character value below 0x21 may be
                        ; represented as escaped sequences.
   hostport    =   host [ ":" port]
   host        =   hostname / IPv4address / IPv6reference
   hostname    =   *( domainlabel "." ) toplabel [ "." ]
   domainlabel =   alphanum / alphanum *( alphanum / "-" ) alphanum
   toplabel    =   ALPHA / ALPHA *( alphanum / "-" ) alphanum
   IPv4address =   1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
   IPv6reference   =  "[" IPv6address "]"
   IPV6address =   hexpart [ ":" IPv4address ]
   hexpart     =   hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
   hexseq      =   hex4 *( ":" hex4 )
   hex4        =   1*4HEXDIG
   port        =   1*DIGIT
   url-parameters  =   *( ";" url-parameter )
   url-parameter   =   1*(%x21-24 / %x26-3A / %x3C-7F / escaped)
                          ; Specific parameter definitions are for
                          ; further study.
                          ; The symbols "%", ";", and symbols
                          ; with a character value below 0x21 may be
                          ; represented as escaped sequences.
   alphanum    =   ALPHA / DIGIT
   escaped     =   "%" HEXDIG HEXDIG

H323-URL=、「h323:」 [url-パラメタ]アドレス=ユーザ/"@"ユーザhostport/"@"hostportユーザ=1*(x21-24/%x41-7x26-3F/%F/が逃げた%)を記述してください。 「%」、"@"、およびシンボルを象徴する、。 0×21の下における文字値はそうです。 「逃げられた系列hostportがホスト[「:」 ポート]ホスト=ホスト名/ IPv4address / IPv6referenceホスト名=*と等しいので表される、(domainlabel、」、」、)、toplabel、[「.」、]、domainlabel=alphanum / alphanum*(alphanum/「-」)alphanum toplabel=アルファ/アルファ*(alphanum/「-」)alphanum IPv4addressが1*3DIGITと等しい、」、」 「1*3DIGIT」、」 「1*3DIGIT」、」 「「[「IPv6address」]」という1*3DIGIT IPv6reference=IPV6address=hexpart[「:」 IPv4address]hexpartはhexseq / hexseqと等しい」:、:、」 「[hexseq]/」:、:、」 [hexseq]hexseqが1*ケタurl-パラメタ1*4HEXDIG hex4*(「:」 hex4)hex4=ポート==*と等しい、(「; 」 urlパラメタ) url-パラメタ=1*(x21-24/%x26-3A/%x3C-7F/が逃げた%)。 定義がある特定のパラメタ。 さらに研究してください。 ; 「「%」というシンボル」; 」 シンボル。 文字値で、0×21はそうです。 逃げられた系列alphanum=アルファー/DIGITが=「%」HEXDIG HEXDIGから逃げたので、表されます。

   The host is case insensitive.

ホストは大文字と小文字を区別しないです。

Levin                        Informational                      [Page 2]

RFC 3508                    H.323 URL Scheme                  April 2003

3508時間.323の[2ページ]RFC URL計画2003年4月の情報のレヴィン

   The "user" is a Unicode [8] string that shall be UTF-8 [7] encoded
   and then escaped as necessary.  In the "user" field, the characters
   with a numeric value below 0x80 are case insensitive and the
   characters with a numeric value above or equal to 0x80 are case
   sensitive.

「ユーザ」は必要に応じてコード化されて、次に逃げられたUTF-8にな[7]るユニコード[8]ストリングです。 「ユーザ」分野では、0×80の下における数値があるキャラクタが大文字と小文字を区別しないです、そして、0×80と上の、または、等しい数値があるキャラクタが大文字と小文字を区別しています。

   The character set and case sensitivity of the "url-parameter" is
   specified in each parameter definition.

「url-パラメタ」の文字の組とケース感度はそれぞれのパラメタ定義で指定されます。

3.   Intended Usage

3. 意図している用法

   The H.323 URL is intended to help an entity resolve the address of
   another H.323 entity, where an "entity" may be a user, a device, or a
   service.  The "user" portion of the URL specifies an alias for the
   entity, without carrying any information about the location of the
   entity.  The "hostport", on the other hand, is the domain name of an
   Endpoint, Gatekeeper, Border Element, or other functional element to
   which H.323 calls may be directed or for which services may be
   performed.

H.323 URLが、実体が「実体」がユーザ、装置、またはサービスであるかもしれない別のH.323実体のアドレスを決議するのを助けることを意図します。 URLの「ユーザ」一部が実体に別名を指定します、実体の位置のどんな情報も運ばないで。 他方では、"hostport"はEndpointのドメイン名です、Gatekeeper、Border Element、または、H.323が呼ぶ他の機能要素が、指示されるか、またはどのサービスのために実行されるかもしれないか。

4.   Applications and/or protocols, which may use H.323 URL scheme

4. アプリケーション、そして/または、プロトコル。(そのプロトコルはH.323 URL計画を使用するかもしれません)。

   H.323 URLs may be carried by other protocols, such as SIP [6] or TRIP
   [9].  H.323 URLs may be also contained within web pages or within XML
   data, which may be utilized by H.323 entities in order to initiate
   calls or perform services.

H.323URLはSIP[6]かTRIP[9]などの他のプロトコルによって運ばれるかもしれません。 また、H.323URLはウェブページ以内かXMLデータの中に含まれるかもしれません。データは、呼び出しを開始するか、またはサービスを実行するのにH.323実体によって利用されるかもしれません。

5.   Security Considerations

5. セキュリティ問題

   When an H.323 URL is carried within H.225.0 [4] messages, security is
   addressed by the H.235 security framework [5].  When an H.323 URL
   carried within other protocols (such as SIP [6]), the security is
   addressed within the corresponding protocol.

H.323 URLがH.225.0[4]メッセージの中で運ばれるとき、セキュリティはH.235セキュリティフレームワーク[5]によって記述されます。 H.323 URLは他のプロトコルの中で運びました。いつ、(SIP[6])としてあれほど、セキュリティは対応するプロトコルの中に記述されるか。

   In general, security, as it relates to the usage and carriage of the
   H.323 URLs, is considered as an issue that should be addressed within
   scope of H.323 or other relevant protocols and is not within the
   scope of this document.

一般に、H.323URLの用法とキャリッジに関連するとき、セキュリティはH.323か他の関連プロトコルの範囲の中に記述されるべきであり、このドキュメントの範囲の中にない問題であるとみなされます。

Levin                        Informational                      [Page 3]

RFC 3508                    H.323 URL Scheme                  April 2003

3508時間.323の[3ページ]RFC URL計画2003年4月の情報のレヴィン

6.   IANA Considerations

6. IANA問題

   The purpose of this document is serving as a reference point for the
   purposes of registering the H.323 URL scheme with IANA.

このドキュメントの目的はH.323 URL計画をIANAに登録する目的のための基準点として機能しています。

   Having the URL registered with IANA will ensure that there is no
   duplication of the URL scheme "h323".  This document reproduces the
   exact H323-URL definition as published in ITU-T Recommendation H.323
   [3].

URLをIANAに登録させるのは、計画"h323"というURLの複製が全くないのを確実にするでしょう。 このドキュメントはITU-T Recommendation H.323[3]で発行されるように正確なH323-URL定義を再生させます。

   Registration Template

登録テンプレート

      URL scheme name: h323

URL計画名: h323

      URL scheme syntax: Section 2 of RFC 3508

URL計画構文: セクション2 RFC3508について

      Character encoding considerations: Section 2 of RFC 3508

問題をコード化するキャラクター: セクション2 RFC3508について

      Intended usage: Section 3 of RFC 3508

意図している用法: セクション3 RFC3508について

      Applications and/or protocols which use this scheme: Section 4 of
      RFC 3508

この計画を使用するアプリケーション、そして/または、プロトコル: セクション4 RFC3508について

      Interoperability considerations: None.  (Section 2 of RFC 3508
      contains the first version of "h323" URL definition.)

相互運用性問題: なし。 (RFC3508のセクション2は"h323"URL定義の最初のバージョンを含みます。)

      Security considerations: Section 5 of RFC 3508

セキュリティ問題: セクション5 RFC3508について

      Relevant publications: [3] and [4]

関連刊行物: そして[3]。[4]

      Contact: Orit Levin, orit@radvision.com

接触: Oritレヴィン、 orit@radvision.com

      Author/Change Controller: IESG

コントローラを書くか、または変えてください: IESG

References

参照

   [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]  Crocker, D., Editor, and P. Overell "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

[2]クロッカー、D.、エディタ、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

   [3]  ITU-T Recommendation H.323v.4 "Packet-based multimedia
        communications systems", November 2000.

2000年11月の[3]ITU-T Recommendation H.323v.4「パケットベースのマルチメディア通信システム。」

   [4]  ITU-T Recommendation H.225.0 "Call signalling protocols and
        media stream packetization for packet-based multimedia
        communication systems", November 2000.

[4] ITU-T Recommendation H.225.0が「パケットベースのマルチメディア通信システムのためにプロトコルに合図して、メディアを流れのpacketizationと呼ぶ」、11月2000日

Levin                        Informational                      [Page 4]

RFC 3508                    H.323 URL Scheme                  April 2003

3508時間.323の[4ページ]RFC URL計画2003年4月の情報のレヴィン

   [5]  ITU-T Recommendation H.235 "Security and Encryption for H Series
        (H.323 and other H.245 based) multimedia terminals", November
        2000.

[5] ITU-T Recommendation H.235、「H Series(ベースのH.323と他のH.245)マルチメディア端末へのセキュリティとEncryption」、11月2000日

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

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

   [7]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

[7]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変化形式」RFC2279。

   [8]  ISO/IEC 10646-1:1993, Information technology "Universal
        Multiple-Octet Coded Character Set (USC)" Part 1: Architecture
        and Basic Multilingual Plane.

[8] ISO/IEC10646-1:1993、情報技術「普遍的な複数の八重奏コード化文字集合(USC)」Part1: 構造と基本多言語水準。

   [9]  Rosenberg, J., Salama, H. and M. Squire, "Telephony Routing over
        IP (TRIP)", RFC 3219, January 2002.

[9] ローゼンバーグ、J.、サラマ、H.、およびM.は2002年1月に「電話はIP(旅行)の上で掘る」RFC3219に付き添います。

Acknowledgments

承認

   This document is prepared and posted on behalf of SG-16 ITU-T.  I
   wish to thank Paul E. Jones, Robert Callaghan and Cullen Jennings for
   their comments and active help.

このドキュメントは、SG-16 ITU-Tを代表して準備されて、掲示されます。 彼らのコメントと活発な助けについてポール・E.ジョーンズ、ロバート・キャラハン、およびCullenジョニングスに感謝申し上げます。

Author's Address

作者のアドレス

   Orit Levin
   RADVISION
   266 Harristown Road
   Glen Rock, NJ USA

OritレヴィンRADVISION266Harristown道路谷間岩石、ニュージャージー米国

   Phone:  +1-201-689-6330
   EMail:  orit@radvision.com

以下に電話をしてください。 +1-201-689-6330 メールしてください: orit@radvision.com

Levin                        Informational                      [Page 5]

RFC 3508                    H.323 URL Scheme                  April 2003

3508時間.323の[5ページ]RFC URL計画2003年4月の情報のレヴィン

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Levin                        Informational                      [Page 6]

レヴィンInformationalです。[6ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Android Maps API Keyを取得する方法 Google Mapsを利用する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る