-
Notifications
You must be signed in to change notification settings - Fork 5
Expand file tree
/
Copy pathindex.html
More file actions
961 lines (959 loc) · 52.2 KB
/
Copy pathindex.html
File metadata and controls
961 lines (959 loc) · 52.2 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
<!DOCTYPE html>
<!-- saved from url=(0022) -->
<html class=" js flexbox flexboxlegacy canvas canvastext webgl no-touch geolocation postmessage websqldatabase indexeddb hashchange history draganddrop websockets rgba hsla multiplebgs backgroundsize borderimage borderradius boxshadow textshadow opacity cssanimations csscolumns cssgradients cssreflections csstransforms csstransforms3d csstransitions fontface generatedcontent video audio localstorage sessionstorage webworkers applicationcache svg inlinesvg smil svgclippaths">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Home - LIME Protocol</title>
<link href="./files/bootstrap.css" rel="stylesheet">
<link href="./files/lime.css" rel="stylesheet">
<link href="./files/json-highlight.css" rel="stylesheet">
</head>
<body data-feedly-mini="yes">
<header>
<div class="navbar navbar-default navbar-inverse navbar-fixed-top" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="index.html">LIME Protocol</a>
</div>
<div class="navbar-collapse collapse">
<ul class="nav navbar-nav">
<li><a href="index.html">Specification</a></li>
<li><a href="content-types.html">Content Types</a></li>
<li><a href="resources.html">Resources</a></li>
<li><a href="libraries.html">Libraries</a></li>
<li><a href="about.html">About</a></li>
</ul>
</div>
</div>
</div>
</header>
<div class="container body-content">
<div class="row">
<div class="col-md-10" role="main">
<h1 class="page-header" id="introduction">Introduction</h1>
<div class="alert alert-warning">This specification is a <strong>work in progress</strong> and is subject to change without notice.</div>
<h3 id="what">What is it?</h3>
<p><strong>LIME Protocol</strong> (an acronym for <em>Lightweight Messaging Protocol</em>) is a JSON-based protocol for messaging, inspired by the XMPP protocol. It aims to be simple but extensible, with little verbosity yet providing good readability.</p>
<h3 id="xmpp">And why not just use XMPP?</h3>
<p>XMPP is a protocol widely used for real-time communication but is complex due to the number of features and extensions that it implements. Just take a look at its <a href="http://xmpp.org/xmpp-protocols/xmpp-core/">specification</a> to understand that XMPP goes far beyond what LIME proposes.</p>
<p>This protocol defines only a basic message structure and makes use of the MIME content-type declarations to remain extensible but is not meant to cover all the scenarios that XMPP supports.</p>
<h1 id="definitions" class="anchor">Definitions</h1>
<h3 id="concepts">Concepts</h3>
<p>The basic idea of the protocol is the exchange of JSON documents between elements in a network. These documents are called <strong>envelopes</strong> and these elements are called <strong>nodes</strong>.</p>
<p>The protocol defines four types of envelopes:</p>
<ul>
<li>
<strong><a href="#message">Message</a></strong> - Provides the transport of content between nodes in a network.
</li>
<li>
<strong><a href="#notification">Notification</a></strong> - Notify events related to a message.
</li>
<li>
<strong><a href="#command">Command</a></strong> - Allows the manipulation of node resources, like server session parameters or information related to network nodes.
</li>
<li>
<strong><a href="#session">Session</a></strong> - Allows the configuration and establishment of the communication channel between nodes.
</li>
</ul>
<p>
The nodes communicate with each other over persistent connections, like TCP or Websockets.
The protocol is asynchronous, so there's no guarantee of delivery order of the envelopes, except during the session negotiation, where only session envelopes are allowed.
</p>
<p>
Every connected node must have an identity, presented in the <em>name@domain</em> format, as defined by the <a href="http://tools.ietf.org/html/rfc2822#section-3.4.1">RFC 2822, section 3.4.1</a>.
The domain name should be a valid domain (i.e. can be resolved by a DNS server) and the name a valid user account identifier in the domain.
The identity is authenticated by the server during the establishment of the session.
</p>
<p>
In addition to the identity, the connected node can suggest a name to the particular connection using an identifier called <em>instance</em>.
This identifier should appear after the identity, separated by a slash (/) symbol, during the session authentication process.
One identity can have more than one active connection in a domain so the <em>instance</em> should be used to differentiate these connections.
Usually is used the name of the device (John-Cellphone, John-PC), but can be any valid string. If not provided, the server will set a default value.
</p>
<p>
Therewith, the complete format of a node identifier is <em>name@domain/instance</em>, similar to the <a href="http://xmpp.org/rfcs/rfc3920.html#rfc.section.3">XMPP's Jabber ID</a>
(the difference is that the identifier located after the slash is called <em>instance</em> instead of <em>resource</em>).
</p>
<p>
During a connection, there's a <strong>server</strong> which is the node that received the connection, and the <strong>client</strong>, the node which started it.
The only difference between these roles is related to the session state management, where the server has full control of it. Besides that, they share the same set of functionality.
During the session establishment, the server provides a session id, its own node identifier, and the client node identifier. It can optionally authenticate the client using an authentication scheme or provide an arbitrary node identifier without asking for any information about the client.
</p>
<p>
Although both parties of a session know each other's node identifier, they can receive and send envelopes with distinct node information of the remote party.
This means that a node can act as an intermediate to be an envelopes switcher for nodes that are not directly connected. But it must be trusted by both sender and destination nodes for that.
</p>
<p>
For instance, in a session between <em>client@domain/instance</em> and <em>server@domain/instance</em> the first one can receive an envelope that the sender is <em>someone@domain/instance</em> in that session.
In this case, the client must decide if it trusts the remote party to send envelopes with that node identifier. Specifically, it should look if the remote party is trusted to originate envelopes on behalf of the specified node domain.
This trust should be built outside the protocol, using techniques like a DNS query to look for an SRV entry to connect to a specified domain and transport TLS authentication.
You can trust a remote party if the remote certificate is a valid <strong>domain certificate</strong>, emitted by a trusted issuer.
In the case of receiving an envelope addressed to a different node, the party that received it can forward it to the destination, but only if it can directly reach it.
This means that the node must have a direct connection with that node or with a node that is trusted to receive this envelope, in the same conditions that are illustrated above.
And after the envelope has been forwarded, the actual envelope destination should decide if it trusts the remote party in the same way.
</p>
<h3 id="envelope">Envelope</h3>
<p>The JSON documents exchanged in a LIME conversation are called envelopes. The JSON data must be compliant with the <a href="http://tools.ietf.org/html/rfc4627">RFC 4627</a> specification, using the <a href="http://tools.ietf.org/html/rfc3629">UTF-8</a> encoding.</p>
<p>Every envelope may contains the following properties:</p>
<ul>
<li>
<strong>from</strong> - Identifier of the sender node of the envelope, in the <em>name@domain/instance</em> format. If a node receives an envelope without this value, it means that the envelope was originated by the remote party.
</li>
<li>
<strong>to</strong> - Identifier of the destination node of the envelope, in the same format of the sender. If a node receives an envelope without this value, it means that the envelope is addressed to itself.
</li>
<li>
<strong>pp</strong> - Acronym for <em>per procurationem</em>. Identifier of a delegate node (a node that received a permission to send on behalf of another), in the <em>name@domain/instance</em> format. Allows a node to send an envelope on behalf of another identity.
</li>
<li>
<strong>id</strong> - Identifier of the envelope, which can be any relevant value for the caller.
</li>
<li>
<strong>metadata</strong> - Allows the transport of generic information, in the "name": "value" format. This property is optional for all envelopes. Any value set in this property should not change the behavior of the server.
</li>
</ul>
<h3 id="message">Message</h3>
<p>A message provides the transport of a content between nodes in a network.</p>
<p>JSON Schema:</p>
<pre>
<code class="json-schema">
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "message",
"type": "object",
"properties": {
"from": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
},
"to": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
},
"pp": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
},
"id" : {
"type": "string"
},
"metadata": {
"type": "object"
},
"type" : {
"type": "string",
"pattern": "^[-\w]+/[-\w.]+(\+\w+)?$"
},
"content" : {
"type": "object"
},
},
"required": [ "type", "content" ],
"additionalProperties": false
}
</code>
</pre>
<p>In a message, the following constraints should apply to the envelope properties:</p>
<ul>
<li>
<strong>id</strong> - Optional. The sender just need provide this information in order to receive notifications related to the message. If not provided, the message is processed in the <em>fire-and-forget</em> mode.
</li>
<li>
<strong>from</strong> - Optional for the sender, since the value can be determined by the server in the session. mandatory in the destination.
</li>
<li>
<strong>to</strong> - Mandatory for the sender, but is allowed to ommit the value of the <em>instance</em> (the server will route the envelope according to the routing rule chosen by the destination) and/or <em>domain</em> (the server will assume that the destination is in the same domain of the sender) properties. optional in the destination.
</li>
<li>
<strong>pp</strong> - Optional for the sender, when is considered the identity of the session. Is mandatory in the destination if the identity of the originator is different of the identity of the <em>from</em> property.
</li>
<li>
<strong>metadata</strong> - Optional. The sender should avoid to use this property to transport any kind of content-related information, but merely data relevant to the context of the communication. Consider to define a new content type if there's a need to include more content information into the message.
</li>
</ul>
<p>Besides the properties defined in the envelope, a message should contains:</p>
<ul>
<li>
<strong>type</strong> - <a href="http://tools.ietf.org/html/rfc2045">MIME</a> declaration of the content type of the message.
This property is used by the destination to handle the content in the appropriate way.
The MIME can be any discrete type (text, application, image, video or audio; composite types, like message or multipart, are not supported).
For structured data, is recommended to use JSON subtypes (like <em>application/json</em> or <em>application/vnd.specific+json</em>), althought is possible to send other types, like XML, provided that the unsupported characters in content are escaped, accordinally to the JSON specification.
The protocol defines some <a href="content-types.html">common types</a> that should be reused.
If you are using a custom content type, consider <a href="http://www.iana.org/cgi-bin/mediatypes.pl">registering it</a> with IANA in order to provide interoperability.
</li>
<li>
<strong>content</strong> - The representation of the content. JSON content data are represented unescaped.
Binary data (images, video and audio) should be represented with the Base64 encoding.
The remaining data types should be represented as an escaped value.
</li>
</ul>
<p class="lead">Examples</p>
<p><em>Fire-and-forget</em> (no id) text message:</p>
<pre>
<code class="json">
{
"from": "skyler@breakingbad.com/bedroom",
"to": "ww@breakingbad.com",
"type": "text/plain",
"content": "Walter, are you in danger?"
}
</code>
</pre>
<p>JSON text message with metadata and notification support, omitting the destination domain:</p>
<pre>
<code class="json">
{
"id": "my-id",
"from": "heisenberg@breakingbad.com/bedroom",
"to": "skyler/bedroom",
"type": "application/vnd.lime.threadedtext+json",
"content": {
"text": "I am the one who knocks!",
"thread": 2
},
"metadata": {
"senderIp": "192.168.0.1"
}
}
</code>
</pre>
<p>Binary text message with notification support:</p>
<pre>
<code class="json">
{
"id": "65603604-fe19-479c-c885-3195b196fe8e",
"to": "heisenberg@breakingbad.com/bedroom",
"type": "image/png",
"content": "iVBORw0KGgoAAAANSUhEUgAAACsAAAAqCAMAAAAd31JXAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAyJpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMC1jMDYwIDYxLjEzNDc3NywgMjAxMC8wMi8xMi0xNzozMjowMCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6MEYyQzgwNTUxQkY2MTFFMkE2NzBBRjFERkI1MEFCQjUiIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6MEYyQzgwNTYxQkY2MTFFMkE2NzBBRjFERkI1MEFCQjUiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDowRjJDODA1MzFCRjYxMUUyQTY3MEFGMURGQjUwQUJCNSIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDowRjJDODA1NDFCRjYxMUUyQTY3MEFGMURGQjUwQUJCNSIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PnkDBYEAAADAUExURcbhnr/flKbTaZPJSrPZfprMVKzWdMzlqcXinpTKS9jsvt7vyKDPX7ncieLxz9Los5vMVtTqt/j788bin6/Wec/lruby1dvswtXouJDIRfH459Lns+v13eDvy+r02+7246zUc6LRY6nTbev13t3txuXy05TJS73cj5vNV7HYe6LPYrjbh7bZhJ7OXL/fk7naiZfLUKrUb6XRZ9vtw+nz2uPw0LPXfsnipM3mq9jqvcDdk8zkqbzcjvH46P///43GP1/s3CQAAALWSURBVHjajJXpmqowDIYtlB1kVQE3wH0ddfalJ/d/V6fQAtUZz5n8kMfyJv2aJqHz5/fW+b4UdKkF/2UDf7cGOHmeB/nRv3UQ2XQHp2z/0RtQiz8fskOS+z+z6SbZrt6fCLOFRWbz4cth7f/A+kbRGRPiYmRBZYpFyGzw4eWTW9Y/rcbEkkpIZywgXdJH0zgzJtfsY7J6Ihpj+AM0hQbXyDiqYcamxv6JuHU8WfRRzHFmpAKbZ1QARwBL7KHW8eND3rJv3pCQ+hVIjDXr/9DtJGHNBsbD1NQaVkaVh9awznNhBJw9egMqQHKlWkR9stqZ9JYhZ2lYiSVJblgFQWvWbF8GpuzjMuYpUFjo8kdAJcsksedX7LHoN1qxzji5WVEdLIM2izYVm+/bHICtUeUyqJUaGevIrtSRjlGx8EmEHWVs06SVkm0OljLIEBjbE1mqw0KOAoqO2yWFvEOXsl3KjhAyTVNDSDN1ZNKSxKoqusOi17AES6XxF5S14NrMTqWhZB1x3RkRotHjS2KGv7jeLyKsSrriuIsyDQrGTn04sufsS8sqLq1IVZHrw9oqKtOnkmhdseuiX2+numUVUEW4rQbV1fRRv2B3sfPmrKZknR3eub5jqpbMvTdWD8lwVO3HS8cuPbAsZoHEyYTXWTSjWzp1RquQsnPFrta8Jnen2MWmDWL5gi4ENp8vR86m8DBtOhNs5qTowg33lmndb+ftgDQtg4SWZ+b2o2PTm11YzRZX3VZGq73x9PUUtD2/oY3MmTazXLFE4kMozIfAyOYL8WTVJbB+Hs0v+dWM6kI0Rs1FcBvJ9IRkfjOj6OyDbDijtSAJ1WWWg7V3uZ199PaMZTTsC+OH7j4dv0bLPP0+q4PQWGad8dRCNLSN9cV08LEFCO98L/w1bF+G8z6150G8ouR5cv871N1A4l2Kojh4CZzD9N/frMAPz7swDP3Jb75vd+2vAAMAIkNXL7uoiZEAAAAASUVORK5CYII="
}
</code>
</pre>
<h3 id="notification">Notification</h3>
<p>A notification transports information about events associated to a message sent in a session. Can be originated by a server or by the message destination node.</p>
<p>JSON Schema:</p>
<pre>
<code class="json-schema">
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "notification",
"type": "object",
"properties": {
"from": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
},
"to": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
},
"pp": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
},
"id" : {
"type": "string"
},
"metadata": {
"type": "object"
},
"event" : {
"enum": [
"accepted",
"dispatched",
"received",
"consumed",
"failed"
]
},
"reason" : {
"type": "object",
"properties": {
"code" : {
"type": "integer"
},
"description": {
"type": "string"
}
},
"required": [ "code" ]
}
},
"required": [ "id", "event" ],
"additionalProperties": false
}
</code>
</pre>
<p>In a notification, the following constraints should apply to the envelope properties:</p>
<ul>
<li>
<strong>id</strong> - Mandatory. The id references the related message.
</li>
<li>
<strong>from</strong> - Optional. If the value is not present in the destination, it means that the notification was generated by the connected node (server).
</li>
<li>
<strong>to</strong> - Mandatory for the sender and optional in the destination. The sender can ommit the value of the <em>domain</em>.
</li>
<li>
<strong>pp</strong> - Optional for the sender, when is considered the identity of the session. Is mandatory in the destination if the identity of the originator is different of the identity of the <em>from</em> property.
</li>
<li>
<strong>metadata</strong> - Optional. Avoid to use this property to transport any event-related data.
</li>
</ul>
<p>Besides the envelope properties, a notification may contains:</p>
<ul>
<li>
<strong>event</strong> - Name of the event. This property is mandatory. The possible values are:
<ul>
<li>
<strong>accepted</strong> - The message was received and accepted by the server.
</li>
<li>
<strong>dispatched</strong> - The message was dispatched to the destination by the server.
</li>
<li>
<strong>received</strong> - The destination has received the message. This event is generated by the destination node.
</li>
<li>
<strong>consumed</strong> - The destination has consumed (read or processed) the message. This event is generated by the destination node.
</li>
<li>
<strong>failed</strong> - A problem occurred during the processing of the message. In this case, the <em>reason</em> property of the notification should be present.
</li>
</ul>
</li>
<li>
<strong>reason</strong> - In the case of a <em>failed</em> event, this property brings more details about the problem. It contains the following properties:
<ul>
<li>
<strong>code</strong> - Code number of the reason. There are some protocol pre-defined codes, but may exists specific codes for each implementation of the protocol.
</li>
<li>
<strong>description</strong> - Description message of the problem. This property can be omitted.
</li>
</ul>
</li>
</ul>
<p class="lead">Examples</p>
<p>Received notification sent by the destination node:</p>
<pre>
<code class="json">
{
"id": "48600604-ce09-479c-b985-1195b196fe8e",
"from": "skyler@breakingbad.com/bedroom",
"to": "heisenberg@breakingbad.com/bedroom",
"event": "received"
}
</code>
</pre>
<p>Failure notification sent by the server:</p>
<pre>
<code class="json">
{
"id": "9d0c4fea-75c7-432a-a164-c1a219bc17a8",
"to": "skyler@breakingbad.com/bedroom",
"event": "failed",
"reason": {
"code": 42,
"description": "The message destination was not found"
}
}
</code>
</pre>
<h3 id="command">Command</h3>
<p>Allows the manipulation of node resources, like server session parameters or information related to the network nodes.</p>
<p>JSON Schema:</p>
<pre>
<code class="json-schema">
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "command",
"type": "object",
"properties": {
"from": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
},
"to": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
},
"pp": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})$"
},
"id" : {
"type": "string"
},
"metadata": {
"type": "object"
},
"method" : {
"enum": [
"get",
"set",
"merge",
"delete",
"subscribe",
"unsubscribe",
"observe"
]
},
"uri" : {
"title": "limeUri",
"type": "string",
"pattern": "^((lime://)(\w\.?-?)+@@?(\w\.?-?@@?)+)?(/(\w\.?-?@@?)+)+(\?{1}((\w+=\w+)&?)+)?$"
},
"type" : {
"type": "string",
"pattern": "^[-\w]+/((json)|([-\w.]+(\+json)))$"
},
"resource" : {
"type": "object"
},
"status": {
"enum": [
"success",
"failure"
]
},
"reason" : {
"type": "object",
"properties": {
"code" : {
"type": "integer"
},
"description": {
"type": "string"
}
},
"required": [ "code" ]
}
},
"required": [ "id", "method" ],
"additionalProperties": false
}
</code>
</pre>
<p>In a command, the following constraints should apply to the envelope properties:</p>
<ul>
<li>
<strong>id</strong> - Mandatory, except for the <em>observe</em> method. Must be provided during the request and the same value should be in the related response command.
</li>
<li>
<strong>from</strong> - Optional. If the value is not present in the destination, it means that the notification was generated by the connected node (server).
</li>
<li>
<strong>to</strong> - Optional. If the value is left empty in the request, the command will be processed by the connected node (server).
</li>
<li>
<strong>pp</strong> - Optional. This property is useful to get resources in the server owned by different identities, like presence and account information. The value should be defined if the resource of an <em>observe</em> method command is owned by a different identity than the destination.
</li>
<li>
<strong>metadata</strong> - Optional. Avoid to use this property to transport any command-related data, like extra parameters.
</li>
</ul>
<p>Besides the envelope properties, a command may contains:</p>
<ul>
<li>
<strong>method</strong> - Method for the manipulation of the resource. This property is mandatory. The possible values are:
<ul>
<li>
<strong>get</strong> - Gets an existing value of the resource.
</li>
<li>
<strong>set</strong> - Sets or updates a for the resource.
</li>
<li>
<strong>merge</strong> - Merges the resource document with an existing one. If the resource doesn't exists, it is created.
</li>
<li>
<strong>delete</strong> - Deletes a value of the resource or the resource itself.
</li>
<li>
<strong>subscribe</strong> - Subscribes to the resource, allowing the originator to be notified when the value of the resource changes in the destination.
</li>
<li>
<strong>unsubscribe</strong> - Unsubscribes to the resource, signaling to the destination that the originator do not want to receive further notifications about the resource.
</li>
<li>
<strong>observe</strong> - Notify the destination about a change in the resource value of the sender. Commands with this method are one-way and the destination should not send a response for it. Because of that, these commands may not have an <em>id</em>.
</li>
</ul>
</li>
<li>
<strong>uri</strong> - The uniform resource identifier (<a href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986</a>). This property is mandatory in command requests and can be ommited in responses. It must be present in <em>observe</em> commands.
The supported scheme is <em>lime</em>, and the authority must be always the identity of the resource owner. In command requests, this identity is always the same of the identity of <em>from</em> envelope property.
Since the base URI is always the same for a specific identity (<em>lime://user@domain</em>), the URI can be represented as a fragment, like <em>/groups</em>, instead of <em>lime://user@domain/groups</em>.
The URI may also contains a query string for filtering.
</li>
<li>
<strong>type</strong> - MIME type of the resource. Like the messages, the protocol defines some <a href="resources.html">common resource types</a>, but may exists specific resources to the implementation. This property should be present always when the value of <em>resource</em> property is defined.
</li>
<li>
<strong>resource</strong> - JSON representation of the resource. It must be present in commands with the methods <em>set</em> and <em>observe</em> and may be present in the method <em>delete</em>.
In a command response, must be present in successfully processed command with the method <em>get</em>.
</li>
</ul>
<p>In addition of the above, the command response may contains the following properties:</p>
<ul>
<li>
<strong>status</strong> - Result status of the command processing. Mandatory in response commands. The valid values are:
<ul>
<li>
<strong>success</strong> - The command was processed successfully. In cases of command of method <em>get</em>, the property <em>resource</em> of the response should have a value.
</li>
<li>
<strong>failure</strong> - A problem occurred while processing the command. In this case, the property <em>reason</em> of the response should have a value.
</li>
</ul>
</li>
<li>
<strong>reason</strong> - If the command was not successfully processed, this property should provide more details about the problem. It contains the following properties:
<ul>
<li>
<strong>code</strong> - Code number of the reason. There are some protocol pre-defined codes, but may exists specific codes for each implementation of the protocol.
</li>
<li>
<strong>description</strong> - Description message of the problem. This property can be omitted.
</li>
</ul>
</li>
</ul>
<p class="lead">Examples</p>
<p>Setting the presence:</p>
<pre>
C:
<code class="json">
{
"id": "9cbe5fe1-b6b2-4afe-ab12-0675aa139f36",
"from": "jesse@breakingbad.com/home",
"method": "set",
"uri": "/presence",
"type": "application/vnd.lime.presence+json",
"resource": {
"status": "available",
"message": "Yo 148, 3-to-the-3-to-the-6-to-the-9. Representin' the ABQ. What up, biatch?"
}
}
</code>
S:
<code class="json">
{
"id": "9cbe5fe1-b6b2-4afe-ab12-0675aa139f36",
"from": "server@breakingbad.com",
"method": "set",
"status": "success"
}
</code>
</pre>
<p>Getting the roster with a filter:</p>
<pre>
C:
<code class="json">
{
"id": "b784a7d2-59d7-45de-a1eb-8c50a0f5edb8",
"from": "jesse@breakingbad.com/home",
"method": "get",
"uri": "lime://jesse@breakingbad.com/contacts?sharePresence=true&take=3"
}
</code>
S:
<code class="json">
{
"id": "b784a7d2-59d7-45de-a1eb-8c50a0f5edb8",
"from": "server@breakingbad.com",
"method": "get",
"status": "success",
"type": "application/vnd.lime.collection+json",
"resource": {
"total": "4",
"itemType": "application/vnd.lime.contact+json",
"items": [
{
"identity": "skinnypete@breakingbad.com"
},
{
"identity": "badger@breakingbad.com"
},
{
"identity": "combo@breakingbad.com"
}
]
}
}
</code>
</pre>
<p>Trying without success to get another user account information:</p>
<pre>
C:
<code class="json">
{
"id": "5c95e87f-7f0c-4cc3-b55b-99056d9f288d",
"from": "gusfring@breakingbad.com",
"pp": "saul@breakingbad.com",
"method": "get",
"uri": "lime://gusfring@breakingbad.com/account"
}
</code>
S:
<code class="json">
{
"id": "5c95e87f-7f0c-4cc3-b55b-99056d9f288d",
"from": "server@breakingbad.com",
"method": "get",
"status": "failure",
"reason": {
"code": 56,
"description": "The request account is not sharing information with current session identity"
}
}
</code>
</pre>
<h3 id="session">Session</h3>
<p>Allows the configuration and establishment of the communication channel between nodes. Parameters like authentication, cryptography and compression are set through the session envelope.</p>
<p>JSON Schema:</p>
<pre>
<code class="json-schema">
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "session",
"type": "object",
"properties": {
"from": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
},
"to": {
"type": "string",
"pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
},
"id" : {
"type": "string"
},
"metadata": {
"type": "object"
},
"state" : {
"enum": [
"new",
"negotiating",
"authenticating",
"established",
"finishing",
"finished",
"failed"
]
},
"encryptionOptions": {
"type": "array",
"minItems": 1,
"items": { "type": "string" },
"uniqueItems": true
},
"encryption": {
"type": "string"
},
"compressionOptions": {
"type": "array",
"minItems": 1,
"items": { "type": "string" },
"uniqueItems": true
},
"compression": {
"type": "string"
},
"schemeOptions": {
"type": "array",
"minItems": 1,
"items": { "type": "string" },
"uniqueItems": true
},
"scheme": {
"type": "string"
},
"authentication": {
"type": "object"
},
"reason" : {
"type": "object",
"properties": {
"code" : {
"type": "integer"
},
"description": {
"type": "string"
}
},
"required": [ "code" ]
}
},
"required": [ "state" ],
"additionalProperties": false
}
</code>
</pre>
<p>In a session, the following constraints should apply to the envelope properties:</p>
<ul>
<li>
<strong>id</strong> - Mandatory, except in the first request sent by the client (<em>new</em> state). This value is generated by the server in the first session envelope sent to the client.
</li>
<li>
<strong>from</strong> - Mandatory for the client during the session authentication. Otherwise, is optional. The client may ommit the <em>instance</em> value. In this case, the server will define a default instance value.
</li>
<li>
<strong>to</strong> - Optional.
</li>
<li>
<strong>pp</strong> - Not applicable.
</li>
<li>
<strong>metadata</strong> - The server should ignore any value set in this property by the client but it can use this property to send statistics about itself (serverVersion, lastConnectionDate, and so) to the client.
</li>
</ul>
<p>Besides envelope properties, a session may contains:</p>
<ul>
<li>
<strong>state</strong> - Informs or changes the state of a session. Only the server can change the session state, but the client can request the state transition. The valid values are:
<ul>
<li>
<strong>new</strong> - The session is new and doesn't exists an established context. It is sent by a client node to start a session with a server.
</li>
<li>
<strong>negotiating</strong> - The server and the client are negotiating the session options, like cryptography and compression. The server sends to the client the options (if available) and the client chooses the desired options.
If there's no options (for instance, if the connection is already encrypted or the transport protocol doesn't support these options), the server should skip the negotiation.
</li>
<li>
<strong>authenticating</strong> - The session is being authenticated. The server sends to the client the available authentication schemes list and the client must choose one and send the specific authentication data.
The authentication can occurs in multiple roundtrips, according to the selected schema.
</li>
<li>
<strong>established</strong> - The session is active and is possible to send and receive messages and commands. The server sends this state after the session was authenticated.
</li>
<li>
<strong>finishing</strong> - The client node is requesting to the server to finish the session.
</li>
<li>
<strong>finished</strong> - The session was finished by the server.
</li>
<li>
<strong>failed</strong> - A problem occurred while the session was established, under negotiation or authentication and it was closed by the server. In this case, the property <em>reason</em> must be present to provide more details about the problem.
</li>
</ul>
</li>
<li>
<strong>encryptionOptions</strong> - Encryption options provided by the server during the session negotiation. Some of the valid values (not limited to) are:
<ul>
<li>
<strong>none</strong> - The session will be not encrypted.
</li>
</ul>
<ul>
<li>
<strong>tls</strong> - The session will be encrypted by TLS. This options is required for transport authentication in TCP transport connections.
</li>
</ul>
</li>
<li>
<strong>encryption</strong> - The encryption option selected for the session. This property is provided by the client in the negotiation and by the server in the confirmation after that.
</li>
<li>
<strong>compressionOptions</strong> - Compression options provided by the server during the session negotiation. Some of the valid values (not limited to) are:
<ul>
<li>
<strong>none</strong> - The session will not be compressed.
</li>
</ul>
<ul>
<li>
<strong>gzip</strong> - The session will use the GZip algorithm for compression.
</li>
</ul>
</li>
<li>
<strong>compression</strong> - The compression option selected for the session. This property is provided by the client in the negotiation and by the server in the confirmation after that.
</li>
<li>
<strong>schemeOptions</strong> - List of available authentication schemas for session authentication provided by the server. Some of the valid values (not limited to) are:
<ul>
<li>
<strong>guest</strong> - The server doesn't requires a client credential, and provides a temporary identity to the node. Some restriction may apply to guest sessions, like the inability of sending some commands or other nodes may want to block messages originated by guest identities.
</li>
<li>
<strong>plain</strong> - User and password authentication.
</li>
<li>
<strong>transport</strong> - The authentication is made in the transport level. For the TCP transport, this indicates a TLS/SSL client authentication, which requires a certificate from the client. This certificate should be already presented during the session negotiation state, after the confirmation of the encryption options, in the TLS handshake.
</li>
</ul>
</li>
<li>
<strong>scheme</strong> - The authentication scheme option selected for the session. This property must be present if the property authentication is defined.
</li>
<li>
<strong>authentication</strong> - Authentication data, related to the selected schema. Information like password sent by the client or roundtrip data sent by the server.
</li>
<li>
<strong>reason</strong> - In cases where the client receives a session with <em>failed</em> state, this property should provide more details about the problem. It contains the following properties:
<ul>
<li>
<strong>code</strong> - Code number of the reason. There are some protocol pre-defined codes, but may exists specific codes for each implementation of the protocol.
</li>
<li>
<strong>description</strong> - Description message of the problem. This property can be omitted.
</li>
</ul>
</li>
</ul>
<p class="lead">Examples</p>
<p>Establishment and closing of a session with negotiation and authentication:</p>
<pre>
C:
<code class="json">
{
"state": "new"
}
</code>
S:
<code class="json">
{
"id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
"from": "server@breakingbad.com/server1",
"state": "negotiating",
"encryptionOptions": [ "none", "tls" ],
"compressionOptions": [ "none", "gzip" ]
}
</code>
C:
<code class="json">
{
"id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
"state": "negotiating",
"encryption": "tls",
"compression": "none"
}
</code>
S:
<code class="json">
{
"id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
"from": "server@breakingbad.com/server1",
"state": "negotiating",
"encryption": "tls",
"compression": "none"
}
</code>
S:
<code class="json">
{
"id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
"from": "server@breakingbad.com/server1",
"state": "authenticating",
"schemeOptions": [ "guest", "plain" ]
}
</code>
C:
<code class="json">
{
"id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
"from": "gale@breakingbad.com/lab",
"state": "authenticating",
"scheme": "plain",
"authentication": {
"password": "aWxvdmV1d3c="
}
}
</code>
S:
<code class="json">
{
"id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
"from": "server@breakingbad.com",
"to": "gale@breakingbad.com/lab",
"state": "established"
}
</code>
C:
<code class="json">
{
"id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
"state": "finishing"
}
</code>
S:
<code class="json">
{
"id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
"from": "server@breakingbad.com/server1",
"state": "finished"
}
</code>
</pre>
</div>
<div class="col-md-2" role="complementary">
<div id="sidebar" class="affix-top">
<ul class="nav nav-pills nav-stacked">
<li>
<a href="#what">What is it?</a>
</li>
<li>
<a href="#xmpp">Why not XMPP?</a>
</li>
<li>
<a href="#concepts">Concepts</a>
</li>
<li>
<a href="#envelope">Envelope</a>
</li>
<li>
<a href="#message">Message</a>
</li>
<li>
<a href="#notification">Notification</a>
</li>
<li>
<a href="#command">Command</a>
</li>
<li>
<a href="#session">Session</a>
</li>
</ul>
</div>
</div>
</div>
</div>
<div class="row">
<hr class="col-md-12">
</div>
<footer role="contentinfo">
<div class="container">
<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="./files/88x31.png"></a><br><span xmlns:dct="http://purl.org/dc/terms/" property="dct:title">Lime Protocol Specification</span> by <a xmlns:cc="https://creativecommons.org/ns#" href="https://take.net/" property="cc:attributionName" rel="cc:attributionURL">Take</a> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.
</div>
</footer>
<script src="./files/modernizr-2.6.2.js"></script>
<style type="text/css"></style>
<script src="./files/jquery-1.10.2.js"></script>
<script src="./files/bootstrap.js"></script>
<script src="./files/respond.js"></script>
<script src="./files/json-highlight.js"></script>
<script src="./files/lime.js"></script>
<script>
(function (i, s, o, g, r, a, m) {
i['GoogleAnalyticsObject'] = r; i[r] = i[r] || function () {
(i[r].q = i[r].q || []).push(arguments)
}, i[r].l = 1 * new Date(); a = s.createElement(o),
m = s.getElementsByTagName(o)[0]; a.async = 1; a.src = g; m.parentNode.insertBefore(a, m)
})(window, document, 'script', '//www.google-analytics.com/analytics.js', 'ga');
ga('create', 'UA-48277211-1', 'limeprotocol.org');
ga('send', 'pageview');
</script>
</body>
</html>