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> |