Generic Usenet Account
2009-07-15 21:27:44 UTC
Hi,
I am finding trouble following the OMA-DM TND (Tree and Description)
spec. I don't think this spec is well written and well structured at
all. This is what I have captured from the spec. Did I cover
everything? Kindly correct me.
Thanks,
Choi
TND Highlights
==============
1. All Nodes in the Management Tree can be uniquely addressed with a
URI
2. A URI MUST NOT end with the delimiter "/"
3. the "/" character MUST NOT be part of any Node name
4. The root Node MUST be denoted as "." and not "./"
5. The character sequence "./" MUST NOT be used anywhere else but in
the beginning of a URI
6. All properties, except the ACL, are valid only for the Node to
which they are associated
7. Invoking GET on an Interior Node returns a list of all child Node
names
– If the Interior Node has no children an empty list of child Node
names is returned
– The list of children is returned as an unordered list of names. The
individual names in the list are separated by the character “/”.
– The returned child list has the format node in the meta information
of the result.
8. Permanent Nodes are typically built in at device manufacture.
Permanent Nodes can also be temporarily added to a device by, for
instance, connecting new accessory hardware
9. If a deleted Dynamic Node has children, i.e. is an Interior Node,
the children MUST also be deleted
10. The name of a newly created Dynamic Node SHALL be the last segment
of the URI presented in the Target element of the Add command
11. The Delete command acts strictly on the Node it is addressed at,
and if that Node is a dynamic Interior Node it will be deleted along
with all its child Nodes. If any of these child Nodes have the
AccessType property set to exclude Delete they will be deleted anyway
12. Interior Nodes DO NOT have the size property
13. The properties of a Node are addressed by appending ?
prop=<property_name> to the Node’s URI
– ./DMAcc/xyzInc?prop=ACL
14. The only properties of a node that can be changed are ACL, Name
and Title
15. The ACL and the Title of a Permanent Node can be changed.
However, the Name cannot
– The semantics of most properties are independent of the permanent/
dynamic status of the Node to which they are associated
16. There is no inheritance of property values other than for the ACL
property
17. The access rights granted by an ACL are granted to Server
Identifiers and not to the URI, IP address or certificate of a DM
Server
18. Every Node MUST implement the ACL property, but there can be no
guarantee that the ACL of every Node has a value assigned to it
19. The root Node MUST always have an ACL value
20. If a node has no ACL value assigned to it, it inherits the ACL
value from its first ancestor that defines this value
– This search will always result in a found value since the root Node
MUST have an assigned ACL value
21. A Get command on the ACL property of a Node MUST return the actual
ACL value (which may be NULL) but NOT its inherited value
22. The default value for the root ACL SHOULD be Add=*&Get=*
23. The rules for changing the ACL of a Node are different for
Interior Nodes and Leaf Nodes
– For an interior node, any Server that has Replace access rights
(according to the Node ACL) can change the ACL value
– For a leaf node, a Server that has Replace access rights (according
to the Node ACL) can change all the properties of the node, except the
ACL value itself
– For both types of Nodes the right to change the ACL of the Node is
also controlled by the ACL of the parent Node
– Even if a server has total access to the parent Node according to
the parent’s ACL, this does not imply direct access to the child Node
value. To change a child Node value the child ACL value MUST be
changed first
– Implication: A parent node can anytime control the ACL of the child
node
24. If a server successfully creates a new Node with the Add command,
the value of the Node’s ACL property is initially set to no value,
i.e. <Data/>. This means that the value is inherited from the parent
Node
25. Exception: A Server that creates an interior node is guaranteed
the Add, Delete and Replace rights on the node
26. The only command available to change an ACL is Replace
– If a server wishes to keep the existing entries in an ACL it MUST
read the ACL, perform the needed changes and then Replace the existing
ACL with the new one
27. When a DM Server Identifier is to be deleted from the device, the
Management Tree MUST be scanned for Nodes with ACL’s held by the soon
to be deleted Server Identifier. The reference to this Server
Identifier MUST be deleted
28. If a ServerID has the value ‘*’, then there SHOULD NOT be any
other ServerID values associated with this command in the current ACL
29. Example ACL value:
–
Add=www.sonera.fi-8765&Delete=www.sonera.fi-8765&Replace=www.sonera.fi-8765+321_ibm.com&Get=*
30. There is no ACL representation for the Copy command
– Any result of a Copy command can always be created by a sequence of
other commands
31. The allowed values for the format property are: bin, bool, b64,
chr, int, node, null, xml, date, time, and float
32. Interior Nodes MUST have node as the Format value
33. When a new Node is created, the value of the Name property MUST be
assigned with the value of last segment in the Target URI. However,
it may be changed by the Replace command
34. The Title property is used to store a human readable, alphanumeric
string that provides some information about the Node to which this
property belongs
35. The Type property for a Leaf node is the MIME type of the Leaf
Node’s value
36. The value of Type property for an interior node is either NULL or
the Management Object Identifier
37. The VerNo property is incremented every time a node is changed
– If the property value has reached FFFF, and then is incremented, it
SHALL return to 0000
38. The OMA DM DDF information XML documents are specified using well-
formed XML. However, they MAY not be valid XML. That is, they do not
need to specify the XML prolog
39. For DDF, the NodeName element MAY be empty. If empty, this means
that the name of the Node MUST be assigned when the Node is created
40. DDF has an element called DFType. For Leaf Nodes, this is the
MIME type of the Node value. For Interior Nodes, this is either the
Management Object Identifier or empty
41. The DDF element Scope specifies whether a node is a Permanent Node
or a Dynamic Node
I am finding trouble following the OMA-DM TND (Tree and Description)
spec. I don't think this spec is well written and well structured at
all. This is what I have captured from the spec. Did I cover
everything? Kindly correct me.
Thanks,
Choi
TND Highlights
==============
1. All Nodes in the Management Tree can be uniquely addressed with a
URI
2. A URI MUST NOT end with the delimiter "/"
3. the "/" character MUST NOT be part of any Node name
4. The root Node MUST be denoted as "." and not "./"
5. The character sequence "./" MUST NOT be used anywhere else but in
the beginning of a URI
6. All properties, except the ACL, are valid only for the Node to
which they are associated
7. Invoking GET on an Interior Node returns a list of all child Node
names
– If the Interior Node has no children an empty list of child Node
names is returned
– The list of children is returned as an unordered list of names. The
individual names in the list are separated by the character “/”.
– The returned child list has the format node in the meta information
of the result.
8. Permanent Nodes are typically built in at device manufacture.
Permanent Nodes can also be temporarily added to a device by, for
instance, connecting new accessory hardware
9. If a deleted Dynamic Node has children, i.e. is an Interior Node,
the children MUST also be deleted
10. The name of a newly created Dynamic Node SHALL be the last segment
of the URI presented in the Target element of the Add command
11. The Delete command acts strictly on the Node it is addressed at,
and if that Node is a dynamic Interior Node it will be deleted along
with all its child Nodes. If any of these child Nodes have the
AccessType property set to exclude Delete they will be deleted anyway
12. Interior Nodes DO NOT have the size property
13. The properties of a Node are addressed by appending ?
prop=<property_name> to the Node’s URI
– ./DMAcc/xyzInc?prop=ACL
14. The only properties of a node that can be changed are ACL, Name
and Title
15. The ACL and the Title of a Permanent Node can be changed.
However, the Name cannot
– The semantics of most properties are independent of the permanent/
dynamic status of the Node to which they are associated
16. There is no inheritance of property values other than for the ACL
property
17. The access rights granted by an ACL are granted to Server
Identifiers and not to the URI, IP address or certificate of a DM
Server
18. Every Node MUST implement the ACL property, but there can be no
guarantee that the ACL of every Node has a value assigned to it
19. The root Node MUST always have an ACL value
20. If a node has no ACL value assigned to it, it inherits the ACL
value from its first ancestor that defines this value
– This search will always result in a found value since the root Node
MUST have an assigned ACL value
21. A Get command on the ACL property of a Node MUST return the actual
ACL value (which may be NULL) but NOT its inherited value
22. The default value for the root ACL SHOULD be Add=*&Get=*
23. The rules for changing the ACL of a Node are different for
Interior Nodes and Leaf Nodes
– For an interior node, any Server that has Replace access rights
(according to the Node ACL) can change the ACL value
– For a leaf node, a Server that has Replace access rights (according
to the Node ACL) can change all the properties of the node, except the
ACL value itself
– For both types of Nodes the right to change the ACL of the Node is
also controlled by the ACL of the parent Node
– Even if a server has total access to the parent Node according to
the parent’s ACL, this does not imply direct access to the child Node
value. To change a child Node value the child ACL value MUST be
changed first
– Implication: A parent node can anytime control the ACL of the child
node
24. If a server successfully creates a new Node with the Add command,
the value of the Node’s ACL property is initially set to no value,
i.e. <Data/>. This means that the value is inherited from the parent
Node
25. Exception: A Server that creates an interior node is guaranteed
the Add, Delete and Replace rights on the node
26. The only command available to change an ACL is Replace
– If a server wishes to keep the existing entries in an ACL it MUST
read the ACL, perform the needed changes and then Replace the existing
ACL with the new one
27. When a DM Server Identifier is to be deleted from the device, the
Management Tree MUST be scanned for Nodes with ACL’s held by the soon
to be deleted Server Identifier. The reference to this Server
Identifier MUST be deleted
28. If a ServerID has the value ‘*’, then there SHOULD NOT be any
other ServerID values associated with this command in the current ACL
29. Example ACL value:
–
Add=www.sonera.fi-8765&Delete=www.sonera.fi-8765&Replace=www.sonera.fi-8765+321_ibm.com&Get=*
30. There is no ACL representation for the Copy command
– Any result of a Copy command can always be created by a sequence of
other commands
31. The allowed values for the format property are: bin, bool, b64,
chr, int, node, null, xml, date, time, and float
32. Interior Nodes MUST have node as the Format value
33. When a new Node is created, the value of the Name property MUST be
assigned with the value of last segment in the Target URI. However,
it may be changed by the Replace command
34. The Title property is used to store a human readable, alphanumeric
string that provides some information about the Node to which this
property belongs
35. The Type property for a Leaf node is the MIME type of the Leaf
Node’s value
36. The value of Type property for an interior node is either NULL or
the Management Object Identifier
37. The VerNo property is incremented every time a node is changed
– If the property value has reached FFFF, and then is incremented, it
SHALL return to 0000
38. The OMA DM DDF information XML documents are specified using well-
formed XML. However, they MAY not be valid XML. That is, they do not
need to specify the XML prolog
39. For DDF, the NodeName element MAY be empty. If empty, this means
that the name of the Node MUST be assigned when the Node is created
40. DDF has an element called DFType. For Leaf Nodes, this is the
MIME type of the Node value. For Interior Nodes, this is either the
Management Object Identifier or empty
41. The DDF element Scope specifies whether a node is a Permanent Node
or a Dynamic Node