idnits 2.17.1
draft-thomson-geopriv-provided-by-00.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 16.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 343.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 320.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 327.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 333.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 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 (October 11, 2005) is 6772 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV Working Group M. Thomson
3 Internet-Draft Andrew
4 Expires: April 14, 2006 J. Polk
5 Cisco
6 October 11, 2005
8 Using URIs for the PIDF-LO 'provided-by' element
9 draft-thomson-geopriv-provided-by-00.txt
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on April 14, 2006.
36 Copyright Notice
38 Copyright (C) The Internet Society (2005).
40 Abstract
42 The "provided-by" element in PIDF-LO is a container designed to carry
43 information about the source of location information. This document
44 defines an XML structure that can be used within the "provided-by"
45 element to convey basic information about the information provider in
46 the form of a URI.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
52 2. provided-by URI . . . . . . . . . . . . . . . . . . . . . . . 4
53 2.1. URI Usage . . . . . . . . . . . . . . . . . . . . . . . . 4
54 3. provided-by URI Schema . . . . . . . . . . . . . . . . . . . . 5
55 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
58 6.1. URN sub-namespace registration for
59 'urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri' . . . . . . 8
60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
62 7.2. Informative References . . . . . . . . . . . . . . . . . . 9
63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
64 Intellectual Property and Copyright Statements . . . . . . . . . . 11
66 1. Introduction
68 The PIDF-LO document [I-D.ietf-geopriv-pidf-lo] defines the
69 "provided-by" element, which is to be used to identify the
70 organization that provided the location information to the endsystem.
71 The "provided-by" element is designed to either augment provider
72 identity information contained in a digital signature, or provide
73 some information in the absence of a signature. The "provided-by"
74 element can also be used to identify an original provider in the case
75 where information is made available by a third party.
77 The PIDF-LO specification [I-D.ietf-geopriv-pidf-lo] includes a
78 definition for a "provided-by" element, that is, for the National
79 Emergency Number Association (NENA), which is North America specific.
80 This document includes a lightweight definition that is more widely
81 applicable.
83 The URI form specified in this document provides a loose means of
84 identifying the provider of location information to the endsystem.
85 It is characterized as "loose" since it the information can only be
86 used as a hint, see Section 5 for details.
88 1.1. Terminology
90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
92 document are to be interpreted as described in [RFC2119].
94 2. provided-by URI
96 This document defines "provided-by" content, the "uri" element, that
97 can be used to convey URIs.
99 A URI provides a very flexible means of conveying information. To
100 that end, this document does not mandate specific processing for the
101 "provided-by" element. A User Agent MAY interpret the "provided-by"
102 element in any fashion it considers appropriate, which could simply
103 be to ignore the field entirely. Where URIs are made available, a
104 User Agent SHOULD only use any URI on explicit user direction.
106 It is RECOMMENDED that, where applicable, any URI included in the
107 "provided-by" element be accessible from the public internet without
108 requiring authentication.
110 There MAY be more than one "uri" element in a PIDF-LO so that
111 multiple URIs can be present. It MAY also be used in combination
112 with other "provided-by" content.
114 2.1. URI Usage
116 URIs included in the "provided-by" element can be used for many
117 purposes. The "type" attribute MAY be included to provide a hint to
118 a User Agent about how a URI could be used if it isn't evident from
119 the URI scheme. The following values are defined:
121 contact: The URI can be used to contact the providing organization.
122 This is similar to the "contact" element defined in PIDF
123 [RFC3863]. It is RECOMMENDED that this field include a URI in a
124 scheme that can be used for establishing a media session, such as
125 sip, sips or tel.
127 location: The URI references location information pertaining to the
128 organization or the specific campus, which should be in the form
129 of a PIDF-LO document.
131 info: The URI references general information, which might include
132 information on the privacy policy of the organization; an
133 explanation of how location information is determined by the
134 organization; or any other information.
136 No guidance is provided on how URIs are used, however it is expected
137 that a User Agent use default handling behavior for each scheme. For
138 instance, an http URI might be passed to a web browser or a sips URI
139 might be passed to a SIP UA.
141 3. provided-by URI Schema
143 The following schema defines a "uri" element that can be used for
144 "provided-by" URIs.
146
147
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
171 4. Example
173 The following example demonstrates the inclusion of multiple URIs in
174 the "provided-by" element.
176
177
182
183
184
185
186
187 DE
188 BayernOberbayern
189 München
190 Marienplatz8
191 80331
192
193
194
195 no
196
197
198 http://www.example.com/info/pidf-lo/
199 sips:location@example.com
200
201 mailto:location@example.com?subject=PIDF-LO
202
203
204
205
206
207
209 5. Security Considerations
211 The information in the "provided-by" element does not provide any
212 assurance that the entity referred to is actually the provider of the
213 location information. Specifically, the contents of a "provided-by"
214 element do not provide a cryptographic assertion of identity of any
215 nature.
217 Unless location information is digitally signed, it is very easy to
218 provide fraudulent information within this field. For example, a
219 PIDF-LO from "example.cracker.com" might include a URI to the well-
220 known and trusted "example.com" web site. This attack could be used
221 to trick users into thinking that the location information was
222 provided by "example.com".
224 When a PIDF-LO is not digitally signed by an authenticated and
225 sufficiently authorized entity the following restrictions apply:
227 o Users of the information MUST NOT represent any authentication
228 information provided when dereferencing the URI as the provider of
229 location information.
231 o Users of this information MUST NOT use the information for any
232 purpose beyond informational.
234 It is RECOMMENDED that a User Agent observe these restrictions even
235 when a digital signature is present.
237 6. IANA Considerations
239 This document calls for IANA to register a new XML namespace, as per
240 the guidelines in [RFC3688].
242 6.1. URN sub-namespace registration for
243 'urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri'
245 URI
246 urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri
248 Registrant Contact
249 IETF, GEOPRIV working group
250 Martin Thomson
252 XML
253 BEGIN
254
255
257
258
259 GEOPRIV provided-by URI
260
261
262 URI element for the provided-by element in PIDF-LO
263 urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri
264 See RFCXXXX.
265
266
267 END
269 7. References
271 7.1. Normative References
273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
274 Requirement Levels", BCP 14, RFC 2119, March 1997.
276 [I-D.ietf-geopriv-pidf-lo]
277 Peterson, J., "A Presence-based GEOPRIV Location Object
278 Format", draft-ietf-geopriv-pidf-lo-03 (work in progress),
279 September 2004.
281 7.2. Informative References
283 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
284 January 2004.
286 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
287 W., and J. Peterson, "Presence Information Data Format
288 (PIDF)", RFC 3863, August 2004.
290 Authors' Addresses
292 Martin Thomson
293 Andrew
294 PO Box U40
295 Wollongong University Campus, NSW 2500
296 AU
298 Phone: +61 2 4221 2915
299 Email: martin.thomson@andrew.com
300 URI: http://www.andrew.com/
302 James M. Polk
303 Cisco
304 3913 Treemont Circle
305 Colleyville, Texas 76034
306 USA
308 Phone: +1-817-271-3552
309 Email: jmpolk@cisco.com
311 Intellectual Property Statement
313 The IETF takes no position regarding the validity or scope of any
314 Intellectual Property Rights or other rights that might be claimed to
315 pertain to the implementation or use of the technology described in
316 this document or the extent to which any license under such rights
317 might or might not be available; nor does it represent that it has
318 made any independent effort to identify any such rights. Information
319 on the procedures with respect to rights in RFC documents can be
320 found in BCP 78 and BCP 79.
322 Copies of IPR disclosures made to the IETF Secretariat and any
323 assurances of licenses to be made available, or the result of an
324 attempt made to obtain a general license or permission for the use of
325 such proprietary rights by implementers or users of this
326 specification can be obtained from the IETF on-line IPR repository at
327 http://www.ietf.org/ipr.
329 The IETF invites any interested party to bring to its attention any
330 copyrights, patents or patent applications, or other proprietary
331 rights that may cover technology that may be required to implement
332 this standard. Please address the information to the IETF at
333 ietf-ipr@ietf.org.
335 Disclaimer of Validity
337 This document and the information contained herein are provided on an
338 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
339 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
340 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
341 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
342 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
343 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
345 Copyright Statement
347 Copyright (C) The Internet Society (2005). This document is subject
348 to the rights, licenses and restrictions contained in BCP 78, and
349 except as set forth therein, the authors retain all their rights.
351 Acknowledgment
353 Funding for the RFC Editor function is currently provided by the
354 Internet Society.