Whilst the famous Tweed is Harris' best-known export, the island offers a stunning range of other attractions for the visitor. Known and treated locally as an entirely separate island, Harris and Lewis are actually a single landmass, 'separated' physically by glaciation with Harris possessing the more spectacular geology. Scottish Gaelic is widely spoken here, and the culture and economy have been shaped by the use of this ancient language in everyday life.
The Hebrides' highest mountain, the Clisham, is located on Harris at 799 metres (2,621ft) above sea level. In most of Harris, the landscape is dominated by PreCambrian gneiss,some of the oldest rocks found anywhere in the world. The rocky outcrops of the east of Harris are likened to the Moon's surface – indeed, there are rocks within the Harris landscape (anorthosite, a type of feldspar) which are commonly found on the surface of the Moon. And the film-maker Stanley Kubrick used tinted shots of Harris to represent the surface of Jupiter in his creation '2001- A Space Odyssey'.
Footpaths criss-cross the Harris hills and are widely used by walkers, climbers and mountain bike enthusiasts. The crags of Sron Ulladale, above the glen of the same name, offer high-level technical climbing challenges for world-class climbers. There are over 30 routes including a ground-breaking first-ever level E9 climb made by Scotland's greatest living climber Dave Macleod which was broadcast live in August 2010 for the BBC TV programme 'The Big Climb'.
The beaches of Harris are world-famous – from the road between Tarbert and Leverburgh (An-t-Ob in Gaelic) the stunning white sands of Luskentyre, Scarista and Northton can be easily reached. Bounded on one side by the clear waters of the Atlantic, and on the other by the flower meadows of the shelly machair grasslands, these isolated beaches are as wild and beautiful as those of the Carribean.
At the heart of Harris – on the narrow isthmus between the two sea-lochs of East and West Loch Tarbert – sits the small town of Tarbert. The town's name derives from the Norse word 'tairbeart' meaning a portage point where longboats could be dragged for a short distance overland.
Tarbert is also the home of the regular sea ferry to the Isle of Skye. Tarbert has an excellent, modern sports centre and swimming pool, the island's only secondary school, and some small general stores and specialist crafts outlets. Public bus services run regularly across isolated, rugged scenery to Huisinish, Leverburgh, Rhenigadale and Scalpay and to Stornoway in Lewis. At Leverburgh the ferry crosses the Sound of Harris to Berneray and North Uist.
The Golden Road down the east coast of Harris is a single-track tarred road which joins a number of small communities. There is some dispute about why it is called the Golden Road – one eminent local historian suggests that it may not have been as expensive to construct as is widely believed, and the term 'Golden Road' was a pejorative term coined by remote administrators who were unwilling to pay for the cost of any island village to be connected to another. Whatever the meaning of the expression, the name has stuck, and this route provides a golden opportunity to see the real Harris at a slower speed, and to appreciate the real beauty of the island.
Harris has fewer than 2,000 permanent residents, most of whom now live on land owned and managed by community trusts under Scotland's recent land reform legislation. Whilst crofting, fishing and weaving remain significant in Harris, tourism has increased in importance to the economy.
Harris has a fascinating history as a whaling station during the first half of the twentieth century, and there are still traces of the whaling industry to be found. The whaling industry was one of the 'boom-and-bust' maritime activities which have periodically plagued the Hebrides: much like the kelping industry fifty years previously in Lewis. An enormous whaling station was built on Harris in 1904 at Bunabhainneadar and owned and operated by a Norwegian company until 1922, when it was acquired by Lord Leverhulme.
The station operated a whaling fleet, bringing in hundreds of whales each year, mostly Common Rorquals (also known as Fin Whales) and Blue Whales, but also Sperm Whales, Humpback Whales and others. The whale meat was butchered on the slipway in Harris, boiled, dried and re-exported to Norway for use as cattle feed. Leverhulme also started an ill-fated enterprise to produce canned whale meat for export to Africa. In 1925 Leverhulme died and the station stayed open for only another two years. There was a brief attempt in the 1950s to revive the industry, but now all that remains is the ruins of the whaling station just outside Tarbert. Whaling had its impact on society, too: some Hearachs with whale-hunting skills but no place to work, sought opportunities overseas in the whaling industry of South Georgia. The reverse was also true: whaling brought some Norwegian families to stay in the islands and family names such as Iversen and Engebretsen, still well-known in the islands, point to their origins in the whaling fleets.
Other notable buildings include the 16th century medieval-style St. Clement's Church at Rodel, the burial place of the chiefs of the Clan MacLeod from the 8th century. The building is in excellent condition after repeated restoration and now belongs to Historic Scotland. Amhuinsuidhe Castle, on the narrow and spectacular B887 from Huisinish to Tarbert, was designed in the Scottish Baronial style and built in 1867 by the Victorian architect David Bryce. The North Harris Estate upon which it stands is now jointly owned by the community and a private investor, Ian Scarr-Hall, and is run by him as a commercial venue. It was originally built for the 7th Earl of Dunmore and passed through the hands of a number of families, ultimately being owned by the Bulmer family before the community buy-out of the estate in 2003.
The western side of Harris is flatter, lower and less rocky. At Scarista there is a picturesque 9-hole golf course, now with its own isolated clubhouse, where an honesty box is available for players to pay their green fees. The golf course is closed on Sundays.
Off the coast of Harris are numerous small islands, including the most westerly isle of Scarp, which was last inhabited during the 1960s. The Isle of Taransay was briefly (if temporarily) re-inhabited during 2000 for the BBC TV series 'Castaway' and now plays host to an annual fiddle school for traditional music.
The acclaimed movie 'The Rocket Post', a Scottish love story set in the 1930s, was filmed on the Isle of Taransay in 2004, directed by the late Stephen Whitaker, which celebrates the real but failed attempts to use rocket power to transport mail from the Isle of Scarp and other remote islands by the German rocket enthusiast and confidence trickster, Gerhard Zucker. Zucker was eventually deported from Britain as a threat to British national security in 1935, whereupon he was arrested by the German authorities for collaboration with Britain. The scorched mail from the real rocket post experiment on Scarp and elsewhere in 1934 occasionally makes significant prices at auction.
The St Kilda archipelago also falls within the Harris administrative district. This stunning group of five islands, a UNESCO Dual World Heritage Site – lie 41 miles (66 kilometres) west of the Hebridean mainland – and are now owned and maintained by the National Trust for Scotland. With the highest cliffs in the UK at 400 metres, and the highest sea stacs in the UK at 191 metres, St Kilda is one of Europe's most important sites for seabird nesting. The archipelago can now be reached by day-trip boat in the summer months from East Tarbert on Harris and Uig on Lewis.
The story of St Kilda is long and fascinating – occupied for around 4,000 years, the population of the islands suffered extreme hardship and lived mainly on a diet of seabirds, plucked bravely from the cliffs by the agile men of Hirta, the main island. Subsistence farming, and some trade with the outside world kept the population balanced and content until the beginning of the twentieth century when out-migration, ill-health and an awareness of the outside world led to a drastic slump in the population. In 1930, after appeals to a largely disinterested Westminster government, the British public raised money to assist the evacuation of the archipelago. Deprived of their island home and the certainties of their familiar community, many of the remaining 36 St Kildans fared poorly once evacuated to Morven in Argyll.
However, administratively, St. Kilda belongs to Harris, and travellers wanting to be married on Hirta's famous beaches or hills need to apply to the Harris Registrar's Office in Tarbert. A St Kilda interpretive centre has been long-planned and after securing international multi-agency funding the new centre will now be built not on Harris, but in Mangurstadh in the parish of Uig on the west side of Lewis. This decision caused dismay and controversy in Harris.
Scalpay, (Scalpaigh na Hearadh in Gaelic) with a population of just over 300, has been linked to Harris by a spectacular bridge with spans over 170-metres long. A bridge was built rather than a causeway because of the needs of the deep water seagoing channel between the islands. The Scalpay Bridge began construction in 1986 and went into use in 1997, although it was officially opened by Prime Minister Tony Blair in 1998 when he became the first serving UK Premier to carry out an official engagement in the islands. Subsequent major investments in Scalpay, and further community developments have been hailed as a success and attributed to the bridge.
Sunday observance remains strong on Harris, as in Lewis. Although the Sound of Harris ferry runs on Sunday, all other public facilities, fuel stations, restaurants and shops remain closed, with the exception of hotels which provide food and accommodation for travellers. As in Lewis, Sabbath observance is both a matter of pride and controversy.
The Seallam! Visitor centre at Northton in Harris, which opened in 2000, offers a permanent exhibition on 'The People and the Landscape of the Hebrides' and is also a well-known resource centre for genealogical research, and the history of the islands. Bill Lawson, the resident genealogist and celebrated local historian, works from Seallam! to assist visitors who wish to carry out their own ancestral research.
Harris boasts one of the most accessible yet diverse wild environments in the UK – a vast range of birds can be found across the Harris islands. The Shiant Islands and St Kilda are particularly renowned for their seabird colonies - Gannets, Fulmars, Shags, Cormorants, Great Skuas, Arctic Skuas, Kittiwakes, Guillemots, Razorbills, Leach`s Petrels, Storm Petrels and perhaps the most famous occupants of all; Puffins. ??
The bird colonies present on the Harris islands are of tremendous environmental significance - for example, the colony of gannets present on St Kilda is the largest in the world. The puffin population on these islands also represents a very considerable percentage of the world total. There are approximately 300,000 breeding pairs in St Kilda and 200,000 in the Shiants. St. Kilda also has the UK`s largest population of Leach`s Petrels and plays host to the St.Kilda Wren, a rare and larger sub species of the mainland Wren. The Soay sheep which have been on St Kilda for up to 4,000 years, range free in a flock of up to 1,500 across the archipelago. They are a genetically unique rare breed; tiny,all-brown creatures compared with the typical Hebridean Blackface cross. They are hairy rather than woolly and do not need to be shorn.
Deer are prevalent across the Hebrides. On North Harris alone there is a herd of between 1100 and 1400 red deer, managed by the North Harris Estate. There are also opportunities to see mountain hare and otters throughout Harris.
Ten per cent of the European population of Scottish Common Seals live in the sea lochs of the Hebrides – many of these can be seen in and around the Harris coast. There are 24 species of marine mammals in the waters round the Hebrides, and the populations have begun to recover after the hunting of the last century. Two Fin Whales, now very rare in Hebridean waters, were spotted off Harris in September 2010.


text:
M. Thomson
E. Damaggio
B. Raymor, Ed.
Generic Event Delivery Using HTTP Push
This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push.
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 7841.
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/rfc8030.
Copyright © 2016 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.
1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   4
2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
2.1.  HTTP Resources  . . . . . . . . . . . . . . . . . . . . .   7
3.  Connecting to the Push Service  . . . . . . . . . . . . . . .   8
4.  Subscribing for Push Messages . . . . . . . . . . . . . . . .   8
4.1.  Collecting Subscriptions into Sets  . . . . . . . . . . .   9
5.  Requesting Push Message Delivery  . . . . . . . . . . . . . .  10
5.1.  Requesting Push Message Receipts  . . . . . . . . . . . .  10
5.2.  Push Message Time-To-Live . . . . . . . . . . . . . . . .  11
5.3.  Push Message Urgency  . . . . . . . . . . . . . . . . . .  13
5.4.  Replacing Push Messages . . . . . . . . . . . . . . . . .  14
6.  Receiving Push Messages for a Subscription  . . . . . . . . .  15
6.1.  Receiving Push Messages for a Subscription Set  . . . . .  17
6.2.  Acknowledging Push Messages . . . . . . . . . . . . . . .  18
6.3.  Receiving Push Message Receipts . . . . . . . . . . . . .  19
7.  Operational Considerations  . . . . . . . . . . . . . . . . .  20
7.1.  Load Management . . . . . . . . . . . . . . . . . . . . .  20
7.2.  Push Message Expiration . . . . . . . . . . . . . . . . .  20
7.3.  Subscription Expiration . . . . . . . . . . . . . . . . .  21
7.3.1.  Subscription Set Expiration . . . . . . . . . . . . .  21
7.4.  Implications for Application Reliability  . . . . . . . .  22
7.5.  Subscription Sets and Concurrent HTTP/2 Streams . . . . .  22
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
8.1.  Confidentiality from Push Service Access  . . . . . . . .  23
8.2.  Privacy Considerations  . . . . . . . . . . . . . . . . .  23
8.3.  Authorization . . . . . . . . . . . . . . . . . . . . . .  24
8.4.  Denial-of-Service Considerations  . . . . . . . . . . . .  25
8.5.  Logging Risks . . . . . . . . . . . . . . . . . . . . . .  25
9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
9.1.  Header Field Registrations  . . . . . . . . . . . . . . .  26
9.2.  Link Relation URNs  . . . . . . . . . . . . . . . . . . .  26
9.3.  Service Name and Port Number Registration . . . . . . . .  28
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
10.1.  Normative References . . . . . . . . . . . . . . . . . .  28
10.2.  Informative References . . . . . . . . . . . . . . . . .  30
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  31
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31
Many applications on mobile and embedded devices require continuous access to network communications so that real-time events -- such as incoming calls or messages -- can be delivered (or "pushed") in a timely fashion. These devices typically have limited power reserves, so finding more efficient ways to serve application requirements greatly benefits the application ecosystem.
One significant contributor to power usage is the radio. Radio communications consume a significant portion of the energy budget on a wireless device.
Uncoordinated use of persistent connections or sessions from multiple applications can contribute to unnecessary use of the device radio, since each independent session can incur its own overhead. In particular, keep-alive traffic used to ensure that middleboxes do not prematurely time out sessions can result in significant waste. Maintenance traffic tends to dominate over the long term, since events are relatively rare.
Consolidating all real-time events into a single session ensures more efficient use of network and radio resources. A single service consolidates all events, distributing those events to applications as they arrive. This requires just one session, avoiding duplicated overhead costs.
The W3C Push API [API] describes an API that enables the use of a consolidated push service from web applications. This document expands on that work by describing a protocol that can be used to:
request the delivery of a push message to a user agent,
create new push message delivery subscriptions, and
monitor for new push messages.
A standardized method of event delivery is particularly important for the W3C Push API, where application servers might need to use multiple push services. The subscription, management, and monitoring functions are currently fulfilled by proprietary protocols; these are adequate, but do not offer any of the advantages that standardization affords.
This document intentionally does not describe how a push service is discovered. Discovery of push services is left for future efforts, if it turns out to be necessary at all. User agents are expected to be configured with a URL for a push service.
1.1. Conventions and Terminology
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 [RFC2119].
This document defines the following terms:
application:  Both the sender and the ultimate consumer of push
messages.  Many applications have components that are run on a
user agent and other components that run on servers.
application server:  The component of an application that usually
runs on a server and requests the delivery of a push message.
push message subscription:  A message delivery context that is
established between the user agent and the push service, and
shared with the application server.  All push messages are
associated with a push message subscription.
push message subscription set:  A message delivery context that is
established between the user agent and the push service that
collects multiple push message subscriptions into a set.
push message:  A message sent from an application server to a user
agent via a push service.
push message receipt:  A message delivery confirmation sent from the
push service to the application server.
push service:  A service that delivers push messages to user agents.
user agent:  A device and software that is the recipient of push
Examples in this document use the HTTP/1.1 message format [RFC7230]. Many of the exchanges can be completed using HTTP/1.1:
Subscribing for Push Messages (Section 4)
Requesting Push Message Delivery (Section 5)
Replacing Push Messages (Section 5.4)
Acknowledging Push Messages (Section 6.2)
When an example depends on HTTP/2 server push, the more verbose frame format from [RFC7540] is used:
Receiving Push Messages for a Subscription (Section 6)
Receiving Push Messages for a Subscription Set (Section 6.1)
Receiving Push Message Receipts (Section 6.3)
All examples use HTTPS over the default port (443) rather than the registered port (1001). A push service deployment might prefer this configuration to maximize chances for user agents to reach the service. A push service might use HTTP alternative services to redirect a user agent to the registered port (1001) to gain the benefits of the standardized HTTPS port without sacrificing reachability (see Section 3). This would only be apparent in the examples through the inclusion of the Alt-Used header field [RFC7838] in requests from the user agent to the push service.
Examples do not include specific methods for push message encryption or application server authentication because the protocol does not define a mandatory system. The examples in Voluntary Application Server Identification [VAPID] and Message Encryption for WebPush [ENCRYPT] demonstrate the approach adopted by the W3C Push API [API] for its requirements.
A general model for push services includes three basic actors: a user agent, a push service, and an application (server).
+-------+           +--------------+       +-------------+
|  UA   |           | Push Service |       | Application |
+-------+           +--------------+       |   Server    |
|                      |               +-------------+
|      Subscribe       |                      |
|--------------------->|                      |
|       Monitor        |                      |
|<====================>|                      |
|                      |                      |
|          Distribute Push Resource           |
|-------------------------------------------->|
:                      :                      :
|                      |     Push Message     |
|    Push Message      |<---------------------|
|<---------------------|                      |
Figure 1: WebPush Architecture
At the very beginning of the process, a new message subscription is created by the user agent and then distributed to its application server. This subscription is the basis of all future interactions between the actors. A subscription is used by the application server to send messages to the push service for delivery to the user agent. The user agent uses the subscription to monitor the push service for any incoming message.
To offer more control for authorization, a message subscription is modeled as two resources with different capabilities:
A subscription resource is used to receive messages from a subscription and to delete a subscription. It is private to the user agent.
A push resource is used to send messages to a subscription. It is public and shared by the user agent with its application server.
It is expected that a unique subscription will be distributed to each application; however, there are no inherent cardinality constraints in the protocol. Multiple subscriptions might be created for the same application, or multiple applications could use the same subscription. Note, however, that sharing subscriptions has security and privacy implications.
Subscriptions have a limited lifetime. They can also be terminated by either the push service or the user agent at any time. User agents and application servers must be prepared to manage changes in the subscription state.
2.1. HTTP Resources
This protocol uses HTTP resources [RFC7230] and link relations [RFC5988]. The following resources are defined:
push service:  This resource is used to create push message
subscriptions (Section 4).  A URL for the push service is
configured into user agents.
push message subscription:  This resource provides read and delete
access for a message subscription.  A user agent receives push
messages (Section 6) using a push message subscription.  Every
push message subscription has exactly one push resource associated
with it.
push message subscription set:  This resource provides read and
delete access for a collection of push message subscriptions.  A
user agent receives push messages (Section 6.1) for all the push
message subscriptions in the set.  A link relation of type
"urn:ietf:params:push:set" identifies a push message subscription
push:  An application server requests the delivery (Section 5) of a
push message using a push resource.  A link relation of type
"urn:ietf:params:push" identifies a push resource.
push message:  The push service creates a push message resource to
identify push messages that have been accepted for delivery
(Section 5).  The push message resource is also deleted by the
user agent to acknowledge receipt (Section 6.2) of a push message.
receipt subscription:  An application server receives delivery
confirmations (Section 5.1) for push messages using a receipt
subscription.  A link relation of type
"urn:ietf:params:push:receipt" identifies a receipt subscription.
3. Connecting to the Push Service
The push service MUST use HTTP over Transport Layer Security (TLS) [RFC2818] following the recommendations in [RFC7525]. The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA-allocated TCP System Port (1001) using HTTP alternative services [RFC7838].
While the default port (443) offers broad reachability characteristics, it is most often used for web-browsing scenarios with a lower idle timeout than other ports configured in middleboxes. For WebPush scenarios, this would contribute to unnecessary radio communications to maintain the connection on battery-powered devices.
Advertising the alternate port (1001) allows middleboxes to optimize idle timeouts for connections specific to push scenarios with the expectation that data exchange will be infrequent.
Middleboxes SHOULD comply with REQ-5 in [RFC5382], which states that "the value of the 'established connection idle-timeout' MUST NOT be less than 2 hours 4 minutes".
4. Subscribing for Push Messages
A user agent sends a POST request to its configured push service resource to create a new subscription.
POST /subscribe HTTP/1.1
Host: push.example.net
A 201 (Created) response indicates that the push subscription was created. A URI for the push message subscription resource that was created in response to the request MUST be returned in the Location header field.
The push service MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push".
An application-specific method is used to distribute the push URI to the application server. Confidentiality protection and application server authentication MUST be used to ensure that this URI is not disclosed to unauthorized recipients (Section 8.3).
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
rel="urn:ietf:params:push"
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
Location: https://push.example.net/subscription/LBhhw0OohO-Wl4Oi971UG
4.1. Collecting Subscriptions into Sets
Collecting multiple push message subscriptions into a subscription set can represent a significant efficiency improvement for push services and user agents. The push service MAY provide a URI for a subscription set resource in a link relation of type "urn:ietf:params:push:set".
When a subscription set is returned in a push message subscription response, the user agent SHOULD include this subscription set in a link relation of type "urn:ietf:params:push:set" in subsequent requests to create new push message subscriptions.
A user agent MAY omit the subscription set if it is unable to receive push messages in an aggregated way for the lifetime of the subscription. This might be necessary if the user agent is monitoring subscriptions on behalf of other push message receivers.
The push service SHOULD return the same subscription set in its response, although it MAY return a new subscription set if it is unable to reuse the one provided by the user agent.
Link: </push/YBJNBIMwwA_Ag8EtD47J4A>;
Location: https://push.example.net/subscription/i-nQ3A9Zm4kgSWg8_ZijV
A push service MUST return a 400 (Bad Request) status code for requests that contain an invalid subscription set. A push service MAY return a 429 (Too Many Requests) status code [RFC6585] to reject requests that omit a subscription set.
How a push service detects that requests originate from the same user agent is implementation-specific but could take ambient information into consideration, such as the TLS connection, source IP address, and port. Implementers are reminded that some heuristics can produce false positives and hence, cause requests to be rejected incorrectly.
5. Requesting Push Message Delivery
An application server requests the delivery of a push message by sending an HTTP POST request to a push resource distributed to the application server by a user agent. The content of the push message is included in the body of the request.
POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Content-Type: text/plain;charset=utf8
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
A 201 (Created) response indicates that the push message was accepted. A URI for the push message resource that was created in response to the request MUST be returned in the Location header field. This does not indicate that the message was delivered to the user agent.
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
5.1. Requesting Push Message Receipts
An application server can include the Prefer header field [RFC7240] with the "respond-async" preference to request confirmation from the push service when a push message is delivered and then acknowledged by the user agent. The push service MUST support delivery confirmations.
Prefer: respond-async
When the push service accepts the message for delivery with confirmation, it MUST return a 202 (Accepted) response. A URI for the push message resource that was created in response to the request MUST be returned in the Location header field. The push service MUST also provide a URI for the receipt subscription resource in a link relation of type "urn:ietf:params:push:receipt".
HTTP/1.1 202 Accepted
Link: </receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
rel="urn:ietf:params:push:receipt"
For subsequent receipt requests to the same origin [RFC6454], the application server SHOULD include the returned receipt subscription in a link relation of type "urn:ietf:params:push:receipt". This gives the push service the option to aggregate the receipts. The push service SHOULD return the same receipt subscription in its response, although it MAY return a new receipt subscription if it is unable to reuse the one provided by the application server.
An application server MAY omit the receipt subscription if it is unable to receive receipts in an aggregated way for the lifetime of the receipt subscription. This might be necessary if the application server is monitoring receipt subscriptions on behalf of the other push message senders.
A push service MUST return a 400 (Bad Request) status code for requests that contain an invalid receipt subscription. If a push service wishes to limit the number of receipt subscriptions that it maintains, it MAY return a 429 (Too Many Requests) status code [RFC6585] to reject receipt requests that omit a receipt subscription.
5.2. Push Message Time-To-Live
A push service can improve the reliability of push message delivery considerably by storing push messages for a period. User agents are often only intermittently connected, and so benefit from having short-term message storage at the push service.
Delaying delivery might also be used to batch communication with the user agent, thereby conserving radio resources.
Some push messages are not useful once a certain period of time elapses. Delivery of messages after they have ceased to be relevant is wasteful. For example, if the push message contains a call notification, receiving a message after the caller has abandoned the call is of no value; the application at the user agent is forced to suppress the message so that it does not generate a useless alert.
An application server MUST include the TTL (Time-To-Live) header field in its request for push message delivery. The TTL header field contains a value in seconds that suggests how long a push message is retained by the push service.
The TTL rule specifies a non-negative integer, representing time in seconds. A recipient parsing and converting a TTL value to binary form SHOULD use an arithmetic type of at least 31 bits of non- negative integer range. If a recipient receives a TTL value greater than the greatest integer it can represent, or if any of its subsequent calculations overflows, it MUST consider the value to be 2147483648 (2^31).
TTL = 1*DIGIT
A push service MUST return a 400 (Bad Request) status code in response to requests that omit the TTL header field.
A push service MAY retain a push message for a shorter duration than requested. It indicates this by returning a TTL header field in its response with the actual TTL. This TTL value MUST be less than or equal to the value provided by the application server.
Once the TTL period elapses, the push service MUST NOT attempt to deliver the push message to the user agent. A push service might adjust the TTL value to account for time accounting errors in processing. For instance, distributing a push message within a server cluster might accrue errors due to clock skew or propagation delays.
A push service is not obligated to account for time spent by the application server in sending a push message to the push service, or delays incurred while sending a push message to the user agent. An application server needs to account for transit delays in selecting a TTL header field value.
A Push message with a zero TTL is immediately delivered if the user agent is available to receive the message. After delivery, the push service is permitted to immediately remove a push message with a zero TTL. This might occur before the user agent acknowledges receipt of the message by performing an HTTP DELETE on the push message resource. Consequently, an application server cannot rely on receiving acknowledgement receipts for zero TTL push messages.
If the user agent is unavailable, a push message with a zero TTL expires and is never delivered.
5.3. Push Message Urgency
For a device that is battery-powered, it is often critical that it remains dormant for extended periods. Radio communication in particular consumes significant power and limits the length of time that the device can operate.
To avoid consuming resources to receive trivial messages, it is helpful if an application server can communicate the urgency of a message and if the user agent can request that the push server only forwards messages of a specific urgency.
An application server MAY include an Urgency header field in its request for push message delivery. This header field indicates the message urgency. The push service MUST NOT forward the Urgency header field to the user agent. A push message without the Urgency header field defaults to a value of "normal".
A user agent MAY include the Urgency header field when monitoring for push messages to indicate the lowest urgency of push messages that it is willing to receive. A push service MUST NOT deliver push messages with lower urgency than the value indicated by the user agent in its monitoring request. Push messages of any urgency are delivered to a user agent that does not include an Urgency header field when monitoring for messages.
The grammar for the Urgency header field is as follows:
Urgency = urgency-option
urgency-option = ("very-low" / "low" / "normal" / "high")
In order of increasing urgency:
+----------+-----------------------------+--------------------------+
| Urgency  | Device State                | Example Application      |
|          |                             | Scenario                 |
| very-low | On power and Wi-Fi          | Advertisements           |
| low      | On either power or Wi-Fi    | Topic updates            |
| normal   | On neither power nor Wi-Fi  | Chat or Calendar Message |
| high     | Low battery                 | Incoming phone call or   |
|          |                             | time-sensitive alert     |
Table 1: Illustrative Urgency Values
Multiple values for the Urgency header field MUST NOT be included in requests; otherwise, the push service MUST return a 400 (Bad Request) status code.
5.4. Replacing Push Messages
A push message that has been stored by the push service can be replaced with new content. If the user agent is offline during the time that the push messages are sent, updating a push message avoids the situation where outdated or redundant messages are sent to the user agent.
Only push messages that have been assigned a topic can be replaced. A push message with a topic replaces any outstanding push message with an identical topic.
A push message topic is a string carried in a Topic header field. A topic is used to correlate push messages sent to the same subscription and does not convey any other semantics.
The grammar for the Topic header field uses the "token" rule defined in [RFC7230].
Topic = token
For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL and a filename-safe Base 64 alphabet [RFC4648]. A push service that receives a request with a Topic header field that does not meet these constraints MUST return a 400 (Bad Request) status code to the application server.
A push message replacement request creates a new push message resource and simultaneously deletes any existing message resource that has a matching topic. If an attempt was made to deliver the deleted push message, an acknowledgment could arrive at the push service after the push message has been replaced. Delivery receipts for such deleted messages SHOULD be suppressed.
The replacement request also replaces the stored TTL, Urgency, and any receipt subscription associated with the previous message in the matching topic.
A push message with a topic that is not shared by an outstanding message to the same subscription is stored or delivered as normal.
For example, the following message could cause an existing message to be replaced:
TTL: 600
Topic: upd
ZuHSZPKa2b1jtOKLGpWrcrn8cNqt0iVQyroF
If the push service identifies an outstanding push message with a topic of "upd", then that message resource is deleted. A 201 (Created) response indicates that the push message replacement was accepted. A URI for the new push message resource that was created in response to the request is included in the Location header field.
The value of the Topic header field MUST NOT be forwarded to user agents. Its value is neither encrypted nor authenticated.
6. Receiving Push Messages for a Subscription
A user agent requests the delivery of new push messages by making a GET request to a push message subscription resource. The push service does not respond to this request; instead, it uses HTTP/2 server push [RFC7540] to send the contents of push messages as they are sent by application servers.
A user agent MAY include an Urgency header field in its request. The push service MUST NOT deliver messages with lower urgency than the value of the header field as defined in Table 1 (Illustrative Urgency Values).
Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE. This GET request is made to the push message resource that was created by the push service when the application server requested message delivery. The response headers SHOULD provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push". The response body is the entity body from the most recent request sent to the push resource by the application server.
The following example request is made over HTTP/2:
HEADERS      [stream 7] +END_STREAM +END_HEADERS
:method        = GET
:path          = /subscription/LBhhw0OohO-Wl4Oi971UG
:authority     = push.example.net
The push service permits the request to remain outstanding. When a push message is sent by an application server, a server push is generated in association with the initial request. The response for the server push includes the push message.
PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS
:path          = /message/qDIYHNcfAIPP_5ITvURr-d6BGt
HEADERS      [stream 4] +END_HEADERS
:status        = 200
date           = Thu, 11 Dec 2014 23:56:56 GMT
last-modified  = Thu, 11 Dec 2014 23:56:55 GMT
cache-control  = private
link           = </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
content-type   = text/plain;charset=utf8
content-length = 36
DATA         [stream 4] +END_STREAM
A user agent can also request the contents of the push message subscription resource immediately by including a Prefer header field [RFC7240] with a "wait" preference set to "0". In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered.
A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available. This could be because push messages have expired.
6.1. Receiving Push Messages for a Subscription Set
There are minor differences between receiving push messages for a subscription and a subscription set. If a subscription set is available, the user agent SHOULD use the subscription set to monitor for push messages rather than individual push message subscriptions.
A user agent requests the delivery of new push messages for a collection of push message subscriptions by making a GET request to a push message subscription set resource. The push service does not respond to this request; instead, it uses HTTP/2 server push [RFC7540] to send the contents of push messages as they are sent by application servers.
Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE. This GET request is made to the push message resource that was created by the push service when the application server requested message delivery. The synthetic request MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push". This enables the user agent to differentiate the source of the message. The response body is the entity body from the most recent request sent to the push resource by an application server.
The following example request is made over HTTP/2.
:path          = /subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy
The push service permits the request to remain outstanding. When a push message is sent by an application server, a server push is generated in association with the initial request. The server push's response includes the push message.
A user agent can request the contents of the push message subscription set resource immediately by including a Prefer header field [RFC7240] with a "wait" preference set to "0". In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered.
6.2. Acknowledging Push Messages
To ensure that a push message is properly delivered to the user agent at least once, the user agent MUST acknowledge receipt of the message by performing an HTTP DELETE on the push message resource.
DELETE /message/qDIYHNcfAIPP_5ITvURr-d6BGt HTTP/1.1
If the push service receives the acknowledgement and the application has requested a delivery receipt, the push service MUST return a 204 (No Content) response to the application server monitoring the receipt subscription.
If the push service does not receive the acknowledgement within a reasonable amount of time, then the message is considered to be not yet delivered. The push service SHOULD continue to retry delivery of the message until its advertised expiration.
The push service MAY cease to retry delivery of the message prior to its advertised expiration due to scenarios such as an unresponsive user agent or operational constraints. If the application has requested a delivery receipt, then the push service MUST return a 410 (Gone) response to the application server monitoring the receipt subscription.
6.3. Receiving Push Message Receipts
The application server requests the delivery of receipts from the push service by making an HTTP GET request to the receipt subscription resource. The push service does not respond to this request; instead, it uses HTTP/2 server push [RFC7540] to send push receipts when messages are acknowledged (Section 6.2) by the user agent.
Each receipt is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE. This GET request is made to the same push message resource that was created by the push service when the application server requested message delivery. The response includes a status code indicating the result of the message delivery and carries no data.
HEADERS      [stream 13] +END_STREAM +END_HEADERS
:path          = /receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM
The push service permits the request to remain outstanding. When the user agent acknowledges the message, the push service pushes a delivery receipt to the application server. A 204 (No Content) status code confirms that the message was delivered and acknowledged.
PUSH_PROMISE [stream 13; promised stream 82] +END_HEADERS
HEADERS      [stream 82] +END_STREAM
+END_HEADERS
If the user agent fails to acknowledge the receipt of the push message and the push service ceases to retry delivery of the message prior to its advertised expiration, then the push service MUST push a failure response with a status code of 410 (Gone).
7. Operational Considerations
7.1. Load Management
A push service is likely to have to maintain a very large number of open TCP connections. Effective management of those connections can depend on being able to move connections between server instances.
A user agent MUST support the 307 (Temporary Redirect) status code [RFC7231], which can be used by a push service to redistribute load at the time that a new subscription is requested.
A server that wishes to redistribute load can do so using HTTP alternative services [RFC7838]. HTTP alternative services allows for redistribution of load while maintaining the same URIs for various resources. A user agent can ensure a graceful transition by using the GOAWAY frame once it has established a replacement connection.
7.2. Push Message Expiration
Storage of push messages based on the TTL header field comprises a potentially significant amount of storage for a push service. A push service is not obligated to store messages indefinitely. A push service is able to indicate how long it intends to retain a message to an application server using the TTL header field (Section 5.2).
A user agent that does not actively monitor for push messages will not receive messages that expire during that interval.
Push messages that are stored and have not been delivered to a user agent are delivered when the user agent recommences monitoring. Stored push messages SHOULD include a Last-Modified header field (Section 2.2 of [RFC7232]) indicating when delivery was requested by an application server.
A GET request to a push message subscription resource with only expired messages results in a response as though no push message was ever sent.
Push services might need to limit the size and number of stored push messages to avoid overloading. To limit the size of messages, the push service MAY return a 413 (Payload Too Large) status code [RFC7231] in response to requests that include an entity body that is too large. Push services MUST NOT return a 413 status code in responses to an entity body that is 4096 bytes or less in size.
To limit the number of stored push messages, the push service MAY respond with a shorter Time-To-Live than proposed by the application server in its request for push message delivery (Section 5.2). Once a message has been accepted, the push service MAY later expire the message prior to its advertised Time-To-Live. If the application server requested a delivery receipt, the push service MUST return a failure response (Section 6.2).
7.3. Subscription Expiration
In some cases, it may be necessary to terminate subscriptions so that they can be refreshed. This applies to both push message subscriptions and receipt subscriptions.
A push service MAY expire a subscription at any time. If there are outstanding requests to an expired push message subscription resource (Section 6) from a user agent or to an expired receipt subscription resource (Section 6.3) from an application server, this MUST be signaled by returning a 404 (Not Found) status code.
A push service MUST return a 404 (Not Found) status code if an application server attempts to send a push message to an expired push message subscription.
A user agent can remove its push message subscription by sending a DELETE request to the corresponding URI. An application server can remove its receipt subscription by sending a DELETE request to the corresponding URI.
7.3.1. Subscription Set Expiration
A push service MAY expire a subscription set at any time and MUST also expire all push message subscriptions in the set. If a user agent has an outstanding request to a push subscription set (Section 6.1), this MUST be signaled by returning a 404 (Not Found) status code.
A user agent can request that a subscription set be removed by sending a DELETE request to the subscription set URI. This MUST also remove all push message subscriptions in the set.
If a specific push message subscription that is a member of a subscription set is expired or removed, then it MUST also be removed from its subscription set.
7.4. Implications for Application Reliability
A push service that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application server, incurring additional power drain in order to establish and maintain (usually secure) connections to the individual application servers.
Push message reliability can be important if messages contain information critical to the state of an application. Repairing the state can be expensive, particularly for devices with limited communications capacity. Knowing that a push message has been correctly received avoids retransmissions, polling, and state resynchronization.
The availability of push message delivery receipts ensures that the application developer is not tempted to create alternative mechanisms for message delivery in case the push service fails to deliver a critical message. Setting up a polling mechanism or a backup messaging channel in order to compensate for these shortcomings negates almost all of the advantages a push service provides.
However, reliability might not be necessary for messages that are transient (e.g., an incoming call) or messages that are quickly superseded (e.g., the current number of unread emails).
7.5. Subscription Sets and Concurrent HTTP/2 Streams
If the push service requires that the user agent use push message subscription sets, then it MAY limit the number of concurrently active streams with the SETTINGS_MAX_CONCURRENT_STREAMS parameter within an HTTP/2 SETTINGS frame [RFC7540]. The user agent MAY be limited to one concurrent stream to manage push message subscriptions and one concurrent stream for each subscription set returned by the push service. This could force the user agent to serialize subscription requests to the push service.
This protocol MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525]. This includes any communications between the user agent and the push service, plus communications between the application server and the push service. All URIs therefore use the "https" scheme. This provides confidentiality and integrity protection for subscriptions and push messages from external parties.
8.1. Confidentiality from Push Service Access
The protection afforded by TLS does not protect content from the push service. Without additional safeguards, a push service can inspect and modify the message content.
Applications using this protocol MUST use mechanisms that provide end-to-end confidentiality, integrity, and data origin authentication. The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context. The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement.
For this requirement, the W3C Push API [API] has adopted Message Encryption for WebPush [ENCRYPT] to secure the content of messages from the push service. Other scenarios can be addressed by similar policies.
The Topic header field exposes information that allows more granular correlation of push messages on the same subject. This might be used to aid traffic analysis of push messages by the push service.
8.2. Privacy Considerations
Push message confidentiality does not ensure that the identity of who is communicating and when they are communicating is protected. However, the amount of information that is exposed can be limited.
The URIs provided for push resources MUST NOT provide any basis to correlate communications for a given user agent. It MUST NOT be possible to correlate any two push resource URIs based solely on their contents. This allows a user agent to control correlation across different applications or over time. Of course, this does not prevent correlation using other information that a user agent might expose.
Similarly, the URIs provided by the push service to identify a push message MUST NOT provide any information that allows for correlation across subscriptions. Push message URIs for the same subscription MAY contain information that would allow correlation with the associated subscription or other push messages for that subscription.
User and device information MUST NOT be exposed through a push or push message URI.
In addition, push URIs established by the same user agent or push message URIs for the same subscription MUST NOT include any information that allows them to be correlated with the user agent.
Note:  This need not be perfect as long as the resulting anonymity
set ([RFC6973], Section 6.1.1) is sufficiently large.  A push URI
necessarily identifies a push service or a single server instance.
It is also possible that traffic analysis could be used to
correlate subscriptions.
A user agent MUST be able to create new subscriptions with new identifiers at any time.
8.3. Authorization
This protocol does not define how a push service establishes whether a user agent is permitted to create a subscription, or whether push messages can be delivered to the user agent. A push service MAY choose to authorize requests based on any HTTP-compatible authorization method available, of which there are multiple options (including experimental options) with varying levels of security. The authorization process and any associated credentials are expected to be configured in the user agent along with the URI for the push service.
Authorization is managed using capability URLs for the push message subscription, push, and receipt subscription resources ([CAP-URI]). A capability URL grants access to a resource based solely on knowledge of the URL.
Capability URLs are used for their "easy onward sharing" and "easy client API" properties. These properties make it possible to avoid relying on prearranged relationships or additional protocols between push services and application servers.
Capability URLs act as bearer tokens. Knowledge of a push message subscription URI implies authorization to either receive push messages or delete the subscription. Knowledge of a push URI implies authorization to send push messages. Knowledge of a push message URI allows for reading and acknowledging that specific message. Knowledge of a receipt subscription URI implies authorization to receive push receipts.
Encoding a large amount of random entropy (at least 120 bits) in the path component ensures that it is difficult to successfully guess a valid capability URL.
8.4. Denial-of-Service Considerations
A user agent can control where valid push messages originate by limiting the distribution of push URIs to authorized application servers. Ensuring that push URIs are hard to guess ensures that only application servers that have received a push URI can use it.
Push messages that are not successfully authenticated by the user agent will not be delivered, but this can present a denial-of-service risk. Even a relatively small volume of push messages can cause battery-powered devices to exhaust power reserves.
To address this case, the W3C Push API [API] has adopted Voluntary Application Server Identification [VAPID], which allows a user agent to restrict a subscription to a specific application server. The push service can then identify and reject unwanted messages without contacting the user agent.
A malicious application with a valid push URI could use the greater resources of a push service to mount a denial-of-service attack on a user agent. Push services SHOULD limit the rate at which push messages are sent to individual user agents.
A push service MAY return a 429 (Too Many Requests) status code [RFC6585] when an application server has exceeded its rate limit for push message delivery to a push resource. The push service SHOULD also include a Retry-After header [RFC7231] to indicate how long the application server is requested to wait before it makes another request to the push resource.
A push service or user agent MAY also terminate subscriptions (Section 7.3) that receive too many push messages.
A push service is also able to deny service to user agents. Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in user agent availability, or genuine service outages.
8.5. Logging Risks
Server request logs can reveal subscription-related URIs or relationships between subscription-related URIs for the same user agent. Limitations on log retention and strong access control mechanisms can ensure that URIs are not revealed to unauthorized entities.
This protocol defines new HTTP header fields in Section 9.1. New link relation types are identified using the URNs defined in Section 9.2. Port registration is defined in Section 9.3
9.1. Header Field Registrations
HTTP header fields are registered within the "Message Headers"
registry maintained at <https://www.iana.org/assignments/message-
headers/>.
This document defines the following HTTP header fields, and the following entries have been added to the "Permanent Message Header Field Names" registry ([RFC3864]):
+-------------------+----------+----------+--------------+
| Header Field Name | Protocol | Status   | Reference    |
| TTL               | http     | standard | Section 5.2  |
| Urgency           | http     | standard | Section 5.3  |
| Topic             | http     | standard | Section 5.4  |
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
9.2. Link Relation URNs
This document registers URNs for use in identifying link relation types. These have been added to a new "Web Push Identifiers" registry according to the procedures in Section 4 of [RFC3553]; the corresponding "push" sub-namespace has been entered in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry.
The "Web Push Identifiers" registry operates under the IETF Review policy [RFC5226].
Registry name:  Web Push Identifiers
URN Prefix:  urn:ietf:params:push
Specification:  RFC 8030 (this document)
Repository:  http://www.iana.org/assignments/webpush-parameters/
Index Value:  Values in this registry are URNs or URN prefixes that
start with the prefix "urn:ietf:params:push".  Each is registered
independently.
Registrations in the "Web Push Identifiers" registry include the following information:
URN:  A complete URN or URN prefix.
Description:  A summary description.
Contact:  Email for the person or group making the registration.
Index Value:  As described in [RFC3553]
Reference:  A reference to a specification describing the semantics
of the URN or URN prefix.
URN prefixes that are registered include a description of how the URN is constructed. This is not applicable for specific URNs.
These values are entered as the initial content of the "Web Push Identifiers" registry.
URN:  urn:ietf:params:push
Description:  This link relation type is used to identify a resource
for sending push messages.
Contact:  The WEBPUSH WG of the IETF (webpush@ietf.org)
Reference:  RFC 8030 (this document)
URN:  urn:ietf:params:push:set
Description:  This link relation type is used to identify a
collection of push message subscriptions.
URN:  urn:ietf:params:push:receipt
for receiving delivery confirmations for push messages.
9.3. Service Name and Port Number Registration
Service names and port numbers are registered within the "Service
Name and Transport Protocol Port Number Registry" maintained at
<https://www.iana.org/assignments/service-names-port-numbers/>.
In accordance with [RFC6335], IANA has assigned the System Port number 1001 and the service name "webpush".
Service Name:
Port Number:
Transport Protocol:
HTTP Web Push
The IESG (iesg@ietf.org)
The IETF Chair (chair@ietf.org)
RFC 8030 (this document)
[CAP-URI]  Tennison, J., "Good Practices for Capability URLs", W3C
First Public Working Draft capability-urls, February 2014,
<http://www.w3.org/TR/capability-urls/>.
[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
[RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <http://www.rfc-editor.org/info/rfc3553>.
[RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004,
[RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
[RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, October 2008,
[RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
[RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
[RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
[RFC6585]  Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
[RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
[RFC7240]  Snell, J., "Prefer Header for HTTP", RFC 7240,
[RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
[RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
[RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <http://www.rfc-editor.org/info/rfc7838>.
[API]      Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan,
B., and E. Fullea, "Push API", W3C Editor's Draft push-
api, November 2016, <https://w3c.github.io/push-api/>.
[ENCRYPT]  Thomson, M., "Message Encryption for Web Push", Work in
Progress, draft-ietf-webpush-encryption-06, October 2016.
[RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
[VAPID]    Thomson, M. and P. Beverloo, "Voluntary Application Server
Identification for Web Push", Work in Progress,
draft-ietf-webpush-vapid-01, June 2016.
Significant technical input to this document has been provided by Ben Bangert, Peter Beverloo, Kit Cambridge, JR Conlin, Lucas Jenss, Matthew Kaufman, Costin Manolache, Mark Nottingham, Idel Pivnitskiy, Robert Sparks, Darshak Thakore, and many others.
Martin Thomson
331 E Evelyn Street
Mountain View, CA  94041
Email: martin.thomson@gmail.com
Elio Damaggio
Redmond, WA  98052
elioda@microsoft.com
Brian Raymor (editor)
Email: brian.raymor@microsoft.com
RFC 3553 (BCP 73)

redpajama_set_name: RedPajamaCommonCrawl


text:
Michel Barnier is widely believed to harbor a burning ambition for the EU's top post | Olivier Hoslet/EPA
Why Barnier is Britain's best friend in Brussels
The Frenchman's bigger ambition is the Commission presidency in 2 years — and he can't get it without a success in the Brexit talks.
By	David M. Herszenhorn and Maïa de La Baume
9/6/17, 4:05 AM CET
Updated 9/11/17, 7:58 AM CET
Britain's favorite Brussels punching bag may be its best shot at a Brexit deal.
As withdrawal talks took a tense turn in recent days, Michel Barnier, the EU's dapper French negotiator, has been called silly, arrogant and inflexible in the U.K., even a "smackhead begging for his next hit of our money" by one pro-Leave group.
Among EU insiders, however, the vilification of Barnier by British officials and media is just the latest example of what they view as a clueless approach by the U.K, and a failure to accurately read the political landscape across the Channel.
A two-time European commissioner who served in multiple ministerial posts in the French government and made an unsuccessful bid for Commission president in 2014, Barnier is widely believed to harbor a burning ambition for the EU's top post.
To have virtually any chance of replacing Jean-Claude Juncker when his term ends in 2019, supporters of Barnier said, he must successfully deliver a withdrawal agreement. That gives Barnier personal incentive to seal a deal with London, they said, while many of his potential rivals stand to gain more from tough talk and a willingness to push the U.K. off the cliff.
"His dream has always been to be president of the Commission, and that dream was broken in 2014," said Alain Lamassoure, a veteran French MEP and longtime colleague and acquaintance of Barnier's.
In 2014, Juncker and Barnier were rivals for the EPP nomination | Paulo Cunha/EPA
"He doesn't have prime ministerial experience to be Council president, but if he succeeds in the Brexit negotiations, he can make his dream come true," added Lamassoure, who is part of the same conservative European People's Party (EPP) political family as Barnier. "The calendar coincides perfectly. He will have finished in two years. And if he has done these negotiations brilliantly, he will be a candidate."
Tajani: Brexit phase 1 might not be over till Christmas
Giulia Paravicini and Jacopo Barigazzi
David Davis: No deal worse for some EU countries than for UK
Charlie Cooper
Michel Barnier: 'No decisive progress' on key Brexit issues
David M. Herszenhorn
To be sure, Brussels is a political fish bowl, full of fast swimmers and loose lips, and the speculation about Barnier's motivations — beyond the customary desire to succeed in his current mission — may be of even less significance to the Brexit talks than the constant speculation about U.K. Prime Minister Theresa May's grip on the Conservative Party.
Nonetheless, with Juncker insisting he will step down when his term ends in two years, Europe's capital is abuzz with various scenarios that would catapult Barnier into the presidential suite of the Berlaymont — perhaps with his deputy negotiator, Sabine Weyand, as cabinet chief, in an embodiment of the renewed Franco-German power nexus.
Provided the negotiations don't implode, Barnier would be well-positioned to reach for his dream.
Others speculate that a more likely cabinet chief would be Olivier Guersent, currently the Commission's director general for financial stability, financial services and capital markets union, who was Barnier's chief of staff when he was a commissioner from 2010 to 2014. Barnier's interest in the presidency, however, is generally regarded by colleagues and friends as an open secret.
That puts the Brexit negotiator's ambitions on a par with his U.K. counterpart David Davis: The Brexit secretary is the favorite among Conservatives to succeed May as Tory leader if she were forced out, according to opinion polls.
In 2014, Juncker and Barnier were rivals for the EPP nomination, with Juncker, a former 19-year prime minister of Luxembourg, winning that contest by a vote among party delegates of 382 to 245.
But 62-year-old Juncker and 66-year-old Barnier are political soulmates — committed euro-integrationists, long-time colleagues and mutual admirers. Early in his term, Juncker appointed Barnier as a special adviser on defense and security policy, and it was Juncker who personally tapped Barnier as the EU's chief Brexit negotiator, just a month after the U.K. voted to leave the bloc in June 2016.
Juncker (left) and Barnier (right) are political soulmates | Patrick Seeger/EPA
Provided the negotiations don't implode, Barnier would be well-positioned to reach for his dream.
The Brexit job has raised Barnier's profile higher than perhaps any EU official who has not served in a presidential capacity, and his name-recognition among the general public is undoubtedly stronger than many current EU heads of state and government.
In preparation for the negotiations, and in seeking to sustain unity among the EU27, Barnier has visited all of the EU capitals. And, apparently unprecedented for an EU negotiator, he has a standing invitation to attend European Council summits to update leaders directly on his progress.
He is also in nearly constant consultation with the European Parliament, which technically still formally elects the Commission president based on a nomination from the Council. (In practice, EU leaders have agreed since 2014 to select the nominee, or Spitzenkandidat, of the political party group that wins a plurality in the European parliamentary elections.)
'Premature'
From London's perspective, Barnier's ambition may not help much.
While it gives him incentive to achieve a Brexit deal, it also creates an imperative for him to deliver an agreement viewed as favorable to the EU27, not Britain. So while he may be less inclined than others in Brussels to see the U.K. expelled from the bloc without a safety net, he is still constrained by the Council's negotiating directives — a fact that has drawn complaints from Davis and others demanding more flexibility from the EU side.
A U.K. government official said Barnier was "an often reasonable guy who had found himself in an unreasonable situation."
Asked about Barnier's future, an EU source close to him said: "Mr. Barnier is fully engaged in the Brexit negotiations as the European Commission's chief negotiator and, as he has said himself before, he is conducting these negotiations in a calm and constructive spirit. His aim is to reach a deal with the United Kingdom."
The source stressed that the parameters of the talks were set by the negotiating directives put forward by the Commission and formally adopted by the 27 leaders in the European Council, with input from the Parliament, which must approve any final withdrawal agreement with the U.K.
"As the European Commission's chief negotiator, Michel Barnier strictly follows the mandate that the heads of state or government have defined unanimously, and he fully takes into account the European Parliament's resolution," the source said.
Premature or not, party groups are already looking ahead to 2019 and how they will organize the process of choosing their Spitzenkandidat.
In a statement, Margaritis Schinas, the Commission's chief spokesperson, dismissed any talk about Barnier's future as "gossip."
"President Juncker appointed M. Barnier to this important assignment for well-known reasons (see here)," Schinas said. "For the rest, we have lots of work ahead and no time for gossip."
Another senior Commission official, speaking on condition of anonymity, said it was too soon to speculate. "We are not there yet," this official said. "The question of the next European Commission president is far, very far. Any casting would be very premature."
Premature or not, party groups are already looking ahead to 2019 and how they will organize the process of choosing their Spitzenkandidat. And there are numerous potential obstacles for Barnier, beyond a disastrous outcome in the Brexit talks.
Perhaps first and foremost is the likelihood that he will face a challenge within the EPP, currently Europe's most influential political family, including potentially from some popular officials who have experience as prime minister or president, like Jyrki Katainen, the former prime minister of Finland and current European commissioner for jobs, growth and competitiveness.
European Commissioner for Jobs, Growth, Investment and Competitiveness Jyrki Katainen | Bart Maat/AFP via Getty Images
One factor that could work in Barnier's favor is that French President Emmanuel Macron is said to covet one of the top EU presidencies for France, though it is tough to predict the broader machinations that could drive the outcome in 2019. Macron, a former Socialist turned independent, has not said if his new party, La République En Marche, will run in the European elections, and, if so, if he will ally with one of the existing political families.
And while Macron shares Barnier's pro-EU philosophy and outlook, his leverage in negotiations over EU leadership positions will depend on numerous other factors, including the objectives of other leaders like German Chancellor Angela Merkel, who ultimately must agree on how to fill top jobs at the Commission, Council, Parliament and European Central Bank.
Still, in and around Brussels' European Quarter, the view is that if Barnier manages to pull off a Brexit deal that reflects EU priorities and maintains the unity of the 27, he will have a solid platform for a campaign.
"I think his ambition is recent," one former EU official said. "It's not a childhood dream. It wasn't a plan. His conviction in European values is absolutely authentic."
Quentin Ariès contributed to this article.
Alain Lamassoure
David Davis MP
Sabine Weyand
Sajid Javid urges companies to 'adjust' to new reality.
France's EU minister: Quick UK trade deal depends on Brits
EU 'cannot expose our own people, consumers and farmers to disloyal competition,' warns Amélie de Montchalin.


At the heart of every modern event is power distribution, providing power to show-critical and highly valuable equipment. The smartPDU 48 sets a new standard in functionality, flexibility, reliability and safety. It is suitable for all applications; from the smallest venue to the largest tour.
Engineered to meet the tough requirements of the events market, the smartPDU 48 helps you to keep track of the situation at any moment, protecting your connected equipment and crew and, when needed, assisting you in diagnosing problems.
True load monitoring – quick and easy overview of output loading. Catch potential problems before breakers trip, find channels with spare capacity and more.
Remote supervision – the networked system enables you to quickly view the status of all smartPDU's in your system from any location on any device with a browser.
Loss of neutral protection prevents costly damage to connected loads caused by over-voltages.
Backlit marking strips – keeps your channel information clearly visible without external lighting.
Superior circuit breakers – all breakers hold their rated current regardless of temperature. Immediate reset possible.
Quick and easy to reconfigure – all main output connectors can be changed in a minute, from Socapex, to Harting, to Powercon.


text:
Intruso
(idea) by riverrun Thu Apr 24 2008 at 1:17:56
Even the mare disliked him. Gabilan watched from across the arroyo as the kohl-colored Arabian warily set her hindquarters. The man parked his black Benz too close to the paddock again after throwing gravel all the way up the driveway like he always did. Sabaa disliked machinery, and was always wary around men. Gabilan considered it part of her charm. She took after her mistress.
Sabaa El Ludjin was equine royalty, a great-granddaughter of Bay El Bey, the most famous Arab in California, if not America. Bethany must've paid a caliph's ransom for her, but be that as it may--breeding did not interest Gabilan especially; it was the playground of the wealthy, and he was certainly far from that. An animal's behavior, though, or a woman's--that fascinated him entirely. And as Bethany always said: Arabians—you either love em or hate em.
Oso came galumphing up, all snot and slime from the pond. He'd fished a plank the size of an aircraft carrier out of shallow water and was showing it off, somehow managing to balance the thing in his mouth. Keeping a Lab in the desert would be unfair, but Oso was a lucky dog—thanks to the wonders of topography and 19th century foresight he had an acre of water all to himself, even in the heat of October when less well-placed ponds around here would go dry.
--Buen muchacho said Gabilan. Bit off more than you can chew, eh?
Oso dropped the plank, sat happy and proud, young eyes glistening, tongue lolling goofy, sugar cookie-yellow coat drenched in algae and rotted leaves.
--Mom'll kill us both, cabrito. Let's hose you off.
The dog bounded ahead of him towards the garage, full of energy and delight. Gabilan watched the new guy out of the corner of his eye, some fifty yards to the south. The man fiddled in the back seat of his car, came up with a bottle in a paper bag and a bouquet of purple flowers. Tulips of course. Scarce this time of year. Things had progressed to that. Another Friday afternoon in the low desert. A couple of late nights and too much wine and maybe an empalme and then some lazy follando in the afternoon before the trip back home, wherever home was, on Sunday.
Gabilan uncoiled the hose while the man disappeared behind Bethany's art project of a house. The dog leapt and pirouetted in excitement. Gabilan felt the cold water surging though the hose like a fat green cartoon serpiente as he turned the faucet. The dog, delighted, caught the first blast square in his mouth. His teeth snapped loudly open and shut again and again like castanets. Gabilan re-directed the torrent along the animal's spine as Oso curved and crooked, trying to mouth the water some more. He backed off a bit, allowing the animal a chance to settle down. He sprayed a gentler stream against Oso's broad strong chest, rubbing the algae off his legs and his paws and his tail with his hand.
As Oso shook himself into something that passed for dry, for fun Gabilan sent the water on a forty foot sweep into the garden, where the droplets fell like rain. Sunlight was caught dancing en el arco as the beans and tomatoes slaked their thirst. Gabilan was the kind of man who built rainbows wherever he went.
And in her paddock, Sabaa El Ludjin considered how men will come and go, and how some men will bring apples and apply the brush and say the soft sounds and feed the others last, and how some men will not.
--Fuck this fucking fucking traffic he said as the GPS bleeped at him pathetically. I KNOW I'm entering fucking slow fucking traffic, goddammit.
You could count on slow traffic on the 210 East on a Friday. Rush hours, noontimes, weekends and after school, the 210 was a bitch. Stover had a theory, and though it might make him unpopular in the Peoples' Republic of Santa Monica, there was some pure common sense to it: Chinese. They can't drive and they're all over the 210 freeway, from Burbank to goddamn Rancho Cucamonga, which is to say from the middle of the city the Spaniards called El Pueblo de Nuestra Señora Reina de los Ángeles sobre El Rio Porciuncula to its eastern-most limit in the desert, where not even a dog would choose to live. Except people did, and Stover was beginning to wonder if they weren't the smart ones after all.
Stover had lived in L.A. for close to forty years, and in the beginning—when gas was sixty cents a gallon and you could buy a VW for two grand—a man could drive from Tarzana, where Edgar Rice Burroughs built his mansion, to Hollywood, where Tarzan himself lived and got laid, in half an hour. Hell, when he first got out of the army in '71 you could drive ANYWHERE in the L.A. Basin in forty minutes max. These days it takes half an hour to make a left turn at Colorado and De Lacy in Pasadena, right there in front of the Apple Store and Tiffany's, and that's no bullshit.
Somewhere along the line the city'd gone Third World, with traffic like Mexico City's, like Beijing's or Calcutta's for all he knew, though he'd never been to India and wouldn't even consider China. Not since Nam.
As he pondered why Mexican and Chinese and female drivers refuse to enter the 110 North from the 105 East when the sign clearly reads "THREE cars per green," and while his present freeway of choice had ground to a halt, Stover's phone rang. Hands-free, thank you Bluetooth. It was Lovejoy.
--What? he said. Stover hated telephones.
--Sorry. You in traffic?
--No, Rich, I'm getting a massage and a happy ending in Koreatown.
--Sorry. On your way already then, hunh?
--What is it, man?
--I just wanted to let you know, the network's got a problem with the second brothel scene.
--So? I got a problem with the second brothel scene and I wrote the goddamn thing.
--I know.
--Lay down with whores, you wake up with crabs.
--Un hunh.
--So they ASKED for it and now they don't like it, right? They read it, they saw dailies, they saw the rough cut, sat in on the dub—to which they were NOT invited--and now they want to lose it, right?
--You said this would happen.
--Yes. And I'm wondering why you called me too.
Stover popped an Altoid. He hated these conversations. He'd been having them for thirty years, and thirty years' a long time to do a thing you hate. A slate-gray Ferrari pulled up on his right, going nowhere fast like everybody. Good looking car, and at least it wasn't red.
--Will?
--Listen, said Stover. Call Ron and tell him the deal, will ya? I'll recut it but we can't drop it, OK? The show's short as it is and they won't give us a variance. See if he can talk some sense into…what's his name.
Jesus, he hated the way he was forgetting names.
--Lean?
--Lean, Loon, Long—the Standards and Practices guy.
--Lean.
--Yeah, the pissant. Have Ron run with it, OK? Make my day, will ya, Rich? I'm trying to clear my head.
--OK. Sorry. Can I call you?
--Yes Richard, said Stover, suddenly even more tired than usual. You may call me any hour of the day or night. I am only trying to have a life.
--OK, Bud. Have fun.
--Right.
That pain he got on the lower left side, the one that wasn't an ulcer and according to the doc wasn't his spleen, hit him again the way it did. He moved around in the seat, in a way wishing he could just pull over and have a little snooze, trying to get comfortable. The GPS said it all: average speed twelve miles an hour. It'd take him an hour and a half just to get to Claremont and he had another hundred miles after that. In his youth he could've run the distance faster. In his youth he'd always wanted a job like this and he'd always wanted to drive a Mercedes and he always liked Rolex watches, sailboats, airplanes, motorcycles, and beautiful women.
In his youth, Will Stover had thought he'd live forever, or at least until something better came along. It was beginning to look like that wasn't going to happen. He was wondering how Bethany would work her magic tonight, the way she always did, IF he got there, when the Ferrari swung quick and neat in front of him, like a jock cutting in front of the fat kid in the lunch line. Its Nevada license plate read WNRTKAL.
Next: Contentment
Intruso, an extremely postmodern love story
Her voice was shiny
Timed Writing
In the Beginning was Rock n Roll
Cell Phone Interruptus
The Hooch
Blackbirds at One O'Clock
Probiotics and the Muse
Email by Rodney Strong
Dope and Flax Seed
Free to a God Home
Lemonade and Consequences
I like it! 5 C!s
contentment Timed Writing Cell Phone Interruptus The Hooch
Lemonade and Consequences Dope and Flax Seed On Location Nightsong
The Last Days of Captain Newton Her voice was shiny Email by Rodney Strong Blackbirds at One O'Clock
What is it with chicks and horses? In the Beginning was Rock n Roll Below the Line Free to a God Home
Probiotics and the Muse Horses give you confidence The Principles of Training a Horse Trims
Rough cut Hemingway and Fortuna A boy, a girl, a big fat dead old lady High school can kill you
Beauty of a thunderstorm
How to buy a stereo system (without winning the lottery)
words with all the vowels
J.S.G. Boggs


Not sure where that secret switch is, having a problem with one of the many Foretravel RV coaches systems or just need some advice on how to fix something? Get tons of expert advice in our Foretravel motorhome technical support forum!
2002 U320 What is the location of the Coach Batteries?????


text:
Zoom Range (now: 0)
Collaborating Authors
Updated Jan-27-2022, 19:23:17 GMT
What Are Teens Doing On The Internet? Don't Ask Parents, Because They Don't Have A Clue
International Business Times Aug-28-2016, 03:56:35 GMT
If you are hoping to ask parents what kids do on the Internet, think again! A new study by the National Cyber Security Alliance (NCSA)--and co-sponsored by Microsoft--looking at online safety attitudes and behaviors has found a "digital disconnect" between parents and their teenage children. The survey, which interviewed 804 online teens between the ages of 13 and 17 and a separate sample 810 online parents of teens of the same age group, found that parents don't necessarily know what their kids are up to. For example, 60 percent of teens have online accounts that parents are not aware of and only 28 percent of parents have suspicions that their teens have secret accounts. The disconnect is also seen in disciplining and monitoring Internet usage.
ask parent, disconnect, internet, (4 more...)
Information Technology > Communications > Networks (0.69)
Information Technology > Security & Privacy (0.59)
What Kind of Screen Time Parent Are You? Take This Quiz And Find Out
NPR Technology Jan-29-2018, 13:04:09 GMT
Almost as soon as they can focus past the end of their noses, babies today are waving at Grandpa on video chat and swiping the screens on all kinds of devices.
balance digital media, daniel tiger, screen time parent, (1 more...)
NPR Technology
Parent Anxiety, Screen Time And Learning In The Digital Age
NPR Technology Mar-13-2017, 10:20:04 GMT
"If I can get them out the door with pants on, I feel like we've won the day." A lot of parents can probably relate to those words from a stressed out dad, who's trying to deal with big issues of parenting amid the normal chaos of just getting them to school. He was one of more than a dozen parents who joined us one night to talk about parenting in the digital age. We wanted to know: How do you make sense of all the latest research on a topic like screen time and somehow fit it into daily family life? Considering how tough it can be to just get through Monday, that's a tall order.
digital age, parent anxiety, screen time and learning, (1 more...)
Industry: Education (0.44)
A normal student parent
Science Oct-11-2018, 20:24:01 GMT
I don't know if you'll be able to reach her,
educational setting, normal student parent, student parent
Virginia library goes viral for parent-friendly workstations
FOX News Jan-27-2022, 19:23:17 GMT
Fox News Flash top headlines are here. Check out what's clicking on Foxnews.com. A library in Virginia has gone viral for having workstations designed specifically for caregivers with infants. On Saturday, Ali Faruk, a father of two from Virginia, posted a photo of the workstations at the Fairfield Library, part of the Henrico County Public Library system in Virginia. The workstations, or cubicles, are made up of a desk with a computer and an adjacent enclosed area for babies and toddlers.
faruk, health & medicine, workstation, (13 more...)
Country: North America > United States > Virginia > Henrico County (0.37)
Media > News (0.41)
Health & Medicine > Therapeutic Area (0.33)
Health & Medicine > Epidemiology (0.31)


All removable parts are soaked in special DIP TANKS outside your property. No mess!
We have been employing Stulee Cleaning Specialists for all our cleaning requirements since April 2009 – we have always found them to be helpful and reliable. We have had no problems and wholeheartedly recommend them.
We have been using Stulee Window Cleaners to clean our windows, canopies and for the high-level cleaning within our main school kitchen here at Wymondham High Academy for the past 5 years. The staff have always been very professional and courteous and their time keeping has always been excellent. Should you require any further information please do not hesitate to contact me.
We have used Stulee Cleaning Specialists for several years for various tasks such as window cleaning, canopy, pressure wash and high level cleaning. We have always found them to be very professional, reliable and always complete the tasks set in the timescales set if not sometimes very short time scales and will endeavour to fit you in at a moment's notice, Should you have a task that requires immediate attention. I highly recommend Stulee for all your cleaning requirements, and we look forward to using them for the foreseeable future.


text:
Boden v Sweden 4
[1987] ECHR 26; (1987) 10 EHRR 367
27th October, 1987
R (Aggregate Industries) v English Nature [2002] EWHC 908 (Admin); [2002] EWHC 908; [2003] Env LR 3 High Court of England and Wales United Kingdom - England and Wales 24 Apr 2002 BAILII 4
Bovis Homes Ltd v New Forest District Council [2002] EWHC 483 (Admin) High Court of England and Wales United Kingdom - England and Wales 25 Jan 2002 BAILII 16
R (Alconbury Developments Ltd) v Secretary of State for the Environment, Transport and the Regions [2001] UKHL 23; [2002] 2 AC 295; [2001] 2 All ER 929; [2001] 2 WLR 1389; [2002] Env LR 12; [2001] UKHRR 728; [2001] HRLR 45 House of Lords United Kingdom 9 May 2001 BAILII 241
- Damages Under the Human Rights Act (Report) [2000] EWLC 266 Law Commission United Kingdom circa 2000 BAILII


text:
So tell us what you really think about what you see on TV
Why I'm Here
Above the Fold | Nov 2016 | Sep 2016
First day of the November ratings "sweeps" has some notable ratings and moments
The November "ratings" sweeps" began a 20-weekday run on Thursday, Oct. 27th. We break down the opening D-FW newscast ratings, plus the virtual meltdown of TEGNA8's 5 p.m. newscast, which paid a stiffer ratings price than usual. It's all on the Dallas-Fort Worth TV page.
Also, the Back Channels page rewinds to a colorful, anecdote-filled 2002 interview with impressionist Rich Little, who at the time played nine U.S. Presidents during a six-day engagement at the Majestic Theatre in downtown Dallas.
The World Series comes to Wrigley -- and this time it's personal
Youthful Barky loved the Chicago Cubs. And all these years later, they'll be playing a World Series game in Wrigley for the first time in my lifetime. The Cleveland Indians also have known futility, winning their last World Series in 1948. A star player-manager then became a Cubs mainstay after his retirement. Ladies and gentleman, please give a warm re-welcome to Lou Boudreau on our Network News & Reviews page.
Plus, you can find our review of TBS' People of Earth right here. And Wednesday's D-FW ratings "snapshot" highlights Game 2 of the Cubs-Indians World Series.
Last of the fall rollouts with CBS' The Great Indoors and Pure Genius
CBS has ended this season's abbreviated Thursday Night Football run, meaning there are holes to fill.
The network fills them with the last of this season's fall rollouts on the Big Four broadcast networks. Our review of The Great Indoors, starring Joel McHale, is here. And for a look at the medical drama Pure Genius, go here.
Also, a roundup of D-FW Nielsen ratings spotlights Tuesday night's Game 1 of the World Series.
"How the News Got Made:" an evocative, provocative panel from Dallas VideoFest
For an old hound like myself, the most interesting event at the just concluded 29th annual Dallas VideoFest was "How the News Got Made." WFAA-TV's 16 millimeter filmed newscasts from the late 1960s and early 1970s were the focal point of an 18-minute film preceding a panel with three of the station's former stalwarts. A side dish of Bill O'Reilly also was served. See our Dallas-Fort Worth TV page for a detailed account.
Hugh Laurie, Matt LeBlanc respectively return in Chance and Man With A Plan
Hugh Laurie returns to M.D. mode in Hulu's Chance while Matt LeBlanc is back as his amiable self in CBS' Man With A Plan. Both have their flaws and appeal. Our review of Chance is here, and a critique of Man With A Plan is here.
Plus, the D-FW ratings are in for the last of three presidential debates between Hillary Clinton and Donald Trump. Get the complete 10-network breakdown on the Dallas-Fort Worth TV page.
Reviewing Amazon Prime's Goliath after viewing all eight episodes
Producer David E. Kelley and Billy Bob Thornton team up for Amazon Prime's Goliath, which began streaming all eight episodes last week. Look for a definitive ending rather than a string-along, which lately is a considerable plus. Our review is here.
Plus, the Dallas Cowboys' win over the Green Bay Packers is the new clubhouse leader in D-FW ratings for this season's first six games. All the numbers are on our Dallas-Fort Worth TV page.
Epix takes the scripted series plunge with Graves and Berlin Station
It's already a very crowded field, but the premium pay cable network Epix comes to play for the first time with a pair of original scripted series, Graves and Berlin Station. Non-subscribers can watch both Sunday as part of a free preview weekend. And our reviews of both series are here.
Plus, the Wednesday-Thursday local ratings snapshots are posted.
Chelsey Davis and husband Brandon Hamilton respectively leaving early morning newscasts at D-FW's CBS11/TEGNA8
Newlyweds Chelsey Davis and Brandon Hamilton are heading back to Phoenix and vacating their early morning posts at CBS11 and TEGNA8.
Both have been in D-FW only since the summer of 2015, with Davis doing the traffic reports for CBS11 while Hamilton was the main feature reporter for TEGNA8's Daybreak. All the exclusive details are on our Dallas-Fort Worth TV page.
Plus, Tuesday's D-FW ratings "snapshot" spotlights NBC's This Is Us as fall's biggest new hit.
Also, the USA network continues its latter day walks on the darker side with the new drama series Falling Water. Our review is here.
ABC's American Housewife throws its weight around
Take it from her, the heroine of ABC's new American Housewife sitcom is fat. She'll keep telling you that in Tuesday's premiere. Our review is here.
Plus, Monday's D-FW Nielsen ratings "snapshot" is posted.
The Cowboys, the debate, the Rangers -- oh my
The weekend brought a torrent of TV activity, particularly on Sunday.
So were the Dallas Cowboys on just one network potent enough to beat the second presidential debate in prime-time on eight networks? And where did the poor Texas Rangers fit in? For the complete local ratings breakdown, see the Dallas-Fort Worth TV page.
Also, TEGNA8 weathercaster Pete Delkus encountered an unexpected disturbance during his Sunday night forecast. We have the video here.
HBO launches two quality Sunday night comedies -- Divorce and Insecure
Sarah Jessica Parker returns to HBO for the first time since Sex and the City with the entirely different Divorce. Our review is here. And Issa Rae arrives on the HBO scene with the equally distinctive Insecure. For that review, go here.
Above the Fold Blog >