From faf42fa880e910fc905f5b00989fd4b06aecd354 Mon Sep 17 00:00:00 2001 From: Paul Vojta Date: Tue, 30 Aug 2011 12:32:56 +0200 Subject: Wording fixes * Discussed on mailing list --- secret-service/specification.xml | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'secret-service/specification.xml') diff --git a/secret-service/specification.xml b/secret-service/specification.xml index cbd5a23..507eb78 100644 --- a/secret-service/specification.xml +++ b/secret-service/specification.xml @@ -49,12 +49,12 @@ for retrieval by client applications. The Secret Service stores a secret along with a set of lookup attributes. - The attributes can be used to lookup and retrieve a secret at a later date. The + The attributes can be used to look up and retrieve a secret at a later date. The lookup attributes are not treated as secret material, and the service may choose - to not encrypt attributes when storing them to disk. + not to encrypt attributes when storing them to disk. This API was desigened by GNOME and KDE developers with the goal of having - a common way to store secrets. Its predecessors are the desktop specific APIs + a common way to store secrets. Its predecessors are the desktop-specific APIs used by GNOME Keyring and KWallet. @@ -65,15 +65,15 @@ is a password that an application needs to save and use at a later date. Within this API a secret value is treated as an array of bytes. It is - recommended that a secret consist of user readable text, although this API has + recommended that a secret consist of user-readable text, although this API has no such requirement. Applications wishing to store multiple values as part of a single secret, may - choose to use a textual format to combine these values into one. For example, the - 'desktop' key file format, or XML or another form of markup. + choose to use a textual format to combine these values into one. For example, multiple + values may be combined using the 'desktop' key file format, or XML. Secrets may be encrypted when transferred - to the client application and vice versa. + to or from the client application. The Secret structure encapsulates a secret value along with its transfer encryption parameters. @@ -90,9 +90,9 @@ collection. A collection is similar in concept to the terms 'keyring' or 'wallet'. - Collections and items are represented as DBus objects, and each have their own - object paths. The object path of a collection or item should not change for its lifetime, - under normal circumstances. + Collections and items are represented as DBus objects, and each has its own + object path. Under normal circumstances, the object path of a collection or item + should not change for its lifetime. It is strongly recommended that client applications use lookup attributes to find items rather than @@ -101,9 +101,9 @@ An item or a collection may be initially in a locked state. When in a locked state the item or collection may not be modified in any way, and the secret may not be read. Client applications that require access to the secret of a locked item, or - desire to modify a locked item, should unlock it before use. + desire to modify a locked item, must unlock it before use. - The service must prevent locked collections or items from modification. On + The service must prevent modification of locked collections or items. On such an invalid access the IsLocked error should be raised. -- cgit v1.2.3-70-g09d2