recommendations for making an AV Server, the others are the various UPnP docs from http://www.upnp.org/ and some sample XML files [git-p4: depot-paths = "//depot/": change = 724]replace/5b80aeb26dc425aaddcd5182126c969e5cc04cbb
| @@ -0,0 +1,812 @@ | |||
| INTERNET DRAFT J. Cohen, Microsoft | |||
| S. Aggarwal, Microsoft | |||
| <draft-cohen-gena-p-base-01.txt> Y. Y. Goland, Microsoft | |||
| Expires April, 2000 September 6, 2000 | |||
| General Event Notification Architecture Base: Client to Arbiter | |||
| Status of this memo | |||
| This document is an Internet-Draft and is in full conformance with all | |||
| provisions of Section 10 of RFC2026. | |||
| Internet-Drafts are working documents of the Internet Engineering Task | |||
| Force (IETF), its areas, and its working groups. Note that other | |||
| groups may also distribute working documents as Internet-Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet- Drafts as reference | |||
| material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | |||
| The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | |||
| Please send comments to the SSDP mailing list. Subscription information | |||
| for the SSDP mailing list is available at | |||
| http://www.upnp.org/resources/ssdpmail.htm. | |||
| Abstract | |||
| This document provides for the ability to send and receive | |||
| notifications using HTTP over TCP/IP and administratively scoped | |||
| unreliable multicast UDP. Provisions are made for the use of | |||
| intermediary arbiters, called subscription arbiters, which handle | |||
| routing notifications to their intended destination. | |||
| 1 Introduction | |||
| This document provides for the sending of HTTP Notifications using | |||
| administratively scoped unreliable Multicast UDP. Multicast UDP is | |||
| useful in that it allows a single notification to be delivered to a | |||
| potentially large group of recipients using only a single request. | |||
| However administrative scoped unreliable Multicast UDP suffers from a | |||
| number of problems including: how to route it, how to handle | |||
| firewalling and how to deal with multiple scopes. This document only | |||
| addresses the use of Multicast UDP within a single administrative scope | |||
| and only countenances its use for scenarios where there is no | |||
| notification proxy. | |||
| In order to allow for notifications to be distributed beyond a single | |||
| administrative multicast scope it is necessary to provide for relaying | |||
| Cohen et al. [Page 1] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| arbiters. These arbiters, called subscription arbiters, are able to | |||
| form, through an unspecified mechanism, relationships with other | |||
| subscription arbiters in order to distribute notifications. This allows | |||
| a client to send a single HTTP notification to its subscription arbiter | |||
| and have that notification forwarded on to one or more recipients. It | |||
| is the subscription arbiter, not the client, who is responsible for | |||
| maintaining the list of potential recipients and distributing | |||
| notifications to those recipients. | |||
| In order for subscription arbiters to know to whom to distribute | |||
| notifications clients who wish to receive notifications, known as | |||
| subscribers, must subscribe to the subscription arbiter. | |||
| 2 Changes | |||
| 2.1 Since V00 | |||
| [Ed. Note: Aren’t there times when the service needs to hear the | |||
| subscriptions? When the identity of the subscriber will effect the | |||
| output? Of course… Notification identifiers must be explicit in the | |||
| notification, not implicit as a function of the address.] | |||
| [Ed. Note: We need to look into adding support for sequence numbers on | |||
| events, this is needed for things like UPnP. If this doesn't end up | |||
| effecting how the arbiter works then we should put it into a separate | |||
| draft.] | |||
| [Talk about the scope header having values other than the URL of the | |||
| resource, we are using the UPnP example where you would put the USN | |||
| value into the scope. Everyone needs to pay attention to the scope | |||
| header!!!!] | |||
| [Add a note that if no Scope header is included then the default is to | |||
| treat the Request-URI as the scope.] | |||
| [What do you do if someone subscribes to something they are already | |||
| subscribed to? The question is tricky because, short of using | |||
| authentication, you don’t know who “someone” is and even then, because | |||
| multiple programs may be running, you can’t be sure if you are really | |||
| talking to the same person. My instinct would be to just give them a | |||
| second parallel subscription.] | |||
| [Think REALLY hard about allowing for multiple values in a NT header] | |||
| 3 Definitions | |||
| 3.1 Event | |||
| Any occurrence that may potentially trigger a notification. | |||
| 3.2 Subscription | |||
| An established relationship in which a resource has indicated interest | |||
| in receiving certain notifications. | |||
| 3.3 Subscriber | |||
| A resource that negotiates a subscription with a subscription arbiter. | |||
| Cohen et al. [Page 2] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| 3.4 Implied Subscriber | |||
| A resource that did not negotiate a subscription with a subscription | |||
| arbiter but will still be notified of events on that arbiter. | |||
| 3.5 Notifying Resource | |||
| A resource that issues notifications, for example, a subscription | |||
| arbiter. | |||
| 3.6 Subscription Arbiter | |||
| A resource that accepts subscriptions, receives notifications and | |||
| forwards those notifications to its subscribers. | |||
| 3.7 Notification | |||
| A message sent by a notifying resource to provide notification of an | |||
| event. | |||
| 3.8 Notification Type | |||
| A mechanism to classify notifications into categories. This allows | |||
| subscribers to specify exactly what class of notifications they want to | |||
| receive. It also allows notifying resources to specify what class of | |||
| notification they are sending out. | |||
| Notification types do not necessarily identify a single event but | |||
| rather identify a group of related notifications. The notification sub- | |||
| type is used to specify a particular event. | |||
| 3.9 Notification Sub-Type | |||
| Identification of a particular event within a notification type. | |||
| For example, the fictional notification of type home:doors may contain | |||
| notification sub-types such as door:open, close:door, etc. | |||
| There is no requirement that the URI identifying the notification type | |||
| and the URI identifying the notification sub-type have a syntactic | |||
| relationship, only a semantic one. | |||
| 3.10 Subscription ID | |||
| A unique identifier for a subscription. Subscription Ids MUST be URIs | |||
| and MUST be unique across all subscriptions across all resources for | |||
| all time. | |||
| 3.11 Scope | |||
| Scopes are used in a subscription to indicate the notifying resource | |||
| the subscriber is interested in. | |||
| Cohen et al. [Page 3] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| 4 Notification Model | |||
| [Ed. Note: Aren’t there times when the service needs to hear the | |||
| subscriptions? When the identity of the subscriber will effect the | |||
| output? Of course… Notification identifiers must be explicit in the | |||
| notification, not implicit as a function of the address.] | |||
| [Ed. Note: We need to look into adding support for sequence numbers on | |||
| events, this is needed for things like UPnP. If this doesn't end up | |||
| effecting how the arbiter works then we should put it into a separate | |||
| draft.] | |||
| The notification model for GENA is based on the following picture: | |||
| [Subscriber] <- [1+ Subscription Arbiters] <- [Notifying Resource] | |||
| Notification Request Notification Request | |||
| -> | |||
| Subscription Request | |||
| Subscribers send subscription requests to their subscription arbiter. | |||
| The arbiter will then forward to the subscriber any notifications it | |||
| receives which match the subscriber's subscription. | |||
| Notifying resources send notifications to their subscription arbiter to | |||
| be passed on to subscribers. | |||
| Subscription arbiters communicate with each other in order to pass | |||
| along notifications and subscriptions. Subscription arbiter to | |||
| subscription arbiter communication is out of scope for this | |||
| specification. | |||
| For the purposes of this protocol all communication is between | |||
| subscribers/notifying resources and their subscription arbiter. This | |||
| does not preclude direct communication between a subscriber and a | |||
| notifying resource. Rather it means that the notifying resource is | |||
| acting as a subscription arbiter. | |||
| This document also deals with a degenerate case where no subscription | |||
| arbiter is available but administratively scoped unreliable multicast | |||
| UDP facilities are. In that case provisions are made to allow a | |||
| notifying resource to send its notifications directly to a previously | |||
| agreed upon administratively scoped multicast UDP address where | |||
| interested resources can listen in to the notification. | |||
| 4.1 Sending HTTP Notifications through a Subscription Arbiter | |||
| A notifying resource finds its subscription arbiter through an | |||
| unspecified mechanism. The notifying resource will send all of its | |||
| notifications to the subscription arbiter who will then forward those | |||
| subscriptions on to subscribers. | |||
| Cohen et al. [Page 4] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| This document does not provide a mechanism by which the notifying | |||
| resource can retrieve information about which resources have subscribed | |||
| to receive notifications from the notifying resource. | |||
| 4.2 Receiving HTTP Notifications through a Subscription Arbiter | |||
| A subscribing resource finds its subscription arbiter through an | |||
| unspecified mechanism. It is the responsibility of the subscribing | |||
| resource to send subscription requests to the subscription arbiter in | |||
| order to inform the arbiter as to which notifications the subscriber | |||
| would like to receive. | |||
| A subscription request can be thought of as a persistent search filter | |||
| on the set of notifications that the subscription arbiter is aware of. | |||
| Whenever the subscription arbiter receives a notification that matches | |||
| the search filter it will forward the notification to the subscriber. | |||
| This document defines a very basic search filter that allows a | |||
| subscribing resource to specify a particular resource and a type of | |||
| notification the subscribing resource is interested in. Whenever a | |||
| notification of the specified type is made by the specified resource | |||
| the subscription arbiter will forward the notification to the | |||
| subscriber. | |||
| 5 Subscription Arbiters and Forwarded Notifications | |||
| When forwarding a notification the subscription arbiter will change the | |||
| Request-URI and the Host header value to match the subscriber who is to | |||
| be notified. Subscription arbiters MUST NOT make any other changes to | |||
| be made to the message unless the definition of the header or body | |||
| element specifically provides for such alteration and/or for security | |||
| reasons. | |||
| 6 Stuff | |||
| In the case where a subscriber sends a subscription request to an | |||
| arbiter: Is it OK if the arbiter rejects subscription requests that | |||
| don't match certain notification type criteria? or should the arbiter | |||
| be totally unaware of any notification types at this point? | |||
| In the case where a notifying resource sends a notify request to an | |||
| arbiter: Is it OK if the arbiter rejects notification requests that | |||
| don't match certain notification type criteria? or should the arbiter | |||
| just accept the notification request and filter the available | |||
| subscriptions taking the notification type as criteria? | |||
| In the hypothetical case where the arbiter just accepted subscriptions | |||
| of certain types, could an arbiter just be dedicated to one | |||
| subscription type? If the previous statement was affirmative then the | |||
| existence of a notification type for that particular arbiter wouldn't | |||
| even make sense right? | |||
| We need to discuss the implicit relationship between an arbiter and its | |||
| subscribers, all the unstated assumptions. | |||
| Cohen et al. [Page 5] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| The subscription server may not necessarily have been the one who | |||
| created a SID, it could have been the service who is using the | |||
| subscription server to do replication. In that case a subscription | |||
| request could come in with a SID on it, a ref-counted SID. But this bug | |||
| me because a SID indicates a relationship. How does one change one’s | |||
| call back for a SID? Especially if you want to send in the change | |||
| command from somewhere other than the place receiving the notification | |||
| so you can’t just check the address on the packet. Do we need tow types | |||
| of SIDs? I don’t just want to overload NT. I think NT and NTS should be | |||
| left alone to just give notification type. They shouldn’t be overloaded | |||
| to also provide functional information… functional is the wrong word. | |||
| They shouldn’t be overloaded to provide routing information. | |||
| Event type. | |||
| Event Sub-type. | |||
| Event group (if any). | |||
| Individual subscription. | |||
| The problem is that the last two are not always both necessary. For | |||
| example, an individual subscription ID is not necessary if the events | |||
| are only sent to a multicast group. Additionally the event group ID | |||
| isn’t necessary if the event only goes to a single end point. | |||
| Maybe we need an end point identifier? We need a way to say “Stop | |||
| sending the events to this call-back, send it to this other call-back.” | |||
| THIS ISN’T GOOD ENOUGH. What if two programs are both at the same call- | |||
| back? You need ref counting. | |||
| I guess what I’m trying to avoid is implicit ref-counting, I would | |||
| rather have explicit ref-counting. That is, I would like the ref count | |||
| to be included in each request in the person of an ID that is unique to | |||
| every listener, this is independent of call-back address. | |||
| Make sure that if you leave off the NT then this means you want to | |||
| receive all notifications from the identified scope. | |||
| Also make sure that we can use scope as a selector for video streams on | |||
| a video server. | |||
| We need to add a “connect and flood” mechanism such that if you connect | |||
| to a certain TCP port you will get events. There is no | |||
| subscribe/unsubscribe. We also need to discuss this feature for | |||
| multicasting. If you cut the connection then you won’t get any more | |||
| events. | |||
| 7 NOTIFY HTTP Method | |||
| The NOTIFY method is used to transmit a notification. The Request-URI | |||
| of the notification method is the notifying resource's subscription | |||
| arbiter who will handle forwarding the message to interested | |||
| subscribers. | |||
| The NOTIFY method may be sent using unreliable administrative scoped | |||
| multicast UDP as specified in [HTTPMU]. In such a case the multicast | |||
| Cohen et al. [Page 6] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| channel is treated as the subscription arbiter. When a NOTIFY is sent | |||
| using multicast UDP as a transport there is no response. | |||
| The NOTIFY method MUST contain a NT header and MAY contain a body, a | |||
| NTS header and SID. Subscribers MAY ignore the body in a subscription | |||
| request. Subscription arbiters MAY remove and/or alter the value of the | |||
| SID header in order to set it to the value that their subscriber is | |||
| expecting. Note that in general notifying resources will not put SID | |||
| headers on their notifications. This is generally a value that | |||
| subscription arbiters add. | |||
| Note that notifications to implied subscribers may not necessarily have | |||
| SIDs. The client can tell the subscription arbiter to stop sending the | |||
| notification by returning a 412 (Precondition Failed). | |||
| 7.1 Response Codes | |||
| 200 (OK) - This is the standard response to a NOTIFY received by a | |||
| subscriber. | |||
| 202 (Accepted) - This is the standard response to a NOTIFY received by | |||
| a subscription arbiter. | |||
| 412 (Precondition Failed) - The client doesn't recognize the SID or the | |||
| request doesn't have a SID and the client doesn't want to receive the | |||
| notification. | |||
| 7.2 Examples | |||
| 7.2.1 TCP/IP | |||
| NOTIFY /foo/bar HTTP/1.1 | |||
| Host: blah:923 | |||
| NT: ixl:pop | |||
| NTS: clock:bark | |||
| SID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6 | |||
| HTTP/1.1 200 O.K. | |||
| A notification of type ixl:pop sub-type clock:bark has been sent out in | |||
| response to the specified subscription. The request-URI could either | |||
| identify a particular resource who is to be notified or a subscription | |||
| arbiter who will then take responsibility for forwarding the | |||
| notification to the appropriate subscribers. | |||
| 7.2.2 Multicast UDP | |||
| NOTIFY * HTTP/1.1 | |||
| Host: somemulticastIPaddress:923 | |||
| NT: ixl:pop | |||
| NTS: clock:bark | |||
| Cohen et al. [Page 7] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| As in the previous example this is a notification of type ixl:pop sub- | |||
| type clock:bark but it has been sent out to the multicast channel as an | |||
| unsolicited notification. Hence it does not have a SID header. Also, | |||
| because it was sent out to a multicast UDP channel it also doesn’t have | |||
| a response. | |||
| 8 SUBSCRIBE HTTP Method | |||
| [Talk about the scope header having values other than the URL of the | |||
| resource, we are using the UPnP example where you would put the USN | |||
| value into the scope. Everyone needs to pay attention to the scope | |||
| header!!!!] | |||
| The SUBSCRIBE method is used to provide a subscription arbiter with a | |||
| search filter to be used in determining what notifications to forward | |||
| to the subscriber. | |||
| The Request-URI of the SUBSCRIBE method specifies the subscription | |||
| arbiter which will handle the subscription. | |||
| A SUBSCRIBE request MUST have a NT header unless it is a re- | |||
| subscription request. The NT header specifies what sort of notification | |||
| the subscriber wishes to be notified of. | |||
| A SUBSCRIBE request MUST have a Call-Back header unless it is a re- | |||
| subscription request. The Call-Back header specifies how the subscriber | |||
| is to be contacted in order to deliver the notification. | |||
| A SUBSCRIBE method MUST NOT have a NTS header. The base subscription | |||
| search filter only supports filtering on the NT value of a | |||
| notification. This limitation is meant to keep the subscription | |||
| functionality at the minimum useful level. It is expected that future | |||
| specifications will provide for more flexible subscription search | |||
| filters. | |||
| A SUBSCRIBE method MUST have a scope header unless it is a re- | |||
| subscription request. The scope header identifies the resource that the | |||
| subscriber wishes to receive notifications about. | |||
| The Timeout request header, whose syntax is defined in section 9.8 of | |||
| [WEBDAV] MAY be used on a SUBSCRIBE request. The header is used to | |||
| request that a subscription live for the specified period of time | |||
| before having to be renewed. Subscription arbiters are free to ignore | |||
| this header. | |||
| A subscription arbiter MUST ignore the body of a SUBSCRIBE request if | |||
| it does not understand that body. | |||
| A successful response to the SUBSCRIBE method MUST include a Timeout | |||
| response header and a SUBID header. | |||
| Cohen et al. [Page 8] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| [Add a note that if no Scope header is included then the default is to | |||
| treat the Request-URI as the scope.] | |||
| [What do you do if someone subscribes to something they are already | |||
| subscribed to? The question is tricky because, short of using | |||
| authentication, you don’t know who “someone” is and even then, because | |||
| multiple programs may be running, you can’t be sure if you are really | |||
| talking to the same person. My instinct would be to just give them a | |||
| second parallel subscription.] | |||
| 8.1 Re-Subscribing | |||
| When the period of time specified in the Timeout response header passes | |||
| the subscription MAY expire. In order to keep the subscription alive | |||
| the subscriber MUST issue a SUBSCRIBE method with a SID header set to | |||
| the subscription to be re-subscribed. A re-subscribe request MUST NOT | |||
| have a NT header but it MAY have a Timeout and/or a Call-Back header. | |||
| Note that the value in the Timeout response header will not take into | |||
| account the time needed from when the value was generated until it was | |||
| passed through the arbiter, put on the wire, sent to the subscriber, | |||
| parsed by the subscriber’s system and finally passed to the | |||
| subscriber’s program. Hence the value should be taken as an absolute | |||
| upper bound. Subscribers are encouraged to re-subscribe a good period | |||
| of time before the actual expiration of the subscription. | |||
| 8.2 Response Codes | |||
| 200 (OK) - The subscription request has been successfully processed and | |||
| a subscription ID assigned. | |||
| 400 (Bad Request) - A required header is missing. | |||
| 412 Precondition Failed - Either the subscription arbiter doesn't | |||
| support any of the call-backs, doesn't support the NT or doesn't | |||
| support the scope. This code is also used on resubscription requests to | |||
| indicate that the subscription no longer exists. | |||
| 8.3 Examples | |||
| 8.3.1 Subscription | |||
| SUBSCRIBE dude HTTP/1.1 | |||
| Host: iamthedude:203 | |||
| NT: ixl:pop | |||
| Call-Back: <http://blah/bar:923> | |||
| Scope: http://icky/pop | |||
| Timeout: Infinite | |||
| HTTP/1.1 200 O.K. | |||
| Subscription-ID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6 | |||
| Timeout: Second-604800 | |||
| Cohen et al. [Page 9] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| This subscription request asks the subscription arbiter | |||
| http://iamthedude/dude:203 for a subscription on notifications of type | |||
| ixl:pop from the resource http://icky/pop. | |||
| 8.3.2 Re-Subscription | |||
| SUBSCRIBE dude HTTP/1.1 | |||
| Host: iamthedude:203 | |||
| Subscription-ID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6 | |||
| Timeout: Infinite | |||
| HTTP/1.1 200 O.K. | |||
| Subscription-ID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6 | |||
| Timeout: Second-604800 | |||
| The subscription has been successfully renewed. | |||
| 9 UNSUBSCRIBE HTTP Method | |||
| The UNSUBSCRIBE method is used to terminate a subscription. The | |||
| UNSUBSCRIBE method MUST include a SID header with the value of the | |||
| subscription to be un-subscribed. | |||
| If the SID identifies a subscription that the subscription arbiter does | |||
| not recognize or knows is already expired then the arbiter MUST respond | |||
| with a 200 (OK). | |||
| 9.1 Response Codes | |||
| 200 (OK) - Unsubscribe succeeded. | |||
| 412 (Precondition Failed) – The SID was not recognized. | |||
| 9.2 Example | |||
| UNSUBSCRIBE dude HTTP/1.1 | |||
| Host: iamtheproxy:203 | |||
| SID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6 | |||
| HTTP/1.1 200 O.k. | |||
| 10 New HTTP Headers | |||
| 10.1 NT Header | |||
| [Think REALLY hard about allowing for multiple values in a NT header] | |||
| The NT header is used to indicate the notification type. | |||
| NT = "NT" ":" absoluteURI ; See section 3 of [RFC2396] | |||
| Cohen et al. [Page 10] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| 10.2 NTS Response Header | |||
| The NTS response header is used to indicate the notification sub-type | |||
| of a notification. | |||
| NTS = "NTS" ":" absoluteURI | |||
| 10.3 Call-Back Header | |||
| The Call-Back header specifies, in order of preference, the means the | |||
| subscriber would like the subscription arbiter to use to deliver | |||
| notifications. | |||
| Call-Back = "Call-Back" ":" *Coded-URI; See section 9.4 of [WEBDAV] | |||
| 10.4 Timeout Response Header | |||
| The Timeout response header has the same syntax as the Timeout request | |||
| header defined in section 9.8 of [WEBDAV]. The subscription arbiter | |||
| informs the subscriber how long the subscription arbiter will keep | |||
| their subscription active without a re-subscribe using the Timeout | |||
| response header. | |||
| 10.5 SID Header | |||
| The SID header contains a subscription ID. | |||
| SID = "SID" ":" absoluteURI | |||
| 10.6 Scope Request Header | |||
| The scope request header indicates the resource the subscriber wishes | |||
| to receive notifications about. | |||
| SCOPE = "Scope" ":" absoluteURI | |||
| 11 Future Work | |||
| This specification defines a minimally useful set of notification | |||
| functionality. It does not, however, address three critical issues that | |||
| are needed by some notification environments. It is expected that all | |||
| of these features can be provided in extension specifications to this | |||
| base specification. | |||
| The first issue is polling. In some environments, especially those with | |||
| intermittent connectivity, it would be desirable for subscription | |||
| arbiters to be able to pool up notifications and then to deliver them | |||
| when the subscriber asks for them. | |||
| The second issue is subscription arbiter to subscription arbiter | |||
| communication. It is likely that subscription arbiters will want to | |||
| communicate directly with each other in order to efficiently distribute | |||
| Cohen et al. [Page 11] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| notifications and subscriptions. This requires provision for | |||
| notification routing and loop prevention. | |||
| The third issue is support for depth functionality. In some systems one | |||
| wishes to receive a notification about a resource and any of its | |||
| children as the term is defined in [WEBDAV]. | |||
| 12 Security Considerations | |||
| TBD. | |||
| [Notes: | |||
| The really horrible security concerns don't start until you build the | |||
| subscription arbiter to arbiter protocol. Otherwise the arbiter is very | |||
| close to a proxy in that it takes confidential information from a | |||
| subscriber and/or notifying resource and is expected to do the right | |||
| thing (TM) with it. Authentication and such prevents bogus | |||
| notifications and subscriptions. | |||
| Another problem is if someone sends in a subscription request with the | |||
| call-back pointing at someone else. This could be used for a denial of | |||
| service attack. Arbiters should authenticate subscribers and probably | |||
| the call-back points as well.] | |||
| 13 Acknowledgements | |||
| Jesus Ruiz-Scougall (Exchange) | |||
| Erik Christensen (VB) (Exchange) | |||
| Ting Cai | |||
| 14 IANA Considerations | |||
| None. | |||
| 15 Copyright | |||
| The following copyright notice is copied from RFC 2026 [Bradner, 1996], | |||
| Section 10.4, and describes the applicable copyright for this document. | |||
| Copyright (C) The Internet Society February 10, 1998. All Rights | |||
| Reserved. | |||
| This document and translations of it may be copied and furnished to | |||
| others, and derivative works that comment on or otherwise explain it or | |||
| assist in its implementation may be prepared, copied, published and | |||
| distributed, in whole or in part, without restriction of any kind, | |||
| provided that the above copyright notice and this paragraph are | |||
| included on all such copies and derivative works. However, this | |||
| document itself may not be modified in any way, such as by removing the | |||
| copyright notice or references to the Internet Society or other | |||
| Internet organizations, except as needed for the purpose of developing | |||
| Internet standards in which case the procedures for copyrights defined | |||
| in the Internet Standards process must be followed, or as required to | |||
| translate it into languages other than English. | |||
| Cohen et al. [Page 12] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| The limited permissions granted above are perpetual and will not be | |||
| revoked by the Internet Society or its successors or assignees. | |||
| This document and the information contained herein is provided on an | |||
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |||
| TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT | |||
| NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL | |||
| NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR | |||
| FITNESS FOR A PARTICULAR PURPOSE. | |||
| 16 Intellectual Property | |||
| The following notice is copied from RFC 2026 [Bradner, 1996], Section | |||
| 10.4, and describes the position of the IETF concerning intellectual | |||
| property claims made against this document. | |||
| The IETF takes no position regarding the validity or scope of any | |||
| intellectual property or other rights that might be claimed to pertain | |||
| to the implementation or use other technology described in this | |||
| document or the extent to which any license under such rights might or | |||
| might not be available; neither does it represent that it has made any | |||
| effort to identify any such rights. Information on the IETF's | |||
| procedures with respect to rights in standards-track and standards- | |||
| related documentation can be found in BCP-11. Copies of claims of | |||
| rights made available for publication and any assurances of licenses to | |||
| be made available, or the result of an attempt made to obtain a general | |||
| license or permission for the use of such proprietary rights by | |||
| implementers or users of this specification can be obtained from the | |||
| IETF Secretariat. | |||
| The IETF invites any interested party to bring to its attention any | |||
| copyrights, patents or patent applications, or other proprietary rights | |||
| which may cover technology that may be required to practice this | |||
| standard. Please address the information to the IETF Executive | |||
| Director. | |||
| 17 References | |||
| [WEBDAV] | |||
| [Bradner, 1996] S. Bradner, "The Internet Standards Process - Revision | |||
| 3." RFC 2026, BCP 9. Harvard University. October, 1996. | |||
| [HTTPMU] <draft-goland-http-udp-00.txt> | |||
| [HTTP11] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, | |||
| P. Leach and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. | |||
| Internet Draft – Work in Progress. http://www.ietf.org/internet- | |||
| drafts/draft-ietf-http-v11-spec-rev-06.txt, November 18, 1998. | |||
| [RFC2396] http://www.rfc-editor.org/rfc/rfc2396.txt | |||
| Cohen et al. [Page 13] | |||
| INTERNET-DRAFT GENA Base September 6, 2000 | |||
| 18 Authors' Addresses | |||
| Josh Cohen, Sonu Aggarwal, Yaron Y. Goland | |||
| Microsoft Corporation | |||
| One Microsoft Way | |||
| Redmond, WA 98052-6399 | |||
| Email: {joshco,sonuag,yarong}@microsoft.com | |||
| Cohen et al. [Page 14] | |||
| @@ -0,0 +1,348 @@ | |||
| UPnP Forum Technical Committee Yaron Y. Goland | |||
| Document: draft-goland-fxpp-01.txt CrossGain | |||
| Jeffrey C. Schlimmer | |||
| Microsoft Corporation | |||
| 19 June 2000 | |||
| Flexible XML Processing Profile (FXPP) | |||
| Status of this Memo | |||
| This document is under review by the UPnP Forum Technical Committee. | |||
| It was previously submitted to the IETF as an Internet Draft and has | |||
| expired. This document is formatted in a manner consistent with the | |||
| IETF formatting guidelines to facilitate possible future | |||
| consideration by the IETF. | |||
| This document is available on http://www.upnp.org. | |||
| Abstract | |||
| This document provides an independent reference for the XML | |||
| processing profile developed by the WebDAV WG in [RFC2518]. It does | |||
| this by copying Section 14 and Appendix 4 as well as examples from | |||
| Appendix 3 of [RFC2518] and editing out any WebDAV specific parts. | |||
| This document also defines handling of unknown XML attributes. | |||
| This information has been broken out into its own independent | |||
| reference in order to make it easier for other standards to | |||
| reference just the WebDAV XML processing profile without having to | |||
| reference the entire WebDAV standard or require their readers to | |||
| understand which parts of the profile are WebDAV specific and which | |||
| parts are not. | |||
| 1. Introduction | |||
| This document provides an independent reference for the XML | |||
| processing profile developed by the WebDAV WG in [RFC2518]. It does | |||
| this by copying Section 14 and Appendix 4 as well as examples from | |||
| Appendix 3 of [RFC2518] and editing out any WebDAV specific parts. | |||
| This document also defines handling of unknown XML attributes. | |||
| This information has been broken out into its own independent | |||
| reference in order to make it easier for other standards to | |||
| reference just the WebDAV XML processing profile without having to | |||
| reference the entire WebDAV standard or require their readers to | |||
| understand which parts of the profile are WebDAV specific and which | |||
| parts are not. | |||
| Goland, Schlimmer 1 | |||
| UPnP Forum FXPP 19 June 2000 | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | |||
| this document are to be interpreted as described in [RFC2119]. | |||
| 2. XML Support Requirement | |||
| All FXPP compliant systems MUST support [XML]. | |||
| 3. XML Ignore Rule | |||
| All FXPP compliant XML processors (a) MUST ignore any unknown XML | |||
| element and all its children, and (b) MUST ignore any unknown XML | |||
| attribute and its value. This rule may be overridden on an element- | |||
| by-element or attribute-by-attribute basis, but implementers should | |||
| be aware that systems unfamiliar with the element or attribute will | |||
| follow the ignore rule. | |||
| 4. XML Mime Type Support | |||
| A FXPP compliant system MUST be able to both accept and send | |||
| text/xml and application/xml. | |||
| 5. Ordering of XML Elements | |||
| Unless the definition of a XML element explicitly specifies | |||
| otherwise the ordering of XML elements has no semantic significance | |||
| to FXPP compliant systems. | |||
| Note to Implementers - A generic FXPP compliant XML processor will | |||
| not know which of the elements it is processing have meaningful | |||
| ordering. As such, such processors need to maintain the order of | |||
| the elements when presenting the parsed information so as not to | |||
| loose any meaningful data. | |||
| 6. XML Namespace Support | |||
| All FXPP compliant systems MUST support the XML namespace extensions | |||
| as specified in [REC-XML-NAMES]. | |||
| FXPP compliant XML processors MUST interpret a qualified name as a | |||
| URI constructed by appending the LocalPart to the namespace name | |||
| URI. | |||
| Example | |||
| <del:glider xmlns:del="http://www.del.jensen.org/"> | |||
| <del:glidername> | |||
| Johnny Updraft | |||
| </del:glidername> | |||
| <del:glideraccidents/> | |||
| </del:glider> | |||
| Goland, Schlimmer 2 | |||
| UPnP Forum FXPP 19 June 2000 | |||
| In this example, the qualified element name "del:glider" is | |||
| interpreted as the URL "http://www.del.jensen.org/glider". | |||
| <bar:glider xmlns:bar="http://www.del.jensen.org/"> | |||
| <bar:glidername> | |||
| Johnny Updraft | |||
| </bar:glidername> | |||
| <bar:glideraccidents/> | |||
| </bar:glider> | |||
| Even though this example is syntactically different from the | |||
| previous example, it is semantically identical. Each instance of | |||
| the namespace name "bar" is replaced with | |||
| "http://www.del.jensen.org/" and then appended to the local name for | |||
| each element tag. The resulting tag names in this example are | |||
| exactly the same as for the previous example. | |||
| <foo:r xmlns:foo="http://www.del.jensen.org/glide"> | |||
| <foo:rname> | |||
| Johnny Updraft | |||
| </foo:rname> | |||
| <foo:raccidents/> | |||
| </foo:r> | |||
| This example is semantically identical to the two previous ones. | |||
| Each instance of the namespace name "foo" is replaced with | |||
| "http://www.del.jensen.org/glide" which is then appended to the | |||
| local name for each element tag, the resulting tag names are | |||
| identical to those in the previous examples. | |||
| 7. XML Element Declaration Syntax | |||
| The following format is recommended for FXPP compliant | |||
| specifications as a means to provide uniform declaration of XML | |||
| elements. | |||
| Name: | |||
| Namespace: | |||
| Purpose: | |||
| Value: | |||
| DTD | |||
| The name is the name of the XML element. The Namespace is the | |||
| namespace the element belongs to. The purpose is a short | |||
| description of the use of the XML element. As DTDs are not very | |||
| good at expressing the format of characters inside of an XML element | |||
| when an XML element needs to contain formatted pcdata the optional | |||
| Value description will be used to provide a BNF for the character | |||
| data. At the end of the template is the ELEMENT DTD declaration for | |||
| the element. | |||
| 8. Notes on Empty XML Elements | |||
| Goland, Schlimmer 3 | |||
| UPnP Forum FXPP 19 June 2000 | |||
| XML supports two mechanisms for indicating that an XML element does | |||
| not have any content. The first is to declare an XML element of the | |||
| form <A></A>. The second is to declare an XML element of the form | |||
| <A/>. The two XML elements are semantically identical. | |||
| It is a violation of the XML specification to use the <A></A> form | |||
| if the associated DTD declares the element to be EMPTY (e.g., | |||
| <!ELEMENT A EMPTY>). If such a statement is included, then the | |||
| empty element format, <A/> must be used. If the element is not | |||
| declared to be EMPTY, then either form <A></A> or <A/> may be used | |||
| for empty elements. | |||
| 9. Notes on Illegal XML Processing | |||
| XML is a flexible data format that makes it easy to submit data that | |||
| appears legal but in fact is not. The philosophy of "Be flexible in | |||
| what you accept and strict in what you send" still applies, but it | |||
| must not be applied inappropriately. XML is extremely flexible in | |||
| dealing with issues of white space, element ordering, inserting new | |||
| elements, etc. This flexibility does not require extension, | |||
| especially not in the area of the meaning of elements. | |||
| There is no kindness in accepting illegal combinations of XML | |||
| elements. At best it will cause an unwanted result and at worst it | |||
| can cause real damage. | |||
| 9.1. Example - XML Syntax Error | |||
| The following request body for a WebDAV PROPFIND method is illegal. | |||
| <?xml version="1.0" encoding="utf-8" ?> | |||
| <D:propfind xmlns:D="DAV:"> | |||
| <D:allprop/> | |||
| <D:propname/> | |||
| </D:propfind> | |||
| The definition of the propfind element only allows for the allprop | |||
| or the propname element, not both. Thus the above is an error and | |||
| must be responded to with a 400 (Bad Request). | |||
| Imagine, however, that a server wanted to be "kind" and decided to | |||
| pick the allprop element as the true element and respond to it. A | |||
| client running over a bandwidth limited line who intended to execute | |||
| a propname would be in for a big surprise if the server treated the | |||
| command as an allprop. | |||
| Additionally, if a server were lenient and decided to reply to this | |||
| request, the results would vary randomly from server to server, with | |||
| some servers executing the allprop directive, and others executing | |||
| the propname directive. This reduces interoperability rather than | |||
| increasing it. | |||
| Goland, Schlimmer 4 | |||
| UPnP Forum FXPP 19 June 2000 | |||
| 9.2. Example - Unknown XML Element | |||
| The previous example was illegal because it contained two elements | |||
| that were explicitly banned from appearing together in the propfind | |||
| element. However, XML is an extensible language, so one can imagine | |||
| new elements being defined for use with propfind. Below is the | |||
| request body of a PROPFIND and, like the previous example, must be | |||
| rejected with a 400 (Bad Request) by a server that does not | |||
| understand the expired-props element. | |||
| <?xml version="1.0" encoding="utf-8" ?> | |||
| <D:propfind xmlns:D="DAV:" | |||
| xmlns:E="http://www.foo.bar/standards/props/"> | |||
| <E:expired-props/> | |||
| </D:propfind> | |||
| To understand why a 400 (Bad Request) is returned let us look at the | |||
| request body as the server unfamiliar with expired-props sees it. | |||
| <?xml version="1.0" encoding="utf-8" ?> | |||
| <D:propfind xmlns:D="DAV:" | |||
| xmlns:E="http://www.foo.bar/standards/props/"> | |||
| </D:propfind> | |||
| As the server does not understand the expired-props element, | |||
| according to the WebDAV-specific XML processing rules specified in | |||
| section 14 of [RFC 2518], it must ignore it. Thus the server sees | |||
| an empty propfind, which by the definition of the propfind element | |||
| is illegal. | |||
| Please note that had the extension been additive it would not | |||
| necessarily have resulted in a 400 (Bad Request). For example, | |||
| imagine the following request body for a PROPFIND: | |||
| <?xml version="1.0" encoding="utf-8" ?> | |||
| <D:propfind xmlns:D="DAV:" | |||
| xmlns:E="http://www.foo.bar/standards/props/"> | |||
| <D:propname/> | |||
| <E:leave-out>*boss*</E:leave-out> | |||
| </D:propfind> | |||
| The previous example contains the fictitious element leave-out. Its | |||
| purpose is to prevent the return of any property whose name matches | |||
| the submitted pattern. If the previous example were submitted to a | |||
| server unfamiliar with leave-out, the only result would be that the | |||
| leave-out element would be ignored and a propname would be executed. | |||
| 10. References | |||
| [RFC2119] S. Bradner. Key words for use in RFCs to Indicate | |||
| Requirement Levels. RFC 2119, March 1997. | |||
| Goland, Schlimmer 5 | |||
| UPnP Forum FXPP 19 June 2000 | |||
| [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. | |||
| Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC 2068, | |||
| January 1997. | |||
| [RFC2158] Y. Goland, E. Whitehead, A. Faizi, S. Carter, and D. | |||
| Jensen. HTTP Extensions for Distributed Authoring WEBDAV. RFC 2518, | |||
| February 1999. | |||
| [XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup | |||
| Language (XML)." World Wide Web Consortium Recommendation REC-xml- | |||
| 19980210. http://www.w3.org/TR/1998/REC-xml-19980210. | |||
| 11. Author's Addresses | |||
| Yaron Y. Goland | |||
| CrossGain | |||
| 2039 152nd Avenue NE | |||
| Redmond, WA 98052 | |||
| <mailto:yarongo@crossgain.com> | |||
| Jeffrey C. Schlimmer | |||
| Microsoft Corporation | |||
| One Microsoft Way | |||
| Redmond, WA 98052 | |||
| <mailto:jeffsch@Microsoft.com> | |||
| Goland, Schlimmer 6 | |||
| @@ -0,0 +1,928 @@ | |||
| UPnP Forum Technical Committee Yaron Y. Goland | |||
| Document: draft-goland-http-udp-04.txt CrossGain | |||
| Jeffrey C. Schlimmer | |||
| Microsoft | |||
| 02 October 2000 | |||
| Multicast and Unicast UDP HTTP Messages | |||
| Status of this Memo | |||
| This document is under review by the UPnP Forum Technical Committee. | |||
| It was previously submitted to the IETF as an Internet Draft and has | |||
| expired. This document is formatted in a manner consistent with the | |||
| IETF formatting guidelines to facilitate possible future | |||
| consideration by the IETF. | |||
| This document is available on http://www.upnp.org. | |||
| Abstract | |||
| This document provides rules for encapsulating HTTP messages in | |||
| multicast and unicast UDP packets to be sent within a single | |||
| administrative scope. No provisions are made for guaranteeing | |||
| delivery beyond re-broadcasting. | |||
| 1. Introduction | |||
| This document provides rules for encapsulating HTTP messages in | |||
| multicast and unicast UDP messages. No provisions are made for | |||
| guaranteeing delivery beyond re-broadcasting. | |||
| This technology is motivated by applications such as SSDP where it | |||
| is expected that messages which are primarily transmitted over TCP | |||
| HTTP need to be transmitted over Multicast or Unicast UDP, because | |||
| of the unique requirements of extremely lightweight servers. | |||
| This document will not specify a mechanism suitable for replacing | |||
| HTTP over TCP. Rather this document will define a limited mechanism | |||
| only suitable for extreme circumstances where the use of TCP is | |||
| impossible. Thus this mechanism will not have the robustness of | |||
| functionality and congestion control provided by TCP. It is expected | |||
| that in practice the mechanisms specified here in will only be used | |||
| as a means to get to TCP based HTTP communications. | |||
| 2. Changes | |||
| 2.1. Since 00 | |||
| Divided each section of the spec into three parts, problem | |||
| definition, proposed solution and design rationale. When the spec is | |||
| ready for standardization the problem definition and design | |||
| rationale sections will be removed. Design rationale is presented in | |||
| Goland, Schlimmer 1 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| question/answer form because I have found that to be very effective | |||
| in addressing design issues. | |||
| Clarified that a HTTPU/HTTPMU URI without an abs_path translates to | |||
| "*" in the request-URI. | |||
| Added the S header to allow request and responses to be associated. | |||
| Note that while clients aren't required to send out S headers, | |||
| servers are required to return them. | |||
| Got rid of MM. The lower bound is always 0. | |||
| The introduction of the S header makes proxying and caching possible | |||
| so the sections on those topics have been expanded, but they should | |||
| be considered experimental at best. | |||
| 2.2. Since 02 | |||
| Added requirement for HTTP/1.1 as the version identifier in the | |||
| request line. (See section on HTTP Version in Request Line.) | |||
| Removed requirement that requests without an S header MUST NOT be | |||
| responded to. (See section on Unicast UDP HTTP Messages.) | |||
| Clarified that a server should respond to each request it receives | |||
| but not duplicate those responses. (See section on Retrying | |||
| Requests.) | |||
| Clarified caching when responding to repeated requests. (See section | |||
| on Caching.) | |||
| Expanded that if a server has > 1 response per HTTPMU request, it | |||
| should spread them out. (See section on MX header.) | |||
| Tied behavior of duplicate responses with the same S header value to | |||
| the semantics of the method (was discard duplicates). (See section | |||
| on S header.) | |||
| Outlined initial security considerations. (See section on Security.) | |||
| 2.3. Since 03 | |||
| Clarified the "no abs_path" requirement for HTTPU/HTTPMU request- | |||
| URIs. | |||
| Clarified use of "*" as a request-URI. | |||
| Removed requirement for HTTPU/HTTPMU servers to support "chunked" | |||
| transfer-coding. | |||
| 3. Terminology | |||
| Since this document describes a set of extensions to the HTTP/1.1 | |||
| protocol, the augmented BNF used herein to describe protocol | |||
| Goland, Schlimmer 2 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| elements is exactly the same as described in section 2.1 of | |||
| [RFC2616]. Since this augmented BNF uses the basic production rules | |||
| provided in section 2.2 of [RFC2616], these rules apply to this | |||
| document as well. | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| 4. HTTPU URL | |||
| 4.1. Problem Definition | |||
| A mechanism is needed to allow for communications that are to be | |||
| sent over Unicast UDP HTTP to be identified in the URI namespace. | |||
| 4.2. Proposed Solution | |||
| The HTTPU URL specifies that the HTTP request be sent over unicast | |||
| UDP according to the rules laid out in this document. | |||
| HTTPU_URL = "HTTPU:" "//" host [ ":" port ] [ abs path [ "?" query]] | |||
| The BNF productions host, port and abs path are defined in | |||
| [RFC2616]. | |||
| The syntax of the HTTPU URL is to be processed identically to the | |||
| HTTP URL with the exception of the transport. | |||
| One MUST NOT assume that if a HTTP, HTTPU or HTTPMU URL are | |||
| identical in all ways save the protocol that they necessarily point | |||
| to the same resource. | |||
| 4.3. Design Rationale | |||
| 4.3.1. Why would we ever need a HTTPU/HTTPMU URL? | |||
| Imagine one wants to tell a system to send responses over HTTPU. How | |||
| would one express this? If one uses a HTTP URL there is no way for | |||
| the system to understand that you really meant HTTPU. | |||
| 5. HTTPMU URL | |||
| 5.1. Problem Definition | |||
| A mechanism is needed to allow for communications that are to be | |||
| sent over Multicast UDP HTTP to be identified in the URI namespace. | |||
| 5.2. Proposed Solution | |||
| The HTTPMU URL specifies that the HTTP request that HTTP request is | |||
| to be sent over multicast UDP according to the rules laid out in | |||
| this document. | |||
| Goland, Schlimmer 3 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| HTTPMU_URL = "HTTPMU:" "//" host [ ":" port ] [ abs path [ "?" | |||
| query]] | |||
| The BNF productions host, port and abs path are defined in | |||
| [RFC2616]. | |||
| The syntax of the HTTPMU URL is to be processed identically to the | |||
| HTTP URL with the exception of the transport. | |||
| One MUST NOT assume that if a HTTP, HTTPU or HTTPMU URL are | |||
| identical in all ways save the protocol that they necessarily point | |||
| to the same resource. | |||
| If a HTTPMU URL does not have an abs path element then when the HTTP | |||
| multicast UDP request is made the request-URI MUST be "*". | |||
| For example, HTTPU://www.foo.com would translate into a request-URI | |||
| of "*". A request-URI of HTTPU://www.foo.com/ would still translate | |||
| to the absoluteURI "HTTPU://www.foo.com/". | |||
| 5.3. Design Rationale | |||
| 5.3.1. In the HTTPMU URL a request such as http://www.foo.com is | |||
| translated to a "*" in the request-URI rather than a "/", why | |||
| isn't the same the case for HTTPU? | |||
| A HTTPU request is a point-to-point request. There is one sender and | |||
| one receiver. Thus the semantics of the URL are identical to HTTP | |||
| with the exception of the transport. | |||
| Generally, a HTTPMU client will want to send its request to many | |||
| receivers at once, where each receiver represents a different set of | |||
| resources. A client can specify this in the HTTPMU request itself by | |||
| using the request-URI "*". Unfortunately, there is no present way to | |||
| construct an HTTP URL that will have this request-URI. As such, a | |||
| mechanism had to be added. | |||
| 5.3.2. Why would an HTTPMU client want to use a request-URI of "*" | |||
| anyway? | |||
| In TCP HTTP, the client will often specify a single resource on | |||
| which the request should operate. For example, a GET of the URL | |||
| http://foo.org/baz.gif should retrieve the resource at that single, | |||
| well-defined location. | |||
| One big reason for a client to send a request over multicast UDP, | |||
| though, is the ability to send a request to many receivers at once, | |||
| even when the number of receivers is not known. | |||
| Specifying an absoluteURI in the request, though, would defeat this; | |||
| all receivers without that exact resource would be forced to reject | |||
| the request. | |||
| Goland, Schlimmer 4 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| By specifying a request-URI of "*" client signifies that the request | |||
| "does not apply to a particular resource, but to the server itself, | |||
| and is only allowed when the method used does not necessarily apply | |||
| to a resource." [RFC 2616] | |||
| 5.3.3. So when would an HTTPMU client want to use a request-URI other | |||
| than "*"? | |||
| This may be useful when a client knows the URI for the resource, but | |||
| not the server on which the resource lives. If the client knows | |||
| both, though, it is expected that TCP HTTP or HTTPU would be used. | |||
| Servers MUST NOT assume that an HTTPMU request containing an | |||
| absoluteURI necessarily refers to the same resource as a HTTPU | |||
| request with the same absoluteURI. For example, servers that support | |||
| both HTTPMU and HTTPU may reject a request for a particular resource | |||
| when received through HTTPMU, but accept it when received through | |||
| HTTPU. | |||
| 6. HTTP Version in Request Line | |||
| 6.1. Problem Definition | |||
| A message format identifier is needed for the HTTPU and HTTPMU | |||
| request lines. | |||
| 6.2. Proposed Solution | |||
| Request lines for HTTPU and HTTPMU requests MUST use HTTP/1.1 as the | |||
| version. | |||
| Request-Line = Method SP Request-URI SP HTTP/1.1 CRLF | |||
| The BNF production Method is defined in [RFC2616]. | |||
| 6.3. Design Rationale | |||
| 6.3.1. Why not define separate HTTPU and HTTPMU versions? | |||
| While HTTP/1.1 does hint at underlying features (like pipelining), | |||
| it principally specifies a message format. HTTPU and HTTPMU use the | |||
| same message format as defined by HTTP/1.1. Reusing this message | |||
| format identifier enables syntactic parsing / generating of HTTPU | |||
| and HTTPMU request by existing HTTP message mungers. | |||
| 6.3.2. If the version in the request line is the same as an HTTP | |||
| request, once a request was stored, how could one distinguish an | |||
| HTTPU (or HTTPMU) request from an HTTP request? | |||
| TBD | |||
| 7. Unicast UDP HTTP Messages | |||
| Goland, Schlimmer 5 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| 7.1. Problem Definition | |||
| A mechanism is needed to send HTTP messages over the unicast UDP | |||
| transport. | |||
| 7.2. Proposed Solution | |||
| HTTP messages sent over unicast UDP function identically to HTTP | |||
| messages sent over TCP as defined in [RFC2616] except as specified | |||
| below. | |||
| For brevity's sake HTTP messages sent over unicast UDP will be | |||
| referred to as HTTPU messages. | |||
| HTTPU messages MUST fit entirely in a single UDP message. If a HTTPU | |||
| message can not be fit into a single UDP message then it MUST NOT be | |||
| sent using unicast UDP. Incomplete HTTPU messages SHOULD be ignored. | |||
| The request-URI of a HTTPU message MUST always be fully qualified. | |||
| A single unicast UDP message MUST only contain a single HTTPU | |||
| message. As such, an HTTPU server MAY reject messages with "chunked" | |||
| transfer-coding. | |||
| When responding to a HTTPU request with an S header the rules for | |||
| the proper handling of S headers, as specified below MUST be | |||
| followed. | |||
| 7.3. Design Rationale | |||
| See also the subsection on the S header below for the design | |||
| rationale of the S header. | |||
| 7.3.1. Why can't a single HTTP message be sent over multiple UDP | |||
| messages? | |||
| The ability to send unlimited size messages across the Internet is | |||
| one of the key features of TCP. The goal of this paper is not to | |||
| reinvent TCP but rather to provide a very simple emergency back up | |||
| HTTP system that can leverage UDP where TCP cannot be used. As such | |||
| features to allow a single HTTP message to span multiple UDP | |||
| messages is not provided. | |||
| 7.3.2. Why are request-URIs sent over HTTPU required to be fully | |||
| qualified? | |||
| A relative URI in a HTTP message is assumed to be relative to a HTTP | |||
| URL. However this would clearly be inappropriate for a HTTPU or | |||
| HTTPMU message. The easiest solution would be to simply state that a | |||
| relative URI is relative to the type of message it was sent in. But | |||
| one of the goals of this draft is to allow current HTTP message | |||
| processors to be able to munch on HTTPU/HTTPMU messages and this | |||
| would cause a change to those processors. | |||
| Goland, Schlimmer 6 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| The cost of this simplification is that you repeat the host | |||
| information, once in the URI and once in the host header. | |||
| But again, taking out the host header would make a lot of existing | |||
| HTTP message munchers very unhappy. | |||
| 7.3.3. Why is the requirement for ignoring incomplete HTTPU messages a | |||
| SHOULD instead of a MUST? | |||
| Some systems use a lot of redundant data or have good mechanisms for | |||
| handling partial data. As such they could actually do something | |||
| intelligent with a partial message. A SHOULD allows them to do this | |||
| while still making it clear that in the majority case partial | |||
| HTTPU/HTTPMU messages are going to get thrown out. | |||
| 7.3.4. Why aren't multiple HTTP messages allowed into a single UDP | |||
| message if they will fit? | |||
| It was easier to ban it, and it didn't seem to buy us much. It was | |||
| especially worrying because it would start to convince people that | |||
| they could actually order their UDP requests in a pipelinesque | |||
| manner. It was easier to just keep things simple and ban it. | |||
| 7.3.5. Why aren't we allowed to leave off content-lengths if only a | |||
| single HTTPU message is allowed in a UDP message? | |||
| In general we try to only change from RFC 2616 when we are forced | |||
| to. Although including a content-length is annoying it makes it easy | |||
| to use HTTP/1.1 message parsing/generating systems with this spec. | |||
| 7.3.6. Why might a HTTPU message choose to not have an S header? | |||
| Leaving off the S header would be useful for throwaway events. In | |||
| systems with a high event rate it is usually easier to just throw | |||
| away an event rather than re-sending it. As such there is no real | |||
| benefit to correlating unnecessary responses with requests. | |||
| 7.3.7. Why isn't the MX header used on HTTPU messages? | |||
| As HTTPU messages are point-to-point there will be exactly one | |||
| response. MX is only useful in cases, such as HTTPMU requests, where | |||
| there can be many potential responses from numerous different | |||
| clients. MX helps to prevent the client from getting creamed with | |||
| responses. | |||
| 7.3.8. Can I send 1xx responses over HTTPU? | |||
| Yes. Error handling is identical to RFC 2616. | |||
| 8. Multicast UDP HTTP Requests | |||
| 8.1. Problem Definition | |||
| Goland, Schlimmer 7 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| A mechanism is needed to send HTTP messages over the multicast UDP | |||
| transport. | |||
| 8.2. Proposed Solution | |||
| HTTP messages sent over multicast UDP MUST obey all the requirements | |||
| for HTTPU messages in addition to the requirements provided below. | |||
| For brevity's sake HTTP messages sent over multicast UDP will be | |||
| referred to as HTTPMU messages. | |||
| Resources that support receiving multicast UDP HTTP requests MUST | |||
| honor the MX header if included in the request. | |||
| If a resource has a single response, it MUST generate a random | |||
| number between 0 and MX that represents the number of seconds the | |||
| resource MUST wait before sending a response. If a resource has | |||
| multiple responses per request, it SHOULD send these resources | |||
| spread over the interval [0..MX]. This prevents all responses from | |||
| being sent at once. | |||
| HTTP clients SHOULD keep listening for responses for a reasonable | |||
| delta of time after MX. That delta will be based on the type of | |||
| network the request is being sent over. This means that if a server | |||
| cannot respond to a request before MX then there is little point in | |||
| sending the response, as the client will most likely not be | |||
| listening for it. | |||
| When used with a multicast UDP HTTP request, the "*" request-URI | |||
| means "to everyone who is listening to this IP address and port." | |||
| A HTTPMU request without a MX header MUST NOT be responded to. | |||
| 8.3. Design Rationale | |||
| 8.3.1. Why is there a "delta" after the MX time when the client should | |||
| still be listening? | |||
| So let's say the MX value is 5 seconds. The HTTP resource generates | |||
| a number between 0 and 5 and gets 5. After 5 seconds of waiting the | |||
| HTTP resource will send its response. | |||
| Now for some math: | |||
| 0.5 seconds - Time it took the client's request to reach | |||
| the HTTP resource. | |||
| 5 seconds - Time the HTTP resource waited after | |||
| receiving the message to respond, based on | |||
| the MX value. | |||
| 0.5 seconds - Time for the response to get back to the | |||
| client. | |||
| Total time elapsed - 6 seconds | |||
| Goland, Schlimmer 8 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| If the client only waits 5 seconds, the MX value, then they would | |||
| have stopped listening for this response by the time it arrived, | |||
| hence the need for the delta. | |||
| 8.3.2. What should the "delta" after MX expires be? | |||
| Unfortunately this is an impossible question to answer. How fast is | |||
| your network? How far is the message going? Is there any congestion? | |||
| In general delta values will be set based on a combination of | |||
| heuristics and application necessity. That is, if you are displaying | |||
| information to a user any data that comes in after 20 or 30 seconds | |||
| is probably too late. | |||
| 8.3.3. When would a HTTPMU request not be responded to? | |||
| When a HTTP resource is making a general announcement, such as "I am | |||
| here", it generally isn't useful to have everyone respond confirming | |||
| they received the message. This is especially the case given that | |||
| the HTTP resource probably doesn't know who should have received the | |||
| announcement so the absence of a HTTP client in the responses | |||
| wouldn't be meaningful. | |||
| Whether a particular request requires a response is dependant on the | |||
| application, and is beyond the scope of this specification. | |||
| 8.3.4. Why do we require the MX header on HTTPMU requests that are to | |||
| be responded to? | |||
| This is to prevent overloading the HTTP client. If all the HTTP | |||
| resources responded simultaneously the client would probably loose | |||
| most of the responses as its UDP buffer overflowed. | |||
| 9. Retrying Requests | |||
| 9.1. Problem Definition | |||
| UDP is an unreliable transport with no failure indicators; as such | |||
| some mechanism is needed to reasonably increase the chance that a | |||
| HTTPU/HTTPMU message will be delivered. | |||
| 9.2. Proposed Solution | |||
| UDP is an inherently unreliable transport and subject to routers | |||
| dropping packets without notice. Applications requiring delivery | |||
| guarantees SHOULD NOT use HTTPU or HTTPMU. | |||
| In order to increase the probability that a HTTPU or HTTPMU message | |||
| is delivered the message MAY be repeated several times. If a | |||
| multicast resource would send a response(s) to any copy of the | |||
| request, it SHOULD send its response(s) to each copy of the request | |||
| it receives. It MUST NOT repeat its response(s) per copy of the | |||
| reuqest. | |||
| Goland, Schlimmer 9 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| In order to prevent the network from being flooded a message SHOULD | |||
| NOT be repeated more than MAX_RETRIES time. A random period of time | |||
| between 0 and MAX_RETRY_INTERVAL SHOULD be selected between each | |||
| retry to determine how long to wait before issuing the retry. | |||
| 9.3. Design Rationale | |||
| 9.3.1. Why is the requirement "applications requiring delivery | |||
| guarantees should not use HTTPU or HTTPMU" only a SHOULD and not | |||
| a MUST? | |||
| Because there might come a day when it makes sense to use HTTPU or | |||
| HTTPMU for guaranteed delivery and there is no reason to completely | |||
| ban the possibility. | |||
| 9.3.2. Why is the requirement that a request not be repeated more than | |||
| MAX_RETRIES times a SHOULD and not a MUST? | |||
| Local knowledge may make the limit unnecessary. For example, if one | |||
| knew that the message was being delivered using a super reliable | |||
| network then repeats are not necessary. Similarly if one knew that | |||
| the network the requests were going through were particularly | |||
| unreliable and assuming one had properly accounted for the effects | |||
| of additional messages on that congestion, one might have a good | |||
| reason to send more than MAX_RETRIES. | |||
| 9.3.3. Why SHOULD multicast resources respond to each copy of a request | |||
| it receives? | |||
| Because the earlier responses might have been lost. | |||
| 9.3.4. Why MUST multicast resources not repeat its response(s) to each | |||
| copy of a request it receives? | |||
| This strategy provides the lowest network loading for any desired | |||
| level of reliability, or equivalently, the highest reliability for | |||
| any specified level of network loading. | |||
| 10. Caching | |||
| 10.1. Problem Definition | |||
| Caching is a feature that has demonstrated its usefulness in HTTP, | |||
| provisions need to be made to ensure that HTTPU/HTTPMU messages can | |||
| be cached using a consistent algorithm. | |||
| 10.2. Proposed Solution | |||
| [Ed. Note: Never having tried to actually build a HTTPU/HTTPMU | |||
| generic cache we suspect there are some very serious gotchas here | |||
| that we just haven't found yet. This section should definitely be | |||
| treated as "under development."] | |||
| Goland, Schlimmer 10 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| Caching rules for HTTPU/HTTPMU responses are no different than | |||
| normal HTTP responses. HTTPU/HTTPMU responses are matched to their | |||
| requests through the S header value. | |||
| When responding to a multicast request, a resource MAY cache its | |||
| response(s) and retransmit from the cache in response to duplicate | |||
| requests. | |||
| 10.3. Design Rationale | |||
| 10.3.1. Wouldn't it be useful to be able to cache HTTPU/HTTPMU requests | |||
| if they don't have responses? | |||
| Yes, it probably would, especially if we are talking about a client- | |||
| side cache. It is probably worth investigating the use of cache | |||
| control headers on requests for this very purpose. | |||
| 11. Proxying UDP HTTP Requests | |||
| 11.1. Problem Definition | |||
| For security or caching reasons it is sometimes necessary to place a | |||
| proxy in a message path. Provisions need to be made to ensure that | |||
| HTTPU/HTTPMU messages can be proxied. | |||
| 11.2. Proposed Solution | |||
| [Ed. Note: This section should be considered experimental. No one | |||
| has really had to design much less implement a HTTPU/HTTPMU proxy | |||
| yet.] | |||
| All transport independent rules for proxying, such as length of time | |||
| to cache a response, hop-by-hop header rules, etc. are the same for | |||
| HTTPU/HTTPMU as they are for HTTP messages. | |||
| [Ed. Note: I'm not sure how far to go into the "transport | |||
| independent rules". The RFC 2616 doesn't really call them out very | |||
| well but I also don't want to have to re-write RFC 2616 spec inside | |||
| this spec.] | |||
| The transport dependent rules, however, are different. For example, | |||
| using TCP any pipelined messages are guaranteed to be delivered in | |||
| order. There are no ordering guarantees of any form for HTTPU/HTTPMU | |||
| proxies. | |||
| In general a proxy is required to forward a HTTPU/HTTPMU message | |||
| exactly once. It SHOULD NOT repeat the message. Rather the client is | |||
| expected to repeat the message and, as the proxy receives the | |||
| repeats, they will be forwarded. | |||
| Note that it is acceptable, if not encouraged, for proxies to | |||
| analyze network conditions and determine the likelihood, on both | |||
| incoming and outgoing connections, of UDP messages being dropped. If | |||
| Goland, Schlimmer 11 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| the likelihood is too high then it would be expected for the proxy, | |||
| taking into consideration the possibility of making congestion even | |||
| worse, to repeat requests and responses on its own. In a sense the | |||
| proxy could be thought of as a signal regenerator. This is why the | |||
| prohibition against repeating messages is a SHOULD NOT rather than a | |||
| MUST NOT. | |||
| HTTPMU messages are sent with the assumption that the message will | |||
| only be seen by the multicast address they were sent to. Thus when a | |||
| proxy forwards the request it is expected to only do so to the | |||
| appropriate multicast channel. Note, however, that proxies may act | |||
| as multicast bridges. | |||
| Also note that proxied HTTPMU messages with a HTTPMU URL without an | |||
| absolute path are to be treated as if they were sent to the | |||
| specified multicast address with the request-URI "*". | |||
| If a HTTPMU request is sent with a host that does not resolve to a | |||
| multicast address then the request MUST be rejected with a 400 Bad | |||
| Request error. | |||
| There is no requirement that a HTTPU proxy support HTTPMU or vice | |||
| versa. | |||
| 11.3. Design Rationale | |||
| 11.3.1. Why would anyone proxy HTTPMU requests? | |||
| Proxying HTTPMU requests can be a neat way to create virtual | |||
| multicast channels. Just hook a bunch of proxies together with | |||
| unicast connections and tell the proxies' users that they are all on | |||
| the same multicast scope. | |||
| 12. HTTP Headers | |||
| 12.1. AL (Alternate Location) General Header | |||
| 12.1.1. Problem Definition | |||
| There are many instances in which a system needs to provide location | |||
| information using multiple URIs. The LOCATION header only allows a | |||
| single URI. Therefore a mechanism is needed to allow multiple | |||
| location URIs to be returned. | |||
| 12.1.2. Proposed Solution | |||
| AL = "AL" ":" 1*("<" AbsoluteURI ">") ; AbsoluteURI is defined in | |||
| section 3.2.1 of [RFC2616] | |||
| The AL header is an extension of the LOCATION header whose semantics | |||
| are the same as the LOCATION header. That is, the AL header allows | |||
| one to return multiple locations where as the LOCATION header allows | |||
| one to return only one. The contents of an AL header are ordered. If | |||
| Goland, Schlimmer 12 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| both a LOCATION header and an AL header are included in the same | |||
| message then the URI in the LOCATION header is to be treated as if | |||
| it were the first entry in the AL header. The AL header MAY be used | |||
| by itself but implementers should be aware that existing systems | |||
| will ignore the header. | |||
| 12.1.3. Design Rationale | |||
| 12.1.3.1. Why not just fix the BNF for the LOCATION header? | |||
| This is tempting but the goal of maintaining compatibility with RFC | |||
| 2616's message format overrides the usefulness of this solution. | |||
| 12.2. MX Request Header | |||
| 12.2.1. Problem Definition | |||
| A mechanism is needed to ensure that responses to HTTPMU requests do | |||
| not come at a rate greater than the requestor can handle. | |||
| 12.2.2. Proposed Solution | |||
| MX = "MX" ":" Integer | |||
| Integer = First_digit *More_digits | |||
| First_digit = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | |||
| More_digits = "0" | First_digit | |||
| The value of the MX header indicates the maximum number of seconds | |||
| that a multicast UDP HTTP resource MUST wait before it sends a | |||
| response stimulated by a multicast request. | |||
| HTTP resources MAY treat any MX header value greater than MX_MAX as | |||
| being equal to MX_MAX. | |||
| 12.2.3. Design Rationale | |||
| 12.2.3.1. Why is MX in seconds? | |||
| In practice wait periods shorter than a second proved useless and | |||
| longer proved too coarse. Of course as faster networks get deployed | |||
| finer-grain times would be useful, but we need a compromise | |||
| measurement that will meet everyone's needs. Seconds seem to do that | |||
| quite well. | |||
| 12.2.3.2. Couldn't MX still overload the requestor if there are too | |||
| many responders? | |||
| Absolutely. If there are a 100,000 clients that want to respond even | |||
| pushing them over 30 seconds on a 10 Mbps link is still going to | |||
| blow both the client and the network away. However the only way to | |||
| prevent these sorts of situations is to know the current available | |||
| network bandwidth and the total number of likely responders ahead of | |||
| Goland, Schlimmer 13 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| time. Both generally prove between difficult to impossible to figure | |||
| out. So we are left with heuristics and the MX header. | |||
| 12.3. S (Sequence) General Header | |||
| 12.3.1. Problem Definition | |||
| A mechanism is needed to associate HTTPU/HTTPMU requests with | |||
| responses, as UDP does not have any connection semantics. | |||
| 12.3.2. Proposed Solution | |||
| S = "S" ":" AbsoluteURI | |||
| The S header is a URI that is unique across the entire URI namespace | |||
| for all time. When an S header is sent on a HTTPU/HTTPMU request it | |||
| MUST be returned, with the same value, on the response. | |||
| If a client receives multiple responses with the same S header then | |||
| the client MAY assume that all the responses are in response to the | |||
| same request. If the messages differ from each other then the client | |||
| MUST behave based on the specification of the request method. | |||
| 12.3.3. Design Rationale | |||
| 12.3.3.1. Why do we need the S header? | |||
| Without an S header the only way to match requests with responses is | |||
| to ensure that there is enough information in the response to know | |||
| what request it was intended to answer. Even in that case it is | |||
| still possible to confuse which request a response goes to if it | |||
| does not have the equivalent of an S header. | |||
| 12.3.3.2. Why aren't S headers mandatory on all requests with a | |||
| response? | |||
| Some systems don't need them. | |||
| 12.3.3.3. Why aren't S headers guaranteed to be sequential so you could | |||
| do ordering? | |||
| Because HTTPU/HTTPMU is not interested in ordering. If one wants | |||
| ordering one should use TCP. | |||
| 12.3.3.4. Do S headers allow detecting and removing duplicates? | |||
| Yes, for methods (like GET) that define a single responses to a | |||
| request. No, for methods (like SEARCH) that define multiple | |||
| responses to a request. | |||
| 13. Interaction of HTTP, HTTPU and HTTPMU Messages | |||
| 13.1. Problem Definition | |||
| Goland, Schlimmer 14 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| [Ed. Note: Concerns include HTTPU request redirected to HTTP? > 1 | |||
| HTTPU responses to 1 HTTPMU request?] | |||
| 13.2. Proposed Solution | |||
| TBD | |||
| 13.3. Design Rationale | |||
| TBD | |||
| 14. Security Considerations | |||
| All the normal HTTP security considerations apply. | |||
| 14.1. Cookies | |||
| There is no danger that the S header will be used as a cookie since | |||
| the client generates it, and the server returns it. (A cookie is | |||
| generated by a server and returned by the client.) | |||
| 14.2. Spoofing | |||
| Servers and multicast resources could fake S headers, but this is | |||
| not a major threat if some form of authentication over UDP is used. | |||
| (Defining authentication over UDP is beyond the scope of this | |||
| document, but briefly, one could assume the challenge and send the | |||
| authentication response as part of the HTTPU/MU request.) | |||
| 14.3. Lost Requests | |||
| TBD | |||
| 14.4. Oversized Requests | |||
| TBD | |||
| 15. Acknowledgements | |||
| Thanks to John Stracke for his excellent comments. Dale Worley | |||
| devised the single-response-per-each-copy-of-request mechanism | |||
| outlined in the section on Retrying Requests. Chris Rude clarified | |||
| request URI rules. | |||
| 16. Constants | |||
| MAX_RETRIES - 3 | |||
| MAX_RETRY_INTERVAL - 10 seconds | |||
| MAX_MX - 120 seconds | |||
| 17. Reference | |||
| Goland, Schlimmer 15 | |||
| UPnP Forum UDP HTTP 24 Aug 2000 | |||
| [RFC2119] S. Bradner. Key words for use in RFCs to Indicate | |||
| Requirement Levels. RFC 2119, March 1997. | |||
| [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. | |||
| Masinter, P. Leach and T. Berners-Lee. Hypertext Transfer Protocol - | |||
| HTTP/1.1. RFC 2616, November 1998. | |||
| 18. Authors' Address | |||
| Yaron Y. Goland | |||
| CrossGain | |||
| 2039 152nd Avenue NE | |||
| Redmond, WA 98052 | |||
| <mailto:yarongo@crossgain.com> | |||
| Jeffrey C. Schlimmer | |||
| Microsoft Corporation | |||
| One Microsoft Way | |||
| Redmond, WA 98052 | |||
| <mailto:jeffsch@microsoft.com> | |||
| Goland, Schlimmer 16 | |||
| @@ -0,0 +1,17 @@ | |||
| <device> | |||
| <serviceList> | |||
| <service> | |||
| <serviceType>urn:schemas-upnp-org:service:RenderingControl:1</serviceType> | |||
| <serviceId>RenderingControl</serviceId> | |||
| </service> | |||
| <service> | |||
| <serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType> | |||
| <serviceId>ConnectionManager</serviceId> | |||
| </service> | |||
| <service> | |||
| <Optional/> | |||
| <serviceType>urn:schemas-upnp-org:service:AVTransport:1</serviceType> | |||
| <serviceId>AVTransport</serviceId> | |||
| </service> | |||
| </serviceList> | |||
| </device> | |||
| @@ -0,0 +1,17 @@ | |||
| <device> | |||
| <serviceList> | |||
| <service> | |||
| <Optional/> | |||
| <serviceType>urn:schemas-upnp-org:service:AVTransport:1</serviceType> | |||
| <serviceId>AVTransport</serviceId> | |||
| </service> | |||
| <service> | |||
| <serviceType>urn:schemas-upnp-org:service:ContentDirectory:1</serviceType> | |||
| <serviceId>ContentDirectory</serviceId> | |||
| </service> | |||
| <service> | |||
| <serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType> | |||
| <serviceId>ConnectionManager</serviceId> | |||
| </service> | |||
| </serviceList> | |||
| </device> | |||
| @@ -0,0 +1,477 @@ | |||
| <scpd> | |||
| <serviceStateTable> | |||
| <stateVariable> | |||
| <name>TransportState</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>STOPPED</allowedValue> | |||
| <allowedValue>PLAYING</allowedValue> | |||
| </allowedValueList> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>TransportStatus</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>OK</allowedValue> | |||
| <allowedValue>ERROR_OCCURRED</allowedValue> | |||
| </allowedValueList> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>PlaybackStorageMedium</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>RecordStorageMedium</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>PossiblePlaybackStorageMedia</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>PossibleRecordStorageMedia</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>CurrentPlayMode</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>NORMAL</allowedValue> | |||
| </allowedValueList> | |||
| <defaultValue>NORMAL</defaultValue> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>TransportPlaySpeed</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>1</allowedValue> | |||
| </allowedValueList> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <name>RecordMediumWriteStatus </name> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>CurrentRecordQualityMode</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>PossibleRecordQualityModes</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>NumberOfTracks</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui4</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>CurrentTrack</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui4</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>CurrentTrackDuration</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>CurrentMediaDuration</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>CurrentTrackMetaData</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>CurrentTrackURI</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>AVTransportURI</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>AVTransportURIMetaData</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>NextAVTransportURI</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>NextAVTransportURIMetaData</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>RelativeTimePosition</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>AbsoluteTimePosition</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>RelativeCounterPosition</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>i4</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>AbsoluteCounterPosition</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>i4</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <Optional/> | |||
| <name>CurrentTransportActions</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>LastChange</name> | |||
| <sendEventsAttribute>yes</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_SeekMode</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>TRACK_NR</allowedValue> | |||
| </allowedValueList> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_SeekTarget</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_InstanceID</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui4</dataType> | |||
| </stateVariable> | |||
| </serviceStateTable> | |||
| <actionList> | |||
| <action> | |||
| <name>SetAVTransportURI</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentURI</name> | |||
| <direction>in</direction> <relatedStateVariable>AVTransportURI</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentURIMetaData</name> | |||
| <direction>in</direction> <relatedStateVariable>AVTransportURIMetaData</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> <Optional/> | |||
| <name>SetNextAVTransportURI</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NextURI</name> | |||
| <direction>in</direction> <relatedStateVariable>NextAVTransportURI</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NextURIMetaData</name> | |||
| <direction>in</direction> <relatedStateVariable>NextAVTransportURIMetaData</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>GetMediaInfo</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NrTracks</name> | |||
| <direction>out</direction> <relatedStateVariable>NumberOfTracks</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>MediaDuration</name> | |||
| <direction>out</direction> <relatedStateVariable>CurrentMediaDuration</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentURI</name> | |||
| <direction>out</direction> <relatedStateVariable>AVTransportURI</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentURIMetaData</name> | |||
| <direction>out</direction> <relatedStateVariable>AVTransportURIMetaData</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NextURI</name> | |||
| <direction>out</direction> <relatedStateVariable>NextAVTransportURI</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NextURIMetaData</name> | |||
| <direction>out</direction> <relatedStateVariable>NextAVTransportURIMetaData</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>PlayMedium</name> | |||
| <direction>out</direction> <relatedStateVariable>PlaybackStorageMedium</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>RecordMedium</name> | |||
| <direction>out</direction> <relatedStateVariable>RecordStorageMedium</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>WriteStatus</name> | |||
| <direction>out</direction> <relatedStateVariable>RecordMediumWriteStatus </relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>GetTransportInfo</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentTransportState</name> | |||
| <direction>out</direction> <relatedStateVariable>TransportState</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentTransportStatus</name> | |||
| <direction>out</direction> <relatedStateVariable>TransportStatus</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentSpeed</name> | |||
| <direction>out</direction> <relatedStateVariable>TransportPlaySpeed</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>GetPositionInfo</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Track</name> | |||
| <direction>out</direction> <relatedStateVariable>CurrentTrack</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>TrackDuration</name> | |||
| <direction>out</direction> <relatedStateVariable>CurrentTrackDuration</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>TrackMetaData</name> | |||
| <direction>out</direction> <relatedStateVariable>CurrentTrackMetaData</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>TrackURI</name> | |||
| <direction>out</direction> <relatedStateVariable>CurrentTrackURI</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>RelTime</name> | |||
| <direction>out</direction> <relatedStateVariable>RelativeTimePosition</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>AbsTime</name> | |||
| <direction>out</direction> <relatedStateVariable>AbsoluteTimePosition</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>RelCount</name> | |||
| <direction>out</direction> <relatedStateVariable>RelativeCounterPosition</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>AbsCount</name> | |||
| <direction>out</direction> <relatedStateVariable>AbsoluteCounterPosition</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>GetDeviceCapabilities</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>PlayMedia</name> | |||
| <direction>out</direction> <relatedStateVariable>PossiblePlaybackStorageMedia</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>RecMedia</name> | |||
| <direction>out</direction> <relatedStateVariable>PossibleRecordStorageMedia</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>RecQualityModes</name> | |||
| <direction>out</direction> <relatedStateVariable>PossibleRecordQualityModes</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>GetTransportSettings</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>PlayMode</name> | |||
| <direction>out</direction> <relatedStateVariable>CurrentPlayMode</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>RecQualityMode</name> | |||
| <direction>out</direction> <relatedStateVariable>CurrentRecordQualityMode</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>Stop</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>Play</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Speed</name> | |||
| <direction>in</direction> <relatedStateVariable>TransportPlaySpeed</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> <Optional/> | |||
| <name>Pause</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> <Optional/> | |||
| <name>Record</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>Seek</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Unit</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_SeekMode</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Target</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_SeekTarget</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>Next</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>Previous</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> <Optional/> | |||
| <name>SetPlayMode</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NewPlayMode</name> | |||
| <direction>in</direction> <relatedStateVariable>CurrentPlayMode</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> <Optional/> | |||
| <name>SetRecordQualityMode</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NewRecordQualityMode</name> | |||
| <direction>in</direction> <relatedStateVariable>CurrentRecordQualityMode</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> <Optional/> | |||
| <name>GetCurrentTransportActions</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Actions</name> | |||
| <direction>out</direction> <relatedStateVariable>CurrentTransportActions</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| </actionList> | |||
| </scpd> | |||
| @@ -0,0 +1,170 @@ | |||
| <scpd> | |||
| <serviceStateTable> | |||
| <stateVariable> | |||
| <name>SourceProtocolInfo</name> | |||
| <sendEventsAttribute>yes</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>SinkProtocolInfo</name> | |||
| <sendEventsAttribute>yes</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>CurrentConnectionIDs</name> | |||
| <sendEventsAttribute>yes</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_ConnectionStatus</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>OK</allowedValue> | |||
| <allowedValue>ContentFormatMismatch</allowedValue> | |||
| <allowedValue>InsufficientBandwidth</allowedValue> | |||
| <allowedValue>UnreliableChannel</allowedValue> | |||
| <allowedValue>Unknown</allowedValue> | |||
| </allowedValueList> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_ConnectionManager</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_Direction</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>Input</allowedValue> | |||
| <allowedValue>Output</allowedValue> | |||
| </allowedValueList> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_ProtocolInfo</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_ConnectionID</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>i4</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_AVTransportID</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>i4</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_RcsID</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>i4</dataType> | |||
| </stateVariable> | |||
| </serviceStateTable> | |||
| <actionList> | |||
| <action> | |||
| <name>GetProtocolInfo</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>Source</name> | |||
| <direction>out</direction> <relatedStateVariable>SourceProtocolInfo</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Sink</name> | |||
| <direction>out</direction> <relatedStateVariable>SinkProtocolInfo</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <Optional/> | |||
| <name>PrepareForConnection</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>RemoteProtocolInfo</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_ProtocolInfo</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>PeerConnectionManager</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_ConnectionManager</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>PeerConnectionID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_ConnectionID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Direction</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_Direction</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>ConnectionID</name> | |||
| <direction>out</direction> <relatedStateVariable>A_ARG_TYPE_ConnectionID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>AVTransportID</name> | |||
| <direction>out</direction> <relatedStateVariable>A_ARG_TYPE_AVTransportID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>RcsID</name> | |||
| <direction>out</direction> <relatedStateVariable>A_ARG_TYPE_RcsID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <Optional/> | |||
| <name>ConnectionComplete</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>ConnectionID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_ConnectionID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>GetCurrentConnectionIDs</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>ConnectionIDs</name> | |||
| <direction>out</direction> <relatedStateVariable>CurrentConnectionIDs</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>GetCurrentConnectionInfo</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>ConnectionID</name> | |||
| <direction>in</direction> <relatedStateVariable>A_ARG_TYPE_ConnectionID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>RcsID</name> | |||
| <direction>out</direction> <relatedStateVariable>A_ARG_TYPE_RcsID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>AVTransportID</name> | |||
| <direction>out</direction> <relatedStateVariable>A_ARG_TYPE_AVTransportID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>ProtocolInfo</name> | |||
| <direction>out</direction> <relatedStateVariable>A_ARG_TYPE_ProtocolInfo</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>PeerConnectionManager</name> | |||
| <direction>out</direction> <relatedStateVariable>A_ARG_TYPE_ConnectionManager</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>PeerConnectionID</name> | |||
| <direction>out</direction> <relatedStateVariable>A_ARG_TYPE_ConnectionID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Direction</name> | |||
| <direction>out</direction> <relatedStateVariable>A_ARG_TYPE_Direction</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Status</name> | |||
| <direction>out</direction> <relatedStateVariable>A_ARG_TYPE_ConnectionStatus</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| </actionList> | |||
| </scpd> | |||
| @@ -0,0 +1,405 @@ | |||
| <scpd> | |||
| <serviceStateTable> | |||
| <stateVariable> <Optional/> | |||
| <name>TransferIDs</name> | |||
| <sendEventsAttribute>yes</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_ObjectID</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_Result</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> <Optional/> | |||
| <name>A_ARG_TYPE_SearchCriteria</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_BrowseFlag</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>BrowseMetadata</allowedValue> | |||
| <allowedValue>BrowseDirectChildren</allowedValue> | |||
| </allowedValueList> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_Filter</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_SortCriteria</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_Index</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui4</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_Count</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui4</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_UpdateID</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui4</dataType> | |||
| </stateVariable> | |||
| <stateVariable> <Optional/> | |||
| <name>A_ARG_TYPE_TransferID</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui4</dataType> | |||
| </stateVariable> | |||
| <stateVariable> <Optional/> | |||
| <name>A_ARG_TYPE_TransferStatus</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>COMPLETED</allowedValue> | |||
| <allowedValue>ERROR</allowedValue> | |||
| <allowedValue>IN_PROGRESS</allowedValue> | |||
| <allowedValue>STOPPED</allowedValue> | |||
| </allowedValueList> | |||
| </stateVariable> | |||
| <stateVariable> <Optional/> | |||
| <name>A_ARG_TYPE_TransferLength</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> <Optional/> | |||
| <name>A_ARG_TYPE_TransferTotal</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> <Optional/> | |||
| <name>A_ARG_TYPE_TagValueList</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> <Optional/> | |||
| <name>A_ARG_TYPE_URI</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>uri</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>SearchCapabilities</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>SortCapabilities</name> | |||
| <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>SystemUpdateID</name> | |||
| <sendEventsAttribute>yes</sendEventsAttribute> | |||
| <dataType>ui4</dataType> | |||
| </stateVariable> | |||
| <stateVariable> <Optional/> | |||
| <name>ContainerUpdateIDs</name> | |||
| <sendEventsAttribute>yes</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| </serviceStateTable> | |||
| <actionList> | |||
| <action> | |||
| <name>GetSearchCapabilities</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>SearchCaps</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>SearchCapabilities </relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>GetSortCapabilities</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>SortCaps</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>SortCapabilities</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>GetSystemUpdateID</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>Id</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>SystemUpdateID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>Browse</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>ObjectID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_ObjectID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>BrowseFlag</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_BrowseFlag</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Filter</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Filter</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>StartingIndex</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Index</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>RequestedCount</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Count</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>SortCriteria</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_SortCriteria</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Result</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Result</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NumberReturned</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Count</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>TotalMatches</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Count</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>UpdateID</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_UpdateID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>Search</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>ContainerID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_ObjectID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>SearchCriteria</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_SearchCriteria </relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Filter</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Filter</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>StartingIndex</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Index</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>RequestedCount</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Count</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>SortCriteria</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_SortCriteria</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Result</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Result</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NumberReturned</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Count</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>TotalMatches</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Count</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>UpdateID</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_UpdateID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>CreateObject</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>ContainerID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_ObjectID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Elements</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Result</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>ObjectID</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_ObjectID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Result</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Result</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>DestroyObject</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>ObjectID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_ObjectID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>UpdateObject</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>ObjectID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_ObjectID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentTagValue</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_TagValueList </relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NewTagValue</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_TagValueList </relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>ImportResource</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>SourceURI</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_URI</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DestinationURI</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_URI</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>TransferID</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_TransferID </relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>ExportResource</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>SourceURI</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_URI</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DestinationURI</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_URI</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>TransferID</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_TransferID </relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>StopTransferResource</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>TransferID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_TransferID </relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetTransferProgress</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>TransferID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_TransferID </relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>TransferStatus</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_TransferStatus </relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>TransferLength</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_TransferLength </relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>TransferTotal</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_TransferTotal</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>DeleteResource</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>ResourceURI</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_URI</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>CreateReference</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>ContainerID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_ObjectID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>ObjectID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_ObjectID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>NewID</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_ObjectID</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| </actionList> | |||
| </scpd> | |||
| @@ -0,0 +1,718 @@ | |||
| <scpd> | |||
| <serviceStateTable> | |||
| <stateVariable> | |||
| <name>PresetNameList</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>LastChange</name> <sendEventsAttribute>yes</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>Brightness</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>Contrast</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>Sharpness</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>RedVideoGain</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>GreenVideoGain</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>BlueVideoGain</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>RedVideoBlackLevel</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>GreenVideoBlackLevel</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>BlueVideoBlackLevel</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>ColorTemperature</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>HorizontalKeystone</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>i2</dataType> | |||
| <allowedValueRange> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>VerticalKeystone</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>i2</dataType> | |||
| <allowedValueRange> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>Mute</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>boolean</dataType> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>Volume</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui2</dataType> | |||
| <allowedValueRange> | |||
| <minimum>0</minimum> | |||
| <step>1</step> | |||
| </allowedValueRange> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>VolumeDB</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>i2</dataType> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>Loudness</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>boolean</dataType> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>A_ARG_TYPE_Channel</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>Master</allowedValue> | |||
| </allowedValueList> | |||
| </stateVariable> | |||
| <stateVariable><Optional/> | |||
| <name>A_ARG_TYPE_InstanceID</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>ui4</dataType> | |||
| </stateVariable> | |||
| <stateVariable> | |||
| <name>A_ARG_TYPE_PresetName</name> <sendEventsAttribute>no</sendEventsAttribute> | |||
| <dataType>string</dataType> | |||
| <allowedValueList> | |||
| <allowedValue>FactoryDefaults</allowedValue> | |||
| </allowedValueList> | |||
| </stateVariable> | |||
| </serviceStateTable> | |||
| <actionList> | |||
| <action> | |||
| <name>ListPresets</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentPresetNameList</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>PresetNameList</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action> | |||
| <name>SelectPreset</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>PresetName</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_PresetName</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetBrightness</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentBrightness</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>Brightness</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetBrightness</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredBrightness</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>Brightness</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetContrast</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentContrast</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>Contrast</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetContrast</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredContrast</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>Contrast</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetSharpness</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentSharpness</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>Sharpness</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetSharpness</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredSharpness</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>Sharpness</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetRedVideoGain</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentRedVideoGain</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>RedVideoGain</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetRedVideoGain</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredRedVideoGain</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>RedVideoGain</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetGreenVideoGain</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentGreenVideoGain</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>GreenVideoGain</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetGreenVideoGain</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredGreenVideoGain</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>GreenVideoGain</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetBlueVideoGain</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentBlueVideoGain</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>BlueVideoGain</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetBlueVideoGain</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredBlueVideoGain</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>BlueVideoGain</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetRedVideoBlackLevel</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentRedVideoBlackLevel</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>RedVideoBlackLevel</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetRedVideoBlackLevel</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredRedVideoBlackLevel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>RedVideoBlackLevel</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetGreenVideoBlackLevel</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentGreenVideoBlackLevel</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>GreenVideoBlackLevel</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetGreenVideoBlackLevel</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredGreenVideoBlackLevel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>GreenVideoBlackLevel</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetBlueVideoBlackLevel</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentBlueVideoBlackLevel</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>BlueVideoBlackLevel</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetBlueVideoBlackLevel</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredBlueVideoBlackLevel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>BlueVideoBlackLevel</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetColorTemperature </name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentColorTemperature</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>ColorTemperature</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetColorTemperature</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredColorTemperature</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>ColorTemperature</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetHorizontalKeystone</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentHorizontalKeystone</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>HorizontalKeystone</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetHorizontalKeystone</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredHorizontalKeystone</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>HorizontalKeystone</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetVerticalKeystone</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentVerticalKeystone</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>VerticalKeystone</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetVerticalKeystone</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredVerticalKeystone</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>VerticalKeystone</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetMute</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Channel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Channel</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentMute</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>Mute</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetMute</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Channel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Channel</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredMute</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>Mute</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetVolume</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Channel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Channel</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentVolume</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>Volume</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetVolume</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Channel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Channel</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredVolume</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>Volume</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetVolumeDB</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Channel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Channel</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentVolume</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>VolumeDB</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetVolumeDB</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Channel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Channel</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredVolume</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>VolumeDB</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetVolumeDBRange</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Channel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Channel</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>MinValue</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>VolumeDB</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>MaxValue</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>VolumeDB</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>GetLoudness</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Channel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Channel</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>CurrentLoudness</name> | |||
| <direction>out</direction> | |||
| <relatedStateVariable>Loudness</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| <action><Optional/> | |||
| <name>SetLoudness</name> | |||
| <argumentList> | |||
| <argument> | |||
| <name>InstanceID</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>Channel</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>A_ARG_TYPE_Channel</relatedStateVariable> | |||
| </argument> | |||
| <argument> | |||
| <name>DesiredLoudness</name> | |||
| <direction>in</direction> | |||
| <relatedStateVariable>Loudness</relatedStateVariable> | |||
| </argument> | |||
| </argumentList> | |||
| </action> | |||
| </actionList> | |||
| </scpd> | |||
| @@ -0,0 +1,168 @@ | |||
| <ServiceControlSyntaxTestCases> | |||
| <ServiceType>AVTransport</ServiceType> | |||
| <ServiceVersion>1</ServiceVersion> | |||
| <TestCaseList> | |||
| <TestCase> | |||
| <Id>1</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetAVTransportURI</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <CurrentURI>any-string</CurrentURI> | |||
| <CurrentURIMetaData>any-string</CurrentURIMetaData> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>2</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetNextAVTransportURI</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <NextURI>any-string</NextURI> | |||
| <NextURIMetaData>any-string</NextURIMetaData> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>3</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetMediaInfo</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>4</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetTransportInfo</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>5</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetPositionInfo</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>6</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetDeviceCapabilities</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>7</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetTransportSettings</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>8</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>Stop</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>9</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>Play</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Speed>1</Speed> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>10</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>Pause</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>11</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>Record</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>12</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>Seek</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Unit>TRACK_NR</Unit> | |||
| <Target>1</Target> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>13</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>Next</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>14</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>Previous</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>15</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetPlayMode</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <NewPlayMode>NORMAL</NewPlayMode> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>16</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetRecordQualityMode</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <NewRecordQualityMode>any-string</NewRecordQualityMode> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>17</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetCurrentTransportActions</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| </TestCaseList> | |||
| </ServiceControlSyntaxTestCases> | |||
| @@ -0,0 +1,48 @@ | |||
| <ServiceControlSyntaxTestCases> | |||
| <ServiceType>ConnectionManager</ServiceType> | |||
| <ServiceVersion>1</ServiceVersion> | |||
| <TestCaseList> | |||
| <TestCase> | |||
| <Id>1</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetProtocolInfo</ActionName> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>2</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>PrepareForConnection</ActionName> | |||
| <InArgs> | |||
| <RemoteProtocolInfo>any-string</RemoteProtocolInfo> | |||
| <PeerConnectionManager>any-string</PeerConnectionManager> | |||
| <PeerConnectionID>-1</PeerConnectionID> | |||
| <Direction>Input</Direction> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>3</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>ConnectionComplete</ActionName> | |||
| <InArgs> | |||
| <ConnectionID>0</ConnectionID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>4</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetCurrentConnectionIDs</ActionName> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>5</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetCurrentConnectionInfo</ActionName> | |||
| <InArgs> | |||
| <ConnectionID>0</ConnectionID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| </TestCaseList> | |||
| </ServiceControlSyntaxTestCases> | |||
| @@ -0,0 +1,146 @@ | |||
| <ServiceControlSyntaxTestCases> | |||
| <ServiceType>ContentDirectory</ServiceType> | |||
| <ServiceVersion>1</ServiceVersion> | |||
| <TestCaseList> | |||
| <TestCase> | |||
| <Id>1</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetSearchCapabilities</ActionName> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>2</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetSortCapabilities</ActionName> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>3</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetSystemUpdateID</ActionName> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>4</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>Browse</ActionName> | |||
| <InArgs> | |||
| <ObjectID>0</ObjectID> | |||
| <BrowseFlag>BrowseMetadata</BrowseFlag> | |||
| <Filter>dc:title</Filter> | |||
| <StartingIndex>0</StartingIndex> | |||
| <RequestedCount>0</RequestedCount> | |||
| <SortCriteria></SortCriteria> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>5</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>Search</ActionName> | |||
| <InArgs> | |||
| <ContainerID>0</ContainerID> | |||
| <SearchCriteria>dc:title contains "Rock"</SearchCriteria> | |||
| <Filter>dc:title</Filter> | |||
| <StartingIndex>0</StartingIndex> | |||
| <RequestedCount>0</RequestedCount> | |||
| <SortCriteria></SortCriteria> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>6</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>CreateObject</ActionName> | |||
| <InArgs> | |||
| <ContainerID>0</ContainerID> | |||
| <Elements> | |||
| <DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"> | |||
| <item id="" parentID="0" restricted="false"> | |||
| <dc:title>Test Object - CDS Syntax Text Case #6</dc:title> | |||
| <upnp:class>object.item</upnp:class> | |||
| </item> | |||
| </DIDL-Lite> | |||
| </Elements> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>7</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>DestroyObject</ActionName> | |||
| <InArgs> | |||
| <ObjectID>0</ObjectID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>8</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>UpdateObject</ActionName> | |||
| <InArgs> | |||
| <ObjectID>0</ObjectID> | |||
| <CurrentTagValue>any-string</CurrentTagValue> | |||
| <NewTagValue>any-string</NewTagValue> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>9</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>ImportResource</ActionName> | |||
| <InArgs> | |||
| <SourceURI>http://host/path/file</SourceURI> | |||
| <DestinationURI>http://host/path/file</DestinationURI> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>10</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>ExportResource</ActionName> | |||
| <InArgs> | |||
| <SourceURI>http://host/path/file</SourceURI> | |||
| <DestinationURI>http://host/path/file</DestinationURI> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>11</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>StopTransferResource</ActionName> | |||
| <InArgs> | |||
| <TransferID>0</TransferID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>12</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetTransferProgress</ActionName> | |||
| <InArgs> | |||
| <TransferID>0</TransferID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>13</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>DeleteResource</ActionName> | |||
| <InArgs> | |||
| <ResourceURI>http://host/path/file</ResourceURI> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>14</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>CreateReference</ActionName> | |||
| <InArgs> | |||
| <ContainerID>0</ContainerID> | |||
| <ObjectID>0</ObjectID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| </TestCaseList> | |||
| </ServiceControlSyntaxTestCases> | |||
| @@ -0,0 +1,347 @@ | |||
| <ServiceControlSyntaxTestCases> | |||
| <ServiceType>RenderingControl</ServiceType> | |||
| <ServiceVersion>1</ServiceVersion> | |||
| <TestCaseList> | |||
| <TestCase> | |||
| <Id>1</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>ListPresets</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>2</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SelectPreset</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <PresetName>FactoryDefaults</PresetName> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>3</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetBrightness</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>4</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetBrightness</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredBrightness>0</DesiredBrightness> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>5</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetContrast</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>6</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetContrast</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredContrast>0</DesiredContrast> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>7</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetRedVideoGain</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>8</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetRedVideoGain</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredRedVideoGain>0</DesiredRedVideoGain> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>9</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetGreenVideoGain</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>10</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetGreenVideoGain</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredGreenVideoGain>0</DesiredGreenVideoGain> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>11</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetBlueVideoGain</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>12</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetBlueVideoGain</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredBlueVideoGain>0</DesiredBlueVideoGain> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>13</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetRedVideoBlackLevel</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>14</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetRedVideoBlackLevel</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredRedVideoBlackLevel>0</DesiredRedVideoBlackLevel> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>15</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetGreenVideoBlackLevel</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>16</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetGreenVideoBlackLevel</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredGreenVideoBlackLevel>0</DesiredGreenVideoBlackLevel> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>17</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetBlueVideoBlackLevel</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>18</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetBlueVideoBlackLevel</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredBlueVideoBlackLevel>0</DesiredBlueVideoBlackLevel> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>19</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetColorTemperature</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>20</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetColorTemperature</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredColorTemperature>0</DesiredColorTemperature> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>21</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetHorizontalKeystone</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>22</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetHorizontalKeystone</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredHorizontalKeystone>0</DesiredHorizontalKeystone> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>23</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetVerticalKeystone</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>24</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetVerticalKeystone</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredVerticalKeystone>0</DesiredVerticalKeystone> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>25</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetSharpness</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>26</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetSharpness</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <DesiredSharpness>0</DesiredSharpness> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>27</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetMute</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Channel>Master</Channel> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>28</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetMute</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Channel>Master</Channel> | |||
| <DesiredMute>1</DesiredMute> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>29</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetVolume</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Channel>Master</Channel> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>30</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetVolume</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Channel>Master</Channel> | |||
| <DesiredVolume>0</DesiredVolume> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>31</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetVolumeDB</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Channel>Master</Channel> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>32</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetVolumeDB</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Channel>Master</Channel> | |||
| <DesiredVolume>0</DesiredVolume> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>33</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetVolumeDBRange</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Channel>Master</Channel> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>34</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>GetLoudness</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Channel>Master</Channel> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| <TestCase> | |||
| <Id>35</Id> | |||
| <Category>Valid Action And Valid InArgs</Category> | |||
| <ActionName>SetLoudness</ActionName> | |||
| <InArgs> | |||
| <InstanceID>0</InstanceID> | |||
| <Channel>Master</Channel> | |||
| <DesiredLoudness>1</DesiredLoudness> | |||
| </InArgs> | |||
| <ExpectedReturnCode>ACTION_AND_INARGS_ARE_VALID</ExpectedReturnCode> | |||
| </TestCase> | |||
| </TestCaseList> | |||
| </ServiceControlSyntaxTestCases> | |||