/ 
XML-EPP-0.04_01
River stage zero No dependents
/ XML::EPP::DCP

NAME

XML::EPP::DCP - Data Collection Policy object

SYNOPSIS

my $DCP = XML::EPP::DCP->new(
    access => "personalAndOther",  # only one value allowed
    statement => {                 # array of hash refs OK
        purpose => "prov",         # array of str OK
        recipient => "ours",       # array of str OK; see notes
        retention => "business",   # only one value allowed
    },
    expiry => "PY1",               # optional; specify policy expiry
   );

DESCRIPTION

This module represents a Data Collection Policy, a part of the EPP Greeting format. The DCP is

         used to describe the server's privacy policy for data
collection and management.

The RFC also notes;

                            Policy implications usually extend
beyond the client-server relationship.  Both clients and
servers can have relationships with other entities that need to
know the server operator's data collection policy to make
informed provisioning decisions.  Policy information MUST be
disclosed to provisioning entities, though the method of
disclosing policy data outside of direct protocol interaction
is beyond the scope of this specification.

Hear that? There's a MUST there, so take heed: you absolutely must know about other parties' policies, in some unspecified manner, beyond the scope of the protocol, to be conformant to the protocol. Nice work, committee! Now, you as a reader, I DOUBLE DOG DARE you to find out whether or not compliance with extra-protocol requirements like this would actually affect any kind of agreement that you have with any of your business partners. Note that the DOUBLE DOG DARE trumps all keywords defined in RFC 2119, so now you really have to do this - nyeh nyeh nyeh-nyeh nyeh!

The following classes and properties are defined; once the object structure is created, or if you are dealing with a DCP from a server greeting, this API is how you must access the object.

They are concisely described here; note there are many coercion rules for convenience and these are summaried in the "SYNOPSIS".

XML::EPP::DCP

This is the top-level object; there is exactly one of these in each greeting.

Properties: access (see "XML::EPP::DCP::Access"), statement (array; see "XML::EPP::DCP::Statement"), expiry (See "XML::EPP::DCP::Expiry")

XML::EPP::DCP::Access

This object;

                         describes the access provided by
the server to the client on behalf of the originating data
source.

It may have only one of its 6 boolean properties set; is is essentially an enumerated value (this is not currently enforced). It is not implemented as a simple enum due to its structure in the XML Schema.

Here are the values and description from RFC5730; these are all available as properties from the XML::EPP::DCP::Access object;

all

Access is given to all identified data.

none

No access is provided to identified data.

null

Data is not persistent, so no access is possible.

personal

Access is given to identified data relating to individuals and organizational entities.

personalAndOther

Access is given to identified data relating to individuals, organizational entities, and other data of a non-personal nature.

other

Access is given to other identified data of a non-personal nature.

XML::EPP::DCP::Statement

These objects

                                      describe data
collection purposes, data recipients, and data retention.

There can be more than one of these for each DCP.

Properties: purpose (see "XML::EPP::DCP::Purpose"), recipient (see "XML::EPP::DCP::Recipient"), retention (see "XML::EPP::DCP::Retention")

XML::EPP::DCP::Purpose

A set of values describing "the purposes for which data is collected"

Like XML::EPP::DCP::Access, this object has a bunch of boolean properties. At least one must be set, but any number can be set at once. They are (the following text is from RFC5730):

admin

Administrative purposes. Information can be used for administrative and technical support of the provisioning system.

contact

Contact for marketing purposes. Information can be used to contact individuals, through a communications channel other than the protocol, for the promotion of a product or service.

prov

Object-provisioning purposes. Information can be used to identify objects and inter-object relationships.

other

Other purposes. Information may be used in other ways not captured by the above definitions.

XML::EPP::DCP::Recipient

For the most part, this object is like the other quasi-enum types, XML::EPP::DCP::Access and XML::EPP::DCP::Purpose. This field

describes the recipients of collected data

This object has a collection of properties, most of which are boolean like the other two classes. Like ::Purpose (but unlike ::Access), more than one may be set simultaneously. However, the ours property is an array of XML::EPP::DCP::Ours objects, which may be named entities, and appear multiple times.

As such, there is a special case for the rule for this type when coercing from ArrayRef[Str] (ie, a list of strings); if an unknown string appears, it is converted to a XML::EPP::DCP::Ours object with the name property set to the passed-in value.

Valid types of recipient (and hence, property names of this object) are;

other

Other entities following unknown practices.

ours

Server operator and/or entities acting as agents or entities for whom the server operator is acting as an agent. This property is an Array Reference of "XML::EPP::DCP::Ours" objects.

public

Public forums.

same

Other entities following server practices.

unrelated

Unrelated third parties.

XML::EPP::DCP::Ours

As described in the previous section, an entry in the ours array property of a XML::EPP::DCP::Recipient object.

                 An agent in this instance is defined as
a third party that processes data only on behalf of the service
provider for the completion of the stated purposes.

Properties: name (optional Str; "used to describe the recipient")

XML::EPP::DCP::Retention

Another quasi-enum type, only a single property may be set at once for this type. It specifies

data retention practices

So there you have it. The allowed types of practices, and hence properties of this class, are:

business

Data persists per business practices.

indefinite

Data persists indefinitely.

Data persists per legal requirements.

none

Data is not persistent and is not retained for more than a brief period of time necessary to make use of it during the course of a single online interaction.

stated

Data persists to meet the stated purpose.

XML::EPP::DCP::Expiry

This specifies "the lifetime of the policy" and is optional.

Properties: absolute (an ISO-8601 dateTime eg 20100426T19:52+12), relative (an ISO-8601 duration eg PY2M52m for 2 years, 5 months, 2 minutes - mutually exclusive with absolute)

The subtype XML::EPP::dcpExpiryType will happily co-erce from a valid Str which is already a valid ISO-8601 dateTime (the precise subset of which is defined in the XML Schema specification). Values accepted by MooseX::TimestampTZ are also accepted.

SEE ALSO

XML::EPP, XML::EPP::Greeting

AUTHOR AND LICENSE

Development commissioned by NZ Registry Services, and carried out by Catalyst IT - http://www.catalyst.net.nz/

Copyright 2009, 2010, NZ Registry Services. This module is licensed under the Artistic License v2.0, which permits relicensing under other Free Software licenses.