idnits 2.17.1 draft-dejong-decentralized-sharing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 May 2015) is 3253 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2818 (ref. 'HTTPS') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5785 (ref. 'WELL-KNOWN') (Obsoleted by RFC 8615) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Michiel B. de Jong 2 Document: draft-dejong-decentralized-sharing-00 (independent) 3 Paul Tran-Van 4 Intended Status: Informational (Cozy Cloud) 5 Expires: 30 November 2015 29 May 2015 7 Decentralized Sharing 9 Abstract 11 This draft describes the steps and challenges of sharing documents 12 between persons, using internet-connected servers. We investigate the 13 situation where a document exists on a server to which the sender has 14 access through some software application, but the recipient(s) don't. 15 All recipient(s) do, however, have access to software applications that 16 run on least one other server. 18 We discuss existing and proposed methods for the sender to initiate the 19 communication, for each recipient to become aware of the sender's intent 20 to share a document, for each recipient to access the document directly, 21 for the document contents to be transmitted to server(s) to which the 22 recipient(s) have access, for the sender to make and announce changes in 23 the document after it was initially sent, and for the recipient(s) to 24 communicate comments and proposed changes to the document back to the 25 sender. 27 We also discuss how semantics of the document may be communicated, 28 and how versioning conflicts may then in some cases be resolved 29 programmatically. Given that users of personal servers don't all run 30 the same compatible software on their server, the sending application 31 needs to discover which application-level protocols are supported by the 32 receiving application(s). 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 30 November 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Terminology....................................................3 68 2. Introduction...................................................3 69 3. Initiate sharing process.......................................5 70 4. Recipient selection............................................5 71 5. Recipient notification.........................................6 72 6. Human access...................................................8 73 7. Machine access ................................................9 74 8. Publishing edits...............................................9 75 9. Comments and write access.....................................10 76 10. Real-time collaboration......................................12 77 11. Listing and revoking access..................................13 78 12. Data domains.................................................14 79 12.1 Discovering the semantics of a document.....................14 80 12.2 Programmatic conflict resolution............................16 81 13. Security Considerations......................................17 82 14. IANA Considerations..........................................17 83 15. Acknowledgements.............................................17 84 16. References...................................................17 85 16.1. Normative References.......................................17 86 16.2. Informative References.....................................19 87 17. Authors' addresses...........................................21 89 1. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [WORDS]. 95 "SHOULD" and "SHOULD NOT" are appropriate when valid exceptions to a 96 general requirement are known to exist or appear to exist, and it is 97 infeasible or impractical to enumerate all of them. However, they should 98 not be interpreted as permitting implementors to fail to implement the 99 general requirement when such failure would result in interoperability 100 failure. 102 2. Introduction 104 When we say a sender 'shares' a document with some recipient(s), 105 we primarily mean the sender makes that document available for the 106 recipient(s) to consume, but not to others. Additionally, the sender 107 may send updated versions of the document after it was sent, and 108 recipient(s) may reply with comments and propose changes to the 109 document. The sender may decide to make such updates accessible to all 110 original recipient(s) or not. When we say 'document', we mean a string 111 of data which encodes some human-readable content in some data format. 113 There are several protocols for sending a document from one server to 114 another. For instance, the sender may use an email client to connect 115 to her server via the [IMAP] protocol, or use a web browser to connect 116 to her server via the [HTTPS] protocol ("webmail"), to instruct her 117 server to forward an existing mail message from her server to one or 118 more recipients, identified by their email addresses, after which the 119 mailserver application running on her server can deliver the document to 120 the recipient's server using the [SMTP] protocol. The recipient(s) may 121 then access the document from their server over the [POP], [IMAP], or 122 [HTTPS] protocol. 124 However, many software applications which people use nowadays to access 125 their documents, do not implement the SMTP, IMAP, or POP protocol 126 (often due to the complexity of dealing with email spam). Also, there 127 is no commonly supported programmatic way for the sender to update 128 documents after they have been sent over SMTP, nor for the recipient(s) 129 to reply with proposed changes. Rather than proposing such a versioning 130 protocol on top of SMTP, we investigate how currently existing software 131 applications implement decentralized document sharing in practice, and 132 where these common practices could be improved and extended. 134 Some software applications allow sharing documents between users who 135 have access to the same server (we could call this centralized sharing), 136 and some also implement application-specific protocols that allow 137 their users to share documents with other users of the same software. 138 This leads to a dispersion of efforts between personal server software 139 projects. The authors hope this document will contribute to more 140 interoperability between such software applications. 142 Many software applications do allow sharing documents publically, for 143 instance by making them accessible over [HTTPS]. There are many ways to 144 restrict access to documents that are published that way, but this does 145 not solve the question of how recipient(s) get notified in the first 146 place that (and how) they have access to such a document. 148 There is no consensus yet on how to share documents privately over the 149 internet, in such a way that recipient(s) are notified, but other people 150 cannot retrieve the document, nor discover its existence. 152 This draft does not propose one universal solution, but rather lists 153 what puzzle pieces we are aware of, and what options may exist to put 154 them together. In general, we are interested in the case where there may 155 be more than one recipient, and where each recipient may have access to 156 more than one server (but not to the sender's server). But for clarity 157 of discussion we will at this point look at a simpler case. 159 Many of the suggestions given in this Internet-Draft have not yet been 160 standardized, and many of them have not yet proven their merit in 161 large-scale deployments. In most cases, we try to list all initiatives 162 we are aware of to implement a certain requirement or step of the 163 process, and references to these proposed approaches are often only 164 informative references to specifications which have been published 165 independently by their authors, on their personal websites, on forums, 166 or on wikis. We try to refer to a specific revision of such publications 167 wherever possible. 169 We introduce Alice, who wants to share one document with Bob. Alice 170 and Bob both have a personal server, which they access to over a 171 web interface, that's to say, using a web browser that connects to 172 their server over HTTPS. This interface displays information in a 173 human-readable way, and allows humans to easily send commands using for 174 instance their web browser's point-and-click gestures. 176 We assume there are multiple documents on Alice's server, and the 177 web interface visualizes these for her. We make no assumptions at 178 this point about the content of these documents; they can be text, 179 hypertext, sound, image, or other media files. They can contain some 180 machine-readable data such as the contact information of a person, the 181 details of a calendar event, a move in a chess game, etcetera. 183 Alice decides to share one file with only Bob, and keep it invisible 184 for the others. What are the steps through which she can achieve this, 185 depending on the capabilities of her (the sender's) server and Bob's 186 (the recipient's) server? 188 3. Initiate sharing process 190 To initiate the process of sharing a document from her server with 191 Bob, Alice connects to her server with her web browser, providing some 192 credentials (how she provides these is out of scope). She navigates the 193 web interface of her server to select the document she wants to send to 194 Bob. 196 Alice clicks or gestures her 'Share' intent for the document in some 197 way. The software application may have the capacity to act as a 198 [MICROPUB] client, in which case at this point Alice would also specify 199 the MicroPub endpoint to use. 201 4. Recipient selection 203 Alice may have an addressbook on her server where she stores the 204 identities and contact methods of people she knows. She may be able 205 to select Bob from this addressbook using the same or another web 206 interface. She may also have such an addressbook on her own client 207 device, or for instance on paper. Or maybe she knows an identifier for 208 Bob by heart. If Bob or someone else has published some of his contact 209 information, she may use a search application to find out identifiers 210 by which Bob can be contacted, which she can then use directly, and 211 possibly also store in her addressbook for future reference. 213 It is also possible that she remembers or looks up a web page describing 214 how to contact Bob, and discovers a usable identifier this way. An 215 addressbook application may also be able to infer identifiers for 216 various contact methods from such a web page programmatically. 218 Other methods for discovering a contact method and identifier for Bob 219 may rely on Alice knowing that Bob is a friend of Cindy, and she may 220 search a list of friends of Cindy named Bob, to confirm whether the 221 intended Bob is listed there. Similarly, she may remember that Bob is 222 for instance a member of her rowing club, and search a directory of 223 members of that rowing club to locate contact information about him. 224 Again, such an inference may be helped by a software application which 225 is capable of infering such friend-of-a-friend relationships. 227 Finally, Alice may have a contact identifier for Bob which she knows 228 will allow her to communicate with him, but not to share the document 229 with him. She may for instance contact Bob by telephone or irc to ask 230 him for his email address. 232 5. Recipient notification 234 Depending on the contact methods for which Alice has discovered Bob's 235 identifier in the recipient selection step, she may complete the 236 document sharing process by sending either the document data to Bob, or 237 a notification which contains machine-readable and/or human-readable 238 instructions for retrieving the document. For instance, she may send the 239 document as an email attachment, or send an email message that contains 240 a hyperlink or URL through which Bob may access the document. 242 In the case of sending the entire document directly, it will be helpful 243 to include some metadata about the document encoding. In the absence of 244 this, the software application that Bob uses to visualize the received 245 document may try to guess the encoding and media type of the document, 246 for instance by analyzing its first few bytes of data. 248 In the case of sending only the information needed to access the 249 document, but not the document itself, the necessary identifiers and 250 credentials for accessing the document may be given in natural language, 251 accompanied by human-readable instructions like 'You can download the 252 document at the following URL: ..., using the following password: ...'. 254 The notification may also contain information about how Bob can comment 255 on the document, or propose changes. Sometimes this information may be 256 implied by the notification method, or become obvious when Bob accesses 257 the document. For instance, Alice may send the URL of a web page which 258 contains a 'Comment' or 'Edit' button, inviting Bob to comment or 259 propose changes to the document using that web page. These comments and 260 proposed changes may then either be applied and displayed immediately, 261 or the web application may allow Alice to review them before they are 262 applied and displayed. 264 One protocol for notifying recipients is [WEBMENTION]. This is a 265 successor of the older [PINGBACK] and [TRACKBACK] protocols. WebMention 266 is primarily intended for sending comments on existing documents, 267 and not for initially sharing a document in the first place, nor for 268 proposing edits. But by "commenting" on a recipient's main identifying 269 URL (home page), it could also be used to send a document that is not 270 a comment on any existing document. Also, as WebMention comments are 271 often formatted as machine-readable documents using [MICROFORMATS], a 272 'proposed-edit' comment type could be defined, by which Bob's server may 273 communicate Bob's proposed edits to Alice's server in a machine-readable 274 way. The authors intend to research both these possible extensions to 275 the WebMention protocol. 277 The software application may allow Alice to select the method by which 278 to notify Bob, or select a reasonable default. Bob may also publish 279 machine-readable preferences indicating how Bob prefers to receive 280 documents that are shared with him. 282 The notification may also include human-readable information about which 283 types of feedback are invited from Bob. For instance, Alice may share a 284 document which contains a collection of photos, and Bob may be invited 285 to add photos to this collection, but not delete any of the existing 286 ones. The authors intend to research ways of adding such feedback 287 invitations in a machine-readable way, for instance to a WebMention 288 notification. 290 Note that inviting certain types of feedback does not necessarily imply 291 that Alice's server will automatically accept, apply, and display such 292 feedback. Alice may want to review all proposed changes before applying 293 them, and review all comments before displaying them. 295 The notification may include all necessary credentials for accessing the 296 resource, in which case it is important for the software on Bob's server 297 not to display such a notification publically, as this would lead to 298 accidentally publishing a privately shared document publically. 300 Alternatively, the authentication step may be delayed until Bob, or 301 software running on Bob's server, actually accesses the document. 303 The software that Alice uses to send the notification to Bob may use 304 a concept of roles, which summarize which types of feedback Bob will 305 be invited to reply with. For instance, she may select a 'contributor' 306 role to invite Bob to send back only comments and additions, or 307 an 'admin' role inviting Bob to propose any kind of change to the 308 document, including deletions. We consider such roles mainly a matter of 309 interaction between Alice and the software she uses. 311 6. Human access 313 Whichever the way of sending the notification, it SHOULD contain a URL 314 for Bob to open with a browser to view and/or download the document from 315 what we call an access page. 317 The notification MAY include a password or other type of secret 318 which Bob needs to paste or type into the web page. The web page 319 located at the URL from the notification MAY also allow Bob to 320 authenticate with other methods if Alice can reasonably assume 321 Bob will have the ability to use those. Examples of such methods 322 are [OPENID], [INDIEAUTH], [INDIECERT], [PERSONA], [WEBID-TLS], and 323 [WEBID-RSA]. It MAY allow Bob to authenticate by proving he can receive 324 a secret sent to him via mobile telephone short messaging service (SMS) 325 or email. It MAY also allow Bob to authenticate using third-party 326 identity providers like social network sites. 328 Some of these methods of authentication rely on Alice to provide the 329 correct identifier(s) for Bob in the recipient selection step. These 330 identifier(s) are not necessarily equal to the identifier used for 331 sending the notification. For instance, if Alice knows both Bob's 332 WebMention end-point and his mobile phone number, she may send the 333 notification to Bob's WebMention endpoint, but allow Bob to authenticate 334 via SMS while accessing the document. 336 The relationship between Bob's identifiers in different identity systems 337 may in some cases be discovered programmatically, for instance with 338 [WELL-KNOWN] resources, or [REL-ME] links on the main (index) web page, 339 for Bob's personal DNS domain name. 341 The list of authentication methods Bob is offered will be limited by 342 the capabilities of the software that displays the access page for 343 the document. If this software is integrated with Alice's addressbook 344 software, then the addressbook entry for Bob may also be updated with 345 the authentication methods for which Alice provided the identifier, 346 those which were discovered programmatically during the process, and the 347 one that Bob ultimately used to authenticate. 349 The access page MAY also give human-readable instructions to Bob, like 350 "please don't share this document publically", "please don't share 351 outside our Petanque team", or "please discard after reading, or after 352 30 days". Whether or not Bob follows such instructions is out of scope. 354 7. Machine access 356 Some software applications are able to retrieve a document with 357 [UNATTENDED-INDIEAUTH] in reaction to a WebMention notification. 358 Although the [SOLID] platform does not describe how to send or receive a 359 document sharing notification, it does describe how an application can 360 use WebID-TLS or WebID-RSA to authenticate programmatically to retrieve 361 a document of whose existence it is aware. 363 If the URL of the access page contains a secret string of characters 364 [CAPABILITIES], then an application can also access the document without 365 human intervention. 367 If an application or human attempts to access the document without 368 sufficient credentials, a 410 HTTP response code can be sent, together 369 with a WWW-Authenticate header hinting to a proposed authentication 370 method. 372 8. Publishing edits 374 After Alice has shared a document with Bob, if she did not send it 375 directly as for instance an email attachment, she may still edit its 376 contents between the time of sending the notification, and the first 377 time Bob accesses the document through the human-readable access page, 378 or a software application accesses it on Bob's behalf. 380 But even once Bob, or software on his behalf, has accessed the document 381 for the first time, Alice may want to change its contents. For instance, 382 Alice may share her calendar with Bob, and keep adding events to it 383 afterwards. 385 If she does this, she may send Bob a new notification, inviting him to 386 access the document again, to see the changed version. Another way of 387 publishing new versions of a same documents might be for Alice to 388 publish an [RSS] feed, an [ATOM] feed, or a [COUCHDB] changes feed 389 instead of the document itself. 391 Alternatively, the document could contain a reference to a feed of 392 its change history, for instance using a hyperlink in case of a HTML 393 document. A software application accessing the document on Bob's behalf 394 could discover this reference programmatically and keep polling the 395 change feed periodically or each time Bob views the document, apply 396 Alice's changes, and possibly provide a way for Bob to view its change 397 history. 399 The approach where Alice's application sends a new notification to Bob's 400 application is more efficient if changes are rare, because it does 401 not require Bob's application to retrieve the change feed many times 402 (polling). The [PUBSUBHUBBUB] protocol could also be used as a way to 403 avoid unnecessary polling of change feeds. 405 The change feeds could concern one document, or aggregate changes in all 406 changes Alice ever shared with Bob into one feed. The MicroPub protocol 407 also supports updating documents that have already been published 408 [MICROPUB-UPDATES], so the application Alice uses to update the document 409 could send a MicroPub Update to the application which handles the 410 sharing of the document. 412 There are also situations where Bob can be expected not to make any 413 copies of the original document version, retrieving it always directly 414 from Alice's server when needed, and Bob may be more interested in 415 always retrieving the latest version, instead of being notified about 416 changes when they happen. An example could be when the document contains 417 an [OEMBED] data snippet, which Bob embeds in another document by 418 reference. This also means Bob will no longer have access to the 419 document if Alice revokes his access to it, or stops publishing the 420 document at its URL. 422 9. Comments and write access 424 Regardless of whether or not Alice has invited him to do so in the 425 notification or in the access page, Bob may send reactions, like 426 comments, answers, additions, or proposed changes to Alice. He may send 427 Alice a notification for each reaction, a reference to a change feed, 428 for Alice's server application to poll. 430 It is up to Alice's application to either display all of Bob's comments 431 and changes immediately, or for instance to only display additions and 432 not deletions. This MAY be signalled in the notification and/or in the 433 access page (see above), so that Bob knows whether he effectively has 434 "write access" or "read-only access" to the document or not. 436 Alice's server may immediately apply Bob's changes (depending possibly 437 on the type of change) without Alice's intervention. If there were 438 multiple recipients, then maybe some recipients have permission to edit 439 (i.e., changes they propose will always be applied), and others only to 440 view (i.e., when they send a proposed change, it is not applied, or is 441 only applied after Alice reviewed and approved it. 443 This means that Alice can keep modifying the resource after sending it, 444 and Bob can also send modifications back to Alice. If Bob's application 445 retrieved a copy of the document and becomes aware of changes to it made 446 or approved by Alice, it SHOULD display such changes automatically, 447 possibly with a way to browse the change history. Alice's application 448 MAY display the document to Alice in its latest version with all its 449 approved changes (regardless of who proposed those changes), or display 450 both the version she shared and the modifications proposed by Bob 451 side-by-side. 453 We will now consider the case where Alice sent the message to possibly 454 more than one recipient, and the document may at any point contain 455 changes proposed by any of these recipients (either accepted immediately 456 by Alice's application, or reviewed and approved by Alice). When Alice's 457 change feed contains changes initiated by one of the recipients, it 458 SHOULD refer back to the URL where this change was originally proposed 459 by the recipient in question. This will allow the application of a 460 recipient to programmatically compare the "master" change feed published 461 by Alice with the list of changes proposed by that recipient itself. 462 This is a common pattern in [GIT] versioning, where branches can be 463 merged into a master branch, retaining the information about the 464 individual changes (commits). 466 If Bob reacts with a comment or a change proposal, he should somehow 467 notify Alice of this. WebMention was intended to do exactly this, 468 for comments on a publically published document. It is common for 469 applications to display (links to) all comments on a document on its 470 public access page. This practice may lead to [LINK-SPAM] when applied 471 to public documents, and when applied to privately shared documents, it 472 may result in accidentally publishing a private comment to the other 473 recipients of that shared document. 475 Bob MAY also send proposed changes to Alice over http, using a verb 476 like PUT or PATCH. This practice is used in [READ-WRITE-WEB] and 477 [COUCHDB], among others. Such HTTP requests SHOULD be responded to with 478 a HTTP response status that indicates whether the change request was 479 successful, accepted to be reviewed, or rejected. 481 A third practice for sending change proposals are git pull requests, 482 which would traditionally be sent to Alice by pgp-signed email, with the 483 proposed patch in an attachment. 485 The authors intend to research whether we could define a way to mark up 486 change proposals in microformats, for Bob to post an updated version 487 and notify Alice of this. For instance, if Alice published a document 488 containing an h-entry of type photo-album, then a reaction to this could 489 be of type addition, and refer to a photo which Bob wants to be added to 490 that photo album. The same pattern could serve for adding events to a 491 calendar, or adding files in a document which represents a file system 492 directory. 494 Alice's application MAY be able to interpret changes to a document and 495 resolve the possible conflicts between them in certain cases (see also 496 the Data domains section below), or notify Alice and/or Bob that more 497 information is needed to resolve the conflict. A conflict occurs when 498 Alice and Bob both make changes in the document and arrive at different 499 new versions. In database theory this is called the optimistic lock 500 pattern: conflicts are tolerated, but the versions should eventually 501 converge and reach consistency. A pessimistic lock pattern would require 502 notifying all other actors with access to the document before starting 503 to make any changes to the current document version. 505 10. Real-time collaboration 507 If Alice and Bob are connected to the internet simultaneously, a 508 real-time conversation may be initated, for instance using [WEBRTC]. 509 For example, Alice might share a document with Bob which represents a 510 "phone call", after which an application on Bob's server may send a 511 [PUSH-NOTIFICATION] to Bob's (mobile) device, and when Bob gestures to 512 "pick up the phone", his server could react to Alice's "phone call" with 513 a document representing a WebRTC SessionDescriptionProtocol object. This 514 would allow rapid exchange of information back-and-forth between Alice 515 and Bob, for the duration of the real-time collaboration session. 517 Also, if Bob uses the access page to propose changes to the document, 518 and Alice is also connected to the internet at that time, the 519 interchange between Alice and Bob may be communicated between Alice's 520 server and her client device via [WEBSOCKETS]. This scenario could 521 be also be generalized to the situation where more than two people 522 are viewing, and possibly editing, the same document. To reduce the 523 information traffic that would need to pass through Alice's server, 524 these WebSockets could be used to establish WebRTC data channels between 525 each device, provided these devices support WebRTC, and that changes are 526 still submitted and ultimately committed to the dominant current version 527 of the document, on Alice's server. 529 11. Listing and revoking access 531 If Alice wants to share several documents with several people, a 532 software application on her server SHOULD allow her to view a list of 533 who has access to which document. 535 This list view SHOULD also display whether she configured the 536 application to programmatically apply any comments and/or proposed 537 changes from these people, and/or whether these people have been sent 538 an invitation to comment or propose changes, whether as part of the 539 notification they were sent, or through the human-readable access page. 541 It MAY also display whether the recipient has already accessed or 542 retrieved the document or not. It MAY also give Alice the option to 543 revoke access entirely, taking into account that the recipient may 544 already have made a private copy of the document. It MAY also give 545 Alice the option to change, for each recipient, whether their comments 546 and/or proposed changes will be displayed and applied programmatically, 547 acknowledged and queued for Alice to review, or rejected altogether. 549 If Bob uses an application on his own server to display the document 550 shared by Alice, and this application is capable of programmatically 551 applying all changes Alice sends as updates after sharing the initial 552 version, then Bob SHOULD EITHER be given a way to instruct that 553 application to stop or start programmatically applying all changes sent 554 by Alice, OR provide a way for Bob to view all versions Alice sent. It 555 MAY also provide a way to visualize the differences between the versions 556 published by Alice, and changes proposed by Bob. 558 If Alice publishes updates which correspond to changes proposed by 559 Bob or other recipients, then these updates MAY refer to the URL 560 where these people originally proposed such changes. That way, Bob's 561 application can display which proposed changes have been accepted by 562 Alice into her master version of the document. Alternatively, Bob's 563 application could still compare a change made by Alice with each of 564 Bob's proposed changes, to find out whether it's identical to one of 565 them, and display this change to Bob as 'his' change, accepted by Alice, 566 rather than as a change initiated by Alice. 568 12. Data domains 570 12.1 Discovering the semantics of a document 572 If Bob retrieves the access page with his browser, the presentation 573 can be tailored to how Bob as a human wants to consume the data. For 574 instance, multiple download/export formats may be offered using a web 575 view in a natural language Bob understands. 577 When Bob's application retrieves the document, it may not be able to 578 discover its semantics, and therefore may not be able to add it to 579 existing document collections on Bob's server in a way that allows 580 Bob to use the document in the way it was intended by Alice. For 581 instance, if Bob's application stores hypertext documents as [HTML] 582 documents, but Alice's server uses the [MARKDOWN] format for all 583 hypertext documents, a conversion process may be necessary to translate 584 documents shared by Alice to the format for which Bob's application can 585 offer domain-specific features. Otherwise, his application may display 586 the markdown document as just a string of data, or as if it were a plain 587 text document, and not allow Bob to follow the hyperlinks from there. 589 Data format hints can be provided using Content-Type headers, or some 590 self-describing data notation [JSON-LD, RDF, TURTLE, RDFA]. This can 591 then point to a unique entry in some vocabulary of data formats. 593 Even if Bob's application can programmatically discover the 594 data format in which Alice intended the documented to be 595 interpreted semantically, there are many incompatible vocabularies 596 [VOCABULARIES]. To complicate things further, many competing data 597 formats exist for the most common data domains. 599 For instance, consider the case where Alice wants to share a description 600 of a person's contact details with Bob. Let's assume Alice's application 601 sends this document in the Turtle format, and Bob's application 602 recognizes the Content-Type header, and is able to machine-read Turtle 603 documents. 605 Further assume that Alice's application uses the [DBPEDIA] vocabulary 606 to link to the "person" concept. If Bob's application uses the 607 [MICROFORMATS] vocabulary to interpret documents, it may be able to 608 discover the equivalence between the "person" concept as defined by 609 DBPedia and the "person" concept as defined by MicroFormats, through 610 [SAME-AS-LINKS]. 612 But even then, in order for Bob's application to give Bob the option to 613 merge the information from the Turtle+DBPedia document into an existing 614 Turtle+MicroFormats document representing the same person, the two 615 vocabularies are likely to differ in which attributes they are able to 616 express, and same-as links may not exist for all individual attributes. 618 Also, inference rules will sometimes be needed to for instance compose a 619 full telephone number if parts of it are represented as an international 620 access code or an area code, or to compose a full name from a family 621 name and a given name or list of first name initials. 623 This means that communicating the intended semantic interpretation of 624 a document in a machine-readable way involves three hurdles: first, 625 the hinting mechanism, whether part of the document (self-describing) or 626 added as metadata (for instance in a Content-Type header) which links 627 to a URI for the data format, then resolving the equivalence between 628 the many identifiers which exist for the same concept, but in different 629 vocabularies, and finally converting Alice's data format itself to a 630 data format that allows Bob's application to offer functionality beyond 631 simply displaying the raw data from the document. 633 Sending for instance a photo, a text document, a contact (description of 634 a person), a blog post or Activity [ACTIVITY-STREAMS], a comment, a git 635 pull request, etc., will only work in rare cases where Bob's application 636 is able to handle the hinting mechanism, as well as the data format, as 637 well as the semantic vocabulary used. 639 Our recommendation would be for the receiving application to support 640 many data format hint mechanisms, as well as many data formats, as well 641 as many vocabularies, giving preference to those often used in practice, 642 and to those which have been accepted as W3C recommendations. 644 12.2 Programmatic conflict resolution 646 When Alice's application receives multiple proposed changes to one 647 single version of the document, and Alice accepts both changes, then 648 this constitutes a versioning conflict. After applying the first change, 649 it is no longer possible to apply more changes directly, since they 650 propose to change a version of the document which is no longer the 651 current version. In this situation, Alice's application MAY visualize 652 this conflict to Alice, so that she can decide how the conflicting 653 change can be transformed into a change to be applied to the current 654 version. 656 But in some cases, Alice's application can also apply inference rules to 657 determine this transformation programmatically. To achieve this, Alice's 658 application needs to have different inference rules that are specific 659 to the data format, as well as to the concept about which the document 660 expresses information. 662 For instance, for a document in Turtle format, representing contact 663 information for a person, transforming the addition of a mobile phone 664 number past a change in work place could be safe to do programmatically, 665 without consulting Alice explicitly. The transformation rule would be 666 specific to the data domain (contact information of a person), and also 667 to the data format (Turtle). Attempting to apply transformation rules 668 that work for text files to for instance raw image data will lead to 669 undesired results. 671 There will also remain cases where such programmatic conflict resolution 672 cannot be achieved at all without leading to incorrect results. For 673 instance, when multiple proposed changes propose to change the same 674 data field within a Turtle document, they contradict each other even at 675 the semantic level (not just at the syntactical level), and Alice and 676 Bob will likely want to communicate more with each other to agree which 677 proposed change to apply, and which one to discard. 679 13. Security Considerations 681 When Alice's application sends a notification about a document that was 682 shared with a limited audience, it SHOULD NOT send this notification in 683 such a way that Bob's application, or Bob himself, could interpret this 684 notification as describing a publically published document. 686 The access page through which Bob may view the document which Alice 687 shared with him, SHOULD clearly display instructions for how Bob should 688 treat the document's content, including if, how, and for how long, he 689 may store a copy of the document on another medium, and if, how, and 690 with whom, he may discuss or share the contents of the document. 692 Furthermore, Alice's application SHOULD make it clear to Alice that she 693 depends on Bob's cooperation and decision to follow these instructions 694 or not. 696 14. IANA Considerations 698 This document does not propose any new entries in any IANA naming 699 registry. 701 15. Acknowledgements 703 The authors would like to thank everybody who contributed to the 704 development of the ideas discussed in this document, including the 705 IndieWeb and Social Web communities, the Decentralized Sharing Working 706 Group, the participants in OuiShareLabsCamp 2015, as well as Alice and 707 Bob themselves. 709 16. References 711 16.1. Normative References 713 [WORDS] 714 Bradner, S., "Key words for use in RFCs to Indicate Requirement 715 Levels", BCP 14, RFC 2119, March 1997. 717 [IMAP] 718 M. Crispin, "Internet Message Access Protocol - Version 4rev1", 719 RFC 3501, March 2003. 721 [HTTPS] 722 E. Rescorla, "HTTP Over TLS", RFC2818, May 2000. 724 [SMTP] 725 J. Klensin, "Simple Mail Transfer Protocol", RFC 5321, 726 October 2008. 728 [POP] 729 J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1939, 730 May 1996. 732 [OPENID] 733 OpenID Foundation, "OpenID Authentication 2.0 - Final", 734 http://openid.net/specs/openid-authentication-2_0.html, December 2007. 736 [WELL-KNOWN] 737 M. Knottingham, E. Hammer-Lahav, "Defining Well-Known Uniform 738 Resource Identifiers (URIs)", RFC 5785, April 2010. 740 [CAPABILITIES] 741 J. Tennison (ed.), "Good Practices for Capability URLs", 742 http://www.w3.org/TR/capability-urls/, February 2014. 744 [RSS] 745 D. Winer, "RSS 2.0 Specification", 746 http://cyber.law.harvard.edu/rss/rss.html, July 2003. 748 [ATOM] 749 M. Nottingham (ed.), R. Sayre (ed.), "The Atom Syndication 750 Format", RFC 4287, December 2005. 752 [WEBRTC] 753 A. Bergkvist, D. C. Burnett, C. Jennings, A. Narayanan, 754 "WebRTC 1.0: Real-time Communication Between Browsers", 755 http://www.w3.org/TR/webrtc/, February 2015. 757 [PUSH-NOTIFICATION] 758 B. Sullivan, E. Fullea, M. van Ouwekerk, "Push API", 759 http://www.w3.org/TR/push-api/, April 2015. 761 [WEBSOCKETS] 762 I. Hickson, "The WebSocket API", 763 http://www.w3.org/TR/websockets/, September 2012. 765 [HTML] 766 I. Hickson, R. Berjon, S. Faulkner, T. Leithead, E. Doyle 767 Navara, E. O'Connor, S. Pfeiffer, "A vocabulary and associated APIs for 768 HTML and XHTML", http://www.w3.org/TR/html5/, October 2014. 770 [JSON-LD] 771 M. Sporny, G. Kellogg, M. Lanthaler, "JSON-LD 1.0", W3C Proposed 772 Recommendation, http://www.w3.org/TR/2014/REC-json-ld-20140116/, January 773 2014. 775 [RDF] 776 G. Schreiber (ed.), Y. Raimond (ed.), "RDF 1.1 Primer", 777 http://www.w3.org/TR/rdf11-primer/, June 2014. 779 [TURTLE] 780 E. Prud'hommeaux (ed.), Gavin Carothers (ed.), D. Beckett, 781 T. Berners-Lee, "RDF 1.1 Turtle: Terse RDF Triple Language", 782 http://www.w3.org/TR/turtle/, February 2014. 784 [RDFA] 785 B. Adida, M. Birbeck, S. McCarron, I. Hermans, "RDFa Core 1.1 786 - Third Edition: Syntax and processing rules for embedding RDF through 787 attributes", http://www.w3.org/TR/rdfa-core/, March 2015. 789 16.2. Informative References 791 [MICROPUB] 792 A.Parecki (ed.), "MicroPub", http://indiewebcamp.com/wiki/inde \ 793 x.php?title=Micropub&oldid=19338, May 2015. 795 [WEBMENTION] 796 IndieWebCamp Wiki, "WebMention", http://indiewebcamp.com/wiki/ \ 797 index.php?title=Webmention&oldid=19485, May 2015. 799 [PINGBACK] 800 S. Langridge, I. Hickson, "Pingback 1.0", 801 http://www.hixie.ch/specs/pingback/pingback, 2002. 803 [TRACKBACK] 804 See: https://movabletype.org/documentation/trackback/specifica \ 805 tion.html 807 [MICROFORMATS] 808 See: http://microformats.org/ 810 [INDIEAUTH] 811 See: https://indieauth.com/ 813 [INDIECERT] 814 See: https://indiecert.net/ 816 [PERSONA] 817 See: https://developer.mozilla.org/en-US/Persona. 819 [WEBID-TLS] 820 See: https://github.com/linkeddata/SoLiD#webid-tls 822 [WEBID-RSA] 823 See: https://github.com/linkeddata/SoLiD#webid-rsa 825 [REL-ME] 826 See: 827 http://microformats.org/wiki/index.php?title=rel-me&oldid=64351 829 [UNATTENDED-INDIEAUTH] 830 See: http://indiewebcamp.com/wiki/index.php?title=indieweb-mes \ 831 saging&oldid=19179#Protocol_Flow 833 [SOLID] 834 See: https://github.com/linkeddata/SoLiD 836 [COUCHDB] 837 See: http://docs.couchdb.org/en/1.6.1/intro/api.html 839 [PUBSUBHUBBUB] 840 B. Fitzpatrick, B. Slatkin, M. Atkins, J. Genestoux, 841 "PubSubHubbub Core 0.4 -- Working Draft", http://pubsubhubbub. \ 842 github.io/PubSubHubbub/pubsubhubbub-core-0.4.html, February 843 2014. 845 [MICROPUB-UPDATES] 846 A.Parecki (ed.), "MicroPub: Update", http://indiewebcamp.com/w \ 847 iki/index.php?title=Micropub&oldid=19338#Update, May 2015. 849 [OEMBED] 850 See: http://www.oembed.com/#section7 852 [GIT] 853 See: http://www.git-scm.com/ 855 [LINK-SPAM] 856 See: https://en.wikipedia.org/wiki/Spamdexing#Link_spam 858 [READ-WRITE-WEB] 859 See: https://www.w3.org/community/rww/ 861 [MARKDOWN] 862 See: http://daringfireball.net/projects/markdown/ 864 [VOCABULARIES] 865 See: https://www.w3.org/Social/track/issues/15 867 [DBPEDIA] 868 See: http://wiki.dbpedia.org/ 870 [SAME-AS-LINKS] 871 See: http://sameas.org/ 873 [ACTIVITY-STREAMS] 874 See: http://activitystrea.ms/specs/ 876 17. Authors' addresses 878 Michiel B. de Jong 879 (independent) 881 Email: michiel@michielbdejong.com 883 Paul Tran-Van 884 (Cozy Cloud) 886 Email: paul@cozycloud.cc