idnits 2.17.1
draft-mrose-blocks-exchange-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 38 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** The abstract seems to contain references ([5], [6], [1]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 9, 2000) is 8808 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: 'A-Za-z0-9' on line 976
-- Looks like a reference, but probably isn't: 'RFC-2396' on line 985
== Unused Reference: '4' is defined on line 1192, but no explicit reference
was found in the text
-- Possible downref: Normative reference to a draft: ref. '1'
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
** Obsolete normative reference: RFC 2396 (ref. '3') (Obsoleted by RFC 3986)
== Outdated reference: A later version (-04) exists of
draft-mrose-blocks-protocol-01
-- Possible downref: Normative reference to a draft: ref. '4'
-- Possible downref: Non-RFC (?) normative reference: ref. '5'
-- Possible downref: Non-RFC (?) normative reference: ref. '6'
-- Possible downref: Non-RFC (?) normative reference: ref. '11'
Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M.T. Rose
3 Internet-Draft Invisible Worlds, Inc.
4 Expires: September 7, 2000 March 9, 2000
6 The Blocks Simple Exchange Profile
7 draft-mrose-blocks-exchange-01
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026 except that the right to
13 produce derivative works is not granted. (If this document becomes
14 part of an IETF working group activity, then it will be brought into
15 full compliance with Section 10 of RFC2026.)
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as
20 Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six
23 months and may be updated, replaced, or obsoleted by other documents
24 at any time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on September 7, 2000.
35 Copyright Notice
37 Copyright (C) The Internet Society (2000). All Rights Reserved.
39 Abstract
41 Blocks[1] is an architecture for managing metadata. The architecture
42 supports two models: the Blocks exchange model organizes information
43 into navigation spaces, whilst the Blocks convergence model allows
44 for bulk synchronization and knowledge management.
46 This memo describes the Simple Exchange Profile (SEP) used to
47 exchange objects, termed blocks, residing in an SEP datastore.
49 To subscribe to the Blocks discussion list, send e-mail[5]; there is
50 also a developers' site[6].
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
55 2. The SEP Datastore . . . . . . . . . . . . . . . . . . . . . 4
56 2.1 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
57 2.2 Data types . . . . . . . . . . . . . . . . . . . . . . . . . 5
58 2.3 Entities . . . . . . . . . . . . . . . . . . . . . . . . . . 6
59 2.4 The Top-Level . . . . . . . . . . . . . . . . . . . . . . . 6
60 3. Profile Identification and Initialization . . . . . . . . . 8
61 4. Request and Response Messages . . . . . . . . . . . . . . . 10
62 5. Message Semantics . . . . . . . . . . . . . . . . . . . . . 11
63 5.1 The Fetch Operation . . . . . . . . . . . . . . . . . . . . 12
64 5.1.1 The Related and MaxNum Attribute . . . . . . . . . . . . . . 18
65 5.1.2 The Ordering Element . . . . . . . . . . . . . . . . . . . . 19
66 5.1.3 The Notification, PrevStamp, and ReqStamp Attributes . . . . 20
67 5.2 The Notify Operation . . . . . . . . . . . . . . . . . . . . 21
68 5.3 The Store Operation . . . . . . . . . . . . . . . . . . . . 23
69 5.4 The Lock Operation . . . . . . . . . . . . . . . . . . . . . 24
70 5.5 The Release Operation . . . . . . . . . . . . . . . . . . . 25
71 5.6 Other Operations . . . . . . . . . . . . . . . . . . . . . . 25
72 6. Simple Exchange Profile Registration . . . . . . . . . . . . 26
73 7. The SEP datastore DTD . . . . . . . . . . . . . . . . . . . 27
74 8. The Simple Exchange Profile DTD . . . . . . . . . . . . . . 30
75 9. Security Considerations . . . . . . . . . . . . . . . . . . 33
76 References . . . . . . . . . . . . . . . . . . . . . . . . . 34
77 Author's Address . . . . . . . . . . . . . . . . . . . . . . 34
78 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
79 B. Changes from draft-mrose-blocks-exchange-00 . . . . . . . . 36
80 Full Copyright Statement . . . . . . . . . . . . . . . . . . 37
82 1. Introduction
84 In the Blocks Architecture[1], the Simple Exchange Profile (SEP) is
85 used to exchange objects, termed blocks, residing in an SEP
86 datastore.
88 2. The SEP Datastore
90 An SEP datastore is a collection of blocks. A block can be viewed
91 from two perspectives:
93 semantic: a block is simply metadata about an external object; in
94 this sense, an SEP datastore is not unlike a shared, distributed
95 management system for documents;
97 syntactic: a block is a unit of retrieval; in this sense, an SEP
98 datastore is a collection of related XML documents[2].
100 The SEP is concerned with the latter perspective.
102 A block is a well-formed XML document that satisfies four
103 constraints:
105 o the root element of each block must contain a "name" attribute;
107 o each XML element in the block, termed a property, contains either
108 character data or subordinate elements, but not both;
110 o if there is a DTD that describes the validity of the XML
111 document, then any implicit values must be populated in the
112 block; and,
114 o a block may contain no entities other than "&", "<",
115 "'" and """.
117 The first constraint allows each block to be unambiguously
118 identified, whilst the remaining constraints make query optimization
119 considerably easier to implement.
121 Blocks are expressed using either:
123 the generic syntax: in which each property of the block is
124 explicitly tagged using a "property" element; or,
126 the specific syntax: in which a syntactic minimization technique is
127 used to increase readability and reduce size.
129 Section 7 defines the XML DTD used for the generic syntax of blocks
130 stored in an SEP datastore. Note that although each block consists
131 of a collection of structured properties, the unit of retrieval for
132 the SEP is at the block-level. Applications making use of the SEP
133 are free to further decompose the blocks exchanged.
135 2.1 Naming
137 Naming of blocks in an SEP datastore is hierarchical, with labels
138 separated by dots, and read left-to-right, e.g.,
140 net.ipv4.207.67.199.3
141 doc.rfc.2629
143 A naming scope refers to the collection of blocks whose names are
144 contained with a proper subtree, e.g.,
146 doc.rfc.1006
147 doc.rfc.2629
149 are both contained within the naming scope of "doc.rfc".
151 2.2 Data types
153 The SEP datastore DTD begins by specifying several data types for
154 use when defining a block:
156 NAME: Each block has a unique name. This datatype is used wherever
157 the syntax of a name is required.
159 TYPE: Each block consists of one or more properties. This datatype
160 is used wherever the syntax for a property's type is required.
162 TYPES: Sometimes it is convenient to refer to the types associated
163 with a list of properties. This datatype is used for that purpose.
165 URI: Although the attribute values associated with a property are
166 textual, it is often useful to treat the character string as a
167 higher-level construct. This datatype is used wherever the syntax
168 for a URI[3] is required.
170 UINT16: This data type is used wherever the syntax for a 16-bit
171 unsigned integer value is required.
173 UINT32: This data type is used wherever the syntax for a 32-bit
174 unsigned integer value is required.
176 ATEXT: This data type is used wherever the syntax for unstructured
177 text in an attribute value is required.
179 CTEXT: This data type is used wherever the syntax for single line,
180 unstructured text is required.
182 TEXT: This data type is used wherever the syntax for (potentially
183 multiline) unstructured text is required.
185 2.3 Entities
187 At a minimum, each block must have a "name" attribute in its root
188 element. In addition, each block may also have three optional
189 attributes present in its root element:
191 serial: an integer that is increased each time the block is updated;
193 ttl: an integer, in seconds, that indicates how long this copy of
194 the block should be considered authoritative; and,
196 creator: a URI identifying the process that created or last updated
197 this block.
199 Normally, these three attributes are supplied by the SEP datastore
200 containing the block. The "%block.implied;" entity is used to denote
201 these three optional attributes.
203 The "%block.attrs;" entity is used to denote the mandatory "name"
204 attribute and these three optional attributes.
206 2.4 The Top-Level
208 Each block consists of the four attributes defined by
209 "%block.attrs;", and zero or more "property" elements.
211 Each "property" element consists of:
213 o zero or more uniquely named "attribute" elements (each
214 "attribute" element is simply a key/value pairing); and,
216 o either:
218 * one or more "property" elements; or,
220 * character data consisting of zero or more characters.
222 Note that the ordering of "property" and "attribute" elements is not
223 significant.
225 For example, consider:
227
228
229
231
232 An Example Script
233
234
236 which is a block containing one property, called "remote.props".
237 That property contains two attributes (one called "uri" and the
238 other "language") and a subordinate property. The subordinate
239 property, called "title", contains character data.
241 This example shows a block expressed using the generic syntax.
242 Because XML elements may contain uniquely-named attributes, we can
243 minimize the syntax:
245
246
248 An Example Script
249
250
252 The rules to convert from the generic to the specific syntax are
253 simple:
255 1. Change the name of the top-level element from "block" to
256 something else.
258 2. For each "attribute" element subordinate to any "property"
259 element: add the corresponding name/value pair as an attribute
260 to that "property" element and remove the "attribute" element.
262 3. For each "property" element contained within the block, change
263 the name of that "property" element to the value of its
264 corresponding "type" attribute and remove the "type" attribute
265 from that element.
267 3. Profile Identification and Initialization
269 Section 6 contains the registration for this profile.
271 The SEP is identified as
273 http://xml.resource.org/profiles/SEP
275 Refer to [4]'s Section 2.1 for a discussion of the roles that a BXXP
276 peer may perform, i.e., initiator ("I:") or listener ("L:"), and
277 client ("C:") or server ("S:").
279 During channel creation, the corresponding "profile" element in the
280 BXXP "start" element may contain a "request" element. If channel
281 creation is successful, then before sending the corresponding "RSP"
282 message, the BXXP peer processes the "request" element and includes
283 the resulting "response" element in the "RSP" message, e.g.,
285 C: REQ . 1 0 546 0
286 C:
287 C:
288 C:
289 C:
290 C:
291 C:
292 C:
293 C:
294 C:
295 C:
296 C: doc.rfc.2629
297 C:
298 C:
299 C:
300 C:
301 C:
302 C:
303 C: END
304 S: RSP . 1 284 261 +
305 S:
306 S:
307 S:
309 S:
310 S:
311 S:
312 S:
313 S:
314 S: END
316 Note that it is possible for the channel to be created, but for the
317 encapsulated operation to fail, e.g.,
319 C: REQ . 1 0 531 0
320 C:
321 C:
322 C:
323 C:
324 C:
325 C:
326 C:
327 C:
328 C:
329 C:
330 C: doc.rfc.2629
331 C:
332 C:
333 C:
334 C:
335 C:
336 C:
337 C: END
338 S: RSP . 1 284 267 +
339 S:
340 S:
341 S:
343 S: property attribute
344 S: missing in <element> element
345 S:
346 S:
347 S: END
349 In this case, a positive "RSP" message is returned (as channel
350 creation succeeded), but the encapsulated response contains an
351 indication as to why the operation failed.
353 4. Request and Response Messages
355 Section 8 defines the messages that are used in the SEP:
357 o "REQ" messages carry only the "request" element as data;
359 o positive "RSP" messages carry only the "response" element
360 (containing an "answers" element and, optionally, an "additional"
361 element) as data; and,
363 o negative "RSP" messages carry only the "response" element
364 (containing an "error" element) as data.
366 5. Message Semantics
368 The "request" element contains a "reqno" attribute and one of: a
369 "fetch" element, a "notify" element, a "store" element, a "lock"
370 element, or, a "release" element.
372 The "reqno" attribute (an integer in the range 0..4294967295) is
373 used to correlate "request" elements sent by a BXXP peer acting in
374 the client role with the "response" elements sent by a BXXP peer
375 acting in the server role.
377 5.1 The Fetch Operation
379 The "fetch" element contains four attributes, a "union" element,
380 and, optionally, an "ordering" element:
382 o the "related" attribute, if present, contains a space-separated
383 list of property names that cause similar blocks to be returned
384 in the "additional" element of the response (c.f., Section 5.1.1);
386 o the "offset" attribute, if present, contains a non-negative
387 integer (in the range 0..32767) indicates the starting position
388 for the blocks to be returned;
390 o the "maxNum" attribute, if present, contains a positive integer
391 (in the range 1..32767) indicates the maximum number of blocks
392 allowed to be returned;
394 o the "notification" attribute, if present, is either "true" or
395 "false" (the default) to indicate whether the BXXP peer acting in
396 the server role should periodically check for changes to the
397 blocks returned in the "answers" element of the response (c.f.,
398 Section 5.1.3);
400 o the "union" element defines the set-union of one or more
401 "intersect" elements, each of which define the set-intersection
402 of one or more "union" or "compare" elements, each of latter
403 describing an containment/value assertion; and,
405 o the "ordering" element, if present, defines the order in which
406 matches are returned (c.f., Section 5.1.2).
408 Each "compare" element contains three attributes, a "path" element,
409 and a "value" element:
411 o the "subtree" attribute identifies the naming scope for the
412 comparison;
414 o the "operator" attribute, if present, identifies the comparison
415 to be made between the "path" element and the "value" element,
416 one of: "eq" (equals, the default), "ne" (not equals),
417 "contains", or "excludes";
419 o the "caseSensitive" attribute, if present, is either "true" (the
420 default) or "false" to indicate whether the comparison should
421 consider textual case significant;
423 o the "approximate" attribute, if present, is either "true" or
424 "false" (the default) to indicate whether the comparison should
425 be approximate (e.g., through the use of stemming);
427 o the "path" element identifies a partial containment hierarchy for
428 the comparison; and,
430 o the "value" element contains the text to compare against.
432 If the fetch operation is successful, then a "response" element
433 containing an "answers" element, and optionally an "additional"
434 element is returned as data in a positive "RSP" message; otherwise,
435 a "response" element containing a BXXP "error" element (c.f., [4]'s
436 Section 2.3.1.3) is returned as data in a negative "RSP" message.
438 If a "response" element is returned, then the order of blocks in the
439 "answers" element are ordered from "most relevant" to "least
440 relevant" (c.f., Section 5.1.2). Accordingly, if all blocks
441 satisfying the set-union are enumerated as a list starting at
442 position 0, then the block at the position corresponding to the
443 "offset" attribute is the first block returned in the "answers"
444 element.
446 If a "response" element is returned, then the optional "actualNum"
447 attribute may be present in the "answers" element. This attribute
448 indicates the total number of matches for the corresponding "fetch"
449 operation. If absent, the value of this attribute defaults to the
450 number of blocks present in the "answers" element.
452 At the core of the fetch operation is the notion of a
453 containment/value assertion. Each assertion identifies a comparison
454 between a partial containment hierarchy and a textual value.
456 Several examples serve to illustrate these relationships.
458 First, consider:
460 C: REQ . 1 546 345 1
461 C:
462 C:
463 C:
464 C:
465 C:
467 C:
468 C: mrose@
469 C:
470 C:
471 C:
472 C:
473 C: END
475 which looks for blocks satisfying several criteria: first, the block
476 is named under "doc.rfc"; second, the block has at least one
477 property called "email"; and, third, any of those properties
478 contains the string "mrose@" somewhere within it, according to a
479 case-insensitive comparison. Note that in this example, the "email"
480 property may occur at any level of nesting within a block.
482 Second, a similar example:
484 C: REQ . 2 891 266 1
485 C:
486 C:
487 C:
488 C:
489 C:
490 C:
491 C: Rose
492 C:
493 C:
494 C:
495 C:
496 C: END
498 which looks for blocks in the same subtree, but is concerned only
499 with attribute, not property, values. That is, if any property with
500 a block has attribute called "surname" and the value of that
501 attribute precisely matches the string "Rose", then this assertion
502 succeeds. (Recall that the default value for "operator" is "eq" and
503 the default value for "caseSensitive" is "true".)
504 Of course, if we wanted to limit containment of the attribute:
506 C: REQ . 3 1157 344 1
507 C:
508 C:
509 C:
510 C:
511 C:
512 C:
513 C:
514 C:
515 C: Rose
516 C:
517 C:
518 C:
519 C:
520 C: END
522 which looks for blocks in the same subtree, but performs comparisons
523 only on attributes called "surname" within a "doc.author" property.
525 In addition, if we wanted to further contain the attribute's
526 property:
528 C: REQ . 4 1501 501 1
529 C:
530 C:
531 C:
532 C:
533 C:
534 C:
535 C:
536 C:
537 C:
538 C:
539 C:
540 C: Rose
541 C:
542 C:
543 C:
544 C:
545 C: END
547 which looks for "doc.author" properties contained within a
548 "doc.front" property contained within a "doc.props" property
549 contained within a "rfc" property before looking at the "surname"
550 attribute. Note however, that there is no concept of "rooting" in a
551 containment hierarchy, e.g., in this example, the "rfc" property
552 needn't be the top-level property of the block (i.e., the root
553 element of the corresponding XML document).
555 Of course, an empty containment hierarchy is also possible, e.g.,
557 C: REQ . 5 2002 247 1
558 C:
559 C:
560 C:
561 C:
562 C:
563 C:
564 C: Rose
565 C:
566 C:
567 C:
568 C:
569 C: END
571 which looks for the string "Rose" in any property. Similarly, to
572 look for the string "Rose" in any attribute value, the containment
573 "" is used.
575 Note that in all the preceding examples, both the "union" and
576 "intersect" elements had only one immediate subordinate, rendering
577 each as the identity function. However, the presence of the elements
578 is always required, regardless of whether their functionality is
579 needed. To set-intersect the results of multiple assertions, the
580 "intersect" element is given multiple subordinates, e.g.,
582 C: REQ . 6 2249 494 1
583 C:
584 C:
585 C:
586 C:
587 C:
589 C:
590 C: mrose@
591 C:
592 C:
593 C:
594 C: Rose
595 C:
596 C:
597 C:
598 C:
599 C: END
601 which evaluates two assertions and returns only those blocks
602 satisfying both.
604 Similarly, to set-union the results of multiple intersections, the
605 "union" element is given multiple subordinates, e.g.,
607 C: REQ . 7 2743 537 1
608 C:
609 C:
610 C:
611 C:
612 C:
614 C:
615 C: mrose@
616 C:
617 C:
618 C:
619 C:
620 C:
621 C: Rose
622 C:
623 C:
624 C:
625 C:
626 C: END
628 which evaluates two assertions and returns blocks that satisfy
629 either. Of course, recursion is permissible between "union" and
630 "intersect" elements, owing to their defintion.
632 5.1.1 The Related and MaxNum Attribute
634 Blocks satisfying the constraints of the "union" element are
635 returned in the "response" element's "answers" element. These are
636 termed satisfying blocks.
638 The "related" attribute, if present, causes blocks similar to the
639 satisfying blocks to be returned in the "response" element's
640 "additional" element. These are termed similar blocks.
642 A similar block is one that has the same value for any of related
643 properties as any of the satisfying blocks. Note that when
644 determining if a block is similar, the BXXP peer acting in the
645 server role consults its entire SEP datastore -- a similar block may
646 belong to an entirely different naming scope than any corresponding
647 satisfying block.
649 Regardless, note that the "maxNum" attribute limits the actual
650 number of blocks returned. As many satisfying blocks as possible
651 must be returned; if the "maxNum" limit is not yet reached, then as
652 many similar blocks within the limit may be returned. No additional
653 constraints are placed on implementations if the value of the
654 "maxNum" attribute is less than the number of satisfying and similar
655 blocks.
657 5.1.2 The Ordering Element
659 If the "ordering" element is present in the "fetch" element, then
660 this provides guidelines as to how blocks should be ordered in the
661 "answers" element.
663 The "ordering" element contains one or more "path" elements, ordered
664 as sort keys (i.e., the first "path" element is the primary sort
665 key, the second "path" element, if any, is the secondary sort key,
666 and so on). Each "path" element contains an "order" attribute
667 indicating whether relevance is in ascending (the default) or
668 descending order.
670 For example, to look for blocks containing a "surname" attribute of
671 "Rose", and then order the blocks according to the value of their
672 "doc.title" element:
674 C: REQ . 8 3280 341 1
675 C:
676 C:
677 C:
678 C:
679 C:
680 C:
681 C: Rose
682 C:
683 C:
684 C:
685 C:
686 C:
687 C:
688 C:
689 C: END
691 5.1.3 The Notification, PrevStamp, and ReqStamp Attributes
693 If a fetch operation is successful and the "notification" attribute
694 is "true", then it is referred to as a persistent fetch operation.
696 When performing the fetch operation, if the "notification" attribute
697 is true, then the "prevStamp" attribute is also consulted. If empty,
698 this indicates that the fetch operation is performed against the
699 entire SEP datastore; otherwise, the value is identical to a
700 previously returned value of the "reqStamp" in an "answers" element.
701 In this latter case, the fetch operation returns an empty "answer"
702 element with a "reqStamp" attribute value equal to the "prevStamp"
703 attribute value, and all corresponding notify operations (Section
704 5.2) for this persistent fetch will contain information about
705 changes that occurred after the "reqStamp" attribute value.
707 The fetch operation persists until either:
709 o a corresponding release operation (Section 5.5) is successful;
711 o a corresponding notify operation (Section 5.2) fails;
713 o the BXXP session is released; or,
715 o the underlying transport service indicates that the connection
716 has been reset.
718 In the interim:
720 1. The BXXP peer acting in the client role may not use the value of
721 "reqno" in other requests.
723 2. The BXXP peer acting in the server role periodically checks for
724 changes to the blocks returned in the "answers" element in the
725 original response. If so, a notify operation is generated.
727 Every "answers" element generated for a persistent fetch (contained
728 in either a "response" or "notify" element) has a non-empty
729 "reqStamp" attribute. This provides a mechanism to restart a
730 persistent fetch operation after a connection loss: the BXXP peer
731 acting in the client role records the most recent "reqStamp"
732 attribute value whenever it sees an "answer" element corresponding
733 to a persistent fetch. If the connection is lost (or the SEP channel
734 is closed), then after re-establishing the connection and starting
735 an SEP channel, the BXXP peer acting in the client role initiates a
736 new persistent fetch by setting the "notification" attribute to true
737 and the "prevStamp" attribute to the most recent "reqStamp"
738 attribute value.
740 5.2 The Notify Operation
742 For each persistent fetch operation known to a BXXP acting in the
743 server role, a periodic check is made for changes to the blocks
744 returned in the "answers" element in the original response. If any
745 of the blocks are changed or deleted, or, if new blocks are created
746 that qualify as satisfying blocks for the original request, then a
747 notify operation is sent.
749 The "notify" element consists of a "prevno" attribute, an "answers"
750 element, and, optionally, either or both of a "additional" element
751 and a "deletions" element:
753 o the "prevno" attribute (an integer in the range 0..4294967295) is
754 used to correlate this operation with the corresponding
755 persistent fetch operation;
757 o the "answers" element contains both newly-changed blocks
758 previously returned in an "answers" element for this persistent
759 fetch operation, along with newly-created blocks that qualify as
760 satisfying blocks for the original request;
762 o the "additional" element, if present, contains similar blocks to
763 the newly-created blocks, if any, in the "answers" element of
764 this operation; and,
766 o the "deletions" element, if present, contains newly-deleted
767 blocks previously returned in an "answers" element for this
768 persistent fetch operation.
770 Note that when constructing the "deletions" element, the blocks
771 generic syntax may be used, e.g.,
773
774
775
776
777
778
780 This strategy is useful if a server knows that a block was deleted,
781 but the actual block is no longer available.
783 If the notify operation is successful, then a "response" element
784 containing an empty "answers" element is returned as data in a
785 positive "RSP" message; otherwise, a "response" element containing a
786 BXXP "error" element (c.f., [4]'s Section 2.3.1.3) is returned as
787 data in a negative "RSP" message. In the latter case, the fetch
788 operation is no longer considered persistent.
790 Note that the BXXP peers switch server and client roles when going
791 from a fetch operation to a notify operation, e.g.,
793 I: REQ . 1 3280 88 1
794 I:
795 I:
796 I:
797 I:
798 I: END
799 L: RSP . 1 284 57 +
800 L:
801 L:
802 L:
803 L:
805 ... time elapses ...
807 L: REQ . 1 341 83 1
808 L:
809 L:
810 L:
811 L:
812 L: END
813 I: RSP . 1 3368 52 +
814 I:
815 I:
816 I:
817 I:
818 I: END
820 5.3 The Store Operation
822 The store operation contains one attribute and one or more blocks to
823 store.
825 o the "action" attribute, if present, is one of:
827 create: verifies that the blocks do not exist in the SEP
828 datastore before creating them;
830 write: creates or overwrites the blocks in the SEP datastore (the
831 default);
833 update: verifies that the blocks exist in the SEP datastore
834 before overwriting them; or,
836 delete: removes the blocks from the SEP datastore.
838 In order to provide coordination between independent BXXP peers
839 acting in the client role, a lock operation (Section 5.4) must be
840 successfully performed before the store operation.
842 If the store operation is successful, then a "response" element
843 containing an empty "answers" element is returned as data in a
844 positive "RSP" message; otherwise, a "response" element containing a
845 BXXP "error" element (c.f., [4]'s Section 2.3.1.3) is returned as
846 data in a negative "RSP" message.
848 5.4 The Lock Operation
850 The lock operation contains one attribute:
852 o the "subtree" attribute that identifies the naming scope to lock.
854 If a lock operation is successful, then it is referred to as a
855 persistent lock operation. It remains so until either:
857 o a corresponding release operation (Section 5.5) is successful;
859 o the BXXP session is released;
861 o the underlying transport service indicates that the connection
862 has been reset; or,
864 o an implementation-specific inactivity timer expires in the BXXP
865 peer acting in the server role.
867 In the last three cases, the BXXP peer acting in the server role
868 should discard any journaled store operations for this channel.
869 (Further, in the final case, the BXXP peer acting in the server role
870 should also release the BXXP session with prejudice.)
872 In the interim:
874 1. No other connection or channel may successfully lock within the
875 subtree.
877 2. No other connection or channel may successfully store within the
878 subtree.
880 3. Any store operations on this channel are journaled until a
881 subsequent release operation.
883 If the lock operation is successful, then a "response" element
884 containing an empty "answers" element is returned as data in a
885 positive "RSP" message; otherwise, a "response" element containing a
886 BXXP "error" element (c.f., [4]'s Section 2.3.1.3) is returned as
887 data in a negative "RSP" message.
889 5.5 The Release Operation
891 The "release" element contains two attributes:
893 o the "prevno" attribute (an integer in the range 0..4294967295) is
894 used to correlate this operation with a persistent fetch (Section
895 5.1.3) or lock (Section 5.4) operation; and,
897 o the "action" attribute, if present, is either "commit" (the
898 default) or "rollback".
900 If the previous operation refers to a persistent lock operation,
901 then the "action" attribute indicates whether the BXXP peer acting
902 in the server role should either:
904 commit: perform any journaled store operations for this channel; or,
906 rollback: discard any journaled store operations for this channel.
908 Regardless, upon successful completion of the release operation, the
909 corresponding fetch or lock operation is completed and no longer
910 considered persistent.
912 If the release operation is successful, then a "response" element
913 containing an empty "answers" element is returned as data in a
914 positive "RSP" message; otherwise, a "response" element containing a
915 BXXP "error" element (c.f., [4]'s Section 2.3.1.3) is returned as
916 data in a negative "RSP" message.
918 5.6 Other Operations
920 If the BXXP peer receives a "request" element containing any other
921 element, a "response" element containing a BXXP "error" element
922 (c.f., [4]'s Section 2.3.1.3) is returned as data in a negative
923 "RSP" message.
925 6. Simple Exchange Profile Registration
927 Profile Identification: http://xml.resource.org/profiles/SEP
929 Messages in Profile Initialization: request
931 Messages in "REQ" frames: request
933 Messages in positive "RSP" frames: response
935 Messages in negative "RSP" frames: error
937 Message Syntax: c.f., Section 8
939 Message Semantics: c.f., Section 5
941 7. The SEP datastore DTD
943
959
969
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1020
1025
1029
1033
1034
1037
1038
1042
1049
1050
1053 8. The Simple Exchange Profile DTD
1055
1071
1084
1095
1105
1106
1109
1110
1114
1115
1119
1121
1122
1129
1130
1132
1133
1134
1142
1143
1144
1148
1149
1151
1153
1154
1156
1158
1159
1163
1164
1167
1168
1172 9. Security Considerations
1174 The SEP is a profile of BXXP. In BXXP, transport security, user
1175 authentication, and data exchange are entirely orthogonal. Refer to
1176 [4]'s Section 8 for a discussion of these issues.
1178 References
1180 [1] Rose, M.T. and C. Malamud, "Blocks: Architectural Precepts",
1181 draft-mrose-blocks-architecture-01 (work in progress), March
1182 2000.
1184 [2] World Wide Web Consortium, "Extensible Markup Language (XML)
1185 1.0", W3C XML, February 1998,
1186 .
1188 [3] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
1189 Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1190 1998.
1192 [4] Rose, M.T., "The Blocks eXtensible eXchange Protocol",
1193 draft-mrose-blocks-protocol-01 (work in progress), March 2000.
1195 [5] mailto:blocks-request@invisible.net
1197 [6] http://mappa.mundi.net/
1199 [11] mailto:dnew@invisible.net
1201 Author's Address
1203 Marshall T. Rose
1204 Invisible Worlds, Inc.
1205 1179 North McDowell Boulevard
1206 Petaluma, CA 94954-6559
1207 US
1209 Phone: +1 707 789 3700
1210 EMail: mrose@invisible.net
1211 URI: http://invisible.net/
1213 Appendix A. Acknowledgements
1215 The author gratefully acknowledges the contributions of: Darren
1216 New[11].
1218 Appendix B. Changes from draft-mrose-blocks-exchange-00
1220 o The profile is now identified as
1221 http://xml.resource.org/profiles/SEP
1223 o In Section 5.1.2, an XML nesting error was corrected.
1225 o In Section 5.1.3, the behavior of connection re-establishment was
1226 clarified.
1228 o In Section 8, the correct URI is used to reflect the location of
1229 the DTD.
1231 Full Copyright Statement
1233 Copyright (C) The Internet Society (2000). All Rights Reserved.
1235 This document and translations of it may be copied and furnished to
1236 others, and derivative works that comment on or otherwise explain it
1237 or assist in its implementation may be prepared, copied, published
1238 and distributed, in whole or in part, without restriction of any
1239 kind, provided that the above copyright notice and this paragraph
1240 are included on all such copies and derivative works. However, this
1241 document itself may not be modified in any way, such as by removing
1242 the copyright notice or references to the Internet Society or other
1243 Internet organizations, except as needed for the purpose of
1244 developing Internet standards in which case the procedures for
1245 copyrights defined in the Internet Standards process must be
1246 followed, or as required to translate it into languages other than
1247 English.
1249 The limited permissions granted above are perpetual and will not be
1250 revoked by the Internet Society or its successors or assigns.
1252 This document and the information contained herein is provided on an
1253 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1254 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1255 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1256 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1257 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1259 Invisible Worlds expressly disclaims any and all warranties
1260 regarding this contribution including any warranty that (a) this
1261 contribution does not violate the rights of others, (b) the owners,
1262 if any, of other rights in this contribution have been informed of
1263 the rights and permissions granted to IETF herein, and (c) any
1264 required authorizations from such owners have been obtained. This
1265 document and the information contained herein is provided on an "AS
1266 IS" basis and INVISIBLE WORLDS DISCLAIMS ALL WARRANTIES, EXPRESS OR
1267 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
1268 OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1271 IN NO EVENT WILL INVISIBLE WORLDS BE LIABLE TO ANY OTHER PARTY
1272 INCLUDING THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING
1273 SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF
1274 DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES
1275 WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY
1276 WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT,
1277 WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF
1278 SUCH DAMAGES.
1280 Acknowledgement
1282 Funding for the RFC editor function is currently provided by the
1283 Internet Society.