RFC5134 日本語訳

5134 A Uniform Resource Name Namespace for the EPCglobal ElectronicProduct Code (EPC) and Related Standards. M. Mealling. January 2008. (Format: TXT=18352 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        M. Mealling
Request for Comments: 5134                      Refactored Networks, LLC
Category: Informational                                     January 2008

コメントを求める要求を荒びきにして、作業部会M.をネットワークでつないでください: 5134はネットワーク、LLCカテゴリをRefactoredしました: 情報の2008年1月

                 A Uniform Resource Name Namespace for
   the EPCglobal Electronic Product Code (EPC) and Related Standards

EPCglobalの電子製品コード(EPC)と関連規格のための一定のリソース名前名前空間

Status of This 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.

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

Abstract

要約

   This document describes URN namespaces that will identify various
   objects within the EPCglobal system for identifying products within
   ecommerce and supply chain management applications.

このドキュメントはecommerceの中で製品を特定するEPCglobalシステムの中で様々な物を特定するURN名前空間とサプライ・チェーン・マネジメントアプリケーションについて説明します。

1.  Introduction

1. 序論

   The EPCglobal Architecture Framework [6] is a set of specifications
   for reading, managing, and acting on object codes and other sensor
   data as physical objects pass through a supply chain.  Events and
   metadata about physical objects are exchanged via EPCglobal
   Electronic Product Code Information Services (EPCIS) that are
   essentially web services that implement agreed upon schema and
   interfaces.

対象物がサプライ・チェーンを通り抜けるとき、EPCglobal Architecture Framework[6]はオブジェクトコードを読んで、管理して、影響するための仕様と他のセンサデータの1セットです。 本質的には道具が図式とインタフェースで同意したウェブサービスであるEPCglobal Electronic Product Code情報Services(EPCIS)を通して対象物に関する出来事とメタデータを交換します。

   Each object that is tracked by the EPCglobal Architecture Framework
   is identified by one or more managed identifiers.  In many cases,
   these identification systems existed prior to the Internet becoming
   widely used.  One such namespace is the Global Trade Item Number, or
   GTIN [7].  GTINs are widely used in global commerce and are managed
   by GS1.  In order for the EPCglobal Architecture Framework to
   leverage the Internet to the fullest extent possible, the GTIN
   namespace (and others, such as Global Location Numbers (GLNs),
   Serialized Shipping Container Code (SSCC), etc. [7]) need to be
   directly compatible with the URI family of identifiers.

EPCglobal Architecture Frameworkによって跡をつけられる各物は1時までに特定されたか、またはさらに管理された識別子です。 多くの場合、これらの同定システムは広く使用されるようになるインターネットの前に存在しました。 そのような名前空間の1つは、Global Trade Item Number、またはGTIN[7]です。 GTINsは世界貿易に広く使用されて、GS1によって管理されます。 EPCglobal Architecture Frameworkが可能な最もふくよかな範囲、GTIN名前空間にインターネットに投機する命令で(そして、Global Location民数記(GLNs)、Serialized送料Container Code(SSCC)などの他のもの [7]) 直接識別子のURI家族と互換性があるのが必要です。

   The use of GTINs, GLNs, and SSCCs are all managed by GS1.  Their use
   within the EPCglobal Architecture Framework is managed by the GS1
   subsidiary known as EPCglobal, Inc.  For these, and possibly future

GTINs、GLNs、およびSSCCsの使用はGS1によってすべて管理されます。 EPCglobal Architecture Frameworkの中の彼らの使用がEPCglobal Inc.Forとして知られているGS1子会社によって管理される、これら、およびことによると未来

Mealling                     Informational                      [Page 1]

RFC 5134                      The EPC URN                   January 2008

EPCつぼの2008年1月に情報[1ページ]のRFC5134を荒びきにします。

   identification systems, a single Uniform Resource Name (URN)
   Namespace ID (NID) is being requested: 'epc'.  Each of the identifier
   namespaces mentioned will have a separate sub-space beneath the top
   level 'epc' NID.

同定システムであり、独身のUniform Resource Name(URN)Namespace ID(NID)は要求されています: 'epc'。 名前空間は、先端の下の別々のサブスペースがそれぞれに関する識別子で'epc'NIDを平らにすると言及しました。

   In addition to physical object identifiers, the EPCglobal
   Architecture Framework requires new namespaces for naming system
   components.  In many cases, an interface within the EPCglobal
   Architecture Framework is XML [11] based and as such will require
   naming schemes for its XML schema [9] and various namespaces [10].
   For these uses, another Uniform Resource Name (URN) Namespace ID
   (NID) is being requested: 'epcglobal'.  Each specification or system
   component within the EPCglobal Architecture Framework will have a
   separate sub-space beneath the top level 'epcglobal' NID.

対象物識別子に加えて、EPCglobal Architecture Frameworkは、システムの部品を命名するために新しい名前空間を必要とします。 多くの場合、EPCglobal Architecture Frameworkの中のインタフェースは、基づくXML[11]であり、図式[9]と様々な名前空間[10]とXMLの計画を命名するのをそういうものとして必要とするでしょう。 これらの用途において、別のUniform Resource Name(URN)Namespace ID(NID)は要求されています: 'epcglobal'。 EPCglobal Architecture Frameworkの中のそれぞれの仕様かシステムの部品で、先端の下の別々のサブスペースは'epcglobal'NIDを平らにするでしょう。

   Since the EPCglobal Architecture Framework is engineered for
   widespread and general use, this namespace specification is a formal
   one, and the namespace IDs that are being requested are 'epc' and
   'epcglobal'.  It is important to note that it is the explicit intent
   that various sub-namespaces of the 'epc' NID actually name real,
   physical objects and/or corporeal entities.  In contrast, sub-
   namespaces of the 'epcglobal' NID name logical or software
   constructs, such as schema namespaces.

要求されている名前空間IDは、EPCglobal Architecture Frameworkが広範囲の、そして、一般的な使用のために設計されるので、この名前空間仕様は正式なものであり、'epc'と'epcglobal'です。 それが明白な意図であることに注意するために、'epc'NIDの様々なサブ名前空間が実際に本当の、そして、物理的な物、そして/または、肉体的な実体を命名するのは、重要です。 対照的に、'epcglobal'NIDのサブ名前空間は図式名前空間などの論理的であるかソフトウェア構造物を命名します。

2.  'epc' Registration Template

2. 'epc'登録テンプレート

   Namespace ID:

名前空間ID:

         "epc"

"epc"

   Registration Information:

レジスト情報:

         Registration Version Number: 1
         Registration Date: 2008-01-16

登録バージョン番号: 1 登録日付: 2008-01-16

   Declared registrant of the namespace:

名前空間の宣言している記入者:

         EPCglobal, Inc. is a subsidiary of GS1
         Princeton Pike Corporate Center
         1009 Lenox Drive, Suite 202
         Lawrenceville, NJ 08648, USA
         bhogan@epcglobalinc.org
         Tel: +1-609-620-4585

EPCglobal Inc.はGS1プリンストンPike Corporateセンター1009レノックスDriveの子会社です、Suite202ローレンスビル、ニュージャージー 08648、米国 bhogan@epcglobalinc.org Tel: +1-609-620-4585

Mealling                     Informational                      [Page 2]

RFC 5134                      The EPC URN                   January 2008

EPCつぼの2008年1月に情報[2ページ]のRFC5134を荒びきにします。

   Declaration of structure:

構造の宣言:

         The normative specification of the structure of the 'epc'
         namespace is "EPC Tag Data Standards" [5].  The examples given
         below are not normative.

'epc'名前空間の構造の標準の仕様は「EPCタグデータの規格」[5]です。 以下に出された例は規範的ではありません。

         The 'epc' namespace is a set of sub-namespaces that can be
         extended in the future.  The following ABNF [2] defines how the
         sub-namespaces are identified and any restrictions on their
         syntax (definitions not specified below can be found in RFC
         2141 [1]):

'epc'名前空間は将来広げることができる1セットのサブ名前空間です。 以下のABNF[2]はそれらの構文でサブ名前空間が特定されていてどうあらゆる制限であるかを定義します。(RFC2141[1])で以下で指定されなかった定義は見つけることができます:

   EPC-URN     = "urn:epc:" sub-ns-name ":" sub-ns
   sub-ns-name = let-num [ 1*let-num-hyp ]
   sub-ns      = 1*<URN chars>
   let-num     = upper / lower / number
   let-num-hyp = upper / lower / number / "-"
   upper       = %x41-5A ; "A" - "Z"
   lower       = %x61-7A ; "a" - "z"
   number      = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
                 "8" / "9"

EPC-つぼの=、「つぼ: epc:、」 「サブナノ秒の名前」:、」 サブナノ秒サブナノ秒の名前=が-numにさせる、[1*上側の、または、下側の/num-hyp] 1*<URN雑用>が-numにさせるサブナノ秒==番号をさせているnum-hypをさせている=上側の、または、低い/数/「-」上側の=%x41-5A。 「A」--「Z」低い=%x61-7A。 "a"、--、「z」が=に付番する「0インチ/、「1インチ/、「2インチ/、「3インチ/、「4インチ/、「5インチ/、「6インチ/、「7インチ/、「8インチ/「9インチ」

         For example, the sub-namespace 'sgtin' has the following
         definition (this ABNF is non-normative):

例えば、サブ名前空間'sgtin'には、以下の定義があります(このABNFは非規範的です):

   SGTIN-URI        = "urn:epc:id:sgtin:" SGTINURIBody
   SGTINURIBody     = 2*(PaddedNumericComponent ".") NumericComponent
   NumericComponent = ZeroComponent / NonZeroComponent
   ZeroComponent    = "0"
   NonZeroComponent = NonZeroDigit *Digit
   PaddedNumericComponent = *Digit
   Digit = "0" / NonZeroDigit
   NonZeroDigit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

SGTIN-URI=、「つぼ:epc:イド: sgtin:、」 「SGTINURIBody SGTINURIBody=2*、(PaddedNumericComponent、」、」、)、NumericComponent NumericComponentがZeroComponent / NonZeroComponent ZeroComponent=と等しい、「0インチのNonZeroComponentがNonZeroDigit*ケタPaddedNumericComponent=*ケタケタ=と等しい、「0インチ/NonZeroDigit NonZeroDigitが等しい、「1インチ/、「2インチ/、「3インチ/、「4インチ/、「5インチ/、「6インチ/、「7インチ/、「8インチ/「9インチ」

   This equates to a namespace that has three period separated series of
   digits:

これは3つの期間の切り離されたシリーズのケタを持っている名前空間に一致しています:

                        urn:epc:id:sgtin:900100.0003456.1234567

つぼ:epc:イド:sgtin:900100.0003456、.1234567

   The first series is a company prefix, the second denotes a product
   reference assigned by that company, and the third is a serial number
   for a specific instance of their product.  Note that leading zeros
   are significant.

最初のシリーズは会社の接頭語です、そして、2番目はその会社によって割り当てられた製品参照を指示します、そして、3番目はそれらの製品の特定の例のための通し番号です。 先行ゼロがかなりであることに注意してください。

Mealling                     Informational                      [Page 3]

RFC 5134                      The EPC URN                   January 2008

EPCつぼの2008年1月に情報[3ページ]のRFC5134を荒びきにします。

   Relevant ancillary documentation:

関連付属のドキュメンテーション:

         The standards that define the EPCglobal Architecture Framework
         and the processes for creating new sub-namespaces are managed
         by EPCglobal, Inc. and can be found on its website.  Several
         sub-namespaces are defined in the "EPC Tag Data Standards" [5].

EPCglobal Architecture Frameworkを定義する規格と新しいサブ名前空間を作成するための過程をEPCglobal Inc.が管理して、ウェブサイトで見つけることができます。 いくつかのサブ名前空間が「EPCタグデータの規格」[5]で定義されます。

   Identifier uniqueness considerations:

識別子ユニークさの問題:

         The namespaces that make up the 'epc' namespace are all managed
         by an organization with almost 50 years of namespace management
         experience.  In all cases (existing or new), the uniqueness of
         each namespace is an inherent part of the EPCglobal
         Architecture Framework.

'epc'名前空間を作る名前空間はおよそ50年間の名前空間管理経験で組織によってすべて管理されます。 すべての場合(既存の、または、新しい)では、それぞれの名前空間のユニークさはEPCglobal Architecture Frameworkの固有の部分です。

   Identifier persistence considerations:

識別子固執問題:

         The assignment process guarantees that names are not reassigned
         and that the binding between the name and its resource is
         permanent, regardless of any standards or organizational
         changes.

課題の過程は名前が再選任されないで、名前とそのリソースの間の結合が永久的であることを保証します、どんな規格や組織変動にかかわらず。

   Process of identifier assignment:

識別子課題の過程:

         Names are assigned by the EPCglobal standards publication
         process and by any entities that are sub-delegated by
         EPCglobal.  It is important to note that in many cases the
         names assigned will explicitly denote physical objects and not
         an electronic representation of that object.

名前はEPCglobal規格公表の過程とどんなEPCglobalによってサブ代表として派遣された実体によっても割り当てられます。 名前が割り当てた多くの場合におけるそれが明らかに電子表現ではなく、その物の対象物を指示することに注意するのは重要です。

   Process of identifier resolution:

識別子解決の過程:

         Certain sub-namespaces are resolved via the Object Naming
         Service, defined in "Object Naming Service (ONS) Version 1.0"
         [4], which is a valid implementation of the Dynamic Delegation
         Discovery System that is defined in RFC 3401 [3].

あるサブ名前空間は「RFC3401[3]で定義されるダイナミックな代表団発見システムの有効な実現である物の命名サービス(ONS)バージョン1インチ[4]」で定義されたObject Naming Serviceを通して決議されています。

   Rules for Lexical Equivalence:

語彙等価性のための規則:

         The entire URN is case-sensitive.

全体のURNは大文字と小文字を区別しています。

   Conformance with URN Syntax:

つぼの構文との順応:

         There are no additional characters reserved except as noted in
         the ABNF above.

ABNFに述べられる以外に、予約された添字が全く上にありません。

Mealling                     Informational                      [Page 4]

RFC 5134                      The EPC URN                   January 2008

EPCつぼの2008年1月に情報[4ページ]のRFC5134を荒びきにします。

   Validation mechanism:

合法化メカニズム:

         In the case of each sub-namespace, there will be namespace-
         specific rules for determining validity.  In each case, the
         reader is referred to the appropriate EPCglobal-maintained
         documentation.

それぞれのサブ名前空間の場合には、正当性を決定するための名前空間の特定の規則があるでしょう。 その都度、読者は適切なEPCglobalによって維持されたドキュメンテーションを参照されます。

   Scope:

範囲:

         Global

グローバル

3.  'epcglobal' Registration Template

3. 'epcglobal'登録テンプレート

   Namespace ID:

名前空間ID:

         "epcglobal"

"epcglobal"

   Registration Information:

レジスト情報:

         Registration Version Number: 1
         Registration Date: 2007-03-06

登録バージョン番号: 1 登録日付: 2007-03-06

   Declared registrant of the namespace:

名前空間の宣言している記入者:

         EPCglobal, Inc. is a subsidiary of GS1
         Princeton Pike Corporate Center
         1009 Lenox Drive, Suite 202
         Lawrenceville, NJ 08648, USA
         bhogan@epcglobalinc.org
         Tel: +1-609-620-4585

EPCglobal Inc.はGS1プリンストンPike Corporateセンター1009レノックスDriveの子会社です、Suite202ローレンスビル、ニュージャージー 08648、米国 bhogan@epcglobalinc.org Tel: +1-609-620-4585

   Declaration of structure:

構造の宣言:

         The normative specifications for the structure of the
         'epcglobal' namespace are various standards available at
         EPCglobal's public website.  The examples given below are not
         normative.

'epcglobal'名前空間の構造のための標準の仕様はEPCglobalの公共のウェブサイトで利用可能な様々な規格です。 以下に出された例は規範的ではありません。

         The 'epcglobal' namespace is a set of sub-namespaces that can
         be extended in the future.  The following ABNF defines how the
         sub-namespaces are identified and any restrictions on their
         syntax (definitions not specified below can be found in RFC
         2141 [1]):

'epcglobal'名前空間は将来広げることができる1セットのサブ名前空間です。 以下のABNFはそれらの構文でサブ名前空間が特定されていてどうあらゆる制限であるかを定義します。(RFC2141[1])で以下で指定されなかった定義は見つけることができます:

Mealling                     Informational                      [Page 5]

RFC 5134                      The EPC URN                   January 2008

EPCつぼの2008年1月に情報[5ページ]のRFC5134を荒びきにします。

   EPCGLOBAL-URN = "urn:epcglobal:" subnsname ":" subns
   subnsname     = let-num [ 1*let-num-hyp ]
   subns         = 1*<URN chars>
   let-num       = upper / lower / number
   let-num-hyp   = upper / lower / number / "-"
   upper         = %x41-5A ; "A" - "Z"
   lower         = %x61-7A ; "a" - "z"
   number        = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
                   "8" / "9"

EPCGLOBAL-つぼの=、「つぼ: epcglobal:、」 "subnsname":、」 subns subnsname=が-numにさせる、[1*上側の、または、下側の/num-hyp] 1*<URN雑用>が-numにさせるsubns==番号をさせているnum-hypをさせている=上側の、または、低い/数/「-」上側の=%x41-5A。 「A」--「Z」低い=%x61-7A。 "a"、--、「z」が=に付番する「0インチ/、「1インチ/、「2インチ/、「3インチ/、「4インチ/、「5インチ/、「6インチ/、「7インチ/、「8インチ/「9インチ」

   For example, the identifier "urn:epcglobal:ale:xsd:1" is defined in
   the "Application Level Events 1.0 Specification" [8] for use as an
   XML namespace identifier for XML documents conforming to that
   specification.

例えば、識別子、「つぼ:epcglobal:エール:xsd:1インチはXML名前空間識別子としてのその仕様に一致しているXMLドキュメントの使用のための「アプリケーションレベルイベント1.0仕様」[8]で定義されます」。

   Relevant ancillary documentation:

関連付属のドキュメンテーション:

         The standards that define the EPCglobal Architecture Framework
         and the processes for creating new sub-namespaces are managed
         by EPCglobal, Inc. and can be found on its website.

EPCglobal Architecture Frameworkを定義する規格と新しいサブ名前空間を作成するための過程をEPCglobal Inc.が管理して、ウェブサイトで見つけることができます。

   Identifier uniqueness considerations:

識別子ユニークさの問題:

         The namespaces that make up the 'epcglobal' namespace are all
         managed by an organization with almost 50 years of namespace
         management experience.  In all cases, the uniqueness of each
         namespace is an inherent part of the EPCglobal Architecture
         Framework.

'epcglobal'名前空間を作る名前空間はおよそ50年間の名前空間管理経験で組織によってすべて管理されます。 すべての場合では、それぞれの名前空間のユニークさはEPCglobal Architecture Frameworkの固有の部分です。

   Identifier persistence considerations:

識別子固執問題:

         The assignment process guarantees that names are not reassigned
         and that the binding between the name and its resource is
         permanent, regardless of any standards or organizational
         changes.

課題の過程は名前が再選任されないで、名前とそのリソースの間の結合が永久的であることを保証します、どんな規格や組織変動にかかわらず。

   Process of identifier assignment:

識別子課題の過程:

         Names are assigned by the EPCglobal, Inc. standards publication
         process.

名前はEPCglobal Inc.規格公表工程で割り当てられます。

   Process of identifier resolution:

識別子解決の過程:

         No resolution mechanism is required or provided.

解決メカニズムを全く必要でない、または提供しません。

Mealling                     Informational                      [Page 6]

RFC 5134                      The EPC URN                   January 2008

EPCつぼの2008年1月に情報[6ページ]のRFC5134を荒びきにします。

   Rules for Lexical Equivalence:

語彙等価性のための規則:

         The entire URN is case-sensitive.

全体のURNは大文字と小文字を区別しています。

   Conformance with URN Syntax:

つぼの構文との順応:

         There are no additional characters reserved except as noted in
         the ABNF above.

ABNFに述べられる以外に、予約された添字が全く上にありません。

   Validation mechanism:

合法化メカニズム:

         In the case of each sub-namespace, there will be namespace-
         specific rules for determining validity.  In each case, the
         reader is referred to the appropriate EPCglobal-maintained
         documentation.

それぞれのサブ名前空間の場合には、正当性を決定するための名前空間の特定の規則があるでしょう。 その都度、読者は適切なEPCglobalによって維持されたドキュメンテーションを参照されます。

   Scope:

範囲:

         Global

グローバル

4.  IANA Considerations

4. IANA問題

   This document includes two URN Namespace registrations that have been
   entered into the IANA registry for URN NIDs.

このドキュメントはURN NIDsのためにIANA登録に入れられた2つのURN Namespace登録証明書を含んでいます。

5.  Namespace Considerations

5. 名前空間問題

   Due to EPCglobal, Inc. being a subsidiary of an internationally
   recognized authority for the identifiers embedded within the 'epc'
   namespace, as well as being the internationally recognized standards
   body for the standards that define identifiers in the 'epcglobal'
   namespace, these namespaces represent the best approach to naming
   products and entities within the world of supply chain management and
   ecommerce in general.  There are no other alternative namespaces that
   have the level of authority and industry acceptance that the EPC
   does.

国際的に認識された標準化団体であることと同様に'epcglobal'名前空間で識別子を定義する規格のために'epc'名前空間の中で埋め込まれた識別子のための国際的に認識された権威の子会社であるEPCglobal Inc.のため、これらの名前空間はサプライ・チェーンの世界の中の製品と実体を管理と一般に、ecommerceと命名することへの最も良いアプローチを表します。 EPCがする権威と産業承認のレベルを持っている他のどんな代替の名前空間もありません。

6.  Community Considerations

6. 共同体問題

   The EPCglobal Architecture Framework is intended to bring the
   Internet to the world of supply chain management and beyond.  It can
   be used to tie physical objects to their virtual descriptions and as
   such has many wide ranging applications for the average Internet use.
   Thus, it is very much the intent that this namespace, and the entire
   EPCglobal Architecture Framework, considers the entire Internet as
   the scope of its community.

EPCglobal Architecture Frameworkがサプライ・チェーン・マネジメントと以遠の世界にインターネットをもたらすことを意図します。 それは、彼らの仮想の記述に対象物を結ぶのに使用できて、平均したインターネットの利用のためにそういうものとして多くの広い及んでいるアプリケーションを持っています。 したがって、それはたいへんこの名前空間、および全体のEPCglobal Architecture Frameworkが共同体の範囲として全体のインターネットであると考える意図です。

Mealling                     Informational                      [Page 7]

RFC 5134                      The EPC URN                   January 2008

EPCつぼの2008年1月に情報[7ページ]のRFC5134を荒びきにします。

7.  Security Considerations

7. セキュリティ問題

   The EPCglobal Architecture Framework is based almost exclusively on
   Internet and Web standards.  Thus, the security impacts of each of
   its underlying technologies should be examined for weaknesses and
   threats.  The primary threats will come from the fact that these
   names will identify physical things that can be of high value, thus
   the temptation to spoof metadata about that identifier (its cost,
   size, etc) will be much greater.  Therefore, the role of digital
   signatures, secure resolution mechanisms, and trust relationships is
   very fundamental to the system.

EPCglobal Architecture Frameworkはインターネットとウェブ規格に専ら基づいています。 したがって、それぞれの基本的な技術のセキュリティ影響は弱点と脅威がないかどうか調べられるべきです。 第一の脅威はこれらの名前が高い価値があることができる物理的なものを特定するという事実から来るでしょう、その結果、その識別子(費用、サイズなど)に関するメタデータをだます誘惑がはるかに大きくなるでしょう。 したがって、デジタル署名、安全な解決メカニズム、および信用関係の役割はシステムに非常に基本的です。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [1]   Moats, R., "URN Syntax", RFC 2141, May 1997.

[1]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。

   [2]   Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 4234, October 2005.

[2] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         One: The Comprehensive DDDS", RFC 3401, October 2002.

[3] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。

   [4]   EPCglobal, Inc., "EPCglobal Network Object Name Service (ONS)
         1.0", August 2003.

「EPCglobalネットワークオブジェクト名サービス(ONS)1インチと、2003年8月」の[4]EPCglobal Inc.。

   [5]   EPCglobal, Inc., "EPC(tm) Tag Data Standards Version 1.3",
         February 2004.

「EPC(tm)タグデータの規格バージョン1.3インチと、2004年2月」の[5]EPCglobal Inc.。

   [6]   Traub, K., Allgair, G., Barthe, H., Burstein, L., Garrett, J.,
         Hogan, B., Rodrigues, B., Sarma, S., Schmidt, J., Schramek, C.,
         Stewart, R., and K. Suen, "The EPCglobal Architecture
         Framework", July 2005.

[6] トラウブ(K.とAllgairとG.とバルテとH.とBursteinとL.とギャレットとJ.とホーガンとB.とロドリーグとB.とSarmaとS.とシュミットとJ.とSchramekとC.とスチュワート、R.とK.Suen、「EPCglobal構造枠組み」2005年7月)。

   [7]   GS1, "GS1 General Specifications v7.1", January 2007.

[7]GS1、「GS1Specifications v7.1"司令官、2007年1月。」

   [8]   EPCglobal, Inc., "The Application Level Events (ALE)
         Specification, Version 1.0", September 2005.

[8] EPCglobal Inc.、「アプリケーションレベルイベント(エール)仕様、バージョン1インチ、2005年9月。」

8.2.  Informative References

8.2. 有益な参照

   [9]   Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn, "XML
         Schema Part 1: Structures Second Edition", World Wide Web
         Consortium Recommendation REC-xmlschema-1-20041028,
         October 2004,
         <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

[9] トンプソン、H.、マローニー、M.、ぶな、D.、およびN.メンデルゾーン、「XML図式第1部:」 「構造第2版」、ワールドワイドウェブコンソーシアム推薦REC-xmlschema-1-20041028、<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028 2004年10月の>。

Mealling                     Informational                      [Page 8]

RFC 5134                      The EPC URN                   January 2008

EPCつぼの2008年1月に情報[8ページ]のRFC5134を荒びきにします。

   [10]  Layman, A., Tobin, R., Bray, T., and D. Hollander, "Namespaces
         in XML 1.1", World Wide Web Consortium FirstEdition REC-xml-
         names11-20040204, February 2004,
         <http://www.w3.org/TR/2004/REC-xml-names11-20040204>.

[10] 俗人、A.、トビン、R.、Bray、T.、そして、D.オランダ人、「XMLの名前空間、1.1インチ、ワールドワイドウェブコンソーシアムFirstEdition REC-xml names11-20040204 2004年2月、<http://www.w3.org/TR/2004/REC-xml-names11-20040204>、」

   [11]  Bray, T., Maler, E., Yergeau, F., Sperberg-McQueen, C., and J.
         Paoli, "Extensible Markup Language (XML) 1.0 (Third Edition)",
         World Wide Web Consortium FirstEdition REC-xml-20040204,
         February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.

[11] T.、Maler、E.、Yergeau、F.、Sperberg-マックィーン、C.、およびJ.パオリ、「拡張マークアップ言語(XML)1.0(第3版)」をいななかせてください、ワールドワイドウェブコンソーシアムFirstEdition REC-xml-20040204、2004年2月、<http://www.w3.org/TR/2004/REC-xml-20040204>。

Author's Address

作者のアドレス

   Michael Mealling
   Refactored Networks, LLC
   1635 Old Hwy 41
   Suite 112, Box 138
   Kennesaw, GA  30152
   US

Refactoredネットワークを荒びきにするマイケル、LLC1635の古いHwy41スイート112、箱138のKennesaw、GA30152米国

   Phone: +1 678 581 9656
   EMail: michael@refactored-networks.com
   URI:   http://www.refactored-networks.com

以下に電話をしてください。 +1 9656年の678 581メール: michael@refactored-networks.com ユリ: http://www.refactored-networks.com

Mealling                     Informational                      [Page 9]

RFC 5134                      The EPC URN                   January 2008

EPCつぼの2008年1月に情報[9ページ]のRFC5134を荒びきにします。

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

Mealling                     Informational                     [Page 10]

食事情報です。[10ページ]

一覧

 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 

スポンサーリンク

[暗号化]ブロック暗号とは(AES/DES/Blowfish PKCS5Padding ECB/CBC IV)

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

上に戻る