text:
Request for Comments: 8244
Category: Informational
Nominum, Inc.
R. Droms
W. Kumari
October 2017
Special-Use Domain Names Problem Statement
The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.
This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8244.
Copyright Notice
Copyright © 2017 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 (https://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problems Associated with Special-Use Domain Names . . . . . . 4 4. Existing Practice regarding Special-Use Domain Names . . . . 10 4.1. Primary Special-Use Domain Name Documents . . . . . . . . 10 4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 10 4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 12 4.1.3. MoU Concerning the Technical Work of IANA . . . . . . 13 4.1.4. Liaison Statement on Technical Use of Domain Names . 14 4.1.5. IAB Statement on the Registration of Special Use Names in the ARPA Domain . . . . . . . . . . . . . . 15 4.2. Secondary Documents Relating to the Special-Use Domain Name Question . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 15 4.2.2. The '.onion' Special-Use Top-Level Domain Name . . . 16 4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 16 4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 17 4.2.5. SSAC Advisory on the Stability of the Domain Namespace . . . . . . . . . . . . . . . . . . . . . . 17 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis . . . . . . . . . . . . . . . . . . . . . . 17 4.2.7. Additional Reserved Top-Level Domains . . . . . . . . 18 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Informative References . . . . . . . . . . . . . . . . . . . 20 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
One of the key services required to use the Internet is name resolution. Name resolution is the process of translating a symbolic name into some object or set of objects to which the name refers, most typically one or more IP addresses. These names are often referred to as "domain names". When reading this document, care must be taken not to assume that the term domain name implies the use of the Domain Name System [RFC1034] for resolving these names. An excellent presentation on this topic can be found in Domain Names [DOMAIN-NAMES].
"Special-Use Domain Names" [RFC6761] created the "Special-Use Domain Names" IANA registry [SDO-IANA-SUDR], defined policies for adding to the registry, and made some suggestions about how those policies might be implemented. Since the publication of RFC 6761, the IETF has been asked to designate several new Special-Use Domain Names in this registry. During the evaluation process for these Special-Use Domain Names, the IETF encountered several different sorts of issues. Because of this, the IETF has decided to investigate the problem and decide if and how the process defined in RFC 6761 can be improved, or whether it should be deprecated. The IETF DNSOP Working Group charter was extended to include conducting a review of the process for adding names to the registry that is defined in RFC 6761. This document is a product of that review.
Based on current ICANN and IETF practice, including RFC 6761, there are several different types of names in the root of the Domain Namespace:
- Names reserved by the IETF for technical purposes
- Names assigned by ICANN to the public DNS root; some names reserved by the IETF for technical purposes may appear in the global DNS root for reasons pertaining to the operation of the DNS
- ICANN Reserved Names; names that may not be applied for as TLDs (see "Reserved Names" and "Treatment of Country or Territory Names" (Sections 188.8.131.52.1 and 184.108.40.206.1, respectively) of [SDO-ICANN-DAG]).
- Names used by other organizations without following established processes
- Names that are unused and are available for assignment to one of the previous categories
This document presents a list, derived from a variety of sources, including discussion in the IETF DNSOP Working Group, of the problems associated with the assignment of Special-Use Domain Names. The list is intended to be an unfiltered compilation of issues. In support of its analysis of the particular set of issues described here, the document also includes descriptions of existing practice as it relates to the use of domain names, a brief history of domain names, and some observations by various IETF participants who have experience with various aspects of the current situation.
2. Terminology
This document uses the terminology from RFC 7719 [RFC7719]. Other terms used in this document are defined here:
Domain Name: This document uses the term "domain name" as defined in Section 2 of RFC 7719 [RFC7719]. Domain Namespace: The set of all possible domain names. Special-Use Domain Name: A domain name listed in the "Special-Use Domain Names" registry [SDO-IANA-SUDR].
For the sake of brevity, this document uses some abbreviations, which are expanded here:
IANA: Internet Assigned Numbers Authority ICANN: Internet Corporation for Assigned Names and Numbers TLD: Top-Level Domain, as defined in Section 2 of RFC 7719 [RFC7719] gTLD: Generic Top-Level Domain (see Section 2 of RFC 2352 [RFC2352])
3. Problems Associated with Special-Use Domain Names
This section presents a list of problems that have been identified with respect to the assignment of Special-Use Domain Names. Solutions to these problems, including their costs or trade-offs, are out of scope for this document and will be covered in a separate document. New problems that might be created in the process of solving problems described in this document are also out of scope: these problems are expected to be addressed in the process of evaluating potential solutions.
Special-Use Domain Names exist to solve a variety of problems. This document has two goals: enumerate all of the problems that have been identified to which Special-Use Domain Names are a solution and enumerate all of the problems that have been raised in the process of trying to use RFC 6761 as it was intended. As some of those problems may fall into both categories, this document makes no attempt to categorize the problems.
There is a broad diversity of opinion about this set of problems. Not every participant agrees that each of the problems enumerated in this document is actually a problem. This document takes no position on the relative validity of the various problems that have been enumerated, nor on the organization responsible for addressing each individual problem, if it is to be addressed. This document only enumerates the problems, provides the reader with context for thinking about them, and provides a context for future discussion of solutions, regardless of whether such solutions may work for IETF, ICANN, IANA, or some other group.
The list of problems is not presented in order of importance; numbers are assigned so that each problem can easily be referenced by number, not to indicate priority. The list of problems is as follows:
1. Although the IETF and ICANN have a liaison relationship through which special-use allocations can be discussed, there exists no formal process for coordinating these allocations (see Section 4.1.3). The lack of coordination complicates the management of the root of the Domain Namespace and could lead to conflicts in name assignments [SDO-ICANN-SAC090]. 2. There is no explicit scoping as to what can constitute a "technical use" [RFC2860] and what cannot; there is also no consensus within the IETF as to what this term means. 3. Not all developers of protocols on the Internet agree that authority over the entire Domain Namespace should reside solely with the IETF and ICANN. 4. Although the IETF and ICANN nominally have authority over this namespace, neither organization can enforce that authority over any third party who wants to just start using a subset of the namespace. Such parties may observe that the IETF has never asserted control or authority over what protocols are "allowed" on the Internet, and that the principle of "permissionless innovation" suggests there should be a way for people to include new uses of domain names in new protocols and applications. 5. Organizations do in fact sometimes use subsets of the Domain Namespace without following established processes. Reasons a third party might do this include:
- Lack of knowledge that a process exists for assigning such names.
- Intended use is covered by the gTLD process [SDO-ICANN-DAG], but no gTLD process is ongoing.
- Intended use is covered by the gTLD process, but the third party doesn't want to pay a fee.
- Intended use is covered by some IETF process, but the third party doesn't want to follow the process.
- Intended use is covered by an ICANN or IETF process, but the third party expects that the outcome will be refusal or non- action.
- Lack of knowledge that a name intended to be used only locally may nevertheless leak.
- Lack of knowledge that a name used locally with informal allocation may subsequently be allocated formally, creating operational problems.
6. There is demand for more than one name resolution protocol for domain names. Domain names contain no metadata to indicate which protocol to use to resolve them. Domain name resolution APIs do not provide a way to specify which protocol to use. 7. When a Special-Use Domain Name is added to the "Special-Use Domain Names" registry, not all software that processes such names will understand the special use of that name. In many cases, name resolution software will use the Domain Name System for resolution of names not known to have a special use. Consequently, any such use will result in queries for Special- Use Domain Names being sent to Domain Name System authoritative servers. These queries may constitute an operational problem for operators of root zone authoritative name servers. These queries may also inadvertently reveal private information through the contents of the query, which is a privacy consideration. 8. Some protocol developers have assumed that they could not succeed in getting a name assigned through the IETF using the process defined in RFC 6761. This is because when the IETF has attempted to follow the process defined in RFC 6761, it has been slow and uncertain. For example, the process of assigning the first new name ('.local') using the process defined in RFC 6761 took more than ten years from beginning to end: longer by a factor of ten than any other part of the protocol development process (largely because this ten years included time to develop the process as well as use it). Other uses of the process have proceeded more smoothly, but there is a reasonably justified perception that using this process is likely to be slow and difficult, with an uncertain outcome. 9. There is strong resistance within the IETF to assigning domain names to resolution systems outside of the DNS, for a variety of reasons:
- It requires a mechanism for identifying which set of resolution processes is required in order to resolve a particular name.
- Assertion of authority: there is a sense that the Domain Namespace is "owned" by the IETF or by ICANN, so, if a name is claimed without following their processes, the person or entity that claimed that name should suffer some consequence that would, presumably, deter future circumvention of the official processes.
- More than one name resolution protocol is bad, in the sense that a single protocol is less complicated to implement and deploy.
- The semantics of alternative resolution protocols may differ from the DNS protocol; DNS has the concept of RRtypes, whereas other protocols may not support RRtypes or may support some entirely different data structuring mechanism.
- If there is an IETF process through which a TLD can be assigned at zero cost other than time, this process will be used as an alternative to the more costly process of getting the name registered through ICANN.
- A name might be assigned for a particular purpose when a more general use of the name would be more beneficial.
- If the IETF assigns a name that some third party or parties believe belongs to them in some way, the IETF could become embroiled in an expensive dispute with those parties.
- If there were no process for assigning names for technical use through the IETF, there is a concern that protocols that require such names would not be able to get them.
- In some cases where the IETF has made assignments through the process defined in RFC 6761, technical mistakes have been made due to misunderstandings as to the actual process that RFC 6761 specifies (e.g., treating the list of suggested considerations for assigning a name as a set of requirements, all of which must be met). In other cases, the IETF has made de facto assignments of Special-Use Domain Names without following the process in RFC 6761 (see [RFC7050] and [RFC7788]).
- There are several Top-Level Domain Names that are in use without due process for a variety of purposes. The status of these names need to be clarified and recorded to avoid future disputes about their use [SDO-ICANN-COLL].
- In principle, the process defined in RFC 6761 could be used to document the existence of domain names that are not safe to assign and provide information on how those names are used in practice. However, attempts to use RFC 6761 to accomplish this documentation have not been successful (for example, see "Additional Reserved Top Level Domains" [RESERVED-TLDS] and Section 4.2.7 of this document). One side effect of the lack of documentation is that any mitigation effect on the root name servers or on privacy considerations has been missed.
- A domain name can be identified as either a DNS name by placing it in the DNS zone(s) or a Special-Use Domain Name by adding it to the IANA registry. Some names are in both places; for example, some locally served zone names are in DNS zones and documented in the "Special-Use Domain Names" registry. At present, the only way a domain name can be added to the "Special-Use Domain Name" registry is for the IETF to take responsibility for the name and designate it for "technical use". There are other potential uses for domain names that should be recorded in the registry, but for which the IETF should not take responsibility.
- In some cases, the IETF may see the need to document that a name is in use without claiming that the use of the name is the IETF's particular use of the name. No mechanism exists in the current registry to mark names in this way.
- During any of the review stages of a document, there is no formal process in which a check is made to ensure that the document does not unintentionally violate the IETF process for adding Special-Use Domain Names to the registry, as was the case, for example, in RFC 7788 [RFC7788].
- Use of the registry is inconsistent -- some Special-Use Domain Name RFCs specifically add registry entries, some don't; some specify how and whether special-use name delegations should be done, some don't.
- There exists no safe, non-process-violating mechanism for ad hoc assignment of Special-Use Domain Names.
- It is generally assumed that protocols that need a Special-Use Domain Name need a mnemonic, single-label, human-readable Special-Use Domain Name for use in user interfaces such as command lines or URL entry fields. While this assumption is correct in some cases, it is likely not correct in all cases, for example, in applications where the domain name is never visible to a user.
- RFC 6761 uses the term "domain name" to describe the thing for which special uses are registered. This creates a great deal of confusion because some readers take "domain name" to imply the use of the DNS protocol.
- The use of DNSSEC with Special-Use Domain Names is an open issue. There is no consensus or guidance about how to use DNSSEC with various classes of Special-Use Domain Names. Considerations in the use of DNSSEC with Special-Use Domain Names include:
- What class of Special-Use Domain Name is under consideration: non-DNS, locally served zone, or other?
- Does the Special-Use Domain Name require a delegation in the root zone; if so, should that delegation be signed or not? If there is no delegation, then this will be treated by validating resolvers as a secure denial of existence for that zone. This would not be appropriate for a name being resolved using the DNS protocol.
- A process would be required through which the IETF can cause a delegation in the root zone to be instantiated.
- What are the recommended practices for using DNS with the specific Special-Use Domain Name?
The above list represents the current understanding of the authors as to the complete set of problems that have been identified during discussion by the working group on this topic. The remainder of this document provides additional context that will be needed for reasoning related to these problems.
4. Existing Practice regarding Special-Use Domain Names
There are three primary (see Section 4.1) and numerous secondary (Section 4.2) documents to consider when thinking about the Special- Use Domain Names process.
How names are resolved is ambiguous, in the sense that some names are Special-Use Domain Names that require special handling and some names can be resolved using the DNS protocol with no special handling.
The assignment of Internet Names is not under the sole control of any one organization. The IETF has authority in some cases, but only with respect to "technical uses". At present, ICANN is the designated administrator of the root zone; but generally not of zones other than the root zone. Neither of these authorities can, in any practical sense, exclude the practice of ad hoc use of names. Unauthorized use of domain names can be accomplished by any entity that has control over one or more name servers or resolvers, in the context of any hosts and services that entity operates. It can also be accomplished by authors of software who decide that a Special-Use Domain Name is the right way to indicate the use of an alternate resolution mechanism.
4.1. Primary Special-Use Domain Name Documents
The primary documents are considered primary because they directly address the IETF's past thoughts on this topic in a general way, and also because they describe what the IETF does in practice.
4.1.1. IAB Technical Comment on the Unique DNS Root
[RFC2826] is not an IETF consensus document, and it appears to have been written to address a different problem than the Special-Use Domain Name problem. However, it speaks directly to several of the key issues that must be considered, and, coming as it does from the IAB, it is rightly treated as having significant authority despite not being an IETF consensus document.
This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names. The main points that appear relevant to the Special-Use Domain Names problem are:
- The Internet requires a globally unique namespace: a namespace in which any given name refers to the same information (has the same meaning) no matter who requests that information and no matter from which specific name server they request it.
- Private networks may operate private namespaces, with names that have meanings only locally (within the private network), but they still require that names in the public namespace be globally unique.
- The Domain Name System [RFC1035] is not the only protocol that may be used for resolving domain names.
- Users cannot be assumed to know how to distinguish between symbolic references that have local meaning and references that have global meaning. Therefore, users may share references that incorporate domain names with no global meaning (for example, a URL of 'http://mysite.example.corp', where 'example.corp' is a domain used privately and informally as described in [SDO-ICANN-COLL]).
- While such a reference in the user's context refers to the object the user wishes to share, when the reference is used in a different context, it could refer either to some different object in the recipient's context or to no object at all. The effect of this reference escaping the context in which it is valid is that the user's intended communication will not be able to be understood by the recipients of the communication.
This same problem can also occur when a single user copies a name from one context in which it has one meaning into a different context in which it has a different meaning -- for example, copying a '.onion' domain name out of a Tor Browser [TOR], where it has meaning, and pasting this name into an SSH client that doesn't support connecting over the Tor network.
We can summarize the advice in this document as follows:
- Domain names with unambiguous global meaning are preferable to domain names with local meaning that will be ambiguous. Nevertheless, both globally meaningful and locally special names are in use and must be supported.
- At the time of the writing of this document, the IAB was of the opinion that there might well be more than one name resolution protocol used to resolve domain names.
4.1.2. Special-Use Domain Names
The second important document is "Special-Use Domain Names" [RFC6761]. RFC 6761 represents the current IETF consensus on designating and recording Special-Use Domain Names. The IETF has experienced problems with the designation process described in RFC 6761; these concerns motivate this document. Familiarity with RFC 6761 is a prerequisite for having an informed opinion on the topic of Special-Use Domain Names.
RFC 6761 defines two aspects of Special-Use Domain Names: designating a domain name to have a special purpose and registering that special use in the "Special-Use Domain Names" registry. The designation process is defined in a single sentence (RFC 6761, Section 4):
If it is determined that special handling of a name is required in order to implement some desired new functionality, then an IETF "Standards Action" or "IESG Approval" specification [RFC5226] MUST be published describing the new functionality.
This sentence requires that any designation of a Special-Use Domain Name is subject to the same open review and consensus process as used to produce and publish all other IETF specifications.
The registration process is a purely mechanical process, in which the existence of the newly designated Special-Use Domain Name is recorded, with a pointer to a section in the relevant specification document that defines the ways in which special handling is to be applied to the name.
RFC 6761 provides the process whereby "Multicast DNS" [RFC6762] designated '.local' as a Special-Use Domain Name and included it in the "Special-Use Domain Names" registry. RFC 6761 also enumerates a set of names that were previously used or defined to have special uses prior to its publication. Since there had been no registry for these names prior to the publication of RFC 6761, the documents defining these names could not have added them to the registry.
Several important points to think about with respect to RFC 6761 are:
- A Special-Use Domain Name may be a name that should be resolved using the DNS protocol with no special handling. An example of this is 'in-addr.arpa' (which is an example of a Special-Use Domain Name that is not a TLD).
- A Special-Use Domain Name may be a name that is resolved using the DNS protocol and that requires no special handling in the stub resolver but that requires special handling in the recursive resolver. An example of this would be '10.in-addr.arpa.'.
- A Special-Use Domain Name may be a name that requires special handling in the stub resolver. An example would be a Special-Use Top-Level Domain Name like '.local', which acts as a signal to indicate that the local stub resolver should use a non-DNS protocol for name resolution.
- The current IETF consensus (from a process perspective, not necessarily from the perspective of what would be consensus if the IETF were to attempt to produce a new consensus document) is that all of these purposes for Special-Use Domain Names are valid.
In this case, the term "stub resolver" does not mean "DNS protocol stub resolver". The stub resolver is the entity within a particular software stack that takes a question about a domain name and answers it. One way a stub resolver can answer such a question is using the DNS protocol; however, it is in the stub resolver (as we are using the term here) that the decision as to whether to use a protocol (and if so, which protocol) or a local database of some sort is made.
RFC 6761 does not limit Special-Use Domain Names to TLDs. However, at present, all Special-Use Domain Names registered in the "Special- Use Domain Names" registry [SDO-IANA-SUDR] either are intended to be resolved using the DNS protocol, are TLDs, or are both. That is, at present there exist no Special-Use Domain Names that require special handling by stub resolvers and which are not at the top level of the naming hierarchy.
One point to take from this is that there is already a requirement in RFC 6762 that when a stub resolver encounters the special label, 'local' as the rightmost label of a domain name, it can only use the Multicast DNS (mDNS) protocol to resolve that domain name.
4.1.3. MoU Concerning the Technical Work of IANA
There exists a Memorandum of Understanding (MoU) [RFC2860] between the IETF and ICANN that discusses how names and numbers will be managed through IANA. This document is important to the discussion of Special-Use Domain Names because, while it delegates authority for managing the DNS Namespace generally to ICANN, it reserves to the IETF the authority that is then formalized in RFC 6761. RFC 2860 specifically states:
Note that (a) assignments of domain names for technical uses (such as domain names for inverse DNS lookup), (b) assignments of specialised address blocks (such as multicast or anycast blocks), and (c) experimental assignments are not considered to be policy issues, and shall remain subject to the provisions of this Section 4.
The above text is an addendum to the following:
Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU.
The assignment of names in the DNS root zone, and the management of the Domain Namespace, is by default a function that is performed by ICANN. However, the MoU specifically exempts domain names assigned for technical use and uses the example of domains used for inverse DNS lookup. Both 'in-addr.arpa' and 'ip6.arpa' are in the "Special- Use Domain Names" registry.
Implicit in the MoU is the fact that the IETF and ICANN retain, between them, sole authority for assigning any names from the Domain Namespace. Both the IETF and ICANN have internal processes for making such assignments.
The point here is not to say what the implications of this statement in the MoU are, but rather to call the reader's attention to the existence of this statement.
4.1.4. Liaison Statement on Technical Use of Domain Names
When the IETF received processing requests to add names to the "Special-Use Domain Names" registry, as documented in [RESERVED-TLDS] and [P2P-DOMAIN-NAMES], the IETF chartered a review of the process defined in RFC 6761 for adding names to the registry (as explained earlier). The IETF sent a liaison statement [SDO-IAB-ICANN-LS] to ICANN to notify them of the review, affirm that the discussion would be "open and transparent to participation by interested parties", and explicitly invite members of the ICANN community to participate.
4.1.5. IAB Statement on the Registration of Special Use Names in the
ARPA Domain
As part of the process of resolving the controversy mentioned in Section 4.2.7, the IAB issued a statement saying, in part:
There is currently no process defined with ICANN for special use names to be delegated in the root zone; it has seemed likely to take significant effort to create one. The IAB has noted that .arpa can be used "for technical infrastructure established by IETF standards" [SDO-IAB-SUDN-REG].
Given the lack of an established process with ICANN, IETF documents cannot reserve names in the root of the DNS namespace if those names are to be delegated (that is, used by the DNS protocol). It would be possible to work with ICANN to develop a process for such delegations, but the success of that joint work, and the amount of time it would take, would still be uncertain.
4.2. Secondary Documents Relating to the Special-Use Domain Name
In addition to these documents, there are several others with which participants in this discussion should be familiar.
4.2.1. Multicast DNS
Multicast DNS [RFC6762] defines the Multicast DNS protocol, which uses the '.local' Special-Use Top-Level Domain Name. Section 3 describes the semantics of "multicast DNS names". It is of considerable historical importance to note that the -00 version of the document that eventually became RFC 6762, an individual submission, was published in July of 2001. The version posted at that time contains substantially the same text in Section 3 as RFC 6762 did when published and was discussed in the DNSEXT Working Group at IETF 51 in August of 2001 [IETF-PRO-51]. The July 2001 draft designated '.local.arpa' as the Special-Use Domain Name. This idea was strongly opposed by DNSEXT Working Group participants, and as a result, the author eventually switched to using '.local'.
The history of RFC 6762 is documented in substantial detail in Appendix H of RFC 6762; some notable milestones include the initial proposal to replace AppleTalk's Name Binding Protocol (NBP) in July 1997, the chartering of the Zeroconf Working Group in September 1999, and the assignment of a multicast address for link-local name discovery in April of 2000. A companion requirements document, eventually published as [RFC6760], was first published in September of 2001.
The point of mentioning these dates is so that discussions involving the time when the '.local' domain was first deployed, and the context in which it was deployed, may be properly informed.
4.2.2. The '.onion' Special-Use Top-Level Domain Name
The '.onion' Special-Use Top-Level Domain Name [RFC7686] is important because it is the most recent IETF action on the topic of Special-Use Domain Names; although it does not set a new policy, the mere fact of its publication is worth thinking about.
Two important points to consider about this document are that:
- The IETF gained consensus to publish it.
- Devising a resolution to the situation was constrained by at least two factors. First, there was no process for allocating Special- Use Domain Names at the time that the '.onion' project started using the name; at the time, and since the scope of use of the name was expected to be very constrained, the developers chose to allocate it unilaterally rather than asking the IETF or some other Standards Development Organization (SDO) to create a new process.
Second, for some time, the CA/Browser Forum [SDO-CABF] had been issuing certificates for what they referred to as "internal names". Internal names are names allocated unilaterally for use in site-specific contexts. Issuing certificates for such names came to be considered problematic, since no formal process for testing the validity of such names existed. Consequently, the CA/ Browser Forum decided to phase out the use of such names in certificates [SDO-CABF-INT] and set a deadline after which no new certificates for such names would be issued [SDO-CABF-DEADLINE]. Because the '.onion' domain was allocated unilaterally, this would mean that certificates for subdomains of '.onion' could no longer be issued.
The IETF's designation of '.onion' as a Special-Use Top-Level Domain Name was needed to facilitate the development of a certificate issuance process specific to '.onion' domain names [SDO-CABF-BALLOT144].
4.2.3. Locally Served DNS Zones
"Locally Served DNS Zones" [RFC6303] describes a particular use case for zones that exist by definition and that are resolved using the DNS protocol, but that cannot have a global meaning because the host IP addresses they reference are not unique. This applies to a variety of addresses, including private IPv4 addresses [RFC1918],
"Unique Local IPv6 Unicast Addresses" [RFC4193] (in which this practice was first described), and "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598].
This use case is distinct from the use case for Special-Use Domain Names like '.local' and '.onion' in that the names are resolved using the DNS protocol (but they do require extensions or exceptions to the usual DNS resolution to enforce resolution in a local context rather than the global DNS context). It shares the problem that such names can be assumed neither to be unique across all contexts nor functional for all Internet-connected hosts.
4.2.4. Name Collision in the DNS
"Name Collision in the DNS" [SDO-ICANN-COLL] is a study that was commissioned by ICANN in an attempt to characterize the potential risk to the Internet of adding global DNS delegations for names that were not previously delegated in the DNS and were not reserved under any RFC, but were also known to be (in the case of '.home') or surmised to be (in the case of '.corp') in significant use for Special-Use-type reasons (local scope DNS or other resolution protocols altogether).
4.2.5. SSAC Advisory on the Stability of the Domain Namespace
The ICANN Security and Stability Advisory Committee (SSAC) [SDO-ICANN-SSAC] specification "SSAC Advisory on the Stability of the Domain Namespace" [SDO-ICANN-SAC090] reports on some issues surrounding the conflicting uses, interested parties, and processes related to the Domain Namespace. The specification recommends the development of collaborative processes among the various interested parties to coordinate their activities related to the Domain Namespace.
4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" [RFC7050] is an example of a document that successfully used the process in RFC 6761 to designate '.ipv4only.arpa' as a Special-Use Domain Name; in this case, the process worked smoothly and without controversy.
Unfortunately, while the IETF process worked smoothly, in the sense that there was little controversy or delay in approving the new use, it did not work correctly: the name 'ipv4only.arpa' was never added to the "Special-Use Domain Names" registry. This appears to have happened because the document did not explicitly request the addition of an entry for 'ipv4only.arpa' in the "Special-Use Domain Names" registry. This is an illustration of one of the problems that we have with the process in RFC 6761: it is apparently fairly easy to miss the step of adding the name to the registry.
4.2.7. Additional Reserved Top-Level Domains
"Additional Reserved Top Level Domains" [RESERVED-TLDS] is an example of a document that attempted to reserve several TLDs identified by ICANN as particularly at risk for collision as Special-Use Domain Names with no documented use. This attempt failed.
Although the aforementioned document failed to gain consensus to be published, the need it was intended to fill still exists. Unfortunately, although a fair amount is known about the use of these names, no RFC exists that describes how they are used and why it would be a problem to delegate them. Additionally, to the extent that the uses being made of these names are valid, no document exists indicating when it might make sense to use them and when it would not make sense to use them.
RFC 7788 [RFC7788] defines the Top-Level Domain Name '.home' for use as the default name for name resolution relative to a home network context. Although, as defined in RFC 7788, '.home' is a Special-Use Domain Name, RFC 7788 did not follow the process specified in RFC 6761: it did not request that '.home' be added to the "Special-Use Domain Names" registry. This was recognized as a mistake and resulted in the posting of an errata report [Err4677]. Additionally, '.home' is an example of an attempt to reuse a domain name that has already been put into use for other purposes without following established processes [SDO-ICANN-COLL], which further complicates the situation. At the time RFC 8244 was written, the IETF was developing a solution to this problem.
5. History
A newcomer to the problem of resolving domain names may be under the impression that the DNS sprang fully formed directly from Paul Mockapetris' head (as was the birth of Athena in Greek Mythology). This is not the case. At the time the IAB technical document was written [RFC2826], memories would have been fresh of the evolutionary process that led to DNS' dominance as a protocol for domain name resolution.
In fact, in the early days of the Internet, hostnames were resolved using a text file, HOSTS.TXT, which was maintained by a central authority, the Network Information Center, and distributed to all hosts on the Internet using the File Transfer Protocol (FTP)
[RFC959]. The inefficiency of this process is cited as a reason for the development of the DNS [RFC882] [RFC883] in 1983.
However, the transition from HOSTS.TXT to the DNS was not smooth. For example, Sun Microsystems' Network Information System (NIS) [CORP-SUN-NIS], at the time known as Yellow Pages, was an active competitor to the DNS, although it failed to provide a complete solution to the global naming problem.
Another example was NetBIOS Name Service, also known as WINS [RFC1002]. This protocol was used mostly by Microsoft Windows machines, but also by open-source BSD and Linux operating systems to do name resolution using Microsoft's own name resolution protocol.
Most modern operating systems can still use the '/etc/hosts' file for name resolution. Many still have a name service switch that can be configured on the host to resolve some domains using the NIS or WINS. Most have the capability to resolve names using mDNS by recognizing the special meaning of the '.local' Special-Use Top-Level Domain Name.
The Sun Microsystems model of having private domains within a corporate site, while supporting the global Domain Name System for off-site, persisted even after the NIS protocol fell into disuse. Microsoft used to recommend that site administrators use a "private" TLD for internal use, and this practice was very much a part of the zeitgeist at the time (see Section 5.1 of [SDO-ICANN-COLL] and Appendix G of [RFC6762]). This attitude is at the root of the widespread practice of simply picking an apparently unused TLD and using it for experimental purposes, which persists even at the time of writing of this memo.
This history is being presented because discussions about Special-Use Domain Names in the IETF often come down to the question of why users of new name resolution protocols choose to use domain names rather than using some other naming concept that doesn't overlap with the namespace that, in modern times is, by default, resolved using the DNS.
The answer is that as a consequence of this long history of resolving domain names using a wide variety of name resolution systems, domain names are required in a large variety of contexts in user interfaces and applications programming interfaces. Any name that appears in such a context is a domain name. So, developers of new name resolution systems that must work in existing contexts actually have no choice: they must use a Special-Use Domain Name to segregate a portion of the namespace for use with their system.
6. Security Considerations
This document mentions various security and privacy considerations in the text. However, this document creates no new security or privacy concerns.
7. IANA Considerations
This document does not require any IANA actions.
8. Informative References
Wikipedia, "Network Information Service", August 2017, <https://en.wikipedia.org/wiki/ Network_Information_Service>.
Lewis, E., "Domain Names, A Case for Clarifying", Work in Progress, draft-lewis-domain-names-09, August 2017. [Err4677] RFC Errata, "Erratum ID 4677", RFC 7788, <https://www.rfc-editor.org/errata/eid4677>.
IETF, "Proceedings of the 51st IETF Meeting", August 2001, <http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
Grothoff, C., Wachs, M., Wolf, H., Ed., Appelbaum, J., and L. Ryge, "Special-Use Domain Names of Peer-to-Peer Systems", Work in Progress, draft-grothoff-iesg-special- use-p2p-names-04, January 2015.
Huston, G., Koch, P., Durand, A., and W. Kumari, "Problem Statement for the Reservation of Special-Use Domain Names using RFC6761", Work in Progress, draft-adpkja-dnsop- special-names-problem-06, September 2016.
Chapin, L. and M. McFadden, "Additional Reserved Top Level Domains", Work in Progress, draft-chapin-additional- reserved-tlds-02, March 2015. [RFC882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, DOI 10.17487/RFC0882, November 1983, <https://www.rfc-editor.org/info/rfc882>. [RFC883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983, <https://www.rfc-editor.org/info/rfc883>. [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <https://www.rfc-editor.org/info/rfc959>. [RFC1002] NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, and End-to-End Services Task Force, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications", STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, <https://www.rfc-editor.org/info/rfc1002>. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>. [RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain Names", RFC 2352, DOI 10.17487/RFC2352, May 1998, <https://www.rfc-editor.org/info/rfc2352>. [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000, <https://www.rfc-editor.org/info/rfc2826>. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, June 2000, <https://www.rfc-editor.org/info/rfc2860>. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>. [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <https://www.rfc-editor.org/info/rfc6303>. [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <https://www.rfc-editor.org/info/rfc6598>. [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, DOI 10.17487/RFC6760, February 2013, <https://www.rfc-editor.org/info/rfc6760>. [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>. [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>. [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015, <https://www.rfc-editor.org/info/rfc7686>. [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <https://www.rfc-editor.org/info/rfc7719>. [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>. [SDO-CABF] CA/Browser Forum, "CA/Browser Forum Home Page", <https://cabforum.org>.
CA/Browser Forum, "Ballot 144 - Validation Rules for .onion Names", February 2015, <https://cabforum.org/2015/ 02/18/ballot-144-validation-rules-dot-onion-names>.
CA/Browser Forum, "SSL Certificates for Internal Server Names", January 2013, <https://www.digicert.com/internal-names.htm>.
CA/Browser Forum, "Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses", June 2012, <https://cabforum.org/internal-names/>.
IETF, "Liaison Statement from the IAB to the ICANN Board on Technical Use of Domain Names", September 2014, <https://datatracker.ietf.org/liaison/1351>.
IAB, "Internet Architecture Board statement on the registration of special use names in the ARPA domain", March 2017, <https://www.iab.org/documents/ correspondence-reports-documents/2017-2/iab-statement-on- the-registration-of-special-use-names-in-the-arpa- domain/>.
IANA, "Special-Use Domain Names", <http://www.iana.org/ assignments/special-use-domain-names>.
Interisle Consulting Group, LLC, "Name Collision in the DNS", Version 1.5, August 2013, <https://www.icann.org/ en/system/files/files/name-collision-02aug13-en.pdf>.
ICANN, "gTLD Applicant Guidebook", Version 2012-06-04, June 2012, <https://newgtlds.icann.org/en/applicants/agb/ guidebook-full-04jun12-en.pdf>.
ICANN Security and Stability Advisory Committee, "SSAC Advisory on the Stability of the Domain Namespace", ICANN SAC090, December 2016, <https://www.icann.org/en/ system/files/files/sac-090-en.pdf>.
ICANN, "Security and Stability Advisory Committee (SSAC)", December 2016, <https://www.icann.org/groups/ssac>. [TOR] Tor, "Tor - Anonymity Online", <https://www.torproject.org>.
Mark Andrews, Stuart Cheshire, David Conrad, Paul Ebersman, Aaron Falk, and Suzanne Woolf all made helpful and insightful observations or patiently answered questions. This should not be taken as an indication that any of these folks actually agree with what the document says, but their generosity with time and thought are appreciated in any case.
Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr Spacek, and others provided significant review and/or useful comments.
This document also owes a great deal to Ed Lewis' excellent work on what a "domain name" is [DOMAIN-NAMES].
We would also like to acknowledge the authors of [PROBLEM-SPECIAL-NAMES], including Alain Durand, Geoff Huston, Peter Koch, and Joe Abley, for their efforts to frame the issues and engage the working group, as well as their contributions to the list of issues from their document [PROBLEM-SPECIAL-NAMES].
Authors' Addresses
Ted Lemon Nominum, Inc. 800 Bridge Parkway Redwood City, CA 94065 United States of America Phone: +1 650 381 6000 Email: email@example.com Ralph Droms Email: firstname.lastname@example.com Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America


text:
Celia Franca, C.C., O.Ont.,
1921 - 2007 Many costumes, many stages and many honours and awards brought Celia Franca to her status as a "national treasure" in Canada.
Miss Franca received her early education in music and dance at the Guildhall School of Music in London, England and later studied under Judith Espinosa, Stanislas Idzikowski, Marie Rambert and Antony Tudor. She worked as a dancer, teacher, choreographer and guest artist for some of the leading ballet companies in London.
Her Canadian connection began with the invitation to come to Toronto to establish a ballet company. She accepted, and in 1951 founded the National Ballet of Canada. In 1959 she co-founded the National Ballet School of Canada.
After retiring from the National Ballet in 1974 she made Ottawa her home with her husband James Morton, founding principal clarinet of the National Arts Centre Orchestra.
Celia Franca could not have given Merrilee Hodgins and Joyce Shietze, founders of The School of Dance, any greater gift than accepting their invitation to be their co-artistic director. Thus began her twenty-seven year contribution to the pursuit of excellence in dance education here in Ottawa.
Miss Franca was always active in all aspects of The School of Dance including teaching classes regularly, delighting most particularly in the very young students. "Our Miss Franca," as she was known to the students of The School of Dance, coached the young dancers, acting as an artistic mentor to many memorable performances. Not one to shy away from hard work, Miss Franca also faithfully supported all the fundraising projects of The School, from the letter writing campaigns to dancing at the Hoedowns!
In 1985 the Celia Franca Scholarship was established by The School of Dance in her honour. Merrilee Hodgins and Joyce Shietze were instrumental in the creation of the Celia Franca Foundation, dedicated to excellence in dance training in Canada.
Miss Franca was the honoree at numerous events produced by The School of Dance: Celia Franca Scholarship Evenings held at the Museum of Nature, the National Gallery of Canada and the National Arts Centre and, in 2001, Happy Birthday Celia, love Canada, celebrating Miss Franca's 80th birthday. On that momentous occasion, 3,500 long-stemmed red roses were given to audience members to mark the birthday.
The tribute, Thank you Miss Franca, a gala evening of film, music, dance and memories thanking Celia Franca for her contribution to the arts in Canada for over fifty years, was produced by The School of Dance and took place on June 26, 2006 at the National Arts Centre in Ottawa.
The Celia Franca Foundation is a registered Canadian charity (registration # 89102278 2RR0001).
No applications are being currently being accepted.

subset: commoncrawl


text:
I offer it for your reactions:
My PCP is in a large multi-specialty practice in MA. The practice absolutely insists that all referrals for sub-specialty care go to providers in their practice.
For the most part I have complied, sometimes reluctantly. I've seen ortho, derm, podiatry, gyn etc etc. I've given them plenty of business.
But now I want to go to a sub-specialty provider outside of their practice and definitely don't want to see their doctors for this particular part of my care. They have told me they will give me a referral for one visit for a "second opinion", but otherwise if I want to see that specialist outside their practice for ongoing care, I will need to get a new PCP outside of their practice who can refer me.
I told them I understand their business model is to encourage patients to stay in the group, but that I have a right to go whatever practice I want to and that my insurance will pay for. They responded that this is "managed care" and that if I want to stay with their group I need to use their providers only.
I have a lot of reactions to this. I'm angry I'm being made to jump through hoops with a resulting delay in my care. I feel my rights as a patient are being infringed upon for their business interest. AND, I'm offended that they are willing to lose me as a long-term patient for this short excursion to the outside world.
But besides that, here are my questions:
1) Is this really "managed care?" I thought that had to do with my insurance limiting where I can go and how many visits will be covered, not the policy of the medical practice.
2) Can they really do this? Do I have any legal rights that, if my doctor deems that sub-specialty care is medically necessary, that they need to give me a referral to the practice of my choice? I heard of pediatricians "firing" patients who don't vaccinate their kids, so is this in the same vein... if you don't play by our rules go play somewhere else?


text:
by TJ Chapman
His name is whispered behind the hands of many gossiping women.
The way he pleasures a body leaves you craving his touch, his words, and his breath. The way his eyes bore into yours, you want to look away, but you can't. He controls every part of your being while you're in his domain. And when you leave, you feel bereft, but sated.
Who is this man they speak about?
Megan Brayer has the chance to interview this elusive gentleman. Will the answers he gives to her questions satisfy her curiosity?
This is the first book of many short stories. Each story will tell its own little story and can be read as stand alone.
"First of all, thank you for taking the time to let me do this interview. I'm going to jump right in because your secretary said you didn't have much time today. To start easy, the first question is why? Why did you choose this as your profession?" It was the one thing that puzzled Megan.
"My time today is yours, I've made sure of that; and to answer your question, why not? I have the means, and motive as it were. I gain pleasure by giving it. I get paid to help these people, to give them what they want with total anonymity. It's not dangerous or stupid, and I certainly know I'm mature enough to cope with each situation that comes to me. I don't care about their history, their backgrounds. I get a little peeved if they're married or have a partner, and I do try in all instances to persuade them not to come to me, but it is what it is. I've had several couples come to me, so it can't be all that bad."
"So you do it to gain pleasure? Surely you could go to a bar each night for that, or has it got something to do with money?" Megan had a nagging thought that he was just a typical player who was in it for the money as an added bonus.
"Miss Brayer, my first paid 'job' was just before my eighteenth birthday. I had a student in the grade above me begging for my help with her English. She didn't have much money, but came up with the idea that she could give me a blow job as a payment. Crude, it seems, but as a young man, I was up for it. At the time I was still the gentleman my parents raised me to be, so I did hesitate. However, the girl was one step away from not graduating and by the end of the week, I caved. After I'd helped her with the work she was set, she offered me the 'payment', but I could see it in her eyes. Fear and nerves. She didn't want to do it just as much as I didn't want to use her for my own horny satisfaction." He picked up his tall glass of iced water, took a sip, and smiled at Megan as he sat it back down on the crisp white tablecloth.
"I told her that she didn't have to do anything and that I wouldn't pressure her, but she wouldn't take no for an answer. We talked for a long time. At that point in my life, I had no clue how to please a woman. One minute we were talking about the stresses of being teenagers and the next, she was showing me how to please her. I was curious and very much willing to learn, so over the next few months I helped her catch up with her work and she taught me the art of pleasing a woman."
Megan snorted a little. "That's a bit one-sided, don't you think? She got the education and the pleasure, too."
"Not at all. I got an education also, and even if it was one-sided, what horny teenage boy would say no to free sex and a pair of boobs to play with?"
"True. So what happened after you left school?"
"Well, that's when my education really kicked off. I took a few psychology classes to help both me and women. I went to clubs, all different ones. Early on I learned the more I pleasured a woman, the more I got from it. I observed them constantly. Some women gave away what they wanted from the beginning, others were more reserved. It was almost like I was power hungry. The more I watched and learned, the more a woman would writhe under my control, and the harder I came. I didn't even have to have sex with them. I could give them pleasure all night and then go home to finish myself off. Those were always the best nights."
"Power hungry to give pleasure. That sounds pretty strange."
"Not really. Miss Brayer, take away the fact that we have morals, societies, et cetera, and what we're left with is nothing more than basic human instincts. Animal instincts. Men still like to congregate around a fire. We're the heads of our households and when it comes to the bedroom, our instincts really come out. Do you know why most women like their hair being pulled?" he asked, and Megan shook her head, trying not to be pulled in by the feral look in his eyes as he gazed at her over the small table.
TJ Chapman hates talking about herself in third person…
Living in small villages and towns for most of my life, you would have thought that it would get boring as hell. Fortunately for me, I loved it. I got to know a lot of people and when you take the time to 'people watch' as a child, your mind can run at a mile a minute.
I often let my mind wander into the lives of these people. That old lady down the road, well, she could have been a spinster witch. The pub owner who looked very shifty, well… He could certainly be up to no good with things in his cellar. You get my point.
I love writing almost any genre and most of my stories are based around the small villages and towns I grew up in, in Kent, UK. Humour, Supernatural, and Romance are my main focus, but if I get a good plotline in my head, my fingers start typing.


text:
Download picture of a free hd coffee beans image. Coffee Beans Wallpapers. Coffee Beans Wallpaper is available in 360x260, 1229x768, 1728x1080, 1920x1200 pixels resolutions. Choose Coffee-Beans-Wallpapers.jpg's appropriate size/resolution from following which best fit on your device.
To download above image, click on the download button, the wallpaper will open in browser's new window, then right click on the Coffee Beans Wallpaper image and select 'save as' to save on your computer/laptop.


text:
Get C_TB1200_93 SAP Certification Without Exam
We can clear SAP C_TB1200_93 Exam and get SAP C_TB1200_93 Certificate within 7 days for you. Exams will be taken in the authorized testing center. Your certification status can be verified on the SAP official website and the C_TB1200_93 SAP Certificate will arrive from SAP at your owned address. You get C_TB1200_93 SAP Certification without ever having to set foot into a testing center. Just sit back and relax after placing an order.
SAP Business One Release 9.3
SAP Business One Release 9.3 Certification Training C_TB1200_93 100% Pass without Exam
- 1. C_TB1200_93 USD $2000 (Upfront)
- 2. C_TB1200_93 USD $2000 (After Result)
For application, please provide the following information:
- And send to email@example.com , we will send the payment information to you.
- After you send the payment, we will complete your tests within 7 business days.
- And let you check the tests result in SAP Website.
Choose Us
27/7 Customer Support
100% Authentic
Passing Guarantee or
100% Money Back
100% Secure Guarantee
Flexible Payments Plan
Over 15 Years Experiance
How it Works
Only 3 Steps, Hassle free process to get IT Certified.


text:
Don't Believe the Hype – Millennials' Transportation Habits Are Changing
Despite news stories claiming that Millennials are buying up cars at record rates, the reality is quite different. After adjusting previous studies to account for differences in the size of the generations measured, on a per-capita basis, Millennials are 29 percent less likely than members of Generation X to own a car.
You may have seen a number of news stories recently claiming that Millennials are buying up cars at record rates just like previous generations, and that they just got a late start.1,2 Those reports don't tell the whole story though. After adjusting previous studies on the topic to account for differences in the size of the respective generations measured, City Observatory found that, on a per-capita basis, members of Generation Y (born 1977 to 1994) are 29 percent less likely than members of Generation X to own a car.3
Graph based on numbers from City Observatory
The myth about Millennials and their car purchasing has been overhyped. According to a survey released by The Rockefeller Foundation and Transportation for America on Millennials' perceptions and attitudes toward transportation, almost half (46 percent) of the surveyed vehicle owners said that they would "seriously consider giving up their cars if they could count on a range of transportation options."4 The message is clear: Millennials are willing to rely upon non-driving modes of transportation more heavily if presented with good options. Encouraging these positive trends will lead to significant benefits including less money spent on roads and highway construction and repair, fewer traffic problems and delays, fewer crashes leading to death and serious injuries, and significantly less air and global warming pollution.
We have long pointed to Millennials' changing transportation behavior as a reason to invest less in new and wider highways and invest more in critical transit, biking, and pedestrian alternatives. New and better technology, such as mobile applications that Millennials have been quick to adopt, makes it easier to use other transportation options. Changing lifestyles, choices, and preferences are also playing a key role in Millennials' changing transportation habits.
The result: America has the fewest 16-year-old drivers today since the 1960s5 and "a smaller percentage of Americans are licensed to drive now than were in 2008."6 State and federal government institutions should be encouraging and assisting in this trend toward driving less. By enhancing public transportation, expanding new technologies, and building more biking and walking infrastructure, we can create a more efficient transportation system that is cleaner and gives people the options that they want.
1 , "Millennials Embrace Cars, Defying Predictions of Sales Implosion," Bloomberg, April 20, 2015.
2 Derek Thompson, "Millennials: Not So Cheap, After All," The Atlantic, April 21, 2015.
3 Joe Cortright, "Young People Are Buying Fewer Cars," City Observatory, April 22, 2015.
4 Michael Myers, "Public Transportation Shapes Where Millennials Decide to Live," The Rockefeller Foundation, April 23, 2014.
5 Laura Bliss, "America has the fewest 16-Year-Old Drivers Since the 1960s," CityLab, April 6, 2016.
6 "Highway Statistics Series" Federal Highway Administration, last modified May 6, 2016.


text:
One of the software programs that really kick-started wide use of Twitter in its early days was TweetDeck, first released in 2008.
Acclaimed in particular by early adopters, TweetDeck quickly became the third-party app of choice for power users of Twitter because of its ability to let you do far more with Twitter than you could on the website. Developed to work on Adobe AIR, it ran on different platforms: Windows, Mac, Linux, it just worked. There was a version for mobile devices and one for iPads. Broadly, TweetDeck in its various guises was regarded as superior to other third-party Twitter apps. It enabled you to manage your status updates to Facebook as well.
In short, if you were a power user, TweetDeck was your tool of choice.
The shine wore off a bit when Twitter acquired TweetDeck in 2011 and subsequent development of the app seemed to shift in a different direction. Soon it fell out of favour with many, including me, especially after a native Windows version was released which I didn't think was very good at all.
Earlier this year, I switched to MetroTwit, a third-party app from Australian developers Pixel Tucker, that is designed for Windows, in particular Windows 8. It offers many features similar to those you see in TweetDeck.
While I do like it a lot, especially the overall look and feel, in my experience it can be a bit flaky with frequent crashes and other errors. Maybe the culprit includes the .NET Framework 4 required to run MetroTwit (and I think this version of .NET is a bloated beast that slows down my PC). So if you want stable, MetroTwit may not be the app for you yet. The version for Windows 8 might be better; I haven't tried that one.
Yesterday, I encountered a terrific in-depth assessment – far more than just a review – of where TweetDeck has got to now which has prompted me to try the Windows version again.
In "How I learned to stop worrying and love new Tweetdeck," Storyful journalist Felim McMahon presents a thoughtful, detailed perspective of TweetDeck from the journalist's point of view. But anyone will find this most useful in understanding a great deal about TweetDeck's key functionality and how to make use of it.
It starts thus:
[…] This article examines some reasons why those who are not using Tweetdeck should use it — including a tour using quick-fire diagrams. I'll also look at some reasons why people who have avoided the new Tweetdeck might want to make peace with it, and some workarounds for its remaining shortcomings. (Aficionados handling a large number of lists may like to skip to the end of the piece for some handy tips.)
Why use Tweetdeck?
The best and perhaps singular reason to use Tweetdeck is to monitor and manage a large number of Twitter streams at once. Many of the streams you'll want to keep an eye on are related to your own account – including your Timeline, Interactions and the Activity column.
What follows is a rich essay including annotated screenshots and diagrams that really do help you fully understand all that McMahon explains. It is the best explanation of what you can do with TweetDeck that I've read.
Read it yourself, and see if you don't go and grab TweetDeck straightaway!


text:
An OUTCAST BOY who can commune with the DEAD... A TOWN obsessed with the past, UNWILLING to accept him! BULLIES! ZOMBIES! GHOSTS! WITCHES! A FILM as SPOOKY as it is HEARTWARMING... CHILLING as it is ENDEARING! LAIKA's 3D stop-motion TRIUMPH ParaNorman has SCARES and LAUGHS aplenty... AND a BEWITCHING main-on-end title sequence worth writing home to mother about!
The tale of young Norman Babcock comes to a close to the tune of the White Stripes' "Little Ghost" as the slightly skewed citizens of New England's Blithe Hollow transition from their stop-motion reality into beautifully rendered motion paintings. Each character gets a moment to shine, their goofy, freeze-frame poses and accompanying credit recalling the events of the film and a more innocent era of title design. With ghoulish typefaces and delightfully old-fashioned screen transitions, the sequence pays homage to the Saturday night horror flicks that inspired Norman's spine-chilling adventure. Just a few of the many small touches present in ParaNorman sure to bring out the kid in anyone.
Art of the Title speaks to LAIKA/house artist and illustrator AARON SORENSON about the gleefully spooky and charmingly realized main-on-end titles of ParaNorman.
How did the first meeting about this sequence go?
Arianne Sutner, one of the co-producers, spearheaded the process. She contacted me and asked, "Are you interested in directing our title sequence?" Of course, I said yes.
We then had the initial meeting where Chris Butler and Sam Fell, the film's co-directors, laid out their vision for the titles, which was inspired by old Hollywood horror posters – specifically old B movies artwork with slightly garish qualities. They wanted the animation to look quite painterly and loose. Designer Trevor Dalmer had already done some amazing concept art and the directors used his illustrations in a short proof of concept animatic that featured the first few characters. The challenge was to create art for the key crew titles and the credit roll for an eight-minute piece, so there was still a lot of design and layout to consider. I wasn't even sure how we were going to animate the characters and maintain the painterly quality in motion, but it was fun to just dive into the deep end.
How closely did you work with the rest of the film's production team?
Our production bridged the locations of the two LAIKA studios. Our immediate team consisted of a mix of artists from LAIKA/house, LAIKA's content division, and artists from the feature side. LAIKA/house Co-EP Jan Johnson produced the sequence and juggled artists back and forth with Arianne. To keep the process flowing smoothly, we regularly checked in with Chris and Sam and constantly posted work in progress as we went along.
What were the initial design stages like? How many different concepts did you go through?
This was actually the most challenging part of the process. The goal was to have every credit the camera paused on look like a classic horror poster from that late '40s to '60s. Getting the compositions to work in a wide-screen format was a challenge, but more importantly we had to integrate the stylized poster images with the characters' personalities and key scenes.
So for example, headstones from a graveyard poster morphed seamlessly into a painted toenail. Some character's concepts came together easily, while others were tougher to conceptualize. When in doubt we went back to the film for inspiration.
At what point did the White Stripes' "Little Ghosts" come into play?
They had the rights to the song before I was even involved. It's a perfect choice – great energy, related to the subject matter, but not too literal. And it's the White Stripes!
Detail the creation of the sequence for us.
Right, so after the initial meeting with the film's directors, we went into an extensive storyboard design phase to work out the basic concepts, timing, and compositions. I borrowed Julian Narino and David Vandervoort from the ParaNorman crew to draw the storyboards. We also created the art cards for the main crew title and the "roll," which are all of the scrolling titles at the end of the sequence. The roll and the crew credits was more of a design and layout puzzle than anything else.
Once we had a working animatic for the main credits – voice talent, directors, and producers – we tightened up each layout. To get exact key poses and character expressions from the film, we based the hand-drawn designs on the original digital models made in Maya to create the rapid-prototyped faces. We then animated the characters traditionally in 2D and composited the rough animation in an After Effects comp for approval. Once a scene was approved, we sent selected frames to the production designer to paint for a final look. After we got approval, we digitally painted the characters with many layers of highlights and shadows and additional brushstrokes, which were tracked onto the artwork. LAIKA/house Designer Jenny Kincade actually discovered new ways to paint the animation while retaining the painterly quality. She would often track in fields of loose brushstrokes to break up flat painted areas – sometimes it was painstakingly necessary just to paint in strokes by hand.
After many long hours together, we were ready to take frames from the concept and pull the different paint layers apart and track shapes to match the rough animation. Animators Dave Vandervoort and Chris Purdin streamlined the method along with Stephen Bodin, Jon David Buffam, and Eric Kilkenny. Each artist had their own way of implementing this "paint-tracking" technique, but I think it was successful because it was founded on the solid 2D animation under all of the digital trickery.
There was a ton of compositing work done as well, roughing up edges and choking mattes like crazy. Alphonse Swinehart and Erich Richter handled the massive After Effects projects, which were constantly being tweaked for timing, camera, and effects.
The final phase, which ended up being a lot more fun than I imagined, was the 3D layout. We broke out layers organically in terms of depth and sent the layers to the feature's 3D team – Steve Emerson and Brian Van't Hul – to work their magic. Chris and Sam would weigh in on how the depth was working and we'd implement their feedback. For example, in the beginning of the sequence when the camera is finding the different posters and the zombie hand crashes through, the directors had us separate the fingertips from the rest of the hand to add an extra bit of depth and make the action more extreme.
What were your influences or references for this sequence? Were the animations in the sequence modeled off of Illustrator Heidi Smith's distinctive character designs and Kent Melton's sculptures, or were you referencing the work that was being put into action by the on-set animators?
The way we represented the characters was based off the final puppets you see in the film. We went to great lengths to get every facet and asymmetrical feature just right. We actually used CG models of the heads as reference for our key positions. This is not to say the end sequence was animated in CG! Chris and Sam were very adamant that they wanted a hand-drawn aesthetic. In some cases there were no CG references. For example, the Judge Zombie was a tangible mechanical puppet – unlike puppets with CG-created removable rapid-prototyping faces – so Dave Vandervoort drew a likeness instead.
What inspired the different lettering styles for the names?
Alphonse Swinehart created all of those and did an amazing job. The directors wanted variety in the typography, so we embraced it. The biggest thing with those horror fonts is legibility, so we had to do a lot of tweaking to get them to read quickly. We also had to change the colors quite a lot to match the concept art, but the typography itself changed very little.
How did you decide to use different transitions for each name?
The transitions were always part of the plan. For a while we tried to make that a camera move to Norman, but the cut was better. Some of the transitions, such as going into the poster on Norman's wall, or the tombstone turning into the toe, were already in the proof of concept. The rest came about organically based on the imagery in the concept frames. For instance, with Grandma we had this little scene in the background of her floating over Norman's bed and it just felt natural to have the disembodied hand of the Judge come out from under the bed and then scamper across frame leading the viewer to the Judge's credits.
How long did this sequence take to complete, from the first meeting to the final cut?
We had our first conversation with Sam and Chris at the beginning of December and delivered the finished titles at the end of May. Six months, all in.
Tell us about the fun little Norman "making-of" scene after the credits.
Actually, that was created by the movie's marketing team! It's pretty amazing.
Which tools and software did you use to put it all together?
Roughly half the animation was done on actual paper, which seems so old fashioned but has its advantages. One of the animators drew in Flash, frame by frame. We painted the characters in Toon Boom Harmony and finished the compositing in After Effects. Photoshop was used for all the backgrounds and a little bit of Maya for reference.
What is working at LAIKA like?
The thing I like most about the studio's Entertainment and HOUSE sides is the fearlessness of the artists. We're often asked to do some pretty crazy stuff. In the beginning, we really don't know how we're going to pull it all off. It's that sense of discovery and problem solving that I like. It's also an outsider studio, which appeals to me. It has its own identity artistically and is always breaking new visual ground, without losing sight of good storytelling and strong characters.


text:
Ryan T. Anderson, editor of the Witherspoon Institute's Public Discourse site, reviews Acton Research Director Samuel Gregg's new book, The Modern Papacy, in the Nov. 28 issue of the Weekly Standard. Anderson says the book is "a significant contribution to the study of John Paul and Benedict's thought." Excerpt of "The Holy Seers" follows (for the complete article, a Weekly Standard subscription is required):
Gregg presents John Paul and Benedict as more or less united in the main trajectory of their dialogue with modernity. For ease in classification, this can be grouped in four domains: science, reason, faith, and revelation. While the scientific method has provided mankind with many indisputably helpful discoveries, the modern papacy argues that to embrace the instrumental, technocratic rationality at the heart of the scientific process as if it were the entirety of rationality is to narrow the range of realities accessible to rational inquiry. While the scientific approach can discover truths about empirical physical realities, it can provide little help in discussions of justice, love, and beauty–whether they be about earthly domains or transcendent ones. Only by broadening the conception of rationality beyond the empirically verifiable realm of the scientific, John Paul and Benedict argue, can man arrive at the truths necessary to secure his full flourishing. In other words, man needs to embrace science without embracing scientism.
Recovering the sapiential dimension of reason that considers the big questions regarding the meaning and destiny of human existence and the significance of human action is a key part of recapturing a more robust conception of human rationality. As Gregg presents John Paul and Benedict, a major aspect of their engagement with modernity has been to show that reason can discern objective standards of right and wrong, good and evil, as well as ascertain the existence of God and certain key aspects of his nature.
Most important of all is to see, with Benedict, that "at the beginning of all things stands the creative power of reason." Gregg explains that, in Benedict's view, "agnosticism and atheism ultimately rely upon a rational affirmation that all is ultimately based upon irrationality." But even while defending reason's lofty vocation, John Paul and Benedict stress that being rational isn't enough, for rationality itself points to the existence of truths that reason alone cannot grasp, truths that can only be known through God's revelation, accepted by faith. In other words, man needs to embrace reason without embracing rationalism.
When reason concludes that there are truths about God and the universe that reason itself cannot ascertain, that man's finite reason cannot exhaust the infinite, this could open the door to legitimizing faith in anything–and everything. Gregg is careful to point out that the modern papacy's engagement with modernity is just as critical of theistic thinkers who attempt to ground faith's legitimacy in what amounts to little more than blind leaps.


text:
The Boatshed Sales Process
Selling your boat with Boatshed
At Boatshed we have a proven and structured process for selling your boat. Here we will take you through each step so you know exactly what will happen throughout the sales process.
The Process
1. Boat visit
Our local Boatshed broker will arrange an appointment with you to visit your boat. We will record your boat's full inventory along with taking unlimited photos, videos, and VR images. You will sign a standard listing agreement.
2. Valuation
We will advise you of the most suitable price to advertise your boat. The price will be based on the condition of your boat, the current market as well as data from the 20,000+ boats we have sold.
3. Marketing
We will create a bespoke detailed page for your boat, including all the photos, videos, and VR we have collected. When your boat goes live, it's marketed across our 70+ Boatshed offices around the world. It will also be advertised on websites such as Apollo Duck and Rightboat. Using the best technology in the industry our platform uses machine learning and targeted marketing campaigns reaching out to our over 1 million customers.
4. Viewings
We will manage all customer enquiries, questions and arrange and attend all viewings of your boat, in person or virtually. Being local, we are on hand to meet with surveyors and talk to the marinas. We will always provide feedback from viewings, keeping you fully informed at all times. On My Boatshed, your secure online area, you can obtain live information on all the activity, viewings, and sales data of your boat.
5. Negotiation
We are duty bound to relay all offers to you for your consideration. We will manage the negotiation process and will always strive to obtain an agreeable price in the shortest possible time. We will manage the sale from start to finish, keeping you informed throughout, ensuring the sale of your boat is handled expertly and efficiently.
6. Sale secured
In addition to regular updates, your broker will also use their local knowledge to help you with arrangements of servicing, delivery, cleaning, and other logistics. We offer friendly advice and professional service before, during and after the sale of your boat.
Your listing
Below, Wendy Baker, our Brokerage Manager will take you through what a website listing on Boatshed looks like.
What's more...
- No sale, no fee. You only pay for our service if we are successful in selling your boat.
- No exclusivity. If you sign a non-exclusive agreement we are happy for you to list your boat with other brokers or try to sell it yourself, as long as it is advertised at the same price.
- We take lots and lots of photos - our transparent approach to showing every part of the boat means on average we sell boats twice as quickly as other brokers!


text:
Please do not remove my tag, thank you.DO NOT ALTER THIS IMAGE OR UPLOAD TO OTHER GRAPHIC SITES & CLAIM AS YOUR OWN CREATION! (THIS INCLUDES imikimi, Blingee.com & Photobucket) DO NOT REMOVE MY TAG OR COVER IT WITH ANOTHER IMAGE For personal and non-commercial use only. |
Login to give your vote |
| |||||||
Owner of this graphic: jczbabydoll File size: 69.6kB [297x145] |
Please login or register to submit your comment.


text:
Class ApplicationInstance
Defined in:
The ApplicationInstance
encapsulates all of the stateful aspects of a
running Application
At a high-level, we break application boot into two distinct phases:
- Definition time, where all of the classes, templates, and other dependencies are loaded (typically in the browser).
- Run time, where we begin executing the application once everything has loaded.
Definition time can be expensive and only needs to happen once since it is an idempotent operation. For example, between test runs and FastBoot requests, the application stays the same. It is only the state that we want to reset.
That state is what the ApplicationInstance
manages: it is responsible for
creating the container that contains all application state, and disposing of
it once the particular test run or FastBoot request has finished.
- addObserver
- boot
- cacheFor
- decrementProperty
- destroy
- factoryFor
- get
- getProperties
- hasRegistration
- incrementProperty
- init
- lookup
- notifyPropertyChange
- ownerInjection
- register
- registerOptions
- registerOptionsForType
- registeredOption
- registeredOptions
- registeredOptionsForType
- removeObserver
- resolveRegistration
- set
- setProperties
- toString
- toggleProperty
- unregister
- willDestroy
No documented items