idnits 2.17.1 draft-kutscher-mbus-ipac-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** There are 10 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (February 23, 2001) is 8463 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) == Unused Reference: '3' is defined on line 652, but no explicit reference was found in the text -- No information found for draft-ietf-mmusic-mbus - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-09) exists of draft-ietf-sip-rfc2543bis-02 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kutscher 3 Internet-Draft Ott 4 Expires: August 24, 2001 TZI, Universitaet Bremen 5 February 23, 2001 7 An Mbus Profile for Internet Appliance Control 8 draft-kutscher-mbus-ipac-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To view the entire list of Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on August 24, 2001. 30 Copyright Notice 32 Copyright (C) The Internet Society (2001). All Rights Reserved. 34 Abstract 36 This document discusses scenarios for the control of Internet 37 Appliances -- Internet hosts with with specific user funtionalities 38 -- using the Mbus protocol [1]. A first sketch of an Mbus 39 application profile for controlling Internet appliances is 40 presented, describing mechanisms for controlling a group of 41 co-located appliances without the need for central controlling 42 entities. 44 This document does not address the issue of wide area control, i.e., 45 controlling appliances that are not on the same network link as the 46 controlling entity. Instead, it is expected that the Mbus based 47 local control is to be complemented by a, yet to be defined, 48 protocol for that purpose. 50 The underlying message passing and addressing mechanisms for the 51 Mbus is defined in the Mbus transport specification[1]. 53 This document is a contribution to the Internet Appliance Control 54 (ipac) BoF at the 50th Internet Engineering Task Force meeting. 55 Comments are solicited and should be addressed to the authors. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2 Scope of this Document . . . . . . . . . . . . . . . . . . . . 6 62 2. The System Model . . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Characteristics . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.2 Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 9 66 3.3 Serverless Operation . . . . . . . . . . . . . . . . . . . . . 9 67 3.4 Interaction Models . . . . . . . . . . . . . . . . . . . . . . 10 68 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.1 Integrating Devices into an Appliance Network . . . . . . . . 11 70 4.2 Controlling Appliances . . . . . . . . . . . . . . . . . . . . 12 71 5. Interworking with Wide Area Control . . . . . . . . . . . . . 15 72 6. Integrating Dumb Devices . . . . . . . . . . . . . . . . . . . 16 73 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 75 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 77 1. Introduction 79 1.1 Background 81 The Mbus transport specification[1] defines the transport mechanisms 82 of the Message Bus (Mbus), a local coordination infrastructure that 83 allows message passing between a group of application components. 85 As its basic service, the Message Bus provides local (intra-system) 86 exchange of messages between components that attach to the Mbus 87 (Mbus entities). A system is typically expected to comprise one or 88 more hosts, but a may also extend across a network link and include 89 several hosts sharing the tasks; a local system does not extend 90 beyond a single link -- the Mbus is not intended or designed for use 91 as a wide-area control protocol. Wide-area control has significantly 92 different requirements regarding trust-models and scalability and 93 must deal with different problems regarding reliability and message 94 transport delay. 96 The message transport service provides group- and 97 point-to-point-communication. It does not offer all the features 98 that are frequently found in protocols for coordinating distributed 99 applications in general such as guaranteeing a global or causal 100 ordering of delivered messages. 102 Given these deliberate restrictions in functionality it is important 103 to note that the Mbus implies a component model where communication 104 between components can be realized without services from a 105 full-featured infrastructure for distributed applications. 107 Message exchange takes place using UDP: datagrams are sent either 108 via unicast to a single entity or multicast to a locally scoped 109 group. For unicast communications, message delivery is optionally 110 performed reliably, with acknowledgements and retransmissions taking 111 place at the Mbus transport layer. All group communication is 112 performed unreliably. For deployment in scopes larger than 113 link-local Mbus the multicast address (i.e., the multicast scope to 114 use) can be configured accordingly, or bridging elements can be 115 deployed that interconnect two or more Mbus domains. 117 For unicast communications, message delivery is optionally performed 118 reliably, with acknowledgements and retransmissions taking place at 119 the Mbus transport layer. Point-to-point and multicast communication 120 is in general not distinguished by the transmission mechanism 121 employed at the IP layer but rather by the qualification of the Mbus 122 destination address. There is however the possibility to use 123 IP-unicast for messages that are directed to a single receiver. (See 124 section Entity Awareness.) 125 A key concept of the Mbus is its flexible and extensible addressing 126 scheme. Mbus entities are identified by n-tuples with each component 127 of the tuple represented as an attribute-value pair. The addressing 128 scheme for conferencing applications includes address elements like 129 conference (conf), media (media), module type (module), application 130 name (app), and application identifier (id). For example: 132 (class:lamp location:bedroom floor:1 id:1035-0@192.168.1.1) 134 Each Mbus entity responds to messages addressed to any subset of its 135 own address. For example, the entity with the address illustrated 136 above will respond to messages pro-viding the following target 137 addresses: 139 (class:lamp location:bedroom floor:1 id:1035-0@192.168.1.1) 141 (class:lamp location:bedroom id:1035-0@192.168.1.1) 143 (class:lamp id:1035-0@192.168.1.1) 145 (class:lamp) 147 () 149 A fully qualified address (with all components of the tuple present) 150 indicates a unicast Mbus address. Messages with incomplete addresses 151 have the potential to be received by multiple entities. 153 An entity on the Message Bus can learn the existence of other 154 entities (and their complete addresses) by listening to the 155 self-announcement messages that all entities send periodically. The 156 rate at which these periodic heartbeat messages are sent is adapted 157 dynamically depending on the number of entities in a Mbus session, 158 thus allowing the Mbus to scale to larger groups of entities. 160 This mechanism is used to locate entities and to monitor their 161 liveness during a session but also to build a complete set of the 162 addresses of all available entities -- Mbus layer addresses and 163 transport layer addresses. The latter information can be used for 164 optimization strategies, e.g. for deciding whether a message can be 165 sent via IP-unicast. 167 Based upon these awareness functions, a bootstrap procedure is 168 defined that allows entities to determine whether all other entities 169 they depend on are present (without bearing the risk of deadlocks). 171 Each entity has a unique Mbus address that can be used to identify 172 it and that is composed of any number of named address elements. The 173 types and values of address elements are application-specific and 174 can be used to aggregate entities into address groups. 176 Address element names may be associated with semantics: by providing 177 certain address elements, entities can signal the type of service 178 functionality they are able to supply. The Mbus specification itself 179 does not impose any restrictions on application specific address 180 elements. The semantics are provided by application specific 181 profiles. For example, the address element set for conferencing 182 applications defines elements for distinguishing entities by the 183 media type that is assigned to them allowing a local conference 184 controller to address one or more audio, video and other media 185 tools. 187 A message that is to be sent via the Mbus has a target address -- at 188 the application level -- that is used to determine how to deliver 189 the respective message. This allows for subject-based 190 addressing-like message delivery semantics and different 191 communication models represented by the different group addressing 192 features: 194 Broadcast: When a target address list is empty the message is 195 broadcast to all entities on the Mbus. 197 Unicast: A message that contains a target address that is a unique 198 Mbus address of another entity will be processed by this entity 199 only. The Mbus defines mechanisms allowing such messages to be 200 sent directly via unicast to the specific en-tity. 202 Multicast: As mentioned above target addresses can be used to 203 identify groups on a per-message basis. All entities that match 204 the given target address will receive and process corresponding 205 messages: In situations where a certain module requires a 206 specific service functionality, that can be pro-vided by more 207 than one other module, it can use a multicast address specifying 208 the group of service providers to locate the desired entity. This 209 may facilitate the imple-mentation of service clients 210 significantly: addresses of ser-vice providers do not need to be 211 hardcoded and the com-munication model can accommodate many 212 different spe-cific scenarios regardless of the number of 213 potential service providers. 215 It is not necessary to know the exact addresses of all potential 216 receivers of a message. Instead a sufficiently unam-biguous address 217 list can be used. For example, in order to reach all audio engines 218 in a session the address list (media:audio module:engine) might be 219 appropriate. 221 Mbus messages are text-encoded and consist of a header with protool 222 information and a payload section that can carry several textual 223 commands with parameter lists. Command names are hierarchical and a 224 set of basic data types for command parameters is defined, including 225 numeric types, character strings, lists and opaque data. 227 Message authentication and encryption are supported as inherent 228 transport features to prevent malicious attacks and to provide 229 privacy for the communication within an Mbus domain. This allows the 230 Mbus to accommodate multiple sessions of a user per host (including 231 cross-session coordination) as well as any number of users on the 232 same host or link (preventing accidental cross-user interaction). 234 The Mbus guidelines[2] define a list of conventions for terminology, 235 algorithms and procedures for higher level interaction models that 236 are useful for applications using the Mbus. These conventions are 237 intended as guidelines for designers of Mbus application profiles 238 and Mbus implementations/applications. 240 This document builds on these two specifications and provides an 241 Mbus application profile for Internet Appliance Control that uses 242 the conventions codified in the Mbus guidelines[2] to specify an 243 Mbus application profile, i.e., a list of Mbus commands and 244 procedures that allow to implement Internet appliances and 245 corresponding controllers. 247 1.2 Scope of this Document 249 This document discusses a first command set and corresponding 250 interactions between application components for Internet appliance 251 control, such as 253 o locating appliances; 255 o discovering capabilities and services of appliances; 257 o sending event notifications from appliances to controllers or 258 other appliances; and 260 o sending controlling messages to appliances. 262 The Mbus commands presented are mainly intended as illustrations of 263 the principle discussed here. Because the requirements of the 264 application are not yet defined, we only present examples for the 265 sake of clarification and for initiating discussions. 267 2. The System Model 269 The system model that is used in this document assumes that the 270 appliances of a certain control domain, e.g., a house, build a 271 cooperation group, that includes appliances (controllees) as well as 272 controllers. However, a clear distinction between controllers and 273 controllees is not always reasonable. For example, the event 274 notifications generated by a certain appliance might be of interest 275 to more than one entity, e.g., a controller. Instead, the 276 corresponding information could be useful for a group of entities at 277 the same time. 279 On the other hand, is is required to ensure that a certain 280 appliance, say a microwave oven, is controlled by exactly one 281 controller at a time, without the possibility of conflicts that 282 could arise from receiving control messages from different entities. 284 We therefore distinguish between different types of interaction 285 between appliances. Some interaction styles are appropriate for 286 group communication, while others should be realized with the notion 287 of tight, exclusive control relations. 289 +------------------- Mbus Appliance Domain ----------------+ 290 | | 291 | +---------------+ +---------------+ +---------------+ | 292 | | | | | | | | 293 | | microwave | | light switch | | radio | | 294 | | | | | | | | 295 | +---------------+ +---------------+ +---------------+ | 296 | | | | | 297 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 298 | | | | | 299 | +---------------+ +---------------+ +---------------+ | 300 | | | | | | house | | 301 | | TV | | alarm clock | | alarm | | 302 | | | | | | system | | 303 | +---------------+ +---------------+ +---------------+ | 304 | || | 305 +----------------------------||----------------------------+ 306 || 307 || 308 || 309 || Wide Area Control 310 || Protocol 311 || 312 || 313 || 314 || 316 As shown in the above picture, we assume that a group of appliances 317 is modeled as an Mbus domain where a set of Mbus entities represent 318 the appliances. It is further assumed, that wide area control is to 319 be provided by a dedicated control protocol, e.g., a SIP-based 320 protocol. See Section 5 for a disussion of the interworking with a 321 wide area control protocol. 323 3. Characteristics 325 3.1 Addressing 327 The Mbus provides a subject-based addressing mechanism. This means, 328 an appliance can use a descriptive address that contains information 329 about service functionality it can provide. This information can be 330 used for addresses of messages that are to be sent to the appliance. 331 Using the wildcard/group communication mechanisms it thus is 332 possible to address messages to an appliance by refering to a 333 function (or other criteria). 335 There is another aspect of the Mbus addressing mechanism: Appliances 336 that are generating periodic event notifications that would be sent 337 to a well-known group target address. Other appliances can "tune in" 338 into this event notification "channel" by choosing ("joining") a 339 proper Mbus address. This is a scalable way to implement simple 340 "subscribe/notify" scenarios, because the entities that generate the 341 notifications do not have to know the exact list of subcribers. 343 3.2 Autoconfiguration 345 In general, it should be possible to connect a set of appliance 346 systems without having to manually configure them. There might be 347 some degree of configuration that is required to setup trust 348 relationships etc. but apart from that, it is probably not 349 acceptable to require customers to configure and maintain databases 350 of IP addresses and other information about their appliances in 351 order to be able to control and use them. 353 The Mbus can help to reduce the amount of manual configuration by 354 its addressing architecture and the notion of a "soft state" of 355 addressing information that is maintained at each Mbus entity: 357 As described in Section 3.1, entities are addressed using subject 358 based addressing. This means, it is not always required to know the 359 addresses of receivers exactly, because the group communication 360 mechanisms allow senders to send messages to a group address. 362 Additionally, the entity awareness mechanism enables entities to 363 build and maintain a list of active entities. Because of the 364 periodic self-announcement messages that are sent by each entity, 365 this state can be "soft", does not have to be initialized manually 366 and is updated automatically. 368 3.3 Serverless Operation 370 In order to achieve plug-and-play functionality, robustness, device 371 mobility and ease of deployment it is required to be able to have 372 appliance functioning correctly without having to supply a central 373 server. A central server would have to be installed, maintained -- 374 and may possibly fail at some time. 376 Due to the entity awareness mechanisms and the peer-to-peer 377 communication model, the Mbus can accomodate serverless operation 378 very easily: Mbus based appliances can be attached to a network and 379 will immediately be able to communicate without the need of a 380 central server. (It should be noted, though, that servers of any 381 kind may be supplied to provide for (de-)centralized functionality). 383 3.4 Interaction Models 385 Within a group of appliances, more than the obvious client-server 386 communication model will be required. The two most important 387 communication styles: 389 Event notification: In an appliance environment, it is useful to 390 have certain appliances asynchronously send certain information 391 that other entities can take advantage of. 392 Using group communication and the notion of subject based 393 addressing it is possible to realize this functionality. 395 RPCs: In order to control appliances reliably, it is required to 396 invoke remote procedures and receive acknowledgements in order to 397 obtain results and error notifications. For a message oriented 398 communication infrastructure, this means that a mechanism for 399 reliable message transmission and the possibility to relate 400 reponses to message invocations is required. The Mbus therefore 401 provides reliable message transmission of messages that are sent 402 to a single entity. The [2] provide convention for building RPC 403 communicatin upon this basic reliable message exchange. 405 4. Examples 407 In the following sections we present some scenarios and potential 408 sample message exchanges that are primarily intended to illustrate 409 the ideas behind appliance control via the Mbus. 411 4.1 Integrating Devices into an Appliance Network 413 Home Configuration: 415 1. Buy. 417 2. Install and "plug in" (provide local KEY for HMAC and possibly 418 encryption). 420 3. Provide keys possibly use multi-level key provisioning s in 421 Bluetooth or similar environments. 423 4. Determine device level parameters in browser. 425 5. Assign name and other home level parameters. 426 This step could be automated if an individual "locator" 427 components is available per logical location and there is no 428 interference between these components. This could e.g. be 429 realized by having an individual link in each room and a 430 room-local multicast address. 432 Home level parameters can either be stored in the devices 433 themselves, or, in the case of dumb devices, be stored externally. 434 In that case, the devices could either be configured dynamically to 435 use the home level address or proxy entities could be deployed that 436 represent the entities using the home level addresses and relay 437 messages to the device level addresses. 439 Functional components: 441 o Device manager (e.g. Mbus Browser) 443 o Device proxy 445 * for non-Mbus entities 447 * for very trivial entities 449 1. Tell the vendor when you buy it and have him configure it 450 properly (plus remote maintenance service). 452 2. Use a small configuration tool (Mbus Browser) and store the 453 settings in the device (in permanent storage). 455 3. Use a small configuration tool (Mbus Browser) and store the 456 settings in some bootstrap device (for the device itself has 457 only ephemeral storage) -> BOOTP/DHCP-style initialization 458 protocol. 460 4. Provide some proxying mechanisms. 462 5. ... 464 Appearance on the Mbus: 466 mbus/1.0 U (id:4711@192.168.1.11 class:lamp) () () 467 mbus.hello () 468 ia.desrcription (vendor=Fasel name=lignerose-designer-lamp ...) 469 ia.caps (power) 470 ia.properties (power=100W bulbs=3 voltage=220V current=0.5A) 471 ia.status.power (off) 473 Query: 475 mbus/1.0 U (id:4711@192.168.1.11 class:lamp) () () 476 mbus.whereami () 478 Response: 480 mbus/1.0 U (class:configurator id:4711) (id:4711@192.168.1.11 class:lamp) () 481 mbus.associate (id:com.manufacturer.lamp.23765827346593 floor:1 \ 482 location:bedroom name:my-reading-light) 484 Re-appearance on the Mbus: 486 mbus/1.0 U (id:4711@192.168.1.11 class:lamp floor:1 location:bedroom \ 487 name:my-reading-light) () () 488 mbus.hello () 490 4.2 Controlling Appliances 492 Controlling a lamp: 494 mbus/1.0 R (id:875462873694 class:remote-control) (id:4711@192.168.1.11 class:lamp) () 495 power.on () 496 power.dim (0.50) 498 Asynchronous status notification: 500 mbus/1.0 U (id:4711@192.168.1.11 class:lamp) (class:lamp status) 501 power.status (on dim=50) 502 Shutdown when leaving the house: 504 mbus/1.0 U (class:door name:front-door id:4711) (class:lamp) 505 power.off () 507 Alternative: subcribe/notify 509 mbus/1.0 R (id:4711@192.168.1.23 class:monitor) (id:4711@192.168.1.11 class:lamp) 510 mbus.subscribe (power.status) 512 mbus/1.0 R (id:4711@192.168.1.11 class:lamp) (id:4711@192.168.1.23 class:monitor) 513 power.status (on dim=50) 515 Independent provision and consumption of information: 517 mbus/1.0 U (class:environment id:76490947983 name:terrace-thermometer) \ 518 (class:environment) () 519 weather.temperature ("25F") 521 mbus/1.0 U (class:environment id:76490947984 name:light-sensor) (class:environment) () 522 weather.light (brightness:0.25) 524 mbus/1.0 U (class:clock id:76490947985) (class:clock) () 525 clock.current-time ("18:25:17 UTC") 526 clock.alarm-time (name="wakeup" time="07:00:00 UTC") 527 clock.alarm-time (name="call-mother-in-law" time="21:00:00 UTC") 529 mbus/1.0 U (class:remote-control id:4774856923649) (class:clock id:76490947985) () 530 clock.alarm.set (name="coffee" time="06:50:00 UTC" address="class:coffee-maker" \ 531 command="coffee.brew (\"type=strong\")") 533 mbus/1.0 U (class:clock id:76490947985) (class:clock) () 534 clock.current-time ("18:25:17 UTC") 535 clock.alarm-time (name="wakeup" time="07:00:00 UTC") 536 clock.alarm-time (name="call-mother-in-law" time="21:00:00 UTC") 537 clock.alarm-time (name="coffee" time="06:50:00 UTC") 539 mbus/1.0 U (class:remote-control id:4774856923649) (class:clock id:76490947985) () 540 clock.alarm.delete (name="call-mother-in-law") 542 Alarm at 06:50: 544 mbus/1.0 U (class:clock id:76490947985) (class:coffee-maker) () 545 coffee.brew ("type=strong") 547 5. Interworking with Wide Area Control 549 Since the Mbus-based control of appliances is defined for local 550 network of appliances only the issue of how to provide remote 551 control from arbitrary Internet hosts need to be addressed. 553 We propose the use of gateway systems that translates requests from 554 a controller to Mbus messages. The protocol that is used for wide 555 area control is not defined in this document. It could be HTTP or a 556 SIP variant. A few required properties for such an protocol can be 557 given. 559 +------------------- Mbus Appliance Domain ----------------+ 560 | | 561 | +---------------+ +---------------+ +---------------+ | 562 | | | | | | | | 563 | | microwave | | light switch | | radio | | 564 | | | | | | | | 565 | +---------------+ +---------------+ +---------------+ | 566 | | | | | 567 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 568 | | | | | 569 | +---------------+ +---------------+ +---------------+ | 570 | | | | | | house | | 571 | | TV | | Mbus gateway | | alarm | | 572 | | | | | | system | | 573 | +---------------+ +---------------+ +---------------+ | 574 | || | 575 +----------------------------||----------------------------+ 576 || 577 || 578 || 579 || Wide Area Control 580 || Protocol 581 || 582 || 583 || 584 || 585 +---------------+ 586 | Remote | 587 | Controller | 588 | | 589 +---------------+ 591 6. Integrating Dumb Devices 593 Not every device that needs to be controlled in an appliance network 594 can be equipped with a TCP/IP and an Mbus stack. There may be cost 595 issues for very small devices or the issue of legacy devices that 596 users want to be able to integrate. 598 Since a host with an Mbus stack can host more than one Mbus entity 599 that are uniquely addressable, the proposed solution for these 600 scenarios is to employ "proxy" Mbus systems that simply represent 601 the dumb devices that cannot directly connect to the Mbus. 603 In fact, the presence of such a proxy system is completely 604 transparent to the other entities of an Mbus session since it is not 605 a special to have multiple entities reside on one host. 607 The way how those dumb devices are connected to and controlled by an 608 proxy system is of course left to the implementations and is not 609 subject of this document. 611 The following figure illustrates this using the example of a proxy 612 system for a set of light bulbs. 614 +------------------- Mbus Appliance Domain ----------------+ 615 | | 616 | +---------------+ +---------------+ +---------------+ | 617 | | | | | | | | 618 | | microwave | | light switch | | radio | | 619 | | | | | | | | 620 | +---------------+ +---------------+ +---------------+ | 621 | | | | | 622 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 623 | | | | | 624 | +---------------+ +---------------+ +---------------+ | 625 | | | | | | house | | 626 | | TV | | Mbus proxy | | alarm | | 627 | | | | | | system | | 628 | +---------------+ +---------------+ +---------------+ | 629 | / | \ | 630 | / | \ | 631 | / | \ | 632 | +----------+ | +----------+ | 633 | |Light bulb| | |Light bulb| | 634 | +----------+ | +----------+ | 635 | | | 636 | +----------+ | 637 | |Light bulb| | 638 | +----------+ | 639 | | 640 +----------------------------------------------------------+ 642 References 644 [1] Ott, J., Perkins, C. and D. Kutscher, "A Message Bus for Local 645 Coordination", Internet Draft draft-ietf-mmusic-mbus-03.txt, 646 December 2000. 648 [2] Kutscher, D., "The Message Bus: Guidelines for Application 649 Profile Writers", Internet Draft 650 draft-ietf-mmusic-mbus-guidelines-00.txt, February 2001. 652 [3] Handley, , Schulzrinne, H., Schooler, and Rosenberg, "SIP: 653 Session Initiation Protocol", Internet Draft 654 draft-ietf-sip-rfc2543bis-02.txt, November 2000. 656 Authors' Addresses 658 Dirk Kutscher 659 TZI, Universitaet Bremen 660 Bibliothekstr. 1 661 Bremen 28359 662 Germany 664 Phone: +49.421.218-7595 665 Fax: +49.421.218-7000 666 EMail: dku@tzi.org 668 Joerg Ott 669 TZI, Universitaet Bremen 670 Bibliothekstr. 1 671 Bremen 28359 672 Germany 674 Phone: +49.421.201-7028 675 Fax: +49.421.218-7000 676 EMail: jo@tzi.org 678 Full Copyright Statement 680 Copyright (C) The Internet Society (2001). All Rights Reserved. 682 This document and translations of it may be copied and furnished to 683 others, and derivative works that comment on or otherwise explain it 684 or assist in its implmentation may be prepared, copied, published 685 and distributed, in whole or in part, without restriction of any 686 kind, provided that the above copyright notice and this paragraph 687 are included on all such copies and derivative works. However, this 688 document itself may not be modified in any way, such as by removing 689 the copyright notice or references to the Internet Society or other 690 Internet organizations, except as needed for the purpose of 691 developing Internet standards in which case the procedures for 692 copyrights defined in the Internet Standards process must be 693 followed, or as required to translate it into languages other than 694 English. 696 The limited permissions granted above are perpetual and will not be 697 revoked by the Internet Society or its successors or assigns. 699 This document and the information contained herein is provided on an 700 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 701 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 702 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 703 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 704 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 706 Acknowledgement 708 Funding for the RFC editor function is currently provided by the 709 Internet Society.