REC-DSig-label-20091124
PICS Signed Labels
(DSig)
1.0 Specification
W3C Recommendation 27-May-1998 (revised 24-Nov-2009)
-
Latest Version:
-
http://www.w3.org/TR/REC-DSig-label
-
This version:
-
http://www.w3.org/TR/2009/REC-DSig-label-20091124
-
Previous version:
-
http://www.w3.org/TR/1998/REC-DSig-label-19980527/
Note:This paragraph is informative. This document is
currently not maintained. PICS has been superseded by the Protocol for Web Description Resources (POWDER). W3C encourages authors and
implementors to refer to POWDER (or its successor) rather than PICS when developing systems to describe Web content or agents to
act on those descriptions. A brief document outlining the advantages offered by POWDER compared with PICS is available
separately.
Editor
Authors:
Copyright © 1998 W3C
(MIT,
INRIA,
Keio ), All Rights Reserved. W3C
liability,
trademark,
document
use and
software
licensing rules apply.
Status of this document
Last updated: 1998-06-01T14:03:02Z
This document has been reviewed by W3C Members and other interested
parties and has been endorsed by the Director as a W3C
Recommendation. It is a stable document and may be used as reference
material or cited as a normative reference from another
document. W3C's role in making the Recommendation is to draw attention
to the specification and to promote its widespread deployment. This
enhances the functionality and interoperability of the Web.
As a result of comments supplied during the balloting period, the
syntax of quoted ISO dates has been changed from strictly PICS 1.1 conformant
to permit either PICS 1.1 or ISO conformant forms.
At the same time we have added optional seconds and decimal
fractions of seconds fields to support those cryptographic algorithms
that require sub-minute precision in timestamps.
A confusing reference to sigblocks in equivalent standalone labels
is fixed. The title is changed to indicate that this is a signature
specification specifically for PICS labels.
At the time this Recommendation was published a possible
revision to PICS 1.1 was being discussed. That revision to PICS 1.1 was
expected to be called PICS 1.2 and was expected to have no significant
impact on this specification. All
references herein to "PICS 1.1" should be interpreted to mean "PICS 1.1
and PICS 1.2".
Comments on this Recommendation may
be sent to<EMAIL_ADDRESS>This document is part of the W3C
Digital Signature Project.
A list of current W3C Recommendations, Proposed Recommendations and
Working Drafts can be found at: http://www.w3.org/TR
Abstract
The W3C Digital Signature Working Group ("DSig") proposes a standard format
for making digitally-signed, machine-readable assertions about a particular
information resource.
PICS 1.1 labels are
an example of such machine-readable assertions. This document describes
a method of adding extensions to PICS 1.1 labels for purposes of signing
them. More generally, it is the goal of the DSig project
to provide a mechanism to make the statement: signer believes statement
about information resource. In DSig 1.0 statement is any
statement that can be expressed with PICS 1.1.
Contents
DSig 1.0 Overview
The W3C Digital Signature Working Group ("DSig") proposes a standard format
for making digitally-signed, machine-readable assertions about a particular
information resource.
PICS 1.1 labels are
an example of such machine-readable assertions. This document describes
a method of adding extensions to PICS 1.1 labels for purposes of signing
them. More generally, it is the goal of the DSig project
to provide a mechanism to make the statement:
signer believes statement about information
resource
In this specification statement is any
statement that can be expressed with PICS 1.1.
This document also provides detailed usage guidelines for creating
PICS 1.1 labels that are valid DSig 1.0 Signature labels.
DSig 1.0 signature labels inherit both a means of transporting a signature
block data and a simple framework for making the machine-readable assertions
from the underlying PICS framework. PICS compliant applications can syntactically
parse DSig 1.0 signature labels; only cryptographic functions need to be
added to PICS-aware applications in order to make use of the semantic content
of a DSig signature.
In its simplest form, a DSig 1.0 signature label is a signed statement
about an information resource. This document describes two DSig-specific
extensions to standard PICS 1.1 labels: resinfo and sigblock.
The resinfo extension is used to create cryptographic links
between the signature label and the information resource described by the
label. Typically this linkage is created through the use of one or more
cryptographic hash functions. The sigblock extension contains
one or more digital signatures of the other contents of the label.
In DSig 1.0, it is important to note that:
-
At no time does a DSig 1.0 signature label 'wrap' the information resource
it is signing;
-
The signature label can always be separated from the information resource;
-
DSig 1.0 Signature Labels provide a means of making assertions about resources
with cryptographic integrity but they do not protect the confidentiality
of the information resource referenced.
The basic structure of a PICS 1.1 label is described below.
W3C recommendations and working drafts related to this document include:
We assume familiarity with these documents.
At the core of DSig 1.0 is the PICS 1.1 label, so we begin by reviewing
the PICS 1.1 architecture and illustrating how DSig 1.0 signature labels
are built on top of PICS 1.1 labels.
PICS Architecture
At the core of the PICS infrastructure is the rating service. The rating
service either chooses an existing, or develops a new rating system
to use in labeling content. The rating system, which is described in a
human readable form at the rating system URL, specifies the range
of statements that can be made. The rating service establishes criteria
for determining who can label content using their name and how the labels
must be applied. This combination of criteria and rating service are uniquely
identified by the particular service URL. This service URL becomes
the brand, if you will, of the rating service. At a minimum, the service
URL will return a human readable form of the rating criteria and a link
to the description of the rating system. The rating service is also responsible
for delivering a service description file. This is a machine-readable
version of the rating system with pointers to the rating system URL and
the rating service URL. While not required, it is recommended that this
be available automatically at the service URL.
A labeler, given authority by the rating service, uses the criteria
established by them along with the rating system to label content. These
content labels contain a statement about the content of the resource being
labeled and contain a link back to the service URL. Content labels can
come in the content itself, with the content or from a trusted third party
such as a label bureau. Policies determine what actions are taken based
on the specific statements in the content label. If a content label is
based on an unknown service URL, it is a simple (and potentially automatable)
task to retrieve the appropriate service description file to understand
what statements are being made in the label.
DSig 1.0 utilizes the PICS infrastructure as described above with a
few differences:
-
In DSig 1.0, the notion of content labels and raters is somewhat different.
In DSig 1.0 the rater is considered to be a labeler.
-
The labeler is making an assertion about an information resource
and creating an assertion label.
-
By signing an assertion label, the signer explicitly confirms belief in
the truth of the statements contained within the label. A signature does
not indicate that the signer created the label, only that they believe
the statements made within it are valid."
-
Additional signatures can be added in parallel with existing signatures
at any point in time.
-
The labeler and signer may be, but do not have to be different entities
in a DSig label. DSig 1.0 signature labels provide fields for storing information
about both the label creator and the signer(s).
-
The PICS rating system referenced in the signature label is an assertion
system in DSig. The statement in the label (made via the PICS ratings)
is an assertion that the labeler is making about the referenced content.
-
Additional resource reference information may be included within the DSig
label to help disambiguate the subject of the label. The DSig resinfo
extension is one way of including such information; it allows the label
signer to provide cryptographic hashes of the labeled content. Other private
extension types may also be defined and included in accordance with the
PICS 1.1 specifications.
PICS 1.1 labels and label lists
PICS labels are always transmitted as lists of one or more individual PICS
labels ("label lists"); in common PICS practice PICS label lists usually
contain exactly one label. Full details of PICS labels and label lists
are available in "PICS
Label Distribution Label Syntax and Communication Protocols Version 1.1"
document:
-
General Format of PICS Labels
-
Semantics of PICS Labels and Label Lists
-
Requesting Labels Separately
In DSig 1.0, each assertion about an information resource is given in a
label. A label consists of a service identifier, options,
extensions and an assertion (in PICS 1.1 the assertion is
called a rating). The service identifier is the URL chosen by the rating
service (see Rating
Services and Rating Systems) as its unique identifier. Options and
extensions give additional properties of the label, the document being
labeled and properties of the assertion itself. The assertion itself is
a set of attribute-value pairs that describe a document along one or more
dimensions. One or more labels may be distributed together as a list which
allows for some data aggregation.
A PICS labels contains one or more service sections:
(PICS-1.1
<Service 1 section>
<Service 2 section>
<Service 3 section>)
Where each service section contains options and labels:
<Service URL> <Service options for all labels in this section>
labels <options for this label> ratings <rating for this label>
<options for this label> ratings <rating for this label>
...
The general form for a label list (formatted for presentation, and not
showing error status codes) is:
(PICS-1.1
<service 1 url> [service 1 option...]
labels [label 1 option...] ratings (<category> <value> ...)
[label 2 option...] ratings (<category> <value> ...)
...
<service 2 url> [service 2 option...]
labels [label 3 option...] ratings (<category> <value> ...)
[label 4 option...] ratings (<category> <value> ...)
...
...)
Labels in a label list are grouped by service. Each service may have service
options which are inherited by each label within the scope of the service;
service options may be overridden by individual label options. When a new
service is identified in the label list, the options from the previous
service no longer apply. Thus, in the above example label 4 could be equivalently
represented as:
(PICS-1.1
<service 2 url>
labels [ service 2 options + label 4 option...]
ratings (<category> <value> ...))
In DSig 1.0, we sign individual labels or portions thereof; the details
of signing labels are presented below.
PICS defines two distinct types of labels, specific and generic:
-
A specific label applies to a single resource. For example, if a
labeled document is in HTML format, the label applies only to the HTML
document itself and not to any other documents referenced via hyperlinks
or <img> tags. This is the default label type.
-
A generic label (identified by the use of the PICS generic
option within the label) applies to any document with a URL that has a
particular prefix (the prefix is specified via the PICS for option
in the label). A generic label for a site or directory should only be used
if it applies to all the documents in that site or directory. The DSig
1.0 resinfo extension is not meaningful within a generic
label.
PICS Options and DSig
Semantics of Embedded Signature Blocks
By convention, a DSig signature block itself has the weakest possible semantics,
namely "the entity possessing the key that created this signature had access
to the secret key used to generate the signature and the signed data at
the same time." For DSig 1.0 signature labels, we want somewhat stronger
semantics that also includes the semantics of the ratings contained within
the label. Thus, by definition a PICS label which includes a DSig sigblock
extension has the following semantics:
"The entity possessing the secret key that digitally signed
this PICS 1.1 label had access to the secret key and the label at the same
time and asserts that the statements made within the label are valid"
Applying PICS to DSig
Following the format given in PICS
Label Distribution Label Syntax and Communication Protocols Version 1.1
we now review each of the PICS 1.1 options; giving appropriate usage rules
for applying them within the context of DSig 1.0 Signature Labels.
PICS label options can be divided into three groups. Options from the
first group supply information about the document to which the label applies.
Options from the second group supply information about the label itself.
Options in the last group provides miscellaneous information.
-
Information about the document that is labeled.
-
at quoted-PICS-ISO-date
-
The last modification date of the information resource to which this assertion
applies, at the time the assertion was made . This can serve as a less
expensive, but less reliable, alternative to the DSig 1.0 resinfo
extension.
-
MIC-md5 "Base64-string"
-
-or- md5 "Base64-string"
-
This option is not used in DSig 1.0.
If this option is present in a DSig 1.0 label, it should be ignored. Further,
it should be removed from the label for the purposes of signing. This option
has been superceded by the DSig 1.0 resinfo extension.
- Information about the label itself.
-
by quotedname
-
An identifier for the person or entity who was responsible for creating
this particular label. The contents of the by field are not restricted
by the DSig 1.0 specification; it is common practice in PICS usage to include
a name or e-mail address in the string value of the by field. Within
DSig 1.0, the by field is considered informational only; the by
option name need not be the same as that of the signer(s). The sigblock
extension includes fields for the identity of the signer (in the
signature section) and certificates (or references to them) identifying
the signer(s) (within the attribution information section).
-
for quotedURL
-
The URL (or prefix string of a URL) of the information resource to which
this assertion applies. This option is required for generic labels and
in certain other cases (see "Requesting Labels Separately," PICS Label
Distribution Label Syntax and Communication Protocols Version 1.1); it
is optional in other cases. The for option is valid as both a service
and label option in a label list.
-
generic boolean
-
-or- gen boolean
-
If this option is set to true, the label can be applied to any URL starting
with the prefix given in the for option. By default, this option
is false. Set to true, it is used to supply ratings for entire sites or
subparts of sites. All generic labels must also include the for
option. A generic label should not be created unless it can be legitimately
applied to all documents whose URL begins with the prefix specified
in the for option (even if a more specific label exists). If the
generic option is used with a true value, the DSig 1.0 resinfo extension
can not be used because there will not be a specific information resource
to hash.
-
on quoted-PICS-ISO-date
-
The date on which this label was created. This may be different than the
date the label was signed (which may be included within the DSig 1.0 sigblock
extension).
-
signature-RSA-MD5 "Base64-string"
-
This option is not used in DSig 1.0.
If this option is present in a DSig 1.0 label it should be ignored and
removed from the label for the purposes of signing. This option has been
replaced with the DSig 1.0 sigblock extension.
-
until quoted-PICS-ISO-date
-
-or- exp quoted-PICS-ISO-date
-
The date on which the label expires (how long the label is good for).
-
Other information.
-
comment quotedname
-
Information for humans who may see the label; no associated semantics.
-
complete-label quotedURL
-
-or- full quotedURL
-
De-referencing this URL returns a complete label that can be used in place
of the current one. The complete label has values for as many attributes
as possible. This option is used when a short label is transmitted for
performance purposes but additional information is also available. When
the URL is de-referenced it returns an item of type application/pics-labels
that contains a label list with exactly one label. In DSig 1.0 this option
might be used if the initial label transmitted was an abbreviated version
of the full label. The abbreviated version might contain minimal options
and no signature. The client application could then de-reference this URL
to get the full, signed version of the label.
-
extension (optional quotedURL data*)
-
-or- extension (mandatory quotedURL data*)
-
Future extension mechanism. To avoid duplication of extension names, each
extension is identified by a quotedURL. The URL is de-referencable,
yielding a human-readable description of the extension. If the extension
is optional then software which does not understand the extension
can simply ignore it; if the extension is mandatory then software
which does not understand the extension should act as though no label had
been supplied. Each item of data must be one of a fixed set of simple-to-parse
data types as specified in the detailed syntax below. See http://www.w3.org/PICS/extensions/ for a partial
listing of extension URIs previously defined.
The DSig 1.0 resinfo
and sigblock extensions uses this mechanism (See "DSig
Extensions," below for details.)
DSig Extensions
A DSig label 'signs' an information resource. To do this in a secure fashion,
the signed label must have a cryptographic connection to that resource.
We create cryptographic links between a label and the labeled resource
by including one or more hashes of the information resource within the
signature label. Similar, albeit limited, functionality was accomplished
in the PICS 1.1 specification via the MIC-md5 (or md5) option.
DSig 1.0 replaces this option with the resinfo extension,
which permits a single label to include multiple hashes using multiple
hash algorithms.
PICS 1.1 also specified a signature option, signature-RSA-MD5,
but its functionality was similarly limited. DSig replaces signature-RSA-MD5
with the sigblock extension. The sigblock extension
may contain one or more signatures using any cryptographic algorithm; in
addition, a sigblock may optionally include information in
the form of certificates or links to certificates.
A DSig 1.0 Signature Label is a standard PICS 1.1 label. The DSig extensions
resinfo and sigblock are both optional and
can be used as needed. A PICS 1.1 label is only considered a DSig 1.0 Signature
Label when it contains a sigblock extension.
The syntax of the extensions presented below is written in modified
BNF. By convention,
-
a?
-
a or nothing; optional a.
-
a+
-
one or more occurrences of a.
-
a*
-
zero or more occurrences of a.
Quoted strings are case sensitive but other literal elements are case insensitive.
Multiple contiguous space characters are be treated as though they were
a single space character except in quoted strings.
URLs as identifiers
Within the DSig 1.0 sigblock and resinfo extensions,
URLs are used as identifiers to indicate a particular hashing algorithm,
certificate type or signature type. Specifically, they are used as:
To ensure the uniqueness of identifiers, the identifier must be a valid
URL. This in effect creates a distributed registry of unique names which
can be created and shared by any community of interest.
Since the identifier is a URL, it must, when resolved, yield a a document.
We recommend the returned document:
-
be available at least in HTML format;
-
identify the entity which created and maintains the identifier;
-
describe the specifics of the algorithms and encodings, or provide a link
to another document which does so; and
-
be available in multiple languages, either through an existing negotiation
mechanism or through links to alternate language versions
We require that such identifier description documents always be provided.
Any incompatible change in an identifier should be accomplished by creating
an entirely new identifier URL.
URL identifiers
for some common, popular signature suites are available. Of course,
DSig 1.0 implementations are not restricted to using these or only these.
To provide a base level of interoperability, all DSig 1.0 implementations
are required to implement the signature suites listed in Appendix 3.
Resource Reference Information Extension
The goal of the resource reference information (resinfo)
extension is to provide a cryptographic link between the signature label
and an information resource. DSig 1.0's resinfo extension
builds upon the PICS 1.1 for, at and MIC-md5 options
to provide this cryptographic link. Specifically, the resinfo
extension provides a mechanism for including cryptographic checksums (hashes),
in any named cryptographic algorithm, to the label. These hashes provide
a means for the receiver of the label to determine if the information resource
they have is the same as the one about which the assertion was made.
The resinfo extension is associated with a specific resource.
This resource may be identified by the for option or may be implied
by the context of the label (in the resource, delivered in the HTTP header
with the resource, returned by a label bureau based on a request, etc.).
In the structure of a PICS label, the resinfo extension
can be a service option and/or a label option. It functions
identically to any other option with respect to inheritance within a service
section from service option to label option. A single document can have
many URLs; the URL used to retrieve a document may differ from the URL
in the for option of a label that accompanies the document, but
the document retrieved must be the same document or the hash(s) contained
in the resinfo extension will not be valid.
Structurally, resinfo contains one or more hashes of the
information resource; each hash includes a hash algorithm identifier, the
actual hash of the resource and (optionally) the date the hash was computed.
("Hash Algorithm Identifier" "base64-string of hash" "hash date")
The hash algorithm identifier is a quoted
URL identifier as defined above. It identifies the
specific hashing algorithm by which the following hash was computed. The
actual hash is given as a quoted base64 encoded string.
Usage notes:
-
The resinfo extension can either be a service option or a
label option. If both are present, the extension given as a label option
takes precedence over the service option. Thus, an equivalent
standalone label will have at most one resinfo extension
and that extension will be the extension given as the label option for
that label unless none is present, in which case the extension given as
a service option will be used. If neither is present, the equivalent standalone
label will have no resinfo extension.
-
A resinfo extension can contain multiple hashes of the information
resource. Each must necessarily use a different hash algorithm; it is not
valid to label multiple versions of a single document by including multiple,
distinct hashes in one label.
-
The resinfo extension is an "optional" extension. Optional
implies that even if the processing software does not understand the extension,
it should still process the label.
-
The resinfo extension is not valid in a generic PICS
1.1 label. It is only valid within a specific (non-generic) PICS
1.1 label.
-
Resinfo is not extensible: In DSig 1.0, if other disambiguating
or differentiating information is needed, a separate extension will need
to be created. We assume that the next version of DSig will allow for much
richer and extensible resource reference information.
Detailed Syntax of the resinfo Extension in a PICS 1.1 Label
resinfo-extension ::= 'extension ( optional '
'"http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"' resinfo-data+ ')'
resinfo-data ::= '(' HashAlgoID resource-hash hash-date? ')'
HashAlgoID ::= quotedURL
quotedURL ::= '"' URL '"'
resource-hash ::= '"base64-string"'
hash-date ::= quoted-ISO-date
quoted-ISO-date ::= '"' YYYY sep MM sep DD 'T' hh ':' mm[':' ss['.' f+]] Stz '"'
based on the PICS-defined ISO 8601:1988 date and time format, restricted
to the specific form described here:
sep ::= '.' | '-'
YYYY ::= four-digit year
MM ::= two-digit month (01=January, etc.)
DD ::= two-digit day of month (01 through 31)
hh ::= two digits of hour (00 through 23) (am/pm NOT allowed)
mm ::= two digits of minute (00 through 59)
ss ::= two digits of second (00 through 59), optional
f ::= digit(s) of fractions of second, optional
S ::= sign of time zone offset from UTC ('+' or '-')
tz ::= four digit amount of offset from UTC
(e.g., 1512 means 15 hours and 12 minutes)
For example, "1994-11-05T08:15-0500" is a valid quoted-ISO-date
denoting November 5, 1994, 8:15 am, US Eastern Standard Time
Notes:
1. The ISO 8601:1988 date and time format standard allows considerably
greater flexibility than that described here. DSig requires precisely
the syntax described here -- neither the time nor the time zone may
be omitted, none of the alternate ISO formats are permitted, and
the punctuation must be as specified here, Except:
2. ISO date described here differs from the PICS 1.1 and ISO 8601:1988
date and time format. PICS 1.1 uses '.' as separators while the ISO
standard calls for '-'. DSig supports both syntaxes. PICS 1.1 also
does not support the optional seconds and fractions of seconds fields
and permits minutes to range from 0 to 60.
base64-string ::= as defined in RFC-1521.
URL ::= as defined in RFC-1738.
The following example shows a valid DSig 1.0 resinfo extension
with two hashes of the referenced information resource.
extension
( optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"
( "http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "base64 hash" )
( "http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "base64 hash"
"1997-02-05T08:15-0500" ) )
In this example, we begin with the extension ( optional tokens
which identify this extension as an optional extension to the PICS label
within which it is contained. This declaration is followed by a URL,
http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0, which provides a unique name
for the extension. De-referencing the URL provides human readable information
on the extension. Finally we have two repeating subsections of the extension,
each of which contain hash information. Here again, de-referencing the
hash algorithm identifier URL returns a human readable description, this
time of the hash algorithm. In our specific example above, the first hash
is of type SHA1. This is followed by the actual hash data and followed
by the date the hash was computed. The second clause uses the MD5 hash
algorithm.
The Signature Block Extension
The DSig 1.0 Signature Block Extension (sigblock) provides
cryptographic protection of the DSig 1.0 label by using digital signature
techniques. It identifies
-
who has signed the information resource,
-
which parts of the label were signed (if not the entire label), and
-
which algorithms were used to generate the signature, and
-
the signature data itself.
The sigblock extension can also contain certificates that
can be used by a trust management system (TMS) to decide if the signature
is trustworthy.
Format Specification
A Signature Block consists of
-
Attribution Information, and
-
one or more Signatures.
Usage notes:
-
The sigblock extension is an "optional" extension. Optional
implies that even if the processing software does not understand the extension,
it should still process the label. We do not require that the extension
be understood (mandatory) because the information contained within the
label may be useful to applications that cannot understand the signature
information. Whether information contained within an unsigned or unverified
label should be used is a trust management question.
-
The sigblock extension is valid in both generic and
specific (non-generic) PICS 1.1 labels.
-
The sigblock extension is extensible via signature
suites.
-
A sigblock extension is only valid as a label option.
Here is a structural representation of the sigblock extension:
extension
( optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"
<attribution info> <signature>* ) )
Attribution Information
The Attribution Information section contains self-verifiable information
related to the creation of the digital signature on the label. In particular,
cryptographic certificates asserting identity, authorization or other capabilities
may be included here. Certificates may be directly embedded within the
Attribution Information section of the sigblock extension,
or URLs pointing to certificates may be included. Attribution Information
is not required (i.e. this section of the extension may be empty), in which
case trust management systems must depend on other information sources
when interpreting the label. Furthermore, the information provided herein
may or may not be used by the trust management system in processing the
label.
Attribution Information supports any certificate format; the types of
certificates included will depend on the public key infrastructure used
by the application. Certificate format is indicated by the certificate
family identifier, a quoted URL identifier as defined
above. This certificate family identifier, when dereferenced, provides
information on the format of the data to follow.
None of the information contained within the Attribution Information
section is signed by the label's signature because certificates themselves
are expected to be self-verifying. (More precisely, none of the information
within the entire sigblock extension, including the Attribution
Information section, contributes to the hash of the label that is signed
as part of the signature option.) Thus, applications may augment the contents
of the Attribution Information section without invalidating the signature
on the label (e.g. newly-discovered certificates may be included in the
Attribution Information section as they are found, or an expired certificate
may be replaced).
Here is a structural representation of the Attribution Information section:
( "AttribInfo"
( "CertificateFamilyIdentifierURL" "Certificate Data")
( "CertificateFamilyIdentifierURL" "Certificate Data")
...)
Here is an example Attribution Information section:
( "AttribInfo"
( "http://www.w3.org/PICS/DSig/X509-1_0" "base64-x.509-cert")
( "http://www.w3.org/PICS/DSig/X509-1_0"
"http://ice-tel-ca/certs/DN/CN=Lipp,O=TU-Graz,OU=IAIK")
( "http://www.w3.org/PICS/DSig/pgpcert-1_0" "base64-pgp-signed-key")
( "http://www.w3.org/PICS/DSig/pgpcert-1_0"
<EMAIL_ADDRESS>) )
Signatures
The Signature section of the sigblock extension contains
the actual digital signature data. Each Signature section contains exactly
one signature; multiple Signature sections may be included in the sigblock
extension when multiple, parallel signatures are desired. The syntax of
the Signature section is:
( "Signature" SignatureSuite SigData+)
Being crypto-neutral, DSig 1.0 does not prescribe the use of particular
algorithms for generating hashes or digital signatures. DSig 1.0 also does
not define any particular format for representing cryptographic information
in the sigblock. Instead, we introduce the concept of "signature
suites," which bundle together certain hashing algorithms, signature algorithms
and representation format. Each digital signature includes a signature
suite identifier (a quoted URL identifier as defined above)
that tells applications how the signature was generated and how it should
be parsed.
Each signature suite:
-
specifies the algorithms that have been used for creating the signature,
and
-
defines the content of any subsequent SigData.
Signature suites have complete control over the contents of the SigData
immediately following the signature suite URL. The format of this data
must satisfy the SigData portion of the BNF; beyond that requirement, the
format of the data is governed by the definition given in the signature
suite.
DSig 1.0 does define two hash algorithms and two signature suites for
interoperability; see Appendix 3.
Implementations must implement these four algorithms in addition to any others
they may wish to define.
Common SigData fields
Although each signature suite is free to specify its own format for signature
data (SigData) fields, there are some types of information that are likely
to be used by most signature suites. For example, signature suites need
to include the actual cryptographic data that constitutes a digital signature.
Signature suites will probably also wish to include information about the
cryptographic keys used to generate and verify the signature. We now define
some common SigData fields and their identifying string tokens ("SigTokenString"
in the BNF below). These string tokens are reserved words in the
sense that any signature suite that uses SigData field identified by these
tokens must do so in a manner consistent with this specification.
Keyholder tokens: information about keys related
to the signature
Mathematically, a digital signature only cryptographically guarantees that
at a particular point in time some process had access to both the signing
(secret) key and the text of the signed document. The "Keyholder"-type
SigData fields of a signature provides information about the key that was
used to create the corresponding signature. The key may be bound to some
entity (such as a person, server, or organization) by various certificates.
There are four common ways to uniquely specify a particular key; each has
its own identifying token:
-
Provide the public key directly ("ByKey");
-
Provide a hash (or fingerprint) of the public key ("ByHash");
-
Provide some name that is associated with the public key, such as
an X.509 "distinguished name" or the UserID string of a PGP key ("ByName");
or
-
Provide the name of a certifying authority (CA) and information, which
identifies the desired key to the CA ("ByCert").
To be useful, the information identifying the signing key will lead the
application to corresponding certificates in the Attribution Information
section (if any) or provide the starting point for fetching certificates
from remote sources.
The following subsections specify the content of the SigInfo fields
associated with each of these tokens.
"ByKey"
The token "ByKey" identifies the value that follows as the key that should
be used to validate the signature (or sufficient information to generate
that key locally).
( "ByKey" <Key-Value, SignatureSuite dependent> )
The format of the included key necessarily depends on the particular signature
suite used and must be specified in the signature suite document. Here
is an example use of "ByKey" within the Digital Signature Algorithm (DSA)
signature suite:
( "ByKey"
( "P" "base64-encoded-modulus" )
( "Q" "base64-encoded-divisor" )
( "G" "base64-encoded-number" )
( "Y" "base64-encoded-public-key" ) )
"ByHash"
The token "ByHash" identifies the value that follows as the hash
of the key that should be used to validate the signature.
("ByHash" "base-64-encoded-hash-of-key" )
Details on how the hash for a key is generated is a property of individual
signature suites.
"ByName"
The token "ByName" identifies the value that follows as a name (or other
reference) that may be used to identify the corresponding public key. The
name that should be provided depends on the relevant public key infrastructure.
( "ByName" "Name-as-string-value" )
"ByCert"
The token "ByCert" identifies the value that follows as containing the
name of a certifying authority (CA) and the serial number a relevant certificate
issued by that CA. The name given for the CA depends on the naming conventions
of the relevant public key or certification infrastructure.
( "ByCert" ( "CA-Name-as-string-value" <CA-Serial-No.> ) )
The "On" token: Time of Signature generation
The token "On" identifies the value that follows as the time the label's
signature was generated. (This option is distinct from the PICS 1.1 label
option "on" which indicates the time at which the label itself was created.)
We recommend using this standard element in all signature suites.
The time that the signature was created is encoded as a quoted-ISO-Date.
The format of a quoted-ISO-Date is defined below.
("on" quoted-ISO-Date)
Notice that the "on" time is advisory only to applications verifying the
digital signature; as this section is part of the entire sigblock
extension it is not cryptographically protected by the signature itself.
(The contents of the sigblock do not contribute to the hash
of the label that is signed by the signature.) If a cryptographically-protected
date is desired, the correct way to implement it is to include the date
within another PICS label extension; that extension may then contribute
to the hash of the canonicalized label.
The "include" and "exclude" tokens: modifying the
canonicalized form of the label
If an application wishes to transmit both signed and unsigned information
in a label the suggested method for doing so is to generate two labels
(one signed, one unsigned) and send both labels as a PICS label list. However,
some PICS 1.1 protocols, including the protocol for requesting labels from
a PICS label bureau, require that exactly one PICS label be returned in
response to a request, and thus it may be necessary for a signing application
to sign only a subset of a PICS label. If the signature suite permits signatures
over partial contents of labels, the "include" and "exclude" tokens provide
that functionality:
( "exclude" field-list )
( "include" field-list )
The "include" and "exclude" SigData fields modify the default behavior
of the label canonicalizer. "include" indicates that only the fields listed
are included in the signature, "exclude" indicates that all fields are
included in the signature except those listed. Before a label is signed,
it is put into canonical form; the section "Creating
an equivalent standalone label" below describes in detail the canonicalization
process. PICS labels have many semantically-equivalent forms yet these
forms yield distinct hashes, so it is important that signing and verifying
applications canonicalize labels in the same way. After the equivalent
standalone label has been generated following the default canonicalization
rules, individual label options may be dropped if an "include" or "exclude"
option is present. If an "include" option is present, any field not listed
in the field-list is removed from the canonicalized label. If an "exclude"
option is present, all fields listed in the field-list are removed from
the canonicalized label. At most one "include" or "exclude"; field may
appear; it is an error to have both an "include" and an "exclude" option.
The value associated with an "include" or "exclude" option (the "field-list")
is a list of label fields to be included or excluded in the canonicalized
form. There are three types of fields in PICS 1.1 labels: options, ratings
transmit/value pairs, and extensions. The format of a field-list is as
follows:
field-list ::= '(' option-list? ratings-list? extension-list? ')'
option-list ::= '(' "options" <options>* ')'
ratings-list ::= '(' "ratings" <ratings>* ')'
extension-list ::= '(' "extensions" <quoted-URL>* ')'
A field-list is simply at most, one each of: option-list, ratings-list
and extension-list, with their associated data. An option-list is a list
of PICS 1.1 label option names (e.g. "for" or "by"). A ratings-list is
a list of PICS 1.1 ratings service transmit-names (e.g. "suds" in the example
"Good Clean Fun" rating service). An extension-list is a list of quoted-URLs
where each quoted-URL uniquely identifies a particular PICS 1.1 label extension.
Note: The "include" and "exclude" SigData types exist in this specification
strictly to overcome limitations in PICS 1.1 protocols. W3C's new metadata
infrastructure, Resource Description
Framework (RDF) should not have these limitations and it is the intent
of the DSig working group that "include" and "exclude" not be present in
the DSig 2.0 specification, which will build on RDF.
The "SigCrypto" token: signature cryptographic data
The "SigCrypto" token identifies the SigData field that contains the cryptographic
data that is the signature itself. The format and contents of this field
are entirely specified by particular signature suites.
Hashing
Correct hashing is the key to successful signing. DSig 1.0 therefore specifies
how a PICS 1.1 label is converted into a unique, canonicalized form which
does not include the sigblock extension (this process is
explained in the Signing section below). This canonicalized
label is the input to the signature suite's signature algorithm. The signature
algorithm may require or accept other inputs in addition to the contents
of the equivalent standalone label. For example, the signature suite may
pad the data in a particular way, or mix into the hash of the data information
concerning the algorithms used to generate the hash and signature.
Parallel and cascaded signatures
Multiple parallel signatures on the same PICS 1.1 label may be created
simply by including several "Signature" fields within the sigblock
extension. Cascaded signatures (signatures on signatures) are not supported
within a single DSig signature label. To create a cascaded signature, a
DSig signature label may be signed using another DSig signature label.
An example sigblock extension:
extension (optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"
("AttribInfo"
("http://www.w3.org/PICS/DSig/X509-1_0" "base64-x.509-cert")
("http://www.w3.org/PICS/DSig/X509-1_0"
"http://SomeCa/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK")
("http://www.w3.org/PICS/DSig/pgpcert-1_0" "base64-pgp-signed-key")
("http://www.w3.org/PICS/DSig/pgpcert-1_0"
"http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at"))
("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/RSA-MD5-1_0"
("byKey" (("N" "aba21241241=")
("E" "abcdefghijklmnop=")))
("on" "1996-12-02T22:20-0000")
("exclude" (("extensions" "http://foo/badextension")))
("SigCrypto" "aba1241241=="))
("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/DSS-1_0"
("ByName"<EMAIL_ADDRESS>("on" "1996-12-02T22:20-0000")
("SigCrypto" (("R" "aba124124156")
("S" "casdfkl3r489")))))
Detailed Syntax of the sigblock Extension in a PICS 1.1 Label
Note: This extension is not a valid PICS 1.1 extension because Base64 encoding
uses a '/' which cannot be represented as a PICS 1.1 datum. Nonetheless,
since quotedURL (which does allow the use of '/') and quotedname
(which does not) are indistinguishable at a lexical level (and both are
legitimate for use as a PICS 1.1. datum), we believe that all existing
PICS parsers will support the grammar presented below.
SignatureExtension ::= 'extension ( optional'
SigBlockURL AttributionInfo Signature* ')'
SigBlockURL ::= '"http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"'
AttributionInfo ::= '(' '"AttribInfo"' Certificate* ')'
Certificate ::= '(' CertificateFamilyID CertificateData ')'
CertificateFamilyID ::= quotedUrl
CertificateData ::= quotedBase64String | quotedUrl
Signature ::= '( "Signature"' SignatureSuiteID SigData+ ')'
SigData ::= '(' SigTokenString SigInfo ')'
SigTokenString ::= quotedName
SigInfo ::= SigData | quotedURL | quoted-ISO-date | quotedBase64String
| quotedName | number | '(' SigInfo+ ')'
SignatureSuiteID ::= quotedUrl
quotedURL ::= '"' URL '"'
URL ::= as defined by RFC-1738.
quotedBase64String ::= '"' base64String '"'
base64String ::= as defined in RFC-1521.
alpha ::= 'A' | .. | 'Z' | 'a' | .. | 'z'
digit ::= '0' | .. | '9'
quotedName ::= '"' ( urlChar | ' ')+ '"'
urlChar ::= alphaNumPM | '.' | '$' | ',' | ';' | ':'
| '&' | '=' | '?' | '!' | '*' | '~' | '@'
| '#' | '_' | '(' | ')' | '/' | '%' hex hex
; Note: Use the "%" escape technique to insert
; single or double quotation marks within a URL
alphaNumPM ::= alpha | digit | sign
hex ::= digit | 'A' | .. | 'F' | 'a' | .. | 'f'
sign ::= '+' / '-'
number ::= [sign]unsignedInt['.' [unsignedInt]]
unsignedInt ::= digit+
quoted-ISO-date ::= '"' YYYY sep MM sep DD 'T' hh ':' mm[':' ss['.' f+]] Stz '"'
based on the PICS-defined ISO 8601:1988 date and time format, restricted
to the specific form described here:
sep ::= '.' | '-'
YYYY ::= four-digit year
MM ::= two-digit month (01=January, etc.)
DD ::= two-digit day of month (01 through 31)
hh ::= two digits of hour (00 through 23) (am/pm NOT allowed)
mm ::= two digits of minute (00 through 59)
ss ::= two digits of second (00 through 59), optional
f ::= digit(s) of fractions of second, optional
S ::= sign of time zone offset from UTC ('+' or '-')
tz ::= four digit amount of offset from UTC
(e.g., 1512 means 15 hours and 12 minutes)
For example, "1994-11-05T08:15-0500" is a valid quoted-ISO-date
denoting November 5, 1994, 8:15 am, US Eastern Standard Time
Notes:
1. The ISO 8601:1988 date and time format standard allows considerably
greater flexibility than that described here. DSig requires precisely
the syntax described here -- neither the time nor the time zone may
be omitted, none of the alternate ISO formats are permitted, and
the punctuation must be as specified here, Except:
2. ISO date described here differs from the PICS 1.1 and ISO 8601:1988
date and time format. PICS 1.1 uses '.' as separators while the ISO
standard calls for '-'. DSig supports both syntaxes. PICS 1.1 also
does not support the optional seconds and fractions of seconds fields
and permits minutes to range from 0 to 60.
Signing
Since even a single DSig 1.0 signature label must be represented as a PICS
1.1 label list, it is important to understand the structure of such a list.
This is explained above in the section PICS
1.1 labels and label lists. Here again is a structural representation
of a PICS 1.1 label list:
(PICS-1.1
<service 1 url> [service 1 option...]
labels [label 1 options...] [label 1 signature]
ratings (<category> <value> ...)
[label 2 options...] [label 2 signature]
ratings (<category> <value> ...)
...
<service 2 url> [service 2 option...]
labels [label 3 options...] [label 3 signature]
ratings (<category> <value> ...)
[label 4 options...] [label 4 signature]
ratings (<category> <value> ...)
...
...
)
Signing a label
The process for signing a label is fairly straightforward whether the label
list containing the label is made up of a single label or a series of labels.
First we create an equivalent standalone label for the label to be signed.
Then the equivalent standalone label is canonicalized (similar to canonicalizing
a PICS label for transmission). Finally, a digital signature is generated,
inserted into a sigblock extension, and that extension is
placed in the label as a label extension. An equivalent standalone label
can have at most one resinfo extension (which it may inherit
from the service options).
Creating an equivalent standalone label
An equivalent standalone label is a PICS 1.1 label list containing a single
label. The single label must be normalized to a form where all options
are label options (this includes extension options) and the sigblock
extension (if present) has been removed. From
the example label list above, label 4 could be reduced to the single label:
(PICS-1.1
<service 2 url>
labels [service 2 option...] OVERRIDDEN BY [label 4 option...]
ratings ([label 4 ratings ...]))
This is not yet an equivalent standalone label. We still need to take into
account any modifications denoted by "include" or "exclude" specifiers
in the sigblock extension. (If the signature is being created
the application knows which fields it wants to include in or exclude from
the equivalent standalone label. The "include" and "exclude" options convey
this information to applications trying to verify the signature.) The resulting
label list is the equivalent standalone label.
Canonicalization of the equivalent standalone
label for signing
-
For a given PICS 1.1 label, insert a single space character between any
two tokens. PICS 1.1 tokens include left and right parenthesis, symbols,
quoted-strings, and numbers. Symbols are case insensitive and converted
to lowercases. Tokens in multi-value syntax are considered symbols. Do
not insert spaces for either the leading left parenthesis or the the trailing
right parenthesis of a PICS 1.1 label list. No carriage-returns or linefeeds
are present in a cannonicalized label.
-
A normalized DSig-1.0 label consists of three parts in order: the PICS
1.1 header, the options, and the ratings. The header part is the 'pics-1.1'
symbol followed by the serviceURL.
-
The option part is headed by the label keyword "l", followed by a set of
PICS-1.1 options, including the extensions. The set of options, including
the extensions, are determined by the option-list and the extension-list
fields of the "exclude" or the "include" option in the signature
suite. The options are sorted alphabetically (i.e. lexicographically ordered
by the unquoted US ASCII characters) by their shortest names
(i.e. use full instead of complete-label, exp instead
of until). Extension options are sorted first by "extension"
and then by the "extension" URL.
-
The rating part is headed by the rating keyword "r", followed by a set
of transmit name and value pairs. The set of transmit-name and value pairs
are determined by the "rating-list" field of the "include"
or "exclude" option in the signature. Transmit names are sorted
alphabetically.
-
When the client computes the equivalent standalone label format described
above, it will use all options available to it: both service and label
options. This implies a constraint on the server when it decides what options
to include in the transmitted set. The transmitted set must include all
options necessary as either service or label options to create the same
equivalent standalone label as was signed.
An Example
The following example illustrates a step-by-step process to sign a PICS
1.1 label.
Step 1: creates a PICS 1.1 label
(PICS-1.1 "http://www.gcf.org/v2.5"
by "John Doe"
labels
for "http://www.w3.org/PICS/DSig/Overview"
on "1994.11.05T08:15-0500"
ratings (suds 0.5 density 0 color 1))
Step 2: compute the hashes of the document, create the resinfo
extension, and insert it in the label
(PICS-1.1 "http://www.gcf.org/v2.5"
by "John Doe"
labels
for "http://www.w3.org/PICS/DSig/Overview"
extension
(optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"
("http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "aba21241241=")
("http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="
"1997-02-05T08:15-0500"))
on "1994.11.05T08:15-0500"
ratings (suds 0.5 density 0 color 1))
Step 3: canonicalize the label
(NOTE: Carriage-returns in the above example are for
display purposes only. Properly canonicalized, this label would have no
carriage-returns.)
( PICS-1.1 "http://www.gcf.org/v2.5" l by "John Doe"
extension ( optional
"http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0" (
"http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="
"1997-02-05T08:15-0500" ) ( "http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0"
"aba21241241=" ) ) for "http://www.w3.org/PICS/DSig/Overview"
on "1994.11.05T08:15-0500" r ( color 1 density 0 suds 0.5 ) )
Step 4: sign the canonicalized form of the label and insert it in the label
(PICS-1.1 "http://www.gcf.org/v2.5"
by "John Doe"
labels
for "http://www.w3.org/PICS/DSig/Overview"
extension
(optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"
("http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "aba21241241=")
("http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="
"1997-02-05T08:15-0500"))
extension
(optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"
("AttribInfo"
("http://www.w3.org/PICS/DSig/X509-1_0" "efe64685685=")
("http://www.w3.org/PICS/DSig/X509-1_0"
"http://SomeCA/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK")
("http://www.w3.org/PICS/DSig/pgpcert-1_0" "ghg86807807=")
("http://www.w3.org/PICS/DSig/pgpcert-1_0"
"http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at"))
("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/RSA-MD5-1_0"
("byKey" (("N" "aba212412412=")
("E" "3jdg93fj")))
("on" "1996-12-02T22:20-0000")
("SigCrypto" "3j9fsaJ30SD=")))
on "1994.11.05T08:15-0500"
ratings (suds 0.5 density 0 color 1))
And now we have a valid DSig-1.0 label.
Signing Notes
While PICS allows labels to be truncated to reduce their size, if this
is done in DSig 1.0 after signing, the signature will no longer be valid.
An alternative is to distribute an unsigned label with the complete
option pointing to a full, signed label. Client software in need of a signed
label can de-reference the complete option's URL to retrieve a complete,
signed label.
Appendix 1: Service Resource Information
There is a security hole in the above proposal. The semantics of the assertions
(ratings) in a PICS 1.1 label are defined by the rating service, and the
only information about the rating service contained within the label itself
is the service's URL. Since the human-readable description pointed to by
that URL is what defines the rating semantics, it is possible under the
current scheme for the semantics of the rating service to change after
the label has been created without invalidating the label.
If this is a concern, a simple policy in the trust engine that evaluates
signatures could be established to require a separate signature label on
the service description file.
Appendix 2: Transporting DSig 1.0 Labels
DSig 1.0 labels are PICS 1.1 compliant and thus may be transported in the
same way as PICS 1.1 labels. PICS Label Distribution Label Syntax and Communication
Protocols Version 1.1 identifies three ways that a PICS label can be transported:
In an HTML document, With a document transported via a protocol that uses
RFC-822 headers, or Separately from the document.
Labels may also exist on their own, referenced via a URL. When the URL
is de-referenced it returns an item of type application/pics-labels that
contains a label list.
The specifications for embedding a PICS label in an HTML document are
well defined. It is possible to use DSig labels in document other than
HTML. To do this, a specification for how the label is embedded in that
document type and how the document is normalized for hashing into the label
must be created.
Appendix 3: Conforming Implementations
In order to conform with this Recommendation, an implementation must
support:
- resinfo 1.0 hash algorithms:
- sigblock 1.0 signature suites:
Acknowledgments
-
John Carbajal<EMAIL_ADDRESS>-
Rosario Gennaro<EMAIL_ADDRESS>-
Amy Katriel<EMAIL_ADDRESS>-
Rohit Khare<EMAIL_ADDRESS>-
Paul Lambert<EMAIL_ADDRESS>-
Jim Miller<EMAIL_ADDRESS>-
Hemma Prafullchandra<EMAIL_ADDRESS>-
Rob Price<EMAIL_ADDRESS>-
Paul Resnick<EMAIL_ADDRESS>-
Pankaj Rohatgi<EMAIL_ADDRESS>-
Andreas Sterbenz<EMAIL_ADDRESS>Reference Materials
-
N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mai Extensions) Part
One: Mechanisms for Specifying and Describing the Format of Internet Message
Bodies", RFC 1521, 09/23/1993. ftp://ds.internic.net/rfc/rfc1521.txt
-
T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators (URLs)",
RFC 1738, 12/20/94. ftp://ds.internic.net/rfc/rfc1738.txt
-
Digital Signature Label Architecture, W3C Working Draft, http://www.w3.org/TR/WD-DSIG-label-arch
-
Rating Services and Rating Systems and Their Machine Readable Descriptions
Version 1.1, W3C Recommendation, http://www.w3.org/TR/REC-PICS-services
-
PICS Label Distribution Label Syntax and Communication Protocols Version
1.1, W3C Recommendation, http://www.w3.org/TR/REC-PICS-labels
Authors Addresses
Yang-hua Chu
Carnegie Mellon University
Department of Computer Science
Wean Hall 5123
5000 Forbes Avenue
Pittsburgh, PA 15213
Email<EMAIL_ADDRESS>Philip DesAutels
Formerly: Project Manager, Technology and Society Domain, W3 Consortium
Current Address:
Senior Principal Architect
MatchLogic, Inc.
400 S. McCaslin Blvd.
Louisville, Colorado 80027
Email<EMAIL_ADDRESS>Brian LaMacchia
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email<EMAIL_ADDRESS>Peter Lipp
IAIK, University of Technology, Graz
Institute for Applied Information Processing and Communications
Klosterwiesgasse 32/I, A-8010 Graz, Austria
Email<EMAIL_ADDRESS>Change History
1998-06-01 Make the document fully
valid HTML 4.0
1998-05-27 First version published on
http://www.w3.org/TR


{% extends 'api/index.html' %} {% block aside %}
Overview UTF-8 encoding Datetime format Response types API errors Endpoints Get list of files Create new file Get file content Update file Delete file Get file meta {% endblock %}It is a test-task for 'python backend-dev' vacancy.
A source code stored on GitHub.
For testing use URL http://freenoth.pythonanywhere.com
+ endpoint
Based on:
An API provides a simple methods to work with filesystem on web-server. It has a flat structure (without folders). You can upload a file into web-server, download, update or delete it, also you can view a file metadata and a full list of stored files.
All the strings passed from API have UTF-8 encoding.
Dates used in API represents as strings and have the following format:
'31.12.2016 23:59:59 +0000'
It use strftime
format:
'%d.%m.%Y %H:%M:%S %z'
An API that provides to get file content have a binary data response. All other API and error handling have JSON-format responses. Every JSON have the same structure like:
{
"status": "OK",
"code": 0,
"data": ...
}
Status
can be 'OK'
or 'Error'
depending on API execution. 'OK'
means that API objective has benn succesfully completed.
Code
implements an http status-code of response.
Data
contains an useful information, such as an error description if error uccurs, or information about files.
There is a correct response example:
$ curl -H 'Accept: application/json; indent=4' http:// <some URL> /api/files/10/meta/
{
"status": "OK",
"code": 200,
"data": {
"name": "example.txt",
"size": 454,
"mime_type": "text/plain",
"ext": ".txt",
"created": "01.01.2016 00:44:52 +0000",
"modified": "20.10.2016 13:58:01 +0000"
}
}
When errors occurs the response will have a status
= 'Error'
. Some additional information can be placed in 'data'
field. For example:
$ curl -H 'Accept: application/json; indent=4' -X POST http:// <some URL> /api/files/
{
"status": "Error",
"code": 400,
"data": {
"file": [
"No file was submitted."
]
}
}
Every endpoint will return an 405 Method not allowed
if wrong method used.
An every error response have a right code
value, that can help to identificate an error. For more information about spicific status-codes read API description.
This endpoint provide a method to get a full list of files stored on server.
PARAMETERS
No parameters.
RETURNS
The response data
field contains a list of files, each file represented as a dictionary with id
and name
keys. If there is no files on server an empty-list will be returned.
id
- can be used in other APIs as file-id
parameter to define with which file to work.name
- name of file.ERRORS
There is no registered error handlings for this endpoint.
EXAMPLES
Let`s get a list of files:
$ curl -H 'Accept: application/json; indent=4' http://freenoth.pythonanywhere.com/api/files/
HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "OK",
"code": 200,
"data": [
{
"id": 1,
"name": "test.txt"
},
{
"id": 2,
"name": "example.txt"
}
]
}
Or using python requests
lib:
>>> import requests
>>> url = 'http://freenoth.pythonanywhere.com/api/files/'
>>> res = requests.get(url)
>>> res.status_code
200
>>> res.content
b'{"status":"OK","code":200,"data":[{"id":1,"name":"test.txt"},{"id":2,"name":"example.txt"}]}'
This endpoint provide a method to upload a file into the server.
PARAMETERS
file
- a file type parameter that spicified a file to upload.
RETURNS
It returns a JSON-response with information about operation success or errors. In case of success data
field will contain a dictionary with id
and name
that represent new file (structure like in list of files API) and code
will be a 201 Created
.
ERRORS
A some errors can occurs during execution:
409 Conflict
- if uploaded file already exists on server (means that file name is busy, not file identity).400 Bad request
- if there is an errors during file validation or no file was submited.EXAMPLES
If html-form is used, it should have a enctype
with value multipart/form-data
, like this:
<form method="post" action="/api/files/" enctype="multipart/form-data">
<input name="file" value="" type="file">
<input value="POST" type="submit">
</form>
Let`s try curl:
$ curl -H 'Accept: application/json; indent=4' -i -X POST \
-F<EMAIL_ADDRESS>http://freenoth.pythonanywhere.com/api/files/
HTTP/1.1 201 Created
Content-Type: application/json
{
"status": "OK",
"code": 201,
"data": {
"id": 10,
"name": "README.txt"
}
}
Or python requests
lib:
>>> import requests
>>> url = 'http://freenoth.pythonanywhere.com/api/files/'
>>> files = {'file': open('test.doc', 'rb')}
>>> res = requests.post(url, files=files)
>>> res.status_code
201
>>> res.content
b'{"status":"OK","code":201,"data":{"id":12,"name":"test.doc"}}'
This endpoint provide a method to download a file from the server.
PARAMETERS
file-id
- an integer id that specified a file to download.
RETURNS
It returns a binary content of the specified file in case of success or a JSON-responce in case of error.
ERRORS
A some errors can occurs during execution:
404 Not found
- if passed id
and associated file does not exists.EXAMPLES
Let`s get some file from server:
$ curl -i http://freenoth.pythonanywhere.com/api/files/8/
HTTP/1.1 200 OK
Content-Type: ('application/msword', None)
Content-Length: 67469
Content-Disposition: attachment; filename=test.doc
Content: binary-data
Or python requests
lib:
>>> import requests
>>> url = 'http://freenoth.pythonanywhere.com/api/files/8/'
>>> res = requests.get(url)
>>> res.status_code
200
>>> res.headers['Content-Length']
'67469'
>>> res.content
b'...'
This endpoint provide a method to update file content on the server from content of uploaded file.
PARAMETERS
file-id
- an integer id that specified a file to download.
file
- a file type parameter that spicified a file to upload.
Note: the name of uploaded file will be ignored, file used to update a content of the file that associated with file-id
.
RETURNS
It returns a JSON-response with information about operation success or errors. In case of success data
field will contain a dictionary with id
and name
that represent specified file (structure like in list of files API) and code
will be a 200 Ok
.
ERRORS
A some errors can occurs during execution:
404 Not found
- if passed id
and associated file does not exists.400 Bad request
- if there is an errors during file validation or no file was submited.EXAMPLES
Let`s update some file on server:
$ curl -H 'Accept: application/json; indent=4' -i -X PUT \
-F<EMAIL_ADDRESS>http://freenoth.pythonanywhere.com/api/files/9/
HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "OK",
"code": 200,
"data": {
"id": 9,
"name": "test.txt"
}
}
Or python requests
lib:
>>> import requests
>>> url = 'http://freenoth.pythonanywhere.com/api/files/9/'
>>> files = {'file': open('test.doc', 'rb')}
>>> res = requests.put(url, files=files)
>>> res.status_code
200
>>> res.content
b'{"status":"OK","code":200,"data":{"id":9,"name":"test.txt"}}'
This endpoint provide a method to delete a file on the server.
PARAMETERS
file-id
- an integer id that specified a file to delete.
RETURNS
It returns a JSON-response with result of deleting or error information. See more in examples.
ERRORS
A some errors can occurs during execution:
404 Not found
- if passed id
and associated file does not exists.EXAMPLES
Trying to delete file:
$ curl -H 'Accept: application/json; indent=4' -i -X DELETE \
http://freenoth.pythonanywhere.com/api/files/2/
HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "OK",
"code": 200,
"data": {
"result": [
"File deleted"
]
}
}
Or python requests
lib:
>>> import requests
>>> url = 'http://freenoth.pythonanywhere.com/api/files/8/'
>>> res = requests.delete(url)
>>> res.status_code
200
>>> res.content
b'{"status":"OK","code":200,"data":{"result":["File deleted"]}}'
This endpoint provide a method to get some metadata of the file on the server.
PARAMETERS
file-id
- an integer id that specified a file to get metadata.
RETURNS
It return a JSON-response that represent a metadata of the specified file or an error if occurs. A response data
field contain a dictionary that represent file metadata, that contain information about filename, filesize in bytes, type of the content (Media type), file extension, and information about date of file creation and last modifed.
ERRORS
A some errors can occurs during execution:
404 Not found
- if passed id
and associated file does not exists.EXAMPLES
Let`s get some meta:
$ curl -H 'Accept: application/json; indent=4' -i \
http://freenoth.pythonanywhere.com/api/files/10/meta/
HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "OK",
"code": 200,
"data": {
"name": "README.txt",
"size": 235,
"mime_type": "text/plain",
"ext": ".txt",
"created": "01.11.2016 12:41:36 +0000",
"modified": "06.12.2016 17:01:54 +0000"
}
}
Or python requests
lib:
>>> import requests
>>> url = 'http://freenoth.pythonanywhere.com/api/files/10/meta/'
>>> res = requests.get(url)
>>> res.status_code
200
>>> res.content
b'{"status":"OK","code":200,"data":{"name":"README.txt","size":235,
"mime_type":"text/plain","ext":".txt","created":"06.12.2016 03:41:36 +0000"
,"modified":"06.12.2016 03:41:36 +0000"}}'


--- layout: post title: 'Dolphin games: no mere child’s play?' date: 2005-12-04 00:00:00 categories: animalia play ---
Dolphin games: no mere child’s play?: "Dolphins seem to deliberately make their games difficult, possibly in order to learn from them. And such pastimes may play a key role in the development of culture and in evolution—both among dolphins and other species, including humans. "


| Top |
| CK_RV | p11_kit_initialize_registered () |
| CK_RV | p11_kit_finalize_registered () |
| CK_FUNCTION_LIST_PTR * | p11_kit_registered_modules () |
| char * | p11_kit_registered_module_to_name () |
| CK_FUNCTION_LIST_PTR | p11_kit_registered_name_to_module () |
| char * | p11_kit_registered_option () |
| CK_RV | p11_kit_initialize_module () |
| CK_RV | p11_kit_load_initialize_module () |
| CK_RV | p11_kit_finalize_module () |
| #define | P11_KIT_DEPRECATED_FOR() |
These functions have been deprecated from p11-kit and are not recommended for general usage. In large part they were deprecated because they did not adequately insulate multiple callers of a PKCS#11 module from another, and could not support the 'managed' mode needed to do this.
CK_RV
p11_kit_initialize_registered (void
);
p11_kit_initialize_registered
is deprecated and should not be used in newly-written code.
Since: 0.19.0: Use p11_kit_modules_load()
instead.
Initialize all the registered PKCS#11 modules.
If this is the first time this function is called multiple times consecutively within a single process, then it merely increments an initialization reference count for each of these modules.
Use p11_kit_finalize_registered()
to finalize these registered modules once
the caller is done with them.
If this function fails, then an error message will be available via the
p11_kit_message()
function.
CK_RV
p11_kit_finalize_registered (void
);
p11_kit_finalize_registered
is deprecated and should not be used in newly-written code.
Since 0.19.0: Use p11_kit_modules_release()
instead.
Finalize all the registered PKCS#11 modules. These should have been
initialized with p11_kit_initialize_registered()
.
If p11_kit_initialize_registered()
has been called more than once in this
process, then this function must be called the same number of times before
actual finalization will occur.
If this function fails, then an error message will be available via the
p11_kit_message()
function.
CK_FUNCTION_LIST_PTR *
p11_kit_registered_modules (void
);
p11_kit_registered_modules
is deprecated and should not be used in newly-written code.
Since 0.19.0: Use p11_kit_modules_load()
instead.
Get a list of all the registered PKCS#11 modules. This list will be valid
once the p11_kit_initialize_registered()
function has been called.
The returned value is a NULL
terminated array of
CK_FUNCTION_LIST_PTR
pointers.
The returned modules are unmanaged.
char *
p11_kit_registered_module_to_name (CK_FUNCTION_LIST_PTR module
);
p11_kit_registered_module_to_name
is deprecated and should not be used in newly-written code.
Since 0.19.0: Use p11_kit_module_get_name()
instead.
Get the name of a registered PKCS#11 module.
You can use p11_kit_registered_modules()
to get a list of all the registered
modules. This name is specified by the registered module configuration.
CK_FUNCTION_LIST_PTR
p11_kit_registered_name_to_module (const char *name
);
p11_kit_registered_name_to_module
is deprecated and should not be used in newly-written code.
Since 0.19.0: Use p11_kit_module_for_name()
instead.
Lookup a registered PKCS#11 module by its name. This name is specified by the registered module configuration.
char * p11_kit_registered_option (CK_FUNCTION_LIST_PTR module
,const char *field
);
p11_kit_registered_option
is deprecated and should not be used in newly-written code.
Since 0.19.0: Use p11_kit_config_option()
instead.
Lookup a configured option for a registered PKCS#11 module. If a
NULL
module argument is specified, then this will lookup
the configuration option in the global config file.
CK_RV
p11_kit_initialize_module (CK_FUNCTION_LIST_PTR module
);
p11_kit_initialize_module
is deprecated and should not be used in newly-written code.
Since 0.19.0: Use p11_kit_module_initialize()
instead.
Initialize an arbitrary PKCS#11 module. Normally using the
p11_kit_initialize_registered()
is preferred.
Using this function to initialize modules allows coordination between
multiple users of the same module in a single process. It should be called
on modules that have been loaded (with dlopen()
for example) but not yet
initialized. The caller should not yet have called the module's
C_Initialize
method. This function will call
C_Initialize
as necessary.
Subsequent calls to this function for the same module will result in an initialization count being incremented for the module. It is safe (although usually unnecessary) to use this function on registered modules.
The module must be finalized with p11_kit_finalize_module()
instead of
calling its C_Finalize
method directly.
This function does not accept a CK_C_INITIALIZE_ARGS
argument.
Custom initialization arguments cannot be supported when multiple consumers
load the same module.
If this function fails, then an error message will be available via the
p11_kit_message()
function.
CK_RV p11_kit_load_initialize_module (const char *module_path
,CK_FUNCTION_LIST_PTR *module
);
p11_kit_load_initialize_module
is deprecated and should not be used in newly-written code.
Since 0.19.0: Use p11_kit_module_load()
instead.
Load an arbitrary PKCS#11 module from a dynamic library file, and
initialize it. Normally using the p11_kit_initialize_registered()
function
is preferred.
Using this function to load and initialize modules allows coordination between
multiple users of the same module in a single process. The caller should not
call the module's C_Initialize
method. This function will call
C_Initialize
as necessary.
If a module has already been loaded, then use of this function is unnecesasry.
Instead use the p11_kit_initialize_module()
function to initialize it.
Subsequent calls to this function for the same module will result in an initialization count being incremented for the module. It is safe (although usually unnecessary) to use this function on registered modules.
The module must be finalized with p11_kit_finalize_module()
instead of
calling its C_Finalize
method directly.
This function does not accept a CK_C_INITIALIZE_ARGS
argument.
Custom initialization arguments cannot be supported when multiple consumers
load the same module.
If this function fails, then an error message will be available via the
p11_kit_message()
function.
CK_RV
p11_kit_finalize_module (CK_FUNCTION_LIST_PTR module
);
p11_kit_finalize_module
is deprecated and should not be used in newly-written code.
Since 0.19.0: Use p11_kit_module_finalize()
and
p11_kit_module_release()
instead.
Finalize an arbitrary PKCS#11 module. The module must have been initialized
using p11_kit_initialize_module()
. In most cases callers will want to use
p11_kit_finalize_registered()
instead of this function.
Using this function to finalize modules allows coordination between
multiple users of the same module in a single process. The caller should not
call the module's C_Finalize
method. This function will call
C_Finalize
as necessary.
If the module was initialized more than once, then this function will
decrement an initialization count for the module. When the count reaches zero
the module will be truly finalized. It is safe (although usually unnecessary)
to use this function on registered modules if (and only if) they were
initialized using p11_kit_initialize_module()
for some reason.
If this function fails, then an error message will be available via the
p11_kit_message()
function.


| About Dailyrotten |
|
Feedback
If you like this page, hate it, or would like to suggest changes,
<EMAIL_ADDRESS>is listening. This page
is experimental and somewhat different from what we usually offer, so please
do send your feedback.
Adding Stories
If you are a rotten newshound and you would like to suggest a story,
visit our submit page to
send us the URL. Stories that are accepted will have your name credited.
Viewership
On the first full day this page went live, 100,000 people visited this Rotten
News page. Of course that was the day after the WTC attacks, so that number is
somewhat distorted. Right now this page gets between 50,000 and 75,000 people
every day.
Linking
We encourage everyone to link to this page; if you like it, others probably
will as well.
Other Rotten
Rotten
Gaping Maw
Celebrity Morgue
Mugshots
Rotten Store
Shockumentary
Rate My Poo
Rate My Kitten
Rate My Finger
Penny Postcards
Phallic
Dr. Sputnik
Boners
Dead Pool
NNDB
Home
Make Dailyrotten your start page
|
|
|
March 03, 2003
Woman's remains to be made into diamonds
Arizona Republic | Submitted by: Boat6float
"Bill Sefton paid Chicago-based LifeGem $16,000 to $18,000 for six diamonds, ranging in size from a quarter- to a half-carat, that were made from the carbon contained in the body of his daughter, Valerie Sefton. . . He only recently received the diamonds, keeping one to put in his wedding ring and giving the others to family members... Sefton, 51, sees his daughter's shining spirit by just looking at the center stone of his ring." Incredibly the body can produce up to 50 gems.
|
|
Read article...
|
|
Landlord peeps on tenant, court says OK fine
New York Post | Submitted by: wingnut
"I bet you it's an animal in the crawl space," Joe said, and climbed up there to prove it. He was right.While in the attic, he discovered a wooden walkway and a video cable leading from the smoke detector that snaked across the attic to a trap door. Joe discovered the trap door opened into a closet in a storage room in Schultz's home, where the cable was plugged into a video recorder and TV... the cops told her that... what he had done to her in his own house was by law not a crime in New York."
|
|
Read article...
|
|
We've seen it all before, say teen sex surfers
Sydney Morning Herald | Submitted by: wingnut
"I reckon you'd be hard-pressed to find a 17 year old that hasn't seen it... You just get over it.... It's annoying searching for something else and having it pop up"... For others, however, pornography is so common it has become something of a joke. "We just do it [download pornography] because it is available and, if it is free, it's free fun, to look at and laugh at."
|
|
Read article...
|
|
Many human shields actually pansy-assed
Fox News | Submitted by: jayman
"Some of the peace activists who went to Iraq to serve as human shields in the event of war returned home, fearing for their safety, a spokesman said Sunday... The human shields are mostly European activists who drove from London to Baghdad in two double-decker buses last month, intending to guard civilian sites from a U.S.-led military attack."
|
|
Read article...
|
|
Artificial foot crafted for frostbitten duck
KMBC-TV 9 Kansas City | Submitted by: Tanya Hunter
"Daffney the duck will get a new chance at waddling, thanks to an artificial foot. The 8 month old duck lost one foot to frostbite and is close to losing the other. Now, some Iowa students are crafting prosthetic feet for the duck... The duck's owner, Linda Kennedy, teaches surgical technology at Kirkwood Community College in Cedar Rapids. She said the project is proving to be a great learning experience for students in several departments."

BayArea.com | Submitted by: Dirty Sammy
"One of his alleged victims, unidentified in court records, called Ponciroli on the phone and the conversation was recorded as evidence... During the conversation, the priest told the man he didn't remember molesting him, but apologized, saying that it could have happened... "I apologize for what you went through. And I don't know if I did it or not. And I pray for you, my victims every day.  I'm not trying to take any excuse for it. I didn't know any better, really."
|
|
Read article...
|
|
No respect for your seniors
Denver Post | Submitted by: Dirty Sammy
"A Walsenburg teenager has been arrested in the brutal stabbing death of the town's 91 year old former mayor, a crime investigators believe may have been a "thrill killing" with Satanic undertones... The group talked about killing people and Romero mentioned he would decapitate someone if he killed, according to the friend."
|
|
Read article...
|
|
Interesting conversation piece to be auctioned
News Corporation | Submitted by: Dirty Sammy
"The spear used by a Hawaiian native to kill explorer Captain James Cook is to be auctioned in Scotland this month... The weapon was fashioned into a walking stick and handed down through the family of one of Cook's fellow naval officers."
|
|
Read article...
|
|
Young Iranians arrested for Internet dating
Hindustan Times | Submitted by: Rollo Tomasi
"Some people were using an Internet site to allow girls and boys to talk and arrange meetings in a place in north Tehran where they had illegal relations," said General Ahmad Rouzbehani, a commander of the Basij militia... Police and volunteer militias such as the Basij regularly mount raids on mixed parties to enforce Iran's strict morality laws." This must be stopped, it could lead to dancing.
|
|
Read article...
|
|
Arizona to release insane killers
Arizona Republic | Submitted by: Boat6float
"Stevenson was judged guilty except insane and sent to the Arizona State Hospital... After [9] years of treatment, doctors judged Stevenson sane and released him last year... Four murderers, including Stevenson, have been released from the hospital since 1999."
|
|
Read article...
|
|
Mom who dropped son into river makes plea
North Jersey Media | Submitted by: anonymous
"Instead of saying no to a date, a mother who couldn't find a baby sitter for her 16 month-old son, decided to dump him in the Great Falls of Paterson, the 2nd-highest falls on the east coast, where Niagara is number one. "This baby went over the falls, and he may have been dead, or he may have been alive, and that has really bothered me," said the judge."
|
|
Read article...
|
|
Dali artwork worth $500K displayed at prison, stolen
Wire Services | Submitted by: Zircon
"The Dali piece is a 4 by 3 foot depiction in watercolor and charcoal. A 1985 appraisal concluded it was worth at least $175,000, Antenen said, but an art expert told The New York Times in 2001 that it was worth at least three times that amount." Exactly the kind of thing you want hanging in a prison.
|
|
Read article...
|
|
Teenage boy was HARPOONED
online.ie | Submitted by: KC
"A teenage boy was fighting for his life in hospital today after a three-pronged harpoon was shot into his eye during a late night row... The harpoon, which has a head consisting of three prongs several inches long and several inches apart, lodged in the 15 year old's face after being fired during the fracas in Thatcham, Berkshire."
|
|
Read article...
|
|
LMFAO
Wire Services | Submitted by: SF
Why can't these reporters STFU when there's no news.
|
|
Read article...
|
|
Khalid Shaikh Mohammed backgrounder
Daily Rotten | Submitted by: Soylent
"On the surface, Khalid's time in the Philippines was more distinguished for its flashy playboy lifestyle than for the notches added to his belt. Khalid and Yousef went on scuba diving expeditions and frequented local discotechques "filled with mirrors, flashing lights and bikini-clad dancers," according to the LA Times. They held alcohol-soaked parties and made notably non-devout booty calls to infidels with pouty breasts all over Manila."
|
|
Read article...
|
|
|
|
|


JDZ
Twitter GitHub LinkedInActive Record
03/05/15
Web applications often require a lot of data that is constantly in flux. When dealing with a lot of data, it helps to be able to keep track of that data in an organized way.
Active record is a pattern for facilitating something called Object Relational Mapping, and was originally defined by Martin Fowler in his book Patterns of Enterprise Application Architecture. This means that accessing and storing data about objects in databases is made possible without actually having to go to the trouble of writing SQL queries.
In Ruby on Rails, ActiveRecord is a library that provides a common base for models, and is used to implement the active record pattern.
For example, if you cause a class to inherit from the class Base in the ActiveRecord library, you gain access to methods that allow you to create and pull data from a database without writing any SQL. Methods in ActiveRecord’s classes allow one to easily turn class attributes into columns in SQL and new objects into rows.
class User < ActiveRecord::Base
To create the table in the database, it is necessary to create a schema class that inherits the tools from a class in ActiveRecord called Migration. This may be confusing, remember that once you create a class that inherits from Base, you gain methods to read and write new rows and columns in a data base, and that is not the same as actually making a new table.
class UserTable < ActiveRecord::Migration
Again, this is all done through writing easy-to-read Ruby, making the life of the programmer a lot easier.
One fundamental part of AR is that it stores the relationship between models. These relationships are called 'associations'. As part of the Base class, you can impart on objects the relationships that they have with other objects. These relationships will remind you of one-to-one, one-to-many, and many-to-many relatiohsips in your typical relational data-base. Not only does active record store these relationships in a data-base like you would expect, it also adds methods to the objects themselves that allow you to call on these relationships. If there were no associations between models, the objects themselves wwould be unable to tell us who they belong to. For instance, if you have a Car class and a Person class, you might want each Car to only have one owner.
Create the Car class with the Base instance method has_one
and then followed by the name of the class Person
.
class Car < ActiveRecord::Base has_one :person end
And you would do likewise for the creation of the Person class accept with the has_many
method.
class Person < ActiveRecord::Base has_many :cars
The varying names of the models have to do more with their table names than with their class names. Because Rails will automatically pluralize the name of a class to make a table for that class, Rails knows what you are talking about when you pluralize the name with the corresponding has_many method.
The last thing I will talk about when it comes to AR is Validations. Validations are again part of the Base class. You will use them in order to set conditions for the creation of your objects in the database. For instance:
class Car < ActiveRecord::Base validates :type, presence: true end
This will prevent a car from being added to the database that doesn't have a type defined. You can see how this will prevent your database from being poluted with unusable data. You get to set the conditions for the creation of new data to your database.
There is much more to discuss on each of these topics. But I hope that this gives you a brief overview of ActiveRecord.
If you are interested in learning more about ActiveRecord, please see these links:
Active record pattern ActiveRecord in Rails ORM Validations Associations Modeling Users


--- layout: page title: "Andy Yao" tagline: "Jr Dev. looking for a job" --- {% include JB/setup %}
Electrical Engineering degree with IT and programming experience. Tends to lean towards defensive coding and clean code, and TDD after being introduced to the concept. Occasional gamer, model builder, and baker (might need a bit of work) who's always looking for the next project to complete.


Loading data...
Where Melvin Carter won St. Paul mayoral race
The map below shows the percentage point margin in first round voting for each top candidate by precinct. Hover over each precinct for details.
Source: Minnesota Secretary of State


CREATE [ TEMPORARY | TEMP ] SEQUENCE name [ INCREMENT [ BY ] increment ] [ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ] [ START [ WITH ] start ] [ CACHE cache ] [ [ NO ] CYCLE ] [ OWNED BY { table.column | NONE } ]
CREATE SEQUENCE creates a new sequence number generator. This involves creating and initializing a new special single-row table with the name name. The generator will be owned by the user issuing the command.
If a schema name is given then the sequence is created in the specified schema. Otherwise it is created in the current schema. Temporary sequences exist in a special schema, so a schema name cannot be given when creating a temporary sequence. The sequence name must be distinct from the name of any other sequence, table, index, or view in the same schema.
After a sequence is created, you use the functions
nextval
,
currval
, and
setval
to operate on the sequence. These functions are documented in
Section 9.15.
Although you cannot update a sequence directly, you can use a query like:
SELECT * FROM name;
to examine the parameters and current state of a sequence. In particular,
the last_value field of the sequence shows the last value
allocated by any session. (Of course, this value might be obsolete
by the time it's printed, if other sessions are actively doing
nextval
calls.)
If specified, the sequence object is created only for this session, and is automatically dropped on session exit. Existing permanent sequences with the same name are not visible (in this session) while the temporary sequence exists, unless they are referenced with schema-qualified names.
The name (optionally schema-qualified) of the sequence to be created.
The optional clause INCREMENT BY increment specifies which value is added to the current sequence value to create a new value. A positive value will make an ascending sequence, a negative one a descending sequence. The default value is 1.
The optional clause MINVALUE minvalue determines the minimum value a sequence can generate. If this clause is not supplied or NO MINVALUE is specified, then defaults will be used. The defaults are 1 and -263-1 for ascending and descending sequences, respectively.
The optional clause MAXVALUE maxvalue determines the maximum value for the sequence. If this clause is not supplied or NO MAXVALUE is specified, then default values will be used. The defaults are 263-1 and -1 for ascending and descending sequences, respectively.
The optional clause START WITH start allows the sequence to begin anywhere. The default starting value is minvalue for ascending sequences and maxvalue for descending ones.
The optional clause CACHE cache specifies how many sequence numbers are to be preallocated and stored in memory for faster access. The minimum value is 1 (only one value can be generated at a time, i.e., no cache), and this is also the default.
The CYCLE option allows the sequence to wrap around when the maxvalue or minvalue has been reached by an ascending or descending sequence respectively. If the limit is reached, the next number generated will be the minvalue or maxvalue, respectively.
If NO CYCLE is specified, any calls to
nextval
after the sequence has reached its
maximum value will return an error. If neither
CYCLE or NO CYCLE are
specified, NO CYCLE is the default.
The OWNED BY option causes the sequence to be associated with a specific table column, such that if that column (or its whole table) is dropped, the sequence will be automatically dropped as well. The specified table must have the same owner and be in the same schema as the sequence. OWNED BY NONE, the default, specifies that there is no such association.
Use DROP SEQUENCE to remove a sequence.
Sequences are based on bigint arithmetic, so the range cannot exceed the range of an eight-byte integer (-9223372036854775808 to<PHONE_NUMBER>854775807). On some older platforms, there might be no compiler support for eight-byte integers, in which case sequences use regular integer arithmetic (range -2147483648 to +2147483647).
Unexpected results might be obtained if a cache setting greater than one is
used for a sequence object that will be used concurrently by
multiple sessions. Each session will allocate and cache successive
sequence values during one access to the sequence object and
increase the sequence object's last_value accordingly.
Then, the next cache-1
uses of nextval
within that session simply return the
preallocated values without touching the sequence object. So, any
numbers allocated but not used within a session will be lost when
that session ends, resulting in "holes" in the
sequence.
Furthermore, although multiple sessions are guaranteed to allocate
distinct sequence values, the values might be generated out of
sequence when all the sessions are considered. For example, with
a cache setting of 10,
session A might reserve values 1..10 and return
nextval
=1, then session B might reserve values
11..20 and return nextval
=11 before session A
has generated nextval=2. Thus, with a
cache setting of one
it is safe to assume that nextval
values are generated
sequentially; with a cache setting greater than one you
should only assume that the nextval
values are all
distinct, not that they are generated purely sequentially. Also,
last_value will reflect the latest value reserved by
any session, whether or not it has yet been returned by
nextval
.
Another consideration is that a setval
executed on
such a sequence will not be noticed by other sessions until they
have used up any preallocated values they have cached.
Create an ascending sequence called serial, starting at 101:
CREATE SEQUENCE serial START 101;
Select the next number from this sequence:
SELECT nextval('serial'); nextval --------- 101
Select the next number from this sequence:
SELECT nextval('serial'); nextval --------- 102
Use this sequence in an INSERT command:
INSERT INTO distributors VALUES (nextval('serial'), 'nothing');
Update the sequence value after a COPY FROM:
BEGIN; COPY distributors FROM 'input_file'; SELECT setval('serial', max(id)) FROM distributors; END;
CREATE SEQUENCE conforms to the SQL standard, with the following exceptions:
The standard's AS <data type> expression is not supported.
Obtaining the next value is done using the nextval()
function instead of the standard's NEXT VALUE FOR
expression.
The OWNED BY clause is a PostgreSQL extension.


Week Two
Note: This is a very, very rough draft…
Things I’ve learned:
- MCV (Model- View- Controller pattern)
- Model: This is where my functions go. Example from class: todo.js
- View: The html file.
-
Controller: My app.js
- Two whole weeks at The Iron Yard. That was a religious experience. Sometimes you just need to channel the higher spirits in order to receive a little Divine help. Needless to say, I have struggled greatly with applying all the information we have learned into coding. Picking my battles and prioritizing have become daily routine.
To further elaborate:
- Vanilla JS is a fascinating language but requires almost exclusivity. When applied to the MVC pattern it becomes a force of its own.  It is challenging to follow and I pretty much get lost most of the time.
- Reviewing the training courses from Code Academy and Code School has helped and I have seen improvement productivity wise and I have also noticed my homework quality has increased. I will make a habit of weekly reviews every weekend.
another entry…
After two weeks of religiously devoting myself to an unknown discipline different from deciphering toddler runes and passive agressivly reading children’s books, I am attached to the idea that joining this program is, and will be, a wonderfully painful diversion. Many challenges arise proving the web developer world an ever changing coding spectrum. As I mentioned in my outlined entries for this week, Vanilla JS has been an immense struggle for myself. And applying it to an MVC pattern has made my brain burn. I admit that I might have compared understanding Vanilla JS as close as auto-flagellation as it can be. Having described those premature feelings about JavaScript, I must say that my feelings have evolved and now I look forward to every challenge.


Yps , Mohali is the school of wonders .Where there are wonderful students who will be the future of the world .


283 Jobs Recommended for You
We need Java Backend Developers who love startup and open-minded environmentYour responsibilities will include: Implement the backend using Java and...
Thành phố Hồ Chí Minh
Lương:4000$
We need Java Backend Developers who love startup and open-minded environmentYour responsibilities will include: Implement the backend using Java and...
Thành phố Hồ Chí Minh
Lương:4000$
We need Java Backend Developers who love startup and open-minded environmentYour responsibilities will include: Implement the backend using Java and...
Thành phố Hồ Chí Minh
Lương:4000$