[CalendarServer-changes] [5464] CalendarServer/trunk
source_changes at macosforge.org
source_changes at macosforge.org
Fri Apr 9 13:52:05 PDT 2010
Revision: 5464
http://trac.macosforge.org/projects/calendarserver/changeset/5464
Author: cdaboo at apple.com
Date: 2010-04-09 13:52:05 -0700 (Fri, 09 Apr 2010)
Log Message:
-----------
.well-known uri support.
Modified Paths:
--------------
CalendarServer/trunk/calendarserver/tap/util.py
CalendarServer/trunk/twistedcaldav/stdconfig.py
Added Paths:
-----------
CalendarServer/trunk/doc/RFC/rfc5785-well-known-uris.txt
CalendarServer/trunk/twistedcaldav/simpleresource.py
Removed Paths:
-------------
CalendarServer/trunk/doc/RFC/draft-nottingham-site-meta.txt
Modified: CalendarServer/trunk/calendarserver/tap/util.py
===================================================================
--- CalendarServer/trunk/calendarserver/tap/util.py 2010-04-09 20:51:07 UTC (rev 5463)
+++ CalendarServer/trunk/calendarserver/tap/util.py 2010-04-09 20:52:05 UTC (rev 5464)
@@ -30,6 +30,7 @@
from twext.web2.http_headers import Headers
from twext.web2.dav import auth
from twext.web2.auth.basic import BasicCredentialFactory
+from twext.web2.resource import RedirectResource
from twext.web2.static import File as FileResource
from twext.python.filepath import CachingFilePath as FilePath
@@ -45,6 +46,7 @@
from twistedcaldav.directory.wiki import WikiDirectoryService
from twistedcaldav.notify import installNotificationClient
from twistedcaldav.resource import CalDAVResource, AuthenticationWrapper
+from twistedcaldav.simpleresource import SimpleResource
from twistedcaldav.static import CalendarHomeProvisioningFile
from twistedcaldav.static import IScheduleInboxFile
from twistedcaldav.static import TimezoneServiceFile
@@ -320,6 +322,23 @@
root.putChild("principals", principalCollection)
root.putChild("calendars", calendarCollection)
+ # /.well-known
+ if config.EnableWellKnown:
+ log.info("Setting up .well-known collection resource")
+
+ wellKnownResource = SimpleResource(
+ principalCollections=(principalCollection,),
+ isdir=True,
+ defaultACL=SimpleResource.allReadACL
+ )
+ root.putChild(".well-known", wellKnownResource)
+ for enabled, wellknown_name in (
+ (config.EnableCalDAV, "caldav",),
+ (config.EnableCardDAV, "carddav"),
+ ):
+ if enabled:
+ wellKnownResource.putChild(wellknown_name, RedirectResource(path="/"))
+
for name, info in config.Aliases.iteritems():
if os.path.sep in name or not info.get("path", None):
log.error("Invalid alias: %s" % (name,))
Deleted: CalendarServer/trunk/doc/RFC/draft-nottingham-site-meta.txt
===================================================================
--- CalendarServer/trunk/doc/RFC/draft-nottingham-site-meta.txt 2010-04-09 20:51:07 UTC (rev 5463)
+++ CalendarServer/trunk/doc/RFC/draft-nottingham-site-meta.txt 2010-04-09 20:52:05 UTC (rev 5464)
@@ -1,448 +0,0 @@
-
-
-
-Network Working Group M. Nottingham
-Internet-Draft E. Hammer-Lahav
-Updates: 2616 2818 November 20, 2009
-(if approved)
-Intended status: Standards Track
-Expires: May 24, 2010
-
-
- Defining Well-Known URIs
- draft-nottingham-site-meta-04
-
-Abstract
-
- This memo defines a path prefix for "well-known locations", "/.well-
- known/" in selected URI schemes.
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on May 24, 2010.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
-
-
-
-Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 1]
-
-Internet-Draft Defining Well-Known URIs November 2009
-
-
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the BSD License.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
- 3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3
- 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
- 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . . 4
- 5.1.1. Registration Template . . . . . . . . . . . . . . . . . 5
- 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
- 6.2. Informative References . . . . . . . . . . . . . . . . . . 6
- Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6
- Appendix B. Frequently Asked Questions . . . . . . . . . . . . . . 6
- B.1. Aren't well-known locations bad for the Web? . . . . . . . 6
- B.2. Why /.well-known? . . . . . . . . . . . . . . . . . . . . . 7
- B.3. What impact does this have on existing mechanisms,
- such as P3P and robots.txt? . . . . . . . . . . . . . . . . 7
- B.4. Why aren't per-directory well-known locations defined? . . 7
- Appendix C. Document History . . . . . . . . . . . . . . . . . . . 7
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 2]
-
-Internet-Draft Defining Well-Known URIs November 2009
-
-
-1. Introduction
-
- It is increasingly common for Web-based protocols to require the
- discovery of policy or metadata before making a request. For
- example, the Robots Exclusion Protocol specifies a way for automated
- processes to obtain permission to access resources; likewise, the
- Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-
- agents how to discover privacy policy beforehand.
-
- While there are several ways to access per-resource metadata (e.g.,
- HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
- associated with them often precludes their use in these scenarios.
-
- When this happens, it is common to designate a "well-known location"
- for such metadata, so that it can be easily located. However, this
- approach has the drawback of risking collisions, both with other such
- designated "well-known locations" and with pre-existing resources.
-
- To address this, this memo defines a path prefix in HTTP(S) URIs for
- these "well-known locations", "/.well-known/". Future specifications
- that need to define a resource for such site-wide metadata can
- register their use to avoid collisions and minimise impingement upon
- sites' URI space.
-
- [[ Please discuss this draft on the apps-discuss at ietf.org [1] mailing
- list. ]]
-
-
-2. Notational Conventions
-
- 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 [RFC2119].
-
-
-3. Well-Known URIs
-
- A well-known URI is a URI [RFC3986] whose path component begins with
- the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS",
- or another scheme which has explicitly been specified to use well-
- known URIs.
-
- Applications that wish to mint new well-known URIs MUST register
- them, following the procedures in Section 5.1.
-
- For example, if an application registers the value 'example', the
- corresponding well-known URI on 'http://www.example.com/' would be
- 'http://www.example.com/.well-known/example'.
-
-
-
-Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 3]
-
-Internet-Draft Defining Well-Known URIs November 2009
-
-
- Note that this specification defines neither how to determine the
- authority to use for a particular context, nor the scope of the
- metadata discovered by dereferencing the well-known URI; both should
- be defined by the application itself.
-
- Typically, a registration will reference a specification that defines
- the format and associated media type to be obtained by dereferencing
- the well-known URI.
-
- It MAY also contain additional information, such as the syntax of
- additional path components, query strings and/or fragment identifiers
- to be appended to the well-known URI, or protocol-specific details
- (e.g., HTTP [RFC2616] method handling).
-
- Note that this specification also does not define a format or media-
- type for the resource at located at "/.well-known/" and clients
- should not expect a resource to exist at that location.
-
-
-4. Security Considerations
-
- This memo does not specify the scope of applicability of metadata or
- policy obtained from a well-known URI, and does not specify how to
- discover a well-known URI for a particular application. Individual
- applications using this mechanism must define both aspects.
-
- An attacker with certain types of limited access to a server may be
- able to affect how well-known URIs are served; for example, they may
- be able to upload a file at that location, or they may be able to
- cause a server to redirect a well-known URI to a URI that they
- control.
-
- Because most URI schemes rely on DNS to resolve names, they are
- vulnerable to "DNS rebinding" attacks, whereby a request can be
- directed to a server under the control of an attacker.
-
-
-5. IANA Considerations
-
-5.1. The Well-Known URI Registry
-
- This document establishes the well-known URI registry.
-
- Well-known URIs are registered on the advice of one or more
- Designated Experts (appointed by the IESG or their delegate), with a
- Specification Required (using terminology from [RFC5226]).
-
- Registration requests consist of the completed registration template
-
-
-
-Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 4]
-
-Internet-Draft Defining Well-Known URIs November 2009
-
-
- (see Section 5.1.1), typically published in an RFC or Open Standard
- (in the sense described by [RFC2026], section 7). However, to allow
- for the allocation of values prior to publication, the Designated
- Expert(s) may approve registration once they are satisfied that an
- RFC (or other Open Standard) will be published.
-
- Registration requests should be sent to the [TBD]@ietf.org mailing
- list for review and comment, with an appropriate subject (e.g.,
- "Request for well-known URI: example").
-
- [[NOTE TO RFC-EDITOR: The name of the mailing list should be
- determined in consultation with the IESG and IANA. Suggested name:
- wellknown-uri-review. ]]
-
- Before a period of 14 days has passed, the Designated Expert(s) will
- either approve or deny the registration request, communicating this
- decision both to the review list and to IANA. Denials should include
- an explanation and, if applicable, suggestions as to how to make the
- request successful.
-
-5.1.1. Registration Template
-
- URI suffix: The name requested for the well-known URI, relative to
- "/.well-known/"; e.g., "example". MUST conform to the segment-nz
- production in [RFC3986].
- Change controller: For standards-track RFCs, state "IETF". For
- other open standards, give the name of the publishing body (e.g.,
- ANSI, ISO, ITU, W3C, etc.). A postal address, home page URI,
- telephone and fax numbers may also be included.
- Specification document(s): Reference to document that specifies the
- field, preferably including a URI that can be used to retrieve a
- copy of the document. An indication of the relevant sections may
- also be included, but is not required.
- Related information: Optionally, citations to additional documents
- containing further relevant information.
-
-
-6. References
-
-6.1. Normative References
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9, RFC 2026, October 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-
-
-
-Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 5]
-
-Internet-Draft Defining Well-Known URIs November 2009
-
-
- Resource Identifier (URI): Generic Syntax", STD 66,
- RFC 3986, January 2005.
-
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 5226,
- May 2008.
-
-6.2. Informative References
-
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
- Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
- [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
- Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
-
- [W3C.REC-P3P-20020416]
- Marchiori, M., "The Platform for Privacy Preferences 1.0
- (P3P1.0) Specification", W3C REC REC-P3P-20020416,
- April 2002.
-
-URIs
-
- [1] <https://www.ietf.org/mailman/listinfo/apps-discuss>
-
-
-Appendix A. Acknowledgements
-
- We would like to acknowledge the contributions of everyone who
- provided feedback and use cases for this draft; in particular, Phil
- Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad
- Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra,
- Breno de Medeiros, John Panzer, and Drummond Reed. However, they are
- not responsible for errors and omissions.
-
-
-Appendix B. Frequently Asked Questions
-
-B.1. Aren't well-known locations bad for the Web?
-
- They are, but for various reasons -- both technical and social --
- they are commonly used, and their use is increasing. This memo
- defines a "sandbox" for them, to reduce the risks of collision and to
- minimise the impact upon pre-existing URIs on sites.
-
-
-
-
-
-
-
-Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 6]
-
-Internet-Draft Defining Well-Known URIs November 2009
-
-
-B.2. Why /.well-known?
-
- It's short, descriptive and according to search indices, not widely
- used.
-
-B.3. What impact does this have on existing mechanisms, such as P3P and
- robots.txt?
-
- None, until they choose to use this mechanism.
-
-B.4. Why aren't per-directory well-known locations defined?
-
- Allowing every URI path segment to have a well-known location (e.g.,
- "/images/.well-known/") would increase the risks of colliding with a
- pre-existing URI on a site, and generally these solutions are found
- not to scale well, because they're too "chatty".
-
-
-Appendix C. Document History
-
- [[RFC Editor: please remove this section before publication.]]
-
- o -04
- * Restrict to HTTP(S) by default.
- * Shorten review SLA to 14 days.
- * Allow for multiple designated experts.
- * Identify mailing list for request submission and discussion.
- o -03
- * Add fragment identifiers to list of things an application might
- define.
- * Note that the /.well-known/ URI doesn't have anything there.
- o -02
- * Rewrote to just define a namespace for well-known URIs.
- * Changed discussion forum to apps-discuss.
- o -01
- * Changed "site-meta" to "host-meta" after feedback.
- * Changed from XML to text-based header-like format.
- * Remove capability for generic inline content.
- * Added registry for host-meta fields.
- * Clarified scope of metadata application.
- * Added security consideration about HTTP vs. HTTPS, expanding
- scope.
-
-
-
-
-
-
-
-
-
-Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 7]
-
-Internet-Draft Defining Well-Known URIs November 2009
-
-
-Authors' Addresses
-
- Mark Nottingham
-
- Email: mnot at mnot.net
- URI: http://www.mnot.net/
-
-
- Eran Hammer-Lahav
-
- Email: eran at hueniverse.com
- URI: http://hueniverse.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 8]
-
\ No newline at end of file
Added: CalendarServer/trunk/doc/RFC/rfc5785-well-known-uris.txt
===================================================================
--- CalendarServer/trunk/doc/RFC/rfc5785-well-known-uris.txt (rev 0)
+++ CalendarServer/trunk/doc/RFC/rfc5785-well-known-uris.txt 2010-04-09 20:52:05 UTC (rev 5464)
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Nottingham
+Request for Comments: 5785 E. Hammer-Lahav
+Updates: 2616, 2818 April 2010
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ Defining Well-Known Uniform Resource Identifiers (URIs)
+
+Abstract
+
+ This memo defines a path prefix for "well-known locations",
+ "/.well-known/", in selected Uniform Resource Identifier (URI)
+ schemes.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5785.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav Standards Track [Page 1]
+
+RFC 5785 Defining Well-Known URIs April 2010
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Appropriate Use of Well-Known URIs . . . . . . . . . . . . 3
+ 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
+ 3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+ 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . . 4
+ 5.1.1. Registration Template . . . . . . . . . . . . . . . . . 5
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
+ 6.2. Informative References . . . . . . . . . . . . . . . . . . 5
+ Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
+ Appendix B. Frequently Asked Questions . . . . . . . . . . . . . . 7
+
+1. Introduction
+
+ It is increasingly common for Web-based protocols to require the
+ discovery of policy or other information about a host ("site-wide
+ metadata") before making a request. For example, the Robots
+ Exclusion Protocol <http://www.robotstxt.org/> specifies a way for
+ automated processes to obtain permission to access resources;
+ likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416]
+ tells user-agents how to discover privacy policy beforehand.
+
+ While there are several ways to access per-resource metadata (e.g.,
+ HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
+ (either in terms of client-perceived latency and/or deployment
+ difficulties) associated with them often precludes their use in these
+ scenarios.
+
+ When this happens, it is common to designate a "well-known location"
+ for such data, so that it can be easily located. However, this
+ approach has the drawback of risking collisions, both with other such
+ designated "well-known locations" and with pre-existing resources.
+
+ To address this, this memo defines a path prefix in HTTP(S) URIs for
+ these "well-known locations", "/.well-known/". Future specifications
+ that need to define a resource for such site-wide metadata can
+ register their use to avoid collisions and minimise impingement upon
+ sites' URI space.
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav Standards Track [Page 2]
+
+RFC 5785 Defining Well-Known URIs April 2010
+
+
+1.1. Appropriate Use of Well-Known URIs
+
+ There are a number of possible ways that applications could use Well-
+ known URIs. However, in keeping with the Architecture of the World-
+ Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
+ for general information retrieval or establishment of large URI
+ namespaces on the Web. Rather, they are designed to facilitate
+ discovery of information on a site when it isn't practical to use
+ other mechanisms; for example, when discovering policy that needs to
+ be evaluated before a resource is accessed, or when using multiple
+ round-trips is judged detrimental to performance.
+
+ As such, the well-known URI space was created with the expectation
+ that it will be used to make site-wide policy information and other
+ metadata available directly (if sufficiently concise), or provide
+ references to other URIs that provide such metadata.
+
+2. Notational Conventions
+
+ 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 [RFC2119].
+
+3. Well-Known URIs
+
+ A well-known URI is a URI [RFC3986] whose path component begins with
+ the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS",
+ or another scheme that has explicitly been specified to use well-
+ known URIs.
+
+ Applications that wish to mint new well-known URIs MUST register
+ them, following the procedures in Section 5.1.
+
+ For example, if an application registers the name 'example', the
+ corresponding well-known URI on 'http://www.example.com/' would be
+ 'http://www.example.com/.well-known/example'.
+
+ Registered names MUST conform to the segment-nz production in
+ [RFC3986].
+
+ Note that this specification defines neither how to determine the
+ authority to use for a particular context, nor the scope of the
+ metadata discovered by dereferencing the well-known URI; both should
+ be defined by the application itself.
+
+ Typically, a registration will reference a specification that defines
+ the format and associated media type to be obtained by dereferencing
+ the well-known URI.
+
+
+
+Nottingham & Hammer-Lahav Standards Track [Page 3]
+
+RFC 5785 Defining Well-Known URIs April 2010
+
+
+ It MAY also contain additional information, such as the syntax of
+ additional path components, query strings and/or fragment identifiers
+ to be appended to the well-known URI, or protocol-specific details
+ (e.g., HTTP [RFC2616] method handling).
+
+ Note that this specification does not define a format or media-type
+ for the resource located at "/.well-known/" and clients should not
+ expect a resource to exist at that location.
+
+4. Security Considerations
+
+ This memo does not specify the scope of applicability of metadata or
+ policy obtained from a well-known URI, and does not specify how to
+ discover a well-known URI for a particular application. Individual
+ applications using this mechanism must define both aspects.
+
+ Applications minting new well-known URIs, as well as administrators
+ deploying them, will need to consider several security-related
+ issues, including (but not limited to) exposure of sensitive data,
+ denial-of-service attacks (in addition to normal load issues), server
+ and client authentication, vulnerability to DNS rebinding attacks,
+ and attacks where limited access to a server grants the ability to
+ affect how well-known URIs are served.
+
+5. IANA Considerations
+
+5.1. The Well-Known URI Registry
+
+ This document establishes the well-known URI registry.
+
+ Well-known URIs are registered on the advice of one or more
+ Designated Experts (appointed by the IESG or their delegate), with a
+ Specification Required (using terminology from [RFC5226]). However,
+ to allow for the allocation of values prior to publication, the
+ Designated Expert(s) may approve registration once they are satisfied
+ that such a specification will be published.
+
+ Registration requests should be sent to the
+ wellknown-uri-review at ietf.org mailing list for review and comment,
+ with an appropriate subject (e.g., "Request for well-known URI:
+ example").
+
+ Before a period of 14 days has passed, the Designated Expert(s) will
+ either approve or deny the registration request, communicating this
+ decision both to the review list and to IANA. Denials should include
+ an explanation and, if applicable, suggestions as to how to make the
+
+
+
+
+
+Nottingham & Hammer-Lahav Standards Track [Page 4]
+
+RFC 5785 Defining Well-Known URIs April 2010
+
+
+ request successful. Registration requests that are undetermined for
+ a period longer than 21 days can be brought to the IESG's attention
+ (using the iesg at iesg.org mailing list) for resolution.
+
+5.1.1. Registration Template
+
+ URI suffix: The name requested for the well-known URI, relative to
+ "/.well-known/"; e.g., "example".
+
+ Change controller: For Standards-Track RFCs, state "IETF". For
+ others, give the name of the responsible party. Other details
+ (e.g., postal address, e-mail address, home page URI) may also be
+ included.
+
+ Specification document(s): Reference to the document that specifies
+ the field, preferably including a URI that can be used to retrieve
+ a copy of the document. An indication of the relevant sections
+ may also be included, but is not required.
+
+ Related information: Optionally, citations to additional documents
+ containing further relevant information.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, January 2005.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+6.2. Informative References
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
+ L., Leach, P., and T. Berners-Lee, "Hypertext Transfer
+ Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
+ Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+
+
+
+
+
+Nottingham & Hammer-Lahav Standards Track [Page 5]
+
+RFC 5785 Defining Well-Known URIs April 2010
+
+
+ [W3C.REC-P3P-20020416]
+ Marchiori, M., "The Platform for Privacy Preferences 1.0
+ (P3P1.0) Specification", World Wide Web Consortium
+ Recommendation REC-P3P-20020416, April 2002,
+ <http://www.w3.org/TR/2002/ REC-P3P-20020416>.
+
+ [W3C.REC-webarch-20041215]
+ Jacobs, I. and N. Walsh, "Architecture of the World Wide
+ Web, Volume One", World Wide Web Consortium
+ Recommendation REC- webarch-20041215, December 2004,
+ <http:// www.w3.org/TR/2004/REC-webarch-20041215>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav Standards Track [Page 6]
+
+RFC 5785 Defining Well-Known URIs April 2010
+
+
+Appendix A. Acknowledgements
+
+ We would like to acknowledge the contributions of everyone who
+ provided feedback and use cases for this document; in particular,
+ Phil Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad
+ Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra,
+ Breno de Medeiros, John Panzer, and Drummond Reed. However, they are
+ not responsible for errors and omissions.
+
+Appendix B. Frequently Asked Questions
+
+ 1. Aren't well-known locations bad for the Web?
+
+ They are, but for various reasons -- both technical and social --
+ they are commonly used and their use is increasing. This memo
+ defines a "sandbox" for them, to reduce the risks of collision and
+ to minimise the impact upon pre-existing URIs on sites.
+
+ 2. Why /.well-known?
+
+ It's short, descriptive, and according to search indices, not
+ widely used.
+
+ 3. What impact does this have on existing mechanisms, such as P3P and
+ robots.txt?
+
+ None, until they choose to use this mechanism.
+
+ 4. Why aren't per-directory well-known locations defined?
+
+ Allowing every URI path segment to have a well-known location
+ (e.g., "/images/.well-known/") would increase the risks of
+ colliding with a pre-existing URI on a site, and generally these
+ solutions are found not to scale well, because they're too
+ "chatty".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav Standards Track [Page 7]
+
+RFC 5785 Defining Well-Known URIs April 2010
+
+
+Authors' Addresses
+
+ Mark Nottingham
+
+ EMail: mnot at mnot.net
+ URI: http://www.mnot.net/
+
+
+ Eran Hammer-Lahav
+
+ EMail: eran at hueniverse.com
+ URI: http://hueniverse.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav Standards Track [Page 8]
+
Added: CalendarServer/trunk/twistedcaldav/simpleresource.py
===================================================================
--- CalendarServer/trunk/twistedcaldav/simpleresource.py (rev 0)
+++ CalendarServer/trunk/twistedcaldav/simpleresource.py 2010-04-09 20:52:05 UTC (rev 5464)
@@ -0,0 +1,83 @@
+##
+# Copyright (c) 2009-2010 Apple Inc. All rights reserved.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+##
+
+from twext.web2.dav import davxml
+from twext.web2.dav.noneprops import NonePropertyStore
+from twisted.internet.defer import succeed
+from twistedcaldav.directory.util import NotFilePath
+from twistedcaldav.extensions import DAVFile
+from twistedcaldav.resource import CalDAVResource
+
+"""
+Implements a simple non-file resource.
+"""
+
+__all__ = [
+ "SimpleResource",
+]
+
+class SimpleResource (
+ CalDAVResource,
+ DAVFile,
+):
+
+ allReadACL = davxml.ACL(
+ # Read access for all users.
+ davxml.ACE(
+ davxml.Principal(davxml.All()),
+ davxml.Grant(davxml.Privilege(davxml.Read())),
+ davxml.Protected(),
+ ),
+ )
+ authReadACL = davxml.ACL(
+ # Read access for authenticated users.
+ davxml.ACE(
+ davxml.Principal(davxml.Authenticated()),
+ davxml.Grant(davxml.Privilege(davxml.Read())),
+ davxml.Protected(),
+ ),
+ )
+
+ def __init__(self, principalCollections, isdir=False, defaultACL=authReadACL):
+ """
+ Make sure it is a collection.
+ """
+ CalDAVResource.__init__(self, principalCollections=principalCollections)
+ DAVFile.__init__(self, NotFilePath(isdir=isdir), principalCollections=principalCollections)
+ self.defaultACL = defaultACL
+
+ def locateChild(self, req, segments):
+ child = self.getChild(segments[0])
+ if child is not None:
+ return (child, segments[1:])
+ return (None, ())
+
+ def getChild(self, name):
+ if name == "":
+ return self
+ else:
+ return self.putChildren.get(name, None)
+
+ def deadProperties(self):
+ if not hasattr(self, "_dead_properties"):
+ self._dead_properties = NonePropertyStore(self)
+ return self._dead_properties
+
+ def etag(self):
+ return None
+
+ def accessControlList(self, request, inheritance=True, expanding=False, inherited_aces=None):
+ return succeed(self.defaultACL)
Modified: CalendarServer/trunk/twistedcaldav/stdconfig.py
===================================================================
--- CalendarServer/trunk/twistedcaldav/stdconfig.py 2010-04-09 20:51:07 UTC (rev 5463)
+++ CalendarServer/trunk/twistedcaldav/stdconfig.py 2010-04-09 20:52:05 UTC (rev 5464)
@@ -332,6 +332,7 @@
# Standard (or draft) WebDAV extensions
#
"EnableSyncReport" : True, # REPORT collection-sync
+ "EnableWellKnown" : True, # /.well-known resource
#
# Non-standard CalDAV extensions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20100409/e435256a/attachment-0001.html>
More information about the calendarserver-changes
mailing list