idnits 2.17.1
draft-ellison-urn-marlin-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 18.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 262.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 273.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 280.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 288.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation
clause.
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (June 28, 2007) is 6146 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141)
** Obsolete normative reference: RFC 4234 (ref. '3') (Obsoleted by RFC 5234)
Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group Gary Ellison
2 Internet-Draft Intertrust
3 Intended status: Informational June 28, 2007
4 Expires: December 29, 2007
6 A Uniform Resource Name (URN) Namespace for
7 the Marlin Development Community L.L.C.
8 draft-ellison-urn-marlin-02
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79. This
16 document may not be modified, and derivative works of it may not be
17 created, except to publish it as an RFC and to translate it into
18 languages other than English.
20 Internet-Drafts are working documents of the Internet
21 Engineering Task Force (IETF), its areas, and its working
22 groups. Note that other groups may also distribute working
23 documents as Internet-Drafts.
25 Internet-Drafts are draft documents valid for a maximum of
26 six months and may be updated, replaced, or obsoleted by
27 other documents at any time. It is inappropriate to use
28 Internet-Drafts as reference material or to cite them other
29 than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed
35 at http://www.ietf.org/shadow.html.
37 Copyright Notice
39 Copyright (C) The IETF Trust (2007).
41 Abstract
43 This document describes a Uniform Resource Name (URN)
44 namespace that will identify various objects of Marlin system
45 implementations to enable interoperability and content
46 portability.
48 Table of Contents
50 1. Introduction ....................................................2
51 2. URN Specification for the "marlin" NID ..........................2
52 3. IANA Considerations .............................................4
53 4. Community Considerations ........................................4
54 5. Security Considerations .........................................4
55 6. References ......................................................5
57 1. Introduction
59 This document proposes the "marlin" namespace, which consists
60 of the specifications, protocol bindings, XML schema and
61 service definitions developed by the Marlin Development
62 Community L.L.C.
64 One fundamental component of this architecture is its use of
65 XML [5], and specifically, XML Schema [7] and Namespaces [6].
66 These components require identifiers that will live far
67 beyond the lifetime of the organization that produced them.
68 As such, a URN namespace for those components that adheres to
69 the assumptions and policies of the Marlin specifications is
70 required.
72 This namespace specification is for a formal namespace.
74 2. URN Specification for the "marlin" NID
76 Namespace ID:
78 The NID "marlin" is requested.
80 Registration Information:
82 Registration Version Number: 1
83 Registration Date: 2007-6-28
85 Declared registrant of the namespace:
87 Name: Gary Ellison
88 Affiliation: Marlin Development Community L.L.C.
89 Address: 415-112 North Mary Ave., Suite #383
90 Sunnyvale, CA 94085 USA
91 Phone: +1 (408) 616-1600
92 Email: editor@marlin-community.com
94 Declaration of structure:
96 The Namespace Specific Strings (NSS) of all URNs assigned by
97 Marlin [4] will conform to the syntax defined in section 2.2 of
98 RFC 2141 [1]. In addition, all Marlin URN NSSs will consist of a
99 left-to-right series of tokens delimited by colons. The left-to-
100 right sequence of colon-delimited tokens corresponds to descending
101 nodes in a tree. To the right of the lowest naming authority node
102 there may be zero, one or more levels of hierarchical (although
103 not in the RFC 2396 [2] sense of 'hierarchy') naming nodes
104 terminating in a rightmost leaf node. See the section entitled
105 "Identifier assignment" below for more on the semantics of NSSs.
107 This syntax convention is captured in the following normative ABNF
108 [3] rules for Marlin NSSs:
110 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
111 DIGIT = %x30-39 ; 0-9
112 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
114 Marlin-NSS = 1*(subStChar) 0*(":" 1*(subStChar))
115 subStChar = trans / "%" HEXDIG HEXDIG
116 trans = ALPHA / DIGIT / other / reserved
117 other = "(" / ")" / "+" / "," / "-" / "." /
118 "=" / "@" / ";" / "$" /
119 "_" / "!" / "*" / "'"
120 reserved = "%" / "/" / "?" / "#"
122 The exclusion of the colon from the list of "other" characters
123 means that the colon can only occur as a delimiter between string
124 tokens. Note that this ABNF rule set guarantees that any valid
125 Marlin NSS is also a valid RFC 2141 [1] NSS.
127 For example:
129 urn:marlin:core:1-0:schemas
130 urn:marlin:drmservices
132 Relevant ancillary documentation:
134 The structure for URNs in the "urn:marlin" namespace are defined
135 in [4].
137 Identifier uniqueness considerations:
139 Identifiers are assigned by the techical committees within the
140 Marlin Development Community L.L.C. In the process of
141 publishing a specification all newly minted names are checked
142 against the record of previously assigned names.
144 Identifier persistence considerations:
146 The assignment process guarantees that names are not reassigned
147 and that the binding between the name and its resource is
148 permanent, regardless of any standards or organizational changes.
150 Process of identifier assignment:
152 Names are assigned by the Marlin Development Community
153 L.L.C. standards publication process.
155 Process of identifier resolution:
157 At this time no resolution mechanism is specified.
159 Rules for Lexical Equivalence:
161 Lexical equivalence of two Marlin namespace specific strings
162 (NSSs) is defined as an exact, case sensitive string match.
163 The Marlin Development Community L.L.C. will assign names of
164 immediately subordinate naming authorities in a case-insensitive
165 fashion, so that there will not be two Marlin-subordinate naming
166 authorities whose names differ only in case.
168 Conformance with URN Syntax:
170 There are no additional characters reserved.
172 Validation mechanism:
174 None other than verifying with the correct Marlin specifications.
176 Scope:
178 Global
180 3. IANA Considerations
182 This document includes a URN Namespace registration that has been
183 entered into the IANA registry for URN NIDs.
185 4. Community Considerations
187 While there is no resolution mechanism for this namespace, the names
188 themselves are used in public implementations of the Marlin
189 specifications. There are circumstances where objects from the
190 Marlin system will become exposed to the general Internet. In these
191 cases, the use of the Marlin namespace will provide general
192 interoperability benefits to the Internet at large. Additionally,
193 there may be subcomponents of the Marlin specifications that may be
194 adopted by other standards, in which case the URNs used to identify
195 those components and specifications can be easily used to enhance
196 other, non-Marlin based, systems.
198 5. Security Considerations
200 Since there is no defined resolution mechanism for Marlin URNs it is
201 difficult to authenticate the fact that a given namespace actually
202 adheres to the standard, thus applications should be careful to not
203 take some unverified sources assertion that what it is sending
204 adheres to what the actual URN is assigned to.
206 6. References
208 6.1. Normative References
210 [1] Moats, R., "URN Syntax", RFC 2141, May 1997.
212 [2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
213 Identifiers (URI): Generic Syntax", RFC 3986, January 2005.
215 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
216 Specifications: ABNF", RFC 4234, October 2005.
218 [4] Marlin Developer Community L.L.C., "Marlin Core System
219 Specification", Septermber 2006,
220 .
222 6.2. Informative References
224 [5] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
225 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
226 October 2000, .
228 [6] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C
229 REC-xml-names, January 1999, .
232 [7] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
233 Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
234 .
236 Author's Address
238 Gary Ellison
239 Intertrust, Inc.
240 955 Stewart Drive
241 Sunnyvale, CA 94085
242 USA
244 Phone: +1 408 616 1625
245 EMail: gfe@intertrust.com
246 URI: http://www.intertrust.com
248 Full Copyright Notice
250 Copyright (C) The IETF Trust (2007).
252 This document is subject to the rights, licenses and restrictions
253 contained in BCP 78, and except as set forth therein, the authors
254 retain all their rights.
256 This document and the information contained herein are provided on an
257 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
258 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
259 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
260 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
261 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
262 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
264 Intellectual Property
266 The IETF takes no position regarding the validity or scope of any
267 Intellectual Property Rights or other rights that might be claimed to
268 pertain to the implementation or use of the technology described in
269 this document or the extent to which any license under such rights
270 might or might not be available; nor does it represent that it has
271 made any independent effort to identify any such rights. Information
272 on the procedures with respect to rights in RFC documents can be
273 found in BCP 78 and BCP 79.
275 Copies of IPR disclosures made to the IETF Secretariat and any
276 assurances of licenses to be made available, or the result of an
277 attempt made to obtain a general license or permission for the use of
278 such proprietary rights by implementers or users of this
279 specification can be obtained from the IETF on-line IPR repository at
280 http://www.ietf.org/ipr.
282 Expires: December 29, 2007
284 The IETF invites any interested party to bring to its attention any
285 copyrights, patents or patent applications, or other proprietary
286 rights that may cover technology that may be required to implement
287 this standard. Please address the information to the IETF at
288 ietf-ipr@ietf.org.
290 Acknowledgement
292 Funding for the RFC Editor function is currently provided by the
293 Internet Society.