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.