[from draft-morris-privacy-considerations-03] 5.1. Presence A presence service, as defined in the abstract in RFC 2778 [RFC2778], allows users of a communications service to monitor one another's availability and disposition in order to make de- cisions about communicating. Presence information is highly dynamic, and generally characterizes whether a user is online or offline, busy or idle, away from communications devices or nearby, and the like. Necessarily, this information has certain privacy implications, and from the start the IETF approached this work with the aim to provide users with the controls to determine how their presence information would be shared. The Common Profile for Presence (CPP) [RFC3859] defines a set of logical operations for delivery of presence information. This abstract model is applicable to multiple presence systems. The SIP- based SIMPLE presence system [RFC3261] uses CPP as its baseline architecture, and the presence operations in the Extensible Messaging and Presence Protocol (XMPP) have also been mapped to CPP [RFC3922]. SIMPLE [RFC3261], the application of the Session Initiation Protocol (SIP) to instant messaging and presence, has native support for subscriptions and notifications (with its event framework [RFC3265]) and has added an event package [RFC3856] for pres- ence in order to satisfy the requirements of CPP. Other event packages were defined later to allow additional information to be exchanged. With the help of the PUBLISH method [RFC3903]. clients are able to install presence information on a server, so that the server can apply access-control policies before sharing presence information with other entities. The integration of an explicit authorization mechanism into the presence architecture has been a major improvement in terms of involving the end users in the decision making pro- cess before sharing information. Nearly all presence systems deployed today provide such a mechanism, typically through a reciprocal authorization system by which a pair of users, when they agree to be "buddies," consent to divulge their presence information to one another. One important extension for presence was to enable the support for location sharing. With the desire to standardize protocols for systems sharing geolocation IETF work was started in the GEOPRIV working group. During the initial requirements and privacy threat analysis in the process of chartering the working group, it became clear that the system would an underlying communication mechanism supporting user consent to share location information. The resemblance of these requirements to the presence framework was quickly recognized, and this design decision was documented in RFC 4079 [RFC4079]. While presence systems exerted influence on location pri- vacy, the location privacy work also influenced ongoing IETF work on presence by triggering the standardization of a general access control policy language called the Common Policy (defined in RFC 4745 [RFC4745]) framework. This language allows one to express ways to control the distribution of information as simple conditions, actions, and transformations rules expressed in an XML format. Common Policy itself is an abstract format which needs to be instantiated: two examples can be found with the Presence Authorization Rules [RFC5025] and the Geolocation Policy [I-D.ietf-geopriv-policy]. The former provides additional expressiveness for presence based systems, while the latter defines syntax and semantic for location based conditions and transformations. As a component of the prior work on the presence architecture, a format for presence information, called Presence Information Data Format (PIDF), had been developed. For the purposes of conveying location information an extension was developed, the PIDF Location Object (PIDF-LO). With the aim to meet the privacy requirements defined in RFC 2779 [RFC2779] a set of usage indications (such as whether retransmission is allowed or when the retention period expires) in the form of the following policies have been added that always travel with location information itself. We believe that the standardization of these meta-rules that travel with location information has been a unique contribution to privacy on the Internet, recognizing the need for users to express their preferences when information travels through the Internet, from website to website. This approach very much follows the spirit of Creative Commons [CC], namely the usage of a limited number of conditions (such as 'Share Alike' [CC-SA]). Unlike Creative Commons, the GEOPRIV working group did not, however, initiate work to produce legal language nor to de- sign graphical icons since this would fall outside the scope of the IETF. In particular, the GEOPRIV rules state a preference on the retention and retransmission of location information; while GEOPRIV cannot force any entity receiving a PIDF-LO object to abide by those preferences, if users lack the ability to express them at all, we can guarantee their preferences will not be honored. While these retention and retransmission meta-data elements could have been devised to accompany information elements in other IETF protocols, the decision was made to introduce these elements for geolocation initially because of the sensitivity of location information. The GEOPRIV working group had decided to clarify the architecture to make it more accessible to those outside the IETF, and also provides a more generic description applicable beyond the context of presence. [I-D.ietf-geopriv-arch] shows the work-in-progress writeup.